[Top] [All Lists]

Re: Promblem with PREF (prefetching) in memcpy

To: "Kevin D. Kissell" <>
Subject: Re: Promblem with PREF (prefetching) in memcpy
From: Ralf Baechle <>
Date: Sat, 5 Oct 2002 01:43:45 +0200
Cc: Dominic Sweetman <>, Carsten Langgaard <>,
In-reply-to: <00dd01c26ba2$b18f55b0$10eca8c0@grendel>; from on Fri, Oct 04, 2002 at 02:36:39PM +0200
Original-recipient: rfc822;
References: <> <> <00dd01c26ba2$b18f55b0$10eca8c0@grendel>
User-agent: Mutt/
On Fri, Oct 04, 2002 at 02:36:39PM +0200, Kevin D. Kissell wrote:

> In case Carsten's reply wasn't clear enough, there is a loophole
> in the spec:  kseg0.  There is no TLB access to cause a TLB
> exception (which would suppress the operation and be nullifed),
> If the prefetch address is correctly aligned, so that there is no
> address exception.  In typical use, kseg0 is cacheable, which
> means that the second paragraph you quote does not apply.
> A prefetch to a well-formed, cacheable kseg0 address which 
> has no primary storage behind it (e.g. 0x04000000 on a system
> with 64M of physical memory) should, according to the spec,
> cause a cache fill to be initiated for the line at that address,
> which will result in a bus error, if not a flat-out system hang.

Traditionally the kernel leaves the last page of memory unused but this
has been lost in the many changes to the memory initialization code.
It's still a good idea with all the broken I/O chips and PCI bridges out
there - and can avoid a hard to track bug.

That only leaves stuff usermode device drivers that are using cachable
mappings in the dangerzone.  That should be a rare case, if at all.


<Prev in Thread] Current Thread [Next in Thread>