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@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@kalimotxo log]# hdparm /dev/hdb /dev/hdb: No such device or address [root@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@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@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@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@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
