2

I’m trying to setup a wireless NIC (TP-Link TL-WN350GD) on a Linux server (Debian Squeeze).

After a cold boot, lspci -nn shows that the PCI ID for the card is 168c:ffa1. The kernel (2.6.38 from backports) doesn’t have any module for that device ID, and so no module gets loaded.

However, after a warm boot (i.e., executing the reboot command), the same device shows up as 168c:001d, which seems to be the right ID and is handled by the ath5k module as documented here. As far as I can tell, the device works flawlessly in Debian with this specific kernel (I can attach to an AP and communicate wirelessly with the rest of the network).

The problem is that when the system gets powered off, the next time it boots the device gets a wrong ID (168c:ffa1), and obviously it’s not detected. If I perform a reboot, then everything goes back to normal (device ID = 168c:001d, with the ath5k module loaded automatically).

I’ve never seen such an odd behavior regarding PCI IDs before, and this is what I’d like to know:

Is there any workaround for a situation like this? Is there any way to “force” the ID of this particular device so that the driver is loaded every time, and not only after a warm boot? If this can be done through an udev rule, an example would be really helpful.

TIA, Alex

Improve this question
1
  • Not a serverfault question; voting to move to superuser.
    – womble ♦
    Jul 28, 2011 at 1:27

3 Answers 3

Reset to default
2

You could probably shoehorn this in with udev, but I'm not drunk enough to try grappling with udev rules at the moment. The not-entirely-insane way would be to have the driver properly register that it can work with the alternate PCI ID -- but only if it actually can.

My guess is that when it comes up with the alternate PCI ID, it's exposing some different device, that isn't actually a wireless card. I would expect that if that alternate device could actually be driven by the driver, the driver would already handle that case. (Given that it's a warm/cold boot difference, I'm guessing it's some sort of firmware loading bollocks). If the driver can't drive the alternate device, then any sort of shoehorning won't work, udev or otherwise.

I'd get rid of the card and replace it with something that isn't quite so insane.

Improve this answer
2

Probably this can be somehow done via udev, too. Many years ago I took another approach while trying to get unknown USB memory key to work; I added the device ID by hand and by luck got it working.

So, a very hardcore way would be to modify drivers/net/wireless/ath/ath5k/pci.c file in Linux source code and modify Known PCI ids section a bit. There's already this line:

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

I wonder what would happen if you modified it to be:

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

and then compiled your own kernel.

But I haven't seen that kind of changing PCI id behaviour before. It's entirely possible that the wireless card isn't actually in usable state while it reports that different id.

Improve this answer
1
  • That sounds like a very good approach, I'll definitely give it a try and see what happens. If the card is usable when it's showing the wrong ID, I guess that adding that ID to the module's device list should work. Thanks a lot for your suggestion.
    – alemartini
    Jul 28, 2011 at 12:22
0

An insane, albeit possibly working, approach would be to do lspci at boot time and force a reboot, when incorrect ID is detected. Note the insane part (and make sure to have some precautions against infinite boot loop).

I think that womble's suggestion to replace the device with something that works every time is the right way.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .