From owner-freebsd-current@FreeBSD.ORG Tue Aug 16 15:45:07 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 965C3106564A; Tue, 16 Aug 2011 15:45:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 633948FC16; Tue, 16 Aug 2011 15:45:07 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id D1EE346B2D; Tue, 16 Aug 2011 11:45:06 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5CFF08A02F; Tue, 16 Aug 2011 11:45:06 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Tue, 16 Aug 2011 11:45:02 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <75E1A2A7D185F841A975979B0906BBA67BCC877062@AVEXMB1.qlogic.org> <75E1A2A7D185F841A975979B0906BBA67BCC877180@AVEXMB1.qlogic.org> <4E4919DA.5000706@FreeBSD.org> In-Reply-To: <4E4919DA.5000706@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108161145.02733.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 16 Aug 2011 11:45:06 -0400 (EDT) Cc: Stanislav Sedov , "freebsd-current@freebsd.org" , David Somayajulu Subject: Re: Loading drivers via kldload X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Tue, 16 Aug 2011 15:45:07 -0000 On Monday, August 15, 2011 9:06:34 am Andriy Gapon wrote: > on 13/08/2011 00:20 David Somayajulu said the following: > > This is pretty bizarre. I have been experimenting with a very simple driver > > (see source below) which essentially checks the PCI vendor and Device ID's in > > the probe routine. The attach and detach are empty functions. When I run > > kldload and load the driver in a system with HBAs which have a valid Subsytem > > Vendor and Device ID's, the driver loads and attaches to the functions. > > > > However when the Subsystem Vendor and Device ID's are zero, the system panics > > and the stack trace is as shown below(FreeBSD 8.2 on amd64 machine). I don't > > understand why ata_pci_attach() is getting invoked. > > This is because ata_pci_probe returns BUS_PROBE_GENERIC for any pci device that > has PCIC_STORAGE class and PCIS_STORAGE_IDE subclass. So I'd guess that it tries > to attach to your non-trivial hardware in this case and gets some incorrect > resource configuration (e.g. BARs) from the hardware. Well, that would seem odd, still. It only returns BUS_PROBE_GENERIC (not 0), so David's driver's probe routine should still be called to get a chance to attach to the device. Also, the ATA driver only allocates its BAR once, so it shouldn't trigger the panic in question in that case (the panic is only triggered when you try to double-allocate a BAR). > Whether we actually have to panic in such situation is a different question. Yes, it could possibly return an error instead. Other places in the resource list code currently panic rather than returning errors as well though. -- John Baldwin