From owner-freebsd-arch@FreeBSD.ORG Tue Apr 1 22:11:52 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BAFB106567B for ; Tue, 1 Apr 2008 22:11:52 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 08C908FC23 for ; Tue, 1 Apr 2008 22:11:51 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m31M94wI093631; Tue, 1 Apr 2008 16:09:04 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 01 Apr 2008 16:09:52 -0600 (MDT) Message-Id: <20080401.160952.1678772361.imp@bsdimp.com> To: jroberson@chesapeake.net From: "M. Warner Losh" In-Reply-To: <20080326230322.H72156@desktop> References: <20080327.013229.1649766744.imp@bsdimp.com> <20080326230322.H72156@desktop> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: AsiaBSDCon DEVSUMMIT patch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2008 22:11:52 -0000 In message: <20080326230322.H72156@desktop> Jeff Roberson 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