Re: [PATCH 07/10] IOCHK interface for I/O error handling/detecting

From: Hidetoshi Seto <seto.hidetoshi_at_jp.fujitsu.com>
Date: 2005-06-10 20:29:58
Hi David,

David Mosberger wrote:
>>>>>>On Thu, 09 Jun 2005 21:58:26 +0900, Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> said:
> 
>   Hidetoshi> +/*
>   Hidetoshi> + * Some I/O bridges may poison the data read, instead of
>   Hidetoshi> + * signaling a BERR.  The consummation of poisoned data
>   Hidetoshi> + * triggers a local, imprecise MCA.
>   Hidetoshi> + * Note that the read operation by itself does not consume
>   Hidetoshi> + * the bad data, you have to do something with it, e.g.:
>   Hidetoshi> + *
>   Hidetoshi> + *	ld.8	r9=[r10];;	// r10 == I/O address
>   Hidetoshi> + *	add.8	r8=r9,r9;;	// fake operation
>   Hidetoshi> + */
>   Hidetoshi> +#define ia64_poison_check(val)					\
>   Hidetoshi> +{	register unsigned long gr8 asm("r8");			\
>   Hidetoshi> +	asm volatile ("add %0=%1,r0" : "=r"(gr8) : "r"(val)); }
>   Hidetoshi> +
>   Hidetoshi> #endif /* CONFIG_IOMAP_CHECK  */
> 
> I have only looked that this briefly and I didn't see off hand where you get
> the "r9=[r10]" sequence from --- I hope you're not relying on the compiler
> happening to generate this sequence!

+static inline unsigned char
+___ia64_readb (const volatile void __iomem *addr)
+{
+    unsigned char val;
+
+    val = *(volatile unsigned char __force *)addr;
+    ia64_poison_check(val);
+
+    return val;
+}

Assigning value from addr to variable val stands for "ld", is it right?
What I want to do here is making sure that ld actually finishs loading data
from memory or mmaped register or far place to general register, and make
sure that the data is healthy enough to operate, not poisoned.

> More importantly: please avoid inline "asm" and use the intrinsics
> defined by gcc_intrin.h instead (if you need something new, we can add
> that), but I think ia64_getreg() will do much of what you want already.

Umm, I think I need something like ia64_setreg(ANYWHERE_DUMMY_REG, val).
How do you think?

Or don't you mind if I move the definition of ia64_poison_check above to
gcc_intrin.h?

Thanks,
H.Seto

-
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.html
Received on Fri Jun 10 06:36:55 2005

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