Adventure into S3 state and back

[rank1seeker at gmail.com]

----- Original Message -----
From: YongHyeon PYUN <pyunyh at gmail.com>
To: rank1seeker at gmail.com
Cc: hackers at freebsd.org, freebsd-acpi at freebsd.org
Date: Sun, 13 Nov 2011 18:14:13 -0800
Subject: Re: Adventure into S3 state and back

> > > 
> > > Known issue. kern/136876.
> > > Mobile bge(4) controllers seem to have this issue.
> > 
> > I can see this has been reported, when 8.0-BETA1 was released.
> > Now is almost 8.3 out and problem is still present
> 
> Actually I spent a lot of time to address this but all attempts
> failed mainly because I have no access to such bge(4) controllers.
> Remote debugging does not work for suspend/resume issues so chances
> would be low to get it fixed in near future unless someone donate
> problematic hardwares to me.


Then you have to update:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/136876

And post at the end, something like ...
"All attempts to fix problem failed, due to physicall unavailability of bge(4) controller.
STATUS -> Waiting for donation of bge(4) hardware, in order to resume fixing a problem"


> > 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.
> 
> HTH,
> -Garrett
>
----- Original Message -----
From: Lars Engels <lars.engels at 0x20.net>
> 
> You might also build a trimmed down kernel without USB support compiled
> in and use USB modules. Before suspending, unload them and re-load them
> after waking up again. That used to work on my Thinkpad.
> 

First I tried to build kernel only without 'ums' and kldload it.
3 times in a row, to S3 and back worked, so I hopped it works, until 4th and 5th time, resulted in error.
I like things to 'WORK' or 'NOT TO WORK'.
This is some borderline case, where IT does "this" on random, so I was so pissed of, with need to test 10 times in a row (slapping lid), to confirm not/working status!

Then I tried ums, uhid, ukbd drivers and recompiled kernel.
Slapping lid around again and nada!

Then what really drained me, was point of removing usb drivers 1 by 1, which caused many kernel builds to fail.
Then again build with 1 job, just to see what was missing, and again ...
Duh!

First echi, then it was uhci, then umass wasn't happy, then uhid ... Tsk tsk!
Anyway now it DOES work: (after ~16 kern builds!)

# vi /boot/loader.conf
--
ums_load="YES"
ehci_load="YES"
uhci_load="YES"
usb_load="YES"
umass_load="YES"
uhid_load="YES"
ukbd_load="YES"
--

And appropriate kld(un)load lines in /etc/rc.suspend and /etc/rc.resume, made it work.
Now upon resume, I see at least 8 times more kernel output.



Domagoj Smolčić