Frequently Asked Questions

# 9. Frequently Asked Questions

Contents of this section

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

## 9.1 Alpha Drivers -- Getting and Using them

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:

Don's Linux Home Page

for the latest dirt on what is new and upcoming.

## 9.2 Using More than one Ethernet Card per Machine

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`

The `ether=` command accepts more than the IRQ + i/o + name shown above. Please have a look at Passing Ethernet Arguments... for the full syntax, card specific parameters, and LILO tips.

These boot time arguments can be made permanent so that you don't have to re-enter them every time. See the LILO configuration option ``append`' in the LILO manual.

The second way (not recommended) is to edit the file `Space.c` and replace the `0xffe0` entry for the i/o address with a zero. The `0xffe0` entry tells it not to probe for that device -- replacing it with a zero will enable autoprobing for that device. If you really need more than four ethernet cards in one machine, then you can clone the `eth3` entry and change `eth3` to `eth4`.

Note that if you are intending to use Linux as a gateway between two networks, you will have to re-compile a kernel with IP forwarding enabled. Usually using an old AT/286 with something like the `kbridge' software is a better solution.

If you are viewing this while net-surfing, you may wish to look at a mini-howto Donald has on his WWW site. Check out Multiple Ethercards .

## 9.3 Problems with NE1000 / NE2000 cards (and clones)

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.

## 9.4 Problems with WD80*3 cards

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.

Solution: Recompile a new kernel without any excess drivers that you aren't using, including the above mcd driver. Or try moving your ethercard to a new I/O addr. Valid I/O addr. for all the cards are listed in Probed Addresses You can also point the mcd driver off in another direction by a boot-time parameter (via LILO) such as:

> `mcd=0x200,12`

Problem: Old wd8003 and/or jumper-settable wd8013 always get the IRQ wrong.

Reason: The old wd8003 cards and jumper-settable wd8013 clones don't have the EEPROM that the driver can read the IRQ setting from. If the driver can't read the IRQ, then it tries to auto-IRQ to find out what it is. And if auto-IRQ returns zero, then the driver just assigns IRQ 5 for an 8 bit card or IRQ 10 for a 16 bit card.

Solution: Avoid the auto-IRQ code, and tell the kernel what the IRQ that you have jumpered the card to is via a boot time argument. For example, if you are using IRQ 9, using the following should work.

> `LILO: linux ether=9,0,eth0`

## 9.5 Problems with 3Com cards

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

## 9.6 Problems with Hewlett Packard Cards

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 mid/late versions of 1.1. Recompile a (possibly newer) kernel with support for the HP PCLAN+ and you should be in business.

## 9.7 FAQs Not Specific to Any Card.

### `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.

### Shared Memory ISA cards in PCI Machine

No shared memory cards of any type will work in a PCI machine unless you have the PCI ROM BIOS setup configuration set properly. If you can't figure out which settings are applicable then ask your supplier or local computer guru.

### Token Ring

Is there token ring support for Linux?

To support token ring requires more than only 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.xx.gz`

He says that it is only tested on an MCA 16/4 Megabit Token Ring board, but it should work with other Tropic based boards.

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

There aren't many 32 bit ethercards out there because a 10Mbs network doesn't justify spending the 5x price increment for the 32 bit interface. See Programmed I/O vs. ... as to why having an ethercard on an 8MHz ISA bus is really not a bottleneck.

This might change now that AMD has introduced the 32 bit PCnet-VLB and PCnet-PCI chips. The street price of the Boca PCnet-VLB board should be under $70 from a place like CMO (see Computer Shopper). See Boca PCI/VLB for info on these cards.

See AMD PCnet-32 for info on the 32 bit versions of the LANCE / PCnet-ISA chip.

The DEC 21040 PCI chip is another option (see DEC 21040 ) for power-users. The 21140 100Base-? chip could prove interesting as well, as it is supposedly driver compatible with the 21040. Should be good for uncovering any race-conditions, if nothing else...

### FDDI

Is there FDDI support for Linux?

Donald writes: `No, there is no Linux driver for any FDDI boards. I come from a place with supercomputers, so an external observer might think FDDI would be high on my list. But FDDI never delivered end-to-end throughput that would justify its cost, and it seems to be a nearly abandoned technology now that 100base{X,Anynet} seems imminent. (And yes, I know you can now get FDDI boards for <$1K. That seems to be a last-ditch effort to get some return on the development investment. Where is the next generation of FDDI going to come from?)'

### Linking 10BaseT without a Hub

Can I link 10BaseT (RJ45) based systems together without a hub?

You can link 2 machines easily, but no more than that, without extra devices/gizmos. See Twisted Pair -- it explains how to do it. And no, you can't hack together a hub just by crossing a few wires and stuff. It's pretty much impossible to do the collision signal right without duplicating a hub.

### SIOCSFFLAGS: Try again

I get `SIOCSFFLAGS: Try again' when I run `ifconfig' -- Huh?

Some other device has taken the IRQ that your ethercard is trying to use, and so the ethercard can't use the IRQ. You don't necessairly need to reboot to resolve this, as some devices only grab the IRQs when they need them and then release them when they are done. Examples are some sound cards, serial ports, floppy disk driver, etc. You can type `cat /proc/interrupts` to see which interrupts are presently in use. Most of the Linux ethercard drivers only grab the IRQ when they are opened for use via `ifconfig'. If you can get the other device to `let go' of the required IRQ line, then you should be able to `Try again' with ifconfig.

### Link UNSPEC and HW-addr of 00:00:00:00:00:00

When I run ifconfig with no arguments, it reports that LINK is UNSPEC (instead of 10Mbs Ethernet) and it also says that my hardware address is all zeros.

This is because people are running a newer version of the `ifconfig' program than their kernel version. This new version of ifconfig is not able to report these properties when used in conjunction with an older kernel. You can either upgrade your kernel, `downgrade' ifconfig, or simply ignore it. The kernel knows your hardware address, so it really doesn't matter if ifconfig can't read it.

### Huge Number of RX and TX Errors

When I run ifconfig with no arguments, it reports that I have a huge error count in both rec'd and transmitted packets. It all seems to work ok -- What is wrong?

Look again. It says `RX packets` big number PAUSE `errors 0` PAUSE `dropped 0` PAUSE `overrun 0`. And the same for the `TX` column. Hence the big numbers you are seeing are the total number of packets that your machine has rec'd and transmitted. If you still find it confusing, try typing `cat /proc/net/dev` instead.

### Entries in `/dev/` for Ethercards

I have /dev/eth0 as a link to /dev/xxx. Is this right?

Contrary to what you have heard, the files in /dev/* are not used. You can delete any `/dev/wd0, /dev/ne0` and similar entries.

### Linux and ``trailers''

Should I disable trailers when I `ifconfig' my ethercard?

You can't disable trailers, and you shouldn't want to. `Trailers' are a hack to avoid data copying in the networking layers. The idea was to use a trivial fixed-size header of size `H', put the variable-size header info at the end of the packet, and allocate all packets `H' bytes before the start of a page. While it was a good idea, it turned out to not work well in practice. If someone suggests the use of `-trailers', note that it is the equivalent of sacrificial goats blood. It won't do anything to solve the problem, but if problem fixes itself then someone can claim deep magical knowledge.

### Non-existent Apricot NIC is detected

I get `eth0: Apricot 82596 at 0x300, 00 00 00 00 00 00 IRQ 10` and `apricot.c:v.0.02 19/05/94` when I boot, but I don't have an ``Apricot''. And then the card I do have isn't detected.

A few kernel releases had a version of the Apricot driver which only used a simple checksum to detect if an Apricot is present. This would mistakenly think that almost everything was an Apricot NIC. It really should look at the vendor prefix instead. However there is now a check to see if the hardware address is all zeros, so this shouldn't happen. Your choices are to move your card off of `0x300` (the only place the Apricot driver probes), or better yet, get a new kernel.

Next Chapter, Previous Chapter

Table of contents of this chapter, General table of contents

Top of the document, Beginning of this Chapter