On Thu, Dec 29, 2011 at 6:04 AM, Eliot Moss <m...@cs.umass.edu> wrote:
> I tried again, starting from checking out gem5 and encumbered, fresh from > the repo. > It seemed to make a difference to use a ../encumbered path in EXTRAS, and > perhaps > to use the specific name 'encumbered' (I had renamed the directory to > gem5-encumbered). > The name and whether it's an absolute or relative path really shouldn't matter. If it bugs you, you can use the '--verbose' flag to scons to print out the full g++ command line and see what was coming after -I before, but if you're content that it works now, that's OK too. > The build went through fine. My command line was: > > scons CC=gcc44 CXX=g++44 EXTRAS=../encumbered build/ALPHA_SE/tests/debug/* > *quick > > The EIO tests indeed fail, but anagram isn't there so it's no surprise. > Where does it come from, by the way? The anagram program that generates the trace is one of the tests that comes with SimpleScalar. I don't know if the EIO trace itself came with SimpleScalar too or if we generated it ourselves. Note that gem5 only reads EIO traces; it can't generate them itself. This capability was very useful for transitioning from SS to m5 way back a long time ago, but I don't know of anyone using it in a long time. We were just discussing dropping support for it recently, since the confusion it causes in the regression tests seems to outweigh any benefit anyone gets from it anymore. > The memtest failure is more bothersome. Are you sure the test was rerun >> after you updated to the >> non-stable repository? If so, it might be worth doing a clean build (you >> can do "scons -c", or just >> "rm -rf build"). >> > > memtest still fails. Here is the exact contents of simerr: > > gem5.debug: build/ALPHA_SE/mem/cache/**cache_impl.hh:1257: void > Cache<TagStore>::handleSnoop(**Packet*, typename TagStore::BlkType*, > bool, bool, bool) [with TagStore = LRU]: Assertion > `!pkt->memInhibitAsserted()' failed. > Program aborted at cycle 409893 > This is still very weird. The assertion failure is one I've seen before; it's commonly a symptom of some corner-case coherence protocol bug. The problem is that (1) there are no outstanding coherence protocol bugs that I know of and (2) even i there were, the pseudo-random number generator should be repeatable such that the fact that we don't encounter it in our regression test means that you shouldn't encounter it either. So I'm doubly confused. I fired up a longer run of the random tester (10M vs 100K accesses) to ook for evidence that assumption #1 is wrong, but it also passed. I'll fire up an even longer one, but that still leaves issue #2. I'm perplexed. Are you running this on Linux? > PS: Since the first, most basic, build is more or less passing, what's the next thing up that I can test? > The util/regress script fires off our full regressions (compiles gem5.debug, gem5.opt, and gem5.fast for all ISAs, runs all the 'quick' tests using gem5.opt). It takes quite a while though. You can subset it as you please using command-line options (util/regress --help for details). The tests do require a number of additional binaries that aren't in the repository though. Most of these are available from te links named "full system files" here: http://gem5.org/Download. I see there's also a very brief discussion here: http://gem5.org/Introduction#Getting_Additional_Tools_and_Files. Neither of these places mentions that you can put the files anywhere you want as long as you set the M5_PATH environment variable to point to them... you have to look here for that: http://gem5.org/Compiling_M5#Installing_full_system_files. Ugh. BTW, if you have any inclination at all to update our wiki to clarify any issues you've run into, please don't hesitate... it would be much appreciated. Steve
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
