Bugzilla – Bug 1213693
Black Screen during boot of kernel 6.4.x
Last modified: 2024-06-25 17:51:56 UTC
Hello, I'm running my "MSI GS65 Stealth Thin RE8" notebook since a long time with Tumbleweed. It features a dual graphics card (intel/nvidia). When you rolled out the new kernel 6.4.x, I faced the issue, that during boot, the screen went black and never comes back. But the system itself is up and running (e.g. ssh works fine). Now, with the last update you have removed the 6.3.x kernel from the system, which was still running fine. The only thing I found which brings the graphics to work in a basic mode, is setting kernel argument "acpi=off". But this leads to a 800x600 resolution which makes me crazy. I also tried the current KDE Live CD (x86_64) version and the installation system (x86_64) of Tumbleweed. Both are ending in the same situation. They are only showing a black screen, too. Do you have any ideas where that comes from? Which kind of log files you might need for analysis? Kind regards, Gori
By the way. It's not important for me if the intel or the nvidia graphics card is used. For me its important that graphics is stable and offers full performance (e.g. resolution) for normal desktop work.
At first, try to boot with nomodeset boot option instead of acpi=off. It also disables the native graphics but keeps ACPI so that other functions still work. The old 6.3.x kernel should be still found in TW history repo: http://download.opensuse.org/history/ Download the kernel package, install it with zypper install --oldpackage, and add a lock to the package with zypper addlock. If 6.3.x kernel is not there any longer in history repo, you can take my kernel in OBS home:tiwai:kernel:6.3, too. Note that it's an unofficial build, hence you'd need to turn off Secure Boot for it.
Once after you get the working 6.3.x kernel, please get the output of hwinfo and dmesg after the boot, and attach the outputs to Bugzilla. Then boot again with 6.4.x with the broken graphics, and get the same outputs and attach to Bugzilla for comparison. Or, if 6.3.x kernel shows the same problem, it means that it's no kernel regression but something else broke.
Yes, that is a good idea. I managed to install and lock the old 6.3.9 kernel and did as you proposed. I'll upload the dmesg and hwinfo files here. Kind regards.
Created attachment 868467 [details] dmesg output from kernel 6.3.9
Created attachment 868468 [details] dmesg output from kernel 6.4.4
Created attachment 868469 [details] hwinfo output from kernel 6.3.9
Created attachment 868470 [details] hwinfo output from kernel 6.4.4
Thanks. The 6.4 kernel shows errors like: [ 3.101617] i915 0000:00:02.0: [drm] Cannot find any crtc or sizes and it's likely relevant. I see that you pass some unusual options like pci=nommconf acpi_osi=! "acpi_osi=Windows 2009" Can you try to drop those?
Yes, if I remember correctly, I intruduced these special options to make touch pad and special function keys on the keyboard working. But I have started the system without them and uploaded the resulting hwinfo and dmesg files. Unfortunately, the black screen is still there.
Created attachment 868471 [details] dmesg output from kernel 6.4.4 without special options
Created attachment 868472 [details] hwinfo output from kernel 6.4.4 without special options
Hello, I have an ASUS ROG GU502GV and am experiencing the same issue. DISPLAY Display Size: 15.6" Resolution: FHD (1920 x 1080) Display Features: 144Hz refresh rate VIDEO Integrated Graphics: Intel UHD Graphics 630 Dedicated Graphics: NVIDIA GeForce RTX 2060 I posted on the Forums before digging into this and finding " [drm] Cannot find any crtc or sizes" in the logs https://forums.opensuse.org/t/blank-black-screen-w-kernel-6-4-any-asus-gu502gv/167991/4 I also dug into the Xorg logs and found assumed "modeset(0): Modeline"s, with the most telling being (kernel 6.4) "[ 16.390] (II) modeset(0): Output eDP-1 using initial mode 15360x8640 +0+0" vs a (kernel 6.3) "[ 17.117] (II) modeset(0): Output eDP-1 using initial mode 1920x1080 +0+0" Thank you
Could you guys verify whether the problem persists with the latest 6.5-rc kernel in OBS Kernel:HEAD repo? http://download.opensuse.org/repositories/Kernel:/HEAD/standard/ If the problem still exists with it, we'll need to report or join to the upstream bug tracker. The symptom looks similar as the upstream issue: https://gitlab.freedesktop.org/drm/intel/-/issues/8789 I'm building a test kernel with the revert of the commit (ca62297b2085) suggested there. It's being built in OBS home:tiwai:bsc1213693 repo. Once after the build finishes (takes an hour or so), the package will appear at http://download.opensuse.org/repositories/home:/tiwai:/bsc1213693/standard/ You can test this one later, too. Also, there is another test kernel built from the latest drm-tip branch, available at OBS home:tiwai:kernel:drm-tip. You can try kernel-vanilla.rpm (not kernel-default) from there if the upstream asks for it, too. Note that all those kernels are unofficial builds, hence you'd need to turn off Secure Boot.
I had already tried `6.5.0-rc3-3.g9ba70bb-debug` with the aforementioned result. I know there's an rc-4 coming out but it is not available at this time. That said, I am all too happy to report that `6.4.7-1.gbd97de6-default` (test kernel, OBS home:tiwai:bsc1213693 repo) works and it's what I'm using to make this post.
I have tested both with similar results. I'm still having same issues with kernel-6.5.0-rc3-4.g651715d from http://download.opensuse.org/repositories/Kernel:/HEAD/standard/. But your test kernel-6.4.7-1.gdb97de6 from http://download.opensuse.org/repositories/home:/tiwai:/bsc1213693/standard/ works fine. I'll upload the log files too.
Created attachment 868512 [details] dmesg output from kernel 6.5.0-rc3-4.g651715d
Created attachment 868513 [details] hwinfo output from kernel 6.5.0-rc3-4.g651715d
Created attachment 868514 [details] dmesg output from kernel 6.4.7-1.gdb97de6
Created attachment 868515 [details] hwinfo output from kernel 6.4.7-1.gdb97de6
Thanks for confirmation. As the revert seems to be the only valid workaround as of now, I sent a PR to revert it for TW stable git branch. Please join to the upstream gitlab issues in comment 14, report there that the problem still persists (and the revert still works), and watch out the upstream development.
Yes, I did, thank you very much.
(In reply to Takashi Iwai from comment #21) > Thanks for confirmation. > > As the revert seems to be the only valid workaround as of now, I sent a PR > to revert it for TW stable git branch. > > Please join to the upstream gitlab issues in comment 14, report there that > the problem still persists (and the revert still works), and watch out the > upstream development. Looks like it made into TW stable as I just got `6.4.8-1-default` via `zypper dup` and it works. There has been no activity upstream. Thank you, again
Yes, I can confirm 6.4.8-1-default works for me too.
Update: Quoting Jani Nikula from upstream (https://gitlab.freedesktop.org/drm/intel/-/issues/8789#note_2048122): > Fixed by commit 50b6f2c82977 ("Revert "drm/edid: Fix csync detailed mode parsing"") in drm-misc-next. > It should find its way in v6.5 and v6.4 stable in the next few weeks.
Hi, can this ticket be resolved as fixed?