Sorry it still doesn't work all the time. 90% time it works. But
sometime(very rare), I still get -EPIPE in packet 49.
In case it matters:
My motherboard is a GIgabyte GA-Z87-UD4H, and all the usb port is
connected to the USB3.0 controller in the intel Z87 chipset
lspci -vv
00:14.0 USB controller: Intel Corporation Lynx Point USB xHCI Host
Controller (rev 04) (prog-if 30 [XHCI])
Subsystem: Giga-byte Technology Device 5007
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 44
Region 0: Memory at f0520000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [70] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0-,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
Address: 00000000feeff00c Data: 41d1
Kernel driver in use: xhci_hcd
lsusb
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
|__ Port 5: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 6: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
|__ Port 9: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 10: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 4: Dev 8, If 0, Class=Human Interface Device,
Driver=usbhid, 12M
|__ Port 4: Dev 8, If 1, Class=Human Interface Device,
Driver=usbhid, 12M
|__ Port 4: Dev 8, If 2, Class=Human Interface Device,
Driver=usbhid, 12M
/: 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
/: 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
On Tue, Jul 9, 2013 at 9:26 AM, Benjamin Tissoires
<benjamin.tissoires@xxxxxxxxxx> wrote:
> On 07/09/2013 06:44 AM, wujun zhou wrote:
>> Hello Jiri,
>> Thanks for the quick reply.
>>
>>> Does the keyboard/mouse get properly discovered if you unplug and replug
>>> the receiver?
>> No. It is still not working after replug or reboot
>>
>>> What if you revert back to the 59626408 workaround (i.e. revert
>>> a9dd22b730 and 8af6c0883)?
>> It works after revert 8af6c08830b1ae114d1a8b548b1f8b056e068887.
>>
>>> so it's either rather timing sensitive, or device-specific.
>> The problem is indeed timing sensitive. Yesterday, after I inserted
>> some dbg_hid() for debuging, the problem just gone, very strange.
>>
>>
>> I think for my case, I find the reason of the problem. My device do
>> not report the expected REPORT_TYPE_NOTIF_DEVICE_PAIRED(0x41). (Not
>> discarded by the hid-core as mentioned in 8af6c0883, the hardware
>> itself has not sent the packet.)
>> Instead, the device reports a
>> REPORT_TYPE_NOTIF_CONNECTION_STATUS(0x42) event, with
>> dj_report->report_params[CONNECTION_STATUS_PARAM_STATUS]=0, the first
>> time I move the mouse.
>> And then report the normal activities of the mouse. (details about the
>> usb packets can be found in the attachment.)
>>
>
> Thanks for the logs. Your analysis is nearly good :) the problem comes
> from the frame 49 and not the 50 in your pcap logs. When calling the
> command REPORT_TYPE_CMD_GET_PAIRED_DEVICES (20 ff 81), we get an error
> -EPIPE. That means that the receiver never got the request for him to
> send the REPORT_TYPE_NOTIF_DEVICE_PAIRED(0x41).
>
> So this bug is definitively linked to the bugs closed by commit
> dcd9006b1b053c7b1cebe81333261d4fd492ffeb. There is something different
> with USB 3 hubs that triggers this -EPIPE. The urb is still not ready
> while it should.
>
> I am trying a long shot here, but could you please give a test to the
> following patch?
>
> Cheers,
> Benjamin
>
>
> From d73c86cff1be22e264fd857ebdc1fd16d07edaad Mon Sep 17 00:00:00 2001
> From: Benjamin Tissoires <benjamin.tissoires@xxxxxxxxxx>
> Date: Tue, 9 Jul 2013 18:22:29 +0200
> Subject: [PATCH] HID: logitech-dj: wait for URB completion before asking
> paired devices
>
> On some USB3 boards, once the receiver is switched to the DJ mode, if
> we try to directly call another SET_REPORT request, we get an error
> -EPIPE.
>
> Waiting for the command to complete fixes this.
>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@xxxxxxxxxx>
> ---
> drivers/hid/hid-logitech-dj.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
> index 5207591a..9a6ccf8 100644
> --- a/drivers/hid/hid-logitech-dj.c
> +++ b/drivers/hid/hid-logitech-dj.c
> @@ -766,6 +766,9 @@ static int logi_dj_probe(struct hid_device *hdev,
> /* Allow incoming packets to arrive: */
> hid_device_io_start(hdev);
>
> + /* wait for the receiver to accept other commands */
> + hid_hw_wait(hdev);
> +
> retval = logi_dj_recv_query_paired_devices(djrcv_dev);
> if (retval < 0) {
> dev_err(&hdev->dev, "%s:logi_dj_recv_query_paired_devices "
> --
> 1.8.3.1
>
>
Attachment:
logitech_with_patch.pcapng.gz
Description: GNU Zip compressed data
