Re: ath9k -> bogus usb xfer on at91

[David Lechner]

On 11/26/14 12:29 PM, Oleksij Rempel wrote:

Am 26.11.2014 um 01:28 schrieb David Lechner:

On 7 July 2014 17:08, Oleksij Rempel  wrote:

/  Am 07.07.2014 15:40, schrieb Anders Darander:/
/> On 4 July 2014 18:54, Oleksij Rempel  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, 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:
. 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 
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 endpo

Re: ath9k -> bogus usb xfer on at91

[Oleksij Rempel]

Am 26.11.2014 um 01:28 schrieb David Lechner:
>> On 7 July 2014 17:08, Oleksij Rempel  wrote:
>> >/  Am 07.07.2014 15:40, schrieb Anders Darander:/
>> >/> On 4 July 2014 18:54, Oleksij Rempel  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, 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:
> . 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 
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

Re: ath9k -> bogus usb xfer on at91

[David Lechner]

On 7 July 2014 17:08, Oleksij Rempel  wrote:
>/  Am 07.07.2014 15:40, schrieb Anders Darander:/
>/> On 4 July 2014 18:54, Oleksij Rempel  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, 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: 
. But, I figured at least knowing 
the kernel commit that introduced the problem would be helpful.|



||
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath9k -> bogus usb xfer on at91

[Anders Darander]

On 7 July 2014 17:08, Oleksij Rempel  wrote:
> Am 07.07.2014 15:40, schrieb Anders Darander:
>> On 4 July 2014 18:54, Oleksij Rempel  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-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath9k -> bogus usb xfer on at91

[Oleksij Rempel]

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

Beside, do any one know how can i get hands on usb protocol analyser?
I think ath9k_htc should be fixed or at least limited.

-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: ath9k -> bogus usb xfer on at91

[Oleksij Rempel]

Am 07.07.2014 15:40, schrieb Anders Darander:
> On 4 July 2014 18:54, Oleksij Rempel  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



signature.asc
Description: OpenPGP digital signature

Re: ath9k -> bogus usb xfer on at91

[Anders Darander]

On 4 July 2014 18:30, Alan Stern  wrote:
> On Fri, 4 Jul 2014, Anders Darander wrote:
-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.
>
>> After temporarily reverting commit
>> 3482528e9aced9234d4e2a4a9538c882a9aa5aa2, which enables debug checks
>> on all USB urb's (previously is was only enabled for a
>> CONFIG_USB_DEBUG enabled kernel), the WiFi chip starts to work
>> correctly. The chip in question is a ar9721.
>>
>>  The same USB stick works without these messages on my laptop; while
>> another USB stick, based on an rtl8187 chip, works without these
>> messages on the target system (at91sam9g20)
>>
>> Any pointers to what it could be? Or suggestions on how to attack the issue?
>
> Fix the URB submission to use the correct pipe type.

Yeah, that's the plan. At least to try and fix it, I just have to find
the spot where the
wrong pipe type is selected. (And the summer vacation is approaching fast).

Thanks for confirming my suspicion regarding the pipe type.

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-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath9k -> bogus usb xfer on at91

[Anders Darander]

On 4 July 2014 18:54, Oleksij Rempel  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?

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?

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.

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-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath9k -> bogus usb xfer on at91

[Oleksij Rempel]

Am 04.07.2014 18:30, schrieb Alan Stern:
> On Fri, 4 Jul 2014, Anders Darander wrote:
> 
>> Hi,
>>
>> While porting an internal BSP (a design based on a at91sam9g20 SoC)
>> from 3.10 to 3.14, I got flooded with messages like:
>>
>> ~# 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
>> Modules linked in: ath9k_htc ath9k_common ath9k_hw ath mac80211
>> cfg80211 ccudrv(O) at91_disable_wdt(O) at91_bootcount(O) at91_adc(O)
>> CPU: 0 PID: 93 Comm: kworker/0:3 Tainted: G W O 3.14.10-ccu #2
>> Workqueue: events request_firmware_work_func
>> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
>> [] (show_stack) from [] (warn_slowpath_common+0x60/0x80)
>> [] (warn_slowpath_common) from []
>> (warn_slowpath_fmt+0x2c/0x3c)
>> [] (warn_slowpath_fmt) from [] 
>> (usb_submit_urb+0x2ac/0x460)
>> [] (usb_submit_urb) from []
>> (hif_usb_send+0x268/0x2c8 [ath9k_htc])
>> [] (hif_usb_send [ath9k_htc]) from []
>> (htc_issue_send.constprop.4+0x64/0x68 [ath9k_htc])
>> [] (htc_issue_send.constprop.4 [ath9k_htc]) from
>> [] (htc_connect_service+0x170/0x1c8 [ath9k_htc])
>> [] (htc_connect_service [ath9k_htc]) from []
>> (ath9k_wmi_connect+0x50/0x6c [ath9k_htc])
>> [] (ath9k_wmi_connect [ath9k_htc]) from []
>> (ath9k_init_htc_services.isra.10+0x20/0x280 [ath9k_htc])
>> [] (ath9k_init_htc_services.isra.10 [ath9k_htc]) from
>> [] (ath9k_htc_probe_device+0xe4/0x928 [ath9k_htc])
>> [] (ath9k_htc_probe_device [ath9k_htc]) from []
>> (ath9k_htc_hw_init+0x10/0x30 [ath9k_htc])
>> [] (ath9k_htc_hw_init [ath9k_htc]) from []
>> (ath9k_hif_usb_firmware_cb+0x4cc/0x5c8 [ath9k_htc])
>> [] (ath9k_hif_usb_firmware_cb [ath9k_htc]) from []
>> (request_firmware_work_func+0x2c/0x4c)
>> [] (request_firmware_work_func) from []
>> (process_one_work+0x20c/0x33c)
>> [] (process_one_work) from [] (worker_thread+0x234/0x384)
>> [] (worker_thread) from [] (kthread+0xc0/0xd4)
>> [] (kthread) from [] (ret_from_fork+0x14/0x24)
>> --[ end trace b92d2c3cd165cd68 ]--
>> ---[ cut here ]---
> 
> 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.

I hope this HW will not be used as AP.

>> After temporarily reverting commit
>> 3482528e9aced9234d4e2a4a9538c882a9aa5aa2, which enables debug checks
>> on all USB urb's (previously is was only enabled for a
>> CONFIG_USB_DEBUG enabled kernel), the WiFi chip starts to work
>> correctly. The chip in question is a ar9721.
>>
>>  The same USB stick works without these messages on my laptop; while
>> another USB stick, based on an rtl8187 chip, works without these
>> messages on the target system (at91sam9g20)
>>
>> Any pointers to what it could be? Or suggestions on how to attack the issue?
> 
> Fix the URB submission to use the correct pipe type.
> 
> Alan Stern
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: ath9k -> bogus usb xfer on at91

[Alan Stern]

On Fri, 4 Jul 2014, Anders Darander wrote:

> Hi,
> 
> While porting an internal BSP (a design based on a at91sam9g20 SoC)
> from 3.10 to 3.14, I got flooded with messages like:
> 
> ~# 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
> Modules linked in: ath9k_htc ath9k_common ath9k_hw ath mac80211
> cfg80211 ccudrv(O) at91_disable_wdt(O) at91_bootcount(O) at91_adc(O)
> CPU: 0 PID: 93 Comm: kworker/0:3 Tainted: G W O 3.14.10-ccu #2
> Workqueue: events request_firmware_work_func
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (warn_slowpath_common+0x60/0x80)
> [] (warn_slowpath_common) from []
> (warn_slowpath_fmt+0x2c/0x3c)
> [] (warn_slowpath_fmt) from [] 
> (usb_submit_urb+0x2ac/0x460)
> [] (usb_submit_urb) from []
> (hif_usb_send+0x268/0x2c8 [ath9k_htc])
> [] (hif_usb_send [ath9k_htc]) from []
> (htc_issue_send.constprop.4+0x64/0x68 [ath9k_htc])
> [] (htc_issue_send.constprop.4 [ath9k_htc]) from
> [] (htc_connect_service+0x170/0x1c8 [ath9k_htc])
> [] (htc_connect_service [ath9k_htc]) from []
> (ath9k_wmi_connect+0x50/0x6c [ath9k_htc])
> [] (ath9k_wmi_connect [ath9k_htc]) from []
> (ath9k_init_htc_services.isra.10+0x20/0x280 [ath9k_htc])
> [] (ath9k_init_htc_services.isra.10 [ath9k_htc]) from
> [] (ath9k_htc_probe_device+0xe4/0x928 [ath9k_htc])
> [] (ath9k_htc_probe_device [ath9k_htc]) from []
> (ath9k_htc_hw_init+0x10/0x30 [ath9k_htc])
> [] (ath9k_htc_hw_init [ath9k_htc]) from []
> (ath9k_hif_usb_firmware_cb+0x4cc/0x5c8 [ath9k_htc])
> [] (ath9k_hif_usb_firmware_cb [ath9k_htc]) from []
> (request_firmware_work_func+0x2c/0x4c)
> [] (request_firmware_work_func) from []
> (process_one_work+0x20c/0x33c)
> [] (process_one_work) from [] (worker_thread+0x234/0x384)
> [] (worker_thread) from [] (kthread+0xc0/0xd4)
> [] (kthread) from [] (ret_from_fork+0x14/0x24)
> --[ end trace b92d2c3cd165cd68 ]--
> ---[ cut here ]---

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.

> After temporarily reverting commit
> 3482528e9aced9234d4e2a4a9538c882a9aa5aa2, which enables debug checks
> on all USB urb's (previously is was only enabled for a
> CONFIG_USB_DEBUG enabled kernel), the WiFi chip starts to work
> correctly. The chip in question is a ar9721.
> 
>  The same USB stick works without these messages on my laptop; while
> another USB stick, based on an rtl8187 chip, works without these
> messages on the target system (at91sam9g20)
> 
> Any pointers to what it could be? Or suggestions on how to attack the issue?

Fix the URB submission to use the correct pipe type.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath9k -> bogus usb xfer on at91

[Oleksij Rempel]

Hi Andreas,

... uff.. again at91_ohci with 12 Mbit usb!!! No interest. I don't even
wont to talk about it. Except only if you have usb protocol analyser.

Beside, this warning is about slow path, which i would expect on this
configuration.

Am 04.07.2014 15:32, schrieb Anders Darander:
> Hi,
> 
> While porting an internal BSP (a design based on a at91sam9g20 SoC)
> from 3.10 to 3.14, I got flooded with messages like:
> 
> ~# 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
> Modules linked in: ath9k_htc ath9k_common ath9k_hw ath mac80211
> cfg80211 ccudrv(O) at91_disable_wdt(O) at91_bootcount(O) at91_adc(O)
> CPU: 0 PID: 93 Comm: kworker/0:3 Tainted: G W O 3.14.10-ccu #2
> Workqueue: events request_firmware_work_func
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (warn_slowpath_common+0x60/0x80)
> [] (warn_slowpath_common) from []
> (warn_slowpath_fmt+0x2c/0x3c)
> [] (warn_slowpath_fmt) from [] 
> (usb_submit_urb+0x2ac/0x460)
> [] (usb_submit_urb) from []
> (hif_usb_send+0x268/0x2c8 [ath9k_htc])
> [] (hif_usb_send [ath9k_htc]) from []
> (htc_issue_send.constprop.4+0x64/0x68 [ath9k_htc])
> [] (htc_issue_send.constprop.4 [ath9k_htc]) from
> [] (htc_connect_service+0x170/0x1c8 [ath9k_htc])
> [] (htc_connect_service [ath9k_htc]) from []
> (ath9k_wmi_connect+0x50/0x6c [ath9k_htc])
> [] (ath9k_wmi_connect [ath9k_htc]) from []
> (ath9k_init_htc_services.isra.10+0x20/0x280 [ath9k_htc])
> [] (ath9k_init_htc_services.isra.10 [ath9k_htc]) from
> [] (ath9k_htc_probe_device+0xe4/0x928 [ath9k_htc])
> [] (ath9k_htc_probe_device [ath9k_htc]) from []
> (ath9k_htc_hw_init+0x10/0x30 [ath9k_htc])
> [] (ath9k_htc_hw_init [ath9k_htc]) from []
> (ath9k_hif_usb_firmware_cb+0x4cc/0x5c8 [ath9k_htc])
> [] (ath9k_hif_usb_firmware_cb [ath9k_htc]) from []
> (request_firmware_work_func+0x2c/0x4c)
> [] (request_firmware_work_func) from []
> (process_one_work+0x20c/0x33c)
> [] (process_one_work) from [] (worker_thread+0x234/0x384)
> [] (worker_thread) from [] (kthread+0xc0/0xd4)
> [] (kthread) from [] (ret_from_fork+0x14/0x24)
> --[ end trace b92d2c3cd165cd68 ]--
> ---[ cut here ]---
> 
> After temporarily reverting commit
> 3482528e9aced9234d4e2a4a9538c882a9aa5aa2, which enables debug checks
> on all USB urb's (previously is was only enabled for a
> CONFIG_USB_DEBUG enabled kernel), the WiFi chip starts to work
> correctly. The chip in question is a ar9721.
> 
>  The same USB stick works without these messages on my laptop; while
> another USB stick, based on an rtl8187 chip, works without these
> messages on the target system (at91sam9g20)
> 
> Any pointers to what it could be? Or suggestions on how to attack the issue?
> 
> Thanks in advance!
> Cheers,
> Anders
> 


-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

ath9k -> bogus usb xfer on at91

[Anders Darander]

Hi,

While porting an internal BSP (a design based on a at91sam9g20 SoC)
from 3.10 to 3.14, I got flooded with messages like:

~# 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
Modules linked in: ath9k_htc ath9k_common ath9k_hw ath mac80211
cfg80211 ccudrv(O) at91_disable_wdt(O) at91_bootcount(O) at91_adc(O)
CPU: 0 PID: 93 Comm: kworker/0:3 Tainted: G W O 3.14.10-ccu #2
Workqueue: events request_firmware_work_func
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (warn_slowpath_common+0x60/0x80)
[] (warn_slowpath_common) from []
(warn_slowpath_fmt+0x2c/0x3c)
[] (warn_slowpath_fmt) from [] (usb_submit_urb+0x2ac/0x460)
[] (usb_submit_urb) from []
(hif_usb_send+0x268/0x2c8 [ath9k_htc])
[] (hif_usb_send [ath9k_htc]) from []
(htc_issue_send.constprop.4+0x64/0x68 [ath9k_htc])
[] (htc_issue_send.constprop.4 [ath9k_htc]) from
[] (htc_connect_service+0x170/0x1c8 [ath9k_htc])
[] (htc_connect_service [ath9k_htc]) from []
(ath9k_wmi_connect+0x50/0x6c [ath9k_htc])
[] (ath9k_wmi_connect [ath9k_htc]) from []
(ath9k_init_htc_services.isra.10+0x20/0x280 [ath9k_htc])
[] (ath9k_init_htc_services.isra.10 [ath9k_htc]) from
[] (ath9k_htc_probe_device+0xe4/0x928 [ath9k_htc])
[] (ath9k_htc_probe_device [ath9k_htc]) from []
(ath9k_htc_hw_init+0x10/0x30 [ath9k_htc])
[] (ath9k_htc_hw_init [ath9k_htc]) from []
(ath9k_hif_usb_firmware_cb+0x4cc/0x5c8 [ath9k_htc])
[] (ath9k_hif_usb_firmware_cb [ath9k_htc]) from []
(request_firmware_work_func+0x2c/0x4c)
[] (request_firmware_work_func) from []
(process_one_work+0x20c/0x33c)
[] (process_one_work) from [] (worker_thread+0x234/0x384)
[] (worker_thread) from [] (kthread+0xc0/0xd4)
[] (kthread) from [] (ret_from_fork+0x14/0x24)
--[ end trace b92d2c3cd165cd68 ]--
---[ cut here ]---

After temporarily reverting commit
3482528e9aced9234d4e2a4a9538c882a9aa5aa2, which enables debug checks
on all USB urb's (previously is was only enabled for a
CONFIG_USB_DEBUG enabled kernel), the WiFi chip starts to work
correctly. The chip in question is a ar9721.

 The same USB stick works without these messages on my laptop; while
another USB stick, based on an rtl8187 chip, works without these
messages on the target system (at91sam9g20)

Any pointers to what it could be? Or suggestions on how to attack the issue?

Thanks in advance!
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-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html