[XenPPC] Re: xencomm porting and "inline" handles

2006-09-26 Thread Tristan Gingold
Le Mardi 26 Septembre 2006 20:23, Hollis Blanchard a écrit : > On Tue, 2006-09-26 at 10:04 +0200, Tristan Gingold wrote: > > After more work, inline xencomm is not that magic: it doesn't work for > > modules which are loaded in virtual memory. So I have to use mini > > xencomm at least for modules

[XenPPC] Xen hang

2006-09-26 Thread Maria Butrico
This is new (at least for me) (on a js21 with 8G, cso91) (XEN) Physical RAM map: (XEN) End of RAM: 10240MB (10485760kB) (XEN) total_pages: 0x001fc000 (XEN) free_xenheap: 0x55000 - 0x40 (XEN) Xen heap: 63MB (65196kB) (XEN) free_xenheap: 0xb36000 - 0x400 (XEN) free_xenheap: Go

[XenPPC]:PPC kernel shutdown & resume over Xen

2006-09-26 Thread Yi Ge
We've tried to shutdown and resume the domU kernel based on the code from xen-tools and reboot.c. The DomU has been suspended and got the status "s" in xm list, but we can't resume it. Who can tell us how the HYPERVISOR_suspend and its parameter "srec" works on the suspend/shutdown procedure? Th

[XenPPC] Re: xencomm porting and "inline" handles

2006-09-26 Thread Hollis Blanchard
On Tue, 2006-09-26 at 10:04 +0200, Tristan Gingold wrote: > > After more work, inline xencomm is not that magic: it doesn't work for > modules which are loaded in virtual memory. So I have to use mini > xencomm at least for modules. What's the problem with modules? Their text/data isn't physical

[XenPPC] [xenppc-unstable] [XEN][POWERPC] Backoff the SCOM stuff by default

2006-09-26 Thread Xen patchbot-xenppc-unstable
# HG changeset patch # User Jimi Xenidis <[EMAIL PROTECTED]> # Node ID af1380a08804aed15a04f3dd60c5e56011e68d06 # Parent acfb1ac23f80286c8b532052f5e4b77f33612636 [XEN][POWERPC] Backoff the SCOM stuff by default Sadly the SCOM stuff is proving to be unstable for various versions of the chip. I'm

[XenPPC] [xenppc-unstable] [XEN][POWERPC] Allocated wrong order for dummy page

2006-09-26 Thread Xen patchbot-xenppc-unstable
# HG changeset patch # User Jimi Xenidis <[EMAIL PROTECTED]> # Node ID 2e303eacce32e5fd3f7b16c92ff034b7117e1d5f # Parent af1380a08804aed15a04f3dd60c5e56011e68d06 [XEN][POWERPC] Allocated wrong order for dummy page This patch makes sure that the dummy page is only 4k not 8k. Signed-off-by: Jimi Xe

[XenPPC] [xenppc-unstable] [XEN][POWERPC] U4 DART workaround for functionality

2006-09-26 Thread Xen patchbot-xenppc-unstable
# HG changeset patch # User Jimi Xenidis <[EMAIL PROTECTED]> # Node ID 2aa9a65408bc10594cd2488f6640574f5ea67549 # Parent 2e303eacce32e5fd3f7b16c92ff034b7117e1d5f [XEN][POWERPC] U4 DART workaround for functionality This patch invalidates the whole DART cache rather than the single entry. Until we

Re: [XenPPC] Help with JS21 disk solution

2006-09-26 Thread Jimi Xenidis
On Sep 26, 2006, at 1:39 AM, Segher Boessenkool wrote: @@ -126,6 +126,8 @@ static void u4_inv_entry(ulong pgn) union dart_ctl dc; ulong retries = 0; +return u4_inv_all(); If you need inv_all here, you have a bug elsewhere... I agree, I'm just trying to corner the beast :) -JX

Re: [XenPPC] JS20 does not boot with latest pull

2006-09-26 Thread Maria Butrico
Dan, do you have a js20? Jimi Xenidis wrote: uh oh. These are really old processor and may have SCOM issues those having a boot problem please comment out the body on cpu_scom_init() in: xen/arch/powerpc/powerpc64/ppc970_scom.c and see let me know if it works? -JX On Sep 25, 2006, at 5:52 P

Re: [Xen-devel] Re: [XenPPC] [RFC][PATCH] Isolating ACM's architecture-dependent parts

2006-09-26 Thread Tristan Gingold
Le Mardi 26 Septembre 2006 13:56, Stefan Berger a écrit : > Tristan Gingold <[EMAIL PROTECTED]> wrote on 09/26/2006 07:54:27 [...] > > Hi, > > > > sorry for the late reply, I am just back from holidays. > > > > It seems you patch has not yet been merged. Is there any reason ? > > I'd like to see i

Re: [XenPPC] Help with JS21 disk solution

2006-09-26 Thread Jimi Xenidis
On Sep 26, 2006, at 9:44 AM, Jimi Xenidis wrote: On Sep 26, 2006, at 1:39 AM, Segher Boessenkool wrote: @@ -126,6 +126,8 @@ static void u4_inv_entry(ulong pgn) union dart_ctl dc; ulong retries = 0; +return u4_inv_all(); If you need inv_all here, you have a bug elsewhere...

Re: [Xen-devel] Re: [XenPPC] [RFC][PATCH] Isolating ACM's architecture-dependent parts

2006-09-26 Thread Tristan Gingold
Le Mercredi 13 Septembre 2006 18:42, Stefan Berger a écrit : > [EMAIL PROTECTED] wrote on 09/13/2006 11:00:16 AM: > > That is where the (non-inline) ACM/multiboot functions should live; not > > in a header file. > > I could move them there but that would include the architecture-dependent > #ifdef'

Re: [Xen-devel] Re: [XenPPC] [RFC][PATCH] Isolating ACM's architecture-dependent parts

2006-09-26 Thread Stefan Berger
Tristan Gingold <[EMAIL PROTECTED]> wrote on 09/26/2006 07:54:27 AM: > Le Mercredi 13 Septembre 2006 18:42, Stefan Berger a écrit : > > [EMAIL PROTECTED] wrote on 09/13/2006 11:00:16 AM: > > > That is where the (non-inline) ACM/multiboot functions should live; not > > > in a header file. > > > >

[XenPPC] Re: xencomm porting and "inline" handles

2006-09-26 Thread Tristan Gingold
Le Mardi 12 Septembre 2006 20:37, Hollis Blanchard a écrit : > Hi Tristan, I've just implemented your "inline" handle idea. > > The Xen changes are committed to xenppc-unstable.hg . In Xen, > architectures need to provide: > - XENCOMM_INLINE_FLAG in arch-foo.h > - paddr_to_maddr(). I'm open to alte