Bug 587171 - Intel kms leads to an all black display
Summary: Intel kms leads to an all black display
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 588275 589304 589907 (view as bug list)
Depends On:
Blocks: F13Blocker, F13FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2010-04-29 09:09 UTC by Hans de Goede
Modified: 2010-05-10 16:43 UTC (History)
15 users (show)

Fixed In Version: kernel-2.6.33.3-85.fc13
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-05-07 05:46:24 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
xorg.log (38.94 KB, text/plain)
2010-04-29 09:09 UTC, Hans de Goede
no flags Details
dmesg (42.74 KB, text/plain)
2010-04-29 09:10 UTC, Hans de Goede
no flags Details
register snapshot (4.00 MB, application/octet-stream)
2010-04-29 09:11 UTC, Hans de Goede
no flags Details
Xorg.0.log (37.76 KB, text/x-log)
2010-05-05 01:00 UTC, Stu Tomlinson
no flags Details
dmesg (36.34 KB, application/octet-stream)
2010-05-05 01:01 UTC, Stu Tomlinson
no flags Details
dmesg with drm.debug=0x06 (71.49 KB, text/plain)
2010-05-05 14:53 UTC, Hans de Goede
no flags Details
rom dump (64.00 KB, application/octet-stream)
2010-05-05 14:54 UTC, Hans de Goede
no flags Details
dmesg from working kernel (70.98 KB, text/plain)
2010-05-05 16:44 UTC, Hans de Goede
no flags Details
dmesg from non working kernel (70.14 KB, text/plain)
2010-05-05 16:45 UTC, Hans de Goede
no flags Details
register snapshot from working kernel (4.00 MB, application/octet-stream)
2010-05-05 16:47 UTC, Hans de Goede
no flags Details
register snapshot from non working kernel (4.00 MB, application/octet-stream)
2010-05-05 16:48 UTC, Hans de Goede
no flags Details
(stu) dmesg from working 2.6.33.1-24 (63.10 KB, application/octet-stream)
2010-05-06 02:01 UTC, Stu Tomlinson
no flags Details
(stu) Xorg.0.log from working 2.6.33.1-24 (37.78 KB, application/octet-stream)
2010-05-06 02:02 UTC, Stu Tomlinson
no flags Details
(stu) rom from working 2.6.33.1-24 (64.00 KB, application/octet-stream)
2010-05-06 02:02 UTC, Stu Tomlinson
no flags Details
(stu) intel_gpu_dump from working 2.6.33.1-24 (82.53 KB, application/x-gzip)
2010-05-06 02:03 UTC, Stu Tomlinson
no flags Details
(stu) dmesg from failing 2.6.33.3-82 (60.99 KB, application/octet-stream)
2010-05-06 02:04 UTC, Stu Tomlinson
no flags Details
(stu) Xorg.0.log from failing 2.6.33.3-82 (37.78 KB, application/octet-stream)
2010-05-06 02:04 UTC, Stu Tomlinson
no flags Details
(stu) rom from failing 2.6.33.3-82 (64.00 KB, application/octet-stream)
2010-05-06 02:05 UTC, Stu Tomlinson
no flags Details
(stu) intel_gpu_dump from failing 2.6.33.3-82 (82.01 KB, application/x-gzip)
2010-05-06 02:05 UTC, Stu Tomlinson
no flags Details
(stu) register snapshot from working 2.6.33.1-24 (34.27 KB, application/x-gzip)
2010-05-06 15:12 UTC, Stu Tomlinson
no flags Details
(stu) register snapshot from failing 2.6.33.3-82 (30.91 KB, application/x-gzip)
2010-05-06 15:12 UTC, Stu Tomlinson
no flags Details

Description Hans de Goede 2010-04-29 09:09:56 UTC
Created attachment 410040 [details]
xorg.log

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
activated.

I've attached Xorg.log, dmesg and the output of intel_reg_snapshot. I've also tried with the 2.6.33.2-68.fc13 and 2.6.33.3-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.

Comment 1 Hans de Goede 2010-04-29 09:10:20 UTC
Created attachment 410041 [details]
dmesg

Comment 2 Hans de Goede 2010-04-29 09:11:40 UTC
Created attachment 410042 [details]
register snapshot

Comment 3 Hans de Goede 2010-04-29 09:26:55 UTC
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
<snip>

[   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
<snip>

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.

Comment 4 Adam Jackson 2010-05-04 20:32:10 UTC
I'm pretty dang sure this will be resolved by the second patch for bug #584229:

http://kojipkgs.fedoraproject.org/packages/kernel/2.6.33.3/78.fc13/

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.

Comment 5 Marko Myllynen 2010-05-04 20:37:43 UTC
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)?

https://bugzilla.redhat.com/show_bug.cgi?id=586235

Comment 6 Adam Williamson 2010-05-04 21:59:20 UTC
-79 has been submitted for f13 and we're likely to take it, so please do test that, hans:

https://admin.fedoraproject.org/updates/kernel-2.6.33.3-79.fc13

thanks.

Comment 7 Stu Tomlinson 2010-05-05 00:59:37 UTC
I see what I believe is the same problem, Fedora 13 Beta install (kernel-2.6.33.1-24.fc13.x86_64) worked OK, but VGA output was blank after I updated (kernel-2.6.33.2-57.fc13.x86_64).

kernel-2.6.33.3-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.

Comment 8 Stu Tomlinson 2010-05-05 01:00:06 UTC
Created attachment 411448 [details]
Xorg.0.log

Comment 9 Stu Tomlinson 2010-05-05 01:01:21 UTC
Created attachment 411449 [details]
dmesg

Comment 10 Adam Williamson 2010-05-05 01:09:04 UTC
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.

Comment 11 Stu Tomlinson 2010-05-05 01:22:55 UTC
(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
xorg-x11-server-common-1.8.0-8.fc13.x86_64
xorg-x11-drv-intel-2.11.0-2.fc13.x86_64

but this issue arises from the moment the kernel starts, way before Xorg gets involved (afaik).

Comment 12 Stu Tomlinson 2010-05-05 01:27:58 UTC
I've confirmed the behavior is the same with latest packages in updates-testing:

$ rpm -q xorg-x11-server-common xorg-x11-drv-intel
xorg-x11-server-common-1.8.0-12.fc13.x86_64
xorg-x11-drv-intel-2.11.0-3.fc13.x86_64

Comment 13 Hans de Goede 2010-05-05 06:08:02 UTC
ajax,

I tried with kernel-PAE-2.6.33.3-82.fc13.i686.rpm, and it does not fix this for me.

Stu,

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

Regards,

Hans

Comment 14 Adam Jackson 2010-05-05 13:41:02 UTC
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

Comment 15 Hans de Goede 2010-05-05 14:53:31 UTC
Created attachment 411639 [details]
dmesg with drm.debug=0x06

Comment 16 Hans de Goede 2010-05-05 14:54:26 UTC
Created attachment 411640 [details]
rom dump

Comment 17 Adam Jackson 2010-05-05 15:43:24 UTC
Also, register dump and drm.debug=0x06 from the working kernel would be helpful.

Comment 18 Adam Jackson 2010-05-05 15:57:46 UTC
To be clear, i suspect that kernels 2.6.33.2-49 and earlier will work.

Comment 19 Hans de Goede 2010-05-05 16:43:57 UTC
(In reply to comment #17)
> Also, register dump and drm.debug=0x06 from the working kernel would be
> helpful.    

Ok, I'm attaching those, and also a new dmesg and dump from 2.6.33.3-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 2.6.33.2-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).

Comment 20 Hans de Goede 2010-05-05 16:44:51 UTC
Created attachment 411672 [details]
dmesg from working kernel

Comment 21 Hans de Goede 2010-05-05 16:45:15 UTC
Created attachment 411673 [details]
dmesg from non working kernel

Comment 22 Hans de Goede 2010-05-05 16:47:14 UTC
Created attachment 411674 [details]
register snapshot from working kernel

Comment 23 Hans de Goede 2010-05-05 16:48:49 UTC
Created attachment 411675 [details]
register snapshot from non working kernel

Comment 24 Stu Tomlinson 2010-05-06 01:59:36 UTC
A little more delayed than I hoped, but I'm going to attach the following for both kernel 2.6.33.1-24 (where VGA output works) and 2.6.33.3-82 (where VGA output is blank):

 - dmesg (with "drm.debug=0x06" on kernel command line)
 - Xorg.0.log
 - rom (as requested in comment #14)
 - intel_gpu_dump (I couldn't find intel_reg_snapshot, so I guess this will do?)

Comment 25 Stu Tomlinson 2010-05-06 02:01:17 UTC
Created attachment 411779 [details]
(stu) dmesg from working 2.6.33.1-24

Comment 26 Stu Tomlinson 2010-05-06 02:02:01 UTC
Created attachment 411780 [details]
(stu) Xorg.0.log from working 2.6.33.1-24

Comment 27 Stu Tomlinson 2010-05-06 02:02:33 UTC
Created attachment 411781 [details]
(stu) rom from working 2.6.33.1-24

Comment 28 Stu Tomlinson 2010-05-06 02:03:33 UTC
Created attachment 411782 [details]
(stu) intel_gpu_dump from working 2.6.33.1-24

Comment 29 Stu Tomlinson 2010-05-06 02:04:18 UTC
Created attachment 411783 [details]
(stu) dmesg from failing 2.6.33.3-82

Comment 30 Stu Tomlinson 2010-05-06 02:04:49 UTC
Created attachment 411784 [details]
(stu) Xorg.0.log from failing 2.6.33.3-82

Comment 31 Stu Tomlinson 2010-05-06 02:05:20 UTC
Created attachment 411785 [details]
(stu) rom from failing 2.6.33.3-82

Comment 32 Stu Tomlinson 2010-05-06 02:05:49 UTC
Created attachment 411786 [details]
(stu) intel_gpu_dump from failing 2.6.33.3-82

Comment 33 Adam Jackson 2010-05-06 14:58:01 UTC
If either of you could test

http://kojipkgs.fedoraproject.org/scratch/ajax/task_2165567/

that'd help.

Comment 34 Adam Jackson 2010-05-06 14:59:12 UTC
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.

Comment 35 Stu Tomlinson 2010-05-06 15:12:14 UTC
Created attachment 412087 [details]
(stu) register snapshot from working 2.6.33.1-24

Comment 36 Stu Tomlinson 2010-05-06 15:12:52 UTC
Created attachment 412088 [details]
(stu) register snapshot from failing 2.6.33.3-82

Comment 37 Hans de Goede 2010-05-06 15:23:40 UTC
(In reply to comment #33)
> If either of you could test
> 
> http://kojipkgs.fedoraproject.org/scratch/ajax/task_2165567/
> 
> that'd help.    

That appears to do the trick for me (IOW with that kernel I once again have a working display).

Comment 38 Adam Williamson 2010-05-06 20:33:09 UTC
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
https://fedoraproject.org/wiki/BugZappers

Comment 39 Fedora Update System 2010-05-06 21:09:46 UTC
kernel-2.6.33.3-85.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/kernel-2.6.33.3-85.fc13

Comment 40 Fedora Update System 2010-05-07 05:46:20 UTC
kernel-2.6.33.3-85.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 41 Sven Lankes 2010-05-07 09:36:45 UTC
*** Bug 588275 has been marked as a duplicate of this bug. ***

Comment 42 Jonathan Dieter 2010-05-07 12:24:43 UTC
*** Bug 589907 has been marked as a duplicate of this bug. ***

Comment 43 H.J. Lu 2010-05-10 16:43:00 UTC
*** Bug 589304 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.