--0OOz7ZB592LYQf07
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Feb 04, 2006 at 03:01:41PM +0000, David Brownlee wrote:
> On Fri, 3 Feb 2006, Quentin Garnier wrote:
>=20
> >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.=20
> >>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=3D<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?
>=20
> 	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.

How long until someone else enables it in GENERIC_LAPTOP?

> 	Would you strongly object to it going in?

I would not object to it going in, but I would not commit it.  Of
course, it's hard to deny the opportunity to at least prepare all the
drivers for ACPI suspend/resume.

--=20
Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
"When I find the controls, I'll go where I like, I'll know where I want
to be, but maybe for now I'll stay right here on a silent sea."
KT Tunstall, Silent Sea, Eye to the Telescope, 2004.

--0OOz7ZB592LYQf07
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQEVAwUBQ+T49NgoQloHrPnoAQJQtggAhOzin4HfQ17ZApwiWWSCLlVB+66OV78f
Rt1yI/OCh0niRf2zMJpfdKz3kKUmC4CMenVx/FSYRQwl4W76XZdBhY0xJ09j2T1K
eyYt136b4eVOn4WKjVpGfJSrrEl3JLF8vHlQeq8/HJOhMAlkmH+5bt0MzZe9TDJa
0A32iveKWHW1VhouTdJXSKKf976LTCb92KIMVhhixQd4+gTqMxMJImscwRS7ypak
N8Ksz9BEv8RCFQxoH0hr/u3X9+6rjlc4Fb6cPMqEyD6glehq8KfHgMVwqE/hPTRM
XPiuThEmL+xYPjVHUFNA3V05xcIjga0mDpXL6huPTwoJM8LdtNtmag==
=NwAn
-----END PGP SIGNATURE-----

--0OOz7ZB592LYQf07--