From owner-freebsd-current Sat Jan 6 17: 7:35 2001 From owner-freebsd-current@FreeBSD.ORG Sat Jan 6 17:07:17 2001 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 14C6237B400 for ; Sat, 6 Jan 2001 17:07:17 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id UAA14929 for ; Sat, 6 Jan 2001 20:07:16 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.1/8.9.1) id f0717F488044; Sat, 6 Jan 2001 20:07:15 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 6 Jan 2001 20:07:15 -0500 (EST) To: freebsd-current@freebsd.org Subject: holy buses & user-level pci access problem X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14935.49104.217145.400932@grasshopper.cs.duke.edu> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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: on irongate0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci2: on pcib1 pci2: at 5.0 isab0: 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 hdr=0x00 alpm0@pci0:17:0: class=0x000000 card=0x00000000 chip=0x710110b9 rev=0x00 hdr=0x00 vga_pci0@pci2:5:0: class=0x030000 card=0x0a351048 chip=0x3d07104c rev=0x11 hdr=0x00 # pciconf -r pci2:5:0 0 pciconf: ioctl(PCIOCREAD): Operation not supported by device # pciconf -r pci1:5:0 0 0x3d07104c Wow. 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? Thanks, Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message