Date: Wed, 2 Dec 1998 15:41:53 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Jim Bryant <jbryant@unix.tfs.net> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Year 2k and PC hardware Message-ID: <Pine.BSF.3.96.981202154058.5892B-100000@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
(resend because of an incorrect address -- hope you don't mind two copies, Jim :-) On Wed, 2 Dec 1998, Jim Bryant wrote: > In reply: > > Having recently visited the web pages of a number of the hardware vendors > > of machines I run FreeBSD on, I am a little concerned about some of the > > older machines. For example, Gateway 2000 refers to BIOS fixes for > > >= pentium machines that fix the bios access functions for the real time > > clock. However, they note that the fix does not apply if the OS attempts > > to access the RTC directly (I'm not sure what this means -- I don't know > > how the RTC is implemented on PC machines). Similarly, Dell suggested the > > the original ibm at, and every "compatable" rtc on the market stores > the year as a 4 digit bcd number. hardware problem solved, circa > 1984. Gateway 2000 seems to dispute this claim -- not that I necessarily believe everything they say (I'm not impressed by GW2K), I am concerned by the seeming inconsistency: http://www.gateway2000.com/frameset2.asp?s=corp&p=support&a=&url=/corp/y2k/y2k/default.html In order to understand Year 2000 testing and solutions, it is important to understand how time is maintained in the computer system. The PC system actually contains two main clocks. The real-time clock (RTC) is embedded in the CMOS chip of the motherboard. It was first implemented on the IBM AT in the early 1980s, and its design became the industry standard for AT-compatible PCs. This RTC incorporated the Motorola MC146818 chip to hold the last two digits of the year (decade and year). Century data was stored as a data point only in a separate memory section of the chip (location 32h, or later, in the PS/2, location 37h). To minimize cost and complexity, this century data was not incorporated directly into the clock functions of the RTC. Rather, the full date was, and still is, provided by combining the last two-digts of the year, which are dynamic, with the first two digits, which are stored. This is the source of the Year 2000 problem for the real-time clock. When the Year 2000 arrives, the year 99 will progress to 00, yet the century data stored in memory will still read 19. For PCs that do not incorporate date correction logic, this will yield incorrect results in the year 2000. The OS clock is the second main clock in the computer system. Unlike the RTC, most operating system clocks (and all OS clocks provided by Gateway) are capable of using four digits for the year. The operating system clock runs only when the machine is powered on, and once initialized, it runs independent of the RTC. More importantly, the OS clock is the point of truth for software applications that use or maintain the current date. The OS clock and the real-time clock are related as follows: To establish the date when the machine is first powered on, the OS clock must refer to the real-time clock. The can be done in two ways, by accessing the RTC directly, or by using BIOS interrupt 1Ah to retrieve the data. The direct approach is less efficient, since century data can be located at location 32h or 37h depending on the PC design. Accessing date information via the BIOS allows one design strategy to work with either RTC design, and for this reason, the BIOS approach became the norm in OS software design. The standard design practice for application software built on this foundation, and rather than retrieve date information from the RTC directly, software applications refer to the four-digit OS clock. Their discussion of solutions is a bit lame, unfortunately, as it suggests things like TSRs :). Their rationale, assuming that anything they have claimed above is technically accurate, however, is reasonable: Modifying the BIOS to correct Year 2000 date calculations proved to be a secure and practical solution. Because operating systems generally access date information via the BIOS, correcting the BIOS would correct the OS system clock, which in turn is the "point-of-truth" for software applications accessing current date information. In addition, unlike the RTC and CMOS hardware, the BIOS can usually be upgraded easily. Gateway PC designs since 1993 have included flash BIOS versions that provide existing clients with an easy upgrade path. As a result, the BIOS became the most common focal point for addressing the Year 2000 issue, and the approach that almost all PC vendors have used. > anyhow, freebsd does not operate in "bootstrap" mode [real mode] like > dos/winblowz does. the specified purpose of real mode is for > bootstrapping into protected mode. don't worry about the bios, unless > you use mickey mouse products from mickeysoft. I would disagree -- real mode is not even a very good bootstrap mode -- it's really just so they can claim it runs DOS. There is no good reason to boot up in a 20-bit address mode if you are just their to bootstrap to a 32-bit virtual address mode. If it were really there to be a boostrap mode, it would bootstrap to a physically addressed 32-bit address mode, and then you would bump into protected mode (and virtual addressing) later if you felt like it. Or on like on an Alpha, where the physical memory is addressable directly via a portion of the virtual address space (helps if you are 64-bit). No, real mode is just a cheap hack so that DOS could run on a 386 because there were few real operating systems available. My concern is with the GW2K statement that they claim that my RTC is going to give incorrect data to the operating system, and that they use a BIOS patch to hack in a better result because operating systems they work with use the BIOS to retrieve the RTC data. So I want to know if anyone has tested this, and whether the BIOS changes will make a difference. > > say, it appears that no one was particularly interested in how 386-class > > machines fared. > > how many still work? anyhow, see previous answer. Many 386s make very serviceable (and affordable) routers and loghosts. Of the 386 and 486 machines I have, almost every machine is in perfect working order (albeit possibly with a hard disk replacement, and a little more RAM than before) after over 6 years of continuous use. Should I get rid of my car because it happens to be a bit older? :) > > (I was also unhappy to see that my bank is not very Y2k-ready just yet :( > > ) > > find a bank that is. put your money there. any firm that hasn't > brought their systems into compliance by september 1, 1999 deserves to > lose business and/or go bankrupt. darwinean economics. I agree, and am in the process of doing that now. Only I would personally not have chosen such a poor date as Sept 1, 1999. I think any firm that isn't in compliance by *now* is not acting responsibly. :) Good thing they're training those air traffic controllers to do it all by hand, huh. :) Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.981202154058.5892B-100000>