September 2023 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1212169] drm:amdgpu_job_timeout
by bugzilla_noreply＠suse.com 11 Sep '23

11 Sep '23

https://bugzilla.suse.com/show_bug.cgi?id=1212169 https://bugzilla.suse.com/show_bug.cgi?id=1212169#c15 --- Comment #15 from Takashi Iwai <tiwai(a)suse.com> --- Just to be sure, could you guys check with the latest 6.5.x kernel from OBS Kernel:stable repo? Also, 6.6-rc1 will be available soon later in OBS Kernel:HEAD repo in this week. If 6.5.x still suffers from the problem, check 6.6-rc1 later, too. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1212874] External Monitor on USB-C Docking station AMD Graphics
by bugzilla_noreply＠suse.com 11 Sep '23

11 Sep '23

https://bugzilla.suse.com/show_bug.cgi?id=1212874 https://bugzilla.suse.com/show_bug.cgi?id=1212874#c12 --- Comment #12 from Takashi Iwai <tiwai(a)suse.com> --- Could you give the kernel log, as well as hwinfo output from the latest TW snapshot? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1215182] SSD's not detected in AHCI mode on GA890GPA UD3M mainboard (AMD870/SB850 chipset)
by bugzilla_noreply＠suse.com 11 Sep '23

11 Sep '23

https://bugzilla.suse.com/show_bug.cgi?id=1215182 https://bugzilla.suse.com/show_bug.cgi?id=1215182#c1 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tiwai(a)suse.com Flags| |needinfo?(michael.sauereise | |n(a)gmx.de) --- Comment #1 from Takashi Iwai <tiwai(a)suse.com> --- Could you give the full dmesg outputs from both working and non-working cases? Also give the hwinfo output from the working system, too. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1213614] Mesa-dri/aarch64: Segmentation fault in freedreno [msi-dri.so] while running on Lenovo x13s laptop
by bugzilla_noreply＠suse.com 11 Sep '23

11 Sep '23

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

1 0

[Bug 1213614] Mesa-dri/aarch64: Segmentation fault in freedreno [msi-dri.so] while running on Lenovo x13s laptop
by bugzilla_noreply＠suse.com 11 Sep '23

11 Sep '23

https://bugzilla.suse.com/show_bug.cgi?id=1213614 https://bugzilla.suse.com/show_bug.cgi?id=1213614#c19 Stefan Dirsch <sndirsch(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|X.Org |Kernel QA Contact|gfx-bugs(a)suse.de |qa-bugs(a)suse.de Assignee|gfx-bugs(a)suse.de |kernel-bugs(a)opensuse.org --- Comment #19 from Stefan Dirsch <sndirsch(a)suse.com> --- Sounds great! So let's reassign to him. ;-) -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1215186] New: Consider applying this patch to Leap's kernel: bring back rep movsq for user access on CPUs without ERMS
by bugzilla_noreply＠suse.com 10 Sep '23

10 Sep '23

https://bugzilla.suse.com/show_bug.cgi?id=1215186 Bug ID: 1215186 Summary: Consider applying this patch to Leap's kernel: bring back rep movsq for user access on CPUs without ERMS Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: x86-64 OS: openSUSE Leap 15.5 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: kaykaykay123(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: Community User Blocker: --- While Intel CPUs since Ivy Bridge support 'Enhanced REP MOVSB' command (ERMS), AMD CPUs prior to Zen 3 lack it. Zen 3 info: https://en.wikipedia.org/wiki/Zen_3. AMD Ryzen 5800X has ERMS, but AMD EPYC Milan 7R13 has not - what is going on there?! Checking for availability of ERMS: cat /proc/cpuinfo | grep erms Patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… , picked up by kernel 6.6, ILL backported to stable kernels (https://lkml.org/lkml/2023/9/8/926). News: https://www.phoronix.com/news/Linux-6.6-Optimize-Lacking-ERMS Discussion: https://stackoverflow.com/questions/27804852/assembly-rep-movs-mechanism https://stackoverflow.com/questions/43343231/enhanced-rep-movsb-for-memcpy Hint: usage of SSE2 instructions may bring better results. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1214208] New: Bluetooth headphone audio inconsistent/connection unstable
by bugzilla_noreply＠suse.com 09 Sep '23

09 Sep '23

https://bugzilla.suse.com/show_bug.cgi?id=1214208 Bug ID: 1214208 Summary: Bluetooth headphone audio inconsistent/connection unstable Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: 64bit OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: slumberbottom(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Bug description: 1) Audio repeatedly cuts off. Sometimes, it works for ~10 seconds at a time. Mostly it works for 1-4 seconds, then cuts off for 1-2 seconds. Sometimes it cuts off more frequently for short periods. The effect is sometimes similar to being at the edge of the Bluetooth connection range. 2) Whatever manages volume control and devices (pulseaudio?) is also broken. 2a) Adding a device (headphones) does not automatically switch them to the default output. (Or not always, it just did for my wired ones, but I’m sure it didn’t before.) 2b) The disconnected Bluetooth headphones stay in the list of devices despite disconnecting them, even if Bluetooth is turned off entirely. Sometimes, they also become the default output device. 2c) Using the keyboard volume buttons to change volume sometimes defaults to the disconnected headphones. 2d) Sometimes, the volume buttons/keyboard volume knob will only change between two volume settings. (Currently, it’s 38% volume and 48% volume, nothing in-between.) Using the widget, it works as expected until the widget is closed again. This also effects other audio devices, not just Bluetooth. Peculiarity: After rebooting, audio works as expected for a while, then the issue gets increasingly worse. Once, I listened to whole ~15 min video before any issues reappeared. ____________________________________________________________________ Steps to reproduce: Connect Bluetooth headphones and try to listen to audio. (Air Pods and Google Pixel buds A series in my case). (Cable-bound headphones and internal speakers remain unaffected, excepting the volume control.) ____________________________________________________________________ System information Operating System: openSUSE Tumbleweed 20230810 [This bug appeared ~4 days ago, I think. I’ve since updated several times in hope that might fix it.] KDE Plasma Version: 5.27.7 KDE Frameworks Version: 5.108.0 Qt Version: 5.15.10 Kernel Version: 6.4.9-1-default (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 5625U with Radeon Graphics Memory: 13.5 GiB of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: LENOVO Product Name: 82SG System Version: IdeaPad 5 15ABA7 Bluetooth: Device-1: Realtek Bluetooth Radio driver: btusb type: USB Report: rfkill ID: hci0 rfk-id: 2 state: down bt-service: enabled,running rfk-block: hardware: no software: yes address: see --recommends pulseaudio packages all seem to be version 16.1-4.1 pipewire-pulseaudio is 0.3.77-1.1 ___________________ Attempted "fixes": Re-pairing devices, updating and rebooting. -- You are receiving this mail because: You are the assignee for the bug.

1 16

[Bug 1214445] Change: Increase vm.max_map_count value
by bugzilla_noreply＠suse.com 09 Sep '23

09 Sep '23

https://bugzilla.suse.com/show_bug.cgi?id=1214445 B <reiokorn(a)tutanota.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|increase vm.max_map_count |Change: Increase | |vm.max_map_count value -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1211459] [Leap 15.4][btrfs][snapper-cleanup], 'systemctl start snapper-cleanup' causes infinite message 'BTRFS warning (device vda2): qgroup rescan is already in progress' in syslog and causes 'yast2 lan' command hang
by bugzilla_noreply＠suse.com 08 Sep '23

08 Sep '23

https://bugzilla.suse.com/show_bug.cgi?id=1211459 https://bugzilla.suse.com/show_bug.cgi?id=1211459#c30 --- Comment #30 from Andrew Daugherity <adaugherity(a)tamu.edu> --- I may have spoken too soon -- I just did another 15.5 install, and removing the pre/post snapshots and rebooting did not fix the issue this time. Even running btrfs check from the rescue environment still thinks a qgroup rescan is in progress, which is crazy since the filesystem isn't even mounted! ==== ttyS0:rescue:~ # btrfs check /dev/sda3 Opening filesystem to check... Checking filesystem on /dev/sda3 UUID: f13af899-5d1d-4611-8d0c-ce42119b8f30 [1/7] checking root items [2/7] checking extents [3/7] checking free space cache [4/7] checking fs roots [5/7] checking only csums items (without verifying data) [6/7] checking root refs [7/7] checking quota groups Qgroup rescan is running, qgroups will not be printed. found 2354786304 bytes used, no error found total csum bytes: 2061704 total tree bytes: 62324736 total fs tree bytes: 55836672 total extent tree bytes: 3457024 btree space waste bytes: 10474331 file data blocks allocated: 2443530240 referenced 2437812224 ==== Mounting it appears to "complete" the qgroup rescan. After unmounting it and running btrfs-check again, errors are found: ==== ttyS0:rescue:~ # mount /dev/sda3 /mnt; dmesg|tail [ 38.857481] systemd[1]: Starting Rebuild Hardware Database... [ 38.858810] systemd[1]: Starting Load/Save Random Seed... [ 38.860095] systemd[1]: Starting Create System Users... [ 38.866850] systemd[1]: Started Journal Service. [ 38.985727] systemd-journald[2135]: Received client request to flush runtime journal. [ 41.709755] BTRFS: device fsid f13af899-5d1d-4611-8d0c-ce42119b8f30 devid 1 transid 76 /dev/sda3 scanned by (udev-worker) (2190) [ 680.775308] BTRFS info (device sda3): disk space caching is enabled [ 680.775313] BTRFS info (device sda3): has skinny extents [ 680.780807] BTRFS info (device sda3): enabling ssd optimizations [ 681.774359] BTRFS info (device sda3): qgroup scan completed (inconsistency flag cleared) ttyS0:rescue:~ # umount /mnt ttyS0:rescue:~ # btrfs check /dev/sda3 Opening filesystem to check... Checking filesystem on /dev/sda3 UUID: f13af899-5d1d-4611-8d0c-ce42119b8f30 [1/7] checking root items [2/7] checking extents [3/7] checking free space cache [4/7] checking fs roots [5/7] checking only csums items (without verifying data) [6/7] checking root refs [7/7] checking quota groups Counts for qgroup id: 0/267 are different our: referenced 2160812032 referenced compressed 2160812032 disk: referenced 2160812032 referenced compressed 2160812032 our: exclusive 20766720 exclusive compressed 20766720 disk: exclusive 20783104 exclusive compressed 20783104 diff: exclusive -16384 exclusive compressed -16384 Counts for qgroup id: 0/278 are different our: referenced 2141519872 referenced compressed 2141519872 disk: referenced 2141519872 referenced compressed 2141519872 our: exclusive 1474560 exclusive compressed 1474560 disk: exclusive 1490944 exclusive compressed 1490944 diff: exclusive -16384 exclusive compressed -16384 Counts for qgroup id: 1/0 are different our: referenced 2141519872 referenced compressed 2141519872 disk: referenced 1524371456 referenced compressed 1524371456 diff: referenced 617148416 referenced compressed 617148416 our: exclusive 1474560 exclusive compressed 1474560 disk: exclusive 3170304 exclusive compressed 3170304 diff: exclusive -1695744 exclusive compressed -1695744 found 2354786304 bytes used, error(s) found total csum bytes: 2061704 total tree bytes: 62324736 total fs tree bytes: 55836672 total extent tree bytes: 3457024 btree space waste bytes: 10474331 file data blocks allocated: 2443530240 ==== Comparing to the output of btrfs subvol list, it appears that 0/267 and 0/268 correspond to the remaining "single" snapshots 1 & 8 from my last comment. Even more strange, after rebooting back into the installed VM, it now appears to be as "fixed" as expected, i.e. 'snapper ls' works but logs "qgroup scan completed (inconsistency flag cleared)" once each time it's run; same thing for snapper-cleanup. And in case I was not clear before: when in the "bad" state where it logs that warning once per second, snapper-cleanup never finishes. In this "fixed but logs the warning once" state, it completes in a couple seconds. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.

1 0

[Bug 1211459] [Leap 15.4][btrfs][snapper-cleanup], 'systemctl start snapper-cleanup' causes infinite message 'BTRFS warning (device vda2): qgroup rescan is already in progress' in syslog and causes 'yast2 lan' command hang
by bugzilla_noreply＠suse.com 08 Sep '23

08 Sep '23

https://bugzilla.suse.com/show_bug.cgi?id=1211459 https://bugzilla.suse.com/show_bug.cgi?id=1211459#c29 Andrew Daugherity <adaugherity(a)tamu.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adaugherity(a)tamu.edu Status|NEW |CONFIRMED --- Comment #29 from Andrew Daugherity <adaugherity(a)tamu.edu> --- I hope this is appropriate to add to this bug -- if not, I can open a new one. Not sure if this satisfies the NEEDINFO, or were you looking for something else? I have found that 100% of my AutoYAST installations on 15.4 and 15.5 encounter this issue. (I also just did another 15.3 AY install for comparison, and it is not affected.) Machines which were installed with 15.3 or earlier and then upgraded have not appeared to hit it, so far. What happens is that once snapper-cleanup.timer fires 10 minutes after boot, the "qgroup rescan is already in progress" message gets logged once per second, e.g.: Sep 7 19:31:47 leap154 kernel: [ 423.891928][T13669] BTRFS warning (device sda3): qgroup rescan is already in progress Sep 7 19:31:48 leap154 kernel: [ 424.891992][T13669] BTRFS warning (device sda3): qgroup rescan is already in progress Sep 7 19:31:49 leap154 kernel: [ 425.892039][T13669] BTRFS warning (device sda3): qgroup rescan is already in progress This continues indefinitely (at least overnight), until I do 'systemctl stop snapper-cleanup'. When the system is in this state, 'snapper ls' hangs indefinitely unless I add --disable-used-space. (Hitting Ctrl-C successfully aborts snapper, but the message continues to be logged once per second until I 'systemctl stop snapperd', which was apparently spawned via DBus by 'snapper ls'.) Also, 'btrfs qgroup show /' reports WARNING: rescan is running, qgroup data may be incorrect, and 'btrfs qgroup show --sync /' does NOT wait but returns immediate results after printing said warning. btrfs quota rescan reports an operation in progress, which appears to never finish (and iostat is idle): leap154:~ # btrfs quota rescan -s / rescan operation running (current key 273178625) Running that without '-s' logs another "BTRFS warning (device sda3): qgroup rescan is already in progress" message. I see the same output from other debug steps in comments on this bug and boo#1206814 as they did: - /sys/fs/btrfs/<FSID>/exclusive_operation is "none" - cat /proc/(pid of [btrfs-qgroup-re])/task/*/stack shows that it's idle/stuck in rescuer_thread, e.g. [<0>] rescuer_thread+0x2de/0x360 [<0>] kthread+0x156/0x180 [<0>] ret_from_fork+0x22/0x30 I think this may be related to the pre/post snapshots created during installation (e.g. 2nd-stage autoyast installing sssd when configuring auth-client). This is the snapshot state immediately after installation: ==== leap154:~ # snapper ls --disable-used-space # | Type | Pre # | Date | User | Cleanup | Description | Userdata ---+--------+-------+---------------------------------+------+---------+-----------------------+-------------- 0 | single | | | root | | current | 1* | single | | Thu 07 Sep 2023 07:04:46 PM CDT | root | | first root filesystem | 2 | pre | | Thu 07 Sep 2023 07:09:43 PM CDT | root | number | zypp(ruby.ruby2.5) | important=no 3 | post | 2 | Thu 07 Sep 2023 07:09:45 PM CDT | root | number | | important=no 4 | pre | | Thu 07 Sep 2023 07:09:51 PM CDT | root | number | zypp(ruby.ruby2.5) | important=no 5 | post | 4 | Thu 07 Sep 2023 07:09:53 PM CDT | root | number | | important=no 6 | pre | | Thu 07 Sep 2023 07:09:56 PM CDT | root | number | zypp(ruby.ruby2.5) | important=no 7 | post | 6 | Thu 07 Sep 2023 07:10:06 PM CDT | root | number | | important=no 8 | single | | Thu 07 Sep 2023 07:10:51 PM CDT | root | number | after installation | important=yes ==== While I've had some VMs magically fix themselves after a number of reboots, the only way I've found to reliably fix this is to remove the pre/post snapshots AND reboot afterwards (until rebooting, the rescan operation is still running with the same key). E.g. for the above snapshot list, 'snapper rm 2-7'. After rebooting, it logs a message about clearing an inconsistency flag: Sep 8 13:26:39 leap154 kernel: [ 6.637822][ T362] BTRFS info (device sda3): qgroup scan completed (inconsistency flag cleared) This message is logged again (once) when snapper-cleanup starts, and also every time I run 'snapper ls', which now runs successfully at least: Sep 8 13:36:31 leap154 systemd-helper[13438]: running cleanup for 'root'. Sep 8 13:36:31 leap154 systemd-helper[13438]: running number cleanup for 'root'. Sep 8 13:36:31 leap154 kernel: [ 605.099983][ T362] BTRFS info (device sda3): qgroup scan completed (inconsistency flag cleared) Sep 8 13:36:31 leap154 systemd-helper[13438]: running timeline cleanup for 'root'. Sep 8 13:36:31 leap154 systemd-helper[13438]: running empty-pre-post cleanup for 'root'. ... Sep 8 16:08:02 leap154 dbus-daemon[619]: [system] Activating via systemd: service name='org.opensuse.Snapper' unit='snapperd.service' requested by ':1.37' (uid=0 pid=14085 comm="snapper ls ") Sep 8 16:08:03 leap154 dbus-daemon[619]: [system] Successfully activated service 'org.opensuse.Snapper' Sep 8 16:08:03 leap154 kernel: [ 9696.519376][T14021] BTRFS info (device sda3): qgroup scan completed (inconsistency flag cleared) Both 15.4 & 15.5 have snapper-0.8.16-150300.3.6.1.x86_64. Kernels are 5.14.21-150400.24.81-default and 5.14.21-150500.55.19-default, respectively. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.

1 0