As we already saw with one of the Ruby regressions, the changes in the port proxies did expose similar issues already (see changeset f2ac0bca75df). In short, I am fairly confident that the port proxies are not the source of the problem.
I think it boils down to the access permissions in Ruby, but wouldn't know how/what to change. Nilay? Andreas -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Gabe Black Sent: 19 March 2012 06:42 To: [email protected] Subject: Re: [gem5-dev] Debugging New Translating Ports / PortProxy Somewhat tangential to the problem you're having, the SE/FS merge and the change to how ports work were pretty much entirely unrelated, they just happened to go in around the same time. What you describe sounds like it could be from the ports change, but, at least from what you've described, I don't think the SE/FS merge is a factor. Gabe On 03/18/12 14:54, Nilay Vaish wrote: > 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 _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
