Re: [Etherboot-developers] Re: [Etherboot-users] Scanning the PCI bus

[Peter L. <P.L...@sy...>]

I don't think there's a single right way (and definitely no "obvious"
right way) to cope with multiple nics; to add confusion I've just
realised something about PXE that's been puzzled me for ages.

> Yes, it's a bug, or rather, incomplete code. As the comment indicates it
> was also to prefer the NIC that the bootrom is on (and it's probably
> doing it wrong anyway), but as you point out, the first candidate always
> wins.

I noticed some time ago that with multiple NICs, PXE seems to prefer
the *last* NIC in the scan order. Then it hit me - when you have
multiple PXE NICs, the BIOS *initialises* PXE for *all* NICS starting
(on all systems we have) from zero and counting up - but there is only
one PXE context, so each new initialisation overwrites the last one.
Then the BIOS initiates PXE - using the nic of *last* PXE rom to
initialise... and, yes, if I wipe PXE from the last nic, PXE uses the
last *initialised* nic, *not* the last *scanned*. I haven't tried
mixing PXE nic types but I'll bet that this is true regardless.

So for multiple NICs, Etherboot chained via PXE is usually guaranteed
to use a different nic from PXE; this is inconvenient where nics are
not connected to the same LAN and can't all see the same dhcp server.
Vasil has a locally hacked Etherboot which scans backwards to fix
this. So Etherboot is started by PXE, it might be a useful short term
fix to scan backwards by default.

> The issue of what to do with multiple NICs needs more thinking. The code
> in config.c is not flexible enough.

Attempts to find the one true nic are ultimately doomed to failure -
one could use the first nic scanned which Etherboot can support, but
this wouldn't reliably match Linux's eth0 where multiple nic types are
present (Linux orders nics from the lowest to highest slot number of
nics which a driver recognises, but the order of driver installation
is essentially arbitrary). If this isn't what you need, then at build
time one might choose...

 Scan...
  0 up to 0xff
  0xff down to 0
  start at X, up or down as per a flag

 Arbitrary list of slot IDs [ for highly predictable hardware ]

 Prompt the user to choose.

My feeling is still that it's "right" to DISCOVER on all available
nics and choose between the replies, certainly for method of running
Etherboot (modular bios, linuxbios, disk) which are "nic agnostic".

If one really wants to associate an image with a nic (maybe then one
it is installed in, but that's not a requirement), encode a preference
for the nic's MAC address. This is reliable - unlike slot number
(fails if the nic is moved) or second guessing a slot scan algorithm
(fails if another nic is inserted); each image would prefer its "own"
nic, but fall back to one of the default algorithms above if it is not
present. The association of image with nic is, after all, made at
install time.

Actually, it occurs to me that one can ask PXE which MAC address UNDI
is using, so that Etherboot chained from PXE can prefer the nic with
that MAC address (but still fall through to the others).

Got an hour or two spare, Vasil?