Bug 503988
| Summary: | r8169 driver destroys MAC address of eth1 on R670 workstation | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Flavio Leitner <fleitner> |
| Component: | kernel | Assignee: | Ivan Vecera <ivecera> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Red Hat Kernel QE team <kernel-qe> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 5.3 | CC: | agospoda, akarlsso, dzickus, john.rushe, ltroan, pasteur, tao, ykun |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-09-24 13:48:31 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 525215, 533192 | ||
|
Description
Flavio Leitner
2009-06-03 17:29:36 UTC
(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. |