On Wed, 9 Feb 2005 19:02:19 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> New patch below.
...
> this patch does the final consolidation of asm-*/resource.h file,
> without changing any of the rlimit definitions on any architecture.
I'm fine with this.
-
To unsubscribe from
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
>
> * Chris Wright <[EMAIL PROTECTED]> wrote:
>
> > * Ingo Molnar ([EMAIL PROTECTED]) wrote:
> > > this patch does the final consolidation of asm-*/resource.h file,
> > > without changing any of the rlimit definitio
* Chris Wright <[EMAIL PROTECTED]> wrote:
> * Ingo Molnar ([EMAIL PROTECTED]) wrote:
> > this patch does the final consolidation of asm-*/resource.h file,
> > without changing any of the rlimit definitions on any architecture.
> > Primarily it removes the __ARCH_RLIMI
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
> this patch does the final consolidation of asm-*/resource.h file,
> without changing any of the rlimit definitions on any architecture.
> Primarily it removes the __ARCH_RLIMIT_ORDER method and replaces it with
> a more compact and
t though. New patch below.
Ingo
--
this patch does the final consolidation of asm-*/resource.h file,
without changing any of the rlimit definitions on any architecture.
Primarily it removes the __ARCH_RLIMIT_ORDER method and replaces it with
a more compact and isolated one that allows arch
Hi Ingo,
On Wed, 9 Feb 2005 10:39:27 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> --- linux/include/asm-sparc/resource.h.orig
> +++ linux/include/asm-sparc/resource.h
.
.
> -#define RLIMIT_NOFILE6 /* max number of open files */
> -#define RLIMIT_NPROC 7
this patch does the final consolidation of asm-*/resource.h file,
without changing any of the rlimit definitions on any architecture.
Primarily it removes the __ARCH_RLIMIT_ORDER method and replaces it with
a more compact and isolated one that allows architectures to define only
the offending
this patch does the final consolidation of asm-*/resource.h file,
without changing any of the rlimit definitions on any architecture.
Primarily it removes the __ARCH_RLIMIT_ORDER method and replaces it with
a more compact and isolated one that allows architectures to define only
the offending
Hi Ingo,
On Wed, 9 Feb 2005 10:39:27 +0100 Ingo Molnar [EMAIL PROTECTED] wrote:
--- linux/include/asm-sparc/resource.h.orig
+++ linux/include/asm-sparc/resource.h
.
.
-#define RLIMIT_NOFILE6 /* max number of open files */
-#define RLIMIT_NPROC 7
those be reversed to match the ones
you are removing (and the sparc64 ones)?
you are right - the sparc32 ones i got mixed up. (sigh.) The sparc64
ones (and mips and alpha) seem correct though. New patch below.
Ingo
--
this patch does the final consolidation of asm-*/resource.h file
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
this patch does the final consolidation of asm-*/resource.h file,
without changing any of the rlimit definitions on any architecture.
Primarily it removes the __ARCH_RLIMIT_ORDER method and replaces it with
a more compact and isolated one that allows
* Chris Wright [EMAIL PROTECTED] wrote:
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
this patch does the final consolidation of asm-*/resource.h file,
without changing any of the rlimit definitions on any architecture.
Primarily it removes the __ARCH_RLIMIT_ORDER method and replaces
On Wed, 9 Feb 2005 19:02:19 +0100
Ingo Molnar [EMAIL PROTECTED] wrote:
New patch below.
...
this patch does the final consolidation of asm-*/resource.h file,
without changing any of the rlimit definitions on any architecture.
I'm fine with this.
-
To unsubscribe from this list: send the line
[Jeff V. Merkey <[EMAIL PROTECTED]>]
> I got a little further with the lock up problem, and it is related to
> MPS reporting a 2nd processor being present in some PPro systems when
> in fact only one CPU is really installed (but MPS is reporting
> default table entry 6 with a second CPU as
On Fri, Nov 03, 2000 at 08:33:36PM -0600, Peter Samuelson wrote:
>
> [Jeff Merkey]
> > Is this what is causing the lockup problems on 2.4.0-pre-10 with
> > PPro, or something else. Looks like something else.
>
> Yeah, it does, doesn't it. If this particular patch cured a
> kernel-side lockup
On Fri, Nov 03, 2000 at 08:33:36PM -0600, Peter Samuelson wrote:
[Jeff Merkey]
Is this what is causing the lockup problems on 2.4.0-pre-10 with
PPro, or something else. Looks like something else.
Yeah, it does, doesn't it. If this particular patch cured a
kernel-side lockup I would
[Jeff V. Merkey [EMAIL PROTECTED]]
I got a little further with the lock up problem, and it is related to
MPS reporting a 2nd processor being present in some PPro systems when
in fact only one CPU is really installed (but MPS is reporting
default table entry 6 with a second CPU as present).
[Jeff Merkey]
> Is this what is causing the lockup problems on 2.4.0-pre-10 with
> PPro, or something else. Looks like something else.
Yeah, it does, doesn't it. If this particular patch cured a
kernel-side lockup I would be very surprised. Because the only effect
this patch is *supposed* to
hpa,
Is this what is causing the lockup problems on 2.4.0-pre-10 with PPro,
or something else. Looks like something else.
Jeff
"H. Peter Anvin" wrote:
>
> Hello friends,
>
> Attached is a patch against 2.4.0-test10 that changes asm/resource.h to
> define RLIM_I
Hello friends,
Attached is a patch against 2.4.0-test10 that changes asm/resource.h to
define RLIM_INFINITY insite the #ifdef __KERNEL__ on all architectures;
previously, this was inconsistent between architecures. This breaks
compilation with -Werror at least on i386 since
includes , at least
Hello friends,
Attached is a patch against 2.4.0-test10 that changes asm/resource.h to
define RLIM_INFINITY insite the #ifdef __KERNEL__ on all architectures;
previously, this was inconsistent between architecures. This breaks
compilation with -Werror at least on i386 since bits/resource.h
hpa,
Is this what is causing the lockup problems on 2.4.0-pre-10 with PPro,
or something else. Looks like something else.
Jeff
"H. Peter Anvin" wrote:
Hello friends,
Attached is a patch against 2.4.0-test10 that changes asm/resource.h to
define RLIM_INFINITY insite
[Jeff Merkey]
Is this what is causing the lockup problems on 2.4.0-pre-10 with
PPro, or something else. Looks like something else.
Yeah, it does, doesn't it. If this particular patch cured a
kernel-side lockup I would be very surprised. Because the only effect
this patch is *supposed* to
23 matches
Mail list logo
