Xen project Mailing List

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?

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