RE: [RFC] Better MCA recovery on IPF

From: Alberto Munoz <>
Date: 2003-11-06 04:14:08
Hi Tony,

Thank you for the clarification.

> > I still believe that a failed speculative read (for example 
> > of poisoned data) will generate an MCA. Perhaps someone from
> > Intel can confirm or deny?
> It depends on exactly what you mean by "speculative read", and
> even there it is not architecturally defined, so different
> implementations may behave differently ("Ask not the elves for
> advice for they will say both yes and no" - Tolkien).
> "Speculative" reads from memory as a result of lfetch, or a code
> fetch for a mispredicted branch that reference poisoned data may
> not generate an MCA (since the processor can know that the poisoned
> data will not be consumed.  Speculative reads from "ld.s" have
> less scope to avoid the MCA

I actually meant a read generated as a result of a ld.s. 

By the way, what do you mean by "less scope to avoid the MCA"? this statement
seems to imply that some existing implementations do it (avoid generating and
MCA when a ld.s accesses poisoned data) under some circumstances. Can you

What implementation of the Itanium processor supports avoiding MCAs from
lfetch or code fetch operations? I don't think Itanium 1 or 2 do this. How
about Madison?

> There's a new bit coming for PAL_PROC_{GET,SET}_FEATURES which
> will at least tell you (and may allow you to request, if the
> implementation supports it) whether the processor will respond
> to poison with CMCI, or upgrade to MCA ... watch the web for a
> spec update to the SDV

I assume this is only for the write path (not the read). As a CMCI on the
read path cannot possibly guarantee containment (prevent unmarked corrupt
data from making it to a register and eventually to memory, disk or the
network). Unless the (architectural) position is that an OS sets this bit at
its own risk...

Thanks again,

Bert Munoz
> -Tony

To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to
More majordomo info at
Received on Wed Nov 5 12:19:22 2003

This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:20 EST