> + 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 <[email protected]> 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 <[email protected]> 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
>>
>>
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 ffff880124f11cc0 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
> 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 <[email protected]> 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 ffff880124f11cc0 status -32 count 0)
>
> This points to a problem in the USB HC driver.
> Can you enable debugging in that driver.
>
> Regards
> Oliver
>
>
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 ffff880124f11cc0 status -32 count 0)
This points to a problem in the USB HC driver.
Can you enable debugging in that driver.
Regards
Oliver
> 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
ffff880128640800 id ffffffffa0197f00
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
ffff880128641000 id ffffffffa0197f00
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
ffff880131dbe3c0 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
ffff880124c45800 id ffffffffa0197f00
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
ffff880124c44c00 id ffffffffa0197f00
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
ffff880129162840 status 0 count 6
Later connected third device(hci2) and after 2mins observed –EPIPE for
hci2(hci2 urb ffff880124f11cc0 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
ffff880119c3b400 id ffffffffa0197f00
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
ffff880119c3a800 id ffffffffa0197f00
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
ffff880124f11cc0 status 0 count 6
Oct 8 17:18:22 banunxcas29 kernel: [ 2678.126333] hci2 urb
ffff880124f11cc0 status 0 count 6
Oct 8 17:20:20 banunxcas29 kernel: [ 2795.645039] hci2 urb
ffff880124f11cc0 status -32 count 0
Oct 8 17:20:20 banunxcas29 kernel: [ 2795.646013] hci2
Later connected 4th device(hci3) and now repeatedly getting –EPIPE for
hci3 and hci2
Oct 8 17:44:14 banunxcas29 kernel: [ 4226.073252] usb 1-1.5.5: new
full speed USB device number 19 using ehci_hcd
Oct 8 17:44:14 banunxcas29 kernel: [ 4226.746971] usb 1-1.5.5: New
USB device found, idVendor=0a12, idProduct=0001
Oct 8 17:44:14 banunxcas29 kernel: [ 4226.746977] usb 1-1.5.5: New
USB device strings: Mfr=0, Product=0, SerialNumber=0
Oct 8 17:44:14 banunxcas29 kernel: [ 4226.749042] intf
ffff880124c47400 id ffffffffa0197f00
Oct 8 17:44:14 banunxcas29 kernel: [ 4226.749403] hci3
Oct 8 17:44:14 banunxcas29 kernel: [ 4226.749407] hci3
Oct 8 17:44:14 banunxcas29 kernel: [ 4226.749526] intf
ffff880124c47000 id ffffffffa0197f00
Oct 8 17:44:14 banunxcas29 kernel: [ 4226.749679] hci3
Oct 8 17:44:14 banunxcas29 kernel: [ 4226.749684] hci3
Oct 8 17:44:14 banunxcas29 kernel: [ 4226.749700] hci3
Oct 8 17:44:14 banunxcas29 kernel: [ 4226.750520] hci3 urb
ffff8801344e6a80 status 0 count 6
Oct 8 17:49:45 banunxcas29 kernel: [ 4556.495180] hci3 urb
ffff8801344e6a80 status -32 count 0
Oct 8 17:49:45 banunxcas29 kernel: [ 4556.496341] hci3
Oct 8 17:51:24 banunxcas29 kernel: [ 4655.170274] hci2 urb
ffff880131c6ea80 status -32 count 0
Oct 8 17:51:24 banunxcas29 kernel: [ 4655.170345] hci3 urb
ffff880124dfb480 status -32 count 0
Oct 8 17:51:24 banunxcas29 kernel: [ 4655.171381] hci2
Oct 8 17:51:24 banunxcas29 kernel: [ 4655.171759] hci3
Oct 8 18:00:24 banunxcas29 kernel: [ 5193.920586] hci3 urb
ffff880124f11d80 status -32 count 0
Oct 8 18:00:24 banunxcas29 kernel: [ 5193.921890] hci3
Oct 8 18:00:24 banunxcas29 kernel: [ 5193.928470] hci3 urb
ffff880124f11d80 status -32 count 0
Oct 8 18:00:24 banunxcas29 kernel: [ 5193.929511] hci3
Oct 8 18:00:24 banunxcas29 kernel: [ 5193.933570] hci3 urb
ffff880124f11d80 status -32 count 0
Oct 8 18:00:24 banunxcas29 kernel: [ 5193.934402] hci3
Oct 8 18:00:24 banunxcas29 kernel: [ 5193.940425] hci3 urb
ffff880124f11d80 status -32 count 0
Oct 8 18:00:24 banunxcas29 kernel: [ 5193.941531] hci3
Oct 8 18:05:18 banunxcas29 kernel: [ 5487.003279] hci3 urb
ffff880124f11d80 status -32 count 0
Oct 8 18:05:18 banunxcas29 kernel: [ 5487.004528] hci3
Oct 8 18:06:24 banunxcas29 kernel: [ 5552.844852] hci3 urb
ffff880124f11d80 status -32 count 0
Oct 8 18:06:24 banunxcas29 kernel: [ 5552.846068] hci3
Oct 8 18:06:24 banunxcas29 kernel: [ 5552.860809] hci3 urb
ffff880124f11d80 status -32 count 0
Oct 8 18:06:24 banunxcas29 kernel: [ 5552.861776] hci3
Oct 8 18:06:24 banunxcas29 kernel: [ 5552.867701] hci3 urb
ffff880124f11d80 status -32 count 0
Oct 8 18:06:24 banunxcas29 kernel: [ 5552.868651] hci3
Oct 8 18:06:24 banunxcas29 kernel: [ 5552.874669] hci2 urb
ffff880124f11cc0 status -32 count 0
Oct 8 18:06:24 banunxcas29 kernel: [ 5552.874738] hci3 urb
ffff880124f183c0 status -32 count 0
Oct 8 18:06:24 banunxcas29 kernel: [ 5552.875772] hci2
Oct 8 18:06:24 banunxcas29 kernel: [ 5552.875949] hci3
Oct 8 18:06:24 banunxcas29 kernel: [ 5552.877734] hci2 urb
ffff880124f11cc0 status -32 count 0
Oct 8 18:06:24 banunxcas29 kernel: [ 5552.877800] hci3 urb
ffff880124f11e40 status -32 count 0
Oct 8 18:06:24 banunxcas29 kernel: [ 5552.878720] hci3
Oct 8 18:06:24 banunxcas29 kernel: [ 5552.878922] hci2
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.098220] hci3 urb
ffff880124f11cc0 status -32 count 0
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.098291] hci2 urb
ffff880124f11e40 status -32 count 0
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.099158] hci2
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.099339] hci3
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.101145] hci3 urb
ffff880124f11e40 status -32 count 0
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.102165] hci3
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.107198] hci3 urb
ffff880124f11e40 status -32 count 0
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.108141] hci3
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.121160] hci3 urb
ffff880124f11e40 status -32 count 0
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.122130] hci3
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.133127] hci2 urb
ffff880124f11cc0 status -32 count 0
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.133196] hci3 urb
ffff880124f11e40 status -32 count 0
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.134075] hci3
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.134300] hci2
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.136143] hci3 urb
ffff880124f11cc0 status -32 count 0
Oct 8 18:06:24 banunxcas29 kernel: [ 5553.136176] hci2 urb
ffff880124f11e40 status -32 count 0
I ran hcidump for each hci device separately, but it does not show any
activity during EPIPE occurrence.
It clearly tells that device not producing stalls , looks like issue
might be in between btusb and ehci_hcd\hub.
What might the best way to recover and avoid spurious stalls?
Thanks,
Naveen
On Wed, Oct 8, 2014 at 4:14 PM, Oliver Neukum <[email protected]> wrote:
> On Wed, 2014-10-08 at 15:51 +0530, Naveen Kumar Parna wrote:
>> hcidump does not show anything when the stalls happen.
>
> There is nothing in all logs. Do you see the problem
> with single devices?
>
> Regards
> Oliver
>
>
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
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: 0xffffffffffffffff
Corresponding usbmon log
ffff8801265343c0 2826295762 C Ii:1:021:1 -32:1 0
ffff880126418840 2826297275 S Ii:1:021:1 -115:1 16 <
ffff880126534240 2826298730 C Ii:1:020:1 -32:1 0
ffff880126418840 2826298856 C Ii:1:021:1 -32:1 0
ffff880126418840 2826299789 S Ii:1:020:1 -115:1 16 <
ffff880126418900 2826300154 S Ii:1:021:1 -115:1 16 <
ffff8801266329c0 2837941755 C Ii:1:018:1 -32:1 0
ffff880126632c00 2837941884 C Ii:1:016:1 -32:1 0
ffff880126418b40 2837942862 S Ii:1:016:1 -115:1 16 <
ffff880126418300 2837943184 S Ii:1:018:1 -115:1 16 <
ffff880126418300 2897160790 C Ii:1:018:1 -32:1 0
ffff880126418300 2897162701 S Ii:1:018:1 -115:1 16 <
ffff880126632cc0 2897332778 C Ii:1:019:1 -32:1 0
ffff880126418840 2897332909 C Ii:1:020:1 -32:1 0
ffff880126418900 2897332959 C Ii:1:021:1 -32:1 0
ffff880126418b40 2897333002 C Ii:1:016:1 -32:1 0
ffff880126418300 2897333035 C Ii:1:018:1 -32:1 0
ffff880126418900 2897334155 S Ii:1:021:1 -115:1 16 <
ffff880126418b40 2897334405 S Ii:1:020:1 -115:1 16 <
ffff880126418300 2897334635 S Ii:1:019:1 -115:1 16 <
ffff880126418f00 2897335015 S Ii:1:018:1 -115:1 16 <
ffff880126418840 2897335367 S Ii:1:016:1 -115:1 16 <
Corresponding kernel log:
Oct 8 15:29:38 banunxcas29 kernel: [ 3244.604776] hci7 urb
ffff8801265343c0 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
ffff880126534240 status -32 count 0
Oct 8 15:29:38 banunxcas29 kernel: [ 3244.607862] hci7 urb
ffff880126418840 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
ffff8801266329c0 status -32 count 0
Oct 8 15:29:49 banunxcas29 kernel: [ 3256.251857] hci2 urb
ffff880126632c00 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
ffff880126418300 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
ffff880126632cc0 status -32 count 0
Oct 8 15:30:49 banunxcas29 kernel: [ 3315.648411] hci6 urb
ffff880126418840 status -32 count 0
Oct 8 15:30:49 banunxcas29 kernel: [ 3315.648461] hci7 urb
ffff880126418900 status -32 count 0
Oct 8 15:30:49 banunxcas29 kernel: [ 3315.648504] hci2 urb
ffff880126418b40 status -32 count 0
Oct 8 15:30:49 banunxcas29 kernel: [ 3315.648537] hci4 urb
ffff880126418300 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 <[email protected]> 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
>
>
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
> 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 <[email protected]> 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
> ffff88012f670b40 status -32 count 0
>
> Oct 7 17:58:41 naveen-OptiPlex-745 kernel: [ 16.311988] hci5 urb
> ffff8801379d2180 status -32 count 0
>
> Oct 7 17:58:41 naveen-OptiPlex-745 kernel: [ 16.455464] hci4 urb
> ffff88012a4b2e40 status -32 count 0
>
> Oct 7 17:58:41 naveen-OptiPlex-745 kernel: [ 16.455586] hci1 urb
> ffff88012a4b2180 status -32 count 0
>
> Oct 7 17:58:41 naveen-OptiPlex-745 kernel: [ 16.455691] hci2 urb
> ffff88012f670480 status -32 count 0
>
> Oct 7 17:58:41 naveen-OptiPlex-745 kernel: [ 16.455784] hci3 urb
> ffff88012f670e40 status -32 count 0
>
> Oct 7 17:58:41 naveen-OptiPlex-745 kernel: [ 16.455853] hci0 urb
> ffff880131e5ee40 status -32 count 0
>
> Oct 7 17:58:41 naveen-OptiPlex-745 kernel: [ 16.455913] hci5 urb
> ffff880131e5e780 status -32 count 0
>
> Oct 7 17:58:44 naveen-OptiPlex-745 kernel: [ 19.690366] hci4 urb
> ffff880131e5e780 status -32 count 0
>
> Oct 7 17:58:44 naveen-OptiPlex-745 kernel: [ 19.690490] hci5 urb
> ffff880131e5e300 status -32 count 0
>
> Oct 7 17:58:47 naveen-OptiPlex-745 kernel: [ 22.163163] hci5 urb
> ffff88012f541540 status -32 count 0
>
> Oct 7 18:06:01 naveen-OptiPlex-745 kernel: [ 45.313996] hci1 urb
> ffff880131e5ee40 status -32 count 0
>
> Oct 7 18:06:01 naveen-OptiPlex-745 kernel: [ 45.314121] hci0 urb
> ffff880131e5e900 status -32 count 0
>
> Oct 7 18:06:01 naveen-OptiPlex-745 kernel: [ 45.314169] hci3 urb
> ffff880131e5e3c0 status -32 count 0
>
> Oct 7 18:06:01 naveen-OptiPlex-745 kernel: [ 45.314213] hci2 urb
> ffff880131e5ef00 status -32 count 0
>
> Oct 7 18:06:01 naveen-OptiPlex-745 kernel: [ 45.314245] hci4 urb
> ffff88012f541d80 status -32 count 0
>
> Oct 7 18:06:01 naveen-OptiPlex-745 kernel: [ 45.314274] hci5 urb
> ffff88012f541540 status -32 count 0
>
> Oct 7 18:06:01 naveen-OptiPlex-745 kernel: [ 45.319974] hci2 urb
> ffff8801384dcb40 status -32 count 0
>
> Oct 7 18:06:01 naveen-OptiPlex-745 kernel: [ 45.320095] hci0 urb
> ffff8801384dc300 status -32 count 0
>
> Oct 7 18:06:01 naveen-OptiPlex-745 kernel: [ 45.320151] hci4 urb
> ffff8801384dc6c0 status -32 count 0
>
> Oct 7 18:06:01 naveen-OptiPlex-745 kernel: [ 45.320193] hci5 urb
> ffff8801384dcf00 status -32 count 0
>
>
>
> Thanks,
>
> Naveen
>
> On Tue, Oct 7, 2014 at 3:31 PM, Oliver Neukum <[email protected]> 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
>>
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
ffff88012f670b40 status -32 count 0
Oct 7 17:58:41 naveen-OptiPlex-745 kernel: [ 16.311988] hci5 urb
ffff8801379d2180 status -32 count 0
Oct 7 17:58:41 naveen-OptiPlex-745 kernel: [ 16.455464] hci4 urb
ffff88012a4b2e40 status -32 count 0
Oct 7 17:58:41 naveen-OptiPlex-745 kernel: [ 16.455586] hci1 urb
ffff88012a4b2180 status -32 count 0
Oct 7 17:58:41 naveen-OptiPlex-745 kernel: [ 16.455691] hci2 urb
ffff88012f670480 status -32 count 0
Oct 7 17:58:41 naveen-OptiPlex-745 kernel: [ 16.455784] hci3 urb
ffff88012f670e40 status -32 count 0
Oct 7 17:58:41 naveen-OptiPlex-745 kernel: [ 16.455853] hci0 urb
ffff880131e5ee40 status -32 count 0
Oct 7 17:58:41 naveen-OptiPlex-745 kernel: [ 16.455913] hci5 urb
ffff880131e5e780 status -32 count 0
Oct 7 17:58:44 naveen-OptiPlex-745 kernel: [ 19.690366] hci4 urb
ffff880131e5e780 status -32 count 0
Oct 7 17:58:44 naveen-OptiPlex-745 kernel: [ 19.690490] hci5 urb
ffff880131e5e300 status -32 count 0
Oct 7 17:58:47 naveen-OptiPlex-745 kernel: [ 22.163163] hci5 urb
ffff88012f541540 status -32 count 0
Oct 7 18:06:01 naveen-OptiPlex-745 kernel: [ 45.313996] hci1 urb
ffff880131e5ee40 status -32 count 0
Oct 7 18:06:01 naveen-OptiPlex-745 kernel: [ 45.314121] hci0 urb
ffff880131e5e900 status -32 count 0
Oct 7 18:06:01 naveen-OptiPlex-745 kernel: [ 45.314169] hci3 urb
ffff880131e5e3c0 status -32 count 0
Oct 7 18:06:01 naveen-OptiPlex-745 kernel: [ 45.314213] hci2 urb
ffff880131e5ef00 status -32 count 0
Oct 7 18:06:01 naveen-OptiPlex-745 kernel: [ 45.314245] hci4 urb
ffff88012f541d80 status -32 count 0
Oct 7 18:06:01 naveen-OptiPlex-745 kernel: [ 45.314274] hci5 urb
ffff88012f541540 status -32 count 0
Oct 7 18:06:01 naveen-OptiPlex-745 kernel: [ 45.319974] hci2 urb
ffff8801384dcb40 status -32 count 0
Oct 7 18:06:01 naveen-OptiPlex-745 kernel: [ 45.320095] hci0 urb
ffff8801384dc300 status -32 count 0
Oct 7 18:06:01 naveen-OptiPlex-745 kernel: [ 45.320151] hci4 urb
ffff8801384dc6c0 status -32 count 0
Oct 7 18:06:01 naveen-OptiPlex-745 kernel: [ 45.320193] hci5 urb
ffff8801384dcf00 status -32 count 0
Thanks,
Naveen
On Tue, Oct 7, 2014 at 3:31 PM, Oliver Neukum <[email protected]> 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
>
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