trackpoint dead after suspend-to-RAM
I have recently installed Debian Sid on a Fujitsu P-2040 laptop, but I've been using Linux for a while on a desktop, but I've never done anything apm/acpi related with it, other than automatic poweroff at shutdown. I'm using kernel 2.6.9, with Debian-specific patches (does not include ACPI-related stuff, as far as I can tell).
I'm trying to get suspend-to-ram working on the machine, but when it resumes, the trackpoint (a PS/2 device) doesn't work. I have confirmed that the issue is at the kernel level and not the X level by cat-ing /dev/input/mice and observing that nothing comes out when pushing on the stick. Removing the psmouse module before shutdown, and inserting it after restoration does not work around the problem.
The issue appears to be similar to what was discussed in the thread "Re:
trackpoint dead after S3 suspend" in late November, 2003 on this mailing list [1]. The last post in that thread said (with regard to a patch reported to at least partially fix the problem), "See l-k to find similar code done less ugly way... (I did it yesterday)." Does anyone know which patch the poster was referencing?
Alternatively, what other techniques could work around the problem?
Thanks,
-Jonathan Brandmeyer
[1]
http://sourceforge.net/mailarchive/forum.php?forum_id=6102&style=flat&viewday=23&viewmonth=200311
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
Thus wrote Jonathan Brandmeyer:
Quoted 6 lines
The issue appears to be similar to what was discussed in the thread "Re:
trackpoint dead after S3 suspend" in late November, 2003 on this mailing list [1]. The last post in that thread said (with regard to a patch reported to at least partially fix the problem), "See l-k to find similar code done less ugly way... (I did it yesterday)." Does anyone know which patch the poster was referencing?
Ugh, that was finally properly fixed and merged around 2.6.3, so you're probably facing something different. Please also try with a vanilla kernel. Best regards,
Signature · 9 lines
Karol 'sziwan' Kozimor sziwan-DETuoxkZsSqrDJvtcaxF/[email protected] ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
A message that is not in the archive (sent off-list or not yet received): 20041202221154.GA19095-DETuoxkZsSqrDJvtcaxF/[email protected]
Quoted 8 lines · Karol Kozimor
Thus wrote Jonathan Brandmeyer:
Quoted 6 lines
The issue appears to be similar to what was discussed in the thread "Re:
trackpoint dead after S3 suspend" in late November, 2003 on this mailing list [1]. The last post in that thread said (with regard to a patch reported to at least partially fix the problem), "See l-k to find similar code done less ugly way... (I did it yesterday)." Does anyone know which patch the poster was referencing?
Quoted 4 lines
Ugh, that was finally properly fixed and merged around 2.6.3, so you're probably facing something different. Please also try with a vanilla kernel. Best regards,
Done. Still busted. What info do ya'll need from me to help track this down?
Thanks,
-Jonathan
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
Quoted 2 lines
I'm trying to get suspend-to-ram working on the machine, but when it resumes, the trackpoint (a PS/2 device) doesn't work.
The Fujitsu P2120 (a younger sibling to your P2040) has a DSDT method "\\_SB.PCI0.EIO.FJEX.SMOU" to swich on and off the internal track point. Calling this function with the argument "1" around the time [1] of _BFS/_WAK in hwsleep.c fixes the problem here.
Ole
[1] This is perhaps a bit simplified. For various reasons, I've split acpi_leave_sleep_state in two pieces. The "SMOU" method happens in the first part which gets to run before devices are resumed.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 8 lines · On Fri, 2004-12-03 at 05:48 +0100, [email protected] wrote:
Quoted 2 lines
I'm trying to get suspend-to-ram working on the machine, but when it resumes, the trackpoint (a PS/2 device) doesn't work.
The Fujitsu P2120 (a younger sibling to your P2040) has a DSDT method "\\_SB.PCI0.EIO.FJEX.SMOU" to swich on and off the internal track point. Calling this function with the argument "1" around the time [1] of _BFS/_WAK in
hwsleep.cfixes the problem here.
Quoted 6 lines
Ole
[1] This is perhaps a bit simplified. For various reasons, I've split
acpi_leave_sleep_statein two pieces. The "SMOU" method happens in the first part which gets to run before devices are resumed.
Promising! I've added this sequence of operations immediately before the call of _BFS:
arg.integer.value = 1;
status = acpi_evaluate_object (NULL, "\\_SB.PCI0.EIO.FJEX.SMOU",
&arg_list, NULL);
if (ACPI_FAILURE (status) && status != AE_NOT_FOUND) {
ACPI_REPORT_ERROR ((
"Method SMOU failed, %s n", acpi_format_exception (status)));
}Does that look sane to you? The patched kernel is building right now; I haven't tested it yet.
I have to wonder if there shouldn't be a more general method for fixing this issue in a way that can be incorporated into the mainline kernel sources. I noted this comment: /* TBD: _WAK "sometimes" returns stuff - do we want to look at it? */ Is there any way to see what that "stuff" is? Could it be a list of other things that need to be initialized?
Also, is there a way to perform the equivalent operation from userspace?
Thanks,
-Jonathan
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
Quoted 20 lines · Jonathan Brandmeyer
Quoted 8 lines · On Fri, 2004-12-03 at 05:48 +0100, [email protected] wrote:
Quoted 2 lines
I'm trying to get suspend-to-ram working on the machine, but when it resumes, the trackpoint (a PS/2 device) doesn't work.
The Fujitsu P2120 (a younger sibling to your P2040) has a DSDT method "\\_SB.PCI0.EIO.FJEX.SMOU" to swich on and off the internal track point. Calling this function with the argument "1" around the time [1] of _BFS/_WAK in
hwsleep.cfixes the problem here.Quoted 6 lines
Ole
[1] This is perhaps a bit simplified. For various reasons, I've split
acpi_leave_sleep_statein two pieces. The "SMOU" method happens in the first part which gets to run before devices are resumed.Promising! I've added this sequence of operations immediately before the call of
_BFS:
arg.integer.value = 1;
status =acpi_evaluate_object(NULL, "\\_SB.PCI0.EIO.FJEX.SMOU",
Quoted 8 lines
&arg_list, NULL); if (ACPI_FAILURE (status) && status != AE_NOT_FOUND) { ACPI_REPORT_ERROR (( "Method SMOU failed, %s n", acpi_format_exception (status))); }Does that look sane to you? The patched kernel is building right now; I haven't tested it yet.
It works! Thanks a million.
-Jonathan
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/