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
