26 Mar
2009
26 Mar
'09
3:52 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
We've got a winner! 2.6.29-rt1
I've just succeeded with a few tests: jackd realtime (64fpp with a USB
UA25) recording/playing Audio and MIDI with qtractor & qsynth and I
played a 32 channel ardour session - no xrun in sight!
I know this is old news since 64studio already ships a 2.6.29
pre-release - However, I run a debian squeeze/sid and
2.6.29-release-candidates were causing an OOPS on this system.
As it turned out it was caused by "irqbalance"! It took me quite a while
to track down that the rt kernel is no longer compatible with irqbalance
(it works fine with 2.6.24-rt).
Here's a debian package built for core2:
http://rg42.org/_media/wiki/kernel/linux-image-2.6.29-rt1_2.6.29-rt1-10.00.…
and the corresponding .config file:
http://rg42.org/_media/wiki/kernel/config-2.6.29-rt1.txt
kudos to the rt-linux devs.
have fun,
robin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAknLzvgACgkQeVUk8U+VK0KgfwCfWyxyyVYMDVx+CNLFzUL3kf57
b48An1WorJjnPNFEDWjv3mUjFrjpvj1Q
=B4PU
-----END PGP SIGNATURE-----
26 Mar
26 Mar
5:13 p.m.
On Thu, 26 Mar 2009 19:52:40 +0100
Robin Gareus <robin(a)gareus.org> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
We've got a winner! 2.6.29-rt1
I've just succeeded with a few tests: jackd realtime (64fpp with a USB
UA25) recording/playing Audio and MIDI with qtractor & qsynth and I
played a 32 channel ardour session - no xrun in sight!
I know this is old news since 64studio already ships a 2.6.29
pre-release - However, I run a debian squeeze/sid and
2.6.29-release-candidates were causing an OOPS on this system.
As it turned out it was caused by "irqbalance"! It took me quite a
while to track down that the rt kernel is no longer compatible with
irqbalance (it works fine with 2.6.24-rt).
Here's a debian package built for core2:
http://rg42.org/_media/wiki/kernel/linux-image-2.6.29-rt1_2.6.29-rt1-10.00.…
and the corresponding .config file:
http://rg42.org/_media/wiki/kernel/config-2.6.29-rt1.txt
kudos to the rt-linux devs.
have fun,
robin
I compiled 2.6.29-rc8-rt4 yesterday and 2.6.29-rt1 today (my first self
compiled kernels). I happen to have the same interface and it seems to
work well here so far, everything seems to work and misbehaving
applications still produce xruns.
Thanks for the warning about irqbalance, I was about to try it..
(Is this the script by fernando lopez leczano or something else?)
If someone is interested I have a buildscript and config for arch linux.
It's probably not optimal, I don't know enough about kernels for that,
but it works.
Best regards
Philipp
5:30 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hollunder(a)gmx.at wrote:
On Thu, 26 Mar 2009 19:52:40 +0100
Robin Gareus <robin(a)gareus.org> wrote:
Congrats. welcome to the club ;)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
We've got a winner! 2.6.29-rt1
I've just succeeded with a few tests: jackd realtime (64fpp with a USB
UA25) recording/playing Audio and MIDI with qtractor & qsynth and I
played a 32 channel ardour session - no xrun in sight!
I know this is old news since 64studio already ships a 2.6.29
pre-release - However, I run a debian squeeze/sid and
2.6.29-release-candidates were causing an OOPS on this system.
As it turned out it was caused by "irqbalance"! It took me quite a
while to track down that the rt kernel is no longer compatible with
irqbalance (it works fine with 2.6.24-rt).
Here's a debian package built for core2:
http://rg42.org/_media/wiki/kernel/linux-image-2.6.29-rt1_2.6.29-rt1-10.00.…
and the corresponding .config file:
http://rg42.org/_media/wiki/kernel/config-2.6.29-rt1.txt
kudos to the rt-linux devs.
have fun,
robin
I compiled 2.6.29-rc8-rt4 yesterday and 2.6.29-rt1 today (my first self
compiled kernels). I happen to have the same interface and it seems to
work well here so far, everything seems to work and misbehaving
applications still produce xruns.
How do you define "misbehaving" ?!
I managed to crash ardour3 and that got me an xrun - but I've got no
complaints there ;)
Thanks for the warning about irqbalance, I was about
to try it..
(Is this the script by fernando lopez leczano or something else?)
It is not Rui's rtirq script. You should definitely get that:
http://www.rncbc.org/jack/rtirq-20090131.tar.gz
"irqbalance" is a different beast. By default all IRQs are handled by
the first CPU only. If you have a SMP system irqbalance can distribute
interrupt handling to all available CPUs.
robin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAknL5fAACgkQeVUk8U+VK0JY9wCeLox88WC6kCRfuDHxR6dEJlbK
aI4AmQEMyReD1O8MaW/yM7dGn66dLGBP
=NwB4
-----END PGP SIGNATURE-----
5:40 p.m.
On Thu, 2009-03-26 at 19:52 +0100, Robin Gareus wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
We've got a winner! 2.6.29-rt1
Hmmmm, getting close but not yet a winner :-)
I've been tracking the 2.6.29 rcx series and I'm still having some
problems. 2.6.29-rt1 still does not shutdown correctly with my kernel
configuration options (you need to specify "noreplace-smp" in the kernel
startup line for shutdown to happen - otherwise you get a problem at the
very end of the halt and the machine does not power down).
And I have seen it hung (hard) the whole machine where a normal kernel
would just work. I'm still trying to find a way to debug that.
-- Fernando
I've just succeeded with a few tests: jackd
realtime (64fpp with a USB
UA25) recording/playing Audio and MIDI with qtractor & qsynth and I
played a 32 channel ardour session - no xrun in sight!
I know this is old news since 64studio already ships a 2.6.29
pre-release - However, I run a debian squeeze/sid and
2.6.29-release-candidates were causing an OOPS on this system.
As it turned out it was caused by "irqbalance"! It took me quite a while
to track down that the rt kernel is no longer compatible with irqbalance
(it works fine with 2.6.24-rt).
Here's a debian package built for core2:
http://rg42.org/_media/wiki/kernel/linux-image-2.6.29-rt1_2.6.29-rt1-10.00.…
and the corresponding .config file:
http://rg42.org/_media/wiki/kernel/config-2.6.29-rt1.txt
kudos to the rt-linux devs.
have fun,
robin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAknLzvgACgkQeVUk8U+VK0KgfwCfWyxyyVYMDVx+CNLFzUL3kf57
b48An1WorJjnPNFEDWjv3mUjFrjpvj1Q
=B4PU
-----END PGP SIGNATURE-----
_______________________________________________
Linux-audio-tuning mailing list
Linux-audio-tuning(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-tuning
6:20 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fernando Lopez-Lezcano wrote:
On Thu, 2009-03-26 at 19:52 +0100, Robin Gareus
wrote:
We've got a winner! 2.6.29-rt1
This is related to your BIOS or motherboard. Do you have the same
problem with a vanilla 2.6.29?
Since I only did reboots, I just performed a shutdown to check and it
powers off just fine. I don't use any boot options (only "root=xx quiet
ro") on this dual-core intel.
Why shut-down, anyway? s2ram and s2disk work fine with 2.6.29-rt1. I'm
very very happy (-:
Hmmmm, getting close but not yet a winner :-)
> I've been tracking the 2.6.29 rcx series and I'm still having some
> problems. 2.6.29-rt1 still does not shutdown correctly with my kernel
> configuration options (you need to specify "noreplace-smp" in the kernel
> startup line for shutdown to happen - otherwise you get a problem at the
> very end of the halt and the machine does not power down). > And I have seen it hung (hard) the whole machine
where a normal kernel
> would just work. I'm still trying to find a way to debug that.
I did not have those for a long time (~2years), previously I experienced
hard lockups when using wifi (iwl3945) and rtirq.
I dare say there's no way to debug that - but you should ask that on
rt-linux list. There's ways to tweak things in /proc/sys/kernel/sched_*
if this lock-up is caused by a runaway process.
It could also be CPU overheating, but then the problem should also occur
with non realtime kernels as well.
robin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAknL8bAACgkQeVUk8U+VK0KoCgCggXU8WvZhiy36i0NtagBy4nqw
lroAoKHWWMBmZP9w5VUY+WJXY1rNs5BM
=B1qh
-----END PGP SIGNATURE-----
27 Mar
27 Mar
9:57 a.m.
On Thu, 26 Mar 2009 22:20:48 +0100
Robin Gareus <robin(a)gareus.org> wrote:
I do have lockups with any kernel and I'm
reasonably certain that it's
a hardware failure, probably the mainboard and something related to
graphics. Is there a way to check if it's only X that locked completely
or if it's the whole machine?
Philipp
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fernando Lopez-Lezcano wrote:
I had that shutdown problem at first as well (with 2.6.29-rc8-rt4),
simply because I had all power saving options disabled. Then I
built 2.6.26-rt1 and I had changed it, but it didn't power off and
after checking the config file it turned out that the changes weren't
there. Compiled again today and it works now.
Basically I just enabled acpi, but only a rather minimal set
(CONFIG_ACPI_BUTTON=y, CONFIG_ACPI_FAN=y) but I guess you know that
kind of stuff far better than me. But maybe there's some weirdness with
your config as well?
On Thu, 2009-03-26 at 19:52 +0100, Robin Gareus
wrote:
We've got a winner! 2.6.29-rt1
This is related to your BIOS or motherboard. Do you have the same
problem with a vanilla 2.6.29?
Since I only did reboots, I just performed a shutdown to check and it
powers off just fine. I don't use any boot options (only "root=xx
quiet ro") on this dual-core intel.
Why shut-down, anyway? s2ram and s2disk work fine with 2.6.29-rt1. I'm
very very happy (-: Hmmmm, getting close but not yet a winner :-)
> I've been tracking the 2.6.29 rcx series and I'm still having some
> problems. 2.6.29-rt1 still does not shutdown correctly with my
> kernel configuration options (you need to specify "noreplace-smp"
> in the kernel startup line for shutdown to happen - otherwise you
> get a problem at the very end of the halt and the machine does not
> power down). > And I have
seen it hung (hard) the whole machine where a normal
> kernel would just work. I'm still trying to find a way to debug
> that.
I did not have those for a long time (~2years), previously I
experienced hard lockups when using wifi (iwl3945) and rtirq.
I dare say there's no way to debug that - but you should ask that on
rt-linux list. There's ways to tweak things
in /proc/sys/kernel/sched_* if this lock-up is caused by a runaway
process.
It could also be CPU overheating, but then the problem should also
occur with non realtime kernels as well.
robin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAknL8bAACgkQeVUk8U+VK0KoCgCggXU8WvZhiy36i0NtagBy4nqw
lroAoKHWWMBmZP9w5VUY+WJXY1rNs5BM
=B1qh
-----END PGP SIGNATURE-----
9:59 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hollunder(a)gmx.at wrote:
I do have lockups with any kernel and I'm
reasonably certain that it's
a hardware failure, probably the mainboard and something related to
graphics. Is there a way to check if it's only X that locked completely
or if it's the whole machine?
you can try to `ping` it, or do a ssh login.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAknMzb0ACgkQeVUk8U+VK0Kv0gCfRCM5nzCwBPRy1t2bUXSd450G
Pe0AniUeNUNtWakhjQSnIyC/+hVDGEvI
=r1xf
-----END PGP SIGNATURE-----
10:02 a.m.
Robin Gareus wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hollunder(a)gmx.at wrote:
> I do have lockups with any kernel and I'm reasonably certain that it's
> a hardware failure, probably the mainboard and something related to
> graphics. Is there a way to check if it's only X that locked completely
> or if it's the whole machine?
>
Maybe it something with the irqbalance?
http://linuxmusicians.com/viewtopic.php?f=24&t=972&start=0#p5043
2:23 p.m.
On Thu, 2009-03-26 at 22:20 +0100, Robin Gareus wrote:
Yes, no hardware problems AFAICT.
-- Fernando
Fernando Lopez-Lezcano wrote:
I have not tested with vanilla 2.6.29 but the problem happens in several
very different machines. I have sent feedback to lkml/Thomas/Ingo.
On Thu, 2009-03-26 at 19:52 +0100, Robin Gareus
wrote:
We've got a winner! 2.6.29-rt1
This is related to your BIOS or motherboard. Do you have the same
problem with a vanilla 2.6.29? Hmmmm, getting close but not yet a winner :-)
> I've been tracking the 2.6.29 rcx series and I'm still having some
> problems. 2.6.29-rt1 still does not shutdown correctly with my kernel
> configuration options (you need to specify "noreplace-smp" in the kernel
> startup line for shutdown to happen - otherwise you get a problem at the
> very end of the halt and the machine does not power down). Since I only did reboots, I just performed a shutdown
to check and it
powers off just fine. I don't use any boot options (only "root=xx quiet
ro") on this dual-core intel.
Why shut-down, anyway? s2ram and s2disk work fine with 2.6.29-rt1. I'm
very very happy (-:
Ok, I'll never turn off the machine and thus conclude there is no
bug! :-)
> And I have
seen it hung (hard) the whole machine where a normal kernel
> would just work. I'm still trying to find a way to debug that.
I did not have those for a long time (~2years), previously I experienced
hard lockups when using wifi (iwl3945) and rtirq.
I dare say there's no way to debug that - but you should ask that on
rt-linux list. There's ways to tweak things in /proc/sys/kernel/sched_*
if this lock-up is caused by a runaway process.
It could also be CPU overheating, but then the problem should also occur
with non realtime kernels as well.
2:27 p.m.
Fernando Lopez-Lezcano wrote:
On Thu, 2009-03-26 at 22:20 +0100, Robin Gareus
wrote:
Can you upload your .config ? It might also be some missing ACPI option.
2c,
robin
Fernando Lopez-Lezcano wrote:
I have not tested with vanilla 2.6.29 but the problem happens in several
very different machines. I have sent feedback to lkml/Thomas/Ingo.
On Thu, 2009-03-26 at 19:52 +0100, Robin Gareus
wrote:
We've got a winner! 2.6.29-rt1
> Hmmmm, getting close but not yet a winner :-)
> I've been tracking the 2.6.29 rcx series and I'm still having some
> problems. 2.6.29-rt1 still does not shutdown correctly with my kernel
> configuration options (you need to specify "noreplace-smp" in the kernel
> startup line for shutdown to happen - otherwise you get a problem at the
> very end of the halt and the machine does not power down).
This is related to
your BIOS or motherboard. Do you have the same
problem with a vanilla 2.6.29?
4:09 p.m.
On Fri, 27 Mar 2009 10:21:28 -0700
Fernando Lopez-Lezcano <nando(a)ccrma.Stanford.EDU> wrote:
On Thu, 2009-03-26 at 22:20 +0100, Robin Gareus
wrote:
Yes, no hardware problems AFAICT.
-- Fernando
After today I'd say I do have a lot more lockups than I
had with my distro's default preempt but non-rt 2.6.28 kernel.
Also have yet to try vanilla 2.6.29.
I'd also like to have a look at your config if possible, I hear good
things about your kernels.
Best regards,
Philipp
Fernando Lopez-Lezcano wrote:
I have not tested with vanilla 2.6.29 but the problem happens in
several very different machines. I have sent feedback to
lkml/Thomas/Ingo.
On Thu, 2009-03-26 at 19:52 +0100, Robin Gareus
wrote:
We've got a winner! 2.6.29-rt1
This is related to your BIOS or motherboard. Do you have the same
problem with a vanilla 2.6.29? Hmmmm, getting close but not yet a winner :-)
> I've been tracking the 2.6.29 rcx series and I'm still having
> some problems. 2.6.29-rt1 still does not shutdown correctly with
> my kernel configuration options (you need to specify
> "noreplace-smp" in the kernel startup line for shutdown to
> happen - otherwise you get a problem at the very end of the halt
> and the machine does not power down). Since I only did reboots, I just performed a
shutdown to check and
it powers off just fine. I don't use any boot options (only
"root=xx quiet ro") on this dual-core intel.
Why shut-down, anyway? s2ram and s2disk work fine with 2.6.29-rt1.
I'm very very happy (-:
Ok, I'll never turn off the machine and thus conclude there is no
bug! :-)
> And I
have seen it hung (hard) the whole machine where a normal
> kernel would just work. I'm still trying to find a way to debug
> that.
I did not have those for a long time (~2years), previously I
experienced hard lockups when using wifi (iwl3945) and rtirq.
I dare say there's no way to debug that - but you should ask that on
rt-linux list. There's ways to tweak things
in /proc/sys/kernel/sched_* if this lock-up is caused by a runaway
process.
It could also be CPU overheating, but then the problem should also
occur with non realtime kernels as well.
5794
days inactive
5795
days old
linux-audio-tuning@lists.linuxaudio.org
10 comments
4 participants
participants (4)
-
Fernando Lopez-Lezcano -
Grammostola Rosea -
hollunder＠gmx.at -
Robin Gareus