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

[Eric Anholt]

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).

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?

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20100210/cb54b89b/attachment.sig>