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 <t...@hamartun.priv.no> 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