[ipxe-devel] Fwd: UEFI iscsi boot windows 7 slowly

Fri Apr 12 21:18:07 UTC 2019

Hi all,

Recently I got an issue on iscsi boot windows 7  with uefi :

*ipxe takes  a long time before  windows  animation  boot logo appears.*

*The detail: *

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)
Client : VMWARE 1000M NIC(E1000) with UEFI network boot enabled ,local hard
disk removed.

After ClientPC boot into ipxe shell , I type
dhcp --> set keep-san 1 -> sanboot --no-describe
iscsi:10.10.10.253::::iqn.2019.com.test:gpt
, then the clientPC begin load OS image, but very slow, it takes about 3 -
5 minutes before the windows animation boot logo appears.

and at this time, I found the wintarget service in server side crashed,
once I restart the wintarget service 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 VM with diffrent NIC(vmxnet3), 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 10.10.10.253 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 10.10.10.253 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 io read  size,
I don't understand why there is an io with read size set to 0x014c2600
bytes (21M). (usually the request size in one efi block 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){return EFI_BAD_BUFFER_SIZE;}*

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
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 vmware efi block io protocol? or in wintarget? I'm not
sure. (I haven't worked with uefi before today) .

I'm going to test these on physical machine and try other linux based iscsi
target next work day, but before it, is there any one can give some
suggestions? really thanks!

(I know the --no-descrbe option will cause windows can't find IBFT, and
finally got 0x0000007B BSOD, so I had install my own iscsi-likely boot
initiator driver into windows, it can works with out IBFT. so the issue I
faced is not about IBFT)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20190413/89a140f6/attachment.htm>