| 1 |
1275 |
phoenix |
Originally, this driver was written for the Digital Equipment
|
| 2 |
|
|
Corporation series of EtherWORKS Ethernet cards:
|
| 3 |
|
|
|
| 4 |
|
|
DE425 TP/COAX EISA
|
| 5 |
|
|
DE434 TP PCI
|
| 6 |
|
|
DE435 TP/COAX/AUI PCI
|
| 7 |
|
|
DE450 TP/COAX/AUI PCI
|
| 8 |
|
|
DE500 10/100 PCI Fasternet
|
| 9 |
|
|
|
| 10 |
|
|
but it will now attempt to support all cards which conform to the
|
| 11 |
|
|
Digital Semiconductor SROM Specification. The driver currently
|
| 12 |
|
|
recognises the following chips:
|
| 13 |
|
|
|
| 14 |
|
|
DC21040 (no SROM)
|
| 15 |
|
|
DC21041[A]
|
| 16 |
|
|
DC21140[A]
|
| 17 |
|
|
DC21142
|
| 18 |
|
|
DC21143
|
| 19 |
|
|
|
| 20 |
|
|
So far the driver is known to work with the following cards:
|
| 21 |
|
|
|
| 22 |
|
|
KINGSTON
|
| 23 |
|
|
Linksys
|
| 24 |
|
|
ZNYX342
|
| 25 |
|
|
SMC8432
|
| 26 |
|
|
SMC9332 (w/new SROM)
|
| 27 |
|
|
ZNYX31[45]
|
| 28 |
|
|
ZNYX346 10/100 4 port (can act as a 10/100 bridge!)
|
| 29 |
|
|
|
| 30 |
|
|
The driver has been tested on a relatively busy network using the DE425,
|
| 31 |
|
|
DE434, DE435 and DE500 cards and benchmarked with 'ttcp': it transferred
|
| 32 |
|
|
16M of data to a DECstation 5000/200 as follows:
|
| 33 |
|
|
|
| 34 |
|
|
TCP UDP
|
| 35 |
|
|
TX RX TX RX
|
| 36 |
|
|
DE425 1030k 997k 1170k 1128k
|
| 37 |
|
|
DE434 1063k 995k 1170k 1125k
|
| 38 |
|
|
DE435 1063k 995k 1170k 1125k
|
| 39 |
|
|
DE500 1063k 998k 1170k 1125k in 10Mb/s mode
|
| 40 |
|
|
|
| 41 |
|
|
All values are typical (in kBytes/sec) from a sample of 4 for each
|
| 42 |
|
|
measurement. Their error is +/-20k on a quiet (private) network and also
|
| 43 |
|
|
depend on what load the CPU has.
|
| 44 |
|
|
|
| 45 |
|
|
=========================================================================
|
| 46 |
|
|
|
| 47 |
|
|
The ability to load this driver as a loadable module has been included
|
| 48 |
|
|
and used extensively during the driver development (to save those long
|
| 49 |
|
|
reboot sequences). Loadable module support under PCI and EISA has been
|
| 50 |
|
|
achieved by letting the driver autoprobe as if it were compiled into the
|
| 51 |
|
|
kernel. Do make sure you're not sharing interrupts with anything that
|
| 52 |
|
|
cannot accommodate interrupt sharing!
|
| 53 |
|
|
|
| 54 |
|
|
To utilise this ability, you have to do 8 things:
|
| 55 |
|
|
|
| 56 |
|
|
0) have a copy of the loadable modules code installed on your system.
|
| 57 |
|
|
1) copy de4x5.c from the /linux/drivers/net directory to your favourite
|
| 58 |
|
|
temporary directory.
|
| 59 |
|
|
2) for fixed autoprobes (not recommended), edit the source code near
|
| 60 |
|
|
line 5594 to reflect the I/O address you're using, or assign these when
|
| 61 |
|
|
loading by:
|
| 62 |
|
|
|
| 63 |
|
|
insmod de4x5 io=0xghh where g = bus number
|
| 64 |
|
|
hh = device number
|
| 65 |
|
|
|
| 66 |
|
|
NB: autoprobing for modules is now supported by default. You may just
|
| 67 |
|
|
use:
|
| 68 |
|
|
|
| 69 |
|
|
insmod de4x5
|
| 70 |
|
|
|
| 71 |
|
|
to load all available boards. For a specific board, still use
|
| 72 |
|
|
the 'io=?' above.
|
| 73 |
|
|
3) compile de4x5.c, but include -DMODULE in the command line to ensure
|
| 74 |
|
|
that the correct bits are compiled (see end of source code).
|
| 75 |
|
|
4) if you are wanting to add a new card, goto 5. Otherwise, recompile a
|
| 76 |
|
|
kernel with the de4x5 configuration turned off and reboot.
|
| 77 |
|
|
5) insmod de4x5 [io=0xghh]
|
| 78 |
|
|
6) run the net startup bits for your new eth?? interface(s) manually
|
| 79 |
|
|
(usually /etc/rc.inet[12] at boot time).
|
| 80 |
|
|
7) enjoy!
|
| 81 |
|
|
|
| 82 |
|
|
To unload a module, turn off the associated interface(s)
|
| 83 |
|
|
'ifconfig eth?? down' then 'rmmod de4x5'.
|
| 84 |
|
|
|
| 85 |
|
|
Automedia detection is included so that in principle you can disconnect
|
| 86 |
|
|
from, e.g. TP, reconnect to BNC and things will still work (after a
|
| 87 |
|
|
pause whilst the driver figures out where its media went). My tests
|
| 88 |
|
|
using ping showed that it appears to work....
|
| 89 |
|
|
|
| 90 |
|
|
By default, the driver will now autodetect any DECchip based card.
|
| 91 |
|
|
Should you have a need to restrict the driver to DIGITAL only cards, you
|
| 92 |
|
|
can compile with a DEC_ONLY define, or if loading as a module, use the
|
| 93 |
|
|
'dec_only=1' parameter.
|
| 94 |
|
|
|
| 95 |
|
|
I've changed the timing routines to use the kernel timer and scheduling
|
| 96 |
|
|
functions so that the hangs and other assorted problems that occurred
|
| 97 |
|
|
while autosensing the media should be gone. A bonus for the DC21040
|
| 98 |
|
|
auto media sense algorithm is that it can now use one that is more in
|
| 99 |
|
|
line with the rest (the DC21040 chip doesn't have a hardware timer).
|
| 100 |
|
|
The downside is the 1 'jiffies' (10ms) resolution.
|
| 101 |
|
|
|
| 102 |
|
|
IEEE 802.3u MII interface code has been added in anticipation that some
|
| 103 |
|
|
products may use it in the future.
|
| 104 |
|
|
|
| 105 |
|
|
The SMC9332 card has a non-compliant SROM which needs fixing - I have
|
| 106 |
|
|
patched this driver to detect it because the SROM format used complies
|
| 107 |
|
|
to a previous DEC-STD format.
|
| 108 |
|
|
|
| 109 |
|
|
I have removed the buffer copies needed for receive on Intels. I cannot
|
| 110 |
|
|
remove them for Alphas since the Tulip hardware only does longword
|
| 111 |
|
|
aligned DMA transfers and the Alphas get alignment traps with non
|
| 112 |
|
|
longword aligned data copies (which makes them really slow). No comment.
|
| 113 |
|
|
|
| 114 |
|
|
I have added SROM decoding routines to make this driver work with any
|
| 115 |
|
|
card that supports the Digital Semiconductor SROM spec. This will help
|
| 116 |
|
|
all cards running the dc2114x series chips in particular. Cards using
|
| 117 |
|
|
the dc2104x chips should run correctly with the basic driver. I'm in
|
| 118 |
|
|
debt to for the testing and feedback that helped get
|
| 119 |
|
|
this feature working. So far we have tested KINGSTON, SMC8432, SMC9332
|
| 120 |
|
|
(with the latest SROM complying with the SROM spec V3: their first was
|
| 121 |
|
|
broken), ZNYX342 and LinkSys. ZNYX314 (dual 21041 MAC) and ZNYX 315
|
| 122 |
|
|
(quad 21041 MAC) cards also appear to work despite their incorrectly
|
| 123 |
|
|
wired IRQs.
|
| 124 |
|
|
|
| 125 |
|
|
I have added a temporary fix for interrupt problems when some SCSI cards
|
| 126 |
|
|
share the same interrupt as the DECchip based cards. The problem occurs
|
| 127 |
|
|
because the SCSI card wants to grab the interrupt as a fast interrupt
|
| 128 |
|
|
(runs the service routine with interrupts turned off) vs. this card
|
| 129 |
|
|
which really needs to run the service routine with interrupts turned on.
|
| 130 |
|
|
This driver will now add the interrupt service routine as a fast
|
| 131 |
|
|
interrupt if it is bounced from the slow interrupt. THIS IS NOT A
|
| 132 |
|
|
RECOMMENDED WAY TO RUN THE DRIVER and has been done for a limited time
|
| 133 |
|
|
until people sort out their compatibility issues and the kernel
|
| 134 |
|
|
interrupt service code is fixed. YOU SHOULD SEPARATE OUT THE FAST
|
| 135 |
|
|
INTERRUPT CARDS FROM THE SLOW INTERRUPT CARDS to ensure that they do not
|
| 136 |
|
|
run on the same interrupt. PCMCIA/CardBus is another can of worms...
|
| 137 |
|
|
|
| 138 |
|
|
Finally, I think I have really fixed the module loading problem with
|
| 139 |
|
|
more than one DECchip based card. As a side effect, I don't mess with
|
| 140 |
|
|
the device structure any more which means that if more than 1 card in
|
| 141 |
|
|
2.0.x is installed (4 in 2.1.x), the user will have to edit
|
| 142 |
|
|
linux/drivers/net/Space.c to make room for them. Hence, module loading
|
| 143 |
|
|
is the preferred way to use this driver, since it doesn't have this
|
| 144 |
|
|
limitation.
|
| 145 |
|
|
|
| 146 |
|
|
Where SROM media detection is used and full duplex is specified in the
|
| 147 |
|
|
SROM, the feature is ignored unless lp->params.fdx is set at compile
|
| 148 |
|
|
time OR during a module load (insmod de4x5 args='eth??:fdx' [see
|
| 149 |
|
|
below]). This is because there is no way to automatically detect full
|
| 150 |
|
|
duplex links except through autonegotiation. When I include the
|
| 151 |
|
|
autonegotiation feature in the SROM autoconf code, this detection will
|
| 152 |
|
|
occur automatically for that case.
|
| 153 |
|
|
|
| 154 |
|
|
Command line arguments are now allowed, similar to passing arguments
|
| 155 |
|
|
through LILO. This will allow a per adapter board set up of full duplex
|
| 156 |
|
|
and media. The only lexical constraints are: the board name (dev->name)
|
| 157 |
|
|
appears in the list before its parameters. The list of parameters ends
|
| 158 |
|
|
either at the end of the parameter list or with another board name. The
|
| 159 |
|
|
following parameters are allowed:
|
| 160 |
|
|
|
| 161 |
|
|
fdx for full duplex
|
| 162 |
|
|
autosense to set the media/speed; with the following
|
| 163 |
|
|
sub-parameters:
|
| 164 |
|
|
TP, TP_NW, BNC, AUI, BNC_AUI, 100Mb, 10Mb, AUTO
|
| 165 |
|
|
|
| 166 |
|
|
Case sensitivity is important for the sub-parameters. They *must* be
|
| 167 |
|
|
upper case. Examples:
|
| 168 |
|
|
|
| 169 |
|
|
insmod de4x5 args='eth1:fdx autosense=BNC eth0:autosense=100Mb'.
|
| 170 |
|
|
|
| 171 |
|
|
For a compiled in driver, in linux/drivers/net/CONFIG, place e.g.
|
| 172 |
|
|
DE4X5_OPTS = -DDE4X5_PARM='"eth0:fdx autosense=AUI eth2:autosense=TP"'
|
| 173 |
|
|
|
| 174 |
|
|
Yes, I know full duplex isn't permissible on BNC or AUI; they're just
|
| 175 |
|
|
examples. By default, full duplex is turned off and AUTO is the default
|
| 176 |
|
|
autosense setting. In reality, I expect only the full duplex option to
|
| 177 |
|
|
be used. Note the use of single quotes in the two examples above and the
|
| 178 |
|
|
lack of commas to separate items.
|
