Regression - Logitech Mouse with Unified Receiver not working

[Rainer Rohde]

Folks,

my Logitech mouse with unified receiver is not working anymore after stepping up to kernel 3.10.0-0-generic on Saucy. When plugging in the unified receiver, I can observe the following dmesg output:

[ 470.852109] usb 3-4: new full-speed USB device number 3 using xhci_hcd
[ 470.870530] usb 3-4: New USB device found, idVendor=046d, idProduct=c52b
[ 470.870533] usb 3-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 470.870535] usb 3-4: Product: USB Receiver
[ 470.870536] usb 3-4: Manufacturer: Logitech
[ 470.875417] logitech-djreceiver 0003:046D:C52B.0006: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-4/input2

However, the mouse does not work. With kernel version 3.9.0-7-generic and some previous kernels, everything was fine.

Please note that I reported a very similar issue some time ago for kernel version 3.5 (https://bugs.launchpad.net/bugs/1039143).

My current laptop is a ASUS G75VW, with USB3 ports only.

Thanks.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: linux-image-3.10.0-0-generic 3.10.0-0.7
ProcVersionSignature: Ubuntu 3.10.0-0.7-generic 3.10.0-rc7
Uname: Linux 3.10.0-0-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.10.2-0ubuntu3
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: rrohde 2739 F.... pulseaudio
 /dev/snd/controlC0: rrohde 2739 F.... pulseaudio
Date: Tue Jun 25 15:51:14 2013
MachineType: ASUSTeK COMPUTER INC. G75VW
MarkForUpload: True
ProcEnviron:
 LANGUAGE=en_US
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB: 0 EFI VGA
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.10.0-0-generic root=UUID=4dac4492-a4d7-4a6d-97bf-ed5c1ee0b1a0 ro elevator=noop quiet splash resume=/swapfile.swap vt.handoff=7
PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions:
 linux-restricted-modules-3.10.0-0-generic N/A
 linux-backports-modules-3.10.0-0-generic N/A
 linux-firmware 1.109
SourcePackage: linux
StagingDrivers: zram
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 01/07/2013
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: G75VW.223
dmi.board.asset.tag: ATN12345678901234567
dmi.board.name: G75VW
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: 1.0
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK COMPUTER INC.
dmi.chassis.version: 1.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrG75VW.223:bd01/07/2013:svnASUSTeKCOMPUTERINC.:pnG75VW:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnG75VW:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:
dmi.product.name: G75VW
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK COMPUTER INC.

[Brad Figg (brad-figg)]

This change was made by a bot.

[Joseph Salisbury (jsalisbury)]

I'd like to perform a bisect to figure out what commit caused this regression. It would be very helpful to know the earliest kernel where the issue started happening as well as the latest kernel that did not have this issue.

Can you test the following kernels and report back? We are looking for the earliest kernel version that exhibits this bug:

v3.10-rc4: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10-rc4-saucy/

If v3.10-rc4 does not exhibit the bug then test v3.8-rc6:
v3.10-rc6: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10-rc6-saucy/

If v3.10-rc4 does exhibit the bug then test v3.8-rc2:
v3.10-rc2: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10-rc2-saucy

You don't have to test every kernel, just up until the kernel that first has this bug.

Thanks in advance!

[Rainer Rohde (rainer-rohde)]

@Joseph,

3.10.0-031000rc4-generic has the bug.

For now, I went back to 3.9.0-7-generic to get my mouse to work.

[Joseph Salisbury (jsalisbury)]

Can you also test v3.10-rc2? If it also has the bug, test v3.10-rc1.

Thanks again.

[Rainer Rohde (rainer-rohde)]

@Joseph,

kernel 3.10.0-031000rc2-generic *has* the bug; kernel 3.10.0-031000rc1-generic also *has* the bug.

[Joseph Salisbury (jsalisbury)]

Can you see if the bug exists in the final version of 3.9:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.9-saucy/

If it does not, I can start a bisect between v3.9 and v3.10-rc1.

[Rainer Rohde (rainer-rohde)]

@Joseph:

kernel 3.9.0-030900-generic *does not* have the bug.

[Joseph Salisbury (jsalisbury)]

Thanks for testing. I'll start a bisect between v3.9 and v3.10-rc1. As a quick test, can you confirm that v3.10-rc7 also has the bug, since it's the latest mainline release:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10-rc7-saucy/

[Rainer Rohde (rainer-rohde)]

@Joseph,

kernel 3.10.0-031000rc7-generic *has* the bug, and, FYI, the newly released (June 28) kernel 3.10.0-1-generic also *has* the bug.

[Andrew Woodward (xarses)]

I also have the bug on 3.10.0-1-generic

[nwt (nwt)]

Same bug for me (Anywhere MX mouse). A quick search turned up that this workaround
https://patchwork.kernel.org/patch/1562431/raw/
was reverted in 3.10 for a proper, but apparently faulty solution:
https://git.kernel.org/cgit/linux/kernel/git/jikos/hid.git/commit/?id=8af6c08830b1ae114d1a8b548b1f8b056e068887

Reapplying it made my cursor move again.

[Rainer Rohde (rainer-rohde)]

Just FYI -- kernel 3.10.0-2-generic (via dist-upgrade on July 1) also has the bug...

[Joseph Salisbury (jsalisbury)]

I started a kernel bisect between v3.9 final and v3.10-rc1. The kernel bisect will require testing of about 7-10 test kernels.

I built the first test kernel, up to the following commit:
73287a43cc79ca06629a88d1a199cd283f42456a

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1194649

Can you test that kernel and report back if it has the bug or not. I will build the next test kernel based on your test results.

Thanks in advance

[Rainer Rohde (rainer-rohde)]

Joseph,

kernel 3.9.0-030900-generic *has* the bug.

[Andrew Woodward (xarses)]

Still impacted by this.
Joseph, Is there any possibility that we can get some of the other kernels you mentioned to test?

[Rainer Rohde (rainer-rohde)]

+1

I reverted back to an old Logitech Trackball with USB cable for now... lol.

[Andrew Woodward (xarses)]

I applied the patch from @nwt into 3.10.0-2-generic on my local system and it resolved this issue.

[Joseph Salisbury (jsalisbury)]

@Andrew, so a revert of the revert done by commit 8af6c08 fixes this bug? If that is the case, we should get in touch with upstream to let them know that commit is still needed.

[Andrew Woodward (xarses)]

@Joseph, It fixed the problem for me, I Just don't know how to let them know the commit is still needed.

[Joseph Salisbury (jsalisbury)]

Thanks for the info, Andrew. I'll send a message to the patch author and upstream to inform them.

[Rainer Rohde (rainer-rohde)]

Just FYI -- Kernel version 3.10.0-3-generic still has the bug.

[Joseph Salisbury (jsalisbury)]

Right. Working with upstream to get commit 8af6c088 reverted.

[Peter Hurley (phurley)]

@Ranier,
Thanks for your persistence in resolving these bugs.

I read through the history of in bug #1039143, and I agree with you that one aspect of this problem is unique to USB3 ports. I forwarded the discussion regarding this bug on the linux kernel mailing list to one of the xhci_hcd authors.

She would like to obtain usbmon log to confirm if this is related to a known bug in the xhci_hcd driver. I realize you've provided several of these already but it would be helpful if you could perform the usbmon capture on 3.10 mainline (not stable) which is here: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10-saucy/

Regards,
Peter Hurley

[Joseph Salisbury (jsalisbury)]

@Ranier,

This issue is being discussed upstream[0]. One of the requests from upstream is to provide dmesg output with CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING turned on.

I built a Saucy kernel with CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING enabled. The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1194649

You will need to install both the linux-image and linux-image-extra .debs.

Can you run a test with this kernel and provide the dmesg output?

Thanks again for all your help!

[0] https://lkml.org/lkml/2013/7/18/558

[Rainer Rohde (rainer-rohde)]

@Joseph, and Peter:

Hope this information from dmesg is useful:

[ 23.866692] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 23.868677] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 23.874676] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 23.882670] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 23.890666] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 23.898664] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 23.906659] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 23.912656] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 23.920653] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 23.928647] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 23.936644] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 23.944638] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 23.952636] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 23.990618] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 23.998611] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 24.005391] show_signal_msg: 147 callbacks suppressed
[ 24.005397] SyncThread[2394]: segfault at 98 ip 00000000004931b6 sp 00007fde948a22d0 error 4 in python2.7[400000+2bb000]
[ 24.006606] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 24.014605] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 24.022600] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 24.030595] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 24.038592] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 24.046589] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 24.054584] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 24.062580] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 24.070574] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 24.078571] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 24.084569] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 24.092566] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 24.100581] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 24.108568] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 24.116546] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 24.124552] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 24.132548] xhci_hcd 0000:00:14.0: ep 0x83 - asked for 32 bytes, 17 bytes untransferred
[ 24.140535] xhci_hcd 0000:00:14.0: e...

[Rainer Rohde (rainer-rohde)]

Just FYI,

today's kernel release of 3.10.0-5-generic still *has* the bug.

What's the outlook on getting this fixed?

Thanks.

[Peter Hurley (phurley)]

@Ranier,

Thanks for the test run data. I pushed that along to the USB3 maintainers so they can address the underlying bug.

I don't know what their schedule is; native xHCI support is new so there may be more pressing issues to address. I suspect if there's no movement in a week or two, the workaround will go back into mainline until the xHCI bug is resolved.

I would expect the Ubuntu kernel to follow suit.

[Rainer Rohde (rainer-rohde)]

Thanks Peter. I appreciate the info.

[nwt (nwt)]

Oddly enough, that second commit with accompanied the revert of the revert seems to have broken it yet again:
https://lkml.org/lkml/2013/7/18/261

It's just one single assignment, but with it my Anywhere MX wouldn't work (on 3.11-rc4). I'm not entirely sure if it's to blame though, maybe it were just two boots in the driver failed for some other reason.

[Rainer Rohde (rainer-rohde)]

Since my cat shredded the mouse cable, I am now in dire need of the universal receiver for my wireless mouse to work. The touchpad is just no substitute for real mouse input. So, is there an ETA as to when we can expect a final and complete fix?

[Andrew Woodward (xarses)]

Rainer,

You can (re)apply the patch that was reverted and rebuild the kernel yourself. This will break (U)EFI secure boot.

see https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel

You can use the kernel I built for myself, I have applyed the afore mentioned patch and a patch to stop the multi-tough palm errors in the cypress driver (https://bugs.launchpad.net/dell-sputnik/+bug/1048258). However you have no reason to expect that it is safe to use. There is no warranty, expressed or implied, and the kernel is not fit for any purpose.

https://www.dropbox.com/sh/vrr3du9iivs47sx/jqlyiyIx4N

[Rainer Rohde (rainer-rohde)]

Andrew,

I will give your kernel a shot and let you know. :)

I appreciate it.

[Rainer Rohde (rainer-rohde)]

Just FYI -- kernel version 3.10.0-6-generic still has the bug...

[Rainer Rohde (rainer-rohde)]

@Andrew --

Your 3.10.0-5-generic did the trick. Thanks again. :) It's nice to be able to use a mouse again.

Let's hope that the official fix will be available really soon, too. I am still scratching my head how something so seemingly mundane takes so long to get fixed. ;)

[nwt (nwt)]

I've just done another round of testing, said additional one-liner which accompanies the revert indeed rebreaks it for me yet again.

[Rainer Rohde (rainer-rohde)]

Hard to believe -- yet sad and true -- today's update to kernel version 3.11.0-0-generic still has the bug... :(

[Rainer Rohde (rainer-rohde)]

FYI - today's kernel update to 3.11.0-1-generic still has the bug.... :(

[Joseph Salisbury (jsalisbury)]

Upstream has decided[0] to revert commit 8af6c088. The revert should land in the 3.11 kernel shortly.

[0] https://lkml.org/lkml/2013/8/9/131

[Rainer Rohde (rainer-rohde)]

Thanks for the heads-up, Joseph. I greatly appreciate everybody's work towards fixing this.

[Rainer Rohde (rainer-rohde)]

Joseph - on another note (since I am able to interface with you here in this thread): How do I go about reporting regressions with ACPI related calls? With Saucy, I've lost pretty much all of my Fn key functions for my ASUS G75VW laptop, including --

Fn+F2 = Toggle wifi on/off
Fn+F3/F4 = Toggle keybord backlight on/off
Fn+F4/F5 = Toggle screen brightness level
Fn+F9 = Toggle touchpad on/off

Any pointers as to what to file these against? Not trying to hijack this topic here... ;)

[Joseph Salisbury (jsalisbury)]

Commit 8af6c088 is now reverted in 3.11-rc5. Can folks affected by this bug test that kernel, and post back if it resolves this bug:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.11-rc5-saucy/

[Joseph Salisbury (jsalisbury)]

@Rainer Rohde, It's probably best to open a new bug for the ACPI regressions. That was we can perform a bisect and keep track of the commits we've tested in the bug report.

[Andreas Egli (kharan-kangon)]

The new saucy kernel 3.11.0-2.5 which is based on 3.11-rc5 resolved the issue, my keyboard and mouse are working again. Thanks a lot!

[Rainer Rohde (rainer-rohde)]

I can confirm that the current iteration of kernel version 3.11.0-2-generic fixed the bug for me as well. Thanks to everyone involved. :)