Date: Wed, 30 Dec 2009 10:33:43 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: jhb@FreeBSD.org Cc: thierry.herbelot@free.fr, current@FreeBSD.org Subject: Re: Panic in a recent kernel (cardbus/pci related ?) Message-ID: <20091230.103343.385399974591655645.imp@bsdimp.com> In-Reply-To: <200912300928.33157.jhb@freebsd.org> References: <200912110615.28030.thierry.herbelot@free.fr> <200912300928.33157.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200912300928.33157.jhb@freebsd.org>
John Baldwin <jhb@freebsd.org> 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: <Intel> at usbus0
: > uhub0: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> 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 <HITACHI DK23DA-30 00J1A0A1> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091230.103343.385399974591655645.imp>