Problem with Adaptec 4-port fast Ethernet in AlphaPC
Jay.Estabrook@digital.com
Jay.Estabrook@digital.com
Fri Sep 18 17:19:53 1998
>>> Quant-X Alpha Linux Support said:
>
> At moment, it seems that both ANA-6944A/TX and Intraserver ITI-5232E
> do not work under AXP-Linux (even under 2.1.122-rth-18).
> This is _not_ a tulip problem, it's IMHO a PCI problem under
> Linux/AXP.
That's correct, but only certain boxes, I believe, and perhaps not under
both SRM and AlphaBIOS on the same box. I'll explain below...
> If anybody has such a card work under Linux/AXP; speak now
> (which board, which console, which kernel, which tulip/de4x5)
> or be quiet forever... ;-(
I do, mostly; DE504-BA, in a 533MHz LX164; see below for more detail...
> PS.: I've seen this on LX && SX boards, SRM && AlphaBIOS. And like
> you reported, it works without problems under Linux/i386.
OK, here's my current knowledge of the problems:
We are actually seeing two (2) problems, that may be related, but show up as
very different symptoms. The first is the PYXIS machine checks, for which I
still have no solution, and this worries me (see below).
The second problem is non-recognition of the devices behind the 21152 bridge
on the card, by the LINUX drivers. This I have a handle on, and the fix is
included at the end of this Email. Here's the technical explanation:
It's a combination of the 21152 bridge, the SRM/AlphaBIOS console PCI setup
code, and the LINUX PCI setup code. The 21152 allows the passing of a full
32-bit I/O space address across the bridge (the older 21052 supported only
16-bit addresses, ie < 64K). The new console code sets up the bridge so that
the I/O space addresses of the devices behind the bridge are above 64K,
using an additional register on the bridge. The LINUX PCI setup code did not
know about the additional register, and assumed only 16-bit addresses would
be passed. So the bridge remainded setup to pass addresses that the LINUX
kernel would not be told to use to talk to those devices.
The fix at the end simply makes sure that the additional register on the
21152 bridge is cleared, so that it *will* pass the addresses correctly for
the devices behind it.
Now, all that simply lets the drivers access the I/O space registers of the
devices behind the bridge, and this allows the drivers to detect and attempt
to use those devices. However, an analysis of the PYXIS machines checks
identifies the problem as affecting WRITEs to some of the PCI config space
registers of the device behind the bridge. It may be that a WRITE does not
complete correctly, meaning that a register that the driver thought needed
to have a certain value, really doesn't. In this way, it's very possible
that the device will not operate as the driver expects. So even though the
driver is now able to see and work with the device, not everything it has
done to the device may have taken place.
Also, in testing, I had much better luck using the DE4X5 driver than
tulip.c; the version of the former was 0.535, the latter 0.89H. I didn't do
much more than look to see that it was working, ie no performance estimates
at all, just look to see that "ping" works... ;-}
Good luck, hope this is helpful. I'll continue looking into the PYXIS
problem over the weekend; please share any experiences you may have...
--Jay++
-----------------------------------------------------------------------------
American Non Sequitur Society: we don't make sense, but we do like pizza...
Jay A Estabrook Alpha Motherboards - LINUX Project
Compaq Computer Corp. (508) 841-3241 or (DTN) 237-3241
334 South Street, Shrewsbury, MA 01545 Jay.Estabrook@digital.com
-----------------------------------------------------------------------------
diff -u /ksrc/TEMP/rth-122-18/arch/alpha/kernel/bios32.c bios32.c
--- /ksrc/TEMP/rth-122-18/arch/alpha/kernel/bios32.c Thu Sep 17 22:59:12 1998
+++ bios32.c Thu Sep 17 23:09:47 1998
@@ -715,8 +715,21 @@
0x1c, &l);
l &= 0xffff0000;
l |= ((bio >> 8) & 0x00f0) | ((tio - 1) & 0xf000);
- pcibios_write_config_dword(bridge->bus->number, bridge->devfn,
- 0x1c, l);
+ pcibios_write_config_dword(bridge->bus->number,
+ bridge->devfn, 0x1c, l);
+
+ /*
+ * If it is a 21152, we also need to clear out the register
+ * used to hold the upper 16 bits of the I/O base and limit.
+ * That is, unless/until we actual start allocating I/O space
+ * addresses above 64K (0x10000)... ;-}
+ */
+ if (bridge->vendor == PCI_VENDOR_ID_DEC &&
+ bridge->device == PCI_DEVICE_ID_DEC_21152)
+ {
+ pcibios_write_config_dword(bridge->bus->number,
+ bridge->devfn, 0x30, 0);
+ }
/*
* Set up the top and bottom of the PCI Memory segment
* for this bus.
-----------------------------------------------------------------------------