At boot time autoconfigure of an O2 Micro single slot PCI-CardBus bridge fails. The output from autoconfigure goes as follows... cbb0: <O2Micro OZ6812/6872 PCI-CardBus Bridge> at device 9.0 on pci0 cardbus0: <CardBus bus> on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pcib0: unable to route slot 9 INTA cbb: Unable to map IRQ... device_attach: cbb0 attach returned 12 So, there is something odd about how the IRQs work. When the system has booted a quick check with pciconf (pciconf -l -v) reports the card as shown below. This gives me the impression that the card should be a known one. cbb0@pci0:9:0: class=0x060700 card=0x00000000 chip=0x68721217 rev=0x05 hdr=0x02 vendor = 'O2 Micro Inc' device = 'OZ6812 CardBus Controller' class = bridge subclass = PCI-CardBus Fix: None known yet. How-To-Repeat: You need only the OZ6812/6872 card and boot. If there is a need for more debug info, just let me know. For the moment the system in which I found this problem is just a testing environment. So, producing more test data should be relatively quick and easy.
Responsible Changed From-To: freebsd-bugs->freebsd-i386 This sounds like it might be i386-specific.
State Changed From-To: open->feedback Is this still a problem with modern versions of FreeBSD?
Responsible Changed From-To: freebsd-i386->linimon
State Changed From-To: feedback->suspended Submitter notes that the code has not changed, so this is probably still a problem. If a committer wants to work on this, he still has the system.
Responsible Changed From-To: linimon->freebsd-bugs Now that feedback has been received, turn this back over to the pool.
If this is still an issue, please capture a full verbose dmesg. -- John Baldwin
There have been various changes in the PCI/cardbus layer since 2007. My request for a complete verbose dmesg back in 2011 wasn't responded to. Without that info this is not going to be fixed.
Sadly I have not had a suitable test environment with the particular device in years now.