Hello all, I have been working on testing FOG+iPXE configurations with new Aquantia AQN-107 10G NIC's as well as new ASUS XG-C100C 10G NIC's. I have successfully used FOG with the integrated NICs on my machines, however both 10G cards only get as far as chainloading iPXE before getting stuck at configuring the interface with an address. I have done numerous tests and see that the cards are sending out a DHCP request and my server is sending an Offer back, however the NICs do not seem to be picking up incoming traffic. I feel this may be a driver issue with the new cards, so I was wondering if anybody had anything in the works as far as integrating drivers for these new cards. Thanks.
What is the PCIIDs of the cards?
What does ifstat show?
Which iPXE binary are you using?
What do you get when you run dhcp? (error message including ipxe.org error url)
Hardware ID's are as follows:
ASUS
PCI\VEN_1D6A&DEV_D107&SUBSYS_87411043&REV_02
PCI\VEN_1D6A&DEV_D107&SUBSYS_87411043
PCI\VEN_1D6A&DEV_D107&CC_020000
PCI\VEN_1D6A&DEV_D107&CC_0200
AQUANTIA
PCI\VEN_1D6A&DEV_D107&SUBSYS_00011D6A&REV_02
PCI\VEN_1D6A&DEV_D107&SUBSYS_00011D6A
PCI\VEN_1D6A&DEV_D107&CC_020000
PCI\VEN_1D6A&DEV_D107&CC_0200
ifstat shows the interface link is up and shows transmit packets, but none received even though I can confirm my DHCP is sending an Offer broadcast.
I've tested this with just about every iPXE binary that came with FOG and even tried making a few custom ones with rom-o-matic
And re-running dhcp returns the same error: "No Configuration Methods Succeeded (
http://ipxe.org/040ee186)
ok so pciid is 1d6a:d107 :
http://pci-ids.ucw.cz/read/PC/1d6a/d107 "AQC107 NBase-T/IEEE 802.3bz Ethernet Controller [AQtion]"
Please provide the output from ifstat (especially the driver) and which binary you are using (the binary you are using when you get that output)
preferably using the "official" ones from
http://boot.ipxe.org
But simply put there is no native drivers in iPXE for that nic, so if iPXE finds any nic at all it is either a different nic that it finds, or it is found using UNDI (or SNP if running in EFI mode) the UNDI/SNP stack is provided by firmware or NIC ROM. We can explain this more after having the information asked above.
Okay here's the full ifstat output, net0 is the integrated card which is currently unplugged and net1 is the Aquantia card
net0: 78:45:c4:fe:42:8e using rt18168 on 0000:05:00.1 (closed)
[Link:down, TX:0 TXE:0 RX:0 RXE:0]
[Link status: Down (
http://ipxe.org/38086193)]
net1: 00:17:b6:00:16:69 using NII on NII-0000:01:00.0 (closed)
[Link:up, TX:8 TXE:0 RX:0 RXE:0]
This is the same output I get, as well as having the same dhcp error messages regardless of which iPXE binary I use including the genereic snp.efi binary. (It is required for my environment use to use EFI mode)
Still not telling us which binary you are using in this particular case
So EFI mode also visible by the NII driver in the ifstat output. (would have been nice to have that info in the first post
)
Thanks to the rtl driver being present as well you are probably using ipxe.efi in this specific case.
The NII driver is a standard interface in EFI mode for NICs, which means (if the MAC address matches) that the NII/SNP implementation _ON_ that nic is broken, so trying to get new firmware on those cards would probably be the first step if you just want them running.
Next is to build a good basic version of snponly.efi (which should only try to initialize the nic that it is chained via) with DEBUG flags enabled
So: make bin-x86_64-efi/snponly.efi DEBUG=nii,snp,snponly
Test that one and see what you get, and then you might be able to use that to get Aquantia to fix their firmware.
Developing a native driver for iPXE might be a different path, but should not rule out getting any firmware fixed as well.
Is there something news? Is this issue fixed? Is it AQN or iPXE to fix it?
I also hit same issue on AQN-107 card to proceed a iPXE loading.