janine@mbf.UUCP (Janine Rivas) (06/07/91)
I have a client who is running Xenix 2.3.2 on an Acer 1200, which is a 486 system. The system time gains several days per real day. I think that the problem is a program called /etc/setclock, which is reported missing each time he reboots. If I pull this file off of the install floppies, will this fix it? Please bear with me for a bit; y'all will be seeing lots of potentially dumb questions from me for a while. I'm fairly familiar with Unix, but I'm used to the BSD and ATT varieties, and sometimes things are just different enough in Xenix to foul me up completely! I'm trying to help the aforementioned client with a really sick system and application, and the net is my best source of "been there before" information. Thanks in advance! janine -- ...!uunet!ccicpg!mbf!janine MAI Systems has NO idea what I do! And they have nothing to do with the questions I post. #include <rest_of_std_disclaimer>
6600joef@ucsbuxa.ucsb.edu (Joe Foster) (06/11/91)
In article <91326@mbf.UUCP> janine@mbf.UUCP (Janine Rivas) writes: >I have a client who is running Xenix 2.3.2 on an Acer 1200, which is a >486 system. The system time gains several days per real day. I think >that the problem is a program called /etc/setclock, which is reported >missing each time he reboots. If I pull this file off of the install >floppies, will this fix it? Try doing a "cat /dev/clock" and comparing its output with that of "date". "/dev/clock" is the interface to the hardware real-time clock, while "date" will report the kernel's idea of the time. If they're different, then XENIX's idea of how many interrupts the system timer generates per second is likely to be screwed up. On most machines, clock ticks occur every 0.02 second. I can't seem to find a kernel tunable parameter for this, however. There is a shell variable named HZ, defined in the rc files, /.profile, and /etc/default/login. This is described in the Administrator's guide, page 19-15. I don't know if this will solve your problem, but it's worth a try. Your client could also have a device installed which is generating interrupts on the same line as the clock, causing the kernel to think more time has elapsed than it should. >janine >-- >...!uunet!ccicpg!mbf!janine Joe Foster 6600joef@ucsbuxa.ucsb.edu >MAI Systems has NO idea what I do! And they have nothing to do with the >questions I post. #include <rest_of_std_disclaimer> *I* have no idea what I do! ;-)