I feel this is currently too complicated for me, and it would probably require too much time, so I'm leaving this route. I have a new problem which I'll post separately.
Thanks again for the answers. Eyal Yaacoby On Sun, Apr 29, 2012 at 6:58 PM, Korey Sewell <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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/[email protected]/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 <[email protected]> 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 >>>> [email protected] >>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>> >>> >>> >>> >>> -- >>> - Korey >>> >>> _______________________________________________ >>> gem5-users mailing list >>> [email protected] >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >> >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > > > > -- > - Korey > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
