ath9k -> bogus usb xfer on at91

Quoted 25 lines

/ 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?/

Quoted 5 lines

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

Quoted 17 lines

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

Quoted 6 lines

/  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

Quoted 84 lines · Oleksij Rempel

Quoted 10 lines

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

Quoted 5 lines

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

Quoted 7 lines

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

Quoted 4 lines

/> related either to/
/> at91-ohci or ar9271?/

/ It is primary ar9271 issue. The interrupt EP has different

response time/

Quoted 1 line

/ on different host controllers. Initially as workaround ath9k was

forcing/

Quoted 1 line

/ Bulk traffic on Interrupt EP. But this workaround is working with

some/

Quoted 1 line

/ host controllers and completely fails on others. So i removed it.

The/

Quoted 1 line

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

Quoted 12 lines

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

Quoted 6 lines

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

Quoted 1 line

/ and transmitting management frames. Depending on location and STAs

or/

Quoted 1 line

/ APs working on same channel, you will get a lot of traffic on this

usb/

Quoted 2 lines

/ interface./
/ Some users reported huge traffic drops on at91 based APs. Since i

can't/

Quoted 1 line

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

Quoted 2 lines

Cheers,
Anders

Anders, did you ever have a chance to look at this? I am seeing this same warning that is filling up the kernel logs in v3.18-rc6.

The device I am using is:

|ID 0846:9030 NetGear, Inc. WNA1100 Wireless-N 150 [Atheros AR9271]||

I found that if I revert kernel commit 2b72111 that the warning stops, but the device does not work very well.||If you are interested to know more about the symptoms we are seeing, there is a bug report here:
<https://github.com/ev3dev/ev3dev/issues/152>. But, I figured at least knowing the kernel commit that introduced the problem would be helpful.|

||

Signature · 4 lines

To unsubscribe from this list: send the line "unsubscribe
linux-wireless" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Am 26.11.2014 um 01:28 schrieb David Lechner:

Quoted 90 lines

Quoted 83 lines · Oleksij Rempel

Quoted 10 lines

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

Quoted 5 lines

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

Quoted 7 lines

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

Quoted 4 lines

/> related either to/
/> at91-ohci or ar9271?/

/ It is primary ar9271 issue. The interrupt EP has different

response time/

Quoted 1 line

/ on different host controllers. Initially as workaround ath9k was

forcing/

Quoted 1 line

/ Bulk traffic on Interrupt EP. But this workaround is working with

some/

Quoted 1 line

/ host controllers and completely fails on others. So i removed it.

The/

Quoted 1 line

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

Quoted 12 lines

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

Quoted 6 lines

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

Quoted 1 line

/ and transmitting management frames. Depending on location and STAs

or/

Quoted 1 line

/ APs working on same channel, you will get a lot of traffic on this

usb/

Quoted 2 lines

/ interface./
/ Some users reported huge traffic drops on at91 based APs. Since i

can't/

Quoted 1 line

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

Quoted 2 lines

Cheers,
Anders

Anders, did you ever have a chance to look at this? I am seeing this same warning that is filling up the kernel logs in v3.18-rc6.

The device I am using is:

Quoted 8 lines

|ID 0846:9030 NetGear, Inc. WNA1100 Wireless-N 150 [Atheros AR9271]||

I found that if I revert kernel commit 2b72111 that the warning stops, but the device does not work very well.||If you are interested to know more about the symptoms we are seeing, there is a bug report here:
<https://github.com/ev3dev/ev3dev/issues/152>. But, I figured at least knowing the kernel commit that introduced the problem would be helpful.|

i assume you mean this:

commit 2b721118b7821107757eb1d37af4b60e877b27e7

Author: Oleksij Rempel <[email protected]>
Date:   Tue Aug 13 21:10:19 2013 +0200

ath9k_htc: do not use bulk on EP3 and EP4

If usb auto suspend is enabled or system run in to suspend/resume cycle, ath9k-htc adapter will stop to response. It is reproducible
on xhci H

Host part of problem:
XHCI do timing calculation based on Transfer Type and bInterval, immediately after device was detected. Ath9k-htc try to overwrite this parameters on module probe and some changes in FW, since we do not initiate usb reset from the driver this changes are not took to account. So, before any kind of suspend or reset, host controller will operate with old parameters. Only after
suspend/resume
and if interface id stay unchanged, new parameters will be applied. Host will send bulk data with no intervals (?), which will cause overflow on FIFO of EP4.

Firmware part of problem:
By default, ath9k-htc adapters configured with EP3 and EP4 as interrupt endpoints. Current firmware will try to overwrite ConfigDescriptor to make EP3 and EP4 bulk. FIFO for this endpoints stay not reconfigured, so under the hood it is still Int EP.

This patch is revert of 4a0e8ecca4ee commit which trying to reduce CPU usage on some systems. Since it will produce more bug as fixes, we will need to find other way to fix it.

here is comment from kernel source which has some more explanation:
* Some buggy high speed devices have bulk endpoints using
* maxpacket sizes other than 512. High speed HCDs may not
* be able to handle that particular bug, so let's warn...

in our case EP3 and EP4 have maxpacket sizes = 64!!!

Signed-off-by Oleksij Rempel <[email protected]>

Signed-off-by John W. Linville <[email protected]>

Quoted 6 lines

||

Signature · 4 lines

To unsubscribe from this list: send the line "unsubscribe
linux-wireless" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html