[Intel-gfx] Fixing the hotplug storm bugs once and for all?
Andrew Lutomirski
luto at mit.edu
Mon Jul 26 20:06:52 CEST 2010
On Mon, Jul 26, 2010 at 1:41 PM, Eric Anholt <eric at anholt.net> wrote:
> On Sun, 25 Jul 2010 15:29:25 -0400, Andrew Lutomirski <luto at mit.edu> wrote:
>> For well over a year now, I (and apparently lots of other people) have
>> had to run patched kernels to avoid crippling hotplug storms.
>>
>> As far as I can tell, on my laptop, enabling DPC_HOTPLUG_INT_EN is
>> safe, but setting either DPB_... or DPD_... (or both) will cause
>> intermittent hotplug interrupt storms. (Turning off all three DP
>> hotplug bits also makes the laptop stable but prevents the DP port
>> from working.)
>>
>> My laptop is a Lenovo X200s with VGA and LVDS on the laptop itself and
>> DP on the docking port. If I boot w/o the docking port, I have:
>>
>>
>> General definitions block:
>> CRT DDC GMBUS addr: 0x02
>> Use ACPI DPMS CRT power states: no
>> Skip CRT detect at boot: no
>> Use DPMS on AIM devices: yes
>> Boot display type: 0x0000
>> TV data block present: yes
>> Child device info:
>> Device type: 1009 (TV)
>> Signature:
>> AIM offset: 0
>> DVO port: 0x05
>> Child device info:
>> Device type: 1022 (LFP)
>> Signature:
>> AIM offset: 52048
>> DVO port: 0x04
>> Child device info:
>> Device type: 68c6 (DisplayPort)
>> Signature:
>> AIM offset: 61152
>> DVO port: 0x08
>>
>> Maybe it's time we started reading that part of VBIOS to detect which
>> outputs really exist. (If that's unsafe, we could add a DMI list.)
>>
>> Any thoughts? It would be nice if 2.6.36 could work without patches.
>
> We had patches to not probe outputs unless they were in child dev tables
> for a while. The issue with reading child dev tables is that some
> BIOSes would give you different child dev results depending on whether
> you were docked or not, so you wouldn't get your DP probed unless you
> booted docked.
>
Do you have a link? I can try to resurrect them.
(Can Xorg handle new outputs appearing and disappearing at runtime?
If not, we could just pretend to create all possible outputs up
front.)
--Andy
More information about the Intel-gfx
mailing list