On Mon, 5 Jan 2009, Michael Ellerman wrote:
On Sun, 2008-12-28 at 03:45 +0300, malc wrote:
On Thu, 25 Dec 2008, Benjamin Herrenschmidt wrote:
On Wed, 2008-12-24 at 03:08 +0300, m...@pulsesoft.com wrote:
Ken Moffat <zarniwh...@ntlworld.com> writes:
On Tue, Dec 23, 2008 at 06:04:45AM +0300, m...@pulsesoft.com wrote:
[..snip..]
[..snip..]
Now to the Christmas cheer, i've tried v2.6.28 and couldn't help but
notice that the problem is gone, bisecting v2.6.27 (which funnily i
had to mark good) to v2.6.28 (which has to be marked bad) wasn't fun
but eventually converged at ab598b6680f1e74c267d1547ee352f3e1e530f89
commit ab598b6680f1e74c267d1547ee352f3e1e530f89
Author: Paul Mackerras <pau...@samba.org>
Date: Sun Nov 30 11:49:45 2008 +0000
powerpc: Fix system calls on Cell entered with XER.SO=1
Now the lock-up is gone, however the code never exercises the path
taken during the lock-up so i guess it, at least, deserves a better
look by PPC64 care takers.
I'm confused. Which code never exercises which path, and so what
deserves a better look?
Before this change (atleast) mono_handle_native_sigsegv was executed
(before machine locks-up hard) after the change this code path is
never touched.
The fact that machine locks up hard and not even magic sysrq works
is what deserves a better look.
[..snip..]
--
mailto:av1...@comtv.ru
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
