jiffies rollover, uptime etc.

jiffies rollover, uptime etc.

Post by Oliver Hillman » Wed, 20 Feb 2002 06:50:11



Hello,

yes, I know this is defenitely no new issue (maybe its none to you
anyway), since I found posts about this dating from 1998: the
jiffies counter rolls over after approx. 497 days uptime, which
causes the uptime to roll over as well, and seems to cause some
other irretation in the system itself (my pc speaker starting
beeping constantely...)

I noticed this on a couple of servers just having had 500 days of
uptime, and so I starting looking at the kernel code and played
around with a tiny jiffie manipulating kernel module. Since jiffies
is unsigned long (being 32 bits wide on x86) and counts 1/100th
seconds, it can only hold about 497 days...

This seems to be true for both 2.2 and 2.4, at least for 2.2.16 and
2.4.17, which I tested...

The uptime thingy could IMHO be solved with some kind of rollover
counter, and I'm currently digging into that area... Stuff like a pc
speaker driver going wild bothers me a bit more...

Could anybody perhaps tell me why he/she doesn't consider this a
problem? And is there a fundamental problem with solving this in
general? (I do see a problem with defining jiffies long long on x86,
because it might break a lot of things and probably wouldnt perform
as often as jiffies is touched... And you might sense I haven't
been into kernel hacking much...)

My first post here, sorry :)

Regards,

Oliver

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

jiffies rollover, uptime etc.

Post by Alan Co » Wed, 20 Feb 2002 07:00:19


Quote:> counter, and I'm currently digging into that area... Stuff like a pc
> speaker driver going wild bothers me a bit more...

Fix the speaker driver I guess is the answer. It shouldnt have done that.

Quote:> Could anybody perhaps tell me why he/she doesn't consider this a
> problem? And is there a fundamental problem with solving this in
> general? (I do see a problem with defining jiffies long long on x86,
> because it might break a lot of things and probably wouldnt perform
> as often as jiffies is touched... And you might sense I haven't
> been into kernel hacking much...)

Counting in long long is expensive and the drivers are meant to all use
roll over safe compares
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

jiffies rollover, uptime etc.

Post by Oliver Hillman » Wed, 20 Feb 2002 07:10:11



> > counter, and I'm currently digging into that area... Stuff like a pc
> > speaker driver going wild bothers me a bit more...

> Fix the speaker driver I guess is the answer. It shouldnt have done that.

Well, yeah.. So if its just the speaker driver I might sleep better
now :)

Quote:> > Could anybody perhaps tell me why he/she doesn't consider this a
> > problem? And is there a fundamental problem with solving this in
> > general? (I do see a problem with defining jiffies long long on x86,
> > because it might break a lot of things and probably wouldnt perform
> > as often as jiffies is touched... And you might sense I haven't
> > been into kernel hacking much...)

> Counting in long long is expensive and the drivers are meant to all use
> roll over safe compares

Yes, that's what I thought of, long long being too expensive. And
since jiffies doesn't seem to have a problem with rolling over, I
might try to hack the uptime-releated code a bit for myself... If
nobody isn't going like "DONT! THAT'S A VERY BAD IDEA FOR THIS AND
THIS REASON!" :)

Thanks

Oliver

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

jiffies rollover, uptime etc.

Post by Tim Schmiela » Wed, 20 Feb 2002 07:20:11



> Hello,

> yes, I know this is defenitely no new issue (maybe its none to you
> anyway), since I found posts about this dating from 1998: the
> jiffies counter rolls over after approx. 497 days uptime, which
> causes the uptime to roll over as well, and seems to cause some
> other irretation in the system itself (my pc speaker starting
> beeping constantely...)

See
http://www.lib.uaa.alaska.edu/linux-kernel/archive/2001-Week-47/0736....
for a patch.
I intend to submit this for 2.4.19pre after some more testing and
feedback.

Also note that several patches for jiffies rollover bugs have gone into
2.4.18pre, maybe one of them fixes the speaker driver.

Tim

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

jiffies rollover, uptime etc.

Post by Ben Greea » Wed, 20 Feb 2002 07:30:13



>>counter, and I'm currently digging into that area... Stuff like a pc
>>speaker driver going wild bothers me a bit more...

> Fix the speaker driver I guess is the answer. It shouldnt have done that.

>>Could anybody perhaps tell me why he/she doesn't consider this a
>>problem? And is there a fundamental problem with solving this in
>>general? (I do see a problem with defining jiffies long long on x86,
>>because it might break a lot of things and probably wouldnt perform
>>as often as jiffies is touched... And you might sense I haven't
>>been into kernel hacking much...)

> Counting in long long is expensive and the drivers are meant to all use
> roll over safe compares

I wonder, is it more expensive to write all drivers to handle the
wraps than to take the long long increment hit?  The increment is
once every 10 miliseconds, right?  That is not too often, all things
considered...

Maybe the non-atomicity of the long long increment is the problem?

Does this problem still exist on 64-bit machines?

THanks,
Ben

--

President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

jiffies rollover, uptime etc.

Post by Alan Co » Wed, 20 Feb 2002 07:40:08


Quote:> I wonder, is it more expensive to write all drivers to handle the
> wraps than to take the long long increment hit?  The increment is

Total cost of handling it right - 0 clocks. Its simply about maths order
and sign

Quote:> Maybe the non-atomicity of the long long increment is the problem?

A big one yes.

Quote:> Does this problem still exist on 64-bit machines?

Not in the same way - you'll need a lot of years before you worry about it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

jiffies rollover, uptime etc.

Post by Tim Schmiela » Wed, 20 Feb 2002 07:40:09



> I wonder, is it more expensive to write all drivers to handle the
> wraps than to take the long long increment hit?  The increment is
> once every 10 miliseconds, right?  That is not too often, all things
> considered...

This is just a matter of getting the signed/unsigned declarations right in
comparisons. (time_before and time_after macros were introduced to aid
here, hint!)
No overhead is involved here.

Actually, quite a few bug fixes in this area went into 2.4.18pre, with
some more to come in 2.4.19pre.

Quote:

> Maybe the non-atomicity of the long long increment is the problem?

Yes.

Quote:> Does this problem still exist on 64-bit machines?

No.

Quote:> THanks,
> Ben

Tim

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

jiffies rollover, uptime etc.

Post by bert huber » Wed, 20 Feb 2002 08:30:13



> > I wonder, is it more expensive to write all drivers to handle the
> > wraps than to take the long long increment hit?  The increment is

> Total cost of handling it right - 0 clocks. Its simply about maths order
> and sign

$ uname -a ; uptime
Linux newyork-1 2.2.18 #3 Mon Dec 11 15:57:33 EST 2000 i686 unknown
  6:22pm  up 425 days,  1:35,  3 users,  load average: 0.10, 0.05, 0.01

This server is pretty remote and hard to reach, and not sure to reboot
properly unattended - are there predictions about how well 2.2.18 will
survive jiffy wraparound?

Would you consider it worth rebooting for? By the way, this is our second
most important production server, I'm exceedingly pleased with the
stability. We've abused it no end.

Thanks.

Regards,

bert

--
http://www.PowerDNS.com          Versatile DNS Software & Services
http://www.tk                              the dot in .tk
Netherlabs BV / Rent-a-Nerd.nl           - Nerd Available -
Linux Advanced Routing & Traffic Control: http://ds9a.nl/lartc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

jiffies rollover, uptime etc.

Post by J Sloa » Wed, 20 Feb 2002 08:30:11


Many will be grateful if this finally allows
the correct uptime to be generated after
497 days - my busy mail/dns servers now
have 611 days uptime, but to outsiders it
appears they only have 114 days uptime,
and there are bizarre items in the process
table, e.g. programs that were apparently
started in the year 2003...

Joe



>>Hello,

>>yes, I know this is defenitely no new issue (maybe its none to you
>>anyway), since I found posts about this dating from 1998: the
>>jiffies counter rolls over after approx. 497 days uptime, which
>>causes the uptime to roll over as well, and seems to cause some
>>other irretation in the system itself (my pc speaker starting
>>beeping constantely...)

>See
>http://www.lib.uaa.alaska.edu/linux-kernel/archive/2001-Week-47/0736....
>for a patch.
>I intend to submit this for 2.4.19pre after some more testing and
>feedback.

>Also note that several patches for jiffies rollover bugs have gone into
>2.4.18pre, maybe one of them fixes the speaker driver.

>Tim

>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

jiffies rollover, uptime etc.

Post by Alan Co » Wed, 20 Feb 2002 08:50:11


Quote:> Would you consider it worth rebooting for? By the way, this is our second
> most important production server, I'm exceedingly pleased with the
> stability. We've abused it no end.

I would schedule maintenance for it at the point it wraps. Its not the most
tested code path in 2.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

jiffies rollover, uptime etc.

Post by J Sloa » Wed, 20 Feb 2002 09:00:15


FWIW our servers that wrapped around
almost 4 months ago have been running
fine, no real problems - Red Hat 6.1 with
2.2.17-pre4 kernel.

Joe



>>>I wonder, is it more expensive to write all drivers to handle the
>>>wraps than to take the long long increment hit?  The increment is

>>Total cost of handling it right - 0 clocks. Its simply about maths order
>>and sign

>$ uname -a ; uptime
>Linux newyork-1 2.2.18 #3 Mon Dec 11 15:57:33 EST 2000 i686 unknown
>  6:22pm  up 425 days,  1:35,  3 users,  load average: 0.10, 0.05, 0.01

>This server is pretty remote and hard to reach, and not sure to reboot
>properly unattended - are there predictions about how well 2.2.18 will
>survive jiffy wraparound?

>Would you consider it worth rebooting for? By the way, this is our second
>most important production server, I'm exceedingly pleased with the
>stability. We've abused it no end.

>Thanks.

>Regards,

>bert

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

jiffies rollover, uptime etc.

Post by Bill Davidse » Wed, 20 Feb 2002 09:30:10



> I wonder, is it more expensive to write all drivers to handle the
> wraps than to take the long long increment hit?  The increment is
> once every 10 miliseconds, right?  That is not too often, all things
> considered...

  If you are willing to code in assembler instead of C you can do better,
at least on x86. You just need to do a 32 bit increment on the LS word,
and if you get a carry you can incr the MS word.

Quote:> Maybe the non-atomicity of the long long increment is the problem?

  I doubt it, the problem is that the software which expects jiffies is
not all going to work well 64 bit. I think that's more the issue, and why
Alan et al are fixing it piecemeal, I don't think there's some magic fix
they're missing.

Quote:> Does this problem still exist on 64-bit machines?

Absolutely. But not as often ;-)

--

  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

jiffies rollover, uptime etc.

Post by Stephen Fros » Wed, 20 Feb 2002 10:10:07



Quote:> $ uname -a ; uptime
> Linux newyork-1 2.2.18 #3 Mon Dec 11 15:57:33 EST 2000 i686 unknown
>   6:22pm  up 425 days,  1:35,  3 users,  load average: 0.10, 0.05, 0.01

Linux ns2 2.2.16 #1 Sun Jul 30 21:57:38 EDT 2000 i386 unknown
 19:55:29 up 1 day, 15:06,  1 user,  load average: 0.00, 0.03, 0.00

-rw-r--r--    1 root     root         1569 Oct  8  2000 /var/log/dmesg

No problems here so far, just wrapped.  Processes seemed to all handle
it okay though ps now shows some things started in 2003.. :)

Quote:> This server is pretty remote and hard to reach, and not sure to reboot
> properly unattended - are there predictions about how well 2.2.18 will
> survive jiffy wraparound?

It's honestly not good to not know how to reboot a box unattended. :)

Quote:> Would you consider it worth rebooting for? By the way, this is our second
> most important production server, I'm exceedingly pleased with the
> stability. We've abused it no end.

I'd certainly make arrangements to have it rebooted if necessary.  If
rebooting is a huge problem then I'd say just have someone on hand in
case you *have* to.

        Stephen

  application_pgp-signature_part
< 1K Download
 
 
 

jiffies rollover, uptime etc.

Post by Chris Adam » Wed, 20 Feb 2002 12:00:15



Quote:>I would schedule maintenance for it at the point it wraps. Its not the most
>tested code path in 2.2

I've got a couple of servers running 2.2 that have long rolled over (one
206 days ago and the other 314 days ago) without any trouble.  Another
six months and the second one will roll over a second time.  We're
looking at moving them to a new location, and I'm trying to figure out
how to splice an UPS in the power cord. :-)
--

Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

jiffies rollover, uptime etc.

Post by Paul Jakm » Wed, 20 Feb 2002 13:50:06



> Linux ns2 2.2.16 #1 Sun Jul 30 21:57:38 EDT 2000 i386 unknown
>  19:55:29 up 1 day, 15:06,  1 user,  load average: 0.00, 0.03, 0.00

> -rw-r--r--    1 root     root         1569 Oct  8  2000 /var/log/dmesg

> No problems here so far, just wrapped.  Processes seemed to all handle
> it okay though ps now shows some things started in 2003.. :)


  4:26am  up 273 days,  1:34, 17 users,  load average: 0.15, 0.18, 0.14

ie it wrapped 273 days ago. :) 734 days. it's the standard RH 2.2.16
kernel from RH6.1.

hanvt noticed any funnies whatsoever. (except init and some other
long running procs seem to have a start time that varies whenever you
run ps, which isnt right.)

regards,
--

Fortune:
It's a recession when your neighbour loses his job; it's a depression
when you lose yours.
                -- Harry S. Truman

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. Uptime rollover, How to tell real uptime?

I have a linux system running 1.2.8  gcc 2.6.3 compiled Dec 28 95
According to the var/adm/messages file it was last booted on
Jan. 2, 1996. This would put the uptime at around 800 days.

Somewhere after 460 days the uptime counter must have rolled over
as the uptime given with "w" started again with low numbers.

I know it was not rebooted as there are daemons running that I started
by hand and are not in scripts.

Is there a way to get the real uptime?

Also I plan to shut it down soon as I am getting scared of fire
hazard due to lots of dust. The internal fan went out a year ago
and I have hung another fan on the back for cooling.

Is this maybe a record uptime??
Dale
=================================================================

Phone:(916)356-5332                     I speak only for myself
=====================================================================

2. System Performance Management: Moving from Chaos to Value

3. Kernel "jiffies" roll-over

4. 2/11 sound/oss replace cli()

5. Linux uptime rollovers.

6. Maximum FileSystem Size?

7. Red Hat 4.1 uptime rollover?

8. Sorting DF

9. How does uptime.netcraft.com know my uptime?

10. C library for linux performance system calls - netstat uptime etc

11. CDE vs. /etc/passwd, /etc/shadow and /etc/group

12. time_t and 2038 date roll-over

13. ssh chrooted enviroment WITHOUT /bin /etc /lib - etc etc in the users dir ?