> On 2012-01-16 08:17:15, Steve Reinhardt wrote: > > I'd rather see something that's a little closer to actually solving the > > problem (even if it doesn't work around it completely). > > > > Looking at arch/mips/isa.cc, the only difference between setMiscReg() and > > setMiscRegNoEffect() is that the former calls scheduleCP0Update(). I'm not > > sure what that's all about, but if setting the LL register shouldn't call > > that, then the right thing to do is to add some code to setMiscReg() to > > avoid that. If you look at most ISAs, setMiscReg() typically has a giant > > switch statement to catch all the idiosyncrasies of misc registers; it's > > odd that MIPS doesn't. > > > > So we could start with a switch statement that keeps the > > scheduleCP0Update() in as the default case but does nothing for > > MISCREG_LLADDR and MISCREG_LLFLAG, unless Korey can help define something > > even better. (E.g., if we knew exactly which misc regs require > > scheduleCP0Update(), it would be vastly preferable to just call it when > > those regs get written, and have the default be nothing.)
I think my review is similar to the original one I had here in that we need to find out why that scheduleCP0Update() isnt working right. That function is supposed to collect all the writes to the system/CP0 state on a given cycle and then update it simultaneously. It was written because changing the system registers affects the functionality but in a multithreaded core there may be multiple updates to the system state on a given cycle. So instantly changing the system state while these updates could result in incorrect execution. My theory is that something happens when the LLFLAG/ADDR gets set and somehow doesnt schedule the update event. Deyuan, if we remove that code, can we identify the cycle that LLFLAG is set and see if it actually gets update (you were saying the system deadlocks instead?) - Korey ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/755/#review1952 ----------------------------------------------------------- On 2012-01-16 10:46:18, Deyuan Guo wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/755/ > ----------------------------------------------------------- > > (Updated 2012-01-16 10:46:18) > > > Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and > Nathan Binkert. > > > 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 > ----- > > src/arch/mips/isa.cc f348cf78072c > > 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
