Date: Mon, 29 Sep 1997 08:45:23 +0200 From: Stefan Esser <se@FreeBSD.ORG> To: will@iki.fi Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Conflicting I/O address spaces -- caused by...? Message-ID: <19970929084523.37780@mi.uni-koeln.de> In-Reply-To: <199709281110.OAA04780@dol-guldur.hut.fi>; from Ville-Pertti Keinonen on Sun, Sep 28, 1997 at 02:10:25PM %2B0300 References: <199709281110.OAA04780@dol-guldur.hut.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 28, Ville-Pertti Keinonen <will@cc.hut.fi> wrote: > I posted a question regarding this issue on freebsd-hackers several > weeks ago and haven't received any kind of response, so I'm posting Sorry, I had seen your message, but did not have time to respond (had quit reading mail for more than one week because of paid work demanding all my energy ...) [ This is now CCed to the mail list where you originally posted your question ... ] > this to you directly hoping that you're the right person to answer my > question... The problem doesn't seem to be caused by FreeBSD, but > could possibly be fixed in the PCI code. OK. We'll see ... > For some reason, my Diamond Stealth64 Video 3200 and Adaptec AHA-3985W > are getting overlapping I/O address spaces. More specifically, the > topmost S3 register (the registers appear to have fixed I/O addresses > between 0x2e8 and 0xe2ea, mostly 0x??e8, where 0xe2e8 is the problem) > is located in the middle of I/O register space used by one of the > channels on the SCSI adapter. Hmmm, yes, the S3 chips are known to decode those addresses, and often conflict with a fourth UART (sio3) at 0x2e8, IIRC ... > This was causing the system to lock up when the X server (XFree86 3.3 > and XFree86 3.3.1, S3 server) was started whenever the SCSI adapter > driver was configured in the kernel (it appeared to depend on whether > it had its interrupt handlers registered correctly...) with several > FreeBSD versions (2.2.2, some 3.0 snapshot and -current) with and > without SMP. > > The problem was occurring even when the X server was supposed to be > using memory mapped I/O -- for some reason, the one problematic > register was being accessed using outw even though a memory mapped > equivalent was available... I changed it and now the X server works > in newmmio mode. However, this is obviously only a workaround, the > real problem still remains... You better ask this on a xfree86 list, but I seem to remember, that the X server *has to* use that port. > Here's the relevant portion of boot -v info (a somewhat current > SMP kernel, kludged to get the right IRQs for the AHA-3985W): > chip2: <DEC 21050 PCI-PCI bridge> rev 0x02 on pci0.14.0 Just BTW: That bridge chip is not PCI 2.1 compliant, and may cause system hangs in various (unlikely but not impossible) situations. > 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 The VGA does really only claim one memory range. There once was a bug in the S3 968 chip, which made it request only half the memory range it actually decodes, but this should have been fixed in more recent chips ... > Probing for devices on PCI bus 1: You are *behind* the PCI to PCI bridge now! > 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 > 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 > 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 As you observed, that Adaptec chip decodes 0xe200 up to 0xe2ff and thus overlaps with the addresses claimed by the S3 card. > 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 > As you can see, the S3 card isn't indicating any use of I/O address > space and 0xe2e8 is in the I/O space of channel B (which also happens > to be the only channel with anything currently connected, but that > doesn't affect the lockup behavior, it occurs without any devices > connected). Yes. Absolutely correct. > These are the only PCI cards I have installed, I also tried moving the > graphics card around earlier when I thought interrupts were the > problem (it was sharing the interrupt used by the aic7810). The > motherboard is a Soyo 5TH5 (430HX, Award BIOS). > > The question is, where is the real problem and what is the correct > solution? My guess is that it would be the S3 card not indicating I/O > address usage (which can't really be solved), but it could also be the > BIOS or even the SCSI adapter (maybe it has fixed addresses, although > I strongly doubt it). However, I don't know how the PCI configuration > is done so I really can only guess... Well, the problem really appears to be the port addresses decoded by the S3, which have been choosen from within the ISA legacy port range, and thus should not be expected to be available to PCI devices. This caused problems with ISA UART cards before, but your conflict with a PCI card is new ;-) I think your PCI BIOS is at fault. When the PC was designed, the port range 0x0000 to 0x00ff was assigned to motherboard devices, and the range 0x0100 to 0x03ff to expansion cards, which often only decoded 10 bits of the port address, and thus were visible on each multiple of 1024 again. The PCI standard had to take this bogosity into consideration, and they defined the ISA MODE bit in the bridge control register, which will have the effect of blocking accesses to the secondary side for port addresses that don't have the 8th and 9th equal to 0. This makes the I/O space behind the bridge appear as non-contigous ranges of 256 port addresses, which caused the requirement, that no device should claim a port range of more than 256 bytes. Anyway, the PCI BIOS should have known about this and should have assigned port addresses 0xe000 to 0xe0ff, 0xe400 to 0x4ff, and so on to the Adaptec cards. In failing to do so, it assigned addresses that are known to cause problems as you observe. If the ISA MODE bit had been set, the PCI BIOS had been forced to only use addresses with bit 8 and 9 off, but the PCI BIOS does not seem to have set the 21050 chip into that mode. (You may want to check bit 18 of the result of pciconf -r pci0:14:0 0x3c which will read the bridge control and interrupt pin and line registers. If that bit is a 1, then ISA MODE is enabled, but I doubt it, you Adaptec card would not get accesses to 0xe100 to 0xe3ff forwarded to the SCSI chips through the bridge, then ...) Changing the port ranges from the values assigned by the BIOS to non-conflicting ones is not that easy, in general, since all PCI to PCI bridges upstream may have to be reprogrammed, and there may be conflicts with neighbour bridges, then. Using memory accesses to the Adaptec cards is a valid fix, though! Port addresses in PCI are only present for legacy device emulations, and for DOS which has no easy way to access memory mapped registers above 1MB. Justin Gibbs gave a good reason why he still uses port accesses (got to do with broken 21050 chips :) and the PCI BIOS deactivating memory accesses through them ...) So, your primary problem is the assignment of port addresses to the Adaptec chips, which fall into ranges that are known to cause conflicts with ISA cards. And while re-assigning those addresses is at least technically possible in the PCI code, I do not want to add such code. You seem to be the first one to report that problem, because it only happens, if there are 4 chips with port maps behind the bridge, and this appears not to be a common thing ... Complain to your motherboard vendor, explain the situation, and see whether they are able to provide a fix. Using memory mapped accesses through that PCI bridge may cause system hangs, but only if one of several possible scenarios exists on your system. They cause dead-lock, or even delivery of wrong data, with a very low probability. Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970929084523.37780>