Your clock is set in the future
Barry OGrady
I tried to run Windows XP on the card for the first time this year and
got an error message to the effect that the date is set in the future.
I discovered that it will run with the year set to 2009 but not with
the year set to 2010. Is there any way to fix it so it will run with
the proper date? I haven't checked the Sun website yet. Perhaps there
is updated SunPCI software.
=-=-=
Barry
http://members.iinet.net.au/~barry.og
Richard B. Gilbert
Why are people having Y2K+10 problems? I thought that 2037 was supposed
to be the next big stumbling block!
Did somebody just put a band-aid on Y2K instead of fixing it?
Gordon Sande
<rgilb...@comcast.net> said:
Four differnt problems:
1. expected 200A but got 2010!
2. 2010 outside the possible future of 2000-2009 hardwired back in 2000
3. buggy code checking for a leapyear after 2000 problems
4. 30 bit version of Unix 2032 bug (hits on Jan 6, 2020)
according to a couple minutes with Google
Richard B. Gilbert
Those who created such problems deserve them!
Never underestimate the power of human stupidity!
Chris Ridd
> 4. 30 bit version of Unix 2032 bug (hits on Jan 6, 2020)
I've not heard of that - you don't mean the 32-bit time_t rollover in
2038 do you?
--
Chris
Gordon Sande
Two typos! Jan 6, 2010 is 30 bit version of Unix 2038 bug. Evidently
some folks have a
30 bit clock from some (not immediately spcified or obvious) origin.
Richard B. Gilbert
<sigh!!!!!!!>
At least one better designed system has a 64 bit clock that will not
fail till the year 30,000 or thereabouts. I don't think they allowed
for five digit years however.
As may be! Our descendants can struggle with that one a few centuries
from now.
Barry OGrady
In this case it turns out that the SunPCI program does a date check.
Someone offered a fix by replacing the call to date check with a noop.
=-=-=
Barry
http://members.iinet.net.au/~barry.og
Martin Møller Skarbiniks Pedersen
David Kirkby
Since you have the fix, can you share it? I happen to have one of
those cards in a Blade 2000, though since I bought an Ultra 27, I've
not used the SunPCi card and to be honest doubt I will. But I'd like
to know of a fix if there is one.
dave
David Kirkby
> "In a hex editor (ghex2) I changed the longword at offset 4CF8 in sunpcbinary
> from 7FFFFE2E to 01000000. This replaces the call to validate_system_time
> with a nop. With this modified sunpcbinary managed to get SunPCI3 to boot
> without having to change the date."
>
> That worked for me.
>
> >dave
>
> Barry
> =====
> Home pagehttp://members.iinet.net.au/~barry.og
Thank you,
Richard L. Hamilton
"Richard B. Gilbert" <rgilb...@comcast.net> writes:
> Gordon Sande wrote:
>> On 2010-01-12 11:59:35 -0400, Chris Ridd <chri...@mac.com> said:
>>
>>> On 2010-01-12 15:34:11 +0000, Gordon Sande said:
>>>
>>>> 4. 30 bit version of Unix 2032 bug (hits on Jan 6, 2020)
>>>
>>> I've not heard of that - you don't mean the 32-bit time_t rollover in
>>> 2038 do you?
>>
>> Two typos! Jan 6, 2010 is 30 bit version of Unix 2038 bug. Evidently
>> some folks have a
>> 30 bit clock from some (not immediately spcified or obvious) origin.
>>
>
> <sigh!!!!!!!>
>
> At least one better designed system has a 64 bit clock that will not
> fail till the year 30,000 or thereabouts. I don't think they allowed
> for five digit years however.
64-bit time_t is good for _billions_ of years, further than present
science can say whether they'll still be a recognizable universe left
at all...
Richard B. Gilbert
The system I was referring to uses 100 nanosecond "ticks" so "30,000"
years is a bit closer than "billions".
>> As may be! Our descendants can struggle with that one a few centuries
>> from now.
They are welcome to it!
Paul Floyd
>
> 64-bit time_t is good for _billions_ of years, further than present
> science can say whether they'll still be a recognizable universe left
> at all...
Well, assuiming that's unsigned 64bit, that's 18446744073709551616
seconds. That's about 585 billion years. A bit of a while to wait, then.
A bientot
Paul
--
Paul Floyd http://paulf.free.fr
Richard B. Gilbert
> On Mon, 15 Feb 2010 20:00:30 GMT, Richard L. Hamilton <rlh...@smart.net> wrote:
>> 64-bit time_t is good for _billions_ of years, further than present
>> science can say whether they'll still be a recognizable universe left
>> at all...
>
> Well, assuiming that's unsigned 64bit, that's 18446744073709551616
> seconds. That's about 585 billion years. A bit of a while to wait, then.
>
A lot depends on the value of the low order bit! If, as in Unix, it
represents one second, sixty four bits is a LOT of years. If, as in
OpenVMS, it represents 100 nanoseconds the clock will fail in about
30,000 years. There may be still other schemes.
In any case, it will need to be very lucky to live long enough for it to
matter to me personally!
Chris Ridd
If Unix or VMS is still around at either of those dates, we have bigger
problems than date rollovers.
--
Chris
Joerg Schilling
Paul Floyd <ro...@127.0.0.1> wrote:
>On Mon, 15 Feb 2010 20:00:30 GMT, Richard L. Hamilton <rlh...@smart.net> wrote:
>>
>> 64-bit time_t is good for _billions_ of years, further than present
>> science can say whether they'll still be a recognizable universe left
>> at all...
>
>Well, assuiming that's unsigned 64bit, that's 18446744073709551616
>seconds. That's about 585 billion years. A bit of a while to wait, then.
The overflow happens earlier in tghe year member of struct tm which is
a signed int.
So it already happens in 2 billion years ;-)
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) J�rg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
joerg.s...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily