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

Andrew Lutomirski luto at mit.edu
Thu Feb 4 17:41:48 CET 2010


On Sun, Jan 31, 2010 at 9:54 PM, Andrew Lutomirski <luto at mit.edu> wrote:
> On Sun, Jan 31, 2010 at 8:03 PM, ykzhao <yakui.zhao at intel.com> wrote:
>> On Sun, 2010-01-31 at 19:49 +0800, Andrew Lutomirski wrote:
>>> On Sat, Jan 30, 2010 at 10:02 PM, Andrew Lutomirski <luto at mit.edu> wrote:
>>> > [I posted this bug earlier with a terrible description as "resume
>>> > lagginess and other problems."  Here it is again with a better bug
>>> > report.]
>>> >
>>> > I'm running 2.6.33-rc5 (plus some wireless-testing stuff, but I've
>>> > seen this problem on a variety of 2.6.33-rc? kernels).  Every now and
>>> > then, X starts to lag badly on my GM45 laptop.  When this happens, I
>>> > usually see a bunch of events in udevmonitor.  Running with
>>> > drm.debug=0x02 (and the patch below to keep the log under control), I
>>> > see tons of messages like this:
>>>
>>> I triggered it again.  This time, the messages looked like
>>> (drm.debug=3 from a different VT to avoid all the hotplug stuff
>>> running off the screen, and running a different debugging hack -- see
>>> all the way at the bottom):
>>>
>>> [ 1324.285057] [drm:i915_driver_irq_handler], hotplug event received,
>>> stat 0x28200000, mask 0x38000800
>>
>> >From the stat value it seems that this is related with the HDMI hotplug.
>> Will you please confirm whether th HDMI is pluged/unpluged in your test?
>
> This is a Lenovo X200s, and it doesn't have HDMI.  I have LVDS on and
> everything else (i.e. VGA and the docking station, which has a DP
> port) disconnected.
>

I don't think this is a hotplug bug.  I don't remember seeing it back
in early January (i.e. before by laptop died and got its motherboard
replaced).  The bug is present in 2.6.32.7 and in 2.6.33-rc6.

I think it's a bad interaction between some kind of idle code and
suspend/resume.  I can't trigger it without suspending and resuming at
least once after reboot, and I can't make it go away completely once
it starts triggering.

Once the bug starts, it seems to manifest in one of two forms.

Bug form 1 (the bad one): X lags so badly that I can hardly do
anything.  The mouse seems to update only twice a second or so.
Compositing gets so slow that I can't use any programs.  I can switch
VTs and use the console, but switching back to X doesn't fix it.
udevmonitor shows a huge flood of events (4/second, maybe).  Once this
starts, it keeps happening for quite awhile or until I kill X.
Killing X seems to switch me to bug form 2.

Bug form 2 (the less bad one): When X is idle, my mouse seems to skip
once or twice a second.  When X is not idle (e.g. I'm dragging a
window), everything is fine.  intel_gpu_top seems to suppress the bug
and shows nothing useful.  udevmonitor shows a slow stream of hotplug
events.

In either case, clearing the high bits of PORT_HOTPLUG_EN using
intel_reg_write (i.e. writing 0x320 to 0x61110) stops the hotplug
events but *does not* fix the lag.  (It is more reliable in stopping
the hotplug events if I patch the dp detect code to not change the
high bits back.)

These problems seem to start one minute or so after resuming.  They're
bad enough that suspend/resume is almost unusable.

Userspace is F12.

If it helps at all, I started noticing this bug at the same time that
I noticed that writing 1 to reset in sysfs breaks graphics.  (It used
to work.)

--Andy

> --Andy
>



More information about the Intel-gfx mailing list