Re: Panic in a recent kernel (cardbus/pci related ?)

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.  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.

-- 
John Baldwin