lkml.org 
[lkml]   [1910]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectStock Market Report for Sun Feb 13 1910
Stop and look at the dates for a sec.  The Subject: line was created
by my script, using the Linux 'date' command. All the rest were made
by the mail system.

I found that the problem was cleared by rebooting that computer (the
Pentium server), however, it still remains in my 486, which I have
not rebooted in order to have a bugged system that I can study.

First, a couple of notes:

1. This is not a BIOS/CMOS problem. I have checked both systems
with clock(8), and the dates are reported correctly. Even though
the 'date' command on the 486 continues to show the year as 1910.

2. This is not an application level or library bug. I now have
files on my system with dates set by the system to Feb 13, 1910.
Furthermore, I have a simple test program which when run on the 486
reports a wildly different number of seconds since 1 Jan 1970 than the
exact same binary run a second earlier or later on the Pentium.

The source of my test program is included at the end of this
message.

To elaborate on #2, here is the output I'm seeing from my test
program on both systems:

--------------------- from bug-plagued 486 --------------------
Result from gettimeofday():
The clock reads 2405401139 seconds and 682168 microseconds
since 1 Jan 1970
Result from time():
The clock reads 2405401139 seconds since 1 Jan 1970
gmtime() returns:
sec=43, min=30, hour=0
mday=15, mon=1, year=10, wday=2, yday=45, isdst=0
localtime() returns:
sec=43, min=30, hour=17
mday=14, mon=1, year=10, wday=1, yday=44, isdst=0
ctime() reports: Mon Feb 14 17:30:43 1910
----------------------- end ----------------------------------

And when I run 'date' on the 486, I get:

Mon Feb 14 17:30:48 MST 1910

-------------------------- from bug-cleared Pentium --------------
Result from gettimeofday():
The clock reads 950574317 seconds and 669079 microseconds
since 1 Jan 1970
Result from time():
The clock reads 950574317 seconds since 1 Jan 1970
gmtime() returns:
sec=17, min=25, hour=0
mday=15, mon=1, year=100, wday=2, yday=45, isdst=0
localtime() returns:
sec=17, min=25, hour=17
mday=14, mon=1, year=100, wday=1, yday=44, isdst=0
ctime() reports: Mon Feb 14 17:25:17 2000
------------------------ end -----------------------------------

And the 'date' program reports:

Mon Feb 14 17:25:24 MST 2000

(Note that the program was run a few seconds apart on the two
systems - the Pentium's clock is about 5 minutes behind the 486's,
which is why they look like they were run 5 minutes apart.)

The problem seems to be coming from the system calls gettimeofday()
and time(), which are reporting very different values between the
bugged and bug-cleared systems. I have not looked into the kernel
source, so I can't provide further analysis there at this time.

Note that since the CMOS clock is fine, rebooting a system that has
this problem will clear it. That's why I'm keeping the 486 up for
a while while I do the analysis. And I assume that setting the
clock with the date command will work as well.

This problem is not easily reproducible - I have a friend down the
street (i.e., in the same time zone = Arizona) and his RH 6.0
system has been up for 5 days without the problem showing up.

The 486 is currently showing an uptime of 12 days, and was
last booted on 1 Feb at 22:38. The Pentium was also booted on
1 Feb, but had been rebooted a few times afterward, notably on Feb 12
at 22:28, and showed the problem the next day.

Hmm... it just occurred to me that both of the bugged systems have
an AMD processor - the "Pentium" is actually an AMD K6 and the "486"
has an Evergreen processor upgrade, which is reported by /proc/cpuinfo
as an "AuthenticAMD Am5x86-WT". Coincidence?

Again, note that I'm not subscribed to the linux-kernel list, and I'd
appreciate if followup messages were CC'd to me.

Cheers,

- Jay Ts
jay@jayts.cx
http://jayts.cx

----------------------- test program source ---------------------
#include <sys/types.h>
#include <time.h>
#include <sys/time.h>
#include <unistd.h>

time_t time(time_t *tloc);

main()
{
time_t clock;
struct tm tp;
int timval;
struct timeval tvp;

if(gettimeofday(&tvp,0) != 0)
{
printf("error from gettimeofday()\n");
}

printf("Result from gettimeofday():\n\tThe clock reads %lu seconds and %lu microseconds\n\tsince 1 Jan 1970\n",tvp.tv_sec,tvp.tv_usec);

clock = time(0);
printf("Result from time():\n\tThe clock reads %u seconds since 1 Jan 1970\n",clock);

tp = *gmtime(&clock);

printf("gmtime() returns: ");
printf("\n\tsec=%d, min=%d, hour=%d\n\tmday=%d, mon=%d, year=%d, wday=%d, yday=%d, isdst=%d\n",
tp.tm_sec,
tp.tm_min,
tp.tm_hour,
tp.tm_mday,
tp.tm_mon,
tp.tm_year,
tp.tm_wday,
tp.tm_yday,
tp.tm_isdst);
tp = *localtime(&clock);

printf("localtime() returns: ");
printf("\n\tsec=%d, min=%d, hour=%d\n\tmday=%d, mon=%d, year=%d, wday=%d, yday=%d, isdst=%d\n",
tp.tm_sec,
tp.tm_min,
tp.tm_hour,
tp.tm_mday,
tp.tm_mon,
tp.tm_year,
tp.tm_wday,
tp.tm_yday,
tp.tm_isdst);

printf("ctime() reports: %s",ctime(&clock));
}
--------------------- end ---------------------------

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.030 / U:0.856 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site