Re: time drift and fb comsole activity

From: Cort Dougan (
Date: Wed Feb 28 2001 - 18:50:26 EST

We have the same trouble on PPC but we make sure to re-sync on each
interrupt. We can see several lost timer interrupts after a ^L in emacs
running on the fb console. The resync lets us catch up on those interrupts
(and not lose time) but we still spend a lot of time not servicing

Does x86 not resync on timer interrupts?

} Eric Buddington wrote:
} >
} > I know this has been reported on the list recently, but I think I can
} > provide better detail. I'm running 2.4.2 with atyfb on a K6-2/266
} > running at 250. This system has no history of clock problems.
} >
} > adjtimex-1.12 --compare gives me "2nd diff" readings of -0.01 in quiescent
} > conditions.
} >
} > flipping consoles rapidly cboosts this number to -3 or -4.
} >
} > catting the full documentation to ntpd (seemed appropriate) gives me
} > "2nd diff" numbers a little over 34. If I read the numbers correctly,
} > 47 seconds of CMOS time passed while the system clock only passed 13
} > seconds.
} >
} > The processor and the CMOS clock were moving at zero velocity relative
} > to each other, and were both in normal Earth gravity.
} The kernel blocks interrupts during console output. fbdev
} consoles are slow. Net result: many lost timer interrupts.
} I'm working on it. Slowly. Should have something next week.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Wed Feb 28 2001 - 21:00:18 EST