From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.4) Gecko/20030922
Description of problem:
An comparable problem to the existing Bug 100422, but with the RHEL
kernel. Please refer:
As stated in 100422: "This kernel fails the XMMS test miserably. Time
sensitive processes such as XMMS and mplayer "skip" very frequently
when doing various actions requiring either disk i/o or cpu time."
Same applies here to the RHEL kernel 2.4.21-4.0.1, with the exception
that skipping is not observed during scrolling of Mozilla, only change
of windows/tabs or going forward/backward in the browsing history.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start XMMS or MPlayer.
2. Open a new Mozilla window or klick on some links.
Actual Results: Sound skipping can be heard.
Expected Results: No sound skipping should be there.
Sound driver: i810_audio
sounds like you need to increase the default buffer size. You're not
using KDE are you ?
No, I also tried to increase the buffer size to 10 seconds, but with
no effect. I am using GNOME.
Some additional information:
1. Much more visible is this problem when using Wolfram Research's
Mathematica 5 when running XMMS. Beside other circumstances, just
left click on any place of a Mathematica notebook will halt XMMS
playing after few seconds (shorter than the actual XMMS buffering
I think this way to reproduce the problem shows very well that the
XMMS buffering and buffer size is unrelated to this problem, since
the buffer is not even empty, when XMMS stops playing.
2. This problem is actually and contrary to my previous report
sensitive to Mozilla scrolling, however, only with very big and
graphics intensive pages.
If I might ask: Is the "O(1) scheduler starvation" as discussed in
June on the Linux Kernel Mailing List related to this issue?
After reading the kernel mailing lists, if I am not very mistaken,
what we need here is a backport of the 2.6.0 kernel with O(1)
scheduler interactivity patch. This seems also have solved the problem
in Fedora Core (Bug 100422).
Then the question would be, when can it be intergrated in RHEL?
Created attachment 96598 [details]
Backport of Con Kolivas' patch-test5-O20.3int
This is the patch I made, which solves the issue mentioned. It can be applied
as the patch no. 50 in the source RPM spec of kernel-2.4.21-4.0.1.EL.src.rpm.
Please note that this is a very minimalistic patch. It especially does not
change the logic towards the idle variable in can_migrate_task() (also see
http://www.ussg.iu.edu/hypermail/linux/kernel/0308.3/0879.html), as implemented
in kernel 2.6.0-test6 and later and Fedora Core 1.
As like the current kernel, sched_clock is implemented for arm, i386, ia64,
ppc, ppc64, s390, sparc64, and x86_64. However, I could only tested this patch
on i386 architecture, first in VMware and then natively. It seems to be stable
and show the expected enhancement of the scheduling behavior.
The last paragraph of comment #6, first sentence is wrong:
As like in 2.6.0-test6, ...
We have just frozen the Update 1 kernel (beta is already available),
so I would like to propose your patch for the Update 2 MUSTFIX list.
Ingo, any objections to the O(1) interactivity patches ?
oh boy, Con's patch has certainly grown from the earlier versions
we may need to look at chainsawing this down to a much smaller change
set, the current patch is way too big for a "minimal changes only" policy
Concerning the patch backport, I encounted the following issue:
VMware Workstation is getting too much CPU time during strong Guest
loads (e.g. booting an OS). The system becoms a "stop and go". Renices
all VMware threads to the nice value of 0 resolves the problem. This
maybe due to the fact that VMware "looks" interactive to the scheduler
and also renices it to -10 (and lower for the I/O threads).
Since VMware has already released a Beta version of VMware Workstation
4.1, and its release note states that it is more suitable for 2.6
kernel series, I will do some testing with this version the next days.
Bug 113851 maybe related to the observation I made.
Any news on this problem? The U2-beta kernel (2.4.21-12.EL) does
still not solve the XMMS problem :-(.
Could this possibly be related to bug #121434 here:
I have similar experiences on my desktop, which is showing horrible
latency with the latest kernel: 2.4.21-15.0.4.EL
Maybe there are two problems, one raid related and another problem
either with the kernel scheduler or the IO elevator.
This is a problem for me with xmms under kernel-2.4.21-20.EL, about
3-4 times a minute - its really annoying.
Created attachment 108040 [details]
2.4.21-20.0.1 version of Backport of Con Kolivas' patch-test5-O20.3int
Its still a problem under kernel-2.4.21-25.EL (latest beta) and
kernel-2.4.21-20.0.1.EL (latest patched version).
I've applied the back port of Con Kolivas's Patch which fixes it (I've been
using it the last couple of days), I've supplied an updated version with the
file manually updated as I had to do this because a couple of hunks failed to
match. The Patch is to be applied to the 18.104.22.168.1.EL kernel.
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.