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

Jung-uk Kim jkim at FreeBSD.org
Tue Jul 27 18:22:51 UTC 2010


On Tuesday 27 July 2010 12:55 pm, Pyun YongHyeon wrote:
> 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 a box with a wireless USB keyboard/mouse receiver at home.  It 
does not hang but these devices just disappear and it does not 
respond to any usbconfig(8) command after S3.  Only workaround I 
found is reloading whole USB stack again.  I think it's a 
chipset-specific (AMD RS780) quirk for ohci(4) or ehci(4).  
Unfortunately the new USB stack is a big wall for me, too. :-(

Jung-uk Kim


More information about the svn-src-head mailing list