>doesn't that mean that those variables are a
>special kind of (per-CPU) variables and should
>get a special handling anyway?
>
>if not, then I'd agree with Peter that a per-cpu
>variable on UP should not be treated any different
>from a normal variable ...
>
>maybe you could clarify
On ia64 we
On Tue, Aug 30, 2005 at 03:01:01PM -0700, david mosberger wrote:
> Ah, I understand now what you mean. Sounds to me like the generic
> module loader infrastructure needs to be changed to support the
> IA64-usage. On IA64, we want to have per-CPU variables remapped even
> on UP, because it allows
On Thu, 1 Sep 2005, Hidetoshi Seto wrote:
> Index: linux-2.6.13/include/asm-ia64/io.h
> ===
> --- linux-2.6.13.orig/include/asm-ia64/io.h
> +++ linux-2.6.13/include/asm-ia64/io.h
> @@ -70,6 +70,26 @@ extern unsigned int num_io_spaces;
Hi,
Could you IPF platform makers share when the new PAL entry
PAL_MC_ERROR_INJECT is going to be available in your platforms?
Thanks,
John Ik Lee (J.I.)
Sr. Staff Engineer
Platform Solutions, Inc
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Christian
Keith,
On 8/31/05, Keith Owens <[EMAIL PROTECTED]> wrote:
> On Wed, 31 Aug 2005 21:58:58 -0700,
> david mosberger <[EMAIL PROTECTED]> wrote:
> >- In several places there are checks of the form:
> >
> >+ if ((r12 & -KERNEL_STACK_SIZE) != r13) {
> >
> > I don't understand why you're doing this. Y
When XPC is being shutdown (i.e., rmmod, reboot) it doesn't ensure that
other partitions with whom it was connected have completely disengaged
from any attempt at cross-partition memory references. This can lead to
MCAs in any of these other partitions when the partition is reset.
Signed-off-by: D
This is continuing on the TLB issues we're observing on 2.4 IA64
NUMA platform. Thanks to this maillist 2 issues have been identified!
However another issue (perhaps issues) persists. We're getting core dumps
in bunches when doing MT forks. I would include an example but
unfortunatelly its diffic
Keith wrote:
>That delay is coming from your SAL, nothing I can do about it.
>
...
>This is wrong. The slave INIT handler was not invoked when the monarch
>was delivered, instead the slave events were delivered _after_ the
>monarch returned to the interrupted context. It works for me on SGI's
>S
