Search Linux Wireless

Re: ath9k -> bogus usb xfer on at91

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 7 July 2014 17:08, Oleksij Rempel <linux@xxxxxxxxxxxxxxxx> wrote:
> Am 07.07.2014 15:40, schrieb Anders Darander:
>> On 4 July 2014 18:54, Oleksij Rempel <linux@xxxxxxxxxxxxxxxx> 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.

Thanks for the comments!
I'll take a look at it, though it might have to be scheduled after the
upcoming vacations...

I'll sure try to look into those workarounds (and your removal of
those). I guess that
it's the firmware in open-ath9-htc-firmware you're talking about.

>>
>> 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.

Again, thanks for the information.
I think I've got a much better understanding of the issues (both those that I've
seen, and those that you have mentioned / explained). I'll see when/what I can
look into this and what I can find out.

Cheers,
Anders

-- 
Anders Darander
EPO guidelines 1978: "If the contribution to the known art resides
solely in a computer program then the subject matter is not
patentable in whatever manner it may be presented in the claims."
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux