Bug 458806

Summary:	xen setup persistently modifies MAC address of tulip NIC
Product:	Red Hat Enterprise Linux 5	Reporter:	Noa Resare <noa>
Component:	kernel-xen	Assignee:	Xen Maintainance List <xen-maint>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:	Martin Jenner <mjenner>
Severity:	low	Docs Contact:
Priority:	low
Version:	5.2	CC:	agospoda, berrange, clalance, drjones, ivecera, pbonzini
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-12-14 10:32:08 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:	514490

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):
kernel-xen-2.6.18-92.1.10.el5
xen-3.0.3-64.el5_2.1

How reproducible:
Always

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

Ivan,
    It looks like the issue here is similar to the one you've recently fixed in BZ 441626.  Could you take a quick look?

Thanks,
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?

Ivan

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

Noa,

Is still still an issue?

Thanks,
Andrew

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.