On Fri, 16 Mar 2012, Joel Hestness wrote:
Hey guys,
I just updated my repo to the gem5 head, and I'm trying to merge my old
patches. It looks like the TranslatingPort that used to be the O3CPU
funcport has changed, and I run into a fatal when trying to run the new
code.
I'm trying to run simulation with x86 O3CPU, full_system=False (SE mode),
and using a Ruby cache hierarchy. With the old code, the O3CPU would
simply use the funcport (before the FS/SE merge) to read from the physmem
directly (::aside:: this already confuses me, since if the data is modified
in a cache, shouldn't that data be read?). With the updated gem5 code, the
functional access uses the O3CPU's data port, which is connected to a Ruby
sequencer (more as I would expect), which checks to see if the data is in a
cache before grabbing the data for the read.
I think the first thing that you need look at is as to why the O3 CPU is
trying to make functional accesses. I rolled back the repo to look if
there is any entity by the name funcport, but grep did not provide
any results. Which code are you referring to?
The problem that I'm running into is in RubyPort.cc: When the functional
read gets to the cache hierarchy, Ruby finds that the AccessPermission on
the data it's looking for is in the Busy state (in
RubyPort::M5Port::doFunctionalRead(PacketPtr pkt) the num_busy value is 2
since the data is currently in the process of being transferred up the
cache hierarchy in a timing request). Because it's in the busy state,
doFunctionalRead returns false, which
causes RubyPort::M5Port::recvFunctional to fall into the if-statement
checking if the access failed (line 445).
In this case, couldn't the functional read just grab the data from
memory? If so, shouldn't there be better signalling between the
doFunctional<type> functions and recvFunctional in RubyPort::M5Port to
indicate the access permissions on the data? Suggestions on how this might
be fixed?
It is possible that the data in the memory is not up to date, as you
mentioned before. In fact, busy = 2 means that there are two controllers
in transient states, so the data might be in the network. You might want
to look at the access permissions of the transient states and decide if it
would be safe to read data from one of the controllers. If it is, then you
can change the access permissions accordingly.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
