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
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
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
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
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
[
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
+ 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
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
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
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
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]
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]
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
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
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.
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
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
42 matches
Mail list logo
