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

From: Hidetoshi Seto
Date: Fri Jun 10 2005 - 05:40:14 EST


Hi David,

David Mosberger wrote:
On Thu, 09 Jun 2005 21:58:26 +0900, Hidetoshi Seto <seto.hidetoshi@xxxxxxxxxxxxxx> 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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/