On 29/03/16 20:41, Todd Stansell wrote:
iPXE> show net0/bustype:hexraw
net0/bustype:hexraw =
908b5424048b04248902896204895a0889720c897a10896a1431c0c38b5424048b44240885c07501408b62048b5a088b720c8b7a108b6a1459ff32c3b8d23b01
Nice catch. It turns out that there is a path whereby
dev->desc.bus_type will not be set to any value (and so will be left as
zero): this can happen if undibus_probe() detects the underlying UNDI as
being neither PCI nor ISAPnP. It will still continue to allow the
device to be used, since dev->desc is not required for actually using
the NIC. However, netdev_fetch_bustype() believes that drivers will
always initialise dev->desc.bus_type (which seems like a reasonable
assumption, since it's generally set by the bus driver before the NIC
driver ever gets called). This eventually leads to
netdev_fetch_bustype() treating NULL as a string pointer.
Should now be fixed in:
http://git.ipxe.org/ipxe.git/commitdiff/70509e6
If you retry with current master, you should now get a "No such file or
directory" from "show net0/bustype".
Adding tcpip debug logs, I see some of these:
Unrecognized TCP/IP protocol 51
I believe that's an IPSEC packet.
Is there some way to help determine if the problem is within iPXE somewhere or
the BIOS or the NIC itself? It feels like all of these problems are the
failed handoff of the bus info above, so it can't load proper network drivers,
etc.
The bus info failure is interesting. It suggests that pxeprefix.S was
unable to retrieve the device information. You should see an error
message somewhere in the "PXE->EB" block of text (before the iPXE
startup banner is printed).
As to loading proper network drivers: you're currently using
undionly.kpxe. By definition, this uses the underlying UNDI driver
(provided by Intel), not an iPXE native driver for that card. For a
native driver, you would use e.g. ipxe.pxe instead.
8086:1572 appears to be handled in Linux by the i40e driver. We don't
yet have a native driver for that card. However, Intel has historically
been exceptionally good at preserving backwards compatibility between
their NICs: we are able to use essentially the same datapath code for
everything from the original e1000 up to the 82599 10Gig virtual
function driver. There's a good chance that i40e cards can be natively
supported in iPXE with minimal effort.
You could even push your luck and try adding a PCI_ROM() line for
8086:1572 to drivers/net/intelx.c. :)
Michael
_______________________________________________
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
