<br><br><div class="gmail_quote">On Wed, Nov 7, 2012 at 11:22 AM, Ben Guthro <span dir="ltr"><<a href="mailto:ben@guthro.net" target="_blank">ben@guthro.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm trying to debug an issue on an older lapop (Toshiba Satellite A505) - that has an i3 processor (M330) - and intel graphics.<div>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</div>

<div><br></div><div>(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.)<br><div><br></div></div></blockquote><div><br></div><div>
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.</div><div>I'll remove xen-devel, and Konrad from future replies to this thread.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>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.</div>

<div><br></div></blockquote><div><br></div><div>10*HZ seems to be the normal hotplug interval, when an interrupt doesn't fire</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div></div><div><br></div><div>There seems to be a mismatch for these IRQ delivery - or at least exhibits the behavior similar to such a problem.</div>
<div><br></div></blockquote><div><br></div><div>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.</div><div>It seems that the hotplug mask is not getting cleared in pch_iir (in i915_irq.c)</div>
<div><br></div><div>Manually clearing this bit with</div><div>pch_iir = pch_iir ^ hotplug_mask;</div><div>in the ironlake_irq_handler() function</div><div><br></div><div>seems to resolve the issue - making it so I don't get the flurry of hotplug work bogging down the system.</div>
<div>...but is this disabling hotplug detection entirely?</div><div><br></div><div><br></div></div>