3.9 Merge window, second episode
Posted Feb 28, 2013 19:37 UTC (Thu) by nix
Parent article: 3.9 Merge window, second episode
In addition to a number of DEC copyrights and a bunch of Don Becker's drivers, a number of fabulous comments have disappeared from the kernel this day. A selection:
*!@$ protocol=eth_type_trans -- now packets flow
The EtherWORKS 3 driver in this distribution is designed to work with all
kernels > 1.1.33 (approx) and includes tools in the 'ewrk3tools'
subdirectory to allow set up of the card, similar to the MSDOS
'NICSETUP.EXE' tools provided on the DOS drivers disk (type 'make' in that
subdirectory to make the tools).
2) if you wish, edit the source code near line 1530 to reflect the I/O
address and IRQ you're using
Fix the last fix...sorry, must be galloping senility
case DEPCA_SAY_BOO: /* Say "Boo!" to the kernel log file */
printk("%s: Boo!\n", dev->name);
/* This should be probed for (or set via an ioctl()) at run-time.
Right now we use a sleazy hack to pass in the interface number
at boot-time via the low bits of the mem_end field. That value is
unused, and the low bits would be discarded even if it was used. */
[This is currently quite safe.... but if one day the 3c503 explodes
you know where to come looking ;)]
The E2100 series ethercard is a fairly generic shared memory 8390
implementation. The only unusual aspect is the way the shared memory
registers are set: first you do an inb() in what is normally the
station address region, and the low three bits of next outb() *address*
is used as the write value for that register. Either someone wasn't
too used to dem bit en bites, or they were trying to obfuscate the
One bug on the chip is that even a hard reset won't disable the memory
window, usually resulting in a hung machine if mem_off() isn't called.
If this happens, you must power down the machine for about 30 seconds.
The MB86965 has a design flaw that makes all probes unreliable. Not
only is it difficult to detect, it also moves around in I/O space in
response to inb()s from other device probes!
results from ftp performance tests with Linux 1.2.5
send and receive about 350-400 KByte/s (peak up to 460 kbytes/s)
sending in NOP-mode: peak performance up to 530K/s (but better don't
run this mode)
The card has 256k of on-board RAM, which is used to buffer received packets. It
might seem at first that more buffers are better, but in fact this isn't true.
From my tests, it seems that more than about 10 buffers are unnecessary, and
there is a noticeable performance hit in having more active on the card. So
the majority of the card's memory isn't, in fact, used.
And, of course, the immortal 3c501:
Do not purchase this card, even as a joke. It's performance is horrible,
and it breaks in many ways.
Some documentation is available from 3Com. Due to the boards age
standard responses when you ask for this will range from 'be serious'
to 'give it to a museum'. The documentation is incomplete and mostly
of historical interest anyway.
The driver is less efficient than it could be. It switches through
receive mode even if more transmits are queued. If this worries you buy
a real Ethernet card.
Attempt to send a packet to a 3c501 card. There are some interesting
catches here because the 3c501 is an extremely old and therefore
stupid piece of technology.
We have a good packet. Well, not really "good", just mostly not broken.
to post comments)