Re: Interrupt storm mitigation needed

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Fri, Feb 13, 2015 at 01:19:49PM +0100, Joerg Sonnenberger wrote:
> On Thu, Feb 12, 2015 at 09:02:37PM -0500, Thor Lancelot Simon wrote:
> > On Thu, Feb 12, 2015 at 07:52:10PM +0100, Tom Ivar Helbekkmo wrote:
> > > Tom Ivar Helbekkmo <tih%hamartun.priv.no@localhost> writes:
> > > 
> > > > The uhci pins on the ioapics are chalking up a few interrupts, but not
> > > > many, and no bursts.
> > > 
> > > Still nothing bad happening, but I did reboot just now, and saw
> > > something that I've observered a few times lately: when the machine was
> > > just sufficiently up that I could log in, 'vmstat -i' told me that the
> > > ioapic pin for uhci2 had already generated slightly more than 210000
> > > interrupts.
> > 
> > I guess the next question would then be whether, with uhci in polled mode,
> > we can safely mask that pin.
> 
> >From what I see from the original message, there are two issues:
> 
> (1) It's a shared interrupt.
> (2) uhci is generated interrupts when it should not.

We saw this on a platform of similar vintage at a former employer of mine,
and indeed the uhci was one of the devices involved.

Eventually we managed to produce working platform-dependent code to reroute
the interrupt (Hi, Darran!).  However, before that was working, I tried
disabling the interrupt and polling the uhci and the other device involved
(actually, in our case, we were lucky -- we were already polling the other
device).  That worked pretty well.

But it looks like Tom's still getting the interrupt, which means, at least,
that he's paying the overhead of a quick "Nope, no handler for this one!"
return from the interrupt handling code.  How far upstream is it possible
to disable or mask it, I wonder, without breaking another device you care
about or having to switch *it* to polled mode?

Thor