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
interrupts.
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
