Hi Tushar, Oh..it's my shame !!! Yes, the network-only simulation works fine after removing the options. Thank you for your point.
As for ALPHA_SE_MOESI_hammer, the problematic protocol state should not have been generated withe the protocol, according to the state diagram in document page. That is why I wonder. Anyway, I downloaded the recent *stable version of gem5* called *gem5-stable * by running *hg clone http://repo.gem5.org/gem5-stable, and *the simulator package's build_opts directory showed me that there was a ALPHA_SE_MOESI_hammer. Thus, I compiled the gem5 binary by executing "scons build/ALPHA_SE_MOESI_hammer". This is the process that I did so as to get the binary. I guess the problem is only related to gem5-stable version, because I am able to run the same command with gem5 (development version). Can you perform the regression test for the protocol with gem5-stable in your side? Thanks. Regards, Juyoung On Wed, May 9, 2012 at 10:23 PM, Tushar Krishna <tus...@csail.mit.edu>wrote: > Hi Juyoung, > Regarding the first deadlock: > The simulation actually doesn't give you anything useful since you have > --fixed-pkts --maxpackets=1 which basically means that each core will only > inject ONE packet whether you run it for 1000 or 1M cycles. > To run with more cycles, you should remove the --fixed-pkts options, or > increase the maxpackets. > The reason why you get a deadlock error is because the tester > (src/cpu/testers/networktest/networktest.cc) thinks there is a deadlock > since nothing happened for the past 500K cycles. > > > For the second deadlock, hmm thats weird. MOESI_hammer is a pretty > rigorously tested protocol. > Note that this is not a deadlock error: the error is that the cache > controller received a non-existent transition request. > > BTW how did you compile a ALPHA_SE_MOESI_hammer? I thought the current > gem5 version has no separate SE and FS versions… > Are you using the latest version? > Can you compile as scons build/ALPHA_MOESI_hammer/gem5.debug and re-try? > > cheers, > Tushar > > > On May 9, 2012, at 7:39 PM, Juyoung Jung wrote: > > Hi Tushar, > > I installed the prerequisites having the following versions, and run the > network tester. > g++: 4.4.6 (rather than 4.4.5) > python: 2.6.7 (rather than 4.4.6) > swig: 1.3.40 > m4: 1.4.14 > gzip: 1.3.12 > > The result was successful with a command > ./build/ALPHA_SE_Network_test/gem5.debug > ./configs/example/ruby_network_test.py --num-cpus=4 --num-dirs=4 > --topology=Mesh --mesh-rows=2 --sim-cycles=1000 --injectionrate=0.01 > --synthetic=0 --fixed-pkts --maxpackets=1 --garnet-network=fixed > > However, when I increased the simulation cycles up to 1M, it exited with > deadlock error like this: > > gem5 compiled May 9 2012 15:40:30 > gem5 started May 9 2012 16:00:17 > gem5 executing on cairo1 > command line: ./build/ALPHA_SE_Network_test/gem5.debug > ./configs/example/ruby_network_test.py --num-cpus=4 --num-dirs=4 > --topology=Mesh --mesh-rows=2 *--sim-cycles=1000000* --injectionrate=0.01 > --synthetic=0 --fixed-pkts --maxpackets=1 --garnet-network=fixed > warning: add_child('cls'): child 'credit_links0 credit_links1' already has > parent > warning: add_child('cls'): child 'credit_links0 credit_links1' already has > parent > warning: add_child('cls'): child 'credit_links0 credit_links1' already has > parent > warning: add_child('cls'): child 'credit_links0 credit_links1' already has > parent > warning: add_child('cls'): child 'credit_links0 credit_links1' already has > parent > warning: add_child('cls'): child 'credit_links0 credit_links1' already has > parent > warning: add_child('cls'): child 'credit_links0 credit_links1' already has > parent > warning: add_child('cls'): child 'credit_links0 credit_links1' already has > parent > warning: add_child('cls'): child 'credit_links0 credit_links1' already has > parent > warning: add_child('cls'): child 'credit_links0 credit_links1' already has > parent > warning: add_child('cls'): child 'credit_links0 credit_links1' already has > parent > warning: add_child('cls'): child 'credit_links0 credit_links1' already has > parent > Global frequency set at 1000000000 ticks per second > info: Entering event queue @ 0. Starting simulation... > system.cpu3: deadlocked at cycle 500015 > fatal: > @ cycle 500015 > [tick:build/ALPHA_SE_Network_test/cpu/testers/networktest/networktest.cc, > line 175] > > > The same deadlock situation occurred with hammer protocol at even earlier > simulation like this: > > gem5 Simulator System. http://gem5.org > gem5 is copyrighted software; use the --copyright option for details. > > gem5 compiled May 9 2012 15:54:32 > gem5 started May 9 2012 16:06:42 > gem5 executing on cairo1 > command line: ./build/ALPHA_SE_MOESI_hammer/gem5.debug > configs/example/ruby_random_test.py --num-cpus=4 --num-dirs=4 > --topology=Mesh --mesh-rows=2 *-l 1000* > Global frequency set at 1000000000 ticks per second > info: Entering event queue @ 0. Starting simulation... > fatal: Invalid transition > system.l1_cntrl0 time: 330144 addr: [0x20c0, line 0x20c0] event: > Flush_line state: MR > @ cycle 330144 > [doTransitionWorker:build/ALPHA_SE_MOESI_hammer/mem/protocol/L1Cache_Transitions.cc, > line 1132] > Memory Usage: 220192 KBytes > > From these trials, I could not successfully run the network simulation > even though I am able to invoke a garnet object without error in this time. > I am not sure if this deadlock or invalid transition problem is also caused > by slightly different development tool version. What would be the real > cause of the deadlock/invalid transition between simply bad code generation > and test controller's bug based on wrong protocol? How can I debug it? I > would like to run the network-only simulation as like being shown in gem5 > document(http://www.m5sim.org/Networktest). Let me hear your comments. > Thanks. > > > - Juyoung > > > On Tue, May 8, 2012 at 5:08 PM, Tushar Krishna <tus...@csail.mit.edu>wrote: > >> Yeah it works for me both with and without garnet. >> >> Here are the versions on my machine: >> g++: 4.4.5 >> python: 2.6.6 >> swig: 1.3.40 >> m4: 1.4.14 >> gzip: 1.3.12 >> >> Start with matching the python and g++ versions as you seem to be getting >> an error when it tries to create a garnet object in configs/ruby/Ruby.py >> >> >> - Tushar >> >> >> >> On May 8, 2012, at 5:31 PM, Juyoung Jung wrote: >> >> Hi Tushar, >> >> Thanks for your quick reply. >> I was able to run the simulation with ruby_random_test.py + >> ALPHA_MOESI_hammer protocol without any error. At a glance, I thought the >> protocol used was a problem. However, after more tests, I found that the >> simulation failed with option to invoke garnet-network as like: >> * ./build/ALPHA_Network_test/gem5.debug >> ./configs/example/ruby_network_test.py --num-cpus=4 --num-dirs=4 >> --topology=Mesh --mesh-rows=2 --sim-cycles=1000 --injectionrate=0.01 >> --synthetic=0 --fixed-pkts --maxpackets=1 --garnet-network=fixed* >> Meanwhile, it worked fine if I drop the option "--garnet-nework=fixed" >> off the command like: >> * ./build/ALPHA_Network_test/gem5.debug >> ./configs/example/ruby_network_test.py --num-cpus=4 --num-dirs=4 >> --topology=Mesh --mesh-rows=2 --sim-cycles=1000 --injectionrate=0.01 >> --synthetic=0 --fixed-pkts --maxpackets=1* >> >> Based on this observation, I wonder if you succeed in running a >> simulation with configs/example/ruby_network_test.py, especially invoking >> garnet network. I tested the ruby network tester with both g++ 4.3.2 and >> g++ 4.6.1, and checked with different garnet mode (i.e. flexible) as well. >> They had the same result "failure" (please see previous email). If you >> think this is related to c++ version issue, could you tell me which version >> of c++ you are using on your platform? (including other packages' version >> such as swig/python/zlib/m4 if possible). >> >> Can you give me more comment on this garnet invocation issue? >> Thanks. >> >> >> - Juyoung >> >> >> >> >> >> >> >> On Tue, May 8, 2012 at 12:08 PM, Tushar Krishna <tus...@csail.mit.edu>wrote: >> >>> Hi Juyoung, >>> In future pls send the emails directly on gem5-users so that others who >>> experienced similar problems can help out as well? >>> I am cc:ing gem5-users >>> >>> >>> I just pulled out the latest version of gem5 and ran this exact command >>> and it worked fine. >>> Are you getting this error only with ruby and garnet and this particular >>> protocol? >>> >>> It seems to me that it might be some C++ version issue etc … >>> >>> Can you test it with another protocol too, without garnet. >>> Eg: >>> >>> scons build/ALPHA_MOESI_hammer/gem5.debug >>> >>> ./build/ALPHA_MOESI_hammer/gem5.debug >>> configs/example/ruby_random_test.py --num-cpus=4 --num-dirs=4 >>> --topology=Mesh --mesh-rows=2 -l 1000 >>> >>> [The -l command in ruby_random_test specifies the number of cycles to >>> inject]. >>> >>> - Tushar >>> >>> >>> On May 8, 2012, at 1:31 PM, Juyoung Jung wrote: >>> >>> Hi Tushar, >>> >>> >>> I am trying to run Garnet simulator with gem5 following the >>> documentation found at http://www.gem5.org/Networktest. However, in my >>> case, it failed to running as it stand, even if other setup conditions have >>> been met. I tested both the most recent stable and dev gem5, and the same >>> problem happened. The followings are errors and warnings which I ran into. >>> >>> >>> #> ./build/ALPHA_Network_test/gem5.debug >>> ./configs/example/ruby_network_test.py --num-cpus=4 --num-dirs=4 >>> --topology=Mesh --mesh-rows=2 --sim-cycles=1000 --injectionrate=0.01 >>> --synthetic=0 --fixed-pkts --maxpackets=1 --garnet-network=fixed >>> >>> gem5 Simulator System. http://gem5.org >>> gem5 is copyrighted software; use the --copyright option for details. >>> >>> gem5 compiled May 8 2012 12:20:15 >>> gem5 started May 8 2012 13:15:56 >>> gem5 executing on panther >>> command line: ./build/ALPHA_Network_test/gem5.debug >>> ./configs/example/ruby_network_test.py --num-cpus=4 --num-dirs=4 >>> --topology=Mesh --mesh-rows=2 --sim-cycles=1000 --injectionrate=0.01 >>> --synthetic=0 --fixed-pkts --maxpackets=1 --garnet-network=fixed >>> warning: add_child('cls'): child 'credit_links0 credit_links1' already >>> has parent >>> warning: add_child('cls'): child 'credit_links0 credit_links1' already >>> has parent >>> warning: add_child('cls'): child 'credit_links0 credit_links1' already >>> has parent >>> warning: add_child('cls'): child 'credit_links0 credit_links1' already >>> has parent >>> warning: add_child('cls'): child 'credit_links0 credit_links1' already >>> has parent >>> warning: add_child('cls'): child 'credit_links0 credit_links1' already >>> has parent >>> warning: add_child('cls'): child 'credit_links0 credit_links1' already >>> has parent >>> warning: add_child('cls'): child 'credit_links0 credit_links1' already >>> has parent >>> warning: add_child('cls'): child 'credit_links0 credit_links1' already >>> has parent >>> warning: add_child('cls'): child 'credit_links0 credit_links1' already >>> has parent >>> warning: add_child('cls'): child 'credit_links0 credit_links1' already >>> has parent >>> warning: add_child('cls'): child 'credit_links0 credit_links1' already >>> has parent >>> Global frequency set at 1000000000 ticks per second >>> Traceback (most recent call last): >>> File "<string>", line 1, in <module> >>> File >>> "/home/juyoung/research/simulators/gem5-dev/gem5/src/python/m5/main.py", >>> line 357, in main >>> exec filecode in scope >>> File "./configs/example/ruby_network_test.py", line 131, in <module> >>> m5.*instantiate()* >>> File >>> "/home/juyoung/research/simulators/gem5-dev/gem5/src/python/m5/simulate.py", >>> line 90, in instantiate >>> for obj in root.descendants(): obj.*createCCObject()* >>> File >>> "/home/juyoung/research/simulators/gem5-dev/gem5/src/python/m5/SimObject.py", >>> line 1035, in createCCObject >>> self.*getCCParams()* >>> File >>> "/home/juyoung/research/simulators/gem5-dev/gem5/src/python/m5/SimObject.py", >>> line 994, in getCCParams >>> *setattr(cc_params, param, value)* >>> SystemError: NULL result without error in PyObject_Call >>> Segmentation fault >>> >>> >>> I am not sure but it seems to have a problem in setting C++ object's >>> attribute. >>> Even if I found some port-related issues posted by Pavan Poluri from old >>> mailing archive, this problem is likely related to more recent changes in >>> either Ruby, Garnet, or both. >>> Could you give me a hint how I can resolve the problem? >>> Thanks. >>> >>> >>> Regards, >>> >>> >>> Juyoung >>> >>> >>> >> >> >> -- >> >> ------------------------------------------------------------------------------------ >> >> >> > > > -- > > ------------------------------------------------------------------------------------ > > > -- ------------------------------------------------------------------------------------
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
