Description of problem: The new R670 workstation comes with 2 LAN chips on board, both Realtek and both use the r8169 driver. When using Xen kernel, MAC address on Realtek NIC is overwritten by FE:FF:FF:FF:FF:FF and is persistent over reboots, but the original will show up in the BIOS again after removing the power cord for a while. How reproducible: Always. Additional info: System architecture(s): arch=i386 release=5 flavour=server base=rhel-i386-server-5 kernel-xen-2.6.18-128.el5 (rhel-i386-server-5) Is a known bug in the Kernel Bugzilla. http://bugzilla.kernel.org/show_bug.cgi?id=9560 Does not show up on Fedora 10 with Kernel 2.6.27.21. So the problem seems to be fixed meanwhile in newer kernels. Desired behavior: No long term change of NIC MAC address. Kernel (r8169) Driver Bug https://bugzilla.redhat.com/show_bug.cgi?id=468135 Regression: kernels greater than 2..6.27.3-30 fail to initialise Realtek RTL 8101E Ethernet controller https://bugzilla.redhat.com/show_bug.cgi?id=468360 r8169 fails to read mac address in recent kernels https://bugzilla.redhat.com/show_bug.cgi?id=468251 Does a proposed patch exist? yes/no Partner has referenced a patch at the following URL: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6709fe9a27e43a4931938fe0d7f2cc5edef31386 but it was later reverted by this: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ea8dbdd17099a9a5864ebd4c87e01e657b19c7ab
(In reply to comment #0) > Description of problem: > The new R670 workstation comes with 2 LAN chips on board, both Realtek and both > use the r8169 driver. When using Xen kernel, MAC address on Realtek NIC is > overwritten by FE:FF:FF:FF:FF:FF and is persistent over reboots, but the > original will show up in the BIOS again after removing the power cord for a > while. This is very known issue, but the proposed fix is not upstream yet. The problem is that all r8169-based chipsets supports a change of MAC address, this address is restored when the system is restarted. But this is only valid for older chipsets (mainly PCI based), newer ones (mainly PCI-E based) needs full power off (power coord or battery removal) to restore hardwired MAC address. > Does not show up on Fedora 10 with Kernel 2.6.27.21. So the problem seems to be > fixed meanwhile in newer kernels. Any kernel version is affected (upstream also). > Does a proposed patch exist? yes/no > Partner has referenced a patch at the following URL: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6709fe9a27e43a4931938fe0d7f2cc5edef31386 > > but it was later reverted by this: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ea8dbdd17099a9a5864ebd4c87e01e657b19c7ab Yes, this is my fix to resolve this issue posted upstream. The solution is load original MAC address from EEPROM and set up appropriate registers. I tested it on several systems with Realtek chipsets without any problem, but several people reports some troubles (MAC address was not read correctly) -> I'm not able to reproduce their troubles and don't know where could be a problem. I consulted this fix directly with Realtek's engineers but they didn't see any problem also. Finally I sent a temporal fix that disables the r8169's ability to change MAC address, this should be included in RHEL 5.4 and should temporarily fix your issue.
Opening comment #4 as it contains key information for this public bug. Ivan, is there a workaround in 5.4? The referenced comment is not clear.
Yes, this temporal fix was introduced in 2.6.18-132 so the 5.4 contains it.
On Wed, 2009-07-29 at 11:40 +0200, Rainer Koenig wrote: > Hi Larry, > > Larry Troan schrieb: <edited> > > Have you tried the RHEL5.4 beta which is supposed to have a workaround > > according to the engineer. Does the workaround work? If so, an option > > here would be to specify 5.4 as the minimum supported level. > > I tried GA snapshot 3 this morning. Indeed the MAC addresses keep > untouched with this version.