From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 09:35:40 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 58D0B16A4CF for ; Fri, 10 Sep 2004 09:35:40 +0000 (GMT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAC4743D54 for ; Fri, 10 Sep 2004 09:35:39 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])i8A9ZSje012917; Fri, 10 Sep 2004 19:35:28 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) i8A9ZNlZ030017; Fri, 10 Sep 2004 19:35:25 +1000 Date: Fri, 10 Sep 2004 19:35:23 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: "M. Warner Losh" In-Reply-To: <20040830.124141.44509158.imp@bsdimp.com> Message-ID: <20040910180421.Y1368@epsplex.bde.org> References: <012301c48e25$14924180$84cba8c0@hh.kew.com> <20040830.124141.44509158.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Fri, 10 Sep 2004 12:07:40 +0000 cc: freebsd-current@freebsd.org cc: ahd@kew.com Subject: Re: PCI SIO devices hog interrupts, cause lock order problems 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 09:35:40 -0000 On Mon, 30 Aug 2004, M. Warner Losh wrote: > In message: <012301c48e25$14924180$84cba8c0@hh.kew.com> > "Andrew H. Derbyshire" writes: > : Basically, any PCI SIO device hogs its interrupt if the PUC device is not > : also in the kernel, and this causes real problems for any environment like > : mine where pulling the modem is not trivial. This seems to be just the old bug that interrupt attributes are wired at bus_setup_intr() time, but that time is too early for at least the INTR_FAST attribute because the best possible wiring depends on the set of devices that is actively using the interrupt. (This set may grow as more devices are attached; it should also shrink as devices are attached, and it should be fully dynamic so that inactive devices don't pessimize the interrupt wiring of active ones.) sio just attempts to set up the interrupt using INTR_FAST because that is best for it. If this fails, then sio tries again without INTR_FAST. The fallback only helps if, if some (non-sio) device on the interrupt can't handle INTR_FAST, then at least one such device is wired to the interrupt before any (not necessarily sio) device asks for the interrupt to be wired as INTR_FAST. Using puc works around the problem by breaking setup of the interrupt using INTR_FAST more deterministically provided PUC_FASTINTR is not used. This depends on the magic and arguably broken ordering of puc and pci-sio attachment -- it depends on puc being attached first, but perhaps pci-sio should be first since it is less generic and more efficient for the small set of hardware that it handles. The cy driver works around the problem in a different way: INTR_FAST is not tried by default, but the CY_PCI_FASTINTR option forces it to be tried first with a fallback to !INTR_FAST in the same way as in sio. Thus the default is fail-safe but pessimal for cy. The default is fail-unsafe for sio mainly for historical reasons. > Does the distributed GENERIC > : kernel have room for the PUC device? Are there side effects that PUC should > : be excluded from GENERIC? > > puc should be in GENERIC, imho. I agree. It is too large due to its sparse data structures, but since the sparse data compresses very well, it doesn't take any more space on boot media than most drivers in GENERIC. Bruce