Time flies and it's not Fun.

Time flies and it's not Fun.

Post by Martin McCormi » Sun, 31 Dec 1899 09:00:00



        What kind of kernel configuration error might cause the system
time and date to serge forward about 16 hours or so around ten minutes
after booting the new kernel?

        The system has worked for months on an older kernel that
someone else who is no longer around here configured.  As I said in an
earlier message, I am simply building a new kernel to add sound
support.

        Well, I built one without the sound and it still has the
glitch.  When it is in sea sure mode, the system seems to hang for a
fraction of a second and then it resumes working, only with the
corrupted time count.

        I did check with Dell to see what kind of PCI bus controller
is used and they indicated that it is a 440FXPCI.  Those letters do
not appear to exist in that combination anywhere in the  kernel
documentation which means that there is probably some generic choice I
should make that is not intuitive.

        I have noticed that the sound drivers also do not appear to be
working, but I don't know if that is related to the same problem.
It's all academic until the system is stable.

        I can communicate on the network and everything looks fine
until the system glitches and then the date shoots ahead.

        It also does not corrupt the CMOS as the date is correct after
a reboot.

        What should I be looking at since the system seems to be close
to working?  As luck has it, nothing complains.  It's just obvious
that the system is unstable.

        I have had the same results on a 2.2.17 kernel and a 2.2.9
which is what I am working with now.

Martin McCormick WB5AGZ  Stillwater, OK
OSU Center for Computing and Information Services Data Communications Group

 
 
 

1. Time Flies and it is not Fun

        I have built a 2.2.17 kernel for a Dell Dimension xps h266 and
as I stated in earlier messages to the group, it basically works.  The
system comes up, does dhcp, and talks on the network like it should.
The first hint of trouble happens at almost exactly 10 minutes after
boot when the date suddenly shoots ahead some random amount of time.
I have had it gain about 16 hours before or it may gain as much as 42
or 43 hours.  I don't think the actual amount tells us anything except
that something is writing junk to a counter.

        I was telling this tale of woe to some of our local Linux
group and somebody said that there is a jiffy clock which is
deliberately set to overflow about 10 minutes after initial start so
that one can know if one's software can handle the overflow.  It
sounds like something is not handling it, all right.  I don't know for
sure that this is the problem, but the glitch seems to hit right at
the ten minute mark.  I waited around another 10 minutes until the
uptime output said that the system was up for 20 minutes and there was
no further sudden increase.  Oddly enough, the uptime counter must not
derive its value from the same place as the counter for the time and
date, or the conversion program for the local time zone must be
corrupted for the uptime value does not reflect the glitch.  It keeps
indicating a value appropriate for the amount of time the system has
been what passes for up.

        When I posted this message last week, I mainly asked where I
should be looking to solve a problem like this, and my question still
remains although I have found out a few more things since then.

        One of the local Linux group folks I talked to said that he
had had similar problems and had gone back to an earlier kernel but
that 2.2.13 had a security problem of some kind.  I certainly hope
that I am not perpetually bound to an old kernel for this otherwise
great system.

        How often does the jiffy clock overflow under normal
conditions?  The person who told me about it wasn't sure but thought
it was several weeks and that the kernel boot procedure simply set it
to a value that was about 10 minutes worth of ticks below the maximum
value so that one would find out what happened sooner rather than
later.:-)  What is the granularity of this clock or how many times per
second does it get updated?

Martin McCormick WB5AGZ  Stillwater, OK
OSU Center for Computing and Information Services Data Communications Group

2. Set Environment Variable for Postgres?

3. Python's flying, Monty....it's not a circus!

4. Esy. Question #

5. Fun fun fun! :)

6. KSH: Help sought getting wrapper code to work in set-uid mode

7. fun, fun fun

8. IBM EtherJet ISA NIC

9. KIllustrator: fun, fun, fun.

10. For fun, it's time for a nostalgia thread...

11. It's not all about up-time (or: Time for some marketing?)

12. getting IP-Filter to reread it's configuration-files 'on-the-fly'

13. help: not detecting network card, can't find 3c509b at boot time (not P&P )