Frequently Asked Questions

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

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

## 8.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. You can enable additional ethercards with LILO parameters such as:

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

These boot time arguments can be made permanent so that you don't have to re-enter them every time. See the LILO manual, and Passing Ethernet Arguments... where there are tips on using LILO to pass boot-time ethernet card arguments.

Also note that only *one* ethercard is auto-probed for, and the second *must* be specified as above. This avoids a lot of possible boot time hangs caused by probing sensitive cards. Probing for the second card can be achieved by using something 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. With the previous example, the user has forced the card at `0x300` to be `eth0` and the card at `0x280` to be `eth1`.

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 .

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

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

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

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.

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: Network `goes away' every time I print something (NE2000)

Reason: You have your NE2000 living at 0x360, and a NE2000 is 0x20 ports wide, putting it to 0x380. Your parallel port is at 0x378 and is stepping on the NE2000 cards I/O space. Jumper it to 0x300 or 0x340 or something like that.

## 8.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: 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. (pl15) 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`

## 8.5 Problems with 3Com cards

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.

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.

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

## 8.7 FAQs Not Specific to Any Card.

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

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.

In the future, the DEC 21040 PCI chip will probably be supported as well, but don't hold your breath.

### 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. Those marked with a `+' are ones that are not taken on a permanent basis. 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 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.

Next Chapter, Previous Chapter

Table of contents of this chapter, General table of contents

Top of the document, Beginning of this Chapter