[Pm-utils] [PATCH 8/8] pm-utils 1.2.3 proposed patches
victor.lowther at gmail.com
Sun Nov 30 08:00:50 PST 2008
On Nov 29, 2008, at 2:32 PM, "Dan Nicholson" <dbn.lists at gmail.com>
> On Sat, Nov 29, 2008 at 11:44 AM, Victor Lowther
> <victor.lowther at gmail.com> wrote:
>> On Sat, 2008-11-29 at 10:51 -0800, Dan Nicholson wrote:
>>> On Sat, Nov 29, 2008 at 8:51 AM, Victor Lowther
>>> <victor.lowther at gmail.com> wrote:
>>>> Document NEED_CLOCK_SYNC
>>>> README.debugging | 6 ++++++
>>>> 1 files changed, 6 insertions(+), 0 deletions(-)
>>>> diff --git a/README.debugging b/README.debugging
>>>> index 76be415..47c756a 100644
>>>> --- a/README.debugging
>>>> +++ b/README.debugging
>>>> @@ -21,6 +21,12 @@ End-user customization and debugging:
>>>> environment variable to have that module removed when the system
>>>> suspends and reloaded when the system wakes up.
>>>> +* If your clock drifts across a sleep/wake cycle, you can use
>>>> + NEED_CLOCK_SYNC="true" to force pm-utils to synchronize clocks.
>>>> + This is a change in the default behaviour of pm-utils --
>>>> 22.214.171.124 and earlier
>>>> + always synchronized clocks, but doing so is slow and most
>>>> hardware stays in
>>>> + sync without assistance.
>>>> * To find out what parameters can be passed to pm-suspend and
>>>> friends, run them
>>>> with '--help' as the first parameter as root. This will print
>>>> out the
>>>> options that it supports and which hooks or modules handle those
>>> Yay! Could we also consider adding a config variable to handle
>>> alsactl? On my laptop (and hopefully most), the state doesn't change
>>> across suspend/resume. I guess we probably need to talk to some ALSA
>>> guru, though.
>> The way I understand it, talking to ALSA gurus requires special
> Well, I'll try sending a mail to alsa-devel and see if anything
Ok, but the alsa hook is pretty fast, so it is lower on my list of
I will probably release an updated 1.2.3 patch series later today. I
missed the slackware init system support patch, I made 50ntpd faster
in the fast path (it is still an ugly hack, tho), and there are some
doc updates as well.
>> Do these changes help with the speed of pm-suspend vs. without on
>> system? Would be able to apply the profiling patches to see a before
>> and after on your machine?
> I didn't profile, but I imagine my results are roughly the same as
> yours. I guess this is more a matter of correctness: lets not
> workaround things that the kernel should be (and probably already is)
More information about the Pm-utils