RE: Machine Check in P2010(e500v2)

-----Original Message-----
From: Joakim Tjernlund [mailto:Joakim.Tjernlund@infinera.com]
Sent: Wednesday, September 06, 2017 3:54 PM
To: linuxppc-dev@lists.ozlabs.org; Leo Li <redacted>; York Sun
[off-list ref]
Subject: Re: Machine Check in P2010(e500v2)
=20
On Wed, 2017-09-06 at 20:28 +0000, Leo Li wrote:

quoted

quoted

-----Original Message-----
From: Joakim Tjernlund [mailto:Joakim.Tjernlund@infinera.com]
Sent: Wednesday, September 06, 2017 3:17 PM
To: linuxppc-dev@lists.ozlabs.org; Leo Li <redacted>; York
Sun [off-list ref]
Subject: Re: Machine Check in P2010(e500v2)

On Wed, 2017-09-06 at 19:31 +0000, Leo Li wrote:

quoted

quoted

-----Original Message-----
From: York Sun
Sent: Wednesday, September 06, 2017 10:38 AM
To: Joakim Tjernlund <redacted>; linuxppc-
dev@lists.ozlabs.org; Leo Li [off-list ref]
Subject: Re: Machine Check in P2010(e500v2)

Scott is no longer with Freescale/NXP. Adding Leo.

On 09/05/2017 01:40 AM, Joakim Tjernlund wrote:

quoted

So after some debugging I found this bug:

@@ -996,7 +998,7 @@ int fsl_pci_mcheck_exception(struct pt_regs

*regs)

quoted

quoted

quoted

quoted

quoted

         if (is_in_pci_mem_space(addr)) {
                 if (user_mode(regs)) {
                         pagefault_disable();
-                       ret =3D get_user(regs->nip, &inst);
+                       ret =3D get_user(inst, (__u32 __user
+ *)regs->nip);
                         pagefault_enable();
                 } else {
                         ret =3D probe_kernel_address(regs->nip=

,

quoted

quoted

quoted

quoted

quoted

inst);

However, the kernel still locked up after fixing that.
Now I wonder why this fixup is there in the first place? The
routine will not really fixup the insn, just return 0xffffffff
for the failing read and then advance the process NIP.

You are right.  The code here only gives 0xffffffff to the load
instructions and

continue with the next instruction when the load instruction is
causing the machine check.  This will prevent a system lockup when
reading from PCI/RapidIO device which is link down.

quoted

I don't know what is actual problem in your case.  Maybe it is a
write

instruction instead of read?   Or the code is in a infinite loop wait=

ing for a

valid

quoted

quoted

read result?  Are you able to do some further debugging with the NIP
correctly printed?

quoted

According to the MC it is a Read and the NIP also leads to a read in =

the

program.

quoted

quoted

ATM, I have disabled the fixup but I will enable that again.
Question, is it safe add a small printk when this MC happens(after
fixing up)? I need to see that it has happened as the error is somewh=

at

random.

quoted

I think it is safe to add printk as the current machine check handlers =

are also

using printk.
=20
I hope so, but if the fixup fires there is no printk at all so I was a bi=

t unsure.

Don't like this fixup though, is there not a better way than faking a rea=

d to user

space(or kernel for that matter) ?

I don't have a better idea.  Without the fixup, the offending load instruct=
ion will never finish if there is anything wrong with the backing device an=
d freeze the whole system.  Do you have any suggestion in mind?

Regards,
Leo