That's a good question... yes, there should be a BadAddr responder associated with the main memory bus that handles this case. The bus should not hand the request to PhysicalMemory object if it's out of the object's range.
Rick, can you post the specific error message you were getting in the original case, and the config.out as well? Thanks, Steve On Mon, Jun 1, 2009 at 4:31 PM, nathan binkert <[email protected]> wrote: > Shouldn't there be a default responder that takes care of this? Has > that changed? > > Nate > > On Mon, Jun 1, 2009 at 12:24 AM, Rick Strong <[email protected]> wrote: > > This was exactly the problem. Thanks for the feedback. The fix that I > > made is as follows for those interested in the future: > > > > diff --git a/src/mem/physical.cc b/src/mem/physical.cc > > --- a/src/mem/physical.cc > > +++ b/src/mem/physical.cc > > @@ -255,8 +255,14 @@ > > Tick > > PhysicalMemory::doAtomicAccess(PacketPtr pkt) > > { > > - assert(pkt->getAddr() >= start() && > > - pkt->getAddr() + pkt->getSize() <= start() + size()); > > + // OOO: Bad address from OOO core > > + if(pkt->getAddr() < start() || > > + pkt->getAddr() + pkt->getSize() > start() + size()){ > > + assert(pkt->needsResponse()); > > + pkt->makeResponse(); > > + pkt->setBadAddress(); > > + return calculateLatency(pkt); > > + } > > > > memAccesses++; > > > > > > Steve Reinhardt wrote: > >> Yea, with speculative execution it's not impossible for the CPU to > >> fetch from a bogus physical address in kernel mode due to a > >> misspeculated path. Physical memory should respond to this with a Bad > >> Address response, which then gets ignored when the misspeculated path > >> is squashed. > >> > >> Steve > >> > >> On Fri, May 29, 2009 at 4:51 PM, Rick Strong <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> Hi all, > >> > >> For the O3 cpu running several of the parsec benchmarks, let's > >> focus on > >> x264 with 16 cores. I see that it's fetch unit requests 0xffffffc0 > >> which > >> fails in the physmem because it is not within the valid address > range > >> for the functional memory. The address is the result of "iew: > >> Execute: > >> Branch mispredict" being detected and execute redirects fetch to > PC: > >> 0xffffffc0. This strange behavior does not occur when I use > >> SimpleTimingCPU. Is there any potential for the iew stage to > redirect > >> fetch to a bogus address, that is inst->readNextPC() in iew_impl.hh > >> returns a bogus address that would propagate to the memory system > >> and be > >> caught later? > >> > >> Thanks in advance, > >> -Rick > >> > >> > >> > >> _______________________________________________ > >> m5-users mailing list > >> [email protected] <mailto:[email protected]> > >> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > >> > >> > > > > _______________________________________________ > > m5-users mailing list > > [email protected] > > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > > > >
_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
