Date: Tue, 27 Jul 2010 09:55:04 -0700 From: Pyun YongHyeon <pyunyh@gmail.com> To: Jung-uk Kim <jkim@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Gavin Atkinson <gavin@freebsd.org>, src-committers@freebsd.org Subject: Re: svn commit: r210514 - in head/sys/amd64: acpica amd64 Message-ID: <20100727165504.GA3100@michelle.cdnetworks.com> In-Reply-To: <201007271215.26238.jkim@FreeBSD.org> References: <201007261953.o6QJrAFd069188@svn.freebsd.org> <1280242180.78791.33.camel@buffy.york.ac.uk> <201007271215.26238.jkim@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100727165504.GA3100>