January 2022 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1193374] New: [kernel 5.15.3][zpci] not initialized/supported: => lspci -v / lspci -k lists no PCI devices
by bugzilla_noreply＠suse.com 29 Apr '22

29 Apr '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1193374 Bug ID: 1193374 Summary: [kernel 5.15.3][zpci] not initialized/supported: => lspci -v / lspci -k lists no PCI devices Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: S/390-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: holger.rauch(a)posteo.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4743.0 Safari/537.36 Build Identifier: a bug search for "zpci" yielded no results, so I decided to file this as a new bug. Regarding the actual details: please see "steps to reproduce" below (to me it *seems* the missing PCI devices are a secondary error due to the missing zpci initialization, which in turn is due to the missing CPU facilities). Please also note that I haven't tried any other kernel releases besides the default kernel shipped with OpenSUSE Tumbleweed (which, at the time of this writing is 5.15.3) Interesting questions in this regard: 1. Are other CPU facilities missing, too (besides the two mentioned ones "69" and "71")? 2. Is there something like a reference list of all CPU facilities that "normally" are/should be supported? TIA for any additional help/info. Reproducible: Always Steps to Reproduce: 1. lspci -v / lspci -k => no devices listed (but interestingly, the exit status of both commands is zero) 2. sudo dmesg | grep zpci => zpci: PCI is not supported because CPU facilities 69 or 71 are not available 3. grep facilities /proc/cpuinfo => facilities : 0 1 2 3 4 6 7 8 9 10 12 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 30 31 32 33 34 35 36 37 38 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 57 58 59 60 61 73 74 75 76 77 80 81 82 128 129 130 131 133 134 135 146 147 148 150 151 152 155 156 168 => both CPU facilities indeed seem to be missing (note that the next facility number after "61" is "73") Actual Results: no PCI devices Expected Results: The "lspci" command should list some PCI devices uname -v => #1 SMP Fri Nov 19 08:35:39 UTC 2021 (404f576) The machine I tested this on is part of the LinuxONE Community Cloud. -- You are receiving this mail because: You are the assignee for the bug.

1 17

[Bug 1194943] New: cert related kernel build breakages in 5.17 merge window
by bugzilla_noreply＠suse.com 26 Apr '22

26 Apr '22

https://bugzilla.suse.com/show_bug.cgi?id=1194943 Bug ID: 1194943 Summary: cert related kernel build breakages in 5.17 merge window 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: mkubecek(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The upcoming 5.17-rc1 breaks build in two different ways: 1. When building locally with "osc build" (i.e. signing key is not provided), the build fails with error like > certs/extract-cert certs/signing_key.x509 > Usage: extract-cert <source> <dest> > make[2]: *** [/home/mike/work/git/kernel-upstream/certs/Makefile:78: certs/signing_key.x509] Error 2 > make[1]: *** [/home/mike/work/git/kernel-upstream/Makefile:1831: certs] Error 2 > make[1]: Leaving directory '/srv/ram/kobj' > make: *** [Makefile:219: __sub-make] Error 2 After mainline commit b8c96a6b466c ("certs: simplify $(srctree)/ handling and remove config_filename macro"), make executes extract-cert with only one argument due to an unquoted empty string. (Easier way to reproduce this is to run sequence-patch.sh, change CONFIG_MODULE_SIG_KEY to an empty string like our kernel-*.spec do and run "make all" or "make certs"). As the trick with empty CONFIG_MODULE_SIG_KEY (used since bug 1187167) is recommended by (upstream) Documentation/kbuild/reproducible-builds.rst, I also reported this to upstream in https://lore.kernel.org/all/20220120094606.2skuyb26yjlnu66q@lion.mk-sys.cz/ 2. When building in OBS, builds after mainline commit e06a61a89ccd ("certs: use if_changed to re-generate the key when the key type is changed") fail in a different way: > [ 42s] make[1]: *** Deleting file 'certs/signing_key.pem' > [ 42s] GENKEY certs/signing_key.pem > [ 42s] Generating a RSA private key > [ 42s] ..........................................................+++++ > [ 42s] ..................+++++ > [ 42s] writing new private key to 'certs/signing_key.pem' > [ 42s] ----- > [ 42s] unable to find 'distinguished_name' in config > [ 42s] problems making Certificate Request > [ 42s] 140680883695552:error:0E06D06C:configuration file routines:NCONF_get_string:no value:crypto/conf/conf_lib.c:273:group=req name=distinguished_name > [ 42s] make[1]: *** [../certs/Makefile:57: certs/signing_key.pem] Error 1 > [ 42s] make: *** [../Makefile:1845: certs] Error 2 > [ 42s] make: *** Waiting for unfinished jobs.... IIUC the problem here is that after rewriting the rule for signing_key.pem to if_changed based version, the rule is always invoked first time as there is no "previous command line" so that the trick introduced in kernel-source commit 6eb6cd2106c2 for bug 983634 (providing our key/certificate under default name and touching certs/x509.genkey to prevent regenerating it no longer works. (The empty certs/x509.genkey is empty created by touch is not valid for openssl.) This can be observed in home:mkubecek:rc0 OBS project at the moment. It can be also reproduced locally with "osc build" by adding a key/certificate file as _projectcert.crt to the directory generated by tar-up.sh (e.g a randomly generated one from a simple "make all" build of expanded tree). I'm not sure if I understand the reason why we do this correctly. Does it still make sense to enforce using the default key/certificate file path when a key/certificate is supplied if we replace CONFIG_MODULE_SIG_KEY with empty string for builds where a key/certificate is not supplied? -- You are receiving this mail because: You are the assignee for the bug.

1 15

[Bug 1193601] New: Kernel log jumps to the middle of the screen
by bugzilla_noreply＠suse.com 17 Apr '22

17 Apr '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1193601 Bug ID: 1193601 Summary: Kernel log jumps to the middle of the screen Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: x86-64 OS: openSUSE Leap 15.4 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: opendreas(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 854451 --> http://bugzilla.opensuse.org/attachment.cgi?id=854451&action=edit Kernel log Kernel log jumps at boot to the middle of the screen. This issue is not present on Leap 15.3, but it is on Tumbleweed. -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1189791] New: btrfs filesystem corruptions with HyperPAV
by bugzilla_noreply＠suse.com 06 Apr '22

06 Apr '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1189791 Bug ID: 1189791 Summary: btrfs filesystem corruptions with HyperPAV 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: azouhr(a)opensuse.org QA Contact: qa-bugs(a)suse.de CC: ada.lovelace(a)gmx.de Found By: --- Blocker: --- For a proof of concept, I created a machine with 22 3390-54 Disks attached to a single btrfs, cylinder 0 excluded as minidisks. This happened in certain junks of disks (at least 4 at a time). After adding devices, I always did a rebalance of the btrfs. When I added disk 15-18, I also enabled hyperpav (without cylinder 0 on the base devices) as available as feature for z/VM 7.2 (feature also has been added to z/VM). The definition looks like this in the directory: COMMAND DEFINE HYPERPAVALIAS 01C0 FOR BASE 0100 I also added alias devices at addresses 01C1-01C7. However, later on when copying data from that disk, I found quite a number of corruptions within btrfs. After a while the server even crashed, and is now running without hyperpav. Corruptions that already happened are obviously still there, but besides that, the system works without the hangs I experienced before. By chance (don't think that would be the issue), the first disk with corruptions is the 16th disk in the system (including the system disk). And while thinking about this, the disk with number 100 has not been enabled on the system, although all disks are defined to the same control unit. HyperPAV has been used during rebalance of the last 8 disks because dasdstat displayed workload on the PAV device. # btrfs device stats /srv | grep corruption_errs [/dev/dasdb1].corruption_errs 0 [/dev/dasdc1].corruption_errs 0 [/dev/dasdd1].corruption_errs 0 [/dev/dasde1].corruption_errs 0 [/dev/dasdk1].corruption_errs 0 [/dev/dasdj1].corruption_errs 0 [/dev/dasdh1].corruption_errs 0 [/dev/dasdm1].corruption_errs 0 [/dev/dasdf1].corruption_errs 0 [/dev/dasdg1].corruption_errs 0 [/dev/dasdl1].corruption_errs 0 [/dev/dasdi1].corruption_errs 0 [/dev/dasdn1].corruption_errs 0 [/dev/dasdo1].corruption_errs 0 [/dev/dasdp1].corruption_errs 331 [/dev/dasdq1].corruption_errs 303 [/dev/dasds1].corruption_errs 302 [/dev/dasdv1].corruption_errs 399 [/dev/dasdr1].corruption_errs 356 [/dev/dasdt1].corruption_errs 206 [/dev/dasdw1].corruption_errs 279 [/dev/dasdu1].corruption_errs 218 # dmesg | tail [ 6616.004750] BTRFS warning (device dasdb1): csum failed root 5 ino 40234 off 1818624 csum 0x8941f998 expected csum 0x99cae683 mirror 1 [ 6616.004755] BTRFS error (device dasdb1): bdev /dev/dasdv1 errs: wr 0, rd 0, flush 0, corrupt 401, gen 0 [ 6616.005008] BTRFS warning (device dasdb1): csum failed root 5 ino 40234 off 3637248 csum 0x8941f998 expected csum 0xe55a18c7 mirror 1 [ 6616.005013] BTRFS error (device dasdb1): bdev /dev/dasdv1 errs: wr 0, rd 0, flush 0, corrupt 402, gen 0 [ 6616.005238] BTRFS warning (device dasdb1): csum failed root 5 ino 40234 off 1818624 csum 0x8941f998 expected csum 0x99cae683 mirror 1 [ 6616.005244] BTRFS error (device dasdb1): bdev /dev/dasdv1 errs: wr 0, rd 0, flush 0, corrupt 403, gen 0 [ 6616.005513] BTRFS warning (device dasdb1): csum failed root 5 ino 40234 off 1818624 csum 0x8941f998 expected csum 0x99cae683 mirror 1 [ 6616.005565] BTRFS error (device dasdb1): bdev /dev/dasdv1 errs: wr 0, rd 0, flush 0, corrupt 404, gen 0 [ 6616.882699] BTRFS warning (device dasdb1): csum failed root 5 ino 40224 off 10055680 csum 0x8941f998 expected csum 0x26222530 mirror 1 [ 6616.882715] BTRFS error (device dasdb1): bdev /dev/dasdu1 errs: wr 0, rd 0, flush 0, corrupt 249, gen 0 # uname -a Linux zlxusr1020 5.12.12-1-default #1 SMP Fri Jun 18 11:07:46 UTC 2021 (0e46a2c) s390x s390x s390x GNU/Linux -- You are receiving this mail because: You are the assignee for the bug.

1 13

[Bug 1184767] New: Several firmwares missing when installing MicroOS
by bugzilla_noreply＠suse.com 16 Mar '22

16 Mar '22

https://bugzilla.suse.com/show_bug.cgi?id=1184767 Bug ID: 1184767 Summary: Several firmwares missing when installing MicroOS 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: dfaggioli(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- After finishing installing MicroOS on my laptop, I have this in dmesg: dario@Palanthas-eth:~> dmesg |grep firmware [ 0.073533] Spectre V2 : Enabling Restricted Speculation for firmware calls [ 2.964996] i915 0000:00:02.0: Direct firmware load for i915/kbl_dmc_ver1_04.bin failed with error -2 [ 2.964998] i915 0000:00:02.0: [drm] Failed to load DMC firmware i915/kbl_dmc_ver1_04.bin. Disabling runtime power management. [ 2.964999] i915 0000:00:02.0: [drm] DMC firmware homepage: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git… [ 66.877346] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [ 66.928640] r8152 4-1.4:1.0: Direct firmware load for rtl_nic/rtl8153a-3.fw failed with error -2 [ 66.928646] r8152 4-1.4:1.0: unable to load firmware patch rtl_nic/rtl8153a-3.fw (-2) [ 67.153449] bluetooth hci0: Direct firmware load for qca/rampatch_usb_00000302.bin failed with error -2 [ 67.906512] ath10k_pci 0000:3a:00.0: Failed to find firmware-N.bin (N between 2 and 6) from ath10k/QCA6174/hw3.0: -2 [ 67.906552] ath10k_pci 0000:3a:00.0: could not fetch firmware files (-2) And WiFi and Bluetooth are not working. All the firmware related messages go away if I install the following packages: - kernel-firmware-iwlwifi - kernel-firmware-realtek - kernel-firmware-i915 - kernel-firmware-bluetooth - kernel-firmware-ath10k The message about regulatory.db goes away if I install the crda package This is related to bug 1184403 with the only difference that there the missing firmware is in kernel-firmware-iwlwifi. Also, it looks like this shouldn't happen, according to bug 1174521, as it's marked as fixed, but the problem seems to still be there -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 1180316] New: [Build 20201222] openQA test fails in kdump_and_crash
by bugzilla_noreply＠suse.com 15 Mar '22

15 Mar '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1180316 Bug ID: 1180316 Summary: [Build 20201222] openQA test fails in kdump_and_crash Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/1523048/modules/kdum p_and_crash/steps/58 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-JeOS-for-kvm-and-xen-x86_64-jeos-extra@64bit_virtio-2G fails in [kdump_and_crash](https://openqa.opensuse.org/tests/1523048/modules/kdump_an… After the update to kernel 5.10, kdump_and_crash fails crash: cannot determine length of symbol: log_end ## Test suite description Same as jeos, plus some more tests. ## Reproducible Fails since (at least) Build [20190311](https://openqa.opensuse.org/tests/877894) ## Expected result Last good: (unknown) (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 2

[Bug 1184782] New: Emergency mode during boot with "mount(2) system call failed: Cannot allocate memory"
by bugzilla_noreply＠suse.com 11 Mar '22

11 Mar '22

https://bugzilla.suse.com/show_bug.cgi?id=1184782 Bug ID: 1184782 Summary: Emergency mode during boot with "mount(2) system call failed: Cannot allocate memory" 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: martin.wilck(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Just had this problem when starting my workstation this morning. May or may not be related to bug 1184779, which I encountered simultaneously. > [ 105.589905] apollon systemd[1]: Mounting /var/spool... > [ 105.610706] apollon systemd[1]: Mounting /var/tmp... > [ 105.612009] apollon systemd[1]: Starting File System Check on /dev/disk/by-label/git... > ... > [ 105.626645] apollon mount[1975]: mount: /var/tmp: mount(2) system call failed: Cannot allocate memory. > [ 105.636377] apollon systemd[1]: Finished Load/Save Screen Backlight Brightness of leds:dell::kbd_backlight. > [ 105.638474] apollon systemd[1]: Mounted /.snapshots. > [ 105.640099] apollon systemd[1]: Mounted /boot/efi. > ... > [ 105.666824] apollon systemd[1]: Failed to mount /var/tmp. > [ 105.668645] apollon systemd[1]: Dependency failed for Local File Systems. > [ 105.668705] apollon systemd[1]: local-fs.target: Job local-fs.target/start failed with result 'dependency'. After entering emergency mode, I simply typed "mount /var/tmp", and had no issue. Bug 1184779 persisted though (see there). /var/tmp is just a btrfs subvolume. # btrfs subvol list / ID 257 gen 930369 top level 5 path @ ID 258 gen 1432317 top level 257 path @/.snapshots ID 260 gen 1427487 top level 257 path @/boot/grub2/x86_64-efi ID 261 gen 1432361 top level 257 path @/opt ID 262 gen 1427487 top level 257 path @/srv ID 263 gen 18 top level 257 path @/tmp ID 264 gen 1432300 top level 257 path @/usr/local ID 265 gen 1432339 top level 257 path @/var/cache ID 266 gen 1427487 top level 257 path @/var/crash ID 267 gen 1427487 top level 257 path @/var/lib/mailman ID 268 gen 1427487 top level 257 path @/var/lib/mariadb ID 269 gen 1427487 top level 257 path @/var/lib/mysql ID 270 gen 1427487 top level 257 path @/var/lib/named ID 271 gen 1427487 top level 257 path @/var/lib/pgsql ID 272 gen 1432392 top level 257 path @/var/log ID 273 gen 1427487 top level 257 path @/var/opt ID 274 gen 1432391 top level 257 path @/var/spool ID 275 gen 1432366 top level 257 path @/var/tmp ID 276 gen 1427487 top level 257 path @/var/lib/machines ID 1650 gen 1432304 top level 257 path @/var/lib/systemd/coredump ID 1893 gen 1432387 top level 258 path @/.snapshots/1113/snapshot ID 2158 gen 1418255 top level 258 path @/.snapshots/1271/snapshot ID 2159 gen 1424575 top level 258 path @/.snapshots/1272/snapshot ID 2163 gen 1427385 top level 258 path @/.snapshots/1273/snapshot ID 2164 gen 1429845 top level 258 path @/.snapshots/1274/snapshot ID 2165 gen 1429883 top level 258 path @/.snapshots/1275/snapshot ID 2166 gen 1429959 top level 258 path @/.snapshots/1276/snapshot ID 2167 gen 1429963 top level 258 path @/.snapshots/1277/snapshot It's listed in fstab like any other subvols. > UUID=ad544c37-37f9-44a4-9798-d29d3cb5db44 /var/tmp btrfs subvol=@/var/tmp 0 0 > UUID=ad544c37-37f9-44a4-9798-d29d3cb5db44 /.snapshots btrfs subvol=(a)/.snapshots 0 0 > UUID=ad544c37-37f9-44a4-9798-d29d3cb5db44 /var/lib/machines btrfs subvol=@/var/lib/machines 0 0 Full boot log is attached. systemd-246.13-1.1.x86_64 kernel-default-5.11.11-1.2.x86_64 libmount1-2.36.2-1.3.x86_64 util-linux-2.36.2-1.3.x86_64 The system has 8BiB RAM. It seems highly unlikely that the system went out of memory this early during boot. After boot and graphical user login, mem usage is like this: # free total used free shared buff/cache available Mem: 7897336 3457336 642880 767688 3797120 3305920 Swap: 8383484 23040 8360444 -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1183990] New: I think I found the cause of a kernel lock when attempting hibernation
by bugzilla_noreply＠suse.com 10 Mar '22

10 Mar '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1183990 Bug ID: 1183990 Summary: I think I found the cause of a kernel lock when attempting hibernation Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: carlos.e.r(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hi, For months I have been experiencing a kernel "trouble" in _some_ of my attempts to hibernate. Sometimes the hibernation would stall and not proceed. Issuing "systemctl hibernate" replied that there was one in progress, but there was no progress. I would attempt to halt the machine, but this would also stall at some point. If I pressed ctrl-alt-del several times, fast, I would see the message that it had detected the keys seven times and would halt immediately, but it did not. I had no way out but hit the power switch, and suffer the long fsck the next morning. Nothing in the logs whatsoever. Well, one day I noticed in "atop" that one of my disks went to 100% busy when this happened. So I left running another instance of gkrellm, displaying the i/o state of all my partitions in /dev/sdc, and experimenting with "sync" I noticed it was sdc9 which was active, at something like 400 Kbps. I noticed that "sync" would take sometimes a minute to complete. /dev/sdc9 is a reiserfs, and has several bind mounts: /dev/sdc9 on /data/Lareiserfs type reiserfs (rw,relatime,lazytime,user_xattr,acl) bind mounts: /dev/sdc9 on /data/homedvl type reiserfs (rw,relatime,lazytime,user_xattr,acl) /dev/sdc9 on /usr/share/flightgear type reiserfs (rw,relatime,lazytime,user_xattr,acl) /dev/sdc9 on /var/spool/news type reiserfs (rw,relatime,lazytime,user_xattr,acl) /dev/sdc9 on /home/cer/terrasync type reiserfs (rw,relatime,lazytime,user_xattr,acl) /dev/sdc9 on /usr/src type reiserfs (rw,relatime,lazytime,user_xattr,acl) Now, the directory that is active is "/var/spool/news". I use leafnode nntp proxy server. It contains 1.2 million files in about 3 GB of space. I found that if I run this sequence: time sync time sync && systemctl hibernate the machine hibernates successfully - 13 days so far, a record. Most days it takes a minute to sync, but one day, I noticed it took several minutes. Why? Well, it happened that at the same time "/usr/sbin/texpire" was working (a cronjob triggers it). This task runs for about half an hour daily expunging old posts, meaning it examines a million files. Maybe with this (tentative) report you can improve the kernel response so that it doesn't stall when trying to hibernate, assumedly when taking too long to sync. Me would think that the kernel should stop tasks before doing the sync :-? At least, running sync manually I can detect the situation and kill the busy task before suffering the crash. On the other hand, maybe there is an issue on reiserfs with "lazytime" (which is default), delaying the writes of "something" till forced to. My wild guess, it delays the timestamp that registers a file was touched. Each time I read a post, or Thunderbird scans a post, the timestamp (sorry, I don't remember which exact timestamp it is) is written, but it is not actually written but delayed "for ever". I use reiserfs for this mount because in theory it should work better than others with millions of small files. -- You are receiving this mail because: You are the assignee for the bug.

1 11

[kernel-bugs] [Bug 1177624] New: watchdog: BUG: soft lockup - CPU#16 stuck for 23s! [qemu-system-aar:4554]
by bugzilla_noreply＠suse.com 08 Mar '22

08 Mar '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1177624 Bug ID: 1177624 Summary: watchdog: BUG: soft lockup - CPU#16 stuck for 23s! [qemu-system-aar:4554] Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: aarch64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: guillaume.gardet(a)arm.com QA Contact: qa-bugs(a)suse.de CC: afaerber(a)suse.com, dmueller(a)suse.com Found By: --- Blocker: --- Created attachment 842562 --> http://bugzilla.opensuse.org/attachment.cgi?id=842562&action=edit dmesg.log The D05 machine used as a worker for openqa.opensuse.org have been upgraded from Leap 15.1 to Leap 15.2 and shows lots of performance problems. Lots of mistyping in qemu, few screen corruptions. Checking the kernel log (in attachment), we can see some traces related to the watchdog. -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 1189808] New: udp datagrams received out-of-order with kernel 5.3.18-lp152.72.1 onwards
by bugzilla_noreply＠suse.com 08 Mar '22

08 Mar '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1189808 Bug ID: 1189808 Summary: udp datagrams received out-of-order with kernel 5.3.18-lp152.72.1 onwards Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: x86-64 OS: openSUSE Leap 15.2 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: simonalogan(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36 Build Identifier: Hi folks, We have observed that Leap 15.2 kernels 5.3.18-lp152.72.1 onwards frequently deliver UDP packets out of order. The issue is 100% reproducable on Haswell hardware, for example an Intel(R) Core(TM) i3-4130 CPU @ 3.40GHz machine. I know UDP makes no guarantee of packet delivery order, but previous kernels always seemed to deliver packets in order. Did something change in 72.1 that would affect this? We noticed this affecting video streaming, but it is easily reproducable using iperf. Please see steps below. Thanks, Simon Reproducible: Always Steps to Reproduce: - Run an iperf server on the Haswell box. iperf3 -s - Now run a set of 10 tests, asking a remote client to receive 300Mbit blocks of UDP data. for iter in 0 1 2 3 4 5 6 7 8 9; do echo "iter: $iter"; iperf3 -c 192.168.1.10 -u -b 300M -R | grep "datagrams received out-of-order"; done Using kernel 5.3.18-lp152.60 I see no out-of-order datagrams. Using kernel 5.3.18-lp152.87 I see > 10k out-of-order datagrams on each run. Actual Results: Using the 5.3.18-lp152.87 kernel: iter: 0 [SUM] 0.0-10.0 sec 22283 datagrams received out-of-order iter: 1 [SUM] 0.0-10.0 sec 23910 datagrams received out-of-order iter: 2 [SUM] 0.0-10.0 sec 20661 datagrams received out-of-order iter: 3 [SUM] 0.0-10.0 sec 20182 datagrams received out-of-order iter: 4 [SUM] 0.0-10.0 sec 18224 datagrams received out-of-order iter: 5 [SUM] 0.0-10.0 sec 19448 datagrams received out-of-order iter: 6 [SUM] 0.0-10.0 sec 27404 datagrams received out-of-order iter: 7 [SUM] 0.0-10.0 sec 17781 datagrams received out-of-order iter: 8 [SUM] 0.0-10.0 sec 11182 datagrams received out-of-order iter: 9 [SUM] 0.0-10.0 sec 25676 datagrams received out-of-order Here's the full output from one run: [ 5] local 192.168.1.8 port 53594 connected to 192.168.1.10 port 5201 [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-1.00 sec 35.8 MBytes 300 Mbits/sec 0.010 ms 0/25904 (0%) [ 5] 1.00-2.00 sec 35.7 MBytes 300 Mbits/sec 0.024 ms 0/25888 (0%) [ 5] 2.00-3.00 sec 35.8 MBytes 300 Mbits/sec 0.027 ms 0/25897 (0%) [ 5] 3.00-4.00 sec 35.8 MBytes 300 Mbits/sec 0.012 ms 1/25908 (0.0039%) [ 5] 4.00-5.00 sec 35.8 MBytes 300 Mbits/sec 0.021 ms -1/25897 (-0.0039%) [ 5] 5.00-6.00 sec 35.8 MBytes 300 Mbits/sec 0.017 ms 0/25897 (0%) [ 5] 6.00-7.00 sec 35.7 MBytes 300 Mbits/sec 0.032 ms 0/25887 (0%) [ 5] 7.00-8.00 sec 35.8 MBytes 300 Mbits/sec 0.012 ms 0/25909 (0%) [ 5] 8.00-9.00 sec 35.8 MBytes 300 Mbits/sec 0.009 ms 0/25899 (0%) [ 5] 9.00-10.00 sec 35.8 MBytes 300 Mbits/sec 0.015 ms 0/25897 (0%) - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-10.00 sec 358 MBytes 300 Mbits/sec 0.000 ms 0/259008 (0%) sender [SUM] 0.0-10.0 sec 22745 datagrams received out-of-order [ 5] 0.00-10.00 sec 358 MBytes 300 Mbits/sec 0.015 ms 0/258983 (0%) receiver Going the other way simon@localhost:~> iperf3 -c 192.168.1.10 -u -b 300M Connecting to host 192.168.1.10, port 5201 [ 5] local 192.168.1.8 port 56004 connected to 192.168.1.10 port 5201 [ ID] Interval Transfer Bitrate Total Datagrams [ 5] 0.00-1.00 sec 35.7 MBytes 300 Mbits/sec 25878 [ 5] 1.00-2.00 sec 35.8 MBytes 300 Mbits/sec 25898 [ 5] 2.00-3.00 sec 35.8 MBytes 300 Mbits/sec 25900 [ 5] 3.00-4.00 sec 35.8 MBytes 300 Mbits/sec 25910 [ 5] 4.00-5.00 sec 35.7 MBytes 300 Mbits/sec 25878 [ 5] 5.00-6.00 sec 35.8 MBytes 300 Mbits/sec 25919 [ 5] 6.00-7.00 sec 35.7 MBytes 300 Mbits/sec 25882 [ 5] 7.00-8.00 sec 35.8 MBytes 300 Mbits/sec 25897 [ 5] 8.00-9.00 sec 35.8 MBytes 300 Mbits/sec 25898 [ 5] 9.00-10.00 sec 35.8 MBytes 300 Mbits/sec 25898 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-10.00 sec 358 MBytes 300 Mbits/sec 0.000 ms 0/258958 (0%) sender [ 5] 0.00-10.00 sec 358 MBytes 300 Mbits/sec 0.013 ms 6/258958 (0.0023%) receiver Expected Results: Based on kernel 5.3.18-lp152.60, I expect no out-of-order datagrams. -- You are receiving this mail because: You are the assignee for the bug.

1 9