Clock delay

[Juan L. Pastor]

On Sat, 2004-09-25 at 15:18, Stewart Nelson wrote:
> Sorry, it's beyond my expertise to say what might be wrong.
> I would guess that you are losing timer interrupts, because of
> higher priority interrupts, or a process that is disabling them.
> Perhaps you can get a clue from interrupt counts or process run times.
> You could try running adjtimex in --compare mode to see if time gets
> lost gradually or in bursts.

This is an extract of the system log in the last reboot:

Sep 26 06:56:22 kalimotxo kernel: hdc: 234441648 sectors (120034 MB) w/2048KiB Cache, CHS=16383/255/63
Sep 26 06:56:22 kalimotxo kernel:  hdc: hdc1 hdc2 hdc3 hdc4 < hdc5 hdc6 hdc7 hdc8 >
Sep 26 06:56:22 kalimotxo kernel: spurious 8259A interrupt: IRQ7.
Sep 26 06:56:22 kalimotxo smartd[1442]: smartd version 5.21 Copyright (C) 2002-3 Bruce Allen
[...]
Sep 26 07:22:13 kalimotxo modprobe: FATAL: Error running install command for sound_slot_1
Sep 26 07:22:13 kalimotxo modprobe: FATAL: Error running install command for sound_slot_1
Sep 26 07:22:13 kalimotxo kernel: application epiphany-bin uses obsolete OSS audio interface
Sep 26 07:42:32 kalimotxo kernel: Losing too many ticks!
Sep 26 07:42:32 kalimotxo kernel: TSC cannot be used as a timesource.
Sep 26 07:42:32 kalimotxo kernel: Possible reasons for this are:
Sep 26 07:42:32 kalimotxo kernel:   You're running with Speedstep,
Sep 26 07:42:32 kalimotxo kernel:   You don't have DMA enabled for your hard disk (see hdparm),
Sep 26 07:42:32 kalimotxo kernel:   Incorrect TSC synchronization on an SMP system (see dmesg).
Sep 26 07:42:32 kalimotxo kernel: Falling back to a sane timesource now.
Sep 26 08:01:39 kalimotxo cups: cupsd shutdown succeeded
Sep 26 08:01:39 kalimotxo cups: cupsd startup succeeded

My system is not SMP, I don't have a clue about what is Speedstep, and this is the output of hdparm
(Win2000 in /dev/hda, linux in /dev/hdc, CD-ROM in /dev/hdd):

[root at kalimotxo log]# hdparm /dev/hda
 
/dev/hda:
 multcount    = 16 (on)
 IO_support   =  0 (default 16-bit)
 unmaskirq    =  0 (off)
 using_dma    =  0 (off)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    = 256 (on)
 geometry     = 65535/16/63, sectors = 78198750, start = 0
[root at kalimotxo log]# hdparm /dev/hdb
/dev/hdb: No such device or address
[root at kalimotxo log]# hdparm /dev/hdc
 
/dev/hdc:
 multcount    = 16 (on)
 IO_support   =  0 (default 16-bit)
 unmaskirq    =  0 (off)
 using_dma    =  0 (off)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    = 256 (on)
 geometry     = 16383/255/63, sectors = 234441648, start = 0
[root at kalimotxo log]# hdparm /dev/hda
 
/dev/hda:
 multcount    = 16 (on)
 IO_support   =  0 (default 16-bit)
 unmaskirq    =  0 (off)
 using_dma    =  0 (off)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    = 256 (on)
 geometry     = 65535/16/63, sectors = 78198750, start = 0
[root at kalimotxo log]# hdparm /dev/hdc
 
/dev/hdc:
 multcount    = 16 (on)
 IO_support   =  0 (default 16-bit)
 unmaskirq    =  0 (off)
 using_dma    =  0 (off)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    = 256 (on)
 geometry     = 16383/255/63, sectors = 234441648, start = 0
[root at kalimotxo log]# hdparm /dev/hdd
 
/dev/hdd:
 HDIO_GET_MULTCOUNT failed: Invalid argument
 IO_support   =  0 (default 16-bit)
 unmaskirq    =  0 (off)
 using_dma    =  0 (off)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    = 256 (on)
 HDIO_GETGEO failed: Invalid argument
[root at kalimotxo log]#

I had read in this list that hdparm parameters shouldn't be touched, that the defaults are OK (?).

> You could also start up adjtimex in --adjust mode, which
> should keep your system time pretty much in sync with the
> hardware clock.  You wouldn't be able to set the system
> clock from the Net (maybe unimportant if you do that from
> Windows), or you could have a script that runs hwclock to
> set the hardware clock from network time.

I don't have adjtimex in my system.

Juan

-- 
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html