Date: Tue, 01 Apr 2008 16:09:52 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: jroberson@chesapeake.net Cc: arch@freebsd.org Subject: Re: AsiaBSDCon DEVSUMMIT patch Message-ID: <20080401.160952.1678772361.imp@bsdimp.com> In-Reply-To: <20080326230322.H72156@desktop> References: <20080327.013229.1649766744.imp@bsdimp.com> <20080326230322.H72156@desktop>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20080326230322.H72156@desktop>
Jeff Roberson <jroberson@chesapeake.net> writes:
:
: On Thu, 27 Mar 2008, M. Warner Losh wrote:
:
: > Greetings,
: >
: > We've been talking about the situation with suspend/resume in the
: > tree. Here's a quick hack to allow one to suspend/resume an
: > individual device. This may or may not work too well, but it is
: > offered up for testing and criticism.
: >
: > http://people.freebsd.org/~imp/devctl.diff
: >
: > devctl -s ath 0 suspend ath0
: > devctl -r ath 0 resume ath0
:
: Hey Warner,
:
: This is a great idea. Would it be possible to provide a little more
: background about what the expected failure/success modes are? If we had
: some easy to follow steps we could ask for testers on current@ and create
: a wiki with a list of known working/broken hardware. That'd be a great
: step towards having widespread suspend/resume support.
There's two areas of testing/use here.
The first is to run it like so:
devctl -s ath 0 && sleep 10 && devctl -r ath 0
Eg, suspend and resume an individual device, or even tree of devices.
At least one bug has been found with this technique (it is actually a
rediscovery of an older bug, but I digress). You'd want the kernel to
not panic, and you'd want things to be good after as before.
One can also use it to test to make sure that a device remains sane
after a long time suspended as well. This can have power savings
potential too, but that's a secondary effect at this time.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080401.160952.1678772361.imp>