svn commit: r210514 - in head/sys/amd64: acpica amd64

[Pyun YongHyeon]

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