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
