----- Original Message -----
From: YongHyeon PYUN <pyu...@gmail.com>
To: rank1see...@gmail.com
Cc: hack...@freebsd.org, freebsd-acpi@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:

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

> > 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.eng...@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 ...

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

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ć

freebsd-acpi@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Reply via email to