Hi all,
Earlier I posted a message to this list, saying that I had some problems
using a QLogic SCSI card and a Dolphin PCI-SCI card on the same PCI bus.
The system I used was a Compaq DS-10 466MHz (Tsunami chipset)
Recently I got a DP264 with two 667MHz EV67's (still Tsunami chipset).
The motherboard has an onboard Adaptec 7890 (64 bit) SCSI controller
attached to PCI bus 0 (On this system there are two Pchips).
If the Doplhin PCI-SCI card was in the same PCI bus as the SCSI chip the
system wouldn't boot (the SCSI driver just looped in resetting the SCSI
bus). When I moved the PCI-SCI card to the other bus the problem
disappeared, but on this bus there was also a Ethernet card (a 3com
Cyclone card) and sometimes I experienced lockups.
The Dolphin PCI-SCI card contains a chip called a PSB (PCI-SCI Bridge)
wich is connected to the PCI bus. This chip is reported as a
PCI_CLASS_BRIDGE_OTHER (0x680). The function of the SCI card is to 'map'
remote memory (memory on another machine) to local adresses, so that you
can read from and write to the remote machine (a very efficient way of
Message passing +120MB/s). Thus the PSB chip has two Memory regions in
PCI space, one small for CSR accesses, and one large (typically 256MB)
for remote memory access.
So, here is the problem:
When the machine is powered on, the Dolphin SCI card gets a PCI base
address for the large memory region from SRM which is 0x40000000 (1GB).
Since this device reports as a PCI_CLASS_BRIDGE_OTHER, the base address
is not changed when the Linux Kernel does a bus layout (in bios32.c).
The base address set up by SRM (0x40000000) is the same address as the
DMA window used when PCI devices shall access physical memory on the
Tsunami chipset. Thus when PCI devices try to access physical memory
matching the size and base of the SCI card (physical memory range 0 -
256MB), i.e ethernet chips accessing skb_buffers and SCSI cards
transferring data, the PCI -> memory access is actually redirected to
the Dolphin SCI card. This is the reson for all my lockups.
I have patched the 2.2.14 kernel in bios32.c (attached) to do a device
layout even on devices reported as PCI_CLASS_BRIDGE_OTHER, so that I
avoid the problem. My question is then, should this patch go into the
original kernel source ??? I think it should.
Another issue is the 2.4 kernel, I have not tested with this kernel, but
from what I've seen I think it should be OK.
Best Regards
--
Steffen Persvold Systems Engineer
Email : mailto:[EMAIL PROTECTED] Scali AS (http://www.scali.com)
Tlf : (+47) 22 62 89 50 Olaf Helsets vei 6
Fax : (+47) 22 62 89 51 N-0621 Oslo, Norway
--- linux/arch/alpha/kernel/bios32.c Tue Jan 4 19:12:11 2000
+++ linux.sci/arch/alpha/kernel/bios32.c Fri Jun 23 20:50:16 2000
@@ -709,6 +709,7 @@
for (dev = bus->devices; dev; dev = dev->sibling) {
if ((dev->class >> 16 != PCI_BASE_CLASS_BRIDGE) ||
+ (dev->class >> 8 == PCI_CLASS_BRIDGE_OTHER) ||
(dev->class >> 8 == PCI_CLASS_BRIDGE_PCMCIA)) {
disable_dev(dev);
}
@@ -721,6 +722,7 @@
for (dev = bus->devices; dev; dev = dev->sibling) {
if ((dev->class >> 16 != PCI_BASE_CLASS_BRIDGE) ||
+ (dev->class >> 8 == PCI_CLASS_BRIDGE_OTHER) ||
(dev->class >> 8 == PCI_CLASS_BRIDGE_PCMCIA)) {
layout_dev(dev);
}
@@ -958,6 +960,7 @@
*/
for (dev = pci_devices; dev; dev = dev->next) {
if ((dev->class >> 16 == PCI_BASE_CLASS_BRIDGE) &&
+ (dev->class >> 8 != PCI_CLASS_BRIDGE_OTHER) &&
(dev->class >> 8 != PCI_CLASS_BRIDGE_PCMCIA))
continue;
