21 Nov
2005
21 Nov
'05
1:02 p.m.
Hello,
Has anyone experienced X going blank at random times for between 1 and
5 seconds at a pop? I started out with a demudi mm kernel (I'm
running DeMudi) and never experienced this problem. Once I ran my own
built-from-source
2.6.14-rt13 kernel, I saw this behavior consistently. It's very annoying.
Basically, while in X, the screen would go blank every so often for a
short period and then reappear. Periods between blackouts would be
between 1 second and 1 minute. I am wondering if it has something to
do with the video having too low of a priority since this is a
realtime-preempt kernel. I tried setting X to a higher prio with
chrt, but that had no effect.
Anyone have an idea?
Thanks,
Aaron
21 Nov
21 Nov
1:58 p.m.
On Mon, 2005-11-21 at 12:02 -0500, Aaron Phillips wrote:
Anyone have an idea?
This is probably a video driver issue. Please give some information
about the video hardware, output of "lsmod", "cat /proc/interrupts",
and
"grep -A10 'Section "Device"' /etc/X11/xorg.conf".
Lee
4:26 p.m.
This is probably a video driver issue. Please give
some information
about the video hardware, output of "lsmod", "cat /proc/interrupts",
and
"grep -A10 'Section "Device"' /etc/X11/xorg.conf".
I don't have access to the machine right now, but I will have this info soon
Thanks,
Aaron
4:09 p.m.
On Mon, 2005-11-21 at 12:02 -0500, Aaron Phillips wrote:
Hello,
Has anyone experienced X going blank at random times for between 1 and
5 seconds at a pop? I started out with a demudi mm kernel (I'm
running DeMudi) and never experienced this problem. Once I ran my own
built-from-source
2.6.14-rt13 kernel, I saw this behavior consistently. It's very annoying.
Basically, while in X, the screen would go blank every so often for a
short period and then reappear. Periods between blackouts would be
between 1 second and 1 minute. I am wondering if it has something to
do with the video having too low of a priority since this is a
realtime-preempt kernel. I tried setting X to a higher prio with
chrt, but that had no effect.
Anyone have an idea?
Which cpu do you have? 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). The X blackouts were
actually the screensaver kicking in. It is supposed to be fixed...
-- Fernando
4:25 p.m.
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 2.6.14.2.. how do you patch that?
Which kernel are you running and do you have the same problem still?
Aaron
10:38 p.m.
On Mon, 2005-11-21 at 15:25 -0500, Aaron Phillips wrote:
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:
cat /sys/devices/system/clocksource/clocksource0/clocksource
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:
echo "acpi_pm">/sys/devices/system/clocksource/clocksource0/clocksource
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.
-- Fernando
[*] "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.
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 2.6.14.2.. how do you patch that?
Which kernel are you running and do you have the same problem still?
22 Nov
22 Nov
4:05 a.m.
Fernando,
Thanks very much for your help. I read the entire 5105 kernel bug
discussion and didn't find the valuable information you presented,
i.e. how to change the clocksource at runtime so easily. I was going
to try the "notsc" kernel option. For what it's worth I changed the
clocksource as you mentioned and I haven't had a glitch yet (10
minutes since the change).. and this is unusual.
Aaron
On 11/21/05, Fernando Lopez-Lezcano <nando(a)ccrma.stanford.edu> wrote:
On Mon, 2005-11-21 at 15:25 -0500, Aaron Phillips
wrote:
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:
cat /sys/devices/system/clocksource/clocksource0/clocksource
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:
echo "acpi_pm">/sys/devices/system/clocksource/clocksource0/clocksource
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.
-- Fernando
[*] "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.
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 2.6.14.2.. how do you patch that?
Which kernel are you running and do you have the same problem still?
6943
days inactive
6944
days old
linux-audio-user@lists.linuxaudio.org
6 comments
3 participants
participants (3)
-
Aaron Phillips -
Fernando Lopez-Lezcano -
Lee Revell