Question regarding the clear_page function

Morning all!
	I've got a question regarding the clear_page function in
arch/ppc/kernel/misc.S.  We have been seeing a series of intermittent oopses in
which the call stack terminates inside clear_page with a data access exception
(trap 0x300), on the 0x100th iteration of the clear_page loop.  Inspection of
the function reveals that for the 8XX processor (we're using an 860P),
clear_page does 4 32 bit stores to memory and advances a counter in increments
of a cache line size.  However, for a non 8XX processor, the dcbz instruction is
used to clear the cache line.  My question is, why is this not the case for the
8XX series as well?  I've looked through the users guide and the instruction is
present on the 8XX family of processors, and the dcbz instruction behavior seems
appropriate to the referenced function regardless of the state of the cache
(enabled or disabled).  I'm asking because I'm testing a modifed kernel in which
we use the dcbz instruction rather than 4 stores, and we curious as to what
consequences I might expect.  Any thoughts or opinions appreciated.  Thanks a
bunch!
Neil :)

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Neil Horman wrote:

.....  My question is, why is this not the case for the
8XX series as well?

The behavior of this instruction during faults and exceptions has often
been incorrect and the different silicon revisions behave differently.
Rather than track all of the different silicon variants, install and
test all of the patches, it is easier to just not use it.

....  I'm asking because I'm testing a modifed kernel in which
we use the dcbz instruction rather than 4 stores, and we curious as to what
consequences I might expect.

You are probably experiencing them :-).


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

got it.  Thanks Dan!
Neil

Dan Malek wrote:

Neil Horman wrote:

quoted

.....  My question is, why is this not the case for the
8XX series as well?

The behavior of this instruction during faults and exceptions has often
been incorrect and the different silicon revisions behave differently.
Rather than track all of the different silicon variants, install and
test all of the patches, it is easier to just not use it.

quoted

....  I'm asking because I'm testing a modifed kernel in which
we use the dcbz instruction rather than 4 stores, and we curious as to what
consequences I might expect.

You are probably experiencing them :-).

        -- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/