17 Jan
2006
17 Jan
'06
6:52 p.m.
Has anyone actually got this working? If so how and with what
settings? I've got 2.6.15 with patch-2.6.15-rt2 to compile fine and
boot but the irq handlers seem to use 90% of cpu and the system really
feels like it's chugging, everything takes 10 to 100 times longer to
load, and anything musical is impossible. I'm running amd64 3000 on an
ati chipset based mb. All normal modules, nothing external. I've tried
with a number of older kernels / patches but i'm wondering if there is
a magic collection that actually works. ;-)
Loki
17 Jan
17 Jan
6:55 p.m.
On Wed, 18 Jan 2006 09:52:35 +1100
Loki Davison <loki.davison(a)gmail.com> wrote:
Has anyone actually got this working? If so how and
with what
settings? I've got 2.6.15 with patch-2.6.15-rt2 to compile fine and
boot but the irq handlers seem to use 90% of cpu and the system really
feels like it's chugging, everything takes 10 to 100 times longer to
load, and anything musical is impossible. I'm running amd64 3000 on an
ati chipset based mb. All normal modules, nothing external. I've tried
with a number of older kernels / patches but i'm wondering if there is
a magic collection that actually works. ;-)
Hi,
i'm on X86, so i cannot test to see whether this is reproducable, but i
would suggest you make sure to run the latest version and if the problem
persists, email to ingo (CC to lkml if you feel like it).
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
6:57 p.m.
On Wed, 2006-01-18 at 09:52 +1100, Loki Davison wrote:
Has anyone actually got this working? If so how and
with what
settings? I've got 2.6.15 with patch-2.6.15-rt2 to compile fine and
boot but the irq handlers seem to use 90% of cpu and the system really
feels like it's chugging, everything takes 10 to 100 times longer to
load, and anything musical is impossible. I'm running amd64 3000 on an
ati chipset based mb. All normal modules, nothing external. I've tried
with a number of older kernels / patches but i'm wondering if there is
a magic collection that actually works. ;-)
Which IRQ handlers? Is this an SMP system/kernel? If you enable
latency tracing what does /proc/latency_trace say?
Lee
7:03 p.m.
New subject: [linux-audio-user] Re: x86_64 and ingo's realtime patches, works?
On 1/18/06, Lee Revell <rlrevell(a)joe-job.com> wrote:
On Wed, 2006-01-18 at 09:52 +1100, Loki Davison
wrote:
I'm not currently running it for obvious reasons. I'll reboot and
check but i'm pretty sure it's called something like irq_timer not
actually irq 11 or anything like that. This is a single core, non-smp
system. I haven't got latency tracing enabled, but i'll recompile with
it and check.
Has anyone got it actually working on x86_64 though?
Loki
Has anyone actually got this working? If so how
and with what
settings? I've got 2.6.15 with patch-2.6.15-rt2 to compile fine and
boot but the irq handlers seem to use 90% of cpu and the system really
feels like it's chugging, everything takes 10 to 100 times longer to
load, and anything musical is impossible. I'm running amd64 3000 on an
ati chipset based mb. All normal modules, nothing external. I've tried
with a number of older kernels / patches but i'm wondering if there is
a magic collection that actually works. ;-)
Which IRQ handlers? Is this an SMP system/kernel? If you enable
latency tracing what does /proc/latency_trace say?
Lee
7:30 p.m.
New subject: [linux-audio-user] Re: x86_64 and ingo's realtime patches, works?
On 1/17/06, Loki Davison <loki.davison(a)gmail.com> wrote:
On 1/18/06, Lee Revell <rlrevell(a)joe-job.com>
wrote:
Yes, I had up to 2.6.15-rt1 working but ran into too many problems
with various areas of running a 64 bit system that when I fried my HD
on accident I installed in legacy mode. Too much just didn't work
right. I haven't tried the RT kernel yet to see if certain areas of
the system still break, but already I am happier with the system as a
whole.
On Wed, 2006-01-18 at 09:52 +1100, Loki Davison
wrote:
I'm not currently running it for obvious reasons. I'll reboot and
check but i'm pretty sure it's called something like irq_timer not
actually irq 11 or anything like that. This is a single core, non-smp
system. I haven't got latency tracing enabled, but i'll recompile with
it and check.
Has anyone got it actually working on x86_64 though? Has anyone actually got this working? If so how
and with what
settings? I've got 2.6.15 with patch-2.6.15-rt2 to compile fine and
boot but the irq handlers seem to use 90% of cpu and the system really
feels like it's chugging, everything takes 10 to 100 times longer to
load, and anything musical is impossible. I'm running amd64 3000 on an
ati chipset based mb. All normal modules, nothing external. I've tried
with a number of older kernels / patches but i'm wondering if there is
a magic collection that actually works. ;-)
Which IRQ handlers? Is this an SMP system/kernel? If you enable
latency tracing what does /proc/latency_trace say?
Lee
7:25 p.m.
On Wed Jan 18, 2006 at 09:52:35AM +1100, Loki Davison wrote:
Has anyone actually got this working? If so how and
with what
settings? I've got 2.6.15 with patch-2.6.15-rt2 to compile fine and
boot but the irq handlers seem to use 90% of cpu and the system really
feels like it's chugging, everything takes 10 to 100 times longer to
load, and anything musical is impossible. I'm running amd64 3000 on an
ati chipset based mb. All normal modules, nothing external. I've tried
with a number of older kernels / patches but i'm wondering if there is
a magic collection that actually works. ;-)
proper and stable audio timing and performance from my perspective after trying to get it
for the past year seems to be a holy grail relegated to those running x86_32 hardware and
RME cards...
ive generally tried out ingo's about once every 6 weeks since switching to AMD64.
about 10% of the time the compile fails, and about 90% of the time it compiles fine, and
it freezes anywhere from 3 minutes to an hour after booting, regardless of load or current
activity, it seems to be straight up random kernel lock, with no panic message or
anything..
once it DID actually work, and my card was flawlessly pumping out audio under load and X
server activity and 16 or 32 sample buffers.. i'll never remember the kernel version,
though.
thats with a desktop, with a turion (and X2) the situation is significantly worse,
involving timer drift causing jack problems (recently discussed here) and ive been too
lazy to track down what is the preferred solution/patch/workaround and whether its
compatible with mingo patch or not..
so basically ive been thinking about installing OsuX instead (and just buying a copy even
though im running it on Turion) since its ATI driver is bound to be vastly better and its
GPU-offloaded windowing system less likely to interfere with CoreAudio (i often get
problems even with 2 1024 sample buffers in JACK and a nice -19 (or is that +20?)
Xserver...even with the 1000hz timing resolution./
good luck!
,c
7:35 p.m.
On Tue, 2006-01-17 at 23:25 +0000, cdr wrote:
On Wed Jan 18, 2006 at 09:52:35AM +1100, Loki Davison
wrote:
Does it work on the same hardware with a 32 bit kernel?
Lee
Has anyone actually got this working? If so how
and with what
settings? I've got 2.6.15 with patch-2.6.15-rt2 to compile fine and
boot but the irq handlers seem to use 90% of cpu and the system really
feels like it's chugging, everything takes 10 to 100 times longer to
load, and anything musical is impossible. I'm running amd64 3000 on an
ati chipset based mb. All normal modules, nothing external. I've tried
with a number of older kernels / patches but i'm wondering if there is
a magic collection that actually works. ;-)
proper and stable audio timing and performance from my perspective after trying to get it
for the past year seems to be a holy grail relegated to those running x86_32 hardware and
RME cards... 
7:37 p.m.
On Tue, 2006-01-17 at 23:25 +0000, cdr wrote:
On Wed Jan 18, 2006 at 09:52:35AM +1100, Loki Davison
wrote:
Interesting. I'm running an AMD64 Athlon 3700+ with no problems.
Ardour, JACK, and JAMin run with zero hiccups. Here's how - I'm running
Fedora Core 4 32 bit OS and Planet CCRMA 2.6.14-0.10.rrt.rhfc4.ccrma. I
decided I'd rather record easily and without xruns than live on the
bleeding edge. My system runs like a scalded dawg as we say down here
in the "Sowf".
--
Jan 'Evil Twin' Depner
The Fuzzy Dice
http://myweb.cableone.net/eviltwin69/fuzzy.html
"As we enjoy great advantages from the invention of others, we should be
glad of an opportunity to serve others by any invention of ours, and
this we should do freely and generously."
Benjamin Franklin, on declining patents offered by the governor of
Pennsylvania for his "Pennsylvania Fireplace", c. 1744
Has anyone actually got this working? If so how
and with what
settings? I've got 2.6.15 with patch-2.6.15-rt2 to compile fine and
boot but the irq handlers seem to use 90% of cpu and the system really
feels like it's chugging, everything takes 10 to 100 times longer to
load, and anything musical is impossible. I'm running amd64 3000 on an
ati chipset based mb. All normal modules, nothing external. I've tried
with a number of older kernels / patches but i'm wondering if there is
a magic collection that actually works. ;-)
proper and stable audio timing and performance from my perspective after trying to get it
for the past year seems to be a holy grail relegated to those running x86_32 hardware and
RME cards...
ive generally tried out ingo's about once every 6 weeks since switching to AMD64.
about 10% of the time the compile fails, and about 90% of the time it compiles fine, and
it freezes anywhere from 3 minutes to an hour after booting, regardless of load or current
activity, it seems to be straight up random kernel lock, with no panic message or
anything..
once it DID actually work, and my card was flawlessly pumping out audio under load and X
server activity and 16 or 32 sample buffers.. i'll never remember the kernel version,
though.
thats with a desktop, with a turion (and X2) the situation is significantly worse,
involving timer drift causing jack problems (recently discussed here) and ive been too
lazy to track down what is the preferred solution/patch/workaround and whether its
compatible with mingo patch or not..
so basically ive been thinking about installing OsuX instead (and just buying a copy even
though im running it on Turion) since its ATI driver is bound to be vastly better and its
GPU-offloaded windowing system less likely to interfere with CoreAudio (i often get
problems even with 2 1024 sample buffers in JACK and a nice -19 (or is that +20?)
Xserver...even with the 1000hz timing resolution./
good luck!
,c
8:39 p.m.
New subject: [linux-audio-user] Re: x86_64 and ingo's realtime patches, works?
On 1/18/06, Jan Depner <eviltwin69(a)cableone.net> wrote:
On Tue, 2006-01-17 at 23:25 +0000, cdr wrote:
Lee, i haven't tried the same hardware with rt patched 32 bit kernel.
I'm guessing i'm just sticking to non-rt kernel then... though how the
hell do the studio 64 guys do it? Then again could reinstall whole
system as 32 bit mode...
Loki
On Wed Jan 18, 2006 at 09:52:35AM +1100, Loki
Davison wrote:
trying to
get it for the past year seems to be a holy grail relegated to
those running x86_32 hardware and RME cards...
Has anyone actually got this working? If so how
and with what
settings? I've got 2.6.15 with patch-2.6.15-rt2 to compile fine and
boot but the irq handlers seem to use 90% of cpu and the system really
feels like it's chugging, everything takes 10 to 100 times longer to
load, and anything musical is impossible. I'm running amd64 3000 on an
ati chipset based mb. All normal modules, nothing external. I've tried
with a number of older kernels / patches but i'm wondering if there is
a magic collection that actually works. ;-)
proper and stable audio timing and performance from my perspective after
ive generally tried out ingo's about once every 6 weeks since switching to
AMD64. about 10% of the time the compile fails, and about 90% of the time it
compiles fine, and it freezes anywhere from 3 minutes to an hour after
booting, regardless of load or current activity, it seems to be straight up
random kernel lock, with no panic message or anything..
once it DID actually work, and my card was flawlessly pumping out audio
under load
and X server activity and 16 or 32 sample buffers.. i'll never
remember the kernel version, though.
thats with a desktop, with a turion (and X2) the situation is
significantly worse,
involving timer drift causing jack problems (recently
discussed here) and ive been too lazy to track down what is the preferred
solution/patch/workaround and whether its compatible with mingo patch or
not..
so basically ive been thinking about installing OsuX instead (and just
buying a
copy even though im running it on Turion) since its ATI driver is
bound to be vastly better and its GPU-offloaded windowing system less likely
to interfere with CoreAudio (i often get problems even with 2 1024 sample
buffers in JACK and a nice -19 (or is that +20?) Xserver...even with the
1000hz timing resolution./
good luck!
,c
Interesting. I'm running an AMD64 Athlon 3700+ with no problems.
Ardour, JACK, and JAMin run with zero hiccups. Here's how - I'm running
Fedora Core 4 32 bit OS and Planet CCRMA 2.6.14-0.10.rrt.rhfc4.ccrma. I
decided I'd rather record easily and without xruns than live on the
bleeding edge. My system runs like a scalded dawg as we say down here
in the "Sowf".
--
Jan 'Evil Twin' Depner
The Fuzzy Dice
http://myweb.cableone.net/eviltwin69/fuzzy.html
"As we enjoy great advantages from the invention of others, we should be
glad of an opportunity to serve others by any invention of ours, and
this we should do freely and generously."
Benjamin Franklin, on declining patents offered by the governor of
Pennsylvania for his "Pennsylvania Fireplace", c. 1744
9:05 p.m.
New subject: [linux-audio-user] Re: x86_64 and ingo's realtime patches, works?
On 1/17/06, Loki Davison <loki.davison(a)gmail.com> wrote:
On 1/18/06, Jan Depner <eviltwin69(a)cableone.net> wrote:
> On Tue, 2006-01-17 at 23:25 +0000, cdr wrote:
> > On Wed Jan 18, 2006 at 09:52:35AM +1100, Loki Davison wrote:
> > > Has anyone actually got this working? If so how and with what
> > > settings? I've got 2.6.15 with patch-2.6.15-rt2 to compile fine and
I have had 2.6.15-rt5 working well for a few days on my FC3 x86_64 laptop
with an RME card. rt1-3 weren't worth it.
The new udev (anything greater than .79) is required, however, and thus far
I've been unable to coax it to work entirely properly (permission creating
syntax is different, for example, and FC3's start_udev script fails to start
udev properly... at the moment I'm firing off udev and chmodding -R a+rw
/dev/*, which is ugly....
.config file attached
--
Mike Taht
PostCards From the Bleeding Edge
http://the-edge.blogspot.com
9:08 p.m.
New subject: [linux-audio-user] Re: x86_64 and ingo's realtime patches, works?
config file attached fer sure this time - now the list will probably stomp
on it - send me private email I'll send it along.
On 1/17/06, Mike Taht <mike.taht(a)gmail.com> wrote:
On 1/17/06, Loki Davison <loki.davison(a)gmail.com > wrote:
--
Mike Taht
PostCards From the Bleeding Edge
http://the-edge.blogspot.com
On 1/18/06, Jan Depner <eviltwin69(a)cableone.net> wrote:
I have had 2.6.15-rt5 working well for a few days on my FC3 x86_64 laptop
with an RME card. rt1-3 weren't worth it.
The new udev (anything greater than .79) is required, however, and thus
far I've been unable to coax it to work entirely properly (permission
creating syntax is different, for example, and FC3's start_udev script fails
to start udev properly... at the moment I'm firing off udev and chmodding -R
a+rw /dev/*, which is ugly....
.config file attached
--
Mike Taht
PostCards From the Bleeding Edge
http://the-edge.blogspot.com
On Tue, 2006-01-17 at 23:25 +0000, cdr wrote:
> On Wed Jan 18, 2006 at 09:52:35AM +1100, Loki Davison wrote:
> > Has anyone actually got this working? If so how and with what
> > settings? I've got 2.6.15 with patch-2.6.15-rt2 to compile fine
and
9:34 p.m.
New subject: [linux-audio-user] Re: x86_64 and ingo's realtime patches, works?
On 1/18/06, Mike Taht <mike.taht(a)gmail.com> wrote:
config file attached fer sure this time - now the list
will probably stomp
on it - send me private email I'll send it along.
I got it, will build a rt6 system with it and check how it goes. If
anyone else has positive reports i'd love to hear.
thanks,
Loki
9:40 p.m.
Hi Loki,
I'm running exactly that kernel in 64-bit mode:
mark@lightning ~ $ uname -a
Linux lightning 2.6.15-rt2 #2 PREEMPT Thu Jan 5 16:13:25 PST 2006
x86_64 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux
mark@lightning ~ $
It works OK for me. I'm xrun free at 64/2 on my HDSP 9652 for anywhere
from 2 - 6 hours and then I'll get a flurry of xruns. I see pretty
much the same problems in Aqualung, which doesn't generally mind the
xruns, or Ardour which will usually shut down when they happen. Folks
here have blamed my complicated setup which uses the Gentoo chroot'ed
32-bit environment for web browsing and 32-bit multimedia only, but
I've run the same tests with all of that turned off and still see that
problem.
I see no issues like you are describing with CPU usage, but I'm using
an NForce4 chipset with an ATI PCI Express video card. Possibly it's
an ATI chipset issue.
I could send you a copy of my config file offline.
Cheers,
Mark
On 1/17/06, Loki Davison <loki.davison(a)gmail.com> wrote:
Has anyone actually got this working? If so how and
with what
settings? I've got 2.6.15 with patch-2.6.15-rt2 to compile fine and
boot but the irq handlers seem to use 90% of cpu and the system really
feels like it's chugging, everything takes 10 to 100 times longer to
load, and anything musical is impossible. I'm running amd64 3000 on an
ati chipset based mb. All normal modules, nothing external. I've tried
with a number of older kernels / patches but i'm wondering if there is
a magic collection that actually works. ;-)
Loki
19 Jan
19 Jan
1:22 a.m.
New subject: [linux-audio-user] Re: x86_64 and ingo's realtime patches, works?
Over the last 3 days I conducted the most intense test of Ingo's
realtime patches I've
conducted to date.
Running 2.6.15-rt5 I have simultaneously running on a 1.8Ghz x86_64
Emachines laptop (1GB of memory), w 2displays enabled at 16 bit...
kernel compiled for no kernel debugging except CONFIG_DEBUG_DEADLOCKS:
Jackd (some version post .100)
Linuxsampler (from cvs about 2 months ago)
Rosegarden (also from cvs about 2 months ago)
HDSP sound interface configured at 96khz/128 frames
FC3 std apps:
KDE
Konqueror
Mozilla
Kopete
About 30 ssh tabs in various shell windows
mplayer playing directly from dvd to the laptop's sound card
Rosegarden playing multiple fairly complex midi hour+ long files into
linuxsampler with
the Bardstown 96khz 24 bit piano. The HDSP audio card is configured
for 96Khz 1.9 ms 128 frames...
480MB are out on swap as I write.
Linuxsampler is pulling it's samples from an ext3 formatted firewire drive
The dvd is coming from /dev/hdc.
The dvd's sound is perfect, except when the window is moved, and it
occasionally drops video frames under this workload.
92-100% of cpu is in use and has been in use for 8-16 hrs a day for
the last 3 days 4 hrs.
Linuxsampler's as perfect as it ever gets (I have some sections in
this piece that exaust the available voices and my (older) version of
linuxsampler doesn't quite do voice stealing right)
Rosegarden's timing seems to be dead on, no matter what.
About the only weirdnesses I have are:
my typing (although perfectly interactive!) tends to make the frame
rate on mplayer much more jumpy.
Also, most of my USB devices disappeared early on, and won't come
back. I doubt that's an RT related problem however. (If they were
still here, I'd try a few more devices - at the moment I'm going for a
workload that will crash the machine - with, so far, no luck)
mplayer occasionally gets hung upon looping a few frames for a few
seconds (no dvd access during that time), then continues. I don't
normally run video apps (me: audio biggot), but I'll twiddle with some
things on that after I post this mail... (boost /dev/hdc's irq? try a
different dvd? maybe try it on a less loaded box would be a start. :))
scp performance is dismal - less than a MB/sec on a 100Mbit network (I
have NO cpu left over, so this makes sense). Since most of my SCP's
over over the internet, this doesn't bother me.
Interactive (e.g. typing) performance is excellent. I have been
hacking all day for days without really noticing (aside from the
cacaphony!) that I have been running with a flatlined cpu. I do have
problems under this workload with marking text for copy and paste with
my touchpad. My guess on that one is that X could use a RT thread in
this case for device input...
The only tuning I did was to force jackd, rosegardensequencer, and the
RME IRQ to be realtime (-65,-64,-66 prios respectively)
Over these nearly 3 days of constant operation I've had about 41 xruns (as
best as I can tell, related to major program startup (things like
openoffice) and heavy
swapping). The maximum scheduling latency was 31.177 msec. Finding out
what caused it strikes me as an intensive exercise... and I don't
think anyone in their right mind would run a workload like this.
I'm going to keep it going for as long as I can...
My hat's off to Ingo. I am delighted to see some of this code
(mutexes/HRT) migrating into 2.6.16 mainline.
--
Mike Taht
PostCards From the Bleeding Edge
http://the-edge.blogspot.com
1:26 a.m.
New subject: [linux-audio-user] Re: x86_64 and ingo's realtime patches, works?
On Wed, 2006-01-18 at 21:22 -0800, Mike Taht wrote:
The maximum scheduling latency was 31.177 msec.
Finding out
what caused it strikes me as an intensive exercise... and I don't
think anyone in their right mind would run a workload like this.
It's actually not hard at all, and would be interesting to know.
Just enable the latency tracing options in the kernel configuration,
reset the tracer on boot with "echo 0
/proc/sys/kernel/preempt_max_latency", and post
the contents
of /proc/latency trace after generating some xruns.
Lee
2:58 p.m.
New subject: [linux-audio-user] Re: x86_64 and ingo's realtime patches, works?
Lee Revell wrote:
On Wed, 2006-01-18 at 21:22 -0800, Mike Taht wrote:
Lee,
Could you elaborate a little more on which "kernel hacking" .config
options are needed to do the latency tracing you have referred to a few
times now?
Besides the obvious "Latency Tracing (LATENCY_TRACE)", there are others
such as:
"Wakeup latency timing (WAKEUP_TIMING)" and it's associated histogram
"Non-preemptible critical section latency timing"
(CRITICAL_PREEMPT_TIMING) and it's associated histogram
"Interrupts-off critical section latency timing"
(CRITICAL_IRQSOFF_TIMING) and it's associated histogram
Each warns of increased kernel size and - more importantly - overhead
with these options enabled.
Could you provide a brief overview of:
1) what each of these options do and used for?
2) what to expect from the "increased overhead" in practice?
3) which ones are essential to provide good latency trace feedback?
I suspect the reason many people, myself included, don't already do this
is simply lack of knowledge.
Thanks,
Rick
The maximum scheduling latency was 31.177 msec.
Finding out
what caused it strikes me as an intensive exercise... and I don't
think anyone in their right mind would run a workload like this.
It's actually not hard at all, and would be interesting to know.
Just enable the latency tracing options in the kernel configuration,
reset the tracer on boot with "echo 0
/proc/sys/kernel/preempt_max_latency", and
post the contents
of /proc/latency trace after generating some xruns.
Lee
3:05 p.m.
New subject: [linux-audio-user] Re: x86_64 and ingo's realtime patches, works?
On Thu, 2006-01-19 at 13:57 -0500, Rick Wright wrote:
Lee Revell wrote:
Enable them all but leave the histograms disabled.
Don't worry about the overhead, this is just for debugging.
Lee
On Wed, 2006-01-18 at 21:22 -0800, Mike Taht
wrote:
Lee,
Could you elaborate a little more on which "kernel hacking" .config
options are needed to do the latency tracing you have referred to a few
times now?
Besides the obvious "Latency Tracing (LATENCY_TRACE)", there are others
such as:
"Wakeup latency timing (WAKEUP_TIMING)" and it's associated histogram
"Non-preemptible critical section latency timing"
(CRITICAL_PREEMPT_TIMING) and it's associated histogram
"Interrupts-off critical section latency timing"
(CRITICAL_IRQSOFF_TIMING) and it's associated histogram
Each warns of increased kernel size and - more importantly - overhead
with these options enabled.
Could you provide a brief overview of:
1) what each of these options do and used for?
2) what to expect from the "increased overhead" in practice?
3) which ones are essential to provide good latency trace feedback?
I suspect the reason many people, myself included, don't already do this
is simply lack of knowledge. The maximum scheduling latency was 31.177 msec.
Finding out
what caused it strikes me as an intensive exercise... and I don't
think anyone in their right mind would run a workload like this.
It's actually not hard at all, and would be interesting to know.
Just enable the latency tracing options in the kernel configuration,
reset the tracer on boot with "echo 0
/proc/sys/kernel/preempt_max_latency", and
post the contents
of /proc/latency trace after generating some xruns.
Lee
2:22 a.m.
New subject: [linux-audio-user] Re: x86_64 and ingo's realtime patches, works?
On Wed, 2006-01-18 at 21:22 -0800, Mike Taht wrote:
Running 2.6.15-rt5 I have simultaneously running on a 1.8Ghz x86_64
Emachines laptop (1GB of memory), w 2displays enabled at 16 bit...
kernel compiled for no kernel debugging except CONFIG_DEBUG_DEADLOCKS:
That seems to be a pretty expensive debug option, you'd probably get
much better performance with it off.
Lee
2:45 a.m.
New subject: [linux-audio-user] Re: x86_64 and ingo's realtime patches, works?
Lee:
At the moment, the madwifi-ng drivers compiled for this machine oops
out. It's not RT's fault - in fact the 2.6.15 non-rt kernel just hangs
completely a few seconds into accessing the madwifi card. The machine
survives a bit longer and prints out a reasonable error message when
compiled for RT and CONFIG_DEBUG_DEADLOCKS. I have some hope now that
the mutex code is in 2.6.16 that it will get easier to track down the
problem with madwifi.
I will try tracking down the latency issue as per your previous
mail...after I convince this box to crash somehow...
I tried to accenuate the positive in the last email (I am impressed as
hell), I didn't mention that madwifi issue nor that the default X
driver for this machine is pretty weak (and the proprietary ATI driver
hasn't worked with RT in a long time - though I haven't tried it since
.13)... those ain't issues to solve in this forum.
But, while I was on the mplayer problem, I did make the RTC (IRQ 8)
and DVD's (IRQ 15) IRQ be realtime, and the frame looping problem went
away, the frame rate went up, and cpu usage pegged at 100% with it and
rosegarden/linuxsampler running. I noticed a little bit of timing
issue (purely subjective) with rosegarden, but not much. Without
anything else running but mplayer, cpu use is at 85%. (The default
X.org driver for this card is pretty sad! and this mplayer doesn't
have things like SSE enabled for x86_64)
... and the system is still running. Jeeze, is there anything else I
can throw at this to make if fall over and die? :) I'm going to leave
rosegarden and mplayer looping overnight.
On 1/18/06, Lee Revell <rlrevell(a)joe-job.com> wrote:
On Wed, 2006-01-18 at 21:22 -0800, Mike Taht wrote:
--
Mike Taht
PostCards From the Bleeding Edge
http://the-edge.blogspot.com
Running 2.6.15-rt5 I have simultaneously running on a 1.8Ghz x86_64
Emachines laptop (1GB of memory), w 2displays enabled at 16 bit...
kernel compiled for no kernel debugging except CONFIG_DEBUG_DEADLOCKS:
That seems to be a pretty expensive debug option, you'd probably get
much better performance with it off.
Lee
2:51 a.m.
New subject: [linux-audio-user] Re: x86_64 and ingo's realtime patches, works?
On Wed, 2006-01-18 at 22:45 -0800, Mike Taht wrote:
Lee:
At the moment, the madwifi-ng drivers compiled for this machine oops
out. It's not RT's fault - in fact the 2.6.15 non-rt kernel just hangs
completely a few seconds into accessing the madwifi card. The machine
survives a bit longer and prints out a reasonable error message when
compiled for RT and CONFIG_DEBUG_DEADLOCKS. I have some hope now that
the mutex code is in 2.6.16 that it will get easier to track down the
problem with madwifi.
Please, when posting a report like this, be sure to mention if you are
using any proprietary kernel modules, otherwise it's impossible to
interpret!
Lee
3:05 a.m.
New subject: [linux-audio-user] Re: x86_64 and ingo's realtime patches, works?
I am not using any proprietary kernel modules at present, I was
trying to say was that CONFIG_DEBUG_DEADLOCKS was an artifact of me
trying to debug madwifi earlier in the 2.6.15 release cycle. (I guess
I got onboard this release on 2.6.15-rt2) The module is certainly not
inserted now.
After I get this kernel to crash some different way, or after another
day of surviving the abuse I've been throwing at it, I will rebuild
without CONFIG_DEBUG_DEADLOCKS and with latency tracing enabled. From
a device and driver coverage standpoint I've exercised everything I
can think of, all that remains is how long can it hold up... I've only
had one RT kernel work this good, ever...
I will take up the madwifi issue on the appropriate forum when I have
time to return to it. (and I figure someone else will have solved it
by then)
On 1/18/06, Lee Revell <rlrevell(a)joe-job.com> wrote:
On Wed, 2006-01-18 at 22:45 -0800, Mike Taht wrote:
--
Mike Taht
PostCards From the Bleeding Edge
http://the-edge.blogspot.com
Lee:
At the moment, the madwifi-ng drivers compiled for this machine oops
out. It's not RT's fault - in fact the 2.6.15 non-rt kernel just hangs
completely a few seconds into accessing the madwifi card. The machine
survives a bit longer and prints out a reasonable error message when
compiled for RT and CONFIG_DEBUG_DEADLOCKS. I have some hope now that
the mutex code is in 2.6.16 that it will get easier to track down the
problem with madwifi.
Please, when posting a report like this, be sure to mention if you are
using any proprietary kernel modules, otherwise it's impossible to
interpret!
Lee
5:15 a.m.
New subject: [linux-audio-user] Re: x86_64 and ingo's realtime patches, works?
Mike Taht <mike.taht(a)gmail.com>om>:
Over these nearly 3 days of constant operation
I've had
about 41 xruns (as best as I can tell, related to major
program startup (things like openoffice) and heavy
swapping). The maximum scheduling latency was 31.177 msec.
Have you tried cdparanoia / cdrecord as workload?
1:40 p.m.
New subject: [linux-audio-user] Re: x86_64 and ingo's realtime patches, works?
On Thu, 2006-01-19 at 10:16 +0100, Wolfgang Woehl wrote:
Mike Taht <mike.taht(a)gmail.com>om>:
What would be the point of that? cdrecord runs at the maximum RT
priority so of course it will cause xruns, it's the expected behavior.
Lee
Over these nearly 3 days of constant operation
I've had
about 41 xruns (as best as I can tell, related to major
program startup (things like openoffice) and heavy
swapping). The maximum scheduling latency was 31.177 msec.
Have you tried cdparanoia / cdrecord as workload?
7:21 p.m.
New subject: [linux-audio-user] Re: x86_64 and ingo's realtime patches, works?
Lee Revell <rlrevell(a)joe-job.com>om>:
On Thu, 2006-01-19 at 10:16 +0100, Wolfgang Woehl
wrote:
Ah ok, I never looked closer. Do you know whether this maximum
priority for cdrecord and the like is still a necessity on
contemporary machines and kernels?
Wolfgang
Mike Taht <mike.taht(a)gmail.com>om>:
What would be the point of that? cdrecord runs at the
maximum RT priority so of course it will cause xruns, it's
the expected behavior. Over these nearly 3 days of constant operation
I've had
about 41 xruns (as best as I can tell, related to major
program startup (things like openoffice) and heavy
swapping). The maximum scheduling latency was 31.177
msec.
Have you tried cdparanoia / cdrecord as workload? 
20 Jan
20 Jan
12:53 a.m.
New subject: [linux-audio-user] Re: Re: x86_64 and ingo's realtime patches, works?
Wolfgang Woehl <tito(a)rumford.de>de>, on Fri Jan 20, 2006 [12:22:12 AM] said:
Lee Revell <rlrevell(a)joe-job.com>om>:
Hi;
Its never been a necessity in my experience. It is, rather
a safeguard against buffer underruns. Ive never bothered to run it
suid root, or as root. Or rather, I have avoided doing that.
Paul
set(a)pobox.com
On Thu, 2006-01-19 at 10:16 +0100, Wolfgang Woehl
wrote:
Ah ok, I never looked closer. Do you know whether this maximum
priority for cdrecord and the like is still a necessity on
contemporary machines and kernels?
Wolfgang
Mike Taht <mike.taht(a)gmail.com>om>:
What would be the point of that? cdrecord runs at the
maximum RT priority so of course it will cause xruns, it's
the expected behavior. Over these nearly 3 days of constant operation
I've had
about 41 xruns (as best as I can tell, related to major
program startup (things like openoffice) and heavy
swapping). The maximum scheduling latency was 31.177
msec.
Have you tried cdparanoia / cdrecord as workload?
6976
days inactive
6978
days old
linux-audio-user@lists.linuxaudio.org
24 comments
11 participants
participants (11)
-
cdr -
Florian Schmidt -
Jan Depner -
Lee Revell -
Loki Davison -
Mark Knecht -
Mike Taht -
Noah Roberts -
Paul -
Rick Wright -
Wolfgang Woehl