On Nov 29, 2008, at 2:32 PM, "Dan Nicholson" <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 29, 2008 at 11:44 AM, Victor Lowther > <[EMAIL PROTECTED]> wrote: >> On Sat, 2008-11-29 at 10:51 -0800, Dan Nicholson wrote: >>> On Sat, Nov 29, 2008 at 8:51 AM, Victor Lowther >>> <[EMAIL PROTECTED]> 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 _______________________________________________ Pm-utils mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pm-utils
