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@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@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@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:15 EST