[ipxe-devel] Hard Lock on Chain Load from undionly.kpxe -> ipxe.pxe

Matthew Helton mwhelton at gmail.com
Fri Aug 21 22:19:51 UTC 2015


More information: The lockup is with VMware v11 VMs in VMware Workstation
11. A Couple of physical hosts will simply spontaneously reboot at the
referenced point in process.



On Fri, Aug 21, 2015 at 2:23 PM, Matthew Helton <mwhelton at gmail.com> wrote:

> I have observed the following on commit 4e03a: When chainloading from
> undionly.ipxe to ipxe.pxe there is a hard lockup:
>
> Client system PXEs into undionly.kpxe normally...reaches out for the
> ${uuid}.ipxe file as normal:
>
> [Error code]
> http://mywebserver.mydomain.net/NetBoot/iPXE/bin/ipxe.pxe... ok
> PXE->EB: !PXE at 94D4:07A0, entry point at 94D4:033D
>                  UNDI Code segment 94D4:083C, data segment 955A:@e60
> (595-609kB)
>                  UNDI device is PCI 02:01.0, type DIX+802.3
>                  609 kB free bade memory after PXE unload
> _
> [Error code/]
>
> The actual scripted invocation from ${uuid}.ipxe is:
>
> [code]
> #!ipxe
> iseq ${chip} undionly && chain -ar ${17}/NetBoot/iPXE/bin/ipxe.pxe ||
> [/code]
>
> Can anyone else confirm?
>
> Best,
>
> Matt
>
>
> --
> There is never time enough to do it right, but there always seems to be
> enough time to do it again.
>



-- 
There is never time enough to do it right, but there always seems to be
enough time to do it again.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20150821/88b882a0/attachment.htm>


More information about the ipxe-devel mailing list