"Clock Skew detected error"

[Pedro M. Rodrigues]

   There are small and +/- cheap isa cards with a new bios on 
them. They should solve the problem of the hardware Y2K rollover 
bug.


Pedro Rodrigues

On 25 Jan 00, at 14:30, Anton Ivanov wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> 
> 
> On 25-Jan-2000 Sujit Vaidya wrote:
> > HI,
> >   I changed the date on the machine using the date
> > command. Then the kernel compiles fine without any
> > errors. But again when i reboot the system it takes
> > the original date. i.e it sets the date to 
> > JAN ** , 1994. 
> >   Is there any way i can change that.
> 
> BIOS considers the date invalid and sets it to manufacturing date.
> Unless you can find a y2k compliant BIOS upgrade you have no
> standalone option.
> 
> If you are on a network set the time somewhere very early in the init
> scripts to something like 1 Jan 2000 and than do a ntp date versus a
> machine with a proper clock. You have to adjust the date first because
> ntpdate will not sync if the difference is too big (something like 6
> months or more).  Than off you go... ;-)
> 
> In btw: linux kernel release dates are very well known. Why not do
> something many bioses do (as an option of course). If date on the
> computer is before the release date and/or compile date adjust the
> date to release/compile date?
> 
> As I said as an option..., part of the RTC driver for example? 
> 
> As a result linux will be one of the few systems to behave reasonably
> on partially non-y2k compliant hardware (clock is OK, but BIOS or
> bootsrap screw it up;-). In btw: amidst 486 this type of problem
> should be quite common.
> 
> - ----------------------------------
> Anton R. Ivanov
> IP Engineer Level3 Communications
> RIPE: ARI2-RIPE      E-Mail: Anton Ivanov <aivanov en eu.level3.net> @***
> White's Observations of Committee Operation ***
>       1) People very rarely think in groups;
>          they talk together, they exchange information, they
>          adjudicate, they make compromises.  But they do not
>          think; they do not create.
>       2) A really new idea affronts current agreement.
>       3) A meeting cannot be productive unless certain premises
>          are so shared that they do not need to be discussed,
>          and the argument can be confined to areas of disagreement.
>          But while this kind of consensus makes a group more effective
>          in its legitimate functions, it does not make the group a
>          creative vehicle -- it would not be a new idea if it didn't
>          -- and the group, impelled as it is to agree, is
>          instinctively hostile to that which is divisive.
> 
> - ----------------------------------
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.0 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iQEVAwUBOI2zaSlWAw/bM84zAQG+bQf8Dvjpz1BMYLD64swoTtiJ9Rtd0o36Uo7J
> MJytT58yiaT8hC6/YjSelMxP5zPM17QolZ9BYRYh5PKv7fPC5YgRyGZgclHYQQKU
> +TAl6IR6gJBogzWWDtU617e1gB5jjYGujciMwbdAVRUUW44qZakESo7ABmOxQexz
> pSkQgaim0Btg1fYH7hgYFPpCoTfsl7vAJR4y/u+A6B8OZPqhaAyl/EbwhHTutm2Y
> nM2kFE3HpukNpkEGloyFh1J/8VtjKI3FE9+wfSzv9XLDkZ3SLcxeBfXbySojgoGP
> Sc7B3Obtf8ZrqNzlPUKBG/4dOAu64J2aLNcCu9VUyrmyV2SR5SOmzA==
> =B7bM
> -----END PGP SIGNATURE-----
> 
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to majordomo en vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
> 
> 



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/