-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/755/
-----------------------------------------------------------
(Updated 2012-01-17 11:49:44.996958)
Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan
Binkert.
Changes
-------
Hello! I think I find the solution to this problem now.
Firstly, I merged the CP0 initialization code from FSConfig.py into configCP()
function in isa.cc, and made ISA::clear() call the configCP() fucntion.
Although it is unnecessary to move those codes from FSConfig.py to isa.cc, the
other parts of configCP() fucntion, such as setRegMask() for some MiscRegs, are
essential to the validity of gem5. After that, I tested a small testcase in
MIPS_SE mode, and the errors caused by linked load instruction are as follows:
info: Entering event queue @ 0. Starting simulation...
info: Increasing stack size by one page.
warn: 300511500: context 0: 100000 consecutive store conditional failures
warn: 600511500: context 0: 200000 consecutive store conditional failures
warn: 900511500: context 0: 300000 consecutive store conditional failures
warn: 1200511500: context 0: 400000 consecutive store conditional failures
...
Then I check the setMiscReg() function. It calls filterCP0Write() just before
scheduleCP0Update(), and filterCP0Write() relies on the miscRegFile_WriteMask
set by configCP(). At this time, I found that the masks of
Random/BADVADDR/LLADDR are wrongly set to 0 in configCP(), which prevented the
writing back of the values to these registers. Furthermore, the zero mask of
LLADDR caused the problem of linked load instruction, and the zero mask of
Random register caused the problem of tlbwr instruction.
By deleting these codes in configCP(), we can get the correct results in both
MIPS_SE and MIPS_FS modes, without fixing any other codes such as setMiscReg()
or scheduleCP0Update().
Summary
-------
The read/setMiscRegNoEffect are declared in inorder_dyn_inst.hh, but not
defined in inorder_dyn_inst.cc.
I hope the definitions can be added for the future use.
----
The problem is caused by a MIPS linked load instruction. It make the CP0 halt
then restart. After that, the tick becomes a large number and it says 'because
simulate() limit reached'.
Korey Sewell told me:
If you get "simulate() reached", that means your system likely deadlocked
as there are no more events on the main event queue. Run w/the cpu progress
interval on to help determine where the CPUs stops committing instructions.
Also, post the locked_mem.hh patch if you want comments on what you are trying
to do to resolve the problem.
----
I change the locked_mem.hh to an old stable version, to avoid the problem
mentioned above. But I know this is not 'fixing the bug', but 'avoiding the
bug'.
Diffs (updated)
-----
src/arch/mips/isa.cc a33fd5964e66
Diff: http://reviews.m5sim.org/r/755/diff
Testing
-------
Only single thread.
Thanks,
Deyuan
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
