Re: btusb_intr_complete returns -EPIPE
On Mon, Nov 10, 2014 at 10:26 PM, Alan Stern st...@rowland.harvard.edu 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
Re: btusb_intr_complete returns -EPIPE
On Tue, 11 Nov 2014, Naveen Kumar Parna wrote: 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. You're welcome. 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. You could try contacting the manufacturer to see if they are aware of this problem and have any suggestions. 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
On Thu, Nov 6, 2014 at 10:14 PM, Alan Stern st...@rowland.harvard.edu 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 (token QTD_STS_DBE)
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
Re: btusb_intr_complete returns -EPIPE
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 -- 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
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 st...@rowland.harvard.edu 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
+++ 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));
Re: btusb_intr_complete returns -EPIPE
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
+++ 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 (token QTD_STS_DBE)
--
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
On Wed, 5 Nov 2014, Naveen Kumar Parna wrote: 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. Any idea why you see the CSPLITs now but didn't see them before? 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 Notice that the problem seems to occur very rarely. There are often many seconds between the -32 status values, whereas the interrupt endpoint gets polled 1000 times per second. Inconsistent behavior like that tends to indicate a hardware problem. Software would behave the same way every time, unless there was some sort of race. 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 transaction 55 1 NAK HS No data 0.004 489 950 Start of Frame (6) HS 232.2 - 232.7 0.004 591 183 SSPLIT IN transaction 55 1 HS No data 0.005 239 000 Start of Frame (2) HS 233.0 - 233.1 0.005 341 283 CSPLIT IN transaction 55 1 NAK HS No data 0.005 490 000 This looks right. The SSPLIT packets get sent in microframe 7 of each frame and the CSPLIT packets get sent in microframe 1. (The full-speed bus transaction occurs during microframe 0, in between.) Also, a NAK response to a CSPLIT is correct when the device has no data to send. It wouldn't cause you to get a STALL indication. I need to see the portion of the analyzer log that corresponds to one of those -32 events in the usbmon log. It ought to show something different, something that would cause the -32 status. External USB-2 hub (Dev 51) log: Start of Frame (570) HS 258.7 - 330.0 0.000 090 550 IN transaction 51 1 NAK HS No data 0.071 226 050 Start of Frame (2,048) HS 299.0 - 554.7 0.071 350 517 IN transaction 51 1 NAK HS No data 0.327 261 817 Start of Frame (2,048) HS 555.0 - 810.7 0.327 386 250 IN transaction 51 1 NAK HS No data 0.583 297 550 Start of Frame (2,048) HS 811.0 - 1,066.7 0.583 422 000 IN transaction 51 1 NAK HS No data 0.839 333 283 Start of Frame (2,048) HS 1,067.0 - 1,322.7 0.839 457 733 IN transaction 51 1 NAK HS No data 1.095 369 050 Start of Frame (2,048) HS 1,323.0 - 1,578.7 1.095 493 483 IN transaction 51 1 NAK HS No data 1.351 404 767 Start of Frame (2,048) HS 1,579.0 - 1,834.7 1.351 529 233 IN transaction 51 1 NAK HS No
Re: btusb_intr_complete returns -EPIPE
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 transaction 55 1 NAK HS No data 0.004 489 950 Start of Frame (6) HS 232.2
Re: btusb_intr_complete returns -EPIPE
On Mon, 3 Nov 2014, Naveen Kumar Parna wrote: On Sat, Nov 1, 2014 at 2:21 AM, Alan Stern st...@rowland.harvard.edu wrote: On Wed, 29 Oct 2014, Naveen Kumar Parna wrote: 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 see what you mean -- the log doesn't contain any CSPLIT transactions for the interrupt endpoints. Only SSPLIT. I'll need to see the scheduling information for these endpoints. You'll have to run a 3.13 or later kernel; then the important files will be under /sys/kernel/debug/usb/ehci/X/, where X is the PCI address of the EHCI controller you are using. Copy the files in that directory while the test is running. I attached all the files. Please let me know if I miss anything? All the information in the files looks correct, as far as I can see. I have no idea why the CSPLIT packets are missing. 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
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
On Wed, 29 Oct 2014, Naveen Kumar Parna wrote: 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? SSPLIT IN transaction 114 1 HS No data884.562 264 267 SSPLIT IN transaction 115 1 HS No data884.562 265 217 SSPLIT IN transaction 116 1 HS No data884.562 285 417 SSPLIT IN transaction 117 1 HS No data884.562 286 467 I see what you mean -- the log doesn't contain any CSPLIT transactions for the interrupt endpoints. Only SSPLIT. I'll need to see the scheduling information for these endpoints. You'll have to run a 3.13 or later kernel; then the important files will be under /sys/kernel/debug/usb/ehci/X/, where X is the PCI address of the EHCI controller you are using. Copy the files in that directory while the test is running. 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
On Thu, Oct 16, 2014 at 7:39 PM, Alan Stern st...@rowland.harvard.edu 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
Re: btusb_intr_complete returns -EPIPE
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
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 -- 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
On Thu, Oct 16, 2014 at 2:45 PM, Oliver Neukum oneu...@suse.de 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
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
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. 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. 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
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 st...@rowland.harvard.edu 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
On Thu, Oct 16, 2014 at 7:46 PM, Alan Stern st...@rowland.harvard.edu 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
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
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 oneu...@suse.de 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
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 pnaveen...@gmail.com 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 oneu...@suse.de 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
On Wed, 15 Oct 2014, Naveen Kumar Parna wrote: 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? 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. 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. 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 problem is that the device fails to respond to a packet then it is an issue with the device. If the hub is the problem… what will be the better solution? Is it possible to change internal hub? No, it is not possible. 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
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. 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
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
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 oneu...@suse.de 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
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
Do you see the problem with single devices? If I connect only one device to system then I did not see this issue. Usually I will use 8 devices(all with the same firmware) for testing. I tried different method to get some clue. First I disconnected all the devices and rebooted the system and later connected only one device and observed hci0 related debug print statements in the kernel log. Waited for 16mins idle, but did not get –EPIPE. Oct 8 16:41:46 banunxcas29 kernel: [ 488.018751] usb 1-1.5.1.7: new full speed USB device number 13 using ehci_hcd Oct 8 16:41:46 banunxcas29 kernel: [ 488.093487] usb 1-1.5.1.7: New USB device found, idVendor=0451, idProduct=2036 Oct 8 16:41:46 banunxcas29 kernel: [ 488.093494] usb 1-1.5.1.7: New USB device strings: Mfr=0, Product=1, SerialNumber=0 Oct 8 16:41:46 banunxcas29 kernel: [ 488.093499] usb 1-1.5.1.7: Product: General Purpose USB Hub Oct 8 16:41:46 banunxcas29 kernel: [ 488.094581] hub 1-1.5.1.7:1.0: USB hub found Oct 8 16:41:46 banunxcas29 kernel: [ 488.094811] hub 1-1.5.1.7:1.0: 2 ports detected Oct 8 16:41:46 banunxcas29 kernel: [ 488.261141] usb 1-1.5.2: new full speed USB device number 14 using ehci_hcd Oct 8 16:41:46 banunxcas29 kernel: [ 488.323983] usb 1-1.5.2: device descriptor read/64, error -32 Oct 8 16:41:47 banunxcas29 kernel: [ 488.518202] usb 1-1.5.2: New USB device found, idVendor=0a12, idProduct=0001 Oct 8 16:41:47 banunxcas29 kernel: [ 488.518208] usb 1-1.5.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Oct 8 16:41:47 banunxcas29 kernel: [ 488.551389] Bluetooth: Core ver 2.16 Oct 8 16:41:47 banunxcas29 kernel: [ 488.551402] NET: Registered protocol family 31 Oct 8 16:41:47 banunxcas29 kernel: [ 488.551404] Bluetooth: HCI device and connection manager initialized Oct 8 16:41:47 banunxcas29 kernel: [ 488.551406] Bluetooth: HCI socket layer initialized Oct 8 16:41:47 banunxcas29 kernel: [ 488.551408] Bluetooth: L2CAP socket layer initialized Oct 8 16:41:47 banunxcas29 kernel: [ 488.551411] Bluetooth: SCO socket layer initialized Oct 8 16:41:47 banunxcas29 kernel: [ 488.565663] Bluetooth: Generic Bluetooth USB driver ver 0.6 Oct 8 16:41:47 banunxcas29 kernel: [ 488.565693] intf 880128640800 id a0197f00 Oct 8 16:41:47 banunxcas29 kernel: [ 488.580231] hci0 Oct 8 16:41:47 banunxcas29 kernel: [ 488.580236] hci0 Oct 8 16:41:47 banunxcas29 kernel: [ 488.580258] intf 880128641000 id a0197f00 Oct 8 16:41:47 banunxcas29 kernel: [ 488.580296] usbcore: registered new interface driver btusb Oct 8 16:41:47 banunxcas29 kernel: [ 488.580480] hci0 Oct 8 16:41:47 banunxcas29 kernel: [ 488.580486] hci0 Oct 8 16:41:47 banunxcas29 kernel: [ 488.580503] hci0 Oct 8 16:41:47 banunxcas29 kernel: [ 488.581314] hci0 urb 880131dbe3c0 status 0 count 6 Later connected one more device to system and noticed hci1 related debug print statements in the kernel log. Waited for 20mins idle and now also not received –EPIPE. Oct 8 16:57:44 banunxcas29 kernel: [ 1443.815276] usb 1-1.5.3: new full speed USB device number 17 using ehci_hcd Oct 8 16:57:45 banunxcas29 kernel: [ 1444.400987] usb 1-1.5.3: New USB device found, idVendor=0a12, idProduct=0001 Oct 8 16:57:45 banunxcas29 kernel: [ 1444.400993] usb 1-1.5.3: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Oct 8 16:57:45 banunxcas29 kernel: [ 1444.403218] intf 880124c45800 id a0197f00 Oct 8 16:57:45 banunxcas29 kernel: [ 1444.403360] hci1 Oct 8 16:57:45 banunxcas29 kernel: [ 1444.403364] hci1 Oct 8 16:57:45 banunxcas29 kernel: [ 1444.403500] intf 880124c44c00 id a0197f00 Oct 8 16:57:45 banunxcas29 kernel: [ 1444.403511] hci1 Oct 8 16:57:45 banunxcas29 kernel: [ 1444.403515] hci1 Oct 8 16:57:45 banunxcas29 kernel: [ 1444.403529] hci1 Oct 8 16:57:45 banunxcas29 kernel: [ 1444.404872] hci1 urb 880129162840 status 0 count 6 Later connected third device(hci2) and after 2mins observed –EPIPE for hci2(hci2 urb 880124f11cc0 status -32 count 0) Oct 8 17:18:21 banunxcas29 kernel: [ 2677.069853] usb 1-1.5.4: new full speed USB device number 18 using ehci_hcd Oct 8 17:18:21 banunxcas29 kernel: [ 2677.681729] usb 1-1.5.4: New USB device found, idVendor=0a12, idProduct=0001 Oct 8 17:18:21 banunxcas29 kernel: [ 2677.681735] usb 1-1.5.4: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Oct 8 17:18:21 banunxcas29 kernel: [ 2677.683689] intf 880119c3b400 id a0197f00 Oct 8 17:18:21 banunxcas29 kernel: [ 2677.683886] hci2 Oct 8 17:18:21 banunxcas29 kernel: [ 2677.683889] hci2 Oct 8 17:18:21 banunxcas29 kernel: [ 2677.684083] intf 880119c3a800 id a0197f00 Oct 8 17:18:21 banunxcas29 kernel: [ 2677.684161] hci2 Oct 8 17:18:21 banunxcas29 kernel: [ 2677.684166] hci2 Oct 8 17:18:21 banunxcas29 kernel: [ 2677.684184] hci2 Oct 8 17:18:21 banunxcas29 kernel: [ 2677.685364] hci2 urb 880124f11cc0 status 0
Re: btusb_intr_complete returns -EPIPE
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
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 oneu...@suse.de 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
On Wed, 8 Oct 2014, 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. It could also be a bug in the hub that the BT devices are plugged into. I have seen a report of a hub that sends STALL when a bunch of devices are plugged in, even though the devices themselves did not send a STALL. 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
+ 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 pnaveen...@gmail.com 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 oneu...@suse.de 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
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
From b8109554277bde9da4275e7a9ce1ef76b43ebd59 Mon Sep 17 00:00:00 2001
From: Oliver Neukum oneu...@suse.de
Date: Mon, 6 Oct 2014 15:27:54 +0200
Subject: [PATCH] btusb: clear halt if intr in stalls
Use a work queue for clearing a halt.
Signed-off-by: Oliver Neukum oneu...@suse.de
---
drivers/bluetooth/btusb.c | 34 --
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 292c38e..716c37a 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -273,6 +273,7 @@ struct btusb_data {
struct work_struct work;
struct work_struct waker;
+ struct work_struct intr_in_work;
struct usb_anchor tx_anchor;
struct usb_anchor intr_anchor;
@@ -314,14 +315,15 @@ static void btusb_intr_complete(struct urb *urb)
struct hci_dev *hdev = urb-context;
struct btusb_data *data = hci_get_drvdata(hdev);
int err;
+ int status = urb-status;
BT_DBG(%s urb %p status %d count %d, hdev-name,
- urb, urb-status, urb-actual_length);
+ urb, status, urb-actual_length);
if (!test_bit(HCI_RUNNING, hdev-flags))
return;
- if (urb-status == 0) {
+ if (status == 0) {
hdev-stat.byte_rx += urb-actual_length;
if (hci_recv_fragment(hdev, HCI_EVENT_PKT,
@@ -330,6 +332,10 @@ static void btusb_intr_complete(struct urb *urb)
BT_ERR(%s corrupted event packet, hdev-name);
hdev-stat.err_rx++;
}
+ } else if (status == -EPIPE) {
+ usb_mark_last_busy(data-udev);
+ schedule_work(data-intr_in_work);
+ return;
}
if (!test_bit(BTUSB_INTR_RUNNING, data-flags))
@@ -971,6 +977,29 @@ static void btusb_waker(struct work_struct *work)
usb_autopm_put_interface(data-intf);
}
+static void clear_halt_intr_in(struct work_struct *work)
+{
+ struct btusb_data *data = container_of(work, struct btusb_data, intr_in_work);
+ int err;
+
+ err = usb_autopm_get_interface(data-intf);
+ if (err 0)
+ return;
+
+ err = usb_clear_halt(data-udev,
+ usb_rcvintpipe(data-udev,
+ data-intr_ep-bEndpointAddress));
+ if (err 0)
+ return;
+
+ if (!test_bit(BTUSB_INTR_RUNNING, data-flags))
+ return;
+
+ btusb_submit_intr_urb(data-hdev, GFP_NOIO);
+
+ usb_autopm_put_interface(data-intf);
+}
+
static int btusb_setup_bcm92035(struct hci_dev *hdev)
{
struct sk_buff *skb;
@@ -1759,6 +1788,7 @@ static int btusb_probe(struct usb_interface *intf,
INIT_WORK(data-work, btusb_work);
INIT_WORK(data-waker, btusb_waker);
+ INIT_WORK(data-intr_in_work, clear_halt_intr_in);
spin_lock_init(data-txlock);
init_usb_anchor(data-tx_anchor);
--
1.8.4.5
Re: btusb_intr_complete returns -EPIPE
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 oneu...@suse.de 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
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 pnaveen...@gmail.com 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 oneu...@suse.de 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
btusb_intr_complete returns -EPIPE
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
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
On Mon, 2014-10-06 at 17:05 +0530, Naveen Kumar Parna wrote: 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? It really shouldn't stall without reason. We need to know which transfers stall. A usbmon trace would show you. 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
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
Thank you very much. I will try that patch. Thanks, Naveen On Mon, Oct 6, 2014 at 6:25 PM, Oliver Neukum oneu...@suse.de 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
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
From f9f74591abed07ee71c46d443dd10176d05096c5 Mon Sep 17 00:00:00 2001
From: Oliver Neukum oneu...@suse.de
Date: Mon, 6 Oct 2014 15:27:54 +0200
Subject: [PATCH] btusb: clear halt if intr in stalls
Use a work queue for clearing a halt.
Signed-off-by: Oliver Neukum oneu...@suse.de
---
drivers/bluetooth/btusb.c | 34 --
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 292c38e..65a2c6b 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -273,6 +273,7 @@ struct btusb_data {
struct work_struct work;
struct work_struct waker;
+ struct work_struct intr_in_work;
struct usb_anchor tx_anchor;
struct usb_anchor intr_anchor;
@@ -314,14 +315,15 @@ static void btusb_intr_complete(struct urb *urb)
struct hci_dev *hdev = urb-context;
struct btusb_data *data = hci_get_drvdata(hdev);
int err;
+ int status = urb-status;
BT_DBG(%s urb %p status %d count %d, hdev-name,
- urb, urb-status, urb-actual_length);
+ urb, status, urb-actual_length);
if (!test_bit(HCI_RUNNING, hdev-flags))
return;
- if (urb-status == 0) {
+ if (status == 0) {
hdev-stat.byte_rx += urb-actual_length;
if (hci_recv_fragment(hdev, HCI_EVENT_PKT,
@@ -330,6 +332,10 @@ static void btusb_intr_complete(struct urb *urb)
BT_ERR(%s corrupted event packet, hdev-name);
hdev-stat.err_rx++;
}
+ } else if (status == -EPIPE) {
+ usb_mark_last_busy(data-udev);
+ schedule_work(data-intr_in_work);
+ return;
}
if (!test_bit(BTUSB_INTR_RUNNING, data-flags))
@@ -971,6 +977,29 @@ static void btusb_waker(struct work_struct *work)
usb_autopm_put_interface(data-intf);
}
+static void clear_halt_intr_in(struct work_struct *work)
+{
+ struct btusb_data *data = container_of(work, struct btusb_data, waker);
+ int err;
+
+ err = usb_autopm_get_interface(data-intf);
+ if (err 0)
+ return;
+
+ err = usb_clear_halt(data-udev,
+ usb_rcvbulkpipe(data-udev,
+ data-intr_ep-bEndpointAddress));
+ if (err 0)
+ return;
+
+ if (!test_bit(BTUSB_INTR_RUNNING, data-flags))
+ return;
+
+ btusb_submit_intr_urb(data-hdev, GFP_ATOMIC);
+
+ usb_autopm_put_interface(data-intf);
+}
+
static int btusb_setup_bcm92035(struct hci_dev *hdev)
{
struct sk_buff *skb;
@@ -1759,6 +1788,7 @@ static int btusb_probe(struct usb_interface *intf,
INIT_WORK(data-work, btusb_work);
INIT_WORK(data-waker, btusb_waker);
+ INIT_WORK(data-intr_in_work, clear_halt_intr_in);
spin_lock_init(data-txlock);
init_usb_anchor(data-tx_anchor);
--
1.8.4.5
Re: btusb_intr_complete returns -EPIPE
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
