7 Sep
2004
7 Sep
'04
7:31 p.m.
Hey,
Now that the final touches are being put on the 2.6 low latency patches,
a massive migration of linux audio users to 2.6 is imminent. Since this
means every single linux audio user will need the realtime-lsm module, I
think we should push to get it in the kernel, the sooner the better.
Why make every user go through the extra step of downloading and
installing it? It's only a few hundred lines of code, and while I don't
consider myself a kernel expert I can grok it easily. I can't imagine
there would be much resistance, especially considering how much easier
this would make life for every audio-oriented distro.
This fits the new kernel development model very well, one of its stated
goals is to get the features that vendors and users need and that they
currently have to patch the kernel to get, into the mainstream kernel.
Anyway if the author does not object, I would be willing to spearhead a
drive to get this into the kernel. I am sure they will approve as soon
as 100s linux audio users voice their approval...
Lee
7 Sep
7 Sep
8:50 p.m.
New subject: [linux-audio-dev] Re: [Jackit-devel] realtime-lsm in the kernel
Hi Lee,
Now that the final touches are being put on the 2.6 low latency patches,
a massive migration of linux audio users to 2.6 is imminent. Since this
means every single linux audio user will need the realtime-lsm module, I
think we should push to get it in the kernel, the sooner the better.
Count my vote in.
BTW ...
I'm having some trouble with latest VP patches on my P4 HT/SMP box. The
trouble is that since Q5 that I can't get my machine to boot reliably, if
at all. It goes almost all through the init scripts to drop dead on the
beach, so to speak. It just freezes completely somewhere before the login
prompts.
This only happens if the kernel is configured for SMP/SMT
(HyperThreading). The very same kernel configured and built for UP boots
and runs fine. As I said before this was introduced on the Q5 patch, and
the same showstopper is present on latest R6. Only with Q3 I'm still
happy, altought only with softirq-preempt=0 AND hardirq-preempt=0.
The "offending" box is a SUSE 9.1 based one, P4 2.80C HT on a ASUS P4P800
mobo, 1GB DDR.
I would like some help in squaring out this mess. I'm feeling left behind
in this VP wagon... Even Ingo's site doesn't list Q3 anymore :(
Lee, could you care giving me some insight on how or who can I point my
thoughts about? ;)
Does anyone else?
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
9:04 p.m.
New subject: [linux-audio-dev] Re: [Jackit-devel] realtime-lsm in the kernel
On Tue, 2004-09-07 at 18:31, Rui Nuno Capela wrote:
Hi Lee,
I posted the above report to LKML and cc'ed you and Ingo. None of the
LKML testers are reporting this problem, it sounds very similar to the
problems others have had with SMP/HT but those were thought to all be
solved.
This is a pretty good report, it should be easy to track this down since
we know exactly when it was introduced.
Has any version worked with softirq or hardirq preemption enabled? What
are the symptoms if you boot Q3 with either of the above enabled?
(Apologies to everyone if this turns into a long tedious kernel
debugging thread, but as you can see it's important for more people to
test these patches before they are ready for widespread use, and to see
what they might be in for ;-))
Lee
Now that the final touches are being put on the 2.6 low latency patches,
a massive migration of linux audio users to 2.6 is imminent. Since this
means every single linux audio user will need the realtime-lsm module, I
think we should push to get it in the kernel, the sooner the better.
Count my vote in.
BTW ...
I'm having some trouble with latest VP patches on my P4 HT/SMP box. The
trouble is that since Q5 that I can't get my machine to boot reliably, if
at all. It goes almost all through the init scripts to drop dead on the
beach, so to speak. It just freezes completely somewhere before the login
prompts.
This only happens if the kernel is configured for SMP/SMT
(HyperThreading). The very same kernel configured and built for UP boots
and runs fine. As I said before this was introduced on the Q5 patch, and
the same showstopper is present on latest R6. Only with Q3 I'm still
happy, altought only with softirq-preempt=0 AND hardirq-preempt=0.
The "offending" box is a SUSE 9.1 based one, P4 2.80C HT on a ASUS P4P800
mobo, 1GB DDR.
I would like some help in squaring out this mess. I'm feeling left behind
in this VP wagon... Even Ingo's site doesn't list Q3 anymore :(
Lee, could you care giving me some insight on how or who can I point my
thoughts about? ;)
Does anyone else?
10:04 p.m.
New subject: [linux-audio-dev] voluntary-preempt-2.6.x-Q5..R6 SMP/HT trouble (was: realtime-lsm in the kernel)
Lee,
Thanks. Yes I was pretty excited with those reports too (I've been lurking
on LKML :), but I just seem to be unlucky. That's why I've been trying one
by one of the patches, from Q5 to R6 and tweaking the available options as
much as I know and time permitted.
OK, could just someone with a P4 HT/SMP box hand me their woring kernel
.config file for me to try? That could be a good starting point, if not a
plain baseline.
I'm having some trouble with latest VP patches on my P4 HT/SMP box. The
trouble is that since Q5 that I can't get my machine to boot reliably,
if at all. It goes almost all through the init scripts to drop dead on
the beach, so to speak. It just freezes completely somewhere before the
login prompts.
This only happens if the kernel is configured for SMP/SMT
(HyperThreading). The very same kernel configured and built for UP
boots and runs fine. As I said before this was introduced on the Q5
patch, and the same showstopper is present on latest R6. Only with Q3
I'm still happy, altought only with softirq-preempt=0 AND
hardirq-preempt=0.
The "offending" box is a SUSE 9.1 based one, P4 2.80C HT on a ASUS
P4P800 mobo, 1GB DDR.
I posted the above report to LKML and cc'ed you and Ingo. None of the
LKML testers are reporting this problem, it sounds very similar to the
problems others have had with SMP/HT but those were thought to all be
solved.
Has any version worked with softirq or hardirq preemption enabled? What
are the symptoms if you boot Q3 with either of the above enabled?
On this box in question, softirq and hardirq-preempt options had NEVER
lead to a stable SMP/HT system, ever since my first rehearsal with VP,
which I think was around O3. UP is quite different, it works and always
worked, as advertised :) FWIW, R6 is pumping hard on my laptop :)
Q3-SMP doesn't pass the KDE 3.3 startup splash if I set softirq=1 or
hardirq=1. The system just hangs. I still keep softirq-preempt=0 and
hardirq-preempt=0 as my Q3-SMP kernel bootloader parameters though.
Hope this gets cleared out. All I can do is offering my best efforts to
dig this out, provided someone give me some hunch ;)
Thanks again.
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
8 Sep
8 Sep
7:48 a.m.
New subject: [linux-audio-dev] Re: [Jackit-devel] realtime-lsm in the kernel
On Tue, 7 Sep 2004, Rui Nuno Capela wrote:
Hi Lee,
There seemed to be much opposition to it on the kernel developer list.
Have you seen the messages?
-mike
Now that the final touches are being put on the 2.6 low latency patches,
a massive migration of linux audio users to 2.6 is imminent.Since this
means every single linux audio user will need the realtime-lsm module, I
think we should push to get it in the kernel, the sooner the better.
4:59 p.m.
New subject: [linux-audio-dev] Re: [Jackit-devel] realtime-lsm in the kernel
On Wednesday 08 September 2004 05:30 am, michael tewner wrote:
On Tue, 7 Sep 2004, Rui Nuno Capela wrote:
LKML is kinda the Paul Masson here. When it's time, it'll be time and not
before.
Hi Lee,
> Now that the final touches are being put on the 2.6 low latency
> patches, a massive migration of linux audio users to 2.6 is
> imminent.Since this means every single linux audio user will need the
> realtime-lsm module, I think we should push to get it in the kernel,
> the sooner the better.
There seemed to be much opposition to it on the kernel developer list.
Have you seen the messages?
-mike
5:07 p.m.
New subject: [linux-audio-dev] Re: [Jackit-devel] realtime-lsm in the kernel
On Wed, 2004-09-08 at 05:30, michael tewner wrote:
On Tue, 7 Sep 2004, Rui Nuno Capela wrote:
Sorry, maybe it was not clear enough from my message or my subject line,
but I am NOT talking about getting the voluntary preemption patches in
the kernel, I am referring to the realtime-lsm module:
http://sourceforge.net/projects/realtime-lsm/
This is a MUCH simpler and MUCH less controversial feature.
What messages are you talking about?
Lee
Hi Lee,
There seemed to be much opposition to it on the kernel developer list.
Have you seen the messages?
Now that the final touches are being put on the 2.6 low latency patches,
a massive migration of linux audio users to 2.6 is imminent.Since this
means every single linux audio user will need the realtime-lsm module, I
think we should push to get it in the kernel, the sooner the better.
2:59 a.m.
New subject: [linux-audio-dev] Re: realtime-lsm in the kernel
Lee Revell <rlrevell(a)joe-job.com> writes:
Anyway if the author does not object, I would be
willing to spearhead a
drive to get this into the kernel. I am sure they will approve as soon
as 100s linux audio users voice their approval...
It's fine with me. I agree that it makes sense, but have not been
willing to hassle with the LKML, myself. Several others have
suggested it in the past, but no one was willing to push it through
the process.
If you do that, I'll help. I have a version in my CVS working tree
that will build as a kernel patch with the appropriate Kconfig and
Makefile updates. Please copy me on any messages you send to the
LKML, I'm not subscribed.
Torben was the original author, and I've been developing and
maintaining it since the end of 2003. I doubt he will object, but he
can speak for himself. :-)
Adding it to the kernel sources would probably make maintenance
easier.
--
joq
3:08 a.m.
New subject: [linux-audio-dev] Re: realtime-lsm in the kernel
On Wed, 2004-09-08 at 00:42, Jack O'Quin wrote:
Lee Revell <rlrevell(a)joe-job.com> writes:
OK, great. I might as well do this before I get sick of LKML and
unsubscribe ;-).
Anyway if the author does not object, I would be
willing to spearhead a
drive to get this into the kernel. I am sure they will approve as soon
as 100s linux audio users voice their approval...
It's fine with me. I agree that it makes sense, but have not been
willing to hassle with the LKML, myself. Several others have
suggested it in the past, but no one was willing to push it through
the process.
If you do that, I'll help. I have a version in my
CVS working tree
that will build as a kernel patch with the appropriate Kconfig and
Makefile updates. Please copy me on any messages you send to the
LKML, I'm not subscribed.
Can you send this to me? I will cc: you and Torben on anything I post.
Torben was the original author, and I've been developing and
maintaining it since the end of 2003. I doubt he will object, but he
can speak for himself. :-)
OK, since it will have his name on it too, I will see if he has any
objections before I post it.
Adding it to the kernel sources would probably make
maintenance
easier.
Yes, definitely. I see many more controversial, more complex, and less
useful features getting added to the kernel all the time, this seems
like a no brainer, because every audio user will need it. Once we get
this in the kernel it will be a one step process (apply Ingo's patches)
to get up and running on 2.6.
Lee
9:30 p.m.
New subject: [linux-audio-dev] Re: [Jackit-devel] Re: realtime-lsm in the kernel
On Wed, 2004-09-08 at 00:42, Jack O'Quin wrote:
Lee Revell <rlrevell(a)joe-job.com> writes:
OK, I am removing LAU from the cc's, as this is now a technical
discussion rather than an opinion poll. ;-)
Are there any known issues with the code that the kernel guys might
bring up? Seems like it has been stable for a while. The only thing I
notices was that the indentation doesn't follow the recommended kernel
style.
I found your original RFC post to the LSM mailing list, I was thinking
of including a pointer to that, as everything in there still seems to
apply.
Also, I assume you are not referring to sourceforge CVS, because I
looked and there aren't any Kconfig patches. Can you commit this to SF
CVS so I can check it out?
Anyway let me know when you have a patch you are comfortable submitting
for inclusion in the kernel and I will go ahead and post it.
Lee
Anyway if the author does not object, I would be
willing to spearhead a
drive to get this into the kernel. I am sure they will approve as soon
as 100s linux audio users voice their approval...
It's fine with me. I agree that it makes sense, but have not been
willing to hassle with the LKML, myself. Several others have
suggested it in the past, but no one was willing to push it through
the process.
If you do that, I'll help. I have a version in my CVS working tree
that will build as a kernel patch with the appropriate Kconfig and
Makefile updates. Please copy me on any messages you send to the
LKML, I'm not subscribed.
Torben was the original author, and I've been developing and
maintaining it since the end of 2003. I doubt he will object, but he
can speak for himself. :-)
Adding it to the kernel sources would probably make maintenance
easier.
10 Sep
10 Sep
2:45 p.m.
New subject: [linux-audio-dev] Re: [Jackit-devel] Re: realtime-lsm in the kernel
Lee Revell <rlrevell(a)joe-job.com> writes:
Are there any known issues with the code that the
kernel guys might
bring up? Seems like it has been stable for a while. The only thing I
notices was that the indentation doesn't follow the recommended kernel
style.
It meets the recommendations I know about. If you point out specific
problems, I'll fix them.
I found your original RFC post to the LSM mailing
list, I was thinking
of including a pointer to that, as everything in there still seems to
apply.
Good idea.
Also, I assume you are not referring to sourceforge
CVS, because I
looked and there aren't any Kconfig patches. Can you commit this to SF
CVS so I can check it out?
That was a working directory. I never committed it because I haven't
figured out a good way to maintain the patches over successive kernel
versions. It doesn't belong in CVS. When I tried it with 2.6.8.1,
the patch failed to apply.
Anyway let me know when you have a patch you are
comfortable submitting
for inclusion in the kernel and I will go ahead and post it.
I am working up a new patch for 2.6.8.1 and testing it today. I'll
send you a copy as soon as it is clean.
--
joq
11 Sep
11 Sep
11:40 a.m.
New subject: [linux-audio-dev] Re: [Jackit-devel] Re: realtime-lsm in the kernel
On Fri, Sep 10, 2004 at 11:29:11AM -0500, Jack O'Quin wrote:
Lee Revell <rlrevell(a)joe-job.com> writes:
i think they will object the allcaps option.
but that one could be left out.
the other options only open doors for DoS attacks.
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
Are there any known issues with the code that the
kernel guys might
bring up? Seems like it has been stable for a while. The only thing I
notices was that the indentation doesn't follow the recommended kernel
style.
It meets the recommendations I know about. If you point out specific
problems, I'll fix them.
2:26 p.m.
New subject: [linux-audio-dev] Re: [Jackit-devel] Re: realtime-lsm in the kernel
torbenh(a)gmx.de writes:
i think they will object the allcaps option. but that
one could be
left out.
the other options only open doors for DoS attacks.
That's a good point.
What if we made allcaps conditional, based on another Kconfig option?
--
joq
12 Sep
12 Sep
2:35 a.m.
New subject: [linux-audio-dev] Re: [Jackit-devel] Re: realtime-lsm in the kernel
On Sat, 2004-09-11 at 12:09, Jack O'Quin wrote:
torbenh(a)gmx.de writes:
Isn't a DoS attack also the worst case scenario with allcaps? Or am I
missing something?
I do not see the objection; assuming there is a legitimate use for
allcaps, the DoS exposure would certainly be less bad than having that
process just run as root. A DoS can't blow away the password file...
Lee
i think they will object the allcaps option. but
that one could be
left out.
the other options only open doors for DoS attacks.
That's a good point.
What if we made allcaps conditional, based on another Kconfig option?
3:16 a.m.
New subject: [linux-audio-dev] Re: [Jackit-devel] Re: realtime-lsm in the kernel
Lee Revell <rlrevell(a)joe-job.com> writes:
Isn't a DoS attack also the worst case scenario
with allcaps? Or am I
missing something?
No, it's not. There is a scenario where an intruder uses SETPCAP to
deny root programs access to resources they need (like system logs).
I don't know all the implications of this, but it is potentially more
damaging than just DoS.
It was because of actual attacks like this that the kernel developers
removed SETPCAP from init's capability set.
I do not see the objection; assuming there is a
legitimate use for
allcaps, the DoS exposure would certainly be less bad than having that
process just run as root. A DoS can't blow away the password file...
Since `allcaps' is an option, you don't have to use it. But, there's
really no requirment for it in a pure 2.6-based system.
The only good reason for `allcaps' that I know of is to run jackstart
the same way in a dual-boot 2.4 and 2.6 environment. Since I do that
a lot, I generally set that option.
For 2.6 users, it is cleaner and more secure not to use allcaps or
jackstart. Just call jackd directly.
--
joq
4:23 a.m.
New subject: [linux-audio-dev] Re: [Jackit-devel] Re: realtime-lsm in the kernel
On Sun, 2004-09-12 at 00:59, Jack O'Quin wrote:
The only good reason for `allcaps' that I know of
is to run jackstart
the same way in a dual-boot 2.4 and 2.6 environment. Since I do that
a lot, I generally set that option.
For 2.6 users, it is cleaner and more secure not to use allcaps or
jackstart. Just call jackd directly.
OK, patch has been posted to LKML...
http://lkml.org/lkml/2004/9/12/22
This would close this debian bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=269661
Lee
5:05 a.m.
New subject: [linux-audio-dev] Re: [Jackit-devel] Re: realtime-lsm in the kernel
On Sun, Sep 12, 2004 at 02:06:53AM -0400, Lee Revell wrote:
OK, patch has been posted to LKML...
http://lkml.org/lkml/2004/9/12/22
Shouldn't you use in_group_p() instead of searching the grouplist
yourself? in the new kernels, groups are sorted, so in_group_p uses a
binary search. Also, the ifdef will never fly. Also, don't put a blank
line after "if (....) {" - you do that in a couple places.
Nitpicking before Linus and Andrew do it for you :)
11 Sep
11 Sep
11:36 a.m.
New subject: [linux-audio-dev] Re: realtime-lsm in the kernel
On Tue, Sep 07, 2004 at 11:42:35PM -0500, Jack O'Quin wrote:
Lee Revell <rlrevell(a)joe-job.com> writes:
of course i wont object :)
i just dont have much time for computers currently so i rarely read
mails...
Anyway if the author does not object, I would be
willing to spearhead a
drive to get this into the kernel. I am sure they will approve as soon
as 100s linux audio users voice their approval...
It's fine with me. I agree that it makes sense, but have not been
willing to hassle with the LKML, myself. Several others have
suggested it in the past, but no one was willing to push it through
the process.
If you do that, I'll help. I have a version in my CVS working tree
that will build as a kernel patch with the appropriate Kconfig and
Makefile updates. Please copy me on any messages you send to the
LKML, I'm not subscribed.
Torben was the original author, and I've been developing and
maintaining it since the end of 2003. I doubt he will object, but he
can speak for himself. :-) Adding it to the kernel sources would probably make
maintenance
easier.
yeah... #ifdefs in structs are pure evil :)
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
9 Sep
9 Sep
10:47 a.m.
New subject: [linux-audio-dev] Re: [linux-audio-user] realtime-lsm in the kernel
On Tue, 07 Sep 2004 17:14:45 -0400
Lee Revell <rlrevell(a)joe-job.com> wrote:
Now that the final touches are being put on the 2.6
low latency
patches, a massive migration of linux audio users to 2.6 is imminent.
Since this means every single linux audio user will need the
realtime-lsm module, I think we should push to get it in the kernel,
the sooner the better.
Go for it. i would definetly like to save the extra step of compiling
the realtime lsm each time i upgrade my kernel.. And i think it might
prove useful even for non audio users.. Often security stuff likes to
mlock small portions of memory, too, etc..
flo
7411
days inactive
7416
days old
linux-audio-dev@lists.linuxaudio.org
18 comments
8 participants
participants (8)
-
Florian Schmidt -
Jack O'Quin -
John Check -
Lee Revell -
michael tewner -
Rui Nuno Capela -
Tim Hockin -
torbenh＠gmx.de