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

[Jung-uk Kim]

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