[ipxe-devel] ipxe-devel Digest, Vol 107, Issue 7

Mon Apr 15 05:01:40 UTC 2019

Hi all,

I give up WinTarget and use FreeNAS as iscsi target , the ipxe can
succcessfully boot into windows with no errors, FreeNAS target no crash.

And I noticed the log below when ipxe login to  wintarget ( and FreeNAS):

<6>ipxe: iSCSI 0xe9a62c8 initiator
iqn.2010-04.org.ipxe:2dfe4d56-efb6-00a3-efcf-7a4242c83c9f
<6>ipxe: iSCSI 0xe9a62c8 target 10.10.10.252 iqn.2019.com.test:gpt
<6>ipxe: iSCSI 0xe9a62c8 entering security negotiation
<6>ipxe: SCSI 0xe9a71e8 created for LUN 0000-0000-0000-0000
<6>ipxe: iSCSI 0xe9a62c8 handling AuthMethod=None
<6>ipxe: iSCSI 0xe9a62c8 ignoring TargetAlias=gpt
<6>ipxe: iSCSI 0xe9a62c8 ignoring TargetPortalGroupTag=1
<6>ipxe: iSCSI 0xe9a62c8 entering operational negotiation
<6>ipxe: iSCSI 0xe9a62c8 ignoring HeaderDigest=None
<6>ipxe: iSCSI 0xe9a62c8 ignoring DataDigest=None
<6>ipxe: iSCSI 0xe9a62c8 ignoring MaxConnections=1
<6>ipxe: iSCSI 0xe9a62c8 ignoring InitialR2T=Yes
<6>ipxe: iSCSI 0xe9a62c8 ignoring ImmediateData=No
<6>ipxe: iSCSI 0xe9a62c8 ignoring MaxRecvDataSegmentLength=131072
*<6>ipxe: iSCSI 0xe9a62c8 ignoring MaxBurstLength=262144          <<==*
<6>ipxe: iSCSI 0xe9a62c8 ignoring FirstBurstLength=65536
<6>ipxe: iSCSI 0xe9a62c8 ignoring DefaultTime2Wait=0
<6>ipxe: iSCSI 0xe9a62c8 ignoring DefaultTime2Retain=0
<6>ipxe: iSCSI 0xe9a62c8 ignoring MaxOutstandingR2T=1
<6>ipxe: iSCSI 0xe9a62c8 ignoring DataPDUInOrder=Yes
<6>ipxe: iSCSI 0xe9a62c8 ignoring DataSequenceInOrder=Yes
<6>ipxe: iSCSI 0xe9a62c8 ignoring ErrorRecoveryLevel=0
<6>ipxe: iSCSI 0xe9a62c8 entering full feature phase

I searched on google,seems  the MaxBurstLength has a effect is limits the
max read size in one scsi cmd, the target say " I only accept read size max
to 262144 bytes in one scsi read cmd",  but IPXE ignoring this .

When a large size read IO occurs  (large than MaxBurstLength) , the ipxe
send large size read request to target , the FreeNAS can handle it
correctly, but wintarget can't and crashed. There must be a bug in
WinTarget.

But  if IPXE can make a  workaround  about this, it would be great. (Don't
ignoring MaxBurstLength and other params, and split large size IO to multi
small size IO)

I'm not familiar with IPXE and ISCSI, or I will be glad to do the
workaround.

And before the workaround done , maybe we should add a remarks to ipxe
documents page (be careful to use wintarget with uefi iscsi boot windows,
use linuxe-based target instead).

My english is not very well, if anything I wrote is hard to understand,
please let me know. Thanks all.

<ipxe-devel-request at lists.ipxe.org> 于2019年4月13日周六 下午7:00写道：

> Send ipxe-devel mailing list submissions to
>         ipxe-devel at lists.ipxe.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
> or, via email, send a message with subject or body 'help' to
>         ipxe-devel-request at lists.ipxe.org
>
> You can reach the person managing the list at
>         ipxe-devel-owner at lists.ipxe.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ipxe-devel digest..."
>
>
> Today's Topics:
>
>    1. Fwd: UEFI iscsi boot windows 7 slowly (junjie hua)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 13 Apr 2019 05:18:07 +0800
> From: junjie hua <halouworls at gmail.com>
> To: ipxe-devel at lists.ipxe.org
> Subject: [ipxe-devel] Fwd: UEFI iscsi boot windows 7 slowly
> Message-ID:
>         <
> CA+TA2aUG0b4HbOqTweccK0GfSqfYsCs1a7Ludz8JFWJddn0XOg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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-0001.html
> >
>
> ------------------------------
>
> _______________________________________________
> ipxe-devel mailing list
> ipxe-devel at lists.ipxe.org
> https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
>
>
> End of ipxe-devel Digest, Vol 107, Issue 7
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20190415/ee212857/attachment.htm>