Re: [discuss] A question about GART aperture unmap

2007-05-10 Thread Andi Kleen
> Sorry, I missed the last sentence. This bug is reproduced by copying a > large file(8G) and in the meanwhile compiling a linux kernel for about > 1 to 2 days. Ok that is then more expected. Don't know what causes the sync flood, but data corruption is at least expected without the clear_kernel_m

Re: [discuss] A question about GART aperture unmap

2007-05-10 Thread Zhao Forrest
On 5/10/07, Andi Kleen <[EMAIL PROTECTED]> wrote: > After commenting out clear_kernel_mapping() line, the system would > have sync flood and reset from time to time. However when with this > clear_kernel_mapping() line, no system reset happened. Hmm, that should not happen. Normally the problems

Re: [discuss] A question about GART aperture unmap

2007-05-10 Thread Zhao Forrest
On 5/10/07, Andi Kleen <[EMAIL PROTECTED]> wrote: > After commenting out clear_kernel_mapping() line, the system would > have sync flood and reset from time to time. However when with this > clear_kernel_mapping() line, no system reset happened. Hmm, that should not happen. Normally the problems

Re: [discuss] A question about GART aperture unmap

2007-05-10 Thread Zhao Forrest
> > As we know that CPU prefetch never cross the page boundary, in this That only applies to sequential prefetch. But speculative execution can prefetch pretty much any address. That is why the clear_kernel_mapping is needed. In BIOS setup, there's "Speculative TLB Reload". Is this "Speculativ

Re: [discuss] A question about GART aperture unmap

2007-05-10 Thread Andi Kleen
> After commenting out clear_kernel_mapping() line, the system would > have sync flood and reset from time to time. However when with this > clear_kernel_mapping() line, no system reset happened. Hmm, that should not happen. Normally the problems fixed by this are expected to be very rare and you