StarTech ST10GSPEXNB（Tehuti TN4010）厂商驱动在 Debian 11、内核 5.10 上编译不过
买了块 StarTech ST10GSPEXNB，想给一台备用服务器加个 10G SFP+ 口，本以为一块随卡附带 Linux 驱动的卡应该能在当前的发行版上编译通过。现在看来是我太乐观了。
- StarTech ST10GSPEXNB，Tehuti TN4010 芯片
- Debian 11，内核 5.10.0-13-amd64，已装好对应的 headers
- 卡自带的厂商驱动包
- 笼子里插的是一个通用的 10G SFP+ 模块，不过这卡还没走到需要关心它的阶段
make 能走很远，但最后在发送路径上栽了：
$ 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'后两条落在 DMA 映射调用那里。
已经试过的东西：
- chmod +x mvidtoh.sh，因为构建早先就因为 permission denied 停住了，生成不了 PHY 头文件——这部分已经解决
- 核对过 uname -r 和已装 headers 是否一致，是一致的
- 找过比厂商发布版更新的包，什么都没找到
有没有人在这个年代的内核上跑通过这块卡，是怎么弄的？
Show original (English)
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
具体是哪个驱动包——压缩包上有没有标版本号，它的 readme 声称支持哪个内核范围？我经手过的每一块基于 Tehuti 的卡，源码树的 readme 里都写着支持的内核，而且通常远远落后于你实际在跑的版本。
也值得说清楚你在编译的是哪一棵树。有随卡自带的厂商发布版，也有社区维护的 tn40xx 系列树——tn40xx-006、tn40xx-003，还有 linux-6.6 和 linux-6.7 分支——它们在历史进度上相差很远。大家经常互相对比经验，却没意识到讨论的其实是不同的代码。
最后一点：3644 真的是日志里第一条错误，还是前面还有什么被你当成噪音跳过了？这三行看着像是同一个 API 变化引起的，但如果构建更早就已经出问题，那后面这些就只是它的连锁反应。
社区维护的树我倒是第一次听说——我手头一直只有随卡附带的那个压缩包，这里的一切都是照原样解包、原样编译的。那些分支是我接下来要去看的东西。顺带一提，压缩包和 makefile 里哪儿都没标版本号。
readme 正如你说的那样。它谈的是 3.x 内核，写到 4.14 那条线就没了。我原来把这当成他们测试过的范围的说明，而不是硬性限制，现在看来这个想法太天真了。
是的，3644 确实是第一条错误。它前面只有警告——未使用的变量、隐式声明之类的，看样子这棵树本来就会产生这些——构建顺顺当当地把它们都走完，才在发送路径上彻底卡死。每次运行都是同样的三行，3644、3648、3651，顺序也一样。
不管 readme 本意是什么，这确实是个硬性限制，你贴的报错已经说明了原因。
内核改变了 skb fragment 的表示方式。从 5.4 开始 skb_frag_t 就是一个 bio_vec，struct skb_frag_struct 根本已经不存在了。凡是给 struct skb_frag_struct * 赋值的源码，都会正好触发你 3644 那行的报错；后面再对它解引用、把 page 和 offset 传给 DMA 映射调用的代码，就会在 3648 和 3651 上触发对一个不存在类型的非法使用。没有头文件、没有开关、也没有更老的编译器能绕过一个已经不存在的类型。
所以在 5.10 上，这棵树需要的是修改，而不是配置。发送路径里的分片处理逻辑得按当前的访问接口重写，而且是真正的补丁而不是改一行就完事，因为围绕这些访问的 DMA 映射同时也变了形态。
我手头没有这块卡，所以这只是诊断，不是承诺。我能告诉你为什么编译失败、这是源码层面的问题；但没法告诉你驱动改完之后链路能不能起来。
在你为这个补丁搭进去一个周末之前，先看看它另一头等着你的是什么。
我这里有一块 StarTech PEX10000SFP，TN9510 那个变体，PCI 1fc9:4025，子系统 1fc9:3015。这块卡用第三方维护的 tn40xx 驱动能编译、能加载，dmesg 看起来相当鼓舞人心：
然后接口就一直停在 NO-CARRIER，模块上是红灯，一直这样。同一块卡，同一个笼子，同一个光模块，换成 StarTech 的 Windows 驱动：立刻起链路。所以硬件是好的，PHY 固件也加载了，是这个驱动链路建立那一步没能完成。
我在 Ubuntu 22.04 和 Rocky Linux 8.10 上试过，内核 4.18、5.15、6.5、6.9，还有 tn40xx-006、tn40xx-003、linux-6.6、linux-6.7 这几个分支。没有一个给我起过 carrier。老实说，能编译过只是简单的那一半。
这就是花钱而不是花一个周末的理由，我说这话的时候，平时其实是更愿意选周末那条路的人。一块二手的 Intel 或 Mellanox 10G 网卡，价格不到你一个下午的时间值钱，而且驱动早就在你正在启动的内核里了。
如果你打算换成 Intel 网卡、又想插第三方光模块，有件事要知道。X520 会直接拒绝这个模块，报 "unsupported SFP+ module type was detected"，结果是连接口都没有。解决办法是一个模块参数：
双口卡这里要写 1,1。然后执行 update-initramfs -u 并做一次冷启动，而不是简单地卸载再加载模块，因为那个禁用状态会被锁死在固件里，热重载往往清不掉它。这只对 82599 和 X520 有效，因为检查是在驱动里做的。X710 上这个检查在固件里，这个参数救不了你。
建议是对的，但问题问反了，而且是在同一句话里。allow_unsupported_sfp 针对的是驱动的光模块白名单，而这个帖子里的卡根本编译不过——这里没有人已经走到光模块被拒绝这一步。以后有用，现在不是答案。
不过如果二手也在考虑范围内的话，另一个基本上是插上就能用的是 HP NC523SFP，也就是 OEM 版的 QLogic QLE3242，HP 料号 593715-001。它走的是内核自带的 qlcnic 驱动，根本不用编译任何东西——我这里有一台机器报的是 qlcnic 5.3.66，配适配器固件 4.8.20，装上之后就没管过它。
两个要注意的地方。它挺热的，空载大概 16 到 17 W，在安静的房间里能感觉出来。还有它的 SR-IOV 支持挺混乱，我问过的人没一个能确认到底行不行。如果你需要 SR-IOV，NC552SFP 是更好的选择，它用的是 bnx2x，SR-IOV 支持是正经的，不过得在它上游启用 ARI forwarding，不然它根本不会出现。