Date: Mon, 27 Sep 2010 16:21:15 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: freebsd-stable@FreeBSD.org Cc: Ted Faber <faber@isi.edu>, Vitaly Magerya <vmagerya@gmail.com>, Ian Smith <smithi@nimnet.asn.au> Subject: Re: resume slow on Thinkpad T42 FreeBSD 8-STABLE Message-ID: <201009271621.17669.jkim@FreeBSD.org> In-Reply-To: <4CA0E892.4010204@gmail.com> References: <20100224165203.GA10423@zod.isi.edu> <20100927170317.I90633@sola.nimnet.asn.au> <4CA0E892.4010204@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 27 September 2010 02:55 pm, Vitaly Magerya wrote: > Ian Smith wrote: > > [...] During the 60s resume stall period, iff > > I'd suspended from a VTY, I found I could slowly (like maybe 3 > > seconds per character echoed) type a command, and some commands - > > possibly those cached? as there's no HD access - would run after > > another few seconds. > > > > In this way I discovered that 'date' commands reported the time > > some seconds after the resume (perhaps hours ago, or yesterday) > > until the stall ended, disk light flashed and normality resumed, > > sometimes with "calcru: time went backwards .." messages, most > > often for devd. > > Yes, same here. I must add that some peripherals do not work > normally after the resume: > - the mouse doesn't work until I restart moused manually --- >8 --- SNIP!!! --- >8 --- If the mouse is connected to PS/2 port, the following device flags may help. 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. Can you please report other problems in the appropriate ML? em -> freebsd-net@ usb -> freebsd-usb@ acpi_ec -> freebsd-acpi@ BTW, USB stack issue is known problem AFAIK. Jung-uk Kim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201009271621.17669.jkim>