我试图在Linux服务器（Debian Squeeze）上安装无线网卡（TP-Link TL-WN350GD）。
冷启动后，lspci -nn显示该卡的PCI ID是168c：ffa1。 内核（来自backports的2.6.38）没有该设备ID的模块，所以没有模块被加载。
但是，在热启动（即执行重启命令）之后，同一个设备显示为168c：001d，这似乎是正确的ID，并由ath5k模块处理，如文中所述。 据我所知，该设备完美地在Debian中以这个特定的内核工作（我可以连接到一个AP，并与networking的其他部分进行无线通信）。
问题是，当系统关机时，下一次启动设备会得到一个错误的ID（168c：ffa1），而且显然没有被检测到。 如果我重新启动，则一切恢复正常（设备ID = 168c：001d，ath5k模块自动加载）。
我以前从来没有见过有关PCI ID的奇怪行为，这就是我想知道的：
有这样的情况有任何解决方法吗？ 有什么办法可以“强制”这个特定设备的ID，这样驱动程序每次都被加载，而不仅仅是在热启动之后？ 如果这可以通过udev规则来完成，那么一个例子会非常有用。
TIA，Alex
你可能可以用udev来解决这个问题，但是我现在还不够醉，不能尝试用udev规则来解决问题。 不完全疯狂的方法是让驱动程序正确注册，它可以使用备用的PCI ID – 但只有当它实际上可以 。
我的猜测是，当它提供备用PCI ID时，它暴露了一些不同的设备，实际上并不是无线网卡。 我希望如果这个替代设备实际上可以由司机驾驶，司机已经处理了这种情况。 （鉴于这是一个温暖/冷启动差异，我猜这是某种固件加载bollocks）。 如果驾驶员不能驾驶替代设备，那么任何types的鞋垫都不会工作，udev或其他。
我会摆脱卡片，并用一些不那么疯狂的东西代替它。
也许这可以通过udev以某种方式完成。 许多年前，我试图find未知的USB存储钥匙工作时采取了另一种方法; 我手动添加设备ID，运气得到它的工作。
所以，一个非常核心的方法是修改Linux源代码中的drivers/net/wireless/ath/ath5k/pci.c文件并修改已知的PCI ID部分。 已经有这一行了：
{ PCI_VDEVICE(ATHEROS, 0x001d) }, /* 2417 Nala */
我想知道如果你修改它会发生什么：
{ PCI_VDEVICE(ATHEROS, 0x001d) }, /* 2417 Nala */ { PCI_VDEVICE(ATHEROS, 0xffa1) }, /* 2417 Nala */
然后编译你自己的内核。
但是我从来没有见过那种改变PCI id的行为。 无线网卡实际上并不处于可用状态，而报告不同的ID是完全可能的。
一个疯狂的，尽pipe可能工作的方法是在启动时执行lspci ，并在检测到不正确的ID时强制重新启动。 注意疯狂的部分（并确保对无限启动循环有一些预防措施）。
我认为，womble的build议，以每次工作取代设备是正确的方式。