In message <05EE46FC-F65B-4AAC-9CA4-A8ABA3C0D712@invisible.ca>, "Jared D. McNei
ll" writes:
>On 2-Feb-06, at 7:34 PM, David Brownlee wrote:
>
>> On Sat, 19 Nov 2005, Jared D. McNeill wrote:
>>> For what it's worth, I had suspend/resume (ACPI S1 and S3) working  
>>> on my Dell Latitude D600. -current doesn't provide a way to  
>>> trigger a suspend, so here's the (old) patch I used:
>>>
>>> 	http://www.invisible.ca/~jmcneill/netbsd/d600/acpi-sleep- 
>>> sysctl.patch
>>>
>>> You can trigger a sleep with 'sysctl -w hw.acpi.sleepstate=<n>'  
>>> where 'n' is the ACPI sleepstate (1, 3, 4, etc).
>>>
>>> There was a bug in the D600 firmware where resume would fail to re- 
>>> initialize the display adapter if it entered S3 while undocked,  
>>> but apart from that our ACPI suspend/resume code works flawlessly.  
>>> Hopefully others have better luck on different hardware.
>>
>> 	Would there be any sense in committing this as a (default
>> 	undefined) option to make it easier for people to play with
>> 	this stuff?
>
>It was undecided that a sysctl was the proper place for this knob to  
>live. I wasn't prepared to commit this as a sysctl knob as a result  
>if someone was planning on a generic power management API.
>
>Also, I have yet to hear any positive / negative feedback to the  
>state of our S3 support, assuming support in our HW devices for the  
>hardware that people are running. I've only been able to test it on  
>my Latitude D600 (again, with patches applied to the appropriate PCI  
>device drivers).
>

Does it make sense, then, to commit it protected by some build-time 
option ACPI_STATE_SYSCTL?

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