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>
index | next in thread | previous in thread | raw e-mail
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
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091230.103343.385399974591655645.imp>