RE: Year 2078 problem!

["Tibbetts, Richard" <Richard Tibbetts PSS Boeing com>]

> mann@eecg.toronto.edu writes:
> 
>  > i had a similar problem.
>  > 
>  > the time was wrong, so i set it using the date command, and
>  > then after using the date command, i used the
>  > /sbin/clock
>  > command so that it would persist after rebooting (e.g. this should
>  > set it so the time is correct even if computer shut off and
> restarted).
>  > 
>  > when i turned it on again, after shutting down, instead of being
> the
>  > correct time, it showed 2078, and would not boot until i fixed it.
>  > 
>  > thus it seems that the /sbin/clock command does not work.
> 
> People have reported that this problem goes away by either removing
> the battery from the motherboard for >5 minutes or replacing the
> battery.
> 
I'd have to concur with this. Mine was doing the same thing. Setting it
from either SRM or from within Linux, would only correct it for the
duration of that session.The first time I'd power it off, it'd go back
to being wrong again (except on mine it going to 2018). 
	What I did, was power it down, and pull the battery for a minute
or two to totally flush the cmos. Then, put it back, and start it back
up. Keep in mind that this will blow away all of your SRM setting, and
you need to re-do them, but it's a small price.
	After doing this, the clock has stayed accurate.


		Ric


> -- 
> Harvey J. Stein
> BFM Financial Research
> hjstein@bfr.co.il
> 
> -- 
> To unsubscribe: send e-mail to axp-list-request@redhat.com with
> 'unsubscribe' as the subject.  Do not send it to axp-list@redhat.com
>