A bad address access should really just return a BadAddressError and not panic. Then the CPU can easily ignore the error if the instruction that caused the error is not committed.
I believe this is what happens with the classic memory system. It may just be a Ruby issue that the same thing doesn't happen there. I'm surprised we haven't run into this already. Steve On Wed, May 16, 2012 at 5:32 PM, Ripudaman Singh <[email protected]>wrote: > Hi, > > I get following error while running a benchmark with O3CPU and Ruby > configuration: > panic: Unable to find destination for addr 0x47f23002c > @ cycle 5749353955244 > [findPort:build_alpha_fs_moesi_cmp_dir/build/ALPHA_FS_MOESI_CMP_directory/mem/bus.cc, > line 359] > Memory Usage: 2711992 KBytes > Program aborted at cycle 5749353955244 > > On debug, I found that it happens because of bad address generated on > speculation. > In other words, core keeps fetching from predicted branch target (or > targets since it encounters other branches on the speculated path) and > branch will mispredict eventually (confirmed on comparing with trace from > TimingSimple CPU). > But before misprediction happens, it leads to an invalid load address and > generates above error. > > I see a check for an invalid address for instruction cache access in > fetch_impl.hh (reproduced below from function finishTranslation) which > stalls fetch stage. > if (!cpu->system->isMemAddr(mem_req->getPaddr())) { > warn("Address %#x is outside of physical memory, stopping > fetch\n", > mem_req->getPaddr()); > fetchStatus[tid] = NoGoodAddr; > delete mem_req; > memReq[tid] = NULL; > return; > } > > But there is no such check for data or load access in iew or lsq. > I guess the fix would be to not execute (or squash?) the faulting load and > somehow signal to fetch stage to stall as done for instruction cache. Can > you suggest how can I do that? > > I already tried limiting in-flight branches to 1. That works but gives > lower perf. So, I'm looking for a better solution. > > Thanks, > Ripudaman Singh > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
