When trying to figure out a bizzare failure of the X server on my
UP1000, I found a bug in the user-level pci bus code.   This machine
is rather wacky in that it has 2 busses: 0 and 2.  0 is the pci bus,
2 is the AGP bus, behind the AMD-751 host-pci bridge (pcib1):

pcib0: <AMD 751 PCI host bus adapter> on irongate0
pci0: <PCI bus> on pcib0
pcib1: <AMD-751 PCI-PCI (AGP) bridge> at device 1.0 on pci0
pci2: <PCI bus> on pcib1
pci2: <VGA-compatible display device> at 5.0
isab0: <AcerLabs M1533 portable PCI-ISA bridge> at device 7.0 on pci0

# pciconf -l
none0@pci0:0:0: class=0x060000 card=0x00000000 chip=0x70061022 rev=0x25 hdr=0x00
pcib1@pci0:1:0: class=0x060400 card=0x00000000 chip=0x70071022 rev=0x01 hdr=0x01
isab0@pci0:7:0: class=0x060100 card=0x00000000 chip=0x153310b9 rev=0xc3 hdr=0x00
dc0@pci0:9:0:   class=0x020000 card=0x500b1011 chip=0x00191011 rev=0x30 hdr=0x00
sym0@pci0:10:0: class=0x010000 card=0x00000000 chip=0x000f1000 rev=0x04 hdr=0x00
fxp0@pci0:11:0: class=0x020000 card=0x00018086 chip=0x12298086 rev=0x02 hdr=0x00
atapci0@pci0:16:0:      class=0x0101fa card=0x00000000 chip=0x522910b9 rev=0xc1 
alpm0@pci0:17:0:        class=0x000000 card=0x00000000 chip=0x710110b9 rev=0x00 
vga_pci0@pci2:5:0:      class=0x030000 card=0x0a351048 chip=0x3d07104c rev=0x11 
# pciconf -r pci2:5:0 0
pciconf: ioctl(PCIOCREAD): Operation not supported by device
# pciconf -r pci1:5:0 0


Note that by doing PCIOREADs of the DEVVENDOR, the graphics card is
found at 1:5:0 and not 2:5:0 -- this confuses the hell out of the
XFree86 resource mapping code, since there isn't a bus 1 on this
system.  It tries to remap the card into the memory space of bus 0 and
fails miserably.

I've got a special-case hack to the XFree86-4 port that I could commit 
(lie to the resource code and tell it the bridge is a bridge to bus1), 
but I'd rather have it fixed correctly.

I think this (in sys/dev/pci/pci_user.c) is the culprit:
                         * Assume that the user-level bus number is
                         * actually the pciN instance number. We map
                         * from that to the real pcib+bus combination.
But I'm at a loss as to how to fix this bug and not introduce a binary 
incompatability by adding a hose field to struct pcisel in pciio.h

Can anybody with more newbus fu than me help me out here?  



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to