trackpoint dead after suspend-to-RAM

trackpoint dead after suspend-to-RAM

[Jonathan Brandmeyer]

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/

Re: trackpoint dead after suspend-to-RAM

[Karol Kozimor]

Thus wrote Jonathan Brandmeyer:
> 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,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
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/

Re: trackpoint dead after suspend-to-RAM

[ole.rohne-vJEk5272eHo]

> 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/

Re: trackpoint dead after suspend-to-RAM

[Jonathan Brandmeyer]

On Thu, 2004-12-02 at 23:11 +0100, Karol Kozimor wrote:
> Thus wrote Jonathan Brandmeyer:
> > 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,
> 

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/

Re: Re: trackpoint dead after suspend-to-RAM

[Jonathan Brandmeyer]

On Fri, 2004-12-03 at 05:48 +0100, ole.rohne-vJEk5272eHo@public.gmane.org wrote:
> > 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.
> 

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/

Re: Re: trackpoint dead after suspend-to-RAM

[Jonathan Brandmeyer]

On Fri, 2004-12-03 at 23:13 -0500, Jonathan Brandmeyer wrote:
> On Fri, 2004-12-03 at 05:48 +0100, ole.rohne-vJEk5272eHo@public.gmane.org wrote:
> > > 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.
> > 
> 
> 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.

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/