Kieran,
First, driver read autoload MAC from INTEL_RAL/INTEL_RAH.
Then driver fetch MAC from EEPROM. After driver tries to validate autoloaded MAC. If it fits, it copies to "hw_addr" otherwise EEPROM MAC will be used. Usually, EEPROM of embedded NICs programmed by the motherboard vendor, because MAC address space is a vendor specific.
Try to add two additional checks before "is_valid_ether_addr()" to see which check fails:
is_multicast_ether_addr(mac.raw) must return 0
is_zero_ether_addr(mac.raw) must return 0
27.07.2012, 14:06, "Kieran Evans" <[email protected]>:
Hi, unless I'm mis-reading this, or I've misunderstood, this code looks like it will always use the EEPROM MAC if it exists (i.e. the return 0 after intel_fetch_mac_eeprom is before the is_valid_ether_addr, so it'll never be reached).
static int intel_fetch_mac ( struct intel_nic *intel, uint8_t *hw_addr ) {union intel_receive_address mac;int rc;/* Read current address from RAL0/RAH0 */mac.reg.low = cpu_to_le32 ( readl ( intel->regs + INTEL_RAL0 ) );mac.reg.high = cpu_to_le32 ( readl ( intel->regs + INTEL _RAH0 ) );DBGC ( intel, "INTEL %p has autoloaded MAC address %s\n",intel, eth_ntoa ( mac.raw ) );/* Try to read address from EEPROM */if ( ( rc = intel_fetch_mac_eeprom ( intel, hw_addr ) ) == 0 )return 0;/* Use current address if valid */if ( is_valid_ether_addr ( mac.raw ) ) {memcpy ( hw_addr, mac.raw, ETH_ALEN );< /div> return 0;}DBGC ( intel, "INTEL %p has no MAC address to use\n", intel );return -ENOENT;}
It seems like this is the correct way to do things, as if a user has burned a custom MAC into the EEPROM, then that's the one to use. I assume (though I can't find any info to back this up) that intel burns the default MAC into the eeprom too, and that's why there's MAC addresses in the EEPROM even though I never changed them. Could this issue be down to PCI device enumeration? I.e. the two ports are being enumerated in a different order by iPXE than elsewhere, so even though the auto-assigned mac is correct, when it checks the EEPROM, it's seeing a different value because it thinks port 0 is port 1 and port 1 is 0?
/Kieran
Also, oops, forgot to reply to the list, last time, so list email added back in.
On 27/07/2012 10:40, Anton D. Kachalov wrote:EEPROM macs used only when autoloaded is not complain by "is_valid_ether_addr" routine (lines 226-230). Try to add more debug messages here to track why driver going to use EEPROM's MAC instead of autloaded. 27.07.2012, 13:14, "Kieran Evans" <[email protected]>:Hmm, it seems that the autoloaded and EEPROM MACs are at odds (I'm the only person to have touched these servers since they were purchased, and no modification of the EEPROM has been made, no setting of alternate MAC addresses etc). http://dbyz.co.uk/ipxe1.png http://dbyz.co.uk/ipxe2.png After seeing that, I can think of two possible temporary workarounds, but not sure about perminent fixes. Workaround A: Set the MACs in EEPROM the other way around. (May then confuse linux, so needs checking) Workaround B: Compile iPXE with Mac loading from the EEPROM disabled (Comment out line 223+224 of src/drivers/net/intel.c ?) Any ideas on a more perminent workaround/fix? I'm fairly lucky as I only have 4 servers with this NIC/Problem, so modifying the eeprom is only half an hour of my time, but this could be a much bigger issue elsewhere._______________________________________________
ipxe-devel mailing list
[email protected]
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
--
Anton D. Kachalov
ITO, R&D group, Senior System Engineer
Tel: +7 (495) 739-70-00 ext.7613
Anton D. Kachalov
ITO, R&D group, Senior System Engineer
Tel: +7 (495) 739-70-00 ext.7613
_______________________________________________ ipxe-devel mailing list [email protected] https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
