Re: SIO Interrupt storms and unhandled interrupts

From: Mike Tancsa (mike_at_sentex.net)
Date: 09/10/04

  • Next message: John Baldwin: "Re: witness oddity" 
    Date: Fri, 10 Sep 2004 15:05:11 -0400
To: John Baldwin <jhb@FreeBSD.org>, "M. Warner Losh" <imp@bsdimp.com>

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

    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.

             ---Mike

    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: John Baldwin: "Re: witness oddity"

    Relevant Pages

    • Re: SIO Interrupt storms and unhandled interrupts
      ... > be a PUC device) that shares its interrupt with the onboard SMBus ... Yes, that would be a storm, and only a driver for the smbus controller could ...
      (freebsd-current)
    • Re: Synchronization between ISR and IST - I2C Based device
      ... We solved the problem by masking the UART Interrupt on every read / ... SMBus Read / Write Operation ... Now the Interrupt is being masked and the ISR will not occur when the ... when the bus access is finished the interrupt is served immediately. ...
      (microsoft.public.windowsce.platbuilder)