On Tuesday 07 February 2006 19:12, Chuck Martin wrote: loki.davison-at-gmail.com |LAU| wrote: Hi Chuck. My old Gateway 500 P111 Katmai using kernel-2.6.10-0.4.rdt.rhfc2.ccrma, and realtime modules "rtirq" and "rtload", is showing similar problems. I had got NTP up and running a while back, and initially had problems with ntpd dying when the machine had booted up. With suggestions from Fernando at Planetccrma, I moved the load point of rtload to before ntpd loaded, which solved that problem. I was then getting time slips, even with ntpd running, and problems contacting the ntp Internet servers. This was severly exaggerated during the night when losing the dial-up connection, resulting in the system clock stopping. Next day, without re-connecting to the Internet, using the time and date facility, I'd reset the time as near as possible, leave the time and date window open, and not move the mouse pointer or do anything on the machine. After a few minutes the clock would stop again. Move the mouse pointer, and Bingo, the clock starts again. I havn't solved the problem on this machine, but it's clearly connected to realtime, and reverting to using the original kernel-2.6.5-1.358 (no realtime), the problem is resolved, and the clock is rock steady, with no problems with ntp contacting the Internet servers. Strangely, the other machine on my network. An i-Friend 1.3Ghz celeron, also, in this example running FC2, with the same planetccrma kernel with the 2 realtime modules, has no clock problems. This machine, again with ntpd enabled, retrieves it's time from the machine with the problems. Even with the terrible time slips (clock stopped) on the Gateway, the i-Friend machines clock stayed on time. Incidentally. The main reason that I enabled NTP was because I'd been getting time slips on the Gateway machine, but obviously this is a realtime problem, specific to this machine. Processor problem? I notice that your P111 is only a bit faster than mine, and strange that my other machine with the same setup shows no time slips. I have posted this problem to questions(a)lists.ntp.org, but with no replies. Nigel.

On Tue, 2006-02-07 at 17:16 -0500, Lee Revell wrote: Hmm, IIRC this might have been related to the softirq timer thread being preempted - try setting it to the maximum RT priorirty (99). Lee

To me, this looks a lot like CLOCK_REALTIME is being used instead of CLOCK_MONOTONIC ... but I disabled ntp on my RT machine long ago while awaiting 2.6.16. On 2/7/06, Chuck Martin <dsdhpnw02(a)sneakemail.com> wrote: -- Mike Taht PostCards From the Bleeding Edge http://the-edge.blogspot.com

On Tue, 07 Feb 2006 19:43:18 -0500 Lee Revell <rlrevell(a)joe-job.com> wrote: Hi, i think the kernel thread in question is "softirq-timer/0". It is kinda resistant against the usual chrt -f -p `pidof "softirq-timer/0"` but something like this works: /usr/bin/chrt -f -p 96 `/usr/bin/getpid.sh "softirq-timer/0"` where getpid.sh looks like this: ------------------snip #! /bin/sh # Uncomment the next line for testing #set -x if [ $# -ne 1 ]; then echo "Usage: $0 prog_regexp"; exit 1; fi ps auxc|grep ${1}|sed 's/^[a-zA-Z]* *\([0-9]*\).*$/\1/' ------------------snap Provided by a kind soul in #lad. I forgot who sorry :( I just don't know whether this is a cure for the problem at hand. I haven't read the whole thread. Flo -- Palimm Palimm! http://tapas.affenbande.org

On Wed, 8 Feb 2006 14:47:34 -0500 "Chuck Martin" <dsdhpnw02(a)sneakemail.com> wrote: Hmm, try with or without high resolution timer support compiled in. Also if you can confirm it doesn't happen with vanilla, i'd suggest reporting this to Ingo. Flo -- Palimm Palimm! http://tapas.affenbande.org

On Sat, 2006-02-25 at 20:24 -0500, Chuck Martin wrote: I didn't see a report of this on the kernel mailing list. A post to LKML with Ingo CC'ed is much more likely to get results than mailing him privately - I often send requests for tech support via private mail to /dev/null as I don't have the bandwidth to help people unless it's in a public forum where others can get the answer from Google next time. Lee