On Fri, 3 Feb 2006, Quentin Garnier wrote:

> On Thu, Feb 02, 2006 at 10:32:04PM -0500, Steven M. Bellovin wrote:
>> 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?
>
> Hacks have a tendency to stick around.  See the umass memmory issue.
> Who will work on actually fixing the underlying problem now?

 	The umass kludge was a workaround to get the common case working
 	for people. This would be a conditionally enabled option which
 	would enable more people to play with the ACPI suspend code. It
 	would not be built by default, and the functionality would be
 	expected to migrate to whatever general purpose power managment
 	tool eventually gets written.

 	Would you strongly object to it going in?

-- 
 		David/absolute       -- www.NetBSD.org: No hype required --