search for: brightcomputing

...lename "efi64/syslinux.efi"; option pxelinux.pathprefix "http://myserverip/tftp/efi64/"; } elsif option architecture-type = 00:07 { # efi32 not supported. } else { filename "bios/pxelinux.0"; } Thanks! -- Oscar Roozen Linux Developer oscar.roozen at brightcomputing.com Bright Computing BV Kingsfordweg 151 1043 GR Amsterdam The Netherlands Tel: +31 20 491 9324 www.BrightComputing.com

Update: I added my debugging stuff (just a bunch of Print()s and dprintf()s) to the branch without the multinic fix to see if I could find a common cause somewhere. This is based on commit 8702009f. Where I expected the machine to crash again, it just exited back to the bootloader without crashing. So.. somehow adding this debug code solved the crashing problem? Or did it? Then I went back

...recompile with some debugging turned on, resolved the crashing issue. Unfortunately I can't test anymore until Friday. Maybe gnu-efi got updated? I seem to remember seeing a shell script pulling in the newest version during compilation... -- Oscar Roozen Linux Developer oscar.roozen at brightcomputing.com Bright Computing BV Kingsfordweg 151 1043 GR Amsterdam The Netherlands Tel: +31 20 491 9324 www.BrightComputing.com

On Sat, Sep 12, 2015 at 7:08 AM, Gene Cumm <gene.cumm at gmail.com> wrote: > On Sat, Sep 12, 2015 at 5:54 AM, Teun Docter > <teun.docter at brightcomputing.com> wrote: >> On 2015-09-12 04:58, Gene Cumm wrote: >>>> >>>> I've captured the following DHCP ACK: >>>> >>>> 10.141.20.1.bootps > 10.141.20.2.bootpc: [udp sum ok] BOOTP/DHCP, Reply, >>>> length 399, xid 0xf0eb955a, secs 1...

On 2015-09-12 04:58, Gene Cumm wrote: >> I've captured the following DHCP ACK: >> >> 10.141.20.1.bootps > 10.141.20.2.bootpc: [udp sum ok] BOOTP/DHCP, Reply, >> length 399, xid 0xf0eb955a, secs 14, Flags [none] (0x0000) >> Your-IP 10.141.20.2 >> Server-IP 10.141.255.254 >> Client-Ethernet-Address fa:16:3e:08:31:b9

>> 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

Hello, I am just installing XCP 0.1.1 on a server with 24GB RAM Normally XCP is a 64 bits version but * *uname -a* Linux node012 2.6.27.42-0.1.1.xs0.1.1.737.1065xen #1 SMP Fri Jan 15 16:20:16 EST 2010 i686 i686 i386 GNU/Linux (not a x86_64 version !!!!) * *cat /proc/meminfo* MemTotal: 746496 kB MemFree: 384332 kB Buffers:

On 05-08-15 12:05, Gene Cumm wrote: > > I recompiled with this in mk/devel.mk <http://devel.mk>: > > GCCWARN += -DDEBUG_PORT=0x2f8 -DCORE_DEBUG=1 > > 0x2f8 is a BIOSism. Is this a problem? The example in the comments said 0x3f8 which is COM1.

On Wed, Aug 5, 2015 at 8:06 AM, Oscar Roozen <oscar.roozen at brightcomputing.com> wrote: > On 05-08-15 12:05, Gene Cumm wrote: >> >> > I recompiled with this in mk/devel.mk <http://devel.mk>: >> > GCCWARN += -DDEBUG_PORT=0x2f8 -DCORE_DEBUG=1 >> >> 0x2f8 is a BIOSism. > Is this a problem? The example in the comments sai...

On Sat, Sep 12, 2015 at 5:54 AM, Teun Docter <teun.docter at brightcomputing.com> wrote: > On 2015-09-12 04:58, Gene Cumm wrote: >>> >>> I've captured the following DHCP ACK: >>> >>> 10.141.20.1.bootps > 10.141.20.2.bootpc: [udp sum ok] BOOTP/DHCP, Reply, >>> length 399, xid 0xf0eb955a, secs 14, Flags [none] (0x0000)...

On Sun, Sep 13, 2015 at 3:46 PM, Geert Stappers via Syslinux <syslinux at zytor.com> wrote: > On Sat, Sep 12, 2015 at 06:56:04PM -0400, Gene Cumm via Syslinux wrote: >> On Sat, Sep 12, 2015 at 6:37 PM, Gene Cumm wrote: >> > On Sat, Sep 12, 2015 at 10:23 AM, Geert Stappers wrote: >> >> diff --git a/core/fs/pxe/dhcp_option.c b/core/fs/pxe/dhcp_option.c >>

...Gene Cumm via Syslinux wrote: > On Sat, Sep 12, 2015 at 7:37 AM, Gene Cumm <gene.cumm at gmail.com> wrote: > > On Sat, Sep 12, 2015 at 7:08 AM, Gene Cumm <gene.cumm at gmail.com> wrote: > >> On Sat, Sep 12, 2015 at 5:54 AM, Teun Docter > >> <teun.docter at brightcomputing.com> wrote: > >>> On 2015-09-12 04:58, Gene Cumm wrote: > >>>>> > >>>>> I've captured the following DHCP ACK: > >>>>> > >>>>> 10.141.20.1.bootps > 10.141.20.2.bootpc: [udp sum ok] BOOTP/DHCP, Reply, > &...

On Sat, Sep 12, 2015 at 7:37 AM, Gene Cumm <gene.cumm at gmail.com> wrote: > On Sat, Sep 12, 2015 at 7:08 AM, Gene Cumm <gene.cumm at gmail.com> wrote: >> On Sat, Sep 12, 2015 at 5:54 AM, Teun Docter >> <teun.docter at brightcomputing.com> wrote: >>> On 2015-09-12 04:58, Gene Cumm wrote: >>>>> >>>>> I've captured the following DHCP ACK: >>>>> >>>>> 10.141.20.1.bootps > 10.141.20.2.bootpc: [udp sum ok] BOOTP/DHCP, Reply, >>>>> length 399...

...yslinux wrote: >> On Sat, Sep 12, 2015 at 7:37 AM, Gene Cumm <gene.cumm at gmail.com> wrote: >> > On Sat, Sep 12, 2015 at 7:08 AM, Gene Cumm <gene.cumm at gmail.com> wrote: >> >> On Sat, Sep 12, 2015 at 5:54 AM, Teun Docter >> >> <teun.docter at brightcomputing.com> wrote: >> >>> On 2015-09-12 04:58, Gene Cumm wrote: >> >>>>> >> >>>>> I've captured the following DHCP ACK: >> >>>>> >> >>>>> 10.141.20.1.bootps > 10.141.20.2.bootpc: [udp sum ok] BOOTP...

> 5) upload handles.txt somewhere It's waiting at http://okkie.nu/tmp/handles.txt

>> OK your HP has 4 NICs >> >> DevicePath(0x0,0x0)/MAC(ECB1D775E524,0x0) >> DevicePath(0x0,0x1)/MAC(ECB1D775E525,0x0)) >> DevicePath(0x0,0x2)/MAC(ECB1D775E526,0x0)) >> DevicePath(0x0,0x3)/MAC(ECB1D775E527,0x0)) According to HP it's actually one nic with four ports. I cannot disable them individually. > git://git.zytor.com/users/genec/syslinux.git >

On 04-08-15 15:42, Oscar Roozen wrote: > I'm adding debug statements as we speak... Okay, the code in efi/ uses Print() from gnu_efi, but generic code from core/ like core/elflink/load_env32.c prints their messages and debugging stuff using printf(). These messages end up nowhere. This may explain why I never saw anything beyond a certain point, even with debugging turned on. Any

On 05-08-15 02:27, Gene Cumm wrote: >> tried without Gene's latest patches crashing before even beginning to load >> the first stage: ldlinux.e64? > > It _probably_ had issues finding the NIC properly. Of course, and your latest patches solved this problem. But I should have been more clear. What happened was: 1 - HP ROM FW: Download syslinux.efi 2 - HP ROM FW: Run

[ merging a few sub-threads into one ] > Weird as it sounds I was able to send debug info to COM2 > (redirected to a pipe) on EFI64 VMware workstation clients. Ports 0x3f8 and 0x2f8 are so hardwired into my brain from back in the old BBS-days that I did not expect them NOT to work. Apparently some firmware engineers have this problem too. ;-) >>>> > If there is

On 07-08-15 05:56, Ady via Syslinux wrote: > If we are talking about UEFI x86_64, then the c32 files are all those > located under the "efi64" directory tree of the Syslinux build. Plus, > the relevant "ldlinux.*" core module. I wonder why ldlinux.c32 got renamed to ldlinux.e64 whereas all other modules remained their c32 extension. This confused me as a beginner.