2 Jun
2004
2 Jun
'04
6:22 p.m.
What specific benefits have folks seen by turning on the kernel
preemption patch in a 2.4.19 kernel?
We found that a nasty system crash was fixed by turning off preemption.
The crash would happen fairly reliably by switching between virtual
terminals a number of times. It locked up the system hard. So hard that
we can't really find the problem in the kernel; we just found a
work-around basically by trial and error.
We turned on kernel preemption basically because "everyone was doing
it". We haven't noticed any obvious, serious problems or differences
since turning preemption off.
Does anyone have some suggestions about what differences to expect and
what we might have a closer look at?
Also, we are newbies about reporting this kind of crash. Any clues about
where to report it or ask about it?
Thanks for any help... mo
===================================
Michael Ost, Software Architect
Muse Research, Inc.
most(a)museresearch.com
2 Jun
2 Jun
6:49 p.m.
What specific benefits have folks seen by turning on
the kernel
preemption patch in a 2.4.19 kernel?
From the benchmarks that have been done, the preemption
patch seems to
have only very small benefits when added to the low latency patch. By
itself, it adds on the order of 80-90% of the low latency patch.
We found that a nasty system crash was fixed by turning
off preemption.
The crash would happen fairly reliably by switching between virtual
terminals a number of times. It locked up the system hard. So hard that
we can't really find the problem in the kernel; we just found a
work-around basically by trial and error.
[ ... ]
Also, we are newbies about reporting this kind of
crash. Any clues about
where to report it or ask about it?
compile the kernel with magic-sysrq support. be sure to get back to a
text console before a lock up is expected. when the system locks up,
try using Ctrl-Alt-SysRq-p to find out if the system is stuck in a
loop or something similar. if Ctrl-Alt-SysRq won't work, you have a
completely stuck system and debugging it will be a work of pure
machocism.
7:41 p.m.
On Wednesday 02 June 2004 22.13, Michael Ost wrote:
What specific benefits have folks seen by turning on
the kernel
preemption patch in a 2.4.19 kernel?
2.4 series is not really built for preemption. But...
We found that a nasty system crash was fixed by turning off preemption.
The crash would happen fairly reliably by switching between virtual
terminals a number of times. It locked up the system hard. So hard that
we can't really find the problem in the kernel; we just found a
work-around basically by trial and error.
Do you use a SMP computer? If not then you might have run into something
that could hurt a SMP computer running without preemption...
(Running SMP and preemption is kind of weird. And you may run into additional
problems - per CPU data has also to be protected by spinlocks, etc... )
We turned on kernel preemption basically because "everyone was doing
it". We haven't noticed any obvious, serious problems or differences
since turning preemption off.
Does anyone have some suggestions about what differences to expect and
what we might have a closer look at?
You won't notice much difference unless you run real time processes. But they
will need to be suid root (or some wrapper/helper) to become RT processes,
and many kernels do not ship with multimedia stuff suid...
Also, we are newbies about reporting this kind of crash. Any clues about
where to report it or ask about it?
First - you mention virtual terminals
What video driver are you using? Nvidia?
If that is the case retest with xfree86 (nv)
Second - try to what is happening (Magic SysRq)
Third - 2.4.19 is kind of old now (not that many will be interested...),
upgrade and try to reproduce.
/RogerL
--
Roger Larsson
Skellefteå
Sweden
3 Jun
3 Jun
3:09 a.m.
On Wed, 2004-06-02 at 14:26, Roger Larsson wrote:
Nope. No SMP.
We have a couple of SCHED_RR r/t threads running; and the app does run
as root. This is what I guess you would call an embedded Linux system: a
vst player on x86 hardware in a rack mount box (called Receptor; sketchy
info at http://www.museresearch.com). It's using Linux and Wine and a
bunch of our own code.
Hmmm. It's onboard video. I'll have to look into that. I'll see if there
is any xfree86 more specific to our hardware.
We found that
a nasty system crash was fixed by turning off preemption.
The crash would happen fairly reliably by switching between virtual
terminals a number of times. It locked up the system hard. So hard that
we can't really find the problem in the kernel; we just found a
work-around basically by trial and error.
Do you use a SMP computer? If not then you might have run into something
that could hurt a SMP computer running without preemption...
(Running SMP and preemption is kind of weird. And you may run into additional
problems - per CPU data has also to be protected by spinlocks, etc... )
We turned on kernel preemption basically because "everyone was doing
it". We haven't noticed any obvious, serious problems or differences
since turning preemption off.
Does anyone have some suggestions about what differences to expect and
what we might have a closer look at?
You won't notice much difference unless you run real time processes. But they
will need to be suid root (or some wrapper/helper) to become RT processes,
and many kernels do not ship with multimedia stuff suid...
Also, we are newbies about reporting this kind of crash. Any clues about
where to report it or ask about it?
First - you mention virtual terminals
What video driver are you using? Nvidia?
If that is the case retest with xfree86 (nv) Second - try to what is happening (Magic SysRq)
Yes. We'll give that go.
Third - 2.4.19 is kind of old now (not that many will
be interested...),
upgrade and try to reproduce.
We're stuck with it for the time being. It's too close to shipping to
switch over.
Thanks, Roger! ... mo
5:42 a.m.
Hi,
What specific benefits have folks seen by turning on
the kernel
preemption patch in a 2.4.19 kernel?
We found that a nasty system crash was fixed by turning off preemption.
The crash would happen fairly reliably by switching between virtual
terminals a number of times. It locked up the system hard. So hard that
we can't really find the problem in the kernel; we just found a
work-around basically by trial and error.
Both preempt and ll are known to cause deadlocks on 2.4. If you want a rock
solid system i recommend to go either with vanilla 2.4 or even better 2.6.
There is an interesting thread about scheduling latency going on on
fedora-devel:
http://www.redhat.com/archives/fedora-devel-list/2004-June/msg00031.html
Regards,
Florian
---
-> Florian Schirmer -> Software Developer
-> NATIVE INSTRUMENTS GmbH -> florian.schirmer(a)native-instruments.de
-> Schlesische Straße 28 -> http://www.native-instruments.de
-> D-10997 Berlin -> Tel. +49-30-61 10 35-453
-> Germany -> Fax +49-30-61 10 35-35
----
New products:
GUITAR RIG - the complete solution for perfect guitar sound
=> http://www.ni-guitar-rig.com
XPRESS KEYBOARDS - xpress versions of PRO-53, FM7, and B4
=> http://www.ni-xpress-keyboards.com
>>>>> NATIVE INSTRUMENTS - Generate the
Future of Sound! <<<<<<
3:09 p.m.
On Thu, 2004-06-03 at 00:34, Florian Schirmer wrote:
Both preempt and ll are known to cause deadlocks on
2.4. If you want a rock
solid system i recommend to go either with vanilla 2.4 or even better 2.6.
Thanks, Florian. What do you mean by 'vanilla' 2.4? Straight from
kernel.org? Ours does come, originally, from RH8.
- mo
7610
days inactive
7611
days old
linux-audio-dev@lists.linuxaudio.org
6 comments
4 participants
participants (4)
-
Florian Schirmer -
Michael Ost -
Paul Davis -
Roger Larsson