Panic in a recent kernel (cardbus/pci related ?)
Thierry Herbelot
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 ---
Cheers
TfH
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
John Baldwin
> 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.
Can you try reverting the recent change to sys/dev/pci/pci.c to use
resource_list_reserve() just to narrow down if that is the cause?
--
John Baldwin
Thierry Herbelot
> 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.
>
> Can you try reverting the recent change to sys/dev/pci/pci.c to use
> resource_list_reserve() just to narrow down if that is the cause?
Hello,
If I revert this commit, the kernel does boot correctly :
308,309c308,309
< $FreeBSD: src/sys/dev/pci/pci.c,v 1.390 2009/11/25 20:50:43 thompsa Exp
$
< $FreeBSD: src/sys/dev/pci/pci_pci.c,v 1.60 2009/05/20 22:00:39 imp Exp
$
---
> $FreeBSD: src/sys/dev/pci/pci.c,v 1.392 2009/12/10 01:01:53 jkim Exp $
> $FreeBSD: src/sys/dev/pci/pci_pci.c,v 1.61 2009/12/10 01:01:53 jkim Exp
$
(the diff is an extract from the change in the idents between the last working
kernel and the next, non-working one)
This commit seems to be about processing ACPI tables : maybe my notebook has a
some bad ACPI data ?
TfH
John Baldwin
> Le Monday 14 December 2009, John Baldwin a �crit :
> > 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.
> >
> > Can you try reverting the recent change to sys/dev/pci/pci.c to use
> > resource_list_reserve() just to narrow down if that is the cause?
>
> Hello,
>
> If I revert this commit, the kernel does boot correctly :
>
> 308,309c308,309
> < $FreeBSD: src/sys/dev/pci/pci.c,v 1.390 2009/11/25 20:50:43 thompsa Exp
> $
> < $FreeBSD: src/sys/dev/pci/pci_pci.c,v 1.60 2009/05/20 22:00:39 imp Exp
> $
> ---
> > $FreeBSD: src/sys/dev/pci/pci.c,v 1.392 2009/12/10 01:01:53 jkim Exp $
> > $FreeBSD: src/sys/dev/pci/pci_pci.c,v 1.61 2009/12/10 01:01:53 jkim Exp
> $
> (the diff is an extract from the change in the idents between the last working
> kernel and the next, non-working one)
>
> This commit seems to be about processing ACPI tables : maybe my notebook has a
> some bad ACPI data ?
This delta includes two changes to pci.c (1.391 and 1.392). Can you try moving
it up so that it applies just 1.391 of pci.c?
--
John Baldwin
Thierry Herbelot
indeed, with revision 1.391, the panic also happens (with the same backtrace
as the one I posted Friday)
TfH
Wojciech A. Koszek
> 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.
I think I experienced the same problem as well:
cardbus0: CIS pointer is 0x5001
cardbus0: CIS in BAR 0x10
cardbus0: CIS Mapped to 0x88000000
cardbus0: CIS offset is 0x5000
cardbus0: CIS pointer is 0x5001
cardbus0: CIS in BAR 0x10
cardbus0: CIS Mapped to 0x88000000
cardbus0: CIS offset is 0x5000
TUPLE: LINKTARGET [3]: 43 49 53
Manufacturer ID: 71021200
TUPLE: Unknown(0x04) [6]: 03 01 00 00 00 00
TUPLE: Unknown(0x05) [14]: 41 b1 39 b5 1e 2d 4e 56 30 ff ff 02 e9 00
Product version: 7.1
Product name: Atheros Communications, Inc. | AR5001-0000-0000 | Wireless LAN Reference Card | 00 |
Functions: Network Adaptor, Memory
Function Extension: 02808d5b00
Function Extension: 0240548900
Function Extension: 02001bb700
Function Extension: 0280a81201
Function Extension: 0200366e01
Function Extension: 0200512502
Function Extension: 02006cdc02
Function Extension: 0280f93703
Function Extension: 0200a24a04
Function Extension: 0308
Function Extension: 040600032f555555
Function Extension: 0501
CIS reading done
panic: resource_list_add: resource entry is busy
cpuid = 0
KDB: enter: panic
Plugging WiFi CardBus-based card.
--
Wojciech A. Koszek
wko...@FreeBSD.org
http://FreeBSD.czest.pl/~wkoszek/
John Baldwin
Yes, I haven't forgotten about this I just haven't had time to figure out the
right set of debug printfs to figure out why it is breaking. I think
cardbus.c needs changes to catch up with the resource_list_reserve() changes
to the PCI bus driver, but I don't see anything obvious looking at cardbus.c.
--
John Baldwin
John Baldwin
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
John Baldwin
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
Wojciech A. Koszek
> 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,
> > >
[..]
>
> 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
Hi John,
I took my current sources:
http://people.freebsd.org/~wkoszek/traces/cb-kernel.txt
Which come from:
FreeBSD laptop.freebsd.czest.pl 9.0-CURRENT FreeBSD 9.0-CURRENT #0
r200811: Mon Dec 21 22:11:17 UTC 2009
wko...@laptop.freebsd.czest.pl:/usr/src/sys/i386/compile/L20091221
And I have applied your patch against src/sys/.... This is what I got when my
Atheros-based CardBus WiFi card got inserted:
http://people.freebsd.org/~wkoszek/traces/cb.jpg
--
Wojciech A. Koszek
wko...@FreeBSD.org
http://FreeBSD.czest.pl/~wkoszek/
M. Warner Losh
John Baldwin <j...@freebsd.org> writes:
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
John Baldwin
> On Wed, Dec 30, 2009 at 10:25:56AM -0500, John Baldwin wrote:
> > 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,
> > > >
>
> [..]
>
> >
> > 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
>
> Hi John,
>
> Atheros-based CardBus WiFi card got inserted:
>
> http://people.freebsd.org/~wkoszek/traces/cb.jpg
I had a typo. Change the 'bus_generic_activate_resource()' in
pci_deactivate_resource() in pci.c to bus_generic_deactivate_resource().
--
John Baldwin
Miki
I can report a success here, I applied your patch and have no panic anymore
with a
atheros based cardbus card.
Thanks !
M. Warner Losh
John Baldwin <j...@freebsd.org> writes:
I'll have to pay special attention to this. It is really easy to get
wrong, and the current code in the tree doesn't quite work.
: 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).
Yea. There's a conflict here. Originally, the view was that PCI
drivers were responsible for freeing all resources they allocated.
And they needed to keep track. Over time lists have sprung up to make
this possible. It is no wonder there's inconsistency here.
: 4) Remove unused pci_release_resource().
:
: The patch is available at http://www.FreeBSD.org/~jhb/patches/cardbus.patch
Can you regenerate this -p?
Warner
John Baldwin
Well, cardbus is the only place that currently needs to forcefully remove a
PCI device, and in the case that you do that I think it's best to not trust
the driver but to always clean up after it. pccard does the same thing as
well for ejected cards.
> : 4) Remove unused pci_release_resource().
> :
> : The patch is available at http://www.FreeBSD.org/~jhb/patches/cardbus.patch
>
> Can you regenerate this -p?
Sure. I've committed some of the more harmless bits already. I've
regenerated the full set of remaining patches at the same URL. I've
also split out two sub-patches:
~jhb/patches/cardbus_bus_space.patch - this just changes the cardbus_cis
code to use bus_*() instead of bus_space_*()
~jhb/patches/rom.patch - this is the set of changes to add PCIR_BIOS
support to the pci(4) bus driver and remove the special hacks for it
from cardbus
--
John Baldwin
Thierry Herbelot
> On Wednesday 30 December 2009 2:48:37 pm M. Warner Losh wrote:
>
> Sure. I've committed some of the more harmless bits already. I've
> regenerated the full set of remaining patches at the same URL. I've
> also split out two sub-patches:
Hello,
I won't find time to test it before the week-end : then I'll tell you the
latest results ;-)
Thanks
TfH
>
> ~jhb/patches/cardbus_bus_space.patch - this just changes the cardbus_cis
> code to use bus_*() instead of bus_space_*()
>
> ~jhb/patches/rom.patch - this is the set of changes to add PCIR_BIOS
> support to the pci(4) bus driver and remove the special hacks for it
> from cardbus
Wojciech A. Koszek
> On Wednesday 30 December 2009 12:33:51 pm Wojciech A. Koszek wrote:
> > On Wed, Dec 30, 2009 at 10:25:56AM -0500, John Baldwin wrote:
> > > 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,
> > > > >
> >
> > [..]
> >
> >
> >
> > And I have applied your patch against src/sys/.... This is what I got when my
> > Atheros-based CardBus WiFi card got inserted:
> >
> > http://people.freebsd.org/~wkoszek/traces/cb.jpg
>
> I had a typo. Change the 'bus_generic_activate_resource()' in
> pci_deactivate_resource() in pci.c to bus_generic_deactivate_resource().
>
Not only your latest commits fix all cardbus(4) issues I have experienced with
my Cardbus card on CURRENT... Several days ago I have acquired Cardbus<->LPT
adapter and modified puc(4) so that it recognizes it. However, ppc_puc_probe()
present in ppc_puc.c from ppc(4) was never getting called... I just saw
ppc_acpi_probe() and ppc_pci_probe() being executed.
In the fresh build of a kernel I have suddently seen a printf() that I've put
there.
--
Wojciech A. Koszek
wko...@FreeBSD.org
http://FreeBSD.czest.pl/~wkoszek/
M. Warner Losh
"Wojciech A. Koszek" <wko...@FreeBSD.org> writes:
: On Wed, Dec 30, 2009 at 01:04:53PM -0500, John Baldwin wrote:
: > On Wednesday 30 December 2009 12:33:51 pm Wojciech A. Koszek wrote:
: > > On Wed, Dec 30, 2009 at 10:25:56AM -0500, John Baldwin wrote:
: > > > 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,
: > > > > >
: > >
: > > [..]
: > >
: > >
: > > Hi John,
: > >
: > > And I have applied your patch against src/sys/.... This is what I got when my
: > > Atheros-based CardBus WiFi card got inserted:
: > >
: > > http://people.freebsd.org/~wkoszek/traces/cb.jpg
: >
: > I had a typo. Change the 'bus_generic_activate_resource()' in
: > pci_deactivate_resource() in pci.c to bus_generic_deactivate_resource().
: >
:
: Not only your latest commits fix all cardbus(4) issues I have experienced with
: my Cardbus card on CURRENT... Several days ago I have acquired Cardbus<->LPT
: adapter and modified puc(4) so that it recognizes it. However, ppc_puc_probe()
: present in ppc_puc.c from ppc(4) was never getting called... I just saw
: ppc_acpi_probe() and ppc_pci_probe() being executed.
:
: In the fresh build of a kernel I have suddently seen a printf() that I've put
: there.
Yea, but the cardbus with CIS in ROM is still kinda borked. My Xircom
card hits that problem :(
Warner
Michael Butler
> Yea, but the cardbus with CIS in ROM is still kinda borked. My Xircom
> card hits that problem :(
>
Seems my Netgear WG511T no longer works either. 'dumpcis' yields nothing.
Not sure why but it may be related to the PCI topology. I have to
'poke' the '1e.0' bridge to allow it to route to bus 9
('/usr/sbin/pciconf -wb pci0:0:30:0 0x1a 9') but this trick no longer works:
imb@toshi:/usr/bin> sudo lspci -tv
-[0000:00]-+-00.0 Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and
945GT Express Memory Controller Hub
+-02.0 Intel Corporation Mobile 945GM/GMS, 943/940GML
Express Integrated Graphics Controller
+-02.1 Intel Corporation Mobile 945GM/GMS/GME, 943/940GML
Express Integrated Graphics Controller
+-1b.0 Intel Corporation 82801G (ICH7 Family) High
Definition Audio Controller
+-1c.0-[02]--
+-1c.1-[03-04]--
+-1c.2-[05-06]----00.0 Intel Corporation PRO/Wireless
3945ABG [Golan] Network Connection
+-1d.0 Intel Corporation 82801G (ICH7 Family) USB UHCI
Controller #1
+-1d.1 Intel Corporation 82801G (ICH7 Family) USB UHCI
Controller #2
+-1d.2 Intel Corporation 82801G (ICH7 Family) USB UHCI
Controller #3
+-1d.3 Intel Corporation 82801G (ICH7 Family) USB UHCI
Controller #4
+-1d.7 Intel Corporation 82801G (ICH7 Family) USB2 EHCI
Controller
+-1e.0-[07-09]--+-06.0 Texas Instruments PCIxx12 Cardbus
Controller
| +-06.1 Texas Instruments PCIxx12 OHCI
Compliant IEEE 1394 Host Controller
| +-06.2 Texas Instruments 5-in-1 Multimedia
Card Reader (SD/MMC/MS/MS PRO/xD)
| +-06.3 Texas Instruments PCIxx12 SDA
Standard Compliant SD Host Controller
| \-08.0 Intel Corporation PRO/100 VE Network
Connection
+-1f.0 Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge
+-1f.2 Intel Corporation 82801GBM/GHM (ICH7 Family) SATA
IDE Controller
\-1f.3 Intel Corporation 82801G (ICH7 Family) SMBus Controller
Any ideas?
Michael
John Baldwin
Hmm, and does it work prior to all the resource_list_reserve() changes if you
fix the cardbus_cis.c code that tries to clear the decoding bit?
--
John Baldwin
John Baldwin
When did the card last work? Can you get bootverbose messages for doing a
card insert in both a working and HEAD kernel?
--
John Baldwin