Bug 458806 - xen setup persistently modifies MAC address of tulip NIC
Summary: xen setup persistently modifies MAC address of tulip NIC
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel-xen
Version: 5.2
Hardware: x86_64
OS: Linux
Target Milestone: rc
: ---
Assignee: Xen Maintainance List
QA Contact: Martin Jenner
Depends On:
Blocks: 514490
TreeView+ depends on / blocked
Reported: 2008-08-12 13:41 UTC by Noa Resare
Modified: 2010-12-14 10:32 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-12-14 10:32:08 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Noa Resare 2008-08-12 13:41:02 UTC
Description of problem:

(Please note that I am not a RHEL customer and my aim is not to piggyback on your support expertise but rather an attempt to help out making your product offering even better.)

I have a fairly standard x86_64 system with a PCIe network card identified by lspci as a "ADMtek NC100 Network Everywhere Fast Ethernet 10/100 (rev 11)" card (lspci -n shows id's 1317:0985)  that is using the 'tulip' network driver.

When booting a linux-xen kernel the xen boot scripts does it's magic and modifies the hardware mac address of the eth0 device (now renamed peth0) to FE:FF:FF:FF:FF:FF Nothing wrong with that, the bridging functionality with lots of funky devices makes the network work as expected.

Until I reboot the system, that is. It turns out that the new MAC address persists during reboots, and when I bring up the system again the xen scripts fail to produce network connectivity.

Also, when I reboot into a regular non-xen linux kernel it detects that the network card MAC has changed and switches the configuration from static ip to DHCP, which fails.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install and boot a xen kernel
2. Reboot into a regular non xen linux kernel
3. Check the MAC address of eth0 with ifconfig
Actual results:
eth0 now has the MAC FE:FF:FF:FF:FF:FF

Expected results:
eth0 should have MAC 00:0C:41:F1:32:7E

Additional info:
Dual booting into Windows Vista once resets the MAC address.

This means that a workaround for this problem is to boot into Vista when I need to reboot after having booted linux-xen.

Comment 1 Daniel Berrangé 2008-11-26 21:36:50 UTC
This is very bizarre - it smells like a kernel bug to me, so reassigning to kernel-xen.

Comment 2 Chris Lalancette 2008-11-26 21:45:22 UTC
Yeah, seems about right.  We have seen other instances of this.  Usually powering down the box and powering it back up again is enough to reset it; no need to boot into that *other* OS :).  That being said, it's a bug that the MAC is getting written all the way through to the firmware, so the tulip driver could do with some modification.

Chris Lalancette

Comment 3 Chris Lalancette 2008-11-26 21:48:19 UTC
    It looks like the issue here is similar to the one you've recently fixed in BZ 441626.  Could you take a quick look?

Chris Lalancette

Comment 4 Noa Resare 2008-11-27 07:26:48 UTC
I'd love to check out if there is a fix available in the referenced bug that solves this, however I don't seem to have the necessary permissions.

Comment 5 Chris Lalancette 2008-11-27 07:43:04 UTC
Oh, no, I'm pretty sure the patch in that bug won't help you; it's for the r8169 card.  However, it's a similar situation where the Xen bridge sets it to FF:FF:FF:FF:FF, and only a power down will reset the card.  That's why I asked Ivan to take a quick look.

Chris Lalancette

Comment 6 Ivan Vecera 2008-11-27 13:47:09 UTC
Yes, this is similar problem. For the most of NICs handled by tulip driver the MAC address is read from EEPROM on init. But your NIC is exception, it's AMDtek Comet and AFAIK (look into driver source) these NICs don't have EEPROM.
For Realtek NICs that have not EEPROM (e.g. integrated NICs) the system BIOS is responsible for initializing MAC address.
What kind of NIC do you have? classic add-on card or motherboard integrated?


Comment 7 Noa Resare 2008-11-27 14:29:40 UTC
eth0 is a discrete PCIe card that I have purchased separately from the rest of the system that identifies as stated above.

Comment 8 Noa Resare 2008-12-16 14:50:39 UTC
I have now verified that turning off the machine for several minutes will not reset the MAC.

Comment 11 Andrew Jones 2010-06-22 17:44:03 UTC

Is still still an issue?


Comment 14 Noa Resare 2010-12-11 21:00:00 UTC
Unfortunately I don't have this hardware available anymore, so I can't be of any help. Sorry.

Comment 15 Paolo Bonzini 2010-12-13 11:34:37 UTC
Ivan, should we close this then?

Comment 16 Ivan Vecera 2010-12-14 10:27:29 UTC
IMHO we should, without appropriate HW for testing it does not make sense.

Note You need to log in before you can comment on or make changes to this bug.