Our Linux xen_maple_defconfig has gotten a bit out of date. This patch
brings it up to the options that Kbuild is automatically turning on anyway.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
diff -r 72c8bc5d88f4 arch/powerpc/configs/xen_maple_defconfig
--- a/arch/powerpc/c
It would be nice to boot the exact same Linux kernel binary image on
bare hardware and as a Xen dom0 on that same hardware. At present we
cannot do this: you stop seeing output early in the boot process.
I spent some time using OF output routines to track down the problem,
and it turns out that C
and without Xen.
I am posting here for review: if the approach is not voted down, I will
send the individual patches to their respective Xen and Linux mailing lists.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
arch/powerpc/configs/xen_maple_defconfig | 12 ++--
Support expressing the command line arguments at make invocation. Use
same section name as Linux's zImage so that arguments can be manipulated
by external tools.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
Makefile |3 +++
boot_of.c |7 +--
2 files changed, 8
Support expressing Xen command line arguments at make invocation. Use
same section name as Linux's zImage and reserve a certain amount of
space so that arguments can be manipulated by external tools.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
Makefile |3 +++
boot_
n
`mknod /dev/xvc c 232 0' in your rootfs to use it.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
drivers/xen/console/console.c | 19 +--
include/linux/major.h |2 ++
2 files changed, 19 insertions(+), 2 deletions(-)
diff -r 17aa29a18b08 drivers
their handlers as needed.
This patch assumes the existence of the "add support for builtin command
line (take two)" patch posted earlier.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
boot_of.c | 37 +++--
1 file changed, 31 insertions(+), 6
pruning `/ht/[EMAIL PROTECTED]/[EMAIL PROTECTED]' from devtree
pruning `/ht/[EMAIL PROTECTED]/[EMAIL PROTECTED]' from devtree
Note that this patch supercedes the "Command line option for serial port"
patch I posted earlier.
Signed-off-by: Amos Waterland <[EMAIL PROTECT
On Wed, Aug 09, 2006 at 07:37:14PM -0400, Amos Waterland wrote:
> The below patch allows Xen/PPC to support the console=comX option
> that Xen/x86 uses. With this patch applied, one need simply
> supply CMDLINE="console=com2" on the make invocation to get proper use
>
This is a rough first cut at handshaking with the secondary processors.
Once we get this right, they will wait on a shared variable, build a
stack, and start running C code proper. I am posting this now because I
want to make sure we get the register flushes and memory barriers
correct. Any comme
will always be environments where it is
difficult to get access to the firmware console.
Tested on JS20 and JS21 blades.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
Makefile |6 --
boot_of.c | 35 +--
setup.c |4
3 files changed,
will always be environments where it is
difficult to get access to the firmware console.
Tested on JS20 and JS21 blades.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
Makefile |6 --
boot_of.c | 38 --
setup.c |4
3 files changed,
. So this patch makes us print one
extra line before quiescing OF.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
boot_of.c | 52 ++---
powerpc64/exceptions.S |8 +++
2 files changed, 57 insertions(+), 3 deletions(-)
: none
This patch reflects that, and makes us stop seeing a bogus OF_FAILURE if
we do actually check the return code of of_start_cpu. Tested on JS20
and JS21 blades.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
boot_of.c | 11 +--
1 file changed, 5 insertions(+), 6 del
Take three. A forthcoming patch will deal with processors that take
longer than five seconds to ack.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
boot_of.c | 53 ++---
powerpc64/exceptions.S |8 +++
2 files c
This is a very rough first attempt to set up the stack and TOC for each
secondary processor such that they can invoke C code. It supercedes the
previous handshaking patches because it moves all the logic to a set of
per-cpu structures. This paves the way for bringing up processors in
parallel, bu
On Fri, Aug 11, 2006 at 08:40:19PM -0400, Amos Waterland wrote:
> I have screwed up the link register or something however, because the
> logic right after the bctrl never seems to run.
It turned out to be the fact that I was using r4 for my per-cpu struct
pointer, and the called C code
This patch gets things to the point that each secondary processor can
call the same C routine that the primary processor did to invalidate the
segment table and initialize the HID registers. It prints the following
and boots up to nfsroot on a JS21 blade:
(XEN) CPU #1 is waiting for a stack ...
On Mon, Aug 14, 2006 at 05:20:42PM -0400, poff wrote:
> The console from today's Xen booting on JS21, 4gb memory
> Booting just hangs
> ...
> boot_of_module: linked in module copied after _end (start 0x0046ac94
> size 0x6f4cb0)
> find_space base=0x00b916a8 eomem=0x8000
Using a `powerpc64-linux-gcc (GCC) 4.1.1 ()' x86->ppc toolchain, if I do this:
diff -r 9563f5c9ab19 xen/include/asm-powerpc/config.h
--- a/xen/include/asm-powerpc/config.h Mon Aug 14 15:22:22 2006 -0500
+++ b/xen/include/asm-powerpc/config.h Mon Aug 14 19:13:07 2006 -0400
@@ -51,7 +51,7 @@ exter
In find_space, if the user passes zero for the size argument she will
get a random value returned.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
boot_of.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -r da9637bef06a xen/arch/powerpc/boot_of.c
--- a/xen/arch/p
On Thu, Aug 17, 2006 at 07:19:05PM -0400, Jimi Xenidis wrote:
> was this by inspection or was it called with a size of zero?
I am soon to send a patch to make arch/powerpc compile with -Wshadow, so
I was going through with a stricter compiler (gcc 4.1.1) that warned
about the unused variable.
__
processors, JS20 with two processors, and JS21 with four processors.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
arch/powerpc/Makefile |2 -
arch/powerpc/boot_of.c | 53 +---
arch/powerpc/mpic.c |2 -
.
Tested on systemsim-gpul with up to four simulated processors, Maple-D
with two processors, JS20 with two processors, and JS21 with four processors.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
arch/powerpc/Makefile |2 -
arch/powerpc/boot_of.c
a candidate for merging. I will submit a patch
next for smp_processor_id, and then one for making the secondary
processors join the idle domain, but I would like to have any necessary
discussion about this portion first.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
arch/p
he final
linked object.
This patch fixes the three issues described above. Tested on
systemsim-gpul, JS20 and JS21.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
arch/powerpc/xen.lds.S | 15 +--
include/asm-powerpc/percpu.h |5 +++--
2 files changed, 1
atch versus previous versions.
Tested on 2-way Maple, 2-way JS20, 4-way JS21, and 16-way systemsim-gpul,
with NR_CPUS from 1 to 64.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
arch/powerpc/boot_of.c | 67 +--
arch/powerpc/powerpc6
0, 4-way JS21, and 16-way systemsim-gpul, with
NR_CPUS from 1 to 64, nosmp, and maxcpus from 1 to 3.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
arch/powerpc/boot_of.c | 67 +++--
arch/powerpc/powerpc64/exceptions.S | 37 +
for me" reports (and no
> "fails miserably" reports :) .
I had the same problem on JS21, and Hollis' patch fixes it for me.
Acked-by: Amos Waterland <[EMAIL PROTECTED]>
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Turn on autofs support in the Xen PPC defconfig. This allows dom0 to do
automounts and is necessary for a portable nfsroot.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
xen_maple_defconfig |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -r 899b84c2c979 arch/p
Using tip of tree xen.hg and linux.hg, I get this when launching a domU:
Freeing initrd memory: 3141k freed
Bad page state in process 'swapper'
page:c075d000 flags:0x1008 mapping: mapcount
:0 count:0
Trying to fix it up, but a reboot is needed
Backtrace:
Call T
On Mon, Aug 28, 2006 at 09:23:17PM -0500, Hollis Blanchard wrote:
> On Mon, 2006-08-28 at 22:13 -0400, Amos Waterland wrote:
> Hmm, I'm not sure what could cause this.
>
> How reproducible is it? Does it only happen once per domU boot? Always
> the same address/backtrace? Gen
This patch fixes memory corruption caused by start_of_day, and makes the
secondary processors join the idle domain and become eligible for domU
scheduling.
It is quite stable in that the secondary processors reliably join the
idle domain and wait for free pages to scrub, handling 0x980 interrupts
On Tue, Aug 29, 2006 at 09:02:58AM +0200, Segher Boessenkool wrote:
> >It is quite stable in that the secondary processors reliably join the
> >idle domain and wait for free pages to scrub, handling 0x980
> >interrupts
> >with no problem.
>
> What's this 980 exception?
Perhaps my phrasing is ba
I saw this fire once and was mightily confused by the "type" printed.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
usercopy.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -r e12aa1195f58 xen/arch/powerpc/usercopy.c
--- a/xen/arch/powerpc/usercopy
Just to provide background for this commit that went in today:
--- a/xen/arch/powerpc/powerpc64/domain.c
+++ b/xen/arch/powerpc/powerpc64/domain.c
@@ -55,7 +55,10 @@ void load_sprs(struct vcpu *v)
/* adjust the DEC value to account for cycles while not
* running this OS */
timebase
Using current xen.hg and linux.hg, I get this when I try to
run `xm vcpu-list':
(XEN)
(XEN) Panic on CPU 0:
(XEN) paddr_to_maddr: Dom:0 paddr: 0xf5d5ecc0 bad type:0x3
(XEN)
(XEN)
(XEN) Reboot in five seconds...
No
Building exceptions.c with CRASH_DEBUG=y produces a build break, because
gcc complains about the unused variable.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
exceptions.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -r 715014b95488 xen/arch/powerpc/except
secondary processor to mark itself online.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
setup.c |1 -
1 file changed, 1 deletion(-)
diff -r 715014b95488 xen/arch/powerpc/setup.c
--- a/xen/arch/powerpc/setup.c Thu Sep 07 22:09:06 2006 -0400
+++ b/xen/arch/powerpc/setup.c Fri
This very simple patch prints sampled statistics every three seconds
about what has been executing on a particular physical processor.
Example output for cpu 3 on a JS21 is:
(XEN)044efbc: 166
(XEN)142a810: 150090839
(XEN)2 c04ea660: 1
(XEN)3 c0
On Wed, Sep 13, 2006 at 11:58:07AM -0500, [EMAIL PROTECTED] wrote:
> > This can be deceiving. Blades have 2 UARTs and SLOF will multiplex
> > output to both, but input from one.
>
> JS20 blades have only one UART wired up.
We actually soldered a connecter for the second serial port for some
our
With current linux.hg and xen.hg, I am getting this consistently when
creating my third domU:
(XEN) Domain[2].0: initializing
(XEN) Assertion 'entry->next->prev == entry' failed, line 92, file
xen/include/xen/list.h
(XEN) BUG at xen/include/xen/list.h:92
This is not a real tracing facility, but it is good enough to find bugs.
It supports symbolic lookup and tracepoint insertion, as well as hooking
the three main entry points to the hypervisor.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
arch/powerpc/exceptions.c
This was the cause of the periodic hang on secondary processors that has
been holding back the submission of the SMP patch.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
time.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -r c94df1e4e62c xen/arch/powerpc/time.c
Enable secondary processors as schedulable entities and allow domU's to
run on them. Tested extensively on JS20 and JS21 with up to ten
domains at a time.
Note that this patch relies on the hdec storm patch just posted.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
set
;.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
boot_of.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff -r 1d9c135673e4 xen/arch/powerpc/boot_of.c
--- a/xen/arch/powerpc/boot_of.cFri Sep 15 18:20:55 2006 -0400
+++ b/xen/arch/powerpc/boot_of.cSun
On Mon, Sep 18, 2006 at 09:19:29AM -0500, Hollis Blanchard wrote:
> On Sun, 2006-09-17 at 02:40 -0400, Amos Waterland wrote:
> > I recently got a few hours on a Maple development board. I wanted to
> > boot with an nfsroot, but I didn't want to risk changing the bootargs
&
On Mon, Sep 18, 2006 at 09:51:05AM -0500, Hollis Blanchard wrote:
> I'm happy to accommodate netbooting large clusters, but I'm asking you
> to simplify this situation, not make it more complex.
In order to scale to large clusters, one must have flexible and
policy-free software. Right now Xen ha
st Xen and Linux.
On Thu, Sep 14, 2006 at 06:21:06PM -0400, Amos Waterland wrote:
> With current linux.hg and xen.hg, I am getting this consistently when
> creating my third domU:
>
> (XEN) Domain[2].0: initializing
> (XEN) Assertion 'entry->next->prev == entry'
On Wed, Sep 20, 2006 at 11:35:51AM -0500, Hollis Blanchard wrote:
> On Tue, 2006-09-19 at 20:04 -0400, Amos Waterland wrote:
> > I am seeing this when loading dom0 now on JS21:
> >
> > (XEN) *** LOADING DOMAIN 0 ***
> > (XEN) Assertion 'entry->next->prev
On Wed, Sep 20, 2006 at 07:20:54PM -0400, Amos Waterland wrote:
> On Wed, Sep 20, 2006 at 11:35:51AM -0500, Hollis Blanchard wrote:
> > On Tue, 2006-09-19 at 20:04 -0400, Amos Waterland wrote:
> > > I am seeing this when loading dom0 now on JS21:
> > >
>
On Wed, Sep 20, 2006 at 10:52:32PM -0400, Amos Waterland wrote:
> On Wed, Sep 20, 2006 at 07:20:54PM -0400, Amos Waterland wrote:
> > On Wed, Sep 20, 2006 at 11:35:51AM -0500, Hollis Blanchard wrote:
> > > On Tue, 2006-09-19 at 20:04 -0400, Amos Waterland wrote:
> > &
This makes Xen/PPC dump a backtrace when a BUG() is triggered.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
config.h | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff -r 5418062d2da8 xen/include/asm-powerpc/powerpc64/config.h
--- a/xen/include/asm-p
With crash_debug=y the compiler can't find a prototype for unimplemented(),
where gdb-arch-read_reg is calling it.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
gdbstub.c |1 +
1 file changed, 1 insertion(+)
diff -r 0e83ba62a3a5 xen/arch/powerpc/gdbstub.c
--- a/xen/a
An automated process boooted Xen on a JS21 blade 126 times, recording 5
failures and 109 passes, using the launch of the ssh daemon by dom0 as a
correctness criteria.
The version of Xen used was changeset 261c458e46af, which is tip of tree
changeset dbfb5fc0b9b2 plus the bootargs simplification pa
An automated process boooted Xen on a JS20 blade 534 times, recording 0
failures and 534 passes, using the launch of the ssh daemon by dom0 as a
correctness criteria.
The version of Xen used was changeset 261c458e46af, which is tip of tree
changeset dbfb5fc0b9b2 plus the bootargs simplification pa
important things: allowing developers and cluster
administrators the option of overriding the bootargs supplied by
firmware, and the ability to take a single gold master xen binary and
customize its bootargs across a cluster with a simple and well-tested
post-processing tool.
Signed-off-by: Amos
Hollis requested that boot argument processing be documented. I have
placed the following text on this wiki:
http://wiki.xensource.com/xenwiki/XenPPC/BootArguments
---
The boot argument processing for powerpc Xen is much less complex than
it may appear. Assuming that the 'Simplify bootargs pr
We are improperly feeding the entire boot parameter string to Xen's
generic command line parser. This can have unexpected results when one
of the dom0 parameters, such as console=X, has meaning to the Xen
parser. First reported by Maria Butrico.
Signed-off-by: Amos Waterland <[EMAIL P
uster with a simple and well-tested
post-processing tool.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
b/xen/arch/powerpc/boot/arg32.c | 22 ++
xen/arch/powerpc/Makefile |5 -
xen/arch/powerpc/boot/boot32.S |5 +
xen/arch/powerp
An automated process has boooted Xen on two JS21 blades and one JS20
blade a total of 1241 times, recording 0 failures and 1237 passes, using
a correctness criteria of the creation of four domU's for the first
JS21, the launch of the ssh daemon for the second JS21, and the creation
of two domU's fo
On Tue, Oct 03, 2006 at 12:25:33PM -0400, Maria Butrico wrote:
> What's really interesting to me about this is that the invocation of the
> icache invalidation did not go in till later. So if anything we could find
> this to be even more reliable one the other changes are also picked up.
The key
On Tue, Oct 03, 2006 at 02:53:02PM -0400, Yi Ge wrote:
> It seems the gcc couldn't find the prototype of __trap_to_gdb when make the
> function call in debugger_trap_fatal(). So I added an extern prototype here
> with ifndef macro.
I'm not positive of this, but I'm pretty sure that this is caused
Rebuild cmdline.o when the user changes the CMDLINE=X argument passed to
the make invocation. I couldn't find an example of another project that
handles this case properly, so I came up with this.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
.hgignore |
On Thu, Oct 05, 2006 at 01:52:39PM +1000, Tony Breeds wrote:
> On Wed, Oct 04, 2006 at 07:36:08AM -0400, Jimi Xenidis wrote:
> > I think hollis nailed correctly, does it work for everyone?
>
> Works for me.
Did you try building with debug=y, then with debug=n, with no
intervening `make clean'?
On Wed, Oct 04, 2006 at 05:34:05PM -0500, Hollis Blanchard wrote:
> On Mon, 2006-10-02 at 11:46 -0400, Amos Waterland wrote:
> > This patch has been in use by an internal IBM project for some time.
> > It enables two important things: allowing developers and cluster
> > admi
I took a look at the situation. It boils down to this:
1. In the internal Xen tree, there is a bug (my fault) in which
firmware bootargs are overridden by the builtin "xen" bootarg. This
is fixed (by Hollis) in the current public Xen tree.
2. In the internal Xen tree, the SMP patch ap
This makes it easier to grep log files, and just looks a lot better in
the console output of a make.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
Makefile |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff -r a41b8cd01ad2 xen/arch/powerpc/Makefile
--- a/xe
On Sat, Oct 07, 2006 at 01:36:18AM +0900, Kiyokuni Kawachiya wrote:
> > > Could you synchronize the console here, there are two ways to do this:
> > > 1) add "sync_console" to the cmdline _before_ "--"
> > > 2) apply the follow diff
>
> > Do you have output for this?
>
> I did this with 1), a
I am having some doubts about this code in external.c:
vec = xen_mpic_get_irq(regs);
if (vec != -1) {
...
spur_count = 0;
} else {
++spur_count;
if (spur_count > 100)
panic("Too many (%d) spurrious interrupts in a row\n");
}
When I do th
Just as a sanity check, is the intention is to put the processor in the
NAP state when .sleep() is invoked? If so, is the following behavior
expected?
@@ -395,12 +396,34 @@ static void __init __start_xen(multiboot
console_endboot();
+while (1) {
+long before, after;
+be
This is the minimal set of changes/hacks necessary to get interprocessor
interrupts delivered reliably.
This is certainly not for submission, I am just posting it because I
would appreciate any feedback on the direction this is headed.
Basically, we are "sharing" the mpic less, but I have not rip
I don't see a definitive statement in the mpic spec. Is it ok to reset
the mpic an arbitrary number of times, or even more than once, after
power on? We are allowing dom0 to reset it at the moment ...
> diff -r b9e38b262f64 arch/powerpc/sysdev/mpic.c
> --- a/arch/powerpc/sysdev/mpic.c Sun
On Sat, Oct 07, 2006 at 01:56:56AM +0900, Kiyokuni Kawachiya wrote:
> > 2. The SMP patch apparently causes dom0 Linux to fail
> > on Kawachiya's JS20, but no other JS20.
>
> > is not solved yet, may depend on my JS20. sent the boot log
Hi Kawachiya. If you get a chance, could you please
This lets Xen with the SMP patch boot reliably on the Maple-D platform I
have access to.
I believe that the long-term strategy for Xen/PPC is to completely
virtualize the PIC, but until that happens, this patch will I believe
allow the SMP patch to go in.
Signed-off-by: Amos Waterland <[EM
Rather than try to make a xen_mpic_init and duplicate all the associated
machinery it pulls in, this patch introduces a feature flag. I tried
the first approach, and it results in a lot of code duplication, which
is a worse maintenence burden than this, I believe.
Signed-off-by: Amos Waterland
An automated process has booted Xen on three JS21 blades a total of 663
times, recording 0 failures and 640 passes, using a correctness criteria
of the creation of four domU's.
changeset : 3dfeb3e4a03f
machines: cso96 cso97 cso102 cso103 cso104
pass: 640
fail: 0
transien
On a JS21 with 8GB of RAM, we attempt 8 runs with the following dom0
memory requests: 128M 192M 256M 512M 700M 1G 2G 7G.
I'm surprised we need as much as 256M just to load dom0, but happy
that 2G works now.
---
changeset : d18a0c0b77d7
machines: cso104
pass: 5
fail: 3
tran
Compiling the current code from linux-ppc-2.6.hg with xen_maple_defconfig
and booting on both JS20 and JS21 produces this:
PID hash table entries: 4096 (order: 12, 32768 bytes)
Maple: Found RTC at IO 0x1070
cpu 0x0: Vector: 300 (Data Access) at [c0002ffe3b60]
pc: c0515128: .loo
This patch enables SMP and IPIs. It works reliably on JS20 and JS21
blades. It is not quite ready for submission, but I would greatly
appreciate any comments.
Note that the flurry of IPIs generated by domain creation seems to be a
waste of time. Xen on x86 doesn't actually to do anything in res
/dev/xvc0 c 204 187' in your rootfs. Built and booted up to
nfsroot on a JS21 ppc64 blade both on bare hardware and as a dom0.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
arch/powerpc/configs/xen_maple_defconfig | 12 ++--
drivers/xen/console/console.c
On Tue, Oct 24, 2006 at 03:18:26PM -0500, Hollis Blanchard wrote:
> I don't see the dependency?
It depends on that patch in that it is irrelevent without that patch.
Linux would not make it far enough to worry about console.
> This doesn't seem to be PowerPC-specific. Why don't you send this to
>
On Tue, Oct 24, 2006 at 05:54:47AM -0400, Jimi Xenidis wrote:
> On Oct 24, 2006, at 12:22 AM, Amos Waterland wrote:
> > Note that the flurry of IPIs generated by domain creation seems to
> > be a waste of time. Xen on x86 doesn't actually to do anything in
> > response t
On Wed, Oct 25, 2006 at 09:02:29PM -0400, Maria Butrico wrote:
> I thought we diligently updated this file by hand. We edit it all the
> time. The comment is flat out wrong.
The file is in fact automatically generated. Nobody should ever edit a
defconfig by hand, since the Kconfig logic that
Remove timestamp from xen_maple_defconfig to reduce merge conflicts in
client trees. Generated with:
KCONFIG_NOTIMESTAMP=1 make xen_maple_defconfig
Thanks to Segher Boessenkool for the suggestion.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
xen_maple_defconfig |1 -
on Maple
and model 884241X JS20 blades.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
changeset : 25c51961bd3f
machines: kpblade1 cso91 cso103
pass: 162
fail: 0
transient : 1
total : 163
reliability : 100%
---
arch/powerpc/exte
We have a particular JS20 blade, named kpblade11, on which we have to
flash a downlevel SLOF, and on which when Linux runs it reports only one CPU.
Current tip of tree Xen/PPC appears to find the missing processor in
some capacity, as the following is printed during boot.
Note that this is vanill
On Thu, Oct 26, 2006 at 11:24:32PM -0400, Amos Waterland wrote:
> Enable SMP and IPI support, including remote function invocation.
It took over 1000 attempts but I did see a case of the timebase sync
hang. I will try to track this down.
changeset : 25c51961bd3f
machines: kpblade1 cs
Using tip of tree Xen/PPC I am seeing warnings like the following on JS20:
(XEN) reprogram_timer[00] Timeout in the past 0x0085D8B8CC58 >
0x0085D8B845D5
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.co
I have seen this on a Maple now as well:
(XEN) reprogram_timer[00] Timeout in the past 0x0038879D3833 >
0x0038879CF88C
(XEN) reprogram_timer[00] Timeout in the past 0x003887AE47A4 >
0x003887AD2018
___
Xen-ppc-devel mailing list
Xen-pp
I just saw a case of the timebase sync hang using vanilla Xen/PPC:
changeset: 12468:9148f7816d00
tag: tip
user:Jimi Xenidis <[EMAIL PROTECTED]>
date:Tue Oct 24 19:11:00 2006 -0400
summary: [TOOLS][POWERPC]fixes to put back commandline in prose builder
The consol
-09.133343
===
spinning up secondary processor #3: ping = 0x:
Note that SLOF reverted to PHYP four times in the 904 runs without this
patch applied, and never in the 2329 runs with this patch applied.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
exceptions.S |4
Ensure that the store to pa.hype_stack_base will be seen before the
store of pa to global_cpu_table[cpuid].
I have been unable to demonstrate this causing a problem in practice
despite many attempts, but I think it should go in by inspection anyway.
Signed-off-by: Amos Waterland <[EM
This patch rolls up and rebases the following patches for submission
against current tip of tree:
* Memory barrier after sp store
* Flush the ERAT early for secondary CPUs
* SMP and IPI support
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
changeset : b30cb72ed5e2+31ae0
ma
On Fri, Nov 10, 2006 at 03:55:26AM +0100, Segher Boessenkool wrote:
> > p = probability of success = .997 (897 / 900)
> > q = probability of failure = .003 (1.0 - .997)
> > n = number of trials = 2323
> > X = number of successes= 2323
> >
> >Applying these to the binomial probability form
On Mon, Nov 13, 2006 at 12:08:33PM -0500, Jimi Xenidis wrote:
> On Nov 9, 2006, at 8:04 PM, Amos Waterland wrote:
> >This patch rolls up and rebases the following patches for submission
> >against current tip of tree:
> >
> > * Memory barrier after sp store
> > * F
solution until we completely virtualize the PIC at some point in
the future.
Signed-off-by: Amos Waterland <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/xen/evtchn.c |1 +
arch/powerpc/sysdev/mpic.c |4
include/asm-powerpc/mpic.h |2 ++
3 files chan
comitted
seperately, and to make the status messages about waiting for remote
function completion ACKs only kick in after a full second has passed.
Note that this path REQUIRES that some form of the dom0 Linux patch
titled "Make Linux bail out of IPI vector reset" be applied.
Signed-of
This will have to be reworked and broken up into individual parts for
submission, but here is what is necessary to make 'C-a C-a C-a t' work
properly.
Jimi, when you disassemble xen-syms compiled without this patch, do you
see a bogus infinite loop in read_clocks? The compiler is not told that
re
On Mon, Nov 27, 2006 at 12:04:36PM -0500, Maria Butrico wrote:
> This problem is solved on the latest version of Xen.
I do not think the problem is completely solved. I am still seeing
repeated prints like this:
(XEN) CPU[PIR:1 IPI:1 Logical:1] Hello World!CPU[PIR:1 IPI:1 Logical:1]
Hello Worl
1 - 100 of 122 matches
Mail list logo
