[PATCH] Workaround for RTAS bug

[PATCH] Workaround for RTAS bug

[Mike Kravetz]

A bug in the RTAS services incorrectly interprets some bits in the CR
when called from the OS.  Specifically, bits in CR4.  The result could
be a firmware crash that also takes down the partition.  A firmware
fix is in the works.  We have seen this situation when performing DLPAR
operations.  As a temporary workaround, clear the CR in enter_rtas().
Note that enter_rtas() will not set any bits in CR4 before calling RTAS.

Also note that the 32 bit version of enter_rtas() should have the same
work around even though the chances of hitting the bug are much smaller
due to the lack of DLPAR on 32 bit kernels.  However, my assembly skills
are a bit rusty and the 32 bit code doesn't seem to follow the conventions
for where things should be saved.  In addition, I don't have a system
to test 32 bit kernels.  Help creating and at least touch testing the
same workaround for 32 bit would be appreciated.

Signed-off-by: Mike Kravetz <kravetz@us.ibm.com>

diff -Naupr linux-2.6.16/arch/powerpc/kernel/entry_64.S linux-2.6.16.work/arch/powerpc/kernel/entry_64.S
--- linux-2.6.16/arch/powerpc/kernel/entry_64.S	2006-03-20 05:53:29.000000000 +0000
+++ linux-2.6.16.work/arch/powerpc/kernel/entry_64.S	2006-03-27 17:17:59.000000000 +0000
@@ -616,6 +616,12 @@ _GLOBAL(enter_rtas)
 	mfsrr1	r10
 	std	r10,_SRR1(r1)
 
+	/* Temporary workaround to clear CR until RTAS can be modified to
+	 * ignore all bits.
+	 */
+	li	r0,0
+	mtcr	r0
+
 	/* There is no way it is acceptable to get here with interrupts enabled,
 	 * check it with the asm equivalent of WARN_ON
 	 */

Re: [PATCH] Workaround for RTAS bug

[Mike Kravetz]

On Mon, Mar 27, 2006 at 03:20:00PM -0800, Mike Kravetz wrote:
> Also note that the 32 bit version of enter_rtas() should have the same
> work around even though the chances of hitting the bug are much smaller
> due to the lack of DLPAR on 32 bit kernels.  However, my assembly skills
> are a bit rusty and the 32 bit code doesn't seem to follow the conventions
> for where things should be saved.  In addition, I don't have a system
> to test 32 bit kernels.  Help creating and at least touch testing the
> same workaround for 32 bit would be appreciated.

Upon further examination, there does not appear to be any exposure to
this issue on 32 bit kernels.  Therefore, the original patch for 64 bit
should be the only workaround that is required.

-- 
Mike