> 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 elaborate? I was just being vague. In the case of "ld.s" the data is targetted at a register ... and we don't have a way to indicate that the contents of a register are poisoned (NaT would at least stop someone consuming the poisoned data, but they wouldn't know why) ... so an MCA is inevitable. In the "lfetch" case we only requested that the data be pulled into cache, which can keep track of whether it is poisoned or not ... so it is architecturally possible to avoid the MCA. I don't have the details to hand on how existing implementations actually handle this. -Tony - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Thu Nov 6 14:11:37 2003
This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:20 EST