Skip to contentSkip to conversation

Maple: killing a process that causes a machine check exception

PATCH jfaslist 3 participants 6 messages May 23, 2006 PowerPC

lore
Share & tools
lore

jfaslist

author
#0 lore raw

Hi,
By applying the following mods (plse see below), i was able to have a user process that caused a machine check exception to be terminated (on a Maple platform), as expected. I was wondering why the PPC64 had a different ME handling than PPC which does send the SIGBUS to the process? Thanks
Regards,
-jean-francois simon

arch/powerpc/kernel/traps.c 2006-05-09 02:46:59.000000000 -0700 renamed from arch/powerpc/kernel/traps.c 2006-05-04 17:03:45.000000000 -0700 +0 -0
diff -urN -X linux-2.6.16.14/Documentation/dontdiff linux-2.6.16.14/arch/powerpc/kernel/traps.c linux-2.6.16.14.vmeberr_fix/arch/powerpc/kernel/traps.c
@@ -340,12 +340,19 @@
#ifdef CONFIG_PPC64
       int recover = 0;

+

       /* See if any machine dependent calls */
       if (ppc_md.machine_check_exception)
             recover = ppc_md.machine_check_exception(regs);

       if (recover)
             return;
+
+       if (user_mode(regs)) {
+             regs->msr |= MSR_RI;
+             _exception(SIGBUS, regs, BUS_ADRERR, regs->nip);
+             return;
+       }
#else
       unsigned long reason = get_mc_reason(regs);

___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com

#1 lore raw
Quoted 5 lines

By applying the following mods (plse see below), i was able to have a user process that caused a machine check exception to be terminated (on a Maple platform), as expected. I was wondering why the PPC64 had a different ME handling than PPC which does send the SIGBUS to the process?

Not all machine checks are synchronous so we cant always do this. From memory the ppc64 version will panic if the machine check wasnt synchronous.

Anton

author
#2 lore raw

Hi,
What do you mean by synchronous? Do you mean that the current process may no be not the one that caused the ME?
In my case I _need_ the process to be killed, as it is making a VME bus error. / PCI target-abort.
I am starting to get desperate. I have been working for several month with IBM to get a solution on machine check related issues on the Maple. First, the Maple was hanging hard. Now that this is fixed, I need the Linux ME to kill the offending process! My feeling now, is that I am really starting to have it w/ the ppc64!

-jfs

Quoted 4 lines · Anton Blanchard
Quoted 3 lines

By applying the following mods (plse see below), i was able to have a user process that caused a machine check exception to be terminated (on a Maple platform), as expected. I was wondering why the PPC64 had a different ME handling than PPC which does send the SIGBUS to the process?

Quoted 8 lines

Not all machine checks are synchronous so we cant always do this. From memory the ppc64 version will panic if the machine check wasnt synchronous.

Anton

___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com

#3 lore raw

Hi,

Quoted 2 lines

What do you mean by synchronous? Do you mean that the current process may no be not the one that caused the ME?

Yeah, a device doing DMA might cause a machine check independent to your current task. In that case we really need to take the machine down.

Quoted 7 lines

In my case I _need_ the process to be killed, as it is making a VME bus error. / PCI target-abort.
I am starting to get desperate. I have been working for several month with IBM to get a solution on machine check related issues on the Maple. First, the Maple was hanging hard. Now that this is fixed, I need the Linux ME to kill the offending process!
My feeling now, is that I am really starting to have it w/ the ppc64!

Sounds like you need a Maple specific machine check handler. My point is we cant merge a fix like that because it affects every powerpc arch out there, all with different machine check handling requirements.

Anton

author
#4 lore raw
Quoted 7 lines
Quoted 6 lines

In my case I _need_ the process to be killed, as it is making a VME bus error. / PCI target-abort.
I am starting to get desperate. I have been working for several month with IBM to get a solution on machine check related issues on the Maple. First, the Maple was hanging hard. Now that this is fixed, I need the Linux ME to kill the offending process! My feeling now, is that I am really starting to have it w/ the ppc64!

Quoted 6 lines

Sounds like you need a Maple specific machine check handler. My point is we cant merge a fix like that because it affects every powerpc arch out there, all with different machine check handling requirements.

understood. thanks. sorry for letting out a little steam -jean-francois simon

___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com

#5 lore raw
In reply to Anton Blanchard
Quoted 7 lines · Anton Blanchard
Quoted 2 lines · jfaslist

What do you mean by synchronous? Do you mean that the current process may no be not the one that caused the ME?

Yeah, a device doing DMA might cause a machine check independent to your current task. In that case we really need to take the machine down.

Quoted 6 lines
Quoted 2 lines

In my case I _need_ the process to be killed, as it is making a VME bus error. / PCI target-abort.

Sounds like you need a Maple specific machine check handler. My point is we cant merge a fix like that because it affects every powerpc arch out there, all with different machine check handling requirements.

Here's an utterly crazy idea that might take a lot of work to implement, but might help with the problem. *If* it can be determined which pci device caused the error, then it might be possible to reset the PCI device and restart the device driver.

There is an existing infrastructure for "PCI Error Recovery" (known as EEH on the pSeries) for detecting and clearing PCI bus errors. On the pSeries, it depends on a combination of custom hardware PCI bridges and firmware to isolate the failing device; but maybe on other systems, one might be able to do "almost" as well.

(See kernel source, Documentation/pci-error-recovery.txt)

--linas