[gPXE] wrong mac with rtl8139 nic on qemu-kvm
James
kojeroo at telus.net
Mon Dec 21 06:01:14 EST 2009
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
>>>>>> gPXE at etherboot.org
>>>>>> http://etherboot.org/mailman/listinfo/gpxe
>>>
>>>
>
More information about the gPXE
mailing list