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 > <benjamin.tissoi...@gmail.com> 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 >> <benjamin.tissoi...@gmail.com> wrote: >>> Hi Bob, >>> >>> On Sun, Mar 3, 2013 at 3:25 PM, Bob Bowles <bobjohnbow...@gmail.com> wrote: >>>> Hi Benjamin >>>> >>>> I wanted to touch base regarding the bug we communicated about earlier, >>>> last >>>> month (Launchpad Bug #1072082 >>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1072082). There appear >>>> to have been developments w.r.t. a related bug I am subscribed to >>>> (Launchpad >>>> Bug #1039143 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1039143). >>>> Not knowing how you are getting on, or what is involved in making a >>>> permanent fix, I was wondering if you may find it helpful to communicate >>>> with others working on the same (or a very similar) issue. >>> Thanks for the update. It's indeed a good piece of information. I did >>> not had the time to work on that, recently and I was wondering how >>> could I find the root of the problem without any buggy device. Now >>> that they manage to find out where the problem lies, it should be >>> possible to find a patch that works 100% of the time. >>> >>>> FYI I am currently using the 3.2.0-38-generic kernel for day-to-day work, >>>> without any workarounds. The problem has not gone away, but the receiver >>>> seems to connect first time from cold start much more often than it used >>>> to, >>>> i.e. at least 50% of the time. On those occasions when it fails, a single >>>> replug of the receiver is usually enough. However, the bug is still there, >>>> and correspondence in the 1039143 bug indicates that it continues to be >>>> present upstream. >>>> >>> Maybe your kernel received some USB3 patches that helped a little the >>> problem :) >>> But indeed nothing happened upstream for the logitech receiver, so >>> it's not very surprising that it has not be fixed... >>> >>> Cheers, >>> Benjamin ** Attachment added: "log4.txt" https://bugs.launchpad.net/bugs/1072082/+attachment/3558508/+files/log4.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1072082 Title: 046d:c52b Problems using Logitech Unifying Receiver To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1072082/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
