Not out of the box, firstly you have to install it from opkg repository.

This issue is marked 'solved', but as far as I can verify the issue still exists when the AR9331 is set up as station looking for AP's. I'm talking specificly about the issue of the USB 'randomly' freezing when running full speed instead of high speed.

Adding a hardware USB 2.0 hub is not a possible workaround in my situation for BOM cost reasons.

Has anyone since tried/succeeded 'fixing' this driver for the unassociated-STA part? This could be something we can look into.

I tinkered for a bit on this. I ended-up concluding that the unassociated-STA is autonomously repeatedly channel-scanning without software intervention, thus there's no hook for the macro that resets the USB PLL. Of course, I don't really know the details of the AR wlan interface and may be mistaken.

Microchip/SMSC USB2412 works well too!

Try to watch the register 0xb8116c84 and 0xb8116c88,check the value before and after wlan reset,and restore the value back when do wlan reset to workaround this "wlan vs usb" bug.There are many hang check in ath9k driver,and also current the ath9k driver is not stable enough for use,it's wlan reset very often,though nbd fix some deeply bug in the recently svn change,we still need dig the ath9k source code,the ath9k is not stable enough to do the AA formal release...
I get some info from atheros SDK,but i'm not test it and don't make sure it's work for this topic.
_________________
vrati блиндирани врати врати за апартаменти входни врати метални врати метални решетки метални решетки цени

(Last edited by gloriatorios on 13 Dec 2014, 10:12)

FYI I had problems with a USB-serial adapter yesterday. The following kernel message was given.

[  382.210000] ftdi_sio ttyUSB0: failed to get modem status: -145

The USB device failed and I had to reset the USB to get it to work again.

My setup was a TP-Link TL-WR710N with a cheap Sabernet HB-UMLS 4-port USB hub and three USB-to-serial adapters on the hub. Only one was being used at the time.

OpenWRT build was r45574.

The host had Wifi on, in client mode, and unassociated with an AP. So, it was probably scanning.

It only happened once. After I reset the USB interface via the GPIO, it worked okay for the rest of the hour I needed it.

So, I am guessing this issue is not fully fixed, and it is possible for this problem to occur on a USB2.

My experience with about 1000 devices running a custom ATmega16U4-based USB ACM device via a Microchip/SMSC USB2412 hub is that there are no problems with USB2. Same USB ACM device hangs in ~30 seconds without the hub.

I'd tend to suspect the USB-serial error you saw is related to the USB-serial device itself.

@jmomo: does you hub enumerate as a full-speed or high-speed device? Please check dmseg.

Also, can you turn off WiFi for test purposes and see if the problem still occurs?

Good questions.

In the log below, I just now ssh'd out to the unit which I posted about above and turned off the USB interface on, after having shut it off for a few seconds:

Wed May 20 00:28:58 2015 kern.info kernel: [633000.300000] usb 1-1: new high-speed USB device number 34 using ehci-platform
Wed May 20 00:28:58 2015 kern.info kernel: [633000.450000] hub 1-1:1.0: USB hub found
Wed May 20 00:28:58 2015 kern.info kernel: [633000.450000] hub 1-1:1.0: 4 ports detected
Wed May 20 00:28:58 2015 kern.info kernel: [633000.750000] usb 1-1.1: new full-speed USB device number 35 using ehci-platform
Wed May 20 00:28:58 2015 kern.info kernel: [633000.860000] pl2303 1-1.1:1.0: pl2303 converter detected
Wed May 20 00:28:58 2015 kern.info kernel: [633000.860000] usb 1-1.1: pl2303 converter now attached to ttyUSB0
Wed May 20 00:28:58 2015 kern.info kernel: [633000.950000] usb 1-1.3: new full-speed USB device number 36 using ehci-platform
Wed May 20 00:28:59 2015 kern.info kernel: [633001.080000] pl2303 1-1.3:1.0: pl2303 converter detected
Wed May 20 00:28:59 2015 kern.info kernel: [633001.080000] usb 1-1.3: pl2303 converter now attached to ttyUSB1
Wed May 20 00:28:59 2015 kern.info kernel: [633001.180000] usb 1-1.4: new full-speed USB device number 37 using ehci-platform
Wed May 20 00:28:59 2015 kern.info kernel: [633001.320000] ftdi_sio 1-1.4:1.0: FTDI USB Serial Device converter detected
Wed May 20 00:28:59 2015 kern.info kernel: [633001.320000] usb 1-1.4: Detected FT232RL
Wed May 20 00:28:59 2015 kern.info kernel: [633001.320000] usb 1-1.4: FTDI USB Serial Device converter now attached to ttyUSB2

You can see that the hub is doing USB2 and then the three serial devices are USB1.

To the best of my knowledge the hub has always negotiated as UBS2/High-speed, but if the problem happens again, I will be sure to look through the dmesg log to find out what the USB hub was negotiated at before the problems.

I can't answer the question regarding turning the WIFI off because the issue happens on a very intermittent basis and it's really hard to reproduce. I regret that I don't have the time to help test this in a more scientific way.

Sorry for being slow on reply to my post. I was not subscribed to the topic. I am now.

That is possible.

I don't recall if I tested the other USB serial devices after that one failed or not. I suspect I just reset the USB interface and just moved on. I was dealing with a network outage at the time, so troubleshooting this USB issue wasn't my priority.

Oh wow.

I wrote the previous posts maybe an hour ago. I had left my device sitting there doing not much and didn't really think about it.

I just came back to it. I had a logread -f going in one terminal and was connected to a serial interface on the other via screen.

It spewed out a ton of USB errors. In fact, more than 32000 lines worth of them, overrunning my terminal scrollback buffer. So, I don't actually know what the errors started with.

Here's what I've got:

Wed May 20 01:15:30 2015 kern.err kernel: [635792.370000] usb 1-1: clear tt 1 (9233) error -71
Wed May 20 01:15:30 2015 kern.err kernel: [635792.380000] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71
Wed May 20 01:15:30 2015 kern.err kernel: [635792.380000] usb 1-1: clear tt 1 (9243) error -71
Wed May 20 01:15:30 2015 kern.err kernel: [635792.380000] pl2303 ttyUSB1: usb_serial_generic_read_bulk_callback - nonzero urb status: -71
Wed May 20 01:15:30 2015 kern.err kernel: [635792.380000] usb 1-1: clear tt 1 (9233) error -71
Wed May 20 01:15:30 2015 kern.err kernel: [635792.390000] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71
Wed May 20 01:15:30 2015 kern.err kernel: [635792.390000] usb 1-1: clear tt 1 (9243) error -71
Wed May 20 01:15:30 2015 kern.err kernel: [635792.390000] pl2303 ttyUSB1: usb_serial_generic_read_bulk_callback - nonzero urb status: -71
Wed May 20 01:15:30 2015 kern.err kernel: [635792.390000] usb 1-1: clear tt 1 (9233) error -71
Wed May 20 01:15:30 2015 kern.err kernel: [635792.400000] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71
Wed May 20 01:15:30 2015 kern.err kernel: [635792.400000] usb 1-1: clear tt 1 (9243) error -71
Wed May 20 01:15:30 2015 kern.err kernel: [635792.400000] pl2303 ttyUSB1: usb_serial_generic_read_bulk_callback - nonzero urb status: -71
Wed May 20 01:15:30 2015 kern.err kernel: [635792.400000] usb 1-1: clear tt 1 (9233) error -71
Wed May 20 01:15:30 2015 kern.err kernel: [635792.410000] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71
Wed May 20 01:15:30 2015 kern.err kernel: [635792.410000] usb 1-1: clear tt 1 (9243) error -71
Wed May 20 01:15:30 2015 kern.info kernel: [635792.410000] usb 1-1.1: USB disconnect, device number 35
Wed May 20 01:15:30 2015 kern.err kernel: [635792.410000] pl2303 ttyUSB0: pl2303_read_int_callback - usb_submit_urb failed with result -19
Wed May 20 01:15:30 2015 kern.info kernel: [635792.410000] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
Wed May 20 01:15:30 2015 kern.info kernel: [635792.410000] pl2303 1-1.1:1.0: device disconnected
Wed May 20 01:15:30 2015 kern.err kernel: [635792.410000] pl2303 ttyUSB1: usb_serial_generic_read_bulk_callback - nonzero urb status: -71
Wed May 20 01:15:30 2015 kern.err kernel: [635792.420000] usb 1-1: clear tt 1 (9233) error -71
Wed May 20 01:15:30 2015 kern.info kernel: [635792.420000] usb 1-1.3: USB disconnect, device number 36
Wed May 20 01:15:30 2015 kern.info kernel: [635792.420000] pl2303 ttyUSB1: pl2303 converter now disconnected from ttyUSB1
Wed May 20 01:15:30 2015 kern.info kernel: [635792.420000] pl2303 1-1.3:1.0: device disconnected
Wed May 20 01:15:30 2015 kern.err kernel: [635792.420000] usb 1-1: clear tt 1 (9243) error -71
Wed May 20 01:15:30 2015 kern.info kernel: [635792.430000] usb 1-1.4: USB disconnect, device number 37
Wed May 20 01:15:30 2015 kern.info kernel: [635792.430000] ftdi_sio ttyUSB2: FTDI USB Serial Device converter now disconnected from ttyUSB2
Wed May 20 01:15:30 2015 kern.info kernel: [635792.430000] ftdi_sio 1-1.4:1.0: device disconnected
Wed May 20 01:15:30 2015 kern.info kernel: [635792.550000] usb 1-1: reset high-speed USB device number 34 using ehci-platform
Wed May 20 01:15:31 2015 kern.info kernel: [635793.020000] usb 1-1.1: new full-speed USB device number 38 using ehci-platform
Wed May 20 01:15:31 2015 kern.info kernel: [635793.150000] pl2303 1-1.1:1.0: pl2303 converter detected
Wed May 20 01:15:31 2015 kern.info kernel: [635793.150000] usb 1-1.1: pl2303 converter now attached to ttyUSB0
Wed May 20 01:15:31 2015 kern.info kernel: [635793.250000] usb 1-1.3: new full-speed USB device number 39 using ehci-platform
Wed May 20 01:15:31 2015 kern.info kernel: [635793.380000] pl2303 1-1.3:1.0: pl2303 converter detected
Wed May 20 01:15:31 2015 kern.info kernel: [635793.380000] usb 1-1.3: pl2303 converter now attached to ttyUSB1
Wed May 20 01:15:31 2015 kern.info kernel: [635793.500000] usb 1-1.4: new full-speed USB device number 40 using ehci-platform
Wed May 20 01:15:31 2015 kern.info kernel: [635793.640000] ftdi_sio 1-1.4:1.0: FTDI USB Serial Device converter detected
Wed May 20 01:15:31 2015 kern.info kernel: [635793.640000] usb 1-1.4: Detected FT232RL
Wed May 20 01:15:31 2015 kern.info kernel: [635793.640000] usb 1-1.4: FTDI USB Serial Device converter now attached to ttyUSB2

There are something like 30000 lines that look like the first few there.

At the time of these errors, the WIFI was on, in client mode, and scanning/unassociated.

All of the serial interfaces appear to be operating normally right now.

I regret that I do not have these devices to log to a syslog server or store their log files somewhere safe. I really don't know if this has happened before or how often it happens while I am not watching, because I only use my serial interfaces interactively on an as-needed basis. I usually check dmesg/logread when I log into a device, but I've not noticed this before.

(Last edited by jmomo on 20 May 2015, 02:47)

I just had problems again with one of my ar9331 TP-Link TL-WR710N devices (described above).

Like before, wifi was in client mode and unassociated. I had a USB hub with a single USB-to-Serial adapter on it.

I started getting some weird lag and timeouts where my input was not taking or being echoed back to me. I didn't suspect anything was wrong with the serial device I was talking to (a Cisco ASA console), so I figured it was this bug again.

In the log below, you will see what I did.

I first shut down the wifi with "wifi down", since I didn't need the 802.11 interface at the time. That seems to have caused the kernel to cough up an error on the serial interface I had been using a few seconds before.

This hardware can flip it's USB port on and off via a GPIO, and I had a script that does that, so that's what I did next. You see me shut down the USB interface at 23:34:50 and then turn it back on again at 23:34:54.

Wed Jun 10 23:33:32 2015 daemon.notice netifd: Interface 'wireless' is disabled
Wed Jun 10 23:34:50 2015 kern.err kernel: [433099.970000] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - nonzero urb status: -71
Wed Jun 10 23:34:50 2015 kern.info kernel: [433099.970000] usb 1-1: USB disconnect, device number 2
Wed Jun 10 23:34:50 2015 kern.info kernel: [433099.970000] usb 1-1.3: USB disconnect, device number 3
Wed Jun 10 23:34:50 2015 kern.info kernel: [433099.980000] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
Wed Jun 10 23:34:50 2015 kern.info kernel: [433099.980000] pl2303 1-1.3:1.0: device disconnected
Wed Jun 10 23:34:50 2015 kern.err kernel: [433099.990000] usb 1-1: clear tt 1 (9033) error -71
Wed Jun 10 23:34:54 2015 kern.info kernel: [433104.200000] usb 1-1: new high-speed USB device number 4 using ehci-platform
Wed Jun 10 23:34:54 2015 kern.info kernel: [433104.350000] hub 1-1:1.0: USB hub found
Wed Jun 10 23:34:54 2015 kern.info kernel: [433104.350000] hub 1-1:1.0: 4 ports detected
Wed Jun 10 23:34:54 2015 kern.info kernel: [433104.650000] usb 1-1.3: new full-speed USB device number 5 using ehci-platform
Wed Jun 10 23:34:54 2015 kern.info kernel: [433104.780000] pl2303 1-1.3:1.0: pl2303 converter detected
Wed Jun 10 23:34:54 2015 kern.info kernel: [433104.780000] usb 1-1.3: pl2303 converter now attached to ttyUSB0

Note that this host has an uptime of about 4 days. It was working fine on day 1 and then yesterday.

If the clock was wandering around, it's subtle. It was enough to cause in/output problems but not quite enough to cause the serial device to die or generate kernel errors before I shut down wifi.

https://github.com/8devices/carambola2/ … 5c4e168923
this patch will not prevent usb to hang if i use the usb_control_msg quicklly

if i use the usb's bulk transfer, it will stable,

but i use the usb's control transfer, it will still go to hang.

then it will post the -145 (which is timeout error if you continue to use the device):

the error is :

usb-1-1.4: usbfs: USBDEVFS_CONTROL failed cmd main rqt 64 rq 0 len 0 ret -145

i close the wifi, then test the usb control transfer, it will stable,
i i open the wifi, then test the usb control transfer, it will hang after working sometime,
so i think, it still relative to ar9331's wifi reset.
may be somewhere does't patched which still have some influences to the usb.

Me i have a comfatst router/ap cf-wa700 with Chipset: Qualcomm Atharos AR9341. but how can i use openwrt with it?

Could be, a passive hub fixed my problems.

But I don't know if there are stability complaints with stock device firmware, so I'm still inclined to think it's a software issue.

I got two tl-mr3020 routers one with a hub and another one without a hub, both got a logitech cams with the same model and firmware version, everything goes well until I update the firmware to Chaos Chalmer r46996.
Before the update, routers where running fine for a year or more, Im using motion for a security survillance, but after the update, the one without the hub start to have problems with the usb connection, I didn't post before because I took the time to test for power problems, change the power capacitors, back to previous version and so on, the problem is solved turning off and on the usb power via gpio pin but there are problems at least, some times runs fine for a day or two but some other times get bad after a minute, I already testing a power problem, using the lab power, testing with the multimeter about power drain and so on, when using with an ethernet connection everything goes better but not perfect and when I turn on the wifi the problems are worst, my solution was putting a hub, but Im very limited with the free space inside the box having the router, the power and the cam.
I try to get back to the Openwrt version before chaos chalmer, but no lucky, the problem persist, and I dont fully understand Openwrt to check if there are some pll register or value that was modified after the upgrade and stored in some memory position or if the bootloader was changed in the upgrade, but I try and fail.

If someone can send me a tip I will really apreciate it, because I have no room to put a hub in the case that hold my cam.

Thanks and sorry for my english.
Luis