[Edgy regression] Hostap driver for PRISM2 wifi card not working any more

[Pascal Vincent]

Binary package hint: linux-image-2.6.17-10-generic

On dapper, i was affected by bug #41652, so that i had to blacklist orinoco kernel modules to make my prism2 wifi card work in wpa crypted wireless network.
This blacklist made hostap-cs module load automatically on dapper (see [syslog dapper]).

After my upgrade to edgy, hostap_cs is not loaded any more. If i load it "manually" with sudo modprobe hostap-cs, it is loaded but doesn't see my pcmcia card (see [syslog edgy]).

If i remove orinoco blacklisting, orinoco_cs driver is automatically loaded :
pascal@laptop:/var/log$ lspcmcia
Socket 0 Bridge: [yenta_cardbus] (bus ID: 0000:00:04.0)
Socket 0 Device 0: [orinoco_cs] (bus ID: 0.0)
Socket 1 Bridge: [yenta_cardbus] (bus ID: 0000:00:04.1)
but orinoco is still not working with wpa_supplicant

[syslog dapper]
Sep 22 23:07:53 localhost kernel: [17179611.448000] ieee80211_crypt: registered algorithm 'NULL'
Sep 22 23:07:53 localhost kernel: [17179611.536000] hostap_cs: 0.4.4-kernel (Jouni Malinen <email address hidden>)
Sep 22 23:07:53 localhost kernel: [17179611.536000] hostap_cs: setting Vcc=33 (constant)
Sep 22 23:07:53 localhost kernel: [17179611.536000] hostap_cs: CS_EVENT_CARD_INSERTION
Sep 22 23:07:53 localhost kernel: [17179611.536000] hostap_cs: setting Vcc=33 (from config)
Sep 22 23:07:53 localhost kernel: [17179611.536000] Checking CFTABLE_ENTRY 0x01 (default 0x01)
Sep 22 23:07:53 localhost kernel: [17179611.536000] IO window settings: cfg->io.nwin=1 dflt.io.nwin=1
Sep 22 23:07:53 localhost kernel: [17179611.536000] io->flags = 0x0046, io.base=0x0000, len=64
Sep 22 23:07:53 localhost kernel: [17179611.536000] hostap_cs: Registered netdevice wifi0
Sep 22 23:07:53 localhost kernel: [17179611.536000] wifi0: Interrupt, but dev not OK
Sep 22 23:07:53 localhost kernel: [17179611.576000] hostap_cs: index 0x01: Vcc 3.3, irq 3, io 0x0140-0x017f
Sep 22 23:07:53 localhost kernel: [17179611.772000] prism2_hw_init: initialized in 196 ms
Sep 22 23:07:53 localhost kernel: [17179611.772000] wifi0: NIC: id=0x801b v1.0.0
Sep 22 23:07:53 localhost kernel: [17179611.772000] wifi0: PRI: id=0x15 v1.1.1
Sep 22 23:07:53 localhost kernel: [17179611.772000] wifi0: STA: id=0x1f v1.8.4
Sep 22 23:07:53 localhost kernel: [17179611.772000] wifi0: Channel setting out of range (3)!
Sep 22 23:07:53 localhost kernel: [17179611.772000] wifi0: registered netdevice wlan0
Sep 22 23:07:53 localhost kernel: [17179612.428000] Adding 746980k swap on /dev/hda1. Priority:-1 extents:1 across:746980k
Sep 22 23:07:53 localhost kernel: [17179612.580000] wifi0: LinkStatus=2 (Disconnected)
Sep 22 23:07:53 localhost kernel: [17179612.580000] wifi0: LinkStatus: BSSID=44:44:44:44:44:44
Sep 22 23:07:53 localhost kernel: [17179612.688000] EXT3 FS on hda2, internal journal
Sep 22 23:07:53 localhost kernel: [17179612.956000] wifi0: LinkStatus=2 (Disconnected)
Sep 22 23:07:53 localhost kernel: [17179612.956000] wifi0: LinkStatus: BSSID=44:44:44:44:44:44
Sep 22 23:07:53 localhost kernel: [17179612.972000] wifi0: LinkStatus=2 (Disconnected)
Sep 22 23:07:53 localhost kernel: [17179612.972000] wifi0: LinkStatus: BSSID=44:44:44:44:44:44
Sep 22 23:07:53 localhost kernel: [17179612.984000] wlan0: Trying to join BSSID XX:XX:XX:XX:XX:XX
Sep 22 23:07:53 localhost kernel: [17179613.008000] wifi0: LinkStatus=1 (Connected)
Sep 22 23:07:53 localhost kernel: [17179613.008000] wifi0: LinkStatus: BSSID=XX:XX:XX:XX:XX:XX
Sep 22 23:07:53 localhost kernel: [17179613.120000] md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
Sep 22 23:07:53 localhost kernel: [17179613.120000] md: bitmap version 4.39
Sep 22 23:07:53 localhost kernel: [17179613.776000] wifi0: dropped unencrypted TX data frame (drop_unencrypted=1)
Sep 22 23:07:53 localhost kernel: [17179614.108000] ieee80211_crypt: registered algorithm 'TKIP'

[syslog edgy]
Sep 27 23:43:31 localhost kernel: [17184392.964000] hostap_cs: 0.4.4-kernel (Jouni Malinen <email address hidden>)
only ...

[towsonu2003 (towsonu2003)]

as per https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/63508/comments/4

[2hansen (bo2hansen)]

I dunno if this is the same problem as bug 63508, but maybe.

My WIFI was working in Edgy until the upgrade to:

[UPGRADE] fglrx-kernel-source 8.28.8+2.6.17.5-5 -> 8.28.8+2.6.17.5-6
[UPGRADE] linux-image-2.6.17-10-generic 2.6.17-10.24 -> 2.6.17-10.25
[UPGRADE] linux-libc-dev 2.6.17-10.24 -> 2.6.17-10.25
[UPGRADE] linux-restricted-modules-2.6.17-10-generic 2.6.17.5-5 -> 2.6.17.5-6
[UPGRADE] linux-restricted-modules-common 2.6.17.5-5 -> 2.6.17.5-6
(from /var/log/aptitude)

The later upgrade to 2.6.17-10.26 haven't changed it.

It seems that during boot a ifrename is tried invoked, but it fails. I dunno if this is of relevance, but my WIFI were previously "eth0" and now is "wlan0" (but recognised as a wired interface).

ifrename cannot be installed by itself "No candidate version found " (aptitude).

[Gérard Bigot (gerard-bigot)]

On 10/3/06, 2hansen <email address hidden> wrote:
>
> I dunno if this is the same problem as bug 63508, but maybe.
>
> My WIFI was working in Edgy until the upgrade to:
>
> [UPGRADE] fglrx-kernel-source 8.28.8+2.6.17.5-5 -> 8.28.8+2.6.17.5-6
> [UPGRADE] linux-image-2.6.17-10-generic 2.6.17-10.24 -> 2.6.17-10.25
> [UPGRADE] linux-libc-dev 2.6.17-10.24 -> 2.6.17-10.25
> [UPGRADE] linux-restricted-modules-2.6.17-10-generic 2.6.17.5-5 ->
> 2.6.17.5-6
> [UPGRADE] linux-restricted-modules-common 2.6.17.5-5 -> 2.6.17.5-6
> (from /var/log/aptitude)
>
> The later upgrade to 2.6.17-10.26 haven't changed it.
>
> It seems that during boot a ifrename is tried invoked, but it fails. I
> dunno if this is of relevance, but my WIFI were previously "eth0" and
> now is "wlan0" (but recognised as a wired interface).
>
> ifrename cannot be installed by itself "No candidate version found "
> (aptitude).
>

Yesterday after the upgrade and a reboot, I lost my orinoco controled Wifi
device. It's interface was eth2, but it was lost. Instead I found a wlan0.

I blacklisted prism2, rebooted again, everything went right again.

So I guess a change in wifi driver priority.

[Mark Florian (markrian)]

This bug means that no prism2 or similar devices will work out of the box, despite there being perfectly good drivers in the kernel, and are even loaded into memory. Therefore I think the importance of this bug should be pushed to high.

[Andrew Jorgensen (ajorg)]

I absolutely agree that this should be marked high priority. The prism2_ drivers don't even begin to support the wireless extensions and won't work at all out-of-the-box for most users. The hostap driver has long been regarded as the best driver for the prism 2 series chipsets and it's the only one that should be working with network-manager / wpa-supplicant (though it's not at the moment on Ubuntu - there's a bug on that somewhere).

The default driver for prism2 cards should be hostap.

[Andrew Jorgensen (ajorg)]

Bug #57146 is the bug I referred to in my previous comment.

[Tollef Fog Heen (tfheen)]

linux-source-2.6.17 (2.6.17-10.33) edgy; urgency=low

  * Fix build failure

  [2.6.17-10.32]

  * ia64: Fix merge error for CVE-2006-3741. Caused a FTBFS.
  * Re-add ipw2200 quiesce patch.
  * Revert "usb/unusual: Add Domain Tech as GO_SLOW".
  * general: Quieten some more messages.
  * prism2: Commented out devices from MODULE_DEV_TABLE that are supported by
    hostap.
    - Malone #62685
  * pcbios: Cherry pick fix for PCBIOS PCI probing:
    Upstream GIT-SHA: 954c0b7cd5b9aaa11fb67a0c011fcb5e5897385a
    - Malone #60231
  * sdhci: Cherry pick fix for some devices, avoid reset in certain cases.
    Upstream GIT-SHA: 8a4da1430f7f2a16df3be9c7b5d55ba4e75b708c
    - Malone #63553
  * ahci: Add Intel 2680 device.
    - Malone #64433
  * hdaps: Re-implement lost dapper patch for y-only axis swapping. Add X41 as
    y-only.
    - Malone #58742
  * Enable all V4L1 modules.
    - Malone #58742

 -- Ben Collins <email address hidden> Wed, 11 Oct 2006 17:05:07 -0400

[Pascal Vincent (pvincent00)]

Sorry but the bug is still present for me.

But i was wrong saying my card is a prism 2. It is in fact a prism 1 card (this is what orinoco_cs module report). Sorry for that.

The behavior is exactly the same. To resume :
- The "by default" loaded module is orinoco_cs. (same as in dapper)
- If i blacklist it, no module is automatically load for my card (in dapper, hostap_cs module was automatically load)
- if i manually load hostap_cs, my card is not seen, this means i only have
hostap_cs: 0.4.4-kernel (Jouni Malinen <email address hidden>) in my syslog.

Perhaps the bug is still present for prism 1 ?

I can do some more tests if necessary.

[towsonu2003 (towsonu2003)]

you might wanna open a new bug report for that?

[Andrew Jorgensen (ajorg)]

This doesn't appear to me to be fixed entirely. My card doesn't get prism2_cs anymore (prism2_cs doesn't even exist in 2.6.17-10.33! Was that supposed to happen?) but it still doesn't get hostap_cs. That bug is really Bug #41652 though.

[Matthew Garrett (mjg59)]

It's quite likely that hostap_cs is missing your card ids, or something. Can you provide the output of cardctl ident with your card plugged in?

[Andrew Jorgensen (ajorg)]

Matthew, I'll get you those numbers tomorrow but hostap_cs gets loaded when I insert the card just fine, it's just that orinoco_cs also gets loaded and it always wins. Unless I misunderstood this bug was going to be fixed by giving hostap_* higher priority than prism2_* and orinoco_*.

[Pascal Vincent (pvincent00)]

Here is the result of
pccardctl ident
Socket 0:
  no product info available
Socket 1:
  product info: "Wireless LAN", "11Mbps PC Card", "Version 01.02", ""
  manfid: 0x0156, 0x0002
  function: 6 (network)

Please note i am actually not totally sure if it is a PRISM 1 or 2 card

Here is orinoco syslog for information
Oct 13 21:47:41 localhost kernel: [17179773.256000] pcmcia: registering new device pcmcia1.0
Oct 13 21:47:41 localhost kernel: [17179773.520000] orinoco 0.15rc3 (David Gibson <email address hidden>, Pavel Roskin <email address hidden>, et al)
Oct 13 21:47:41 localhost kernel: [17179773.532000] orinoco_cs 0.15rc3 (David Gibson <email address hidden>, Pavel Roskin <email address hidden>, et al)
Oct 13 21:47:41 localhost kernel: [17179773.768000] eth1: Hardware identity 801b:0000:0001:0000
Oct 13 21:47:41 localhost kernel: [17179773.768000] eth1: Station identity 001f:0004:0001:0008
Oct 13 21:47:41 localhost kernel: [17179773.768000] eth1: Firmware determined as Intersil 1.8.4
Oct 13 21:47:41 localhost kernel: [17179773.768000] eth1: Ad-hoc demo mode supported
Oct 13 21:47:41 localhost kernel: [17179773.768000] eth1: IEEE standard IBSS ad-hoc mode supported
Oct 13 21:47:41 localhost kernel: [17179773.768000] eth1: WEP supported, 104-bit key
Oct 13 21:47:41 localhost kernel: [17179773.768000] eth1: MAC address XX:XX:XX:XX:XX:XX
Oct 13 21:47:41 localhost kernel: [17179773.768000] eth1: Station name "Prism I"
Oct 13 21:47:41 localhost kernel: [17179773.768000] eth1: ready
Oct 13 21:47:41 localhost kernel: [17179773.772000] eth1: index 0x01: , irq 3, io 0x0140-0x017f

[Joe Clifford (joeclifford)]

I am experiencing the same problems in an up-to-date edgy. Has the fix been released because the problem still exists on my machine? My wifi card worked well with the hostap drivers in dapper. My card details are similar to Pascal's above:

dmesg output:

orinoco 0.15rc3 (David Gibson <email address hidden>, Pavel Roskin <email address hidden>, et al)
[17179599.552000] orinoco_cs 0.15rc3 (David Gibson <email address hidden>, Pavel Roskin <email address hidden>, et al)
[17179599.792000] eth1: Hardware identity 800c:0000:0001:0000
[17179599.792000] eth1: Station identity 001f:0004:0001:0005
[17179599.792000] eth1: Firmware determined as Intersil 1.5.4
[17179599.792000] eth1: Ad-hoc demo mode supported
[17179599.792000] eth1: IEEE standard IBSS ad-hoc mode supported
[17179599.792000] eth1: WEP supported, 104-bit key
[17179599.792000] eth1: MAC address XX:XX:XX:XX:XX:XX
[17179599.792000] eth1: Station name "Prism I"
[17179599.792000] eth1: ready
[17179599.792000] eth1: index 0x01: , irq 3, io 0x2080-0x20bf

sudo pccardctl ident output:

Socket 0:
  product info: "Wireless LAN", "11Mbps PC Card", "Version 01.02", ""
  manfid: 0x0156, 0x0002
  function: 6 (network)

I tried adding the card to /etc/pcmcia/hostap_cs.conf after blacklisting the orinoco_cs module like this:

card "Generic 11Mbps WLAN PC Card"
   version "Wireless LAN", "11Mbps PC Card", "Version 01.02"
   manfid 0x0156, 0x0002
   bind "hostap_cs"

but it doesn't seem to work (because of new pcmcia system??). I also tried to compile the hostap drivers from the hostap-source package but it would not compile (maybe I should raise another ticket for this?)

[2hansen (bo2hansen)]

I just upgraded from Dapper to Edgy yesterday - and after reboot my wlan (prism2 card) was not working. However blacklisting orinoco_pci and prism2_pci in /etc/modprobe.d/blacklist seems to do the work for me - but an "automatic" solution would be preferable.

[Timo Aaltonen (tjaalton)]

I have a Thinkpad T23 with Prism 2.5 and I'm having similar problems like others (hostap_pci/prism2_pci/orinoco_pci all loaded), hence reopening the bug

[Jonathan Doda (jdoda)]

I just got bit by this as well. My prism2 card was working fine in dapper using the orinoco drivers. I upgraded to edgy, and the card didn't work at all. I blacklisted prism2_pci, and now it works again.

[Colin Watson (cjwatson)]

I'm not entirely sure what's going on here, but it might be an edgy-updates candidate; Ben, please change if appropriate.

[Michael R. Head (burner)]

The problem is that (at least on my system) hostap_pci, prism2_pci, and orinoco_pci are all loaded (by udev or hotplug or discover or whatever is detecting hardware and loading drivers these days) and attempt to control my hardware. In previous releases, prism2_pci wasn't built, so there was only a conflict between hostap_pci and orinoco_pci. I believe the hostap driver was coded so that it would back off and let orinoco_pci handle the hardware, or at any rate, this case as solved.

In edgy, the prism2_pci driver is now being built. It thinks it can handle my hardware, but it can't. What's more, when it is loaded by udev/hotplug, it prevents the orinoco_pci from taking control, so wireless doesn't work unless I either manually unload all the drivers and reload the orinoco_pci driver, or unless I tell udev/hotplug not to load prism2_pci driver via a blacklist file entry.

I think a lot of middle-aged laptops (Thinkpad T30 and others from the ~2002 timeframe) used similar minipci hardware. Unless the users know about this bug, they'll probably assume Ubuntu no longer supports it.

Too bad this had to be pushed to the edgy-updates (though I understand the time constraints), because there will be a class of users that install edgy and may not be able to connect to the net (wirelessly) to get the update without config file tweaking.

Still, thanks for looking at this Colin.

[Michael R. Head (burner)]

Blah, I thought this was a different bug. I really jumped the gun on my response.

[2hansen (bo2hansen)]

As mentioned above ( https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/62685/comments/15 ) the blacklisting does the trick for me. However, after longer periods in suspend mode the WLAN is somehow disabled. I have to "sudo modprobe -r hostap_pci && sudo modprobe hostap_pci to make it work again. This problem was not present in Dapper. (I am on an Sony Vaio PCG-V505AP).

[Joe Clifford (joeclifford)]

I would just like to add that I also tried the 386 kernel in edgy (I used the generic one in my previous post) and the same problem exists.
It seems there are two separate problems detailed in this bug report or am I wrong?
The initial report is in regards to the pcmcia hostap drivers not working at all which is the problem I am having. Later posts regard hostap pci drivers which seem to work (sometimes?) if other pci wifi drivers are blacklisted. Is the source of these problems the same?
I would love to see the hostap_cs driver working in edgy. Is there anything I can do to help. I have time to do testing if anyone can explain what I need to do.

[Robert Knight (robertknight)]

I can confirm this bug on an IBM Thinkpad X30 when booting from the Edgy LiveCD.

Initially my wireless interface did not show up at all. Unloading hostap_pci, prism2_pci, and orinoco_pci then reloading orinoco_pci fixed the problem.

[nuku (nuku)]

Some quick googling revealed:
http://lists.infradead.org/pipermail/linux-pcmcia/2006-February/003298.html

The problem is, that the pcmcia ids are NOT unique, since some hermes based cards and prism based cards share the 0x0156 / 0x0002 .
The hermes based cards are incompatible with the hostap driver and hence the patch to detect cards with "Intersil" in it only.

Debian reverted the patch as it seems (Bug #358656):
http://lists.debian.org/debian-kernel/2006/03/msg00979.html

This is clearly an upstream bug in the hostap kernel module. So please make sure you have got a prism based card with this ID and send the pccardctl ident output to the linux-pcmcia list so the appropriate string based matches get extended.
I guess it's not that easy to make a generic fix for this as one has to determine if the card is hermes/prism based while probing.

An simple workaround for those having some prism based cards with this particular pcmcia id would be to apply the debian patch / revert the upstream patch by building a custom kernel.
Another side note (that should probably go to an extra bug report): The hostap-source package is not usable as 1) It's in the kernel tree now 2) It's based on an old kernel makefile structure....

Conclusion: For those with prism based cards, reverting the patch for the pcmcia strings would fix this on the other hand it would break things for people having an hermes based card.
Proposed solution: Add correct string matchings for more cards (could easily be done as ubuntu patch) or do a real fix of detection code for this (which should probably discussed on linux kernel list).

[Pascal Vincent (pvincent00)]

Any news on this front ? It would be awesome if my prism card can work again for Feisty (i don't want to stay in dapper). I can help with testing if needed, but i can't help on nuku's proposed ideas ...

[Timo Aaltonen (tjaalton)]

I will test this on feisty, soon.

[Kate Ward (kate-ward)]

Just as an aside, I am having similar problems with a PCMCIA 3G card. When I first installed Edgy, I was able to access the card with AT commands, but I am no longer able to. It could be related.

[Timo Aaltonen (tjaalton)]

on my Thinkpad T23 all the modules (prism2_pci, orinoco_pci, hostap_pci) are loaded, and prism2_pci seems to be the one controlling the device (ie. loaded first).

[Michael R. Head (burner)]

This appears to be fixed for me in feisty. My T30's built-in minipci orinoco card can connect to my accesspoint with hostap. I'm posting this comment over said connection.

[Brunellus (luigi12081)]

which feisty kernel fixes the problem?

[Michael R. Head (burner)]

I'm using whatever linux-generic pulls in. I don't know at which point it was fixed, since it worked as soon as I finished the upgrade and rebooted..

[Timo Aaltonen (tjaalton)]

If I blacklist prism2_pci and orinoco_pci all is well. Network-manager works with hostap_pci and even supports encryption

[Michael R. Head (burner)]

Timo, are you talking about edgy or feisty?

[Michael R. Head (burner)]

BTW: See bug #41652 for info about blacklisting orinoco_* (before dapper you didn't have to)

See bug #63989 for another related bug about the prism2 driver blocking the hostap driver.

[Timo Aaltonen (tjaalton)]

I'm running feisty. I'll check those other bugs, thanks.

[Joe Clifford (joeclifford)]

I have just installed a basic command-line version of feisty herd 4 on a usb pen drive. The kernel version is 2.6.20 BUT the bug is still there! My PCMCIA wireless card picks up the orinoco_cs driver which works (albeit only up to channel 11 though this may be hardware restriction). If I blacklist the orinoco_cs driver and modprobe the hostap_cs driver it does not associate with my card at all.

Does any one know if the solution is as simple as Nuku suggests above? ie write an ubuntu patch to include the correct pcmcia IDs? If it is I could have a go if someone can tell me which kernel source file to patch (kernel/drivers/net/wireless/hostap/hostap_cs)?? though I'm not sure where to get the different pcmcia IDs from.

I would like to have this fixed mainly so that I can use both my wireless cards. I have on orinoco usb card which I use most of the time. It needs to have the drivers compiled manually from CVS but they conflict with the built in kernel orinoco drivers. This means when I plug in my pcmcia wireless card even the orinoco_cs driver does not work now :S

Is the pursuit of fixing this bug futile or pointless now? I'm not sure if the 0.15 orinoco drivers in the kernel support monitor mode, wpa_supplicant and gnome network manager as well as hostap did/does. If it does then perhaps fixing this bug is not needed any more..... my two cents worth.....

[nuku (nuku)]

To find the pcmcia IDs you can "lspcmcia -v" (in pcmciautils). Given you have a prism based and not a hermes based card, it should be possible to add the IDs to drivers/net/wireless/hostap/hostap_cs.c. Search for PCMCIA_DEVICE_MANF_CARD.
You may want to check if the IDs are already present and are refined by a string based match (.._PROD_ID1..) as those IDs are conflicting with other incompatible cards with the same ID and finally add the appropiate full match (from your "lspcmcia -v" output).

[Michael R. Head (burner)]

Joe, you should check out bug #63989

Are you sure that the prism2_cs driver isn't taking over your card, thus preventing hostap_cs from loading?

[Pascal Vincent (pvincent00)]

I tried yesterday on feisty, the bug is still present for my card.
How can i help ?

[nuku (nuku)]

...and also please keep in mind, that there are (at least) TWO bugs:
1) The hostap_cs module is blocked by another module (like prism2_cs/orinoco_cs)
2) The hostap_cs failes to probe a card (as of a missing pcmcia id/string)

[Joe Clifford (joeclifford)]

Hurray! I have just patched and compiled the hostap_cs driver and it works! I don't know (yet) how to write a patch but this is what I did:

  lspcmcia -v:

Socket 0 Bridge: [yenta_cardbus] (bus ID: 0000:02:03.0)
        Configuration: state: on ready: unknown
                        Voltage: 3.3V Vcc: 3.3V Vpp: 0.0V
Socket 0 Device 0: [hostap_cs] (bus ID: 0.0)
        Configuration: state: on
        Product Name: Wireless LAN 11Mbps PC Card Version 01.02
        Identification: manf_id: 0x0156 card_id: 0x0002
                        function: 6 (network)
                        prod_id(1): "Wireless LAN" (0x4b8870ff)
                        prod_id(2): "11Mbps PC Card" (0x70e946d1)
                        prod_id(3): "Version 01.02" (0x4b74baa0)
                        prod_id(4): --- (---)

So from this I added in the kernel source drivers/net/wireless/hostap/hostap_cs.c at line 861 this:

  PCMCIA_DEVICE_PROD_ID123(
  "Wireless LAN", "11Mbps PC Card", "Version 01.02",
  0x4b8870ff, 0x70e946d1, 0x4b74baa0),

in between the other wireless card definitions.

Then:
   make-kpkg clean
   make-kpkg --initrd kernel_image
in /usr/src/linux

BUT instead of installing the whole kernel I just compiled (the version number was different - linux-image-2.6.17.14-ubuntu1_2.6.17.14-ubuntu1-10.00.Custom_i386.deb) I just copied over the hostap_cs.ko module from drivers/net/wireless/hostap to the running kernel drivers directory to test it.

I then did:
sudo update-modules
sudo depmod -ae

I then blacklisted the orinoco and orinoco_cs drivers in /etc/modprob.d/blacklist and made sure none of the wireless drivers were currently loaded by sudo modprobe -r etc, inserted my pcmcia card and hey presto!

Also, I was not affected by prism2_cs trying to take over the card.

This fix should work for me and for Pascal but I don't know if it will for others. Pascal, if you want I have attached the hostap_cs.ko module. Backup the original first before you copy it over! Very hacky I know but it works for now....

[Joe Clifford (joeclifford)]

Well it seems one thing leads to another. If I boot my laptop with the wireless pcmcia card inserted then it hard locks the machine about half way through the boot process. Booting into single mode shows me this just after the kernel registers the hostap driver:

  Unexpected IRQ trap in vector 30
or sometimes
  Unexpected IRQ trap in vector b0

I tried various kernel parameters in various combinations including lapic, noapic, pci=routeirq, irqpoll, pci=assign-busses, nosmp but none had any effect.

The wireless card will work however if I boot up with it ejected and then insert it after I reach the log in stage for gnome!?

Perhaps this is something to do with differing version magic numbers in the kernel modules hostap.ko and hostap_cs.ko or something to do with the hostap drivers not playing nice with an smp kernel..... I will try to recompile a module for the running kernel and I'm working on a patch that I will post here later.
I am still running edgy eft by the way, kernel 2.6.17-11-generic.

[Michael R. Head (burner)]

Just reifying the fact that it's fixed in feisty.

[Joe Clifford (joeclifford)]

I have succeeded in writing a patch using diff but realised afterwards that I had done it on the already patched ubuntu linux-source package from the repositories. I don't know but I think I should have done it to the pristine kernel sources so that the patch can be added to the ubuntu kernel patches. Could someone advise me on this?

I also tried the feisty kernel (only the kernel - used everything else from edgy) from herd 4 and the bug still exists. I tried recompiling the feisty kernel with my hostap_cs patch but booting with the card inserted hard locked the machine similar to the edgy kernel so I tried inserting the card after booting and logging in but this also hard locked the machine. I also tried single boot mode to the same effect. I am wondering whether it is something to do with the new upstart init system or a kernel IRQ allocation problem. Any ideas anyone?

[Joe Clifford (joeclifford)]

I have solved the hard lock problem I was experiencing above. I am now running feisty 7.04 beta with the low-latency kernel. I assume the same effect for the generic kernel. I patched the hostap_cs module in the kernel source as described above first and rebuilt the kernel. My wireless card worked the same as in edgy 6.10 by inserting the card after reaching the Gnome log in prompt (it locked the computer if it was already inserted at boot time). To diagnose the lock up problem I booted into single mode with the card removed. I then removed all pcmcia related modules, inserted the wireless card and modprobe'd each pcmcia related module in turn to determine which was causing problems. The yenta_socket module was the source so I examined the module information using "modinfo yenta_socket". I tried each module parameter in turn. I have found that the "isa_probe=no" yenta_socket parameter solves the problem so I added it to /etc/modprobe.d/options like so:

  #yenta_socket pcmcia startup parameter to stop kernel hardlock
  options yenta_socket isa_probe=no

then

  depmod -ae

I then rebooted with the card inserted and it works properly; I can log in to Gnome and the wireless card works well. I have however found that Gnome Network manager does not seem to work with the hostap_cs module so I have disabled it and use wifi-radar instead. Also, iwconfig seems to add a strange 'other' character to my wireless card's registered ESSID though this does not cause any problems:

Access Point ESSID is "observer" but iwconfig shows an extra "b" or sometimes "?" at the end like this:

  wifi0 IEEE 802.11b ESSID:"observerb" Nickname:"observer"
          Mode:Managed Frequency:2.452 GHz Access Point: ##:##:##:##:##:##
          Bit Rate:1 Mb/s Sensitivity=1/3
          Retry limit:8 RTS thr:off Fragment thr:off
          Power Management:off

  eth1 IEEE 802.11b ESSID:"observerb" Nickname:"observer"
          Mode:Managed Frequency:2.452 GHz Access Point: ##:##:##:##:##:##
          Bit Rate:1 Mb/s Sensitivity=1/3
          Retry limit:8 RTS thr:off Fragment thr:off
          Power Management:off
          Link Quality=38/70 Signal level=-58 dBm Noise level=-97 dBm
          Rx invalid nwid:0 Rx invalid crypt:48 Rx invalid frag:0
          Tx excessive retries:74 Invalid misc:152 Missed beacon:0

hostap-utils shows that this card uses a Prism 2.5 chipset so I think the card definitions should be added to the hostap_cs source file:

  sudo hostap_diag -p eth1
  Host AP driver diagnostics information for 'eth1'

  NICID: id=0x800c v1.0.0 (PRISM II (2.5) PCMCIA (SST parallel flash))
  PRIID: id=0x0015 v1.1.1
  STAID: id=0x001f v1.7.4 (station firmware)

  Production Data Area (PDA)

  Could not read wlan PDA. This requires PRISM2_DOWNLOAD_SUPPORT definition for the kernel driver.

Could someone let me know whether I should provide a patch to the pristine unpatched ubuntu kernel source or to the already patched ubuntu kernel source. Thanks....

[Sitsofe Wheeler (sitsofe)]

There is also the mention of a missing device id over in Bug #97172

[Stefan Grotehans (stefan-grotehans)]

I observed a similar behavior after upgrading my ThinkPad from edgy to feisty:
My orinoco gold pcmcia card stopped working.
Strange enough it got irq 4 assigned which was supposed to be reserved for irda.

The solution was to disable in yenta_socket the probing of isa irqs.
In the options file in modprobe.d I entered:
options yenta_socket isa-probe=0

After that yenta_socket got IRQ 11 and the orinoco card worked again.

Stefan

[Caroline Ford (secretlondon)]

Setting gutsy to invalid. Person who added gutsy kernel wasn't running gutsy and all reports say fixed in feisty. if it really exists in gutsy (and hardy) then please reopen.

[Joe Clifford (joeclifford)]

Have re-opened this bug to reflect that it still affects kernel 2.6.24-19 in hardy.

[Joe Clifford (joeclifford)]

At least I have tried to re-open the bug but launchpad won't let me put linux-source-2.6.24 as the affected package and reverts to linux only....

A fix has been released as detailed by me in the bug comments; all that is required is the correct and specific product ID information to be put into the hostap_cs source code.

Quote:
"So from this I added in the kernel source drivers/net/wireless/hostap/hostap_cs.c at line 861 this:

  PCMCIA_DEVICE_PROD_ID123(
  "Wireless LAN", "11Mbps PC Card", "Version 01.02",
  0x4b8870ff, 0x70e946d1, 0x4b74baa0),

in between the other wireless card definitions."

This fixes the original reporter's problem and mine because we both have the same card. The patch above is specific to that card. Unfortunately, if this patch is applied, users of this exact card will need to blacklist orinoco_cs because the orinoco source code contains a generic entry for manf_id: 0x0156 card_id: 0x0002 which is the same for the card in question. It seems that some of the cards identified by these ids may not all be prism2 based cards like mine.

It would be helpful to have this fixed upstream so that users of this card have the advantage of being able to use hostap drivers and the prism2 wireless access point facility.
Do I report to the maintainer of the hostap code directly? Also, should I start a new bug that is specifically titled "Missing device product IDs in hostap driver" like in Bug #97172?

[Manoj Iyer (manjo)]

Unfortunately it seems this bug is still an issue. Can you confirm this issue exists with the most recent Jaunty Jackalope 9.04 release - http://www.ubuntu.com/news/ubuntu-9.04-desktop . Please let us know your results. Thanks.

[Joe Clifford (joeclifford)]

This bug never got fixed as far as I am aware but would have been fixed methinks if the product ID information that I provided had been forwarded upstream to the hostap_cs maintainer. The original report was filed more than 3 years ago (not by me though I had a vested interest) and I for one have moved on and am now using more modern hardware and so I am unable to test the original set up with the most up to date distribution. Surely after such a length of time the launchpad janitor should be closing these old bugs due to dis-interest?