Hi Linus, On 10/3/07, Linus Torvalds <[email protected]> wrote: > I would bet that the reason the intel-optimized memcpy triggers this is > that the non-temporal stores just means that you go out directly on the > bus, and it probably just shows a weakness in the chipset or bus that > doesn't show with the normal cacheline accesses. But that should show up with memtest too, no? Pekka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: File corruption when using kernels 2.6.18+
- From: Alan Cox <[email protected]>
- Re: File corruption when using kernels 2.6.18+
- From: Linus Torvalds <[email protected]>
- Re: File corruption when using kernels 2.6.18+
- References:
- Re: File corruption when using kernels 2.6.18+
- From: Neil Romig <[email protected]>
- Re: File corruption when using kernels 2.6.18+
- From: "Pekka Enberg" <[email protected]>
- Re: File corruption when using kernels 2.6.18+
- From: Neil Romig <[email protected]>
- Re: File corruption when using kernels 2.6.18+
- From: "Pekka Enberg" <[email protected]>
- Re: File corruption when using kernels 2.6.18+
- From: Linus Torvalds <[email protected]>
- Re: File corruption when using kernels 2.6.18+
- Prev by Date: Re: [PATCH 08/10] ia64: Convert cpu_sibling_map to a per_cpu data array (v3)
- Next by Date: A kernel Tracing interface (was Re: -mm merge plans for 2.6.24)
- Previous by thread: Re: File corruption when using kernels 2.6.18+
- Next by thread: Re: File corruption when using kernels 2.6.18+
- Index(es):