From owner-freebsd-current@FreeBSD.ORG Wed Dec 30 15:26:12 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31FCE106566C; Wed, 30 Dec 2009 15:26:12 +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 068788FC0C; Wed, 30 Dec 2009 15:26:12 +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 AB9D846B23; Wed, 30 Dec 2009 10:26:11 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 4E0C28A01B; Wed, 30 Dec 2009 10:25:59 -0500 (EST) From: John Baldwin To: Thierry Herbelot Date: Wed, 30 Dec 2009 10:25:56 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091103; KDE/4.3.1; amd64; ; ) References: <200912110615.28030.thierry.herbelot@free.fr> <200912300928.33157.jhb@freebsd.org> In-Reply-To: <200912300928.33157.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200912301025.56737.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 30 Dec 2009 10:25:59 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Warner Losh , current@freebsd.org Subject: Re: Panic in a recent kernel (cardbus/pci related ?) 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: Wed, 30 Dec 2009 15:26:12 -0000 On Wednesday 30 December 2009 9:28:33 am John Baldwin wrote: > On Friday 11 December 2009 12:15:27 am Thierry Herbelot wrote: > > Hello, > > > > I'm seeing a panic in my latest -Current kernel (config file == GENERIC > minus > > INVARIANTS, WITNESS and SMP). The machine is an older notebook, with a > PCMCIA > > network card. > > > > The end of the verbose dmesg, showing the panic is following : > > [SNIP] > > Device configuration finished. > > procfs registered > > Timecounter "TSC" frequency 169163324 Hz quality 800 > > Timecounters tick every 1.000 msec > > firewire0: fw_sidrcv: ERROR invalid self-id packet > > firewire0: 1 nodes, maxhop <= 0 Not IRM capable irm(-1) > > lo0: bpf attached > > hptrr: no controller detected. > > ata0: Identifying devices: 00000001 > > ata0: New devices: 00000001 > > usbus0: 12Mbps Full Speed USB v1.0 > > battery0: battery initialization start > > battery1: battery initialization start > > acpi_acad0: ugen0.1: at usbus0 > > uhub0: on usbus0 > > acline initialization start > > acpi_acad0: On Line > > acpi_acad0: acline initialization done, tried 1 times > > ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire > > ad0: setting UDMA33 > > ad0: 28615MB at ata0-master UDMA33 > > ad0: 58605120 sectors [62016C/15H/63S] 16 sectors/interrupt 1 depth queue > > unknown: Lazy allocation of 0x400 bytes rid 0x14 type 3 at 0x88000000 > > cbb1: Opening memory: > > cbb1: Normal: 0x88000000-0x88000fff > > cbb1: Opening memory: > > cbb1: Normal: 0x88000000-0x88000fff > > map[10]: type I/O Port, range 32, base 0, size 8, port disabled > > map[14]: type Memory, range 32, base 0, size 10, enabled > > panic: resource_list_add: resource entry is busy > > KDB: enter: panic > > [thread pid 8 tid 100032 ] > > Stopped at kdb_enter+0x3a: movl $0,kdb_why > > db> where > > Tracing pid 8 tid 100032 td 0xc256cb40 > > kdb_enter(c0c9240f,c0c9240f,c0c93aaa,c23d4b70,c23d4b70,...) at > kdb_enter+0x3a > > panic(c0c93aaa,3,14,400,ffffffff,...) at panic+0xd1 > > resource_list_add(c26e9004,3,14,0,ffffffff,...) at resource_list_add+0x96 > > pci_add_map(c26e9004,1,0,c23d4c58,14,...) at pci_add_map+0x628 > > pci_add_resources(c256b980,c267a980,1,0,1,...) at pci_add_resources+0x59e > > cardbus_attach_card(c256b980,c24fd990,c0d23d08,f889cc55,ffebf3e8,...) at > > cardbus_attach_card+0x56e > > cbb_event_thread(c2676000,c23d4d38,4478b00,840fc085,428,...) at > > cbb_event_thread+0x395 > > fork_exit(c070db40,c2676000,c23d4d38) at fork_exit+0x90 > > fork_trampoline() at fork_trampoline+0x8 > > --- trap 0, eip = 0, esp = 0xc23d4d70, ebp = 0 --- > > I think I have finally figured this out. What is happening is that the card > stores its CIS in a PCI BAR (this is probably fairly common for cardbus > cards). So, the PCI BAR holding the CIS is being allocated before > pci_add_resources() is called hence the confusion. There is a bit of a > chicken and egg problem here in that we need to parse the CIS to determine > what special requirements (e.g. prefetch) might be required for other BARs. > I'm not sure if the Cardbus spec makes certain guarantees about the properties > of a BAR that is used to hold the CIS. I'm not actually sure how this worked > prior to my change as the resource for the CIS BAR should still have been > present in this case causing the same error (the old pci_release_resource() > would still have left the resource around). I'll need to talk to Warner about > the best way to resolve this. This is one possible hack. It instructs the PCI bus to completely remove the resource for the CIS. While looking at this I found some other bugs (the code to disable decoding in the ROM BAR didn't actually work for example) and have come up with a larger patch. It does a few things: 1) Fixes bus_generic_rl_(alloc|release)_resource() to not try to fetch a resource list for a grandchildren. 2) Add full support for device ROM BARs to the PCI bus and remove the device ROM hacks from the cardbus driver now that PCI manages them. 3) Use a resource_list_unreserve() when purging resources from a cardbus card when it is removed as this is a bit cleaner. Arguably the PCI bus driver should have a 'delete all resources' method that does this instead (hotplug PCI would need to use it). 4) Remove unused pci_release_resource(). The patch is available at http://www.FreeBSD.org/~jhb/patches/cardbus.patch -- John Baldwin