November 2021 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1192767] Kernel boot logging gets mixed up when bringing up CPUs on SMP system
by bugzilla_noreply＠suse.com 18 Nov '21

18 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192767 https://bugzilla.suse.com/show_bug.cgi?id=1192767#c9 --- Comment #9 from Petr Mladek <pmladek(a)suse.com> --- (In reply to Archie Cobbs from comment #4) > But to be clear there are two bugs here... > > #1 Bogus promotion from INFO to WARN This "bug" can be fixed by using pr_cont(KERN_INFO "...") instead of plain pr_cont("..."). This notation has been supported by commit 4bcc595ccd80decb424509 ("printk: reinstate KERN_CONT for printing continuation lines") since kernel 4.9. But I do not see it used anywhere: $> git grep pr_cont\( | wc -l 1977 $> git grep pr_cont\(KERN_ | wc -l 0 Why? My guess is that it is because: + pr_cont() mostly works + it would be an extra work to keep loglevel of all the related pr_cont() pieces in sync + nobody cared enough to fix location where it did not work + many people do not know about the notation We might make it easier to use it by introducing pr_cont_<level>() wrappers. But will people use them? I do not know. There were some ideas to support continuous lines another way. For example, create an API that would use some local buffer on stack and explicitely flush it when the string is complete. But nobody cared enough to implement it. Also it would be more complicated to use and error prone. And any local buffering might cause that the message will never reach the main log buffer when something gets wrong. From my point of view. It is an aesthetic issue that it not worth fixing. The fix might do more harm than good. > #2 Broken formatting if there are any per-CPU log messages One possibility would be to print each CPU on a separate line. But it would look ugly on systems with many CPUs. Also it would create problems with slow consoles (softlockups, lost messages). Another possibility would be to use a local buffer and print the line when it is complete. But it would make it harder to debug when something went wrong in the middle. Interleaving with other messages helps to find correlation with between various events/problems on the system. It is even the case here. The interleaving helps to understand that "Disabled fast string operations" is printed for each initialized CPU. > Both bugs should be fixed. Any solution has its drawbacks. IMHO, the current code is a good compromise as long as the list of CPU IDs is interleaved only rarely. That said. It would be easy to make the loglevel consistent here. But there will be another 2000 pr_cont() calls that might cause the same problem. And there is no simple generic solution. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1192473] DE0-Nano-SoC boot fails on 15.3
by bugzilla_noreply＠suse.com 18 Nov '21

18 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192473 https://bugzilla.suse.com/show_bug.cgi?id=1192473#c15 --- Comment #15 from Christian Gross <christian.gross(a)centerofgravity.at> --- This kernel is also booting. And it looks like a very good solution. ... [ OK ] Reached target Timers. Welcome to openSUSE Leap 15.2 - Kernel 5.3.18-3.g07d0aaa-default (ttyS0). localhost login: -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1191795] Ethernet (RJ45) Not Detected
by bugzilla_noreply＠suse.com 18 Nov '21

18 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1191795 https://bugzilla.suse.com/show_bug.cgi?id=1191795#c37 --- Comment #37 from Oliver Neukum <oneukum(a)suse.com> --- Please conduct the following test. In the description I am assuming that your interface is named enp5s0. If it isn't, please replace the name. 1. Do not use TLP 2. Unplug the RJ45 on the laptop's side 3 Do: ethtool -s enp5s0 wol p 4: Suspend your laptop 5. Wait 60s 6. Plug the cable back in If it does not wake up from the plug, repeat the test with ethtool -s enp5s0 wol umb and report the result. To get your system back to normal do: ethtool -s enp5s0 wol d -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1191795] Ethernet (RJ45) Not Detected
by bugzilla_noreply＠suse.com 18 Nov '21

18 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1191795 https://bugzilla.suse.com/show_bug.cgi?id=1191795#c36 --- Comment #36 from Oliver Neukum <oneukum(a)suse.com> --- OK, another extremely specific question. What is on the other end of the ethernet cable when you do that experiment? Are they in a hub or switch or do you dangle them in the air? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1192118] [Build 20211027] openQA test fails in finit_module02
by bugzilla_noreply＠suse.com 18 Nov '21

18 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192118 https://bugzilla.suse.com/show_bug.cgi?id=1192118#c5 --- Comment #5 from Takashi Iwai <tiwai(a)suse.com> --- .. or do you mean that this is triggered by other (SLE) release? If so, we may need backport. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1191795] Ethernet (RJ45) Not Detected
by bugzilla_noreply＠suse.com 18 Nov '21

18 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1191795 https://bugzilla.suse.com/show_bug.cgi?id=1191795#c35 --- Comment #35 from Oliver Neukum <oneukum(a)suse.com> --- Please provide the output of "ethtool NAMEOFFAILINGDEVICE" while in the state plug ins are not recognized. To explain: The device implements runtime power management setting its WOL level to "anything". A reason for the problem is that this may fail. I am also trying to come up with a test procedure. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1191795] Ethernet (RJ45) Not Detected
by bugzilla_noreply＠suse.com 18 Nov '21

18 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1191795 https://bugzilla.suse.com/show_bug.cgi?id=1191795#c34 --- Comment #34 from Oliver Neukum <oneukum(a)suse.com> --- Please provide te outputs of "lspci -vvv" and "lspci -vvvn" (as root) -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1192714] [Build 20211114] podman tests triggering gpf in kernel 5.15.1
by bugzilla_noreply＠suse.com 18 Nov '21

18 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192714 https://bugzilla.suse.com/show_bug.cgi?id=1192714#c15 --- Comment #15 from Jan Kara <jack(a)suse.com> --- Thanks for the traces. So in all the cases it seems that struct bfq_group got freed while still being fully linked into various structures. The freeing always happened from blkg_free() called from RCU callback so everything points to the fact that blkg refcount got somehow corrupted (likely someone dropping a ref without taking it). Looking more into this... -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1192118] New: [Build 20211027] openQA test fails in finit_module02
by bugzilla_noreply＠suse.com 18 Nov '21

18 Nov '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1192118 Bug ID: 1192118 Summary: [Build 20211027] openQA test fails in finit_module02 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/1998049/modules/fini t_module02/steps/7 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-ltp-syscalls@uefi_virtio-2G fails in [finit_module02](https://openqa.opensuse.org/tests/1998049/modules/finit_mod… failed # echo 'OpenQA::run_ltp.pm: Starting finit_module02' > /dev/ttyS0; echo EuAAc-$?- EuAAc-0- # finit_module02; echo "### TEST finit_module02 COMPLETE >>> $?" tst_test.c:1363: TINFO: Timeout per run is 0h 05m 00s finit_module02.c:119: TPASS: TestName: invalid-fd : EBADF (9) fin�� finit_module02 finit_module02.c:119: TPASS: TestName: invalid-fd : EBADF (9) finit_module02.c:119: TPASS: TestName: zero-fd : EINVAL (22) finit_module02.c:119: TPASS: TestName: null-param : EFAULT (14) finit_module02.c:119: TPASS: TestName: invalid-param : EINVAL (22) finit_module02.c:119: TPASS: TestName: invalid-flags : EINVAL (22) finit_module02.c:119: TPASS: TestName: no-perm : EPERM (1) finit_module02.c:119: TPASS: TestName: module-exists : EEXIST (17) finit_module02.c:119: TFAIL: TestName: file-not-readable expected EBADF: ETXTBSY (26) finit_module02.c:119: TPASS: TestName: directory : EINVAL (22) Failed. Test took approximately 0.0326297609935864 seconds Some test output could not be parsed: 12 lines were ignored. ## Test suite description ## Reproducible Fails since (at least) Build [20211026](https://openqa.opensuse.org/tests/1994788) ## Expected result Last good: [20211025](https://openqa.opensuse.org/tests/1992656) (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 3

[Bug 1192714] [Build 20211114] podman tests triggering gpf in kernel 5.15.1
by bugzilla_noreply＠suse.com 18 Nov '21

18 Nov '21

https://bugzilla.suse.com/show_bug.cgi?id=1192714 https://bugzilla.suse.com/show_bug.cgi?id=1192714#c13 Fabian Vogt <fvogt(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(fvogt(a)suse.com) | --- Comment #13 from Fabian Vogt <fvogt(a)suse.com> --- Created attachment 853836 --> https://bugzilla.suse.com/attachment.cgi?id=853836&action=edit decoded traces + dmesg (In reply to Jiri Slaby from > comment #10) > > (In reply to Fabian Vogt from comment #8) > > > Created attachment 853801 [details] > > > dmesg + blktrace > > > > Could you feed the trace through the kernel's ./scripts/decode_stacktrace.sh > > (provided you built the kernel with debuginfo)? > > Will do. decode_stacktrace.sh got confused when using a serial console dump as input, because of CRLF line endings. After dos2unix treatment it worked. Decoded traces and dmesg are attached. -- You are receiving this mail because: You are the assignee for the bug.

1 0