From owner-freebsd-hackers Mon Sep 15 00:55:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA10173 for hackers-outgoing; Mon, 15 Sep 1997 00:55:21 -0700 (PDT) Received: from vipunen.hut.fi (root@vipunen.hut.fi [130.233.224.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA10166 for ; Mon, 15 Sep 1997 00:55:17 -0700 (PDT) Received: from dol-guldur.hut.fi (will@dol-guldur.hut.fi [130.233.224.39]) by vipunen.hut.fi (8.8.7/8.8.7) with ESMTP id KAA42292 for ; Mon, 15 Sep 1997 10:55:06 +0300 Received: (will@localhost) by dol-guldur.hut.fi (8.8.3/8.6.7) id KAA18816; Mon, 15 Sep 1997 10:55:04 +0300 (EET DST) Date: Mon, 15 Sep 1997 10:55:04 +0300 (EET DST) Message-Id: <199709150755.KAA18816@dol-guldur.hut.fi> From: Ville-Pertti Keinonen To: freebsd-hackers@freebsd.org Subject: PCI device I/O mappings Reply-To: will@iki.fi Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've had some problems (now "sort of" solved) getting the XFree86 3.3/3.3.1 S3-server to work simultaneously with an AHA-3985W RAID controller (used as a plain SCSI controller, of course). It appears that the problems were not caused by FreeBSD, perhaps it isn't all that relevant to this mailing list, but it could be fixed in the kernel. What I'm not quite certain about is what the correct solution would be... The relevant parts of my hardware configuration consist of a Soyo 5TH5 motherboard (430HX, Award BIOS) with two Pentium CPUs, a Diamond Stealth64 Video 3200 card (S3 968 + 2MB VRAM) and the AHA-3985W (a PCI-PCI bridge, three aic7870s and an aic7810). Various kernel versions and configurations behave differently: FreeBSD 2.2.2 kernel.GENERIC - ahc works, X doesn't. A kernel without an ahc driver, X works. FreeBSD 3.0 970815 kernel.GENERIC - ahc works, X doesn't. kernel.SMP-GENERIC - X works, ahc doesn't. An SMP kernel with interrupt numbers "manually" fixed (to fix APIC interrupts over the PCI bridge), ahc works, X doesn't... FreeBSD 3.0-current (at src-cur ctm 3046) Works like 970815-SNAP... When the XF86_S3-server was run the system would hang with a blank screen (-probeonly *did* work) with no panic visible (I used sio0 as the console). If the system was running off a SCSI-disk, a timeout error would appear, so there was *some* functionality left, but leaving a sleep+reboot or shutdown in the background didn't help, the reset button seemed the only way out... The system hang seemed to be independent of whether the SCSI adapter was actually being used. Being configured with the correct interrupts was enough to screw things up. After experimenting with the X server for a while (booting the machine lots of times) I found that the SCSI adapter (along with most other functionality in the system) stopped when a write to the PIX_TRANS (0xe2e8) register occurred. Looking at the verbose boot output from FreeBSD for the PCI devices found (piix junk excluded): found-> vendor=0x1011, dev=0x0001, revid=0x02 class=06-04-00, hdrtype=0x01, mfdev=0 chip2: rev 0x02 on pci0.14.0 Freeing (NOT implemented) redirected PCI irq 9. found-> vendor=0x5333, dev=0x88f0, revid=0x00 class=03-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=19 map[0]: type 1, range 32, base e0000000, size 25 vga0: rev 0x00 int a irq 19 on pci0.17.0 Probing for devices on PCI bus 1: Freeing (NOT implemented) redirected PCI irq 11. found-> vendor=0x9004, dev=0x7378, revid=0x03 class=01-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=16 map[0]: type 4, range 32, base 0000e000, size 8 map[1]: type 1, range 32, base d0000000, size 12 ahc0: rev 0x03 int a irq 16 on pci1.4.0 ahc0: Reading SEEPROM...done. low byte termination enabled, high byte termination enabled ahc0: aic7870 Wide Channel A, SCSI Id=7, 16 SCBs ahc0: Resetting Channel A ahc0: Downloading Sequencer Program...ahc0: 369 instructions downloaded Done ahc0: Probing channel A ahc0: waiting for scsi devices to settle scbus0 at ahc0 bus 0 Freeing (NOT implemented) redirected PCI irq 10. found-> vendor=0x9004, dev=0x1078, revid=0x00 class=05-80-00, hdrtype=0x00, mfdev=0 intpin=a, irq=17 map[0]: type 4, range 32, base 0000e100, size 8 map[1]: type 1, range 32, base d0001000, size 12 map[2]: type 3, range 32, base df000000, size 21 ahc1: rev 0x00 int a irq 17 on pci1.5.0 RAID functionality unsupported Freeing (NOT implemented) redirected PCI irq 11. found-> vendor=0x9004, dev=0x7378, revid=0x03 class=01-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=16 map[0]: type 4, range 32, base 0000e200, size 8 map[1]: type 1, range 32, base d0002000, size 12 ahc2: rev 0x03 int a irq 16 on pci1.8.0 using shared irq16. ahc2: Reading SEEPROM...done. low byte termination enabled, high byte termination enabled ahc2: aic7870 Wide Channel B, SCSI Id=7, 16 SCBs ahc2: Resetting Channel A ahc2: Downloading Sequencer Program...ahc2: 369 instructions downloaded Done ahc2: Probing channel A ahc2: waiting for scsi devices to settle scbus1 at ahc2 bus 0 ahc2: target 0 using 16Bit transfers ahc2: target 0 synchronous at 10.0MHz, offset = 0x8 sd0 at scbus1 target 0 lun 0 sd0: type 0 fixed SCSI 2 sd0: Direct-Access 4134MB (8467200 512 byte sectors) sd0: with 8205 cyls, 6 heads, and an average 171 sectors/track Freeing (NOT implemented) redirected PCI irq 11. found-> vendor=0x9004, dev=0x7378, revid=0x03 class=01-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=16 map[0]: type 4, range 32, base 0000e300, size 8 ahc3: rev 0x03 int a irq 16 on pci1.12.0 ahc3: Reading SEEPROM...done. low byte termination enabled, high byte termination enabled ahc3: aic7870 Wide Channel C, SCSI Id=7, 16 SCBs ahc3: Resetting Channel A ahc3: Downloading Sequencer Program...ahc3: 369 instructions downloaded Done ahc3: Probing channel A ahc3: waiting for scsi devices to settle scbus2 at ahc3 bus 0 PIX_TRANS is in ahc2's I/O space, no wonder it got confused. But isn't the S3 newmmio driver being used supposed to use memory mapped I/O? It does, except for the SET_PIX_TRANS_W and SET_PIX_TRANS_L macros (the latter is never used). I was able to get the X server to work by modifying the SET_PIX_TRANS_W macro to use memory mapped I/O in the newmmio driver and by disabling the check for some Trio32 bug which explicitly called s3ImageWriteNoMem. This obviously isn't the correct way to fix the problem, since it doesn't work for the generic driver. What is the real problem? Is it: - The S3 card not indicating use of I/O space? - The X server assuming knowledge of I/O registers? - The BIOS configuring the I/O space for PCI devices wrong? - The AHA-3985W requiring strange bits of I/O space? Or something else? What is the correct solution? (Should FreeBSD to know how to re-configure PCI devices?)