March 2023 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1207372] suspend/hibernate broken on Lenovo X1 Extreme Gen5 because of
by bugzilla_noreply＠suse.com 09 Mar '23

09 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1207372 Chenzi Cao <chcao(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Basesystem |Kernel Assignee|screening-team-bugs(a)suse.de |kernel-bugs(a)opensuse.org -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208990] intel: UHD630 (Kabylake) support broken?
by bugzilla_noreply＠suse.com 09 Mar '23

09 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208990 http://bugzilla.opensuse.org/show_bug.cgi?id=1208990#c21 Stefan Dirsch <sndirsch(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Comment #19 is|1 |0 private| | Status|IN_PROGRESS |RESOLVED Resolution|--- |DUPLICATE Flags|needinfo?(opendreas(a)gmail.c | |om) | --- Comment #21 from Stefan Dirsch <sndirsch(a)suse.com> --- Ok. This has already been fixed for current images of sle15sp5, but apparently not for Leap 15.5 Beta. :-( *** This bug has been marked as a duplicate of bug 1207516 *** -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208990] intel: UHD630 (Kabylake) support broken?
by bugzilla_noreply＠suse.com 09 Mar '23

09 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208990 http://bugzilla.opensuse.org/show_bug.cgi?id=1208990#c20 --- Comment #20 from Andreas <opendreas(a)gmail.com> --- Created attachment 865416 --> http://bugzilla.opensuse.org/attachment.cgi?id=865416&action=edit Xorg.99.log (In reply to Stefan Dirsch from comment #18) > Ok. There is already running one. Please try again with > > Xorg -config /etc/X11/xorg.conf.install -retro :99 > > Then attach /var/log/Xorg.99.log X.Org X Server 1.21.1.4 X Protocol Version 11, Revision 0 Current Operating System: Linux precision 5.14.21-150500.43-default #1 SMP PREEMPT_DYNAMIC Wed Mar 1 05:38:55 UTC 2023 (11cbfa2) x86_64 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.14.21-150500.43-default root=UUID=3084deeb-b3e4-40cc-a328-20df3960a04e splash=silent preempt=full quiet loglevel=3 security=apparmor mitigations=auto Current version of pixman: 0.40.0 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.99.log", Time: Thu Mar 9 17:06:17 2023 (++) Using config file: "/etc/X11/xorg.conf.install" (==) Using config directory: "/etc/X11/xorg.conf.d" (==) Using system config directory "/usr/share/X11/xorg.conf.d" xf86EnableIO: failed to enable I/O ports 0000-03ff (Operation not permitted) MESA-LOADER: failed to open nouveau: /usr/lib64/dri/nouveau_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib64/dri, suffix _dri) failed to load driver: nouveau (EE) (EE) Backtrace: (EE) 0: Xorg (xorg_backtrace+0x65) [0x561218599815] (EE) 1: Xorg (0x5612183d5000+0x1c84e9) [0x56121859d4e9] (EE) 2: /lib64/libpthread.so.0 (0x7fda53fd9000+0x168c0) [0x7fda53fef8c0] (EE) 3: Xorg (InitOutput+0x4be) [0x561218476e3e] (EE) 4: Xorg (0x5612183d5000+0x63d25) [0x561218438d25] (EE) 5: /lib64/libc.so.6 (__libc_start_main+0xef) [0x7fda53c1929d] (EE) 6: Xorg (_start+0x2a) [0x5612184227ca] (EE) (EE) Segmentation fault at address 0x8e (EE) Fatal server error: (EE) Caught signal 11 (Segmentation fault). Server aborting (EE) (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. (EE) Please also check the log file at "/var/log/Xorg.99.log" for additional information. (EE) (EE) Server terminated with error (1). Closing log file. Abgebrochen -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208990] intel: UHD630 (Kabylake) support broken?
by bugzilla_noreply＠suse.com 09 Mar '23

09 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208990 Stefan Dirsch <sndirsch(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |snwint(a)suse.com -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208990] intel: UHD630 (Kabylake) support broken?
by bugzilla_noreply＠suse.com 09 Mar '23

09 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208990 http://bugzilla.opensuse.org/show_bug.cgi?id=1208990#c18 --- Comment #18 from Stefan Dirsch <sndirsch(a)suse.com> --- Ok. There is already running one. Please try again with Xorg -config /etc/X11/xorg.conf.install -retro :99 Then attach /var/log/Xorg.99.log -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208990] intel: UHD630 (Kabylake) support broken?
by bugzilla_noreply＠suse.com 09 Mar '23

09 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208990 http://bugzilla.opensuse.org/show_bug.cgi?id=1208990#c17 --- Comment #17 from Andreas <opendreas(a)gmail.com> --- Created attachment 865414 --> http://bugzilla.opensuse.org/attachment.cgi?id=865414&action=edit xorg.conf.install -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208990] intel: UHD630 (Kabylake) support broken?
by bugzilla_noreply＠suse.com 09 Mar '23

09 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208990 http://bugzilla.opensuse.org/show_bug.cgi?id=1208990#c16 --- Comment #16 from Andreas <opendreas(a)gmail.com> --- Created attachment 865413 --> http://bugzilla.opensuse.org/attachment.cgi?id=865413&action=edit Xorg.0.log (In reply to Stefan Dirsch from comment #14) > Ok. Could you try this in the *installed* sytem, please? > > Xorg -config /etc/X11/xorg.conf.install -retro > Xorg -config /etc/X11/xorg.conf.install -retro _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed _XSERVTransMakeAllCOTSServerListeners: server already running (EE) Fatal server error: (EE) Cannot establish any listening sockets - Make sure an X server isn't already running(EE) (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. (EE) Please also check the log file at "/home/andreas/.local/share/xorg/Xorg.0.log" for additional information. (EE) (EE) Server terminated with error (1). Closing log file. > Does this crash the Xserver as well? Please attach then /var/log/Xorg.0.log > and /etc/X11/xorg.conf.install No, nothing crashed -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208990] intel: UHD630 (Kabylake) support broken?
by bugzilla_noreply＠suse.com 09 Mar '23

09 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208990 http://bugzilla.opensuse.org/show_bug.cgi?id=1208990#c15 --- Comment #15 from Andreas <opendreas(a)gmail.com> --- (In reply to Takashi Iwai from comment #13) > (In reply to Andreas from comment #11) > > > Just to be sure, can you check whether you can start the fallback (icewm) > > > session (selected at login on display manager) with the same monitor > > > configuration you've seen the problems on the installer? > > I don't have IceWM installed because I unchecked it before installing Leap. > > It doesn't work well with a 4K display > > Do you mean that icewm can't be started, or it's practically unusable > because of the resolution (too small fonts, etc)? > I asked it just because YaST graphical mode uses icewm without decoration. Yes, because IceWM is unusable. I just tested IceWM on a Leap 15.5 Live image and it works. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208990] intel: UHD630 (Kabylake) support broken?
by bugzilla_noreply＠suse.com 09 Mar '23

09 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208990 http://bugzilla.opensuse.org/show_bug.cgi?id=1208990#c14 --- Comment #14 from Stefan Dirsch <sndirsch(a)suse.com> --- Ok. Could you try this in the *installed* sytem, please? Xorg -config /etc/X11/xorg.conf.install -retro Does this crash the Xserver as well? Please attach then /var/log/Xorg.0.log and /etc/X11/xorg.conf.install -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208990] intel: UHD630 (Kabylake) support broken?
by bugzilla_noreply＠suse.com 09 Mar '23

09 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208990 http://bugzilla.opensuse.org/show_bug.cgi?id=1208990#c13 --- Comment #13 from Takashi Iwai <tiwai(a)suse.com> --- (In reply to Andreas from comment #11) > > Just to be sure, can you check whether you can start the fallback (icewm) > > session (selected at login on display manager) with the same monitor > > configuration you've seen the problems on the installer? > I don't have IceWM installed because I unchecked it before installing Leap. > It doesn't work well with a 4K display Do you mean that icewm can't be started, or it's practically unusable because of the resolution (too small fonts, etc)? I asked it just because YaST graphical mode uses icewm without decoration. > > If this works on the installed system while not on the installer, something > > must be missing in the installer. > Yes, after loading drivers Yast GUI installer fails to start > https://bugzilla.opensuse.org/attachment.cgi?id=865313 > It failback to text mode, but you can only see it on external monitor. > https://bugzilla.opensuse.org/attachment.cgi?id=865315 > After clicking on "OK", Yast appears in text mode, very small with 4K > resolution. This shows the crash of X, core dumped. Something for Stefan, I guess. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208990] intel: UHD630 (Kabylake) support broken?
by bugzilla_noreply＠suse.com 09 Mar '23

09 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208990 http://bugzilla.opensuse.org/show_bug.cgi?id=1208990#c12 --- Comment #12 from Andreas <opendreas(a)gmail.com> --- Yast fails to start after an error /usr/lib/Yast2/startup/YaST2.call: line 33: 4009 Aborted This video does not have this error at the 30th second. https://youtu.be/pohDXspaMuE?t=30 -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208990] intel: UHD630 (Kabylake) support broken?
by bugzilla_noreply＠suse.com 09 Mar '23

09 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208990 http://bugzilla.opensuse.org/show_bug.cgi?id=1208990#c11 --- Comment #11 from Andreas <opendreas(a)gmail.com> --- (In reply to Takashi Iwai from comment #10) > And you're running X11, not Wayland, right? Leap 15.5 with Gnome on X11 and Wayland works well. > Just to be sure, can you check whether you can start the fallback (icewm) > session (selected at login on display manager) with the same monitor > configuration you've seen the problems on the installer? I don't have IceWM installed because I unchecked it before installing Leap. It doesn't work well with a 4K display > If this works on the installed system while not on the installer, something > must be missing in the installer. Yes, after loading drivers Yast GUI installer fails to start https://bugzilla.opensuse.org/attachment.cgi?id=865313 It failback to text mode, but you can only see it on external monitor. https://bugzilla.opensuse.org/attachment.cgi?id=865315 After clicking on "OK", Yast appears in text mode, very small with 4K resolution. At 30 seconds you can see this place with a error in the photo above, but in the video Yast is starting. https://youtu.be/pohDXspaMuE?t=30 > Judging from hwinfo, nouveau is still used. So that should be same as on > installer, at least... Yes, right now I can't use the proprietary nvidia driver on Leap 15.5 https://bugzilla.opensuse.org/show_bug.cgi?id=1209067 -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209102] New: Regressions in gitsource between 6.1 and 6.2
by bugzilla_noreply＠suse.com 09 Mar '23

09 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209102 Bug ID: 1209102 Summary: Regressions in gitsource between 6.1 and 6.2 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: jack(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Our performance testing infrastructure has noticed that gitsource benchmark has regressed between 6.1 and 6.2 upstream kernel versions on some machines. It has bisected the regression to commit f1a7941243c1 ("mm: convert mm's rss stats into percpu_counter"). The regression was detected on many machines in our performance testing grid. On pumbaa the difference is very visible: before (9cd6ffa6025) after (f1a7941243c1) Amean User 471.12 * 0.30%* 481.77 * -1.96%* Amean System 244.47 * 0.90%* 269.13 * -9.09%* Amean Elapsed 709.22 * 0.45%* 742.27 * -4.19%* Amean CPU 100.00 ( 0.20%) 101.00 * -0.80%* We can see the biggest difference in the "System time" and still noticeable difference in the "Elapsed time". The benchmark runs 'make test' in a checked-out sources of git (fixed to a particular version) so it is effectively heavily exercising shell scripting and spawning lots of shortlived tasks. So I suspect the setup cost of the percpu counters may be playing role here. -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1209006] Document how to secureboot-sign manually-built kernel modules on TW kernel >= 6.2.1
by bugzilla_noreply＠suse.com 09 Mar '23

09 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c26 --- Comment #26 from Michal Suchanek <msuchanek(a)suse.com> --- (In reply to Martin Wilck from comment #24) > From > https://lore.kernel.org/all/20220928055900.GT4909@linux-l9pv.suse/t/ > #m3ce7e451f1855d9c432965bb896cb7ce0f89e009: > > > The end-user will now need to enroll two keys. First the CA Key into the MOK and then the leaf cert into the secondary trusted keyring. > > HOW would the user add this leaf cert? I am not getting it. From the PDF At runtime, presumably with keyctl. This is not used in (open)SUSE at all but should be so that you can load official KMPs when running non-official kernel. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1209006] Document how to secureboot-sign manually-built kernel modules on TW kernel >= 6.2.1
by bugzilla_noreply＠suse.com 09 Mar '23

09 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c25 Stefan Dirsch <sndirsch(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|jslaby(a)suse.com |jlee(a)suse.com --- Comment #25 from Stefan Dirsch <sndirsch(a)suse.com> --- Now that we reverted the lockdown patches, I think we can reassign this to Joey, so he can work on this ... I will be happy to give a test kernel a try with my nvidia KMPs once things are implemented. :-) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1209006] Document how to secureboot-sign manually-built kernel modules on TW kernel >= 6.2.1
by bugzilla_noreply＠suse.com 09 Mar '23

09 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c24 --- Comment #24 from Martin Wilck <martin.wilck(a)suse.com> --- From https://lore.kernel.org/all/20220928055900.GT4909@linux-l9pv.suse/t/#m3ce7e…: > The end-user will now need to enroll two keys. First the CA Key into the MOK and then the leaf cert into the secondary trusted keyring. HOW would the user add this leaf cert? I am not getting it. From the PDF slides I got the impression that the "Root user" would play a role here, but I couldn't figure out how this would work, in particular how the root user's cert would be added to the kernel. Wrt the general mind set, I agree with Michal. IMO the biggest issue is that IMA is disabled as soon as a .machine keyring is populated. That looks like a political movement of upstream with the intention to deter people from using MoK (and thus, 3rd party modules). Most of the main actors behind the current changes seem be IBM employees, plus the Oracle guy. I guess their intention is to find an upstream-accepted framework that would keep IMA functional while allowing a root of trust outside the kernel itself. If they succeed without breaking the current, _relatively_ easy-to-use way to combine 3rd party modules with distro kernels, we might be able to drop our downstream patches, which would be a good thing. But AFAICS their approach would be harder to use, unless some additonal tooling is invented or incorporated in mokutil. MokListTrustedRT ist just an annoyance. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1209006] Document how to secureboot-sign manually-built kernel modules on TW kernel >= 6.2.1
by bugzilla_noreply＠suse.com 09 Mar '23

09 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c23 --- Comment #23 from Michal Suchanek <msuchanek(a)suse.com> --- I think that upstream as failing to understand that the transitivity of trust goes both ways. If MS verifies SUSE shim, and SUSE shim accepts enrollment of Joe Users' key then MS transitively verifies enrollment of Joe Users' key. But if Joe User trusts SUSE shim with his key, and MS to verify that SUSE shim Joe User also transitively trusts that MS key. You could enforce some baroque policies that only allow specific keys to be used for verification of specific things but the kernel does not have infrastructure for storing such key purpose information. Until such infrastructure exists key trust is just binary. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1209006] Document how to secureboot-sign manually-built kernel modules on TW kernel >= 6.2.1
by bugzilla_noreply＠suse.com 09 Mar '23

09 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c22 --- Comment #22 from Michal Suchanek <msuchanek(a)suse.com> --- (In reply to Joey Lee from comment #21) > For reference, kernel upstream's plan of .platform and .machine keyrings is > here: > > keyrings, key usage, and trust models > https://lore.kernel.org/all/20220928055900.GT4909@linux-l9pv.suse/t/ > #m3ce7e451f1855d9c432965bb896cb7ce0f89e009 So there are only questions, no answers. It has been pointed out that the scheme proposed by upstream is inconsistent and broken, and there has been no reply. Upstream is not willing to concern itself with distribution kernel needs, and if we want to use MOK we need to patch the kernel downstream so that using MOK is possible. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1209006] Document how to secureboot-sign manually-built kernel modules on TW kernel >= 6.2.1
by bugzilla_noreply＠suse.com 09 Mar '23

09 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c20 --- Comment #20 from Martin Wilck <martin.wilck(a)suse.com> --- (In reply to Michal Suchanek from comment #19) > Or just verify everything with the platform keyring. It's trusted for kernel > verification, anyway. Why that distinction? I agree. As noted above, I fail to understand what additional security upstream's MokListTrustedRT buys us. Repeating my previous question, why would anyone put keys into MoK which they don't trust? And while it's somewhat understandable that some people might not want to trust Microsoft's keys in the db (because of general contempt for Microsoft or what not), doing so doesn't provide any extra security, either. After all the firmware has already been verified by just these keys. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1209006] Document how to secureboot-sign manually-built kernel modules on TW kernel >= 6.2.1
by bugzilla_noreply＠suse.com 09 Mar '23

09 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c19 --- Comment #19 from Michal Suchanek <msuchanek(a)suse.com> --- (In reply to Joey Lee from comment #18) > Hi Martin, > > (In reply to Martin Wilck from comment #16) > > (In reply to Martin Wilck from comment #15) > > > (In reply to Joey Lee from comment #9) > > > > > > Base on v6.2 kernel, keys in .machine keyring still must be trusted(signed) > > > > by key in built-in/secondary keyring. It applies restrict_link_to_ima and > > > > depends on CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY. > > > > > > [...] > > > > > > So keys could be added from the machine keyring to the secondary keyring > > > without being trusted by the secondary keyring beforehand, but such keys > > > could never have been added to the machine keyring in the first place. > > > > > > That looks like an upstream bug to me. > > > > Sorry, no. I was wrong. > > > > https://elixir.bootlin.com/linux/v6.2/source/security/integrity/digsig.c#L1… > > shows that there is no restriction at all for keys in the machine and > > platform key rings. > > > > But now I fail to see why MoK keys don't make it into the secondary > > keyring... > > You are right! I missed the above code when tracing. I have tested .machine > keyring and confirmed that .machine keyring be linked to .secondary keyring > and can be used to verify kernel module. > > First we need run "mokutil --trust-mok" command to request shim to create > MokListTrustedRT for linking .machine keyring to .secondary keying. > > Unfortunately we need shim-15.5 to support MokListTrustedRT, but we only > have Microsoft signed shim-15.4 now. Our shim-15.6 and shim 15.7 is waiting > shim usptream review and Microsoft signing. Or patch this requirement out of the kernel. What's the point anyway? Or just verify everything with the platform keyring. It's trusted for kernel verification, anyway. Why that distinction? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1206224] Dell notebook drains battery during sleep
by bugzilla_noreply＠suse.com 09 Mar '23

09 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1206224 https://bugzilla.suse.com/show_bug.cgi?id=1206224#c44 --- Comment #44 from Michal Svec <msvec(a)suse.com> --- FTR I've been running with 6.1.12-lp154.2.g373f017-default for some time and it seems to work fine. Also 5.14.21-150500.75.ged939b6-default IIRC worked fine. I haven't tried any more recent kernel, though. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1206224] Dell notebook drains battery during sleep
by bugzilla_noreply＠suse.com 09 Mar '23

09 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1206224 https://bugzilla.suse.com/show_bug.cgi?id=1206224#c43 --- Comment #43 from Takashi Iwai <tiwai(a)suse.com> --- (In reply to Jan-Marten Br�ggemann from comment #42) > After the Test of your custom kernel (comment 18) didn't fix the problem, > I've tried this with Leap 15.5 beta, hoping that there will be a newer > kernel. But sadly it is a 15.4 kernel, too. Nevertheless I tried standby > over night and lost 74% charge. Leap 15.5 kernel is not Leap 15.4 kernel. Please make sure that you've tested with the right kernel. At best, check the latest build from OBS Kernel:SLE15-SP5 repo. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1206224] Dell notebook drains battery during sleep
by bugzilla_noreply＠suse.com 09 Mar '23

09 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1206224 https://bugzilla.suse.com/show_bug.cgi?id=1206224#c42 Jan-Marten Br�ggemann <fussel(a)fusselkater.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(msvec(a)suse.com) | --- Comment #42 from Jan-Marten Br�ggemann <fussel(a)fusselkater.org> --- After the Test of your custom kernel (comment 18) didn't fix the problem, I've tried this with Leap 15.5 beta, hoping that there will be a newer kernel. But sadly it is a 15.4 kernel, too. Nevertheless I tried standby over night and lost 74% charge. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208990] intel: UHD630 (Kabylake) support broken?
by bugzilla_noreply＠suse.com 09 Mar '23

09 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208990 http://bugzilla.opensuse.org/show_bug.cgi?id=1208990#c10 --- Comment #10 from Takashi Iwai <tiwai(a)suse.com> --- And you're running X11, not Wayland, right? Just to be sure, can you check whether you can start the fallback (icewm) session (selected at login on display manager) with the same monitor configuration you've seen the problems on the installer? If this works on the installed system while not on the installer, something must be missing in the installer. Judging from hwinfo, nouveau is still used. So that should be same as on installer, at least... -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209006] Document how to secureboot-sign manually-built kernel modules on TW kernel >= 6.2.1
by bugzilla_noreply＠suse.com 09 Mar '23

09 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209006 https://bugzilla.suse.com/show_bug.cgi?id=1209006#c17 --- Comment #17 from Jiri Slaby <jslaby(a)suse.com> --- (In reply to Stefan Dirsch from comment #14) > > But we will need to change the rpm scripts of Nvidia driver again when Eric > > Snowberg's patch set be merged on mainline if we want to follow upstream's > > approach. > > Ok. But I need to know in which way. And I would like to have the time to > prepare this beforehand ... Ok, this is enough. commit 44ca817f15b215421a4c788790dd5351c186d1df (HEAD -> stable, origin/users/jslaby/stable/for-next) Author: Jiri Slaby <jslaby(a)suse.cz> Date: Thu Mar 9 07:01:29 2023 +0100 Disable lockdown. (bsc#1209006) This somehow doesn't play good wrt to external modules. When all is ready again, we can revert this revert. master still have the patchset enabled, we can tune there... -- You are receiving this mail because: You are on the CC list for the bug.

1 0