Re: Does 2.2.14 Break SMP for PPC?

From: Tom Sightler <redacted>
Subject: Does 2.2.14 Break SMP for PPC?
Should SMP be working in 2.2.14?  If so, does anyone else have any
suggestions on what may be wrong?  I really have no pressing need to
upgrade to 2.2.14 right away since 2.2.13 with SMP has been running very
stable, but I always like to keep my kernels updated and these machines

I also had the same problem.  After updating to 2.2.14, the secondary
processor get stuck during the boot time and smp become disabled.  After
looking at the patch files, I noticed there is a small change in
linux/arch/ppc/kernel/head.S. There are three lines added in the beginning
of the secondary CPU initialization.

From patch-2.2.14:

@@ -245,13 +233,16 @@
        bl      prom_init
        .globl  __secondary_start
 __secondary_start:
-/*
- * Use the first pair of BAT registers to map the 1st 16MB
+/* Switch MMU off, clear BATs and flush TLB */
+       bl      mmu_off
+       bl      clear_bats
+       bl      flush_tlbs
+
+/* Use the first pair of BAT registers to map the 1st 16MB
  * of RAM to KERNELBASE.  From this point on we can't safely
  * call OF any more.
  */
        lis     r11,KERNELBASE@h

Well, I don't know PPC assembly, but I commented out the three "bl ... "
lines.  Then the 2nd CPU stack message went away and SMP was enabled.
However it it really unstable, though.  So the problem with 2.2.14 SMP
seems to be around here.  Probably someone who knows PPC assembly can
help here...

Naoki Takebayashi     [off-list ref]

--- Dept. of Biology, Indiana University, Jordan Hall 142
--- 1001 E. Third St. Bloomington, IN 47405-3700 USA

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Thu, Jan 6, 2000, Naoki Takebayashi [off-list ref] wrote:

I'm the one responsible for those few lines of code, I'm a bit annoyed
that it broke SMP since I don't have an SMP card to play with.

Cort, Paul, any clue about what's wrong ? I'm wondering if it's related
to the physical address returned by OF and used in mmu_off which might be
wrong for the second CPU...


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/