9 Frequently Asked Questions

I heard that there is an alpha driver available for my card. Where can I get it?

The newest of the `new' drivers can be found on Donald's new ftp site: cesdis.gsfc.nasa.gov in the /pub/linux/ area. Things change here quite frequently, so just look around for it. There is still all the stuff on the old ftp site ftp.super.org in /pub/linux, but this is not being actively maintained, and hence will be of limited value to most people.

As of recent v1.1 kernels, the `useable' alpha drivers have been included in the standard kernel source tree. When running make config you will be asked if you want to be offered ALPHA test drivers.

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!

People reading this while net-surfing may want to check out:

What needs to be done so that Linux can run two ethernet cards?

The hooks for multiple ethercards are all there. However, note that only one ethercard is auto-probed for by default. This avoids a lot of possible boot time hangs caused by probing sensitive cards.

There are two ways that you can enable auto-probing for the second (and third, and...) card. The easiest method is to pass boot-time arguments to the kernel, which is usually done by LILO.Probing for the second card can be achieved by using a boot-time argument as simple as ether=0,0,eth1. In this case eth0 and eth1 will be assigned in the order that the cards are found at boot. Say if you want the card at 0x300 to be eth0 and the card at 0x280 to be eth1 then you could use

LILO: linux ether=5,0x300,eth0 ether=15,0x280,eth1

Problem: NE*000 ethercard at 0x360 doesn't get detected anymore.

Reason: Recent kernels ( > 1.1.7X) have more sanity checks with respect to overlapping i/o regions. Your NE2000 card is 0x20 wide in i/o space, which makes it hit the parallel port at 0x378. Other devices that could be there are the second floppy controller (if equipped) at 0x370 and the secondary IDE controller at 0x376--0x377. If the port(s) are already registered by another driver, the kernel will not let the probe happen.

Solution: Either move your card to an address like 0x280, 0x340, 0x320 or compile without parallel printer support.

Problem: Network `goes away' every time I print something (NE2000)

Reason: Same problem as above, but you have an older kernel that doesn't check for overlapping i/o regions. Use the same fix as above, and get a new kernel while you are at it.

Problem: NE*000 ethercard probe at 0xNNN: 00 00 C5 ... not found. (invalid signature yy zz)

Reason: First off, do you have a NE1000 or NE2000 card at the addr. 0xNNN? And if so, does the hardware address reported look like a valid one? If so, then you have a poor NE*000 clone. All NE*000 clones are supposed to have the value 0x57 in bytes 14 and 15 of the SA PROM on the card. Yours doesn't -- it has `yy zz' instead.

Solution: The driver (/usr/src/linux/drivers/net/ne.c) has a "Hall of Shame" list at about line 42. This list is used to detect poor clones. For example, the DFI cards use `DFI' in the first 3 bytes of the prom, instead of using 0x57 in bytes 14 and 15, like they are supposed to.

You can determine what the first 3 bytes of your card PROM are by adding a line like:

    printk("PROM prefix: %#2x %#2x %#2x\n",SA_prom[0],SA_prom[1],SA_prom[2]);

into the driver, right after the error message you got above, and just before the "return ENXIO" at line 227.

Reboot with this change in place, and after the detection fails, you will get the three bytes from the PROM like the DFI example above. Then you can add your card to the bad_clone_list[] at about line 43. Say the above line printed out:

PROM prefix: 0x3F 0x2D 0x1C

after you rebooted. And say that the 8 bit version of your card was called the "FOO-1k" and the 16 bit version the "FOO-2k". Then you would add the following line to the bad_clone_list[]:

{"FOO-1k", "FOO-2k", {0x3F, 0x2D, 0x1C,}},

Note that the 2 name strings you add can be anything -- they are just printed at boot, and not matched against anything on the card. You can also take out the "printk()" that you added above, if you want. It shouldn't hit that line anymore anyway. Then recompile once more, and your card should be detected.

Problem: Errors like 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 in 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.

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.

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 0x340. Alternatively, you can use the device registrar implemented in 0.99pl13 and later kernels.

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.

Reason: 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.

Reason: No, that's really during the silent SCSI probe, and it's the same problem as above.

Problem: Errors like 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.)

Problem: NE2000 not detected at boot - no boot messages at all

Donald writes: `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.'

Here are some things to try, as they have fixed it for some people:

• Change the bus speed, or just move the card to a different slot.
• Change the `I/O recovery time' parameter in the BIOS chipset configuration.

Problem: A WD80*3 is falsely detected. Removing the sound or MIDI card eliminates the `detected' message.

Reason: Some MIDI ports happen to produce the same checksum as a WD ethercard.

Solution: Update your ethercard driver: new versions include an additional sanity check. If it is the midi chip at 0x388 that is getting detected as a WD living at 0x380, then you could also use:

        LILO: linux reserve=0x380,8

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 sporadic, 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@cesdis.gsfc.nasa.gov - Take particular note of the shared memory location.

Problem: WD80*3 will not get detected at boot.

Reason: Earlier versions of the Mitsumi CD-ROM (mcd) driver probe at 0x300 will succeed if just about anything is that I/O location. This is bad news and needs to be a bit more robust. Once another driver registers that it `owns' an I/O location, other drivers (incl. the wd80x3) are `locked out' and can not probe that addr for a card.

Problem: The 3c503 picks IRQ N, but this is needed for some other device which needs IRQ N. (eg. CD ROM driver, modem, 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. Very old drivers used to pick the IRQ line at boot-time, and the current driver (0.99pl12 and newer) chooses when the card is open()/ifconfig'ed.

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

Problem: 3c503: Configured interrupt number XX is out of range.

Reason: Whoever built your kernel fixed the ethercard IRQ at XX. 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 as described above, or rebuild the kernel, enabling autoIRQ by not specifying the IRQ line.

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

Also note that kernel revisions 1.00 to 1.03 had an interesting `feature'. They would switch to the AUI port when the internal transciever failed. This is a problem, as it will never switch back if for example you momentarily disconnect the cable. Kernel versions 1.04 and newer only switch if the very first Tx attempt fails.

Problem: HP Vectra using built in AMD LANCE chip gets IRQ and DMA wrong.

Solution: The HP Vectra uses a different implementation to the standard HP-J2405A. The `lance.c' driver used to always use the value in the setup register of an HP Lance implementation. In the Vectra case it's reading an invalid 0xff value. Kernel versions newer than about 1.1.50 now handle the Vectra in an appropriate fashion.

Problem: HP Card is not detected at boot, even though kernel was compiled with `HP PCLAN support'.

Solution: You probably have a HP PCLAN+ -- note the `plus'. Support for the PCLAN+ was added to final versions of 1.1, but some of them didn't have the entry in `config.in'. If you have the file hp-plus.c in ~/linux/drivers/net/ but no entry in config.in, then add the following line under the `HP PCLAN support' line:

        bool 'HP PCLAN Plus support' CONFIG_HPLAN_PLUS n

Kernels up tp 1.1.54 are missing the line in `config.in' still. Do a `make mrproper;make config;make dep;make zlilo' and you should be in business.

ifconfig reports the wrong i/o address for the card.

No it doesn't. You are just interpreting it incorrectly. This is not a bug, and the numbers reported are correct. It just happens that some 8390 based cards (wd80x3, smc-ultra, etc) have the actual 8390 chip living at an offset from the first assigned i/o port. Try cd /usr/src/linux/drivers/net;grep NIC_OFFSET *.c|more to see what is going on. This is the value stored in dev->base_addr, and is what ifconfig reports. If you want to see the full range of ports that your card uses, then try cat /proc/ioports which will give the numbers you expect.

Token Ring

Is there token ring support for 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. It is the source routing that would be the most time comsuming to write.

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.'

Peter De Schrijver has been spending some time on Token Ring lately, and has patches that are available for IBM ISA and MCA token ring cards. Don't expect miracles here, as he has just started on this as of 1.1.42. You can get the patch from:

aix13ps2.cc.kuleuven.ac.be:/pub/Linux/TokenRing.patch-1.1.49.gz

32 Bit / VLB / PCI Ethernet Cards

What is the selection for 32 bit ethernet cards?

There aren't many 32 bit ethercard device drivers because there aren't that many 32 bit ethercards.