3.9 Merge window, second episode

3.9 Merge window, second episode

Posted Feb 28, 2013 19:37 UTC (Thu) by nix (subscriber, #2304)
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 */
        if(!capable(CAP_NET_ADMIN))
                return -EPERM;
        printk("%s: Boo!\n", dev->name);
        break;

/* 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 programming interface.

[...]

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.

---

(Log in to post comments)