|
Hi nouveau@xxxxxxxxxxxxxxxxxxxxx
As a follow up on my previous mail, I have noted that my problem is near-identical to https://gitlab.freedesktop.org/drm/intel/-/issues/1922
Issue 1922 was closed because the reporter wrote "sorry, I actually upgraded my system a while ago and I no longer have access to the one with this problem". Thus, the issue was no longer reproducible and was closed.
Now I have a system which reproduces issue 1922.
When I add " drm.debug=0x1ff log_buf_len=100M" as kernel parameters at boot, I get the attached output from dmesg from Fedora 36. I cannot attach the corresponding output from Fedora 34 because of the size limitations of the present mailing list. The interesting lines of dmesg-drm-stdout-34 read:
[ 2.402685] [drm:drm_mode_debug_printmodeline [drm]] Modeline "3840x2160": 60 533250 3840 3888 3920 4000 2160 2163 2168 2222 0x48 0x9
[ 2.402703] [drm:drm_mode_prune_invalid [drm]] Not using 3840x2160 mode: CLOCK_HIGH The interesting lines of dmesg-drm-stdout-36 read:
[ 2.926857] [drm:drm_mode_debug_printmodeline] Modeline "3840x2160": 60 533250 3840 3888 3920 4000 2160 2163 2168 2222 0x48 0x9
The difference between Fedora 34 and 36 is that under Fedora 34 I can enforce
3840x2160 using a suitable /etc/X11/xorg.conf.d/90-monitor.conf. That does not work under Fedora 36 where the monitor goes blank and then turns off instead of showing a login screen.[ 2.926861] [drm:drm_mode_prune_invalid] Not using 3840x2160 mode: CLOCK_HIGH By the way, I have compared the pixel clock, horizontal clock and vertical clock to the maxima defined in the EDID, and I cannot spot any clock which is too high.
Question is: What should I do now? Should I open a new issue and link to issue 1922?
Cheers,
Klaus
|
Attachment:
dmesg-drm-stdout-36
Description: dmesg-drm-stdout-36
