I have a Sunblade 150 running Solaris 10 and which has a SunPCI3 card. 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 OGrady wrote: > I have a Sunblade 150 running Solaris 10 and which has a SunPCI3 card. > 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 OGrady wrote: >> I have a Sunblade 150 running Solaris 10 and which has a SunPCI3 card. >> 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.
> 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?
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)
Gordon Sande wrote: > On 2010-01-12 11:10:41 -0400, "Richard B. Gilbert" > <rgilber...@comcast.net> said:
>> Barry OGrady wrote: >>> I have a Sunblade 150 running Solaris 10 and which has a SunPCI3 card. >>> 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.
>> 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?
> 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)
On 2010-01-12 11:59:35 -0400, Chris Ridd <chrisr...@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.
Gordon Sande wrote: > On 2010-01-12 11:59:35 -0400, Chris Ridd <chrisr...@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.
As may be! Our descendants can struggle with that one a few centuries from now.
<rgilber...@comcast.net> wrote: >Barry OGrady wrote: >> I have a Sunblade 150 running Solaris 10 and which has a SunPCI3 card. >> 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.
Richard B. Gilbert wrote: > Barry OGrady wrote: >> I have a Sunblade 150 running Solaris 10 and which has a SunPCI3 card. >> 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.
> On Tue, 12 Jan 2010 10:10:41 -0500, "Richard B. Gilbert"
> <rgilber...@comcast.net> wrote: > >Barry OGrady wrote: > >> I have a Sunblade 150 running Solaris 10 and which has a SunPCI3 card. > >> 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.
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.
> On Wed, 13 Jan 2010 21:29:55 -0800 (PST), David Kirkby <drkir...@gmail.com> wrote: > >On Jan 12, 8:30 pm, Barry OGrady <god_free_jo...@hotmail.com> wrote: > >> On Tue, 12 Jan 2010 10:10:41 -0500, "Richard B. Gilbert"
> >> <rgilber...@comcast.net> wrote: > >> >Barry OGrady wrote: > >> >> I have a Sunblade 150 running Solaris 10 and which has a SunPCI3 card. > >> >> 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.
> >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.
> This is a quote from a forum. > "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."
> Gordon Sande wrote: >> On 2010-01-12 11:59:35 -0400, Chris Ridd <chrisr...@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 L. Hamilton wrote: > In article <beKdnUGjoIoTTdHWnZ2dnUVZ_tKdn...@giganews.com>, > "Richard B. Gilbert" <rgilber...@comcast.net> writes: >> Gordon Sande wrote: >>> On 2010-01-12 11:59:35 -0400, Chris Ridd <chrisr...@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...
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.
On Mon, 15 Feb 2010 20:00:30 GMT, Richard L. Hamilton <rlha...@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.
Paul Floyd wrote: > On Mon, 15 Feb 2010 20:00:30 GMT, Richard L. Hamilton <rlha...@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!
> Paul Floyd wrote: >> On Mon, 15 Feb 2010 20:00:30 GMT, Richard L. Hamilton >> <rlha...@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!
If Unix or VMS is still around at either of those dates, we have bigger problems than date rollovers. -- Chris
In article <slrnhnjckd.th.r...@tryfan.orange.fr>, Paul Floyd <r...@127.0.0.1> wrote:
>On Mon, 15 Feb 2010 20:00:30 GMT, Richard L. Hamilton <rlha...@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.
