ubuntu-eee-coders team mailing list archive

[Stuart Young <cef@xxxxxxxxx>]

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.

-- 
MAC Address change after suspend (atl1e)
https://bugs.launchpad.net/bugs/271744
You received this bug notification because you are a member of Ubuntu
Eee Coders, which is subscribed to Ubuntu Eee.

Status in Ubuntu Eee: New
Status in Ubuntu EeePC-optimized Kernel: Triaged

Bug description:
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.