Red Hat Bugzilla – Bug 587171
Intel kms leads to an all black display
Last modified: 2010-05-10 12:43:00 EDT
Created attachment 410040 [details]
As mentioned in bug 584229, with recent F-13 installs (from
fedora/development/13/x86_64/os), my monitor goes black and stays black
(no signal lost or mode out of range messages) as soon as kms gets
I've attached Xorg.log, dmesg and the output of intel_reg_snapshot. I've also tried with the 126.96.36.199-68.fc13 and 188.8.131.52-71.fc13 kernels to no avail.
You were right this is a different bug as bug 584229, as the xorg log clearly
shows that the dcc information is being read correctly.
Created attachment 410041 [details]
Created attachment 410042 [details]
Proposing this as an F13Blocker as the system is completely unusable without this fixed.
One maybe important note, this system has a single DVI (or hdmi, can't remember and I cannot easily reach the back of the machine) VDSO card, but the monitor is connected to the vga connector (because of kvm usage) Note the kvm so far
has never caused issues and as shown it does pass through DCC. This problem happens when leaving the kvm set to display the output of the troublesome screen the entire time during boot.
Also from the Xorg log note:
[ 324.307] (II) intel(0): Printing DDC gathered Modelines:
[ 324.307] (II) intel(0): Modeline "1920x1200"x0.0 154.00 1920 1968 2000 20
[ 324.307] (II) intel(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 6
[ 324.307] (II) intel(0): Modeline "640x480"x0.0 31.50 640 656 720 840 48
[ 324.307] (II) intel(0): Modeline "640x480"x0.0 25.18 640 656 752 800 48
[ 324.307] (II) intel(0): Modeline "720x400"x0.0 28.32 720 738 846 900 40
[ 324.308] (II) intel(0): Printing probed modes for output VGA1
[ 324.308] (II) intel(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 13
[ 324.308] (II) intel(0): Modeline "800x600"x60.3 40.00 800 840 968 1056
[ 324.308] (II) intel(0): Modeline "800x600"x56.2 36.00 800 824 896 1024
[ 324.308] (II) intel(0): Modeline "848x480"x60.0 33.75 848 864 976 1088
[ 324.308] (II) intel(0): Modeline "640x480"x59.9 25.18 640 656 752 800 4
This is caused by the kvm being switched away at the time Xorg started
(I had to do a telinit 5 to start Xorg, as I installed using vnc because of
this issue the default runlevel is 3).
If this is a problem and you want a new xorg.log / register dump, with the kvm pointing to the monitor while starting X let me know. Note that this does not
make any difference for the black screen problem.
I'm pretty dang sure this will be resolved by the second patch for bug #584229:
or later. It looks like the same symptoms the other way around; you have an analog monitor connection, but we're trying the "DVI" connector first, the DDC pins are shared so we think it's connected but then don't look at the analog/digital bit in EDID to be sure.
Whether that counts as "same bug" or not... meh. Anyway, try -78 or later.
Could this be related to bug 586235 which also is about Intel KMS producing
black screen due to "Out of Range Scan" (but there is no DVI/HDMI involved)?
-79 has been submitted for f13 and we're likely to take it, so please do test that, hans:
I see what I believe is the same problem, Fedora 13 Beta install (kernel-184.108.40.206-24.fc13.x86_64) worked OK, but VGA output was blank after I updated (kernel-220.127.116.11-57.fc13.x86_64).
kernel-18.104.22.168-79.fc13.x86_64 does NOT appear to resolve this (unless I need to do something in addition to just installing and booting this kernel to fix it?)
I will attach Xorg.0.log and dmesg, but I don't know where to get output of "intel_reg_snapshot".
This is on a Dell Vostro 230 which has integrated Intel VGA controller with no (physical) DVI output/connector.
Created attachment 411448 [details]
Created attachment 411449 [details]
it's not necessarily the same bug...also, can you check you have the very latest xorg-x11-server (-12) and xorg-x11-drv-intel (-4)? thanks.
(In reply to comment #10)
> it's not necessarily the same bug...also, can you check you have the very
> latest xorg-x11-server (-12) and xorg-x11-drv-intel (-4)? thanks.
I don't have the latest of these installed (yet, will re-test with them shortly, when downloaded):
$ rpm -q xorg-x11-server-common xorg-x11-drv-intel
but this issue arises from the moment the kernel starts, way before Xorg gets involved (afaik).
I've confirmed the behavior is the same with latest packages in updates-testing:
$ rpm -q xorg-x11-server-common xorg-x11-drv-intel
I tried with kernel-PAE-22.214.171.124-82.fc13.i686.rpm, and it does not fix this for me.
To generate the register snapshot you need to do:
intel_reg_snapshot > reg-snapshot
You can do this over ssh after letting the machine startup normally with the black screen.
To get intel_reg_snapshot do:
yum install intel-gpu-tools
Hans and Stu, can you attach dmesg from booting with "drm.debug=0x06" on -82, and the rom file from doing:
# dd if=/dev/mem of=/tmp/rom bs=64k skip=12 count=1
Created attachment 411639 [details]
dmesg with drm.debug=0x06
Created attachment 411640 [details]
Also, register dump and drm.debug=0x06 from the working kernel would be helpful.
To be clear, i suspect that kernels 126.96.36.199-49 and earlier will work.
(In reply to comment #17)
> Also, register dump and drm.debug=0x06 from the working kernel would be
Ok, I'm attaching those, and also a new dmesg and dump from 188.8.131.52-82, this time
I made sure to leave my kvm pointing to the machine in question during the entire machine startup (so also when Xorg was started). I did the same for the 184.108.40.206-49 dumps of course. This way I hope to ensure you'll be comparing apples to apples (the last logs I switched the kvm away from the machine after the screen went black, iow at the moment kms had initialized the gpu, so when Xorg started the kvm was pointing elsewhere).
Created attachment 411672 [details]
dmesg from working kernel
Created attachment 411673 [details]
dmesg from non working kernel
Created attachment 411674 [details]
register snapshot from working kernel
Created attachment 411675 [details]
register snapshot from non working kernel
A little more delayed than I hoped, but I'm going to attach the following for both kernel 220.127.116.11-24 (where VGA output works) and 18.104.22.168-82 (where VGA output is blank):
- dmesg (with "drm.debug=0x06" on kernel command line)
- rom (as requested in comment #14)
- intel_gpu_dump (I couldn't find intel_reg_snapshot, so I guess this will do?)
Created attachment 411779 [details]
(stu) dmesg from working 22.214.171.124-24
Created attachment 411780 [details]
(stu) Xorg.0.log from working 126.96.36.199-24
Created attachment 411781 [details]
(stu) rom from working 188.8.131.52-24
Created attachment 411782 [details]
(stu) intel_gpu_dump from working 184.108.40.206-24
Created attachment 411783 [details]
(stu) dmesg from failing 220.127.116.11-82
Created attachment 411784 [details]
(stu) Xorg.0.log from failing 18.104.22.168-82
Created attachment 411785 [details]
(stu) rom from failing 22.214.171.124-82
Created attachment 411786 [details]
(stu) intel_gpu_dump from failing 126.96.36.199-82
If either of you could test
intel_gpu_dump is not the same thing as intel_reg_snapshot. Both should be present in intel-gpu-tools 2.11.0-4 and later.
Created attachment 412087 [details]
(stu) register snapshot from working 188.8.131.52-24
Created attachment 412088 [details]
(stu) register snapshot from failing 184.108.40.206-82
(In reply to comment #33)
> If either of you could test
> that'd help.
That appears to do the trick for me (IOW with that kernel I once again have a working display).
great. stu reported the same. kernel -85 is in koji, but hasn't been submitted as an update. can you please submit it as an update so we can get the rcs in? thanks!
Fedora Bugzappers volunteer triage team
kernel-220.127.116.11-85.fc13 has been submitted as an update for Fedora 13.
kernel-18.104.22.168-85.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 588275 has been marked as a duplicate of this bug. ***
*** Bug 589907 has been marked as a duplicate of this bug. ***
*** Bug 589304 has been marked as a duplicate of this bug. ***