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):
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
eth0 now has the MAC FE:FF:FF:FF:FF:FF
eth0 should have MAC 00:0C:41:F1:32:7E
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.
This is very bizarre - it smells like a kernel bug to me, so reassigning to kernel-xen.
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.
It looks like the issue here is similar to the one you've recently fixed in BZ 441626. Could you take a quick look?
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.
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.
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?
eth0 is a discrete PCIe card that I have purchased separately from the rest of the system that identifies as stated above.
I have now verified that turning off the machine for several minutes will not reset the MAC.
Is still still an issue?
Unfortunately I don't have this hardware available anymore, so I can't be of any help. Sorry.
Ivan, should we close this then?
IMHO we should, without appropriate HW for testing it does not make sense.