Hi, all, This issue has not been fixed yet. Can anyone suggest how to fix this?
To deal with the invalid address, I tried to define a new python class, PIOBus, inherent from Noncoherent bus and the new python class contains BadAddr member, like the way used in classic memory system. Then I use the PIOBus when creating Alpha system, but it is said that BadAddr is not connected to the system. Thanks! -----Original Message----- From: gem5-users-boun...@gem5.org [mailto:gem5-users-boun...@gem5.org] On Behalf Of Nilay Vaish Sent: Friday, May 18, 2012 8:45 PM To: gem5 users mailing list Subject: Re: [gem5-users] Panic due to bad address on speculation in O3CPU 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 <ni...@cs.wisc.edu> >> To: gem5 users mailing list <gem5-users@gem5.org> >> Subject: Re: [gem5-users] gem5-users Digest, Vol 70, Issue 73 >> Message-ID: <pine.lnx.4.64.1205172233170.31...@ribera.cs.wisc.edu> >> 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 <ste...@gmail.com> >>>> To: gem5 users mailing list <gem5-users@gem5.org> >>>> 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 <ni...@cs.wisc.edu> 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 >>>>>> <ripudaman.i...@gmail.com>**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 >>>>>>> gem5-users@gem5.org >>>>>>> http://m5sim.org/cgi-bin/**mailman/listinfo/gem5-users< >>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users> >>>>>>> >>>>>>> >>>>>> ______________________________**_________________ >>>>> gem5-users mailing list >>>>> gem5-users@gem5.org >>>>> http://m5sim.org/cgi-bin/**mailman/listinfo/gem5-users< >>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users> >>>>> >>>> >>>> >>>> >>> >> >> >> ------------------------------ >> >> _______________________________________________ >> gem5-users mailing list >> gem5-users@gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> >> End of gem5-users Digest, Vol 70, Issue 79 >> ****************************************** >> > _______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users _______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
