Date: Mon, 14 Nov 2011 20:50:57 +0100 From: rank1seeker@gmail.com To: "Garrett Cooper" <yanegomi@gmail.com>, "Lars Engels" <lars.engels@0x20.net>, "Ian Smith" <smithi@nimnet.asn.au>, pyunyh@gmail.com, hackers@freebsd.org, freebsd-acpi@freebsd.org Subject: Re: Adventure into S3 state and back Message-ID: <20111114.195057.675.1@DOMY-PC> In-Reply-To: <20111114021413.GA1709@michelle.cdnetworks.com> References: <20111110.182948.630.1@DOMY-PC> <20111112002727.GD17792@michelle.cdnetworks.com> <20111112.144149.725.1@DOMY-PC> <20111114021413.GA1709@michelle.cdnetworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message ----- From: YongHyeon PYUN <pyunyh@gmail.com> To: rank1seeker@gmail.com Cc: hackers@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: 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@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ć
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111114.195057.675.1>