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>