On Thu, 9 Aug 2007 20:14:35 -0500 Dean Nelson <[EMAIL PROTECTED]> wrote:
> This patch provides cross partition access to user memory (XPMEM) when
> running multiple partitions on a single SGI Altix.
>
- Please don't send multiple patches all with the same title.
- Feed the diff through checkpat
I noticed that Ski was unable to do a stacktrace on the kernel. Turns
out that's because the PT_IA_64_UNWIND program-header is missing.
Perhaps this is due to a change in binutils, but in any case, it seems
like we should be explicit about the unwind header, so this patch is
probably a good idea n
This patch provides cross partition access to user memory (XPMEM) when
running multiple partitions on a single SGI Altix.
Signed-off-by: Dean Nelson <[EMAIL PROTECTED]>
xpmem-module.v002.bz2
Description: BZip2 compressed data
This patch exports zap_page_range as it is needed by XPMEM.
Signed-off-by: Dean Nelson <[EMAIL PROTECTED]>
---
XPMEM would have used sys_madvise() except that madvise_dontneed()
madvise_dontneed() returns an -EINVAL if VM_PFNMAP is set, which is
always true for the pages XPMEM imports from other
This patch exports __put_task_struct as it is needed by XPMEM.
Signed-off-by: Dean Nelson <[EMAIL PROTECTED]>
---
One struct file_operations registered by XPMEM, xpmem_open(), calls
'get_task_struct(current->group_leader)' and another, xpmem_flush(), calls
'put_task_struct(tg->group_leader)'. Th
Terminology
The term 'partition', adopted by the SGI hardware designers and which
perculated up into the software, is used in reference to a single SSI
when multiple SSIs are running on a single Altix. An Altix running
multiple SSIs is said to be 'partitioned', whereas one that is running
onl
> There is a libunwind test-case that used to work fine but fails with
> recent kernels (e.g., 2.6.23-rc2). The problem is exhibited by the
> attached test program. It attempts to map the page right after the
> register-backing-store area with a no-access page. The mmap call
> succeeds, but the
Attached is a trivial patch that makes stack-unwinding stop at the
last frame of the bootloader.
--david
--
Mosberger Consulting LLC, http://www.mosberger-consulting.com/
[IA64] Add a dummy nop at the end of _start() to maintain the invariant that
the return-pointer (rp) always point to
Never mind: with MAP_SHARED, the ia64 linux kernel will try to align
the mapping to a 1MB boundary to avoid potentially bad performance due
to false sharing, so the kernel is doing the Right Thing and it's the
app that should have used MAP_PRIVATE instead.
--david
On 8/9/07, David Mosberger-Tan
On Thu, 2007-08-09 at 11:04 -0700, Luck, Tony wrote:
> > Sure, that sounds reasonable. Updated patch attached.
> >
> > I tried this patch with Linus' 2.6.23-rc2 tree and the resulting
> > kernel boots fine, though there are some scary-looking error messages:
>
> These come from some debug code a
There is a libunwind test-case that used to work fine but fails with
recent kernels (e.g., 2.6.23-rc2). The problem is exhibited by the
attached test program. It attempts to map the page right after the
register-backing-store area with a no-access page. The mmap call
succeeds, but the kernel inc
> Sure, that sounds reasonable. Updated patch attached.
>
> I tried this patch with Linus' 2.6.23-rc2 tree and the resulting
> kernel boots fine, though there are some scary-looking error messages:
These come from some debug code added by Thomas ... adding him to
this thread so he can see the tr
On 8/9/07, Roland McGrath <[EMAIL PROTECTED]> wrote:
> That placement is probably fine (the standard size is 36 bytes, so don't
> fret too much about how optimal its location is). Since ia64 has an
> explicit PHDRS, it would be ideal to add there a "note PT_NOTE" and then use:
>
> NOTES :c
On Thu, Aug 09, 2007 at 12:36:25PM +0900, Hidetoshi Seto wrote:
> Luck, Tony wrote:
> >diff --git a/arch/ia64/kernel/process.c b/arch/ia64/kernel/process.c
> >index e92ea64..4305d2b 100644
> >--- a/arch/ia64/kernel/process.c
> >+++ b/arch/ia64/kernel/process.c
> >@@ -202,12 +202,9 @@ default_idle (
14 matches
Mail list logo