Hi Marty, Here are some results.
i = 0 Reset succeeded. gPXE 0.9.9+ -- Open Source Boot Firmware -- http://etherboot.org Features: HTTP 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 i = 0 Reset succeeded. i = 0 Reset succeeded. i = 0 Reset succeeded. gPXE 0.9.9+ -- Open Source Boot Firmware -- http://etherboot.org Features: HTTP 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 Boot environment is qemu with kvm. The host is a Xeon E5335 with 4GB RAM. This CPU has four cores. Here's my qemu command line qemu -pidfile /var/run/vb1.pid -daemonize -boot n -m 512 -name "2.43.241.151:1" -cdrom W2K8R2.iso -fda virtio.dsk -usbdevice tablet -serial telnet:localhost:2001,server,nowait,nodelay -cpu qemu64 -no-hpet -rtc-td-hack -vnc :1 -net nic,vlan=0,macaddr=00:21:D8:AB:E2:7E,model=rtl8139 -net tap,vlan=0,ifname=vblade10,script=/tmp/vblade10,downscript=/tmp/qemu-ifdown -drive index=0,if=ide,file=vb1-disk0,cache=off James On 20-Dec-09 13:53 Marty Connor wrote: > Hi James, > > Please do enjoy the rest of your Sunday. I am watching some football > while doing a bit of light hacking :) > > I just instrumented rtl8139 a bit more. When you have a moment would > you try again with: > > http://etherboot.org/share/mdc/gpxe.git/contrib/rom-o-matic/ > > It should print out an indication of whether reset completed > successfully. This happens just before the NVS reading code executes. > > If it isn't a timing issue with reset, we may have to look at the NVS > code to look at each bit as it is read. > > This is a very curious issue since rtl8139 is so widely used, I would > have expected to have heard about this problem previously. > > Can you please describe your booting environment? Is this a regular PC > BIOS or Coreboot+SeaBIOS. Any details on your environment may help us > to reproduce and address this problem. > > Many thanks for your help with debugging this. > > Marty > > James wrote on 12/20/09 3:58 PM: >> 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
