From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 14 03:08:19 2011 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9995B106567D for ; Mon, 14 Nov 2011 03:08:19 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id D3A148FC0C for ; Mon, 14 Nov 2011 03:08:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id pAE38FNO095057; Mon, 14 Nov 2011 14:08:16 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 14 Nov 2011 14:08:15 +1100 (EST) From: Ian Smith To: Garrett Cooper In-Reply-To: Message-ID: <20111114133503.T59637@sola.nimnet.asn.au> References: <20111110.182948.630.1@DOMY-PC> <20111112002727.GD17792@michelle.cdnetworks.com> <20111112.144149.725.1@DOMY-PC> <20111113094810.GC80782@e-new.0x20.net> <20111113.132924.396.1@DOMY-PC> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1524783476-1321238492=:59637" Content-ID: <20111114134914.S59637@sola.nimnet.asn.au> Cc: rank1seeker@gmail.com, pyunyh@gmail.com, freebsd-acpi@freebsd.org Subject: Re: Adventure into S3 state and back X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 03:08:19 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1524783476-1321238492=:59637 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-ID: <20111114134914.K59637@sola.nimnet.asn.au> Removing hackers@freebsd.org from ccs: On Sun, 13 Nov 2011, Garrett Cooper wrote: > On Sun, Nov 13, 2011 at 5:29 AM, wrote: > > ----- Original Message ----- > > From: Lars Engels > > To: rank1seeker@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 --0-1524783476-1321238492=:59637--