From owner-freebsd-current@FreeBSD.ORG Thu Sep 9 19:10:23 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 AC2DB16A4CF for ; Thu, 9 Sep 2004 19:10:23 +0000 (GMT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B74D43D1F for ; Thu, 9 Sep 2004 19:10:23 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 26390 invoked from network); 9 Sep 2004 19:10:23 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 9 Sep 2004 19:10:22 -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 i89J9xOk009185; Thu, 9 Sep 2004 15:10:10 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Thu, 9 Sep 2004 13:22:19 -0400 User-Agent: KMail/1.6.2 References: <6.1.2.0.0.20040908152736.07440148@64.7.153.2> In-Reply-To: <6.1.2.0.0.20040908152736.07440148@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: <200409091322.19501.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Mike Tancsa Subject: Re: SIO Interrupt storms and unhanded 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: Thu, 09 Sep 2004 19:10:24 -0000 On Wednesday 08 September 2004 07:25 pm, Mike Tancsa wrote: > I think we have been bouncing around this issue for the past few months > both on RELENG_4 and now RELENG_5. In the past it has been somewhat > difficult to reproduce, but now we can do it reliably. I dont think its > a hardware issue as I can take the exact same 2 boxes with the exact same > IRQ assignments and boot with OpenBSD and not run into an interrupt storm > or freeze up the box. Swap back the RELENG_4 or RELENG_5 HD and again, I > can produce an interrupt storm at will. > > I can also reproduce it on 2 different chipsets as well (VIA and > Intel). The problem seems to be around how a PUC device (either a PCI > modem or a PCI serial card) and the sharing of an interrupt (usually an USB > controller, but not always). > > On RELENG_4, the box just locks up in a race trying to service an interrupt > on IRQ 12 but remains unhandled. > > On RELENG_5, I actually catch an interrupt storm. e.g. I attach to sio4 > (PUC modem) and > > Interrupt storm detected on "irq12: uhci1"; throttling interrupt source > > Looking at vmstat -i does indeed show a the rate getting throttled > > releng-5-pioneer# vmstat -i > interrupt total rate > irq0: clk 596719 99 > irq1: atkbd0 2 0 > irq4: sio0 1079 0 > irq6: fdc0 1 0 > irq8: rtc 763812 127 > irq12: uhci1 5825 0 > irq13: npx0 1 0 > irq14: ata0 38727 6 > irq15: vr0 ata1 1984 0 > Total 1408150 235 > releng-5-pioneer# > > where irq12 is the IRQ shared by the modem and the USB port. However, > because all IRQ 12s get throttled, the modem is unusable. e.g. trying to cu > -l /dev/cuaa4 and typing atz takes about 5 seconds. > > > Is there some way to safely tell the kernel that the PUC device that its > shareable ? We did this perhaps very ugly hack on RELENG_4 > > > @@ -1431,15 +1431,19 @@ > > rid = 0; > com->irqres = bus_alloc_resource(dev, SYS_RES_IRQ, &rid, 0ul, > ~0ul, 1, - RF_ACTIVE); > +/* RF_ACTIVE); */ > + RF_SHAREABLE); > > to /usr/src/sys/isa/sio.c > > and at least we can talk to the sio device. However, on RELENG_5 there > does not seem to be the same fix. > > My question is this-- Is the root cause the same issue on RELENG_4 and > RELENG_5 ? Are we going about it the best way to fix the problem ? Or is > the underlying problem something else ? > > Attached is a dmesg and acpidump You can do a similar hack to puc/sio in 5.x, but you also need to remove the 'INTR_FAST' flag to bus_setup_intr() for it to work. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org