Bug 60507

confirming the bug.
Logitech wireless trackball (unifying receiver) is detected on the USB bus, but further action to activate it as a mouse device does not occur.

Andreas' analysis above is correct.

Please *REVERT* kernel commit 

https://git.kernel.org/cgit/linux/kernel/git/jikos/hid.git/commit/?id=8af6c08830b1ae114d1a8b548b1f8b056e068887

because the code it removes is still necessary to properly associate the
mouse with the logitech unifying receiver.  The messages sent during "probe"
phase are getting diverted and ignored. The additional re-probes proviede by the code this commit removes are still required.

My Performance MX mouse is also affected. Kernel versions 3.10.0 and 3.10.1 are affected, 3.9.10 and all earlier 3.9 versions that I used are not affected.

I also get a message in the kernel that the Logitech receiver is detected, but no mouse is.

(In reply to Andreas Reis from comment #0)
> My wireless mouse (Anywhere MX) isn't registered anymore in 3.10.0.
> 
> "dmesg | grep HID" still contains:
> [    2.191916] logitech-djreceiver 0003:046D:C52B.0005: hiddev0,hidraw2: USB
> HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-8/input2
> 
> A quick search showed that this workaround in hid-logitech-dj was reverted
> in 3.10.0 for a proper solution, which unfortunately doesn't work, at least
> not for all devices:
> 
> https://git.kernel.org/cgit/linux/kernel/git/jikos/hid.git/commit/
> ?id=8af6c08830b1ae114d1a8b548b1f8b056e068887
> 
> I reapplied the workaround (introduced Oct, 2012:
> https://patchwork.kernel.org/patch/1562431 ) and the cursor moves again.
> "dmesg | grep HID" then also contains:
> 
> [   22.285488] logitech-djdevice 0003:046D:C52B.0006: input,hidraw3: USB HID
> v1.11 Mouse [Logitech Unifying Device. Wireless PID:1017] on
> usb-0000:00:14.0-8:1
> 
> Others have confirmed the bug, see Launchpad (I use Arch):
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1194649

I am experiencing this bug as well.

Andreas, could you please explain to me how you reapplied the old workaround? I am running Fedora 19 if that makes any difference. I would very much appreciate it, I am a newbie to Linux. Thank you. :)

Basically it's just inserting this line before the make command(s) into the build script (I don't know how Fedora/YUM/RPM handles this, so I can't help you there, sorry):

patch -Np1 -i [if required: /path/to/patch/]patchfile

Check "man patch" for an explanation of these CL arguments.

See also discussion at LKML[1]. A workaround that triggers re-enumeration without having to remove the USB receiver[2] (essentially same magic as in hid-logitech-dj driver):

# should output /dev/hidrawN where N is usually 0
hidraw=/dev/$(cd /sys/bus/hid/drivers/logitech-djreceiver/*/hidraw &&
echo hidraw*)
printf '\x20\xff\x81\0\0\0\0\0\0\0\0\0\0\0\0' | sudo tee "$hidraw" >/dev/null

 [1]: http://www.spinics.net/lists/linux-input/msg26713.html
 [2]: https://bbs.archlinux.org/viewtopic.php?pid=1309535#p1309535

@Andreas Reis,

As the OP, on any 3.10+ vanilla kernel, please attach
1) complete dmesg output
2) usbmon capture of a plug attempt

Created attachment 107220 [details]
cellisten's dmesg

I got these files from cellisten from the Arch Linux forums[1].

 [1]: https://bbs.archlinux.org/viewtopic.php?pid=1312624#p1312624

Created attachment 107221 [details]
cellisten's lsusb -v

The affected 001.004 (bus.dev) device is using the xhci driver (see dmesg).
Part from lsusb:

    Bus 001 Device 004: ID 046d:c52b Logitech, Inc. Unifying Receiver

Created attachment 107222 [details]
cellisten's usbmon (via debugfs)

Post-processing the usbmon output with an AWK script[1] helped me find an issue. Consider this part:

ffff8803f4802cc0 3000314283 S Ii:1:012:3 -115:2 32 <
ffff8803f4802840 3000314443 C Co:1:012:0 0 15 >
ffff8803f4802840 3000314449 S Co:1:012:0 s 21 09 0220 0002 000f 15 = 20ff8100 00000000 00000000 000000
ffff8803f4802840 3000314525 C Co:1:012:0 -32 0

After sending an enumeration report to the receiver (20 ff 81 00..), a callback is returned with -EPIPE. This sounds familiar, it was reported to the mailing lists before by Benjamin Tissoires[2].

After 3.3 seconds, the receiver reports a connected device:
ffff8803f4802cc0 3003676450 C Ii:1:012:3 0:2 15 = 20014200 00000000 00000000 000000

I do not know what is happening here, let me know if you need more details.


 [1]: https://git.lekensteyn.nl/ltunify/tree/usbmon.awk
 [2]: https://lkml.kernel.org/r/CAN+gG=HKe0eNBmwaf=h6nzR9U3DPC-Hvb1W-uwVqjih5AiKUuQ@mail.gmail.com

I am Cellisten, if you want me to try any patches, just tell me. The dmesg and lsusb was captured after I had renumerated the receiver to make it work. The usbmon was captured after I unplugged the receiver and reinserted it. I have a 100% failure rate when doing that. Best regards /Balder

@Peter and Balder,

Thanks for all the trace and report data.
Please open a *new* kernel bug assigned to Drivers/USB with the files and commentary you posted here.

The OP for this bug may or may not have the identical problem you're experiencing, so this may confuse the proper resolution of both your bug and the OP's.

I suspect your bug is a known bug with the xhci-hcd driver that needs to get fixed.

@Balder, please open a new bug. Can you also try 3.11-rc6 with commit c63e0e370028d7e4033bd40165f18499872b5183 reverted?

I could not reproduce the XHCI issue on my laptop which runs 3.11-rc6 (with that commit reverted).

(In reply to Peter from comment #13)
> @Balder, please open a new bug. Can you also try 3.11-rc6 with commit
> c63e0e370028d7e4033bd40165f18499872b5183 reverted?
> 
> I could not reproduce the XHCI issue on my laptop which runs 3.11-rc6 (with
> that commit reverted).

Perhaps commit 481f2d4f89f87a0baa26147f323380e31cfa7c44 'usb: core: don't try to reset_device() a port that got just disconnected' has addressed one aspect of the underlying bug and therefore not triggered the xHCI reset-on-not-halted-endpoint bug?

Can you revert commit 481f2d4f on vanilla 3.11-rc6 and reproduce this bug?

I reverted 481f2d4f and c63e0e3 on top of 3.11-rc6, but I can still not reproduce the bug. I cannot reproduce it on my laptop (M525) nor my desktop (K800). On the desktop, I also tried vanilla 3.10.5 which still does not expose the bug. Below you can find lshw output for the machines.

When comparing Baldars usbmon with the one from my desktop, there is absolutely no difference in the data except for the callback output ("-32 0" vs "0 15 >") and the additional NOTIF_DEVICE_PAIRED messages using isochronous input (for my working desktop).

In order to compare the usbmon logs, I use the following bash functions:
##################################################
filter(){ sed -r -e "s/^[0-9a-f]+ [0-9]+ /# /" -e \
"s/([IC][oi]:)[0-9]:0[0-9][0-9]:[0-9]/\1#:0##:#/" "$@";}
comp() {
    diff -u --label "$1" --label "$2" \
        <(filter "$1") <(filter "$2")
}
ccomp(){ colordiff -u "$@" | less -r; }
ccomp usbmon-xhci usbmon-xhci-new
##################################################

lshw for my laptop:
        *-pci:1
             description: PCI bridge
             product: 5 Series/3400 Series Chipset PCI Express Root Port 1
             vendor: Intel Corporation
             physical id: 1c
             bus info: pci@0000:00:1c.0
             version: 05
             width: 32 bits
             clock: 33MHz
             capabilities: pci normal_decode bus_master cap_list
             configuration: driver=pcieport
             resources: irq:16 ioport:3000(size=4096) memory:fc000000-fcffffff ioport:fa000000(size=16777216)
           *-usb
                description: USB controller
                product: uPD720200 USB 3.0 Host Controller
                vendor: NEC Corporation
                physical id: 0
                bus info: pci@0000:02:00.0
                version: 03
                width: 64 bits
                clock: 33MHz
                capabilities: xhci bus_master cap_list
                configuration: driver=xhci_hcd latency=0
                resources: irq:16 memory:fc000000-fc001fff

lshw for desktop:
        *-pci:2
             description: PCI bridge
             product: 6 Series/C200 Series Chipset Family PCI Express Root Port 5
             vendor: Intel Corporation
             physical id: 1c.4
             bus info: pci@0000:00:1c.4
             version: b5
             width: 32 bits
             clock: 33MHz
             capabilities: pci normal_decode bus_master cap_list
             configuration: driver=pcieport
             resources: irq:16 memory:f7a00000-f7afffff
           *-usb
                description: USB controller
                product: EJ168 USB 3.0 Host Controller
                vendor: Etron Technology, Inc.
                physical id: 0
                bus info: pci@0000:04:00.0
                version: 01
                width: 64 bits
                clock: 33MHz
                capabilities: xhci bus_master cap_list
                configuration: driver=xhci_hcd latency=0
                resources: irq:40 memory:f7a00000-f7a07fff

I will try to find some time this week to troubleshoot further.

*** Bug 60572 has been marked as a duplicate of this bug. ***

What is the status of this bug? Commit 8af6c088 was reverted in kernels 3.11.0 (commit c63e0e37) and 3.10.27, so I believe the bug should be gone when using these or more recent kernels. Andreas (or others), can you confirm?

Yes, this bug should be closed.  Kernels in 3.13.x series are working fine without having to tweak hid/logitech-dj.c