# kernel recognizes nic, but no eth [solved]

## Daytona

Having a problem getting an old NIC to function. It's a 3Com 3c900B-TPO.

I have the driver compiled in-kernel, 2.6.20-gentoo-r8.

The kernel appears to be recognizing it:

```
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html

0000:00:12.0: 3Com PCI 3c900 Cyclone 10Mbps TPO at c880cc00.

```

```
00:12.0 Ethernet controller: 3Com Corporation 3c900B-TPO Etherlink XL [Cyclone] (rev 04)

        Subsystem: 3Com Corporation 3C900B-TPO Etherlink XL TPO 10Mb

        Flags: bus master, medium devsel, latency 80, IRQ 11

        I/O ports at fc80 [size=128]

        Memory at fedffc00 (32-bit, non-prefetchable) [size=128]

        [virtual] Expansion ROM at 10000000 [disabled] [size=128K]

        Capabilities: [dc] Power Management version 1

```

The 3com utility says it's in Bus 0, slot/dev 18, so that fits (12h=18d)

Also, according to the 3com utility, the expansion at 10000000 would be the boot rom, if I had one.

However, it should be showing up on IRQ 11, but isn't

```
netres ~ # cat /proc/interrupts

           CPU0

  0:      92409    XT-PIC-XT        timer

  1:          8    XT-PIC-XT        i8042

  2:          0    XT-PIC-XT        cascade

  4:        673    XT-PIC-XT        serial

  6:          3    XT-PIC-XT        floppy

  8:          2    XT-PIC-XT        rtc

 12:          6    XT-PIC-XT        i8042

 14:       1789    XT-PIC-XT        ide0

 15:         53    XT-PIC-XT        ide1

NMI:          0

LOC:          0

ERR:          0

MIS:          0

netres ~ #

```

It is showing up in ioports/iomem:

```
netres ~ # cat /proc/iomem

00000000-0009fbff : System RAM

0009fc00-0009ffff : reserved

000a0000-000bffff : Video RAM area

000c0000-000c7fff : Video ROM

000e7670-000e931f : reserved

000f0000-000fffff : System ROM

00100000-07ffffff : System RAM

  00100000-002c65d9 : Kernel code

  002c65da-0035cf43 : Kernel data

10000000-1001ffff : 0000:00:12.0

10020000-1002ffff : 0000:00:0a.0

fe000000-fe7fffff : 0000:00:0a.0

fedffc00-fedffc7f : 0000:00:12.0

ffff6124-ffffffff : reserved

netres ~ # cat /proc/ioports

0000-001f : dma1

0020-0021 : pic1

0040-0043 : timer0

0050-0053 : timer1

0060-006f : keyboard

0070-0077 : rtc

0080-008f : dma page reg

00a0-00a1 : pic2

00c0-00df : dma2

00f0-00ff : fpu

0170-0177 : 0000:00:0d.0

  0170-0177 : ide1

01f0-01f7 : 0000:00:0d.0

  01f0-01f7 : ide0

02f8-02ff : serial

0376-0376 : 0000:00:0d.0

  0376-0376 : ide1

03c0-03df : vga+

03f2-03f5 : floppy

03f6-03f6 : 0000:00:0d.0

  03f6-03f6 : ide0

03f7-03f7 : floppy DIR

03f8-03ff : serial

0cf8-0cff : PCI conf1

fc80-fcff : 0000:00:12.0

netres ~ #

```

I don't think it's a bus master issue, because I had a D-Link 530TX+ installed that I took out for use elsewhere which was working fine. D-Link says it requires bus mastering, too. Since this machine (dhcp/dns/ntp for home network) doesn't see that much use, I figured I could live with 10Mb. And I already had this card.Last edited by Daytona on Thu Dec 18, 2008 9:08 pm; edited 1 time in total

----------

## gringo

does the nic appear if you look through a ifconfig -a ? what version of udev are you running ?

cheers

----------

## Daytona

udev is 104-r12

Oh, gee. I didn't know about the ifconfig -a command. There it is, under eth1.

I expected it to show under eth0 since the old card was gone. dhcpcd eth1 and all is well.   :Very Happy: 

On a related note, I've been considering switching this machine back to static /dev for a while now. No big need for udev, and it would speeed boot time a little (It's a Pentium-75).

Thanks!

----------

## Hu

 *Daytona wrote:*   

> udev is 104-r12
> 
> I expected it to show under eth0 since the old card was gone. dhcpcd eth1 and all is well.  
> 
> 

 

udev reserved the name eth0 for your old card.  This can be a security feature in some cases.  For example, if your machine had two NICs in it, one connected to a trusted network and the other to an untrusted network, then the udev feature prevents the disappearance of the NIC attached to the trusted network from causing the NIC attached to the untrusted network to assume the name of the trusted NIC.  If it did change names in that circumstance, firewall rules might become wrong in a dangerous way.

If you do not want the old name to remain reserved, look at /etc/udev/rules.d/70-persistent-net.rules.

----------

## Daytona

Ah, I see, That makes sense. And very relevant, both for this (I want another card in here for getting external requests, ie time), and the server I'm going to tackle once this machine is straightened out. I'll check out persistant-net-rules.

Thanks for the info!

----------

