My point in the previous email was that intel_fetch_mac_eeprom is called
before is_valid_ether_addr. If there is a MAC in the EEPROM, the if
statement surounding intel_fetch_mac_eeprom retruns 0 from the
intel_fetch_mac function.
This means that if there's a MAC in eeprom, the is_valid_ether_addr
function is never reached, and so the autoloaded MAC is never checked
for validity.
So any checks I add to is_valid_ether_addr() will never be reached.
/Kieran
On 27/07/2012 11:16, Anton D. Kachalov wrote:
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]>
<mailto:[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] <mailto:[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
_______________________________________________
ipxe-devel mailing list
[email protected]
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
