Thanks Marty, I've generated a rom from your link but it hasn't helped
gPXE 0.9.9+ -- Open Source Boot Firmware -- http://etherboot.org Features: FTP HTTP HTTPS DNS TFTP bzImage COMBOOT ELF Multiboot NBI PXE PXEXT net0: 00:00:d8:ab:e2:7e on PCI00:03.0 (open) [Link:up, TX:0 TXE:0 RX:0 RXE:0] DHCP (net0 00:00:d8:ab:e2:7e).............. Besides the features listed above I also selected CONSOLE_SERIAL COMPRESERVE I've gone ahead and also generated a rom without serial console options and have also seen it fail. I'm gonna have to sign off for today and get on with my Sunday. I'll follow-up with any other emails late tonight or Monday. Thanks, James On 20-Dec-09 11:47 Marty Connor wrote: > Hi James, > > I have patched my testing rom-o-matic.net instance with the patch I > suggested earlier. You can build with the patch from here: > > http://etherboot.org/share/mdc/gpxe.git/contrib/rom-o-matic/ > > Thanks for your testing! > > Marty > > James wrote on 12/20/09 2:27 PM: >> Since I've been getting my roms from rom-o-matic it might >> take me a while to get around to trying to build my own. >> I'll look into doing this on Monday. >> >> Thanks, >> James >> >> >> On 20-Dec-09 11:09 Marty Connor wrote: >>> Hi James, >>> >>> I think this is a timing issue. >>> >>> Can you please find this line (around line 313): >>> >>> mdelay ( 10 ); >>> >>> and change it to: >>> >>> mdelay ( 100 ); >>> >>> If that fixes the problem I may suggest another patch that actually >>> tests that reset has completed rather than simply waiting the required >>> 10ms for the reset to complete. >>> >>> Please let us know know if this helps. >>> >>> Regards, >>> >>> Marty >>> >>> James wrote on 12/20/09 1:42 PM: >>>> Hello Shao, >>>> >>>> gPXE is loaded as an option rom in qemu-kvm. My qemu-kvm version is >>>> 0.9.1 >>>> from RHEL 5.4.9. >>>> >>>> >>>> For first pass it means first DHCP discover after initial start or >>>> after >>>> a qemu system_reset in the monitor. It does appear to be random but >>>> it is >>>> happening more often than not. Here's a capture from the console. >>>> >>>> gPXE 0.9.9 -- Open Source Boot Firmware --http://etherboot.org >>>> Features: FTP HTTP HTTPS DNS TFTP bzImage COMBOOT ELF Multiboot NBI >>>> PXE PXEXT >>>> >>>> net0: 00:00:d8:ab:e2:7e on PCI00:03.0 (open) >>>> [Link:up, TX:0 TXE:0 RX:0 RXE:0] >>>> DHCP (net0 00:00:d8:ab:e2:7e)................ Connection timed out >>>> (0x4c106035) >>>> No more network devices >>>> >>>> >>>> >>>> >>>> gPXE 0.9.9 -- Open Source Boot Firmware --http://etherboot.org >>>> Features: FTP HTTP HTTPS DNS TFTP bzImage COMBOOT ELF Multiboot NBI >>>> PXE PXEXT >>>> >>>> net0: 00:21:d8:ab:e2:7e on PCI00:03.0 (open) >>>> [Link:up, TX:0 TXE:0 RX:0 RXE:0] >>>> DHCP (net0 00:21:d8:ab:e2:7e).... ok >>>> net0: 2.43.241.156/255.255.255.240 gw 2.43.241.145 >>>> Booting from filename "pxelinux.0" >>>> tftp://2.43.241.155/pxelinux.0.. ok >>>> >>>> James >>>> >>>> >>>> >>>> On 19-Dec-09 14:29 Shao Miller wrote: >>>>> James wrote: >>>>>> hi... i have a problem with gPXE 0.9.9 for rtl8139 10ec:8139 and >>>>>> qemu-kvm >>>>>> >>>>>> The first pass of the boot the device mac is sometimes incorrect... >>>>>> I see 00:00:d8:ab:e2:7e instead of 00:21:d8:ab:e2:7e. >>>>>> The second octet is 00 instead of 21 in the mac. >>>>> >>>>> How is gPXE booting? A floppy disk for the VM? A ROM for the VM? >>>>> Chained from another boot-loader in the VM? When you say "first pass," >>>>> do you mean that rebooting resolves the issue or that you perform a >>>>> DHCP >>>>> twice and it's been corrected by the second time? Is it random? >>>>> >>>>> - Shao Miller >>>> _______________________________________________ >>>> gPXE mailing list >>>> [email protected] >>>> http://etherboot.org/mailman/listinfo/gpxe > > _______________________________________________ gPXE mailing list [email protected] http://etherboot.org/mailman/listinfo/gpxe
