Bug 202097 - [EFI] boot/loader.efi: efinet regression
Summary: [EFI] boot/loader.efi: efinet regression
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Many People
Assignee: FreeBSD bugs mailing list
URL: https://reviews.freebsd.org/D5366
Keywords: regression, uefi
Depends on:
Blocks: 203349
  Show dependency treegraph
 
Reported: 2015-08-05 06:54 UTC by Ganael LAPLANCHE
Modified: 2016-05-27 13:43 UTC (History)
4 users (show)

See Also:


Attachments
Screenshot with IPv4 and IPv6 enabled (67.89 KB, image/png)
2016-01-21 11:32 UTC, Ganael LAPLANCHE
no flags Details
Debug patch used to produce attached screenshot (2.15 KB, patch)
2016-01-21 11:33 UTC, Ganael LAPLANCHE
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
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 freebsd_committer 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 freebsd_committer 2016-03-11 08:22:07 UTC
Reset assignee
Comment 6 Ganael LAPLANCHE 2016-03-11 08:26:40 UTC
Please, can someone have a look at that regression ?
Comment 7 Ed Maste freebsd_committer 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 freebsd_committer 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 !