046d:c52b Problems using Logitech Unifying Receiver

Bug #1072082 reported by Robert John Bowles on 2012-10-27
16
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Medium
Unassigned

Bug Description

Commit that caused the regression 534a7b8e10ec55d9f521e68c20dbb3634c25b98a.

I recently purchased a new Logitech K350 keyboard (UK layout) and M505 mouse, both of which use the Logitech Unifying Receiver. I 'paired' the keyboard and mouse to the receiver by using the proprietary Logitech 'Setpoint' software on a friend's computer running Windows XP. On their computer, the receiver, keyboard and mouse worked perfectly.

I then moved the receiver to my own computer, a new Dell Inspiron 7520 SE running under Ubuntu 12.04.1. I tried with no success to get the keyboard and mouse to work by repeatedly unplugging and re-plugging the receiver, and by re-booting the machine.

I experimented with solutions posted on the web, in particular in this thread on Ask Ubuntu (http://askubuntu.com/questions/128345/logitech-m515-does-not-work-after-upgrade-to-12-04/202627#202627). The accepted answer did not solve my problem.

WORKAROUND: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1072082/+attachment/3415472/+files/mousefix running this workaround script on the command line enabled the receiver. I added the script to crontab as suggested. The script does not cause the receiver to work after a reboot, but I found that a single unplug/replug cycle was now sufficient to restore operation of the keyboard and mouse.

Potential duplicate of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1039143 .

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: linux-image-3.2.0-32-generic 3.2.0-32.51
ProcVersionSignature: Ubuntu 3.2.0-32.51-generic 3.2.30
Uname: Linux 3.2.0-32-generic x86_64
NonfreeKernelModules: fglrx
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
ApportVersion: 2.0.1-0ubuntu14
Architecture: amd64
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: PCH [HDA Intel PCH], device 0: CONEXANT Analog [CONEXANT Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: bob 1987 F.... pulseaudio
CRDA:
 country DE:
  (2400 - 2483 @ 40), (N/A, 20)
  (5150 - 5250 @ 40), (N/A, 20), NO-OUTDOOR
  (5250 - 5350 @ 40), (N/A, 20), NO-OUTDOOR, DFS
  (5470 - 5725 @ 40), (N/A, 26), DFS
Card0.Amixer.info:
 Card hw:0 'PCH'/'HDA Intel PCH at 0xc1610000 irq 47'
   Mixer name : 'Intel PantherPoint HDMI'
   Components : 'HDA:14f1506e,10280572,00100003 HDA:80862806,80860101,00100000'
   Controls : 25
   Simple ctrls : 12
Date: Sat Oct 27 14:28:16 2012
HibernationDevice: RESUME=UUID=ff03d603-a284-462d-9451-fc56344430f4
InstallationMedia: Ubuntu 12.04.1 LTS "Precise Pangolin" - Release amd64 (20120823.1)
MachineType: Dell Inc. Inspiron 7520
ProcEnviron:
 LANGUAGE=en_GB:en
 TERM=xterm
 PATH=(custom, user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-32-generic root=UUID=31a3cccd-851f-461b-8918-bee5a4814e66 ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.2.0-32-generic N/A
 linux-backports-modules-3.2.0-32-generic N/A
 linux-firmware 1.79.1
SourcePackage: linux
StagingDrivers: rts5139 mei
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 08/13/2012
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A05
dmi.board.name: 0PXH02
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.chassis.version: A05
dmi.modalias: dmi:bvnDellInc.:bvrA05:bd08/13/2012:svnDellInc.:pnInspiron7520:pvrA05:rvnDellInc.:rn0PXH02:rvrA00:cvnDellInc.:ct8:cvrA05:
dmi.product.name: Inspiron 7520
dmi.product.version: A05
dmi.sys.vendor: Dell Inc.

Brad Figg (brad-figg) on 2012-10-27
Changed in linux (Ubuntu):
status: New → Confirmed
summary: - Problems using Logitech Unifying Receiver
+ 046d:c52b Problems using Logitech Unifying Receiver
description: updated

Further notes about the use of mousefix:
Having installed the script in root crontab, plug cycling the receiver at the login screen restores keyboard and mouse function.
Plug cycling _after_ login does not work, but the script does restore keyboard and mouse function when run as root from the console command line.
An example console session is attached.

description: updated
Changed in linux (Ubuntu):
importance: Undecided → Medium

Robert John Bowles, thank you for reporting this and helping make Ubuntu better. As per http://www.dell.com/support/drivers/us/en/19/Product/inspiron-15r-se-7520 an update is available for your BIOS (A07). If you update to this, does this change anything?

tags: added: bios-outdated needs-upstream-testing
Changed in linux (Ubuntu):
status: Confirmed → Incomplete

Christopher M. Penalver, thank you for notifying me of the BIOS upgrade. I downloaded it, but it is provided only as a Windows executable. I have requested guidance from Dell on how to implement the BIOS upgrade under Ubuntu. I will advise as/when I have further information. Meanwhile I am investigating how to implement the upgrade via web searches.

Robert John Bowles, does the following article help you update your BIOS https://help.ubuntu.com/community/BiosUpdate ?

Christopher M. Panalver, the short answer is 'no'. The article appears to be out of date, the publication was in 2009, and it refers to pages that were last active in 2008 or before. The links to Dell sites express plans and aspirations that do not appear to have been implemented.

So far I have tried two other approaches, both using FreeDOS, one from USB (http://ubuntuforums.org/showthread.php?t=1901977), another from a CD (http://madphilosopher.ca/2010/04/dell-laptop-bios-update-using-freedos-and-iso-master/). Neither of them work.

The USB method gets as far as running the downloaded .exe file, but all that does is print a brief message saying 'Test.' to the console. I am wondering if there are some command line arguments I don't know about.

The CD method does not get as far as a DOS prompt. It boots into FDISK whatever menu options I choose, and at that point I bail out rather than lose my hard drive. There is supposed to be a LiveCD option on the menu, but this does not seem to be present. Having followed the instructions assiduously, I am not sure what I might be doing wrong.

I have found some other recipes on the web, but they all look more complicated. I am proceeding cautiously because I do not want to turn my laptop into a desk ornament. If I find one that works I will let you know in this thread.

I have now tried all the different methods I could find to upgrade the BIOS, including making a .img file and booting to it from grub. In the cases that work at all, I get the message at the DOS prompt 'Test.' It appears that the .exe file has been nerfed so it will only work 'properly' under Windows (as opposed to FreeDOS), unless there are some other command parameters to enter when executing the file.

Christopher M. Penalver, this is an update on the BIOS issue. Unfortunately, it is bad news.

I was contacted yesterday by email from Dell support to phone them, which I did this morning. I spent 2 hours on the phone describing the issue and the problems regarding flashing the new BIOS. Basically the situation is that Ubuntu (and all other Linux distros?) have no official support from Dell. I have asked that the issue be escalated to someone in Dell who can make a response, but I am not holding my breath.

I confirm what I wrote earlier, none of the methods involving FreeDOS (bootable USB, CD-ROM, or mount from Grub) enable the executable to be successfully booted to the menu. In addition, none of the methods involving Dell Linux tools appear to be current, either because the software scripts have been obsoleted, or because the repositories for the BIOS upgrades have not been maintained for an extended period of time (at least 18 months).

At the present time, it is therefore not possible for me to upgrade my BIOS by any of the published methods, because I do not have a Windows partition on my hard drive, and I do not have a copy of Windows that I can install. There is no currently-published method of doing this from Linux that will work for my computer.

If you (or anyone else reading this) has any suggestions I will be pleased to hear them. I am considering options other than FreeDOS for making a bootable USB/CD image, but this will have to be done on a borrowed Windows machine.

Christopher M. Penalver

I have tried a few more ways to execute the BIOS upgrade file I downloaded from Dell. None of them worked, but I am documenting them here for the record.

Thinking that FreeDOS was the problem, I tried making an XP MS-DOS bootable USB. This failed in exactly the same way, with the 'Test.' message. This seems to indicate that at least FreeDOS is not the issue here.

I then made a Windows 7 bootable image on USB, and added the executable to the root directory. I used [this link](http://www.intowindows.com/bootable-usb/) to make the bootable media. Booting the USB and selecting X64 Recovery Mode I navigated Install Windows->Repair->Use Recovery Tools->Command Prompt. At the prompt I found the USB media as disk C: and again attempted to run the BIOS upgrade .exe. It failed, but this time the message was different:

'The subsystem needed to support the image type is not present.'

When I can work out what that means I will be a step nearer to running the upgrade...

Christopher M. Penalver:

I have managed to run the BIOS upgrade. It does seem to have made a significant difference, but it still falls short of ideal behaviour.

The original behaviour with the A05 BIOS was that, without the 'mousefix' installed in crontab or /etc/rc.local, the Logitech Unifying Receiver was detected, but inoperative. This was not changed by re-plugging the device any number of times. After the BIOS upgrade to A07, the device can be enabled after a small number of re-plug cycles. On 5 test boot-ups, the receiver started working after a range of 0-3 replugs, with a mode of 1 (on one boot no replug was needed, on another 3 were required).

After re-installing the 'mousefix' the reboot behaviour seemed to be somewhat improved over 5 trials, in that all 5 times the mouse and keyboard worked after just 1 re-plug cycle of the receiver. I would need to do a lot more power cycle trials to see if this was significant.

FYI I eventually got the Dell BIOS upgrade to run using a Windows 7 System Repair Disk. With the .exe installed on a separate USB, all I needed to do was get to the command prompt from the repair disk boot and navigate to the correct drive letter. This does not seem to be documented anywhere, in particular with regard to Ubuntu, so I will put this info up on one of the Ubuntu forums.

I have put the method for upgrading the BIOS on AskUbuntu (http://askubuntu.com/questions/237741/how-to-update-dell-laptop-bios/237742#237742).

My original Q&A on the BIOS upgrade for Dell referred to in theprevious post has been merged with an older question covering the same topic at this link: http://askubuntu.com/questions/100945/how-do-i-update-the-bios-of-a-dell-laptop/237742#237742

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
tags: removed: bios-outdated

Robert John Bowles, any change if you update to the A09 BIOS noted in http://www.dell.com/support/drivers/us/en/19/Product/inspiron-15r-se-7520 ?

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
tags: added: bios-outdated regression-potential

Christopher M. Penalver, no improvement over the A07 BIOS. After reading the upgrade notes it did not seem that any of the changes to the BIOS were targeted at improving USB3 performance, so this is not too surprising.

To summarise, using the A05 BIOS the Logitech receiver does not work at all unless I implement the 'mousefix'. Using the A07 BIOS the receiver works intermittently on first boot, but often successfully boots after a small number of replugs. Using the A09 BIOS (as I have done for a few weeks) has not made any noticeable difference over and above the A07 BIOS performance w.r.t. USB3.

Robert John Bowles, thank you for updating your BIOS. Could you please execute the following at a terminal, undo your WORKAROUND, reboot into the new kernel, and report the results:
cd ~/Desktop && git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-stable && cd linux-stable && git checkout 8f25229026c89912574558d0a4e36c8fe51b9bb4 && cp /boot/config-`uname -r` .config && yes '' | make oldconfig && make-kpkg clean && CONCURRENCY_LEVEL=`getconf _NPROCESSORS_ONLN` fakeroot make-kpkg --initrd --append-to-version=-custom kernel_image kernel_headers && cd .. && sudo dpkg -i *.deb

tags: removed: bios-outdated

Christopher M. Penalver, I followed your instructions, and then tested the new kernel (3.0.0-custom+) versus the current kernel (3.2.0.37-generic-44) by power-cycling and testing for keyboard/mouse availability at the login screen (no -re-plugging of the Logitech receiver). The test was repeated 10 times for each kernel.

Here are the results:
                                         Pass Fail
3.2.0.37-generic(44): 0 10
3.0.0-custom+: 10 0

I conclude whatever is in the custom kernel does the job.

tags: added: regression-release
removed: regression-potential

Robert John Bowles, thank you for testing the requested kernel. It reverted commit 534a7b8e10ec55d9f521e68c20dbb3634c25b98a.

Before we continue regression commit bisecting, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the kernel in the mainline kernels archive directory daily folder. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.8-rc6

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

If you are unable to test the mainline kernel, please comment as to why specifically you were unable to test it and add the following tags:
kernel-unable-to-test-upstream
kernel-unable-to-test-upstream-VERSION-NUMBER

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

Helpful bug reporting tips:
https://help.ubuntu.com/community/ReportingBugs

tags: added: kernel-bug-exists-upstream kernel-bug-exists-upstream-3.4.0-rc6
removed: needs-upstream-testing

Christopher M. Penalver, I tested the upstream kernel 3.4.0-030400rc6 using the same procedure as with the custom kernel. The test failed 10/10 times.

NB in order to install the upstream kernel I had to remove the custom AMD graphics drivers and Broadcom wireless drivers I had been using, also non-standard VirtualBox packages (v4.2.6 from the ricotz1 ppa). I have no reason to believe this would have changed the outcome, in particular since the behavior of the 3.2.0.37 kernel w.r.t. the Logitech receiver was identical without the custom drivers and packages.

NB 2) Although I used the amd64 deb files, when I checked what was installed, the upstream kernel was marked as '32-bit'. I am not sure if this was just a documentation error or if the kernel was genuinely 32-bit. Everything else seemed to work, so I think it must have been a documentation issue in the upstream deb file.

Robert John Bowles, did you test the newest mainline kernel available -> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.8-rc6-raring/ ? If not, could you please do this and report on the results?

Christopher M. Penalver, will a Raring kernel work with a Precise installation - I am still using Ubuntu 12.04? I assumed not, which is why I tested the 3.4.0-rc6 kernel.

Raring John Bowles, it is ok to test in Precise http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.8-rc6-raring/ .

v3.8.0-cr6 test results: Total tests 20. Pass 2, Fail 18

It is not clear to me if the 2 passes are statistically significant, but they are the reason I did the test 20 times rather than 10. So, it seems that the 2 passes out of a total of 20 tests represent no real improvement. I am recording this as a 'fail' in the tags.

tags: added: kernel-bug-exists-upstream-3.8.0-rc6

Robert John Bowles, thank you for testing the newest mainline kernel. Could you please execute the following, boot into the generated kernel, and report the results:
cd ~/Desktop && git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-stable && cd linux-stable && git checkout 534a7b8e10ec55d9f521e68c20dbb3634c25b98a && cp /boot/config-`uname -r` .config && yes '' | make oldconfig && make-kpkg clean && CONCURRENCY_LEVEL=`getconf _NPROCESSORS_ONLN` fakeroot make-kpkg --initrd --append-to-version=-custom2 kernel_image kernel_headers && cd .. && sudo dpkg -i *.deb

tags: removed: kernel-bug-exists-upstream-3.4.0-rc6

Christopher M. Penalver, here are the results of the test of the 3.0.0-custom2+ kernel, over 20 trials:

Pass 3; Fail 17

This looks very similar to the result for the Raring 3.8.0-rc6 kernel.

It is not clear if there is a statistically significant difference from using the current Precise 3.2.0-37 kernel; although my test reported above noted Pass/Fail of 0/10 I have seen _occasionally_ using the 3.2.0-37 kernel that it can boot with the Logitech receiver operational, without the 'mousefix'; this does appear to be very rare, and getting accurate statistics rather than anecdotal evidence would be very tedious. I estimate each test run would require at least 50 reboots.

Robert John Bowles, the issue you are reporting is an upstream one. Could you please report this problem through the appropriate channel by following the instructions _verbatim_ at https://wiki.ubuntu.com/Bugs/Upstream/kernel#KernelTeam.2BAC8-KernelTeamBugPolicies.Overview_on_Reporting_Bugs_Upstream ?

Thank you for your understanding.

description: updated
tags: added: cherry-pick
tags: added: bisect-done
Changed in linux (Ubuntu):
status: Incomplete → Triaged
Download full text (41.8 KiB)

bob@bobDell:/$ # Launchpad Short Description:
046d:c52b Problems using Logitech Unifying Receiver

bob@bobDell:/$ # Launchpad Long Description:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1072082

Commit that caused the regression 534a7b8e10ec55d9f521e68c20dbb3634c25b98a.

I recently purchased a new Logitech K350 keyboard (UK layout) and M505
mouse, both of which use the Logitech Unifying Receiver. I 'paired' the
keyboard and mouse to the receiver by using the proprietary Logitech
'Setpoint' software on a friend's computer running Windows XP. On their
computer, the receiver, keyboard and mouse worked perfectly.

I then moved the receiver to my own computer, a new Dell Inspiron 7520
SE running under Ubuntu 12.04.1. I tried with no success to get the
keyboard and mouse to work by repeatedly unplugging and re-plugging the
receiver, and by re-booting the machine.

I experimented with solutions posted on the web, in particular in this
thread on Ask Ubuntu
(http://askubuntu.com/questions/128345/logitech-m515-does-not-work-after-upgrade-to-12-04/202627#202627).
The accepted answer did not solve my problem.

WORKAROUND:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1072082/+attachment/3415472/+files/mousefix
running this workaround script on the command line enabled the receiver.
I added the script to crontab as suggested. The script does not cause
the receiver to work after a reboot, but I found that a single
unplug/replug cycle was now sufficient to restore operation of the
keyboard and mouse.

Potential duplicate of
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1039143 .

bob@bobDell:/$ # KEYWORDS:
kernel usb3 logitech

bob@bobDell:/$
bob@bobDell:/$ # Kernel Version:
bob@bobDell:/$ cat /proc/version
Linux version 3.8.0-030800rc6-generic (root@gomeisa) (gcc version 4.6.3
(Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201301312135 SMP Fri Feb 1 02:36:25
UTC 2013

bob@bobDell:/$
bob@bobDell:/$ # Oops... message: N/A

bob@bobDell:/$
bob@bobDell:/$ # Script to reproduce:
bob@bobDell:/$ # No script. These are the steps:
bob@bobDell:/$ # 1) Ensure Logitech Unifying Receiver is plugged into a
USB3 port (on this computer ALL ports are USB3)
bob@bobDell:/$ # 2) Boot the computer
bob@bobDell:/$ # 3) Attempt to use the Logitech keyboard or mouse at the
Ubuntu login screen
bob@bobDell:/$ # EXPECTED OUTCOME: the keyboard/mouse should work.
bob@bobDell:/$ # OBSERVED OUTCOME: the keyboard/mouse do not work.
bob@bobDell:/$ # NB 1: The Logitech Receiver must be pre-configured to
be paired with the keyboard/mouse. This can be most easily done on a
Windows system. Correct functioning of the receiver/keyboard/mouse can
be checked prior to the above test by using on a Windows system, or
testing them on another computer with USB2 ports.
bob@bobDell:/$ # NB 2: This is an INTERMITTENT failure; frequency of
failure is approximately 90% or more of trials.

bob@bobDell:/$
bob@bobDell:/$ # Environment:
bob@bobDell:/$ lsb_release -rd
Description: Ubuntu 12.04.2 LTS
Release: 12.04

bob@bobDell:/$
bob@bobDell:/$ # Software (NB Headers not installed):
root@bobDell:/usr/src/linux-headers-3.8.0-030800rc6-generic/scripts# sh
ver_lin...

Download full text (45.4 KiB)

Hi Julian

Thanks for getting back to me.

Following advice received earlier from Christian Lamparter, I have
already submitted the report to linux-input.

Best Wishes Bob Bowles

On 11/02/13 01:26, Julian Calaby wrote:

> Hi Bob,
>
> This isn't the correct place to ask about this hardware, this is for
> wireless devices that use WiFi or bluetooth, not wireless keyboard /
> mice solutions. You should ask questions about keyboards and mice on
> the linux-input list. (CC'd)
>
> On Sun, Feb 10, 2013 at 9:31 PM, Bob Bowles <email address hidden> wrote:
>> bob@bobDell:/$ # Launchpad Short Description:
>> 046d:c52b Problems using Logitech Unifying Receiver
> While I'm familiar with the hardware (I have it working flawlessly on
> a couple of my computers) I don't really have any experience debugging
> issues with it.
>
> Hopefully someone on the linux-input list will be able to help you.
>
>> bob@bobDell:/$ # Launchpad Long Description:
>>
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1072082
>>
>> Commit that caused the regression 534a7b8e10ec55d9f521e68c20dbb3634c25b98a.
>>
>> I recently purchased a new Logitech K350 keyboard (UK layout) and M505
>> mouse, both of which use the Logitech Unifying Receiver. I 'paired' the
>> keyboard and mouse to the receiver by using the proprietary Logitech
>> 'Setpoint' software on a friend's computer running Windows XP. On their
>> computer, the receiver, keyboard and mouse worked perfectly.
>>
>> I then moved the receiver to my own computer, a new Dell Inspiron 7520 SE
>> running under Ubuntu 12.04.1. I tried with no success to get the keyboard
>> and mouse to work by repeatedly unplugging and re-plugging the receiver, and
>> by re-booting the machine.
>>
>> I experimented with solutions posted on the web, in particular in this
>> thread on Ask Ubuntu
>> (http://askubuntu.com/questions/128345/logitech-m515-does-not-work-after-upgrade-to-12-04/202627#202627).
>> The accepted answer did not solve my problem.
>>
>> WORKAROUND:
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1072082/+attachment/3415472/+files/mousefix
>> running this workaround script on the command line enabled the receiver. I
>> added the script to crontab as suggested. The script does not cause the
>> receiver to work after a reboot, but I found that a single unplug/replug
>> cycle was now sufficient to restore operation of the keyboard and mouse.
>>
>> Potential duplicate of
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1039143 .
>>
>>
>> bob@bobDell:/$ # KEYWORDS:
>> kernel usb3 logitech
>>
>>
>> bob@bobDell:/$
>> bob@bobDell:/$ # Kernel Version:
>> bob@bobDell:/$ cat /proc/version
>> Linux version 3.8.0-030800rc6-generic (root@gomeisa) (gcc version 4.6.3
>> (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201301312135 SMP Fri Feb 1 02:36:25 UTC
>> 2013
>>
>>
>> bob@bobDell:/$
>> bob@bobDell:/$ # Oops... message: N/A
>>
>>
>> bob@bobDell:/$
>> bob@bobDell:/$ # Script to reproduce:
>> bob@bobDell:/$ # No script. These are the steps:
>> bob@bobDell:/$ # 1) Ensure Logitech Unifying Receiver is plugged into a USB3
>> port (on this computer ALL ports are USB3)
>> bob@bobDell:/$ # 2) Boot the computer
>> bob@bobDell:/$ # 3) Attemp...

Download full text (3.9 KiB)

Hi Benjamin

Following the install, the workaround succeeded on 10/10 power cycle
tests to be operational on the login screen.

It looks like you are on the right track. I await further news with
interest. I won't sign off the bug till you are happy.

Regards Bob Bowles

On 14/02/13 15:05, Benjamin Tissoires wrote:
> On Thu, Feb 14, 2013 at 2:36 PM, Bob Bowles <email address hidden> wrote:
>> Hi Benjamin
>>
>> Thanks for sticking at this.
>>
>> I did as requested, and the pull, make, rmmod, insmod, dmesg, and the
>> kern.log tail are logged in log3.txt (attached). At this point, as before,
>> both mouse and keyboard were still inoperative, but as you can see, the
>> error messages have been replaced with 'success' messages in the logs (?!).
>>
>> I did the replug, and both mouse and keyboard worked right away. I have
>> included the dmesg for that in log3a.txt.
> Ok. So I understood the problem:
> - during the boot, the distribution's module hid-logitech-dj trigger a
> command to switch the receiver to the "dj" mode.
> - however, this command is sent during a phase where the USB3 hw or
> driver is not cooperative.
> - this blocks the receiver in a way it can not receive nor emit any data.
> - if you rmmod/modprobe the driver, it won't work until either the
> receiver or the usb subsystem reset the device and the communication
> in some way.
>
> This explains why the 'couple of replug' is working: the usb
> communication is aborted, and the receiver accepts to receive/emit new
> data, so it can be switched to the dj mode.
>
>> This seems to be progress of sorts, though at the moment it does not seem to
>> improve over the 3.2.0 version of the driver, which typically works after a
>> couple of replugs. The intermittent nature of this bug makes testing quite
>> tricky. Will a power cycle wipe out the changes, or are they permanent (or
>> permanent enough) to test through a power cycle?
> A power cycle won't be of any help here. If you want to actually reset
> the receiver, just unplug it and replug it. It will go back to its
> original state.
>
> If you want to directly use the new driver at boot, you will have to
> follow this (I just updated the repo):
> $ git pull
> $ sudo make install
>
> Then reboot. Normally, the mouse should work directly.
>
> However, you must understand that I disabled the enhanced mode of the
> logitech receiver, meaning that it should not be used as a permanent
> fix (please do not close the bug: I won't put this workaround
> upstream).
> So I will come back to you for other tests when I have something.
>
> Cheers,
> Benjamin
>
>> On 14/02/13 10:46, Benjamin Tissoires wrote:
>>> On Thu, Feb 14, 2013 at 10:38 AM, Benjamin Tissoires
>>> <email address hidden> wrote:
>>>> Hi Bob,
>>>>
>>>> mmm... ok, let's try something else.
>>>>
>>>> Please "git pull" again, and insmod the new compiled module. The
>>>> receiver should be in the very same state than when it was during
>>>> grub.
>>>>
>>>> Oh, and I hope you did not experienced the crash during resume with
>>>> the previous version. My bad, sorry if it happened.
>>> And if it's still not working, please unplug and replug the receiver.
>>> It will reset th...

Read more...

  • log4.txt Edit (59.1 KiB, text/plain; charset=UTF-8; name="log4.txt")
Download full text (4.6 KiB)

Hi Benjamin

The results are as follows. Please see the attached log file tracking
the fetch, checkout, build, etc..

The quick test worked after a replug. After a full install into the
3.2.0-38-generic kernel, I performed the usual power cycle test, and it
passed 20/20 times. For comparison, the out-of-the box version for the
3.2.0-38-generic kernel passed 6/20 times. Checking these results via
Fisher's Exact Test leads to a 1-tailed p-value less than 0.0001,
'extremely significant' (1-tailed statistics is valid here because we
are only interested in improvements). In short, it works at least as
well as the workaround I tested earlier.

Here is the 2*2 contingency table:
Outcome Pass Fail
No Fix 6 14
'for-bob' 20 0

One fly in the ointment which I noticed is this seems to have introduced
a new bug with regard to Logitech keyboard behaviour. See below.

_Short Description:_
The first character typed on a Logitech keyboard using the Logitech
Unifying Receiver after power-up is frequently lost.
_Long Description:_
When using a Logitech keyboard linked via a Logitech Unifying Receiver,
the first character typed after power-up is often not registered. This
does not happen every time, but at least 75% of trials during a power
cycle test. The practical consequences are that after power-on, when you
enter your password, without checking the number of characters recorded
in the password box, you are likely to have to re-enter your password if
you have not touched the mouse first.
_Steps to reproduce:_
Power cycle the computer, booting in the appropriate kernel.
At the login screen, hit the Logitech keyboard spacebar 3 times.
_Expected behaviour:_
There should be 3 dots in the password box.
_Observed behaviour:_
On at least 75% of trials there are only 2 dots in the password box.
_Workaround (2 options):_
1) Always move the (Logitech) mouse first.
2) Pay particular attention to the appearance of the first-typed
character in the password box and re-type it if it does not immediately
appear.

I hope this helps. Your solution seems to be very close now.

Best Wishes Bob

On 04/03/13 17:07, Benjamin Tissoires wrote:
> On Mon, Mar 4, 2013 at 6:06 PM, Benjamin Tissoires
> <email address hidden> wrote:
>> Hi Bob,
>>
>> I'd like you to test a new release of hid-logitech-dj if you don't mind.
>> I've spotted a potential problem in hid-logitech-dj that may explains
>> why the msleep was needed.
>>
>> Here are the instructions:
>>
>> $ cd hid-logitech-dj
>> $ git fetch
>> $ git checkout for-bob
>> $ make
>> $ sudo rmmod hid_logitech_dj \
>> sudo insmod hid-logitech-dj.ko
> oops, typo in this line:
>
> $ sudo rmmod hid_logitech_dj ; \
> sudo insmod hid-logitech-dj.ko
>
> Cheers,
> Benjamin
>
>> If it's working, then you can do a
>> $ sudo make install
>>
>> Thanks,
>> Benjamin
>>
>> On Sun, Mar 3, 2013 at 5:35 PM, Benjamin Tissoires
>> <email address hidden> wrote:
>>> Hi Bob,
>>>
>>> On Sun, Mar 3, 2013 at 3:25 PM, Bob Bowles <email address hidden> wrote:
>>>> Hi Benjamin
>>>>
>>>> I wanted to touch base regarding the bug we communicated about earlier, last
>>>> month (Launchpad Bug #1072082
...

Read more...

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers