linux-mips
[Top] [All Lists]

Re: Promblem with PREF (prefetching) in memcpy

To: "Kevin D. Kissell" <kevink@mips.com>
Subject: Re: Promblem with PREF (prefetching) in memcpy
From: Ralf Baechle <ralf@linux-mips.org>
Date: Sat, 5 Oct 2002 01:43:45 +0200
Cc: Dominic Sweetman <dom@algor.co.uk>, Carsten Langgaard <carstenl@mips.com>, linux-mips@linux-mips.org
In-reply-to: <00dd01c26ba2$b18f55b0$10eca8c0@grendel>; from kevink@mips.com on Fri, Oct 04, 2002 at 02:36:39PM +0200
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <3D9D484B.4C149BD8@mips.com> <200210041153.MAA12052@mudchute.algor.co.uk> <00dd01c26ba2$b18f55b0$10eca8c0@grendel>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.2.5.1i
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.

  Ralf

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