grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: UEFI/PXE and emulating grub-legacy-uefi-hacked behaviour


From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: RFC: UEFI/PXE and emulating grub-legacy-uefi-hacked behaviour
Date: Wed, 25 Apr 2012 22:39:30 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120329 Icedove/10.0.3

On 25.04.2012 22:21, Bean wrote:
> On Thu, Apr 26, 2012 at 1:57 AM, Seth Goldberg <address@hidden> wrote:
>>  Just to chime in here with some data -- I've found numerous UEFI systems' 
>> network functionality to be buggy (what a shock, right).  Specifically, 
>> using the TFTP APIs allow files to be retrieved, but using GRUB 2's TFTP 
>> stack, those same files fail to download, with the failure lying somewhere 
>> within the network driver.  In other words, there is close coupling between 
>> the network driver and the TFTP implementation in some vendors' UEFI 
>> implementations such that when you try to just use SNP, you end up with 
>> random timeouts that kill performance or dropped packets.  So, supporting 
>> use of UEFI's TFTP APIs seems like a good thing to do to deal with those 
>> types of systems.
> Hi,
>
> Actually I believe the problem is not in snp, but in timeout handling
> mechanism. I once implemented a tftp service using udp, and found its
> performance very bad compared to the native driver. After some
> debugging, I found out that it set an event which is signaled by snp
> while udp set the timeout to 0 so that it always returned whether or
> not there is available packet. When I use similar technique, my own
> tftp run as fast as the native service.
It's very good that you found the real reason for this brain damage. I'm
happy that someone did. Do you have this in code/as patch?
>


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]