> 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:
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:[c0126fda] CPU: 0
EIP is at sys_timer_settime+0xfa+0x1f0
EFLAGS: 0282 Not tainted (2.6.11-rc3-mm2)
EAX: 0282 EBX:
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
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
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
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.
>
>
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
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
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.
Even if we
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
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
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
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
* 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
>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
* 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
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
* 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
* 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
* 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
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
* 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
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
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
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
* 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
* 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 think it's
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
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.
There
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 desktop
* 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
as
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' and
'RT
* 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 such as
* 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 in
* 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 what
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 prefer the
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 can
* 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 scheduling
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/cachefs.txt
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
-
To
* 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 launcher. It would be
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 priorities of
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 APIs
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 whatsoever -
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 unprivileged, how does it
* 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
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
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
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
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
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
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
* 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
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,
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
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:
> > >
> > >
> > >
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
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
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 and
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 guys.
It
[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/2.6.11-rc3-mm2/
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.
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 is
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.
It seems
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
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 least
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:
* 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
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 the
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
term
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
[ 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
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
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
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)
---
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
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 that
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 out?
* 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 up'
90 matches
Mail list logo
