[Pm-utils] [PATCH 8/8] pm-utils 1.2.3 proposed patches

[Victor Lowther]

On Nov 29, 2008, at 2:32 PM, "Dan Nicholson" <dbn.lists at gmail.com>  
wrote:

> 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 --  
>>>> 1.2.2.1 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  
>>>> options.
>>>
>>> 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
>> incantations.
>
> Well, I'll try sending a mail to alsa-devel and see if anything  
> happens.

Ok, but the alsa hook is pretty fast, so  it is lower on my list of  
priorities.

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  
>> your
>> 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)
> doing.
>
> --
> Dan