I was also thinking that maybe it could be related to the MIPS32 instruction cache flushing routine, so I tried applying the patch Ralf posted. The system still functioned OK for me, but one other in my group had their board lock up hard ( no oops produced ), and when I asked Ralf if that patch was ready for applying to CVS, he said it needed to be reworked before doing that. As a result we didn't follow up too closely on that avenue of investigation.
So basically what I am concluding from the responses so far , is that do_ri should NEVER occur in blast_icache32() and for it to do so, it could be either a hardware problem, or possibly the MIPS32 icache flushing problem.
Anyone agree / disagree ?
Jun Sun <jsun@xxxxxxxxxx> wrote:
One possibility _could_ be the "instruction flushing itself" problem on
MIPS32. However, as far as I know au1x00 CPUs don't suffer from this problem.
Anybody knows for sure?
You could try to use the two phase cache flushing (such as the one used
by tx47xx and also see an earlier related discussion thread) and see if
the problem goes away.
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
