From: Martijn de Gouw <hidden> Date: 2012-11-02 12:16:22
Hi,
The following commit:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;h=e49b1fae0ba4d06b29bd753a961abb447566bf4a
causes confusion, because it prints "Machine check in kernel mode" also when the bus error is actually in user space. When using RapidIO memory mapped access, and the device is removed or powered off, then a bus error is generated. This is on a freescale mpc8548 powerpc. Due to removing the user_mode check, the kernel calls "die" which causes the process to die with a BUS error, regardless of having a SIGBUS handler or not.
Therefore I request to put this check back, and even to put the removed code at the top of the machine check handler because there is no point in trying to recover from a user space bus error anyway.
Best regards,
--
Martijn de Gouw
Engineer
Prodrive B.V.
Mobile: +31 63 17 76 161
Phone: +31 40 26 76 200
=20
causes confusion, because it prints "Machine check in kernel mode" =20
also when the bus error is actually in user space. When using RapidIO =20
memory mapped access, and the device is removed or powered off, then =20
a bus error is generated. This is on a freescale mpc8548 powerpc. Due =20
to removing the user_mode check, the kernel calls "die" which causes =20
the process to die with a BUS error, regardless of having a SIGBUS =20
handler or not.
=20
Therefore I request to put this check back, and even to put the =20
removed code at the top of the machine check handler because there is =20
no point in trying to recover from a user space bus error anyway.
Why is there no point trying to recover? For example, see MCSR_ICPERR =20
and MCSR_DCPERR_MC in machine_check_e500mc. The machine check is just =20
letting us know that there was an error and the read-only cache got =20
dumped (i.e. it was a correctable error).
-Scott=
Therefore I request to put this check back, and even to put the
removed code at the top of the machine check handler because there is
no point in trying to recover from a user space bus error anyway.
=20
Why is there no point trying to recover? For example, see MCSR_ICPERR
and MCSR_DCPERR_MC in machine_check_e500mc. The machine check is just
letting us know that there was an error and the read-only cache got
dumped (i.e. it was a correctable error).
Oh I overlooked those cases; those correctable errors shouldn't be bus erro=
rs for the user space process?
Hmm I guess there is no simple solution then, since the "recover" function =
also prints the kernel messages about the machine check being in kernel mod=
e without having checked whether it really was in kernel mode. In the past =
the user mode check was in between.
Micha
From: Scott Wood <hidden> Date: 2012-11-06 16:34:40
On 11/06/2012 03:21:37 AM, Micha Nelissen wrote:
From: Scott Wood [mailto:scottwood@freescale.com]
quoted
quoted
Therefore I request to put this check back, and even to put the
removed code at the top of the machine check handler because =20
there is
quoted
quoted
no point in trying to recover from a user space bus error anyway.
Why is there no point trying to recover? For example, see =20
MCSR_ICPERR
quoted
and MCSR_DCPERR_MC in machine_check_e500mc. The machine check is =20
just
quoted
letting us know that there was an error and the read-only cache got
dumped (i.e. it was a correctable error).
=20
Oh I overlooked those cases; those correctable errors shouldn't be =20
bus errors for the user space process?
=20
Hmm I guess there is no simple solution then, since the "recover" =20
function also prints the kernel messages about the machine check =20
being in kernel mode without having checked whether it really was in =20
kernel mode. In the past the user mode check was in between.
It shouldn't be that difficult to make it say "in user mode" or "in =20
kernel mode" depending on which it was... or just remove that phrase =20
altogether and let the following output indicate whether it was in =20
kernel mode.
-Scott=
Hmm I guess there is no simple solution then, since the "recover"
function also prints the kernel messages about the machine check
being in kernel mode without having checked whether it really was in
kernel mode. In the past the user mode check was in between.
=20
It shouldn't be that difficult to make it say "in user mode" or "in
kernel mode" depending on which it was... or just remove that phrase
altogether and let the following output indicate whether it was in
kernel mode.
Well printing the correct message is only part of it: do "we" want to pass =
guarded load errors (RapidIO bus errors) to user space or not? And if we pa=
ss them, should we print a kernel message at all?
Micha
From: Scott Wood <hidden> Date: 2012-11-06 20:13:21
On 11/06/2012 10:43:19 AM, Micha Nelissen wrote:
From: Scott Wood [mailto:scottwood@freescale.com]
quoted
quoted
Hmm I guess there is no simple solution then, since the "recover"
function also prints the kernel messages about the machine check
being in kernel mode without having checked whether it really was =20
in
quoted
quoted
kernel mode. In the past the user mode check was in between.
It shouldn't be that difficult to make it say "in user mode" or "in
kernel mode" depending on which it was... or just remove that phrase
altogether and let the following output indicate whether it was in
kernel mode.
=20
Well printing the correct message is only part of it: do "we" want to =20
pass guarded load errors (RapidIO bus errors) to user space or not?
Yes.
And if we pass them, should we print a kernel message at all?