If you look at the definition of MemBus in configs/common/FSConfig.py, you
would find a bad address device being instantiated. It seems that this
device would respond in case no port exists for the address being
accessed.
--
Nilay
On Thu, 17 May 2012, Ripudaman Singh wrote:
Hi Steve/Nilay,
Thanks for your response.
I see following messages from RubyPort:
On a Valid Address:
9001116318499: system.l1_cntrl0.sequencer-port1: Timing access caught for
address 0x7f012d80
9001116318499: system.l1_cntrl0.sequencer-port1: Request found in 0 -
0x7fffffff range
9001116318499: system.l1_cntrl0.sequencer-port1: Request 0x7f012d80 issued
On the Bad Address:
9001116318812: system.l1_cntrl0.sequencer-port1: Timing access caught for
address 0x47f23002c
9001116318812: system.l1_cntrl0.sequencer-port1: Request for address
0x0x47f23002c is assumed to be a pio request
Hence Ruby assumes its a pio request since it doesn't lie in actual
Physical Memory Range.
The complete flow is:
RubyPort::M5Port::recvTiming -> RubyPort::PioPort::sendTiming
-> SimpleTimingPort::sendDeferredPacket -> Port::sendTiming
-> Bus::recvTiming -> Bus::findPort
This would be for any request actually. Just second function sendTiming
would be RubyPort::M5Port::sendTiming instead of PioPort.
And from front-end LSQ the access is sent to dcache port without any check
made on physical address.
Also, I couldn't find the usage of BadAddressError in classic memory
system. It is defined as one of responses for memory cmds but couldn't find
where it is being used.
Any further suggestions on a clean fix?
Thanks,
Ripudaman Singh
Date: Wed, 16 May 2012 21:47:07 -0700
From: Steve Reinhardt <[email protected]>
To: gem5 users mailing list <[email protected]>
Subject: Re: [gem5-users] Panic due to bad address on speculation in
O3CPU
Message-ID:
<CAHgMoh8KyYr=ud-orzzyq4befpatoqvt4fr6tqbqww0mtdo...@mail.gmail.com
Content-Type: text/plain; charset="iso-8859-1"
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
