Jamie McKnight wrote: >pci bus 0x0000 cardnum 0x0a function 0x00: vendor 0x1217 device 0x6972 >O2 Micro, Inc. OZ601/6912/711E0 CardBus/SmartCardBus Controller >STATUS 0x0410 COMMAND 0x0007 >CLASS 0x06 0x07 0x00 REVISION 0x00 >BIST 0x00 HEADER 0x02 LATENCY 0x40 CACHE 0x00 >BASE0 0x0c000000 addr 0x0c000000 MEM > > BASE0 (pci config offset 0x10) is *mistakenly* programmed as 0x0c000000.
0x0c000000=192M. It overlaps the system memory (You have >=256M memory, right?), not within the memory range for PCI devices. In other words the values read through 0x0c000000 are in your system memory, not on the device. That's why it can be a weird value like 0xffffffff. This is a bug of either BIOS or Newboot; interesting. If c000000 appears in *both* the output of prtconf -v and prtconf -pv (for 0/a/0), then it's a BIOS bug, otherwise it's a Newboot bug. If you'd like to try something experimental, you may set a breakpoint before the cardbus driver is attached. For example: # reboot kernel/unix -kd It reboots and stops, we can then set the breakpoint: >::bp pcic`_init Then set BASE0 to 0: >*pci_putl_func::call 0 a 0 10 0 >:c If it's 0, the cardbus driver will try to find a correct value. You may also put a value which you believe is correct. For example: >*pci_putl_func::call 0 a 0 10 fc000000 >:c If BABSE0 is correct, it'll be able to detect the card inserted (It'll work or it'll hang :), but the 0xffffffff problem will go away). Vincent.
