That sounds exactly like what's happening. It's that assert that is failing. Can you whip up a fix? If you don't have time to re-run regressions, you can send the fix to me and I can run them tonight. You can alternatively just run this one: long/50.vortex/alpha/tru64/simple-atomic
it fails very quickly right now. On Fri, Nov 14, 2008 at 2:27 PM, Steve Reinhardt <[EMAIL PROTECTED]> wrote: > If your getting an assertion failure in the chunk generator, it's > probably (partially) my fault... I added an assertion there (totalSize >>= 0) that would have caught a painful bug I had to track down much > earlier, and just ran the quick regressions on it. > > I think that assertion is probably now exposing a pre-existing bug in > obreakFunc() where we use ChunkGenerator to allocate new pages without > verifying that the new break val is actually larger than the old one. > > Steve > > On Fri, Nov 14, 2008 at 2:18 PM, nathan binkert <[EMAIL PROTECTED]> wrote: >> I just ran the long regressions (quick all pass) and some of them >> crash in the obreak syscall because of bogus arguments to the chunk >> generator code. It is entirely possible that it's another bug caused >> by me, but I'm not certain. I can't do any more hacking until later >> tonight, so unless someone has the time to try to figure out the >> problem, the tree is slightly broken. >> >> I apologize if this is my fault. I know I passed all of the >> regressions with m5.fast before I did my big push the other day, but I >> didn't run the opt. >> >> If it's not solved by tonight, I'll try to get it figured out. >> >> Nate >> _______________________________________________ >> m5-dev mailing list >> m5-dev@m5sim.org >> http://m5sim.org/mailman/listinfo/m5-dev >> > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
