Hi Andrew, On PPC64, we keep track of when we need to update jiffies (and the variables used to calculate the time of day) based on the time base. If the time base frequence is sufficiently high compared to the processor clock frequency, then it is possible for the time of day variables to be corrupted by at the time of the first decrementer interrupt we take. This became obvious on a legacy iSeries where the time base frequency is the same as the processor clock. This one line patch fixes the initialisation so that the time of day variables and the indicator we use to tell when updates are due are better synchronised. Signed-off-by: Stephen Rothwell <[email protected]> Please apply and send to Linus. -- Cheers, Stephen Rothwell [email protected] http://www.canb.auug.org.au/~sfr/ diff -ruNp linus/arch/ppc64/kernel/time.c linus-clock.1/arch/ppc64/kernel/time.c --- linus/arch/ppc64/kernel/time.c 2005-05-17 09:23:08.000000000 +1000 +++ linus-clock.1/arch/ppc64/kernel/time.c 2005-05-25 13:11:14.000000000 +1000 @@ -515,6 +515,7 @@ void __init time_init(void) do_gtod.varp = &do_gtod.vars[0]; do_gtod.var_idx = 0; do_gtod.varp->tb_orig_stamp = tb_last_stamp; + get_paca()->next_jiffy_update_tb = tb_last_stamp + tb_ticks_per_jiffy; do_gtod.varp->stamp_xsec = xtime.tv_sec * XSEC_PER_SEC; do_gtod.tb_ticks_per_sec = tb_ticks_per_sec; do_gtod.varp->tb_to_xs = tb_to_xs;
Attachment:
pgpQB9EWkheRN.pgp
Description: PGP signature
- Prev by Date: Re: RT patch acceptance
- Next by Date: Re: surprisingly slow accept/connect cycle time
- Previous by thread: CONFIG_HOTPLUG, 2.4.x and ppc
- Next by thread: Fwd: Reading media files from within a driver
- Index(es):
 |