Try it out! I think you would just need to replace the call to Bus() with
a call to MemBus().
--
Nilay
On Fri, 18 May 2012, Ripudaman Singh wrote:
Hi Nilay,
Yes, I see the instantiation of bad address in MemBus but this is not being
used for Ruby.
It is done only for classic memory system as Steve mentioned.
Can we do a similar thing for Ruby?
Thanks,
Ripudaman Singh
Date: Thu, 17 May 2012 22:44:56 -0500 (CDT)
From: Nilay Vaish <[email protected]>
To: gem5 users mailing list <[email protected]>
Subject: Re: [gem5-users] gem5-users Digest, Vol 70, Issue 73
Message-ID: <[email protected]>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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=
[email protected]
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
End of gem5-users Digest, Vol 70, Issue 79
******************************************
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
