> 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
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
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
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
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
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
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
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
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
>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
* 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
>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
-
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
* 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
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
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
* 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
* 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
* 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
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
* 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
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
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
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
* 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
* 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
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
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
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
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)
---
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
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?
>
[ 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
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
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
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
* 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
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:
> > > >
> > > >
> > 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
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
>
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.
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
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.
[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/
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
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
46 matches
Mail list logo