Hi Nilay and Tushar, I got rid of that error by writing a check for memory message and network message in the SWallocator_d.cc. However, I am getting a deadlock error now when I run the same test. I get this error:
panic: Deadlock detected: current_time: 50001 last_progress_time: 0 difference: 50001 processor: 0 @ cycle 50001 [checkForDeadlock:build/ALPHA_SE_MOESI_hammer/cpu/testers/rubytest/RubyTester.cc, line 182] Memory Usage: 170696 KBytes Program aborted at cycle 50001 Aborted I am attaching my code file here. It will be great if you could have a look to see if I am making any obvious error here (method - priority_arbitrate_outports), I am unable to find out what could have gone wrong. Thanks for your guidance and time. On Thu, Sep 27, 2012 at 5:46 AM, Nilay Vaish <ni...@cs.wisc.edu> wrote: > On Wed, 26 Sep 2012, tejasi pimpalkhute wrote: > > Hi Nilay and Tushar, >> >> Thanks for your response. I thought so earlier but I tried running pure >> memory test (e.g. ruby_mem_test.py) as well as ruby_random_test. >> Shouldn't >> the memory test inject only memory request packets in the network? In that >> case why should the type cast fail? Please correct me if I am wrong. >> > > You are wrong in your assumption. > > > Is >> there any way of determining whether a flit corresponds to a memory >> message >> or a network message? >> >> > There is an obvious check given the behavior of dynamic_cast in C++. You > might want to figure it out on your own. > > -- > Nilay > -- Thanks and Regards, Tejasi
SWallocator_d_.cc
Description: Binary data
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
