December 2023 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1218235] New: Built in Sreen won't wake up
by bugzilla_noreply＠suse.com 19 Dec '23

19 Dec '23

https://bugzilla.suse.com/show_bug.cgi?id=1218235 Bug ID: 1218235 Summary: Built in Sreen won't wake up 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: mail(a)bewi.at QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Hello all! I’ve a problem with the wake up from screen sleep and latest kernels. When the computer screen goes to sleep it won’t wake up anymore. No mouse cursor nor i can change the tty (Strg + Alt + F1 …). The journals logs are also empty and only a hard reset helps. I’ve tested it with the lastest Linux Kernel 6.6.6 and 6.6.7. Funnily if the whole computer goes to sleep (for example Sleep, Hybrid Sleep and Hibernate), and i disable Screen Sleep before, the screen wakes up. The problem exists only when the screen goes to sleep. With older kernels (i don't know the exact version) it does work. Info for my System: Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 PRO 7840U w/ Radeon 780M Graphics Memory: 30,1 GiB of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: LENOVO Product Name: 21F80041GE System Version: ThinkPad T14s Gen 4 Maybe someone have an idea or an tip where i should submit a bug ticket. Thank you very much. Best regards! -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1218231] New: Hw virtualization enabled in BIOS of Intel Skylake i5-6200U, but lscpu says "VMX" disabled
by bugzilla_noreply＠suse.com 19 Dec '23

19 Dec '23

https://bugzilla.suse.com/show_bug.cgi?id=1218231 Bug ID: 1218231 Summary: Hw virtualization enabled in BIOS of Intel Skylake i5-6200U, but lscpu says "VMX" disabled Classification: openSUSE Product: openSUSE Distribution Version: Leap 16.0 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: el(a)horse64.org QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- I boot with these kernel options for CPU security: "mitigations=auto,nosmt mds=full,nosmt", on a laptop with Skylake i5-6200U. However, in the BIOS/UEFI options I enabled all virtualization features of this CPU. This means VT-x/VMX should be available, since Skylake supports this according to product pages. The kernel's iTLB multihit mitigation documentation does NOT suggest that any mitigation option will ever disable VT-x/VMX fully. Therefore, I would strongly expect it to be enabled on this system with this configuration. Now here comes the problem: $ lscpu | grep VMX Vulnerability Itlb multihit: KVM: Mitigation: VMX disabled Vulnerability L1tf: Mitigation; PTE Inversion; VMX conditional cache flushes, SMT disabled $ cat /sys/devices/system/cpu/vulnerabilities/itlb_multihit KVM: Mitigation: VMX disabled Something seems to be wrong here. As a semi naive uninformed user, I am guessing the following possible options for what happened: Option A: VMX is actually disabled by the kernel through some mitigation option. In this case this is a documentation issue, since the kernel help explaining this "KVM: Mitigation: VMX disabled" text ( https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/multihit.html ) is written like no mitigation would actively disable it, suggesting "VMX disabled" is only meant to show when the BIOS/UEFI turned it off. So the help page should then say what may mess with VMX on a kernel level beyond BIOS/UEFI. Option B: VMX is actually enabled, and the iTLB mitigation is set to "Split huge pages" (this would as far as I can tell be the "correct" option for this system). In this case, there seems to be some mostly benign iTLB info output bug. Option C: VMS is actually enabled, and the iTLB mitigation is NOT active and the device is vulnerable. This potential outcome is why I marked this as SECURITY ISSUE until it can be ruled out, since if that is true then lscpu clearly tells me I'm safe while I'm actually not. So this outcome could trick admins into making expensive hardening missteps. Option D: Maybe I'm just not smart enough to use my BIOS/UEFI, lol, or I misunderstand VMX/VT-x fundamentally. I'm not a kernel developer, after all. Vaguely related, this server fault post suggests this may also happen on many distributions: https://serverfault.com/questions/1073247/if-kvm-is-working-why-does-vmx-sh… (Not entirely sure though if it's the same cause) First seen with Fedora's 5.13.15-200.fc34.x86_64, still present with OpenSUSE slowroll's 6.5.9-1-default. Steps to reproduce: 1. Boot an Intel Skylake computer with Fedora installed. Ensure all virtualization features are enabled in the UEFI/BIOS options. 2. Once Linux has booted, change /etc/default/grub to add in "mitigations=auto,nosmt mds=full,nosmt" and update your generated grub2 files, and reboot. 3. Once inside Linux again, check "lscpu" output and /sys/devices/system/cpu/vulnerabilities/itlb_multihit output. Expected output would be something else than "VMX disabled". -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1211226] Eliminate the need for 'OBS source links': convert to _multibuild
by bugzilla_noreply＠suse.com 19 Dec '23

19 Dec '23

https://bugzilla.suse.com/show_bug.cgi?id=1211226 Frederic Crozat <fcrozat(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |1218184 -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1218133] enable regulator modules (REGULATOR_MT6323, REGULATOR_MT6380, MFD_MT6397)
by bugzilla_noreply＠suse.com 18 Dec '23

18 Dec '23

https://bugzilla.suse.com/show_bug.cgi?id=1218133 https://bugzilla.suse.com/show_bug.cgi?id=1218133#c1 Bob Goddard <opensuse(a)1.opensuse.bgcomp.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|enable regulator modules |enable regulator modules |(REGULATOR_MT6323, |(REGULATOR_MT6323, |MFD_MT6397) |REGULATOR_MT6380, | |MFD_MT6397) --- Comment #1 from Bob Goddard <opensuse(a)1.opensuse.bgcomp.co.uk> --- And also REGULATOR_MT6380. I think it would be better to enable them all if they can be build as modules. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1218153] New: reduce SERIAL_8250_RUNTIME_UARTS?
by bugzilla_noreply＠suse.com 18 Dec '23

18 Dec '23

https://bugzilla.suse.com/show_bug.cgi?id=1218153 Bug ID: 1218153 Summary: reduce SERIAL_8250_RUNTIME_UARTS? 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: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- CONFIG_SERIAL_8250_RUNTIME_UARTS is currently set to 32 which leads to 32 /dev/ttyS*. The upstream default is 4. Is there a need to pre-create that many nodes? I noticed that it clutters the `systemd-analyze blame` quite a bit when looking for boot times. Maybe reduce it back to 4? Users that really need that many ports can set 8250.nr_uarts=32 on the kernel command line as documented upstream: https://github.com/torvalds/linux/blob/master/drivers/tty/serial/8250/Kconf… -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1218133] New: Missing modules
by bugzilla_noreply＠suse.com 17 Dec '23

17 Dec '23

https://bugzilla.suse.com/show_bug.cgi?id=1218133 Bug ID: 1218133 Summary: Missing modules 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: opensuse(a)1.opensuse.bgcomp.co.uk QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- There are quite a number of regulator modules not being built. Some of these at least depend on the multifunction device drivers. I am looking to get tumbleweed up and running on the BananaPi-R3, and perhaps the new BananaPi-R4 in the future. This needs REGULATOR_MT6323 enabled, at least as a module, and it depend on MFD_MT6397. There seems to be an awful lot of regulators not being build, mainly because the multi function devices have not been selected. As many of these can be built as modules, can these all be enables? As in all the PMICs? -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1217344] New: Linux 6.6.1 fails to boot
by bugzilla_noreply＠suse.com 16 Dec '23

16 Dec '23

https://bugzilla.suse.com/show_bug.cgi?id=1217344 Bug ID: 1217344 Summary: Linux 6.6.1 fails to boot Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Critical Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: neronio(a)outlook.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- The default 6.6.1 kernel installed on my Tumbleweed system does not boot. Upon selecting it in GRUB, I see: "Loading Linux 6.6.1-1-default ..." "Loading initial ramdisk ..." and the system hangs on this screen forever. My workstation's diagnostic LEDs turn on in a pattern that, according to the service manual, indicates an "other type of failure". The workstation is a Dell T5600. CPU: 2x Intel Xeon E5-2680 (v1) RAM: 8x 8 GB DDR3 1600 MHz GPU: Nvidia NVS510, I'm using nouveau drivers. My kernel cmdline: root=UUID=5136bb35-acaa-4796-b463-8c9ef307025d splash=silent quiet mitigations=auto The latest default 6.5.9 kernel works fine on this machine. I'm available for all kinds of testing/debugging, including kernel recompilation with experimental patches and the like. -- You are receiving this mail because: You are the assignee for the bug.

1 12

[Bug 1213830] New: rather current notebook hw (from 2021) has no deep sleep /sys/power/mem_sleep - desktop hw and really old hw does have it
by bugzilla_noreply＠suse.com 15 Dec '23

15 Dec '23

https://bugzilla.suse.com/show_bug.cgi?id=1213830 Bug ID: 1213830 Summary: rather current notebook hw (from 2021) has no deep sleep /sys/power/mem_sleep - desktop hw and really old hw does have it Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: x86-64 OS: openSUSE Leap 15.5 Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: abittner(a)opensuse.org QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Hello Opensuse Kernel team, how come that my rather new notebook hardware (hp probook with amd apu, from 2021) does not sleep properly and eats up the battery all the time. barely any difference between when leaving an idle desktop (KDE) sitting around and blanking the screen and when only s2idle sleeping it (lid close, or kde function: sleep) i have tried to make sense of all of this, also reading about the linux folks over at framework-laptop e.g. <https://community.frame.work/t/responded-linux-deep-sleep/2491> all i can find is the value: cat /sys/power/mem_sleep [s2idle] cat /sys/power/state freeze mem disk also added the kernel boot parameter mem_sleep_default=deep command line via yast2 to grub2 or something: ---------- sudo dmesg -e | grep mem_sleep [ +0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.14.21-150500.55.7-default root=/dev/mapper/system-root splash=silent resume=/dev/system/swap preempt=full quiet security=apparmor mem_sleep_default=deep mitigations=auto [ +0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.14.21-150500.55.7-default root=/dev/mapper/system-root splash=silent resume=/dev/system/swap preempt=full quiet security=apparmor mem_sleep_default=deep mitigations=auto --------------- to sum it up, the system eats away the battery/power at high rates even when sleeping, lid closed etc. how to make this work on leap 15.5 with proper (deep?) memory sleep states and all? is this maybe incompatible with FDE, secureboot? this kernel lockdown stuff? i am not understanding much of this i guess. i am wondering why a really old system and other also older desktop systems just instantly show deep mem_sleep feature activated and working? this system: UEFI ans secureboot system [ +0.109168] smpboot: CPU0: AMD Ryzen 7 5800U with Radeon Graphics (family: 0x19, model: 0x50, stepping: 0x0) full disk encryption on single nvme drive thanks for helping. -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 1217344] Linux 6.6.x fails to boot
by bugzilla_noreply＠suse.com 14 Dec '23

14 Dec '23

https://bugzilla.suse.com/show_bug.cgi?id=1217344 https://bugzilla.suse.com/show_bug.cgi?id=1217344#c22 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(neronio(a)outlook.c | |om) | --- Comment #22 from Takashi Iwai <tiwai(a)suse.com> --- The upstream fix commit 50d7cdf7a9b1 landed to Linus tree: efi/x86: Avoid physical KASLR on older Dell systems I'm going to backport the fix. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1216647] Missing dummy in kernel-default-base
by bugzilla_noreply＠suse.com 14 Dec '23

14 Dec '23

https://bugzilla.suse.com/show_bug.cgi?id=1216647 Petr Vorel <petr.vorel(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugzilla.suse.com/s | |how_bug.cgi?id=1210335 -- You are receiving this mail because: You are the assignee for the bug.

1 0