oops. mistakenly sent to list ... On 6/8/12, Mahmood Naderan <mahmood...@gmail.com> wrote: > On 6/8/12, mingkai huang <huangming...@gmail.com> wrote: >> No fast forward and max inst. I compiled the binary in SPEC2006 and I >> didn't modify the source file. The input is from test input. >> I have posted the link to download the binary and input I used in my >> previous email, and I wrote the command I used in my first email. >> >> My command line is: >> build/X86/gem5.fast configs/example/se.py --cpu-type=detailed --caches -c >> bzip2 -o "input.program 5" >> >> The version of my gem5 is 8981. >> The os I used is RHEL 6.2. >> >> The link to my binary and input: >> http://mail.qq.com/cgi-bin/ftnExs_download?k=0962383845ebe89e745811294262054e53570059515a0e041a555c0f544f0356540315015355534c0f530f01535253000556080a646b37034d0b480a4a105613375f&t=exs_ftn_download&code=7b88db7a >> >> On Thu, Jun 7, 2012 at 12:57 PM, Mahmood Naderan >> <mahmood...@gmail.com>wrote: >> >>> what input do you use? have you modify source code? How many fast >>> forward? how many max inst/tick? >>> i have not such problem with bzip2 for -F 2000000000 --maxtick >>> 100000000000 >>> >>> On 6/7/12, mingkai huang <huangming...@gmail.com> wrote: >>> > Thanks! I tried that, but it seems doing that can't fix this problem. >>> > The output of bzip2 going wrong is many "info: Increasing stack size >>> > by >>> one >>> > page." followed by "fatal: Over max stack size for one thread". I >>> > think >>> > that bzip2 goes into a dead loop and increases the stack for ever. No >>> > matter how much stack size set, the stack will be running out. >>> > >>> > On Sun, Jun 3, 2012 at 4:23 PM, Mahmood Naderan >>> > <mahmood...@gmail.com>wrote: >>> > >>> >> I faced that before. Thank to Ali, the problem is now fixed >>> >> You should modify two files: >>> >> >>> >> 1) src/sim/process.cc >>> >> you should find something like this: >>> >> if (stack_base - stack_min > 8 * 1024 * 1024) >>> >> fatal("Over max stack size for one thread\n"); >>> >> >>> >> >>> >> 2) src/arch/x86/process.cc >>> >> you should find two occurrence of this statement >>> >> next_thread_stack_base = stack_base - (8 * 1024 * 1024); >>> >> >>> >> Now change the right side from 8*1024*1024 to whatever you want. >>> >> 32*1024*1024 is enough I think. >>> >> >>> >> Hope that help >>> >> >>> >> On 6/3/12, mingkai huang <huangming...@gmail.com> wrote: >>> >> > Hi, >>> >> > I am sorry to be too late to rely. >>> >> > I tracediffed the output of 8842 and 8841 and attached the output. >>> >> > I >>> >> > revised one place of the output format in 8841 to make the output >>> >> > more >>> >> > similar, but it seems the format changed a lot, and the diff may >>> >> > not >>> >> > be helpful. I also put a breakpoint, printed out the stack trace, >>> >> > and >>> >> > attached the output. >>> >> > This is the bzip2 and input I used: >>> >> > >>> >> >>> http://mail.qq.com/cgi-bin/ftnExs_download?k=0962383845ebe89e745811294262054e53570059515a0e041a555c0f544f0356540315015355534c0f530f01535253000556080a646b37034d0b480a4a105613375f&t=exs_ftn_download&code=7b88db7a >>> >> > Because of mail list size limitation, I use the qq large file >>> >> > attachment. >>> >> > Thanks! >>> >> > >>> >> > On Thu, May 17, 2012 at 6:49 AM, Steve Reinhardt <ste...@gmail.com> >>> >> wrote: >>> >> >> Hi Mingkai, >>> >> >> >>> >> >> Can you run under gdb, put a breakpoint on this fatal statement >>> (which >>> >> is >>> >> >> in >>> >> >> Process::fixupStackFault() in sim/process.cc), print out the stack >>> >> >> trace >>> >> >> when you hit it, and mail that to the list? >>> >> >> >>> >> >> I wonder if the new branch predictor is causing some different >>> >> wrong-path >>> >> >> execution, and that we are erroneously calling fatal() on >>> >> >> something >>> >> >> that >>> >> >> looks like a stack fault but is actually a misspeculated >>> >> >> instruction. >>> >> >> >>> >> >> Given that all the regressions pass, I doubt the new branch >>> >> >> predictor >>> >> >> is >>> >> >> actually changing the committed execution path. That's why I >>> >> >> think >>> it >>> >> >> may >>> >> >> have something to do with a bug in how we handle misspeculation. >>> >> >> >>> >> >> If anyone knows the code well enough to say whether this seems >>> >> >> likely >>> >> >> or >>> >> >> unlikely, that would be helpful. >>> >> >> >>> >> >> Steve >>> >> >> >>> >> >> >>> >> >> On Wed, May 16, 2012 at 3:09 PM, Geoffrey Blake <bla...@umich.edu> >>> >> wrote: >>> >> >>> >>> >> >>> Unfortunately the CheckerCPU does not work for x86 and is only >>> >> >>> verified as working on ARM. It needs some additional work to >>> >> >>> support >>> >> >>> the representation of machine instructions for x86. >>> >> >>> >>> >> >>> Geoff >>> >> >>> >>> >> >>> On Tue, May 15, 2012 at 7:43 AM, Gabe Black >>> >> >>> <gbl...@eecs.umich.edu> >>> >> >>> wrote: >>> >> >>> > The change may have made the branch predictor code behave >>> >> incorrectly, >>> >> >>> > for instance an instruction could execute twice, a >>> >> >>> > misspeculated >>> >> >>> > instruction could sneak through and commit, an instruction >>> >> >>> > could >>> be >>> >> >>> > skipped, a branch could be "corrected" to go down the wrong >>> >> >>> > path. >>> >> >>> > There >>> >> >>> > are lots of things that could go wrong. Alternatively, the >>> >> >>> > branch >>> >> >>> > predictor might have just gotten better and put more stress on >>> some >>> >> >>> > other part of the CPU, or coincidentally lined up circumstances >>> >> >>> > which >>> >> >>> > expose another bug. You should try to find where execution >>> diverges >>> >> >>> > between O3 and the atomic CPU, possibly using tracediff or >>> possibly >>> >> >>> > using the checker CPU. I'm not sure the checker works correctly >>> >> >>> > with >>> >> >>> > x86, but if it does this is pretty much exactly what it's for. >>> >> >>> > >>> >> >>> > Gabe >>> >> >>> > >>> >> >>> > On 05/14/12 17:22, mingkai huang wrote: >>> >> >>> >> Hi, >>> >> >>> >> I tried to use gem5 to run SPEC2006 in x86 O3 mode. When I ran >>> >> bzip2, >>> >> >>> >> it failed with: >>> >> >>> >> fatal: Over max stack size for one thread >>> >> >>> >> My command line is: >>> >> >>> >> build/X86/gem5.fast configs/example/se.py --cpu-type=detailed >>> >> >>> >> --caches >>> >> >>> >> -c bzip2 -o "input.program 5" >>> >> >>> >> The version of my gem5 is 8981. >>> >> >>> >> Bzip2 can run correctly in atomic mode. >>> >> >>> >> I binary searched where the problem happened first, and found >>> >> version >>> >> >>> >> 8842. I noticed this patch is about branch prediction, and I >>> don't >>> >> >>> >> understand why this can affect the correctness of an >>> >> >>> >> application. >>> >> >>> >> Before 8842, Bzip2 can run correctly in both mode, but the >>> >> >>> >> outputed >>> >> >>> >> numbers of "info: Increasing stack size by one page." are not >>> >> >>> >> equal. >>> >> >>> >> Because of email size limitation, I can't attached the file I >>> >> >>> >> used. >>> >> >>> >> >>> >> >>> > >>> >> >>> > _______________________________________________ >>> >> >>> > 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 >>> >> >> >>> >> >> >>> >> >> >>> >> >> _______________________________________________ >>> >> >> gem5-users mailing list >>> >> >> gem5-users@gem5.org >>> >> >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >> > >>> >> > >>> >> > >>> >> > -- >>> >> > Best regards, >>> >> > Mingkai Huang >>> >> > >>> >> >>> >> >>> >> -- >>> >> // Naderan *Mahmood; >>> >> _______________________________________________ >>> >> gem5-users mailing list >>> >> gem5-users@gem5.org >>> >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >> >>> > >>> > >>> > >>> > -- >>> > Best regards, >>> > Mingkai Huang >>> > >>> >>> >>> -- >>> // Naderan *Mahmood; >>> _______________________________________________ >>> gem5-users mailing list >>> gem5-users@gem5.org >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >> >> >> >> -- >> Best regards, >> Mingkai Huang >> > > > -- > // Naderan *Mahmood; >
-- // Naderan *Mahmood; _______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
