[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] S3 causing IRQ delivery mismatch - i915 hotplug storm





On Wed, Nov 7, 2012 at 11:22 AM, Ben Guthro <ben@xxxxxxxxxx> 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?


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.