| 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> |
| Severity: | blocker | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | |||
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. (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? 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. As I observed already on IRC, the link training errors in dmesg are surprisingly similar to the ones in bug 64332. 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. Created attachment 79768 [details]
dmesg output (nightly build, 3.9.0-rc5+)
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. (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. Created attachment 80417 [details]
intel_reg_dump output
Thanks Imre; attached! I also tried the newest nightly build, no change. (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. Created attachment 80427 [details]
dmesg output (nightly build, 3.10.0-rc2+)
dmesg immediately after boot; no X, no reg dump.
Created attachment 80428 [details]
dmesg output (nightly build, 3.10.0-rc2+) (POST)
dmesg output immediately after testdisplay script
Created attachment 80429 [details]
intel_reg_dump output (phase2)
intel_reg_dump after clean boot, no test, no X
Created attachment 80430 [details]
intel_reg_dump output (phase2) (WHILE TESTING)
reg dump DURING the testdisplay script
Created attachment 80431 [details]
intel_reg_dump output (phase2) (POST)
reg dump AFTER running testdisplay
Created attachment 80432 [details]
Failed Xorg.0.log
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):[0] 1920x1200 60 1920 1964 1968 2080 1200 1209 1210 1234 0xa 0x8 154000 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. 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.
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. Tha patch worked! Thanks Imre! Please, mark this bug as closed. Fix merged to -fixes with cc: stable as commit 2e6efddd203c15ca5c4700511f717c0e9a3ea31a Author: Imre Deak <imre.deak@intel.com> Date: Fri Aug 23 23:50:23 2013 +0300 drm/i915: ivb: fix edp voltage swing reg val |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 79683 [details] dmesg output CHIP: IvyBridge GPU (8086:0166) KERNEL: 3.6.9.1 (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: 3.6.9.1 (vanilla) -- Linux distribution: Ubuntu 12.04 -- Machine or mobo model: Panasonic (prototype) -- Display connector: eDP-1