Date: Mon, 15 Sep 1997 10:55:04 +0300 (EET DST) From: Ville-Pertti Keinonen <will@cc.hut.fi> To: freebsd-hackers@freebsd.org Subject: PCI device I/O mappings Message-ID: <199709150755.KAA18816@dol-guldur.hut.fi>
next in thread | raw e-mail | index | archive | help
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: <DEC 21050 PCI-PCI bridge> 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: <VGA-compatible display device> 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: <Adaptec 398X SCSI RAID adapter> 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: <Adaptec aic7810 RAID memory controller> 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: <Adaptec 398X SCSI RAID adapter> 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: <IBM DCAS-34330W S65A> 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: <Adaptec 398X SCSI RAID adapter> 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?)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709150755.KAA18816>