From owner-freebsd-doc@FreeBSD.ORG Wed Jul 28 15:47:07 2010 Return-Path: Delivered-To: doc@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 1033) id 25DC11065675; Wed, 28 Jul 2010 15:47:07 +0000 (UTC) Date: Wed, 28 Jul 2010 15:47:07 +0000 From: Alexey Dokuchaev To: Jung-uk Kim Message-ID: <20100728154707.GA89549@FreeBSD.org> References: <201007261953.o6QJrAFd069188@svn.freebsd.org> <1280242180.78791.33.camel@buffy.york.ac.uk> <201007271215.26238.jkim@FreeBSD.org> <20100727173632.GA61992@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline In-Reply-To: <20100727173632.GA61992@FreeBSD.org> User-Agent: Mutt/1.4.2.1i Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, Gavin Atkinson , doc@FreeBSD.org, src-committers@FreeBSD.org Subject: [patch] Add some ACPI debugging advice to the Handbook X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 15:47:07 -0000 --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=koi8-r Content-Disposition: inline On Tue, Jul 27, 2010 at 05:36:32PM +0000, Alexey Dokuchaev wrote: > On Tue, Jul 27, 2010 at 12:15:06PM -0400, Jung-uk Kim wrote: > > The simplest thing to try is: > > > > sysctl debug.bootverbose=1 > > sysctl debug.acpi.suspend_bounce=1 > > acpiconf -s 3 > > > > This test emulates suspend/resume cycle of all device drivers without > > actually going into S3 state. In some cases, you can easily catch > > problems with this method (e.g., losing firmware state, device > > watchdog time out, and retrying forever). Note that the system does > > not really enter S3 state, which means devices may not lose power at > > all. It also means some devices will just work fine even if > > suspend/resume methods are totally missing unlike real S3 state. > > This is really nice piece of advice. Is any one interested (maybe even > the author) in converting it do docbook format and adding to acpi-debug > handbook chapter? I can do it if no one else steps before me. Could you please review attached diff, and I would appreciate if someone on the doc@ team can correct my markup (I haven't done documentation for a while) and commit it to HB? I can sumbmit PR is that's preferred. Thanks. ./danfe --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="acpi-debug.diff" Index: chapter.sgml =================================================================== RCS file: /home/danfe/fbsd/FreeBSD-CVS/doc/en_US.ISO8859-1/books/handbook/config/chapter.sgml,v retrieving revision 1.239 diff -u -r1.239 chapter.sgml --- chapter.sgml 25 Oct 2009 21:21:54 -0000 1.239 +++ chapter.sgml 28 Jul 2010 15:33:16 -0000 @@ -2807,6 +2807,32 @@ do not expect the problem to be resolved since there are a lot of drivers/hardware that need more testing and work. + One of the biggest problems with suspend/resume is that too + many drivers exist that do not save, restore, or reinitialize + their firmware, registers, or device memory properly. To make + these kind of problems easier to debug, the simplest thing to try + is: + + &prompt.root; sysctl + debug.bootverbose=1 + &prompt.root; sysctl + debug.acpi.suspend_bounce=1 + &prompt.root; acpiconf -s 3 + + This test emulates suspend/resume cycle of all device drivers + without actually going into S3 state. In some + cases, you can easily catch problems with this method (e.g., + losing firmware state, device watchdog time out, and retrying + forever). Note that the system will not really enter + S3 state, which means devices may not lose + power at all. It also means some devices will just work fine + even if suspend/resume methods are totally missing unlike real + S3 state. + + Harder cases require additional hardware, i.e., serial + port/cable for serial console or Firewire port/cable for + &man.dcons.4;, and usual kernel debugging skills. + To help isolate the problem, remove as many drivers from your kernel as possible. If it works, you can narrow down which driver is the problem by loading drivers until it fails --cWoXeonUoKmBZSoM--