2016-07-05 12:21:04

by Alexey Brodkin

[permalink] [raw]
Subject: ath9k-htc on OHCI -> bogus usb xfer

Hello,

Looks like this is another manifestation of already seen problem with ath9k-htc
and OHCI controller.

I'm trying to get USB Wi-Fi dongle based on Atheros AR9271 to work with our
development board (this is Synopsys AXS103) and seeing a picture very similar to
what was discussed here+AKA-http://thread.gmane.org/gmane.linux.usb.general/110847

Below is what I see on insertion of the dongle.
Note I have the most recent ath9k-htc firmware (see +ACI-ath9k+AF8-htc/htc+AF8-9271-1.4.0.fw+ACI-
in the log below) and Linux kernel is 4.6.3 (latest stable as of today) but the same
happens even on 4.4.

Interesting enough if I simply remove or disable the warning like that
------------------------+AD4-8---------------------------
diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c
index 3d27477..a317e1e 100644
--- a/drivers/usb/core/urb.c
+-+-+- b/drivers/usb/core/urb.c
+AEAAQA- -443,11 +-443,6 +AEAAQA- int usb+AF8-submit+AF8-urb(struct urb +ACo-urb, gfp+AF8-t mem+AF8-flags)
+AKAAoACgAKAAoACgAKAAoACgACo- cause problems in HCDs if they get it wrong.
+AKAAoACgAKAAoACgAKAAoACgACo-/
+AKA-
-+AKAAoACgAKAAoACgAKA-/+ACo- Check that the pipe's type matches the endpoint's type +ACo-/
-+AKAAoACgAKAAoACgAKA-if (usb+AF8-pipetype(urb-+AD4-pipe) +ACEAPQ- pipetypes+AFs-xfertype+AF0-)
-+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-dev+AF8-WARN(+ACY-dev-+AD4-dev, +ACI-BOGUS urb xfer, pipe +ACU-x +ACEAPQ- type +ACU-x+AFw-n+ACI-,
-+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoA-usb+AF8-pipetype(urb-+AD4-pipe), pipetypes+AFs-xfertype+AF0-)+ADs-
-
+AKAAoACgAKAAoACgAKAAoA-/+ACo- Check against a simple/standard policy +ACo-/
+AKAAoACgAKAAoACgAKAAoA-allowed +AD0- (URB+AF8-NO+AF8-TRANSFER+AF8-DMA+AF8-MAP +AHw- URB+AF8-NO+AF8-INTERRUPT +AHw- URB+AF8-DIR+AF8-MASK +AHw-
+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-URB+AF8-FREE+AF8-BUFFER)+ADs-
------------------------+AD4-8---------------------------
everything seem to work quite nice.

Any thoughts are much appreciated.

That's the log itself:
------------------------+AD4-8---------------------------
usb 1-1: new full-speed USB device number 2 using ohci-platform
usb 1-1: ath9k+AF8-htc: Firmware ath9k+AF8-htc/htc+AF8-9271-1.4.0.fw requested
usb 1-1: ath9k+AF8-htc: Transferred FW: ath9k+AF8-htc/htc+AF8-9271-1.4.0.fw, size: 51008
------------+AFs- cut here +AF0-------------
WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb+AF8-submit+AF8-urb+-0x162/0x404
usb 1-1: BOGUS urb xfer, pipe 1 +ACEAPQ- type 3
Modules linked in:
CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 4.6.3 +ACM-10
Workqueue: events request+AF8-firmware+AF8-work+AF8-func

Stack Trace:
+AKA- arc+AF8-unwind+AF8-core.constprop.1+-0x94/0x10c
---+AFs- end trace 2249b79eac9991d1 +AF0----
------------+AFs- cut here +AF0-------------
WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb+AF8-submit+AF8-urb+-0x162/0x404
usb 1-1: BOGUS urb xfer, pipe 1 +ACEAPQ- type 3
Modules linked in:
CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G+AKAAoACgAKAAoACgAKAAoA-W+AKAAoACgAKAAoACgAKA-4.6.3 +ACM-10
Workqueue: events request+AF8-firmware+AF8-work+AF8-func

Stack Trace:
+AKA- arc+AF8-unwind+AF8-core.constprop.1+-0x94/0x10c
---+AFs- end trace 2249b79eac9991d2 +AF0----
------------+AFs- cut here +AF0-------------
WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb+AF8-submit+AF8-urb+-0x162/0x404
usb 1-1: BOGUS urb xfer, pipe 1 +ACEAPQ- type 3
Modules linked in:
CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G+AKAAoACgAKAAoACgAKAAoA-W+AKAAoACgAKAAoACgAKA-4.6.3 +ACM-10
Workqueue: events request+AF8-firmware+AF8-work+AF8-func

Stack Trace:
+AKA- arc+AF8-unwind+AF8-core.constprop.1+-0x94/0x10c
---+AFs- end trace 2249b79eac9991d3 +AF0----

...
------------------------+AD4-8---------------------------

-Alexey


2016-07-05 17:24:42

by Oleksij Rempel

[permalink] [raw]
Subject: Re: ath9k-htc on OHCI -> bogus usb xfer

Hi,

Am 05.07.2016 um 14:20 schrieb Alexey Brodkin:
> Hello,
>
> Looks like this is another manifestation of already seen problem with ath9k-htc
> and OHCI controller.
>
> I'm trying to get USB Wi-Fi dongle based on Atheros AR9271 to work with our
> development board (this is Synopsys AXS103) and seeing a picture very similar to
> what was discussed here http://thread.gmane.org/gmane.linux.usb.general/110847
>
> Below is what I see on insertion of the dongle.
> Note I have the most recent ath9k-htc firmware (see "ath9k_htc/htc_9271-1.4.0.fw"
> in the log below) and Linux kernel is 4.6.3 (latest stable as of today) but the same
> happens even on 4.4.
>
> Interesting enough if I simply remove or disable the warning like that
> ------------------------>8---------------------------
> diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c
> index 3d27477..a317e1e 100644
> --- a/drivers/usb/core/urb.c
> +++ b/drivers/usb/core/urb.c
> @@ -443,11 +443,6 @@ int usb_submit_urb(struct urb *urb, gfp_t mem_flags)
> * cause problems in HCDs if they get it wrong.
> */
>
> - /* Check that the pipe's type matches the endpoint's type */
> - if (usb_pipetype(urb->pipe) != pipetypes[xfertype])
> - dev_WARN(&dev->dev, "BOGUS urb xfer, pipe %x != type %x\n",
> - usb_pipetype(urb->pipe), pipetypes[xfertype]);
> -
> /* Check against a simple/standard policy */
> allowed = (URB_NO_TRANSFER_DMA_MAP | URB_NO_INTERRUPT | URB_DIR_MASK |
> URB_FREE_BUFFER);
> ------------------------>8---------------------------
> everything seem to work quite nice.
>
> Any thoughts are much appreciated.
>
> That's the log itself:
> ------------------------>8---------------------------
> usb 1-1: new full-speed USB device number 2 using ohci-platform
> usb 1-1: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested
> usb 1-1: ath9k_htc: Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 51008
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb_submit_urb+0x162/0x404
> usb 1-1: BOGUS urb xfer, pipe 1 != type 3
> Modules linked in:
> CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 4.6.3 #10
> Workqueue: events request_firmware_work_func
>
> Stack Trace:
> arc_unwind_core.constprop.1+0x94/0x10c
> ---[ end trace 2249b79eac9991d1 ]---
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb_submit_urb+0x162/0x404
> usb 1-1: BOGUS urb xfer, pipe 1 != type 3
> Modules linked in:
> CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G W 4.6.3 #10
> Workqueue: events request_firmware_work_func
>
> Stack Trace:
> arc_unwind_core.constprop.1+0x94/0x10c
> ---[ end trace 2249b79eac9991d2 ]---
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb_submit_urb+0x162/0x404
> usb 1-1: BOGUS urb xfer, pipe 1 != type 3
> Modules linked in:
> CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G W 4.6.3 #10
> Workqueue: events request_firmware_work_func
>
> Stack Trace:
> arc_unwind_core.constprop.1+0x94/0x10c
> ---[ end trace 2249b79eac9991d3 ]---
>


please send content of hif_usb_send_regout() from your source code.
It is located in drivers/net/wireless/ath/ath9k/hif_usb.c


--
Regards,
Oleksij

Attachments:
signature.asc (213.00 B)
OpenPGP digital signature

2016-07-06 07:44:30

by Alexey Brodkin

[permalink] [raw]
Subject: Re: ath9k-htc on OHCI -> bogus usb xfer

Hi+AKA-Oleksij,

On Tue, 2016-07-05 at 21:01 +-0200, Oleksij Rempel wrote:
+AD4- Am 05.07.2016 um 19:31 schrieb Alexey Brodkin:
+AD4- +AD4-
+AD4- +AD4- Hi Oleksij,
+AD4- +AD4-
+AD4- +AD4- On Tue, 2016-07-05 at 19:23 +-0200, Oleksij Rempel wrote:
+AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- Hi,
+AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- Am 05.07.2016 um 14:20 schrieb Alexey Brodkin:
+AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- Hello,
+AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- Looks like this is another manifestation of already seen problem with ath9k-htc
+AD4- +AD4- +AD4- +AD4- and OHCI controller.
+AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- I'm trying to get USB Wi-Fi dongle based on Atheros AR9271 to work with our
+AD4- +AD4- +AD4- +AD4- development board (this is Synopsys AXS103) and seeing a picture very similar to
+AD4- +AD4- +AD4- +AD4- what was discussed here http://thread.gmane.org/gmane.linux.usb.general/110847
+AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- Below is what I see on insertion of the dongle.
+AD4- +AD4- +AD4- +AD4- Note I have the most recent ath9k-htc firmware (see +ACI-ath9k+AF8-htc/htc+AF8-9271-1.4.0.fw+ACI-
+AD4- +AD4- +AD4- +AD4- in the log below) and Linux kernel is 4.6.3 (latest stable as of today) but the same
+AD4- +AD4- +AD4- +AD4- happens even on 4.4.
+AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- Interesting enough if I simply remove or disable the warning like that
+AD4- +AD4- +AD4- +AD4- ------------------------+AD4-8---------------------------
+AD4- +AD4- +AD4- +AD4- diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c
+AD4- +AD4- +AD4- +AD4- index 3d27477..a317e1e 100644
+AD4- +AD4- +AD4- +AD4- --- a/drivers/usb/core/urb.c
+AD4- +AD4- +AD4- +AD4- +-+-+- b/drivers/usb/core/urb.c
+AD4- +AD4- +AD4- +AD4- +AEAAQA- -443,11 +-443,6 +AEAAQA- int usb+AF8-submit+AF8-urb(struct urb +ACo-urb, gfp+AF8-t mem+AF8-flags)
+AD4- +AD4- +AD4- +AD4- +AKAAoACgAKAAoACgAKAAoACgACo- cause problems in HCDs if they get it wrong.
+AD4- +AD4- +AD4- +AD4- +AKAAoACgAKAAoACgAKAAoACgACo-/
+AD4- +AD4- +AD4- +AD4- +AKA-
+AD4- +AD4- +AD4- +AD4- -+AKAAoACgAKAAoACgAKA-/+ACo- Check that the pipe's type matches the endpoint's type +ACo-/
+AD4- +AD4- +AD4- +AD4- -+AKAAoACgAKAAoACgAKA-if (usb+AF8-pipetype(urb-+AD4-pipe) +ACEAPQ- pipetypes+AFs-xfertype+AF0-)
+AD4- +AD4- +AD4- +AD4- -+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-dev+AF8-WARN(+ACY-dev-+AD4-dev, +ACI-BOGUS urb xfer, pipe +ACU-x +ACEAPQ- type +ACU-x+AFw-n+ACI-,
+AD4- +AD4- +AD4- +AD4- -+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoA-usb+AF8-pipetype(urb-+AD4-pipe), pipetypes+AFs-xfertype+AF0-)+ADs-
+AD4- +AD4- +AD4- +AD4- -
+AD4- +AD4- +AD4- +AD4- +AKAAoACgAKAAoACgAKAAoA-/+ACo- Check against a simple/standard policy +ACo-/
+AD4- +AD4- +AD4- +AD4- +AKAAoACgAKAAoACgAKAAoA-allowed +AD0- (URB+AF8-NO+AF8-TRANSFER+AF8-DMA+AF8-MAP +AHw- URB+AF8-NO+AF8-INTERRUPT +AHw- URB+AF8-DIR+AF8-MASK +AHw-
+AD4- +AD4- +AD4- +AD4- +AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-URB+AF8-FREE+AF8-BUFFER)+ADs-
+AD4- +AD4- +AD4- +AD4- ------------------------+AD4-8---------------------------
+AD4- +AD4- +AD4- +AD4- everything seem to work quite nice.
+AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- Any thoughts are much appreciated.
+AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- That's the log itself:
+AD4- +AD4- +AD4- +AD4- ------------------------+AD4-8---------------------------
+AD4- +AD4- +AD4- +AD4- usb 1-1: new full-speed USB device number 2 using ohci-platform
+AD4- +AD4- +AD4- +AD4- usb 1-1: ath9k+AF8-htc: Firmware ath9k+AF8-htc/htc+AF8-9271-1.4.0.fw requested
+AD4- +AD4- +AD4- +AD4- usb 1-1: ath9k+AF8-htc: Transferred FW: ath9k+AF8-htc/htc+AF8-9271-1.4.0.fw, size: 51008
+AD4- +AD4- +AD4- +AD4- ------------+AFs- cut here +AF0-------------
+AD4- +AD4- +AD4- +AD4- WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb+AF8-submit+AF8-urb+-0x162/0x404
+AD4- +AD4- +AD4- +AD4- usb 1-1: BOGUS urb xfer, pipe 1 +ACEAPQ- type 3
+AD4- +AD4- +AD4- +AD4- Modules linked in:
+AD4- +AD4- +AD4- +AD4- CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 4.6.3 +ACM-10
+AD4- +AD4- +AD4- +AD4- Workqueue: events request+AF8-firmware+AF8-work+AF8-func
+AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- Stack Trace:
+AD4- +AD4- +AD4- +AD4- +AKA- arc+AF8-unwind+AF8-core.constprop.1+-0x94/0x10c
+AD4- +AD4- +AD4- +AD4- ---+AFs- end trace 2249b79eac9991d1 +AF0----
+AD4- +AD4- +AD4- +AD4- ------------+AFs- cut here +AF0-------------
+AD4- +AD4- +AD4- +AD4- WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb+AF8-submit+AF8-urb+-0x162/0x404
+AD4- +AD4- +AD4- +AD4- usb 1-1: BOGUS urb xfer, pipe 1 +ACEAPQ- type 3
+AD4- +AD4- +AD4- +AD4- Modules linked in:
+AD4- +AD4- +AD4- +AD4- CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G+AKAAoACgAKAAoACgAKAAoA-W+AKAAoACgAKAAoACgAKA-4.6.3 +ACM-10
+AD4- +AD4- +AD4- +AD4- Workqueue: events request+AF8-firmware+AF8-work+AF8-func
+AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- Stack Trace:
+AD4- +AD4- +AD4- +AD4- +AKA- arc+AF8-unwind+AF8-core.constprop.1+-0x94/0x10c
+AD4- +AD4- +AD4- +AD4- ---+AFs- end trace 2249b79eac9991d2 +AF0----
+AD4- +AD4- +AD4- +AD4- ------------+AFs- cut here +AF0-------------
+AD4- +AD4- +AD4- +AD4- WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb+AF8-submit+AF8-urb+-0x162/0x404
+AD4- +AD4- +AD4- +AD4- usb 1-1: BOGUS urb xfer, pipe 1 +ACEAPQ- type 3
+AD4- +AD4- +AD4- +AD4- Modules linked in:
+AD4- +AD4- +AD4- +AD4- CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G+AKAAoACgAKAAoACgAKAAoA-W+AKAAoACgAKAAoACgAKA-4.6.3 +ACM-10
+AD4- +AD4- +AD4- +AD4- Workqueue: events request+AF8-firmware+AF8-work+AF8-func
+AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- Stack Trace:
+AD4- +AD4- +AD4- +AD4- +AKA- arc+AF8-unwind+AF8-core.constprop.1+-0x94/0x10c
+AD4- +AD4- +AD4- +AD4- ---+AFs- end trace 2249b79eac9991d3 +AF0----
+AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- please send content of hif+AF8-usb+AF8-send+AF8-regout() from your source code.
+AD4- +AD4- +AD4- It is located in drivers/net/wireless/ath/ath9k/hif+AF8-usb.c
+AD4- +AD4- I use vanilla 4.6.3 tree so that's what I have is the same as
+AD4- +AD4- http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/net/wireless/ath/ath9k/hif+AF8-usb.c?h+AD0-
+AD4- +AD4- linu
+AD4- +AD4- x-4.6.y+ACM-n99
+AD4-
+AD4- Interesting.
+AD4- Can you please send lsusb -v for this adapter?

See below:
--------------------------+AD4-8---------------------------
+ACM- lsusb -v

Bus 002 Device 002: ID 0cf3:9271+AKAAoA-
Device Descriptor:
+AKA- bLength+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKA-18
+AKA- bDescriptorType+AKAAoACgAKAAoACgAKAAoACg-1
+AKA- bcdUSB+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-2.00
+AKA- bDeviceClass+AKAAoACgAKAAoACgAKAAoACgAKA-255+AKA-
+AKA- bDeviceSubClass+AKAAoACgAKAAoACgAKA-255+AKA-
+AKA- bDeviceProtocol+AKAAoACgAKAAoACgAKA-255+AKA-
+AKA- bMaxPacketSize0+AKAAoACgAKAAoACgAKAAoA-64
+AKA- idVendor+AKAAoACgAKAAoACgAKAAoACgAKAAoA-0x0cf3+AKA-
+AKA- idProduct+AKAAoACgAKAAoACgAKAAoACgAKA-0x9271+AKA-
+AKA- bcdDevice+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-1.08
+AKA- iManufacturer+AKAAoACgAKAAoACgAKAAoACgAKA-16 ATHEROS
+AKA- iProduct+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-32 USB2.0 WLAN
+AKA- iSerial+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKA-48 12345
+AKA- bNumConfigurations+AKAAoACgAKAAoACg-1
+AKA- Configuration Descriptor:
+AKAAoACgAKA-bLength+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoA-9
+AKAAoACgAKA-bDescriptorType+AKAAoACgAKAAoACgAKAAoACg-2
+AKAAoACgAKA-wTotalLength+AKAAoACgAKAAoACgAKAAoACgAKAAoA-60
+AKAAoACgAKA-bNumInterfaces+AKAAoACgAKAAoACgAKAAoACgAKA-1
+AKAAoACgAKA-bConfigurationValue+AKAAoACgAKAAoA-1
+AKAAoACgAKA-iConfiguration+AKAAoACgAKAAoACgAKAAoACgAKA-0+AKA-
+AKAAoACgAKA-bmAttributes+AKAAoACgAKAAoACgAKAAoACg-0x80
+AKAAoACgAKAAoACg-(Bus Powered)
+AKAAoACgAKA-MaxPower+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoA-500mA
+AKAAoACgAKA-Interface Descriptor:
+AKAAoACgAKAAoACg-bLength+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoA-9
+AKAAoACgAKAAoACg-bDescriptorType+AKAAoACgAKAAoACgAKAAoACg-4
+AKAAoACgAKAAoACg-bInterfaceNumber+AKAAoACgAKAAoACgAKAAoA-0
+AKAAoACgAKAAoACg-bAlternateSetting+AKAAoACgAKAAoACgAKA-0
+AKAAoACgAKAAoACg-bNumEndpoints+AKAAoACgAKAAoACgAKAAoACgAKAAoA-6
+AKAAoACgAKAAoACg-bInterfaceClass+AKAAoACgAKAAoACgAKA-255+AKA-
+AKAAoACgAKAAoACg-bInterfaceSubClass+AKAAoACgAKAAoACg-0+AKA-
+AKAAoACgAKAAoACg-bInterfaceProtocol+AKAAoACgAKAAoACg-0+AKA-
+AKAAoACgAKAAoACg-iInterface+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoA-0+AKA-
+AKAAoACgAKAAoACg-Endpoint Descriptor:
+AKAAoACgAKAAoACgAKAAoA-bLength+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoA-7
+AKAAoACgAKAAoACgAKAAoA-bDescriptorType+AKAAoACgAKAAoACgAKAAoACg-5
+AKAAoACgAKAAoACgAKAAoA-bEndpointAddress+AKAAoACgAKAAoA-0x01+AKAAoA-EP 1 OUT
+AKAAoACgAKAAoACgAKAAoA-bmAttributes+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-2
+AKAAoACgAKAAoACgAKAAoACgAKA-Transfer Type+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-Bulk
+AKAAoACgAKAAoACgAKAAoACgAKA-Synch Type+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-None
+AKAAoACgAKAAoACgAKAAoACgAKA-Usage Type+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-Data
+AKAAoACgAKAAoACgAKAAoA-wMaxPacketSize+AKAAoACgAKAAoA-0x0040+AKAAoA-1x 64 bytes
+AKAAoACgAKAAoACgAKAAoA-bInterval+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-0
+AKAAoACgAKAAoACg-Endpoint Descriptor:
+AKAAoACgAKAAoACgAKAAoA-bLength+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoA-7
+AKAAoACgAKAAoACgAKAAoA-bDescriptorType+AKAAoACgAKAAoACgAKAAoACg-5
+AKAAoACgAKAAoACgAKAAoA-bEndpointAddress+AKAAoACgAKAAoA-0x82+AKAAoA-EP 2 IN
+AKAAoACgAKAAoACgAKAAoA-bmAttributes+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-2
+AKAAoACgAKAAoACgAKAAoACgAKA-Transfer Type+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-Bulk
+AKAAoACgAKAAoACgAKAAoACgAKA-Synch Type+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-None
+AKAAoACgAKAAoACgAKAAoACgAKA-Usage Type+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-Data
+AKAAoACgAKAAoACgAKAAoA-wMaxPacketSize+AKAAoACgAKAAoA-0x0040+AKAAoA-1x 64 bytes
+AKAAoACgAKAAoACgAKAAoA-bInterval+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-0
+AKAAoACgAKAAoACg-Endpoint Descriptor:
+AKAAoACgAKAAoACgAKAAoA-bLength+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoA-7
+AKAAoACgAKAAoACgAKAAoA-bDescriptorType+AKAAoACgAKAAoACgAKAAoACg-5
+AKAAoACgAKAAoACgAKAAoA-bEndpointAddress+AKAAoACgAKAAoA-0x83+AKAAoA-EP 3 IN
+AKAAoACgAKAAoACgAKAAoA-bmAttributes+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-3
+AKAAoACgAKAAoACgAKAAoACgAKA-Transfer Type+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-Interrupt
+AKAAoACgAKAAoACgAKAAoACgAKA-Synch Type+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-None
+AKAAoACgAKAAoACgAKAAoACgAKA-Usage Type+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-Data
+AKAAoACgAKAAoACgAKAAoA-wMaxPacketSize+AKAAoACgAKAAoA-0x0040+AKAAoA-1x 64 bytes
+AKAAoACgAKAAoACgAKAAoA-bInterval+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-1
+AKAAoACgAKAAoACg-Endpoint Descriptor:
+AKAAoACgAKAAoACgAKAAoA-bLength+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoA-7
+AKAAoACgAKAAoACgAKAAoA-bDescriptorType+AKAAoACgAKAAoACgAKAAoACg-5
+AKAAoACgAKAAoACgAKAAoA-bEndpointAddress+AKAAoACgAKAAoA-0x04+AKAAoA-EP 4 OUT
+AKAAoACgAKAAoACgAKAAoA-bmAttributes+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-2
+AKAAoACgAKAAoACgAKAAoACgAKA-Transfer Type+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-Bulk
+AKAAoACgAKAAoACgAKAAoACgAKA-Synch Type+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-None
+AKAAoACgAKAAoACgAKAAoACgAKA-Usage Type+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-Data
+AKAAoACgAKAAoACgAKAAoA-wMaxPacketSize+AKAAoACgAKAAoA-0x0040+AKAAoA-1x 64 bytes
+AKAAoACgAKAAoACgAKAAoA-bInterval+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-0
+AKAAoACgAKAAoACg-Endpoint Descriptor:
+AKAAoACgAKAAoACgAKAAoA-bLength+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoA-7
+AKAAoACgAKAAoACgAKAAoA-bDescriptorType+AKAAoACgAKAAoACgAKAAoACg-5
+AKAAoACgAKAAoACgAKAAoA-bEndpointAddress+AKAAoACgAKAAoA-0x05+AKAAoA-EP 5 OUT
+AKAAoACgAKAAoACgAKAAoA-bmAttributes+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-2
+AKAAoACgAKAAoACgAKAAoACgAKA-Transfer Type+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-Bulk
+AKAAoACgAKAAoACgAKAAoACgAKA-Synch Type+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-None
+AKAAoACgAKAAoACgAKAAoACgAKA-Usage Type+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-Data
+AKAAoACgAKAAoACgAKAAoA-wMaxPacketSize+AKAAoACgAKAAoA-0x0040+AKAAoA-1x 64 bytes
+AKAAoACgAKAAoACgAKAAoA-bInterval+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-0
+AKAAoACgAKAAoACg-Endpoint Descriptor:
+AKAAoACgAKAAoACgAKAAoA-bLength+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoA-7
+AKAAoACgAKAAoACgAKAAoA-bDescriptorType+AKAAoACgAKAAoACgAKAAoACg-5
+AKAAoACgAKAAoACgAKAAoA-bEndpointAddress+AKAAoACgAKAAoA-0x06+AKAAoA-EP 6 OUT
+AKAAoACgAKAAoACgAKAAoA-bmAttributes+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-2
+AKAAoACgAKAAoACgAKAAoACgAKA-Transfer Type+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-Bulk
+AKAAoACgAKAAoACgAKAAoACgAKA-Synch Type+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-None
+AKAAoACgAKAAoACgAKAAoACgAKA-Usage Type+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-Data
+AKAAoACgAKAAoACgAKAAoA-wMaxPacketSize+AKAAoACgAKAAoA-0x0040+AKAAoA-1x 64 bytes
+AKAAoACgAKAAoACgAKAAoA-bInterval+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-0
Device Qualifier (for other device speed):
+AKA- bLength+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKA-10
+AKA- bDescriptorType+AKAAoACgAKAAoACgAKAAoACg-6
+AKA- bcdUSB+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-2.00
+AKA- bDeviceClass+AKAAoACgAKAAoACgAKAAoACgAKA-255+AKA-
+AKA- bDeviceSubClass+AKAAoACgAKAAoACgAKA-255+AKA-
+AKA- bDeviceProtocol+AKAAoACgAKAAoACgAKA-255+AKA-
+AKA- bMaxPacketSize0+AKAAoACgAKAAoACgAKAAoA-64
+AKA- bNumConfigurations+AKAAoACgAKAAoACg-1
can't get debug descriptor: Resource temporarily unavailable
Device Status:+AKAAoACgAKAAoA-0x0000
+AKA- (Bus Powered)

Bus 002 Device 001: ID 1d6b:0001+AKAAoA-
Device Descriptor:
+AKA- bLength+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKA-18
+AKA- bDescriptorType+AKAAoACgAKAAoACgAKAAoACg-1
+AKA- bcdUSB+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-1.10
+AKA- bDeviceClass+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-9+AKA-
+AKA- bDeviceSubClass+AKAAoACgAKAAoACgAKAAoACg-0+AKA-
+AKA- bDeviceProtocol+AKAAoACgAKAAoACgAKAAoACg-0+AKA-
+AKA- bMaxPacketSize0+AKAAoACgAKAAoACgAKAAoA-64
+AKA- idVendor+AKAAoACgAKAAoACgAKAAoACgAKAAoA-0x1d6b+AKA-
+AKA- idProduct+AKAAoACgAKAAoACgAKAAoACgAKA-0x0001+AKA-
+AKA- bcdDevice+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-4.06
+AKA- iManufacturer+AKAAoACgAKAAoACgAKAAoACgAKAAoA-3 Linux 4.6.3 ohci+AF8-hcd
+AKA- iProduct+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKA-2 Generic Platform OHCI controller
+AKA- iSerial+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoA-1 e0060000.ohci
+AKA- bNumConfigurations+AKAAoACgAKAAoACg-1
+AKA- Configuration Descriptor:
+AKAAoACgAKA-bLength+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoA-9
+AKAAoACgAKA-bDescriptorType+AKAAoACgAKAAoACgAKAAoACg-2
+AKAAoACgAKA-wTotalLength+AKAAoACgAKAAoACgAKAAoACgAKAAoA-25
+AKAAoACgAKA-bNumInterfaces+AKAAoACgAKAAoACgAKAAoACgAKA-1
+AKAAoACgAKA-bConfigurationValue+AKAAoACgAKAAoA-1
+AKAAoACgAKA-iConfiguration+AKAAoACgAKAAoACgAKAAoACgAKA-0+AKA-
+AKAAoACgAKA-bmAttributes+AKAAoACgAKAAoACgAKAAoACg-0xe0
+AKAAoACgAKAAoACg-Self Powered
+AKAAoACgAKAAoACg-Remote Wakeup
+AKAAoACgAKA-MaxPower+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKA-0mA
+AKAAoACgAKA-Interface Descriptor:
+AKAAoACgAKAAoACg-bLength+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoA-9
+AKAAoACgAKAAoACg-bDescriptorType+AKAAoACgAKAAoACgAKAAoACg-4
+AKAAoACgAKAAoACg-bInterfaceNumber+AKAAoACgAKAAoACgAKAAoA-0
+AKAAoACgAKAAoACg-bAlternateSetting+AKAAoACgAKAAoACgAKA-0
+AKAAoACgAKAAoACg-bNumEndpoints+AKAAoACgAKAAoACgAKAAoACgAKAAoA-1
+AKAAoACgAKAAoACg-bInterfaceClass+AKAAoACgAKAAoACgAKAAoACg-9+AKA-
+AKAAoACgAKAAoACg-bInterfaceSubClass+AKAAoACgAKAAoACg-0+AKA-
+AKAAoACgAKAAoACg-bInterfaceProtocol+AKAAoACgAKAAoACg-0+AKA-
+AKAAoACgAKAAoACg-iInterface+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoA-0+AKA-
+AKAAoACgAKAAoACg-Endpoint Descriptor:
+AKAAoACgAKAAoACgAKAAoA-bLength+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoA-7
+AKAAoACgAKAAoACgAKAAoA-bDescriptorType+AKAAoACgAKAAoACgAKAAoACg-5
+AKAAoACgAKAAoACgAKAAoA-bEndpointAddress+AKAAoACgAKAAoA-0x81+AKAAoA-EP 1 IN
+AKAAoACgAKAAoACgAKAAoA-bmAttributes+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-3
+AKAAoACgAKAAoACgAKAAoACgAKA-Transfer Type+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-Interrupt
+AKAAoACgAKAAoACgAKAAoACgAKA-Synch Type+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-None
+AKAAoACgAKAAoACgAKAAoACgAKA-Usage Type+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-Data
+AKAAoACgAKAAoACgAKAAoA-wMaxPacketSize+AKAAoACgAKAAoA-0x0002+AKAAoA-1x 2 bytes
+AKAAoACgAKAAoACgAKAAoA-bInterval+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKA-255
Hub Descriptor:
+AKA- bLength+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-9
+AKA- bDescriptorType+AKAAoACgAKAAoACg-41
+AKA- nNbrPorts+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKA-1
+AKA- wHubCharacteristic 0x0002
+AKAAoACgAKA-No power switching (usb 1.0)
+AKAAoACgAKA-Ganged overcurrent protection
+AKA- bPwrOn2PwrGood+AKAAoACgAKAAoACgAKAAoA-2 +ACo- 2 milli seconds
+AKA- bHubContrCurrent+AKAAoACgAKAAoACg-0 milli Ampere
+AKA- DeviceRemovable+AKAAoACgAKA-0x00
+AKA- PortPwrCtrlMask+AKAAoACgAKA-0xff
+AKA-Hub Port Status:
+AKAAoACg-Port 1: 0000.0103 power enable connect
can't get debug descriptor: Resource temporarily unavailable
Device Status:+AKAAoACgAKAAoA-0x0001
+AKA- Self Powered

Bus 001 Device 001: ID 1d6b:0002+AKAAoA-
Device Descriptor:
+AKA- bLength+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKA-18
+AKA- bDescriptorType+AKAAoACgAKAAoACgAKAAoACg-1
+AKA- bcdUSB+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-2.00
+AKA- bDeviceClass+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-9+AKA-
+AKA- bDeviceSubClass+AKAAoACgAKAAoACgAKAAoACg-0+AKA-
+AKA- bDeviceProtocol+AKAAoACgAKAAoACgAKAAoACg-0+AKA-
+AKA- bMaxPacketSize0+AKAAoACgAKAAoACgAKAAoA-64
+AKA- idVendor+AKAAoACgAKAAoACgAKAAoACgAKAAoA-0x1d6b+AKA-
+AKA- idProduct+AKAAoACgAKAAoACgAKAAoACgAKA-0x0002+AKA-
+AKA- bcdDevice+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-4.06
+AKA- iManufacturer+AKAAoACgAKAAoACgAKAAoACgAKAAoA-3 Linux 4.6.3 ehci+AF8-hcd
+AKA- iProduct+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKA-2 EHCI Host Controller
+AKA- iSerial+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoA-1 e0040000.ehci
+AKA- bNumConfigurations+AKAAoACgAKAAoACg-1
+AKA- Configuration Descriptor:
+AKAAoACgAKA-bLength+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoA-9
+AKAAoACgAKA-bDescriptorType+AKAAoACgAKAAoACgAKAAoACg-2
+AKAAoACgAKA-wTotalLength+AKAAoACgAKAAoACgAKAAoACgAKAAoA-25
+AKAAoACgAKA-bNumInterfaces+AKAAoACgAKAAoACgAKAAoACgAKA-1
+AKAAoACgAKA-bConfigurationValue+AKAAoACgAKAAoA-1
+AKAAoACgAKA-iConfiguration+AKAAoACgAKAAoACgAKAAoACgAKA-0+AKA-
+AKAAoACgAKA-bmAttributes+AKAAoACgAKAAoACgAKAAoACg-0xe0
+AKAAoACgAKAAoACg-Self Powered
+AKAAoACgAKAAoACg-Remote Wakeup
+AKAAoACgAKA-MaxPower+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKA-0mA
+AKAAoACgAKA-Interface Descriptor:
+AKAAoACgAKAAoACg-bLength+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoA-9
+AKAAoACgAKAAoACg-bDescriptorType+AKAAoACgAKAAoACgAKAAoACg-4
+AKAAoACgAKAAoACg-bInterfaceNumber+AKAAoACgAKAAoACgAKAAoA-0
+AKAAoACgAKAAoACg-bAlternateSetting+AKAAoACgAKAAoACgAKA-0
+AKAAoACgAKAAoACg-bNumEndpoints+AKAAoACgAKAAoACgAKAAoACgAKAAoA-1
+AKAAoACgAKAAoACg-bInterfaceClass+AKAAoACgAKAAoACgAKAAoACg-9+AKA-
+AKAAoACgAKAAoACg-bInterfaceSubClass+AKAAoACgAKAAoACg-0+AKA-
+AKAAoACgAKAAoACg-bInterfaceProtocol+AKAAoACgAKAAoACg-0+AKA-
+AKAAoACgAKAAoACg-iInterface+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoA-0+AKA-
+AKAAoACgAKAAoACg-Endpoint Descriptor:
+AKAAoACgAKAAoACgAKAAoA-bLength+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoA-7
+AKAAoACgAKAAoACgAKAAoA-bDescriptorType+AKAAoACgAKAAoACgAKAAoACg-5
+AKAAoACgAKAAoACgAKAAoA-bEndpointAddress+AKAAoACgAKAAoA-0x81+AKAAoA-EP 1 IN
+AKAAoACgAKAAoACgAKAAoA-bmAttributes+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-3
+AKAAoACgAKAAoACgAKAAoACgAKA-Transfer Type+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-Interrupt
+AKAAoACgAKAAoACgAKAAoACgAKA-Synch Type+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-None
+AKAAoACgAKAAoACgAKAAoACgAKA-Usage Type+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-Data
+AKAAoACgAKAAoACgAKAAoA-wMaxPacketSize+AKAAoACgAKAAoA-0x0004+AKAAoA-1x 4 bytes
+AKAAoACgAKAAoACgAKAAoA-bInterval+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoA-12
Hub Descriptor:
+AKA- bLength+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-9
+AKA- bDescriptorType+AKAAoACgAKAAoACg-41
+AKA- nNbrPorts+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKA-1
+AKA- wHubCharacteristic 0x0009
+AKAAoACgAKA-Per-port power switching
+AKAAoACgAKA-Per-port overcurrent protection
+AKA- bPwrOn2PwrGood+AKAAoACgAKAAoACgAKA-10 +ACo- 2 milli seconds
+AKA- bHubContrCurrent+AKAAoACgAKAAoACg-0 milli Ampere
+AKA- DeviceRemovable+AKAAoACgAKA-0x00
+AKA- PortPwrCtrlMask+AKAAoACgAKA-0xff
+AKA-Hub Port Status:
+AKAAoACg-Port 1: 0000.0100 power
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
Device Status:+AKAAoACgAKAAoA-0x0001
+AKA- Self Powered
--------------------------+AD4-8---------------------------

+AD4- and it will be
+AD4- interesting to see, which usb endpoint was actualy used.

Any hints on how may I get this information?

-Alexey

2016-07-06 08:32:05

by Alexey Brodkin

[permalink] [raw]
Subject: Re: ath9k-htc on OHCI -> bogus usb xfer

Hi+AKA-Oleksij,

On Wed, 2016-07-06 at 10:24 +-0200, fixed-term.Oleksij.Rempel wrote:
+AD4AoA-
+AD4- Hm... this Endpoint should be Interrupt, not Bulk. If you search for
+AD4- lsusb of this kind of adapter all of them list EP3 and EP4 as Interrupt.
+AD4-
+AD4- what did went wrong here? Is it not working in USB High Speed mode?

Unfortunately as of now on that board EHCI doesn't work.

That's not a problem of a particular USB device but something in either
ECHI host controller or its integration. I do hope we will fix it sometime soon
(this is a development board and USB controller is implemented in FPGA so
there's a chance to fix stuff later on).

So given only OHCI works on the board I went forward and attempted to use it
with Wi-Fi USB dongle.

-Alexey

2016-07-05 17:31:38

by Alexey Brodkin

[permalink] [raw]
Subject: Re: ath9k-htc on OHCI -> bogus usb xfer

Hi Oleksij,

On Tue, 2016-07-05 at 19:23 +-0200, Oleksij Rempel wrote:
+AD4- Hi,
+AD4-
+AD4- Am 05.07.2016 um 14:20 schrieb Alexey Brodkin:
+AD4- +AD4-
+AD4- +AD4- Hello,
+AD4- +AD4-
+AD4- +AD4- Looks like this is another manifestation of already seen problem with ath9k-htc
+AD4- +AD4- and OHCI controller.
+AD4- +AD4-
+AD4- +AD4- I'm trying to get USB Wi-Fi dongle based on Atheros AR9271 to work with our
+AD4- +AD4- development board (this is Synopsys AXS103) and seeing a picture very similar to
+AD4- +AD4- what was discussed here http://thread.gmane.org/gmane.linux.usb.general/110847
+AD4- +AD4-
+AD4- +AD4- Below is what I see on insertion of the dongle.
+AD4- +AD4- Note I have the most recent ath9k-htc firmware (see +ACI-ath9k+AF8-htc/htc+AF8-9271-1.4.0.fw+ACI-
+AD4- +AD4- in the log below) and Linux kernel is 4.6.3 (latest stable as of today) but the same
+AD4- +AD4- happens even on 4.4.
+AD4- +AD4-
+AD4- +AD4- Interesting enough if I simply remove or disable the warning like that
+AD4- +AD4- ------------------------+AD4-8---------------------------
+AD4- +AD4- diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c
+AD4- +AD4- index 3d27477..a317e1e 100644
+AD4- +AD4- --- a/drivers/usb/core/urb.c
+AD4- +AD4- +-+-+- b/drivers/usb/core/urb.c
+AD4- +AD4- +AEAAQA- -443,11 +-443,6 +AEAAQA- int usb+AF8-submit+AF8-urb(struct urb +ACo-urb, gfp+AF8-t mem+AF8-flags)
+AD4- +AD4- +AKAAoACgAKAAoACgAKAAoACgACo- cause problems in HCDs if they get it wrong.
+AD4- +AD4- +AKAAoACgAKAAoACgAKAAoACgACo-/
+AD4- +AD4- +AKA-
+AD4- +AD4- -+AKAAoACgAKAAoACgAKA-/+ACo- Check that the pipe's type matches the endpoint's type +ACo-/
+AD4- +AD4- -+AKAAoACgAKAAoACgAKA-if (usb+AF8-pipetype(urb-+AD4-pipe) +ACEAPQ- pipetypes+AFs-xfertype+AF0-)
+AD4- +AD4- -+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-dev+AF8-WARN(+ACY-dev-+AD4-dev, +ACI-BOGUS urb xfer, pipe +ACU-x +ACEAPQ- type +ACU-x+AFw-n+ACI-,
+AD4- +AD4- -+AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoA-usb+AF8-pipetype(urb-+AD4-pipe), pipetypes+AFs-xfertype+AF0-)+ADs-
+AD4- +AD4- -
+AD4- +AD4- +AKAAoACgAKAAoACgAKAAoA-/+ACo- Check against a simple/standard policy +ACo-/
+AD4- +AD4- +AKAAoACgAKAAoACgAKAAoA-allowed +AD0- (URB+AF8-NO+AF8-TRANSFER+AF8-DMA+AF8-MAP +AHw- URB+AF8-NO+AF8-INTERRUPT +AHw- URB+AF8-DIR+AF8-MASK +AHw-
+AD4- +AD4- +AKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACgAKAAoACg-URB+AF8-FREE+AF8-BUFFER)+ADs-
+AD4- +AD4- ------------------------+AD4-8---------------------------
+AD4- +AD4- everything seem to work quite nice.
+AD4- +AD4-
+AD4- +AD4- Any thoughts are much appreciated.
+AD4- +AD4-
+AD4- +AD4- That's the log itself:
+AD4- +AD4- ------------------------+AD4-8---------------------------
+AD4- +AD4- usb 1-1: new full-speed USB device number 2 using ohci-platform
+AD4- +AD4- usb 1-1: ath9k+AF8-htc: Firmware ath9k+AF8-htc/htc+AF8-9271-1.4.0.fw requested
+AD4- +AD4- usb 1-1: ath9k+AF8-htc: Transferred FW: ath9k+AF8-htc/htc+AF8-9271-1.4.0.fw, size: 51008
+AD4- +AD4- ------------+AFs- cut here +AF0-------------
+AD4- +AD4- WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb+AF8-submit+AF8-urb+-0x162/0x404
+AD4- +AD4- usb 1-1: BOGUS urb xfer, pipe 1 +ACEAPQ- type 3
+AD4- +AD4- Modules linked in:
+AD4- +AD4- CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 4.6.3 +ACM-10
+AD4- +AD4- Workqueue: events request+AF8-firmware+AF8-work+AF8-func
+AD4- +AD4-
+AD4- +AD4- Stack Trace:
+AD4- +AD4- +AKA- arc+AF8-unwind+AF8-core.constprop.1+-0x94/0x10c
+AD4- +AD4- ---+AFs- end trace 2249b79eac9991d1 +AF0----
+AD4- +AD4- ------------+AFs- cut here +AF0-------------
+AD4- +AD4- WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb+AF8-submit+AF8-urb+-0x162/0x404
+AD4- +AD4- usb 1-1: BOGUS urb xfer, pipe 1 +ACEAPQ- type 3
+AD4- +AD4- Modules linked in:
+AD4- +AD4- CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G+AKAAoACgAKAAoACgAKAAoA-W+AKAAoACgAKAAoACgAKA-4.6.3 +ACM-10
+AD4- +AD4- Workqueue: events request+AF8-firmware+AF8-work+AF8-func
+AD4- +AD4-
+AD4- +AD4- Stack Trace:
+AD4- +AD4- +AKA- arc+AF8-unwind+AF8-core.constprop.1+-0x94/0x10c
+AD4- +AD4- ---+AFs- end trace 2249b79eac9991d2 +AF0----
+AD4- +AD4- ------------+AFs- cut here +AF0-------------
+AD4- +AD4- WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb+AF8-submit+AF8-urb+-0x162/0x404
+AD4- +AD4- usb 1-1: BOGUS urb xfer, pipe 1 +ACEAPQ- type 3
+AD4- +AD4- Modules linked in:
+AD4- +AD4- CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G+AKAAoACgAKAAoACgAKAAoA-W+AKAAoACgAKAAoACgAKA-4.6.3 +ACM-10
+AD4- +AD4- Workqueue: events request+AF8-firmware+AF8-work+AF8-func
+AD4- +AD4-
+AD4- +AD4- Stack Trace:
+AD4- +AD4- +AKA- arc+AF8-unwind+AF8-core.constprop.1+-0x94/0x10c
+AD4- +AD4- ---+AFs- end trace 2249b79eac9991d3 +AF0----
+AD4- +AD4-
+AD4-
+AD4- please send content of hif+AF8-usb+AF8-send+AF8-regout() from your source code.
+AD4- It is located in drivers/net/wireless/ath/ath9k/hif+AF8-usb.c

I use vanilla 4.6.3 tree so that's what I have is the same as
http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/net/wireless/ath/ath9k/hif+AF8-usb.c?h+AD0-linu
x-4.6.y+ACM-n99

-Alexey

2016-07-07 05:16:14

by Alexey Brodkin

[permalink] [raw]
Subject: Re: ath9k-htc on OHCI -> bogus usb xfer

Hi+AKA-Oleksij,

On Wed, 2016-07-06 at 12:32 +-0200, fixed-term.Oleksij.Rempel wrote:
+AD4-
+AD4- On 06.07.2016 11:30, Alexey Brodkin wrote:
+AD4- +AD4-
+AD4- +AD4- Hi Oleksij,
+AD4- +AD4-
+AD4- +AD4- On Wed, 2016-07-06 at 11:09 +-0200, fixed-term.Oleksij.Rempel wrote:
+AD4- +AD4- +AD4-
+AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- On 06.07.2016 10:45, Alexey Brodkin wrote:
+AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- Hi Oleksij,
+AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- On Wed, 2016-07-06 at 10:38 +-0200, fixed-term.Oleksij.Rempel wrote:
+AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- On 06.07.2016 10:32, Alexey Brodkin wrote:
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- Hi Oleksij,
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- On Wed, 2016-07-06 at 10:24 +-0200, fixed-term.Oleksij.Rempel wrote:
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AKA-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- Hm... this Endpoint should be Interrupt, not Bulk. If you search for
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- lsusb of this kind of adapter all of them list EP3 and EP4 as Interrupt.
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- what did went wrong here? Is it not working in USB High Speed mode?
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- Unfortunately as of now on that board EHCI doesn't work.
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- That's not a problem of a particular USB device but something in either
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- ECHI host controller or its integration. I do hope we will fix it sometime soon
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- (this is a development board and USB controller is implemented in FPGA so
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- there's a chance to fix stuff later on).
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- So given only OHCI works on the board I went forward and attempted to use it
+AD4- +AD4- +AD4- +AD4- +AD4- +AD4- with Wi-Fi USB dongle.
+AD4- +AD4- +AD4- +AD4- +AD4- I did some tests for 2 years on OHCI controller on x86. There was no
+AD4- +AD4- +AD4- +AD4- +AD4- noticable issues. It was even a bit faster then Intels EHCI. I don't
+AD4- +AD4- +AD4- +AD4- +AD4- think OHCI alone is the source of this problem.
+AD4- +AD4- +AD4- +AD4- Well I was also surprised how well that dongle works with that board in
+AD4- +AD4- +AD4- +AD4- OHCI mode. I saw quite consistent +AH4-4-5 Mbit/second rates when doing Speedtest
+AD4- +AD4- +AD4- +AD4- from my smartphone. So IMHO it's completely usable. Especially on that kind of
+AD4- +AD4- +AD4- +AD4- HW which has main CPU running at just 100MHz.
+AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- On other side, so far i know, this adapter claims to provide usb full
+AD4- +AD4- +AD4- +AD4- +AD4- speed support, (Not only high speed) and may use different usb
+AD4- +AD4- +AD4- +AD4- +AD4- descriptor for this. May be this is the problem.
+AD4- +AD4- +AD4- +AD4- So is there something we may do with all that?
+AD4- +AD4- +AD4- Sure...
+AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- This shows that EP4 is Bluk in full speed mode. And it is defined by a
+AD4- +AD4- +AD4- boot loader of this chip:
+AD4- +AD4- +AD4- grep -R USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE +ACo-
+AD4- +AD4- +AD4- sboot/magpie+AF8-1+AF8-1/sboot/hif/usb/src/usb+AF8-table.c:
+AD4- +AD4- +AD4- m2BYTE(USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE, USB+AF8-FS+AF8-EP4+AF8-MAX+AF8-PACKET+AF8-SIZE),
+AD4- +AD4- +AD4- sboot/magpie+AF8-1+AF8-1/sboot/hif/usb/src/usb+AF8-table.h:+ACM-define
+AD4- +AD4- +AD4- USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-bUSB+AF8-EP+AF8-TYPE+AF8-BULK
+AD4- +AD4- +AD4- sboot/magpie+AF8-1+AF8-1/inc/usb+AF8-table.h:+ACM-define USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE
+AD4- +AD4- +AD4- +AKA-bUSB+AF8-EP+AF8-TYPE+AF8-BULK
+AD4- +AD4- +AD4- target+AF8-firmware/magpie+AF8-fw+AF8-dev/target/inc/k2/usb+AF8-table.h:+ACM-define
+AD4- +AD4- +AD4- USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-bUSB+AF8-EP+AF8-TYPE+AF8-BULK
+AD4- +AD4- +AD4- target+AF8-firmware/magpie+AF8-fw+AF8-dev/target/inc/magpie/usb+AF8-table.h:+ACM-define
+AD4- +AD4- +AD4- USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-bUSB+AF8-EP+AF8-TYPE+AF8-BULK
+AD4- +AD4- +AD4-
+AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- So, there are fallowing variants to fix it:
+AD4- +AD4- +AD4- a) patch full speed usb descriptor in firmware and add usb reinit
+AD4- +AD4- +AD4- support to the driver.
+AD4- +AD4- +AD4- b) add support of different EP4 types.
+AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- In any case, some one need to implement it... right now i have time only
+AD4- +AD4- +AD4- for mentoring.
+AD4- +AD4- That's understood.
+AD4- +AD4-
+AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- It is hard to say, which solution is better. It will affect performance
+AD4- +AD4- +AD4- and stability. We will need lots of testing on different HW variants to
+AD4- +AD4- +AD4- know it.
+AD4- +AD4- +AD4- May be usb maeling list can give some input here?
+AD4- +AD4- Let's hope so :)
+AD4- +AD4-
+AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- Currently we have fallowing issues:
+AD4- +AD4- +AD4- - if EP4 and EP3 are Interrupt, it works slower on High Speed controller.
+AD4- +AD4- +AD4- - if EP4 and EP3 are Bulk, the work better on High Speed and brake on
+AD4- +AD4- +AD4- Super Speed controllers. This adapter support my 64B packets and if we
+AD4- +AD4- +AD4- have more, fifo of this adapter will overrun.
+AD4- +AD4- +AD4- - Full Speed is currently unknown field for me, and it looks like it was
+AD4- +AD4- +AD4- never actually working properly.
+AD4- +AD4- But given that dongle seem to work fine with muted warning do you think it's
+AD4- +AD4- fine to continue that way or not?
+AD4- +AD4-
+AD4- +AD4- I mean if there's a chance this +ACI-bogus usb xfer+ACI- might affect something during
+AD4- +AD4- execution? Otherwise if that's just not a crucial problem or not a problem at all
+AD4- +AD4- may be we may just think how to make this warning not so annoying (in my case
+AD4- +AD4- I saw never ending flood of those warnings so that basically stopped me from using
+AD4- +AD4- the board after that warning started to appear.
+AD4-
+AD4- I'll answer with an example:
+AD4- on USB3 hw this warning was ignore and caused hard reproducible bug
+AD4- which cost me some week to debug. The result was a FIFO overflow on
+AD4- adapter side.

Yeah that makes a perfect sense then.
Let's see if there're any other suggestions on the topic.

-Alexey

2016-07-05 19:02:50

by Oleksij Rempel

[permalink] [raw]
Subject: Re: ath9k-htc on OHCI -> bogus usb xfer

Am 05.07.2016 um 19:31 schrieb Alexey Brodkin:
> Hi Oleksij,
>
> On Tue, 2016-07-05 at 19:23 +0200, Oleksij Rempel wrote:
>> Hi,
>>
>> Am 05.07.2016 um 14:20 schrieb Alexey Brodkin:
>>>
>>> Hello,
>>>
>>> Looks like this is another manifestation of already seen problem with ath9k-htc
>>> and OHCI controller.
>>>
>>> I'm trying to get USB Wi-Fi dongle based on Atheros AR9271 to work with our
>>> development board (this is Synopsys AXS103) and seeing a picture very similar to
>>> what was discussed here http://thread.gmane.org/gmane.linux.usb.general/110847
>>>
>>> Below is what I see on insertion of the dongle.
>>> Note I have the most recent ath9k-htc firmware (see "ath9k_htc/htc_9271-1.4.0.fw"
>>> in the log below) and Linux kernel is 4.6.3 (latest stable as of today) but the same
>>> happens even on 4.4.
>>>
>>> Interesting enough if I simply remove or disable the warning like that
>>> ------------------------>8---------------------------
>>> diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c
>>> index 3d27477..a317e1e 100644
>>> --- a/drivers/usb/core/urb.c
>>> +++ b/drivers/usb/core/urb.c
>>> @@ -443,11 +443,6 @@ int usb_submit_urb(struct urb *urb, gfp_t mem_flags)
>>> * cause problems in HCDs if they get it wrong.
>>> */
>>>
>>> - /* Check that the pipe's type matches the endpoint's type */
>>> - if (usb_pipetype(urb->pipe) != pipetypes[xfertype])
>>> - dev_WARN(&dev->dev, "BOGUS urb xfer, pipe %x != type %x\n",
>>> - usb_pipetype(urb->pipe), pipetypes[xfertype]);
>>> -
>>> /* Check against a simple/standard policy */
>>> allowed = (URB_NO_TRANSFER_DMA_MAP | URB_NO_INTERRUPT | URB_DIR_MASK |
>>> URB_FREE_BUFFER);
>>> ------------------------>8---------------------------
>>> everything seem to work quite nice.
>>>
>>> Any thoughts are much appreciated.
>>>
>>> That's the log itself:
>>> ------------------------>8---------------------------
>>> usb 1-1: new full-speed USB device number 2 using ohci-platform
>>> usb 1-1: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested
>>> usb 1-1: ath9k_htc: Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 51008
>>> ------------[ cut here ]------------
>>> WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb_submit_urb+0x162/0x404
>>> usb 1-1: BOGUS urb xfer, pipe 1 != type 3
>>> Modules linked in:
>>> CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 4.6.3 #10
>>> Workqueue: events request_firmware_work_func
>>>
>>> Stack Trace:
>>> arc_unwind_core.constprop.1+0x94/0x10c
>>> ---[ end trace 2249b79eac9991d1 ]---
>>> ------------[ cut here ]------------
>>> WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb_submit_urb+0x162/0x404
>>> usb 1-1: BOGUS urb xfer, pipe 1 != type 3
>>> Modules linked in:
>>> CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G W 4.6.3 #10
>>> Workqueue: events request_firmware_work_func
>>>
>>> Stack Trace:
>>> arc_unwind_core.constprop.1+0x94/0x10c
>>> ---[ end trace 2249b79eac9991d2 ]---
>>> ------------[ cut here ]------------
>>> WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb_submit_urb+0x162/0x404
>>> usb 1-1: BOGUS urb xfer, pipe 1 != type 3
>>> Modules linked in:
>>> CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G W 4.6.3 #10
>>> Workqueue: events request_firmware_work_func
>>>
>>> Stack Trace:
>>> arc_unwind_core.constprop.1+0x94/0x10c
>>> ---[ end trace 2249b79eac9991d3 ]---
>>>
>>
>> please send content of hif_usb_send_regout() from your source code.
>> It is located in drivers/net/wireless/ath/ath9k/hif_usb.c
>
> I use vanilla 4.6.3 tree so that's what I have is the same as
> http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/net/wireless/ath/ath9k/hif_usb.c?h=linu
> x-4.6.y#n99

Interesting.
Can you please send lsusb -v for this adapter? and it will be
interesting to see, which usb endpoint was actualy used.

--
Regards,
Oleksij

Attachments:
signature.asc (213.00 B)
OpenPGP digital signature

2016-07-06 08:46:00

by Alexey Brodkin

[permalink] [raw]
Subject: Re: ath9k-htc on OHCI -> bogus usb xfer

Hi+AKA-Oleksij,

On Wed, 2016-07-06 at 10:38 +-0200, fixed-term.Oleksij.Rempel wrote:
+AD4-
+AD4- On 06.07.2016 10:32, Alexey Brodkin wrote:
+AD4- +AD4-
+AD4- +AD4- Hi Oleksij,
+AD4- +AD4-
+AD4- +AD4- On Wed, 2016-07-06 at 10:24 +-0200, fixed-term.Oleksij.Rempel wrote:
+AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AKA-
+AD4- +AD4- +AD4- Hm... this Endpoint should be Interrupt, not Bulk. If you search for
+AD4- +AD4- +AD4- lsusb of this kind of adapter all of them list EP3 and EP4 as Interrupt.
+AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- what did went wrong here? Is it not working in USB High Speed mode?
+AD4- +AD4- Unfortunately as of now on that board EHCI doesn't work.
+AD4- +AD4-
+AD4- +AD4- That's not a problem of a particular USB device but something in either
+AD4- +AD4- ECHI host controller or its integration. I do hope we will fix it sometime soon
+AD4- +AD4- (this is a development board and USB controller is implemented in FPGA so
+AD4- +AD4- there's a chance to fix stuff later on).
+AD4- +AD4-
+AD4- +AD4- So given only OHCI works on the board I went forward and attempted to use it
+AD4- +AD4- with Wi-Fi USB dongle.
+AD4-
+AD4- I did some tests for 2 years on OHCI controller on x86. There was no
+AD4- noticable issues. It was even a bit faster then Intels EHCI. I don't
+AD4- think OHCI alone is the source of this problem.

Well I was also surprised how well that dongle works with that board in
OHCI mode. I saw quite consistent +AH4-4-5 Mbit/second rates when doing Speedtest
from my smartphone. So IMHO it's completely usable. Especially on that kind of
HW which has main CPU running at just 100MHz.

+AD4- On other side, so far i know, this adapter claims to provide usb full
+AD4- speed support, (Not only high speed) and may use different usb
+AD4- descriptor for this. May be this is the problem.

So is there something we may do with all that?

-Alexey

2016-07-06 09:30:33

by Alexey Brodkin

[permalink] [raw]
Subject: Re: ath9k-htc on OHCI -> bogus usb xfer

Hi+AKA-Oleksij,

On Wed, 2016-07-06 at 11:09 +-0200, fixed-term.Oleksij.Rempel wrote:
+AD4-
+AD4- On 06.07.2016 10:45, Alexey Brodkin wrote:
+AD4- +AD4-
+AD4- +AD4- Hi Oleksij,
+AD4- +AD4-
+AD4- +AD4- On Wed, 2016-07-06 at 10:38 +-0200, fixed-term.Oleksij.Rempel wrote:
+AD4- +AD4- +AD4-
+AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- On 06.07.2016 10:32, Alexey Brodkin wrote:
+AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- Hi Oleksij,
+AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- On Wed, 2016-07-06 at 10:24 +-0200, fixed-term.Oleksij.Rempel wrote:
+AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- +AKA-
+AD4- +AD4- +AD4- +AD4- +AD4- Hm... this Endpoint should be Interrupt, not Bulk. If you search for
+AD4- +AD4- +AD4- +AD4- +AD4- lsusb of this kind of adapter all of them list EP3 and EP4 as Interrupt.
+AD4- +AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- +AD4- what did went wrong here? Is it not working in USB High Speed mode?
+AD4- +AD4- +AD4- +AD4- Unfortunately as of now on that board EHCI doesn't work.
+AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- That's not a problem of a particular USB device but something in either
+AD4- +AD4- +AD4- +AD4- ECHI host controller or its integration. I do hope we will fix it sometime soon
+AD4- +AD4- +AD4- +AD4- (this is a development board and USB controller is implemented in FPGA so
+AD4- +AD4- +AD4- +AD4- there's a chance to fix stuff later on).
+AD4- +AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- +AD4- So given only OHCI works on the board I went forward and attempted to use it
+AD4- +AD4- +AD4- +AD4- with Wi-Fi USB dongle.
+AD4- +AD4- +AD4- I did some tests for 2 years on OHCI controller on x86. There was no
+AD4- +AD4- +AD4- noticable issues. It was even a bit faster then Intels EHCI. I don't
+AD4- +AD4- +AD4- think OHCI alone is the source of this problem.
+AD4- +AD4- Well I was also surprised how well that dongle works with that board in
+AD4- +AD4- OHCI mode. I saw quite consistent +AH4-4-5 Mbit/second rates when doing Speedtest
+AD4- +AD4- from my smartphone. So IMHO it's completely usable. Especially on that kind of
+AD4- +AD4- HW which has main CPU running at just 100MHz.
+AD4- +AD4-
+AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- On other side, so far i know, this adapter claims to provide usb full
+AD4- +AD4- +AD4- speed support, (Not only high speed) and may use different usb
+AD4- +AD4- +AD4- descriptor for this. May be this is the problem.
+AD4- +AD4- So is there something we may do with all that?
+AD4- Sure...
+AD4-
+AD4- This shows that EP4 is Bluk in full speed mode. And it is defined by a
+AD4- boot loader of this chip:
+AD4- grep -R USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE +ACo-
+AD4- sboot/magpie+AF8-1+AF8-1/sboot/hif/usb/src/usb+AF8-table.c:
+AD4- m2BYTE(USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE, USB+AF8-FS+AF8-EP4+AF8-MAX+AF8-PACKET+AF8-SIZE),
+AD4- sboot/magpie+AF8-1+AF8-1/sboot/hif/usb/src/usb+AF8-table.h:+ACM-define
+AD4- USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-bUSB+AF8-EP+AF8-TYPE+AF8-BULK
+AD4- sboot/magpie+AF8-1+AF8-1/inc/usb+AF8-table.h:+ACM-define USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE
+AD4- +AKA-bUSB+AF8-EP+AF8-TYPE+AF8-BULK
+AD4- target+AF8-firmware/magpie+AF8-fw+AF8-dev/target/inc/k2/usb+AF8-table.h:+ACM-define
+AD4- USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-bUSB+AF8-EP+AF8-TYPE+AF8-BULK
+AD4- target+AF8-firmware/magpie+AF8-fw+AF8-dev/target/inc/magpie/usb+AF8-table.h:+ACM-define
+AD4- USB+AF8-FS+AF8-EP4+AF8-ATTRIBUTE+AKAAoACgAKAAoACgAKAAoACgAKAAoACg-bUSB+AF8-EP+AF8-TYPE+AF8-BULK
+AD4-
+AD4-
+AD4- So, there are fallowing variants to fix it:
+AD4- a) patch full speed usb descriptor in firmware and add usb reinit
+AD4- support to the driver.
+AD4- b) add support of different EP4 types.
+AD4-
+AD4- In any case, some one need to implement it... right now i have time only
+AD4- for mentoring.

That's understood.

+AD4- It is hard to say, which solution is better. It will affect performance
+AD4- and stability. We will need lots of testing on different HW variants to
+AD4- know it.
+AD4- May be usb maeling list can give some input here?

Let's hope so :)

+AD4- Currently we have fallowing issues:
+AD4- - if EP4 and EP3 are Interrupt, it works slower on High Speed controller.
+AD4- - if EP4 and EP3 are Bulk, the work better on High Speed and brake on
+AD4- Super Speed controllers. This adapter support my 64B packets and if we
+AD4- have more, fifo of this adapter will overrun.
+AD4- - Full Speed is currently unknown field for me, and it looks like it was
+AD4- never actually working properly.

But given that dongle seem to work fine with muted warning do you think it's
fine to continue that way or not?

I mean if there's a chance this +ACI-bogus usb xfer+ACI- might affect something during
execution? Otherwise if that's just not a crucial problem or not a problem at all
may be we may just think how to make this warning not so annoying (in my case
I saw never ending flood of those warnings so that basically stopped me from using
the board after that warning started to appear.

-Alexey