Re: When are machine checks suppose to be recoverable?

On Wed, Aug 17, 2005 at 10:42:12PM -0500, Kumar Gala wrote:

On Aug 17, 2005, at 5:30 PM, David Woodhouse wrote:

quoted

On Thu, 2005-08-18 at 07:44 +1000, Benjamin Herrenschmidt wrote:

quoted

On Wed, 2005-08-17 at 09:00 -0500, Kumar Gala wrote:

quoted

David's 8250 cleanup patch made me wondering when are machine checks

quoted

quoted

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) {