Re: [XenPPC] [PATCH] Fix Maple SMP spurious interrupts assert

[Jimi Xenidis]

I am not familiar with "SMP spurious interrupts assert"
   panic("Too many (%d) spurrious interrupts in a row\n"
  "  Known problem, please halt and let machine idle/ 
cool "

  "  then reboot\n",
  100);
message?
That is independent of SMP, we get that in UP as well.
I'm willing to believe that this patch will make it so the panic does  
not happen.


On Oct 11, 2006, at 8:05 PM, Amos Waterland wrote:

This lets Xen with the SMP patch boot reliably on the Maple-D  
platform I

have access to.


Sure, I can even run one dom, but at some point my 405 either halts  
or resets the 970s

at seemingly random points.
I also get:
  PIBS $ Error: Magic number in message area NVRAM is not valid.
  Error: Magic number in message area NVRAM is not valid.
  Error: Magic number in message area NVRAM is not valid.

Which makes me a little woried that we have a wild write somewhere.



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.


I send a suggestion for this patch.. I will attempt that as well.

-JX

___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel

Re: [XenPPC] [PATCH] Fix Maple SMP spurious interrupts assert

[Jimi Xenidis]

On Oct 11, 2006, at 8:05 PM, Amos Waterland wrote:

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 <[EMAIL PROTECTED]>


Wow, thats it?! this is good news, I'll have to verify it on my maple.
I think we can patch this better by copying:
  arch/powerpc/platforms/maple/setup.c maple_init_IRQ
into
  arch/powerpc/platforms/xen/evtchn.c

and simply drop:
  MPIC_WANTS_RESET
in the mpic_alloc() call.

and then have no changes in common code.

this make sense to you?
-JX

___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel

[XenPPC] [PATCH] Fix Maple SMP spurious interrupts assert

[Amos Waterland]

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 <[EMAIL PROTECTED]>

---

 Makefile |4 
 mpic.c   |2 ++
 2 files changed, 6 insertions(+)

diff -r b9e38b262f64 arch/powerpc/sysdev/Makefile
--- a/arch/powerpc/sysdev/Makefile  Sun Oct 08 14:22:12 2006 -0400
+++ b/arch/powerpc/sysdev/Makefile  Wed Oct 11 19:35:53 2006 -0400
@@ -1,5 +1,9 @@ ifeq ($(CONFIG_PPC64),y)
 ifeq ($(CONFIG_PPC64),y)
 EXTRA_CFLAGS   += -mno-minimal-toc
+endif
+
+ifeq ($(CONFIG_PPC_XEN),y)
+EXTRA_CFLAGS   += -DCONFIG_PPC_XEN
 endif
 
 obj-$(CONFIG_MPIC) += mpic.o
diff -r b9e38b262f64 arch/powerpc/sysdev/mpic.c
--- a/arch/powerpc/sysdev/mpic.cSun Oct 08 14:22:12 2006 -0400
+++ b/arch/powerpc/sysdev/mpic.cWed Oct 11 19:40:07 2006 -0400
@@ -619,6 +619,7 @@ struct mpic * __init mpic_alloc(unsigned
mpic->tmregs = mpic->gregs + ((MPIC_TIMER_BASE - MPIC_GREG_BASE) >> 2);
BUG_ON(mpic->gregs == NULL);
 
+#ifndef CONFIG_PPC_XEN
/* Reset */
if (flags & MPIC_WANTS_RESET) {
mpic_write(mpic->gregs, MPIC_GREG_GLOBAL_CONF_0,
@@ -628,6 +629,7 @@ struct mpic * __init mpic_alloc(unsigned
   & MPIC_GREG_GCONF_RESET)
mb();
}
+#endif
 
/* Read feature register, calculate num CPUs and, for non-ISU
 * MPICs, num sources as well. On ISU MPICs, sources are counted

___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel