2091 lines
86 KiB
Plaintext
2091 lines
86 KiB
Plaintext
From: Paul Gortmaker <gpg109@rsphysse.anu.edu.au>
|
|
Newsgroups: comp.os.linux.announce,comp.os.linux.admin,comp.answers,news.answers
|
|
Subject: Linux Ethernet HOWTO (Part 1/2)
|
|
Keywords: Linux, Ethernet, TCP/IP, NET-2
|
|
Followup-To: poster
|
|
Approved: linux-announce@tc.cornell.edu (Matt Welsh)
|
|
|
|
Archive-Name: linux/howto/ethernet/part1
|
|
Last-Modified: November 16, 1993
|
|
|
|
Linux Ethernet HOWTO v0.3 -- Last updated November 6, 1993
|
|
=================================================================
|
|
INDEX:
|
|
|
|
(Part 1/2)
|
|
0 Introduction.
|
|
0.01 How do I use this Guide?
|
|
0.01 Disclaimer
|
|
0.02 Questions already?
|
|
0.03 Related Documentation
|
|
0.04 New Versions of this Document
|
|
0.05 Feedback
|
|
|
|
1 What card should I buy for Linux?
|
|
1.01 Eight bit vs 16 bit
|
|
1.02 Low price Ethernet cards
|
|
1.03 Vendors and brands to avoid.
|
|
1.04 Type of cable that your card should support
|
|
|
|
2 Status of various Ethernet cards under Linux.
|
|
2.01 3Com
|
|
2.02 Western Digital / SMC
|
|
2.03 NExxxx
|
|
2.04 Hewlett Packard Cards
|
|
2.05 D-Link
|
|
2.06 Cabletron
|
|
2.07 Allied Telesis
|
|
2.08 Arcnet
|
|
2.09 Digital / DEC
|
|
2.10 Intel
|
|
2.11 PureData
|
|
2.12 Xircom
|
|
2.13 Zenith
|
|
2.14 Racal-Interlan
|
|
2.15 AMD LANCE (79C960)
|
|
2.16 AT-Lan-Tec
|
|
|
|
3 Clones of popular Ethernet cards.
|
|
3.01 WD80x3 Clones
|
|
3.02 NE2000 Clones
|
|
|
|
4 Cables, coax, twisted pairs etc.
|
|
4.01 Thin Ethernet (thinnet)
|
|
4.02 Twisted Pair
|
|
4.03 Thick Ethernet
|
|
|
|
(Part 2/2)
|
|
5 Technical information.
|
|
5.01 Probed addresses
|
|
5.02 Skeleton / prototype driver
|
|
5.03 Driver interface to the kernel
|
|
5.04 Interrupts and linux
|
|
5.05 Programmed I/O vs. shared mem. vs slave/master DMA
|
|
5.06 Programming the Intel chips (i82586 and i82593)
|
|
5.07 Programming information from 3Com
|
|
5.08 Notes on AMD PCnet-ISA / LANCE Based cards (79C960)
|
|
5.09 Multicast and Promiscuous mode
|
|
5.10 The Berkely Packet Filter (BPF)
|
|
5.11 Unresolved questions / concerns
|
|
|
|
6 Possible problems, questions and troubleshooting.
|
|
6.01 Problems with NE2000 (and clones)
|
|
6.02 Problems with WD80*3 cards
|
|
6.03 Problems with 3Com cards
|
|
|
|
7 Networking with a laptop computer.
|
|
7.01 Option 1 -- using SLIP
|
|
7.02 Option 2 -- Built in NE2000 compatible or PCMCIA Ethercard.
|
|
7.03 Option 3 -- ISA Ethercard in the docking station.
|
|
7.04 Option 4 -- Pocket / parallel port adaptors.
|
|
|
|
8 Frequently asked questions.
|
|
8.01 Just the FAQ's ma'am -- just the FAQ's.
|
|
|
|
9 Miscellaneous.
|
|
9.01 The Cabletron story.
|
|
9.02 The Xircom story
|
|
9.03 Closing
|
|
|
|
======================================================================
|
|
|
|
0. Introduction.
|
|
|
|
This is the Ethernet-HOWTO, which is a compilation of information
|
|
about which ethernet devices can be used for Linux, and how to
|
|
set them up.
|
|
|
|
This Ethernet-HOWTO is by:
|
|
Donald J. Becker <becker@super.org>
|
|
Paul Gortmaker <gpg109@rsphysse.anu.edu.au>
|
|
|
|
It covers what cards you should and shouldn't buy; how to set
|
|
them up, how to run more than one, and other common problems and
|
|
questions. It does *not* cover the software end of things, as that
|
|
is covered in the NET-2 HOWTO. You can freely distribute this
|
|
document as long as you distribute an original copy with the
|
|
author's names intact.
|
|
|
|
Other people who have contributed (directly or indirectly) are,
|
|
in alphabetical order:
|
|
|
|
Peter Bauer <pbauer@rnivh.rni.sub.org>
|
|
Ross Biro <bir7@leland.Stanford.EDU>
|
|
Alan Cox <iiitac@pyr.swan.ac.uk>
|
|
Bjorn Ekwall <bj0rn@blox.se>
|
|
Mike Jagdis <jaggy@purplet.demon.co.uk>
|
|
Duke Kamstra <kamstra@ccmail.west.smc.com>
|
|
Russell Nelson <nelson@crynwr.com>
|
|
Cameron Spitzer <cls@truffula.sj.ca.us> <camerons@NAD.3Com.com>
|
|
Dave Roberts <david.roberts@amd.com>
|
|
Glenn Talbott <gt@hprnd.rose.hp.com>
|
|
Miquel van Smoorenburg <miquels@cistron.nl.mugnet.org>
|
|
|
|
Many thanks to the above people, and all the other unmentioned
|
|
testers out there.
|
|
|
|
0.01 How Do I Use This Guide?
|
|
|
|
As this guide is getting bigger and bigger, you probably don't want
|
|
to spend the rest of your afternoon reading the whole thing. And you
|
|
don't *have* to read it all. If you haven't got an ethernet card, then
|
|
you will want to start with section one to see what you should buy,
|
|
and what you should avoid. If you have already got an ethernet card,
|
|
but are not sure if you can use it with Linux, then you will want to
|
|
read section two, which contains specific information on each
|
|
manufacturer, and their cards. If you are having trouble with your
|
|
card, then you will want to read the specific information about
|
|
your card in section two and the troubleshooting information in
|
|
section six. If you are intersted in some of the technical aspects
|
|
of the device drivers, then you can find that information in
|
|
section 5.
|
|
|
|
0.01 Disclaimer
|
|
|
|
This document is *not* gospel. However, it is probably the most
|
|
up to date info that you will be able to find. Nobody is responsible
|
|
for what happens to your hardware but yourself. If your ethercard
|
|
or any other hardware goes up in smoke (...nearly impossible!)
|
|
we take no responsibility. ie. THE AUTHORS ARE NOT RESPONSIBLE
|
|
FOR ANY DAMAGES INCURRED DUE TO ACTIONS TAKEN BASED ON THE
|
|
INFORMATION INCLUDED IN THIS DOCUMENT.
|
|
|
|
0.02 Questions already?
|
|
|
|
If you have questions about your ethernet card, please READ this
|
|
document first. You may also want to join the NET channel of the
|
|
Linux-activists mailing list by sending mail to
|
|
linux-activists-request@niksula.hut.fi
|
|
with the line
|
|
X-Mn-Admin: join NET
|
|
at the top of the message body (not the subject). If you want to
|
|
learn how to use the mailing channels, then send an empty message
|
|
to the above address, and you will get an instruction manual sent
|
|
back to you in a few hours. However, it is worth noting that the NET
|
|
channel is primarily used for discussion of the networking code, and
|
|
you may not see much discussion about a particular driver.
|
|
Furthermore keep in mind that the NET channel is for development
|
|
discussions only. General questions on how to configure your system
|
|
should be directed to comp.os.linux.help unless you are actively
|
|
involved in the development of part of the networking for Linux.
|
|
We ask that you *please* respect this general guideline for content.
|
|
You can safely bet that neither of the authors will respond to
|
|
any plea for help that *should* be posted to c.o.l.help, but is
|
|
inappropraitely placed elsewhere.
|
|
|
|
0.03 Related Documentation
|
|
|
|
Much of this info came from saved postings from the comp.os.linux
|
|
groups, which shows that it is a valuable resource of information.
|
|
Other useful information came from a bunch of small files by Donald
|
|
himself. Some of these are found at /pub/linux/info on ftp.super.org
|
|
[192.31.192.1] Of course, if you are setting up an Ethernet card,
|
|
then you will want to read the NET-2 HOWTO so that you can actually
|
|
do something with it. This is also the home of any alpha drivers that
|
|
are not presently in the kernel. And last but not least, the
|
|
contributions from the individuals and companies listed above are
|
|
greatly appreciated as well.
|
|
|
|
0.04 New versions of this document
|
|
|
|
New versions of this document can be retrieved via anonymous
|
|
FTP from sunsite.unc.edu:/pub/Linux/docs/HOWTO/* and various
|
|
Linux ftp mirror sites. It will also be posted to the newsgroup
|
|
comp.os.linux.announce at a regular interval. Updates will be made
|
|
as new information / drivers becomes available.
|
|
|
|
0.05 Feedback
|
|
|
|
Any corrections can be sent to one of us (gpg109@rsphysse.anu.edu.au
|
|
or becker@super.org) We will *attempt* to keep this up to date as
|
|
more drivers become available, and as NET-2 matures.
|
|
|
|
1 What card should I buy for Linux?
|
|
|
|
For impatient users that just want a quick, cheap answer the
|
|
summary is: get 16 bit thinnet 8013 cards. For more detail as
|
|
to the who what where and why, read on.
|
|
|
|
1.01 Eight bit vs 16 bit
|
|
|
|
Unless you are a light user, or are confined to using the smaller
|
|
ISA slot, the use of the 8 bit cards like the wd8003 and the 3c503
|
|
is really not worth the cost savings. Get the 8013 or the 3c503/16
|
|
instead.
|
|
|
|
1.02 Low price Ethernet cards
|
|
|
|
I keep track of the current low-price vendors, just because it's
|
|
asked so often. Call AT-LAN-TEC at 301-948-7070. Ask for their
|
|
technical support person, "Vincent Bono". As with all purchases,
|
|
you should indicate you are buying this for a Linux system.
|
|
The last I checked the price for 10 NE2000s was $480, or $48 ea.!
|
|
NB: Their current NE2000 clone is a model that "traps" other
|
|
drivers that probe into their address space. AT-LAN-TEC also carries
|
|
a clone, non-EEPROM 8013 board for somewhat more, and a NE2100 clone.
|
|
Either is a better choice if the very lowest price isn't essential.
|
|
|
|
The Allied Telesis AT1500 is offered at a good price by many vendors.
|
|
Even Inmac, known for their premium markup, has this card for under
|
|
$100.
|
|
|
|
1.03 Vendors and Brands to Avoid
|
|
|
|
These vendors have decided *not* to release programming information
|
|
about their products, without signing a non-disclosure agreement.
|
|
More information can be found in sections two and nine. Hence there
|
|
is no support for products offered from these companies:
|
|
|
|
(1) Cabletron
|
|
(2) Xircom
|
|
|
|
These particular cards should be avoided, as they are obsolete.
|
|
The reasons as to why they have been classified as such can be
|
|
found in section 2 of this document.
|
|
|
|
(1) 3c501
|
|
(2) Arcnet
|
|
|
|
1.04 Type of cable that your card should support
|
|
|
|
Unless you have to conform to an existing network, you will want
|
|
to use thinnet or thin ethernet cable. This is the style with the
|
|
standard BNC connectors. See section 4 for other concerns with
|
|
different types of ethernet cable.
|
|
|
|
Most ethercards also come in a "Combo" version for only $10-$20 more.
|
|
These have both twisted pair and thinnet transceiver built-in,
|
|
allowing you to change your mind later.
|
|
|
|
2 Status of Various Ethernet Cards under Linux
|
|
|
|
The only thing that one needs to use an ethernet card with Linux
|
|
is the appropriate driver. For this, it is essential that the
|
|
manufacturer will release the technical programming information to
|
|
the general public without you (or anyone) having to sign your life
|
|
away. A good guide for the likelihood of getting documentation
|
|
(or, if you aren't writing code, the likelihood that someone
|
|
else will write that driver you really, really need) is the
|
|
availability of the Crynwr (nee Clarkson) packet driver. Russ
|
|
Nelson (see the acknowledgements in the intro.) runs this
|
|
operation, and has been very helpful in supporting the development
|
|
of drivers for Linux.
|
|
|
|
Given the documentation, you can write a driver for
|
|
your card and use it for Linux, at least in theory. Keep in
|
|
mind that some old hardware that was designed for XT type
|
|
machines will not function very well in a multitasking
|
|
environment such as Linux. Use of these will lead to major
|
|
problems if your network sees a reasonable amount of traffic.
|
|
|
|
Most cards come with drivers for MS-DOS interfaces such as
|
|
NDIS and ODI, but these are useless for Linux. Many people
|
|
have suggested directly linking them in or automatic
|
|
translation, but this is nearly impossible. The MS-DOS
|
|
drivers expect to be in 16 bit mode and hook into "software
|
|
interrupts", both incompatible with the Linux kernel. This
|
|
incompatibility is actually a feature, as some Linux drivers
|
|
are considerably better than their MS-DOS counterparts. The
|
|
"8390" series drivers, for instance, use ping-pong transmit
|
|
buffers, which are only now being introduced in the MS-DOS world.
|
|
|
|
Keep in mind that PC ethercards have the widest variety of
|
|
interfaces (shared memory, programmed I/O, bus-master, or slave
|
|
DMA) of any computer hardware for anything, and supporting a
|
|
new ethercard sometimes requires re-thinking most of the lower-level
|
|
networking code. (If you are interested in learning more about
|
|
these different forms of interfaces, see section 5)
|
|
|
|
Also, similar product numbers don't always indicate similar products.
|
|
For instance, the 3c50* product line from 3Com varies wildly
|
|
between different members.
|
|
|
|
Enough talk. Let's get down to the information you want.
|
|
|
|
2.01 3Com
|
|
|
|
Supported:
|
|
|
|
3c503, 3c503/16
|
|
3Com shared-memory ethercards. They also have a
|
|
programmed I/O mode that doesn't use the 8390
|
|
facilities (their engineers found too many bugs!)
|
|
It should be about the same speed as the same bus
|
|
width WD80x3, but I don't have a 16 bit version
|
|
to benchmark. Unless you are a light user, spend
|
|
the extra money and get the 16 bit model, as the
|
|
price difference isn't significant. The 3c503 does not
|
|
have "EEPROM setup", so the diagnostic/setup program
|
|
isn't needed before running the card with Linux. The
|
|
shared memory address of the 3c503 is set using jumpers
|
|
that are shared with the boot PROM address. This is
|
|
confusing to people familiar with other ISA cards,
|
|
where you always leave the jumper set to "disable"
|
|
unless you have a boot PROM.
|
|
|
|
The Linux 3c503 driver can also work with the 3c503
|
|
programmed-I/O mode, but this is slower and less
|
|
reliable than shared memory mode. Also, programmed-I/O
|
|
mode is not tested when updating the drivers, the
|
|
deadman (deadcard?) check code may falsely timeout on
|
|
some machines, and the probe for a 3c503 in
|
|
programmed-I/O mode is turned off by default in some
|
|
versions of the kernel. This was a panic reaction to
|
|
the general device driver probe explosion; the 3c503
|
|
shared memory probe is a safe read from memory, rather
|
|
than an extensive scan through I/O space. As of pl13,
|
|
the kernel has a I/O port registrar that makes I/O
|
|
space probes safer, (see section 5.1 for more info.)
|
|
and the programmed-I/O 3c503 probe has been re-enabled.
|
|
You still shouldn't use the programmed-I/O mode though,
|
|
unless you need it for MS-DOS compatibility.
|
|
|
|
The 3c503's IRQ line is set in software, with no hints
|
|
from an EEPROM. Unlike the MS-DOS drivers, the
|
|
Linux driver has capability to autoIRQ: it uses the
|
|
first available IRQ line in {5,2/9,3,4}, selected each
|
|
time the card is 'ifconfig'ed. (Older driver versions
|
|
selected the IRQ at boot time.) The ioctl() call
|
|
in 'ifconfig' will return EAGAIN if no IRQ line is
|
|
available at that time.
|
|
|
|
The 0.99pl13 open-time-autoIRQ 3c503 driver has two
|
|
minor bugs. The first is that autoIRQ list is effect-
|
|
ively {5, 3, 4} instead of {5, 2/9, 3, 4}. The second
|
|
is that if you use autoIRQ the interrupt channel isn't
|
|
set the first time, and the board is frozen until the
|
|
first transmit timeout triggers a board reset. After
|
|
that, everything works fine. The fixed version will be
|
|
in pl14 if alpha-tester reports are received in time.
|
|
|
|
3c509
|
|
A new card from 3Com. It's inexpensive and has
|
|
excellent performance for a non-bus-master design. The
|
|
drawbacks are that it _requires_ very low interrupt
|
|
latency, and it isn't rated for bus speeds greater than
|
|
8Mhz.
|
|
|
|
A working 3c509 driver is included as an alpha-test
|
|
version in the 0.99pl13 kernel sources, but
|
|
it's not enabled by default. You'll have to edit
|
|
config.in by hand to remove the comment character in
|
|
front of the 3c509 line.
|
|
|
|
The 3c509 has a tiny Rx buffer, causing the driver to
|
|
occasionally drop a packet if interrupts are masked for
|
|
too long. To minimize this problem, the driver should
|
|
be completely rewritten to use predictive interrupts.
|
|
(Note: performance re-writes of working drivers are low
|
|
priority unless there is some particular incentive or
|
|
need.)
|
|
|
|
It's likely that the EISA 3c579 probe will be working
|
|
and tested before a new driver is done, so watch for
|
|
an interim release.
|
|
|
|
There is also an alpha version of a Linux 3c509
|
|
diagnostic and EEPROM setup program, but for now
|
|
users that don't like the defaults should use the
|
|
MS-DOS EEPROM setup program.
|
|
|
|
3c579
|
|
The EISA version of the 509. The current EISA version
|
|
uses the same 16 bit wide chip rather than a 32 bit
|
|
interface, so the performance increase isn't stunning.
|
|
The 3c509 driver should work with the EISA version, if
|
|
the EISA version is configured to an ISA base address.
|
|
(I have neither an EISA machine nor a 3c579 to test it
|
|
on. -djb) We would be interested in hearing progress
|
|
reports from any 3c579 users. (Read the above 3c509
|
|
section for info on the driver.)
|
|
|
|
Cameron Spitzer writes:
|
|
"The 3C579 (Etherlink III EISA) should be configured
|
|
as an EISA card. The IO Base Address (window 0
|
|
register 6 bits 4:0) should be 1f, which selects EISA
|
|
addressing mode. Logic outside the ASIC decodes the
|
|
IO address s000, where s is the slot number. I don't
|
|
think it was documented real well. Except for its IO
|
|
Base Address, the '579 should behave EXACTLY like the
|
|
'509 (EL3 ISA), and if it doesn't, I want to hear
|
|
about it (at my work address).
|
|
|
|
I will leave it to the Real Programmers to suggest
|
|
the right hack to /usr/src/linux/net/inet/3c509.c to
|
|
take care of the EISA case.
|
|
|
|
Beware that if you put a '509 in EISA addressing mode
|
|
by mistake and save that in the EEPROM, you'll have
|
|
to use an EISA machine or the infamous Test Via to
|
|
get it back to normal, and it will conflict at IO
|
|
location 0 which may hang your ISA machine. It's not
|
|
my job to say whether this is a bug or feature, but I
|
|
have heard loud and clear that customers don't like
|
|
it and I don't think we'll do it that way again."
|
|
|
|
Unsupported:
|
|
|
|
3c501
|
|
Too brain-damaged to use. Available surplus from many
|
|
places. Avoid it like the plague. Again, do not
|
|
purchase this card, even as a joke. It's performance
|
|
is horrible, and it breaks in many ways.
|
|
|
|
(I have a standing offer: I'll pay $2 for each 3c501
|
|
shipped to me postpaid, but only if you include the
|
|
BNC 'T' connector and the jumpers. $2.50 if you just
|
|
send the 'T', jumpers, and address PROM and promise to
|
|
destroy the board. -djb)
|
|
|
|
Cameron L. Spitzer of 3Com said:
|
|
"I'm speaking only for myself here, of course, but I
|
|
believe 3Com advises against installing a 3C501 in a
|
|
new system, mostly for the same reasons Donald has
|
|
discussed. You probably won't be happy with the
|
|
3C501 in your Linux box. The data sheet is marked
|
|
"(obsolete)" on 3Com's Developers' Order Form, and
|
|
the board is not part of 3Com's program for sending
|
|
free Technical Reference Manuals to people who need
|
|
them. The decade-old things are nearly
|
|
indestructible, but that's about all they've got
|
|
going for them any more."
|
|
|
|
For those not yet convinced, the 3c501 can only do one
|
|
thing at a time -- while you are removing one packet
|
|
from the single-packet buffer it cannot receive
|
|
another packet, nor can it receive a packet while are
|
|
loading a transmit packet. This was fine for a
|
|
network between two 8088-based computers where
|
|
processing each packet and replying took 10's of
|
|
msecs, but modern networks send back-to-back
|
|
packets for almost every transaction.
|
|
|
|
Having read this far, you must be persistent, so you
|
|
get let in on a secret. As of pl13, some more of
|
|
the hardware problems were "compensated for".
|
|
|
|
Ie. in a fit of madness I wasted a whole day updating
|
|
my 3c501 driver and then trying to track down a few
|
|
more of the 3c501 glitches. It now works well enough
|
|
to NFS mount filesystems, but the receiver still
|
|
occasionally hangs. I'm mostly certain that this is
|
|
a hardware bug. When it hangs, the next set of
|
|
outgoing packets will reset the board, but that's
|
|
only useful if you have something occasionally
|
|
generating outgoing packets.
|
|
|
|
I'll let this out for "pre-alpha" testing, under the
|
|
following conditions: This is unsupported code. I
|
|
know my usual copyright says all the code is
|
|
unsupported, but this is _really_ unsupported. I
|
|
DON'T want to see bug reports, and I'll accept bug
|
|
fixes only if I'm in a good mood that day.
|
|
|
|
I don't want to see a fest of "Linux ethercards for
|
|
sale" postings. A bunch of people have bought dozens
|
|
of "dumpster special" 3c501s, and they hope to sell
|
|
them at rip-off prices. A 3c501 is barely worth the
|
|
shipping cost, and if I see people trying to sell
|
|
them here by claiming "supported by Linux" I _will_
|
|
flame them. They are _not_ supported by Linux.
|
|
|
|
I don't want to be flamed later for putting out bad
|
|
software. I don't know all all of the 3c501 bugs,
|
|
and I know this driver only handles a few that I've
|
|
been able to figure out. It has taken a long
|
|
intense effort just to get the driver working this
|
|
well.
|
|
|
|
That said, ftp.super.org:/pub/linux/pl14/3c501.c
|
|
Jumper your card to 0x280, add the 3c501.o to the
|
|
OBJS line in net/inet/Makefile, uncomment the 3c501
|
|
line in linux/config.in, 'make config; make' as usual.
|
|
|
|
AutoIRQ works, DMA isn't used, the autoprobe only
|
|
looks at 0x280, the debug level is set with the third
|
|
boot-time argument. You'll probably want to change
|
|
the default EL_DEBUG to '2'.
|
|
|
|
Once again, THE USE OF A 3c501 IS STRONGLY DISCOURAGED
|
|
and it is NOT SUPPORTED BY LINUX.
|
|
|
|
|
|
3c505
|
|
An Intel-based ethercard with no driver available
|
|
at present. (Not a very common card.)
|
|
|
|
3c507
|
|
This card uses one of the Intel chips, and the
|
|
development of the driver is closely related to
|
|
the development of the Intel Ether Express driver.
|
|
An alpha driver is presently available. Expect to
|
|
see the driver in the standard release of pl15.
|
|
Technical information is available in section 5.06,
|
|
and if you have experience in writing drivers, see
|
|
section 5.07 as well.
|
|
|
|
2.02 Western Digital / SMC
|
|
|
|
The ethernet part of Western Digital has been bought by SMC. The
|
|
SMC Elite and SMC Elite Plus are the same as late-model WD8003
|
|
and WD8013 cards. Note that the SMC Elite Ultra is *not* the
|
|
same as the plain SMC Elite / WD8013 card. (see below)
|
|
|
|
Supported:
|
|
|
|
WD8003, WD8013, SMC Elite, SMC Elite Plus
|
|
A shared memory design by Western Digital. The
|
|
8 bit 8003 is slightly less expensive, but only
|
|
worth the savings for light use. Over the
|
|
years the design has added more registers and an
|
|
EEPROM. Clones usually go by the '8013' name, and
|
|
usually use a non-EEPROM (jumpered) design. This part
|
|
of WD has been sold to SMC, so you'll usually see
|
|
something like SMC/WD8013 or SMC Elite Plus (WD8013).
|
|
The shared memory makes the cards 10-20% faster,
|
|
especially with larger packets. More importantly
|
|
(to me at least) it avoids a few bugs in the
|
|
programmed-I/O mode of the 8390, allows safe
|
|
multi-threaded access to the packet buffer, and
|
|
doesn't have a programmed-I/O data register that
|
|
hangs your machine during warm-boot probes.
|
|
|
|
SMC Elite 16 ULTRA
|
|
This ethercard is based on a new chip from SMC, with
|
|
a few new features. While it has a mode that is
|
|
similar to the older SMC ethercards, it's not
|
|
compatible with the old WD80*3 drivers. However, in
|
|
this mode it shares most of its code with the other
|
|
8390 drivers, while operating somewhat faster than a
|
|
WD8013 clone.
|
|
|
|
I'm considering writing a separate driver for the
|
|
Ultra's "Altego" mode which allows chaining transmits
|
|
at the cost of inefficient use of receive buffers,
|
|
but that will probably not happen right away.
|
|
Performance re-writes of working drivers are low
|
|
priority unless there is some particular incentive
|
|
or need.
|
|
|
|
This is a new driver, made possible by documentation
|
|
and ethercard loan from kamstra@ccmail.west.smc.com,
|
|
Duke Kamstra. If you plan on using an Ultra with Linux
|
|
send him a note of thanks to let him know that there
|
|
are Linux users out there!
|
|
If you would like to _ALPHA_ test this driver:
|
|
ftp.super.org:/pub/linux/pl14/smc-ultra.c
|
|
ftp.super.org:/pub/linux/pl14/Space.c
|
|
You'll have to add an "Ultra" line to config.in and
|
|
edit net/inet/Makefile. The Ultra driver will probably
|
|
be (silently?) included in pl14.
|
|
|
|
2.03 NExxxx
|
|
|
|
The prefix "NE" came from Novell Ethernet. Novell followed the
|
|
cheapest NatSemi databook design and sold the manufacturing rights
|
|
(spun off?) Eagle, just to get reasonably-priced ethercards into
|
|
the market.
|
|
|
|
Supported:
|
|
|
|
NE1000, NE2000
|
|
The now-generic name for a bare-bones design around
|
|
the NatSemi 8390. They use programmed I/O rather than
|
|
shared memory, leading to easier installation but
|
|
slightly lower performance and a few problems. Again,
|
|
the savings of using an 8 bit NE1000 over the NE2000
|
|
are only warranted if you expect light use. Some
|
|
recently introduced NE2000 clones use the National
|
|
Semiconductor "AT/LANTic" 83905 chip, which offers
|
|
a shared memory mode similar to the 8013 and EEPROM
|
|
or software configuration. Some problems can arise
|
|
with poor clones. See the question and answer section
|
|
later in this document, and the section on clones.
|
|
I have written a NE2000 diagnostic program, but it
|
|
is still presently in alpha test. (ne2k)
|
|
|
|
NE1500, NE2100
|
|
The AT1500 driver, recently added to the list of
|
|
supported cards, also supports the NE1500, NE2100 and
|
|
clones. The driver shipped with pl12 kernel doesn't
|
|
detect non-AT1500 cards with autoprobe, but will work
|
|
fine if you specify the base address explicitly and
|
|
jumper for DMA channel 5. Read the Allied Telesis
|
|
section for more information on LANCE based cards.
|
|
|
|
2.04 Hewlett Packard
|
|
|
|
The 272** cards use programmed I/O, similar to the NE*000 boards,
|
|
but the data transfer port can be "turned off" when you aren't
|
|
accessing it, avoiding problems with autoprobing drivers.
|
|
|
|
Thanks to Glenn Talbott for cleaning up the confusion in this
|
|
section regarding the version numbers of the HP hardware, and
|
|
adding lots of new info.
|
|
|
|
Supported:
|
|
|
|
27245A
|
|
8 Bit 8390 based 10BaseT, not recommended for all the
|
|
8 bit reasons. It was re-designed a couple years
|
|
ago to be highly integrated which caused some
|
|
changes in initialization timing which only
|
|
affected testing programs, not LAN drivers. (The
|
|
new card is not 'ready' as soon after switching
|
|
into and out of loopback mode.)
|
|
|
|
27247B, 27252A
|
|
The 47B is a 16 Bit 8390 based 10BaseT w/AUI, and
|
|
the 52A is a 16 Bit 8390 based ThinLAN w/AUI.
|
|
These cards are high performers (3c509 speed) without
|
|
the interrupt latency problems (32K onboard RAM for TX
|
|
or RX packet buffering). They both offer LAN
|
|
connector autosense, data I/O in I/O space (simpler) or
|
|
memory mapped (faster), and soft configuration. 27247B
|
|
was rated Best for ISA Servers by PC Mag this year.
|
|
|
|
27247A
|
|
This is the older model that existed before the "B".
|
|
Two versions 27247-60001 or 27247-60002 have part
|
|
numbers marked on the card. Functionally the same to
|
|
the LAN driver, except bits in ROM to identify
|
|
boards differ. -60002 has a jumper to allow
|
|
operation in non-standard ISA busses (chipsets
|
|
that expect IOCHRDY early.)
|
|
|
|
HP J2405A
|
|
These are lower priced, and slightly faster than the
|
|
27247B/27252A, but are missing some features, such
|
|
as AUI, ThinLAN connectivity, and boot PROM socket.
|
|
This is a fairly generic LANCE design, but a minor
|
|
design decision makes it incompatible with a generic
|
|
"NE2100" driver. Special support for it (including
|
|
reading the DMA channel from the board) should be in
|
|
pl14 thanks to information provided by HP's Glenn
|
|
Talbott, gt@hprnd.rose.hp.com. To use the pl12 and
|
|
pl13 LANCE driver you must remove the outw(...RESET)
|
|
calls that are commented "for old NE2100 designs", as
|
|
these will change the board's base address(!).
|
|
More information on LANCE based cards can be found in
|
|
section 5.08.
|
|
|
|
2.05 D-Link
|
|
|
|
Supported:
|
|
|
|
DE-600
|
|
Laptop users and other folk who might want a quick
|
|
way to put their computer onto the ethernet may want
|
|
to use this. The driver is included with the default
|
|
kernel source tree as of pl12 and possibly earlier.
|
|
Bjorn Ekwall <bj0rn@blox.se> wrote the original.
|
|
Expect about 80kb/s transfer speed from this via the
|
|
parallel port. You should read the README.DLINK
|
|
file in the kernel source tree. The latest release
|
|
of this driver is v0.32, and it should be included
|
|
in pl14 if all goes well.
|
|
|
|
DE100, DE200, DE-220-T
|
|
The manual says that it is 100% compatible with the
|
|
NE2000. This is not true. You should call them and
|
|
tell them you are using their card with Linux, and they
|
|
should correct their documentation. Some pre-0.99pl12
|
|
driver versions may have trouble recognizing the DE2**
|
|
series as 16 bit cards, and these cards are the most
|
|
widely reported as having the spurious transfer address
|
|
mismatch errors.
|
|
|
|
Unsupported:
|
|
|
|
DE-620
|
|
Same as the DE-600, only with two output formats.
|
|
Bjorn writes: "I have still no information on the
|
|
DE-620 that I can include in this release. (Maybe
|
|
someone well connected to D-Link sees this,
|
|
hint, hint, hint...)
|
|
|
|
2.06 Cabletron
|
|
|
|
Yes, another one of these companies that won't release its
|
|
programming information. They waited for months before actually
|
|
confirming that all their information was proprietary. If you feel
|
|
like asking them why they don't want to release their info so that
|
|
people can use their cards, write to pkelly@ctron.com. You should
|
|
read section 9.1 of this document, as it has specific information
|
|
pertaining to Cabletron.
|
|
|
|
Supported: (...well, not *really* supported)
|
|
|
|
E10**, E10**-x, E20**, E20**-x
|
|
These are NEx000 almost-clones that are reported to
|
|
work with the standard NEx000 drivers, thanks to a
|
|
ctron-specific check during the probe. If there are
|
|
any problems, they are unlikely to be fixed, as the
|
|
programming information is unavailable.
|
|
|
|
Unsupported:
|
|
|
|
E21**
|
|
Again, there is not much one can do when the
|
|
programming information is proprietary. Feel free
|
|
to ask pkelly@ctron.com. This is the only 8390-based
|
|
ethercard series that isn't supported by Linux.
|
|
|
|
2.07 Allied Telesis
|
|
|
|
Allied Telesis is the worlds largest maker of separate
|
|
transceivers thanks to their low prices, and they now have a
|
|
series of low-cost ethercards using the 79C960 version of the AMD
|
|
LANCE. These are bus-master cards, and thus probably the fastest
|
|
ISA bus ethercards available (although the 3c509 has lower latency
|
|
thanks to predictive interrupts).
|
|
|
|
Supported:
|
|
|
|
AT1500
|
|
The driver for the AT1500 series is new in the
|
|
0.99pl12 kernel, but it won't work "out-of-the-box"
|
|
with >16M machines. (NB This isn't a fundamental
|
|
limitation, so stop pointing and laughing at the ISA
|
|
bus. The driver just needs a hook to allocate
|
|
low-memory buffers for the bus-master DMA, and should
|
|
be just as fast on >16M systems. It can be easily
|
|
fixed by initializing the LANCE driver with the
|
|
character devices, but this fix depends on the
|
|
resolution of the networking code uncertainty.)
|
|
|
|
For those inquiring about using bus-master LANCE
|
|
boards with >16M systems, I've been working on that
|
|
recently. I borrowed 16M from another system here
|
|
at work, and am using the resulting 32M system while
|
|
typing this message. The bad news is that the modified
|
|
driver uses a very ugly interface, and I'm unlikely
|
|
to have it cleaned up and tested in time for pl14.
|
|
|
|
This driver should also work with NE1500 and NE2100
|
|
clones. The pl12 version, included with SLS1.03, is
|
|
named "le0" rather than "eth0" and it requires the
|
|
base address to be specified if you don't have a real
|
|
AT1500. You might be able to use it as easily as
|
|
using the boot line:
|
|
lilo: linux ether=0,0x320,le0
|
|
(change 0x320 to your true base address) and then
|
|
changing "eth0" to "le0" in /etc/rc.net. Your DMA
|
|
channel must be set at DMA5, but autoIRQ does work.
|
|
|
|
The 0.99pl13 driver should be able to autoprobe for
|
|
your ethercard at the locations {0x300, 0x320, 0x340,
|
|
0x360}. Also, the driver is now named "eth0" by
|
|
default.
|
|
|
|
Future driver versions may figure out a way to
|
|
autoDMA. Although there is no autoDMA (until I verify
|
|
that autoDMA is safe and reliable), some versions
|
|
(pl13) allow passing the DMA channel at boot-time via
|
|
LILO. (Boot-time parameters can be made permanent in
|
|
LILO v13+, read the docs.) The DMA channel otherwise
|
|
defaults to DMA5.
|
|
|
|
Please report the exact chip used by your ethercard,
|
|
and any success or failure you have. This driver is
|
|
still young, and I've gotten few reports.
|
|
|
|
More information on AMD LANCE based Ethernet cards
|
|
can be found in section 5.08.
|
|
|
|
AT1700
|
|
The Allied Telesis AT1700 series ethercards are based
|
|
on the Fujitsu MB86965. This chip uses a programmed
|
|
I/O interface, and a pair of fixed-size tranmit
|
|
buffers. This allows small groups of packets to sent
|
|
be sent back-to-back, with a short pause while
|
|
switching buffers.
|
|
|
|
A unique feature is the ability to drive 150ohm STP
|
|
(Shielded Twisted Pair) cable commonly installed for
|
|
Token Ring, in addition to 10baseT 100ohm UTP
|
|
(unshielded twisted pair).
|
|
|
|
A mis-feature to watch out for is that the current
|
|
production version silently wires to DMA channel 5,
|
|
rendering it useless. No device driver will be
|
|
written using DMA if installing a second card into
|
|
the machine breaks both, and only way to disble the
|
|
DMA is with a knife.
|
|
|
|
The at1700 driver is in alpha test, and will probably
|
|
be released with the pl14 kernel.
|
|
|
|
2.08 Arcnet
|
|
|
|
There is no Arcnet driver for Linux. Feel free to write a driver. With
|
|
the very low cost and better performance of ethernet, I expect that
|
|
most places will be giving away their Arcnet hardware for free,
|
|
resulting in a lot of home systems with Arcnet.
|
|
|
|
An advantage of Arcnet is that all of the cards have identical
|
|
interfaces, so once a driver is available it will work for everyone.
|
|
|
|
2.09 Digital / DEC
|
|
|
|
Supported: DE200-64k, DE200-32k, DE202, DE100, DEPCA rev E
|
|
|
|
Peter Bauer has written a driver for the older DEPCA models.
|
|
Look for depca-0.7.tar.z -- It patches against pl13. This
|
|
will allow you to use any of the above cards. FvK is
|
|
currently trying to arrange integration of this driver
|
|
into pl14, so you *may* not need this file after pl13.
|
|
If you are using this driver, Peter would like to hear
|
|
from you. His e-mail addr. is near the start of this
|
|
document.
|
|
|
|
Peter had this to say about all the DEPCA cards:
|
|
"In this thing I'll document my knowledge about the digital
|
|
ethernet boards for PC's: There exist lots of different
|
|
hardware-releases of ethernet boards of DEC, all subsumed
|
|
under the keyword 'DEPCA'. All these boards are more or
|
|
less compatible as they all seem to use some chip called
|
|
"Lance". The hardware of these cards and the programing
|
|
of them is documented in a manual purchasable from DEC
|
|
(about $70 -- I had the order number some months ago, but
|
|
lost it...)"
|
|
|
|
Unsupported: Digital Etherlink III
|
|
|
|
Again, Peter Bauer said that "the new etherlink III seems to
|
|
be a break: No official docu from DEC as far as today,
|
|
other (incompatible??) hardware used, and (no joke) (at least
|
|
for the first delivered cards) also a sharp knife necessary
|
|
to get the card working (needs cut of some irq lines ...)
|
|
As far as I know, lots of DEC Employees use Linux (at least
|
|
for hobby purposes) and the depca-driver, because its a
|
|
de-facto standard in DEC, so I encourage any DEC-employee
|
|
reading this to check wether my writing is true, and to
|
|
support sources of information about the etherworks-III."
|
|
|
|
2.10 Intel Ethernet Cards
|
|
|
|
Supported: Ether Express
|
|
|
|
This card uses the intel i82586. An alpha driver is available.
|
|
Expect to see the driver in the standard release of pl15.
|
|
|
|
2.11 PureData
|
|
|
|
Supported: PDUC8028, PDI8023
|
|
|
|
The PureData PDUC8028 and PDI8023 series of cards are reported
|
|
to work, thanks to special probe code contributed by Mike
|
|
Jagdis <jaggy@purplet.demon.co.uk>. The support is integrated
|
|
with the WD driver.
|
|
|
|
2.12 Xircom
|
|
|
|
Another group that won't release documentation. No cards
|
|
supported. Don't look for any support in the future unless
|
|
they release their programming information. And this is
|
|
highly unlikely, as they *forbid* you from even reverse-
|
|
engineering their drivers. Here is some of the results from
|
|
people who have tried to deal with Xircom.
|
|
|
|
"I had no end of problems trying to work with Xircom.
|
|
After spending months talking to them and working up a
|
|
prospectus, I was told that no information would be forthcoming
|
|
and that they were not interested in markets other than the
|
|
ISA/DOS market. (I was trying to interface the pocket adapters
|
|
to an Amiga). I won't work with them anymore and I won't
|
|
recommend their products to anyone."
|
|
|
|
"They (Xircom) won't give it (programming info.) out. BSDI
|
|
was able to get the spec and write a driver for it, but
|
|
only by promising not to give out the source."
|
|
|
|
You might also be interested in reading section 9.2
|
|
|
|
2.13 Zenith
|
|
|
|
The built-in Z-Note network adaptor is based on the Intel
|
|
i82593 using two DMA channels. There might be a driver for it
|
|
in early 1994. See section 5.06 for more information.
|
|
|
|
2.14 Racal-Interlan
|
|
|
|
There is an alpha driver for the NI5210 floating about.
|
|
(last seen on tsx-11.mit.edu /pub/linux/ALPHA/ni/ni52.tar.gz)
|
|
This card also uses one of the Intel chips. See section
|
|
5.06 for more information.
|
|
|
|
2.15 AMD LANCE (79C960)
|
|
|
|
There really is no AMD ethernet card. You are probably reading this
|
|
because the only markings you could find on your card said AMD
|
|
and the above number. The above number refers to a chip from AMD
|
|
that is the heart of many ethernet cards. See the section on the
|
|
Allied Telesis AT1500, the NE1500/2100 and the information in
|
|
section 5.08. Chances are that the existing LANCE driver will work
|
|
with all AMD LANCE based cards.
|
|
|
|
2.16 AT-Lan-Tec
|
|
|
|
AT-Lan-Tec pocket ethernet adaptor:
|
|
This is a generic, low-cost OEM pocket adaptor being sold by
|
|
AT-Lan-Tec, and (likely) a number of other suppliers. A
|
|
driver is in progress, but not yet complete (-djb 11/9/93).
|
|
|
|
3. Clones of popular Ethernet cards.
|
|
|
|
Due to the popular design of some cards, different companies will
|
|
make "clones" or replicas of the original card. However, one must
|
|
be careful, as some of these clones are not 100% compatible, and
|
|
can be troublesome. Some common problems with "not-quite-clones"
|
|
are noted in the question and answer section of this document.
|
|
|
|
3.1 WD80x3 clones
|
|
|
|
The following clones are reported to work with the standard
|
|
WD80x3 driver:
|
|
|
|
AT-LAN-TEC 8013
|
|
PureData (not a 8013 clone, but the 8013 driver has special code)
|
|
LANNET LEC-45
|
|
PE-8013 (WD-8013 Compatible)
|
|
|
|
3.2 NE2000 clones
|
|
|
|
The following clones are reported to work with the standard
|
|
NE2000 driver:
|
|
|
|
Accton NE2000 (might not get detected at boot, see section 6)
|
|
Alta Combo NE2000 clone
|
|
Aritsoft LANtastic AE-2 (OK, but has flawed error-reporting registers)
|
|
Asante Etherpak 2001/2003
|
|
AT-LAN-TEC NE2000 clone (uses Winbond chip that traps SCSI drivers)
|
|
Cabletron products: E10**, E10**-x, E20**, E20**-x
|
|
Cnet UTP 10baseT (NE 2000 emulation)
|
|
D-Link Ethernet II (bad clones, but the driver checks for them)
|
|
4-Dimension FD0490 EtherBoard16
|
|
LTC E-NET/16 P/N: 8300-200-002 (lipka@lip.hanse.de)
|
|
Network Solutions HE-203
|
|
SIIG Inc E-Lan/200 (NE 2000 comp.)
|
|
SVEC 4 Dimension Ethernet
|
|
|
|
4. Cables, coax, twisted pairs etc.
|
|
|
|
If you are starting a network from scratch, it's considerably less
|
|
expensive to use thin ethernet, RG58 co-ax cable with BNC connectors,
|
|
than old-fashioned thick ethernet, RG-5 cable with N connectors, or
|
|
10baseT, twisted pair telco-style cables with RJ-45 "phone"
|
|
connectors.
|
|
|
|
4.01 Thin Ethernet (thinnet)
|
|
|
|
Thin ethernet is the "ether of choice". The cable is inexpensive. If
|
|
you are making your own cables solid-core RG58A is $0.09/ft. and
|
|
stranded RG58AU is $0.15/ft. Twist-on BNC connectors are < $2 ea.,
|
|
and other misc. pieces are similarly inexpensive. It is essential
|
|
that you properly terminate each end of the cable with 50 ohm
|
|
terminators, so budget $2 ea. for a pair. It's also vital that
|
|
your cable have no "stubs" -- the 'T' connectors must be attached
|
|
directly to the ethercards.
|
|
|
|
4.02 Twisted pair
|
|
|
|
Twisted pair networks require active hubs, which start around $250,
|
|
and the raw cable cost can actually be higher than thinnet. They are
|
|
usually sold using the claim that you can use your existing telephone
|
|
wiring, but it's a rare installation where that turns out to be the
|
|
case. The claim that you can upgrade to higher speeds is also
|
|
suspect, as most proposed schemes use higher-grade (read $$) cable and
|
|
more sophisticated termination ($$$) than you would likely install on
|
|
speculation.
|
|
|
|
On the other hand, hubs are rapidly dropping in price, all 100Mb/sec
|
|
ethernet proposals use twisted pair, and most new business
|
|
installations use twisted pair.
|
|
|
|
4.03 Thick Ethernet
|
|
|
|
Thick ethernet is mostly obsolete, and is usually used only to remain
|
|
compatible with an existing implementation. You can stretch the rules
|
|
and connect short spans of thick and thin ethernet together with a
|
|
passive $3 N-to-BNC connector, and that's often the best solution to
|
|
expanding an existing thicknet. A correct (but expensive) solution is
|
|
to use a repeater in this case.
|
|
|
|
[End part 1/2]
|
|
From: Paul Gortmaker <gpg109@rsphysse.anu.edu.au>
|
|
Newsgroups: comp.os.linux.announce,comp.os.linux.admin,comp.answers,news.answers
|
|
Subject: Linux Ethernet HOWTO (Part 2/2)
|
|
Keywords: Linux, Ethernet, TCP/IP, NET-2
|
|
Followup-To: poster
|
|
Approved: linux-announce@tc.cornell.edu (Matt Welsh)
|
|
|
|
Archive-Name: linux/howto/ethernet/part2
|
|
Last-Modified: November 16, 1993
|
|
|
|
This is part 2/2 of the Linux Ethernet HOWTO. It is archived on
|
|
sunsite.unc.edu in pub/Linux/docs/HOWTO.
|
|
|
|
[Begin part 2/2]
|
|
|
|
5 Technical information.
|
|
|
|
For those who want to play with the present drivers, or try to make
|
|
up their own driver for a card that is presently unsupported, this
|
|
information should be useful. If you do not fall into this category,
|
|
then perhaps you will want to skip this section.
|
|
|
|
5.01 Probed addresses
|
|
|
|
While trying to determine what ethernet card is there, the following
|
|
addresses are autoprobed, assuming the type and specs of the card
|
|
have not been set in the kernel. In /usr/src/linux/net/inet/CONFIG,
|
|
one can set the cards that are compiled in to the kernel. As of
|
|
0.99pl12, doing a "make config" will ask what cards are to be
|
|
supported. The file names below are in /usr/src/linux/net/inet/
|
|
----------------------------------------------------------------
|
|
wd.c: 0x300, 0x280, 0x380, 0x240
|
|
3c503.c: 0x300, 0x310, 0x330, 0x350, 0x250, 0x280, 0x2a0, 0x2e0
|
|
ne.c: 0x300, 0x280, 0x320, 0x340, 0x360
|
|
hp.c: 0x300, 0x320, 0x340, 0x280, 0x2C0, 0x200, 0x240
|
|
lance.c: 0x300, 0x320, 0x340, 0x360
|
|
smc-ultra.c: 0x300, 0x280
|
|
3c509.c: <Special "ID Port" probe>
|
|
----------------------------------------------------------------
|
|
There are some NE2000 clone ethercards out there that are waiting black
|
|
holes for autoprobe drivers. While many NE2000 clones are
|
|
safe until they are enabled, some can't be reset to a safe mode.
|
|
These dangerous ethercards will hang any I/O access to their
|
|
"dataports". The typical dangerous locations are:
|
|
|
|
Ethercard jumpered base Dangerous locations (base + 0x10 - 0x1f)
|
|
0x300 * 0x310-0x317
|
|
0x320 0x330-0x337
|
|
0x340 0x350-0x357
|
|
0x360 0x370-0x377
|
|
|
|
* The 0x300 location is the traditional place to put an ethercard, but
|
|
it's also a popular place to put other devices (often SCSI
|
|
controllers). The 0x320 location is often the next one chosen, but
|
|
that's bad for for the AHA1542 driver probe. The 0x360 location is
|
|
bad, because it conflicts with the parallel port at 0x378.
|
|
|
|
To avoid these lurking ethercard, here are the things you can do:
|
|
|
|
o Probe for the device's BIOS in memory space. This is easy
|
|
and always safe, but it only works for cards that always have
|
|
BIOSes, like primary SCSI controllers.
|
|
|
|
o Avoid probing any of the above locations until you think
|
|
you've located your device. The NE2000 clones have a reset range
|
|
from <base>+0x18 to <base>+0x1f that will read as 0xff, so probe
|
|
there first if possible. It's also safe to probe in the 8390
|
|
space at <base>+0x00 - <base>+0x0f, but that area will return
|
|
quasi-random values
|
|
|
|
o If you must probe in the dangerous range, for instance if your
|
|
target device has only a few port locations, first check that
|
|
there isn't an NE2000 there. You can see how to do this by
|
|
looking at the probe code in /usr/src/linux/net/inet/ne.c
|
|
|
|
In other news, I've written the code for the I/O port registrar.
|
|
Peter MacDonald and I have been intensely discussing this, and I think
|
|
our current scheme has the necessary functionality with minimal kernel
|
|
size impact. (The implementation involved rewriting the bitmap ops in
|
|
kernel/ioport.c:ioperm() so that most code could be shared.)
|
|
|
|
Here is the current "blurb". As usual comments are welcome. Please
|
|
keep them substantial and constructive (we've already talked about
|
|
changing the name from "reserve=" to "noprobe=").
|
|
|
|
==================
|
|
|
|
Boot-Time Parameters: "reserve="
|
|
|
|
In some machines it may be necessary to prevent device drivers from
|
|
checking for devices (auto-probing) in a specific region. This may be
|
|
because of poorly designed hardware that causes the boot to "freeze"
|
|
(such as some ethercards), hardware that is mistakenly identified,
|
|
hardware whose state is changed by an earlier probe, or merely
|
|
hardware you don't want the kernel to initialize.
|
|
|
|
The "reserve" boot-time argument addresses this problem by specifying
|
|
an I/O port region that shouldn't be probed. That region is reserved
|
|
in the kernel's port registration table as if a device has already
|
|
been found in that region. Note that this mechanism shouldn't be
|
|
necessary on most machine, only when there is a problem or special
|
|
case.
|
|
|
|
The boot-line syntax is
|
|
|
|
lilo-prompt: linux-image reserve=[<port>,<size>,<port>,<size>...]
|
|
|
|
As usual with boot-time specifiers there is an 11 parameter limit, thus
|
|
you can only specify 5 reserved regions per "reserve" keyword.
|
|
Multiple "reserve" specifiers will work if you have an usually
|
|
complicated request.
|
|
|
|
If you specify a "reserve" region to protect a specific device, you
|
|
must generally specify an explicit probe for that device. Most
|
|
drivers ignore the port registration table if they are given an
|
|
explicit address.
|
|
|
|
5.02 Skeleton / prototype driver
|
|
|
|
OK. So you have decided that you want to write a driver for the
|
|
Foobar Ethernet card, as you have the programming information,
|
|
and it hasn't been done yet. (...these are the two main require-
|
|
ments ;-) You can use the skeleton network driver that is provided
|
|
with the Linux kernel source tree. It can be found in the file
|
|
/usr/src/linux/net/inet/README.DRIVERS as of 0.99pl12, and later.
|
|
|
|
It's also very useful to look at the Crynwr (nee Clarkson) driver
|
|
for your target ethercard, if it's available. Russ Nelson
|
|
<nelson@crynwr.com> has been actively updating and writing these,
|
|
and he has been very helpful with his code reviews of the current
|
|
Linux drivers.
|
|
|
|
5.03 Driver interface to the kernel
|
|
|
|
Here are some notes that may help when trying to figure out what
|
|
the code in the driver segments is doing, or perhaps what it is
|
|
supposed to be doing.
|
|
|
|
=====================================================
|
|
|
|
int ethif_init(struct device *dev)
|
|
{
|
|
...
|
|
dev->send_packet = &ei_send_packet;
|
|
dev->open = &ei_open;
|
|
dev->stop = &ei_close;
|
|
dev->hard_start_xmit = &ei_start_xmit;
|
|
...
|
|
}
|
|
|
|
int ethif_init(struct device *dev)
|
|
|
|
This function is put into the device structure in Space.c. It is
|
|
called only at boot time, and returns '0' iff the ethercard 'dev'
|
|
exists.
|
|
|
|
=====================================================
|
|
|
|
static int ei_open(struct device *dev)
|
|
static int ei_close(struct device *dev)
|
|
|
|
This routine opens and initializes the board in response to an
|
|
socket ioctl() usually called by 'config' or 'ifconfig'. It is
|
|
commonly stuffed into the 'struct device' by ethif_init().
|
|
|
|
The inverse routine is ei_close(), which should shut down the
|
|
ethercard, free the IRQs and DMA channels if the hardware permits,
|
|
and turn off anything that will save power (like the transceiver).
|
|
|
|
(Note: As of NET-2, the relevant program is '/etc/ifconfig' - and
|
|
the device *can* be turned off or on via passing 'up' or 'down'
|
|
to 'ifconfig' from the command line with the device name.)
|
|
|
|
=====================================================
|
|
|
|
static int ei_start_xmit(struct sk_buff *skb, struct device *dev)
|
|
dev->hard_start_xmit = &ei_start_xmit;
|
|
|
|
This routine puts packets to be transmitted into the hardware. It
|
|
is usually stuffed into the 'struct device' by ethif_init().
|
|
|
|
When the hardware can't accept additional packets it should set
|
|
the dev->tbusy flag. When additional room is available, usually
|
|
during a transmit-complete interrupt, dev->tbusy should be cleared
|
|
and the higher levels informed with mark_bh(INET_BH).
|
|
[[Note: pre0.99.4 kernels didn't use this interface for all packets.]]
|
|
|
|
=====================================================
|
|
|
|
...
|
|
if (dev_rint(buffer, length, is_skb ? IN_SKBUFF : 0, dev))
|
|
stats->rx_dropped++;
|
|
...
|
|
A received packet is passed to the higher levels using dev_rint().
|
|
If the unadorned packet data in a memory buffer, dev_rint will copy
|
|
it into a 'skbuff' for you. Otherwise a new skbuff should be
|
|
kmalloc()ed, filled, and passed to dev_rint() with the IN_SKBUFF flag.
|
|
|
|
=====================================================
|
|
|
|
5.04 Interrupts and Linux
|
|
|
|
There are two kinds of interrupt handlers in Linux:
|
|
fast ones and slow ones. You decide what kind you are installing by
|
|
the flags you pass to irqaction(). The fast ones, such as the serial
|
|
interrupt handler, run with _all_ interrupts disabled. The normal
|
|
interrupt handlers, such as the one for ethercard drivers, runs with
|
|
other interrupts enabled.
|
|
|
|
There is a two-level interrupt structure. The "fast" part handles the
|
|
device register, removes the packets, and perhaps sets a flag. After
|
|
it is done, and interrupts are re-enabled, the slow part is run if the
|
|
flag is set.
|
|
|
|
The flag between the two parts is set by:
|
|
mark_bh(INET_BH);
|
|
|
|
Usually this flag is set within dev_rint() during a received-packet
|
|
interrupt, and set directly by the device driver during a
|
|
transmit-complete interrupt.
|
|
|
|
You might wonder why all interrupt handlers cannot run in
|
|
"normal mode" with other interrupts enabled. Ross Biro uses this
|
|
scenario to illustrate the problem:
|
|
o You get a serial interrupt, and start processing it.
|
|
The serial interrupt is now masked.
|
|
o You get a network interrupt, and you start transferring
|
|
a maximum-sized 1500 byte packet from the card.
|
|
o Another character comes in, but this time the interrupts
|
|
are masked!
|
|
|
|
The "fast" interrupt structure solves this problem by allowing
|
|
bounded-time interrupt handlers to run without the risk of leaving
|
|
their interrupt lines masked by another interrupt request.
|
|
|
|
There is an additional distinction between fast and slow interrupt
|
|
handlers -- the arguments passed to the handler. A "slow" handler is
|
|
defined as
|
|
|
|
static void
|
|
handle_interrupt(int reg_ptr)
|
|
{
|
|
int irq = -(((struct pt_regs *)reg_ptr)->orig_eax+2);
|
|
struct device *dev = irq2dev_map[irq];
|
|
...
|
|
|
|
While a fast handler gets the interrupt number directly
|
|
|
|
static void
|
|
handle_fast_interrupt(int irq)
|
|
{
|
|
...
|
|
|
|
A final aspect of network performance is latency. The only board
|
|
that really addresses this is the 3c509, which allows a predictive
|
|
interrupt to be posted. It provides an interrupt response timer so
|
|
that the driver can fine-tune how early an interrupt is generated.
|
|
|
|
Alan Cox has some advice for anyone wanting to write drivers
|
|
that are to be used with pl14 kernels and newer. He says:
|
|
|
|
"Any driver intended for pl14 should use the new alloc_skb() and
|
|
kfree_skbmem() functions rather than using kmalloc() to obtain an
|
|
sk_buff. The new pl14 skeleton does this correctly. For drivers
|
|
wishing to remain compatible with both sets the define
|
|
'HAVE_ALLOC_SKB' indicates these functions must be used.
|
|
|
|
In essence replace
|
|
|
|
skb=(struct sk_buff *)kmalloc(size)
|
|
with
|
|
|
|
skb=alloc_skb(size)
|
|
|
|
and
|
|
|
|
kfree_s(skb,size)
|
|
|
|
with
|
|
|
|
kfree_skbmem(skb,size) /* Only sk_buff memory though */
|
|
|
|
Any questions should I guess be directed to me since I made the change.
|
|
This is a change to allow tracking of sk_buff's and sanity checks on
|
|
buffers and stack behaviour. If a driver produces the message
|
|
'File: ??? Line: ??? passed a non skb!' then it is probable the
|
|
driver is not using the new sk_buff allocators."
|
|
|
|
|
|
|
|
|
|
5.05 Programmed I/O vs. shared mem. vs. slave/master DMA
|
|
|
|
Ethernet is 10Mbs. (Don't be pedantic, 3Mbs and 100Mbs don't count.)
|
|
If you can already send and receive back-to-back packets, you just
|
|
can't put more bits over the wire. Every modern ethercard can receive
|
|
back-to-back packets. The Linux DP8390 drivers come pretty close to
|
|
sending back-to-back packets (depending on the current interrupt
|
|
latency) and the 3c509 and AT1500 hardware has no problem at all
|
|
automatically sending back-to-back packets.
|
|
|
|
The ISA bus can do 5.3MB/sec (42Mb/sec), which sounds like more than
|
|
enough. You can use that bandwidth in several ways:
|
|
|
|
Programmed I/O
|
|
==============
|
|
Pro: Doesn't use any constrained system resources,
|
|
just a few I/O registers, and has no 16M limit.
|
|
Con: Usually the slowest transfer rate, the CPU is waiting
|
|
the whole time, and interleaved packet access is usually
|
|
difficult to impossible.
|
|
|
|
Shared memory
|
|
=============
|
|
Pro: Simple, faster than programmed I/O, and allows random
|
|
access to packets.
|
|
Con: Uses up memory space (a big one for DOS users, only a minor
|
|
issue under Linux), and it still ties up the CPU.
|
|
|
|
Slave (normal) DMA
|
|
==================
|
|
Pro: Frees up the CPU during the actual data transfer.
|
|
Con: Checking boundary conditions, allocating contiguous buffers,
|
|
and programming the DMA registers makes it the slowest
|
|
of all techniques. It also uses up a scarce DMA
|
|
channel, and requires aligned low memory buffers.
|
|
|
|
Master (bus-master) DMA
|
|
=======================
|
|
Pro: Frees up the CPU during the data transfer, can string together
|
|
buffers, can require little or no CPU time lost on the
|
|
ISA bus.
|
|
Con: Requires low-memory buffers and a DMA channel. Any
|
|
bus-master will have problems with other bus-masters that
|
|
are bus-hogs, such as some primitive SCSI adaptors. A few
|
|
badly-designed motherboard chipsets have problems with
|
|
bus-masters. And a reason for not using *any* type of
|
|
DMA device is using a Cyrix 486 processor designed for
|
|
plug-in replacement of a 386: these processors must
|
|
flush their cache with each DMA cycle.
|
|
|
|
5.06 Programming the Intel chips (i82586 and i82593)
|
|
|
|
These chips are used on a number of cards, namely the 3c507 ('86),
|
|
the Intel EtherExpress 16 ('86), Microdyne's exos205t ('86),
|
|
the Z-Note ('93), and the Racal-Interlan ni5210 ('86).
|
|
|
|
Russ Nelson writes:
|
|
"Most boards based on the 82586 can reuse quite a bit of their code.
|
|
More, in fact, than the 8390-based adapters. There are only three
|
|
differences between them:
|
|
|
|
o The code to get the Ethernet address,
|
|
o The code to trigger CA on the 82586, and
|
|
o The code to reset the 82586.
|
|
|
|
The Intel EtherExpress 16 is an exception, as it I/O maps the 82586.
|
|
Yes, I/O maps it. Fairly clunky, but it works.
|
|
|
|
Garrett Wollman did an AT&T driver for BSD that uses the BSD
|
|
copyright. The latest version I have (Sep '92) only uses a single
|
|
transmit buffer. You can and should do better than this if you've
|
|
got the memory. The AT&T and 3c507 adapters do; the ni5210 doesn't.
|
|
|
|
The people at Intel gave me a very big clue on how you queue up
|
|
multiple transmit packets. You set up a list of
|
|
NOP->XMIT->NOP->XMIT->NOP->XMIT->(beginning) blocks, then you set the
|
|
"next" pointer of all the NOP blocks to themselves. Now you start
|
|
the command unit on this chain. It continually processes the first
|
|
NOP block. To transmit a packet, you stuff it into the next transmit
|
|
block, then point the NOP to it. To transmit the next packet, you
|
|
stuff the next transmit block and point the previous NOP to *it*. In
|
|
this way, you don't have to wait for the previous transmit to finish,
|
|
you can queue up multiple packets without any ambiguity as to whether
|
|
it got accepted, and you can avoid the command unit start-up delay."
|
|
|
|
5.07 Technical information from 3Com
|
|
|
|
From: Cameron Spitzer 764-6339 <camerons@nad.3com.com>
|
|
Subject: getting 3Com Adapter manuals
|
|
Date: Mon, 27 Sep 1993 21:17:07 +0200
|
|
|
|
Since this is becoming a FAQ, I'm going to tread the thin
|
|
ice of No Commercial Use and answer it here.
|
|
|
|
3Com's Ethernet Adapters are documented for driver writers
|
|
in our "Technical References" (TRs). These manuals describe
|
|
the programmer interfaces to the boards but they don't talk
|
|
about the diagnostics, installation programs, etc that end
|
|
users can see.
|
|
|
|
The Network Adapter Division marketing department has the
|
|
TRs to give away. To keep this program efficient, we
|
|
centralized it in a thing called "CardFacts." CardFacts is
|
|
an automated phone system. You call it with a touch-tone
|
|
phone and it faxes you stuff. To get a TR, call CardFacts
|
|
at 408-727-7021. Ask it for Developer's Order Form,
|
|
document number 9070. Have your fax number ready when you
|
|
call. Fill out the order form and fax it to 408-764-5004.
|
|
Manuals are shipped by Federal Express 2nd Day Service.
|
|
|
|
If you don't have a fax and nobody you know has a fax,
|
|
really and truly, *then* send mail to
|
|
Terry_Murphy@3Mail.3Com.com and tell her about your problem.
|
|
PLEASE use the fax thing if you possibly can.
|
|
|
|
After you get a manual, if you still can't figure out how to
|
|
program the board, try our "CardBoard" BBS at
|
|
1-800-876-3266, and if you can't do that, write
|
|
Andy_Chan@3Mail.3com.com and ask him for alternatives. If
|
|
you have a real stumper that nobody has figured out yet, the
|
|
fellow who needs to know about it is
|
|
Steve_Lebus@3Mail.3com.com.
|
|
|
|
There are people here who think we are too free with the
|
|
manuals, and they are looking for evidence that the system
|
|
is too expensive, or takes too much time and effort. That's
|
|
why it's important to try to use CardFacts *before* you
|
|
start calling and mailing the people I named here.
|
|
|
|
There are even people who think we should be like Diamond
|
|
and Xircom, requiring tight "partnership" with driver
|
|
writers to prevent poorly performing drivers from getting
|
|
written. So far, 3Com customers have been really good about
|
|
this, and there's no problem with the level of requests
|
|
we've been getting. We need your continued cooperation and
|
|
restraint to keep it that way.
|
|
|
|
Cameron Spitzer, 408-764-6339
|
|
3Com NAD
|
|
Santa Clara
|
|
work: camerons@nad.3com.com
|
|
home: cls@truffula.sj.ca.us
|
|
|
|
5.08 Notes on AMD PCnet-ISA / LANCE Based cards (79C960)
|
|
|
|
The AMD LANCE (Local Area Network Controller for Ethernet)
|
|
was the original offering, and has since been replaced by
|
|
the "PCnet-ISA" chip, otherwise known as the 79C960.
|
|
A relatively new chip from AMD, the 79C960, is the heart of many
|
|
new cards being released at present. Note that the name "LANCE"
|
|
has stuck, and some people will refer to the new chip by the old
|
|
name. Dave Roberts of the Network Products Division of AMD was kind
|
|
enough to contribute the following information regarding this chip:
|
|
|
|
"As for the architecture itself, AMD developed it originally
|
|
and reduced it to a single chip -- the PCnet(tm)-ISA -- over a year
|
|
ago. It's been selling like hotcakes ever since.
|
|
|
|
Functionally, it is equivalent to a NE1500. The register set
|
|
is identical to the old LANCE with the 1500/2100 architecture
|
|
additions. Older 1500/2100 drivers will work on the PCnet-ISA.
|
|
The NE1500 and NE2100 architecture is basically the same.
|
|
Initially Novell called it the 2100, but then tried to distinguish
|
|
between coax and 10BASE-T cards. Anything that was 10BASE-T only was
|
|
to be numbered in the 1500 range. That's the only difference.
|
|
|
|
Many companies offer PCnet-ISA based products, including HP,
|
|
Racal-Datacom, Allied Telesis, Boca Research, Kingston Technology, etc.
|
|
The cards are basically the same except that some manufacturers
|
|
have added "jumperless" features that allow the card to
|
|
be configured in software. Most have not. AMD offers a standard
|
|
design package for a card that uses the PCnet-ISA and many
|
|
manufacturers use our design without change.
|
|
What this means is that anybody who wants to write drivers for
|
|
most PCnet-ISA based cards can just get the data-sheet from AMD. Call
|
|
our literature distribution center at (800)222-9323 and ask for the
|
|
Am79C960, PCnet-ISA data sheet. It's free.
|
|
|
|
A quick way to understand whether the card is a "stock" card
|
|
is to just look at it. If it's stock, it should just have one large
|
|
chip on it, a crystal, a small IEEE address PROM, possibly a socket
|
|
for a boot ROM, and a connector (1, 2, or 3, depending on the media
|
|
options offered). Note that if it's a coax card, it will have some
|
|
transceiver stuff built onto it as well, but that should be near the
|
|
connector and away from the PCnet-ISA.
|
|
|
|
The PCnet-ISA is faster than the original LANCE design and
|
|
makes better use of the available bus bandwidth. Additionally, some
|
|
LANCE bugs were corrected and many enhancements were made."
|
|
|
|
5.09 Multicast and Promiscuous mode
|
|
|
|
One of the things I've been working on recently is the
|
|
major remaining item on the ethercard feature list:
|
|
implementing multicast and promiscuous mode hooks.
|
|
|
|
At first I was planning to do it while implementing either
|
|
the /dev/* or DDI interface, but that's not really the
|
|
correct way to do it. We should only enable multicast or
|
|
promiscuous modes when something wants to look at the
|
|
packets, and shut it down when that application is
|
|
finished, neither of which is strongly related to when the
|
|
hardware is opened or released.
|
|
|
|
I'll start by discussing promiscuous mode, which is
|
|
conceptually easy to implement. For most hardware you
|
|
only have to set a register bit, and from then on you get
|
|
every packet on the wire. Well, it's almost that easy;
|
|
for some hardware you have to shut the board (potentially
|
|
dropping a few packet), reconfigure it, and then re-enable
|
|
the ethercard. This is grungy and risky, but the
|
|
alternative seems to be to have every application register
|
|
before you open the ethercard at boot-time.
|
|
|
|
OK, so that's easy, so I'll move on something that's not
|
|
quite so obvious: Multicast. It can be done two ways:
|
|
|
|
1) Use promiscuous mode, and a packet filter like the
|
|
Berkeley packet filter (BPF). The BPF is a pattern matching
|
|
stack language, where you write a program that picks out the
|
|
addresses you are interested in. Its advantage is that it's
|
|
very general and programmable. Its disadvantage is that there
|
|
is no general way for the kernel to avoid turning on promiscuous
|
|
mode and running every packet on the wire through every registered
|
|
packet filter. See the next section for more information on BPF.
|
|
|
|
2) Using the built-in multicast filter that most etherchips have.
|
|
|
|
I guess I should list what a few ethercards/chips provide:
|
|
|
|
Chip/card Promiscuous Multicast filter
|
|
========================================
|
|
Seeq8001/3c501 Yes Binary filter (1)
|
|
3Com/3c509 Yes Binary filter (1)
|
|
8390 Yes Autodin II six bit hash (2) (3)
|
|
LANCE Yes Autodin II six bit hash (2) (3)
|
|
i82586 Yes Hidden Autodin II six bit hash (2) (4)
|
|
|
|
|
|
(1) These cards claim to have a filter, but it's a simple
|
|
yes/no 'accept all multicast packets', or 'accept no
|
|
multicast packets'.
|
|
|
|
(2) AUTODIN II is the standard ethernet CRC (checksum)
|
|
polynomial. In this scheme multicast addresses are hashed
|
|
and looked up in a hash table. If the cooresponding bit
|
|
is enabled, this packet is accepted. Ethernet packets are
|
|
laid out so that the hardware to do this is trivial -- you
|
|
just latch six (usually) bits from the CRC circuit (needed
|
|
anyway for error checking) after the first six octets (the
|
|
destination address), and use them as an index into the
|
|
hash table (six bits == a 64-bit table).
|
|
|
|
(3) These chips use the six bit hash, and must have the
|
|
table computed and loaded by the host. This means the
|
|
kernel must include the CRC code.
|
|
|
|
(4) The 82586 uses the six bit hash internally, but it
|
|
computes the hash table itself from a list of multicast
|
|
addresses to accept.
|
|
|
|
Note that none of these chips do perfect filtering, and we
|
|
still need a middle-level module to do the final
|
|
filtering. Also note that in every case we must keep a
|
|
complete list of accepted multicast addresses to recompute
|
|
the hash table when it changes.
|
|
|
|
My first pass at device-level support is detailed in the
|
|
new outline driver:
|
|
ftp.super.org:/pub/linux/pl14/skeleton.c
|
|
|
|
Also in that directory you'll find all of my drivers
|
|
updated to use the proposed promiscuous/multicast mode
|
|
hook.
|
|
|
|
#ifdef HAVE_MULTICAST
|
|
static void set_multicast_list(struct device *dev, int num_addrs,
|
|
void *addrs);
|
|
#endif
|
|
.
|
|
.
|
|
|
|
ethercard_open() {
|
|
...
|
|
#ifdef HAVE_MULTICAST
|
|
dev->set_multicast_list = &set_multicast_list;
|
|
#endif
|
|
...
|
|
|
|
#ifdef HAVE_MULTICAST
|
|
/* Set or clear the multicast filter for this adaptor.
|
|
num_addrs == -1 Promiscuous mode, receive all packets
|
|
num_addrs == 0 Normal mode, clear multicast list
|
|
num_addrs > 0 Multicast mode, receive normal and
|
|
MC packets, and do best-effort filtering.
|
|
*/
|
|
static void
|
|
set_multicast_list(struct device *dev, int num_addrs, void *addrs)
|
|
{
|
|
...
|
|
|
|
Any comments, criticism, etc. are welcome.
|
|
|
|
Alan Cox adds that "...in pl14, user programs can access promiscuous
|
|
mode but not multicast mode, even though the drivers support both.
|
|
The ifconfig program allows you to mark an interface 'promisc'."
|
|
|
|
5.10 The Berkely Packet Filter (BPF)
|
|
|
|
I'm not bitterly opposed to it, but I'm coming to the
|
|
conclusion that the 'bpf' functionality should not be provided
|
|
by the kernel, but should be in a (hopefully little-used)
|
|
compatibility library.
|
|
|
|
For those not in the know: 'bpf' (the Berkeley Packet Filter)
|
|
is an mechanism for specifying to the kernel networking layers
|
|
what packets you are interested in. It's implemented as a
|
|
specialized stack language interpreter built into a low level
|
|
of the networking code. An application passes a program
|
|
written in this language to the kernel, and the kernel runs the
|
|
program on each incoming packet. If the kernel has multiple
|
|
'bpf' applications, each program is run on each packet.
|
|
|
|
The problem is that it's difficult to deduce what kind of
|
|
packets the application is really interested in from the packet
|
|
filter program, so the general solution is to always run the
|
|
filter. Imagine a program that registers a 'bpf' program to
|
|
pick up a low data-rate stream sent to a multicast address.
|
|
Most ethernet cards have a hardware multicast address filter
|
|
implemented as a 64 entry hash table that ignores most unwanted
|
|
multicast packets, so the capability exists to make this a very
|
|
inexpensive operation. But with the BFP the kernel must switch
|
|
the interface to promiscuous mode, receive _all_ packets, and
|
|
run them through this filter. This is work, BTW, that's very
|
|
difficult to account back to the process requesting the packets.
|
|
|
|
5.11 Unresolved questions / concerns
|
|
|
|
There may be some benefit from processing packet data as it is
|
|
transferred to and from the ethercard, especially with very fast
|
|
processors transferring data to a slow ethercard. As I see it this
|
|
question has multiple parts:
|
|
1) Is there any useful processing power available, perhaps
|
|
during the ISA bus recovery period, or while the 8390
|
|
remote DMA is preparing for another transfer??
|
|
2) Is there any useful but simple work that can be done
|
|
between/during each word of the copy, such as calculating
|
|
a CRC, or discarding obviously unwanted packets??
|
|
3) would the complexity of an interface to do this make future
|
|
ethercard drivers impossible??
|
|
|
|
There should be a better structure than Space.c Drivers should be
|
|
able to autoprobe for all installed ethercards rather than just
|
|
quitting after finding the first. I've written code to do this,
|
|
but the constant promise (threat?) of DDI has prevented me from
|
|
making it standard.
|
|
|
|
A related topic is the problem of driver probes corrupting
|
|
unrelated hardware. Even worse is a probe into a dataport that
|
|
isn't set up to transfer data, which will freeze the machine. The
|
|
common suggestion is a boot-time device registry that records
|
|
already-used I/O ports and shared memory. This has been implemented
|
|
as of pl13, see section 5.01.
|
|
|
|
6 Possible problems, and troubleshooting.
|
|
|
|
This section tries to answer any unresolved questions, and not so
|
|
common solutions to common problems. They are sorted on a "per
|
|
manufacturer basis". You should have also read the relevant info.
|
|
from section 1 about your specific card. Section 8 contains more
|
|
general FAQ's.
|
|
|
|
6.01 Problems with NE2000 (and clones)
|
|
|
|
"DMA address mismatch"
|
|
======================
|
|
|
|
Is the chip a real NatSemi 8390? (DP8390, DP83901, DP83902 or DP83905)?
|
|
If not, some clone chips don't correctly implement the transfer
|
|
verification register. MS-DOS drivers never do error checking,
|
|
so it doesn't matter to them.
|
|
|
|
Are most of the messages off by a factor of 2?
|
|
If so: Are you using the NE2000 in a 16 bit slot?
|
|
Is it jumpered to use only 8 bit transfers?
|
|
|
|
The Linux driver expects a NE2000 to be a 16 bit slot. A NE1000 can
|
|
be in either size slot. This problem can also occur with some clones,
|
|
notably D-Link 16 bit cards, that don't have the correct ID bytes
|
|
in the station address PROM. [[ This should be fixed in pl12.]]
|
|
|
|
Are you running the bus faster than 8Mhz?
|
|
If you can change the speed (faster or slower), see if that
|
|
makes a difference. Most NE2000 clones will run at 16Mhz, but
|
|
some may not. Changing speed can also mask a noisy bus.
|
|
|
|
What other devices are on the bus?
|
|
If moving the devices around changes the reliability, then you
|
|
have a bus noise problem -- just what that error message was
|
|
designed to detect. Congratulations, you've probably found the
|
|
source of other problems as well.
|
|
|
|
Machine Hangs during Boot.
|
|
==========================
|
|
|
|
Problem: The machine hangs during boot right after the "8390..." or
|
|
"WD...." message. Removing the NE2000 fixes the problem.
|
|
|
|
Solution: Change your NE2000 base address to 0x360 (or 0x340 for
|
|
pl12 or later kernels.) Alternatively, you can use the new
|
|
device registrar implemented in pl13 (see section 5.1)
|
|
|
|
Reason: Your NE2000 clone isn't a good enough clone. An active
|
|
NE2000 is a bottomless pit that will trap any driver
|
|
autoprobing in its space. The other ethercard drivers take
|
|
great pain to reset the NE2000 so that it's safe, but some
|
|
clones cannot be reset. Clone chips to watch out for:
|
|
Winbond 83C901. Changing the NE2000 to a less-popular
|
|
address will move it out of the way of other autoprobes,
|
|
allowing your machine to boot.
|
|
|
|
Problem: The machine hangs during the SCSI probe at boot.
|
|
|
|
Solution: It's the same problem as above, change the
|
|
ethercard's address, or use the device registrar.
|
|
|
|
Problem: The machine hangs during the soundcard probe at boot.
|
|
|
|
Solution: No, that's really during the silent SCSI probe, and it's
|
|
the same problem as above.
|
|
|
|
"eth0: DMAing conflict in ne_block_input"
|
|
=========================================
|
|
|
|
This bug came from timer-based packet retransmissions. If you got a
|
|
timer tick _during_ a ethercard RX interrupt, and timer tick tried to
|
|
retransmit a timed-out packet, you could get a conflict. Because of
|
|
the design of the NE2000 you would have the machine hang (exactly the
|
|
same the NE2000-clone boot hangs).
|
|
|
|
Early versions of the driver disabled interrupts for a long time,
|
|
and didn't have this problem. Later versions are fixed. (ie. kernels
|
|
after 0.99p9 should be OK.)
|
|
|
|
NE2000 not detected at boot.
|
|
============================
|
|
|
|
A few people have reported a problem with detecting the Accton NE2000.
|
|
This problem occurs only at boot-time, and the card is later detected
|
|
at run-time by the identical code my (alpha-test) ne2k diagnostic
|
|
program. Accton has been very responsive, but I still haven't tracked
|
|
down what is going on. I've been unable to reproduce this problem
|
|
with the Accton cards we purchased. If you are having this problem,
|
|
please send me an immediate bug report. For that matter, if you have
|
|
an Accton card send me a success report, including the type of the
|
|
motherboard. I'm especially interested in finding out if this problem
|
|
moves with the particular ethercard, or stays with the motherboard.
|
|
|
|
6.02 Problems with WD80*3 cards
|
|
|
|
Detected Non-existent Ethercard
|
|
===============================
|
|
|
|
Problem: A WD80*3 is falsely detected. Removing the sound or
|
|
MIDI card eliminates the "detected" message.
|
|
|
|
Solution: Update your ethercard driver: new versions include an
|
|
additional sanity check.
|
|
|
|
Reason: Some MIDI ports happen to produce the same checksum as a
|
|
WD ethercard.
|
|
|
|
Error messages from the 80*3
|
|
============================
|
|
|
|
Problem: You get messages such as the following with your 80*3:
|
|
eth0: bogus packet size, status = ........
|
|
kmalloc called with impossibly large argument (65400)
|
|
eth0: Couldn't allocate sk_buff of size 65400
|
|
eth0: receiver overrun
|
|
|
|
Reason: There is a shared memory problem.
|
|
|
|
Solution: If the problem is sparodic, you have hardware problems.
|
|
Typical problems that are easy to fix are board conflicts,
|
|
having cache or "shadow ROM" enabled for that region, or
|
|
running your bus faster than 8Mhz. There are also a
|
|
surprising number of memory failures on ethernet cards,
|
|
so run a diagnostic program if you have one for your
|
|
ethercard.
|
|
|
|
If the problem is continual, and you have have to reboot
|
|
to fix the problem, record the boot-time probe message
|
|
and mail it to becker@super.org Take particular note of
|
|
the shared memory location.
|
|
|
|
6.03 Problems with 3Com cards
|
|
|
|
Choosing the Interrupt of the 3c503
|
|
===================================
|
|
|
|
Problem: The 3c503 picks IRQ n at boot, but this is needed for some
|
|
other device which needs IRQ n. (eg. CD ROM driver, etc.)
|
|
Can this be fixed without compiling this into the kernel?
|
|
|
|
Solution: The 3c503 driver probes for a free IRQ line in the order
|
|
{5, 9/2, 3, 4}, and it should pick a line which isn't being
|
|
used. The pre-pl12 (SLS 1.02) driver picked the IRQ line
|
|
at boot-time, and the current driver (pl12) chooses when
|
|
the card is open()/'ifconfig'ed. Note the "bug" noted in
|
|
the 3c503 section in 1.01
|
|
|
|
Alternately, you can fix the IRQ at boot by passing
|
|
parameters via LILO. The following selects IRQ9, base
|
|
location 0x300, <ignored value>, and if_port #1 (the
|
|
external transceiver).
|
|
lilo: linux ether=9,0x300,0,1,eth0
|
|
|
|
The following selects IRQ3, probes for the base location,
|
|
<ignored value>, and the default if_port #0 (the internal
|
|
transceiver)
|
|
lilo: linux ether=3,0,0,0,eth0
|
|
|
|
"3c503: Configured interrupt number XX is out of range."
|
|
========================================================
|
|
|
|
Problem: Whoever built your kernel fixed the ethercard IRQ at XX.
|
|
|
|
Reason: The above is truly evil, and worse than that, it is
|
|
not necessary. The 3c503 will autoIRQ when it gets
|
|
"ifconfig"ed, and pick one of IRQ{5, 2/9, 3, 4}.
|
|
|
|
Solution: Use lilo to set the IRQ, or rebuild the kernel, enabling
|
|
autoIRQ by not specifying the IRQ line.
|
|
|
|
Choosing the output of the 3c503
|
|
================================
|
|
|
|
Problem: The supplied 3c503 drivers don't use the AUI (thicknet) port.
|
|
How does one choose it over the default thinnet port?
|
|
|
|
Solution: The 3c503 AUI port can be selected at boot-time with 0.99pl12
|
|
and later. The selection is overloaded onto the low bit of
|
|
the currently-unused dev->rmem_start variable, so a boot-time
|
|
parameter of:
|
|
lilo: linux ether=0,0,0,1,eth0
|
|
should work. A boot line to force IRQ 5, port base 0x300,
|
|
and use an external transceiver is:
|
|
lilo: linux ether=5,0x300,0,1,eth0
|
|
|
|
7 Networking with a laptop computer
|
|
|
|
There are currently only a few ways to put your laptop on a network.
|
|
You can use the NET-2 SLIP code (and run at serial line speeds);
|
|
you can buy one of the few laptops that come with a NE2000-compatible
|
|
ethercard or PCMCIA slot built-in; you can get a laptop with a
|
|
docking station and plug in an ISA ethercard; or you can use a
|
|
parallel port Ethernet adapter such as the D-Link DE-600.
|
|
|
|
7.01 Option 1 -- using SLIP
|
|
|
|
This is the cheapest solution, but by far the most difficult. Also,
|
|
you will not get very high transmission rates. Since SLIP is not
|
|
really related to ethernet cards, it will not be discussed further
|
|
here. See the NET-2 HOWTO.
|
|
|
|
7.02 Option 2 -- Built in NE2000 compatible or PCMCIA Ethercard.
|
|
|
|
The second solution severely limits your laptop choices and is fairly
|
|
expensive. Be sure to read the specifications carefully, you may find
|
|
that you will have to buy an additional non-standard transceiver to
|
|
actually put the machine on a network. Anyone who has used a PCMCIA
|
|
Ethernet card is requested to contact us so that we can add it to
|
|
this document. Barry Jaspan <bjaspan@security.ov.com> has started
|
|
some work on controlling the PCMCIA slot.
|
|
|
|
7.03 Option 3 -- ISA Ethercard in the Docking Station.
|
|
|
|
I recommend the third solution. Docking stations for laptops typically
|
|
cost about $250 and provide two full-size ISA slots, two serial and one
|
|
parallel port. Most (all?) docking stations are powered off of the
|
|
laptop's batteries, and a few allow adding extra batteries in the
|
|
docking station if you use short ISA cards. You can add an inexpensive
|
|
ethercard and enjoy full-speed ethernet performance.
|
|
|
|
7.04 Option 4 -- Pocket / parallel port adaptors.
|
|
|
|
The "pocket" ethernet adaptors may also fit your need.
|
|
Until recently they actually costed more than a docking station and
|
|
cheap ethercard, and most tie you down with a wall-brick power supply.
|
|
The only pocket adaptor driver right now is for the D-Link.
|
|
I'm also working on a driver for the AT-LAN-TEC/RealTek pocket adaptor.
|
|
Most other companies, especially Xircom, treat the programming
|
|
information as a trade secret, so support will likely be slow in
|
|
coming.
|
|
|
|
You can sometimes avoid the wall-brick with the adaptors by buying
|
|
or making a cable that draws power from the laptop's keyboard
|
|
port.
|
|
|
|
8 Frequently asked questions
|
|
|
|
Here are some of the more frequently asked questions about using
|
|
Linux with an Ethernet connection. Some of the more specific
|
|
questions are sorted on a "per manufacturer basis" and are listed
|
|
in the "Troubleshooting" section. (section 6). However, since this
|
|
document is basically "old" by the time you get it, any "new" problems
|
|
will not appear here instantly. For these, I suggest that you make
|
|
efficient use of your newsreader. For example, nn users would type
|
|
nn -xX -s'3c'
|
|
to get all the news articles in your subscribed list that have
|
|
"3c" in the subject. (ie. 3com, 3c509, 3c503, etc.)
|
|
The moral: Read the man page for your newsreader.
|
|
|
|
8.01 Just the FAQ's ma'am -- just the FAQ's.
|
|
|
|
Q: I heard that there is an alpha driver available for my card.
|
|
Where can I get it?
|
|
|
|
A: Assuming that it is a djb driver, it will be on ftp.super.org
|
|
in the /pub/linux/ area. Things change here quite frequently,
|
|
so just look around for it. There is usually only about 3
|
|
subdirs, so you should be able to find it. Now, if it really
|
|
is an alpha, or pre-alpha driver, then please treat it as
|
|
such. In other words, don't complain because you can't figure
|
|
out what to do with it. If you can't figure out how to install
|
|
it, then you probably shouldn't be testing it. Also, if it brings
|
|
your machine down, don't complain. Instead, send us a well
|
|
documented bug report, or even better, a patch!
|
|
|
|
Q: Is there token ring support for Linux?
|
|
|
|
A: No, there is no token ring support in Linux. To support token ring
|
|
requires more than only a writing a device driver, it also requires
|
|
writing the source routing routines for token ring. Given that
|
|
token ring is expensive, not fast, and will probably be swept away
|
|
by 100baseVG in a few months, it doesn't seem worth it to write
|
|
a driver. In case anyone wants to, I looked at writing a token ring
|
|
device driver, and concluded that the hardware interface
|
|
wasn't too difficult to do, but writing the support for source
|
|
routing would take significantly longer than I was willing to spend
|
|
on an expensive and dying technology.
|
|
|
|
Alan Cox adds: "It will require [...] changes to the bottom socket
|
|
layer to support 802.2 and 802.2 based TCP/IP. Don't expect
|
|
anything soon."
|
|
|
|
Q: Is there IPX or Novell support available for Linux?
|
|
|
|
A: Alan Cox writes: "The novell protocols are available from novell
|
|
for various amounts. IPX is freely documented. SPX is about $1000
|
|
but I'm told Xerox SPP is identical. _PLEASE_ has anyone got any
|
|
freely distributable Xerox SPP code/documentation? The novell
|
|
server spec costs you $15000 + royalties providing you only
|
|
want to write a client, or $30000 + royalties otherwise. Needless
|
|
to say the final output has to be binary only and subject to a
|
|
novell license. Reading their license rules by my interpretation
|
|
its also impossible for us to do because you would seem to have
|
|
to bar disassembly of your final result, which is not allowed
|
|
in the EEC.
|
|
|
|
Bits of NCP are known, and I hope eventually enough will be known
|
|
to write limited NCP support into Linux, for the moment I'm poking
|
|
around at IPX, tho this will have to wait until the new network
|
|
code is finished.
|
|
|
|
An Alpha test IPX protocol layer is available from me (Alan)
|
|
for pl14 or higher. People are also exploring the issue of NCP and
|
|
the new Dr Dobbs journal article on the innards of netware has
|
|
provided a core of good information."
|
|
|
|
As an alternative, Miquel van Smoorenburg suggests the following:
|
|
"It _is_ possible to set up a dedicated PC running both novell and
|
|
the PD SOSS server and let it gateway from NFS to novell. This way
|
|
it is possible to mount the Novell drives on the Unix client.
|
|
|
|
SOSS is a PD (perhaps with some restrictions, but freely available)
|
|
NFS server for DOS. It includes the PC/IP TCP/IP implementation
|
|
and runs on a packet driver. I have run both a Novell client
|
|
(with PDIPX, a Packet Driver IPX) and this SOSS server together
|
|
successfully."
|
|
|
|
Q: What needs to be done so that Linux can run two ethernet cards?
|
|
|
|
A: The easiest solution is to get 0.99pl13, which already includes
|
|
the changes described below. You can enable additional ethercards
|
|
with LILO parameters such as
|
|
lilo: linux ether=5,0x300,0,1,eth0 ether=15,0x280,eth1
|
|
|
|
For pre-pl13 you can enable additional ethercards by
|
|
adding another entry to Space.c, naming it "eth1" instead
|
|
of "eth0". If you want routing to work well you should
|
|
use a recent kernel, say 0.99pl11 or later. You may also
|
|
want to verify that your driver writer kept all of the
|
|
per-card variables in 'dev->priv'. Most do, but the pl12
|
|
AT1500/LANCE driver has a single static low-memory buffer.
|
|
|
|
Q: I have /dev/eth0 as a link to /dev/xxx. Is this right?
|
|
|
|
A: Contrary to the Net-2 HowTo, the files in /dev/* are not used.
|
|
I originally thought that they might be an OK idea. I've since
|
|
concluded that they won't work, at least in the documented form.
|
|
|
|
9 Miscellaneous.
|
|
|
|
Any other associated stuff that didn't fit in anywhere else gets
|
|
dumped here. It may not be relevant, and it may not be of general
|
|
interest but it is here anyway.
|
|
|
|
9.01 The Cabletron story. (...as related by Donald J. Becker)
|
|
|
|
I contacted Cabletron in early December 1992 for
|
|
programming information (I had called and sent several
|
|
earlier messages). I was referred through several
|
|
different people, and each one took several days to
|
|
respond before they forwarded me to the next. Eventually
|
|
I was told I should deal with their (outside?) developer
|
|
Mr. Dev.Null. I persisted, and around March it seemed
|
|
that I had finally succeed: Cabletron offered to send me
|
|
an evaluation board (unrequested) and everything I needed
|
|
to use it (what I wanted). The hardware showed up right
|
|
away, and I waited, expecting the the programming
|
|
information information as well. About a month later I
|
|
contacted them, and they told me that "all I needed to use
|
|
it" was the standard MS-DOS NDIS drivers, a binary on
|
|
standard driver disk. The disk envelope was covered in
|
|
legalese, including no-disassembly, no-reverse-engineering
|
|
clauses. It was May (and a few email exchanges later)
|
|
before I figured out that I had been "slow rolled", and
|
|
had wasted about 20 hours on this particular windmill.
|
|
|
|
The story isn't over yet. People have written to me say
|
|
they have vetoed several medium-sized purchases from
|
|
Cabletron based on the lack of Linux drivers. Cabletron
|
|
must have noticed this because yesterday I got a call
|
|
_from_ Cabletron (the first!) stating that they will be
|
|
independently writing a Linux driver. Of course, their
|
|
lawyers probably haven't read the GPL yet...
|
|
|
|
9.02 The Xircom story. (...as related by Russ Nelson)
|
|
|
|
From: "Russell Nelson" <nelson@crynwr.com>
|
|
Subject: Xircom support (horses mouth)
|
|
Date: Mon, 30 Aug 1993 17:01:04 +0300
|
|
|
|
Okay, here's the word on Xircom support. I spoke to Dirk
|
|
Gates, President of Xircom, about the packet driver
|
|
situation. Yes, the packet driver uses the Crynwr packet
|
|
driver skeleton, and yes, it's in violation of the GPL.
|
|
However, it was not Xircom's intention to violate the GPL.
|
|
They paid Persoft to write a proprietary driver for them,
|
|
and Persoft used the Clarkson skeleton, alleging that the
|
|
code was in the public domain. Xircom is unsuable because
|
|
they were an innocent infringer. I will shortly be sending
|
|
them a demand letter. If they continue to distribute the
|
|
driver after they get the letter, they will be in
|
|
infringement and I can *then* sue them. Xircom has
|
|
basically the same philosophy as Diamond. The actual
|
|
hardware interface is reverse-engineerable in the space of a
|
|
day or so. However, Xircom prefers to write all their own
|
|
drivers, because badly-written drivers reflect badly on
|
|
their product. They also perceive a monetary interest in
|
|
keeping their product proprietary. Xircom would *probably*
|
|
release the specs at this point if they were approached by
|
|
an ad-hoc consortium of potential purchasers who required
|
|
the specs as a condition of purchase. However, I don't
|
|
think this is the right thing to do. At this point they
|
|
have already gotten all the proprietary advantage they are
|
|
going to. Purchasing their product now will only reward
|
|
their "bad attitude" toward open systems. Much better to
|
|
purchase from a vendor who appreciates and encourages open
|
|
systems, such as D-Link.
|
|
|
|
9.03 Closing
|
|
|
|
If you have found any glaring typos, or outdated info in this
|
|
document, please let one of us know.
|
|
|
|
Paul Gortmaker <gpg109@rsphysse.anu.edu.au>
|
|
Donald J. Becker <becker@super.org>
|
|
|
|
=========== end of Ethernet HOWTO ============
|
|
|
|
|