[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