btusb_intr_complete returns -EPIPE

[Naveen Kumar Parna]

Hi,

I am using =E2=80=9C3.1.0-7.fc16.x86_64=E2=80=9D kernel and testing ei=
ght 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 ffff88012954dd80 status -32 count 0

[ 1389.411367] hci4 urb ffff88012954d3c0 status -32 count 0

[ 1389.411845] hci1 urb ffff88012b4b6b40 status -32 count 0

[ 1389.412238] hci2 urb ffff8801347ee0c0 status -32 count 0

[ 1518.647255] hci3 urb ffff88012954dd80 status -32 count 0

[ 1518.647722] hci4 urb ffff88012954d3c0 status -32 count 0

[ 1518.648120] hci1 urb ffff88012b4b6b40 status -32 count 0

[ 1518.648514] hci2 urb ffff8801347ee0c0 status -32 count 0

[ 1518.722033] hci2 urb ffff8801347ee0c0 status -32 count 0

[ 2191.964545] hci4 urb ffff88012954d3c0 status -32 count 0

[ 2191.965001] hci1 urb ffff88012b4b6b40 status -32 count 0

[ 2191.965396] hci2 urb ffff8801347ee0c0 status -32 count 0

[ 2191.966530] hci2 urb ffff8801347ee0c0 status -32 count 0

[ 2191.975514] hci4 urb ffff88012954d3c0 status -32 count 0

[ 2191.975936] hci1 urb ffff88012b4b6b40 status -32 count 0

[ 2191.976330] hci2 urb ffff8801347ee0c0 status -32 count 0

[ 2191.977503] hci4 urb ffff88012954d3c0 status -32 count 0

[ 2191.977929] hci1 urb ffff88012b4b6b40 status -32 count 0

[ 2191.978325] hci2 urb ffff8801347ee0c0 status -32 count 0

[ 2560.132682] hci2 urb ffff8801347ee0c0 status -32 count 0

[ 2569.160895] hci4 urb ffff88012954d3c0 status -32 count 0

[ 2569.161367] hci1 urb ffff88012b4b6b40 status -32 count 0

[ 2569.161827] hci2 urb ffff8801347ee0c0 status -32 count 0

[ 3022.252541] hci2 urb ffff8801347ee0c0 status -32 count 0

[ 3022.254504] hci2 urb ffff8801347ee0c0 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=E2=80=99t see the error(-EPIPE) handling code in btusb module=
=2E Does
anyone has the patch for this scenario?

Thanks,
Naveen

[Naveen Kumar Parna]

Hi,

I am using =E2=80=9C3.1.0-7.fc16.x86_64=E2=80=9D kernel and testing ei=
ght 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 ffff88012954dd80 status -32 count 0

[ 1389.411367] hci4 urb ffff88012954d3c0 status -32 count 0

[ 1389.411845] hci1 urb ffff88012b4b6b40 status -32 count 0

[ 1389.412238] hci2 urb ffff8801347ee0c0 status -32 count 0

[ 1518.647255] hci3 urb ffff88012954dd80 status -32 count 0

[ 1518.647722] hci4 urb ffff88012954d3c0 status -32 count 0

[ 1518.648120] hci1 urb ffff88012b4b6b40 status -32 count 0

[ 1518.648514] hci2 urb ffff8801347ee0c0 status -32 count 0

[ 1518.722033] hci2 urb ffff8801347ee0c0 status -32 count 0

[ 2191.964545] hci4 urb ffff88012954d3c0 status -32 count 0

[ 2191.965001] hci1 urb ffff88012b4b6b40 status -32 count 0

[ 2191.965396] hci2 urb ffff8801347ee0c0 status -32 count 0

[ 2191.966530] hci2 urb ffff8801347ee0c0 status -32 count 0

[ 2191.975514] hci4 urb ffff88012954d3c0 status -32 count 0

[ 2191.975936] hci1 urb ffff88012b4b6b40 status -32 count 0

[ 2191.976330] hci2 urb ffff8801347ee0c0 status -32 count 0

[ 2191.977503] hci4 urb ffff88012954d3c0 status -32 count 0

[ 2191.977929] hci1 urb ffff88012b4b6b40 status -32 count 0

[ 2191.978325] hci2 urb ffff8801347ee0c0 status -32 count 0

[ 2560.132682] hci2 urb ffff8801347ee0c0 status -32 count 0

[ 2569.160895] hci4 urb ffff88012954d3c0 status -32 count 0

[ 2569.161367] hci1 urb ffff88012b4b6b40 status -32 count 0

[ 2569.161827] hci2 urb ffff8801347ee0c0 status -32 count 0

[ 3022.252541] hci2 urb ffff8801347ee0c0 status -32 count 0

[ 3022.254504] hci2 urb ffff8801347ee0c0 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=E2=80=99t see the error(-EPIPE) handling code in btusb module=
=2E Does
anyone has the patch for this scenario?

Thanks,
Naveen

[Oliver Neukum]

These errors will repeat until sending a proper HCI command on the US=

B

bus. Again after some time duration same error will repeats.
=20
The error -32(-EPIPE) says , Endpoint stalled. For non-control
endpoints, reset this status with usb_clear_halt().
=20
But I don=E2=80=99t see the error(-EPIPE) handling code in btusb modu=

le. 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 majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Oliver Neukum]

Hi,
I just collected the usbmon log(1.mon.out) and attached it. It stalls
for INT in transfers.
Oct 6 18:00:48 naveen-OptiPlex-745 kernel: [ 7528.718473] hci3 urb
ffff88012954dd80 status -32 count 0
Oct 6 18:05:35 naveen-OptiPlex-745 kernel: [ 7814.688122] hci3 urb
ffff88012954dd80 status -32 count 0
Oct 6 18:05:35 naveen-OptiPlex-745 kernel: [ 7814.693086] hci3 urb
ffff88012954dd80 status -32 count 0
Oct 6 18:05:35 naveen-OptiPlex-745 kernel: [ 7814.695058] hci3 urb
ffff88012954dd80 status -32 count 0
Oct 6 18:05:35 naveen-OptiPlex-745 kernel: [ 7814.703073] hci3 urb
ffff88012954dd80 status -32 count 0
Oct 6 18:05:35 naveen-OptiPlex-745 kernel: [ 7814.717038] hci5 urb
ffff88012954de40 status -32 count 0
Oct 6 18:05:35 naveen-OptiPlex-745 kernel: [ 7814.717496] hci3 urb
ffff88012954dd80 status -32 count 0
ffff88012954dd80 2936526502 C Ii:1:009:1 -32:1 0
ffff88012954dd80 3223215374 C Ii:1:009:1 -32:1 0
ffff88012954dd80 3223220352 C Ii:1:009:1 -32:1 0
ffff88012954dd80 3223222332 C Ii:1:009:1 -32:1 0
ffff88012954dd80 3223230362 C Ii:1:009:1 -32:1 0
ffff88012954de40 3223244362 C Ii:1:019:1 -32:1 0
ffff88012954dd80 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 majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Naveen Kumar Parna]

Thank you very much. I will try that patch.



Thanks,
Naveen

Post by Oliver Neukum

Hi,
I just collected the usbmon log(1.mon.out) and attached it. It stalls
for INT in transfers.
Oct 6 18:00:48 naveen-OptiPlex-745 kernel: [ 7528.718473] hci3 urb
ffff88012954dd80 status -32 count 0
Oct 6 18:05:35 naveen-OptiPlex-745 kernel: [ 7814.688122] hci3 urb
ffff88012954dd80 status -32 count 0
Oct 6 18:05:35 naveen-OptiPlex-745 kernel: [ 7814.693086] hci3 urb
ffff88012954dd80 status -32 count 0
Oct 6 18:05:35 naveen-OptiPlex-745 kernel: [ 7814.695058] hci3 urb
ffff88012954dd80 status -32 count 0
Oct 6 18:05:35 naveen-OptiPlex-745 kernel: [ 7814.703073] hci3 urb
ffff88012954dd80 status -32 count 0
Oct 6 18:05:35 naveen-OptiPlex-745 kernel: [ 7814.717038] hci5 urb
ffff88012954de40 status -32 count 0
Oct 6 18:05:35 naveen-OptiPlex-745 kernel: [ 7814.717496] hci3 urb
ffff88012954dd80 status -32 count 0
ffff88012954dd80 2936526502 C Ii:1:009:1 -32:1 0
ffff88012954dd80 3223215374 C Ii:1:009:1 -32:1 0
ffff88012954dd80 3223220352 C Ii:1:009:1 -32:1 0
ffff88012954dd80 3223222332 C Ii:1:009:1 -32:1 0
ffff88012954dd80 3223230362 C Ii:1:009:1 -32:1 0
ffff88012954de40 3223244362 C Ii:1:019:1 -32:1 0
ffff88012954dd80 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 majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Oliver Neukum]

Post by Naveen Kumar Parna
Thank you very much. I will try that patch.

Then please try.

Regards
Oliver

[Naveen Kumar Parna]

Thanks for the patch.

I tried and It crashed after the first occurrence of EPIPE.

Crash log is attached.

Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.188379] hci4 urb
ffff880127ad9240 status -32 count 0
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.188556] BUG: unable
to handle kernel paging request at 00000000000102a0
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.189281] IP:
[<ffffffff812e53c9>] atomic_inc+0x9/0xe
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.189634] PGD
127884067 PUD 131fc0067 PMD 0
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.189989] Oops: 0002 [#1] SMP
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.190337] CPU 6
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.190344] Modules
linked in: rfcomm bnep btusb bluetooth rfkill babel nfs fscache
auth_rpcgss nfs_acl lockd iTCO_wdt iTCO_vendor_support i2c_i801
i2c_core tg3 joydev sunrpc uinput microcode hpsa usb_storage uas [last
unloaded: scsi_wait_scan]
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.192109]
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.192442] Pid: 53,
comm: kworker/6:1 Not tainted 3.1.0-7.fc16.x86_64 #1 HP ProLiant DL120
G6/ProLiant DL120 G6
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.193151] RIP:
0010:[<ffffffff812e53c9>] [<ffffffff812e53c9>] atomic_inc+0x9/0xe
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.193839] RSP:
0018:ffff88013868ddb0 EFLAGS: 00010202
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.194273] RAX:
ffff880128191c78 RBX: 0000000000010130 RCX: ffff880128191c70
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.194625] RDX:
ffff880128191c70 RSI: 0000000000000004 RDI: 00000000000102a0
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.194979] RBP:
ffff88013868ddb0 R08: ffff880128191c78 R09: 0000000000608007
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.195329] R10:
0000000000608007 R11: ffff88013fd92f80 R12: 0000000000010100
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.195680] R13:
0000000000010130 R14: 0000000000000004 R15: ffff88013fd96805
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.196032] FS:
0000000000000000(0000) GS:ffff88013fd80000(0000)
knlGS:0000000000000000
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.196716] CS: 0010
DS: 0000 ES: 0000 CR0: 000000008005003b
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.197063] CR2:
00000000000102a0 CR3: 000000012a613000 CR4: 00000000000006e0
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.197422] DR0:
0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.197780] DR3:
0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.198138] Process
kworker/6:1 (pid: 53, threadinfo ffff88013868c000, task
ffff880138690000)
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.198811] Stack:

Message from ***@naveen-OptiPlex-745 at Oct 6 19:49:24 ...
kernel:[ 979.189989] Oops: 0002 [#1] SMP

Message from ***@naveen-OptiPlex-745 at Oct 6 19:49:24 ...
kernel:[ 979.198811] Stack:
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.199146]
ffff88013868ddf0 ffffffff812e645c ffffffff81605920 ffff88013fd92f80
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.199831]
ffff880128191c70 0000000000010100 0000000000010130 ffffffffa0091b49
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.200525]
ffff88013868de20 ffffffff8133a672 ffff880128191c70 ffff880128191c70
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.201211] Call Trace:
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.201550]
[<ffffffff812e645c>] __pm_runtime_resume+0x2c/0x65
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.201907]
[<ffffffffa0091b49>] ? btusb_submit_intr_urb+0x173/0x173 [btusb]
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.202268]
[<ffffffff8133a672>] usb_autopm_get_interface+0x23/0x52
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.202626]
[<ffffffffa0091b60>] clear_halt_intr_in+0x17/0xac [btusb]
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.202978]
[<ffffffff8106edbc>] process_one_work+0x176/0x2a9
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.203331]
[<ffffffff8106f8ca>] worker_thread+0xda/0x15d
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.203680]
[<ffffffff8106f7f0>] ? manage_workers+0x176/0x176
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.204022]
[<ffffffff81072d17>] kthread+0x84/0x8c
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.204365]
[<ffffffff814be5f4>] kernel_thread_helper+0x4/0x10
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.204711]
[<ffffffff81072c93>] ? kthread_worker_fn+0x148/0x148
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.205058]
[<ffffffff814be5f0>] ? gs_change+0x13/0x13
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.205402] Code: d9 81
e8 07 f6 ff ff 80 3d 24 26 ab 00 00 75 05 e8 da f7 ff ff 8a 05 17 26
ab 00 41 5b 5b 5d c3 90 90 55 48 89 e5 66 66 66 66 90 <f0> ff 07 5d c3
55 48 89 e5 66 66 66 66 90 f0 ff 0f 0f 94 c0 84
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.206652] RIP
[<ffffffff812e53c9>] atomic_inc+0x9/0xe
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.207007] RSP
<ffff88013868ddb0>
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.207354] CR2: 00000000000102a0
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.208287] ---[ end
trace 0089da2b8191af16 ]---
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.208739] BUG: unable
to handle kernel paging request at fffffffffffffff8
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.208742] IP:
[<ffffffff81072f65>] kthread_data+0x11/0x16
Oct 6 19:49:24 naveen-OptiPlex-745 kernel: [ 979.208747] PGD 1a07067
PUD 1a08067 PMD 0

Thanks,
Naveen

Post by Oliver Neukum

Post by Naveen Kumar Parna
Thank you very much. I will try that patch.

Then please try.
Regards
Oliver

[Oliver Neukum]

Post by Naveen Kumar Parna
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

[Naveen Kumar Parna]

+ err =3D usb_clear_halt(data->udev,
+ usb_rcvbulkpipe(data->udev,
+ data->intr_ep->bEndpoint=

Address));

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


Does the =E2=80=9Clsusb =E2=80=93v=E2=80=9D gives any clue about the re=
ason for getting -EPIPE?

Thanks,
Naveen

Attached the lsusb -v file.
Captured the usbmon log file for this patch and attached it.
Thanks,
Naveen

Post by Oliver Neukum

Post by Naveen Kumar Parna
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

[Oliver Neukum]

Post by Naveen Kumar Parna

+ err = usb_clear_halt(data->udev,
+ usb_rcvbulkpipe(data->udev,
+ data->intr_ep->bEndpointAddress));

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

Yes. And I noticed a copy and past error.

Post by Naveen Kumar Parna
Does the “lsusb –v” gives any clue about the reason for getting -EPIPE?

No. Could you nevertheless test the attached version?

Regards
Oliver

[Naveen Kumar Parna]

Thanks for the new patch.



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



Corresponding kernel log is here:

Oct 7 17:58:41 naveen-OptiPlex-745 kernel: [ 16.311863] hci0 urb
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

Post by Oliver Neukum

+ err =3D usb_clear_halt(data->udev,
+ usb_rcvbulkpipe(data->udev,
+ data->intr_ep->bEndpo=

intAddress));

Post by Oliver Neukum

EPIPE occurred for INT in endpoint, so we should use usb_rcvintpipe(=

)

Post by Oliver Neukum

instead of usb_rcvbulkpipe() right?

Yes. And I noticed a copy and past error.

Does the =E2=80=9Clsusb =E2=80=93v=E2=80=9D gives any clue about the=

reason for getting -EPIPE?

Post by Oliver Neukum
No. Could you nevertheless test the attached version?
Regards
Oliver

[Naveen Kumar Parna]

Post by Naveen Kumar Parna
The new patch clears the halt condition.

I mean usb_clear_halt( ) returned zero.


Thanks,

Naveen

Post by Naveen Kumar Parna
Thanks for the new patch.
The new patch clears the halt condition. But after submitting the urb
again the INT in endpoint returns EPIPE, this behavior continues
infinitely.
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

Post by Oliver Neukum

+ err =3D usb_clear_halt(data->udev,
+ usb_rcvbulkpipe(data->udev,
+ data->intr_ep->bEndp=

ointAddress));

Post by Naveen Kumar Parna

Post by Oliver Neukum

EPIPE occurred for INT in endpoint, so we should use usb_rcvintpipe=

()

Post by Naveen Kumar Parna

Post by Oliver Neukum

instead of usb_rcvbulkpipe() right?

Yes. And I noticed a copy and past error.

Does the =E2=80=9Clsusb =E2=80=93v=E2=80=9D gives any clue about th=

e reason for getting -EPIPE?

Post by Naveen Kumar Parna

Post by Oliver Neukum
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 majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Oliver Neukum]

Post by Naveen Kumar Parna

Post by Naveen Kumar Parna
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 majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Naveen Kumar Parna]

hcidump does not show anything when the stalls happen.



Here is the hcidump log:

[***@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

Post by Oliver Neukum

Post by Naveen Kumar Parna

Post by Naveen Kumar Parna
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 majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Oliver Neukum]

Post by Naveen Kumar Parna
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

[Naveen Kumar Parna]

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 =E2=80=93EPIPE.

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=3D0451, idProduct=3D2036

Oct 8 16:41:46 banunxcas29 kernel: [ 488.093494] usb 1-1.5.1.7: New
USB device strings: Mfr=3D0, Product=3D1, SerialNumber=3D0

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=3D0a12, idProduct=3D0001

Oct 8 16:41:47 banunxcas29 kernel: [ 488.518208] usb 1-1.5.2: New
USB device strings: Mfr=3D0, Product=3D0, SerialNumber=3D0

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 =E2=80=93EPIPE.

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=3D0a12, idProduct=3D0001

Oct 8 16:57:45 banunxcas29 kernel: [ 1444.400993] usb 1-1.5.3: New
USB device strings: Mfr=3D0, Product=3D0, SerialNumber=3D0

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 =E2=80=93EP=
IPE 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=3D0a12, idProduct=3D0001

Oct 8 17:18:21 banunxcas29 kernel: [ 2677.681735] usb 1-1.5.4: New
USB device strings: Mfr=3D0, Product=3D0, SerialNumber=3D0

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 =E2=80=93EP=
IPE 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=3D0a12, idProduct=3D0001

Oct 8 17:44:14 banunxcas29 kernel: [ 4226.746977] usb 1-1.5.5: New
USB device strings: Mfr=3D0, Product=3D0, SerialNumber=3D0

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

Post by Naveen Kumar Parna
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

[Oliver Neukum]

Later connected third device(hci2) and after 2mins observed =E2=80=93=

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

[Naveen Kumar Parna]

Post by Oliver Neukum
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 drive=
r?



Thanks,

Naveen

Post by Oliver Neukum

Later connected third device(hci2) and after 2mins observed =E2=80=93=

EPIPE for

Post by Oliver Neukum

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

[Alan Stern]

Post by Oliver Neukum

Later connected third device(hci2) and after 2mins observed =E2=80=93=

EPIPE for

Post by Oliver Neukum

hci2(hci2 urb ffff880124f11cc0 status -32 count 0)

=20
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.=
=20
I have seen a report of a hub that sends STALL when a bunch of devices=20
are plugged in, even though the devices themselves did not send a=20
STALL.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Alan Stern]

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 majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Oliver Neukum]

Post by Alan Stern

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 majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Naveen Kumar Parna]

EHCI controller on PCI card and hub("rate-matching" hub) also internal.

Is it possible to change the internal hub?



Thanks,
Naveen

Post by Oliver Neukum

Post by Alan Stern

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

[Naveen Kumar Parna]

Hi Oliver,

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



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

[***@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 H=
ub

Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching H=
ub

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.

[***@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 =E2=80=9CIf the device runs =
at low
speed or full speed and is connected through a USB-2.0 hub=E2=80=9D? If=
so it
looks like hub driver issue right?


If the hub is the problem=E2=80=A6 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

EHCI controller on PCI card and hub("rate-matching" hub) also interna=

l.

Is it possible to change the internal hub?
Thanks,
Naveen

Post by Oliver Neukum

Hi Oliver & Alan,
Thanks for your inputs.
I enabled the dynamic debugging for USB HC driver. Please correct=

me

Post by Oliver Neukum

if I am wrong.

Debugging the kernel (or doing anything else to the kernel, for tha=

t

Post by Oliver Neukum

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 majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Alan Stern]

Post by Naveen Kumar Parna
Hi Oliver,
=20
I tried this test in two different set of hardware configurations.
=20
=20
=20
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 configuratio=

n

Post by Naveen Kumar Parna
gives spurious stall packets.
=20
=20
00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipse=

t

Post by Naveen Kumar Parna
USB2 Enhanced Host Controller (rev 05)
=20
00:1d.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipse=

t

Post by Naveen Kumar Parna
USB2 Enhanced Host Controller (rev 05)
=20
=20
=20
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching=

Hub

Post by Naveen Kumar Parna
=20
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching=

Hub

Post by Naveen Kumar Parna
=20
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
=20
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
=20
=20
=20
=20
=20
ii) I found different test systems which has
OHCI-USB host controller on PCI card and internal USB 1.1 hub. All th=

e

Post by Naveen Kumar Parna
test systems with this configuration are not producing stall packets.
=20
=20
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev =

a2)

Post by Naveen Kumar Parna
=20
00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev =

a3)

Post by Naveen Kumar Parna
=20
=20
=20
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
=20
Bus 002 Device 002: ID 0451:2077 Texas Instruments, Inc. TUSB2077 Hub
=20
=20
=20
=20
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. =20
When a full-speed device is connected to a USB-2 hub, and the device=20
fails to respond to a packet sent by the host, the hub reports this=20
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.

Post by Naveen Kumar Parna
Is there a chance of getting stall packets =E2=80=9CIf the device run=

s at low

Post by Naveen Kumar Parna
speed or full speed and is connected through a USB-2.0 hub=E2=80=9D? =

If so it

Post by Naveen Kumar Parna
looks like hub driver issue right?

If the problem is that the device fails to respond to a packet then it=20
is an issue with the device.

Post by Naveen Kumar Parna
If the hub is the problem=E2=80=A6 what will be the better solution? =

Is it

Post by Naveen Kumar Parna
possible to change internal hub?

No, it is not possible.

Alan Stern

[Naveen Kumar Parna]

Post by Alan Stern
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.

Post by Alan Stern
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

[Alan Stern]

It's entirely possible that the stall packets are created by the hu=

b.

When a full-speed device is connected to a USB-2 hub, and the devic=

e

fails to respond to a packet sent by the host, the hub reports this
failure as a stall.

=20
Here I don=E2=80=99t think device fails to respond to a packet sent b=

y the

host. I verified this by connecting Ellisys USB analyser in between
host and devices.
=20
For example Look at the attached(Sample_HciEvt.png) HCI event capture=

d

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=
=20
properly on these four occasions. What if the device failed to respond=
=20
on some other occasion? You have to compare the output of the analyzer=
=20
with the output from usbmon. If usbmon shows a STALL and the analyzer=20
shows a valid reply for the very same packet, then you'll know the=20
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=20
the other test, connect the analyzer to the cable segment between the=20
hub and the device.

Alan Stern

[Naveen Kumar Parna]

It's entirely possible that the stall packets are created by the h=

ub.

When a full-speed device is connected to a USB-2 hub, and the devi=

ce

fails to respond to a packet sent by the host, the hub reports thi=

s

failure as a stall.

Here I don=E2=80=99t 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 captur=

ed

by Ellisys USB analyser. It is a valid HCI event from device to Host=

=2E

IN transaction 96 1 ACK FS 16 bytes (FF 2F C2 01 00 17 00 DF 00 01 1=

0

00 00 A9 EE 0F)
IN transaction 96 1 ACK FS 16 bytes (00 00 00 5A 06 9D 39 00 00 66 0=

0

00 00 00 00 00)
IN transaction 96 1 ACK FS 16 bytes (00 00 00 00 00 00 00 00 00 00 0=

0

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 respond=

ed

properly on these four occasions. What if the device failed to respo=

nd

on some other occasion? You have to compare the output of the analyz=

er

with the output from usbmon. If usbmon shows a STALL and the analyze=

r

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=E2=80=99s I used same device=
s.

You should also run a similar test when you connect the device throug=

h

a USB-2 hub. In fact, you should run two tests. In one test, connec=

t

the analyzer to the cable segment between the computer and the hub; i=

n

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

[Oliver Neukum]

Post by Alan Stern

If the hub is the problem=E2=80=A6 what will be the better solution=

? Is it

Post by Alan Stern

possible to change internal hub?

=20
No, it is not possible.

Indeed. However, it is possible to use an additional in between your
devices and the internal hub.

Regards
Oliver

[Naveen Kumar Parna]

Post by Oliver Neukum

Post by Alan Stern

If the hub is the problem=E2=80=A6 what will be the better soluti=

on? Is it

Post by Oliver Neukum

Post by Alan Stern

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=3Droot_hub, Driver=3Dehci-pci/2p, 480M

/: Bus 01.Port 1: Dev 1, Class=3Droot_hub, Driver=3Dehci-pci/2p, 480M

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

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

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

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

|__ Port 2: Dev 12, If 0, Class=3Dvend., Driver=3D, 12M

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

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

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

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

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

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

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

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

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

|__ Port 2: Dev 5, If 2, Class=3Dapp., Driver=3D, 12M

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

|__ Port 2: Dev 19, If 2, Class=3Dapp., Driver=3D, 12M

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

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

|__ Port 3: Dev 20, If 2, Class=3Dapp., Driver=3D, 12M
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Alan Stern]

Post by Naveen Kumar Parna

Post by Oliver Neukum
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 majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Naveen Kumar Parna]

Ok, I will do this and update you.
But Currently I am on long leave and I can update you on 27th Oct.

Thanks,
Naveen

Post by Alan Stern

Post by Naveen Kumar Parna

Post by Oliver Neukum
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