[ipxe-devel] IPXE and parallels on MAC

[Patel, Kalpesh, US]

Hey Michael, thanks for the reply. I've answered in-line below.



On 4/17/14 8:03 AM, "Michael Brown" <mcb30 at ipxe.org> wrote:

>On 08/04/14 17:07, Patel, Kalpesh wrote:
>> I broke into to the shell and ran the command ifstat and route commands
>> like you suggested, Michael -- ping isn't available looks like. Please
>>see
>> screenshot named 'Parallels Picture 3.png' and 'Parallels Picture after
>> shell and net reset.png' for details. I welcome further debugging means
>> and methods or insight hereŠ
>
>Thanks.  (For information, the ping command isn't part of the standard
>build; see http://ipxe.org/cmd/ping for details on how to enable it.)

The one I am going to build for below purposes, I'll enable the option,
unless you feel otherwise. I, without looking at the C code, however,
suspect the problem rears well after ping's code would be exercised so it
may not provide much way of debugging information. Let me know one way or
another and I will be more than happy to accept the guidance.

>
>The ifstat output shows two interesting error categories:
>
>   [TXE: 13 x "Error 0x2a654006" (http://ixe.org/2a654006)]
>   [RXE: 6 x "Error 0x2a654006" (http://ixe.org/2a654006)]
>
>These errors originate from
>
>   http://git.ipxe.org/ipxe.git/blob/master:/src/drivers/net/intel.c#l598
>   http://git.ipxe.org/ipxe.git/blob/master:/src/drivers/net/intel.c#l720
>
>and indicate that the virtual NIC seems to have stopped processing
>packets: it is reporting an RX overrun condition (INTEL_IRQ_RXO), and
>the transmit ring has also filled up.

That would be in line with what is observed as the behavior. In the middle
of the download, the NIC "drops" out, which I suspect might be a buffer
over run or something in that line causing the entire VM to freeze.
  

>
>I suspect this is a flaw in the emulation of the Intel NIC.  We had a
>similar problem with VMware:
>
>   http://git.ipxe.org/ipxe.git/commitdiff/0c5e3df
>
>If you're happy experimenting with driver code, then you could try
>adding some calls to intel_diag() to see what the hardware and software
>think the ring pointers are.  I've attached a sample patch which will
>dump out the ring pointers when RX overrun is first detected.


I am happy experimenting with the driver code to get to the root cause of
it. Could you let me know against which code line is the patch for? I just
want to make sure. 


>
>> Quite a number of you folks have suggested to move away from gpxelinux
>>to
>> ipxe since it has greater benefits. I completely agree that it does have
>> number of advantages. However, in our case, the overall framework is
>>bound
>> by use of HTTP protocol only which gpxelinux, as well as built in pxe
>> loader from Parallels, VMWare and VirtualBox seems to respect when I
>>force
>> set the option 210 in DHCP (see 'Parallels Picture.png' and
>> 'Snip20140408_30.png').
>
>Option 210 is specific to pxelinux.  You don't need to use it with iPXE.
>  If you give iPXE an HTTP URI, it will use HTTP.

Indeed it is. My belief is that all of you will have very powerful case
for me to switch over once the NIC issue is resolved. I believe this is
what is holding me back. This would help me consolidate the framework
solely on iPXE on both fronts, a locally bootable CDROM and net booting it.

>
>Michael
>

Much appreciate your attention and help.

Kalpesh...

>