From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 19:20:26 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 8827D16A4CE for ; Fri, 10 Sep 2004 19:20:26 +0000 (GMT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A72043D41 for ; Fri, 10 Sep 2004 19:20:26 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 29194 invoked from network); 10 Sep 2004 19:20:25 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 10 Sep 2004 19:20:25 -0000 Received: from [10.50.40.210] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i8AJKLWi017227; Fri, 10 Sep 2004 15:20:22 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Mike Tancsa Date: Fri, 10 Sep 2004 15:20:44 -0400 User-Agent: KMail/1.6.2 References: <6.1.2.0.0.20040908152736.07440148@64.7.153.2> <200409101407.11508.jhb@FreeBSD.org> <6.1.2.0.0.20040910143939.0905b980@64.7.153.2> In-Reply-To: <6.1.2.0.0.20040910143939.0905b980@64.7.153.2> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409101520.44916.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: freebsd-current@FreeBSD.org cc: "M. Warner Losh" 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 19:20:26 -0000 On Friday 10 September 2004 03:05 pm, Mike Tancsa wrote: > 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" 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 <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org