On Thu, 6 Nov 2014, Andreas Hansson wrote:
On Oct. 31, 2014, 10:21 p.m., Nilay Vaish wrote:
Andreas, please review this patch. I would like the ruby-related patches
be committed soon as possible.
I'm surprised this is needed. The busBusyUntil should be initialised to a
sufficiently high value that this would never occur.
Could you elaborate on when the problem arises (under what conditions)?
I encountered problems when simulating with ruby and dram ctrl and
starting from a checkpoint. Ruby issues memory requests in its startup()
function when loading a checkpoint. It seems that the startup() was not
called on the dram ctrl when ruby started issuing requests. This means
that busBusyUntil was at 0 to begin with. Since busBusyUntil is unsigned,
subtracting a higher value from it results in a very large tick value.
This results in a dead lock. I added the checks as shown in the patch to
avoid subtracting a larger number from a smaller number. This resolved
the problem.
As of now I am unsure if this is right way to solve the problem. Is it
possible to move the initialization of busBusyUntil to init() and
unserialize()? What's the earliest stage in a sim object initialization
phase that can call curTick()?
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
