Hi Nilay, Apologies for my limited insight in how Ruby restores from a checkpoint, but could we not avoid injecting any packets all together? Is there a fundamental reason why this is needed? Could we not let the various objects be responsible for their own portion of the checkpoint state?
Andreas On 06/11/2014 16:32, "Nilay Vaish" <[email protected]> wrote: >Ok, in that case, I would add one more stage to the initialization phase >so as to allow ruby to restore from a checkpoint. > >-- >Nilay > > >On Thu, 6 Nov 2014, Andreas Hansson wrote: > >> Hi Nilay, >> >> I see. >> >> The reason that it is set in startup is due to the checkpoints. >> >> I would argue that we should not allow any transactions to be issued in >> startup. Would that work? >> >> Andreas >> >> On 06/11/2014 15:55, "Nilay Vaish" <[email protected]> wrote: >> >>> 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 >>> >> >> >> -- 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. >> >> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, >>Registered in England & Wales, Company No: 2557590 >> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 >>9NJ, Registered in England & Wales, Company No: 2548782 >> >> >> > -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782 _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
