[linux-audio-user] intermittent X blackout in rt kernel
nando at ccrma.Stanford.EDU
Mon Nov 21 21:38:33 EST 2005
On Mon, 2005-11-21 at 15:25 -0500, Aaron Phillips wrote:
> > Which cpu do you have?
> I have AMD X2 also, the AMD X2 3800, interesting...
> > I have seen this coupled also to keyboard repeats
> > being too fast because of kernel problems in keeping time (in my case
> > related to using AMD X2 dual core processors).
> Really? well should I turn down repeats in the BIOS or in Linux?
> > The X blackouts were actually the screensaver kicking in. It is supposed to be fixed...
> In which version is it supposed to be fixed. I am using the latest
> and greatest 2.6.14 plus the latest RT patch (rt13). The only thing I
> don't quite understand is what to do with the post-release version
> increments such as 220.127.116.11.. how do you patch that?
> Which kernel are you running and do you have the same problem still?
I still have the problem and it is not fixed yet (just earlier today I
think I finally understood what is actually happening).
At this point this only happens on dual core systems (for example the
Athlon X2 processor family) running an SMP i386 kernel, it does not
happen on x86_64 systems. A patch has just been posted to lkml (by John
Stultz) that should take care of this, but it will take a while for the
stuff to get to the -rtxx patches.
There is a workaround (thanks to John Stultz) which is to change the
source clock for the timing to something other than the TSC[*]. You can
see which source is being used by typing:
The default should show something like this:
acpi_pm jiffies *tsc pit
note the "*" next to tsc, means it is the one being used.
If you have acpi_pm change the source to it like this:
That should fix the problem you are having.
You can also add "clocksource=xyz" as a boot time kernel parameter,
where xyz is the source you want to use.
[*] "Time Stamp Clock": on Athlon X2 systems each cpu has its own and
they can drift from each other, software that does not take this into
account gets into big trouble, for example Jack.
More information about the Linux-audio-user