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 -----=0D=0AFrom: YongHyeon PYUN = <pyunyh@gmail.com>=0D=0ATo: rank1seeker@gmail.com=0D=0ACc: = hackers@freebsd.org, freebsd-acpi@freebsd.org=0D=0ADate: Sun, 13 Nov 2011 = 18:14:13 -0800=0D=0ASubject: Re: Adventure into S3 state and = back=0D=0A=0D=0A> > > =0D=0A> > > Known issue. kern/136876.=0D=0A> > > = Mobile bge(4) controllers seem to have this issue.=0D=0A> > =0D=0A> > I = can see this has been reported, when 8.0-BETA1 was released.=0D=0A> > Now = is almost 8.3 out and problem is still present=0D=0A> =0D=0A> Actually I = spent a lot of time to address this but all attempts=0D=0A> failed mainly = because I have no access to such bge(4) controllers.=0D=0A> Remote = debugging does not work for suspend/resume issues so chances=0D=0A> would = be low to get it fixed in near future unless someone donate=0D=0A> = problematic hardwares to me.=0D=0A=0D=0A=0D=0AThen you have to = update:=0D=0Ahttp://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/136876=0D=0A=0D=0AAnd = post at the end, something like ...=0D=0A"All attempts to fix problem = failed, due to physicall unavailability of bge(4) controller.=0D=0ASTATUS = -> Waiting for donation of bge(4) hardware, in order to resume fixing a = problem"=0D=0A=0D=0A=0D=0A> > Mouse won't work unless I unplug/plug it's = USB receiver=0D=0A> =0D=0A> You may need to kldunload and kldload ums(4) = in order to get things to=0D=0A> work (which suggests a driver bug in the = newbus suspend and resume=0D=0A> functions).=0D=0A> =0D=0A> FWIW I only = need to do /etc/rc.d/moused restart in rc.resume to get=0D=0A> things to = work, but I'm using psm(4). The mouse pointer is kind of=0D=0A> braindead = for a second, but then it comes to life and does the right=0D=0A> = thing.=0D=0A> =0D=0A> So, bottom line is that there's something that gets = out of sync with=0D=0A> some mice drivers and moused, and mice driver = bugs or bugs with moused=0D=0A> might be involved.=0D=0A> =0D=0A> = HTH,=0D=0A> -Garrett=0D=0A>=0D=0A----- Original Message -----=0D=0AFrom: = Lars Engels <lars.engels@0x20.net>=0D=0A> =0D=0A> You might also build a = trimmed down kernel without USB support compiled=0D=0A> in and use USB = modules. Before suspending, unload them and re-load them=0D=0A> after = waking up again. That used to work on my Thinkpad.=0D=0A> = =0D=0A=0D=0AFirst I tried to build kernel only without 'ums' and kldload = it.=0D=0A3 times in a row, to S3 and back worked, so I hopped it works, = until 4th and 5th time, resulted in error.=0D=0AI like things to 'WORK' = or 'NOT TO WORK'.=0D=0AThis 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!=0D=0A=0D=0AThen I tried = ums, uhid, ukbd drivers and recompiled kernel.=0D=0ASlapping lid around = again and nada!=0D=0A=0D=0AThen what really drained me, was point of = removing usb drivers 1 by 1, which caused many kernel builds to = fail.=0D=0AThen again build with 1 job, just to see what was missing, and = again ...=0D=0ADuh!=0D=0A=0D=0AFirst echi, then it was uhci, then umass = wasn't happy, then uhid ... Tsk tsk!=0D=0AAnyway now it DOES work: (after = ~16 kern builds!)=0D=0A=0D=0A# vi = /boot/loader.conf=0D=0A--=0D=0Aums_load=3D"YES"=0D=0Aehci_load=3D"YES"=0D=0Auhci_load=3D"YES"=0D=0Ausb_load=3D"YES"=0D=0Aumass_load=3D"YES"=0D=0Auhid_load=3D"YES"=0D=0Aukbd_load=3D"YES"=0D=0A--=0D=0A=0D=0AAnd = appropriate kld(un)load lines in /etc/rc.suspend and /etc/rc.resume, made = it work.=0D=0ANow upon resume, I see at least 8 times more kernel = output.=0D=0A=0D=0A=0D=0A=0D=0ADomagoj Smol=E8i=E6=0D=0A=0D=0A
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111114.195057.675.1>