|
Bugzilla – Full Text Bug Listing |
|
Description
Gerd Richard
2023-07-26 16:29:27 UTC
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? |