From owner-svn-src-head@FreeBSD.ORG Tue Jul 27 16:55:52 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 606C51065675; Tue, 27 Jul 2010 16:55:52 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id BA6B78FC0C; Tue, 27 Jul 2010 16:55:51 +0000 (UTC) Received: by gyg4 with SMTP id 4so1649753gyg.13 for ; Tue, 27 Jul 2010 09:55:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=/mt0nog/geJl0woNUWxBo1ajEFws6AKxhTVZxF4EC7o=; b=iRWSA/++YmCZIylUa3V+qu1Ysfv1rpEg5C7qsjt7RQkBAZ89bBR5krhkWF8wtm2kWZ V92MLYios/Zh2L/bt3fd6MhLhxHofIwf+JpD3UNeoNmdQrTtvA4WfGjmvLm6MxDLngB6 NCHK6UQyOOdqCvrmoCY/4fUBCSqYIZW8BsXbg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=XWnJf+/fTLF5Oe7Dm/8NgViejmI3KN/CV8ecz/xgtnnQbwaRTpvTaB/ZPF0G0y6mfS bhxXnyfI1NM1FwcHpHu2slVedx2f81JHtEkHfv2XPrR1b3p6abdZenu8OzwKJ67FwS+o BRtvSYj986qMRD1GMfibaUno2vTItSP0+U2uo= Received: by 10.150.7.3 with SMTP id 3mr8240337ybg.407.1280249751035; Tue, 27 Jul 2010 09:55:51 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 36sm5105813ybr.20.2010.07.27.09.55.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 27 Jul 2010 09:55:49 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 27 Jul 2010 09:55:04 -0700 From: Pyun YongHyeon Date: Tue, 27 Jul 2010 09:55:04 -0700 To: Jung-uk Kim Message-ID: <20100727165504.GA3100@michelle.cdnetworks.com> References: <201007261953.o6QJrAFd069188@svn.freebsd.org> <1280242180.78791.33.camel@buffy.york.ac.uk> <201007271215.26238.jkim@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201007271215.26238.jkim@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Gavin Atkinson , src-committers@freebsd.org Subject: Re: svn commit: r210514 - in head/sys/amd64: acpica amd64 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 16:55:52 -0000 On Tue, Jul 27, 2010 at 12:15:06PM -0400, Jung-uk Kim wrote: > 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. > To me, it was always USB stack that completely hangs the box. I tried to fix that but I'm still seeing big wall of new USB stack and lock complexity. Maybe this would be one of reason why I can't wake up my box via USB ethernet controller with magic packet. It seems that suspend/resume KOBJ method is not even invoked for USB devices. > > 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