DragonFlyBSD

:So now that NATA works on my laptop, I noticed that my cardbus rl(4)
:adapter gets no longer recognized, apparently due to PCI_MAP_FIXUP being
:in my config now.
:
:Removing PCI_MAP_FIXUP will lead to rl being recognized again in the
:dmesg but fail upon attachment of ata0 and ata1:
:
:ata0.atapci0.pci0.pcib0.legacypci0.nexus0.root0
:ata0: <ATA channel 0> [tentative] on atapci0
:device_probe_and_attach: ata0 attach returned 6
:ata1.atapci0.pci0.pcib0.legacypci0.nexus0.root0
:ata1: <ATA channel 1> [tentative] on atapci0
:device_probe_and_attach: ata1 attach returned 6
:..
:lo0: bpf attached
:bootdev: a0200000 type=0 unit=0 slice=2 part=0 major=3
:no such device 'ad'
:..
:Sascha

This may seem strange, but do you have the same rl recognition
    problem if you turn on PCI_MAP_FIXUP but use ATA instead of NATA?
    If so then could you generate the verbose dmesg output with ATA with
    PCI_MAP_FIXUP and ATA without PCI_MAP_FIXUP and post the two URLs?

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

Hmm,

dmesg of ATA without PCI_MAP_FIXUP is here:

http://87.78.98.243/tmp/dmesg.boot

However, an ATA kernel with PCI_MAP_FIXUP will fail with:

.
ata0: probe allocation failed
ata1: probe allocation failed
.

and end up at "mountroot>" (similar to NATA without PCI_MAP_FIXUP).

It will not recognize the rl either. The "found-> vendor=0x10ec,
dev=0x8139, revid=0x10" and all following lines having to do with it
don't appear at all.

I could take photos of the ATA w/ PCI_MAP_FIXUP dmesg it if you tell me
which parts you are interested in.

Sascha

The following patch kindly provided by sephe fixes this issue for me:

http://leaf.dragonflybsd.org/~sephe/pcib.diff

Thanks sephe!

Sascha