UEFI 10G Intel X710/XL710 Hang Windows Splash Screen

[renato]

I am testing iPXE on a 10G intel X710/XL710 card. During boot, the messages indicate that ipxe.efi does not have drivers, and it falls to using NII. The ethernet interface is initialized and the the winPE wim image is downloaded successfully very slow though. When the process in handed over to windows, winpe gets stuck at the win logo and the keyboard freezes. The only way to get it out is by force shutdown, pressing the power button 10 sec.

I am using ipxe.efi from commit 0be77e959e813773cac10f049cb62c83258f81ff. I built it using DEBUG options efi_driver and efi_pci. I am also using the prebuilt binary of wimboot from commit 901fe9537b2ff99cba0d5ed72f496c6b160f1084.

I tried to add to intelx.c the pid vid of the card as PCI_ROM ( 0x8086, 0x1572, "x710", "X710 Test", 0 ), and after that ipxe fails to initialize the card.

I read some topics here:http://forum.ipxe.org/archive/index.php/thread-8116.html where it got fixed by using ipxe.efi and i remember another where it got fixed by using a newer version of wimboot (sorry did not find the link). but none of these helped now.

Will appreciate your help,

Renato

[NiKiZe]

There is no native support for X710 in ipxe yet,
it have however been recently requested http://lists.ipxe.org/pipermail/ipxe-dev...05173.html
One request for native support was the speed issue.

You could test snponly.efi to force it to use the firmware NII/SNP mode but that is essentially what ipxe.efi falls back to when no native drivers are found. So checking for offical firmware/ROM upgrade might be worth a try.

The winpe hang can have many causes, I would check that the same wim works on another machine, and also that it works on this machine without the X710 NIC. Most of the time I have had issues with boot hangs due to Mass storage device drivers, rather then nic drivers or hardware. (I'm assuming you are using wimboot)

---

For reference, a different thread about X7xxx: http://forum.ipxe.org/showthread.php?tid=11170

[renato]

(2016-10-26 20:09)NiKiZe Wrote:  There is no native support for X710 in ipxe yet,
it have however been recently requested http://lists.ipxe.org/pipermail/ipxe-dev...05173.html
One request for native support was the speed issue.

You could test snponly.efi to force it to use the firmware NII/SNP mode but that is essentially what ipxe.efi falls back to when no native drivers are found. So checking for offical firmware/ROM upgrade might be worth a try.

The winpe hang can have many causes, I would check that the same wim works on another machine, and also that it works on this machine without the X710 NIC. Most of the time I have had issues with boot hangs due to Mass storage device drivers, rather then nic drivers or hardware. (I'm assuming you are using wimboot)

I tested the same scenario (dhcp/tftp/ipxe/script/wimboot/wim image) in another system that has a Broadcomm NIC and it booted fine that was what it led me believe that is was related to the driver. However, it could also be a wimboot issue. I also, tested snponly.efi with the same results as ipxe.efi. I will try booting the same system using another NIC to discard a MB issue and post the results.

Is there anything I can do to test and help the iPXE community and make this a win/win?

thank you for your prompt response NiKiZe, "gracias amigo" .

Renato

[renato]

OK, tested the same system but with another 10G intel card X540I350, same system, same dhcp/ipxe configuration and it does NOT hang, it boots normally!!!!!.

O_o, What does it mean?

there is no support for .ISO booting under UEFI mode, right? wanted to see if this is a wimboot or iPXE/driver issue.
In case you are wondering I did test with another X710 card just to discard is not a bad NIC.

I will check if the BIOS/FIRMWARE of the MB and NIC card are the latest, in the meantime

any advice?

Renato

[NiKiZe]

(2016-10-26 23:44)renato Wrote:  OK, tested the same system but with another 10G intel card X540I350, same system, same dhcp/ipxe configuration and it does NOT hang, it boots normally!!!!!.

O_o, What does it mean?

Ok so XL710 related, could you boot the wim by putting it on usb driver, replacing the original boot.wim so that you can boot without involving ipxe at all. To me a hang in winpe booting is still a windows driver issue, not ipxe/wimboot related.

(2016-10-26 23:44)renato Wrote:  there is no support for .ISO booting under UEFI mode, right? wanted to see if this is a wimboot or iPXE/driver issue.

No sanboot support in efi mode yet.

If you could post some info just to be sure.

your ipxe script for booting.
output from imgstat before boot line in that script

and output of what you get when starting wimboot with pause.

So output from a script like this:

Code:

kernel wimboot gui pause
initrd.....
imgstat
pause
boot

EDIT: efi sanboot seems to have been implemented in: https://git.ipxe.org/ipxe.git/commitdiff...25c2c2f5ad different forum post about this: http://forum.ipxe.org/showthread.php?tid=6896

[renato]

(2016-10-27 07:34)NiKiZe Wrote:  Ok so XL710 related, could you boot the wim by putting it on usb driver, replacing the original boot.wim so that you can boot without involving ipxe at all. To me a hang in winpe booting is still a windows driver issue, not ipxe/wimboot related.

OK, Tested with a USB, all I did was to put the contents of the folder "winboot" (see below) in the USB. It booted without problem in UEFI Mode, I did not check it in BIOS mode but it boots fine using PXE/iPXE and BIOS.

(2016-10-27 07:34)NiKiZe Wrote:  If you could post some info just to be sure.

your ipxe script for booting.

there are two parts, the following is the embeded script

Code:

dhcp
chain http://${next-server}/pxefiles/lboot.php?MAC=${mac}&DID=${product}

and the following is the answer to the lboot.php script

Code:

#!ipxe
kernel wimboot
initrd winboot/bootmgr.exe                     bootmgr.exe
initrd winboot/boot/bcd                    bcd
initrd winboot/boot/boot.sdi               boot.sdi
initrd winboot/sources/boot.wim            boot.wim
boot

The bootmgr is replaced by wimboot automatically

(2016-10-27 07:34)NiKiZe Wrote:  output from imgstat before boot line in that script

and output of what you get when starting wimboot with pause.

So output from a script like this:

Code:

kernel wimboot gui pause
initrd.....
imgstat
pause
boot

Here is a picture of the output: https://drive.google.com/file/d/0B-ZdAQk...sp=sharing

[NiKiZe]

You probably want to remove the initrd bootmgr.exe line it should be extracted automatically from the wim if needed in legacy mode.

But with this we can be quite sure it is nic state and windows nic drivers that is the issue. You might want to open an issue with Intel about this. Just so that they can create working snp firmware and compatibility with their windows drivers.

[renato]

Hi, I did some more testing and i wanted to share my findings

I tested other 10G NIC cards all on a Dell server PowerEdge r630
Emulex OCm14104-U2-D 10DF 0720
Broadcom BCM95781 14E4 168E
Broadcom BCM95784 14E4 16A1

All of them presented the same issue so this take us away from a INTEL firmware issue
I also noticed that when the winPE image is PXE booted using the bootmgfw.efi directly taking ipxe/wimbbot away from the equation it boots fine. Then, I added ipxe.efi and then chain loaded bootmgfw.efi from there and it booted fine. Then, I started with ipxe but then switch to wimboot but instead of using http I used tftp and IT BOOTED FINE.

It is only the combination of ipxe/wimboot and transfer via http that fails to boot.

I used the tcp debug option and noticed that the connection is closed/shutdown randomly between 60 and 100% (it gets to tcp_wait_expired function) but continues downloading. Lastly it is weird that the md5sum of the downloaded files match the originals ie they are not getting corrupted.

I did ask Intel for support but they have not responded yet

hopefully you guys have a better insight now with my new findings

[NiKiZe]

Could you try a a packet dump on the interface and see if there is anything weird/re-transmissions going on.

One think I can think of is that when using the TCP stream (such as http) instead of UDP (in tftp) then it can't close the connection directly after completed transfer and something goes wrong.

What if you add pause as an option to wimboot.
or maybe using ifclose before boot does it make any difference?

[jrrowan]

I am having a very similar issue but my scenario fails about 80% of the time with one WinPE error or another. In my case a pause does not help.

Is there suggested workaround. Should I use TFTP or chain load bootx64.efi? If the later, could someone describe how to do it?

[jrrowan]

I noticed that I am getting this error message. The WIM is created from Windows ADK.

...found WIM file boot.wim
Can't handle unknown compression scheme 0x00020082 for <address> chunk 0...

[renato]

(2016-11-07 21:38)NiKiZe Wrote:  Could you try a a packet dump on the interface and see if there is anything weird/re-transmissions going on.

One think I can think of is that when using the TCP stream (such as http) instead of UDP (in tftp) then it can't close the connection directly after completed transfer and something goes wrong.

What if you add pause as an option to wimboot.
or maybe using ifclose before boot does it make any difference?

It booted with ifclose followed by dhcp. Thank you, Is this a iPXE bug? is there anything I can do to test/debug?

---

(2016-11-15 21:57)jrrowan Wrote:  I am having a very similar issue but my scenario fails about 80% of the time with one WinPE error or another. In my case a pause does not help.

Is there suggested workaround. Should I use TFTP or chain load bootx64.efi? If the later, could someone describe how to do it?

you could do it for testing or if you want to check if it is the same problem I am having. You could also try the solution directly just add ifclose, dhcp. That worked for me.

Code:

#!ipxe
kernel wimboot
initrd boot/bcd         BCD
initrd boot/boot.sdi    boot.sdi
initrd sources/boot.wim boot.wim
ifclose
dhcp
boot

here are some instructions to boot winpe over ipxe
http://ipxe.org/howto/winpe
http://ipxe.org/wimboot

just when chaining your menu
use for tftp

Code:

chain menu

use for http

Code:

chain http://boot.ipxe.org/menu

you can also set bootmgfw.efi as the dhcpd filename (for UEFI) to bypass ipxe. However, beware that there are some character remapping you would need to do in order for it to work if you are using linux (xinet), I did that a couple years ago, I don't know if that still holds true. You can use tftpd32 for testing. just google it, there is plenty of information.

in my case ifclose/dhcp worked.

---

(2016-11-16 22:32)jrrowan Wrote:  I noticed that I am getting this error message. The WIM is created from Windows ADK.

...found WIM file boot.wim
Can't handle unknown compression scheme 0x00020082 for <address> chunk 0...

please check http://forum.ipxe.org/showthread.php?tid=7987

[NiKiZe]

There is now iPXE native drivers available for the Intel X710 and friends: http://git.ipxe.org/ipxe.git/commitdiff/d2063b769