[PATCH,RFC] PPC32 Machine Check Handling

STALE8020d

4 messages, 3 authors, 2004-11-04 · open the first message on its own page

[PATCH,RFC] PPC32 Machine Check Handling

From: Adrian Cox <hidden>
Date: 2004-08-27 10:26:29

The attached patch rearranges PPC32 machine check handling in order to
test for internal CPU failures before signalling user processes. This
makes the behaviour match that of i386.

The patch currently only changes behaviour for 6xx processors. It does
not enable any extra causes of machine check, but it will turn internal
CPU faults into kernel panics rather than signals.

The PowerMac and Qspan specific code is moved into platform files. There
don't seem to be any boards in the tree that actually use Qspan PCI. I'd
like to hear test reports for PowerMac machines that take machine checks
on I/O faults.

Paul, Tom: This isn't the finished version, but is there any chance of
something like this going mainstream?  The current behaviour makes it
very hard to separate chip failures and cooling problems from
application bugs.

- Adrian Cox
Humboldt Solutions Ltd.

Re: [PATCH,RFC] PPC32 Machine Check Handling

From: Tom Rini <hidden>
Date: 2004-08-27 22:12:04

On Fri, Aug 27, 2004 at 11:26:29AM +0100, Adrian Cox wrote:
The attached patch rearranges PPC32 machine check handling in order to
test for internal CPU failures before signalling user processes. This
makes the behaviour match that of i386.

The patch currently only changes behaviour for 6xx processors. It does
not enable any extra causes of machine check, but it will turn internal
CPU faults into kernel panics rather than signals.

The PowerMac and Qspan specific code is moved into platform files. There
don't seem to be any boards in the tree that actually use Qspan PCI. I'd
like to hear test reports for PowerMac machines that take machine checks
on I/O faults.

Paul, Tom: This isn't the finished version, but is there any chance of
something like this going mainstream?  The current behaviour makes it
very hard to separate chip failures and cooling problems from
application bugs.
This seems like a fine idea to me.

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH,RFC] PPC32 Machine Check Handling

From: Dan Malek <hidden>
Date: 2004-08-28 00:38:54

On Aug 27, 2004, at 6:12 PM, Tom Rini wrote:
quoted
The PowerMac and Qspan specific code is moved into platform files.
There
don't seem to be any boards in the tree that actually use Qspan PCI.
The MBX-860, RPC Classic (with PCI enabled) are two well known
boards that use the Qspan.  I don't know many people that use those
boards, I'm just listing them for documentation purposes :-)  There
are also some custom boards that use it, but I suspect it won't
affect them.

Thanks.


	-- Dan


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH,RFC] PPC32 Machine Check Handling

From: Tom Rini <hidden>
Date: 2004-11-04 19:08:08

On Fri, Aug 27, 2004 at 03:12:04PM -0700, Tom Rini wrote:
On Fri, Aug 27, 2004 at 11:26:29AM +0100, Adrian Cox wrote:
quoted
The attached patch rearranges PPC32 machine check handling in order to
test for internal CPU failures before signalling user processes. This
makes the behaviour match that of i386.

The patch currently only changes behaviour for 6xx processors. It does
not enable any extra causes of machine check, but it will turn internal
CPU faults into kernel panics rather than signals.

The PowerMac and Qspan specific code is moved into platform files. There
don't seem to be any boards in the tree that actually use Qspan PCI. I'd
like to hear test reports for PowerMac machines that take machine checks
on I/O faults.

Paul, Tom: This isn't the finished version, but is there any chance of
something like this going mainstream?  The current behaviour makes it
very hard to separate chip failures and cooling problems from
application bugs.
This seems like a fine idea to me.
This get cleaned up anymore, etc?  Thanks.

-- 
Tom Rini
http://gate.crashing.org/~trini/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help