> > > Hi folks, > > I am getting a deadlock detected error when I try to run Alpha MOESI CMP directory with 32 or more cores, when configured with Ruby and full system. I found mention of this in mailing list archives but no solutions worked for me. This also seems to happen in the baseline version, and I can't find a set of parameters that prevent this. > > Any ideas? Is this a known problem? > > Thank you! > > Panic: Possible Deadlock detected. Aborting! > version: 0 request.paddr: 0x[0x4000, line 0x4000] m_readRequestTable: 1 current time: 250000000 issue_time: 0 difference: 250000000 > <at> tick 1056460 > [wakeup:build/ALPHA_MOESI_CMP_directory/mem/ruby/system/Sequencer.cc, line 176] > > > ./configs/example/fs.py \ > -n 64 \ > --ruby \ > --cpu-type=timing \ > --caches \ > --l2cache \ > --sys-clock=2GHz \ > --cpu-clock=2GHz \ > --num-l2caches=16 \ > --l1i_size=32kB \ > --l1d_size=32kB \ > --l2_size=16MB \ > --l1d_assoc=2 \ > --l1i_assoc=2 \ > --l2_assoc=8 \ > --cacheline_size=64 \ > --num-dirs=16 \ > --topology=Crossbar \ > --kernel=vmlinux_2.6.27-gcc_4.3.4 \ > > > > > > _______________________________________________ > gem5-users mailing list > gem5-users <at> gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Hi George Is your problem solved now? I met the same problem, and I find that it is because the L2 cache controllers are always calling zz_recycleL1RequestQueue action which causes the L2 cache always handling the L1 request while the data response from the directory for 0x4000 cannot be processed. If you modify the action to z_stall this problem can be solved. But I met more problems after getting over this step, the OS still cannot come up and hang at srm_env: version 0.0.6 loaded successfully when I use 16 core configuration. George Michelogiannakis <mixelogj13 <at> yahoo.co.uk> writes: _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
