On 06.08.2012 11:48, Nilay wrote:
> On Mon, August 6, 2012 9:17 am, Andreas Hansson wrote: > >> Hi everyone, A bit more detail on the mysterious pc-simple-timing that passes in zizzer but fails on a whole range of other systems. It turns out the zizzer stats generated in the test run are wrong(!) Here's how I found this out: 1) Added a flag where the stat is incremented (num_mem_refs and store_insts in src/cpu/simple/base.cc) 2) Dumped on two systems with the stats .value() printed with a dedicated flag 3) Compared the traces, and they match! This is where my head started to spin... :) 4) Ran the pc-simple-timing manually on zizzer with the command found in the simout and guess what: the stats are the same as on the other systems! 5) Tried running the regression again with scons -j1 to avoid any odd race conditions, but the stats that come out that way are off, suggesting the last instruction (or at least memory access) has simply not happened yet the moment the stats are dumped. Odd to say the least. I have massaged the tests/SConscript to not use scons Execute command, but instead subprocess.call, and with this change the regressions on zizzer also fail. In conclusion, either scons or gem5 is doing something odd here. Any scons ninja out there that has any idea? I tried adding a sleep of 10 s before and after, but that does not seem to help. Could it be related to some bug in drain? Perhaps we can bump the scons version on zizzer just in case? > > I was recently testing a patch related to x86 when I also noticed the > problem and the stats actually matched the ones that you had posted > earlier. I think it is some case similar to x86 cpuid instruction. Steve > had mentioned another instruction for which he saw difference in traces > from two different runs. I tried to figure if there was something wrong, > but was not able to. > > I think if there was some problem with scons / dumping of stats, we would > have seen this problem occur with other tests as well. The difference between running gem5 in SCons and running it with a subprocess call is the environment that is present when gem5 starts (what is on the initial stack mostly). It's likely that the stack differences is causing the output to change and it's not SCons fault directly. Thanks, Ali _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
