[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Q] how to deal with 'clock vs hwclock' call

On Mon, Jun 01, 1998 at 08:55:13PM -0400, Gregory S. Stark wrote:

> > > And I don't quite see why this call has to be there. The kernel
> > > already does what I think you're trying to do:
> > 
> > Unfortunately, it doesn't do it properly.  I haven't had time to look at
> > it closely, but my laptop loses _large_ amounts of time when it goes
> > into suspend.
> Uhm, are you sure your laptop's clock isn't simply running too slowly? Run
> hwclock in a loop and see if it loses time. If so you need a patch to
> reset the timer interrupt after a resume. I'm pretty sure your model needs
> this.

Sometimes (VERY seldom) the clock has reset itself, and indeed that really
sucks.  You can tell because BEEP noises are about 5 times too long.

But that's not the same problem.  I have an unidentified time-lossage
problem when I go in and out of suspend.  The world just seems to slow down
in suspend.  Perhaps the problem is standby, where the system clock really
is slowed.  Anyway, hwclock -s -u fixes it.

> > One interesting effect is due to time zones:  last time I looked, the
> > kernel records the GMT offset the first time you go into
> > suspend/standby, and uses it forever after.  Interesting side effects:
> Oh ick, yes as i mentioned, if you set your CMOS clock to local time
> you're going to lose in a number of circumstances. You'll lose around the
> switch to and from daylight saving time, you'll lose if the cpu clock
> slows down before the kernel measures the offset from GMT, you'll lose all
> over the place.

Actually I set my CMOS clock to GMT, since I don't have any other OS on my
laptop.  I hate reporting problems I haven't investigated fully, but I
really did hit some problems with the GMT offset thing (I think perhaps it
went into standby while waiting for me to answer some question during
boot... and it set the GMT offset _afterward_.)

> The same patch i mentioned will solve that too. 

Thanks for including it, it may help.

> I would suggest setting the init.d scripts (or adding a configuration file
> in etc and configuring it there) to run-parts something like
> /etc/apmd-suspend.d and /etc/apmd-resume.d. That way users can add
> whatever they want.

Hmm, good idea.  I may have just become the apmd package maintainer, so this
might not be very far off :)

> I'm using the modified update (aka bdflush) daemon written by Pavel Machek
> that attempts to spin the disk down when possible. It does a decent job,
> though I can think of some improvements. It checks /proc/stat and when no
> reads have been done in a specified period (it can't check writes because
> of its own buffer flushing) it stops flushing buffers and calls a script
> in /etc/rc.spindown to explicitly spin down the disk using hdparm.

Could you give a pointer to this?

Thanks.  Have fun,


To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: