Question regarding the clear_page function
Morning all!
I've got a question regarding the clear_page function inarch/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/
Quoted 2 lines · Neil Horman
..... 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 3 lines
.... 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
Quoted 11 lines · Dan Malek
Quoted 2 lines · Neil Horman
..... 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 8 lines
Quoted 3 lines
.... 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/