iPXE on DELL 7010 in UEFI mode

[SebastianRoth]

Hello iPXE community,

over the last weeks I've tried to get a DELL OptiPlex 7010 (Intel 82579LM NIC / PCI-ID 8086:1502) to PXE boot iPXE in UEFI mode. Helping a friend with this so I don't have a machine here to test myself. But we went through several cycles with different debugging options. This is confirmed by another friend on a 7010 as well.

'DEBUG=device,pci,snp,snponly,snpnet,netdevice'

Code:

iPXE initialising devices...Adding 3c509 root bus
Adding EFI root bus
MII PciRoot(0x0)/Pci(0x19,0x0)/MAC(90b11c9bc14f,0x0) is an MII device
MII PciRoot(0x0)/Pci(0x19,0x0)/MAC(90b11c9bc14f,0x0) is an MII device
SNP PciRoot(0x0)/Pci(0x19,0x0)/MAC(90b11c9bc14f,0x0)/IPv4(0.0.0.0) is an SNP device
SNP PciRoot(0x0)/Pci(0x19,0x0)/MAC(90b11c9bc14f,0x0)/IPv4(0.0.0.0) is an SNP device
NETDEV net0 registered (phys SNP-0xd07eb518 hwaddr 90:b1:1c:9b:c1:4f)
NETDEV net0 could not add SNP device: Error 0x7f45e082 (http://ipxe.org/7f45e082)
SNP PciRoot(0x0)/Pci(0x19,0x0)/MAC(90b11c9bc14f,0x0)/IPv6(0000:0000...) is an SNP device
SNP PciRoot(0x0)/Pci(0x19,0x0)/MAC(90b11c9bc14f,0x0)/IPv6(0000:0000...) is an SNP device
NETDEV rejecting duplicate (phys SNP-0xd07e9d98) of net0 (phys SNP-0xd07eb518)
...

Those 'rejecting duplicate' messages keep repeating for a while. The first phys address is changing every time.

As the error code was pointing me to efi_utils we also tried 'DEBUG=efi_utils' and ended up with this:

Code:

iPXE initialising devices...EFIDEV UNKNOWN(0xd07e9d98) cannot open device path: Error 0x7f45e082 (http://ipxe.org/err/7f45e082)
EFIDEV UNKNOWN(0xd07e9d98) is not a PCI device: Error 0x7f45e082 (http://ipxe.org/err/7f45e082)
EFIDEV UNKNOWN(0xd07e9d98) could not get underlying device information
EFIDEV PciRoot(0x0)/Pci(0x19,0x0)/MAC(90b11c9bc14f,0x0)/IPv4(0.0.0.0)/MAC(90b11c9bc14f,0x1) could not add child PciRoot(0x0)/Pci(0x19,0x0)/MAC(90b11c9bc14f,0x0)/...
EFIDEV UNKNOWN(0xd07e8d18) cannot open device path: Error 0x7f45e082 (http://ipxe.org/err/7f45e082)
EFIDEV UNKNOWN(0xd07e8d18) is not a PCI device: Error 0x7f45e082 (http://ipxe.org/err/7f45e082)
EFIDEV UNKNOWN(0xd07e8d18) could not get underlying device information
...

Again those messages keep repeating for some time with different addresses.

Any hint on what to try next are highly appreciated! Thanks a lot in advance.

[SebastianRoth]

Trying ipxe.efi on a different machine (Fujitsu ESPRIMO P910 E85+) with Intel 82579LM NIC (same PCI-ID 8086:1502) it works great!

'DEBUG=device,pci,netdevice'

Code:

iPXE initialising devices...Adding 3c509 root bus
Adding EFI root bus
PCI 00:19.0 (8086:1502) has driver "82579lm"
PCI 00:19.0 has mem f7100000 io f040 irq 11
PCI latency timer is unreasonably low at 0. Setting to 32.
NETDEV net0 registered (phys PCI00:19.0 hwaddr 00:19...)
NETDEV net0 link is up
Adding EISA root bus
Adding ...
...
Adding PCI root bus
ok

[SebastianRoth]

Anyone having a Intel 82579LM NIC has tried UEFI booting iPXE on it?

[mcb30]

(2015-11-23 19:44)SebastianRoth Wrote:  over the last weeks I've tried to get a DELL OptiPlex 7010 (Intel 82579LM NIC / PCI-ID 8086:1502) to PXE boot iPXE in UEFI mode. Helping a friend with this so I don't have a machine here to test myself. But we went through several cycles with different debugging options. This is confirmed by another friend on a 7010 as well.

'DEBUG=device,pci,snp,snponly,snpnet,netdevice'

Which iPXE binary are you using? The error messages you quoted seem to be relevant to snponly.efi. You later mention that it worked on another machine (with the same NIC) using ipxe.efi. Have you tried ipxe.efi on the problematic machine?

Also, which git commit of iPXE are you using?

Michael

[SebastianRoth]

(2016-02-04 14:19)mcb30 Wrote:  Which iPXE binary are you using? The error messages you quoted seem to be relevant to snponly.efi. You later mention that it worked on another machine (with the same NIC) using ipxe.efi. Have you tried ipxe.efi on the problematic machine?

Also, which git commit of iPXE are you using?

Has been a while so I don't remember all the details anymore. But from what we discussed in the FOG forums here (valuable information on the most current pages 1-3) I am pretty sure that we always used ipxe.efi - actually I think it was the same binary which works on Fujitsu ESPRIMO P910 E85+ but causes the issue on DELL OptiPlex 7010 both having the "same" NIC.

As well interesting is that using intel.efi didn't work on the OptiPlex either. Compiled with DEBUG=intel,netdevice,device,pci it hanged on "iPXE initialising devices...Adding EFI root bus". That's it, nothing more.

We used current git version from that date - which was around the 19th of November 2015. Sorry but I cannot say for sure which commit this was. Maybe 309c58824fc75a931cf3c25268abdb35870ce8f0 but I cannot tell for sure.

Sorry about the ragged and missing information. There were too many other things happening and we just didn't get to follow a clean path to test this. But I know almost for sure that we tested the same ipxe.efi binary on both machines (same NIC, UEFI enabled). So I am wondering if anyone else has tried ipxe UEFI boot with Intel 82579LM NICs?

[SebastianRoth]

I got hooked up to this issue again as it is still a problem with most current iPXE in UEFI mode on the Dell 7010's and people start to move over from legacy BIOS to UEFI on those machines.

So we are trying to dig deeper into this and found that it fails on disconnecting drivers just before it would usually connect the iPXE driver. This is what we see on the 7010 machines (DEBUG=init,efi_utils,efi_pci,efi_driver:3)


On a different model/machine (not even a Dell! just to see how it should look like) I see the this output:

Code:

...
EFIPCI ... has driver "14e4-1686"
EFIDRV ... has driver "PCI"
EFIDRV ... disconnecting existing drivers
EFIDRV ... connecting new drivers
EFIPCI ... has driver "14e4-1686"
EFIDRV ... has driver "PCI"
EFIDRV ... DRIVER_START
EFIPCI ... has driver "14e4-1686"
EFIPCI ... using driver "14e4-1686"
EFIDRV ... using driver "PCI"
...

So from what I understand reading the code on the Dell 7010 it fails on:

Code:

if ( ( efirc = bs->DisconnectController ( device, NULL,
                                          NULL ) ) != 0 ) {
        rc = -EEFI ( efirc );
        DBGC ( device, "EFIDRV %s could not disconnect existing "
               "drivers: %s\n", efi_handle_name ( device ),
               strerror ( rc ) );
        /* Ignore the error and attempt to connect our drivers */
}

And it doesn't even reach to where it would print the "EFIDRV ... after disconnecting:" message nor it gets to "bs->ConnectController" just a few lines down the road.

Does anyone have an idea why it would fail here and how to further debug this? Comparing the HANDLE output with to that of another machine it didn't ring a bell for me straight away. Looks ok to me. Can't see any obvious issue here.

[NiKiZe]

There are a few recent commits that reminds me of something similar
https://git.ipxe.org/ipxe.git/commit/d46...6703e3d178
https://git.ipxe.org/ipxe.git/commit/74d...11d93b6a39

The actual message "refusing to start during disconnection" that you see was introduced in the 74d90 commit

Here the issue was that the firmware didn't allow for the device to be disconnected, so it just hung.
During troubleshooting I tried to document at least some of the steps: http://ipxe.org/appnote/efidriverdisconnect
This would confirm if it is a pure firmware issue or not.

The reason it works on some machines but not others is most certainly due to different implementations of the EFI firmware. With that said it might be some way to work around it, but no good solution yet, as can be seen in the above 2 commits.