From owner-svn-src-all@FreeBSD.ORG Tue Jul 27 16:15:34 2010 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id AF4751065674; Tue, 27 Jul 2010 16:15:34 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Gavin Atkinson Date: Tue, 27 Jul 2010 12:15:06 -0400 User-Agent: KMail/1.6.2 References: <201007261953.o6QJrAFd069188@svn.freebsd.org> <1280242180.78791.33.camel@buffy.york.ac.uk> In-Reply-To: <1280242180.78791.33.camel@buffy.york.ac.uk> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007271215.26238.jkim@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r210514 - in head/sys/amd64: acpica amd64 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 16:15:34 -0000 On Tuesday 27 July 2010 10:49 am, Gavin Atkinson wrote: > On Mon, 2010-07-26 at 19:53 +0000, Jung-uk Kim wrote: > > Author: jkim > > Date: Mon Jul 26 19:53:09 2010 > > New Revision: 210514 > > URL: http://svn.freebsd.org/changeset/base/210514 > > > > Log: > > Re-implement FPU suspend/resume for amd64. This removes > > superfluous uses of critical_enter(9) and critical_exit(9) by > > fpugetregs() and fpusetregs(). Also, we do not touch PCB flags > > any more. > > Hi, > > Is this likely to make suspend.resume more reliable? Or is it > basically more of a tidy up of the existing code? The latter. > My laptop hangs on resume maybe 1 in 5 times, but will also hang > 100% of the time if I've been running virtualbox - and as a result > I'm assuming it's somethign to do with some register > saving/restoring that needs to happen but isn't at the moment. The biggest problem with suspend/resume is there are too many drivers (from base and ports) do not save/restore/reinitialize firmware, registers or device memory properly. I haven't looked at the source but I guess vbox host driver may be one of them. > I have no idea how to debug the problem further though. 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. Harder cases require additional hardware, i.e., serial port/cable for serial console or Firewire port/cable for dcons(4), and usual kernel debugging skills. When you find the culprit, try S3 again *without* the driver. Then, the next and the next until everything is working properly. In fact, I had to buy a "port 80h card" when I encountered a complicated hard hang. :-/ Don't forget to file PR if you find an offending driver. Jung-uk Kim