lkml.org 
[lkml]   [2001]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: time drift and fb comsole activity
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:28    [W:0.070 / U:1.612 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site