On Tue, 20 Jun 2006 21:06:52 -0300 (ADT), "Jared D. McNeill"
<jmcneill@invisible.ca> wrote:

> On Tue, 20 Jun 2006, Steven M. Bellovin wrote:
> > I wrote simple lid_switch and sleep_button scripts; both work properly for
> > suspending if I have them set sleep_state via the sysctl.  However, the
> > machine does not resume when I open the lid, even though it does under APM
> > or Windows.  If I comment out the sysctls, I see 'pressed' and 'released'
> > events for lid_switch; for sleep_button, I only see the 'pressed' event.
> 
> We will only send a 'lid_switch released' event if we see one. What I 
> have been doing with my wake scripts is ignoring a 'lid_switch released' 
> event, and doing the restoration scripting immediately after the call to 
> sysctl to put myself into S3.
> 
> I've posted my sleep_button script:
> 
>    http://www.invisible.ca/~jmcneill/netbsd/sleep_button

That's a reasonable script, though I think I'd change it to invoke
/etc/powerd/scripts/suspend and resume, rather than putting it all inline
-- I have at least 3 ways to suspend, Fn+F4, closing the lid, and the
actual sysctl.  I'm willing to regard that last as an internal mechanism,
and have a 'zzz' command that ran /etc/powerd/scripts/suspend, issued the
sysctl, and then ran /etc/powerd/scripts/resume.  This would get the
effect I wanted without adding API complexity.  In fact, I like that idea
enough that I'm going to recode my scripts that way.

The real point is that it doesn't wake up on lid-open, and it should.
> 
> If you want to resume from X, throw in a 'wsconscfg -s 1' before the first 
> sleep, and a 'wsconscfg -s 7' (or whatever vt you run X on) after the 
> second sleep.

Right, though I regard that more as a work-around.  And that does not take
care of the lines I see.
> 
> > Speedstep, via estd, is *not* working; the speed stays at 1800 Mhz.
> 
> What behaviour do you expect?
> 
I run sysutils/estd, which changes the CPU speed in response to CPU load;
the idea is to save battery.  The machine also runs cooler when at 600
Mhz...  Even without estd, I have the BIOS configured to slow it down when
running on battery.  Here's what I just ran:

$ while sleep 1; do sysctl machdep.est.frequency.current;done
machdep.est.frequency.current = 600
machdep.est.frequency.current = 600
machdep.est.frequency.current = 600
machdep.est.frequency.current = 600
machdep.est.frequency.current = 800
machdep.est.frequency.current = 1200
machdep.est.frequency.current = 1600
machdep.est.frequency.current = 1800
machdep.est.frequency.current = 1800
machdep.est.frequency.current = 1800
machdep.est.frequency.current = 1800
machdep.est.frequency.current = 600
machdep.est.frequency.current = 600
machdep.est.frequency.current = 600
machdep.est.frequency.current = 600

It ramped up when I started a CPU-bound process running.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb