similar to: [PATCH 2/5] ntfs: remove unused variable and have ntfssect use char API calls

Hi guys, I have re-implemented /efi/udp.c The new code fixes: 1) The low and decreasing throughput on TFTP transfers. 2) The added delay between consecutive TFTP transfers. 3) The TFTP errors induced by broadcast traffic like ARP. Initial tests on a 50MB transfer showed times going from 3 minutes to ~12 seconds, also tested OK with nested TFTP transfers (include command). This

I did change both instances of txdata->GatewayAddress, but I think something may be wrong in my toolchain. If I extract syslinux.zip and attempt to make from there (without modifying any files), the cached DHCP packet isn't read on the same subnet. I receive "Succeed to download NBP file." twice before anything from syslinux is loaded, so I believe the duplicate request for

Signed-off-by: Julien Viard de Galbert <jviarddegalbert at online.net> --- efi/udp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/efi/udp.c b/efi/udp.c index 1088f47..b0f13ad 100644 --- a/efi/udp.c +++ b/efi/udp.c @@ -163,7 +163,7 @@ void core_udp_connect(struct pxe_pvt_inode *socket, uint32_t ip, } else { udata.UseDefaultAddress = FALSE;

Here is a completely untested patch if someone wants to try and take it for a spin? -hpa -------------- next part -------------- diff --git a/efi/udp.c b/efi/udp.c index 59bb426..60a8fe9 100644 --- a/efi/udp.c +++ b/efi/udp.c @@ -41,8 +41,7 @@ int core_udp_open(struct pxe_pvt_inode *socket) udp = (EFI_UDP4 *)udp_reader->this; memset(&udata, 0, sizeof(udata)); -

The attached patch resolves a buffer reuse bug in the efi/tcp.c code. The bug can be triggered when multiple TCP connections are opened when using the EFI bootloader. Signed-off-by: Joshua Weage <joshua.weage at dell.com> --- --- master/core/fs/pxe/pxe.h 2017-07-22 14:45:46.561674329 -0500 +++ jw/core/fs/pxe/pxe.h 2017-07-23 19:44:46.466498950 -0500 @@ -144,6 +144,7 @@ struct

So last week I was wondering if XFS was still working -- even with its last on-disk structure changes -- and it _suprisingly_ worked as expected. Right, now I can finally get rid of GRUB and use Syslinux to boot my Linux on EFI from a rootfs with xfs. Shit, I have two partitions (the first one being the required ESP) so there is no way to access the other partitions since because Syslinux does not

On Sun, Feb 28, 2016 at 04:26:07PM +0000, Patrick Masotta via Syslinux wrote: > > > I have re-implemented /efi/udp.c > Signed-off-by: Patrick Masotta <masottaus at yahoo.com> > > diff -uprN a/core/fs/pxe/pxe.h b/core/fs/pxe/pxe.h > --- a/core/fs/pxe/pxe.h 2014-10-06 10:27:44.000000000 -0600 > +++ b/core/fs/pxe/pxe.h 2016-02-28 08:44:47.127996962 -0700 > @@

On Fri, Nov 8, 2013 at 5:08 PM, Jason Matthews <jason.david.matthews at gmail.com> wrote: > I attempted the patch, but had to add a declaration to get it to compile. I > also added the gateway like before. Here's a link to the modified diff I > used and the pcaps from tftpserver and mirrored port from boot to reset. > > http://ge.tt/136167y/v/0 > > I'm also not

From: Sylvain Gault <sylvain.gault at gmail.com> On some architecture, including my hardware, the function ExitBootServices may need to be called twice in order to successfully exit the boot services. As stated by the UEFI spec, the first call to ExitBootServices may perform a partial shutdown of the services. It seems that during this partial shutdown, the memory map can be modified, thus

Hi Alexander, thanks for your good work on the megatec_usb driver. I have made a few more (cosmetic) changes. Is the driver now working stably for your device? In particular, do the instant commands (and particularly "upsdrvctl -k") work properly? In this case, we could hopefully mark the device as "supported" and merge the driver to the main branch. There is still the

Sometimes the UEFI memory map changes between GetMemoryMap() and ExitBootServices(), making the MapKey value incorrect. Per the UEFI spec, the memory map should then be fetched again and exiting retried. Signed-off-by: Tom Huibregtse <thuibregtse at xes-inc.com> --- efi/main.c | 81 ++++++++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 70 insertions(+), 11 deletions(-)

On Sat, Nov 9, 2013 at 11:33 AM, Gene Cumm <gene.cumm at gmail.com> wrote: > On Sat, Nov 9, 2013 at 11:20 AM, Gene Cumm <gene.cumm at gmail.com> wrote: >> On Fri, Nov 8, 2013 at 5:08 PM, Jason Matthews >> <jason.david.matthews at gmail.com> wrote: >>> I attempted the patch, but had to add a declaration to get it to compile. I >>> also added the

On Tue, Aug 25, 2015 at 11:54 PM, celelibi--- via Syslinux <syslinux at zytor.com> wrote: > From: Sylvain Gault <sylvain.gault at gmail.com> > > Some firmware implementations may need ExitBootServices to be called > twice. The second time with an updated memory map key. > > Signed-off-by: Sylvain Gault <sylvain.gault at gmail.com> > --- > efi/main.c | 75

From: Matt Fleming <matt.fleming at intel.com> For x86_64 versions of gnu-efi >= 3.0s GNU_EFI_USE_MS_ABI is enabled which turns on the Microsoft ABI, allowing the compiler to do all the work of interfacing with the EFI firmware instead of jumping through uefi_call_wrapper(). Add support to turn this on in the gnu-efi headers, otherwise we'll encounter undefined references to

Hum... Some packets seems duplicated when captured from the server, but not when captured from the mirror port. So let's assume that's ok. I can't find anything in the capture of the non-modified version that would look suspicious. Anyway, syslinux.efi is supposed to be downloaded by the UEFI firmware itself. It succeed but keep restarting for no apparent reason. Maybe an early

This patch adds to the core EFI image booting capabilities. It was tested on VMware EFI clients and HP Elitebook EFI notebooks, only on PXE environments but it should work on non-PXE scenarios as well. Feedback appreciated. Best, Patrick Signed-off-by: Patrick Masotta <masottaus at yahoo.com> --- diff -uprN a/com32/elflink/ldlinux/execute.c b/com32/elflink/ldlinux/execute.c ---

The UEFI PXE boot DHCP/proxyDHCP issue is very timely. I am working on that very topic now. Our scenario is a manufacturing environment set up to format and load/install custom hard drive images in our systems. Our environment: This is a manufacturing floor setup where we build computers for our customers. We have two servers and a client in the mix, all connected via Ethernet (IPv4 only).

Without an assigned source port, Transmit function assign a random new source port to the packet being sent. It thus have to be set before calling Transmit if the source port have already been decided. Conversly, we have to save the assigned port to reuse it later if needed. Resolve bug #35. Signed-off-by: Celelibi <celelibi at gmail.com> --- efi/udp.c | 18 ++++++++++++++++++ 1 file

>>> Jeff, Patrick: Could you try my code from my github repo branch efi-multinic?? It's derived from Patrick's code and I finally see good responses with a VMware VM's e1000e NIC (never saw ANYTHING good from it until now). git://github.com/geneC/syslinux.git https://github.com/geneC/syslinux.git -- -Gene <<< Hi there I think in the case of a particular

>> Are there any known problems with the performance of TFTP in (U)EFI >> environments in general or maybe just on VMWare? > I don't believe so. I use Workstation 10.0.2 on Ubuntu 12.04 for the > moment. <stupid question> and have EFI enabled? </stupid> > I hope this is a hex-core host with 6+GiB of RAM. Fedora runs on an AMD A8-6600K at 3Ghz and has 8G of