是否有可能获得一个模块来支持(有时)报告错误的PCI ID的设备？

Question

我试图在Linux服务器上设置一个无线NIC (TP-LinkTL-WN350GD)。

冷引导后，lspci -nn显示该卡的PCI ID为168 c:ffa1 1。内核(来自backports的2.6.38)没有用于该设备ID的任何模块，因此不会加载任何模块。

但是，在热启动(即执行重新启动命令)之后，相同的设备显示为168 c:001 d，这似乎是正确的ID，由ath5k模块作为文档的这里处理。据我所知，该设备在Debian中使用这个特定内核(我可以连接到AP并与网络的其他部分进行无线通信)工作得完美无缺。

问题是，当系统关闭时，下次它启动设备时会得到一个错误的ID (168 c:ffa1 1)，而且很明显，它没有被检测到。如果我执行重新启动，那么一切都恢复正常(设备ID =168 c:001 d，自动加载ath5k模块)。

我以前从未见过如此奇怪的PCI is行为，这就是我想知道的：

在这种情况下有什么解决办法吗？有没有办法“强制”这个特定设备的ID，以便每次都加载驱动程序，而不仅仅是在温暖的启动之后？如果这可以通过一个udev规则来完成，那么一个例子将是非常有帮助的。

蒂亚角

Answer 1

你也许可以用udev来解决这个问题，但我还没醉到现在还没试着处理udev的规则。不完全疯狂的方法是让驱动程序正确地注册它可以使用替代的PCI ID --但前提是它确实可以。

我的猜测是，当它推出替代的PCI ID时，它暴露了一些不同的设备，这实际上不是一张无线网卡。我希望如果那个备用设备真的可以由驱动程序驱动，那么驱动程序就已经可以处理这个问题了。(考虑到这是一个温暖的/冷的启动差异，我猜这是某种固件加载的错误)。如果驱动器不能驱动备用设备，那么任何类型的鞋角都不能工作，udev或其他。

我会处理掉这张卡片，用一些不那么疯狂的东西来代替它。

Answer 2

也许这也可以通过udev来实现。许多年前，当我试图获得未知的USB内存密钥时，我采取了另一种方法；我手工添加了设备ID，幸运地使它正常工作。

因此，一个非常核心的方法是修改Linux源代码中的drivers/net/wireless/ath/ath5k/pci.c文件，并稍微修改一下已知的PCI部分。已经有这样一条线了：

    { PCI_VDEVICE(ATHEROS, 0x001d) }, /* 2417 Nala */

我想知道如果你把它修改成：

    { PCI_VDEVICE(ATHEROS, 0x001d) }, /* 2417 Nala */
    { PCI_VDEVICE(ATHEROS, 0xffa1) }, /* 2417 Nala */

然后编译你自己的内核。

但我以前从未见过这种改变PCI id行为的情况。完全有可能，无线网卡在报告不同的id时，实际上并不处于可用状态。

Answer 3

一种疯狂的(尽管可能有效)方法是在启动时执行lspci，并在检测到不正确的ID时强制重新启动。注意疯狂的部分(并确保对无限引导循环有一些预防措施)。

我认为，妇女的建议，以取代设备的工作，每次都是正确的方式。