Re: 2.6.11-rc3-mm2: lockup in sys_timer_settime

2005-02-20 Thread Alexander Nyberg
> When running a Posix conformance test (from posixtestsuite), the kernel > locks up with: > > BUG: soft lockup detected on CPU#0 > > Pid: 1873, comm: 10-1.test > EIP: 0060:[] CPU: 0 > EIP is at sys_timer_settime+0xfa+0x1f0 > EFLAGS: 0282 Not tainted (2.6.11-rc3-mm2) > EAX: 0282 EBX: 0

Re: 2.6.11-rc3-mm2

2005-02-14 Thread Stefano Rivoir
Alle 11:35, giovedì 10 febbraio 2005, Andrew Morton ha scritto: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2. >6.11-rc3-mm2/ I was trying to use the skge module for my Intel 3c940 card, in place of the (working) sk98lin. It gives the following: Feb 14 14:16:35 nb

Re: 2.6.11-rc3-mm2

2005-02-13 Thread Werner Almesberger
Ingo Molnar wrote: > the pro applications will always want to have a 100% guarantee (it > really sucks to generate a nasty audio click during a live performance) ... and the "generic kernels" distributions use will follow just as swiftly, as soon as the feature appears stable enough. It even makes

Re: 2.6.11-rc3-mm2

2005-02-12 Thread Olaf Dietsche
Christoph Hellwig <[EMAIL PROTECTED]> writes: > On Thu, Feb 10, 2005 at 02:35:08AM -0800, Andrew Morton wrote: >> >> - Added the mlock and !SCHED_OTHER Linux Security Module for the audio guys. >> It seems that nothing else is going to come along and this is completely >> encapsulated. > > Ev

Re: 2.6.11-rc3-mm2

2005-02-12 Thread Henning Rohde
Hi, Yuval Tanny wrote: > Andrew Morton wrote: >>cachefs-filesystem.patch >> CacheFS filesystem > ... as you mention cachefs - know what's the status of supporting nfs? Or is the project as dead as the mailing-list? Is there any whole-in-one patch relative to vanilla-sources, at best including

Re: 2.6.11-rc3-mm2

2005-02-11 Thread Matt Mackall
On Fri, Feb 11, 2005 at 06:49:05PM +0100, Ingo Molnar wrote: > > * Matt Mackall <[EMAIL PROTECTED]> wrote: > > > > > Yes. There's also the whole soft limit thing. > > > > > > i'm curious, how does this 'per-app' rlimit thing work? If a user has > > > jackd installed and runs it from X unprivileg

Re: 2.6.11-rc3-mm2

2005-02-11 Thread Lee Revell
On Fri, 2005-02-11 at 11:42 -0800, Matt Mackall wrote: > On Fri, Feb 11, 2005 at 12:49:04PM -0500, Paul Davis wrote: > > >RT-LSM introduces architectural problems in the form of bogus API. And > > > > that may be true of LSM, but not RT-LSM in particular. RT-LSM doesn't > > introduce *any* API wha

Re: 2.6.11-rc3-mm2

2005-02-11 Thread Matt Mackall
On Fri, Feb 11, 2005 at 12:49:04PM -0500, Paul Davis wrote: > >RT-LSM introduces architectural problems in the form of bogus API. And > > that may be true of LSM, but not RT-LSM in particular. RT-LSM doesn't > introduce *any* API whatsoever - it simply allows software to call > various existing AP

Re: 2.6.11-rc3-mm2

2005-02-11 Thread Matt Mackall
On Fri, Feb 11, 2005 at 10:53:27AM +0100, Ingo Molnar wrote: > > * Matt Mackall <[EMAIL PROTECTED]> wrote: > > > On Fri, Feb 11, 2005 at 09:59:42AM +0100, Ingo Molnar wrote: > > > > > > think of SCHED_FIFO on the desktop as an ugly wart, a hammer, that > > > destroys the careful balance of prior

Re: 2.6.11-rc3-mm2

2005-02-11 Thread Paul Davis
>RT-LSM introduces architectural problems in the form of bogus API. And that may be true of LSM, but not RT-LSM in particular. RT-LSM doesn't introduce *any* API whatsoever - it simply allows software to call various existing APIs (mostly from POSIX) and have them not fail as result of not being r

Re: 2.6.11-rc3-mm2

2005-02-11 Thread Ingo Molnar
* Matt Mackall <[EMAIL PROTECTED]> wrote: > > > Yes. There's also the whole soft limit thing. > > > > i'm curious, how does this 'per-app' rlimit thing work? If a user has > > jackd installed and runs it from X unprivileged, how does it get the > > elevated rlimit? > > It needs a setuid launche

Re: 2.6.11-rc3-mm2

2005-02-11 Thread Paul Davis
>introduced. See devfs. And I think the adoption barrier thing is a red >herring as well: the current users are by and large compiling their >own RT-tuned kernels. not true. most people are using kernels built for specialized distros or addons, such as CCRMA, Demudi, Ubuntu, or dyne:bolic. --p -

Re: 2.6.11-rc3-mm2

2005-02-11 Thread Yuval Tanny
In fs/Kconfig, See "Documentation/filesystems/fscache.txt for more information." and "See Documentation/filesystems/cachefs.txt for more information." Should be changed to: "See Documentation/filesystems/caching/fscache.txt for more information." and "See Documentation/filesystems/caching/cachef

Re: 2.6.11-rc3-mm2

2005-02-11 Thread Ingo Molnar
* Matt Mackall <[EMAIL PROTECTED]> wrote: > On Fri, Feb 11, 2005 at 09:59:42AM +0100, Ingo Molnar wrote: > > > > think of SCHED_FIFO on the desktop as an ugly wart, a hammer, that > > destroys the careful balance of priorities of SCHED_OTHER tasks. Yes, it > > can be useful if you _need_ a sched

Re: 2.6.11-rc3-mm2

2005-02-11 Thread Matt Mackall
On Fri, Feb 11, 2005 at 09:59:42AM +0100, Ingo Molnar wrote: > > think of SCHED_FIFO on the desktop as an ugly wart, a hammer, that > destroys the careful balance of priorities of SCHED_OTHER tasks. Yes, it > can be useful if you _need_ a scheduling guarantee due to physical > constraints, and it

Re: 2.6.11-rc3-mm2

2005-02-11 Thread Matt Mackall
On Fri, Feb 11, 2005 at 10:04:19AM +0100, Ingo Molnar wrote: > > * Matt Mackall <[EMAIL PROTECTED]> wrote: > > > So the comparison boils down to putting a magic gid in a sysfs > > file/module parameter or setting an rlimit with standard tools (PAM, > > etc). I'm really boggled that anyone could p

Re: 2.6.11-rc3-mm2

2005-02-11 Thread Ingo Molnar
* Matt Mackall <[EMAIL PROTECTED]> wrote: > So the comparison boils down to putting a magic gid in a sysfs > file/module parameter or setting an rlimit with standard tools (PAM, > etc). I'm really boggled that anyone could prefer the former, > especially since we had almost this exact debate over

Re: 2.6.11-rc3-mm2

2005-02-11 Thread Ingo Molnar
* Matt Mackall <[EMAIL PROTECTED]> wrote: > Read more closely: there are two independent limits in the patch, > RLIMIT_NICE and RLIMIT_RTPRIO. This lets us grant elevated nice > without SCHED_FIFO. ok, indeed. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel

Re: 2.6.11-rc3-mm2

2005-02-11 Thread Ingo Molnar
* Matt Mackall <[EMAIL PROTECTED]> wrote: > > i disagree that desktop performance tomorrow will necessarily have to > > utilize SCHED_FIFO. Today's desktop audio applications perform quite > > good at SCHED_NORMAL priorities [with the 2.6.11 kernel that has more > > interactivity/latency fixes su

Re: 2.6.11-rc3-mm2

2005-02-11 Thread Matt Mackall
On Fri, Feb 11, 2005 at 09:48:43AM +0100, Ingo Molnar wrote: > > * Matt Mackall <[EMAIL PROTECTED]> wrote: > > > Here's Chris' patch for reference: > > > > http://groups-beta.google.com/group/linux.kernel/msg/6408569e13ed6e80 > > how does this patch solve the separation of 'negative nice values

Re: 2.6.11-rc3-mm2

2005-02-11 Thread Ingo Molnar
* Matt Mackall <[EMAIL PROTECTED]> wrote: > Here's Chris' patch for reference: > > http://groups-beta.google.com/group/linux.kernel/msg/6408569e13ed6e80 how does this patch solve the separation of 'negative nice values' and 'RT priority rlimits'? In one piece of code it handles the rlimit value

Re: 2.6.11-rc3-mm2

2005-02-11 Thread Matt Mackall
On Fri, Feb 11, 2005 at 09:14:22AM +0100, Ingo Molnar wrote: > > > I think it's important to recognize that we're trying to address an > > issue that has a much wider potential audience than pro audio users, > > and not very far off - what is high end audio performance today will > > be expected d

Re: 2.6.11-rc3-mm2

2005-02-11 Thread Matt Mackall
On Fri, Feb 11, 2005 at 08:54:17AM +0100, Ingo Molnar wrote: > > * Matt Mackall <[EMAIL PROTECTED]> wrote: > > > Eh? Chris Wright's original rlimits patch was very straightforward > > [...] > > the problem is that it didnt solve the problem (unprivileged user can > lock up the system) in any way

Re: 2.6.11-rc3-mm2

2005-02-11 Thread Christoph Hellwig
On Fri, Feb 11, 2005 at 09:14:22AM +0100, Ingo Molnar wrote: > an "RT priorities rlimit" is still not adequate as a desktop solution, > because it still allows the box to be locked up. Also, if it turns out > to be a mistake then it's already codified into the ABI, while RT-LSM is > much less 'pers

Re: 2.6.11-rc3-mm2

2005-02-11 Thread Ingo Molnar
* Matt Mackall <[EMAIL PROTECTED]> wrote: > > > What happened to the RT rlimit code from Chris? > > > > I still have it, but I had the impression Ingo didn't like it as a long > > term solution/hack (albeit small) to the scheduler. Whereas the rt-lsm > > patch is wholly self-contained. > > I t

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Ingo Molnar
* Matt Mackall <[EMAIL PROTECTED]> wrote: > Eh? Chris Wright's original rlimits patch was very straightforward > [...] the problem is that it didnt solve the problem (unprivileged user can lock up the system) in any way. So after it became visible that all the existing 'dont allow users to lock

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Matt Mackall
On Thu, Feb 10, 2005 at 10:41:28PM -0500, Paul Davis wrote: > [ the best solution is ] > > [ my preferred solution is ... ] > > [ it would be better if ... ] > > [ this is a kludge and it should be done instead like ... ] > > did nobody read what andrew wrote and what JOQ pointed o

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Nick Piggin
On Fri, 2005-02-11 at 17:34 +1100, Peter Williams wrote: > Nick Piggin wrote: > > I can't say much about it because I'm not putting my hand up to > > do anything. Just mentioning that rlimit would be better if not > > for the userspace side of the equation. I think most were already > > agreed on

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Peter Williams
Nick Piggin wrote: On Thu, 2005-02-10 at 22:41 -0500, Paul Davis wrote: [ the best solution is ] [ my preferred solution is ... ] [ it would be better if ... ] [ this is a kludge and it should be done instead like ... ] did nobody read what andrew wrote and what JOQ pointed out? after week

Re: 2.6.11-rc3-mm2 (compile stats)

2005-02-10 Thread John Cherry
Linux 2.6 (mm tree) Compile Statistics (gcc 3.4.1) Web page with links to complete details: http://developer.osdl.org/cherry/compile/ KernelbzImage bzImage bzImage modules bzImage modules (defconfig) (allno) (allyes) (allyes) (allmod) (allmod) ---

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Peter Williams
Paul Davis wrote: [ the best solution is ] [ my preferred solution is ... ] [ it would be better if ... ] [ this is a kludge and it should be done instead like ... ] did nobody read what andrew wrote and what JOQ pointed out? after weeks of debating this, no other conceptual solution e

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Nick Piggin
On Thu, 2005-02-10 at 22:41 -0500, Paul Davis wrote: > [ the best solution is ] > > [ my preferred solution is ... ] > > [ it would be better if ... ] > > [ this is a kludge and it should be done instead like ... ] > > did nobody read what andrew wrote and what JOQ pointed out? >

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Paul Davis
[ the best solution is ] [ my preferred solution is ... ] [ it would be better if ... ] [ this is a kludge and it should be done instead like ... ] did nobody read what andrew wrote and what JOQ pointed out? after weeks of debating this, no other conceptual solution emerged that d

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Peter Williams
Nick Piggin wrote: On Thu, 2005-02-10 at 18:09 -0800, Matt Mackall wrote: On Thu, Feb 10, 2005 at 04:47:27PM -0800, Chris Wright wrote: * Matt Mackall ([EMAIL PROTECTED]) wrote: What happened to the RT rlimit code from Chris? I still have it, but I had the impression Ingo didn't like it as a long t

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Nick Piggin
On Thu, 2005-02-10 at 18:09 -0800, Matt Mackall wrote: > On Thu, Feb 10, 2005 at 04:47:27PM -0800, Chris Wright wrote: > > * Matt Mackall ([EMAIL PROTECTED]) wrote: > > > What happened to the RT rlimit code from Chris? > > > > I still have it, but I had the impression Ingo didn't like it as a long

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Matt Mackall
On Thu, Feb 10, 2005 at 04:47:27PM -0800, Chris Wright wrote: > * Matt Mackall ([EMAIL PROTECTED]) wrote: > > What happened to the RT rlimit code from Chris? > > I still have it, but I had the impression Ingo didn't like it as a long > term solution/hack (albeit small) to the scheduler. Whereas t

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Chris Wright
* Matt Mackall ([EMAIL PROTECTED]) wrote: > What happened to the RT rlimit code from Chris? I still have it, but I had the impression Ingo didn't like it as a long term solution/hack (albeit small) to the scheduler. Whereas the rt-lsm patch is wholly self-contained. thanks, -chris -- Linux Secu

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Matt Mackall
On Thu, Feb 10, 2005 at 02:51:44PM -0600, Jack O'Quin wrote: > [direct reply bounced, resending via gmail] > > Andrew Morton <[EMAIL PROTECTED]> writes: > > > Christoph Hellwig <[EMAIL PROTECTED]> wrote: > > > > > > On Thu, Feb 10, 2005 at 02:35:08AM -0800, Andrew Morton wrote: > > > > > > > >

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Benjamin Herrenschmidt
> > Without the aty128fb and radeonfb updates, current 2.6.11 is a > > regression on pmac as it breaks sleep support on previously working > > laptops. > > Is that worse than the risk of the large patch? Well, it used to work upstream fine for some time now... The large patch isn't risky imho, at

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Adrian Bunk
On Thu, Feb 10, 2005 at 02:35:08AM -0800, Andrew Morton wrote: >... > - Various other stuff. If anyone has a patch in here which they think > should be in 2.6.11, please let me know. I'm intending to merge the > following into 2.6.11: > > alpha-add-missing-dma_mapping_error.patch >

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Andrew Morton
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > On Thu, 2005-02-10 at 02:35 -0800, Andrew Morton wrote: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/ > > > > > > - Added the mlock and !SCHED_OTHER Linux Security Module for the audio guys.

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Benjamin Herrenschmidt
On Thu, 2005-02-10 at 02:35 -0800, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/ > > > - Added the mlock and !SCHED_OTHER Linux Security Module for the audio guys. > It seems that nothing else is going to come along and this i

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Corey Minyard
Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/ - Added the mlock and !SCHED_OTHER Linux Security Module for the audio guys. It seems that nothing else is going to come along and this is completely encapsulated. - Various other stuff.

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Jack O'Quin
[direct reply bounced, resending via gmail] Andrew Morton <[EMAIL PROTECTED]> writes: > Christoph Hellwig <[EMAIL PROTECTED]> wrote: > > > > On Thu, Feb 10, 2005 at 02:35:08AM -0800, Andrew Morton wrote: > > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Andrew Morton
Christoph Hellwig <[EMAIL PROTECTED]> wrote: > > On Thu, Feb 10, 2005 at 02:35:08AM -0800, Andrew Morton wrote: > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/ > > > > > > - Added the mlock and !SCHED_OTHER Linux Security Module for the audio

Re: 2.6.11-rc3-mm2

2005-02-10 Thread Christoph Hellwig
On Thu, Feb 10, 2005 at 02:35:08AM -0800, Andrew Morton wrote: > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/ > > > - Added the mlock and !SCHED_OTHER Linux Security Module for the audio guys. > It seems that nothing else is going to come along