[Intel-gfx] i915: severe lag after resume (was Re: i915: hotplug events gone wild)

[Andrew Lutomirski]

On Wed, Feb 10, 2010 at 5:21 PM, Eric Anholt <eric at anholt.net> wrote:
> On Wed, 10 Feb 2010 09:15:19 -0500, Andrew Lutomirski <luto at mit.edu> wrote:
>> I did some digging with gdb and perf.  Here's what's happening:
>>
>> 1. Something causes i915 to detect and report a flood of bogus hotplug events.
>> 2. Fedora has a patched version of the "intel" driver that detects
>> uevents and calls RRGetInfo.
>> 3. RRGetInfo eventually issues a bunch of GETCONNECTOR calls.
>> 4. i915 reprobes an input on each GETCONNECTOR call, and the LVDS
>> probe is slow.  X is blocked while this is happening, and it's slow
>> enough and frequent enough that it makes X unusable.
>>
>> I think that there are a few "bugs" here:
>>
>> First, the root cause: why are we detecting a flood of hotplug events?
>>  They seem to come from HDMI or SDVO, none of which I have.  I don't
>> really understand the connector initialization code -- SDVO and HDMI
>> seem to share some hardware (sometimes, maybe), and they share a bunch
>> of hotplug bits, yet I detect:
>>
>> ard0-DisplayPort-1
>> card0-DisplayPort-2
>> card0-DisplayPort-3
>> card0-HDMI Type A-1
>> card0-HDMI Type A-2
>> card0-LVDS-1
>> card0-VGA-1
>
> We tried cleaning up the list of DP/HDMI outputs using the BIOS VBT
> tables, but it turned out that some clever BIOSes (oh, how we hate
> clever BIOSes) will not expose a DP/HDMI pair unless the laptop is
> docked, so if you docked it later you wouldn't get your DP.  That got
> backed out.  A question I have is whether when docked the VBT gets
> munged to show the updated info.  There might be an opportunity then to
> hook into docking to expose new connectors (or change them from
> always-report-disconnected-and-not-check-i2c to check-i2c).
>

This doesn't seem to be much of a problem for me.  The problem is that
I get a bogus interrupt to begin with.  (The other problem is that an
interrupt on a port with nothing attached causes an i2c transaction on
a *different* port, which is slow.)

> Another thought would be to cache EDID outputs from a second or so ago,
> to reduce the pain of somebody eating uevents one by one and triggering
> reprobes, or various other userland reprobe sequences.  I suspect xrandr
> does some excessive reprobing sometimes.  The downside there is the
> chance of races so that somebody gets stale data after a hotplug.  Maybe
> only cache for outputs where we've got hotplug for them and invalidate
> the output that triggered the hotplug?

What if we cache forever and invalidate when hotplug happens.  And
then start reloading the cache even before userspace asks.  Or even
wait until we've finished loading everything before we notify
userspace?

(I'm willing to try coding this.  If we like the idea in general,
maybe it should go into core DRM where it would be less awkward.)

>
> Our I2C is a CPU-hogging mess, too.  We might do better using the GMBUS.
> I'd be kind of afraid of GMBUS at this point now that we've got the
> bit-bang i2c stable, but it's worth investigating I think.  It's more or
> less sending commands out saying "get this data in/out the i2c bus and
> interrupt when done."  Doesn't that sound nice?  However, if you've got
> a slow device on the other end of your i2c, you're still going to be
> blocked in the kernel on the i2c transaction with X not smooth mousing
> until it's done.

True.  GMBUS would save battery life, though :)

--Andy