svn commit: r210514 - in head/sys/amd64: acpica amd64
Pyun YongHyeon
pyunyh at gmail.com
Tue Jul 27 16:55:52 UTC 2010
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
More information about the svn-src-all
mailing list