Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Jan 2015 00:36:23 +0200
From:      Ivan Klymenko <fidaj@ukr.net>
To:        Andriy Gapon <avg@FreeBSD.org>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r277796 - in head/sys: dev/acpica dev/syscons dev/vt sys
Message-ID:  <20150128003623.4f843a5c@nonamehost.local>
In-Reply-To: <201501271733.t0RHXJ3M058422@svn.freebsd.org>
References:  <201501271733.t0RHXJ3M058422@svn.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
=D0=92 Tue, 27 Jan 2015 17:33:19 +0000 (UTC)
Andriy Gapon <avg@FreeBSD.org> =D0=BF=D0=B8=D1=88=D0=B5=D1=82:

> Author: avg
> Date: Tue Jan 27 17:33:18 2015
> New Revision: 277796
> URL: https://svnweb.freebsd.org/changeset/base/277796
>=20
> Log:
>   hook userland threads suspend + resume into acpi suspend code
>  =20
>   Also, split power_suspend into power_suspend and
> power_suspend_early.=20
>   power_suspend_early is called before the userland is frozen.
>   power_suspend is called after the userland is frozen.
>  =20
>   Currently only VT switching is hooked to power_suspend_early.
>   This is needed because switching away from X server requires its
>   cooperation, so obviously X server must not be frozen when that
> happens.=20
>   Freezing userland during ACPI suspend is useful because not all
> drivers correctly handle suspension concurrent with other activity.
> This is especially applicable to drivers ported from other operating
> systems that suspend all software activity between placing drivers
> and hardware into suspended state.
>   In particular drm2/radeon (radeonkms) depends on the described
>   procedure.  The driver does not have any internal synchronization
>   between suspension activities and processing of userland requests.
>  =20
>   Many thanks to kib for the code that allows to freeze and thaw all
>   userland threads.
>  =20
>   Note that ideally we also need to park / inhibit (non-special)
> kernel threads as well to ensure that they do not call into drivers.
>  =20
>   MFC after:	17 days
>=20

Thank you for your work!

acpiconf -s 3 works perfectly, but there is one problem.
I use not the main timecounter
kern.timecounter.hardware=3DHPET
after turning on the power button does not occur laptop recovery hdac0
and it is likely that the same applies to the timer.
Indirect evidence of this - it's a quick video playback, for example in
flash on YouTube.

dmesg_first : http://pastebin.com/a4gC5PGy
dmesg_afterS3 : http://pastebin.com/vyHtrakZ

my HW:

pciconf -lvbce :
https://bz-attachments.freebsd.org/attachment.cgi?id=3D148947
devinfo -vr :
https://bz-attachments.freebsd.org/attachment.cgi?id=3D148948

Thanks.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150128003623.4f843a5c>