> We can verify this by setting a breakpointn in cardbus_probe_children()
> and check its return value to see if a child is detected.
> cardbus_probe_children() is called repeatedly probing
> every dev/func on the bus. Suppose you only inserted one card, then the bus
> number should be 3. And the PC Card inserted is supposed to be 3(bus),
> 0(dev), 0(func).
cardbus_probe_children() returns 42, PCICFG_NODEVICE.
# /net/leo/files/jk/src/dtrace/cardbus.d
dtrace: script '/net/leo/files/jk/src/dtrace/cardbus.d' matched 2 probes
CPU FUNCTION
0 -> cardbus_probe_children
0 <- cardbus_probe_children returns 42
0 -> cardbus_probe_children
0 <- cardbus_probe_children returns 42
...
With cardbus_debug set to 9 (or was it 10?):
pcic(1),0xdb8613a8: cardbus_load_cardbus
pcic(1),0xdb8613a8: cardbus_configure ()
pcic(1),0xdb8613a8: cardbus_primary_busno: bus range is 2 to 9
pcic(1),0xdb8613a8: Set bus type to cardbus
hp_attachment,0xd37b4050: Configuring [0x2][0x9][0x1]
pcic(1),0xdb8613a8: cardbus_probe_bridge bus 2 device 9 func 1
pcic(1),0xdb8613a8: ---Vendor ID = [0x1524]
pcic(1),0xdb8613a8: ---Device ID = [0x1421]
pcic(1),0xdb8613a8: --Cardbus bridge found root bus [0x2] device[0x9] func [0x1]
pcic(1),0xdb8613a8: allowable bus range is 2->9
pcic(1),0xdb8613a8: NEW bus found [2]->[3]
cardbus_set_bus_numbers [2->3]
pcic(1),0xdb8613a8: enable_cardbus_bridge() stat 0x0210 comm 0x0007 bctrl 0x0420
hp_attachment,0xd37b4050: cardbus_probe_children bus 3 device 0 func 0
pseudo,0xd5c1ee98: cardbus_config_setup(dip=0xd5c1ee98)
pseudo,0xd5c1ee98: cardbus_config_setup, reg = 0xd5ac1820
pcic(1),0xdb8613a8: cardbus_bus_map(dip=0xdb8613a8, rdip=0xd37b4050)
pcic(1),0xdb8613a8: cardbus_bus_map(hp_attachment) calling pci_pci -
0xfebac884, offset 0x0, len 0x0
hp_attachment,0xd37b4050: cardbus_bus_map OK
pseudo,0xd5c1ee98: PROBING =>->->->->->-> [0x3][0x0][0x0] 0x30000 0x0
pseudo,0xd5c1ee98: cardbus_config_setup returning 42
hp_attachment,0xd37b4050: cardbus_probe_children bus 3 device 1 func 0
pseudo,0xd5c1ee98: cardbus_config_setup(dip=0xd5c1ee98)
pseudo,0xd5c1ee98: cardbus_config_setup, reg = 0xd60785d8
pcic(1),0xdb8613a8: cardbus_bus_map(dip=0xdb8613a8, rdip=0xd37b4050)
pcic(1),0xdb8613a8: cardbus_bus_map(hp_attachment) calling pci_pci -
0xfebac884, offset 0x0, len 0x0
hp_attachment,0xd37b4050: cardbus_bus_map OK
pseudo,0xd5c1ee98: PROBING =>->->->->->-> [0x3][0x1][0x0] 0x30800 0x0
pseudo,0xd5c1ee98: cardbus_config_setup returning 42
...
> We may also set cardbus_debug as 9, then /var/adm/messages should show
> the probing process. Check the result of probing 3,0,0.
Hmm, the 16bit pci configuration space access to bus 3, device 0, func 0,
offset 0 returns 0xffff.
I've set a breakpoint in cardbus_probe_children, hotplugged the card, kmdb stops
at the breakpoint:
- at this point the power led on the firewire cardbus card is already enabled,
so I guess power is OK
- when I use the following kmdb command, I get a return value of 0xffff:
*pci_getw_func::call 3 0 0 0
=================================================
While playing with the hardware I've found something interesting:
1. cold boot the tecra s1
2. hotplug the firewire card into the upper pcic#0 socket, hci1394 is detected
3. modunload hci1394 kernel module, and remove cardbus card from pcic#0 socket
(the modunload is required to work around hot-remove problems, without it
the
tecra s1 will freeze)
4. hotplug the firewire card into the lower pcic#1 socket, hci1394 is detected
!!
Seems as if the cardbus bridge at bus/device/function 2/9/1 starts to work just
fine after the other bridge at 2/9/0 has been used.
This message posted from opensolaris.org
