From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Kumar Gala <kumar.gala@freescale.com>
Cc: linuxppc-dev list <linuxppc-dev@ozlabs.org>,
David Woodhouse <dwmw2@infradead.org>
Subject: Re: When are machine checks suppose to be recoverable?
Date: Mon, 22 Aug 2005 23:56:45 -0300 [thread overview]
Message-ID: <20050823025645.GG9667@dmt.cnet> (raw)
In-Reply-To: <8DC63AB4-C547-4023-BE7F-46176BC71535@freescale.com>
On Wed, Aug 17, 2005 at 10:42:12PM -0500, Kumar Gala wrote:
>
> On Aug 17, 2005, at 5:30 PM, David Woodhouse wrote:
>
> >On Thu, 2005-08-18 at 07:44 +1000, Benjamin Herrenschmidt wrote:
> >
> >>On Wed, 2005-08-17 at 09:00 -0500, Kumar Gala wrote:
> >>
> >>>David's 8250 cleanup patch made me wondering when are machine checks
> >>>
> >
> >
> >>>suppose to recoverable? General class of conditions is what I'm
> >>>looking for here.
> >>>
> >>>Is David's case due to some PCI master abort or something else?
> >>>
> >>
> >>Might be some issue on SMP machines...
> >>
> >
> >Yeah, that'll probably be the reason it turns out _not_ to be
> >recoverable despite our expectations. But that wasn't Kumar's
> >question.
>
> David's right, that wasn't my question :) I was asking more about
> what cases do we actually recover and that is considered correct
> behavior.
Quoting David:
"My dual G4 PowerMac crashes sometimes when it probes for the (absent)
serial ports. Theoretically it's supposed to take a machine check and
recover -- but it doesn't always work like that."
Maybe you just need the proper entry in the exception table for IO
inb/outb?
Is there a stacktrace, David?
arch/ppc/kernel/traps.c:
/*
* I/O accesses can cause machine checks on powermacs.
* Check if the NIP corresponds to the address of a sync
* instruction for which there is an entry in the exception
* table.
* Note that the 601 only takes a machine check on TEA
* (transfer error ack) signal assertion, and does not
* set any of the top 16 bits of SRR1.
* -- paulus.
*/
static inline int check_io_access(struct pt_regs *regs)
{
#ifdef CONFIG_PPC_PMAC
unsigned long msr = regs->msr;
const struct exception_table_entry *entry;
unsigned int *nip = (unsigned int *)regs->nip;
if (((msr & 0xffff0000) == 0 || (msr & (0x80000 | 0x40000)))
&& (entry = search_exception_tables(regs->nip)) != NULL) {
next prev parent reply other threads:[~2005-08-23 3:02 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-16 16:21 [PATCH] Use platform device for 8250 registration David Woodhouse
2005-08-17 6:30 ` Kumar Gala
2005-08-17 6:34 ` Benjamin Herrenschmidt
2005-08-17 7:31 ` David Woodhouse
2005-08-17 13:54 ` Kumar Gala
2005-08-17 15:05 ` Tom Rini
2005-08-17 15:22 ` Kumar Gala
2005-08-17 15:30 ` Tom Rini
2005-08-17 16:16 ` Kumar Gala
2005-08-17 16:27 ` Matt Porter
2005-08-17 16:35 ` Tom Rini
2005-08-17 16:27 ` Tom Rini
2005-08-17 11:11 ` Russell King
2005-08-17 16:39 ` David Woodhouse
2005-08-17 16:46 ` Russell King
2005-08-17 14:00 ` When are machine checks suppose to be recoverable? Kumar Gala
2005-08-17 21:44 ` Benjamin Herrenschmidt
2005-08-17 22:30 ` David Woodhouse
2005-08-18 3:42 ` Kumar Gala
2005-08-23 2:56 ` Marcelo Tosatti [this message]
2005-08-23 16:43 ` David Woodhouse
2005-08-23 17:04 ` Kumar Gala
2005-08-23 23:10 ` David Woodhouse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050823025645.GG9667@dmt.cnet \
--to=marcelo.tosatti@cyclades.com \
--cc=dwmw2@infradead.org \
--cc=kumar.gala@freescale.com \
--cc=linuxppc-dev@ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.