Revision r277943 (a modification to the efinet_match() function within sys/boot/efi/libefi/efinet.c) broke netbooting on my machine. The netbooting process ends up with the following message displayed :
panic: netboot: no interfaces left untried
--> Press a key on the console to reboot <--
Reverting the change allows the machine loading the kernel again.
With the change reverted, I can read the following variables from within loader.efi :
The machine has a Supermicro X9SRi-F motherboard with an Intel i350 *Dual Port* NIC.
Further testing on a X10SRi-F mobo shows that on this board (with a single interface that has two ports), enabling IPv6 support in EFI FW does not create two additional interfaces.
Also, d_unit starts at 0 as shown on attached screenshots (reproduced with attached "debug" patch applied).
Created attachment 165912 [details]
Screenshot with IPv4 and IPv6 enabled
Created attachment 165913 [details]
Debug patch used to produce attached screenshot
Seeing exact same thing with 01/21/2016 -head snapshot while trying to netboot minnowboard max using loader.efi.
Please, can someone have a look at that regression ?
Can you test the change(s) proposed in review D5366
Thanks for your answers.
The patch proposed on :
fixes netbooting on my X9SRi-F machine.
I have also tested the second patch :
(as suggested in D5366), it also fixes netbooting on the same machine.
A commit references this bug:
Date: Thu May 26 23:32:29 UTC 2016
New revision: 300810
Fix unit number of EFI net interfaces and ignore psuedo network interfaces.
In r277943, the efinet_match() routine was changed to use an off by one
when matching network interfaces. The effect was that using "net1"
actually used the device attached to "net0".
Digging into the hardware that needed this workaround more, I found that
UEFI was creating two simple network protocol devices for each physical
NIC. The first device was a "raw" Ethernet device and the second device
was a "IP" device that used the IP protocol on top of the underlying
"raw" device. The PXE code in the firmware used the "IP" device to pull
across the loader.efi, so currdev was set to "net1" when booting from the
physical interface "net0". (The loaded image's device handle referenced
the "IP" device that "net1" claimed.)
However, the IP device isn't suitable for doing raw packet I/O (and the
current code to open devices exclusively actually turns the "IP" devices
off on these systems).
To fix, change the efinet driver to only attach to "raw" devices. This
is determined by fetching the DEVICE_PATH for each handle which supports
the simple network protocol and examining the last node in the path. If
the last node in the path is a MAC address, the device is assumed to be
a "raw" device and is added as a 'netX' device. If the last node is not
a MAC address, the device is ignored.
However, this causes a new problem as the device handle associated with
the loaded image no longer matches any of the handles enumerated by
efinet for systems that load the image via the "IP" device. To handle
this case, expand the logic that resolves currdev from the loaded image
in main(). First, the existing logic of looking for a handle that
matches the loaded image's handle is tried. If that fails, the device
path of the handle that loaded the loaded image is fetched via
efi_lookup_image_devpath(). This device path is then walked from the
end up to the beginning using efi_handle_lookup() to fetch the handle
associated with a path. If the handle is found and is a known handle,
then that is used as currdev. The effect for machines that load the
image via the "IP" device is that the first lookup fails (the handle
for the "IP" device isn't claimed by efinet), but walking up the
image's device path finds the handle of the raw MAC device which is used
With these fixes in place, the hack to subtract 1 from the unit can now
be removed, so that setting currdev to 'net0' actually uses 'net0'.
Tested by: ambrisko
Sponsored by: Cisco Systems
This commit fixes boot on X9SRI-F, thanks John !