Re: Interrupt storm mitigation needed

[Tom Ivar Helbekkmo <tih%hamartun.priv.no@localhost>]

Tom Ivar Helbekkmo <tih%hamartun.priv.no@localhost> writes:

> 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.

The machine has now been running for nine hours, doing a "-j 2" system
build, and also running backups during the night -- with no incidents.
The interrupt counts, though, are up to 600 thousand on the uhci2 pin,
400 thousand on the uhci0 pin, along with about 3 million "legit"
interrupts for amr0, and 2 million for wm0.  I guess the storms are
still happening, but Joerg's changes, where he doesn't explicitly enable
interrupts for these devices, soften the effect, and let them stop more
quickly?

Also, I guess I'm lucky to have this hit uhci on my particular brand of
motherboard.  I see that others with the Intel E7520 chip set report
e.g. the network interface getting the interrupt storms.

Oh, and in case I haven't made that clear: while I'm currently using the
uhci2 port (for very slow communication), the observed hangs were there
also when I was not.  Using the port merely made them happen more
frequently, just like piling on network traffic did.  The only
prerequisite, it seems, is that moderately heavy disk I/O through the
RAID controller needs to be going on.  Rhymes with this FreeBSD thread,
of course, where it is claimed that masking the ioapic pin while
handling an interrupt makes this chip set reroute it, whack-a-mole style:

http://freebsd.1045724.n5.nabble.com/em-interrupt-storm-td3877379.html

-tih
-- 
Popularity is the hallmark of mediocrity.  --Niles Crane, "Frasier"