February 2022 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1193889] [Build 20211215] openQA test fails in reconnect_mgmt_console because yast.ssh can not restart the operating system
by bugzilla_noreply＠suse.com 23 Feb '22

23 Feb '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1193889 http://bugzilla.opensuse.org/show_bug.cgi?id=1193889#c47 --- Comment #47 from Sarah Kriesch <ada.lovelace(a)gmx.de> --- The new openQA result is here: https://openqa.opensuse.org/tests/2204125#step/reconnect_mgmt_console/9 -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1193889] [Build 20211215] openQA test fails in reconnect_mgmt_console because yast.ssh can not restart the operating system
by bugzilla_noreply＠suse.com 23 Feb '22

23 Feb '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1193889 http://bugzilla.opensuse.org/show_bug.cgi?id=1193889#c46 --- Comment #46 from Sarah Kriesch <ada.lovelace(a)gmx.de> --- The restart is failing continuously, but it seems, that there are more problems with the kernel. I can identify in the logs (memsample.zcat) this part with processes: 075 ? 15416 14407 1008 2192 1200 1645 sshd: root@pts/3 2081 pts/3 8472 7424 1047 1548 1936 2075 -bash 2118 pts/3 4540 3492 1047 1092 612 2081 /bin/bash /sbin/yast.ssh 2119 pts/3 7628 6580 1047 1544 1132 2118 /bin/bash /usr/lib/YaST2/startup/YaST2.First-Stage 3267 pts/3 7768 6720 1047 1544 1272 2119 /bin/bash /usr/lib/YaST2/startup/YaST2.call installation initial 3688 pts/3 678452 678448 3 260064 350692 3267 /usr/bin/ruby.ruby3.1 --encoding=utf-8 /usr/lib/YaST2/bin/y2start installation --arg initial ncurses 43560 pts/3 0 0 0 0 0 3688 [get_kernel_vers] <defunct> 43627 pts/3 0 0 0 0 0 3688 [get_kernel_vers] <defunct> Mark or IBM: We need somebody with mainframe system access to reproduce and debug the kernel in this case now. You can find the download links in https://bugzilla.opensuse.org/show_bug.cgi?id=1193889#c37 -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1196060] systemtap fails to build simple example from docs
by bugzilla_noreply＠suse.com 22 Feb '22

22 Feb '22

https://bugzilla.suse.com/show_bug.cgi?id=1196060 https://bugzilla.suse.com/show_bug.cgi?id=1196060#c5 --- Comment #5 from Tony Jones <tonyj(a)suse.com> --- ok. definitely a regression here vs SP3. I'll look at it. # stap -vv --poison-cache -l 'module("ext4").function("*")' ... derive-probes (location #0): module("ext4").function("*") of keyword at <input>:1:1 semantic error: resolution failed in DWARF builder thrown from: elaborate.cxx:1093 semantic error: resolution failed in DWARF builder thrown from: elaborate.cxx:1093 semantic error: while resolving probe point: identifier 'module' at <input>:1:7 thrown from: elaborate.cxx:1081 source: probe module("ext4").function("*") {} ^ semantic error: no match thrown from: elaborate.cxx:1044 -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1196209] New: The system often fails to reboot and hangs on "Reach target" after updating to Kernel 5.16.8, btrfs related?
by bugzilla_noreply＠suse.com 22 Feb '22

22 Feb '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1196209 Bug ID: 1196209 Summary: The system often fails to reboot and hangs on "Reach target" after updating to Kernel 5.16.8, btrfs related? Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: qydwhotmail(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The system often refuses to reboot after updating to 5.16.8. There are some abnormal symptoms when rebooting: 1. A 2-min wait saying waiting for a user task to finish 2. Failed to unmount /home and /var 3. Transparent dialog windows everywhere System information: Operating System: openSUSE Tumbleweed 20220218 KDE Plasma Version: 5.24.80 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.2 Kernel Version: 5.16.5-1-default (64-bit) Graphics Platform: X11 Processors: 8 � AMD Ryzen 7 4700U with Radeon Graphics Memory: 15.0 GiB of RAM Graphics Processor: AMD RENOIR There are some suspicious commits on btrfs: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/fs/bt… https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/fs/bt… https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/fs/bt… -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 1182762] uvcvideo: webcam stops working after 3 seconds
by bugzilla_noreply＠suse.com 21 Feb '22

21 Feb '22

https://bugzilla.suse.com/show_bug.cgi?id=1182762 https://bugzilla.suse.com/show_bug.cgi?id=1182762#c5 --- Comment #5 from Derek Wickersham <derek(a)wickersham.info> --- I have not attempted the camera connection until just this week. So I don't know what would have happened with other, older kernels. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1191954] btrfs fiemap results are inconsistent compared to XFS
by bugzilla_noreply＠suse.com 21 Feb '22

21 Feb '22

https://bugzilla.suse.com/show_bug.cgi?id=1191954 https://bugzilla.suse.com/show_bug.cgi?id=1191954#c1 --- Comment #1 from David Disseldorp <ddiss(a)suse.com> --- Zygo provided some background on Btrfs' fiemap behaviour in a recent upstream mailing list thread https://lore.kernel.org/all/YhMzKeX3FvJPvtmR@hungrycats.org/ : FIEMAP's output cannot correctly represent btrfs compressed data. In some cases you may be able to identify logical blocks as belonging to the same underlying compressed extent, but not with enough precision to infer data content of the blocks. The physical location of a compressed byte is a two-dimensional quantity--one to identify the physical compressed extent, one to identify the byte's offset within the decompressed data. The length is similarly two-dimensional, one for the physical size and one for the logical size. Since compressed bytes are a different size unit than uncompressed bytes, we can't add a compressed offset or length to a physical position and get a number that isn't garbage, so we can't fill in distinct values for physical location of compressed data blocks that make numerical sense. Try 'btrfs-search-metadata file' (from the python-btrfs package) for an accurate description of what's going on with the extent references. It uses TREE_SEARCH_V2 and the underlying btrfs file extent reference structure, which has the fields that FIEMAP is missing. Underneath, the compressed extent is an immutable contiguous region of storage, identified by the bytenr (virtual address) of the first byte of the storage. Each reference to the extent in the file refers to a contiguous range of the extent's logical blocks (after decompression). The fields are, in no particular order: 1. the logical offset within the file (seek offset) where the referenced data appears in the file 2. the extent bytenr (extent identifier for reference counting and backref search, first physical byte of the extent) 3. the logical length of the referenced data (the portion of the compressed data referenced at this offset in the file) 4. the logical offset within the extent where the referenced data begins (after decompressing the extent, where to start reading the data in memory) 5. the physical (compressed) length of the complete extent data (how many bytes are used in physical storage) 6. the logical (decompressed) length of the complete extent data (how much RAM is required to decompress the extent) Only the first three of these fields are available via FIEMAP. FIEMAP provides only one length field, so it can't handle compressed extents which have two distinct lengths. FIEMAP provides only one integer for physical position, so it can't handle references to blocks that are not the first block in a compressed extent. TREE_SEARCH_V2 provides all six fields, so you can get accurate logical or physical extent boundary information as needed. In simple write() cases, the offset fields are zero, so FIEMAP appears to work at first: 1. seek offset is some number, FIEMAP returns that number 2. extent bytenr is the FIEMAP physical start of extent 3. logical length of the referenced data (#3) is the same as the logical decompressed length (#6). FIEMAP gives #3. This value will change if the extent is partially overwritten in the file. 4. logical offset within the extent is 0, since the extent was created for exactly this file data reference 5. physical length of the compressed extent isn't reported in FIEMAP. Tools like 'filefrag -v' which try to compute extent boundary adjacency won't work--they will use the length in #3 when they should use field #2 + #5 to compute physical extent end boundaries. 6. logical length of the compressed extent is the same as #3. This value never changes until the extent is destroyed. In the test case, FIEMAP reports the same number at #2 for all extents since the same physical extent is referenced, but the referenced data location is actually a function of fields #2 and #4. The second and third extents have non-zero offsets for #4, and the length at #3 becomes different from the length at #6, making any computed values based on these fields nonsense. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1195887] intel/radeon graphics doesn't work due to simpledrm enablement in Kernel 5.16.8
by bugzilla_noreply＠suse.com 21 Feb '22

21 Feb '22

https://bugzilla.suse.com/show_bug.cgi?id=1195887 Stefan Dirsch <sndirsch(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|kernel-bugs(a)opensuse.org |tzimmermann(a)suse.com -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1194416] radeon drm crash
by bugzilla_noreply＠suse.com 21 Feb '22

21 Feb '22

https://bugzilla.suse.com/show_bug.cgi?id=1194416 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |https://gitlab.freedesktop. | |org/drm/amd/-/issues/1902 -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1193889] [Build 20211215] openQA test fails in reconnect_mgmt_console because yast.ssh can not restart the operating system
by bugzilla_noreply＠suse.com 21 Feb '22

21 Feb '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1193889 http://bugzilla.opensuse.org/show_bug.cgi?id=1193889#c45 --- Comment #45 from Sarah Kriesch <ada.lovelace(a)gmx.de> --- We are speaking about Tumbleweed. This issue has happened since around Christmas in openSUSE Tumbleweed. It seems, that the patch has been included in our repo 28 days ago: https://github.com/openSUSE/kernel/commit/f3b7e73b2c6619884351a3a0a7468642f… Then it has to be built and included into Tumbleweed. I have to check, whether it is fixed. Thank you all for the support! (Another openSUSE bug with s390-tools is keeping us away at the moment. We are working on it.) -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1193889] [Build 20211215] openQA test fails in reconnect_mgmt_console because yast.ssh can not restart the operating system
by bugzilla_noreply＠suse.com 21 Feb '22

21 Feb '22

https://bugzilla.suse.com/show_bug.cgi?id=1193889 https://bugzilla.suse.com/show_bug.cgi?id=1193889#c44 --- Comment #44 from LTC BugProxy <bugproxy(a)us.ibm.com> --- ------- Comment From Ulrich.Weigand(a)de.ibm.com 2022-02-21 05:26 EDT------- (In reply to comment #15) > (In reply to Sarah Kriesch from comment #42) > > Our SUSE kernel developers are on CC and they know more about which patches > > are included. > > > > @SUSE Kernel Developers: Is this patch included in our Kernel? > > https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git/commit/ > > ?h=fixes&id=abf0e8e4ef25478a4390115e6a953d589d1f9ffd > > This commit was included in 5.16-rc6, so the current TW 5.16.x kernel > already contains it, at least. > > Or was the question about other SLE/Leap kernels? The question was about the initial kernel loaded by grub2 (which then performs the kexec to the final kernel) - see the comment on 2021-12-27 16:59:16. I'm not sure how exactly this initial boot process is set up in OpenSUSE, but if the root cause of the problem is that kexec bug described above, then the specific question is whether whatever kernel is used to perform that kexec has the fix or not. -- You are receiving this mail because: You are the assignee for the bug.

1 0