In terms of fast forwarding and checkpointing, you probably should understand how it works in the SimpleCPU (or O3CPU) before implementing it for InOrder. In short, at checkpoint time you need to drain the CPU then save the checkpoint. As far as I can remember, there are no valid implementations of save/restore checkpoint for the InOrder CPU as of yet so that's what's preventing you from fixing that. The "port connections" problem sounds like something that's been on the mailing list before so check the archives for that.
There are a few things that can be done to speedup inorder but it requires understanding the model so that you can make the optimizations to the code (this deals with memory allocation as well as CPU sleeping/waking up). If you are interested in going that route, send a message to gem5-dev. On Sun, Apr 29, 2012 at 11:21 AM, Eyal Yaacoby <eya...@gmail.com> wrote: > Hi, > Thanks for the reply. > > When I say that HWREI caused problems, I mean that the inorder CPU does > not take a branch that the O3 CPU does take (the inorder CPU just keeps > executing the code afterwards), thus it starts executing nonsense > instructions. > This code path eventually causes it to read from a bad address > (specifically, 0xfffff00188), where it gets an error (when debugging with > InOrderCPUAll, one can see this error: "system.cpu.dcache_port-cache-port: > Got error packet back for address: fffff00188"). This error causes the CPU > to go to sleep and never wake up. > > After fixing this issue, Linux boots successfully, but this takes a very > long time (~40 minutes on my personal computer). > I'm trying to work around it. Fast forwarding instructions doesn't work on > an inorder CPU, and restoring from checkpoint doesn't work either (for the > same reason). > The error (or a segmentation fault, depending on the configuration) > happens when the simulator finds out that the I$ of the inorder CPU has a > port that isn't connected. The port isn't connected as the inorder CPU was > constructed with defer_registration. > I'm trying to figure out what's the right way to fix this issue. > > > Eyal Yaacoby > > > > On Sun, Apr 29, 2012 at 1:20 AM, Korey Sewell <ksew...@umich.edu> wrote: > >> Yup, >> that's in this patch: >> http://reviews.m5sim.org/r/740/ >> >> There is no clean way to do enforce hwrei unfortunately. I really think >> the correct way to do this is mark the HWREI as control as it does actually >> change the program flow. >> >> However, that breaks O3 and I haven't taken the time to go through the O3 >> code to fix things if that is now marked as control. I may take that dive >> soon so we stop getting this question. >> >> Also, very nice debugging sir. When you say HWREI caused problems, what >> specifically do you see that let you know it was a problem (this will be >> good for the mailing list archives). >> >> On Sat, Apr 28, 2012 at 1:01 PM, Eyal Yaacoby <eya...@gmail.com> wrote: >> >>> Update: >>> I was able to solve the problem. >>> >>> The first useful step was to print all the instructions that ran on the >>> inorder CPU (--debug-flags=ExecAll helped here) and I found out that the >>> first instruction that caused problems was HW_REI. >>> Apparently, this instruction is not recognized as a control instruction >>> by the inorder CPU. >>> >>> It looks like it is a known issue - see >>> http://www.mail-archive.com/gem5-users@gem5.org/msg02614.html - adding >>> "IsControl" to the hw_rei instruction (on /arch/alpha/isa/decoder.isa) >>> solves the problem and the inorder CPU successfully boots the Linux kernel. >>> This, however, also causes the O3 CPU to fail, so I'm currently keeping two >>> distinct versions for both CPUs. >>> >>> >>> Eyal Yaacoby >>> >>> >>> >>> On Sat, Apr 28, 2012 at 3:42 AM, Eyal Yaacoby <eya...@gmail.com> wrote: >>> >>>> Hi, >>>> >>>> I'm new to Gem5. I hope this is the right place to seek for help. >>>> >>>> I ran into a problem when trying to boot linux on Alpha full-system >>>> using an inorder CPU - after ~187 instructions, the CPU tries to read from >>>> address 0xfffff00188, gets an error (as it isn't translated properly), goes >>>> to sleep and never wakes up. >>>> >>>> This problem happens on both gem5 and gem5-stable, with two versions of >>>> "vmlinux" (the linux kernel alpha binary) I've tried, and with several >>>> different command lines, e.g. >>>> ./build/ALPHA_FS/gem5.debug ./configs/example/fs.py --inorder --caches >>>> --l2cache >>>> ./build/ALPHA_FS/gem5.opt ./configs/example/fs.py --inorder --caches >>>> --l2cache >>>> and others. >>>> The same command lines work with all other CPU types. >>>> >>>> I've tried debugging it by outputting debug information, and I'm pretty >>>> sure something goes wrong earlier than that memory read (from >>>> 0xfffff00188), as I believe it should never get there, but I don't know >>>> where to look. >>>> >>>> Does the inorder CPU support booting the linux kernel on Alpha at all? >>>> Am I doing something wrong? If not, where can I look further to debug >>>> this issue? >>>> >>>> Thanks in advance, >>>> Eyal Yaacoby >>>> >>>> >>>> >>> >>> _______________________________________________ >>> gem5-users mailing list >>> gem5-users@gem5.org >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >> >> >> >> -- >> - Korey >> >> _______________________________________________ >> gem5-users mailing list >> gem5-users@gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > -- - Korey
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
