I suspect the device bus that Ruby uses doesn't have a default bad address responder like the non-Ruby memory system does. This is the "fake device" that responds with BadAddressError when there's no device associated with an address.
Steve On Wed, May 16, 2012 at 8:33 PM, Nilay Vaish <[email protected]> wrote: > From the source of the panic message, it seems Ruby never came into > picture. Or if it did, it just assumed that this address lies in some > device' address space. In fact that seems to be the reason why no check > appears in the O3 CPU on whether or not the address lies in the physical > memory's address range. > > -- > Nilay > > > On Wed, 16 May 2012, Steve Reinhardt wrote: > > 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<http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users> >>> >>> >> ______________________________**_________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/**mailman/listinfo/gem5-users<http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users> >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
