[ipxe-devel] Dell C6220 lkrn MAC address issue / Intel I350

Matthew Drobnak mdrobnak at appnexus.com
Sun Feb 24 21:02:25 UTC 2013


Thanks for the quick response.

Indeed, a debug build sheds a lot of light on it -

Loading ipxe.lkrn...ready.
iPXE initialising devices...INTEL 0xbb6a0 MAC reset (ctrl 081c0261)
INTEL 0xbb6a0 has autoloaded MAC address 78:45:c4:f8:9c:e3
INTEL 0xbb6a0 has large-format EERD
INTEL 0xbb6a0 has EEPROM MAC address 78:45:c4:f8:9c:e4 (port 0)
INTEL 0xbb6a0 link status is 80280387
INTEL 0xbb870 MAC reset (ctrl 081c0261)
INTEL 0xbb870 has autoloaded MAC address 78:45:c4:f8:9c:e4
INTEL 0xbb870 has large-format EERD
INTEL 0xbb870 has EEPROM MAC address 78:45:c4:f8:9c:e7 (port 3)
INTEL 0xbb870 link status is 80280783
ok



iPXE 1.0.0+ (b757) -- Open Source Network Boot Firmware -- http://ipxe.org
Features: AoE VLAN HTTP iSCSI DNS TFTP SRP bzImage ELF MBOOT PXE PXEXT Menu
iPXE>



So now the question is how do we make it use the autoloaded MAC address, 
as they are correct? Or, why are the EEPROM ones incorrect?

-Matt


On 02/24/2013 04:03 AM, Robin Smidsrød wrote:
> On 24.02.2013 02:55, Matthew Drobnak wrote:
>> When chainloaded from pxelinux as the ipxe.lkrn module, the following
>> occurs:
>>
>> CLIENT MAC ADDR: 78 45 C4 F8 9C E3 GUID: 44454C4C 4C00 1034 8047
>> B8C04F5A5631
>> !PXE entry point found (we hope) at 97D2:0106 via plan A
>> UNDI code segment at 97D2 len 5210
>> UNDI data segment at 9197 len 63B0
>> BOOTIF=01-78-45-c4-f8-9c-e3
>> Loading ipxe.lkrn...ready.
>> iPXE initialising devices...ok
>> iPXE 1.0.0+ (71727) -- Open Source Network Boot Firmware -- http://ipxe.org
>> DHCP (net0 78:45:c4:f8:9c:e4).................. Connection timed out
>> (http://ipx
>> e.org/4c106035)
>> Could not configure net0: Connection timed out (http://ipxe.org/4c106035)
>> DHCP (net1 78:45:c4:f8:9c:e7)..........
>>
>> The MACs in this mode -
>>
>> iPXE 1.0.0+ (b757) -- Open Source Network Boot Firmware -- http://ipxe.org
>> iPXE> show net0/mac
>> net0/mac:hex = 78:45:c4:f8:9c:e4
>> iPXE> show net1/mac
>> net1/mac:hex = 78:45:c4:f8:9c:e7
>> iPXE> show net2/mac
>> Could not find "net2/mac": No such device (http://ipxe.org/2c0c203b)
>>
>> However, when loaded directly using undionly.kpxe:
>>
>> Intel(R) Boot Agent GE v1.3.72
>> CLIENT MAC ADDR: 78 45 C4 F8 9C E3 GUID: 44454C4C 4C00 1034 8047
>> B8C04F5A5631
>> PXE->EB: !PXE at 97D2:0070, entry point at 97D2:0106
>> UNDI code segment 97D2:5210, data segment 9197:63B0 (582-628kB)
>> UNDI device is PCI 02:00.0, type DIX+802.3
>> 582kB free base memory after PXE unload
>> iPXE initialising devices...ok
>> iPXE 1.0.0+ (b757) -- Open Source Network Boot Firmware -- http://ipxe.org
>> iPXE> show net0/mac
>> net0/mac:hex = 78:45:c4:f8:9c:e3
>>
>> Note that the correct MACs end in "e3" and "e4". So, something
>> strange is happening when using the "Linux kernel" version of iPXE. Only
>> seems to be happening on I350 based cards. We have two other Dell "Cloud
>> Series" servers, the C6100 and C2100 series, which have no issues at
>> all. Hopefully this helps find this bug. Please let me know if you need
>> any more information. Thanks. -Matt
> This might be a bug in how the firmware initializes the MAC and how it
> is calculated with multi-port NICs.
>
> I'm not a core developer, but I believe build with DEBUG=intel would
> help to shed some light on the issue.
>
> Build your image like this:
>
> make bin/ipxe.lkrn DEBUG=intel
>
> Send us similar output to what you did above. As undionly.kpxe seems to
> work, I see no need to look at that one anymore.
>
> -- Robin
>




More information about the ipxe-devel mailing list