ath9k-htc on OHCI -> bogus usb xfer

ath9k-htc on OHCI -> bogus usb xfer

[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 ]---

...
------------------------>8---------------------------

-Alexey

Re: ath9k-htc on OHCI -> bogus usb xfer

[Oleksij Rempel]

[-- Attachment #1.1: Type: text/plain, Size: 3438 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: ath9k-htc on OHCI -> bogus usb xfer

[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

-Alexey

Re: ath9k-htc on OHCI -> bogus usb xfer

[Oleksij Rempel]

[-- Attachment #1.1: Type: text/plain, Size: 4063 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: ath9k-htc on OHCI -> bogus usb xfer

[Alexey Brodkin]

Hi Oleksij,

On Tue, 2016-07-05 at 21:01 +0200, Oleksij Rempel wrote:
> 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?

See below:
-------------------------->8---------------------------
# lsusb -v

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

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

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

> and it will be
> interesting to see, which usb endpoint was actualy used.

Any hints on how may I get this information?

-Alexey

Re: ath9k-htc on OHCI -> bogus usb xfer

[Alexey Brodkin]

Hi Oleksij,

On Wed, 2016-07-06 at 10:24 +0200, fixed-term.Oleksij.Rempel wrote:
> 
> Hm... this Endpoint should be Interrupt, not Bulk. If you search for
> lsusb of this kind of adapter all of them list EP3 and EP4 as Interrupt.
> 
> 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

Re: ath9k-htc on OHCI -> bogus usb xfer

[Alexey Brodkin]

Hi Oleksij,

On Wed, 2016-07-06 at 10:38 +0200, fixed-term.Oleksij.Rempel wrote:
> 
> On 06.07.2016 10:32, Alexey Brodkin wrote:
> > 
> > Hi Oleksij,
> > 
> > On Wed, 2016-07-06 at 10:24 +0200, fixed-term.Oleksij.Rempel wrote:
> > > 
> > >  
> > > Hm... this Endpoint should be Interrupt, not Bulk. If you search for
> > > lsusb of this kind of adapter all of them list EP3 and EP4 as Interrupt.
> > > 
> > > 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.
>
> I did some tests for 2 years on OHCI controller on x86. There was no
> noticable issues. It was even a bit faster then Intels EHCI. I don't
> 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 ~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.

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

So is there something we may do with all that?

-Alexey

Re: ath9k-htc on OHCI -> bogus usb xfer

[Alexey Brodkin]

Hi Oleksij,

On Wed, 2016-07-06 at 11:09 +0200, fixed-term.Oleksij.Rempel wrote:
> 
> On 06.07.2016 10:45, Alexey Brodkin wrote:
> > 
> > Hi Oleksij,
> > 
> > On Wed, 2016-07-06 at 10:38 +0200, fixed-term.Oleksij.Rempel wrote:
> > > 
> > > 
> > > On 06.07.2016 10:32, Alexey Brodkin wrote:
> > > > 
> > > > 
> > > > Hi Oleksij,
> > > > 
> > > > On Wed, 2016-07-06 at 10:24 +0200, fixed-term.Oleksij.Rempel wrote:
> > > > > 
> > > > > 
> > > > >  
> > > > > Hm... this Endpoint should be Interrupt, not Bulk. If you search for
> > > > > lsusb of this kind of adapter all of them list EP3 and EP4 as Interrupt.
> > > > > 
> > > > > 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.
> > > I did some tests for 2 years on OHCI controller on x86. There was no
> > > noticable issues. It was even a bit faster then Intels EHCI. I don't
> > > 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 ~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.
> > 
> > > 
> > > On other side, so far i know, this adapter claims to provide usb full
> > > speed support, (Not only high speed) and may use different usb
> > > descriptor for this. May be this is the problem.
> > So is there something we may do with all that?
> Sure...
> 
> This shows that EP4 is Bluk in full speed mode. And it is defined by a
> boot loader of this chip:
> grep -R USB_FS_EP4_ATTRIBUTE *
> sboot/magpie_1_1/sboot/hif/usb/src/usb_table.c:
> m2BYTE(USB_FS_EP4_ATTRIBUTE, USB_FS_EP4_MAX_PACKET_SIZE),
> sboot/magpie_1_1/sboot/hif/usb/src/usb_table.h:#define
> USB_FS_EP4_ATTRIBUTE            bUSB_EP_TYPE_BULK
> sboot/magpie_1_1/inc/usb_table.h:#define USB_FS_EP4_ATTRIBUTE
>  bUSB_EP_TYPE_BULK
> target_firmware/magpie_fw_dev/target/inc/k2/usb_table.h:#define
> USB_FS_EP4_ATTRIBUTE            bUSB_EP_TYPE_BULK
> target_firmware/magpie_fw_dev/target/inc/magpie/usb_table.h:#define
> USB_FS_EP4_ATTRIBUTE            bUSB_EP_TYPE_BULK
> 
> 
> So, there are fallowing variants to fix it:
> a) patch full speed usb descriptor in firmware and add usb reinit
> support to the driver.
> b) add support of different EP4 types.
> 
> In any case, some one need to implement it... right now i have time only
> for mentoring.

That's understood.

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

Let's hope so :)

> Currently we have fallowing issues:
> - if EP4 and EP3 are Interrupt, it works slower on High Speed controller.
> - if EP4 and EP3 are Bulk, the work better on High Speed and brake on
> Super Speed controllers. This adapter support my 64B packets and if we
> have more, fifo of this adapter will overrun.
> - Full Speed is currently unknown field for me, and it looks like it was
> 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 "bogus usb xfer" 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

Re: ath9k-htc on OHCI -> bogus usb xfer

[Alexey Brodkin]

Hi Oleksij,

On Wed, 2016-07-06 at 12:32 +0200, fixed-term.Oleksij.Rempel wrote:
> 
> On 06.07.2016 11:30, Alexey Brodkin wrote:
> > 
> > Hi Oleksij,
> > 
> > On Wed, 2016-07-06 at 11:09 +0200, fixed-term.Oleksij.Rempel wrote:
> > > 
> > > 
> > > On 06.07.2016 10:45, Alexey Brodkin wrote:
> > > > 
> > > > 
> > > > Hi Oleksij,
> > > > 
> > > > On Wed, 2016-07-06 at 10:38 +0200, fixed-term.Oleksij.Rempel wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > On 06.07.2016 10:32, Alexey Brodkin wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Hi Oleksij,
> > > > > > 
> > > > > > On Wed, 2016-07-06 at 10:24 +0200, fixed-term.Oleksij.Rempel wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > >  
> > > > > > > Hm... this Endpoint should be Interrupt, not Bulk. If you search for
> > > > > > > lsusb of this kind of adapter all of them list EP3 and EP4 as Interrupt.
> > > > > > > 
> > > > > > > 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.
> > > > > I did some tests for 2 years on OHCI controller on x86. There was no
> > > > > noticable issues. It was even a bit faster then Intels EHCI. I don't
> > > > > 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 ~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.
> > > > 
> > > > > 
> > > > > 
> > > > > On other side, so far i know, this adapter claims to provide usb full
> > > > > speed support, (Not only high speed) and may use different usb
> > > > > descriptor for this. May be this is the problem.
> > > > So is there something we may do with all that?
> > > Sure...
> > > 
> > > This shows that EP4 is Bluk in full speed mode. And it is defined by a
> > > boot loader of this chip:
> > > grep -R USB_FS_EP4_ATTRIBUTE *
> > > sboot/magpie_1_1/sboot/hif/usb/src/usb_table.c:
> > > m2BYTE(USB_FS_EP4_ATTRIBUTE, USB_FS_EP4_MAX_PACKET_SIZE),
> > > sboot/magpie_1_1/sboot/hif/usb/src/usb_table.h:#define
> > > USB_FS_EP4_ATTRIBUTE            bUSB_EP_TYPE_BULK
> > > sboot/magpie_1_1/inc/usb_table.h:#define USB_FS_EP4_ATTRIBUTE
> > >  bUSB_EP_TYPE_BULK
> > > target_firmware/magpie_fw_dev/target/inc/k2/usb_table.h:#define
> > > USB_FS_EP4_ATTRIBUTE            bUSB_EP_TYPE_BULK
> > > target_firmware/magpie_fw_dev/target/inc/magpie/usb_table.h:#define
> > > USB_FS_EP4_ATTRIBUTE            bUSB_EP_TYPE_BULK
> > > 
> > > 
> > > So, there are fallowing variants to fix it:
> > > a) patch full speed usb descriptor in firmware and add usb reinit
> > > support to the driver.
> > > b) add support of different EP4 types.
> > > 
> > > In any case, some one need to implement it... right now i have time only
> > > for mentoring.
> > That's understood.
> > 
> > > 
> > > It is hard to say, which solution is better. It will affect performance
> > > and stability. We will need lots of testing on different HW variants to
> > > know it.
> > > May be usb maeling list can give some input here?
> > Let's hope so :)
> > 
> > > 
> > > Currently we have fallowing issues:
> > > - if EP4 and EP3 are Interrupt, it works slower on High Speed controller.
> > > - if EP4 and EP3 are Bulk, the work better on High Speed and brake on
> > > Super Speed controllers. This adapter support my 64B packets and if we
> > > have more, fifo of this adapter will overrun.
> > > - Full Speed is currently unknown field for me, and it looks like it was
> > > 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 "bogus usb xfer" 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.
>
> I'll answer with an example:
> on USB3 hw this warning was ignore and caused hard reproducible bug
> which cost me some week to debug. The result was a FIFO overflow on
> adapter side.

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

-Alexey