Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

cardbus wireless card in kernel 2.6

2004-11-29
2013-04-08
  • I have been trying to get my Atheros RoamAbout wireless card to work with kernel 2.6.9. I know it needs the madwifi driver and all that, but my problem starts earlier. This card is a "cardbus" type, and on a 2.4 series kernel it is seen as a PCI device just fine. It's the last line from the lspci output here:

    ...
    00:13.0 CardBus bridge: Texas Instruments PCI1420
    00:13.1 CardBus bridge: Texas Instruments PCI1420
    00:14.0 VGA compatible controller: Trident Microsystems Cyber 9525 (rev 49)
    01:00.0 Ethernet controller: Unknown device 1688:ffff

    I had no luck whatsoever getting the card recognized in a (any, I tried several versions over time) 2.6.x kernel. That last line is just not there. I would have a hard time going back to 2.4, so maybe someone has a hint where I should look.

    I read through the release notes and later came to this section in linux/driver/pcmcia/cs.c, in the send_event routine:

        if (s->state & SOCKET_CARDBUS)
            return 0;

    with s being a pointer to the pcmcia socket structure in question. It looks like these lines (which don't have an equivalent in the corresponding 2.4 file) squash the event generated by the insertion of a cardbus/PCI-type device.

    I put a few more debug statements in, and indeed the card has the cardbus bit set. I commented the return out and tried to follow what happens, but this is a far as I understand the structure of this code.

    I have all proper flags set in the kernel, pcmcia/cardbus/hotplug etc.

    Is there anyone who got that card to work in 2.6, or any cardbus type card for that matter? Is there a trick? I run gentoo, but I briefly tried FC3 with 2.6.9 and it's the same thing.

    Thanks,
    Martin

     
    • David Hinds
      David Hinds
      2004-12-20

      You can't comment that code out; that isn't the problem.  The problem is a bug in the kernel's PCI code (or at least a bad interaction with CardBus devices) that is causing the device identification codes to be misread.

      -- Dave