In message <xofg0zbfcbf.fsf_-_@blubb.pdc.kth.se>J,
ohan Danielsson writes:

>Jason Thorpe <thorpej@nas.nasa.gov> writes:
>
>> > FWIW, the CardBus code doesn't work right on my Dell Inspiron 3500, either

And it doesn't work right on a Vaio F350, where (like the 505-tx)
the CardBus bridge isnt getting assigned an IRQ by the BIOS.

A legacy-mode(?) pcic0 gets attached with pcmcia0 and pcmcia1
as children,  then attaches two sub-functions of the CardBus
bridge as cbb0 and cbb1:

	pcic0 at isa0 port 0x3e0-0x3e1  (irq 3
	pcmcia0 at pcic0
	pcmcia1 at pcic0

	cbb0 at  pc10 dev 10 function 0		(irq not set by bios,)
	cbb1 at  pc10 dev 10 function 1		(kludged up by pccbb.c)
	...
	cardslot0 at cbb0
	cardbus1 at cardslot0
	pcmcia2 at cardslot0

	cardslot1 at cbb1
	cardbus1 at cardslot1
	pcmcia3 at cbb1

So for example, a 3c589 in slot 0 ends up at both ep1 at pcmcia0
and as ep2 at pcmcia2.  Neither of which seem to work: they can send
packets, but dont interrupt on reception.

pccbb.c does at least notice the bridge didn't get an IRQ and
hardcodes it to IRQ 10. That didn't work for me[*], but neither did
changing it to 3 (edge/level conflict) or 11. Neither did the patch I
got from Soren Jorvang <soren@wheel.dk>.

Plus, after touching the pci-cardbus bridge the legacy I/O no longer
works, and I have ot powercycle to get the BIOS to reset the brdige.

[*] I think the USB chip on this Vaio is hardcoded at IRQ10, but it
didnt autoconfigure; I got "uhci0: can't map I/O space", so I assume
the darn Phoenix BIOS didn't set up I/O space for the USB chip, either.


MI PCI enumeration would be really nice. So would an (MD) way to probe
to see which IRQs a bridge can acutally generate interrupts at.

Are Uchiyama-san's PCI-BIOS patches in
 ftp://f77.nop.or.jp/users/uch/PCI/PCIBIOS-NetBSD-1.4L-991017.patch.gz
a useful fix for any of this -- at least on i386?