powerpc: Fix the corrupt r3 error during MCE handling.
PATCH 1/1 powerpc: Fix the corrupt r3 error during MCE handling.
From: Mahesh Salgaonkar <[email protected]>
During Machine Check interrupt on pseries platform, R3 generally points to memory region inside RTAS (FWNMI) area. We see r3 corruption because when RTAS delivers the machine check exception it passes the address inside FWNMI area with the top most bit set. This patch fixes this issue by masking top two bit in machine check exception handler.
--- arch/powerpc/platforms/pseries/ras.c | 3 +++ 1 file changed, 3 insertions(+)
arch/powerpc/platforms/pseries/ras.c +3 -0
@@ -287,6 +287,9 @@ static struct rtas_error_log *fwnmi_get_errinfo(struct pt_regs *regs)unsigned long *savep;struct rtas_error_log *h, *errhdr =NULL ; +/* Mask top two bits */ + regs->gpr[3 ] &= ~(0x3UL <<62 ); +if (!VALID_FWNMI_BUFFER (regs->gpr[3 ])) {printk (KERN_ERR "FWNMI: corrupt r3 0x%016lx\n" , regs->gpr[3 ]);return NULL ;
Quoted 7 lines · Mahesh J Salgaonkar
From: Mahesh Salgaonkar <[email protected]>
During Machine Check interrupt on pseries platform, R3 generally points to memory region inside RTAS (FWNMI) area. We see r3 corruption because when RTAS delivers the machine check exception it passes the address inside FWNMI area with the top most bit set. This patch fixes this issue by masking top two bit in machine check exception handler.
I always got that error and used to wonder why I find FWNMI corrupt. IS this a rtas bug or is it documented in papr ?
Quoted 12 lines
Signed-off-by Mahesh Salgaonkar <[email protected]>--- arch/powerpc/platforms/pseries/ras.c | 3 +++ 1 file changed, 3 insertions(+)arch/powerpc/platforms/pseries/ras.c +0
-0
arch/powerpc/platforms/pseries/ras.c static struct rtas_error_log *fwnmi_get_errinfo(struct pt_regs *regs) · line 295
Quoted 9 lines
arch/powerpc/platforms/pseries/ras.c +3
-0@@ -287,6 +287,9 @@ static struct rtas_error_log *fwnmi_get_errinfo(struct pt_regs *regs)unsigned long *savep;struct rtas_error_log *h, *errhdr =NULL ; +/* Mask top two bits */ + regs->gpr[3 ] &= ~(0x3UL <<62 ); +if (!VALID_FWNMI_BUFFER (regs->gpr[3 ])) {printk (KERN_ERR "FWNMI: corrupt r3 0x%016lx\n" , regs->gpr[3 ]);return NULL ;
-aneesh
Quoted 4 lines · Aneesh Kumar K.V
Quoted 2 lines · Mahesh J Salgaonkar
From: Mahesh Salgaonkar <[email protected]>
Quoted 8 lines
Quoted 5 lines
During Machine Check interrupt on pseries platform, R3 generally points to memory region inside RTAS (FWNMI) area. We see r3 corruption because when RTAS delivers the machine check exception it passes the address inside FWNMI area with the top most bit set. This patch fixes this issue by masking top two bit in machine check exception handler.
I always got that error and used to wonder why I find FWNMI corrupt. IS this a rtas bug or is it documented in papr ?
Nope. There is no mention of it in PAPR. It looks like a bug in RTAS.
Quoted 31 lines
Quoted 14 lines
Signed-off-by Mahesh Salgaonkar <[email protected]>--- arch/powerpc/platforms/pseries/ras.c | 3 +++ 1 file changed, 3 insertions(+)arch/powerpc/platforms/pseries/ras.c +0
-0arch/powerpc/platforms/pseries/ras.c static struct rtas_error_log *fwnmi_get_errinfo(struct pt_regs *regs) · line 295
Quoted 9 lines
arch/powerpc/platforms/pseries/ras.c +3
-0@@ -287,6 +287,9 @@ static struct rtas_error_log *fwnmi_get_errinfo(struct pt_regs *regs)unsigned long *savep;struct rtas_error_log *h, *errhdr =NULL ; +/* Mask top two bits */ + regs->gpr[3 ] &= ~(0x3UL <<62 ); +if (!VALID_FWNMI_BUFFER (regs->gpr[3 ])) {printk (KERN_ERR "FWNMI: corrupt r3 0x%016lx\n" , regs->gpr[3 ]);return NULL ;-aneesh
_______________________________________________
Linuxppc-dev mailing list
[email protected]
https://lists.ozlabs.org/listinfo/linuxppc-dev
Quoted 4 lines · Mahesh Jagannath Salgaonkar
Quoted 2 lines
I always got that error and used to wonder why I find FWNMI corrupt. IS this a rtas bug or is it documented in papr ?
Nope. There is no mention of it in PAPR. It looks like a bug in RTAS.
Typically, the top bit in real mode means to ignore the HRMOR... I think it's some old bug in RTAS indeed.
Cheers,
Ben.
Quoted 18 lines · Mahesh J Salgaonkar
From: Mahesh Salgaonkar <[email protected]>
During Machine Check interrupt on pseries platform, R3 generally points to memory region inside RTAS (FWNMI) area. We see r3 corruption because when RTAS delivers the machine check exception it passes the address inside FWNMI area with the top most bit set. This patch fixes this issue by masking top two bit in machine check exception handler.
Signed-off-by Mahesh Salgaonkar <[email protected]>--- arch/powerpc/platforms/pseries/ras.c | 3 +++ 1 file changed, 3 insertions(+)arch/powerpc/platforms/pseries/ras.c +0
-0
arch/powerpc/platforms/pseries/ras.c static struct rtas_error_log *fwnmi_get_errinfo(struct pt_regs *regs) · line 291
Quoted 5 lines
arch/powerpc/platforms/pseries/ras.c +2
-0@@ -287,6 +287,9 @@ static struct rtas_error_log *fwnmi_get_errinfo(struct pt_regs *regs)unsigned long *savep;struct rtas_error_log *h, *errhdr =NULL ; +/* Mask top two bits */ + regs->gpr[3 ] &= ~(0x3UL <<62 );
We need to replace this "62" with a shift macro specifying the significance of these top two address bits in the real mode.
Quoted 22 lines · Anshuman Khandual
Quoted 21 lines · Mahesh J Salgaonkar
From: Mahesh Salgaonkar <[email protected]>
During Machine Check interrupt on pseries platform, R3 generally points to memory region inside RTAS (FWNMI) area. We see r3 corruption because when RTAS delivers the machine check exception it passes the address inside FWNMI area with the top most bit set. This patch fixes this issue by masking top two bit in machine check exception handler.
Signed-off-by Mahesh Salgaonkar <[email protected]>--- arch/powerpc/platforms/pseries/ras.c | 3 +++ 1 file changed, 3 insertions(+)arch/powerpc/platforms/pseries/ras.c +0
-0@@ -287,6 +287,9 @@ static struct rtas_error_log *fwnmi_get_errinfo(struct pt_regs *regs)unsigned long *savep;struct rtas_error_log *h, *errhdr =NULL ;
Quoted 5 lines
arch/powerpc/platforms/pseries/ras.c static struct rtas_error_log *fwnmi_get_errinfo(struct pt_regs *regs) · line 291
Quoted 2 lines
arch/powerpc/platforms/pseries/ras.c +2
-0+/* Mask top two bits */ + regs->gpr[3 ] &= ~(0x3UL <<62 );We need to replace this "62" with a shift macro specifying the significance of these top two address bits in the real mode.
huh??
(gdb) p/t 0x3ull << 62
$4 = 1100000000000000000000000000000000000000000000000000000000000000
Why you need an extra comment to explain 62. But yes, we can possibly write that this is an RTAS bug
-aneesh
Quoted 30 lines · Aneesh Kumar K.V
Quoted 22 lines · Anshuman Khandual
Quoted 21 lines · Mahesh J Salgaonkar
From: Mahesh Salgaonkar <[email protected]>
During Machine Check interrupt on pseries platform, R3 generally points to memory region inside RTAS (FWNMI) area. We see r3 corruption because when RTAS delivers the machine check exception it passes the address inside FWNMI area with the top most bit set. This patch fixes this issue by masking top two bit in machine check exception handler.
Signed-off-by Mahesh Salgaonkar <[email protected]>--- arch/powerpc/platforms/pseries/ras.c | 3 +++ 1 file changed, 3 insertions(+)arch/powerpc/platforms/pseries/ras.c +0
-0@@ -287,6 +287,9 @@ static struct rtas_error_log *fwnmi_get_errinfo(struct pt_regs *regs)unsigned long *savep;struct rtas_error_log *h, *errhdr =NULL ;Quoted 5 lines
arch/powerpc/platforms/pseries/ras.c static struct rtas_error_log *fwnmi_get_errinfo(struct pt_regs *regs) · line 291
Quoted 2 lines
arch/powerpc/platforms/pseries/ras.c +2
-0+/* Mask top two bits */ + regs->gpr[3 ] &= ~(0x3UL <<62 );We need to replace this "62" with a shift macro specifying the significance of these top two address bits in the real mode.
Quoted 7 lines
huh??
(gdb) p/t
0x3ull<< 62
$4 = 1100000000000000000000000000000000000000000000000000000000000000Why you need an extra comment to explain 62. But yes, we can possibly write that this is an RTAS bug
62 was just to point at the top two address bits in the real mode. Extra comment request was to specify what is the RTAS behaviour or bug with respect to those top two bits and how we are dealing with them here in this fix.