SIO Interrupt storms and unhandled interrupts

[John Baldwin]

On Friday 10 September 2004 03:05 pm, Mike Tancsa wrote:
> At 02:07 PM 10/09/2004, John Baldwin wrote:
> > >             Mike Tancsa <mike at sentex.net> writes:
> > > :          Thanks for the response!  We found a different solution /
> > > : approach which seems to work on both RELENG_4 and RELENG_5.  The
> > > : problem is that the modem is not being seen as a PCI / PUC device and
> > > : instead is being seen as an ISA SIO device ??  The following RELENG_5
> > > : and RELENG_4 patches seem to fix the problem.  I wonder if the other
> > > : modems listed in sio.c suffer the same fate ?
> > > :
> > > : Also fixed in this are those "cant re-use leafs" at bootup time.  The
> > > : modem is seen as a PUC device now....  At the bottom is a diff
> > > : between the boot -v
> > >
> > > I like this fix!  I'll see if I can find to commit it.
> >
> >Note that hacking sio to not use INTR_FAST would have had the same result.
> >Note that in his dmesg diff, sio4 has to fall back to normal interrupt
> > mode.
>
> While on this topic, we are still trying to track down one issue that we
> think is related.   On a remote production machine (i.e. we cannot do too
> much with it just yet) the hardware watchdog will kick in a few times a
> month (perhaps in 1 week, perhaps after 2 weeks, perhaps 2 days--  at
> seemingly random intervals). Of the dozen or so machines we have deployed,
> its the only one with the modem (it does not have the patch forcing it to
> be a PUC device) that shares its interrupt with the onboard SMBus
> controller and its the only one where its locking up like this.  We dont
> have the SMBus driver support compiled in.   My question is this-- what
> happens if the SMBus device fires an interrupt ?  Will the same lockups
> happen in that the kernel thinks the modem is firing the interrupt, but its
> really the SMBus ? The remote device is currently running RELENG_4, so
> there is no "storm detection"

Yes, that would be a storm, and only a driver for the smbus controller could 
turn it off, so if no driver it just locks up.

> Also, if we went the hacking of the sio to not use INTR_FAST, I am not sure
> it would work. I am pretty sure that when we were debugging this issue with
> the help of Bruce Evans, he provided a patch to do just this and it did not
> work.

For the case with smbus the hack won't work, but for your puc case it should 
work.

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org