ilcu@icoven.olivetti.com (Daniela Papa) (05/02/88)
Every time I reboot my SUN 3/50M I get the message that the clock lost 29 days. While running the clock slows done about 10 minutes per hour, I avoid this by speeding up the clock rate ( date -annn.sss ) but having to reset the date every time I boot is a pain in the neck. Has anybody experienced this problem? Is it a hardware bug.... I tried pulling out the lithium battery and short-circuiting the electrolitic capacitor in order to reset the Intersil ICM7170 but nothing happened except that I got the message the the tod clock wasn't initialized. Any pointers.... The header isn't completely correct because I'm not in Cupertino but in Ivrea, Italy and read news through our link to Cupertino.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (05/02/88)
In article <21024@oliveb.olivetti.com> ilcu@icoven.UUCP (Daniela Papa) writes: >Every time I reboot my SUN 3/50M I get the message that the clock lost >29 days. While running the clock slows done about 10 minutes per hour My first thought was that you haven't fixed the clock bug in the Sun kernel (contact Sun for details). My next thought was that perhaps the difference between 50Hz and 60Hz power line frequency might be a factor; that's about 10 minutes per hour.
guy@gorodish.Sun.COM (Guy Harris) (05/03/88)
> My first thought was that you haven't fixed the clock bug in the Sun > kernel (contact Sun for details). My next thought was that perhaps > the difference between 50Hz and 60Hz power line frequency might be a > factor; that's about 10 minutes per hour. Quite likely the former, and almost certainly not the latter; the time-of-day clocks in Suns run from a crystal, not from the line frequency.
cloos@batcomputer.tn.cornell.edu (James H. Cloos Jr.) (05/03/88)
In article <21024@oliveb.olivetti.com> ilcu@icoven.UUCP (Daniela Papa) writes: > >Every time I reboot my SUN 3/50M I get the message that the clock lost >29 days. While running the clock slows done about 10 minutes per hour, I >avoid this by speeding up the clock rate ( date -annn.sss ) but having to >reset the date every time I boot is a pain in the neck. Has anybody >experienced this problem? Is it a hardware bug.... I tried pulling out >the lithium battery and short-circuiting the electrolitic capacitor in >order to reset the Intersil ICM7170 but nothing happened except that I >got the message the the tod clock wasn't initialized. Any pointers.... > >The header isn't completely correct because I'm not in Cupertino but >in Ivrea, Italy and read news through our link to Cupertino. 10 minutes per hour, huh? Which means that your clock only registers 50 minutes for every 60 that pass. Kinda like running a US spec AC clock in Europe. The clock would expect 60 hz but get 50 hz, causing it to slow down 10 min per hour. But a clock running on a lithium battery would be DC, no?? And DC should not be affected by the change in Hz in the AC line. Is it possible that the capacitator is not matched to the battery correctly? (Now that I think of it, when I use Kodak Lithium 9-volts to back up my alarm clock, rather then Alkaline 9-volts, the clock gains about a min per hour, so choice of battery could be a factor. Can anyone explain my problem w/ lithium 9 volts either???) Good luck. -JimC -- batcomputer!cloos@cornell.UUCP |James H. Cloos, Jr.|#include <disclaimer.h> cloos@batcomputer.tn.cornell.EDU|B7 Upson, Cornell U|#include <cute_stuff.h> cloos@tcgould.tn.cornell.EDU |Ithaca, NY 14853 |"Entropy isn't what cloos@crnlthry.BITNET | +1 607 272 4519 | it used to be."
ked@garnet.berkeley.edu (Charles Faulhaber) (05/03/88)
>Is it possible that the capacitator is not matched to the battery correctly?
~~~~~~~~~~~
Is this computer literacy?dpb@tellab5.UUCP (Darryl Baker) (05/04/88)
In article <7811@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: +>In article <21024@oliveb.olivetti.com> ilcu@icoven.UUCP (Daniela Papa) writes: +>>Every time I reboot my SUN 3/50M I get the message that the clock lost +>>29 days. While running the clock slows done about 10 minutes per hour +> +>My first thought was that you haven't fixed the clock bug in the Sun +>kernel (contact Sun for details). My next thought was that perhaps We had the very same problem on all our machines (3/50, 3/60, 3/180 more than one of each). We installed a one byte patch from Sun and that fixed it. This was 3.5. -- __ _ __ / ) // / ) / / / __. __ __ __ , // /--< __. /_ _ __ Darryl Baker /__/_(_/|_/ (_/ (_/ (_/_</_ /___/_(_/|_/ <_</_/ (_ ihnp4!tellab5!dpb / '
lyndon@ncc.Nexus.CA (Lyndon Nerenberg) (05/04/88)
There is a bug in SunOS that causes the clock to do strange things.
This has been discussed at length in comp.sys.sun. A patch is available
from the sun-spots archive server at Rice.
[ This has nothing to do with Xenix, etc. Followups are in comp.unix.questions ]
--
{alberta,utzoo,uunet}!ncc!lyndon lyndon@Nexus.CApcm@iwarpv.intel.com (Phil C. Miller) (05/04/88)
In article <9546@agate.BERKELEY.EDU> cck@deneb.ucdavis.edu (Earl H. Kinmonth) writes: >>Is it possible that the capacitator is not matched to the battery correctly? > ~~~~~~~~~~~ >Is this computer literacy? Yes, although my inductative logic tells me that people have a high resistatance to looking up words in a dictionary. Phil Miller
mike@ists (Mike Clarkson) (05/06/88)
In article <967@tellab5.UUCP>, dpb@tellab5.UUCP (Darryl Baker) writes: > In article <7811@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: > +>In article <21024@oliveb.olivetti.com> ilcu@icoven.UUCP (Daniela Papa) writes: > +>>Every time I reboot my SUN 3/50M I get the message that the clock lost > +>>29 days. While running the clock slows done about 10 minutes per hour > +> > +>My first thought was that you haven't fixed the clock bug in the Sun > +>kernel (contact Sun for details). My next thought was that perhaps > We had the very same problem on all our machines (3/50, 3/60, 3/180 more > than one of each). We installed a one byte patch from Sun and that fixed > it. This was 3.5. I happen to have a copy of the patch handy so here it is. This text was extracted from SunSpots. As always, you should make a spare copy of vmunix in case something goes wrong. P.S. : why is Sun still shipping kernels with this bug when they've known about it since January ? ------------------------------------------------------------------------------- Date: Thu, 7 Jan 88 10:29:15 PST >From: chuq@sun.com (Chuq Von Rospach) Subject: Sun TOD Clock bug Patches for all releases [These are the official patches from Sun for all known affected releases in the field. If you have any questions or problems, please call Sun Tech Support] chuq Sun Tech Support There exists a problem for all Sun3 (68020) machines running SunOS Releases 3.0-3.5, and all Sun4 (SPARC) machines running SunOS Release Sys4-3.2 FCS and Sys4-3.2L GAMMA. This problem does not exist for Sun-2's. As of Jan 1 00:00 1988, the clock routine in the kernel will put the clock chip into an uncertain state if you attempt to set the date. The visible effects of this is to 1) cause the message WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE! to appear while booting vmunix, and to 2) cause the system date to start to drift widely. Any attempts to actually *set* the date will have only a temporary effect (i.e., the date you set will be good for about 30 seconds). In order to solve this problem, you must patch both the kernel and system object files. [[ NOTE that there are three separate patches. Make sure you use the right one. --wnl ]] ============================================================================== Sun3 System Patch Releases 3.2, 3.3, 3.4, 3.5 This is for Diskful and Server Machines only. Diskless machines need to be fixed on the server. As root, run the follwing command: echo 'resettodr+c0?i' | adb /vmunix - | grep reset You should see the following printed out: _resettodr+c0: bnes _resettodr+0xca If you see instead: _resettodr+c0: bnes _resettodr+0xce the patch has already been applied to this system. Proceed with the rest of the patch procedure anyway! If you do not see either of these messages, go no further with this patch, and please contact Sun Microsystems Customer Service. If you do see either of those messages, then run, as root, the following commands: echo 'resettodr+c0?w 660c' | adb -w /vmunix Reboot and then *set* the date. If you build kernels for your system, or are a server for diskless clients, do, as root cp /sys/OBJ/clock.o /sys/OBJ/clock.o- echo 'resettodr+c0?w 660c' | adb -w /sys/OBJ/clock.o and then rebuild your kernel and/or the kernels for your diskless clients. ============================================================================== Sun3 System Patch Release SunOS Release 3.0 This is for Diskful and Server Machines only. Diskless machines need to be fixed on the server. As root, run the following command: echo 'todset+0xb4?i' | adb /vmunix - You should see the following printed out: _todset+0xb4: bnes _todset+0xbe If you see instead: _todset+0xb4: bnes _todset+0xc2 the patch has already been applied to this system. Proceed with the rest of the patch procedure anyway! If you do not see either of these messages, go no further with this patch, and please contact Sun Microsystems Customer Service. If you do see either of those messages, then run, as root, the following command: echo 'todset+0xb4?w 0x660c' | adb -w /vmunix Reboot and then *set* the date. If you build kernels for your system, or are a server for diskless clients, do, as root cp /sys/OBJ/clock.o /sys/OBJ/clock.o- echo 'todset+0xb4?w 0x660c' | adb -w /sys/OBJ/clock.o and then rebuild your kernel and/or the kernels for your diskless clients. ============================================================================== Sun4 System Patch Release Sys4-3.2 FCS, Sys4-3.2L GAMMA This is for Diskful and Server Machines only. Diskless machines need to be fixed on the server. echo 'resettodr+0x110?i' | adb /vmunix - You should see the following printed out: _resettodr+0x110: sub %i5, 0x1, %i5 If you see instead: _resettodr+0x110: sub %i5, 0x0, %i5 the patch has already been applied to this system. Proceed with the rest of the patch procedure anyway! If you do not see either of these messages, go no further with this patch, and please contact Sun Microsystems Customer Service. If you do see either of those messages, then run, as root, the following command: echo 'resettodr+0x110?W ba276000' | adb -w -k /vmunix /dev/mem Reboot and then *set* the date. If you build kernels for your system, or are a server for diskless clients, do, as root cp /sys/sun4/OBJ/clock.o /sys/sun4/OBJ/clock.o- echo 'resettodr+0x110?W ba276000' | adb -w /sys/sun4/OBJ/clock.o and then rebuild your kernel and/or the kernels for your diskless clients. -- Mike Clarkson mike@ists.UUCP Institute for Space and Terrestrial Science mike@ists.yorku.ca York University, North York, Ontario, CANADA M3J 1P3 (416) 736-5611
marcus@fkihh.UUCP (Marcus Moehrmann) (05/06/88)
In article <21024@oliveb.olivetti.com> ilcu@icoven.UUCP (Daniela Papa) writes: > >Every time I reboot my SUN 3/50M I get the message that the clock lost >29 days. While running the clock slows done about 10 minutes per hour, I >avoid this by speeding up the clock rate ( date -annn.sss ) but having to >reset the date every time I boot is a pain in the neck. Has anybody >experienced this problem? Is it a hardware bug.... Here is a fix, which was posted to newsgroup 'Comp.sys.sun' *** Marcus Moehrmann | UUCP: marcus@fkihh.UUCP *** *** (TeX: M\"{o}hrmann) | PHONE: +49-40-4123-2573 *** *** Univ of Hamburg, W. Germany | +49-40-5202464 *** -------------------------------------------------------------------------- SUN-SPOTS DIGEST Thursday, 7 January 1988 Volume 6 : Issue 1 Today's Topics: Administrivia and Non-trivia Sun TOD Clock bug Patches for all releases Sendmail 'Oi' fix breaks SMTP mail Re: rows,cols (window sizing) Re: disk versus memory Diffs to make gnuplot 1.1.0 run under SunCGI PD indexing software Low Cost SCSI drives for Sun's Sun 3 keyboards drop characters when you type too fast Strange failure of bind(2) on diskless clients Attempt to compile dumpregion.c ping bug? Removable Disk Storage on Suns? Maximum disk space limitation? How to do hybrid slider/text panel items? SI83 8" SMD disks and SMD controllers? Ethernet controllers for Suns? ---------------------------------------------------------------------- Date: Wed, 6 Jan 88 17:46:46 CST From: William LeFebvre <phil@Rice.edu> Subject: Administrivia and Non-trivia I just got all caught up with Sun-Spots and then Christmas break hit. Oh well...... Two of the files in the SunRPC distribution (contained in the archives) suffer from the infamous dot-on-a-line-by-itself disease. I hope to take care of the problem in the very near future (I may just ask the author to repack those files with a better mail packer). The afflicted files are "rpcsrc.doc.11" and "rpcsrc.doc.13". Sorry for the inconvenience. Finally, what new year would be complete without a widespread and serious bug to plague everyone. No, I'm not talking about the flu. I'm talking about a disturbance in the temporal plane: the now infamous drifting clock bug. As most of you probably know by now, there is a bug in SunOS that, as of the beginning of the year, makes the TOD clock drift or otherwise behave oddly. Chuq at Sun has been kind enough to send a patch to Sun-Spots for this bug. I recommend this patch over all others---it's straight from Sun. It is all contained in the next message. I felt it important enough to pull it out of the queue of waiting message and run it immediately. William LeFebvre Department of Computer Science Rice University <phil@Rice.edu> ------------------------------ Date: Thu, 7 Jan 88 10:29:15 PST From: chuq@sun.com (Chuq Von Rospach) Subject: Sun TOD Clock bug Patches for all releases [These are the official patches from Sun for all known affected releases in the field. If you have any questions or problems, please call Sun Tech Support] chuq Sun Tech Support There exists a problem for all Sun3 (68020) machines running SunOS Releases 3.0-3.5, and all Sun4 (SPARC) machines running SunOS Release Sys4-3.2 FCS and Sys4-3.2L GAMMA. This problem does not exist for Sun-2's. As of Jan 1 00:00 1988, the clock routine in the kernel will put the clock chip into an uncertain state if you attempt to set the date. The visible effects of this is to 1) cause the message WARNING: TOD clock not initialized -- CHECK AND RESET THE DATE! to appear while booting vmunix, and to 2) cause the system date to start to drift widely. Any attempts to actually *set* the date will have only a temporary effect (i.e., the date you set will be good for about 30 seconds). In order to solve this problem, you must patch both the kernel and system object files. [[ NOTE that there are three separate patches. Make sure you use the right one. --wnl ]] ============================================================================== Sun3 System Patch Releases 3.2, 3.3, 3.4, 3.5 This is for Diskful and Server Machines only. Diskless machines need to be fixed on the server. As root, run the follwing command: echo 'resettodr+c0?i' | adb /vmunix - | grep reset You should see the following printed out: _resettodr+c0: bnes _resettodr+0xca If you see instead: _resettodr+c0: bnes _resettodr+0xce the patch has already been applied to this system. Proceed with the rest of the patch procedure anyway! If you do not see either of these messages, go no further with this patch, and please contact Sun Microsystems Customer Service. If you do see either of those messages, then run, as root, the following commands: echo 'resettodr+c0?w 660c' | adb -w /vmunix Reboot and then *set* the date. If you build kernels for your system, or are a server for diskless clients, do, as root cp /sys/OBJ/clock.o /sys/OBJ/clock.o- echo 'resettodr+c0?w 660c' | adb -w /sys/OBJ/clock.o and then rebuild your kernel and/or the kernels for your diskless clients. ============================================================================== Sun3 System Patch Release SunOS Release 3.0 This is for Diskful and Server Machines only. Diskless machines need to be fixed on the server. As root, run the following command: echo 'todset+0xb4?i' | adb /vmunix - You should see the following printed out: _todset+0xb4: bnes _todset+0xbe If you see instead: _todset+0xb4: bnes _todset+0xc2 the patch has already been applied to this system. Proceed with the rest of the patch procedure anyway! If you do not see either of these messages, go no further with this patch, and please contact Sun Microsystems Customer Service. If you do see either of those messages, then run, as root, the following command: echo 'todset+0xb4?w 0x660c' | adb -w /vmunix Reboot and then *set* the date. If you build kernels for your system, or are a server for diskless clients, do, as root cp /sys/OBJ/clock.o /sys/OBJ/clock.o- echo 'todset+0xb4?w 0x660c' | adb -w /sys/OBJ/clock.o and then rebuild your kernel and/or the kernels for your diskless clients. ============================================================================== Sun4 System Patch Release Sys4-3.2 FCS, Sys4-3.2L GAMMA This is for Diskful and Server Machines only. Diskless machines need to be fixed on the server. echo 'resettodr+0x110?i' | adb /vmunix - You should see the following printed out: _resettodr+0x110: sub %i5, 0x1, %i5 If you see instead: _resettodr+0x110: sub %i5, 0x0, %i5 the patch has already been applied to this system. Proceed with the rest of the patch procedure anyway! If you do not see either of these messages, go no further with this patch, and please contact Sun Microsystems Customer Service. If you do see either of those messages, then run, as root, the following command: echo 'resettodr+0x110?W ba276000' | adb -w -k /vmunix /dev/mem Reboot and then *set* the date. If you build kernels for your system, or are a server for diskless clients, do, as root cp /sys/sun4/OBJ/clock.o /sys/sun4/OBJ/clock.o- echo 'resettodr+0x110?W ba276000' | adb -w /sys/sun4/OBJ/clock.o and then rebuild your kernel and/or the kernels for your diskless clients. --------------------------------- many articles removed ... End of SUN-Spots Digest ***********************
wes@obie.UUCP (Barnacle Wes) (05/07/88)
In article <9546@agate.BERKELEY.EDU> cck@deneb.ucdavis.edu (Earl H. Kinmonth) writes: >>Is it possible that the capacitator is not matched to the battery correctly? > ~~~~~~~~~~~ >Is this computer literacy? In article <3440@omepd>, pcm@iwarpv.intel.com (Phil C. Miller) replies: | Yes, although my inductative logic tells me that people have a high | resistatance to looking up words in a dictionary. ^^^^^^^^^^ Shouldn't that be `dictationary'? -- /\ - "Against Stupidity, - {backbones}! /\/\ . /\ - The Gods Themselves - utah-cs!uplherc! / \/ \/\/ \ - Contend in Vain." - sp7040!obie! / U i n T e c h \ - Schiller - wes
mkhaw@teknowledge-vaxc.ARPA (Mike Khaw) (05/11/88)
+ | Yes, although my inductative logic tells me that people have a high
+ | resistatance to looking up words in a dictionary.
+ ^^^^^^^^^^
+ Shouldn't that be `dictationary'?
"dictionatary", because diction and dictation are differentative.
Mike Khaw
--
internet: mkhaw@teknowledge.arpa
uucp: {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge-vaxc.arpa
hardcopy: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303aglew@urbsdc.Urbana.Gould.COM (05/13/88)
>>>Is it possible that the capacitator is not matched to the battery correctly? >> ~~~~~~~~~~~ >>Is this computer literacy? > >| Yes, although my inductative logic tells me that people have a high >| resistatance to looking up words in a dictionary. This has gone far enough. In my copy of "Everyman's Wireless Handbook", published in England in the Twenties, the term "capacitator" is used as synonymous with the British "condensor", Yank "capacitor". And you can mock me all you want for not being sure whether the British word is spelled "condensor", "condenser", or "condensator".