[syslinux] UEFI: Failed to load ldlinux.e64/ldlinux.e32

Patrick Masotta masottaus at yahoo.com
Sun Oct 25 05:40:27 PDT 2015


>>>
On Sun, Oct 25, 2015 at 6:31 AM, Geert Stappers via Syslinux
<syslinux at zytor.com> wrote:
> On Mon, Oct 12, 2015 at 08:44:18PM -0400, Gene Cumm via Syslinux wrote:
>> On Sun, Oct 11, 2015 at 3:15 PM, Michael Glasgow <glasgow at beer.net> wrote:
>>
>> > I'm not sure what the decaying i/o issue looks like.  It's a bit
>> > slow loading the initrd, but I think the efi drivers are just slow
>> > in general.  Just in case, I went ahead and did a capture on the
>> > g18 patch loading OL 7.1, which you can grab from here:
>> >
>> > http://www.beer.net/m/etc/sl604p0g18.pcap.gz
>>
>> Just like that although this one maintains a reasonable IO rate.
>> Wireshark, Statistics, IO Graph, "udp.dstport == 1719", bits/tick.
>> Look at both 1 second per tick and 5 pixels per tick and then 0.1
>> seconds per tick and 1 pixel per tick.
>
> In a different thread there was a posting[1] where
> updating the TFTP _server_  did help.
>
> Is in this thread also a newer TFTP-server being tried?
>
>
> Groeten
> Geert Stappers
> [1] http://www.syslinux.org/archives/2015-October/024468.html

In my system, I'm also using tftp-hpa though it's possible switching
may help Michael.  I've been trying to dig into this issue and it
appears it's mostly in the gnu-efi callbacks or the UEFI firmware
gnu-efi calls (if I trust my tests and the custom timer I just made).


-- 
-Gene
<<<
Obviously there are timing issues involved; different TFTP servers probably means different TFTP 
default timeout values (remember the RFC 1350 does not say a single word on them) and that 
can make the difference between the TFTP self recovery schema working or failing on a particular transfer.I agree with Gene; I'm also thinking of a firmware/callback interaction leading to this issue;if this is the case the goal would be not to solve the problem but just to avoid it.My proposal was getting rid of the EFI Service Binding protocols and go back to the "ultra-tested" 
PXEbc even when we know the side effect this approach might have (no concurrent transfers).

Best,Patrick



  


More information about the Syslinux mailing list