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.
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).
Over to maintainer(s).
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.
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
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
> [root@peqs ~]# usbconfig -d 1.2 dump_device_desc
> ugen1.2: <USB2.0 WLAN SMC> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps)
> 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.
I am getting identical behavior from a Belkin Wireless Adapter on
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
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
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
commit bit has been taken in for safekeeping.
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
For bugs that match the following
- Status Is In progress
- Untouched since 2018-01-01.
- Affects Base System OR Documentation
Reset to open status.
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.