Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!rice!sun-spots-request From: dupuy@cs.columbia.edu Newsgroups: comp.sys.sun Subject: 4/330 time problems Keywords: Miscellaneous Message-ID: <2964@brazos.Rice.edu> Date: 13 Nov 89 16:45:45 GMT Sender: news@rice.edu Organization: Sun-Spots Lines: 31 Approved: Sun-Spots@rice.edu X-Refs: Original: v8n192 X-Sun-Spots-Digest: Volume 8, Issue 194, message 10 of 23 > Problem Description: > There is a bug in SunOS 4.0.3 which causes the Sun 4300 processor > board to be unable to synchronize the kernel's notion of the time > of day with the TOD chip. > > Corrective Action: > To patch a running kernel: (will be fixed until next reboot) > > # adb -w -k /vmunix /dev/mem > todget+0x1e0/X > > todget+0x1e0/W 80a3e007 > $q > # Just as a note, the clock.o module that comes with the SPARCserver 390 "feature" tape (i.e. support for IPI disks/controllers) already has this patch in it. It certainly seems to be able to set the TOD chip, in fact it tells us every time it does so! :-( Nov 12 23:54:11 hudson vmunix: resettodr: setting TOD chip to 12-13-21 04:54:11 Nov 12 23:54:11 hudson vmunix: resettodr: TOD chip was 12-13-21 04:54:11 Nov 12 23:54:23 hudson vmunix: resettodr: setting TOD chip to 12-13-21 04:54:23 Nov 12 23:54:23 hudson vmunix: resettodr: TOD chip was 12-13-21 04:54:23 We run NTP, and it seems only to be able to keep the clock within about 100 ms of our local secondary time servers. So there's still some bad stuff happening with them thar clocks. inet: dupuy@cs.columbia.edu uucp: ...!rutgers!cs.columbia.edu!dupuy