ZyDAS USB zd1211rw wireless key usually not recognised by kernel

Bug #154787 reported by Oisín Mac Fhearaí
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Incomplete
Undecided
Unassigned
linux-source-2.6.22 (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

Binary package hint: linux-source-2.6.22

This was happening since the last Feisty kernel (2.6.20?) and still in Gutsy 2.6.22-14-386.
The symptoms have worsened somewhat over time which is quite disturbing, but I don't think it's a hardware problem as I tried the adapter in a Windows XP machine while my linux box wasn't recognising it, and it was configured immediately.

When I insert the adapter, I get the following messages in dmesg repeatedly:
[ 80.666307] usb 4-7: new high speed USB device using ehci_hcd and address 34
[ 81.529673] usb 4-7: new high speed USB device using ehci_hcd and address 38
[ 81.790249] ehci_hcd 0000:00:1d.7: port 7 reset error -110
[ 81.790259] hub 4-0:1.0: hub_port_status failed (err = -32)

And sometimes (this was probably for a different port, but it doesn't matter which one I use:
[ 317.075770] hub 4-1:1.0: Cannot enable port 3. Maybe the USB cable is bad?
(a few times).

No device entry shows up in lsusb.

The following script seems to work around it _sometimes_, but it appears nondeterministic to me - I might try it 20 times before the card suddenly works.
"rmmod zd1211rw && rmmod ehci_hcd && modprobe ehci_hcd && sleep 1 && modprobe ehci_hcd && modprobe zd1211rw && sleep 1 && dmesg|tail"

Eventually a successful case will look like:
[ 978.751143] usb 4-1.3: new high speed USB device using ehci_hcd and address 5
[ 978.843818] usb 4-1.3: configuration #1 chosen from 1 choice
[ 978.947003] usb 4-1.3: reset high speed USB device using ehci_hcd and address 5
[ 980.488771] zd1211rw 4-1.3:1.0: firmware version 4725
[ 980.544735] zd1211rw 4-1.3:1.0: zd1211b chip 0ace:1215 v4810 high 00-11-e2 AL2230_RF pa0 ---N-
[ 980.547692] zd1211rw 4-1.3:1.0: eth1
[ 980.547956] usbcore: registered new interface driver zd1211rw
[ 981.026493] ADDRCONF(NETDEV_UP): eth1: link is not ready

(but the link will be ready).

thanks,
Oisín

Revision history for this message
Dennis M (low-entropy-states) wrote :

I am having the same problem. Likewise, it started with the final pre-Gutsy Feisty kernel, and is still present in Gutsy.

My wireless network card was immediately recognized by a friend's Gutsy installation, so there is clearly scope to fix this problem with the existing kernel.

I've considered using the zd1211rw-mac80211 module, but it is not found by modprobe on my system and I could find no user-level instructions on how to make it available.

Regards,

Dennis

Revision history for this message
Oisín Mac Fhearaí (denpashogai) wrote :

That's interesting, I didn't know they were replacing the 802.11 stack... but I don't see why they'd rewrite any of the parts of code that deal with the USB end of things really - that being the point of modularity.
That said, I don't know much at all about USB and how it's handled in-kernel... I see from lsmod that the "usbcore" module is used by (among many others) zd1211rw, and although ehci_hcd is used by nothing, it clearly performs some vital functionality since removing it stops my USB keyboard from working.

I get the feeling that the problems I mentioned are related to usbcore and/or ehci_hcd, from the syslog messages. For example, the problem reappears after suspend and resume, with the following messages (I have to remove and reinsert the wireless stick):
[ 10.117198] hub 4-1:1.0: Cannot enable port 3. Maybe the USB cable is bad?
[ 13.470407] hub 4-1:1.0: Cannot enable port 3. Maybe the USB cable is bad?
[ 16.868962] hub 4-1:1.0: Cannot enable port 3. Maybe the USB cable is bad?
[ 19.822716] hub 4-1:1.0: Cannot enable port 3. Maybe the USB cable is bad?
[ 19.823960] usb 4-1.3: USB disconnect, address 5
[ 19.957738] usb 4-1.3: USB control request for firmware upload failed. Error number -19
[ 19.957811] usb 4-1.3: Could not upload firmware code uph. Error number -19
[ 19.957882] zd1211rw 4-1.3:1.0: couldn't load firmware. Error number -19

regards,
Oisín

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

This seems to be a duplicate of bug 88746. Care to try the workaround mentioned there? (ie don't reload the ehci_hcd module). Let us know if this helps. Thanks!

Changed in linux-source-2.6.22:
status: New → Incomplete
Revision history for this message
Oisín Mac Fhearaí (denpashogai) wrote :

There's a few workarounds listed there, and certainly some updates since I haven't booted that system for quite a while now (running a MacBook now... :)).

I'll try them later and see how it goes.

Thanks!
Oisín

Revision history for this message
Dennis M (low-entropy-states) wrote :

Using uhci_hcd rather than ehci_hcd does indeed work, but it's not an ideal solution.

Thanks,

Dennis

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

HI Dennis,

I agree this is not a proper solution but a workaround to get thing running for you. My main concern was distinguishing if this report is indeed a duplicate of bug 88746. As such it should be marked appropriately. I'll go ahead and mark this as a duplicate of that report. Thanks.

Revision history for this message
Launchpad Janitor (janitor) wrote : This bug is now reported against the 'linux' package

Beginning with the Hardy Heron 8.04 development cycle, all open Ubuntu kernel bugs need to be reported against the "linux" kernel package. We are automatically migrating this bug to the new "linux" package. However, development has already began for the upcoming Intrepid Ibex 8.10 release. It would be helpful if you could test the upcoming release and verify if this is still an issue - http://www.ubuntu.com/testing . If the issue still exists, please update this report by changing the Status of the "linux" task from "Incomplete" to "New". We appreciate your patience and understanding as we make this transition. Thanks!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.