November 2022 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1204063] New: Kernel 5.19.8 appears to be missing lpuart earlycon and console
by bugzilla_noreply＠suse.com 29 Nov '22

29 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1204063 Bug ID: 1204063 Summary: Kernel 5.19.8 appears to be missing lpuart earlycon and console Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: aarch64 OS: openSUSE Tumbleweed Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: afaerber(a)suse.com Reporter: afaerber(a)suse.com QA Contact: qa-bugs(a)suse.de CC: ddavis(a)suse.com, dmueller(a)suse.com, guillaume.gardet(a)arm.com, kernel-bugs(a)opensuse.org, mbrugger(a)suse.com, mkubecek(a)suse.com Found By: --- Blocker: --- Despite kernel command line "console=ttyLP0,115200 earlycon=lpuart32,0x5a060000,115200" on an NXP i.MX 8QM based Variscite VAR-SOM-MX8 module based device, I am not seeing any kernel serial output other than EFI stub: Loading Linux 5.19.8-1-default ... Loading initial ramdisk ... EFI stub: Booting Linux Kernel... EFI stub: EFI_RNG_PROTOCOL unavailable EFI stub: Using DTB from configuration table EFI stub: Exiting boot services... or without EFI: Starting kernel ... Having ruled out a red herring of EFI stub: ERROR: Failed to install memreserve config table! as caused by old U-Boot 2018.03 having a hardcoded config table array size of 2, the lack of output most likely is because of: CONFIG_SERIAL_FSL_LPUART=m git-blame points to a SLE15-SP2 sync: https://github.com/openSUSE/kernel-source/commit/769684a2fa08#diff-a9e1c242… Serial Kconfig options need to be built-in (=y) in order to enable their sub-option *_CONSOLE=y, needed for both console= and earlycon= kernel options. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1205743] Installer hangs on "Probing USB devices" on Dell XPS 9520
by bugzilla_noreply＠suse.com 29 Nov '22

29 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1205743 https://bugzilla.suse.com/show_bug.cgi?id=1205743#c7 --- Comment #7 from Takashi Iwai <tiwai(a)suse.com> --- Can switch the VT via ctrl-alt-F1, F2 or other? Also, ctrl-alt-shift-X should start an xterm, IIRC. If you can have a terminal access, try to get the dmesg output. If we are lucky, we can see some errors. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1205743] Installer hangs on "Probing USB devices" on Dell XPS 9520
by bugzilla_noreply＠suse.com 29 Nov '22

29 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1205743 https://bugzilla.suse.com/show_bug.cgi?id=1205743#c6 --- Comment #6 from Johnny Willemsen <jwillemsen(a)remedy.nl> --- The screen "System Probing" appears and on "Probe USB devides" nothing happens, progress bar stays at 0%, mouse does seem to work but nothing more happens. Any magic button or something I can do to give you more details/insight? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1205743] Installer hangs on "Probing USB devices" on Dell XPS 9520
by bugzilla_noreply＠suse.com 29 Nov '22

29 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1205743 https://bugzilla.suse.com/show_bug.cgi?id=1205743#c5 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tiwai(a)suse.com Flags| |needinfo?(jwillemsen@remedy | |.nl) --- Comment #5 from Takashi Iwai <tiwai(a)suse.com> --- How exactly is the situation? Does the complete screen freeze, or does the cursor still work? Also, can you change the VT? It's difficult to know what's going without the detailed logs and without the way to reproduce locally on the installed system, unfortunately. Judging from the hwinfo, it's a system with Alterlake and Nvidia, and as nomodeset works around it, it's likely a problem in i915 driver. But that's the only information we can have from the description. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1205639] New: After 'zypper dup' the Ethernet device got name end0 instead of eth0
by bugzilla_noreply＠suse.com 29 Nov '22

29 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1205639 Bug ID: 1205639 Summary: After 'zypper dup' the Ethernet device got name end0 instead of eth0 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: aarch64 OS: openSUSE Tumbleweed Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: freek(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- After 'zypper dup' to tumbleweed:20221120 on an aarch64 system the name of the Ethernet device got the name end0 instead of remaining eth0. Because this device is not present in the firewall configuration, access to this system is not possible anymore. I do have access via a tty device. -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 1205813] BTRFS data corruption - need help
by bugzilla_noreply＠suse.com 29 Nov '22

29 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1205813 http://bugzilla.opensuse.org/show_bug.cgi?id=1205813#c7 --- Comment #7 from Felix Niederwanger <felix.niederwanger(a)suse.com> --- Hard to know. btrfs can only detect those issues via checksuming but is itself not able to tell you where they come from - they can originate from basically anywhere. Faulty hardware or bad connectors are by far more likely than a filesystem issue itself. IMHO - don't bother trying to repair such issues. If you could save the data elsewhere then nuke the filesystem and start over. I would be suspicious on the hardware itself and wouldn't rely on it for a couple of months after such a failure, i.e. always keep backups and assume it's going to shoot itself in the foot again. At this point I would say it's safe to assume the disk is somehow flanky until proven otherwise. But those are just my two cents - Your hardware, your rules :-) -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1190256] Keyboard not working after cold-boot on ASUS Zenbook 14 UM425UA with Tumbleweed 20210904
by bugzilla_noreply＠suse.com 29 Nov '22

29 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1190256 Jeffrey Cheung <jcheung(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P2 - High -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1205813] BTRFS data corruption - need help
by bugzilla_noreply＠suse.com 28 Nov '22

28 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1205813 http://bugzilla.opensuse.org/show_bug.cgi?id=1205813#c6 --- Comment #6 from Max Thein <opensuse(a)mailbox.org> --- I have followed the wiki instructions up to the scrub command. After that, the first warning box says: "...If the above doesn't fix things for you, you can continue with the below steps but the situation is serious enough to justify a bug report, please!" Wouldn't it be interesting to know why there are these checksum errors? Occurred during an average desktop use case? I can follow the further wiki instructions. Maybe it will help, maybe my system will become unusable. Then I am left with a reinstall without knowing the reason. Not very smart. My hope is to figure out the problem before I enter irreversible terminal commands. I'm not a BTRFS expert, so I am asking for help here. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1205813] BTRFS data corruption - need help
by bugzilla_noreply＠suse.com 28 Nov '22

28 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1205813 http://bugzilla.opensuse.org/show_bug.cgi?id=1205813#c5 Felix Niederwanger <felix.niederwanger(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |felix.niederwanger(a)suse.com --- Comment #5 from Felix Niederwanger <felix.niederwanger(a)suse.com> --- It's more a support request than a bug report. Judging from the dmesg output it looks like that part of the partition got corrupted and btrfs detects checksum mismatches. It's good that you could save everything important already elsewhere. Checkout the wiki page on how to repair a (unmountable) btrfs filesystem, that might help you: https://en.opensuse.org/SDB:BTRFS#How_to_repair_a_broken.2Funmountable_btrf… Good luck! -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1205660] New: Fix non-working Realtek USB ethernet after system resume
by bugzilla_noreply＠suse.com 28 Nov '22

28 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1205660 Bug ID: 1205660 Summary: Fix non-working Realtek USB ethernet after system resume 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: noga.dany(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 863051 --> http://bugzilla.opensuse.org/attachment.cgi?id=863051&action=edit Dmesg from trying to multiple sleep, resume cycles I am using Lenovo T15p gen.2 (Intel) connected to the Dell TB16 dock. Whenever I put notebook on the sleep and then resume, ethernet from dock does not work. I can fix it by unplug and plug again thunderbold cable or by command line: sudo rmmod r8153_ecm sudo rmmod r8152 sudo modprobe r8153_ecm Issue is with all Leap 15.4 kernels including 5.14.21-150400.24.33-default It looks similar to the https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1847063 , but that bug mentions something about r8152 and nothing about r8153_ecm Dmesg from trying to multiple sleep, resume cycles and from trying to fix it via rmmod and modprobe attached. Issue is not 100% reproducible, when I wrote this bug report, it worked once right after boot. But only once. -- You are receiving this mail because: You are the assignee for the bug.

1 12