processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 7
model name : 00/07
stepping : 2
cpu MHz : 448.881356
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
sep_bug : no
f00f_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx osfxsr kni
bogomips : 447.28
[7.3.] Module information (from /proc/modules):
[7.4.] SCSI information (from /proc/scsi/scsi)
[7.5.]
I recently started having trouble with X on a dual-proc PIII-450: the
server would execute gettimeofday() periodically, but the time
returned would warp forward 4294 seconds every 1-2 seconds, and then
warp back almost immediately. The forward warp would kick off the
server's screen saver, which was a major annoyance; but I was worried
that file timestamps would be screwed up as well.
After a little digging, I found that the Pentium TSC register is being
used to give accurate microseconds in struct timeval, and guessed that
if the two CPUs' TSCs were off slightly, then you'd occasionally get
huge values for the count differential. (I should have realized right
away that 4294 is what you get when you divide 2^32 by 1e6, but
anyway...)
I added this sanity check to .../arch/i386/kernel/time.h:
/* .. relative to previous jiffy (32 bits is enough) */
eax -= last_tsc_low; /* tsc_low delta */
+ if (eax > 5000000)
+ return delay_at_last_interrupt;
and it seems to have cured my problem, but it's clearly just a hack.
I don't know how to either keep the TSCs in sync or to ensure that the
gettimeofday code is always executed by the same CPU; if it's not
possible, then perhaps this is the best way to handle it.
regards,
d.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/