I think the fix first appears in 6.0 (I happened to be the one who fixed it). We now use a 64-bit millisecond counter. Not sure how many years that is offhand, but I think we're ok for a while. Brian -- your quoted mail msg below is the text of the bug report :-).
Thanks!!
Steve
-----Original Message----- From: Brian Tao [mailto:taob@risc.org] Sent: Monday, October 09, 2000 9:53 PM To: toasters@mathworks.com Cc: Yoder, Alan Subject: RE: 32-bit uptime counter?
On Wed, 19 May 1999, Yoder, Alan wrote:
[Guy Harris writes]...
[Brian Tao writes]...
Still running good ol' 4.2a on an F230:Sun Apr 18 21:00:00 EDT [statd]: 9:00pm up 497 days,
1:10 407777519 NFS ops, 0 CIFS ops, 0 HTTP ops
Sun Apr 18 22:00:00 EDT [statd]: 10:00pm up 497 days,
2:10 408458997 NFS ops, 0 CIFS ops, 0 HTTP ops
Sun Apr 18 23:00:00 EDT [statd]: 11:00pm up 42 mins,
409036765 NFS ops, 0 CIFS ops, 0 HTTP ops
Mon Apr 19 00:00:00 EDT [statd]: 12:00am up 1:42
409494263 NFS ops, 0 CIFS ops, 0 HTTP ops
This looks like 2^32 ticks elapsed (about 42949673seconds)...
Yes, the tick counter is 32 bits in 4.2a:
tooting$ egrep sk_tics ../sk/*.h ../sk/sk.h:extern VOLATILE int4 sk_tics; /* number of ticks since boot */
is this one of the counters being increased to 64 bits?
It's not been increased in size yet; I don't know if it's
one of the
ones we plan to boost in size.
It is now.
Say, which release was the change incorporated? I'm gettin' tiredof seeing my uptime counters roll. ;-)
| Sun Oct 1 00:00:01 EDT [asup_main]: System Notification mail sent | Sun Oct 1 01:00:00 EDT [statd]: 1:00am up 496 days, 16:35 1845869853 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 01:00:00 EDT [raid_scrub_admin]: Beginning disk scrubbing... | Sun Oct 1 02:01:03 EDT [statd]: 2:01am up 496 days, 17:35 1846202045 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 03:00:32 EDT [consumer]: Scrub found 0 parity inconsistencies | Sun Oct 1 03:00:32 EDT [consumer]: Scrub found 0 media errors | Sun Oct 1 03:00:32 EDT [consumer]: Disk scrubbing finished... | Sun Oct 1 03:00:42 EDT [statd]: 3:00am up 496 days, 18:34 1846455096 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 04:00:00 EDT [statd]: 4:00am up 496 days, 19:33 1846520843 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 05:00:00 EDT [statd]: 5:00am up 496 days, 20:34 1846581690 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 06:00:00 EDT [statd]: 6:00am up 496 days, 21:34 1846983917 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 07:00:01 EDT [statd]: 7:00am up 496 days, 22:34 1847368872 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 08:00:00 EDT [statd]: 8:00am up 496 days, 23:33 1847430632 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 09:00:00 EDT [statd]: 9:00am up 497 days, 34 mins, 1847493449 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 10:00:00 EDT [statd]: 10:00am up 497 days, 1:34 1847553879 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 11:00:00 EDT [statd]: 11:00am up 6 mins, 1847633991 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 12:00:00 EDT [statd]: 12:00pm up 1:06 1847697785 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 13:00:00 EDT [statd]: 1:00pm up 2:06 1847760829 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 14:00:00 EDT [statd]: 2:00pm up 3:06 1847824644 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 15:00:00 EDT [statd]: 3:00pm up 4:06 1847886612 NFS ops, 0 CIFS ops, 0 HTTP ops
-- Brian Tao (BT300, taob@risc.org) "Though this be madness, yet there is method in't"
-
Strange, Steve