10 Jul
2004
10 Jul
'04
6:08 a.m.
* Jeremy Hall <jhall(a)maoz.com> wrote:
I compiled this on SMP and when I enabled preempt in
/proc/sys/kernel
commands worked for a few seconds, then the machine crashed. It
responded to pings but otherwise was dead in the water. When I
enabled voluntary preempt as well, the machine almost immediately
crashed.
The note says that you should be able to switch from the four modes of
operation at will while the machine is running. Is that true?
it's true, it should work. This is probably a bug in the patch.
Investigating it.
Ingo
10 Jul
10 Jul
6:24 a.m.
* Ingo Molnar <mingo(a)elte.hu> wrote:
found the bug and i've uploaded the -H3 patch to:
http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.7-bk20-H3
(i've re-tested all 4 modes and they all work on my box.)
Ingo
The note says
that you should be able to switch from the four modes of
operation at will while the machine is running. Is that true?
it's true, it should work. This is probably a bug in the patch.
Investigating it. 
10:18 a.m.
On Sat, 10 Jul 2004 10:15:21 +0200
Ingo Molnar <mingo(a)elte.hu> wrote:
* Ingo Molnar <mingo(a)elte.hu> wrote:
found the bug and i've uploaded the -H3 patch to:
http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.7-bk20-H3
(i've re-tested all 4 modes and they all work on my box.)
Hi, chiming in late. I experienced the same. When i booted into the patched kernel
voountary_preemption was on. But when i tried to turn on kernel_preemption, too, it
immeaditly crashed.. will try your new patch now..
flo
--
Palimm Palimm!
http://affenbande.org/~tapas/wiki
The note
says that you should be able to switch from the four modes of
operation at will while the machine is running. Is that true?
it's true, it should work. This is probably a bug in the patch.
Investigating it.
12 Jul
12 Jul
10:34 a.m.
On Sat, 10 Jul 2004 14:15:47 +0200
Florian Schmidt <mista.tapas(a)gmx.net> wrote:
Hi, chiming in late. I experienced the same. When i
booted into the patched kernel voountary_preemption was on. But when i tried to turn on
kernel_preemption, too, it immeaditly crashed.. will try your new patch now..
Ok, no more crashing, but i don't see any substantial improvement either. Actually
i'm not sure i saw any improvement. I use JACK with a periodsize of 512 frames. At a
framerate of 48khz this equals a time of 512/48000secs = 0.010667secs. So basically jack
has about 10msecs to produce the next period while another one is playing. But: No matter
which 2.6.x kernel i use i always can trigger xruns by either
1] many window manager ops [like rapid desktop wheeling in fluxbox]
2] compiling a kernel in some other term
Mind you i talk about just jackd alone, no clients connected, etc, same thing as user and
as root. As root it doesn't even make a difference if i export LD_ASSUME_KERNEL in
jackd's process.. And yes, jackd runs in th SCHED_FIFO scheduling class with no other
SCHED_FIFO process fighting for cpu time..
mango:~# LD_ASSUME_KERNEL=2.4.19 jackd -R -d alsa -p512
jackd 0.98.1
Copyright 2001-2003 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
loading driver ..
creating alsa driver ... hw:0|hw:0|512|2|48000|0|0|nomon|swmeter|-|32bit
control device hw:0
configuring for 48000Hz, period = 512 frames, buffer = 2 periods
Couldn't open hw:0 for 32bit samples trying 24bit instead
Couldn't open hw:0 for 24bit samples trying 16bit instead
Couldn't open hw:0 for 32bit samples trying 24bit instead
Couldn't open hw:0 for 24bit samples trying 16bit instead
**** alsa_pcm: xrun of at least 0.057 msecs
**** alsa_pcm: xrun of at least 0.033 msecs
**** alsa_pcm: xrun of at least 0.117 msecs
Behviour was substantially better with 2.4.x + ll + preempt. I could compile a kernel, do
other stuff AND run an ardour session with 4 tracks w/o xruns at all for hours..
So, i hope that maybe you, Ingo, know a way on how to provide more useful info for you
kernel development people. I read somewhere about ALSA's xrun debugging. Which kernel
options and boottime parameters do i need for this? Is there a sysctl to switch it on?
What file is the log dumped, too..
I also read on lkml about some latency Instrumentation patch for the 2.6.x kernels to find
out where kernel latencies are happening.. Maybe you can provide a simple howto on how to
use all that stuff to provide better infos for you..
Maybe the best is to assume that we start out with a clean 2.6.7 vanilla kernel source.
Please tell us which patches to apply to get useful results.
thanks for all the great kernel work btw. You guys rock! :)
Florian Schmidt
--
Palimm Palimm!
http://affenbande.org/~tapas/wiki
10:36 a.m.
On Mon, 12 Jul 2004 14:32:22 +0200
Florian Schmidt <mista.tapas(a)gmx.net> wrote:
produce the next period while another one is playing. But: No matter which 2.6.x kernel i
use i always can trigger xruns by either
1] many window manager ops [like rapid desktop wheeling in fluxbox]
2] compiling a kernel in some other term
Mind you i talk about just jackd alone, no clients connected, etc, same thing as user and
as root. As root it doesn't even make a difference if i export LD_ASSUME_KERNEL in
jackd's process.. And yes, jackd runs in th SCHED_FIFO scheduling class with no other
SCHED_FIFO process fighting for cpu time..
Ah, i forgot to say, that turning on/off kernel/volountary_preemption does not seem to
have any effect on this.. well, i think i saw more xruns with both turned off.. but
i'm not sure..
flo
--
Palimm Palimm!
http://affenbande.org/~tapas/wiki
7240
days inactive
7242
days old
linux-audio-dev@lists.linuxaudio.org
4 comments
2 participants
participants (2)
-
Florian Schmidt -
Ingo Molnar