Re: btusb_intr_complete returns -EPIPE

2014-10-31 Thread Naveen Kumar Parna 
Hi ,

I tried on plenty of test servers(Fedora distribution) with USB-EHCI
and all these are having spurious STALL packets issue.

Today I got a test laptop(Ubuntu distribution) with USB-EHCI and
interestingly it does not report STALL packets. The only difference I
observed from lsusb is, Fedora test servers shows “Driver=ehci-pci/2p”
but Ubuntu Laptop shows “Driver=ehci-pci/3p”, but both has same EHCI
controller.


00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset
USB2 Enhanced Host Controller (rev 05)
00:1d.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset
USB2 Enhanced Host Controller (rev 05)


Fedora test server:
[lowerlayers@banunxcas29 epipe_debug]$ lsusb -t
1-1.5.1:1.2: No such file or directory
1-1.5.2:1.2: No such file or directory
1-1.5.3:1.2: No such file or directory
1-1.5.4:1.2: No such file or directory

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M

|__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/8p, 480M

|__ Port 1: Dev 3, If 0, Class=HID, Driver=usbhid, 12M

|__ Port 1: Dev 3, If 1, Class=HID, Driver=usbhid, 12M

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M

|__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/6p, 480M

|__ Port 5: Dev 112, If 0, Class=hub, Driver=hub/4p, 480M

|__ Port 1: Dev 113, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 1: Dev 113, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 1: Dev 113, If 2, Class=app., Driver=, 12M

|__ Port 2: Dev 114, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 2: Dev 114, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 2: Dev 114, If 2, Class=app., Driver=, 12M

|__ Port 3: Dev 115, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 3: Dev 115, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 3: Dev 115, If 2, Class=app., Driver=, 12M

|__ Port 4: Dev 116, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 4: Dev 116, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 4: Dev 116, If 2, Class=app., Driver=, 12M



Ubuntu Laptop:
root@sandeep-E6410:/home/sandeep# lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M

|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M

|__ Port 3: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M

|__ Port 1: Dev 5, If 0, Class=Wireless, Driver=btusb, 12M

|__ Port 1: Dev 5, If 1, Class=Wireless, Driver=btusb, 12M

|__ Port 1: Dev 5, If 2, Class=Application Specific
Interface, Driver=, 12M

|__ Port 2: Dev 6, If 0, Class=Wireless, Driver=btusb, 12M

|__ Port 2: Dev 6, If 1, Class=Wireless, Driver=btusb, 12M

|__ Port 2: Dev 6, If 2, Class=Application Specific
Interface, Driver=, 12M

|__ Port 3: Dev 7, If 0, Class=Wireless, Driver=btusb, 12M

|__ Port 3: Dev 7, If 1, Class=Wireless, Driver=btusb, 12M

|__ Port 3: Dev 7, If 2, Class=Application Specific
Interface, Driver=, 12M

|__ Port 4: Dev 8, If 0, Class=Wireless, Driver=btusb, 12M

|__ Port 4: Dev 8, If 1, Class=Wireless, Driver=btusb, 12M

|__ Port 4: Dev 8, If 2, Class=Application Specific
Interface, Driver=, 12M

|__ Port 8: Dev 3, If 0, Class=Application Specific Interface,
Driver=, 12M

|__ Port 8: Dev 3, If 1, Class=Chip/SmartCard, Driver=, 12M

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M

|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M

|__ Port 4: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M

|__ Port 4: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M


And in Fedora test servers Bluetooth devices are getting connected to
root_hub on the Bus-1, where as in Ubuntu Laptop these are getting
connected to root_hub on the Bus-2.


Does it gives any clue for the stall packet issue?

Thanks,
Naveen


lspci_nv_ubuntu
Description: Binary data


lspci_nv_fedora
Description: Binary data

Re: btusb_intr_complete returns -EPIPE

2014-11-04 Thread Naveen Kumar Parna 
>> >> Split packet transactions are hidden. I could see them by clicking on
>> >> the (Show/Hide Split transactions) button. For INT IN, I could see
>> >> only Start Split packet.
>> >>
>> >> I attached([2014-10-28 session 144012] Trace0003.rar) complete log for
>> >> this scenario.
>> >
>> > How come the log doesn't contain any SOF packets?
>>
>>
>> To avoid recording a huge quantity of data , I enabled the "Drop Start
>> of Frames" filter in the recording options.
>
> Can you do it again, but this time keep the SOF packets?
>
> You don't have to post the entire analyzer log.  Just extract 3 or 4 ms
> from the middle, where it shows the SSPLITS but no CSPLITS for the
> interrupt endpoints, and post only that portion.
>

I tried again, I keep getting STALL's but this time I see CSPLITS  for
the interrupt end points.

[root@banunxcas29 ns06]# lsusb -t
1-1.5.1:1.2: No such file or directory
1-1.5.2:1.2: No such file or directory
1-1.5.3:1.2: No such file or directory
1-1.5.4:1.2: No such file or directory
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/6p, 480M
|__ Port 5: Dev 51, If 0, Class=hub, Driver=hub/4p, 480M
|__ Port 1: Dev 52, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M
|__ Port 1: Dev 52, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M
|__ Port 1: Dev 52, If 2, Class=app., Driver=, 12M
|__ Port 2: Dev 53, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M
|__ Port 2: Dev 53, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M
|__ Port 2: Dev 53, If 2, Class=app., Driver=, 12M
|__ Port 3: Dev 56, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M
|__ Port 3: Dev 56, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M
|__ Port 3: Dev 56, If 2, Class=app., Driver=, 12M
|__ Port 4: Dev 55, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M
|__ Port 4: Dev 55, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M
|__ Port 4: Dev 55, If 2, Class=app., Driver=, 12M


Here Dev 51 is external USB-2 hub.


usbmon log:
8800b2cce6c0 1558099725 C Ii:1:055:1 -32:1 0
8800b2cce6c0 1558099740 S Ii:1:055:1 -115:1 16 <
8800b2cce6c0 1558435684 C Ii:1:055:1 -32:1 0
8800b2cce6c0 1558435700 S Ii:1:055:1 -115:1 16 <
8800b2cce6c0 1558447773 C Ii:1:055:1 -32:1 0
8800b2cce6c0 1558447790 S Ii:1:055:1 -115:1 16 <
8800b2cce6c0 1562003759 C Ii:1:055:1 -32:1 0
8800b2cce6c0 1562003777 S Ii:1:055:1 -115:1 16 <
8800b2cce6c0 1835091798 C Ii:1:055:1 -32:1 0
8800b2cce6c0 1835091818 S Ii:1:055:1 -115:1 16 <
8800b2cce6c0 2360295770 C Ii:1:055:1 -32:1 0
8800b2cce6c0 2360295785 S Ii:1:055:1 -115:1 16 <
8800b2cce6c0 2360307814 C Ii:1:055:1 -32:1 0
8800b2cce6c0 2360307827 S Ii:1:055:1 -115:1 16 <
8800b2cce6c0 2746327776 C Ii:1:055:1 -32:1 0
8800b2cce6c0 2746327796 S Ii:1:055:1 -115:1 16 <
8800b2cce6c0 2750455832 C Ii:1:055:1 -32:1 0
8800b2cce6c0 2750455844 S Ii:1:055:1 -115:1 16 <
8800b2cce6c0 2751751777 C Ii:1:055:1 -32:1 0
8800b2cce6c0 2751751788 S Ii:1:055:1 -115:1 16 <
8800b2cce6c0 2752707689 C Ii:1:055:1 -32:1 0
8800b2cce6c0 2752707707 S Ii:1:055:1 -115:1 16 <
8800b2cce6c0 2762271761 C Ii:1:055:1 -32:1 0
8800b2cce6c0 2762271776 S Ii:1:055:1 -115:1 16 <
8800b2cce6c0 2977131824 C Ii:1:055:1 -32:1 0
8800b2cce6c0 2977131835 S Ii:1:055:1 -115:1 16 <
8800b2cce6c0 3602679779 C Ii:1:055:1 -32:1 0
8800b2cce6c0 3602679798 S Ii:1:055:1 -115:1 16 <
8800b2cce6c0 456023739 C Ii:1:055:1 -32:1 0
8800b2cce6c0 456023758 S Ii:1:055:1 -115:1 16 <
8800b2cce6c0 456231695 C Ii:1:055:1 -32:1 0
8800b2cce6c0 456231712 S Ii:1:055:1 -115:1 16 <


Dev 55 usb log:

SSPLIT IN transaction 55 1 HS No data 0.000 238 117
Start of Frame (2) HS 228.0 -> 228.1 0.000 340 583
CSPLIT IN transaction 55 1 NAK HS No data 0.000 489 817
Start of Frame (6) HS 228.2 -> 228.7 0.000 590 617
SSPLIT IN transaction 55 1 HS No data 0.001 238 117
Start of Frame (2) HS 229.0 -> 229.1 0.001 340 733
CSPLIT IN transaction 55 1 NAK HS No data 0.001 489 850
Start of Frame (6) HS 229.2 -> 229.7 0.001 590 767
SSPLIT IN transaction 55 1 HS No data 0.002 238 933
Start of Frame (2) HS 230.0 -> 230.1 0.002 340 867
CSPLIT IN transaction 55 1 NAK HS No data 0.002 489 933
Start of Frame (6) HS 230.2 -> 230.7 0.002 590 900
SSPLIT IN transaction 55 1 HS No data 0.003 238 967
Start of Frame (2) HS 231.0 -> 231.1 0.003 341 017
CSPLIT IN transaction 55 1 NAK HS No data 0.003 489 900
Start of Frame (6) HS 231.2 -> 231.7 0.003 591 050
SSPLIT IN transaction 55 1 HS No data 0.004 238 950
Start of Frame (2) HS 232.0 -> 232.1 0.004 341 150
CSPLIT IN tr

Re: btusb_intr_complete returns -EPIPE

2014-11-09 Thread Naveen Kumar Parna 
I am sorry for the late response.

I applied the patch and here is the dmesg log:

[  713.125709] ehci-pci :00:1a.0: split intr info2 42821c01 token
80108d46 overlay token 80108d46
[  713.125796] ehci-pci :00:1a.0: split intr info2 42821c01 token
80108d46 overlay token 80108d46
[  713.125853] hci4 urb 8800b89a7c00 status -32 count 0
[  713.125857] hci3 urb 8800b7399c00 status -32 count 0
[  713.126801] hci4
[  713.127003] hci3
[ 3046.032153] ehci-pci :00:1a.0: split intr info2 42821c01 token
108d46 overlay token 108d46
[ 3046.032227] ehci-pci :00:1a.0: split intr info2 42821c01 token
108d46 overlay token 108d46
[ 3046.032272] hci3 urb 8800b30f5a80 status -32 count 0
[ 3046.032278] hci4 urb 8800b30f53c0 status -32 count 0
[ 3046.033326] hci4
[ 3046.033344] hci3

Does it gives the reason for -32 status code?

Thanks,
Naveen

On Thu, Nov 6, 2014 at 10:14 PM, Alan Stern  wrote:
> On Thu, 6 Nov 2014, Naveen Kumar Parna wrote:
>
>> > Any idea why you see the CSPLITs now but didn't see them before?
>>
>> It looks like , I failed to locate the exact portion of the analyzer
>> log that corresponds to one of those -32 events in the usbmon log.
>
> Well, I still don't understand that, but never mind...
>
>> USB Analyzer records several megabytes of data very quickly, so it’s
>> very hard to find the portion of the analyzer log that corresponds to
>> one of those -32 events in the usbmon log. To avoid this difficulty I
>> applied the attached patch
>> (0002-btusb-clear-halt-if-intr-in-stalls.patch – got it from Oliver
>> Neukum) to btusb driver and reloaded this driver.
>>
>> The applied patch calls usb_clear_halt() on receiving the stall
>> response, so now I can easily search for ClearFeature(ENDPOINT_HALT)
>> request in the analyzer log. It can be found at "2.304 252 217" &
>> "2.316 264 600" time instance in the attached log.
>>
>> Re ran the Analyzer again and attached it’s exported text
>> log([2014-11-06 session 125138] Trace_only_ep0_ep1.txt). Here
>> filtered out the BulkIN transactions.
>>
>> usbmon log:
>> 8800b7670a80 506095728 C Ii:1:108:1 -32:1 0
>> 8800affdccc0 506107757 C Ii:1:108:1 -32:1 0
>
>> Here is the portion of the log that corresponds to “8800b7670a80
>> 506095728 C Ii:1:108:1 -32:1 0”:
>>
>> Start of Frame (6) HS 553.2 -> 553.7 2.302 964 717
>> SSPLIT IN transaction 105 1 HS No data 2.303 590 367
>> SSPLIT IN transaction 106 1 HS No data 2.303 591 283
>> SSPLIT IN transaction 107 1 HS No data 2.303 600 283
>> SSPLIT IN transaction 108 1 HS No data 2.303 601 350
>> Start of Frame (2) HS 554.0 -> 554.1 2.303 714 817
>> CSPLIT IN transaction 105 1 NAK HS No data 2.303 840 400
>> CSPLIT IN transaction 106 1 NAK HS No data 2.303 842 033
>> CSPLIT IN transaction 107 1 NAK HS No data 2.303 855 317
>> Start of Frame (3) HS 554.2 -> 554.4 2.303 964 850
>
> Obviously, there aren't any CSPLITs for device 108 ep 1.
>
>> Here is the portion of the log that corresponds to “8800affdccc0
>> 506107757 C Ii:1:108:1 -32:1 0":
>>
>> Start of Frame (6) HS 565.2 -> 565.7 2.314 966 383
>> SSPLIT IN transaction 105 1 HS No data 2.315 592 033
>> SSPLIT IN transaction 106 1 HS No data 2.315 592 967
>> SSPLIT IN transaction 107 1 HS No data 2.315 612 800
>> SSPLIT IN transaction 108 1 HS No data 2.315 613 850
>> Start of Frame (2) HS 566.0 -> 566.1 2.315 716 483
>> CSPLIT IN transaction 105 1 NAK HS No data 2.315 842 067
>> CSPLIT IN transaction 106 1 NAK HS No data 2.315 843 683
>> CSPLIT IN transaction 107 1 NAK HS No data 2.315 928 750
>> Start of Frame (3) HS 566.2 -> 566.4 2.315 966 517
>
>> In both the cases, CSPLIT of Dev-108 is missing in this portion of the log.
>>
>> So, Does this test log gives some conclusion?
>
> It indicates that the EHCI host controller hardware isn't working
> right.  Every now and then it skips sending CSPLIT packets when it
> should send them.
>
> I suppose it's possible that the host controller is okay and the
> problem is a bad memory chip.  That could also cause this sort of
> error.  Regardless, it has to be a hardware problem.
>
> Now, this doesn't explain why you get the -32 status code.  Maybe the
> patch below will provide more information.  Try running your test with
> this patch installed and see what shows up in the dmesg log.
>
> Alan Stern
>
>
>
> Index: usb-3.18/drivers/usb/host/ehci-q.c
> ===
> --- usb-3.18.orig/drivers/usb/host/ehci-q.c
> +

Re: btusb_intr_complete returns -EPIPE

2014-11-10 Thread Naveen Kumar Parna 
On Thu, Nov 6, 2014 at 10:14 PM, Alan Stern  wrote:
> On Thu, 6 Nov 2014, Naveen Kumar Parna wrote:
>
>> > Any idea why you see the CSPLITs now but didn't see them before?
>>
>> It looks like , I failed to locate the exact portion of the analyzer
>> log that corresponds to one of those -32 events in the usbmon log.
>
> Well, I still don't understand that, but never mind...
>
>> USB Analyzer records several megabytes of data very quickly, so it’s
>> very hard to find the portion of the analyzer log that corresponds to
>> one of those -32 events in the usbmon log. To avoid this difficulty I
>> applied the attached patch
>> (0002-btusb-clear-halt-if-intr-in-stalls.patch – got it from Oliver
>> Neukum) to btusb driver and reloaded this driver.
>>
>> The applied patch calls usb_clear_halt() on receiving the stall
>> response, so now I can easily search for ClearFeature(ENDPOINT_HALT)
>> request in the analyzer log. It can be found at "2.304 252 217" &
>> "2.316 264 600" time instance in the attached log.
>>
>> Re ran the Analyzer again and attached it’s exported text
>> log([2014-11-06 session 125138] Trace_only_ep0_ep1.txt). Here
>> filtered out the BulkIN transactions.
>>
>> usbmon log:
>> 8800b7670a80 506095728 C Ii:1:108:1 -32:1 0
>> 8800affdccc0 506107757 C Ii:1:108:1 -32:1 0
>
>> Here is the portion of the log that corresponds to “8800b7670a80
>> 506095728 C Ii:1:108:1 -32:1 0”:
>>
>> Start of Frame (6) HS 553.2 -> 553.7 2.302 964 717
>> SSPLIT IN transaction 105 1 HS No data 2.303 590 367
>> SSPLIT IN transaction 106 1 HS No data 2.303 591 283
>> SSPLIT IN transaction 107 1 HS No data 2.303 600 283
>> SSPLIT IN transaction 108 1 HS No data 2.303 601 350
>> Start of Frame (2) HS 554.0 -> 554.1 2.303 714 817
>> CSPLIT IN transaction 105 1 NAK HS No data 2.303 840 400
>> CSPLIT IN transaction 106 1 NAK HS No data 2.303 842 033
>> CSPLIT IN transaction 107 1 NAK HS No data 2.303 855 317
>> Start of Frame (3) HS 554.2 -> 554.4 2.303 964 850
>
> Obviously, there aren't any CSPLITs for device 108 ep 1.
>
>> Here is the portion of the log that corresponds to “8800affdccc0
>> 506107757 C Ii:1:108:1 -32:1 0":
>>
>> Start of Frame (6) HS 565.2 -> 565.7 2.314 966 383
>> SSPLIT IN transaction 105 1 HS No data 2.315 592 033
>> SSPLIT IN transaction 106 1 HS No data 2.315 592 967
>> SSPLIT IN transaction 107 1 HS No data 2.315 612 800
>> SSPLIT IN transaction 108 1 HS No data 2.315 613 850
>> Start of Frame (2) HS 566.0 -> 566.1 2.315 716 483
>> CSPLIT IN transaction 105 1 NAK HS No data 2.315 842 067
>> CSPLIT IN transaction 106 1 NAK HS No data 2.315 843 683
>> CSPLIT IN transaction 107 1 NAK HS No data 2.315 928 750
>> Start of Frame (3) HS 566.2 -> 566.4 2.315 966 517
>
>> In both the cases, CSPLIT of Dev-108 is missing in this portion of the log.
>>
>> So, Does this test log gives some conclusion?
>
> It indicates that the EHCI host controller hardware isn't working
> right.  Every now and then it skips sending CSPLIT packets when it
> should send them.
>
> I suppose it's possible that the host controller is okay and the
> problem is a bad memory chip.  That could also cause this sort of
> error.  Regardless, it has to be a hardware problem.

Is there any test I can run to prove that memory chip is bad?


>
> Now, this doesn't explain why you get the -32 status code.  Maybe the
> patch below will provide more information.  Try running your test with
> this patch installed and see what shows up in the dmesg log.
>
> Alan Stern
>
>
>
> Index: usb-3.18/drivers/usb/host/ehci-q.c
> ===
> --- usb-3.18.orig/drivers/usb/host/ehci-q.c
> +++ usb-3.18/drivers/usb/host/ehci-q.c
> @@ -346,6 +346,12 @@ qh_completions (struct ehci_hcd *ehci, s
> /* always clean up qtds the hc de-activated */
>   retry_xacterr:
> if ((token & QTD_STS_ACTIVE) == 0) {
> +   u32 info2 = hc32_to_cpu(ehci, hw->hw_info2);
> +
> +   if ((info2 & QH_SMASK) && (token & 0x7e))
> +   ehci_info(ehci, "split intr info2 %x token %x 
> overlay token %x\n",
> +   info2, token, 
> hc32_to_cpu(ehci,
> +   hw->hw_token));
>
> /* Report Data Buffer Error: non-fatal but useful */
> if

Re: btusb_intr_complete returns -EPIPE

2014-11-11 Thread Naveen Kumar Parna 
On Mon, Nov 10, 2014 at 10:26 PM, Alan Stern  wrote:
> On Mon, 10 Nov 2014, Naveen Kumar Parna wrote:
>
>> I am sorry for the late response.
>>
>> I applied the patch and here is the dmesg log:
>>
>> [  713.125709] ehci-pci :00:1a.0: split intr info2 42821c01 token
>> 80108d46 overlay token 80108d46
>> [  713.125796] ehci-pci :00:1a.0: split intr info2 42821c01 token
>> 80108d46 overlay token 80108d46
>> [  713.125853] hci4 urb 8800b89a7c00 status -32 count 0
>> [  713.125857] hci3 urb 8800b7399c00 status -32 count 0
>
>> Does it gives the reason for -32 status code?
>
> More or less.  The last (status) byte in the "token" values is 0x46,
> and the 0x04 status bit is documented in the EHCI spec as follows:
>
> Missed Micro-Frame. This bit is ignored unless the QH.EPS field
> indicates a full- or low-speed endpoint and the queue head is
> in the periodic list. This bit is set when the host controller
> detected that a host-induced hold-off caused the host
> controller to miss a required complete-split transaction. If the
> host controller sets this bit to a one, then it remains a one
> for the duration of thetransfer.
>
> This means the host controller is telling you it was unable to carry
> out the CSPLIT part of the transaction, which means it really is a
> hardware problem (and not a bad memory chip).  Either the controller
> isn't working right or else your system is somehow overloaded.
>
> The 0x42 bits indicate that the Queue Head was halted and a CSPLIT is
> pending (which we already knew).  The "halted" status bit is the reason
> why you got a -32 status code.
>
> Alan Stern
>

I am really glad we reached to a conclusion on this.
Thanks for all your help, without which I could not have seen this through.

Now I am confronted with many of these controllers in my lab, with
this hardware issue.
I am not sure I can find a better way than just to tell people to replace them.

Thanks,
Naveen
--
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

Urb completion handler returns -32

2014-09-29 Thread Naveen Kumar Parna 
Hi All,

I want to know the reason for getting INT urb completion status as -EPIPE ?

Thanks,
Pnav
--
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: Urb completion handler returns -32

2014-09-29 Thread Naveen Kumar Parna 
Hi All,


Sorry I forgot to add this small detail:

I am having a USB bluetooth dongle and it support Control \ Interrupt
\ Bulk \ Isochronous Transfers.

I am having a device driver  for this, In driver probe function I am
submitting an URB to INT endpoint. And in the completion handler again
re-queue that URB.

Most of the times I see urb->status as -32(EPIPE) in INT urb
completion handler. Here I don’t know why I am getting this error.

This error observed if I connect more than three devices to host via USB-Hub.

Can anyone tell me what might be the reason for getting this error.


Thanks,
Pnav

On Mon, Sep 29, 2014 at 5:49 PM, Naveen Kumar Parna
 wrote:
> Hi All,
>
> I want to know the reason for getting INT urb completion status as -EPIPE ?
>
> Thanks,
> Pnav
--
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: Urb completion handler returns -32

2014-09-29 Thread Naveen Kumar Parna 
Hi Alan,

> The device replied with a STALL.
> The device runs at low speed or full speed and is connected through a USB-2 
> hub

Yes, my device is full speed (12Mbps) device and connected to 2.0 root
hub. So how  to avoid getting the STALL?



I attached the usbmon log and Ellisys USB analyser log.



I connected the eight similar devices(USB Bluetooth Dongles) to host
and captured the logs.

My device numbers are here :

Bus 001 Device Numbers (063\066\067\068\069\070\071\072)



Usbmon log shows STALL packets for INT in URB completion handler

$ tail -f /tmp/1.mon.out | grep "C Ii"

8800aaedb780 3159611663 C Ii:1:072:1 -32:1 0

880131449cc0 3360277718 C Ii:1:068:1 -32:1 0

8800aaedb9c0 3360278570 C Ii:1:069:1 -32:1 0

880131f52000 3360291656 C Ii:1:067:1 -32:1 0

8800aae88600 3360299542 C Ii:1:068:1 -32:1 0



On receiving the STALL response, work queue got scheduled in INT in
URB completion handler for clearing halt condition(used
usb_clear_halt() API in that work queue)



I enabled “Drop Start of Frames and Keep Alives” & “Drop NAK
transactions” recording options before taking the Ellisys USB analyser
log.

I don’t see STALL packet in Ellisys USB analyser log, but only
observed in usbmon log. Does it mean, device is not sending the STALL,
but only Host controller driver is sending it to my USB device driver?

On Mon, Sep 29, 2014 at 7:01 PM, Alan Stern  wrote:
> On Mon, 29 Sep 2014, Naveen Kumar Parna wrote:
>
>> Hi All,
>>
>> I want to know the reason for getting INT urb completion status as -EPIPE ?
>
> The most common reasons are:
>
> The device replied with a STALL.
>
> The device runs at low speed or full speed and is connected
> through a USB-2 hub.  Under those conditions, URBs complete
> with -EPIPE status when the device is disconnected.
>
> 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: Urb completion handler returns -32

2014-09-30 Thread Naveen Kumar Parna 
The device tree is here:

root@naveen-OptiPlex-745:/home/naveen# lsusb -t

1-1.5.2:1.2: No such file or directory

1-1.5.3:1.2: No such file or directory

1-1.5.4:1.2: No such file or directory

1-1.5.5:1.2: No such file or directory

1-1.5.6:1.2: No such file or directory

1-1.5.7.1:1.2: No such file or directory

1-1.5.7.2:1.2: No such file or directory

1-1.5.7.3:1.2: No such file or directory

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/2p, 480M

|__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/6p, 480M

|__ Port 1: Dev 3, If 0, Class=HID, Driver=usbhid, 12M

|__ Port 1: Dev 3, If 1, Class=HID, Driver=usbhid, 12M

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/2p, 480M

|__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/6p, 480M

|__ Port 3: Dev 3, If 0, Class=HID, Driver=usbhid, 480M

|__ Port 3: Dev 3, If 1, Class=HID, Driver=usbhid, 480M

|__ Port 3: Dev 3, If 2, Class=stor., Driver=usb-storage, 480M

|__ Port 3: Dev 3, If 3, Class=stor., Driver=usb-storage, 480M

|__ Port 5: Dev 4, If 0, Class=hub, Driver=hub/7p, 12M

|__ Port 1: Dev 5, If 0, Class=hub, Driver=hub/7p, 12M

|__ Port 1: Dev 12, If 0, Class=vend., Driver=babel, 12M

|__ Port 2: Dev 13, If 0, Class=vend., Driver=babel, 12M

|__ Port 3: Dev 14, If 0, Class=vend., Driver=babel, 12M

|__ Port 4: Dev 15, If 0, Class=vend., Driver=babel, 12M

|__ Port 5: Dev 16, If 0, Class=vend., Driver=babel, 12M

|__ Port 6: Dev 17, If 0, Class=vend., Driver=babel, 12M

|__ Port 7: Dev 18, If 0, Class=hub, Driver=hub/2p, 12M

|__ Port 1: Dev 22, If 0, Class=vend., Driver=babel, 12M

|__ Port 2: Dev 23, If 0, Class=vend., Driver=babel, 12M

|__ Port 2: Dev 66, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=mybtusb, 12M

|__ Port 2: Dev 66, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=mybtusb, 12M

|__ Port 2: Dev 66, If 2, Class=app., Driver=, 12M

|__ Port 4: Dev 63, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=mybtusb, 12M

|__ Port 4: Dev 63, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=mybtusb, 12M

|__ Port 4: Dev 63, If 2, Class=app., Driver=, 12M

|__ Port 3: Dev 67, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=mybtusb, 12M

|__ Port 3: Dev 67, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=mybtusb, 12M

|__ Port 3: Dev 67, If 2, Class=app., Driver=, 12M

|__ Port 5: Dev 68, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=mybtusb, 12M

|__ Port 5: Dev 68, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=mybtusb, 12M

|__ Port 5: Dev 68, If 2, Class=app., Driver=, 12M

|__ Port 6: Dev 69, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=mybtusb, 12M

|__ Port 6: Dev 69, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=mybtusb, 12M

|__ Port 6: Dev 69, If 2, Class=app., Driver=, 12M

|__ Port 7: Dev 11, If 0, Class=hub, Driver=hub/3p, 12M

|__ Port 1: Dev 70, If 0, Class='bInterfaceClass 0xe0
not yet handled', Driver=mybtusb, 12M

|__ Port 1: Dev 70, If 1, Class='bInterfaceClass 0xe0
not yet handled', Driver=mybtusb, 12M

|__ Port 1: Dev 70, If 2, Class=app., Driver=, 12M

|__ Port 2: Dev 71, If 0, Class='bInterfaceClass 0xe0
not yet handled', Driver=mybtusb, 12M

|__ Port 2: Dev 71, If 1, Class='bInterfaceClass 0xe0
not yet handled', Driver=mybtusb, 12M

|__ Port 2: Dev 71, If 2, Class=app., Driver=, 12M

|__ Port 3: Dev 72, If 0, Class='bInterfaceClass 0xe0
not yet handled', Driver=mybtusb, 12M

|__ Port 3: Dev 72, If 1, Class='bInterfaceClass 0xe0
not yet handled', Driver=mybtusb, 12M

|__ Port 3: Dev 72, If 2, Class=app., Driver=, 12M

On Tue, Sep 30, 2014 at 12:05 PM, Naveen Kumar Parna
 wrote:
> Hi Alan,
>
>> The device replied with a STALL.
>> The device runs at low speed or full speed and is connected through a USB-2 
>> hub
>
> Yes, my device is full speed (12Mbps) device and connected to 2.0 root
> hub. So how  to avoid getting the STALL?
>
>
>
> I attached the usbmon log and Ellisys USB analyser log.
>
>
>
> I connected the eight similar devices(USB Bluetooth Dongles) to host
> and captured the logs.
>
> My device numbers are here :
>
> Bus 001 Device Numbers (063\066\067\068\069\070\071\072)
>
>
>
> Usbmon l

btusb_intr_complete returns -EPIPE

2014-10-06 Thread Naveen Kumar Parna 
Hi,

I am using  “3.1.0-7.fc16.x86_64” kernel and testing eight USB
Bluetooth dongles using btusb.ko module.


Once I power-on the system and loading the btusb.ko driver immediately
results the below mentioned errors:

[ 1389.410907] hci3 urb 88012954dd80 status -32 count 0

[ 1389.411367] hci4 urb 88012954d3c0 status -32 count 0

[ 1389.411845] hci1 urb 88012b4b6b40 status -32 count 0

[ 1389.412238] hci2 urb 8801347ee0c0 status -32 count 0

[ 1518.647255] hci3 urb 88012954dd80 status -32 count 0

[ 1518.647722] hci4 urb 88012954d3c0 status -32 count 0

[ 1518.648120] hci1 urb 88012b4b6b40 status -32 count 0

[ 1518.648514] hci2 urb 8801347ee0c0 status -32 count 0

[ 1518.722033] hci2 urb 8801347ee0c0 status -32 count 0

[ 2191.964545] hci4 urb 88012954d3c0 status -32 count 0

[ 2191.965001] hci1 urb 88012b4b6b40 status -32 count 0

[ 2191.965396] hci2 urb 8801347ee0c0 status -32 count 0

[ 2191.966530] hci2 urb 8801347ee0c0 status -32 count 0

[ 2191.975514] hci4 urb 88012954d3c0 status -32 count 0

[ 2191.975936] hci1 urb 88012b4b6b40 status -32 count 0

[ 2191.976330] hci2 urb 8801347ee0c0 status -32 count 0

[ 2191.977503] hci4 urb 88012954d3c0 status -32 count 0

[ 2191.977929] hci1 urb 88012b4b6b40 status -32 count 0

[ 2191.978325] hci2 urb 8801347ee0c0 status -32 count 0

[ 2560.132682] hci2 urb 8801347ee0c0 status -32 count 0

[ 2569.160895] hci4 urb 88012954d3c0 status -32 count 0

[ 2569.161367] hci1 urb 88012b4b6b40 status -32 count 0

[ 2569.161827] hci2 urb 8801347ee0c0 status -32 count 0

[ 3022.252541] hci2 urb 8801347ee0c0 status -32 count 0

[ 3022.254504] hci2 urb 8801347ee0c0 status -32 count 0


These errors will repeat until sending a proper HCI command on the USB
bus. Again after some time duration same error will repeats.

The error -32(-EPIPE) says , Endpoint stalled.  For non-control
endpoints, reset this status with usb_clear_halt().

But I don’t see the error(-EPIPE) handling code in btusb module. Does
anyone has the patch for this scenario?

Thanks,
Naveen
--
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

btusb_intr_complete returns -EPIPE

2014-10-06 Thread Naveen Kumar Parna 
Hi,

I am using  “3.1.0-7.fc16.x86_64” kernel and testing eight USB
Bluetooth dongles using btusb.ko module.


Once I power-on the system and loading the btusb.ko driver immediately
results the below mentioned errors:

[ 1389.410907] hci3 urb 88012954dd80 status -32 count 0

[ 1389.411367] hci4 urb 88012954d3c0 status -32 count 0

[ 1389.411845] hci1 urb 88012b4b6b40 status -32 count 0

[ 1389.412238] hci2 urb 8801347ee0c0 status -32 count 0

[ 1518.647255] hci3 urb 88012954dd80 status -32 count 0

[ 1518.647722] hci4 urb 88012954d3c0 status -32 count 0

[ 1518.648120] hci1 urb 88012b4b6b40 status -32 count 0

[ 1518.648514] hci2 urb 8801347ee0c0 status -32 count 0

[ 1518.722033] hci2 urb 8801347ee0c0 status -32 count 0

[ 2191.964545] hci4 urb 88012954d3c0 status -32 count 0

[ 2191.965001] hci1 urb 88012b4b6b40 status -32 count 0

[ 2191.965396] hci2 urb 8801347ee0c0 status -32 count 0

[ 2191.966530] hci2 urb 8801347ee0c0 status -32 count 0

[ 2191.975514] hci4 urb 88012954d3c0 status -32 count 0

[ 2191.975936] hci1 urb 88012b4b6b40 status -32 count 0

[ 2191.976330] hci2 urb 8801347ee0c0 status -32 count 0

[ 2191.977503] hci4 urb 88012954d3c0 status -32 count 0

[ 2191.977929] hci1 urb 88012b4b6b40 status -32 count 0

[ 2191.978325] hci2 urb 8801347ee0c0 status -32 count 0

[ 2560.132682] hci2 urb 8801347ee0c0 status -32 count 0

[ 2569.160895] hci4 urb 88012954d3c0 status -32 count 0

[ 2569.161367] hci1 urb 88012b4b6b40 status -32 count 0

[ 2569.161827] hci2 urb 8801347ee0c0 status -32 count 0

[ 3022.252541] hci2 urb 8801347ee0c0 status -32 count 0

[ 3022.254504] hci2 urb 8801347ee0c0 status -32 count 0


These errors will repeat until sending a proper HCI command on the USB
bus. Again after some time duration same error will repeats.

The error -32(-EPIPE) says , Endpoint stalled.  For non-control
endpoints, reset this status with usb_clear_halt().

But I don’t see the error(-EPIPE) handling code in btusb module. Does
anyone has the patch for this scenario?

Thanks,
Naveen
--
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: btusb_intr_complete returns -EPIPE

2014-10-06 Thread Naveen Kumar Parna 
Thank you very much. I will try that patch.



Thanks,
Naveen

On Mon, Oct 6, 2014 at 6:25 PM, Oliver Neukum  wrote:
> On Mon, 2014-10-06 at 18:18 +0530, Naveen Kumar Parna wrote:
>> Hi,
>>
>> I just collected the usbmon log(1.mon.out) and attached it. It stalls
>> for INT in transfers.
>>
>> Corresponding kernel log is here:
>> Oct  6 18:00:48 naveen-OptiPlex-745 kernel: [ 7528.718473] hci3 urb
>> 88012954dd80 status -32 count 0
>> Oct  6 18:05:35 naveen-OptiPlex-745 kernel: [ 7814.688122] hci3 urb
>> 88012954dd80 status -32 count 0
>> Oct  6 18:05:35 naveen-OptiPlex-745 kernel: [ 7814.693086] hci3 urb
>> 88012954dd80 status -32 count 0
>> Oct  6 18:05:35 naveen-OptiPlex-745 kernel: [ 7814.695058] hci3 urb
>> 88012954dd80 status -32 count 0
>> Oct  6 18:05:35 naveen-OptiPlex-745 kernel: [ 7814.703073] hci3 urb
>> 88012954dd80 status -32 count 0
>> Oct  6 18:05:35 naveen-OptiPlex-745 kernel: [ 7814.717038] hci5 urb
>> 88012954de40 status -32 count 0
>> Oct  6 18:05:35 naveen-OptiPlex-745 kernel: [ 7814.717496] hci3 urb
>> 88012954dd80 status -32 count 0
>>
>> Corresponding Usbmon trace:
>> 88012954dd80 2936526502 C Ii:1:009:1 -32:1 0
>> 88012954dd80 3223215374 C Ii:1:009:1 -32:1 0
>> 88012954dd80 3223220352 C Ii:1:009:1 -32:1 0
>> 88012954dd80 3223222332 C Ii:1:009:1 -32:1 0
>> 88012954dd80 3223230362 C Ii:1:009:1 -32:1 0
>> 88012954de40 3223244362 C Ii:1:019:1 -32:1 0
>> 88012954dd80 3223244830 C Ii:1:009:1 -32:1 0
>>
>> Does it gives any clue?
>
> Not really. I'll make a patch to clear the condition.
> Let's see what happens then.
>
> Regards
> Oliver
>
>
--
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: btusb_intr_complete returns -EPIPE

2014-10-06 Thread Naveen Kumar Parna 
-OptiPlex-745 kernel: [  979.208287] ---[ end
trace 0089da2b8191af16 ]---
Oct  6 19:49:24 naveen-OptiPlex-745 kernel: [  979.208739] BUG: unable
to handle kernel paging request at fff8
Oct  6 19:49:24 naveen-OptiPlex-745 kernel: [  979.208742] IP:
[] kthread_data+0x11/0x16
Oct  6 19:49:24 naveen-OptiPlex-745 kernel: [  979.208747] PGD 1a07067
PUD 1a08067 PMD 0

Thanks,
Naveen

On Mon, Oct 6, 2014 at 6:59 PM, Oliver Neukum  wrote:
> On Mon, 2014-10-06 at 18:33 +0530, Naveen Kumar Parna wrote:
>> Thank you very much. I will try that patch.
>
> Then please try.
>
> Regards
> Oliver
>


0001-btusb-clear-halt-if-intr-in-stalls.patch.crash.log
Description: Binary data

Re: btusb_intr_complete returns -EPIPE

2014-10-06 Thread Naveen Kumar Parna 
> +   err = usb_clear_halt(data->udev,
> +usb_rcvbulkpipe(data->udev,
> +
> data->intr_ep->bEndpointAddress));

EPIPE occurred for INT in endpoint, so we should use usb_rcvintpipe()
instead of usb_rcvbulkpipe() right?


Does the “lsusb –v” gives any clue about the reason for getting -EPIPE?

Thanks,
Naveen



On Mon, Oct 6, 2014 at 8:42 PM, Naveen Kumar Parna  wrote:
> Attached the lsusb -v file.
>
> Captured the usbmon log file for this patch and attached it.
>
>
>
> Thanks,
>
> Naveen
>
> On Mon, Oct 6, 2014 at 8:20 PM, Oliver Neukum  wrote:
>> On Mon, 2014-10-06 at 20:08 +0530, Naveen Kumar Parna wrote:
>>> Thanks for the patch.
>>>
>>> I tried and It crashed after the first occurrence of EPIPE.
>>>
>>> Crash log is attached.
>>
>> Could you post a full "lsusb -v"?
>>
>> Regards
>> Oliver
>>
>>
--
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: btusb_intr_complete returns -EPIPE

2014-10-07 Thread Naveen Kumar Parna 
Thanks for the new patch.



The new patch clears the halt condition. But after submitting the urb
again the INT in endpoint returns EPIPE, this behavior continues
infinitely.



Corresponding kernel log is here:

Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.311863] hci0 urb
88012f670b40 status -32 count 0

Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.311988] hci5 urb
8801379d2180 status -32 count 0

Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.455464] hci4 urb
88012a4b2e40 status -32 count 0

Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.455586] hci1 urb
88012a4b2180 status -32 count 0

Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.455691] hci2 urb
88012f670480 status -32 count 0

Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.455784] hci3 urb
88012f670e40 status -32 count 0

Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.455853] hci0 urb
880131e5ee40 status -32 count 0

Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.455913] hci5 urb
880131e5e780 status -32 count 0

Oct  7 17:58:44 naveen-OptiPlex-745 kernel: [   19.690366] hci4 urb
880131e5e780 status -32 count 0

Oct  7 17:58:44 naveen-OptiPlex-745 kernel: [   19.690490] hci5 urb
880131e5e300 status -32 count 0

Oct  7 17:58:47 naveen-OptiPlex-745 kernel: [   22.163163] hci5 urb
88012f541540 status -32 count 0

Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.313996] hci1 urb
880131e5ee40 status -32 count 0

Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.314121] hci0 urb
880131e5e900 status -32 count 0

Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.314169] hci3 urb
880131e5e3c0 status -32 count 0

Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.314213] hci2 urb
880131e5ef00 status -32 count 0

Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.314245] hci4 urb
88012f541d80 status -32 count 0

Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.314274] hci5 urb
88012f541540 status -32 count 0

Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.319974] hci2 urb
8801384dcb40 status -32 count 0

Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.320095] hci0 urb
8801384dc300 status -32 count 0

Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.320151] hci4 urb
8801384dc6c0 status -32 count 0

Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.320193] hci5 urb
8801384dcf00 status -32 count 0



Thanks,

Naveen

On Tue, Oct 7, 2014 at 3:31 PM, Oliver Neukum  wrote:
> On Tue, 2014-10-07 at 12:14 +0530, Naveen Kumar Parna wrote:
>> > +   err = usb_clear_halt(data->udev,
>> > +usb_rcvbulkpipe(data->udev,
>> > +
>> > data->intr_ep->bEndpointAddress));
>>
>> EPIPE occurred for INT in endpoint, so we should use usb_rcvintpipe()
>> instead of usb_rcvbulkpipe() right?
>
> Yes. And I noticed a copy and past error.
>
>> Does the “lsusb –v” gives any clue about the reason for getting -EPIPE?
>
> No. Could you nevertheless test the attached version?
>
> Regards
> Oliver
>
--
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: btusb_intr_complete returns -EPIPE

2014-10-07 Thread Naveen Kumar Parna 
> The new patch clears the halt condition.

I mean usb_clear_halt( ) returned zero.


Thanks,

Naveen

On Tue, Oct 7, 2014 at 7:04 PM, Naveen Kumar Parna  wrote:
> Thanks for the new patch.
>
>
>
> The new patch clears the halt condition. But after submitting the urb
> again the INT in endpoint returns EPIPE, this behavior continues
> infinitely.
>
>
>
> Corresponding kernel log is here:
>
> Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.311863] hci0 urb
> 88012f670b40 status -32 count 0
>
> Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.311988] hci5 urb
> 8801379d2180 status -32 count 0
>
> Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.455464] hci4 urb
> 88012a4b2e40 status -32 count 0
>
> Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.455586] hci1 urb
> 88012a4b2180 status -32 count 0
>
> Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.455691] hci2 urb
> 88012f670480 status -32 count 0
>
> Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.455784] hci3 urb
> 88012f670e40 status -32 count 0
>
> Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.455853] hci0 urb
> 880131e5ee40 status -32 count 0
>
> Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.455913] hci5 urb
> 880131e5e780 status -32 count 0
>
> Oct  7 17:58:44 naveen-OptiPlex-745 kernel: [   19.690366] hci4 urb
> 880131e5e780 status -32 count 0
>
> Oct  7 17:58:44 naveen-OptiPlex-745 kernel: [   19.690490] hci5 urb
> 880131e5e300 status -32 count 0
>
> Oct  7 17:58:47 naveen-OptiPlex-745 kernel: [   22.163163] hci5 urb
> 88012f541540 status -32 count 0
>
> Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.313996] hci1 urb
> 880131e5ee40 status -32 count 0
>
> Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.314121] hci0 urb
> 880131e5e900 status -32 count 0
>
> Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.314169] hci3 urb
> 880131e5e3c0 status -32 count 0
>
> Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.314213] hci2 urb
> 880131e5ef00 status -32 count 0
>
> Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.314245] hci4 urb
> 88012f541d80 status -32 count 0
>
> Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.314274] hci5 urb
> 88012f541540 status -32 count 0
>
> Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.319974] hci2 urb
> 8801384dcb40 status -32 count 0
>
> Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.320095] hci0 urb
> 8801384dc300 status -32 count 0
>
> Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.320151] hci4 urb
> 8801384dc6c0 status -32 count 0
>
> Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.320193] hci5 urb
> 8801384dcf00 status -32 count 0
>
>
>
> Thanks,
>
> Naveen
>
> On Tue, Oct 7, 2014 at 3:31 PM, Oliver Neukum  wrote:
>> On Tue, 2014-10-07 at 12:14 +0530, Naveen Kumar Parna wrote:
>>> > +   err = usb_clear_halt(data->udev,
>>> > +usb_rcvbulkpipe(data->udev,
>>> > +
>>> > data->intr_ep->bEndpointAddress));
>>>
>>> EPIPE occurred for INT in endpoint, so we should use usb_rcvintpipe()
>>> instead of usb_rcvbulkpipe() right?
>>
>> Yes. And I noticed a copy and past error.
>>
>>> Does the “lsusb –v” gives any clue about the reason for getting -EPIPE?
>>
>> No. Could you nevertheless test the attached version?
>>
>> Regards
>> Oliver
>>
--
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: btusb_intr_complete returns -EPIPE

2014-10-08 Thread Naveen Kumar Parna 
hcidump does not show anything when the stalls happen.



Here is the hcidump log:

[root@banunxcas29 np03]# hcidump -x -t

HCI sniffer - Bluetooth packet analyzer ver 2.1

device: hci0 snap_len: 1028 filter: 0x



Corresponding usbmon log

8801265343c0 2826295762 C Ii:1:021:1 -32:1 0

880126418840 2826297275 S Ii:1:021:1 -115:1 16 <

880126534240 2826298730 C Ii:1:020:1 -32:1 0

880126418840 2826298856 C Ii:1:021:1 -32:1 0

880126418840 2826299789 S Ii:1:020:1 -115:1 16 <

880126418900 2826300154 S Ii:1:021:1 -115:1 16 <

8801266329c0 2837941755 C Ii:1:018:1 -32:1 0

880126632c00 2837941884 C Ii:1:016:1 -32:1 0

880126418b40 2837942862 S Ii:1:016:1 -115:1 16 <

880126418300 2837943184 S Ii:1:018:1 -115:1 16 <

880126418300 2897160790 C Ii:1:018:1 -32:1 0

880126418300 2897162701 S Ii:1:018:1 -115:1 16 <

880126632cc0 2897332778 C Ii:1:019:1 -32:1 0

880126418840 2897332909 C Ii:1:020:1 -32:1 0

880126418900 2897332959 C Ii:1:021:1 -32:1 0

880126418b40 2897333002 C Ii:1:016:1 -32:1 0

880126418300 2897333035 C Ii:1:018:1 -32:1 0

880126418900 2897334155 S Ii:1:021:1 -115:1 16 <

880126418b40 2897334405 S Ii:1:020:1 -115:1 16 <

880126418300 2897334635 S Ii:1:019:1 -115:1 16 <

880126418f00 2897335015 S Ii:1:018:1 -115:1 16 <

880126418840 2897335367 S Ii:1:016:1 -115:1 16 <





Corresponding kernel log:

Oct  8 15:29:38 banunxcas29 kernel: [ 3244.604776] hci7 urb
8801265343c0 status -32 count 0

Oct  8 15:29:38 banunxcas29 kernel: [ 3244.606273] hci7

Oct  8 15:29:38 banunxcas29 kernel: [ 3244.607741] hci6 urb
880126534240 status -32 count 0

Oct  8 15:29:38 banunxcas29 kernel: [ 3244.607862] hci7 urb
880126418840 status -32 count 0

Oct  8 15:29:38 banunxcas29 kernel: [ 3244.608787] hci6

Oct  8 15:29:38 banunxcas29 kernel: [ 3244.609155] hci7

Oct  8 15:29:49 banunxcas29 kernel: [ 3256.251736] hci4 urb
8801266329c0 status -32 count 0

Oct  8 15:29:49 banunxcas29 kernel: [ 3256.251857] hci2 urb
880126632c00 status -32 count 0

Oct  8 15:29:49 banunxcas29 kernel: [ 3256.252828] hci2

Oct  8 15:29:49 banunxcas29 kernel: [ 3256.253153] hci4

Oct  8 15:30:49 banunxcas29 kernel: [ 3315.476287] hci4 urb
880126418300 status -32 count 0

Oct  8 15:30:49 banunxcas29 kernel: [ 3315.478179] hci4

Oct  8 15:30:49 banunxcas29 kernel: [ 3315.648289] hci5 urb
880126632cc0 status -32 count 0

Oct  8 15:30:49 banunxcas29 kernel: [ 3315.648411] hci6 urb
880126418840 status -32 count 0

Oct  8 15:30:49 banunxcas29 kernel: [ 3315.648461] hci7 urb
880126418900 status -32 count 0

Oct  8 15:30:49 banunxcas29 kernel: [ 3315.648504] hci2 urb
880126418b40 status -32 count 0

Oct  8 15:30:49 banunxcas29 kernel: [ 3315.648537] hci4 urb
880126418300 status -32 count 0

Oct  8 15:30:49 banunxcas29 kernel: [ 3315.649651] hci7

Oct  8 15:30:49 banunxcas29 kernel: [ 3315.649905] hci6

Oct  8 15:30:49 banunxcas29 kernel: [ 3315.650134] hci5

Oct  8 15:30:49 banunxcas29 kernel: [ 3315.650514] hci4

Oct  8 15:30:49 banunxcas29 kernel: [ 3315.650866] hci2



Thanks,
Naveen


On Wed, Oct 8, 2014 at 2:39 PM, Oliver Neukum  wrote:
> On Tue, 2014-10-07 at 20:01 +0530, Naveen Kumar Parna wrote:
>> > The new patch clears the halt condition.
>>
>> I mean usb_clear_halt( ) returned zero.
>
> That probably means that the device doesn't just
> produce spurious stalls. Does hcidump show anything
> when the stalls happen?
>
> Regards
> Oliver
>
>
--
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: btusb_intr_complete returns -EPIPE

2014-10-08 Thread Naveen Kumar Parna 
not producing stalls , looks like issue
might be in between btusb and ehci_hcd\hub.

What might the best way to recover and avoid spurious stalls?



Thanks,

Naveen

On Wed, Oct 8, 2014 at 4:14 PM, Oliver Neukum  wrote:
> On Wed, 2014-10-08 at 15:51 +0530, Naveen Kumar Parna wrote:
>> hcidump does not show anything when the stalls happen.
>
> There is nothing in all logs. Do you see the problem
> with single devices?
>
> Regards
> Oliver
>
>
--
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: btusb_intr_complete returns -EPIPE

2014-10-08 Thread Naveen Kumar Parna 
> This points to a problem in the USB HC driver.
> Can you enable debugging in that driver.



Is it enabling dynamic debugging?

Could you please point me the steps to enable debugging in USB HC driver?



Thanks,

Naveen

On Wed, Oct 8, 2014 at 6:47 PM, Oliver Neukum  wrote:
> On Wed, 2014-10-08 at 18:31 +0530, Naveen Kumar Parna wrote:
>> Later connected third device(hci2) and after 2mins observed –EPIPE for
>> hci2(hci2 urb 880124f11cc0 status -32 count 0)
>
> This points to a problem in the USB HC driver.
> Can you enable debugging in that driver.
>
> Regards
> Oliver
>
>
--
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: btusb_intr_complete returns -EPIPE

2014-10-15 Thread Naveen Kumar Parna 
EHCI controller on PCI card and hub("rate-matching" hub) also internal.

Is it possible to change the internal hub?



Thanks,
Naveen

On Wed, Oct 15, 2014 at 3:41 PM, Oliver Neukum  wrote:
> On Thu, 2014-10-09 at 10:31 -0400, Alan Stern wrote:
>> On Thu, 9 Oct 2014, Naveen Kumar Parna wrote:
>>
>> > Hi Oliver & Alan,
>> >
>> >
>> >
>> > Thanks for your inputs.
>> >
>> >
>> >
>> > I enabled the dynamic debugging for USB HC driver. Please correct me
>> > if I am wrong.
>>
>> Debugging the kernel (or doing anything else to the kernel, for that
>> matter) won't solve the problem if it is caused by a buggy hub.
>
> Indeed. Could you just try a different hub?
>
> Regards
> Oliver
>
>
>
--
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: btusb_intr_complete returns -EPIPE

2014-10-15 Thread Naveen Kumar Parna 
Hi Oliver,

I tried this test in two different set of hardware configurations.



i)I tried in multiple test systems which has
EHCI-USB host controller on PCI card and internal USB 2.0
hub("rate-matching" hub). All the test systems with this configuration
gives spurious stall packets.

[lowerlayers@banunxcas29 ~]$ lspci | grep -i usb

00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset
USB2 Enhanced Host Controller (rev 05)

00:1d.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset
USB2 Enhanced Host Controller (rev 05)


lsusb:

Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub

Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub





ii)   I found different test systems which has
OHCI-USB host controller on PCI card and internal USB 1.1 hub. All the
test systems with this configuration are not producing stall packets.

 [lowerlayers@camunxcas11 ~]$ lspci | grep -i usb

00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)

00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)


lsusb:

Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Bus 002 Device 002: ID 0451:2077 Texas Instruments, Inc. TUSB2077 Hub




My device is a full-speed device. So , stall packets are due to buggy
USB 2.0 hub?


Is there a chance of getting stall packets “If the device runs at low
speed or full speed and is connected through a USB-2.0 hub”? If so it
looks like hub driver issue right?


If the hub is the problem… what will be the better solution? Is it
possible to change internal hub?




Thanks,

Naveen

On Wed, Oct 15, 2014 at 6:39 PM, Naveen Kumar Parna
 wrote:
> EHCI controller on PCI card and hub("rate-matching" hub) also internal.
>
> Is it possible to change the internal hub?
>
>
>
> Thanks,
> Naveen
>
> On Wed, Oct 15, 2014 at 3:41 PM, Oliver Neukum  wrote:
>> On Thu, 2014-10-09 at 10:31 -0400, Alan Stern wrote:
>>> On Thu, 9 Oct 2014, Naveen Kumar Parna wrote:
>>>
>>> > Hi Oliver & Alan,
>>> >
>>> >
>>> >
>>> > Thanks for your inputs.
>>> >
>>> >
>>> >
>>> > I enabled the dynamic debugging for USB HC driver. Please correct me
>>> > if I am wrong.
>>>
>>> Debugging the kernel (or doing anything else to the kernel, for that
>>> matter) won't solve the problem if it is caused by a buggy hub.
>>
>> Indeed. Could you just try a different hub?
>>
>> Regards
>> Oliver
>>
>>
>>
--
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: btusb_intr_complete returns -EPIPE

2014-10-16 Thread Naveen Kumar Parna 
> It's entirely possible that the stall packets are created by the hub.
> When a full-speed device is connected to a USB-2 hub, and the device
> fails to respond to a packet sent by the host, the hub reports this
> failure as a stall.

Here I don’t think device fails to respond to a packet sent by the
host. I verified this by connecting Ellisys USB analyser in between
host and devices.

For example Look at the attached(Sample_HciEvt.png) HCI event captured
by Ellisys USB analyser. It is a valid HCI event from device to Host.
IN transaction 96 1 ACK FS 16 bytes (FF 2F C2 01 00 17 00 DF 00 01 10
00 00 A9 EE 0F)
IN transaction 96 1 ACK FS 16 bytes (00 00 00 5A 06 9D 39 00 00 66 00
00 00 00 00 00)
IN transaction 96 1 ACK FS 16 bytes (00 00 00 00 00 00 00 00 00 00 00
8E 05 28 00 01)
IN transaction 96 1 ACK FS 1 byte (00)

Due to spurious stall packets , sometimes btusb driver is not
receiving this full event , instead it got STALL packet instead of
first 16 bytes plus rest of other 33 bytes.



> When the device is connected to an OHCI controller, such failures would
> be reported in a different way, such as a -EPROTO or -EILSEQ status.
>

I did not observed -EPROTO or -EILSEQ status in OHCI controller scenario.

Thanks,
Naveen

Re: btusb_intr_complete returns -EPIPE

2014-10-16 Thread Naveen Kumar Parna 
On Thu, Oct 16, 2014 at 2:45 PM, Oliver Neukum  wrote:
>
> On Wed, 2014-10-15 at 12:11 -0400, Alan Stern wrote:
> > > If the hub is the problem… what will be the better solution? Is it
> > > possible to change internal hub?
> >
> > No, it is not possible.
>
> Indeed. However, it is possible to use an additional in between your
> devices and the internal hub.
>
> Regards
> Oliver
>
>


Tested with this configuration(external hubs Dev 3, Dev 4, Dev 17, Dev
10) and got the same result.

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M

|__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/6p, 480M

|__ Port 5: Dev 3, If 0, Class=hub, Driver=hub/7p, 12M

|__ Port 1: Dev 4, If 0, Class=hub, Driver=hub/7p, 12M

|__ Port 1: Dev 11, If 0, Class=vend., Driver=, 12M

|__ Port 2: Dev 12, If 0, Class=vend., Driver=, 12M

|__ Port 3: Dev 13, If 0, Class=vend., Driver=, 12M

|__ Port 4: Dev 14, If 0, Class=vend., Driver=, 12M

|__ Port 5: Dev 15, If 0, Class=vend., Driver=, 12M

|__ Port 6: Dev 16, If 0, Class=vend., Driver=, 12M

|__ Port 7: Dev 17, If 0, Class=hub, Driver=hub/2p, 12M

|__ Port 1: Dev 21, If 0, Class=vend., Driver=, 12M

|__ Port 2: Dev 22, If 0, Class=vend., Driver=, 12M

|__ Port 2: Dev 5, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 2: Dev 5, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 2: Dev 5, If 2, Class=app., Driver=, 12M

|__ Port 3: Dev 6, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 3: Dev 6, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 3: Dev 6, If 2, Class=app., Driver=, 12M

|__ Port 4: Dev 7, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 4: Dev 7, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 4: Dev 7, If 2, Class=app., Driver=, 12M

|__ Port 5: Dev 8, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 5: Dev 8, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 5: Dev 8, If 2, Class=app., Driver=, 12M

|__ Port 6: Dev 9, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 6: Dev 9, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 6: Dev 9, If 2, Class=app., Driver=, 12M

|__ Port 7: Dev 10, If 0, Class=hub, Driver=hub/3p, 12M

|__ Port 1: Dev 18, If 0, Class='bInterfaceClass 0xe0
not yet handled', Driver=btusb, 12M

|__ Port 1: Dev 18, If 1, Class='bInterfaceClass 0xe0
not yet handled', Driver=btusb, 12M

|__ Port 1: Dev 18, If 2, Class=app., Driver=, 12M

|__ Port 2: Dev 19, If 0, Class='bInterfaceClass 0xe0
not yet handled', Driver=btusb, 12M

|__ Port 2: Dev 19, If 1, Class='bInterfaceClass 0xe0
not yet handled', Driver=btusb, 12M

|__ Port 2: Dev 19, If 2, Class=app., Driver=, 12M

|__ Port 3: Dev 20, If 0, Class='bInterfaceClass 0xe0
not yet handled', Driver=btusb, 12M

|__ Port 3: Dev 20, If 1, Class='bInterfaceClass 0xe0
not yet handled', Driver=btusb, 12M

|__ Port 3: Dev 20, If 2, Class=app., Driver=, 12M
--
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: btusb_intr_complete returns -EPIPE

2014-10-16 Thread Naveen Kumar Parna 
Ok, I will do this and update you.
But Currently I am on long leave and I can update you on 27th Oct.

Thanks,
Naveen

On Thu, Oct 16, 2014 at 7:39 PM, Alan Stern  wrote:
> On Thu, 16 Oct 2014, Naveen Kumar Parna wrote:
>
>> > Indeed. However, it is possible to use an additional in between your
>> > devices and the internal hub.
>> >
>> > Regards
>> > Oliver
>> >
>> >
>>
>>
>> Tested with this configuration(external hubs Dev 3, Dev 4, Dev 17, Dev
>> 10) and got the same result.
>>
>> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
>>
>> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
>>
>> |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/6p, 480M
>>
>> |__ Port 5: Dev 3, If 0, Class=hub, Driver=hub/7p, 12M
>>
>> |__ Port 1: Dev 4, If 0, Class=hub, Driver=hub/7p, 12M
>
> This is not what Oliver meant.  You have to use a USB-2 hub.  And
> having one of them is enough; you don't need two.
>
> 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: btusb_intr_complete returns -EPIPE

2014-10-16 Thread Naveen Kumar Parna 
On Thu, Oct 16, 2014 at 7:46 PM, Alan Stern  wrote:
> On Thu, 16 Oct 2014, Naveen Kumar Parna wrote:
>
>> > It's entirely possible that the stall packets are created by the hub.
>> > When a full-speed device is connected to a USB-2 hub, and the device
>> > fails to respond to a packet sent by the host, the hub reports this
>> > failure as a stall.
>>
>> Here I don’t think device fails to respond to a packet sent by the
>> host. I verified this by connecting Ellisys USB analyser in between
>> host and devices.
>>
>> For example Look at the attached(Sample_HciEvt.png) HCI event captured
>> by Ellisys USB analyser. It is a valid HCI event from device to Host.
>> IN transaction 96 1 ACK FS 16 bytes (FF 2F C2 01 00 17 00 DF 00 01 10
>> 00 00 A9 EE 0F)
>> IN transaction 96 1 ACK FS 16 bytes (00 00 00 5A 06 9D 39 00 00 66 00
>> 00 00 00 00 00)
>> IN transaction 96 1 ACK FS 16 bytes (00 00 00 00 00 00 00 00 00 00 00
>> 8E 05 28 00 01)
>> IN transaction 96 1 ACK FS 1 byte (00)
>
> This doesn't prove anything.  All it means is that the device responded
> properly on these four occasions.  What if the device failed to respond
> on some other occasion?  You have to compare the output of the analyzer
> with the output from usbmon.  If usbmon shows a STALL and the analyzer
> shows a valid reply for the very same packet, then you'll know the
> device isn't at fault.
>


I forgot to post usbmon log, but usbmon shows a STALL and the analyser
shows a valid reply for the very same packet.

I tried this many number of times and always got same result.

But did not get STALL on OHCI-USB host controller on PCI card with
internal USB 1.1 hub. In both the scenario’s I used same devices.




> You should also run a similar test when you connect the device through
> a USB-2 hub.  In fact, you should run two tests.  In one test, connect
> the analyzer to the cable segment between the computer and the hub; in
> the other test, connect the analyzer to the cable segment between the
> hub and the device.
>


Ok, I will try and update you on this.




Thanks,
Naveen
--
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: btusb_intr_complete returns -EPIPE

2014-10-27 Thread Naveen Kumar Parna 
On Thu, Oct 16, 2014 at 7:39 PM, Alan Stern  wrote:
> On Thu, 16 Oct 2014, Naveen Kumar Parna wrote:
>
>> > Indeed. However, it is possible to use an additional in between your
>> > devices and the internal hub.
>> >
>> > Regards
>> > Oliver
>> >
>> >
>>
>>
>> Tested with this configuration(external hubs Dev 3, Dev 4, Dev 17, Dev
>> 10) and got the same result.
>>
>> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
>>
>> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
>>
>> |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/6p, 480M
>>
>> |__ Port 5: Dev 3, If 0, Class=hub, Driver=hub/7p, 12M
>>
>> |__ Port 1: Dev 4, If 0, Class=hub, Driver=hub/7p, 12M
>
> This is not what Oliver meant.  You have to use a USB-2 hub.  And
> having one of them is enough; you don't need two.
>
> Alan Stern
>


As suggested, I connected USB-2 hub(Dev 87) in between my devices and
the internal hub. In this scenario also observed the STALL packets.

I am interested in understanding the objective of this test, can you
please help me?


[lowerlayers@banunxcas29 ~]$ lsusb -t

1-1.5.1:1.2: No such file or directory

1-1.5.3:1.2: No such file or directory

1-1.5.4:1.2: No such file or directory

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M

|__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/6p, 480M

|__ Port 5: Dev 87, If 0, Class=hub, Driver=hub/4p, 480M

|__ Port 1: Dev 88, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 1: Dev 88, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 1: Dev 88, If 2, Class=app., Driver=, 12M

|__ Port 3: Dev 90, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 3: Dev 90, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 3: Dev 90, If 2, Class=app., Driver=, 12M

|__ Port 4: Dev 89, If 0, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 4: Dev 89, If 1, Class='bInterfaceClass 0xe0 not
yet handled', Driver=btusb, 12M

|__ Port 4: Dev 89, If 2, Class=app., Driver=, 12M



[root@banunxcas29 ~]# cat /sys/kernel/debug/usb/usbmon/1u

8800b2036540 2419900733 C Ii:1:090:1 -32:1 0

8800b2036540 2419900753 S Ii:1:090:1 -115:1 16 <

8800b2036540 963424773 C Ii:1:090:1 -32:1 0

8800b2036540 963424792 S Ii:1:090:1 -115:1 16 <

8800b2036540 963448864 C Ii:1:090:1 -32:1 0

8800b2036540 963448880 S Ii:1:090:1 -115:1 16 <


/var/log/kernel

Oct 27 13:21:15 banunxcas29 kernel: [1017571.251514] hci2 urb
8800b2036540 status -32 count 0

Oct 27 14:05:15 banunxcas29 kernel: [1020211.003086] hci2 urb
8800b2036540 status -32 count 0

Oct 27 14:05:15 banunxcas29 kernel: [1020211.027178] hci2 urb
8800b2036540 status -32 count 0


Thanks,
Naveen
--
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