MAC Address change after suspend (atl1e)

[Stuart Young]

Occasionally after suspend, the MAC address for the wired network card on a Eee 901/1000/1000h changes to something other than the correct MAC address. I've had this behavior confirmed by 2 other independent sources on IRC (#eeepc on FreeNode).

On a network with DHCP, this results in a new IP address being allocated after a suspend. It also results in the interface name changing, and a bunch of bogus entries being left in /etc/udev/rules.d/70-persistent-net.rules storing the varied MAC addresses that seem to be given to the adapter after this suspend bug.

Note: This does not happen always. I've had it happen irregularly. When trying to directly force it to happen, it took at least 5 suspends in the space of 3 minutes to get it to happen.

Applies to the 2.6.24-21-eeepc kernel and I've had an independent confirmation that the same bug exists in 2.6.24-22-eeepc kernel in the array.org hardy-proposed repository.

[Adam McDaniel (adamrmcd)]

Thx for the report, unfortunately this may need to be fixed upstream by the atl1e module vendor.

I'll see if there's a more recent version that addresses this.

[Adam McDaniel (adamrmcd)]

It appears that the atl2 module doesn't have this problem.

(atl2 is used by EeePC models 900A and earlier)

[Stuart Young (cef)]

FWIW: I've managed to build a kernel and modules using the array.org git sources and tested a few theories (cleaning up differences between the atl1e driver and the atl2 driver). So far no luck but there's still some code there to go through.

Notes:
 The driver is apparently based on the Intel 1000e driver, so if there are any bugs relating to MAC address changing after suspend with an Intel 1000e, they might contain a solution.
 The atl2 and atl1e code are differently formatted, so as I'm going through things, I'm reformatting it like the atl2 code, at least during testing. If reformatting would prove useful, I'm happy to help.
 There's a whole heap of kcompat code that might not be needed (and in fact if it's being used for whatever reason, could be causing the problem, as it emulates newer kernel functionality for older kernels).
  There is so little difference in most places between the atl2 and atl1e drivers that in future they could probably be merged with a little effort.
 There is a section of code commented out in the atl1e driver that it says saves power by not using it, which is present in the atl2 driver. Still need to test if this is the culprit. If not, it's possible this could be duplicated in the atl2 driver and save a few more mW.
 Main section that showed discrepancies was around get_permanent_address() (which fetches the mac address from the eeprom or the bios) but at leats so far appears not to be causing the issue.

Will keep at it.

[Sitsofe Wheeler (sitsofe)]

Stuart:
Can you make this happen on demand with later kernels (e.g. 2.8.28)? If so, what are the steps you have to follow to trigger this bug? Do you know (again only if those involved are using 2.6.28 or later) if EeePC 900s also showed this issue? Are those involved using the latest BIOS?

[Stuart Young (cef)]

Sitsofe: I have not yet tried later kernels, as I'm still running Hardy. Given the outstanding list of issues I've seen mentioned in the past around power management issues with Intrepid, I've been loathe to change my setup and try.

Will re-evaluate and see if I can upgrade now.

[Stuart Young (cef)]

FWIW: The method to reproduce is simple:

1. Boot with a wired network connection and get an IP. Check the MAC address.

2. Suspend to Ram (using the shutdown dialog and clicking 'suspend' - aka via the menu, NOT through system hotkeys).

3. Resume.

4. Check interface to see if MAC address changed.

5. Repeat.

Notes:

The Assigned (Adam McDaniel) has been able to reproduce this bug himself, but I do not know if he has actual hardware, or if it was a loan unit.

As mentioned, this ONLY affects systems that use the atl1e wired network driver, which should be the 1000H, and the 901. The 900A afaik uses a different wired network driver.

I have had much more success actually suspending using the shutdown dialog than via system hotkeys, and it eliminates any issues that could be caused by the tools that catch/perform the hotkey actions.

[Adam McDaniel (adamrmcd)]

FWIW2: My EeePC 900 has officially died, I picked up a free upgrade to the 901 which has this chipset.

It should be easy enough for me to replicate your problem again and validate it with 2.6.27 and 2.6.28.

I know that upstream ubuntu has issued an upgrade to the atl1e module in 2.6.27.11-ish, but i don't know if this issue was fixed.

I'll validate if this is still issue and post my results this week.

[Sitsofe Wheeler (sitsofe)]

Stuart:
You are right. My Eee 900 uses atl2 not atl1e so I can't test this problem myself.

[Anthony Harrington (linuxchemist)]

I've actually been having this bug myself for a while - i think since maverick meerkat's 2.6.35 kernel?? (9/10 times i use my wireless connection, but i have to use wired at university) and i've finally had enough of this issue :(

(You can check any relevant hardware info you need from other bugs i've posted, but in short i'm on ubuntu 11.10 64bit on an Asus K51AE.)

So it's definitely the atl1e driver and everytime i shutdown/suspend/restart, the MAC address changes (this is a particular problem because the university MAC filters us, so i would have to reregister everytime were it not for a few commands i picked up to get around the problem:

sudo ifconfig eth0 down
sudo ifconfig eth0 hw ether xx:xx:xx:xx:xx:xx
sudo ifconfig eth0 up

(I change the address to one i've registered previously ((However, this only lasts until i shutdown/restart/suspend/until i remove and reinsert the ethernet cable.))

Sometimes, if i restart, it not only changes the MAC address but increments the name for the new connection, i.e. After a few restarts, i can end up being on connection eth8 - when this is the only wired connection i ever use.

I've used dozens of kernels and many versions of ubuntu and lubuntu since this first happened (~xmas 2010?) Possibly a regression somewhere?