Date: Tue, 04 Jan 2000 15:12:55 +0800 From: Peter Wemm <peter@netplex.com.au> To: mjacob@feral.com Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/dec mcclock.c Message-ID: <20000104071255.D2B501CC6@overcee.netplex.com.au> In-Reply-To: Message from Matthew Jacob <mjacob@feral.com> of "Mon, 03 Jan 2000 22:31:02 PST." <Pine.BSF.4.10.10001032228380.3517-100000@beppo.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Jacob wrote: > > The reason I didn't do it this way is that there are cases where OSF/1 and > ARC usages of the TOY chip leave it with a date readable with what you > have below, but completely wrong. I always can tell when I've been running > NT because the date is 2021. That's why I specifically selected a 10 year > window. Err what? If you boot NT, it sets the year to "21" instead of "00"? If so, that's bizzare.. :-/ > If you think there's something else going on, let me know. No, I was just pointing out that on the i386 family (which have a RTC which is derived from this device), we completely ignore the century byte which is in cmos ram, not an actual register. If the year value is < 70, we use 2000-2069 but if it's >= 70 then we use 1970 - 1999. Aside from leap year issues, FreeBSD/i386 is y2k compliant on hardware that doesn't roll over properly (providing the bios doesn't reset "00" to "80" like some do). (In the code below, USE_RTC_CENTURY is never defined) Hmm, it looks like we have another 'prior art' to shoot down the y2k windowing patent. We've used the 1970 window since at least as far back as 1994. It was "intented" and patented in Feb 1995: http://www.washingtonpost.com/wp-srv/WPlate/1999-12/17/081l-121799-idx.html > -matt > > > > On Tue, 4 Jan 2000, Peter Wemm wrote: > > > Matt Jacob wrote: > > > mjacob 2000/01/03 19:22:06 PST > > > > > > Modified files: > > > sys/dev/dec mcclock.c > > > Log: > > > Ho, ho, ho... this clock chip is not y2k compliant. Motorola > > > has it blacklisted. Silly us for not planning ahead. Tsk. Anyway- > > > a 10 year window patch is probably sufficient to still detect > > > nonsense in the clock but allow us to roll past the year 2000. > > > > Umm, this is the same chip that the PC rtc is based on: > > #define MC_YEAR 0x9 /* Time of year: year in century (0-99) */ > > > > On the PC side of things we use an 70 year window. < 70 = 2000-2069 > > and >= 70 = 1970-1999. > > #ifdef USE_RTC_CENTURY > > year = readrtc(RTC_YEAR) + readrtc(RTC_CENTURY) * 100; > > #else > > year = readrtc(RTC_YEAR) + 1900; > > if (year < 1970) > > year += 100; > > #endif > > if (year < 1970) { > > splx(s); > > goto wrong_time; > > } > > > > The alpha equivalent of this code is in alpha/alpha/clock.c (inittodr), whi ch > > doesn't look quite right... > > > > Cheers, > > -Peter > > > > > Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000104071255.D2B501CC6>