From owner-freebsd-current@FreeBSD.ORG Wed Dec 30 17:40:30 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 37D031065670; Wed, 30 Dec 2009 17:40:30 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id DDE608FC20; Wed, 30 Dec 2009 17:40:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id nBUHX605001707; Wed, 30 Dec 2009 10:33:06 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 30 Dec 2009 10:33:43 -0700 (MST) Message-Id: <20091230.103343.385399974591655645.imp@bsdimp.com> To: jhb@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <200912300928.33157.jhb@freebsd.org> References: <200912110615.28030.thierry.herbelot@free.fr> <200912300928.33157.jhb@freebsd.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: thierry.herbelot@free.fr, 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 17:40:30 -0000 In message: <200912300928.33157.jhb@freebsd.org> John Baldwin writes: : 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. That makes sense. It used to be OK to do that. : 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. The CIS bar doesn't need that junk to read the CIS. : I'm not sure if the Cardbus spec makes certain guarantees about the properties : of a BAR that is used to hold the CIS. They are just BARs. Nothing magical about them. : 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. We did some special magic to allocate and deallocate the BAR in the CIS reading code. Maybe that symmetry saved us. Warner