|Summary:||[IVB cpu eDP] KMS Black Screen (link training)|
|Product:||DRI||Reporter:||Jeremy Moles <cubicool>|
|Component:||DRM/Intel||Assignee:||Intel GFX Bugs mailing list <intel-gfx-bugs>|
|Status:||CLOSED FIXED||QA Contact:||Intel GFX Bugs mailing list <intel-gfx-bugs>|
|i915 platform:||i915 features:|
Description Jeremy Moles 2013-05-22 20:55:31 UTC
Created attachment 79683 [details] dmesg output CHIP: IvyBridge GPU (8086:0166) KERNEL: 126.96.36.199 (vanilla) DISTRO: Ubuntu 12.04 Bug description: As the machine boots, as soon as KMS throbs the card, the screen goes entirely black (though brightness still functions) and does not recover. The system is not locked up, and can be SSH'd into, etc. Discussing this in IRC the phrase "link training" was used, though I do not exactly know what indicated such a problem or what the phrase means. Booting with 'nomodeset i915.modeset=0' lets me use the vesa X driver, and I get functional (though non-native) virtual consoles. NOTE: I cannot include any of the register dumps, as I get the following error: ntel_reg_dumpe:3065 conflicting memory types f7800000-f7c00000 uncached-minus<->write-combining reserve_memtype failed [mem 0xf7800000-0xf7bfffff], track uncached-minus, req uncached-minus System environment: -- chipset: IvyBridge (8086:0166) -- system architecture: 64bit -- kernel: 188.8.131.52 (vanilla) -- Linux distribution: Ubuntu 12.04 -- Machine or mobo model: Panasonic (prototype) -- Display connector: eDP-1
Comment 1 Imre Deak 2013-05-22 21:45:10 UTC
The dmesg shows 3.9.1-emp1 kernel version, so I assume it's 3.9.1. Could you confirm that you were running commit c554f06fc801004f3fc3b162c490d8fdf4e79725? If not then please provide a git url for your kernel.
Comment 2 Imre Deak 2013-05-22 21:47:42 UTC
(In reply to comment #1) > The dmesg shows 3.9.1-emp1 kernel version, so I assume it's 3.9.1. Could you > confirm that you were running commit > c554f06fc801004f3fc3b162c490d8fdf4e79725? If not then please provide a git > url for your kernel. Also could you try the git://people.freedesktop.org/~danvet/drm-intel drm-intel-nightly branch?
Comment 3 Jeremy Moles 2013-05-22 21:52:38 UTC
I'm sorry, I added a 6 in my bug report; it is indeed 3.9.1. I have a slew of vanilla builds from 3.5 - 3.9, all of which have the same behavior. It's a standard, vanilla kernel with no special patches. I will try the nightly branch now.
Comment 4 Jani Nikula 2013-05-23 07:36:22 UTC
As I observed already on IRC, the link training errors in dmesg are surprisingly similar to the ones in bug 64332.
Comment 5 Jani Nikula 2013-05-23 07:43:47 UTC
Also, what happens without "acpi_osi=!Windows 2012"? Usually I like to see the timestamps in the dmesg. Please add printk.time=1 module parameter or change the relevant config option.
Comment 6 Jeremy Moles 2013-05-24 13:50:03 UTC
Created attachment 79768 [details] dmesg output (nightly build, 3.9.0-rc5+)
Comment 7 Jeremy Moles 2013-05-24 13:50:13 UTC
Hello everyone, and thanks for the responses. I have built the kernel using the nightly branch as requested. It exhibits the same issue, and I am attaching the dmesg (with timestamps). Further, there is no difference with or without acpi_osi being befined.
Comment 8 Imre Deak 2013-06-06 12:48:43 UTC
(In reply to comment #7) > Hello everyone, and thanks for the responses. I have built the kernel using > the nightly branch as requested. It exhibits the same issue, and I am > attaching the dmesg (with timestamps). Further, there is no difference with > or without acpi_osi being befined. Now that intel_reg_dumper works (based on IRC feedback), could you attach the register dump? And perhaps also try the latest -nightly kernel.
Comment 9 Jeremy Moles 2013-06-06 14:50:58 UTC
Created attachment 80417 [details] intel_reg_dump output
Comment 10 Jeremy Moles 2013-06-06 14:51:28 UTC
Thanks Imre; attached! I also tried the newest nightly build, no change.
Comment 11 Imre Deak 2013-06-06 18:17:37 UTC
(In reply to comment #10) > Thanks Imre; attached! > > I also tried the newest nightly build, no change. Can't see yet the problem :/ There are two non-fatal issues in dmesg: - Corrupt EDID. This isn't fatal as the driver picks the mode from VBT instead, I assume it's the correct one: "1920x1200" 0 154000 1920 1964 1968 2080 1200 1209 1210 1234 0x8 0xa - Link training CR failure. This isn't fatal either, since we still do channel EQ, which succeeds. From the reg dump the display seems to be off, so I wonder if X is running at all, or if the screen is just blanked. We'd need Xorg.0.log for more details. Could you run 'sudo tests/testdisplay -s 20 > /tmp/out 2>&1' from igt? It should enable the screen and show some test pattern for 20 secs. You first need to stop X if it's running, or VT switch away from it. Then while the test is running, please take a dmesg and an intel_reg_dumper snapshot from a remote terminal and attach these with the xorg.0.log and /tmp/out.
Comment 12 Jeremy Moles 2013-06-06 19:06:56 UTC
Created attachment 80427 [details] dmesg output (nightly build, 3.10.0-rc2+) dmesg immediately after boot; no X, no reg dump.
Comment 13 Jeremy Moles 2013-06-06 19:07:53 UTC
Created attachment 80428 [details] dmesg output (nightly build, 3.10.0-rc2+) (POST) dmesg output immediately after testdisplay script
Comment 14 Jeremy Moles 2013-06-06 19:08:53 UTC
Created attachment 80429 [details] intel_reg_dump output (phase2) intel_reg_dump after clean boot, no test, no X
Comment 15 Jeremy Moles 2013-06-06 19:09:40 UTC
Created attachment 80430 [details] intel_reg_dump output (phase2) (WHILE TESTING) reg dump DURING the testdisplay script
Comment 16 Jeremy Moles 2013-06-06 19:10:18 UTC
Created attachment 80431 [details] intel_reg_dump output (phase2) (POST) reg dump AFTER running testdisplay
Comment 17 Jeremy Moles 2013-06-06 19:11:07 UTC
Created attachment 80432 [details] Failed Xorg.0.log
Comment 18 Jeremy Moles 2013-06-06 19:13:36 UTC
I disabled all services that start X and booted into a clean system. I ran dmesg and reg_dump and attached their outputs. I then ran testdisplay -s 20 and captured the output of reg_dump. Finally, I ran dmesg again and did one final reg_dump. There is also a Xorg.0.log attached, though I don't know how useful it will be. The only output from testdisplay was: CRTS(3): 1920x1200 60 1920 1964 1968 2080 1200 1209 1210 1234 0xa 0x8 154000
Comment 19 Imre Deak 2013-08-01 13:19:18 UTC
I haven't found any obvious problems in the reg dumps :( Could you get a reg dump with a working display output? Best would be to prevent the i915 from loading by adding an invalid module parameter to the kernel command line (for example i915.foobar=1) and take the reg dump from the vga console. Thanks.
Comment 20 Jeremy Moles 2013-08-14 17:36:49 UTC
Created attachment 84070 [details] intel_reg_dump output (nomodeset, VESA Xorg) This is the output of intel_reg_dump while booted with KMS disabled, and using VESA/Xorg in the background.
Comment 21 Imre Deak 2013-08-23 14:19:59 UTC
Created attachment 84519 [details] [review] fix ivb dp volatge swing hw encoding (In reply to comment #20) > Created attachment 84070 [details] > intel_reg_dump output (nomodeset, VESA Xorg) > > This is the output of intel_reg_dump while booted with KMS disabled, and > using VESA/Xorg in the background. Thanks. I noticed one bug that might affect you, could you try the attached fix? Another thing is that in the working case we are using a non-SSC clock source while in the failing case we use an SSC one. So could you try booting with i915.lvds_use_ssc=0? Another difference is that the working case is with 1024x768, so would be useful to see a regdump also with 1024x768 modesetting.
Comment 22 Jeremy Moles 2013-08-23 20:53:50 UTC
Tha patch worked! Thanks Imre! Please, mark this bug as closed.