Bug 138292 - [zyd] [usb8] "zyd0: device timeout" with ZyXEL G-202
Summary: [zyd] [usb8] "zyd0: device timeout" with ZyXEL G-202
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 8.0-BETA3
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-usb (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-08-29 00:10 UTC by Samuel Boivie
Modified: 2018-05-28 19:46 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Samuel Boivie 2009-08-29 00:10:05 UTC
The problem appeared after Weongyo Jeong made the device, ZyXEL G-202,
work in May. The device works fine for a while after being configured
and then suddenly stops with "kernel: zyd0: device timeout" in
/var/less/messages. A soft reboot appears not to help, the device will
still not work after reboot. Cutting power will make it work again.

from dmesg:
zyd0: <ZyDAS ZyXEL G-202, rev 2.00/48.10, addr 2> on usbus4

How-To-Repeat: Just using the device for a while, eventually it will fail. A csup of
ports appears to trigger the timeout quickly and reliably (haven't
failed to reproduce timeout yet with 5+ tries).
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2009-08-29 14:45:10 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-net

Over to maintainer(s).
Comment 2 pprocacci 2009-09-01 06:02:58 UTC
I've got the same problem here for what it's worth.

zyd0: <Belkin USB2.0 WLAN, rev 2.00/48.10, addr 2> on usbus0

This is Freebsd 9.0-Current.

Same timeout problems.  (was trying to download/install fluxbox)

This message may contain confidential or privileged information.  If you ar=
e not the intended recipient, please advise us immediately and delete this =
message.  See http://www.datapipe.com/emaildisclaimer.aspx for further info=
rmation on confidentiality and the risks of non-secure electronic communica=
tion. If you cannot access these links, please notify us by reply message a=
nd we will send the contents to you.
Comment 3 Weongyo Jeong freebsd_committer freebsd_triage 2009-09-08 21:39:37 UTC
Responsible Changed
From-To: freebsd-net->weongyo

grap.
Comment 4 jintxo 2010-08-30 09:55:44 UTC
  Hello,

Just wanted to note that I have the exact some behaviour with SMC 
EzConnect g (vendor 0x083a product 0x4505) on FreeBSD 8.1

Conects fine, works for a while and then I get "zyd0: device timeout" 
and must unplug the USB stick and plug it back in to get it to work.

usbconfig -dugen1.2 power_off

and then

usbconfig -dugen1.2 power_on

does not solve the issue, I have to actually unplug it, which makes me 
thing the hardware itself is "locking up" sort of.

During normal functioning of the device I am getting "zyd0: unsupported 
rate 0" all the time in dmesg, although it works fine until the timeout 
message appears.

>  [root@peqs ~]# usbconfig -d 1.2 dump_device_desc
>  ugen1.2: <USB2.0 WLAN SMC> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps)
>  pwr=ON
>
>    bLength = 0x0012
>    bDescriptorType = 0x0001
>    bcdUSB = 0x0200
>    bDeviceClass = 0x00ff
>    bDeviceSubClass = 0x00ff
>    bDeviceProtocol = 0x00ff
>    bMaxPacketSize0 = 0x0040
>    idVendor = 0x083a
>    idProduct = *0x4505*
>    bcdDevice = 0x4810
>    iManufacturer = 0x0010 <SMC>
>    iProduct = 0x0020 <USB2.0 WLAN>
>    iSerialNumber = 0x0000 <no string>
>    bNumConfigurations = 0x0001

If I can help in some way, please let me know. I am unable to "dive in" 
to the code but am happy to do any testing/patching necessary.

Cedric
Comment 5 John Merryweather Cooper 2012-06-08 00:42:12 UTC
I am getting identical behavior from a Belkin Wireless Adapter on 
9.0-STABLE:

Copyright (c) 1992-2012 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
         The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-STABLE #4: Thu May 31 07:12:27 CDT 2012
     root@g7-HP.borgsdemons.com:/usr/obj/usr/src/sys/G7 amd64
CPU: AMD A4-3305M APU with Radeon(tm) HD Graphics (1896.59-MHz K8-class CPU)
   Origin = "AuthenticAMD"  Id = 0x300f10  Family = 12  Model = 1  
Stepping = 0
   
Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
   Features2=0x802009<SSE3,MON,CX16,POPCNT>
   AMD 
Features=0xee500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow!>
   AMD 
Features2=0x37ff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT>
   TSC: P-state invariant, performance statistics
real memory  = 5368709120 (5120 MB)
avail memory = 4596224000 (4383 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: <HP     INSYDE >
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
  cpu0 (BSP): APIC ID:  0
  cpu1 (AP): APIC ID:  1
ioapic0: Changing APIC ID to 4
ioapic0 <Version 2.1> irqs 0-23 on motherboard

* * *

ugen1.2: <Belkin> at usbus1
zyd0: <Belkin USB2.0 WLAN, rev 2.00/48.10, addr 2> on usbus1

Power cycling (pulling the dongle out and pushing it back in) gets 
things started again, but it is a pain.

--
John M. Cooper
Comment 6 Mark Linimon freebsd_committer freebsd_triage 2013-07-03 01:50:32 UTC
State Changed
From-To: open->open

commit bit has been taken in for safekeeping. 


Comment 7 Mark Linimon freebsd_committer freebsd_triage 2013-07-03 01:50:32 UTC
Responsible Changed
From-To: weongyo->freebsd-usb
Comment 8 Yuri Victorovich freebsd_committer freebsd_triage 2016-10-10 03:09:39 UTC
I am getting the same problem om 10.3 amd64 with Belkin WiFi NIC:
> zyd0: <Belkin USB2.0 WLAN, rev 2.00/48.10, addr 3> on usbus3
> zyd0: HMAC ZD1211B, FW 47.25, RF AL2230 S1, PA0 LED 0 BE0 NP1 Gain1 F0
Comment 9 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:46:41 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.