Fixing the hotplug storm bugs once and for all?

Fixing the hotplug storm bugs once and for all?

[Andrew Lutomirski]

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.

Thanks,
Andy

Re: Fixing the hotplug storm bugs once and for all?

[Eric Anholt]

[-- Attachment #1.1: Type: text/plain, Size: 2258 bytes --]

On Sun, 25 Jul 2010 15:29:25 -0400, Andrew Lutomirski <luto@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.

Now, I'm sure there's a way to detect dock events, and if we then
reprobed and reconfigured hotplug and output->detect() probing based on
child devs, we should get no hotplug storms, reduced boot time, and
lower power consumption.  Everyone would be happy, right?

[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Fixing the hotplug storm bugs once and for all?

[Andrew Lutomirski]

On Mon, Jul 26, 2010 at 1:41 PM, Eric Anholt <eric@anholt.net> wrote:
> On Sun, 25 Jul 2010 15:29:25 -0400, Andrew Lutomirski <luto@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

Re: Fixing the hotplug storm bugs once and for all?

[Eric Anholt]

[-- Attachment #1.1: Type: text/plain, Size: 3676 bytes --]

On Mon, 26 Jul 2010 14:06:52 -0400, Andrew Lutomirski <luto@mit.edu> wrote:
> On Mon, Jul 26, 2010 at 1:41 PM, Eric Anholt <eric@anholt.net> wrote:
> > On Sun, 25 Jul 2010 15:29:25 -0400, Andrew Lutomirski <luto@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.)

Yeah, I was figuring set up all outputs, and just always report
disconnected unless it's in the child dev tables.  We can worry about
making a pretty output list later after things *work*.

commit 6207937d4feea000913e8ca23fe20c7744be7847
Author: Zhao Yakui <yakui.zhao@intel.com>
Date:   Wed Jan 6 09:49:31 2010 +0800

    drm/i915: Don't use the child device parsed from VBT to setup HDMI/DP
    
    On some boxes the BIOS will report different child device arrays when
    the system is booted with/without the dock. In such case the HDMI/DP
    port can't be setup correctly.  So revert two commits
    (fc816655236cd9da162356e96e74c7cfb0834d92/
    6e36595a2131e7ed5ee2674be54b2713ba7f0490) that use the child device
    parsed from VBT to setup HDMI/DP.
    
    http://bugzilla.kernel.org/show_bug.cgi?id=14854
    http://bugzilla.kernel.org/show_bug.cgi?id=14860
    
    Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
    Tested-by: Sean Young <sean@mess.org>
    Signed-off-by: Eric Anholt <eric@anholt.net>

[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx