With the latest update of the Kernel 5.18.9-2 after the login the Desktop appears after a long time, but I can not do anything the bar does not come out and no command goes
https://bugzilla.opensuse.org/show_bug.cgi?id=1201396
https://bugzilla.suse.com/show_bug.cgi?id=1201392
I’ve tried the suggestions there are but it doesn’t work. So I uninstalled the Kernel 5.18.9-2 and then I blocked the update before that with a new update also the one with a Bug I have two kernels that don’t work !
There is only one workaround atm which works perfectly: add nosimplefb=1 to your kernel command line in grub (press e in your bootloader).
Totally normal function on Intel graphics:
# pinxi -GSaz --vs
pinxi 3.3.19-10 (2022-07-07)
System:
**Kernel: 5.18.9-2-default** arch: x86_64 bits: 64 compiler: gcc v: 12.1.1
parameters: BOOT_IMAGE=/boot/vmlinuz root=LABEL=<filter> noresume
ipv6.disable=1 net.ifnames=0 mitigations=auto consoleblank=0
Desktop: Trinity v: R14.0.12 tk: Qt v: 3.5.0 info: kicker wm: Twin v: 3.0
vt: 7 dm: TDM Distro: openSUSE **Tumbleweed 20220711**
Graphics:
**Device**-1: **Intel Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics**
vendor: ASUSTeK **driver: i915** v: kernel arch: Gen5.75 process: Intel 45nm
built: 2010 ports: active: DP-1,VGA-1 empty: HDMI-A-1,HDMI-A-2,HDMI-A-3
bus-ID: 00:02.0 chip-ID: 8086:0402 class-ID: 0300
**Display**: x11 server: **X.Org v: 21.1.3 driver: X: loaded: modesetting**
unloaded: fbdev,vesa alternate: intel gpu: i915 display-ID: :0 screens: 1
**Screen**-1: 0 s-**res: 4240x1440** s-dpi: 120 s-size: 897x304mm (35.31x11.97")
s-diag: 947mm (37.29")
Monitor-1: DP-1 pos: primary,right model: Acer K272HUL serial: <filter>
built: 2018 res: 2560x1440 hz: 60 dpi: 109 gamma: 1.2
size: 598x336mm (23.54x13.23") diag: 686mm (27") ratio: 16:9 modes:
max: 2560x1440 min: 720x400
Monitor-2: VGA-1 pos: primary,left model: Lenovo L2251x Wide
serial: <filter> built: 2011 res: 1680x1050 hz: 60 dpi: 90 gamma: 1.2
size: 474x296mm (18.66x11.65") diag: 559mm (22") ratio: 16:10 modes:
max: 1680x1050 min: 720x400
**OpenGL: renderer: Mesa Intel HD Graphics (HSW GT1)** v: 4.6 Mesa 22.1.3
direct render: Yes
Yeah, thats why the bug is called “Kernel 5.18.9-2.1 with enabled simpledrm breaks **nvidia driver **(use kernel boot option ‘nosimplefb=1’ as workaround)”
Before your #6 post, following mine, there was nothing in the text of this thread to prevent scaring everyone, regardless of GPU(s) employed, from installing the 5.18.9-2.1 kernel.
I don’t know that one. Are you talking about “Kernel 5.18.9-2.1 with enabled simpledrm breaks nvidia driver if modeset driver isn’t activated (use kernel boot option ‘nosimplefb=1’ as workaround)”?
Everything was already mentioned in comment #2 from Sauerland.
Bug 1201392 - Kernel 5.18.9-2.1 with enabled simpledrm breaks nvidia driver (use kernel boot option ‘nosimplefb=1’ as workaround)
Wrong. Not mentioned in thread text means what it says, entirely within, or on the face of, the thread content. It does not mean opening references.
Also, “breaks NVidia driver” is ambiguous. There are drivers for NVidia GPUs that work fine with TW’s 5.18.9-2 without any workarounds:
# pinxi -GSaz --vs
pinxi 3.3.19-10 (2022-07-07)
System:
**Kernel: 5.18.9-2-default** arch: x86_64 bits: 64 compiler: gcc v: 12.1.1
parameters: root=LABEL=<filter> ipv6.disable=1 net.ifnames=0 noresume
mitigations=auto consoleblank=0
Desktop: KDE Plasma v: 5.25.2 tk: Qt v: 5.15.5 wm: kwin_x11 vt: 7 dm: KDM
Distro: openSUSE **Tumbleweed 20220711**
Graphics:
**Device**-1: **NVIDIA** GT218 [GeForce 210] vendor: eVga.com. **driver: nouveau**
v: kernel non-free: 340.xx status: legacy (EOL, try --gpu) arch: Tesla
process: 40-80nm built: 2006-13 pcie: gen: 1 speed: 2.5 GT/s lanes: 16
ports: active: DVI-I-1,HDMI-A-1 empty: VGA-1 bus-ID: 01:00.0
chip-ID: 10de:0a65 class-ID: 0300
**Display**: x11 server: X.Org v: 21.1.3 compositor: kwin_x11 **driver: X:**
**loaded: modesetting** unloaded: fbdev,vesa alternate: nouveau,nv,nvidia
gpu: nouveau display-ID: :0 screens: 1
Screen-1: 0 s-res: 3840x1200 s-dpi: 120 s-size: 812x254mm (31.97x10.00")
s-diag: 851mm (33.5")
Monitor-1: DVI-I-1 pos: primary,left model: NEC EA243WM serial: <filter>
built: 2011 res: 1920x1200 hz: 60 dpi: 94 gamma: 1.2
size: 519x324mm (20.43x12.76") diag: 612mm (24.1") ratio: 16:10 modes:
max: 1920x1200 min: 640x480
Monitor-2: HDMI-A-1 mapped: HDMI-1 pos: right model: Samsung built: 2009
res: 1920x1080 hz: 60 dpi: 305 gamma: 1.2 size: 160x90mm (6.3x3.54")
diag: 184mm (7.2") ratio: 16:9 modes: max: 1920x1080 min: 720x400
**OpenGL: renderer: NVA8 v: 3.3 Mesa** 22.1.3 direct render: Yes
I prefer not to have Kernel with the bug. With Tumbleweed I always have to be careful, sometimes the kernel is upgraded and the Nvidia driver is not ready for this, and it makes me waste some time.
When starting a thread, too much information is better than too little. Saying my car won’t start is too little information for anyone to help you determine why your car won’t start. Same goes for computer threads that blame a kernel for a black screen without mentioning GPU or driver. OP was fortunate Sauerland is an apparent mindreader, though the thread at that point still wouldn’t be a very good hit in a web search, due to shortage of information. He might have mentioned those bugs’ summaries, so that AMD, Intel and FOSS NVidia users would unlikely waste their time on it, or be scared of upgrading because of it.
If you are not affected by the mentioned bugs, no problem, open a new bugzilla…
I am very sorry and I apologize for not being of any use if I have left out some information, unfortunately I am already trying to do my best using the translator because I have no command of the English language. The post is still here and if someone can make it useful with their skills they can do it, honestly feeling that someone is shooting me as a kid is not the best I can expect … soon I will not open any more posts just looking. Thank you all the same .
Enziosavio, I’m grateful that you started this thread, as Sauerland’s response (with links to the related bugzillas) helped me troubleshoot this problem without opening a thread of my own. So, thank you!
I restored a 7/4 snapshot, locked the 5.18.6 kernel files (and Virtualbox) to prevent pulling in the problematic kernel, and then DUP’d without problems. (I’m using the nvidia driver installed ‘the hard way.’) I wouldn’t have had any idea of what to do without seeing this thread. I’ll remove the locks when a snapshot brings in a later 5.18 kernel.
Ask and when someone means to answer and has also questions to you, he will also ask you…
Thats a normal way.
If my first answer does not help, you should open an bugreport, because Tumbleweed (also kernel:stable) has some problems with new kernel…
You are right, but I am not able to open a Bugreport. Unfortunately the translator is sometimes incomprehensible and what you say in Italian is translated into meaningless sentences
Ok.
I will watch the mailinglist…
But please delete the non working kernel, in kernel:stable, we are on 5.18.11
uname -a
Linux linux64 5.18.11-lp153.3.g834606b-default
In case it’s of use to other users who have installed nvidia “the hard way:” I removed the locks to DUP to snapshot 20220718 and the 5.18.11-1 kernel, and discovered that the kernel parameter nosimplefb=1 is still necessary. Everything works with that parameter, but I boot to a black screen without it.
Just a note to say that new Nvidia drivers have been added to:
https://download.nvidia.com/opensuse/tumbleweed/x86_64/
I installed them and took out ‘nosimplefb=1’ from the boot line but the problem of not starting up is still there.