Troubleshooting the Aquantia Atlantic driver

M

MatthewH

After issuing kldload if_atlantic.ko (FreeBSD 14.0 release, module v0.0.5_2), the window dumps out about 10 lines (or one long string, I can't tell) of spaces or non-printable characters. The aq0 interface is created, but the status is "no carrier", and as soon as the module loads the LEDs on the physical interface go out.

I'm willing to troubleshoot the driver, but I don't know how to go about it. I would like to get this working, and I'm down for doing research and writing code to make it happen, I just need some tips, pointers, suggestions, etc. to get going.

This is a motherboard NIC on the Lenovo P620 ThinkStation (AMD chipset / Ryzen ThreadRipper CPU) and identifies as:

Code: 
Aquantia Corp. AQC107 NBase-T/IEEE 802.3bz Ethernet Controller [AQtion] (rev 02)

I also built the port for comparison, and the compiled if_atlantic.ko file is identical to the one installed by pkg.

Any insight would be appreciated,
Matthew
 
The interface is "up" after loading the module. Below is the kldload sesson. Note the blank lines after loading, I don't know what that is about, or the blue line that appears as a result (see attached photo, and I removed my MAC address info). This is a KDE Konsole terminal. The aq0 interface is set to DHCP configure and it will also take a manually assigned IP, but it makes no difference with the status or activity LEDs on physical interface.

Code: 
$ sudo kldload if_atlantic.ko





















$ ifconfig aq0
aq0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=48103bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWFILTER,HWSTATS,MEXTPG>
        ether xx:xx:xx:xx:xx:xx
        media: Ethernet autoselect <full-duplex,rxpause,txpause> (autoselect)
        status: no carrier
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

if_atlantic.png
 
Thanks for the links. I posted a reply in the github thread along with BIOS screenshots. I don't have any BIOS settings that are specifically related to unlocking PCIe lanes. The NIC works on the same computer when running Linux and Win10, so I can only assume this is a driver problem.

If NetBSD / OpenBSD have drivers, does that mean it is straight forward to get them into FreeBSD?
 
MatthewH said:
Thanks for the links. I posted a reply in the github thread along with BIOS screenshots. I don't have any BIOS settings that are specifically related to unlocking PCIe lanes. The NIC works on the same computer when running Linux and Win10, so I can only assume this is a driver problem.

If NetBSD / OpenBSD have drivers, does that mean it is straight forward to get them into FreeBSD?
Click to expand...
I don't know, I am not a developer. Probably it wouldn't be very difficult. There is an open bug
Bug 238324 - Add XG-C100C/AQtion AQC107 10GbE NIC driver

Marvell bought Aquantia in Sept. 2019
Marvell released a driver for one their NIC series for FreeBSD 7 once ... Maybe they would like to support development for these new-ish series. Honestly I'd just ask them if or when they are going to release a driver. But if you need,want the speed; well supported fast pcie network cards should be available too
 
I looked for the datasheet, but if Aquantia made them available I could not find any old versions, and Marvell has decided to keep them behind an NDA pay-wall. Without the register details, making the driver work is much much harder. I don't know why engineer would choose a part where the datasheets were not readily available. It seems all the development support stopped when Marvell bought Aquantia.

Yeah, I know other NICs are available. I have a dual-port X540-T2 that "just works" out of the box with the genric kernel. But I don't need a dual 10Gb NIC in this system, or the extra heat it produces (those cards get HOT), when there is a perfectly good and working NIC on the motherboard.

I'll try to ask Marvell, but I suspect they won't even bother to reply.
 
MatthewH said:
when there is a perfectly good and working NIC on the motherboard.
Click to expand...
Of course this would be my way of thinking as well. As there are ("prototype"?) versions of this driver available already, it probably shouldn't be entirely impossible to get them into a quite stable working state.

I'd be interested to know if you get a response from Marvell
 
pming said:
it probably shouldn't be entirely impossible to get them into a quite stable working state
Click to expand...

While not impossible, without a datasheet giving the register details of the chip, I would say the effort needed would be unreasonable. I'm willing to debug and test the driver, but I'm not willing to reverse engineer the chip. Even a working reference driver is usually void of comments that explain why things are being set in such a way, so you would still need the datasheets to validate such code (and know if you need to make a change, or if there is a bug or mistake). This tends to be the state of software these days, piles of code with almost no explanations as to why it was done that way.

pming said:
I'd be interested to know if you get a response from Marvell
Click to expand...

I sent the message, I'll post any response.
 
You must log in or register to reply here.
Back
Top