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(a)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 42949673
> seconds)...
> > >
> > > 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' tired
> of 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(a)risc.org)
> "Though this be madness, yet there is method in't"
>