Hi Nilay, Changing from Bus() to MemBus() gave another panic related to connections with piobus.
However, I got it working by making flag piobus.use_default_range = False and hence, it proceeded without generating panic. It still isn't a proper solution though but it works! Thanks for your help anyways. -Ripu Date: Fri, 18 May 2012 07:45:15 -0500 (CDT) > From: Nilay Vaish <[email protected]> > To: gem5 users mailing list <[email protected]> > Subject: Re: [gem5-users] Panic due to bad address on speculation in > O3CPU > Message-ID: <[email protected]> > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > 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
