r8169 ethernet MAC address changes in 2.6.32 kernel

Though I don't use Ubuntu, I've been hit by the same issue. Luckily the redhat bug report (https://bugzilla.redhat.com/show_bug.cgi?id=573201) contains a link to the kernel fix.

Kernel fix is here:
http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commitdiff;h=78f1cd02457252e1ffbc6caa44a17424a45286b8

The fix is not in -stable yet.

@Thomas
I know that Debian is also affected. Somewhere (I don't recall exactly) I saw a similar message, to the effect that a fix had been committed upstream. No indication was given as to when it would make it to the repositories.

@anyone
Maybe there won't be a fix in time for the Lucid release. If that's the case, is there a workaround? (Apart from compiling one's own kernel, that is)

I've tested the fully-updated install with the latest mainline kernel, 2.6.34-020634rc5-i386 (should have thought of this sooner).

The problem shows no signs of occurring while using this kernel, even after several reboots.

After behaving well for a couple of days or so, the mainline kernel has been throwing errors on this over the last several hours, particularly not activating the ethernet chip at all (lights on switch blink slowly). I had noticed that my working ethernet connection was labelled "eth1" instead of "eth0". I altered that in /etc/udev/rules.d/70-persistent-net.rules, removed dhcp3 leases and rebooted. That's when the problem started.

Whether that's what caused it, or whether that was a coincidence and a buggy update was the culprit, I have no idea. I'll do a reinstall later today and see what the result is.

Irihapeti - please try linux_2.6.32-22.33~lp562742 in my PPA at http://launchpad.net/~timg-tpi/+archive/ppa

@Tim:

Sorry, the machine is still exhibiting the same behaviour with your kernel.

First boot: OK
Subsequent reboots, whether into the same kernel or another one, setting the MAC address to 00:00:00:00:BD:D1
Reset by complete power off (at the wall or the back of the PC case).

Incidentally, I installed the mainline kernel 2.6.34-rc5 and it handles the MAC address correctly again. I've had plenty of opportunity to test this with all the live CD/install testing of the last 48 hours or so.

Irihapeti - try linux_2.6.32-22.33.lp562742.2 at the same PPA. This kernel contains what is essentially the r8169.c from 2.6.34-rc5. If it still doesn't work reliably, then there must be something external to the driver causing your problems.

@TIm
The package is labelled "building" and isn't available. I'll get it as soon as I can.
Should I also be using the updated firmware from your ppa, or not?

Unless I've misunderstood this bug report, for example if it only applies to very specific hardware, I'm not affected by this. My hardware is
  04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02),
which uses the r8169 driver. I have upgraded to Lucid, and my MAC address has stayed the same (in particular, it's non-zero for several of the first four pairs) after many reboots. I'm using kernel 2.6.32-21-generic.

@Tim
The new kernel has failed to build, according to Launchpad. I'll check back later and install it when it's ready.

Kernel 2.6.34-rc6 contains some additional fixes similar to those referenced above.

From the changelog:

commit 908ba2bfd22253f26fa910cd855e4ccffb1467d0
Author: françois romieu
Date: Mon Apr 26 11:42:58 2010 +0000

    r8169: more broken register writes workaround

    78f1cd02457252e1ffbc6caa44a17424a45286b8 ("fix broken register writes")
    does not work for Al Viro's r8169 (XID 18000000).

    Signed-off-by: Francois Romieu
    Signed-off-by: David S. Miller

I can say that this hardware *is* affected (this is from a Jetway J7F4K1G2E-PB motherboard with integrated Realtek NICs):

00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)

Confirming same behavior on Jetway J7F4K1G5S-LF motherboard with integrated Realtek NICs:

00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)

I just upgraded from Hardy. The first few reboots were fine, then udev renamed my interfaces because for some reason the MAC addresses were changed:

HWaddr 00:00:00:00:29:85
HWaddr 00:00:00:00:29:86

As suggested in the Debian bug report (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573007), I am doing this as a workaround:

In /etc/udev/rules.d/70-persistent-net.rules, map the broken MAC addresses to eth0 and eth1.

So far this works between reboots, although when I tested the previous Lucid alpha, it would rename my interfaces constantly between reboots. Fortunately, this is my network router so I don't reboot that often.

@Tim:
I've installed the kernel linux-image-2.6.32-22-generic_2.6.32-22.33.lp562742.3_i386 and rebooted several times.

So far, it's behaving fine, but I'd like to test it for a couple of days before making a definite statement.

PS: That is without using the firmware from the PPA; just the standard Ubuntu version.

Irihapeti - Thanks for your feedback. The r8169 driver does not use firmware, so no worries there.

After further testing, I finally encountered an error: the ethernet chip not being activated at all (slow blink on ethernet switch, no connection).

However, to my surprise, I was able to fix it by issuing the commands:

sudo rmmod r8169
sudo modprobe r8169

No turning off at the wall, or even rebooting needed. (The first command may not have been necessary.)

It's kept the correct MAC address throughout.

I wonder if this is connected with booting between other distros. I've had it happen occasionally in the past when I was playing with Puppy linux and running Hardy as my main OS.

Still seeing this in 2.6.32-22:

mtvoelke@hostname:~$ uname -a
Linux smokies 2.6.32-22-generic #33-Ubuntu SMP Wed Apr 28 13:27:30 UTC 2010 i686 GNU/Linux
mtvoelke@hostname:~$ ifconfig | grep HWaddr
eth3 Link encap:Ethernet HWaddr 00:00:00:00:bc:49
mtvoelke@hostname:~$
mtvoelke@hostname:~$ lspci | grep thernet
00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)
mtvoelke@hostname:~$

I have seen no incorrect ethernet addresses during the past week, and I've been rebooting regularly between various linux versions.

As far as I am concerned, the problem is solved.

Submitted patch: https://lists.ubuntu.com/archives/kernel-team/2010-May/010510.html

The patches Tim has submitted to the kernel-team mailing list are already included in the actively developed Maverick kernel. As a result, I'm marking the current linux task as Fix Released. The Lucid task for SRU still remains open and under consideration. Thanks.

Same here. I'm running Ubuntu Lucid, 32 bit with 2.6.32-20
Replaced my NIC with a TP-Link Gigabit card based on a r8169 chip.

The card was sometimes not recognized by the kernel driver. I compiled the driver from the realtek site and got the card to work at 100baseTx-FD

I set up the DHCP server for a fixed address but this fails. Random adresses are assigned because apparently the drivers fails to send the correct MAC.

Also, I'm unable to get the card to 1000baseT-HD or 1000baseT-FD which are supported. An ethtool eth0 shows the mode as available. I've tried all the usual stuff like ethtool -s eth0 autoneg off speed..... etc.etc.etc
Did depmod -a and made a new initrd, etc.etc.

I also tried to manipulate the card with mii-tool but got the same result. I'm unable to switch the card in ANY mode. Not even to 10base-T, no autoneg or another duplexing mode.

The Switch is from the same brand and works fine with other 1000baseT equipment like my laptop and NAS. I've tried Cat5e and Cat6 cables but no results either.

My conclusion is that the driver is locked somehow to 100baseTx-FD

On the internet I read about people getting their r8169 devices to work with r1000 or r8168 drivers but I didn't get good results.

I was using Tim Gardner's patched kernel successfully. Of course, there's been a kernel update recently (two of them, actually) and therefore Tim's kernel has been replaced with a standard Ubuntu version - with the error in it.

For the moment, I've gone back to using a mainline kernel: 2.6.35-020635rc1-generic, which doesn't have this error.

However, if the fix isn't going to be released for lucid any time soon, how would be go about compiling either a whole kernel (gulp!) or just the r8169 driver so that we can get the functionality in the standard Ubuntu kernel?

@Irihapeti # 24

That's exacly what I did. The kernel r8169 driver seldomly worked *at all* so I compiled the driver from source. I had to donwload the latest sources from realtek because the source code included with the card didn't compile on lucid.

I got the card to work, but only at speed 100.

I should have just bought the more expensive Intel card.. stupid...stupid...

Can y'all try the pre-proposed kernel 2.6.32-23.37~pre201006081000 at http://ppa.launchpad.net/kernel-ppa/pre-proposed/ubuntu ? It has the stable updates required to fix this bug.

This bugfix is part of the upstream stable update for Lucid to 2.6.32.13 (see Bug #583414).

@Tim Gardner:
The pre-proposed kernel is working correctly.

@Tim. I could download the package after adding "deb http://ppa.launchpad.net/kernel-ppa/pre-proposed/ubuntu lucid main" to my /etc/apt/sources.list but don't know what to do next. I'm a virgin when it comes to compiling a kernel :)

So I can't tell if the fix works or not.

avdheiden - run 'sudo apt-get update; sudo apt-get -u dist-upgrade'. That should install the latest kernel from either the archive or the kernel-pre-proposed PPA.

Accepted linux into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

@Tim & Martin

Added the kernel from pre-proposed, no results. I added proposed and downloaded the latest kernel, no results. In both cases, I got a card in ifconfig -a but not in network-manager. The r8169 driver appeared in lsmod | grep r81 but no connection at all.

Thanks for your help so far and I hope you have more suggestions. If you need more info about my system, please ask. My card is a TP-Link TG-3269 (realtek r8169 based).

avdheiden - I'm thinking you likely have a different bug then Irihapeti since the pre-proposed kernel did solve his problem, and he was the original reporter. I suggest you file a new bug with your relevant information using 'ubuntu-bug linux', though you'll have to do it using a different ethernet interface.

After today's kernel upgrade (2.6.32-23-generic #37) the bug appears to
be fixed. No more weird MAC addresses after reboots! :-)

Many thanks to all the people who worked to fix this bug!

:-)

Frank

@Tim Gardner

Thought I'd better set the record straight - I'm not a "he".

No need to apologise. You weren't to know.

@Tim

I've posted bug 596825, as suggested, to find a solution for my ongoing problem. Thanks for your help and suggestions.

Update after my message wrote on 2010-06-15

> the ethernet MAC address is incorrectly read.
> The first four pairs of characters are rendered as zeros.

I confirm that this part of the bug seems to be fixed. I never had weird MAC addresses anymore! That's fine!

However...

> Occasionally, the ethernet adapter doesn't register at all and the
> light on the ethernet switch blinks slowly on and off, about once per second.

This still happens occasionally. Rarely, but it happens. The only solution is a "cold restart" of the machine.

@MadFranky:

I've found that I can deal with the ethernet not registering (lights blinking) error by issuing the two following commands:

sudo rmmod r8169
sudo modprobe r8169

This bug was fixed in the package linux - 2.6.32-23.37

---------------
linux (2.6.32-23.37) lucid-proposed; urgency=low

  [ Alex Deucher ]

  * SAUCE: drm/radeon/kms/atom: fix dual-link DVI on DCE3.2/4.0
    - LP: #564559

  [ Andy Whitcroft ]

  * [Config] ports -- build in dm-mod to enable LVM boot
    - LP: #560717
  * tools -- fix perf version extraction for multi-part flavours
    - LP: #555130
  * SAUCE: ACPI: EC: Allow multibyte access to EC (v3)
    - LP: #526354
  * [Config] enforce -- ensure dm_mod is built-in for LVM
    - LP: #560717
  * update to ubuntu-debian:7e708d33054c373faf41da23b73e8b48c342d958
    - LP: #570500, #576274

  [ Chase Douglas ]

  * Revert "(pre-stable): input: ALPS - Add signature for HP Pavilion dm3
    laptops"
    - LP: #550625
  * Enable ftrace function profiler
    - LP: #570389
  * enforce CONFIG_TMPFS_POSIX_ACL=y
    - LP: #575940

  [ Leann Ogasawara ]

  * Revert "staging/comdi -- disable"
    - LP: #563436
  * [Config] Enable multicast routing for sparc
    - LP: #416266
  * [Config] Add ahci.ko to virtual sub-flavour
    - LP: #570542

  [ Stefan Bader ]

  * Revert "SAUCE: drm/i915: Disable FBC on 915GM and 945GM"
    - LP: #588832

  [ Tim Gardner ]

  * ubuntu: rtl8192se -- update to version 0015.0127.2010
    - LP: #567016
  * [Config] Add atl1c to nic-modules udeb
    - LP: #557130

  [ Upstream Kernel Changes ]

  * Revert "(pre-stable) iwlwifi: fix nfreed--"
    - LP: #575853
  * Revert "backlight: mbp_nvidia_bl - add five more MacBook variants"
    - LP: #575853
  * Revert "(pre-stable) pata_via: Add VIA VX900 support"
    - LP: #575853
  * Revert "(pre-stable) x86-32, resume: do a global tlb flush in S4
    resume"
    - LP: #575853
  * Revert "x86: disable IOMMUs on kernel crash"
    - LP: #575853
  * Revert "sunrpc: fix peername failed on closed listener"
    - LP: #575853
  * Revert "sunrpc: move the close processing after do recvfrom method"
    - LP: #575853
  * Revert "(pre-stable) drm/edid: allow certain bogus edids to hit a fixup
    path rather than fail"
    - LP: #575853
  * Revert "drm/radeon/kms: don't print error on -ERESTARTSYS."
    - LP: #575853
  * Revert "ath9k: fix lockdep warning when unloading module" on stable
    kernels
    - LP: #588832
  * Staging: comedi: removed "depricated" from COMEDI_CB_BLOCK
    - LP: #483343
  * fat: fix buffer overflow in vfat_create_shortname()
    - LP: #575853
  * xfs: simplify inode teardown
    - LP: #575853
  * xfs: fix mmap_sem/iolock inversion in xfs_free_eofblocks
    - LP: #575853
  * xfs: I/O completion handlers must use NOFS allocations
    - LP: #575853
  * xfs: Wrapped journal record corruption on read at recovery
    - LP: #575853
  * xfs: Fix error return for fallocate() on XFS
    - LP: #575853
  * xfs: check for not fully initialized inodes in xfs_ireclaim
    - LP: #575853
  * xfs: fix timestamp handling in xfs_setattr
    - LP: #575853
  * xfs: Don't flush stale inodes
    - LP: #575853
  * xfs: Ensure we force all busy extents in range to disk
    - LP: #575853
  * xfs: reclaim inodes under a write lock
    - LP: #575853
  * xfs: Avoid inodes in reclaim when flushing from inode cache
    - LP: #575853
  * xfs: recla...

Today I had another "blinking lights" error.

On Fri, 2010-06-25 at 21:38 +0000, Irihapeti wrote:

> I've found that I can deal with the ethernet not registering (lights
> blinking) error by issuing the two following commands:
>
> sudo rmmod r8169
> sudo modprobe r8169

That has helped, indeed! Thanks for your help! :-)

Frank

I have the same behaviour since upgrade to Lucid, and this bug is not fixed for me with current kernel 2.6.32-24-generic. Still getting broken MAC address after reboot.

# lspci -v

00:00.0 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
 Subsystem: VIA Technologies, Inc. K8T800Pro Host Bridge
 Flags: bus master, 66MHz, medium devsel, latency 8
 Memory at <ignored> (32-bit, prefetchable)
 Capabilities: [80] AGP version 3.0
 Capabilities: [50] Power Management version 2
 Capabilities: [60] HyperTransport: Slave or Primary Interface
 Capabilities: [58] HyperTransport: Interrupt Discovery and Configuration
 Kernel driver in use: agpgart-amd64

00:00.1 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
 Flags: bus master, medium devsel, latency 0

00:00.2 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
 Flags: bus master, medium devsel, latency 0

00:00.3 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
 Flags: bus master, medium devsel, latency 0

00:00.4 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
 Flags: bus master, medium devsel, latency 0

00:00.7 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
 Flags: bus master, medium devsel, latency 0

00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South]
 Flags: bus master, 66MHz, medium devsel, latency 0
 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
 I/O behind bridge: 0000d000-0000dfff
 Memory behind bridge: f0000000-f00fffff
 Prefetchable memory behind bridge: e0000000-efffffff
 Capabilities: [80] Power Management version 2
 Kernel modules: shpchp

00:0a.0 Multimedia controller: Philips Semiconductors SAA7131/SAA7133/SAA7135 Video Broadcast Decoder (rev d1)
 Subsystem: Hauppauge computer works Inc. Device 6701
 Flags: bus master, medium devsel, latency 32, IRQ 18
 Memory at f0122000 (32-bit, non-prefetchable) [size=2K]
 Capabilities: [40] Power Management version 2
 Kernel driver in use: saa7134
 Kernel modules: saa7134

00:0b.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07)
 Subsystem: Creative Labs Device 8061
 Flags: bus master, medium devsel, latency 32, IRQ 19
 I/O ports at e000 [size=32]
 Capabilities: [dc] Power Management version 1
 Kernel driver in use: EMU10K1_Audigy
 Kernel modules: snd-emu10k1

00:0b.1 Input device controller: Creative Labs SB Live! Game Port (rev 07)
 Subsystem: Creative Labs Device 0020
 Flags: bus master, medium devsel, latency 32
 I/O ports at e100 [size=8]
 Capabilities: [dc] Power Management version 1
 Kernel driver in use: Emu10k1_gameport
 Kernel modules: emu10k1-gp

00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)
 Subsystem: Micro-Star International Co., Ltd. Device 094c
 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16
 I/O ports at e200 [size=256]
 Memory at f0120000 (32-bit, non-prefetchable) [size=256]
 [virtual] Expansion ROM at 60000000 [disabled] [size=128K]
 Capabilities: [dc] Power Management version 2
 Kernel driver in use: r8169
 Kernel modules: r8169

00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) (prog-if 8f [Master Se...

Looks like a regression in 2.6.32-24-generic. Doing a few reboots with packaged kernel 2.6.32-23-generic MAC address seems to stay intact on my machine, too.

I accepted the update to the 2.6.32-24-generic kernel with some trepidation, in the light of the last two messages. However, I've rebooted several times and the correct MAC address has loaded each time. My hardware is a little different from Sven's, though.

04:07.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet [10ec:8167] (rev 10)
 Subsystem: ASUSTeK Computer Inc. Device [1043:820d]
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 64 (8000ns min, 16000ns max), Cache Line Size: 32 bytes
 Interrupt: pin A routed to IRQ 20
 Region 0: I/O ports at a800 [size=256]
 Region 1: Memory at dfdff000 (32-bit, non-prefetchable) [size=256]
 [virtual] Expansion ROM at 5c200000 [disabled] [size=128K]
 Capabilities: [dc] Power Management version 2
  Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
  Status: D0 PME-Enable- DSel=0 DScale=0 PME-
 Kernel driver in use: r8169
 Kernel modules: r8169

Broken again. Regression from 2.6.32-23 to 2.6.32-24. Needs fixing...

Updated to 2.6.32-24-generic-pae: r8169 MAC addresses issue fixed, but DHCP server stopped distributing IP addresses

lsof -i show:
dhcpd3 2504 dhcpd 5u IPv4 6485 0t0 UDP *:bootps

but dhcpd3 is not responding to any request from the clients...

Rebooting to 2.6.32.23-generic-pae everything works fine again...

On Sun, 2010-07-25 at 02:50 +0000, Kristian Erik Hermansen wrote:

> Broken again. Regression from 2.6.32-23 to 2.6.32-24. Needs fixing...

I can not confirm! I never had any weird MAC addresses anymore!

> Occasionally, the ethernet adapter doesn't register at all

On the other hand, I still occasionally have the annoying "adapter not
registering" problem.

MAC adresses are still wrong in 2.6.32-24 (confirmed on 6 identical machines.)
Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)

A possibly relevant piece of information on this issue:-

I installed Windows Vista to a spare drive in order to test some stuff. Among the zillions of Windows updates was one for the ethernet driver. I discovered that the updated Windows driver was causing similar problems - changing the MAC address so that I had to turn the computer off completely before restarting, if I wanted the original address back. Reverting to the earlier driver solved the problem.

If any of you folk having problems are running Windows, it could be something to be aware of.

In case it's not quite clear, I'm talking about a dual-boot configuration in the message above.

Is this bug still under investigation? MAC addresses on kernel 2.6.32-24-generic are wrong, even after cleaning /etc/udev/rules.d/70-persistent-net.rules

On Mon, 2010-09-06 at 09:59 +0000, Alvin wrote:

> Is this bug still under investigation? MAC addresses on kernel
> 2.6.32-24-generic are wrong,

I never again had any weird MAC address.

However...

> Occasionally, the ethernet adapter doesn't register at all and the
> light on the ethernet switch blinks slowly on and off, about once per
second.

This still happens occasionally. The only solution is a "cold restart"
of the machine. And that's quite annoying. :-(

@ MadFranky

Try the commands:

sudo rmmod r8169 && sudo modprobe r8169

Works for me, and is a lot less inconvenient than a cold restart.

Hi Irihapeti

On Sun, 2010-09-12 at 16:06 +0000, Irihapeti wrote:

> Try the commands:
>
> sudo rmmod r8169 && sudo modprobe r8169

Thanks for the suggestion. I tried the commands, but...

> Works for me, and is a lot less inconvenient than a cold restart.

...sometimes it works; unfortunately, mostly there is no effect. The
LEDs on the switch continues to blink and the only way is to completely
power-off and then to restart.

Thanks anyway! :-)

Frank

my eth0 ethernet r8169 with MAC, e.g., ab:cd:ef:gh:ij:kl, normal before 9.10, but abnormal when installed 10.04.
There was a new eth1 item, eth1, in /etc/udev/rules.d/70-persistent-net.rules with MAC, 00:00:00:00:ij:kl.
It became normal after updating about one month later.
But It became 00:00:00:00:ij:kl once again after updating today.

I believe this same bug is affecting Ubuntu 11.04, kernel 2.6.38-8-generic -- my r8169 interface is now eth1, and it has been assigned MAC address 00:E0:12:34:56:78

This is quite an odd bug, I must say.