|Summary:||[EFI] boot/loader.efi: efinet regression|
|Product:||Base System||Reporter:||Ganael LAPLANCHE <ganael.laplanche>|
|Component:||kern||Assignee:||freebsd-bugs (Nobody) <bugs>|
|Severity:||Affects Many People||CC:||emaste, hiren, jhb, martymac|
|Bug Depends on:|
Description Ganael LAPLANCHE 2015-08-05 06:54:51 UTC
Hi Doug, 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 : currdev=net0: loaddev=net0: The machine has a Supermicro X9SRi-F motherboard with an Intel i350 *Dual Port* NIC. Best regards, Ganael.
Comment 1 Ganael LAPLANCHE 2016-01-21 11:31:43 UTC
Hi Doug, 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). Regards, Ganael.
Comment 2 Ganael LAPLANCHE 2016-01-21 11:32:31 UTC
Created attachment 165912 [details] Screenshot with IPv4 and IPv6 enabled
Comment 3 Ganael LAPLANCHE 2016-01-21 11:33:53 UTC
Created attachment 165913 [details] Debug patch used to produce attached screenshot
Comment 4 Hiren Panchasara 2016-01-22 23:50:09 UTC
Seeing exact same thing with 01/21/2016 -head snapshot while trying to netboot minnowboard max using loader.efi.
Comment 5 Ganael LAPLANCHE 2016-03-11 08:22:07 UTC
Comment 6 Ganael LAPLANCHE 2016-03-11 08:26:40 UTC
Please, can someone have a look at that regression ?
Comment 7 Ed Maste 2016-03-29 18:40:03 UTC
Can you test the change(s) proposed in review D5366 https://reviews.freebsd.org/D5366
Comment 8 Ganael LAPLANCHE 2016-03-31 08:33:46 UTC
Hi, Thanks for your answers. The patch proposed on : https://reviews.freebsd.org/D5366 fixes netbooting on my X9SRi-F machine. I have also tested the second patch : http://www.pastebin.ca/3379018 (as suggested in D5366), it also fixes netbooting on the same machine. Regards, Ganael.
Comment 9 commit-hook 2016-05-26 23:33:01 UTC
A commit references this bug: Author: jhb Date: Thu May 26 23:32:29 UTC 2016 New revision: 300810 URL: https://svnweb.freebsd.org/changeset/base/300810 Log: 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 as currdev. 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'. PR: 202097 Tested by: ambrisko Sponsored by: Cisco Systems Changes: head/sys/boot/efi/libefi/efinet.c head/sys/boot/efi/loader/main.c
Comment 10 Ganael LAPLANCHE 2016-05-27 13:43:33 UTC
This commit fixes boot on X9SRI-F, thanks John !