我正在尝试在 Linux 服务器（Debian Squeeze）上设置无线网卡（TP-Link TL-WN350GD）。
冷启动后，lspci -nn 显示卡的 PCI ID 为 168c:ffa1。内核（来自反向移植的 2.6.38）没有该设备 ID 的任何模块，因此不会加载任何模块。
然而，在热启动（即执行重启命令）后，同一个设备显示为 168c:001d，这似乎是正确的 ID，并且由 ath5k 模块处理，如文档所述这里据我所知，该设备在使用此特定内核的 Debian 中运行完美（我可以连接到 AP 并与网络的其余部分进行无线通信）。
问题是，当系统关闭时，下次启动时设备会得到错误的 ID（168c:ffa1），显然无法检测到。如果我重新启动，则一切都会恢复正常（设备 ID = 168c:001d，ath5k 模块自动加载）。
我以前从未见过有关 PCI ID 的如此奇怪的行为，这就是我想知道的：
有没有什么办法可以解决这种情况？有没有办法“强制”此特定设备的 ID，以便每次都加载驱动程序，而不仅仅是在热启动后加载？如果可以通过 udev 规则做到这一点，那么示例将非常有帮助。
TIA，亚历克斯
答案1
您可能可以将其与 udev 强行整合，但目前我还没有醉到尝试解决 udev 规则的程度。不太疯狂的方法是让驱动程序正确注册，以便它可以与备用 PCI ID 一起工作——但前提是它实际上能。
我的猜测是，当它出现备用 PCI ID 时，它会暴露一些不同的设备，而这些设备实际上并不是无线网卡。我认为，如果该备用设备实际上可以由驱动程序驱动，则驱动程序已经可以处理这种情况。（鉴于这是热启动/冷启动的差异，我猜这是某种固件加载问题）。如果驱动程序不能驱动备用设备，则任何形式的强行插入都不会起作用，无论是 udev 还是其他方式。
我会扔掉这张卡，然后用一些不那么疯狂的东西来代替它。
答案2
可能也可以通过 udev 以某种方式完成此操作。许多年前，我在尝试让未知的 USB 存储钥匙工作时采用了另一种方法；我手动添加了设备 ID，幸运的是它工作正常。
因此，一个非常硬核的方法是修改drivers/net/wireless/ath/ath5k/pci.cLinux 源代码中的文件并修改已知 PCI ID部分。已经有这一行了：
{ PCI_VDEVICE(ATHEROS, 0x001d) }, /* 2417 Nala */
我想知道如果你将其修改为如下形式会发生什么：
{ PCI_VDEVICE(ATHEROS, 0x001d) }, /* 2417 Nala */
{ PCI_VDEVICE(ATHEROS, 0xffa1) }, /* 2417 Nala */
然后编译自己的内核。
但我以前从未见过这种改变 PCI ID 的行为。无线网卡报告不同的 ID 时，它实际上可能并未处于可用状态。
答案3
一种疯狂但可能有效的方法是lspci在启动时执行此操作，并在检测到错误 ID 时强制重启。注意疯狂的部分（并确保采取一些预防措施以防止无限启动循环）。
我认为 Womble 的建议——用每次都能正常工作的设备来替换该设备——是正确的方法。