[Top] [All Lists]

Re: Promblem with PREF (prefetching) in memcpy

To: "Kevin D. Kissell" <>
Subject: Re: Promblem with PREF (prefetching) in memcpy
From: Dominic Sweetman <>
Date: Fri, 4 Oct 2002 15:24:18 +0100 (BST)
Cc: "Dominic Sweetman" <>, "Carsten Langgaard" <>, "Ralf Baechle" <>, <>
In-reply-to: <00dd01c26ba2$b18f55b0$10eca8c0@grendel>
Original-recipient: rfc822;
References: <> <> <00dd01c26ba2$b18f55b0$10eca8c0@grendel>
> 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,

True (at the CPU boundary).

The system, having decoded the prefetch address and discovered it
accesses the 'launch at once on read' I/O register is not obliged to
resolve its dilemma by reading it.

It's not even obliged to generate a bus error: it's often less harmful
to just ignore it and pacify the CPU with some rubbish data...

... but let's suppose it doesn't:

> which will result in a bus error...

I assume that this is not theoretical, and that at least one MTI core
fails to ignore bus-error on prefetch?  (I take it that you're *not*
arguing that this would be wrong).  Oops.

If you enable bus errors, you must expect to have a bus error
exception handler - and one of its jobs is to quietly ignore the bogus

There are lots of other system hardware or software workarounds.

> ... if not a flat-out system hang.

It's not good to design such suicide regions into the memory
map... surely there's no MTI hardware which does *that*?


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