first eth device gets new number on resume

[Richard Jonsson]

On resume from suspend to ram, Every other time the eth0 device gets a different number, ie eth43. This number seems to increment too.
Thus a workaround would be to suspend and resume again to get back to the name eth0. The strange thing is that the MAC number is not that of the adapter when this happens, but a different number every time. This makes it impossible to have mac-based connection/firewall rules on the router the computer is connected to.
As I have been using wireless until a few weeks ago I can't tell how long this bug has existed. I noticed it 2 days ago.

Steps to reproduce:
1. boot computer.
2. suspend
3. resume and check eth device name
4. repeat step 2. and 3. if 3. seems ok.

System: gutsy current, daily updates, custom kernel 2.6.24-rc3-git, on x86_64

dmesg for two resumes in a row:
first resume:
[ 2.220559] forcedeth: Reverse Engineered nForce ethernet driver. Version 0.61.
[ 2.482227] PM: Adding info for No Bus:eth0
[ 2.482671] forcedeth 0000:00:14.0: ifname eth0, PHY OUI 0x5043 @ 1, addr 00:16:d3:11:97:e1
[ 2.482675] forcedeth 0000:00:14.0: highdma pwrctl timirq lnktim desc-v3
[ 2.508430] eth0: no link during initialization.
[ 2.509722] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 3.566876] eth0: link up.
[ 3.946072] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 22.802300] eth0: no IPv6 routers present

second resume:
[ 3.073035] forcedeth: Reverse Engineered nForce ethernet driver. Version 0.61.
[ 3.073094] forcedeth 0000:00:14.0: Invalid Mac address detected: e1:97:11:d3:16:00
[ 3.073160] forcedeth 0000:00:14.0: Please complain to your hardware vendor. Switching to a random MAC.
[ 3.592041] PM: Adding info for No Bus:eth0
[ 3.592500] forcedeth 0000:00:14.0: ifname eth0, PHY OUI 0x5043 @ 1, addr 00:00:6c:ee:f2:ed
[ 3.592505] forcedeth 0000:00:14.0: highdma pwrctl timirq lnktim desc-v3
[ 3.771732] eth42: no link during initialization.
[ 3.773029] ADDRCONF(NETDEV_UP): eth42: link is not ready
[ 4.399902] eth42: link up.
[ 5.763947] ADDRCONF(NETDEV_CHANGE): eth42: link becomes ready
[ 11.958840] eth42: no IPv6 routers present
[ 18.205935] eth42: no IPv6 routers present

[Richard Jonsson (richard-jonsson-bredband)]

Just noticed in that dmesg output that the mac address has a revered byte-order. As I don't know what to do with that I'll leave the bug here.

[Richard Jonsson (richard-jonsson-bredband)]

After some research it apperas that the forcedeth driver, which I use, has had issues with reverse mac addresses in other contexts.
A guess is that the driver attempts to correct the address byte order on boot up, but fails to restore on suspend, and therefore reverses the corrected address on resume. I've tried to look up who maintains the driver but found nothing in the driver source files or MAINTAINERS file from the kernel source.

[Richard Jonsson (richard-jonsson-bredband)]

Bug has been confirmed on LKML, and a patch has been provided there, for testing, which solves the issue in my case. See links below:

For a complete discussion on LKML:
http://lkml.org/lkml/2008/1/2/253

The provided patch:
http://lkml.org/lkml/2008/1/3/418

[Lex Ross (lross)]

New forcedeth version 0.61 that now ships with Hardy 8.04 Alpha 6 cured this problem on my nVidia nForce 610M chipset. Any chance of forcedeth driver updates to older kernels?

[Richard Jonsson (richard-jonsson-bredband)]

I hope I assigned this to the right identity. This bug should be easy to backport to a current gutsy kernel. Patch is provided at http://lkml.org/lkml/2008/1/3/418

[sam tygier (samtygier)]

I am seeing this in hardy on an aspire 7520.
after reboot
eth8 Link encap:Ethernet HWaddr 00:1b:38:68:92:6c
after suspend
eth9 Link encap:Ethernet HWaddr 00:00:6c:2b:83:26

i will attach dmesg and lspci -vv

[sam tygier (samtygier)]

after another suspend it changes again
eth10 Link encap:Ethernet HWaddr 00:00:6c:6b:a4:b0

[Richard Jonsson (richard-jonsson-bredband)]

I would just like to point out that sam tygiers bug is not the same as mine, but related ofcourse.

From sam tygiers dmesg:
[ 5.752349] forcedeth 0000:00:0a.0: Invalid Mac address detected: 00:00:00:00:00:00

This card don't read an address at all, whereas my card got it backwards. The patch I linked to earlier here will not work and is most likely included in the hardy kernel anyway.

[Lars G. Hanson (larsh)]

Unfortunately the reverse byte-ordering problem of the MAC address after suspend is still present in Hardy (forcedeth driver), although perhaps not in its original form.

If I suspend or hibernate the usual way, all is good. I need wake-on-lan, however, and the net card must therefore first be put to sleep (ACPI D3 state). Doing this, hibernate still works, but after resuming from suspend, the byte-ordering of the MAC address is inverted, and the interface gets a new name.

A simple workaround: Invert the byte ordering before putting the net card to sleep. Some useful commands for the purpose:

ethtool -s eth0 wol g # enable wake-on-lan on eth0
ethtool -i eth0 | grep bus-info # Find PCI bus/device/function
Returns "bus-info: 0000:00:04.0 (bus 0, device 4, function 0)" in my case.
pci-config is used to set power state to D3, but first the ID must be identified based on the bus-info. List IDs for bus 0:
pci-config -B0 -a
Returns "Device #12 at bus 0 device/function 4/0, 006610de".
Shutdown eth0 and reverse MAC address to avoid problems after resume:
ifconfig eth0 down hw ether 08:f6:11:6e:0c:00 # hw MAC is 00:0c:6e:11:f6:08
Set power state of device #12 to D3:
pci-config -B0 -S -#12
Now suspend or hibernate.
Please note that in order to wake up the machine, you need to use the reversed MAC address:
etherwake 08:f6:11:6e:0c:00
All is well after the wake-up call, but without the MAC reversal above, eth0 would be lost after suspend (in any case eth0 needs to be shut down, otherwise the machine will hang when the NIC power state is changed).

I am happy with my work-around, so I am not eager to try out patches (and my experience with kernel patching is very limited). Also, I am not sure where this bug should be reported.

Thanks,
Lars

Details:
Motherboard: Asus A7N8X Deluxe
Linux corolla 2.6.24-19-generic #1 SMP Fri Jul 11 23:41:49 UTC 2008 i686 GNU/Linux
00:04.0 Ethernet controller: nVidia Corporation nForce2 Ethernet Controller (rev a1)
pci-config is at ftp://ftp.scyld.com/pub/diag/pci-config.c and the power-down procedure was inspired by http://www.nvnews.net/vbulletin/archive/index.php/t-21578.html

[Leann Ogasawara (leannogasawara)]

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

[Leann Ogasawara (leannogasawara)]

Has anyone been able to confirm with Intrepid? Thanks.

[hackob (hackob.me)]

I'm having this problem with ubuntu jaunty:

root@ubuntu:~# dmesg | grep eth
[ 4.691544] forcedeth: Reverse Engineered nForce ethernet driver. Version 0.61.
[ 4.691952] forcedeth 0000:00:0a.0: PCI INT A -> Link[LMAC] -> GSI 20 (level, low) -> IRQ 20
[ 4.691957] forcedeth 0000:00:0a.0: setting latency timer to 64
[ 4.692081] forcedeth 0000:00:0a.0: Invalid Mac address detected: 00:00:00:00:00:00
[ 4.692085] forcedeth 0000:00:0a.0: Please complain to your hardware vendor. Switching to a random MAC.
[ 5.209066] forcedeth 0000:00:0a.0: ifname eth0, PHY OUI 0x732 @ 1, addr 00:00:6c:4a:6c:49
[ 5.209071] forcedeth 0000:00:0a.0: highdma pwrctl mgmt timirq lnktim msi desc-v3
[ 11.388152] udev: renamed network interface eth0 to eth5
[ 23.681659] forcedeth 0000:00:0a.0: irq 2300 for MSI/MSI-X
[ 34.004012] eth5: no IPv6 routers present
[ 881.974103] eth5: link down.

[Leann Ogasawara (leannogasawara)]

Just want to try to keep this report up to date. Care to test and confirm this issue remains with the latest development release of Ubuntu (ie Karmic). ISO CD images are available from http://cdimage.ubuntu.com/releases/ .