APMD-List:
Archives

  From: Craig Markwardt <craigm@pcasun3.gsfc.nasa.gov>
  To  : <pz@caltech.edu>
  Date: Mon, 13 Sep 1999 19:56:12 -0400 (EDT)

Re: Another CPU slows to a crawl after resume from suspend

John Pezaris writes:
 >    From: Craig Markwardt <craigm@pcasun3.gsfc.nasa.gov>
 >    Subject: Re: Another CPU slows to a crawl after resume from suspend
 > 
 >    Therefore I would argue that a simple "set_cpu_speed" function will
 >    not do the trick.  You actually need to inform the BIOS that we want
 >    to "resume" from standby.  [ However, as a side note, I am *very*
 >    interested in ways to actively control the CPU throttling.  Somehow I
 >    think this is very hardware dependent though. ]
 > 
 > But much of the resume has indeed happened -- the screen is on, the disk
 > works normally, the keyboard, etc.  

Yes, that happened to me too.  I guess what I mean is that the BIOS is
somehow fooled into thinking it's still in standby mode when it's not.
After checking the APM kernel code, I see that registered callback
owners can "reject" an event.  Could the PCMCIA driver somehow reject
a resume event?  My first perusal says, "no," since "undo" is set to
zero in send_event().  If the resume event was rejected, you have a
paradox: the system has by appearances resumed, but the BIOS has been
told that the resume event was rejected, so it must be in standby
mode.

One way to trace the problem better is to enable full debugging.  I
presume you have compiled your kernel yourself.  If so, then you can
define APM_DEBUG in arch/i386/kernel/apm.c (edit the source directly).
You can also log the activity of apmd by checking out the DEBUGGING
section of /etc/apmd_proxy.

Craig