[Intel-gfx] S3 causing IRQ delivery mismatch - i915 hotplug storm

[Ben Guthro]

On Wed, Nov 7, 2012 at 11:22 AM, Ben Guthro <ben at guthro.net> wrote:

> I'm trying to debug an issue on an older lapop (Toshiba Satellite A505) -
> that has an i3 processor (M330) - and intel graphics.
> This is running under Xen-unstable, and a 3.7-rc4 pvops kernel - but can
> also be reproduced using kernels as old as 3.2.23 - and hypervisors as old
> as 4.0.4
>
> (I have cross posted here, because I am not yet sure if this is a Xen,
> pvops, or i915 issue - and would appreciate opinions in sorting it out.)
>
>
This appears to be unrelated to Xen / pvops, at the moment, after some
additional debugging, and appears to be an issue with the i915 driver with
older hardware.
I'll remove xen-devel, and Konrad from future replies to this thread.



>
> Additionally, this same trace stack is printed out at a regular 10s
> interval, after resume - where prior to resuming from S3 it is printed out
> once at boot time.
>
>
10*HZ seems to be the normal hotplug interval, when an interrupt doesn't
fire


>
> There seems to be a mismatch for these IRQ delivery - or at least exhibits
> the behavior similar to such a problem.
>
>
I was mistaken here. The i8042 IRQ would just start up the IRQ handling -
but the i915 driver always thinks it has pending work, and schedules it.
It seems that the hotplug mask is not getting cleared in pch_iir (in
i915_irq.c)

Manually clearing this bit with
pch_iir = pch_iir ^ hotplug_mask;
in the ironlake_irq_handler() function

seems to resolve the issue - making it so I don't get the flurry of hotplug
work bogging down the system.
...but is this disabling hotplug detection entirely?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20121107/506352d6/attachment.html>