Messages in this thread | | | From | "Pedro M. Rodrigues" <> | Date | Tue, 25 Jan 2000 17:11:05 -0000 | Subject | Re: "Clock Skew detected error" |
| |
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/
| |