StarTech ST10GSPEXNB (Tehuti TN4010) vendor driver will not build on Debian 11, kernel 5.10
Bought a StarTech ST10GSPEXNB to give a backup server a 10G SFP+ port, on the assumption that a card sold with a Linux driver would build against a current distribution. That was optimistic of me.
- StarTech ST10GSPEXNB, Tehuti TN4010 chip
- Debian 11, kernel 5.10.0-13-amd64, matching headers installed
- vendor driver package as shipped for the card
- generic 10G SFP+ module in the cage, not that the card has got far enough to care about it
make gets a long way in and then falls over in the transmit path:
$ make
...
tn40.c:3644: error: assignment to 'struct skb_frag_struct *' from incompatible pointer type
tn40.c:3648: error: invalid use of undefined type 'struct skb_frag_struct'
tn40.c:3651: error: invalid use of undefined type 'struct skb_frag_struct'The last two land in the DMA mapping calls.
Tried so far:
- chmod +x mvidtoh.sh, because the build stopped earlier with a permission denied and would not generate the PHY headers - that part is sorted
- checked uname -r against the installed headers, they match
- hunted for a newer package than the one the vendor ships and found nothing at all
Is anyone running one of these on a kernel from this decade, and if so, how?
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 6
Which driver package exactly - is there a version stamped on the tarball, and what kernel range does its readme claim? Every Tehuti based card I have had through my hands ships a source tree that names its supported kerenls in the readme, and it's usually a long way behind whatever you are actually running.
Worth saying which tree you are building, too. There is the vendor drop that comes with the card, and there are the community tn40xx trees - tn40xx-006 and tn40xx-003, plus the linux-6.6 and linux-6.7 branches - and they are nowhere near the same point in history. People compare notes across them all the time without noticing they are discussing different code.
Last thing: is 3644 genuinely the first error in the log, or is there something further up that you read as noise? Those three lines look like a single API change, but if the build broke earlier then the rest is just fallout from it.
Community trees are news to me - I have only ever had the tarball that came in the box, and everything here is built from that, unpacked as shipped. Those branches are the next thing I read. No version anywhere on the tarball or in the makefile, for what that is worth.
The readme is exactly as you describe. It talks about 3.x kernels and stops at the 4.14 line. I read that as a note about what they had tested on rather than a hard limit, which now looks naive.
And yes, 3644 is the first error. Above it there's nothing but warnings - unused variables, implicit declarations, the sort of thing that tree evidently produces as a matter of course - and the build walks through all of it quite happily before stopping dead in the transmit path. Same three lines, 3644, 3648 and 3651, in the same order, every run.
It is a hard limit, whatever the readme meant by it, and the errors you pasted spell out why.
The kernel changed how skb fragments are represented. From 5.4 onwards skb_frag_t is a bio_vec, and struct skb_frag_struct is simply not there any more. Source that assigns to a struct skb_frag_struct * earns exactly your line 3644 complaint, and anything that then dereferences it to hand a page and an offset to the DMA mapping calls earns the invalid use of an undefined type on 3648 and 3651. No header, no flag and no older compiler gets you around a type that no longer exists.
So on 5.10 that tree needs editing rather than configuring. The fragment handling in the transmit path has to be rewritten against the current accesssors, and it is a real patch rather than a one line fix, because the DMA mapping around those accesses changes shape at the same time.
I do not own one of these cards, so take that as a diagnosis and not a promise. I can tell you why the build fails and that it is a source problem; I cannot tell you that the driver brings a link up afterwards.
Before you sink a weekend into that patch, have a look at what's waiting on the other side of it.
I've got a StarTech PEX10000SFP here, the TN9510 variant, PCI 1fc9:4025 with subsystem 1fc9:3015. The out-of-tree tn40xx driver builds and loads for it, and dmesg is thoroughly encouraging:
And then the interface sits at NO-CARRIER with a red light in the module, forever. Same card, same cage, same optic under the StarTech Windows driver: links immediately. So the hardware's sound and the PHY firmware loads, it's the link stage of that driver port that never finishes the job.
I went through Ubuntu 22.04 and Rocky Linux 8.10, kernels 4.18, 5.15, 6.5 and 6.9, and the tn40xx-006, tn40xx-003, linux-6.6 and linux-6.7 branches. Not one of them gave me a carrier. Getting the thing to compile is the easy half, honestly.
That is the argument for spending money instead of a weekend, and I say it as somebody who normally enjoys the weekend option. A used Intel or Mellanox 10G card costs less than an afternoon of your time and its driver is already in the kernel you are booting.
One thing to know if you go Intel and put a third party optic in it. An X520 refuses the module outright with "unsupported SFP+ module type was detected" and you end up with no interface at all. The fix is a module option:
Dual port cards want 1,1 there. Then update-initramfs -u and a cold boot rather than just unloading and reloading the module, because that disabled state gets latched down in firmware and a warm reload frequently does not clear it. That is 82599 and X520 only, where the check lives in the driver. On X710 the check is in firmware and this option will not save you.
Right advice, wrong problem, in the same breath. allow_unsupported_sfp is about the driver's optic whitelist, and the card in this thread doesn't compile at all - nobody here is anywhere near the point of having an optic rejected. Useful to know later, not an answer now.
If second hand is on the table though, the other one that simply works is an HP NC523SFP, which is the OEM QLogic QLE3242, HP part 593715-001. It runs on the in-kernel qlcnic driver, so there's nothing to build at all - I have a box here reporting qlcnic 5.3.66 against adapter firmware 4.8.20, and it has needed no attention since it went in.
Two caveats. It runs hot, somewhere around 16 to 17 W at idle, which you notice in a quiet room. And SR-IOV on it is a muddle nobody I asked could confirm one way or the other. If you need SR-IOV then the NC552SFP is the better buy, it uses bnx2x and supports it properly, but you have to enable ARI forwarding upstream of it or it will not appear.