S10 on amd64 timewarp
Peter C. Tribble
Opteron machine is in a wierd state and not talking to me. It's up, but
I can't get in and nothing via the network works.
Fortunately I left a window open on it, and that reveals something
*very* interesting:
% date
Tue Jan 6 09:47:48 BST 1970
Yikes!
And, for what it's worth, if I count back then it gets to 00:00:00 on
Jan 1 1970 at exactly 2am last Sunday, when the clocks went to British
Summer Time.
(And it just affects the 64-bit x86 system - 32-bit x86 machines and
all my sparc boxes are fine. I've only got one opteron box, so I don't
know whether it's just that one machine or whether it's all such
machines that are affected. Odd that I haven't heard about this from
anywhere else, though.)
It appears that this is global. For example, "perl -e 'print time();'"
gives 464773 which is about right for just over 5 days. And
/var/adm/messages starts with:
Jan 1 00:04:23 einsteinium nis_cachemgr: [ID 105279 daemon.error] nis_cast: t_open: /dev/udp:Not enough space
Is this a bug or what? Does 64-bit S10 on x86 know how to handle the
time change? (Although I can't see why, as the kernel clock isn't moved
at all. Or is this some strange interaction with rtc?)
(And as the US don't turn their clocks back until this weekend, are
they going to see it too?)
Still, it makes for an interesting uptime:
% uptime
uptime: getexecname() failed
% /usr/bin/amd64/uptime
3:40pm up 36894 day(s), 3:02, 0 users, load average: 1.02, 1.02, 1.02
even if most other things I try fail completely!
--
-Peter Tribble
MRC Rosalind Franklin Centre for Genomics Research
http://www.rfcgr.mrc.ac.uk/~ptribble/ - http://ptribble.blogspot.com/
Casper H.S. Dik
>Just got back after a long easter break, to find that my sole 64-bit
>Opteron machine is in a wierd state and not talking to me. It's up, but
>I can't get in and nothing via the network works.
Yes, this is bug:
6247281 x86 real time warps back to beginning of time on DST change
Except that it really wrapps to 2070 or some such.
You will need to reboot and set the date; the bug causes a kernel
variable to be truncated to a 32 bit value (it's 64 bit signed).
You can fix the variable using:
mdb -wk
gmt_lag+4/Wffffffff
which sign extends it.
Then you can call "date/rdate" again to set the time, that is, if you
can still login.
>And, for what it's worth, if I count back then it gets to 00:00:00 on
>Jan 1 1970 at exactly 2am last Sunday, when the clocks went to British
>Summer Time.
Exactly; it's a bug in the interface used by the "rtc" command which
only manifests itself on 64 bit kernel on amd64 and only in timezones
which are before GMT (upto including the UK in the summer)
Unfortunately, our AMD64 port was only completed just in time for
the last date rollover so only a few machines were running it west
of the UK (the change to wintertime did not affect the UK) and while
hnting down the issue we found a few more issues that caused this but
missed this one.
>Is this a bug or what? Does 64-bit S10 on x86 know how to handle the
>time change? (Although I can't see why, as the kernel clock isn't moved
>at all. Or is this some strange interaction with rtc?)
Yes.
>(And as the US don't turn their clocks back until this weekend, are
>they going to see it too?)
No, at least not that we think.
It also affects all uses of the "rtc -c -z zone" command where zone
translates to a negative timestamp.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Peter C. Tribble
Casper H.S. Dik <Caspe...@Sun.COM> writes:
> ptri...@hgmp.mrc.ac.uk (Peter C. Tribble) writes:
>
>>Just got back after a long easter break, to find that my sole 64-bit
>>Opteron machine is in a wierd state and not talking to me. It's up, but
>>I can't get in and nothing via the network works.
>
> Yes, this is bug:
>
> 6247281 x86 real time warps back to beginning of time on DST change
>
> Except that it really wrapps to 2070 or some such.
>
> You will need to reboot and set the date; the bug causes a kernel
> variable to be truncated to a 32 bit value (it's 64 bit signed).
Indeed. Unfortunately the window I had open was sufficiently crippled
that going for the power button was the only way out, but after setting
the date correctly it seems to be much happier.
I'm glad we didn't have anything mission critical on this box. That
would have been embarassing!
Thanks for the help!
Charles Meeks
Casper H.S. Dik wrote:
> ptri...@hgmp.mrc.ac.uk (Peter C. Tribble) writes:
>
>
>>Just got back after a long easter break, to find that my sole 64-bit
>>Opteron machine is in a wierd state and not talking to me. It's up, but
>>I can't get in and nothing via the network works.
>
>
> Yes, this is bug:
>
> 6247281 x86 real time warps back to beginning of time on DST change
>
> Except that it really wrapps to 2070 or some such.
>
> You will need to reboot and set the date; the bug causes a kernel
> variable to be truncated to a 32 bit value (it's 64 bit signed).
>
> You can fix the variable using:
>
> mdb -wk
> gmt_lag+4/Wffffffff
>
> which sign extends it.
>
> Then you can call "date/rdate" again to set the time, that is, if you
> can still login.
Casper, Since I have noticed several bugs reported against S10, I have
been wondering... is there a list, either public or contract access,
that enumerates bugs found thus far and workarounds for same. Or is
every customer supposed to just find them for themselves, sort of like
easter eggs ... although not nearly as much fun. ;-)
Charles
pbec...@gmail.com
Sun. Hahah, your date is wrong! Get a load of that! :-) A (rotten)
easter egg, perhaps :)
I too would like to know if there's a comprehensive list of the bugs
for x86 Sol10...So much for Solaris being "just Solaris"...sparc wins
out again :/
Rich Teer
> I too would like to know if there's a comprehensive list of the bugs
> for x86 Sol10...So much for Solaris being "just Solaris"...sparc wins
> out again :/
You can't blame Sun for the inadequacies of the PC platform (or for the
other OSes that inhabit it)...
--
Rich Teer, SCNA, SCSA
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich
Alan Coopersmith
|I too would like to know if there's a comprehensive list of the bugs
|for x86 Sol10...
SunSolve makes the bug database available to people with support
contracts. A simple comprehensive bug list would be too big and
get out of date too quickly. (If you truly mean comprehensive as
in including every bug, from P1 bugs like this time change down to
the bug I filed recently about the "addrss" typo in the getaddrinfo
man page which won't really cause any problems in using the system.)
|So much for Solaris being "just Solaris"...sparc wins
|out again :/
SPARC "won" here mainly for two reasons:
- it's had 64-bit support for years, instead of months, so a bug like
this would have been found years ago.
- it doesn't have this split-brained clock scheme like PC's to worry
about keeping in sync with the rtc command.
It's hard to blame the Sun for the PC architecture or for Intel & AMD
coming to the 64-bit CPU game years after Sun and the rest of the
the RISC CPU makers did.
--
________________________________________________________________________
Alan Coopersmith * al...@alum.calberkeley.org * Alan.Coo...@Sun.COM
http://www.csua.berkeley.edu/~alanc/ * http://blogs.sun.com/alanc/
Working for, but definitely not speaking for, Sun Microsystems, Inc.
Joerg Schilling
>Unfortunately, our AMD64 port was only completed just in time for
>the last date rollover so only a few machines were running it west
>of the UK (the change to wintertime did not affect the UK) and while
>hnting down the issue we found a few more issues that caused this but
>missed this one.
This is wrong: a few years ago, the UK and the EU did agree on a unique
summer time switching. Unless the UK ignores this, the UK did agree to
switch to summer time in March already and the rest of the EU did extend
for one month...
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
schi...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Casper H.S. Dik
>In article <424d328f$0$154$e4fe...@news.xs4all.nl>,
>Casper H.S. Dik <Caspe...@Sun.COM> wrote:
>>ptri...@hgmp.mrc.ac.uk (Peter C. Tribble) writes:
>>Unfortunately, our AMD64 port was only completed just in time for
>>the last date rollover so only a few machines were running it west
>>of the UK (the change to wintertime did not affect the UK) and while
>>hnting down the issue we found a few more issues that caused this but
>>missed this one.
>This is wrong: a few years ago, the UK and the EU did agree on a unique
>summer time switching. Unless the UK ignores this, the UK did agree to
>switch to summer time in March already and the rest of the EU did extend
>for one month...
You've misread what I wrote: when the UK switches to wintertime,
it calls sysi86(SGMTL, 0), it sets the GMT lag to 0 as wintertime is
the "natural" time. When SGMTL is called with an argument >= 0 the bug
does not occur.
Only when sysi86(SGMTL, newlag) is called with a negative value, time blows up.
Kjetil Torgrim Homme
>
> - it doesn't have this split-brained clock scheme like PC's to worry
> about keeping in sync with the rtc command.
why does Solaris bother to use local time on the RTC, anyway? I've
never run DOS or Windows on any of my PCs, and with Linux the
recommended setting is to set the RTC to be UTC. how many of the
servers Sun sell do you expect are set up with dualbooting Windows?
--
Kjetil T.
Scott Howard
Servers? None of them.
But take a quick look through this group and you'll find no shortage of
people trying to multiboot two, three or even more OSes on their PCs.
Scott
Casper H.S. Dik
The default is to coexist nicely with others; but if you want you can run:
rtc -c -z GMT
and the clock is run in UTC.
The recommended setting for Linux does not play ball with anything else
I'm aware off. Can Windows do that?
Rich Teer
> This is wrong: a few years ago, the UK and the EU did agree on a unique
Frankly, I think the whole concept of "daylight saving" by messing about with
the clock twice per year is wrong!
Casper H.S. Dik
>On Sat, 2 Apr 2005, Joerg Schilling wrote:
>> This is wrong: a few years ago, the UK and the EU did agree on a unique
>Frankly, I think the whole concept of "daylight saving" by messing about with
>the clock twice per year is wrong!
The whole timezone idea is broken, anyway :-)
Laurent Blume
> The whole timezone idea is broken, anyway :-)
That's why the JDS clock can be set to UNIX time, much cleanier.
It's currently the 1112461133rd second since the Epoch :-)
Laurent
Kjetil Torgrim Homme
>
> The default is to coexist nicely with others; but if you want you
> can run:
>
> rtc -c -z GMT
>
> and the clock is run in UTC.
thanks.
> The recommended setting for Linux does not play ball with anything
> else I'm aware off. Can Windows do that?
yes, the Windows NT kernel has a registry key:
HKLM/SYSTEM/CurrentControlSet/Control/TimeZoneInformation/RealTimeIsUniversal
(REG_DWORD = 1)
(as I don't have Windows, I haven't tried it.)
--
Kjetil T.
Andrew Gabriel
Casper H.S. Dik <Caspe...@Sun.COM> writes:
> ptri...@hgmp.mrc.ac.uk (Peter C. Tribble) writes:
>
>>Just got back after a long easter break, to find that my sole 64-bit
>>Opteron machine is in a wierd state and not talking to me. It's up, but
>>I can't get in and nothing via the network works.
>
> Yes, this is bug:
>
> 6247281 x86 real time warps back to beginning of time on DST change
>
> Except that it really wrapps to 2070 or some such.
Yes. The system seemed to be mainly killed by /proc becoming inaccessable
to all non-64-bit processes (and possibly all non-largefile processes),
because the timestamps in it result in EOVERFLOW returns (IIRC) for most
processes accessing it.
--
Andrew Gabriel
Casper H.S. Dik
>thanks.
>HKLM/SYSTEM/CurrentControlSet/Control/TimeZoneInformation/RealTimeIsUniversal
>(REG_DWORD = 1)
This does seem to work:
- change the registry setting as seen above
- configure "date & time" changing to "automatic" in the
control panel
- run "rtc -c -z GMT" on Solaris
- set the clock to the correct time.
Casper
Casper H.S. Dik
>thanks.
>HKLM/SYSTEM/CurrentControlSet/Control/TimeZoneInformation/RealTimeIsUniversal
>(REG_DWORD = 1)
BTW, thanks a lot for this gem; I have some dual boot systems and DST
changes are always a pain.
This must be little known; google only gave 13 matches for it.
Of course, we'll have to wait a year or so to be sure it really works;
and it's weird you need to check the "automatically adjust" tick box to
make it work.
Rich Teer
> Of course, we'll have to wait a year or so to be sure it really works;
> and it's weird you need to check the "automatically adjust" tick box to
> make it work.
Weird, not too suprising. WIndoze is, after all, broken as designed...
Joerg Schilling
What do you like to do instaead? Du you like to have two different
methods on Solaris?
Linux is a constant cause of pain with RTC and UNIX time if you
ever boot Win32 on the same machine. These problems do not happen
with Solaris.
Joerg Schilling
Casper H.S. Dik <Caspe...@Sun.COM> wrote:
>
>>On Sat, 2 Apr 2005, Joerg Schilling wrote:
>
>>> This is wrong: a few years ago, the UK and the EU did agree on a unique
>
>>Frankly, I think the whole concept of "daylight saving" by messing about with
>>the clock twice per year is wrong!
>
>The whole timezone idea is broken, anyway :-)
Yes, US people would not admit that they are on a negative
TZ offset.....
Paris is approx. at the same longitude as Greenwitch but if you look
at hotel world time clocks, you see Paris as the marker for MET.
....more correct would be to use Berlin which is only 3 minutes off MET.
Thomas Tornblom
> On Sat, 2 Apr 2005, Casper H.S. Dik wrote:
>
> > Of course, we'll have to wait a year or so to be sure it really works;
> > and it's weird you need to check the "automatically adjust" tick box to
> > make it work.
>
> Weird, not too suprising. WIndoze is, after all, broken as designed...
VMS heritage shining trough?
>
> --
> Rich Teer, SCNA, SCSA
>
Thomas
Kjetil Torgrim Homme
>
> Kjetil Torgrim Homme wrote:
> > why does Solaris bother to use local time on the RTC, anyway?
> > I've never run DOS or Windows on any of my PCs, and with Linux
> > the recommended setting is to set the RTC to be UTC. how many
> > of the servers Sun sell do you expect are set up with
> > dualbooting Windows?
>
> What do you like to do instaead?
isn't it clear? I want the RTC to be UTC.
> Do you like to have two different methods on Solaris?
I only need one. thanks to Casper, I now know how to do it, and
without inconveniencing other installations.
> Linux is a constant cause of pain with RTC and UNIX time if you
> ever boot Win32 on the same machine. These problems do not happen
> with Solaris.
why are you booting Win32 on the same machine? besides, I already
gave a method for fixing Windows.
the pain caused by using the RTC on localtime is just so much greater.
consider a laptop. do you change the RTC according to the timezone as
you travel across the world? keep it simple, keep it on UTC.
--
Kjetil T.
Joerg Schilling
Kjetil Torgrim Homme <kjet...@kaksi.ifi.uio.no> wrote:
>> Linux is a constant cause of pain with RTC and UNIX time if you
>> ever boot Win32 on the same machine. These problems do not happen
>> with Solaris.
>
>why are you booting Win32 on the same machine? besides, I already
>gave a method for fixing Windows.
Send me a Centrino wlan driver for my notebook and I will stop booting
win32 on it....
Scott Howard
> Send me a Centrino wlan driver for my notebook and I will stop booting
> win32 on it....
Can't do that sorry, but I can tell you that it's being worked on (along
with a lot of other WLAN support)...
Scott.
Charles Meeks
Is the Belkin 2.4G pcmcia wireless card among those being worked on, or
are there already drivers for it? I am certain it comes as no surprise
to readers here, but Solaris, even the latest SX build, lacks a
sufficient scope of drivers to allow most of us to run Solaris on our
laptops/desktops as a viable windows replacement. I wish I could run
Solaris exclusively.
Rich Teer
> Is the Belkin 2.4G pcmcia wireless card among those being worked on, or
> are there already drivers for it? I am certain it comes as no surprise
> to readers here, but Solaris, even the latest SX build, lacks a
> sufficient scope of drivers to allow most of us to run Solaris on our
> laptops/desktops as a viable windows replacement. I wish I could run
> Solaris exclusively.
You'll be able to do so very soon. I'm typing this on my Ferrari 3400,
using wireless Ethernet. (The drivers are still very early versions,
so they're not available on the SOlaris Express program yet...)
--
Rich Teer, SCNA, SCSA
President,