[syslinux] Syslinux EFI + TFTPBOOT Support

Sun Mar 9 17:48:49 PDT 2014

On 2014/3/10 上午 05:48, Gene Cumm wrote:
> 1) My assumption would be that the VMware virtualized AMD 79C970A
> (PCNet32 driver; vlance virtualDev) lacks proper EFI64 support.
>
> 2) I have 0 speed issues using your VMX.  If you only have two real
> cores for this 2vCPU VM, you're choking it as the host needs time to
> run.  If you choke it, you mess with timers.  If you mess with timers,
> interface polling and a HUGE slew of items (including a guest OS's
> clock) will be slowed to a crawl.
>
> In my experience (both on ESXi and VMware Workstation), gGeneral
> sizing guidelines are that the first core on the first socket and
> 1-2GiB RAM should be considered dedicated to the host and arbitrary
> VMs should not have a vCPU count greater than the number of cores of
> an available socket and the vRAM should not exceed the RAM directly
> available to the NUMA node of the socket.  2 Intel Xeon x54xx
> constitute 1 NUMA node so you can have (1) 4vCPU VM with most of the
> RAM of the entire server.  2 Intel Xeon x55xx constitute 2 NUMA nodes
> so you can up to the vCPU count of the number of available cores in a
> socket and up to the available RAM directly controlled by that socket.
>   If we had 2 Intel Xeon E5530 with (6) 8GiB DIMMs, the best we could
> do for a single VM on this otherwise idle host is 4vCPUs and 22-24 GiB
> RAM.
>
> -- -Gene
Hi Gene,
Thanks for your explanation. Today I did two more tests here. All were 
done with Syslinux 6.03-pre6.
First one is for the real machine (Lenovo X230, Intel CPU core i5, NIC 
is Intel Corporation 82579LM Gigabit Network Connection (rev 04).
The 2nd one is for VMWare WS 10 with 1 core client. The host machine 
uses Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz with hyper-thread on, so 8 
cores shown in /proc/cpuinfo.
I describe the results in the following:
(1) For the Lenovo X230, I have the issue to EFI network booting. The 
client machine stopped at:
=================
Getting cached packet
My IP is 192.168.1.1
=================
The system log on the server shows:
=================
Mar 10 08:09:32 drbldbn dhcpd: Client 3c:97:e:9b:75:46 requests 
1:2:3:4:5:6:c:d:f:11:12:16:17:1c:28:29:2a:2b:32:33:36:3a:3b:3c:42:43:61:80:81:82:83:84:85:86:87 
- PXEClient:Arch:00007:UNDI:003016 - no dhcp-client-id
Mar 10 08:09:32 drbldbn dhcpd: DHCPREQUEST for 192.168.1.1 
(192.168.1.182) from 3c:97:0e:9b:75:46 via eth1
Mar 10 08:09:32 drbldbn dhcpd: DHCPACK on 192.168.1.1 to 
3c:97:0e:9b:75:46 via eth1
Mar 10 08:09:32 drbldbn atftpd[4821]: Serving bootx64.efi to 
192.168.1.1:1549
Mar 10 08:09:32 drbldbn atftpd[4821]: Serving bootx64.efi to 
192.168.1.1:1550
Mar 10 08:12:02 drbldbn dhcpd: DHCPREQUEST for 192.168.1.1 from 
3c:97:0e:9b:75:46 via eth1
Mar 10 08:12:02 drbldbn dhcpd: DHCPACK on 192.168.1.1 to 
3c:97:0e:9b:75:46 via eth1
=================
As you can tell, the client did not request ldlinux.e64.

(2) For the VM with one core,
The system log on the server shows:
=================
Mar 10 08:13:10 drbldbn dhcpd: Client 0:c:29:68:f3:23 requests 
1:2:3:4:5:6:c:d:f:11:12:16:17:1c:28:29:2a:2b:32:33:36:3a:3b:3c:42:43:61:80:81:82:83:84:85:86:87 
- PXEClient:Arch:00007:UNDI:003016 - no dhcp-client-id
Mar 10 08:13:10 drbldbn dhcpd: DHCPREQUEST for 192.168.120.3 
(192.168.120.254) from 00:0c:29:68:f3:23 via vmnet1
Mar 10 08:13:10 drbldbn dhcpd: DHCPACK on 192.168.120.3 to 
00:0c:29:68:f3:23 via vmnet1
Mar 10 08:13:10 drbldbn atftpd[4821]: Serving bootx64.efi to 
192.168.120.3:1540
Mar 10 08:13:10 drbldbn atftpd[4821]: Serving bootx64.efi to 
192.168.120.3:1541
Mar 10 08:13:10 drbldbn atftpd[4821]: Serving ldlinux.e64 to 
192.168.120.3:1542
Mar 10 08:13:10 drbldbn atftpd[4821]: Serving 
pxelinux.cfg/564d880a-57b6-3c13-26d5-a2af8968f323 to 192.168.120.3:1543
Mar 10 08:13:10 drbldbn atftpd[4821]: Serving 
pxelinux.cfg/01-00-0c-29-68-f3-23to 192.168.120.3:1544
Mar 10 08:13:10 drbldbn atftpd[4821]: Serving vesamenu.c32 to 
192.168.120.3:1545
Mar 10 08:13:10 drbldbn atftpd[4821]: Serving efi64/vesamenu.c32 to 
192.168.120.3:1546
Mar 10 08:13:11 drbldbn atftpd[4821]: Serving libcom32.c32 to 
192.168.120.3:1547
Mar 10 08:13:11 drbldbn atftpd[4821]: Serving efi64/libcom32.c32 to 
192.168.120.3:1548
Mar 10 08:13:11 drbldbn atftpd[4821]: Serving libutil.c32 to 
192.168.120.3:1549
Mar 10 08:13:11 drbldbn atftpd[4821]: Serving efi64/libutil.c32 to 
192.168.120.3:1550
Mar 10 08:13:11 drbldbn atftpd[4821]: Serving 
pxelinux.cfg/01-00-0c-29-68-f3-23 to 192.168.120.3:1551
Mar 10 08:13:11 drbldbn atftpd[4821]: Serving drblwp.png to 
192.168.120.3:1552
Mar 10 08:13:14 drbldbn atftpd[4821]: Serving vmlinuz-pxe to 
192.168.120.3:1553
Mar 10 08:13:17 drbldbn atftpd[4821]: Serving initrd-pxe.img to 
192.168.120.3:1554
Mar 10 08:14:25 drbldbn dhcpd: Client 0:c:29:68:f3:23 requests 
1:3:6:c:f:1c:2a - DRBLClient - no dhcp-client-id
=================
As you can see, with one core this time it took longer to download 
initrd-pxe.img.

For the Lenovo client, any test I could do?
Thanks in advance.

Steven.

-- 
Steven Shiau <steven _at_ nchc org tw> <steven _at_ stevenshiau org>
National Center for High-performance Computing, Taiwan.
http://www.nchc.org.tw
Public Key Server PGP Key ID: 4096R/47CF935C
Fingerprint: 0240 1FEB 695D 7112 62F0  8796 11C1 12DA 47CF 935C