[3.5.y.z extended stable] Patch "parisc: Do not crash 64bit SMP kernels on machines with >= 4GB RAM" has been added to staging queue

[Luis Henriques]

This is a note to let you know that I have just added a patch titled

    parisc: Do not crash 64bit SMP kernels on machines with >= 4GB RAM

to the linux-3.5.y-queue branch of the 3.5.y.z extended stable tree 
which can be found at:

 http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.5.y-queue

If you, or anyone else, feels it should not be added to this tree, please 
reply to this email.

For more information about the 3.5.y.z tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable

Thanks.
-Luis

------

>From 743f04eb6aa71e2db46b89d5162c020015755d30 Mon Sep 17 00:00:00 2001
From: Helge Deller <deller at gmx.de>
Date: Sat, 26 Oct 2013 23:19:25 +0200
Subject: parisc: Do not crash 64bit SMP kernels on machines with >= 4GB RAM

commit 54e181e073fc1415e41917d725ebdbd7de956455 upstream.

Since the beginning of the parisc-linux port, sometimes 64bit SMP kernels were
not able to bring up other CPUs than the monarch CPU and instead crashed the
kernel.  The reason was unclear, esp. since it involved various machines (e.g.
J5600, J6750 and SuperDome). Testing showed, that those crashes didn't happened
when less than 4GB were installed, or if a 32bit Linux kernel was booted.

In the end, the fix for those SMP problems is trivial:
During the early phase of the initialization of the CPUs, including the monarch
CPU, the PDC_PSW firmware function to enable WIDE (=64bit) mode is called.
It's documented that this firmware function may clobber various registers, and
one one of those possibly clobbered registers is %cr30 which holds the task
thread info pointer.

Now, if %cr30 would always have been clobbered, then this bug would have been
detected much earlier. But lots of testing finally showed, that - at least for
%cr30 - on some machines only the upper 32bits of the 64bit register suddenly
turned zero after the firmware call.

So, after finding the root cause, the explanation for the various crashes
became clear:
- On 32bit SMP Linux kernels all upper 32bit were zero, so we didn't faced this
  problem.
- Monarch CPUs in 64bit mode always booted sucessfully, because the inital task
  thread info pointer was below 4GB.
- Secondary CPUs booted sucessfully on machines with less than 4GB RAM because
  the upper 32bit were zero anyay.
- Secondary CPus failed to boot if we had more than 4GB RAM and the task thread
  info pointer was located above the 4GB boundary.

Finally, the patch to fix this problem is trivial by saving the %cr30 register
before the firmware call and restoring it afterwards.

Signed-off-by: Helge Deller <deller at gmx.de>
Signed-off-by: John David Anglin <dave.anglin at bell.net>
Signed-off-by: Helge Deller <deller at gmx.de>
Signed-off-by: Luis Henriques <luis.henriques at canonical.com>
---
 arch/parisc/kernel/head.S | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/parisc/kernel/head.S b/arch/parisc/kernel/head.S
index 37aabd7..d2d5825 100644
--- a/arch/parisc/kernel/head.S
+++ b/arch/parisc/kernel/head.S
@@ -195,6 +195,8 @@ common_stext:
 	ldw             MEM_PDC_HI(%r0),%r6
 	depd            %r6, 31, 32, %r3        /* move to upper word */

+	mfctl		%cr30,%r6		/* PCX-W2 firmware bug */
+
 	ldo             PDC_PSW(%r0),%arg0              /* 21 */
 	ldo             PDC_PSW_SET_DEFAULTS(%r0),%arg1 /* 2 */
 	ldo             PDC_PSW_WIDE_BIT(%r0),%arg2     /* 2 */
@@ -203,6 +205,8 @@ common_stext:
 	copy            %r0,%arg3

 stext_pdc_ret:
+	mtctl		%r6,%cr30		/* restore task thread info */
+
 	/* restore rfi target address*/
 	ldd             TI_TASK-THREAD_SZ_ALGN(%sp), %r10
 	tophys_r1       %r10
--
1.8.3.2