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: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=100422 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): kernel-2.4.21-4.0.1.EL How reproducible: Always Steps to Reproduce: 1. Start XMMS or MPlayer. 2. Open a new Mozilla window or klick on some links. 3. Actual Results: Sound skipping can be heard. Expected Results: No sound skipping should be there. Additional info: 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 size). 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? http://lkml.org/lkml/2003/6/18/102
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: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121434 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 2.4.20.0.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: http://www.redhat.com/security/updates/errata/ 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.