insanely-high interrupt rates

[Rodney W. Grimes]

> On Mon, 2019-03-25 at 12:16 -0500, Karl Denninger wrote:
> > On 3/25/2019 12:05, Ian Lepore wrote:
> > > On Mon, 2019-03-25 at 11:58 -0500, Karl Denninger wrote:
> > > > On 3/25/2019 11:48, Bernd Walter wrote:
> > > > > On Mon, Mar 25, 2019 at 11:33:32AM -0500, Karl Denninger wrote:
> > > > > > > [insanely high interrupt rates]
> > > Is the interrupt rate consistent from second to second?  Running
> > > 'vmstat 1' for a while might be useful to see that.  That many
> > > interrupts almost sounds like a line is floating, but if that were
> > > the
> > > case I'd expect a widely varying number of int/sec.
> > > 
> > > If you build custom kernels, it might be helpful to apply r345475
> > > locally... it will display partial device names instead of just '+'
> > > when the name doesn't fit in the vmstat output.
> > > 
> > > -- Ian
> > 
> > No, but it's in the same general range -- around 500k although it does
> > flop around some, and occasionally by a lot (e.g. if I sit and watch it
> > it'll occasionally put up VERY different numbers -- e.g. a ~730k number,
> > then it goes back, etc.)
> > 
> > I don't generally build custom kernels on these but I CAN put this into
> > the STABLE tree I'm building that from since I keep a separate one for
> > Crochet builds on these boxes.  Where do I find that specific delta?  (I
> > usually just svn things and I don't want to roll it all the way back to
> > there, right -- or do I?)
> > 
> 
> I now have an rpi2b, and I see the same thing you do in the 'vmstat -i'
> output, including rates like 500K int/sec on cpu3 timer0.  But while it
> was behaving like that, the output from 'vmstat 1' showed a perfectly
> steady 8800-9200 int/sec, which is certainly more consistent with top
> showing under 2% being used for combined system+interrupt.
> 
> I think the problem here is with vmstat -i, not with actual interrupts.
> Something about the stats reporting is wrong on armv6/v7.
> 
> Note that this is completely separate from the spurious interrupt
> problem, which I still haven't been able to reproduce.

I do not know if this data is of any relavance but when I was
trying to get a Samsung chrome book snow working:
https://wiki.freebsd.org/FreeBSD/arm/Chromebook

I had tons of problems with spurious interrupts if I tried
to use the internal keyboard.  I found that if I plugged
a USB keyboard in and never touched the built in keyboard
I could infact get booted to multiuser and use the system
somewhat.

This testing was done on head before the stable/12 branch,
I can re-aquire the hardware if there is anyone interested
in helping to debug this platform.

> -- Ian
-- 
Rod Grimes                                                 rgrimes at freebsd.org