SIO Interrupt storms and unhandled interrupts

Mike Tancsa mike at
Fri Sep 10 11:59:35 PDT 2004

At 02:07 PM 10/09/2004, John Baldwin wrote:
> >             Mike Tancsa <mike at> 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"

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 


More information about the freebsd-current mailing list