> 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
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
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
>
> 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
> 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
Hi,
The following is extracted from function gart_iommu_init()
..
/*
* Unmap the IOMMU part of the GART. The alias of the page is
* always mapped with cache enabled and there is no full cache
* coherency across the GART remapping. The unmapping avoids
* automatic prefetches from the CPU alloc
6 matches
Mail list logo
