bnx2x fails to load firmware on Dell R430

[george1421]

OK this is good promising news. eth5 is getting a link up but no IP address in FOS but you can pxe boot and iPXE is getting an IP address because the FOS kernel (bzImage) and VHD (init.xz) are being sent to the target computer. When we see this we typically see that spanning tree is turned on at the network switch. Spanning tree takes about 27 seconds for the port to start forwarding data. The FOS engine is so fast that it has already given up by the time spanning tree starts to forward data.

On these ports you need to enable one of the fast spanning tree prototocols (port fast, fast stp, rstp, or what ever your switch mfg calls it). A quick check to see if its a spanning tree issue is to put an unmanaged switch between the building switch and the target computer. This unmanaged switch keeps the port on the building switch from winking as the iPXE kernel hands off the network interface to the FOS engine.

[grey]

@george1421 said in bnx2x fails to load firmware on Dell R430:

OK this is good promising news. eth5 is getting a link up but no IP address in FOS but you can pxe boot and iPXE is getting an IP address because the FOS kernel (bzImage) and VHD (init.xz) are being sent to the target computer. When we see this we typically see that spanning tree is turned on at the network switch. Spanning tree takes about 27 seconds for the port to start forwarding data. The FOS engine is so fast that it has already given up by the time spanning tree starts to forward data.

On these ports you need to enable one of the fast spanning tree prototocols (port fast, fast stp, rstp, or what ever your switch mfg calls it). A quick check to see if its a spanning tree issue is to put an unmanaged switch between the building switch and the target computer. This unmanaged switch keeps the port on the building switch from winking as the iPXE kernel hands off the network interface to the FOS engine.

its a cisco so its port fast, i’ll check right now,

[george1421]

Also pondering this a bit more since your first (usable) interface is eth5 I can see another issue.

@Developers Does the FOS engine stop enumerating the network adapter at eth1 or will it keep going until it finds a network adapter with a link up state to use? OR Is there a kernel parameter we can pass that says to use ethX as the FOS network interface?

[Tom Elliott]

@george1421 It tries everything until it finds a link up I believe.

[george1421]

@Tom-Elliott said in bnx2x fails to load firmware on Dell R430:

@george1421 It tries everything until it finds a link up I believe.

Great, I have never tried. But I just thought I can test this by creating a vm with 6 network adapters with eth5 being the only one connected. But I’m not sure if I can have it defined but not having the link up. I may have to play in my test lab later tonight.

[Tom Elliott]

@george1421 Well it goes a bit further, if a link is up, but fails to get an ip, it will continue on as well, I believe.

[george1421]

@Tom-Elliott That one I can test by setting the interface to a vlan without a dhcp server. I will prove that one out for sure. The other one I’m not sure if I can have a “unplugged” interface but have it appear in linux with ESXi.

[grey]

@Tom-Elliott said in bnx2x fails to load firmware on Dell R430:

@george1421 Well it goes a bit further, if a link is up, but fails to get an ip, it will continue on as well, I believe.

Networking works!

I can confirm that, mine runs through interfaces 1-5 and now now acquires a IP!, i’m unsure if there is a arbitrary limit. when 5 was failing to get DHCP it also tried 6 and 7. Toms fix on the firmware of the drivers and Georges portfast suggestion solved the last of my network issues. Unfortunately I won’t have access to the servers for a week or so, but once they get back i’ll see how the imaging goes. at this point it should work as the rest is similar to my older servers setup the same way.

[grey]

@grey

oh btw, thanks tons guys for all your help

[george1421]

@grey Before you loose access to this server pxe boot it again and run the compatibility test from the FOG iPXE menu. I’m interested to see if both networking and storage passes (you will be too).

[grey]

@george1421

I will do that as soon as the servers return, they are all out with customers now and I have no access.

[Tom Elliott]

@george1421 I’m fairly sure they will both pass.

[Sebastian Roth]

@grey said:

Toms fix on the firmware of the drivers and Georges portfast suggestion solved the last of my network issues.

I don’t think the added firmware binaries made any difference in this case. As we can see in the dmesg output further down the connected NIC eth5 is managed by the tg3 driver…
@Tom-Elliott How much did those drivers add to the kernel size? We might think about removing those again as I have never seen anyone PXE booting on fiber cards. What do you think? @george1421?

[george1421]

@Sebastian-Roth You are right that firmware is for the fiber (10G) adapter. While it did fix the error in the log its not adding any real value for the OP or for FOG in general. But too, I’m still not seeing FOG as a good tool for cloning servers because of the other mix of hardware (you won’t find in desktops). I would say remove the firmware and have the OP test again now that its working in his environment (because the other roadblocks have been removed).