Re: ath9k -> bogus usb xfer on at91

[Oleksij Rempel <linux@rempel-privat.de>]

[-- Attachment #1: Type: text/plain, Size: 2516 bytes --]

Am 07.07.2014 15:40, schrieb Anders Darander:
> On 4 July 2014 18:54, Oleksij Rempel <linux@rempel-privat.de> wrote:
>> Am 04.07.2014 18:30, schrieb Alan Stern:
>>> On Fri, 4 Jul 2014, Anders Darander wrote:
>>>> ~# usb 1-1: new full-speed USB device number 3 using at91_ohci
>>>> usb 1-1: ath9k_htc: Firmware htc_9271.fw requested
>>>> usb 1-1: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272
>>>> -----------[ cut here ]-----------
>>>> WARNING: CPU: 0 PID: 93 at
>>>> /mnt/cs-builds/anders/oe-build/build-ccu/tmp-eglibc/work/ccu-oe-linux-gnueabi/linux-yocto-ccu/3.14+gitAUTOINC+7b03bd3dfd-r0/linux/drivers/usb/core/urb.c:450
>>>> usb_submit_urb+0x2ac/0x460()
>>>> usb 1-1: BOGUS urb xfer, pipe 1 != type 3
> 
>>>
>>> I can't tell exactly where the fault is, but this message means that an
>>> URB was submitted for a bulk endpoint with a pipe of type
>>> PIPE_INTERRUPT.
>>
>> Then kernel driver and firmware should be updated. There was some
>> Bulk/Interrupt issues which was fixed last year.
> 
> Any pointers to the bulk/interrupt issues? Was it a general issue, or
> related either to
> at91-ohci or ar9271?

It is primary ar9271 issue. The interrupt EP has different response time
on different host controllers. Initially as workaround ath9k was forcing
Bulk traffic on Interrupt EP. But this workaround is working with some
host controllers and completely fails on others. So i removed it. The
patches are included in master kernel branch and git firmware source.

> 
> As far as I've been able to find out, I've got the latest firmware
> (check again with linux-firmware).
> I've also tried with the master from open-ath9k-htc-firmware.
> 
>> I hope this HW will not be used as AP.
> 
> Is this based on the use of at91- SoC, or based on the ar9271?

ar9271 can work as AP with limit on 8 stations but according to user
reports it fails even with one station on at91

> The primary use case is to run as a client, though there will likely
> be some instances where it'll
> function as a AP. (Though primarily for M2M communications), thus
> pretty low traffic.

For AP usually should be created monitor mode interface for receiving
and transmitting management frames. Depending on location and STAs or
APs working on same channel, you will get a lot of traffic on this usb
interface.
Some users reported huge traffic drops on at91 based APs. Since i can't
debug it, i can't promise that it will be fixed any time soon.

-- 
Regards,
Oleksij


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 278 bytes --]