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>
