From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 18:59:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7308916A4CE; Fri, 10 Sep 2004 18:59:35 +0000 (GMT) Received: from avscan1.sentex.ca (avscan1.sentex.ca [199.212.134.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id E15CD43D5C; Fri, 10 Sep 2004 18:59:34 +0000 (GMT) (envelope-from mike@sentex.net) Received: from localhost (localhost.sentex.ca [127.0.0.1]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id i8AIxTYJ025807; Fri, 10 Sep 2004 14:59:29 -0400 (EDT) (envelope-from mike@sentex.net) Received: from avscan1.sentex.ca ([127.0.0.1]) by localhost (avscan1.sentex.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 25517-04; Fri, 10 Sep 2004 14:59:29 -0400 (EDT) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id i8AIxTiC025763; Fri, 10 Sep 2004 14:59:29 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.11/8.12.11) with ESMTP id i8AIxMEe005767; Fri, 10 Sep 2004 14:59:23 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.1.2.0.0.20040910143939.0905b980@64.7.153.2> X-Sender: mdtpop@64.7.153.2 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 10 Sep 2004 15:05:11 -0400 To: John Baldwin , "M. Warner Losh" From: Mike Tancsa In-Reply-To: <200409101407.11508.jhb@FreeBSD.org> References: <6.1.2.0.0.20040908152736.07440148@64.7.153.2> <6.1.2.0.0.20040909154407.08b1a9f8@64.7.153.2> <20040909.154123.106438047.imp@bsdimp.com> <200409101407.11508.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at avscan1b cc: freebsd-current@FreeBSD.org Subject: Re: SIO Interrupt storms and unhandled interrupts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2004 18:59:35 -0000 At 02:07 PM 10/09/2004, John Baldwin wrote: > > Mike Tancsa 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