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
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
