August 2022 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1190764] New: [Build 20210920] btrfs: invalid qgroupid or subvolume path
by bugzilla_noreply＠suse.com 26 Oct '22

26 Oct '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1190764 Bug ID: 1190764 Summary: [Build 20210920] btrfs: invalid qgroupid or subvolume path Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/1929805/modules/btrf s_qgroups/steps/24 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: dimstar(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: openQA Blocker: Yes ## Observation openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-extra_tests_filesystem@64bit fails in [btrfs_qgroups](https://openqa.opensuse.org/tests/1929805/modules/btrfs_qgro… The openQA test code is this: assert_script_run "btrfs quota enable ."; # Create subvolumes, qgroups, assigns and limits # 2/1 # / \ # 1/1 1/2 # / \ / | \ # a b c d(k) assert_script_run "for c in {a..d}; do btrfs subvolume create \$c; done"; assert_script_run "for c in 1/1 1/2 2/1; do btrfs qgroup create \$c .; done"; assert_script_run "for c in a b; do btrfs qgroup assign \$c 1/1 .; done"; assert_script_run "for c in b c d; do btrfs qgroup assign \$c 1/2 .; done"; assert_script_run "for c in 1/1 1/2; do btrfs qgroup assign \$c 2/1 .; done"; And the last command here returns: ERROR: invalid qgroupid or subvolume path: a ERROR: invalid qgroupid or subvolume path: b ## Test suite description Maintainer: QE Core Filesystem related tests, for example snapper and btrfs features. ## Reproducible Fails since (at least) Build [20210920](https://openqa.opensuse.org/tests/1928938) ## Expected result Last good: [20210918](https://openqa.opensuse.org/tests/1927312) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensus… -- You are receiving this mail because: You are the assignee for the bug.

1 4

[Bug 1187566] New: Display connected to Thunderbolt 3 Docking Station is not detected on cold boot
by bugzilla_noreply＠suse.com 10 Oct '22

10 Oct '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1187566 Bug ID: 1187566 Summary: Display connected to Thunderbolt 3 Docking Station is not detected on cold boot Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: x86-64 OS: openSUSE Leap 15.3 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: eecdc3.opensuse(a)coders-haven.net QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I am using a HP Elitebook 1040 G4 notebook connected to a HP Thunderbolt 3 Docking Station, which in turn is connected to multiple USB devices and an external monitor via DisplayPort. Unfortunately, I am experiencing issues with this configuration as described below. I am using boltd from the hardware repository to authorize my Thunderbolt 3 Docking Station during startup. (Boot ACLs are not supported by my BIOS, as far as I can tell.) While devices connected to the docking station via USB will work afterwards, my external monitor, which is connected via DisplayPort, will not be detected automatically. Only when I manually reconnect the docking station after startup has completed, it will finally be detected (and awoken from standby). This leads me to believe that this issue is boot order related. (Previously, I was using openSUSE Leap 15.2 and a custom udev rule to authorize the docking station via sysfs and I did not experience this issue but the system would occasionally hang while booting instead. I have already tried the udev rule with openSUSE Leap 15.3 but this made the issue worse as the display was then only detected if I reconnected the external monitor itself.) Any help investigating this issue is appreciated as I do not have in-depth knowledge of the kernel or its Thunderbolt subsystem and cannot really make any progress towards a resolution on my own. -- You are receiving this mail because: You are the assignee for the bug.

1 8

[Bug 1200716] New: occasional "xHCI host controller not responding, assume dead' with Thunderbolt dock
by bugzilla_noreply＠suse.com 07 Oct '22

07 Oct '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1200716 Bug ID: 1200716 Summary: occasional "xHCI host controller not responding, assume dead' with Thunderbolt dock Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: pujos.michael(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I have a laptop with a TB2 dock connected via TB3 using the TB3->TB2 Apple adapter. It worked fine for a while but since a few kernels, the USB hub of the dock get (seemingly) randomly disconnected: [ 8524.631011] xhci_hcd 0000:09:00.0: xHCI host controller not responding, assume dead [ 8524.631039] xhci_hcd 0000:09:00.0: HC died; cleaning up [ 8524.631076] usb 3-4: 1:0: usb_set_interface failed (-110) [ 8524.631087] usb 3-4: Not enough bandwidth for altsetting 1 [ 8524.631093] usb 3-4: 1:1: usb_set_interface failed (-19) [ 8524.631101] usb 3-4: Not enough bandwidth for altsetting 0 [ 8524.631107] usb 3-4: 1:0: usb_set_interface failed (-19) [ 8524.631213] usb 3-4: Not enough bandwidth for altsetting 0 [ 8524.631220] usb 3-4: 1:0: usb_set_interface failed (-19) [ 8524.631226] usb 3-4: Not enough bandwidth for altsetting 1 [ 8524.631231] usb 3-4: 1:1: usb_set_interface failed (-19) [ 8524.631238] usb 3-4: Not enough bandwidth for altsetting 0 [ 8524.631243] usb 3-4: 1:0: usb_set_interface failed (-19) [ 8524.631294] usb 3-4: Not enough bandwidth for altsetting 0 [ 8524.631300] usb 3-4: 1:0: usb_set_interface failed (-19) [ 8524.631306] usb 3-4: Not enough bandwidth for altsetting 1 [ 8524.631311] usb 3-4: 1:1: usb_set_interface failed (-19) [ 8524.631317] usb 3-4: Not enough bandwidth for altsetting 0 [ 8524.631323] usb 3-4: 1:0: usb_set_interface failed (-19) [ 8524.631358] usb 3-4: Not enough bandwidth for altsetting 0 [ 8524.631364] usb 3-4: 1:0: usb_set_interface failed (-19) [ 8524.631370] usb 3-4: Not enough bandwidth for altsetting 1 [ 8524.631376] usb 3-4: 1:1: usb_set_interface failed (-19) [ 8524.631382] usb 3-4: Not enough bandwidth for altsetting 0 [ 8524.631387] usb 3-4: 1:0: usb_set_interface failed (-19) [ 8524.631430] usb 3-4: Not enough bandwidth for altsetting 0 [ 8524.631436] usb 3-4: 1:0: usb_set_interface failed (-19) [ 8524.631442] usb 3-4: Not enough bandwidth for altsetting 1 [ 8524.631447] usb 3-4: 1:1: usb_set_interface failed (-19) [ 8524.631453] usb 3-4: Not enough bandwidth for altsetting 0 [ 8524.631458] usb 3-4: 1:0: usb_set_interface failed (-19) [ 8524.631639] usb 3-4: USB disconnect, device number 2 The disconnections does not happen very frequently, but when it happens it is annoying as I usually have my keyboard connected to it and use its USB audio output. It also has a DisportPort port to which my external monitor is attached, but it is not affected. -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1202825] New: Haswell Laptop Completely Freezes After Waking up from Suspend
by bugzilla_noreply＠suse.com 03 Oct '22

03 Oct '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1202825 Bug ID: 1202825 Summary: Haswell Laptop Completely Freezes After Waking up from Suspend Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: ege.oz(a)tutanota.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 861132 --> http://bugzilla.opensuse.org/attachment.cgi?id=861132&action=edit Output of "inxi -F" Hello, Haswell laptop with the latest TW kernel completely freezes after waking from suspend. Downgrading to 5.14.21 from Leap 15.4 fixes this issue. I am unable to debug this is issue, as the previous boot's kernel log (journalct -b -1) abruptly ends without any indication regarding this issue. In fact, after attempting to wake up the system, even keyboard status LEDs are unresponsive. I have also attempted to SSH into the laptop after waking it up without any success. Thank you, Kind regards. -- You are receiving this mail because: You are the assignee for the bug.

1 11

[Bug 1180985] New: Kernel 5.10 breaks ethernet connection with lenovo x390
by bugzilla_noreply＠suse.com 30 Sep '22

30 Sep '22

https://bugzilla.suse.com/show_bug.cgi?id=1180985 Bug ID: 1180985 Summary: Kernel 5.10 breaks ethernet connection with lenovo x390 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: fcastelli(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I have a lenovo x390 laptop with an intel CPU. I've been running Tumbleweed on it since a while because I needed a newer kernel compared to Leap to get my network card to work. Everything worked fine since I upgraded to 5.10.x. The upgrade caused the ethernet card to became unreliable (like it happened with old Leap 15.1 kernel). The network card works fine for some time, then it suddenly loses the connection. I can see Gnome NetworkManager trying to setup the card, but the process never ends. The x390 doesn't have a physical eth port, it has a proprietary adapter that provides that to the laptop. This adapter is plagued by the issue. The same issue happens when I connect the computer to its USB-C docking station (an official one provided by Lenovo). The docking station provides an eth port which is affected by this issue. The 5.9.14-1.2 and the 5.9.12-1.1 kernels are the last kernels I tested on my computer that proved to be fine. I'll try to collect more detailed logs from syslog, but right now it's a bit hard for me because I cannot reproduce the issue. I just have to wait for it to happen... -- You are receiving this mail because: You are the assignee for the bug.

1 17

[Bug 1202727] New: Upstream kernel commit 30de14b1884ba makes s390 to stop working on qemu
by bugzilla_noreply＠suse.com 16 Sep '22

16 Sep '22

https://bugzilla.suse.com/show_bug.cgi?id=1202727 Bug ID: 1202727 Summary: Upstream kernel commit 30de14b1884ba makes s390 to stop working on qemu Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: S/390-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: mpdesouza(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- If the following commit is reverted commit 30de14b1884ba609fc1acfba5b40309e3a6ccefe Author: Sven Schnelle <svens(a)linux.ibm.com> Date: Fri Apr 8 14:51:26 2022 +0200 s390: current_stack_pointer shouldn't be a function qemu can boot a s390 correct. The commit was added in 5.18-rc3. With this commit reverted qemu-kvm can boot v6.0-rc2 without any problem. I found this bug while trying to debug a livepatch issue: https://github.com/SUSE/qa_test_klp/issues/17 I enabled dyndebug while runnig the livepatch testing, but it didn't show anything useful for the bug: [ 863.108916] livepatch: enabling patch 'klp_tc_10_livepatch' [ 863.112892] livepatch: 'klp_tc_10_livepatch': starting patching transition [ 864.310918] livepatch: 'klp_tc_10_livepatch': patching complete [ 864.972595] livepatch: 'klp_tc_10_livepatch': starting unpatching transition [ 866.395047] livepatch: 'klp_tc_10_livepatch': unpatching complete [ 1003.993309] livepatch: enabling patch 'klp_tc_10_livepatch' [ 1003.993320] livepatch: 'klp_tc_10_livepatch': initializing patching transition [ 1003.997171] livepatch: 'klp_tc_10_livepatch': starting patching transition [ 1003.997396] livepatch: klp_try_switch_task: swapper/1:0 is running [ 1003.997435] livepatch: klp_try_switch_task: swapper/2:0 is running [ 1003.997467] livepatch: klp_try_switch_task: swapper/3:0 is running [ 1003.997485] livepatch: klp_try_switch_task: swapper/4:0 is running [ 1003.997504] livepatch: klp_try_switch_task: swapper/5:0 is running [ 1003.997509] livepatch: klp_try_switch_task: swapper/6:0 is running [ 1003.997542] livepatch: klp_try_switch_task: swapper/7:0 is running [ 1003.997575] livepatch: klp_try_switch_task: swapper/8:0 is running [ 1003.997610] livepatch: klp_try_switch_task: swapper/9:0 is running [ 1005.430335] livepatch: 'klp_tc_10_livepatch': completing patching transition [ 1005.430843] livepatch: 'klp_tc_10_livepatch': patching complete [ 1006.878375] livepatch: 'klp_tc_10_livepatch': initializing unpatching transition [ 1006.878421] livepatch: 'klp_tc_10_livepatch': starting unpatching transition [ 1006.878644] livepatch: klp_try_switch_task: swapper/1:0 is running [ 1006.878664] livepatch: klp_try_switch_task: swapper/2:0 is running [ 1006.878693] livepatch: klp_try_switch_task: swapper/3:0 is running [ 1006.878722] livepatch: klp_try_switch_task: swapper/4:0 is running [ 1006.878748] livepatch: klp_try_switch_task: swapper/5:0 is running [ 1006.878780] livepatch: klp_try_switch_task: swapper/6:0 is running [ 1006.878811] livepatch: klp_try_switch_task: swapper/7:0 is running [ 1006.878830] livepatch: klp_try_switch_task: swapper/8:0 is running [ 1006.878853] livepatch: klp_try_switch_task: swapper/9:0 is running [ 1008.390362] livepatch: 'klp_tc_10_livepatch': completing unpatching transition [ 1008.394954] livepatch: 'klp_tc_10_livepatch': unpatching complete I believe that maybe the two issues can be linked, due to the nature of the patch, which can have some impacts on ftrace. Any advice would be welcome. Thanks! -- You are receiving this mail because: You are the assignee for the bug.

1 10

[Bug 1202734] New: amdgpu crashes when switching display
by bugzilla_noreply＠suse.com 14 Sep '22

14 Sep '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1202734 Bug ID: 1202734 Summary: amdgpu crashes when switching display Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Critical Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: karl.mistelberger(a)nefkom.net QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The crash occurs after resuming from suspend to RAM. In the KDE session CTRL+ALT+F1 will freeze the display and crash graphics. Issue occurred first with kernel version 5.18.15-1-default: Aug 09 09:15:00 kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out! Aug 09 09:15:00 kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=4194879, emitted seq=4194882 Aug 09 09:15:00 kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process Xorg.bin pid 1036 thread Xorg.bin:cs0 pid 1117 Aug 09 09:15:01 kernel: amdgpu: cp is busy, skip halt cp Aug 09 09:15:01 kernel: amdgpu: rlc is busy, skip halt rlc Aug 09 09:15:02 kernel: [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize parser -125! Aug 09 09:15:02 kernel: [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize parser -125! ... Aug 09 09:15:34 kernel: [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize parser -125! Aug 09 09:15:44 kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=4194884, emitted seq=4194885 Aug 09 09:15:44 kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process firefox pid 29507 thread firefox:cs0 pid 29585 Aug 09 09:15:44 kernel: amdgpu: cp is busy, skip halt cp Aug 09 09:15:45 kernel: amdgpu: rlc is busy, skip halt rlc Aug 09 09:15:59 kernel: [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize parser -125! -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1202534] New: After 5.19 upgrade, system does not shutdown to reboot complaining about blkdev_get_no_open
by bugzilla_noreply＠suse.com 08 Sep '22

08 Sep '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1202534 Bug ID: 1202534 Summary: After 5.19 upgrade, system does not shutdown to reboot complaining about blkdev_get_no_open Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Linux Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: David.Boyd49(a)twc.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- After 5.19 kernel upgrade, system does not shutdown to reboot Console is flooded with two messages: blkdev_get_no_open xxx callbacks suppressed and block device autoloading is deprecated and will be removed This message is repeated a dozen or more times. This sequence repeats forever (actually, for at least twenty minutes ... I hit reset). Problem was not detected through the 5.18 series of kernels -- You are receiving this mail because: You are the assignee for the bug.

1 13

[Bug 1198972] New: btrfs send slow
by bugzilla_noreply＠suse.com 07 Sep '22

07 Sep '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1198972 Bug ID: 1198972 Summary: btrfs send slow Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: x86-64 OS: openSUSE Leap 15.3 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: jon.brightwell(a)zpg.co.uk QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- We have a btrfs send that starts fast (25MiBs) but quickly crawls (100KiBs~). example command: /sbin/btrfs send -v "/sqldata/central/.snapshots/112/snapshot" | pv -btraT -B50m | ssh backup3.repl.x.net sudo btrfs receive "/backup/dbshard1a.prod.x.net/central/112" At subvol /sqldata/central/.snapshots/112/snapshot At subvol snapshot 777MiB {----} 0:02:55 [ 130KiB/s] [4.44MiB/s] It slows down after 400MiB. I added a buffer size to pv check to see if it was network but the buffer never fills. htop doesn't show any kernel threads struggling and dstat and iostat don't show much. It's a live DB server but there's plenty of IO capacity and we have 5 identical servers that cap out the network. # iostat -x 5 Linux 5.3.18-150300.59.54-default (dbshard1a.prod.x.net) 04/28/22 _x86_64_ (48 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 2.22 0.00 1.27 0.09 0.00 96.43 Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util nvme3n1 58.24 441.63 791.34 8244.19 5.67 51.31 8.88 10.41 0.18 0.10 0.06 13.59 18.67 0.55 27.45 nvme0n1 86.05 441.56 1379.26 8244.25 5.18 51.38 5.67 10.42 0.14 0.10 0.06 16.03 18.67 0.53 28.00 nvme1n1 58.27 441.53 791.50 8245.03 5.67 51.32 8.87 10.41 0.18 0.10 0.06 13.58 18.67 0.55 27.40 nvme2n1 86.08 441.46 1379.37 8244.97 5.18 51.38 5.67 10.43 0.14 0.10 0.06 16.02 18.68 0.53 28.04 sda 11.45 14.98 712.51 79.42 0.45 0.08 3.79 0.52 4.37 0.15 0.05 62.20 5.30 1.07 2.84 sdb 11.30 14.98 699.35 79.42 0.44 0.08 3.72 0.52 4.44 0.15 0.05 61.90 5.30 1.08 2.83 avg-cpu: %user %nice %system %iowait %steal %idle 3.85 0.00 3.40 0.12 0.00 92.63 Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util nvme3n1 88.80 867.80 1016.00 11651.20 0.00 68.00 0.00 7.27 0.10 0.08 0.07 11.44 13.43 0.51 48.56 nvme0n1 66.00 867.40 728.80 11651.20 0.00 68.40 0.00 7.31 0.10 0.08 0.07 11.04 13.43 0.52 48.88 nvme1n1 93.00 863.00 1048.00 11732.80 0.00 72.00 0.00 7.70 0.10 0.08 0.08 11.27 13.60 0.51 48.64 nvme2n1 65.20 862.80 768.80 11732.80 0.00 72.20 0.00 7.72 0.18 0.08 0.08 11.79 13.60 0.53 48.72 sda 41.00 72.20 3498.40 445.10 0.00 0.00 0.00 0.00 0.85 0.11 0.05 85.33 6.16 1.28 14.48 sdb 36.60 72.20 2855.20 445.10 0.00 0.00 0.00 0.00 0.79 0.10 0.04 78.01 6.16 1.31 14.24 avg-cpu: %user %nice %system %iowait %steal %idle 4.43 0.00 3.30 0.12 0.00 92.15 Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util nvme3n1 70.80 761.20 769.60 10829.60 0.00 63.40 0.00 7.69 0.10 0.09 0.08 10.87 14.23 0.50 41.92 nvme0n1 92.20 761.00 869.60 10829.60 0.00 63.60 0.00 7.71 0.09 0.09 0.08 9.43 14.23 0.52 44.64 nvme1n1 68.80 751.20 767.20 10528.80 0.00 61.80 0.00 7.60 0.10 0.13 0.10 11.15 14.02 0.51 42.08 nvme2n1 91.00 751.00 931.20 10528.80 0.00 62.00 0.00 7.63 0.09 0.13 0.11 10.23 14.02 0.53 44.56 sda 14.00 46.60 1089.60 297.40 0.00 0.20 0.00 0.43 0.69 0.11 0.02 77.83 6.38 1.48 8.96 sdb 10.00 46.60 552.80 297.40 0.00 0.20 0.00 0.43 0.66 0.11 0.01 55.28 6.38 1.55 8.80 # dstat 5 You did not select any stats, using -cdngy by default. --total-cpu-usage-- -dsk/total- -net/total- ---paging-- ---system-- usr sys idl wai stl| read writ| recv send| in out | int csw 2 1 96 0 0|5753k 32M| 0 0 | 86B 376B| 17k 14k 4 3 92 0 0|8436k 95M|2705k 3862k| 0 0 | 39k 29k 5 3 93 0 0|2510k 34M|2119k 3624k| 819B 0 | 30k 22k 3 3 94 0 0|2274k 39M|3914k 4882k| 0 0 | 37k 27k 3 3 94 0 0|1385k 34M|2466k 3345k| 0 0 | 32k 22k # ps -aux | grep send root 7557 94.8 0.0 24572 172 pts/1 Rl+ 11:40 8:06 /sbin/btrfs send -v /sqldata/central/.snapshots/112/snapshot does seem to be maxing out one core. # ps -auxf | grep "btrfs" root 1679 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-worker] root 1680 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-worker-hi] root 1681 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-delalloc] root 1682 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-flush_del] root 1683 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-cache] root 1684 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-submit] root 1685 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-fixup] root 1686 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-endio] root 1687 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-endio-met] root 1688 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-endio-met] root 1689 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-endio-rai] root 1690 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-endio-rep] root 1691 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-rmw] root 1692 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-endio-wri] root 1693 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-freespace] root 1694 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-delayed-m] root 1695 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-readahead] root 1696 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-qgroup-re] root 1716 0.0 0.0 0 0 ? S Mar19 0:01 \_ [btrfs-cleaner] root 1717 1.5 0.0 0 0 ? S Mar19 872:22 \_ [btrfs-transacti] root 22056 0.8 0.0 0 0 ? I 05:23 3:28 \_ [kworker/u96:10-btrfs-endio-write] root 28815 0.0 0.0 0 0 ? I< 06:41 0:00 \_ [kworker/u97:2-btrfs-worker-high] root 43020 1.5 0.0 0 0 ? I 09:22 2:22 \_ [kworker/u96:12-btrfs-endio-meta] root 44734 1.5 0.0 0 0 ? I 09:41 2:05 \_ [kworker/u96:2-btrfs-endio-meta] root 45641 0.0 0.0 0 0 ? I< 09:51 0:00 \_ [kworker/u97:6-btrfs-worker-high] root 578 0.0 0.0 0 0 ? I< 10:34 0:00 \_ [kworker/u97:1-btrfs-worker-high] root 3129 0.0 0.0 0 0 ? I< 10:59 0:00 \_ [kworker/u97:3-btrfs-worker-high] root 4401 4.2 0.0 0 0 ? I 11:06 1:56 \_ [kworker/u96:8-btrfs-endio] root 5660 0.0 0.0 0 0 ? I< 11:20 0:00 \_ [kworker/u97:4-btrfs-worker-high] root 6567 7.8 0.0 0 0 ? I 11:30 1:45 \_ [kworker/u96:14-btrfs-endio-meta] root 6570 7.6 0.0 0 0 ? I 11:30 1:42 \_ [kworker/u96:20-btrfs-endio-meta] root 6574 4.6 0.0 0 0 ? I 11:30 1:01 \_ [kworker/u96:24-btrfs-endio-meta] root 6584 8.2 0.0 0 0 ? I 11:30 1:49 \_ [kworker/u96:25-btrfs-endio-write] root 6679 0.0 0.0 0 0 ? I< 11:31 0:00 \_ [kworker/u97:5-btrfs-worker-high] root 6681 7.4 0.0 0 0 ? I 11:31 1:34 \_ [kworker/u96:27-btrfs-endio-meta] root 7499 1.7 0.0 0 0 ? I 11:40 0:13 \_ [kworker/u96:1-btrfs-endio-meta] root 7500 2.7 0.0 0 0 ? I 11:40 0:21 \_ [kworker/u96:3-btrfs-endio] root 8460 0.1 0.0 0 0 ? I 11:50 0:00 \_ [kworker/u96:4-btrfs-endio-meta] #iotop PID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND 7557 be/4 root 190.55 K/s 0.00 B/s 0.00 % 0.13 % btrfs send -v /sqldata/central/.snapshots/112/snapshot 6570 be/4 root 9.30 K/s 18.59 K/s 0.00 % 0.01 % [kworker/u96:20-bond0] 12922 be/4 mysql 1692.48 K/s 16.67 M/s 0.00 % 0.01 % mariadbd --defaults-file=/etc/my.appdata.cnf 7499 be/4 root 6.20 K/s 9.30 K/s 0.00 % 0.01 % [kworker/u96:1-btrfs-endio-write] 22056 be/4 root 3.10 K/s 15.49 K/s 0.00 % 0.00 % [kworker/u96:10-bond0] 7500 be/4 root 3.10 K/s 3.10 K/s 0.00 % 0.00 % [kworker/u96:3-btrfs-endio-write] 12761 be/4 mysql 24.79 K/s 1332.29 K/s 0.00 % 0.00 % mariadbd --defaults-file=/etc/my.central.cnf 6359 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/12:1-events] 9123 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/19:0-events] 3015 be/4 dd-agent 0.00 B/s 3.87 K/s 0.00 % 0.00 % agent run -p /opt/datadog-agent/run/agent.pid 6567 be/4 root 0.00 B/s 12.39 K/s 0.00 % 0.00 % [kworker/u96:14-btrfs-endio-write] 6584 be/4 root 0.00 B/s 9.30 K/s 0.00 % 0.00 % [kworker/u96:25-btrfs-endio-write] What diagnostics are recommended to work out why this one server is a slug and possibly bugged? :) scrub is fine but can't take server offline to do a check. No errors in dmesg or journal. -- You are receiving this mail because: You are the assignee for the bug.

1 4

[Bug 1190340] New: armv7hl 5.14 kernel build fails for Leap 15.4
by bugzilla_noreply＠suse.com 06 Sep '22

06 Sep '22

https://bugzilla.suse.com/show_bug.cgi?id=1190340 Bug ID: 1190340 Summary: armv7hl 5.14 kernel build fails for Leap 15.4 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: tiwai(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Now we start building the armv7hl kernel for Leap 15.4, and it fails as: [ 9793s] GEN modules.builtin [ 9793s] LD .tmp_vmlinux.btf [ 9827s] BTF .btf.vmlinux.bin.o [ 9884s] [4957384] STRUCT thread_info's field 'vfpstate' offset=2048 bit_size=0 type=4957356 Error emitting field [ 9884s] Encountered error while encoding BTF. .... [ 9994s] FAILED: load BTF from vmlinux: No such file or directory [ 9994s] make[1]: *** [/home/abuild/rpmbuild/BUILD/kernel-default-5.14.2/linux-5.14/Makefile:1200: vmlinux] Error 255 My initial attempt worked because BTF wasn't enabled due to the old tools. OTOH, the same 5.14 build is OK with stable branch, so there is still some missing piece, supposedly. -- You are receiving this mail because: You are the assignee for the bug.

1 9