[XenPPC] multicast function invocations

2006-11-28 Thread Amos Waterland
To summarize the situation, I found two problems. 1. Core Xen has a bug (I believe) in which they do not mark their cpu mask volatile, so the compiler generates an infinite loop in read_clocks. I will send some patches upstream to resolve this issue. 2. Xen/PPC has a problem in that its

Re: [XenPPC] [xenppc-unstable] [XEN][POWERPC] SMP/IPI/MB combined

2006-11-28 Thread Jimi Xenidis
On Nov 28, 2006, at 1:37 AM, Amos Waterland wrote: 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

[XenPPC] [xenppc-unstable] cpu_relax() needs to call barrier()

2006-11-28 Thread Xen patchbot-xenppc-unstable
# HG changeset patch # User Jimi Xenidis [EMAIL PROTECTED] # Node ID a8e67a19c3255a6bbc0aaa5c9e1736f1ddd76f6c # Parent cc45282daf3d242fdcf6e858c0b18b7f1086a318 cpu_relax() needs to call barrier() Signed-off-by: Jimi Xenidis [EMAIL PROTECTED] --- xen/include/asm-powerpc/processor.h |3 ++- 1

Re: [XenPPC] Crash on js12

2006-11-28 Thread Jimi Xenidis
On Nov 28, 2006, at 2:24 AM, Amos Waterland wrote: 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

Re: [XenPPC] [xenppc-unstable] [XEN][POWERPC] SMP/IPI/MB combined

2006-11-28 Thread Amos Waterland
On Tue, Nov 28, 2006 at 10:47:31AM -0500, Jimi Xenidis wrote: On Nov 28, 2006, at 1:37 AM, Amos Waterland wrote: The compiler is not told that read_clocks_cpumask is volatile, so it is free to turn that loop into an infinite loop, as my gcc 4.1.1 cross-compiler does. I am surprised that

Re: [XenPPC] multicast function invocations

2006-11-28 Thread Jimi Xenidis
On Nov 28, 2006, at 3:17 AM, Amos Waterland wrote: To summarize the situation, I found two problems. 1. Core Xen has a bug (I believe) in which they do not mark their cpu mask volatile, so the compiler generates an infinite loop in read_clocks. I will send some patches upstream to

[XenPPC] [PATCH] Make IPI handlers run in parallel

2006-11-28 Thread Amos Waterland
Make a copy of the vector information while protected by a lock, then release the lock and use that information to acknowledge and act on the IPI. We always have a consistent set of information in this case, as opposed to the case of dropping and reaquiring the lock. This patch makes

[XenPPC] [PATCH] Relax IPI stall timeout

2006-11-28 Thread Amos Waterland
When using the register dump feature of Xen, one will often see a message about an IPI finish stall. This is because we expected IPI handlers to run very quickly, but in this case, the handler is doing a lot of console I/O in order to print the register contents. So relax the stall timeout.

[XenPPC] [PATCH] Generalized parallel IPI handlers

2006-11-28 Thread Amos Waterland
Our problem with x86 do_IRQ is that it does not respect IRQ_PER_CPU, so make our logic reflect that generically. We remove the spin lock in this case, since the programming convention is to update irq descs atomically (if at all). This patch allows read_clocks to work properly. Signed-off-by:

[XenPPC] [PATCH] Do not override smp function call wait flag

2006-11-28 Thread Amos Waterland
Do not override the caller's wishes regarding waiting for smp function call completion. I was being too conservative in this respect: the lock protects the call_data structure, and the function called is expected to be threadsafe. Signed-off-by: Amos Waterland [EMAIL PROTECTED] --- smp.c |

Re: [XenPPC] [PATCH] Generalized parallel IPI handlers

2006-11-28 Thread Jimi Xenidis
pushed, thanks! -JX On Nov 28, 2006, at 4:27 PM, Amos Waterland wrote: Our problem with x86 do_IRQ is that it does not respect IRQ_PER_CPU, so make our logic reflect that generically. We remove the spin lock in this case, since the programming convention is to update irq descs atomically (if

[XenPPC] [xenppc-unstable] [XEN][POWERPC] Generalized parallel IPI handlers

2006-11-28 Thread Jimi Xenidis
# HG changeset patch # User Jimi Xenidis [EMAIL PROTECTED] # Node ID 1e1a63408129bea2d87f485c52f1be21ada35ff0 # Parent a2a4a6bdc5cdedf3fe90626de9b16c9ee898f178 [XEN][POWERPC] Generalized parallel IPI handlers Our problem with x86 do_IRQ is that it does not respect IRQ_PER_CPU, so make our

[XenPPC] [xenppc-unstable] [XEN][POWERPC] Do not override smp function call wait flag

2006-11-28 Thread Xen patchbot-xenppc-unstable
# HG changeset patch # User Jimi Xenidis [EMAIL PROTECTED] # Node ID e01e08ca629b4f154828b0976a58df8767558aec # Parent 1e1a63408129bea2d87f485c52f1be21ada35ff0 [XEN][POWERPC] Do not override smp function call wait flag Do not override the caller's wishes regarding waiting for smp function call

[XenPPC] [PATCH] Fix IPI stall timeout

2006-11-28 Thread Amos Waterland
When using the register dump feature of Xen, one will sometimes see a message about an IPI finish stall. This is because of an int to long comparison bug, so fix it by doing proper nanosecond based time accounting. As a side note, our IPI remote function call latency of completion on a JS21

Re: [XenPPC] [PATCH] Fix IPI stall timeout

2006-11-28 Thread Jimi Xenidis
On Nov 28, 2006, at 5:55 PM, Amos Waterland wrote: When using the register dump feature of Xen, one will sometimes see a message about an IPI finish stall. This is because of an int to long comparison bug, so fix it by doing proper nanosecond based time accounting. As a side note, our IPI

[XenPPC] [xenppc-unstable] [XEN][POWERPC] cleanup hard tabs

2006-11-28 Thread Xen patchbot-xenppc-unstable
# HG changeset patch # User Jimi Xenidis [EMAIL PROTECTED] # Node ID bb5491a55606b88c86f380aae406f7077c3118bc # Parent 2e909d6f2ab767fe5723a97e2f5413f876167296 [XEN][POWERPC] cleanup hard tabs allowed in some files in order to track linux lineage --- xen/arch/powerpc/bitops.c | 124

Re: SMP issue (Re: Status summary Was: [XenPPC] Cannot boot from local disk)

2006-11-28 Thread Amos Waterland
I can confirm that the JS20 of Kawachiya-san does not boot current Xen/PPC without the nosmp option. I got some time on the blade and narrowed the point of failure down to somewhere in the synchronize_rcu call that synchronize_net makes in dom0 Linux init. I will work on it tomorrow during JST

Re: SMP issue (Re: Status summary Was: [XenPPC] Cannot boot from local disk)

2006-11-28 Thread Kiyokuni Kawachiya
Amos, I can confirm that the JS20 of Kawachiya-san does not boot current Xen/PPC without the nosmp option. I got some time on the blade and narrowed the point of failure down to somewhere in the synchronize_rcu call that synchronize_net makes in dom0 Linux init. I will work on it tomorrow

Re: SMP issue (Re: Status summary Was: [XenPPC] Cannot boot from local disk)

2006-11-28 Thread Amos Waterland
On Wed, Nov 29, 2006 at 03:14:54PM +0900, Kiyokuni Kawachiya wrote: I can confirm that the JS20 of Kawachiya-san does not boot current Xen/PPC without the nosmp option. I got some time on the blade and narrowed the point of failure down to somewhere in the synchronize_rcu call that