[gPXE] wrong mac with rtl8139 nic on qemu-kvm

[James]

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