One more data point:

On another system, the same kernel has no problem with a similar Logitech device:

kernel: usb 4-1: New USB device found, idVendor=046d, idProduct=c52b
kernel: usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
kernel: usb 4-1: Product: USB Receiver
kernel: usb 4-1: Manufacturer: Logitech
kernel: logitech-djreceiver 0003:046D:C52B.0003: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:1a.1-1/input2
kernel: input: Logitech Unifying Device. Wireless PID:1025 as /devices/pci0000:00/0000:00:1a.1/usb4/4-1/4-1:1.2/0003:046D:C52B.0003/input/input2
kernel: logitech-djdevice 0003:046D:C52B.0004: input,hidraw1: USB HID v1.11 Mouse [Logitech Unifying Device. Wireless PID:1025] on usb-0000:00:1a.1-1:1

This system is a Dell desktop and the failing system is a Dell XPS13 laptop.

Working system (desktop):

$ lsusb
Bus 001 Device 003: ID 152d:2329 JMicron Technology Corp. / JMicron USA Technology Corp. JM20329 SATA Bridge
Bus 004 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 006 Device 002: ID 413c:2003 Dell Computer Corp. Keyboard
Bus 007 Device 002: ID 051d:0002 American Power Conversion Uninterruptible Power Supply
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
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
$

Failing system (laptop):

$ lsusb
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 003 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver
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
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 1bcf:288f Sunplus Innovation Technology Inc. 
Bus 002 Device 003: ID 8087:07da Intel Corp. 
$

I tried physically swapping the devices and the laptop system continues to fail and the desktop system works fine.

I'm having the same problem on an Asus N56VZ with a Logitech m905 Anywhere MX mouse and unifying receiver.

dmesg:
[  200.291738] usb 3-3: new full-speed USB device number 5 using xhci_hcd
[  200.305443] usb 3-3: New USB device found, idVendor=046d, idProduct=c52b
[  200.305450] usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  200.305464] usb 3-3: Product: USB Receiver
[  200.305465] usb 3-3: Manufacturer: Logitech
[  200.310684] logitech-djreceiver 0003:046D:C52B.000A: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-3/input2

lsusb entry:
Bus 003 Device 005: ID 046d:c52b Logitech, Inc. Unifying Receiver

This looks like it's probably https://bugzilla.kernel.org/show_bug.cgi?id=60507

Is there any chance the kernel package could carry a patch for this until this bug gets attention upstream? The Asus N56 has a fairly terrible touchpad. =(

Benjamin, any thoughts on this one?

There are already few upstream discussions about this bug. I thought it was related to the 3.11-rc series, but actually, this land into 3.10.

So, the current consensus is to revert commit 8af6c08830b1ae114d1a8b548b1f8b056e068887 (Revert "HID: Fix logitech-dj: missing Unifying device issue"), which triggers the bug until we find out the true USB3 problem.

It should be fixed in this branch (just 2 commits from Nestor):
http://git.kernel.org/cgit/linux/kernel/git/jikos/hid.git/log/?h=for-3.11/logitech-enumeration-fix

I'm not sure when this will land in Linus' tree or in stable tree, but definitively, we can revert the revert in Fedora.

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

OK, I've added those two patches.  Thanks Benjamin!

kernel-3.10.4-300.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/kernel-3.10.4-300.fc19

I installed https://admin.fedoraproject.org/updates/kernel-3.10.4-300.fc19 but it doesn't fix the mouse.

garry@tfr$ rpm -qa|grep kernel|grep 4-300
kernel-modules-extra-3.10.4-300.fc19.x86_64
kernel-headers-3.10.4-300.fc19.x86_64
kernel-3.10.4-300.fc19.x86_64
kernel-devel-3.10.4-300.fc19.x86_64
garry@tfr$

Any other information I can provide?

Hmm... I'm not seeing any improvement from 3.10.4-300 either. =( No change in log output as far as I can tell.

hmm... this is strange. I would need then the usbmon traces.
Please run wireshark (as root :( ), then start a capture for the usbmon devices. Plug your receiver, wait few seconds, and then move your mouse.
Stop the capture, and attach the results to the bug.

Which of usbmons I needed to capture?

Created attachment 781296 [details]
wireshark screenshot

Created attachment 781399 [details]
wireshark capture

I'm attaching a trace from wireshark.

(In reply to Mikhail from comment #11)
> Which of usbmons I needed to capture?

I'm not that familiar with wireshark, so there's probably a better way to do this, but you can use lsusb to figure out which bus your device's USB port is on (while it's plugged in, of course), and later on capture the usbmon device corresponding to that bus.

Created attachment 781403 [details]
wireshark capture for kernel 3.10.4-300.fc19.x86_64

Attaching additional wireshark captures in case they're useful. This is for the non-working but patched kernel 3.10.4-300.fc19.x86_64

I'll attach another capture for the working kernel 3.9.9-302.fc19.x86_64 - unfortunately I don't have the unpatched kernel 3.10.3-300.fc19.x86_64 on hand, but I suppose I could install it if a trace from that would be useful.

Created attachment 781404 [details]
wireshark capture for kernel 3.9.9-302.fc19.x86_64

thanks for the traces. I got all I need.

Josh can you remove the second patch sent by Nestor (HID-hid-logitech-dj-querying_devices-was-never-set.patch)? It does break the enumeration. With only the revert, we will be at the same state than we were on the 3.9 series.

Dropped.  Should be in the next build.  Thanks for working through this everyone.

Thank you for the prompt response. =)

I see a kernel 3.10 build for Fedora 18 which doesn't seem to be carrying the revert patch. Will the patch be needed there as well?

kernel-3.10.4-300.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Reopening as this isn't quite fixed yet.

Please see also my capture. May be not same problem, because when I plug mouse directly it works, not work's when I plug mouse via USB hub. Also not worked USB flash when I plug via USB hub.

Created attachment 782144 [details]
my capture of pluging mouse

(In reply to Mikhail from comment #22)
> Please see also my capture. May be not same problem, because when I plug
> mouse directly it works, not work's when I plug mouse via USB hub. Also not
> worked USB flash when I plug via USB hub.

Well, this is the exact same problem. hid-logitech-dj reveal a bug in the USB subsystem, and the current fix is a total workaround. So the fix should work for you too (for the mouse part, not the flash one).

Additional data point.  I did a local build of the git master (rawhide) 3.11.0 rc4 branch, kernel-3.11.0-0.rc4.git0.1.fc20.x86_64, and it has the same problem.

i am having the same situation with my logitech m600 wireless mouse not connecting. but the odd thing is this: if i start up a vm running windows 8 (yeah, i know), the mouse works in the windows vm. if i then run the logitech unifying software to sync the mouse with the usb transmitter, and then shut down the vm, the mouse works in fedora 19.

for what it's worth...

dmesg snip after plugging in my connector before running the vm:

[ 1972.830927] usb 3-2: new full-speed USB device number 6 using xhci_hcd
[ 1972.844731] usb 3-2: New USB device found, idVendor=046d, idProduct=c52b
[ 1972.844742] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1972.844748] usb 3-2: Product: USB Receiver
[ 1972.844753] usb 3-2: Manufacturer: Logitech
[ 1972.850341] logitech-djreceiver 0003:046D:C52B.000F: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-2/input2

and here is everything after that last line having started and stopped my win 8 vm:

[ 2126.970573] cgroup: libvirtd (1306) created nested cgroup for controller "memory" which has incomplete hierarchy support. Nested cgroups may change behavior in the future.
[ 2126.970576] cgroup: "memory" requires setting use_hierarchy to 1 on the root.
[ 2126.970736] cgroup: libvirtd (1306) created nested cgroup for controller "blkio" which has incomplete hierarchy support. Nested cgroups may change behavior in the future.
[ 2127.005740] device vnet0 entered promiscuous mode
[ 2127.010948] virbr0: topology change detected, propagating
[ 2127.010952] virbr0: port 2(vnet0) entered forwarding state
[ 2127.010966] virbr0: port 2(vnet0) entered forwarding state
[ 2136.997228] virbr0: port 2(vnet0) entered disabled state
[ 2136.997641] device vnet0 left promiscuous mode
[ 2136.997650] virbr0: port 2(vnet0) entered disabled state
[ 2148.762725] device vnet0 entered promiscuous mode
[ 2148.776951] virbr0: topology change detected, propagating
[ 2148.776957] virbr0: port 2(vnet0) entered forwarding state
[ 2148.776970] virbr0: port 2(vnet0) entered forwarding state
[ 2149.499801] usb 3-2: reset full-speed USB device number 6 using xhci_hcd
[ 2149.511831] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801672b96c0
[ 2149.511836] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801672b90c0
[ 2149.511839] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801672b9440
[ 2149.570606] usb 3-2: usbfs: interface 0 claimed by usbhid while 'qemu-system-x86' sets config #1
[ 2161.851089] usb 3-2: reset full-speed USB device number 6 using xhci_hcd
[ 2161.863144] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801672b96c0
[ 2161.863149] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801672b90c0
[ 2161.863160] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801672b9440
[ 2161.865431] logitech-djreceiver 0003:046D:C52B.0010: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-2/input2
[ 2161.870132] input: Logitech Unifying Device. Wireless PID:401a as /devices/pci0000:00/0000:00:14.0/usb3/3-2/3-2:1.2/0003:046D:C52B.0010/input/input11
[ 2161.870272] logitech-djdevice 0003:046D:C52B.0013: input,hidraw1: USB HID v1.11 Mouse [Logitech Unifying Device. Wireless PID:401a] on usb-0000:00:14.0-2:1
[ 2162.046183] usb 3-2: reset full-speed USB device number 6 using xhci_hcd
[ 2162.058285] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801672b96c0
[ 2162.058288] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801672b90c0
[ 2162.058290] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801672b9440
[ 2162.154589] usb 3-2: usbfs: interface 0 claimed by usbhid while 'qemu-system-x86' sets config #1
[ 2291.426237] virbr0: port 2(vnet0) entered disabled state
[ 2291.426294] device vnet0 left promiscuous mode
[ 2291.426302] virbr0: port 2(vnet0) entered disabled state
[ 2291.586536] usb 3-2: reset full-speed USB device number 6 using xhci_hcd
[ 2291.598626] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801672b96c0
[ 2291.598638] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801672b90c0
[ 2291.598644] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801672b9440
[ 2291.600952] logitech-djreceiver 0003:046D:C52B.0014: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-2/input2
[ 2291.610449] input: Logitech Unifying Device. Wireless PID:401a as /devices/pci0000:00/0000:00:14.0/usb3/3-2/3-2:1.2/0003:046D:C52B.0014/input/input12
[ 2291.610596] logitech-djdevice 0003:046D:C52B.0017: input,hidraw1: USB HID v1.11 Mouse [Logitech Unifying Device. Wireless PID:401a] on usb-0000:00:14.0-2:1

@Zach Carter:

yes, the patch is on its way to Linus, so hopefully it will be in the next rc.

@mock:

yes, this is normal given the way the driver is written.

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

For me on Fedora 19 with "Anywhere MX" after upgrading from 3.9.x to 3.10.4 the mouse stops working. 
From the previous comments it should be fixed via workaround patch on 3.10.4, so after some research I found that mouse works again if I "unpair & pair" it again.

You can do that on Fedora 19 with "ltunify", so on my system I fixed the problem with:

# git clone https://git.lekensteyn.nl/ltunify.git
# cd ltunify
# make
cc -g -O2 -Wall -Wextra -D_FORTIFY_SOURCE=2 -fstack-protector --param ssp-buffer-size=4  -o ltunify ltunify.c
cc -g -O2 -Wall -Wextra -D_FORTIFY_SOURCE=2 -fstack-protector --param ssp-buffer-size=4  -o read-dev-usbmon read-dev-usbmon.c
# ./ltunify list
Devices count: 1
Connected devices:
idx=1	Mouse	Anywhere MX

" Not Working at this stage"

# ./ltunify -d /dev/hidraw0 unpair 1
Device 0x01 Mouse successfully unpaired
# ./ltunify -d /dev/hidraw0 pair 10
Please turn your wireless device off and on to start pairing.
Found new device, id=0x01 Mouse
# ./ltunify list
Devices count: 1
Connected devices:
idx=1	Mouse	Anywhere MX

Working again!

So if you are on kernel 3.10.4 and mouse is not working yet try "unpair/pair" and see if that also fixes the issue 

Regards,
\\CA,

I indeed have tried this and it works.

ltunify.c seems to have enough code in it to make it useful in creating a plugin control for the KDE mouse settings since it looks like you can check on status/etc of the pairing.

The code should be trivial.  I will see what I can cook up and get back to you.

Very nice, thank you.

-gc

guys, please do not do such hackish way to fix this problem. I know that you can not use your mouse right now, but it is a matter of days or even hours.
So, please, if you want to use your mouse, the simplest way is to run a previous 3.9 fedora kernel, and you will be just fine.

BTW, if you want to make a KDE plugin with ltunify, I'm ok, but don't say that this is the solution to fix the current problem.

I installed the following kernel-3.10.5-201.fc19 build and the problem is fixed there, no hacks needed:

http://koji.fedoraproject.org/koji/buildinfo?buildID=454939

(In reply to Carlos Almeida from comment #29)

> # git clone https://git.lekensteyn.nl/ltunify.git

ltunify is already part of fedora, so you should be able to avoid the compile and just do "yum install ltunify"

Yes, I see that.

However, the version in the repo is too old.

The one in GIT allowed me to unpair etc.

Also, the GIT version seems to have a lot of status query possibilities with the unify driver, making it suitable for a gui interface.

-gc

Just FYI: using the version already in Fedora, I was able to unpair/pair successfully, and it "fixed" the problem for me.

But I also agree with Benjamin, the correct fix here is to get a kernel out that fixes the issue.

kernel-3.10.5-201.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/kernel-3.10.5-201.fc19

Just out of curiosity, what GIT submission ID fixed the issue for upcoming 3.10.6?

-gc

(In reply to Zach Carter from comment #32)
> I installed the following kernel-3.10.5-201.fc19 build and the problem is
> fixed there, no hacks needed:
> 
> http://koji.fedoraproject.org/koji/buildinfo?buildID=454939

Confirmed.  This fixes the regression.

kernel-3.10.5-201.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.