From owner-freebsd-current@FreeBSD.ORG Tue Sep 13 02:55:38 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org 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 EB34416A41F; Tue, 13 Sep 2005 02:55:37 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.95]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3706643D46; Tue, 13 Sep 2005 02:55:36 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from flame.pc (patr530-a103.otenet.gr [212.205.215.103]) by kane.otenet.gr (8.13.4/8.13.4/Debian-1) with ESMTP id j8D2tJVS014483; Tue, 13 Sep 2005 05:55:20 +0300 Received: from flame.pc (flame [127.0.0.1]) by flame.pc (8.13.4/8.13.4) with ESMTP id j8D2tGEZ001848; Tue, 13 Sep 2005 05:55:16 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by flame.pc (8.13.4/8.13.4/Submit) id j8D2tFA9001847; Tue, 13 Sep 2005 05:55:15 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Tue, 13 Sep 2005 05:55:15 +0300 From: Giorgos Keramidas To: John Baldwin , "M. Warner Losh" Message-ID: <20050913025515.GD1615@flame.pc> References: <20050816124525.GA31411@flame.pc> <20050816.092235.16452975.imp@bsdimp.com> <20050816154750.GB93756@flame.pc> <200508161348.09643.jhb@FreeBSD.org> <20050821215616.GA1750@gothmog.gr> <20050913005636.GA2563@flame.pc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050913005636.GA2563@flame.pc> X-Mailman-Approved-At: Tue, 13 Sep 2005 10:45:38 +0000 Cc: freebsd-current@FreeBSD.org Subject: Re: if_dc panics with 3Com OfficeConnect 10/100B PCI 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, 13 Sep 2005 02:55:38 -0000 On 2005-08-22 00:56, Giorgos Keramidas wrote: > On 2005-08-16 13:48, John Baldwin wrote: > > > > Compile in DDB and get a stack trace over the serial console using 't' in DDB > > instead of worrying about getting a dump. > > [...] > I have no way to debug the crash now, since I only have one machine at > home. When I get the chance I plan to test this again, and I'll report > back then, if this is still a problem. I think I've finally located the cause of this panic. The panic happens early in dc_attach(), and the last message I see is the one printed by dc_attach() in src/sys/pci/if_dc.c: % if (sc->dc_res == NULL) { % device_printf(dev, "couldn't map ports/memory\n"); % error = ENXIO; % goto fail; % } % % [ various busdma setup calls ] % % fail: % if (error) % dc_detach(dev); % return (error); The bug of dc_detach() that causes the panic is that it doesn't check if one of the busdma tags and some maps it destroys have been allocated. In this case, because dc_attach() fails too early, before any busdma calls, they haven't been allocated and one of the busdma calls panics when it gets a NULL pointer. The following patch fixes the panic of loading if_dc.ko when the 3Com NIC of the subject is installed: %%% Index: if_dc.c =================================================================== RCS file: /home/ncvs/src/sys/pci/if_dc.c,v retrieving revision 1.166 diff -u -r1.166 if_dc.c --- if_dc.c 29 Aug 2005 18:45:21 -0000 1.166 +++ if_dc.c 13 Sep 2005 00:32:51 -0000 @@ -2364,11 +2364,17 @@ bus_dmamem_free(sc->dc_stag, sc->dc_cdata.dc_sbuf, sc->dc_smap); if (sc->dc_ldata != NULL) bus_dmamem_free(sc->dc_ltag, sc->dc_ldata, sc->dc_lmap); - for (i = 0; i < DC_TX_LIST_CNT; i++) - bus_dmamap_destroy(sc->dc_mtag, sc->dc_cdata.dc_tx_map[i]); - for (i = 0; i < DC_RX_LIST_CNT; i++) - bus_dmamap_destroy(sc->dc_mtag, sc->dc_cdata.dc_rx_map[i]); - bus_dmamap_destroy(sc->dc_mtag, sc->dc_sparemap); + if (sc->dc_mtag) { + for (i = 0; i < DC_TX_LIST_CNT; i++) + if (sc->dc_cdata.dc_tx_map[i] != NULL) + bus_dmamap_destroy(sc->dc_mtag, + sc->dc_cdata.dc_tx_map[i]); + for (i = 0; i < DC_RX_LIST_CNT; i++) + if (sc->dc_cdata.dc_rx_map[i] != NULL) + bus_dmamap_destroy(sc->dc_mtag, + sc->dc_cdata.dc_rx_map[i]); + bus_dmamap_destroy(sc->dc_mtag, sc->dc_sparemap); + } if (sc->dc_stag) bus_dma_tag_destroy(sc->dc_stag); if (sc->dc_mtag) %%% With this patch, on CURRENT of Sep-12-2005, the attach of the NIC in question still fails, but at least it doesn't panic the system while doing so :) P.S.: Is there any way to guard against similar bugs in other drivers and/or bugs that may be introduced later on? For instance, would adding KASSERT() macros in busdma_machdep.c slow things down too much?