[ipxe-devel] Request for Network support for HP Elitebook 745 G3 (Broadcom NetXtreme Gigabit Ethernet Plus)

[Krizak, Paul]

Interesting, because ipxe.kkpxe is the *only* way we have gotten it to work so far on our other hardware (a dozen or so different varieties of desktop hardware).

As I noted in an earlier e-mail, all three ipxe variants (.pxe, .kpxe, .kkpxe) failed in the same way (warning about using legacy driver, zeroed-out MAC address).  I also tried undionly.kpxe, which worked (got an IP address) but did not properly embed the script/menu file.

I am not claiming to be in some kind of magic vortex where computers work differently -- I totally believe you guys when you say that .kkpxe is the wrong way to go.  It's just that the alternatives you've suggested definitely DON’T work (for me) and the .kkpxe variant DOES work on everything so far.

I'm thus forced to conclude that we are completely misusing/abusing ipxe here and probably need to start over from scratch.

----
Paul Krizak              office: AF-250D
Staff IT Engineer, UCM   desk: 858-651-2467
Qualcomm, Inc            cell: 512-791-0686


-----Original Message-----
From: Michael Brown [mailto:mcb30 at ipxe.org] 
Sent: Wednesday, February 03, 2016 3:04 PM
To: Krizak, Paul; Christian Nilsson
Cc: Doose, Michael; ipxe-devel at lists.ipxe.org
Subject: Re: [ipxe-devel] Request for Network support for HP Elitebook 745 G3 (Broadcom NetXtreme Gigabit Ethernet Plus)

On 03/02/16 19:59, Krizak, Paul wrote:
> 3. make bin/ipxe.kkpxe EMBED=/tmp/menu.ipxe

Stop.  Do not pass go.  Do not attempt to use this binary.

What you're creating there is a binary that says:

- bin/ipxe.* : include native drivers for all known NICs
- *.kkpxe    : leave the underlying PXE stack active on startup

So, iPXE will choose _not_ to shut down the underlying PXE stack (due to 
the ".kkpxe").  It will then find a native driver for the NIC, which 
will most likely reset the hardware and completely blow away any 
configuration done by the underlying PXE stack.

The underlying PXE stack (a) has no idea that this has happened, and (b) 
may still have an interrupt service routine hooked.

This is not a recipe for happiness.  You might get away with it on some 
hardware, but you're basically playing Russian roulette with network 
packets.


Try the following tests:

1. Try booting from bin/ipxe.usb (on a USB key) to see if iPXE actually 
has a working native driver for your network card.

2a. If bin/ipxe.usb works, then try replacing ipxe.kkpxe with ipxe.pxe 
(which _will_ shut down the underlying PXE stack).

2b. If bin/ipxe.usb does not work, then try replacing ipxe.kkpxe with 
undionly.kpxe (which will _not_ load a native driver).

Michael