I've been running a linux server at home successfully for several
years now. Previously, the server had been configured with two
ethernet cards:

1. Intel InBusiness 10/100 - eth0 - internet connection (DSL)
2. Intel Pro/100 - eth1 - internal lan

I recently purchased and installed a third NIC, another Intel
InBusiness 10/100 card. The purpose of this third NIC is to serve as
the primary interface to a firewalled WIFI network I am installing at
home.

The server is running Debain 3.0r1 (Woody). The kernel is 2.4.20
(stock) with the 'e100' driver compiled into the kernel (not as a
module). I have tried both the 'eepro100' and 'e100' kernel drivers,
but the results are always the same:

Although the system boots, and recognizes the third ethernet card as
eth2, I cannot get the interface into 'RUNNING' mode according to the
output of 'ifconfig -a'.

Here is the output of 'ifconfig -a' (note all neworks use non-routable
addreses):

# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:03:47:0A:40:F5
          inet addr:10.0.0.1  Bcast:10.0.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1176 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1421 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:227637 (222.3 KiB)  TX bytes:941697 (919.6 KiB)
          Interrupt:10 Base address:0x9000 Memory:e3306000-e3306038

eth1      Link encap:Ethernet  HWaddr 00:90:27:99:01:7B
          inet addr:192.168.1.2  Bcast:192.168.1.255 
Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:33462 errors:0 dropped:0 overruns:0 frame:0
          TX packets:32871 errors:0 dropped:0 overruns:0 carrier:0
          collisions:21 txqueuelen:100
          RX bytes:6969854 (6.6 MiB)  TX bytes:6105687 (5.8 MiB)
          Interrupt:10 Base address:0x9400 Memory:e3305000-e3305038

eth2      Link encap:Ethernet  HWaddr 00:03:47:95:AB:28
          inet addr:192.168.0.1  Bcast:192.168.0.255 
Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:11 Base address:0x9800 Memory:e3304000-e3304038

Notice that the main difference between eth0/eth1 and eth2 is that
eth2's status line does not include the 'RUNNING' keyword.

Here is the lspci output:

# lspci
00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 3189
00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device b168
00:0a.0 Ethernet controller: Intel Corp. 82559 InBusiness 10/100 (rev
08)
00:0b.0 Ethernet controller: Intel Corp. 82557 [Ethernet Pro 100] (rev
08)
00:0d.0 Ethernet controller: Intel Corp. 82559 InBusiness 10/100 (rev
08)
00:0f.0 RAID bus controller: Promise Technology, Inc.: Unknown device
5275 (rev 01)
00:10.0 USB Controller: VIA Technologies, Inc. UHCI USB (rev 80)
00:10.1 USB Controller: VIA Technologies, Inc. UHCI USB (rev 80)
00:10.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 80)
00:10.3 USB Controller: VIA Technologies, Inc.: Unknown device 3104
(rev 82)
00:11.0 ISA bridge: VIA Technologies, Inc.: Unknown device 3177
00:11.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06)
00:11.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio
Controller (rev 50)
00:14.0 FireWire (IEEE 1394): VIA Technologies, Inc. OHCI Compliant
IEEE 1394 Host Controller (rev 46)
01:00.0 VGA compatible controller: nVidia Corporation NV11 (GeForce2
MX) (rev b2)

And here is the contents of /proc/interrupts:

# cat /proc/interrupts
           CPU0
  0:     204320          XT-PIC  timer
  1:        211          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  4:      12343          XT-PIC  serial
 10:      74510          XT-PIC  eth1, eth0, usb-uhci
 11:     168864          XT-PIC  eth2, usb-uhci, usb-uhci, nvidia
 12:       1554          XT-PIC  PS/2 Mouse
 14:    1233062          XT-PIC  ide0
 15:          1          XT-PIC  ide1
NMI:          0
ERR:          0

My first attempt to fix this problem was to recompile the kernel using
the 'e100' driver istead of the 'eepro100' driver I had originally
been using. This did not help.

Next, I moved the third ethernet card to a new PCI slot, hoping that
it had something to do with IRQ assignments. That did not fix the
problem.

Then, I booted to BIOS, and tried to manually assign IRQ numbers to
the PCI slots. When the machine rebooted, however, it appeard to
totally ignore my IRQ settings and configured the NICs with the
original IRQs as shown in the 'ifconfig' output above.

Many attempts to use 'ifconfig eth2 down' and 'ifconfig eth2 up' have
also failed. Attempts to do 'ifonfig eth2 irq 9' also failed with
'irq: SIOCSIFMAP: Operation not supported'.

My google searches have turned up one other person who seems to have
had a similar problem, but no solution was posted. Attempts to contact
the original poster of that message have failed.

So the primary question is: How do I get my third ethernet card to
function properly?

Possibly related questions (although I'm not positive they are
relative to the solution) would be:

1. Why are the manual IRQ assignments done via BIOS not having any
apparent effect?
2. What is the difference between the RUNNING and the UP status
idicator?
3. Should I purchase a card from a different manufacturer in order to
force the linux kernel to use a different driver?

What's the output of a standard ifconfig (without the -a) does it
include the eth2 in the list?

Using just 'ifconfig' the output appears identical (and included eth2
in all of it's non-RUNNING glory):

# /sbin/ifconfig
eth0      Link encap:Ethernet  HWaddr 00:03:47:0A:40:F5
          inet addr:10.0.0.1  Bcast:10.0.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3525 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8027 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:509511 (497.5 KiB)  TX bytes:2350005 (2.2 MiB)
          Interrupt:10 Base address:0x9000 Memory:e3306000-e3306038

eth1      Link encap:Ethernet  HWaddr 00:90:27:99:01:7B
          inet addr:192.168.1.2  Bcast:192.168.1.255 
Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1223464 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1193761 errors:0 dropped:0 overruns:0 carrier:0
          collisions:374 txqueuelen:100
          RX bytes:235032955 (224.1 MiB)  TX bytes:136924544 (130.5
MiB)
          Interrupt:10 Base address:0x9400 Memory:e3305000-e3305038

eth2      Link encap:Ethernet  HWaddr 00:03:47:95:AB:28
          inet addr:192.168.0.1  Bcast:192.168.0.255 
Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:11 Base address:0x9800 Memory:e3304000-e3304038

It's an interesting problem. I'm actually interested in becoming a
Google researcher, but their not accepting new researchers at the
moment, so I'll just play the comments for the moment.

I run a very similar configuration (eth0-lan, eth1-cable, eth2-dsl),
but my config is a mix of isa & pci based cards.

Looking at the output of lspci on yours, it looks like your 1st & 3rd
network cards are the same? Intel InBusiness 10/100's?  If you swap
the two cards, do you get exactly the same result? (ie: eth0, eth1, no
eth2).

From looking around so far I can't find anything that differentiates
the UP vs RUNNING status, except that they're both normally assigned
when the card is brought up. http://www.tldp.org/LDP/nag/node73.html

Does the 3rd nic get a link light to the unit? ie: what is it plugging
into hub, direct to access point, etc. IT may be that it's not
negotiating a link speed correctly, so although the card is up, the
link is down. I'm not 100% but it would be a logical reason for the
UP, but not running status.

Reading through: http://kernel.kernelnotes.de/linux-2.4.20/Documentation/networking/e100.txt

There are some notes about forcing link type. So it might be worth
shutting down all the links, then try bringing eth2 up by itself, and
check the message log to see if it reports a link speed, etc.

One question that I can answer: The third NIC does NOT get a link
light. Tried multiple cables (and even multiple versions of the exact
same model card).

I went to Fry's today and bought a pair of different ethernet NICs.
One netgear that uses the National Semi driver, and a D-Link that uses
the Rhine driver. I've just finished building those driver modules,
and I'm about to install the NICs and see what happens.

Whish me luck.

If it's not getting a Link light that would be consistent with it not
getting a RUNNING status (based on assumptions, but seems to be
consistent).

Something else I have just thought about. Are you plugging the card
'directly' into the Access Point for the Wireless Lan? Or are both the
card & the AP plugging into a hub/switch.

Access Points are designed primarily to connect onto lans, not
directly to network cards.

If you are plugging the two of them into each other directly, you're
going to need a crossover cable, not a standard twisted pair cable. 
With a crossover cable you may also need to use that force link type
option, not all cards will negotiate a link properly with crossover
cables.

Jp.