Nvidia Bluefield-3 NIC cannot be configured.

[praveengsmc]

iPxe Initializing devices is ok. Soon after, it gets stuck at Configuring (net0 xx:xx:xx:xx:xx:xx) ........

The NIC configures properly and works fine with 081b3eefc48953795122c4b1a38430498e2bb2b6 commit.

[NiKiZe]

Use ctrl-b before configuring, run ifstat, post output.

Use instructions at https://ipxe.org/howto/bisect to figure out which is the first non working commit.

[gerritmaritz]

I am having a similar issue with the data interface of the Bluefield-3. Behavior:

DHCP 0x85a08edc8 entering discovery state
Configuring (net2 a0:88:c2:4d:66:46)...DHCP 0x85a08edc8 DHCPDISCOVER
DHCP 0x85a08edc8 DHCPOFFER from 10.10.42.1:67 for 10.10.42.21
DHCP 0x85a08edc8 DHCPDISCOVER
...DHCP 0x85a08edc8 entering request state
DHCP 0x85a08edc8 DHCPREQUEST to 10.10.42.1:67 for 10.10.42.21
DHCP 0x85a08edc8 DHCPREQUEST to 10.10.42.1:67 for 10.10.42.21
DHCP 0x85a08edc8 DHCPREQUEST to 10.10.42.1:67 for 10.10.42.21
.DHCP 0x85a08edc8 DHCPREQUEST to 10.10.42.1:67 for 10.10.42.21
..DHCP 0x85a08edc8 DHCPREQUEST to 10.10.42.1:67 for 10.10.42.21
....DHCP 0x85a08edc8 DHCPREQUEST to 10.10.42.1:67 for 10.10.42.21
........ No configuration methods succeeded (https://ipxe.org/040ee186)

On the wire I can see the DHCPDISCOVER and DHCPOFFER but not any of the DHCPREQUEST packets.

Output of ifstat:

iPXE> ifstat
net0: 00:1a:ca:ff:ff:01 using SNP on SNP-0x85f2f6d18 (Ethernet) [closed]
  [Link:up, TX:0 TXE:0 RX:0 RXE:0]
net1: a0:88:c2:4d:66:5a using SNP on SNP-0x85f2f5f18 (Ethernet) [closed]
  [Link:up, TX:0 TXE:0 RX:0 RXE:0]
net1-4040: a0:88:c2:4d:66:5a using SNP on SNP-0x85f2f5f18 (Ethernet) [closed]
  [Link:up, TX:0 TXE:0 RX:0 RXE:0]
net2: a0:88:c2:4d:66:46 using BlueField-3 on 0000:03:00.0 (Ethernet) [open]
  [Link:up, TX:76779 TXE:0 RX:370780 RXE:4]
  [RXE: 3 x "The socket is not connected (https://ipxe.org/380f6093)"]
  [RXE: 1 x "Operation not supported (https://ipxe.org/3c086083)"]
net3: a0:88:c2:4d:66:47 using BlueField-3 on 0000:03:00.1 (Ethernet) [closed]
  [Link:down, TX:0 TXE:0 RX:0 RXE:0]
  [Link status: Unknown (https://ipxe.org/1a086194)]

(net2 is the interface of interest, this was taken after successful dhcp and downloading a test file)

Output of git bisect:

8b14652e506d99499cfbeaed0df07d6a83ec029e is the first bad commit
commit 8b14652e506d99499cfbeaed0df07d6a83ec029e
Author: Michael Brown <[email protected]>
Date:   Fri Sep 15 16:14:59 2023 +0100

    [eapol] Send EAPoL-Start packets to trigger EAP authentication
    
    We have no way to force a link-layer restart in iPXE, and therefore no
    way to explicitly trigger a restart of EAP authentication.  If an iPXE
    script has performed some action that requires such a restart
    (e.g. registering a device such that the port VLAN assignment will be
    changed), then the only means currently available to effect the
    restart is to reboot the whole system.  If iPXE is taking over a
    physical link already used by a preceding bootloader, then even a
    reboot may not work.
    
    In the EAP model, the supplicant is a pure responder and never
    initiates transmissions.  EAPoL extends this to include an EAPoL-Start
    packet type that may be sent by the supplicant to (re)trigger EAP.
    
    Add support for sending EAPoL-Start packets at two-second intervals on
    links that are open and have reached physical link-up, but for which
    EAP has not yet completed.  This allows "ifclose ; ifopen" to be used
    to restart the EAP process.
    
    Signed-off-by: Michael Brown <[email protected]>

https://github.com/ipxe/ipxe/commit/8b14652e506d99499cfbeaed0df07d6a83ec029e by @mcb30

Compilation options: make CROSS=aarch64-linux-gnu- bin-arm64-efi/ipxe.efi EMBED=myscript.ipxe DEBUG=dhcp

[gerritmaritz]

I believe this issue has been fixed by https://github.com/ipxe/ipxe/commit/926816c58fca5641b17c17379b52203458081668

[mcb30]

I believe this issue has been fixed by 926816c

Thanks, will mark this as closed.