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
