Hi, I encountered a slight regression from 2.6.31 to 2.6.32 concerning the settings for speed and sensitivity of my Lenovo x61t trackpoint after a suspend/resume-cycle: They're reset to 97 and 128, respectively. This applies only if the settings are written into sysfs (/sys/devices/platform/i8042/serio1/{speed,sensitivity}). If there are udev-rules present to set the values they remain unchanged (or are re-set automatically after resume?). After resume I can write the desired values back into sysfs successfully. So there seems to be nothing broken, only the values are lost. (See also http://bugzilla.kernel.org/show_bug.cgi?id=14970#c11) This is on Archlinux with a default kernel only enhanced by including the patch from http://bugzilla.kernel.org/show_bug.cgi?id=14970 to re-enable the recognition of the trackpoint device. Suspending and resuming is carried out by pm-utils. Thanks and cheers, Marten
Sorry, I made a mistake: this also happens if udev-rules are present, i.e. always. `udevadm test /sys/devices/platform/i8042/serio1` re-sets the values successfully, too. Marten
Does the same thing happens if you use 'echo "mem" > /sys/power/state' to suspend? Can I please see dmesg over suspend with i8042.debug kernel option?
Yes, I see the same behavious with 'echo "mem" > /sys/power/state'. I'm attaching a dmesg-snippet from a suspend/resume-cycle triggered by echo'ing mem into /sys/power/state. Thanks again, Marten
Created attachment 24698 [details] dmesg over suspend/resume cycle with i8042.debug=Y
I think this may have been fixed in the latest kernel. Could you please try 2.6.33-rc5 and let me know if settings persist. If they do not could I get another debug dmesg but from 2.6.32-rc5? Thank you.
I tested with 2.6.32-6 and see the same behaviour. dmesg is coming in a minute. Thank you, Marten
Created attachment 24832 [details] dmesg over suspend/resume cycle with i8042.debug=Y, 2.6.32-6
Marten, I am not sure what 2.6.32-6 is (it is a distro kernel?) but the code was changed after 2.6.33-rc4 so could you please test with 2.6.33-rc5 or 2.6.33-rc6. Yes, these are development kernels. Thank you.
Dmitry, sorry, I did not read your request properly and had been testing with 2.6.32.6. I tested now with a vanilla 2.6.33-rc6 (no patches) and unfortunately see still the same problem (dmesg coming up). Is there anything else I can provide? Thank you for all the work you do! Marten
Created attachment 24882 [details] dmesg over suspend/resume cycle with i8042.debug=Y, 2.6.33-rc6
Created attachment 24889 [details] Ignore mouse data until reconnect is done. Marten, Could you please try this patch and let me know if it fixes your issue. It should apply cleanly to 2.6.33-rc6. Thank you.
Note that the "0xaa 0x00" power-up response comes back from the device, the device will not respond to any commands, including the disable command, and they'll just keep timing out.
Um, I wanted to say "Note that UNTIL the "0xaa 0x00" ...". The reason being that the mouse is performing internal diagnostics, in the case of a touchpad it is calibrating itself, and in general booting. Only after it sends the "0xaa 0x00", it's ready to talk to the OS. The sad part is that we don't know whether it'll send that or not, as it might have been rather fast and could have sent the data while the BIOS was still in control, and then we would have discarded the data at i8042 re-init time.
(In reply to comment #13) > Um, I wanted to say "Note that UNTIL the "0xaa 0x00" ...". The reason being > that the mouse is performing internal diagnostics, in the case of a touchpad > it > is calibrating itself, and in general booting. Only after it sends the "0xaa > 0x00", it's ready to talk to the OS. The sad part is that we don't know > whether > it'll send that or not, as it might have been rather fast and could have sent > the data while the BIOS was still in control, and then we would have > discarded > the data at i8042 re-init time. Yes, that is concern. However if we are unfortunate enough to step onto trackpoint POST the initial reconnect will fail and we will reschedule the full rescan bringing the device back, albeit with default settings. If the patch works for Marten I think we should apply it and then see if we actually see these breakages. If there are any we could try issuing GET ID a couple of times at the beginning of reconnect routine to make sure device is ready to talk to us. What do you think?
Dmitry, this works! Thank you! I used 2.6.33-rc6 with your patch and none other. The last two comments I don't understand. Is there someting else I should test now? Would you like to see the dmesg-snippet?
(In reply to comment #15) > Dmitry, this works! Thank you! > > I used 2.6.33-rc6 with your patch and none other. > > The last two comments I don't understand. Is there someting else I should > test > now? No, it was a discussion about more potential problems in this area. No action is needed at this time. > > Would you like to see the dmesg-snippet? No, I am good. May I add "Tested-by: Marten Vance <your e-mail>" to the commit text of the patch? Thanks.
> May I add "Tested-by: Marten Vance <your e-mail>" to the commit text of the > patch? Is that important to you or the project or the workflow? To me it's not and I'd prefer not to, simply to protect my name and e-mail-address a little more. Thank you for all the work! Marten
No, I do not have to have it, I'll just put a reference to this bugzilla #. Some people are OK with their e-mail in logs, some are not so much, that's why I did ask.
Alright. Will you mark this bug-report "resolved" or should I? Thanks again and best wishes! Marten
I will when the patch hits upstream (unless I forget ;) ). That you for your help with providing the data and testing different kernels/patches.
Handled-By : Dmitry Torokhov <dmitry.torokhov@gmail.com> Patch : http://bugzilla.kernel.org/attachment.cgi?id=24889
Fixed by commit a9f0c381973097462d9688dc26fe66f4f020502e.