iPXE discussion forum

Full Version: UEFI iscsi boot windows 7 slowly
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Please forgive my poor english first.Sad

Test environment:

Server: windows server 2012 with iscsi target(wintarget) + tftp32 + latest ipxe.efi / snponly.efi + gpt system image (128GB, three partitons: ESP, MSR, and win7 OS volume)
Client : 1000M PCI-E NIC with UEFI network boot enabled ,local harddisk has removed.

After ClientPC boot into ipxe shell , I type
dhcp --> set keep-san 1 -> sanboot iscsi: , then the clientPC begin load OS image, but very very slowly, it takes about 3 - 5 minutes before the windows boot animation logo appeared.

and at this time, I found the wintarget service in server side has crashed, once I restart the wintarget servive manually, it crashed soon(because ipxe will reconnect to target and retry the previous failed scsi cmd) , after crash -> restart for 10 - 20 times , the clientPC can successfully boot into windows desktop.

I tried snponly.efi , and tried another PC with diffrent NIC, the result always same. So I guess this is not a network or NIC driver problem, it maybe the ipxe send a wrong scsi command to iscsi target, and caused the target crash.

at last, I fetched the latest IPXE source ,and compiled with DEBUG=iscsi,scsi,efi_block:2, enable syslog, then I replace ipxe.efi in server side, and reboot the clientPC.

syslog I got after clientPC reboot:


<6>ipxe: EFIBLK 0x80 read LBA 0x00032800 to 0xbf5000+0x00002000
<6>ipxe: EFIBLK 0x80 read LBA 0x00072800 to 0xc04000+0x00004000
<6>ipxe: EFIBLK 0x80 read LBA 0x00672800 to 0xbf5000+0x00000400
<6>ipxe: EFIBLK 0x80 read LBA 0x0067280a to 0xbf5000+0x00000400
<6>ipxe: EFIBLK 0x80 read LBA 0x00072960 to 0xc08000+0x00004000
<6>ipxe: EFIBLK 0x80 read LBA 0x0067ab08 to 0xbf5000+0x00000400
<6>ipxe: EFIBLK 0x80 read LBA 0x0101c830 to 0xbf5000+0x00002000
<6>ipxe: EFIBLK 0x80 read LBA 0x004a5988 to 0x24c5000+0x014c2600
<6>ipxe: iSCSI 0xe9a3008 closed: Connection reset (http://ipxe.org/0f0a6095)
<6>ipxe: SCSI 0xe9a36e8 tag 18ae01e6 closed: Connection reset (http://ipxe.org/0f0a6095)
<6>ipxe: iSCSI 0xe99fb08 initiator iqn.2010-04.org.ipxe:2dfe4d56-efb6-00a3-efcf-7a4242c83c9f
<6>ipxe: iSCSI 0xe99fb08 target iqn.2019.com.test:gpt
<6>ipxe: iSCSI 0xe99fb08 entering security negotiation
<6>ipxe: SCSI 0xe9a12e8 created for LUN 0000-0000-0000-0000
<6>ipxe: iSCSI 0xe99fb08 closed: Connection reset (http://ipxe.org/0f0a6095)
<6>ipxe: iSCSI 0xe99f908 initiator iqn.2010-04.org.ipxe:2dfe4d56-efb6-00a3-efcf-7a4242c83c9f
<6>ipxe: iSCSI 0xe99f908 target iqn.2019.com.test:gpt
<6>ipxe: iSCSI 0xe99f908 entering security negotiation
<6>ipxe: SCSI 0xe99fb28 created for LUN 0000-0000-0000-0000
<6>ipxe: iSCSI 0xe99f908 closed: Connection reset (http://ipxe.org/0f0a6095)

once the log line " <6>ipxe: EFIBLK 0x80 read LBA 0x004a5988 to 0x24c5000+0x014c2600 " appears , the wintarget crashed .
from the source , the 0x014c2600 in the log means efi block read io size, I don't understand why there is an efi block io with read size set to 0x014c2600 bytes (21M). (usually the request size in one efi read io is 0x200 - 0x100000. (512B - 64K))

I simply add some code in the function efi_block_io_read (efi_block.c) :

if (len > 0x1000000)

then the client can successfully boot with no errors in 30 - 40 seconds, and the target has not crash.
But this is not a good solution, I think we need to figure out the reason of why the len arg passed to efi_block_io_read is so large.

The GPT disk image in the target and the physical disk of the server are all ok, I checked with HDTUNE ,no errors or warnnings.

And I test in legacy bios with a MBR disk image, The boot slow problem and large size read request won't occurrs, only uefi.

I readed the UEFI spec , it doesn't mentioned the max request size limits of block_io_read.

maybe the bug is in efi block io protocol? or in wintarget? I'm not sure. (I haven't worked with uefi before today)

Any one can help? Thanks very much.
This seems to be same or related to http://lists.ipxe.org/pipermail/ipxe-dev...06639.html
(2019-04-13 06:05)NiKiZe Wrote: [ -> ]This seems to be same or related to http://lists.ipxe.org/pipermail/ipxe-dev...06639.html

Yes, that's me.
I post here first,and a few hours later, I think it's better to post to devel-list. If conflict, please delete this post. I apologize for posting repeatedly.
Reference URL's