System Environment: -------------------------- Platform: IVB Mesa: (9.0)7f011e20758b1f4552d56dd40204605f7ae0e3c3 Kernel: (drm-intel-fixes) 974a3b0f9f05b748fe11f1afc31efc32aa5160cb Bug detailed description: ---------------------------- EDID error when machine boot on IVB. Pls see attached about dmesg. It's kernel regression. We found the good commit 172cf15. Out in console ------------------------------------------------- [ 11.979769] Raw EDID: [ 11.979798] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 11.979833] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 11.979854] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 11.979876] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 11.979897] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 11.979919] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 11.979940] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 11.979961] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 11.979985] i915 0000:00:02.0: VGA-1: EDID block 0 invalid. Reproduce steps: ---------------------------- 1, start machine 2, if start X, reproduce the EDID error easily.
Created attachment 67145 [details] dmesg
You say this is a regression - which is the last working commit?
Also please reattach dmesg with drm.debug, so that we have an idea which edid transfer is failing here ...
Created attachment 67262 [details] dmesg with drm.debug
(In reply to comment #2) > You say this is a regression - which is the last working commit? By bisected, the first bad commit is aaa37. commit aaa377302b2994fcc2c66741b47da33feb489dca Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sat Jun 16 15:30:32 2012 +0200 drm/i915/crt: Do not rely upon the HPD presence pin VGA hotplug detection "works" by measuring the resistance across certain pins. A lot of kvm switches fumble this and wire up cheap resistors with the wrong resistance or don't bother at all.
It's not a regression then as the error was always present on this system but masked.
Can you please give us a few more details about the system? First is there anything attached to the VGA? If so, does that monitor + cable work with other machines? Does swapping the cable make any difference?
(In reply to comment #7) EDID error exist on IVB1, but not exist on IVB2. IVB1 only have HDMI. ----------------------------------------------------------------------- IVB1 : Desktop i7-3770K product(id=0x0162, rev 09), Host bridge id=0x0150 (rev 09), 4C/8T, CPU @3.50GHz, GT2 1150MHz,no VT-d, no AMT. IVB2 : Maho Bay IVB E1 stepping (id=0x162, rev 09), Panther Point 04(C1 stepping)(), 4C/8T, CPU @3.4GHz, GT2 1150MHz, VT-d support
So if I understand you correctly, there is no VGA connector on the IVB GT1 machine and this is just a phantom? And definitely no VGA monitor attached?
(In reply to comment #9) > So if I understand you correctly, there is no VGA connector on the IVB GT1 > machine and this is just a phantom? And definitely no VGA monitor attached? Confirmed, there is no VGA connector on the IVB1 machine.
Is the IVB1 machine a production system or some prototype machine? We have a DMI blacklist in the driver for phantom VGA connectors. If your machine is a production system we could add it to the blacklist. Can you attach the output from dmidecode to this bug? I have an IVB machine with a phantom VGA connector as well, but it isn't a production system, so I haven't added it to the blacklist. We generally don't want to bloat the driver with workarounds for any kind of prototype machines. Daniel, I don't suppose opregion or some other BIOS thingy could tell us which connectors are present on the system, so that we wouldn't need the blacklist?
(In reply to comment #11) > Daniel, I don't suppose opregion or some other BIOS thingy could tell us > which connectors are present on the system, so that we wouldn't need the > blacklist? The information used from the VBT is also quirked. The only way to win is not to play and kill all the BIOS authors instead.
Can you also please attach the output of xrandr --verbose from this machine?
Created attachment 70345 [details] xrander --verbose info
Created attachment 70346 [details] dmidecode info
Right, so on your machine the hotplug detection returns false (a fact that was already shown in your original debug log, but I somehow missed it), so it seems that adding the DMI quirk is not really necessary since the connector status is reported as disconnected. So the only real issue is the spurious warning about invalid EDID. I suppose we should try to eliminate that somehow. On my IVB machine the situation is different because the hotlug detection returns true. But since it's not a production machine, I think we can ignore it.
Looks like on current kernels we should only complain about this once unless debugging is enabled, and since we get the detection right on this system I think we can just wontfix this one.
Yeah, phantom connectors are generally WONTFIX. Phantom _detected_ outputs are an entirely different matter, but that seems to not apply.
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.