Rev | Author | # | Line |
---|---|---|---|
2 | IanMcDonald | 1 | <verbatim> |
1 | perry | 2 | NAME |
2 | IanMcDonald | 3 | hwclock - query and set the hardware clock (RTC) |
4 | |||
1 | perry | 5 | SYNOPSIS |
2 | IanMcDonald | 6 | hwclock -r or hwclock --show |
7 | hwclock -w or hwclock --systohc | ||
8 | hwclock -s or hwclock --hctosys | ||
9 | hwclock -a or hwclock --adjust | ||
10 | hwclock -v or hwclock --version | ||
11 | hwclock --set --date=newdate | ||
12 | hwclock --getepoch | ||
13 | hwclock --setepoch --epoch=year | ||
1 | perry | 14 | |
2 | IanMcDonald | 15 | other options: |
1 | perry | 16 | |
2 | IanMcDonald | 17 | [-u|--utc] --localtime --noadjfile --directisa --test [-D|--debug] |
18 | --rtc=filename | ||
1 | perry | 19 | |
2 | IanMcDonald | 20 | and arcane options for DEC Alpha: |
1 | perry | 21 | |
2 | IanMcDonald | 22 | [-A|--arc] [-J|--jensen] [-S|--srm] [-F|--funky-toy] |
1 | perry | 23 | |
2 | IanMcDonald | 24 | Minimum unique abbreviations of all options are acceptable. |
1 | perry | 25 | |
2 | IanMcDonald | 26 | Also, -h asks for a help message. |
1 | perry | 27 | |
28 | |||
2 | IanMcDonald | 29 | DESCRIPTION |
30 | hwclock is a tool for accessing the Hardware Clock. You can display | ||
31 | the current time, set the Hardware Clock to a specified time, set the | ||
32 | Hardware Clock to the System Time, and set the System Time from the | ||
33 | Hardware Clock. | ||
1 | perry | 34 | |
2 | IanMcDonald | 35 | You can also run hwclock periodically to insert or remove time from the |
36 | Hardware Clock to compensate for systematic drift (where the clock con‐ | ||
37 | sistently gains or loses time at a certain rate if left to run). | ||
1 | perry | 38 | |
39 | |||
2 | IanMcDonald | 40 | OPTIONS |
41 | You need exactly one of the following options to tell hwclock what | ||
42 | function to perform: | ||
1 | perry | 43 | |
44 | |||
2 | IanMcDonald | 45 | --show Read the Hardware Clock and print the time on Standard Output. |
46 | The time shown is always in local time, even if you keep your | ||
47 | Hardware Clock in Coordinated Universal Time. See the --utc | ||
48 | option. | ||
1 | perry | 49 | |
50 | |||
2 | IanMcDonald | 51 | --set Set the Hardware Clock to the time given by the --date option. |
1 | perry | 52 | |
2 | IanMcDonald | 53 | --hctosys |
54 | Set the System Time from the Hardware Clock. | ||
1 | perry | 55 | |
2 | IanMcDonald | 56 | Also set the kernel’s timezone value to the local timezone as |
57 | indicated by the TZ environment variable and/or /usr/share/zone‐ | ||
58 | info, as tzset(3) would interpret them. The obsolete tz_dsttime | ||
59 | field of the kernel’s timezone value is set to DST_NONE. (For | ||
60 | details on what this field used to mean, see settimeofday(2).) | ||
1 | perry | 61 | |
2 | IanMcDonald | 62 | This is a good option to use in one of the system startup |
63 | scripts. | ||
1 | perry | 64 | |
2 | IanMcDonald | 65 | --systohc |
66 | Set the Hardware Clock to the current System Time. | ||
1 | perry | 67 | |
2 | IanMcDonald | 68 | --adjust |
69 | Add or subtract time from the Hardware Clock to account for sys‐ | ||
70 | tematic drift since the last time the clock was set or adjusted. | ||
71 | See discussion below. | ||
1 | perry | 72 | |
2 | IanMcDonald | 73 | --getepoch |
74 | Print the kernel’s Hardware Clock epoch value to standard out‐ | ||
75 | put. This is the number of years into AD to which a zero year | ||
76 | value in the Hardware Clock refers. For example, if you are | ||
77 | using the convention that the year counter in your Hardware | ||
78 | Clock contains the number of full years since 1952, then the | ||
79 | kernel’s Hardware Counter epoch value must be 1952. | ||
1 | perry | 80 | |
2 | IanMcDonald | 81 | This epoch value is used whenever hwclock reads or sets the |
82 | Hardware Clock. | ||
1 | perry | 83 | |
2 | IanMcDonald | 84 | --setepoch |
85 | Set the kernel’s Hardware Clock epoch value to the value speci‐ | ||
86 | fied by the --epoch option. See the --getepoch option for | ||
87 | details. | ||
1 | perry | 88 | |
2 | IanMcDonald | 89 | --version |
90 | Print the version of hwclock on Standard Output. | ||
1 | perry | 91 | |
2 | IanMcDonald | 92 | --date=date_string |
93 | You need this option if you specify the --set option. Other‐ | ||
94 | wise, it is ignored. This specifies the time to which to set | ||
95 | the Hardware Clock. The value of this option is an argument to | ||
96 | the date(1) program. For example, | ||
1 | perry | 97 | |
2 | IanMcDonald | 98 | hwclock --set --date="9/22/96 16:45:05" |
1 | perry | 99 | |
2 | IanMcDonald | 100 | The argument is in local time, even if you keep your Hardware |
101 | Clock in Coordinated Universal time. See the --utc option. | ||
1 | perry | 102 | |
103 | |||
2 | IanMcDonald | 104 | --epoch=year |
105 | Specifies the year which is the beginning of the Hardware | ||
106 | Clock’s epoch. I.e. the number of years into AD to which a zero | ||
107 | value in the Hardware Clock’s year counter refers. It is used | ||
108 | together with the --setepoch option to set the kernel’s idea of | ||
109 | the epoch of the Hardware Clock, or otherwise to specify the | ||
110 | epoch for use with direct ISA access. | ||
1 | perry | 111 | |
2 | IanMcDonald | 112 | For example, on a Digital Unix machine: |
1 | perry | 113 | |
2 | IanMcDonald | 114 | hwclock --setepoch --epoch=1952 |
1 | perry | 115 | |
116 | |||
2 | IanMcDonald | 117 | The following options apply to most functions. |
1 | perry | 118 | |
2 | IanMcDonald | 119 | --utc |
1 | perry | 120 | |
2 | IanMcDonald | 121 | --localtime |
122 | Indicates that the Hardware Clock is kept in Coordinated Univer‐ | ||
123 | sal Time or local time, respectively. It is your choice whether | ||
124 | to keep your clock in UTC or local time, but nothing in the | ||
125 | clock tells which you’ve chosen. So this option is how you give | ||
126 | that information to hwclock. | ||
1 | perry | 127 | |
2 | IanMcDonald | 128 | If you specify the wrong one of these options (or specify nei‐ |
129 | ther and take a wrong default), both setting and querying of the | ||
130 | Hardware Clock will be messed up. | ||
1 | perry | 131 | |
2 | IanMcDonald | 132 | If you specify neither --utc nor --localtime , the default is |
133 | whichever was specified the last time hwclock was used to set | ||
134 | the clock (i.e. hwclock was successfully run with the --set , | ||
135 | --systohc , or --adjust options), as recorded in the adjtime | ||
136 | file. If the adjtime file doesn’t exist, the default is local | ||
137 | time. | ||
1 | perry | 138 | |
139 | |||
2 | IanMcDonald | 140 | --noadjfile |
141 | disables the facilities provided by /etc/adjtime. hwclock will | ||
142 | not read nor write to that file with this option. Either --utc | ||
143 | or --localtime must be specified when using this option. | ||
1 | perry | 144 | |
145 | |||
2 | IanMcDonald | 146 | --rtc=filename |
147 | overrides the default /dev file name, which is /dev/rtc on many | ||
148 | platforms but may be /dev/rtc0, /dev/rtc1, and so on. | ||
1 | perry | 149 | |
150 | |||
2 | IanMcDonald | 151 | --directisa |
152 | is meaningful only on an ISA machine or an Alpha (which imple‐ | ||
153 | ments enough of ISA to be, roughly speaking, an ISA machine for | ||
154 | hwclock’s purposes). For other machines, it has no effect. | ||
155 | This option tells hwclock to use explicit I/O instructions to | ||
156 | access the Hardware Clock. Without this option, hwclock will | ||
157 | try to use the /dev/rtc device (which it assumes to be driven by | ||
158 | the rtc device driver). If it is unable to open the device (for | ||
159 | read), it will use the explicit I/O instructions anyway. | ||
1 | perry | 160 | |
2 | IanMcDonald | 161 | The rtc device driver was new in Linux Release 2. |
1 | perry | 162 | |
2 | IanMcDonald | 163 | --badyear |
164 | Indicates that the Hardware Clock is incapable of storing years | ||
165 | outside the range 1994-1999. There is a problem in some BIOSes | ||
166 | (almost all Award BIOSes made between 4/26/94 and 5/31/95) | ||
167 | wherein they are unable to deal with years after 1999. If one | ||
168 | attempts to set the year-of-century value to something less than | ||
169 | 94 (or 95 in some cases), the value that actually gets set is 94 | ||
170 | (or 95). Thus, if you have one of these machines, hwclock can‐ | ||
171 | not set the year after 1999 and cannot use the value of the | ||
172 | clock as the true time in the normal way. | ||
1 | perry | 173 | |
2 | IanMcDonald | 174 | To compensate for this (without your getting a BIOS update, |
175 | which would definitely be preferable), always use --badyear if | ||
176 | you have one of these machines. When hwclock knows it’s working | ||
177 | with a brain-damaged clock, it ignores the year part of the | ||
178 | Hardware Clock value and instead tries to guess the year based | ||
179 | on the last calibrated date in the adjtime file, by assuming | ||
180 | that that date is within the past year. For this to work, you | ||
181 | had better do a hwclock --set or hwclock --systohc at least once | ||
182 | a year! | ||
1 | perry | 183 | |
2 | IanMcDonald | 184 | Though hwclock ignores the year value when it reads the Hardware |
185 | Clock, it sets the year value when it sets the clock. It sets | ||
186 | it to 1995, 1996, 1997, or 1998, whichever one has the same | ||
187 | position in the leap year cycle as the true year. That way, the | ||
188 | Hardware Clock inserts leap days where they belong. Again, if | ||
189 | you let the Hardware Clock run for more than a year without set‐ | ||
190 | ting it, this scheme could be defeated and you could end up los‐ | ||
191 | ing a day. | ||
1 | perry | 192 | |
2 | IanMcDonald | 193 | hwclock warns you that you probably need --badyear whenever it |
194 | finds your Hardware Clock set to 1994 or 1995. | ||
1 | perry | 195 | |
196 | |||
2 | IanMcDonald | 197 | --srm This option is equivalent to --epoch=1900 and is used to specify |
198 | the most common epoch on Alphas with SRM console. | ||
1 | perry | 199 | |
2 | IanMcDonald | 200 | --arc This option is equivalent to --epoch=1980 and is used to specify |
201 | the most common epoch on Alphas with ARC console (but Ruffians | ||
202 | have epoch 1900). | ||
1 | perry | 203 | |
2 | IanMcDonald | 204 | --jensen |
1 | perry | 205 | |
2 | IanMcDonald | 206 | --funky-toy |
207 | These two options specify what kind of Alpha machine you have. | ||
208 | They are invalid if you don’t have an Alpha and are usually | ||
209 | unnecessary if you do, because hwclock should be able to deter‐ | ||
210 | mine by itself what it’s running on, at least when /proc is | ||
211 | mounted. (If you find you need one of these options to make | ||
212 | hwclock work, contact the maintainer to see if the program can | ||
213 | be improved to detect your system automatically. Output of | ||
214 | ‘hwclock --debug’ and ‘cat /proc/cpuinfo’ may be of interest.) | ||
1 | perry | 215 | |
2 | IanMcDonald | 216 | --jensen means you are running on a Jensen model. |
1 | perry | 217 | |
2 | IanMcDonald | 218 | --funky-toy means that on your machine, one has to use the UF |
219 | bit instead of the UIP bit in the Hardware Clock to detect a | ||
220 | time transition. "Toy" in the option name refers to the Time Of | ||
221 | Year facility of the machine. | ||
1 | perry | 222 | |
223 | |||
224 | |||
2 | IanMcDonald | 225 | --test Do everything except actually updating the Hardware Clock or |
226 | anything else. This is useful, especially in conjunction with | ||
227 | --debug, in learning about hwclock. | ||
1 | perry | 228 | |
2 | IanMcDonald | 229 | --debug |
230 | Display a lot of information about what hwclock is doing inter‐ | ||
231 | nally. Some of its function is complex and this output can help | ||
232 | you understand how the program works. | ||
1 | perry | 233 | |
234 | |||
235 | |||
2 | IanMcDonald | 236 | NOTES |
237 | Clocks in a Linux System | ||
238 | There are two main clocks in a Linux system: | ||
1 | perry | 239 | |
2 | IanMcDonald | 240 | The Hardware Clock: This is a clock that runs independently of any con‐ |
241 | trol program running in the CPU and even when the machine is powered | ||
242 | off. | ||
1 | perry | 243 | |
2 | IanMcDonald | 244 | On an ISA system, this clock is specified as part of the ISA standard. |
245 | The control program can read or set this clock to a whole second, but | ||
246 | the control program can also detect the edges of the 1 second clock | ||
247 | ticks, so the clock actually has virtually infinite precision. | ||
1 | perry | 248 | |
2 | IanMcDonald | 249 | This clock is commonly called the hardware clock, the real time clock, |
250 | the RTC, the BIOS clock, and the CMOS clock. Hardware Clock, in its | ||
251 | capitalized form, was coined for use by hwclock because all of the | ||
252 | other names are inappropriate to the point of being misleading. | ||
1 | perry | 253 | |
2 | IanMcDonald | 254 | So for example, some non-ISA systems have a few real time clocks with |
255 | only one of them having its own power domain. A very low power exter‐ | ||
256 | nal I2C or SPI clock chip might be used with a backup battery as the | ||
257 | hardware clock to initialize a more functional integrated real-time | ||
258 | clock which is used for most other purposes. | ||
1 | perry | 259 | |
2 | IanMcDonald | 260 | The System Time: This is the time kept by a clock inside the Linux ker‐ |
261 | nel and driven by a timer interrupt. (On an ISA machine, the timer | ||
262 | interrupt is part of the ISA standard). It has meaning only while | ||
263 | Linux is running on the machine. The System Time is the number of sec‐ | ||
264 | onds since 00:00:00 January 1, 1970 UTC (or more succinctly, the number | ||
265 | of seconds since 1969). The System Time is not an integer, though. It | ||
266 | has virtually infinite precision. | ||
1 | perry | 267 | |
2 | IanMcDonald | 268 | The System Time is the time that matters. The Hardware Clock’s basic |
269 | purpose in a Linux system is to keep time when Linux is not running. | ||
270 | You initialize the System Time to the time from the Hardware Clock when | ||
271 | Linux starts up, and then never use the Hardware Clock again. Note | ||
272 | that in DOS, for which ISA was designed, the Hardware Clock is the only | ||
273 | real time clock. | ||
1 | perry | 274 | |
2 | IanMcDonald | 275 | It is important that the System Time not have any discontinuities such |
276 | as would happen if you used the date(1L) program to set it while the | ||
277 | system is running. You can, however, do whatever you want to the Hard‐ | ||
278 | ware Clock while the system is running, and the next time Linux starts | ||
279 | up, it will do so with the adjusted time from the Hardware Clock. You | ||
280 | can also use the program adjtimex(8) to smoothly adjust the System Time | ||
281 | while the system runs. | ||
1 | perry | 282 | |
2 | IanMcDonald | 283 | A Linux kernel maintains a concept of a local timezone for the system. |
284 | But don’t be misled -- almost nobody cares what timezone the kernel | ||
285 | thinks it is in. Instead, programs that care about the timezone (per‐ | ||
286 | haps because they want to display a local time for you) almost always | ||
287 | use a more traditional method of determining the timezone: They use the | ||
288 | TZ environment variable and/or the /usr/share/zoneinfo directory, as | ||
289 | explained in the man page for tzset(3). However, some programs and | ||
290 | fringe parts of the Linux kernel such as filesystems use the kernel | ||
291 | timezone value. An example is the vfat filesystem. If the kernel | ||
292 | timezone value is wrong, the vfat filesystem will report and set the | ||
293 | wrong timestamps on files. | ||
1 | perry | 294 | |
2 | IanMcDonald | 295 | hwclock sets the kernel timezone to the value indicated by TZ and/or |
296 | /usr/share/zoneinfo when you set the System Time using the --hctosys | ||
297 | option. | ||
1 | perry | 298 | |
2 | IanMcDonald | 299 | The timezone value actually consists of two parts: 1) a field tz_min‐ |
300 | uteswest indicating how many minutes local time (not adjusted for DST) | ||
301 | lags behind UTC, and 2) a field tz_dsttime indicating the type of Day‐ | ||
302 | light Savings Time (DST) convention that is in effect in the locality | ||
303 | at the present time. This second field is not used under Linux and is | ||
304 | always zero. (See also settimeofday(2).) | ||
1 | perry | 305 | |
306 | |||
2 | IanMcDonald | 307 | How hwclock Accesses the Hardware Clock |
308 | hwclock Uses many different ways to get and set Hardware Clock values. | ||
309 | The most normal way is to do I/O to the device special file /dev/rtc, | ||
310 | which is presumed to be driven by the rtc device driver. However, this | ||
311 | method is not always available. For one thing, the rtc driver is a | ||
312 | relatively recent addition to Linux. Older systems don’t have it. | ||
313 | Also, though there are versions of the rtc driver that work on DEC | ||
314 | Alphas, there appear to be plenty of Alphas on which the rtc driver | ||
315 | does not work (a common symptom is hwclock hanging). Moreover, recent | ||
316 | Linux systems have more generic support for RTCs, even systems that | ||
317 | have more than one, so you might need to override the default by speci‐ | ||
318 | fying /dev/rtc0 or /dev/rtc1 instead. | ||
1 | perry | 319 | |
2 | IanMcDonald | 320 | On older systems, the method of accessing the Hardware Clock depends on |
321 | the system hardware. | ||
1 | perry | 322 | |
2 | IanMcDonald | 323 | On an ISA system, hwclock can directly access the "CMOS memory" regis‐ |
324 | ters that constitute the clock, by doing I/O to Ports 0x70 and 0x71. | ||
325 | It does this with actual I/O instructions and consequently can only do | ||
326 | it if running with superuser effective userid. (In the case of a | ||
327 | Jensen Alpha, there is no way for hwclock to execute those I/O | ||
328 | instructions, and so it uses instead the /dev/port device special file, | ||
329 | which provides almost as low-level an interface to the I/O subsystem). | ||
1 | perry | 330 | |
2 | IanMcDonald | 331 | This is a really poor method of accessing the clock, for all the rea‐ |
332 | sons that user space programs are generally not supposed to do direct | ||
333 | I/O and disable interrupts. Hwclock provides it because it is the only | ||
334 | method available on ISA and Alpha systems which don’t have working rtc | ||
335 | device drivers available. | ||
1 | perry | 336 | |
337 | |||
2 | IanMcDonald | 338 | On an m68k system, hwclock can access the clock via the console driver, |
339 | via the device special file /dev/tty1. | ||
1 | perry | 340 | |
2 | IanMcDonald | 341 | hwclock tries to use /dev/rtc. If it is compiled for a kernel that |
342 | doesn’t have that function or it is unable to open /dev/rtc (or the | ||
343 | alternative special file you’ve defined on the command line) hwclock | ||
344 | will fall back to another method, if available. On an ISA or Alpha | ||
345 | machine, you can force hwclock to use the direct manipulation of the | ||
346 | CMOS registers without even trying /dev/rtc by specifying the --direc‐ | ||
347 | tisa option. | ||
1 | perry | 348 | |
349 | |||
350 | |||
2 | IanMcDonald | 351 | The Adjust Function |
352 | The Hardware Clock is usually not very accurate. However, much of its | ||
353 | inaccuracy is completely predictable - it gains or loses the same | ||
354 | amount of time every day. This is called systematic drift. hwclock’s | ||
355 | "adjust" function lets you make systematic corrections to correct the | ||
356 | systematic drift. | ||
1 | perry | 357 | |
2 | IanMcDonald | 358 | It works like this: hwclock keeps a file, /etc/adjtime, that keeps some |
359 | historical information. This is called the adjtime file. | ||
1 | perry | 360 | |
2 | IanMcDonald | 361 | Suppose you start with no adjtime file. You issue a hwclock --set com‐ |
362 | mand to set the Hardware Clock to the true current time. Hwclock cre‐ | ||
363 | ates the adjtime file and records in it the current time as the last | ||
364 | time the clock was calibrated. 5 days later, the clock has gained 10 | ||
365 | seconds, so you issue another hwclock --set command to set it back 10 | ||
366 | seconds. Hwclock updates the adjtime file to show the current time as | ||
367 | the last time the clock was calibrated, and records 2 seconds per day | ||
368 | as the systematic drift rate. 24 hours go by, and then you issue a | ||
369 | hwclock --adjust command. Hwclock consults the adjtime file and sees | ||
370 | that the clock gains 2 seconds per day when left alone and that it has | ||
371 | been left alone for exactly one day. So it subtracts 2 seconds from | ||
372 | the Hardware Clock. It then records the current time as the last time | ||
373 | the clock was adjusted. Another 24 hours goes by and you issue another | ||
374 | hwclock --adjust. Hwclock does the same thing: subtracts 2 seconds and | ||
375 | updates the adjtime file with the current time as the last time the | ||
376 | clock was adjusted. | ||
1 | perry | 377 | |
2 | IanMcDonald | 378 | Every time you calibrate (set) the clock (using --set or --systohc ), |
379 | hwclock recalculates the systematic drift rate based on how long it has | ||
380 | been since the last calibration, how long it has been since the last | ||
381 | adjustment, what drift rate was assumed in any intervening adjustments, | ||
382 | and the amount by which the clock is presently off. | ||
1 | perry | 383 | |
2 | IanMcDonald | 384 | A small amount of error creeps in any time hwclock sets the clock, so |
385 | it refrains from making an adjustment that would be less than 1 second. | ||
386 | Later on, when you request an adjustment again, the accumulated drift | ||
387 | will be more than a second and hwclock will do the adjustment then. | ||
1 | perry | 388 | |
2 | IanMcDonald | 389 | It is good to do a hwclock --adjust just before the hwclock --hctosys |
390 | at system startup time, and maybe periodically while the system is run‐ | ||
391 | ning via cron. | ||
1 | perry | 392 | |
2 | IanMcDonald | 393 | The adjtime file, while named for its historical purpose of controlling |
394 | adjustments only, actually contains other information for use by | ||
395 | hwclock in remembering information from one invocation to the next. | ||
1 | perry | 396 | |
2 | IanMcDonald | 397 | The format of the adjtime file is, in ASCII: |
1 | perry | 398 | |
2 | IanMcDonald | 399 | Line 1: 3 numbers, separated by blanks: 1) systematic drift rate in |
400 | seconds per day, floating point decimal; 2) Resulting number of seconds | ||
401 | since 1969 UTC of most recent adjustment or calibration, decimal inte‐ | ||
402 | ger; 3) zero (for compatibility with clock(8)) as a decimal integer. | ||
1 | perry | 403 | |
2 | IanMcDonald | 404 | Line 2: 1 number: Resulting number of seconds since 1969 UTC of most |
405 | recent calibration. Zero if there has been no calibration yet or it is | ||
406 | known that any previous calibration is moot (for example, because the | ||
407 | Hardware Clock has been found, since that calibration, not to contain a | ||
408 | valid time). This is a decimal integer. | ||
1 | perry | 409 | |
2 | IanMcDonald | 410 | Line 3: "UTC" or "LOCAL". Tells whether the Hardware Clock is set to |
411 | Coordinated Universal Time or local time. You can always override this | ||
412 | value with options on the hwclock command line. | ||
1 | perry | 413 | |
2 | IanMcDonald | 414 | You can use an adjtime file that was previously used with the clock(8) |
415 | program with hwclock. | ||
1 | perry | 416 | |
417 | |||
418 | |||
2 | IanMcDonald | 419 | Automatic Hardware Clock Synchronization By the Kernel |
420 | You should be aware of another way that the Hardware Clock is kept syn‐ | ||
421 | chronized in some systems. The Linux kernel has a mode wherein it | ||
422 | copies the System Time to the Hardware Clock every 11 minutes. This is | ||
423 | a good mode to use when you are using something sophisticated like ntp | ||
424 | to keep your System Time synchronized. (ntp is a way to keep your Sys‐ | ||
425 | tem Time synchronized either to a time server somewhere on the network | ||
426 | or to a radio clock hooked up to your system. See RFC 1305). | ||
1 | perry | 427 | |
2 | IanMcDonald | 428 | This mode (we’ll call it "11 minute mode") is off until something turns |
429 | it on. The ntp daemon xntpd is one thing that turns it on. You can | ||
430 | turn it off by running anything, including hwclock --hctosys, that sets | ||
431 | the System Time the old fashioned way. | ||
1 | perry | 432 | |
2 | IanMcDonald | 433 | To see if it is on or off, use the command adjtimex --print and look at |
434 | the value of "status". If the "64" bit of this number (expressed in | ||
435 | binary) equal to 0, 11 minute mode is on. Otherwise, it is off. | ||
1 | perry | 436 | |
2 | IanMcDonald | 437 | If your system runs with 11 minute mode on, don’t use hwclock --adjust |
438 | or hwclock --hctosys. You’ll just make a mess. It is acceptable to | ||
439 | use a hwclock --hctosys at startup time to get a reasonable System Time | ||
440 | until your system is able to set the System Time from the external | ||
441 | source and start 11 minute mode. | ||
1 | perry | 442 | |
443 | |||
444 | |||
2 | IanMcDonald | 445 | ISA Hardware Clock Century value |
446 | There is some sort of standard that defines CMOS memory Byte 50 on an | ||
447 | ISA machine as an indicator of what century it is. hwclock does not | ||
448 | use or set that byte because there are some machines that don’t define | ||
449 | the byte that way, and it really isn’t necessary anyway, since the | ||
450 | year-of-century does a good job of implying which century it is. | ||
1 | perry | 451 | |
2 | IanMcDonald | 452 | If you have a bona fide use for a CMOS century byte, contact the |
453 | hwclock maintainer; an option may be appropriate. | ||
1 | perry | 454 | |
2 | IanMcDonald | 455 | Note that this section is only relevant when you are using the "direct |
456 | ISA" method of accessing the Hardware Clock. ACPI provides a standard | ||
457 | way to access century values, when they are supported by the hardware. | ||
1 | perry | 458 | |
459 | |||
2 | IanMcDonald | 460 | ENVIRONMENT VARIABLES |
461 | TZ | ||
1 | perry | 462 | |
463 | |||
2 | IanMcDonald | 464 | FILES |
465 | /etc/adjtime /usr/share/zoneinfo/ /dev/rtc /dev/rtc0 /dev/port | ||
466 | /dev/tty1 /proc/cpuinfo | ||
1 | perry | 467 | |
468 | |||
2 | IanMcDonald | 469 | SEE ALSO |
470 | </verbatim> | ||
471 | <pre> | ||
472 | [adjtimex(8)], [date(1)], [gettimeofday(2)], [settimeofday(2)], [crontab(1)], | ||
473 | [tzset(3)] /etc/init.d/hwclock.sh, /usr/share/doc/util- | ||
474 | linux/README.Debian.hwclock | ||
475 | </pre> | ||
476 | <verbatim> | ||
1 | perry | 477 | |
2 | IanMcDonald | 478 | AUTHORS |
479 | Written by Bryan Henderson, September 1996 (bryanh@giraffe-data.com), | ||
480 | based on work done on the clock program by Charles Hedrick, Rob Hooft, | ||
481 | and Harald Koenig. See the source code for complete history and cred‐ | ||
482 | its. | ||
1 | perry | 483 | |
484 | |||
2 | IanMcDonald | 485 | AVAILABILITY |
486 | The hwclock command is part of the util-linux-ng package and is avail‐ | ||
487 | able from ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/. | ||
488 | </verbatim> |
lib/blame.php:177: Warning: Invalid argument supplied for foreach() (...repeated 17 times)