Decoding machine checks is CPU specific and so machine_check_generic doesn't
do the right thing on 64bit chips. Luckily we never call into this code
because we call ppc_md.machine_check_exception instead if available.
Since we check cur_cpu_spec->machine_check before calling it, we may as
well re
The spec suggests we should first check the extended log flag before checking
the length field.
Signed-off-by: Anton Blanchard
---
Index: powerpc.git/arch/powerpc/kernel/rtasd.c
===
--- powerpc.git.orig/arch/powerpc/kernel/rtasd.c
The FWNMI code uses a global buffer without any locks to read the RTAS error
information. If two CPUs take a machine check at once then we will corrupt
this buffer.
Since most FWNMI rtas messages are not of the extended type, we can create a
64bit percpu buffer and use it where possible. If we do
Rework pseries machine check handler:
- If MSR_RI isn't set, we cannot recover even if the machine check was fully
recovered
- Rename nonfatal to recovered
- Handle RTAS_DISP_LIMITED_RECOVERY
- Use BUS_MCEERR_AR instead of BUS_ADRERR
- Don't check all the RTAS error log fields when receivin
If a machine check comes from userspace we send a SIGBUS to the task and
fail to printk anything.
If we are taking machine checks due to bad hardware we want to know about
it right away. Furthermore if we don't complain loudly then it will look
a lot like a bug in the userspace application, poten
We are calling debugger_fault_handler twice in machine_check_exception.
Signed-off-by: Anton Blanchard
---
Index: powerpc.git/arch/powerpc/kernel/traps.c
===
--- powerpc.git.orig/arch/powerpc/kernel/traps.c2011-01-11
13:46
Newer versions of the System p firwmare send a partial RTAS error log in the
machine check handler with a more detailed response appearing sometime later
via check event.
This means at machine check time we do not have enough information to
ascertain exactly what went on. Furthermore, I have foun
We should never force MSR_RI on. If we take a machine check with MSR_RI off
then we have no chance of recovering safely.
Signed-off-by: Anton Blanchard
---
Index: powerpc.git/arch/powerpc/kernel/traps.c
===
--- powerpc.git.orig/arc
We were printing 64 bits of DSISR in show_regs even though it is 32 bit.
Signed-off-by: Anton Blanchard
---
Index: powerpc.git/arch/powerpc/kernel/process.c
===
--- powerpc.git.orig/arch/powerpc/kernel/process.c 2010-10-15
13
Here are a number of fixes to our machine check handling, found when
testing our memory uncorrectable error handling.
Anton
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Hi Linus !
Here's the powerpc bunch for this merge window. Small this time, looks
like Kumar was too busy with holidays to send me anything from freescale
this time around.
There's some rework & cleanup of our nvram code, some support for the
POWER7+ processors, various iommu cleanups, etc... in
Willy Tarreau wrote on 2011/01/11 21:08:53:
>
> On Tue, Jan 11, 2011 at 09:12:44AM +0100, Joakim Tjernlund wrote:
> > Willy Tarreau wrote on 2011/01/11 07:09:26:
> > >
> > > Hi Joakim,
> > >
> > > On Mon, Jan 10, 2011 at 10:37:46PM +0100, Joakim Tjernlund wrote:
> > > > This is a backport from 2.
On Tue, Jan 11, 2011 at 09:12:44AM +0100, Joakim Tjernlund wrote:
> Willy Tarreau wrote on 2011/01/11 07:09:26:
> >
> > Hi Joakim,
> >
> > On Mon, Jan 10, 2011 at 10:37:46PM +0100, Joakim Tjernlund wrote:
> > > This is a backport from 2.6 which I did to overcome 8xx CPU
> > > bugs. 8xx does not up
Original-Nachricht
> Datum: Sun, 09 Jan 2011 00:24:01 +
> Von: Ben Hutchings
> An: Benjamin Herrenschmidt , Paul Mackerras
>
> CC: Gerhard Pircher , linuxppc-dev@lists.ozlabs.org
> Betreff: [PATCH 1/2] powerpc/boot/dts: Install dts from the right directory
> The dts-insta
> Sent by: linuxppc-dev-bounces+joakim.tjernlund=transmode...@lists.ozlabs.org
>
> Rafael Beims wrote on 2011/01/10 17:35:38:
> > >
> > > Once you have tested it and it works, please send a patch to remove the
> > > 8xx workaround.
> > > Make sure Scott is cc:ed
> > >
> > >
> >
> > I tested linux
Thanks very much.
I'm sorry for that and will get it later.
On δΈ€, 2011-01-10 at 10:22 -0600, Kumar Gala wrote:
> On Jan 10, 2011, at 4:06 AM, Xulei wrote:
>
> > For FSL PPC SoCs USB_ARCH_HAS_EHCI currently on depends on PPC_83xx.
> > However that excludes support for USB on 85xx & QorIQ devices.
Joakim Tjernlund/Transmode wrote on 2011/01/11 09:12:44:
>
> Willy Tarreau wrote on 2011/01/11 07:09:26:
> >
> > Hi Joakim,
> >
> > On Mon, Jan 10, 2011 at 10:37:46PM +0100, Joakim Tjernlund wrote:
> > > This is a backport from 2.6 which I did to overcome 8xx CPU
> > > bugs. 8xx does not update th
Willy Tarreau wrote on 2011/01/11 07:09:26:
>
> Hi Joakim,
>
> On Mon, Jan 10, 2011 at 10:37:46PM +0100, Joakim Tjernlund wrote:
> > This is a backport from 2.6 which I did to overcome 8xx CPU
> > bugs. 8xx does not update the DAR register when taking a TLB
> > error caused by dcbX and icbi insns
18 matches
Mail list logo