# Strange problem with e1000 - no device appearing

## dcdead

Hi, i'm experiencing a very strange problem with my 82547 Intel Network Card (LOM on Intel 875PBZ Board). On my gentoo, installed on the hdd i only see 

e1000: 0000:02:00.1: e1000_probe: (PCI Express:2.5Gb/s:32-bit) 00:15:17:xxxx:xx

e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection

and there is no eth device available. When i boot the gentoo installation CD, everything works fine, besides the above i get the link up message from e1000_watchdog in dmesg. 

For testing, i compiled the same Kernel Version on my installation as used on the CD (2.6.17 with e1000 ver. 7.3.15-k2). I also tried the newest version of the e1000 driver but no help. After that i inserted an intel gbit pci card with 82541 Chip and experienced the exactly the same (even when the onboard chip had been turned off). I tried compiling the driver with and without NAPI but nothing helped...  :Sad:  Are there any kernel options which could cause such a behaviour?

----------

## thoughtform

i have an intel gigabit card and i load it as a module, not compiled in.

make an M by the driver in the kernel and add it to

```

teh portsentry # cat /etc/modules.autoload.d/kernel-2.6

# /etc/modules.autoload.d/kernel-2.6:  kernel modules to load when system boots.

#

# Note that this file is for 2.6 kernels.

#

# Add the names of modules that you'd like to load when the system

# starts into this file, one per line.  Comments begin with # and

# are ignored.  Read man modules.autoload for additional details.

# For example:

# aic7xxx

e1000

nvidia

```

----------

## didymos

Also, what do you mean when you say you tried the newest version of the driver?  Did you mean you used newer kernel source, or built the driver separately?

----------

## DirtyHairy

Do you also get some error of the form

```
The EEPROM Checksum Is Not Valid
```

?

----------

## dcdead

I already tried the kernel module. With newest version i mean the driver from e1000.sf.net which is currently at 7.4.35. I do not get the Checksum error, only those 2 lines above.

----------

## wynn

Could you run

```
ifconfig -a
```

which should show all ethN devices, even those which are not active.

If you get any ethN device, you can run

```
udevinfo -a -p /sys/class/net/ethN | grep DRIVER
```

to find out what driver has snaffled it.

Of course, instead of running "ifconfig -a" you could just look at /sys/class/net ...

----------

## razholio

So, I had this *exact* same problem.  The kernel never prints it in dmesg, but it is actually creating eth2.  ifconfig -a will show eth2, but I thought it was bogus given the lack of eth0 and eth1 (and the fact that a livecd *and* another system image on a HD also showed eth0 as expected).  I don't know what it is about the userland on my main workstation image that does this, but it insists on creating eth2 instead of eth0.

I can use eth2 and dmesg shows its creation once I configure it, but I would like to know why eth0 is not used (alot of things assume that your ethernet device will remain consistent, like vmware).

I would love to hear any ideas if anyone out there has any...

----------

## wynn

Have a look at 70-persistent-net.rules in /etc/udev/rules.d/, this may be forcing the card to eth2.

If it is, you can edit it to make it eth0.

----------

## razholio

THANKYOU!!!

I asked several folks who know linux and gentoo quite well, and noone thought that userspace had anything todo with ethernet device setup.  I didn't think so either, but figured was just missing something.  I can see how this would be useful in some applications, but why the default?  this causes much pain when attempting to swap out NIC's.

What is the correct way to make sure an ethernet interface is not permanently bound to a particular MAC?

----------

## wynn

 *razholio wrote:*   

> I can see how this would be useful in some applications, but why the default?  this causes much pain when attempting to swap out NIC's.
> 
> What is the correct way to make sure an ethernet interface is not permanently bound to a particular MAC?

 I think you mean bound to an ethN, don't you?

The way udev works, it will run 75-persistent-net-generator.rules if 70-persistent-net.rules is missing (I haven't checked this, but it seems likely as 70-persistent-net.rules will be recreated on the next boot if it is deleted).

If you swap out NICs, then you should delete 70-persistent-net.rules as part of the procedure. There may be other ways of doing it but I think there will be more pain involved.

----------

## razholio

wynn:  I'm assuming this was a relatively recent addition to the gentoo config for udev?  I noticed that debian has this disabled by default.  I can see how this would be helpful for a minority of users and confusing for most, however, it is a very cool feature.

Thank you very much for your help!

----------

## wynn

 *razholio wrote:*   

> wynn:  I'm assuming this was a relatively recent addition to the gentoo config for udev?  I noticed that debian has this disabled by default.

 I seem to remember that posts resulting from it appeared recently, but I don't know exactly.

 *razholio wrote:*   

> I can see how this would be helpful for a minority of users and confusing for most, however, it is a very cool feature.

 Don't you think that most users will have only one NIC, and won't be swapping it in and out ?

----------

## dilbot

Same problem here - I see udev is moving eth1 (a VIA chip eth port) to eth0 in my case,  so I guess it then creates the intel device on eth2.

Removing 70-persistent-net.rules and resetting solved the problem.

----------

## gentoo_ram

The reason why this feature is in there is because if you have multiple net cards, especially using different drivers, it might be unpredictable which card will get to which ethX device every time you boot.  It might depend on timing and how things are hot-plugged.

The persistent rules stuff tries to make this more deterministic.  But it means if you change your ethernet hardware, you manually have to do something to get back your original ethX names.  Seems fair to me.

----------

