On Oct 7, 2006, at 9:15 AM, Segher Boessenkool wrote:

The code of concern seems well suited to catch a spurious interrupt
storm, since when a valid external interrupt is recieved, the counter is reset. But given that we don't take our first external until way into
dom0's boot, we are actually asserting that 100 spurious interrupts
won't be received over a fairly long period of time.

I can't find any documents regarding expected spurious interrupt rates. Can anyone with knowledge in this area comment about the code of concern?

All edge-triggered interrupts can cause spurious interrupts; this
is normal.  For example, a second edge interrupt (on the same line)
can come in before the first has been handled.  The rate at which
this happens should be really low.

The CPC9x5 interrupt controller has an issue though that manifests
itself as lots of spurious interrupts all over the place.  Those
are interspersed with valid interrupts, there is no functional
problem; it can turn into a performance problem though.

My theory on our specific problem has to do with how we currently "share" the MPIC with Dom0. The code/design is temporary and will be addressed at a later date, thought I would gladly take a patch from anyone.

Since we share the MPIC, Xen takes the interrupt, acks it and then "sends" it to dom0 via Xen Evtchn and then Dom0 takes over the rest. Dom0 knows everything and Xen knows very little.

Sometimes right after Dom0 inits the MPIC for the second time, we get a spurious interrupt storm.

Amos has a concern that the current test gives false positives of this condition, but I have yet to see this condition occur at any other point then immediately after Dom0 inits the mpic.

One day, all mpic operations will happen in Xen, but until then we are stuck with this scenario.

Xen-ppc-devel mailing list

Reply via email to