Adventure into S3 state and back

[Ian Smith]

Removing hackers at freebsd.org from ccs:

On Sun, 13 Nov 2011, Garrett Cooper wrote:

 > On Sun, Nov 13, 2011 at 5:29 AM,  <rank1seeker at gmail.com> wrote:
 > > ----- Original Message -----
 > > From: Lars Engels <lars.engels at 0x20.net>
 > > To: rank1seeker at gmail.com

[ chomp ]

 > >> > > > Next step was to get rid of 'bge' device from my KERNCONF and
 > > recompile
 > >> > it.
 > >> > > > Voila! S3 works!
 > >> > > >
 > >> > > > But another, mouse problem, didn't go away!
 > >> > > > In 9 out of 10 cases, mouse doesn't resume.
 > >> > > > As it is USB mouse, I've did:
 > >> > > >
 > >> > > > # camcontrol rescan all
 > >> > > >     didn't help
 > >> > > >
 > >> > > > I've also tried adding into loader.conf and nada:
 > >> > > > ---
 > >> > > > hint.psm.0.flags="0x3000"
 > >> > > > ---
 > >> > > > But i think it is PS/2 related
 > >> > > >
 > >> > > > What works 100% for a mouse is to unplug and then plug back it's USB
 > >> > receiver
 > >> > > >
 > >> > > > This is Dell D830 laptop
 > >> > > >
 > >> >
 > >> > How do I solve mouse issue?
 > >> > It is annoying to unplug and then plug back it's USB receiver, each
 > > time.
 > >>
 > >> stop moused in rc.suspend and start it in rc.resume.
 > >>
 > >
 > > Thanks, but it isn't that.
 > > Even with it, mouse works on random, after resume from S3.
 > >
 > > But what I did figured out, looking kernel msgs on console, just after
 > > resume, is that IF I see >1 of this:
 > > --
 > > uhub_reattach_port: port 1 reset failed, error=USB_ERR_TIMEOUT
 > > uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 1
 > > --
 > >
 > > Mouse won't work unless I unplug/plug it's USB receiver
 > 
 > You may need to kldunload and kldload ums(4) in order to get things to
 > work (which suggests a driver bug in the newbus suspend and resume
 > functions).
 > 
 > FWIW I only need to do /etc/rc.d/moused restart in rc.resume to get
 > things to work, but I'm using psm(4). The mouse pointer is kind of
 > braindead for a second, but then it comes to life and does the right
 > thing.
 > 
 > So, bottom line is that there's something that gets out of sync with
 > some mice drivers and moused, and mice driver bugs or bugs with moused
 > might be involved.

I also used to restart moused in rc.resume, until this clue from jkim@

========
psm(4):

    bit 13 HOOKRESUME
        The built-in PS/2 pointing device of some laptop computers is
        somehow not operable immediately after the system `resumes' from
        the power saving mode, though it will eventually become available.
        There are reports that stimulating the device by performing I/O
        will help waking up the device quickly.  This flag will enable a
        piece of code in the psm driver to hook the `resume' event and
        exercise some harmless I/O operations on the device.

    bit 14 INITAFTERSUSPEND
        This flag adds more drastic action for the above problem.  It will
        cause the psm driver to reset and re-initialize the pointing
        device after the `resume' event.  It has no effect unless the
        HOOKRESUME flag is set as well.

I always use hint.psm.0.flags="0x6000" in /boot/loader.conf, i.e.,
turn on both HOOKRESUME and INITAFTERSUSPEND, to work around similar
problem on different laptop.
=======

This works reliably for me on my Thinkpad:
# 29/9/10 thanks Jung-uk Kim .. so can remove moused restart from rc.resume
hint.psm.0.flags="0x6000"

It's psm of course so I doubt it could help with ums(4), which appears 
to be a hint-free zone, but it should work for you, Garrett.

cheers, Ian