Re: [m5-dev] memtest.cc

On Mon, Aug 31, 2009 at 8:48 PM, Polina Dudnik wrote: > I see. It seems like it would be more appropriate to have tester test larger > requests because we are getting a false sense of correctness by running the > test. It tests the protocol logic well but not the data correctness. It's a "false sh

Re: [m5-dev] memtest.cc

I see. It seems like it would be more appropriate to have tester test larger requests because we are getting a false sense of correctness by running the test. It tests the protocol logic well but not the data correctness. Also, is there a maximum on the size of the m5 request? I would like to test

Re: [m5-dev] memtest.cc

Good question. Looks like historical cruft to me. I think there used to be a mode that tested variable-size accesses but that mode got ripped out. Note that access_size is log2 of the access size, so setting it to 0 means byte accesses. Steve On Mon, Aug 31, 2009 at 3:30 PM, Polina Dudnik wrot

[m5-dev] memtest.cc

Hi, I have a question: why is it that the access_size is first calculated as random() % 4 and then reset to zero before issuing the request in MemTest::tick? Thank you. Polina ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m

[m5-dev] config patch

Hi, I am attaching a small patch that enables the passing of the ruby config file as a parameter. So, multiple protocols can be tested without manually modifying the config_file name. Comments are welcome. Polina config_as_param Description: Binary data

[m5-dev] Syscall issue: exit() vs. exit_group()

Hello evebody, Here's a small observation that I made: In SMT configurations for ALPHA/Linux, the first workload that finishes terminates all the other workloads on the CPU because it makes the system call, exit_group(). This problem, however, does not surface with the "hello" binary checked into

Re: [m5-dev] Cron /z/m5/regression/do-regression quick

Quoting nathan binkert : >> I'm rerunning regressions on zizzer and everything seems fine so >> far... this looks like an issue with swig on the pool machines.  Does >> anyone have any idea why things might have changed (either with the >> version of swig on the pool machines, or the version that

Re: [m5-dev] Cron /z/m5/regression/do-regression quick

> I'm rerunning regressions on zizzer and everything seems fine so > far... this looks like an issue with swig on the pool machines.  Does > anyone have any idea why things might have changed (either with the > version of swig on the pool machines, or the version that we require)? > > Unfortunately

Re: [m5-dev] Cron /z/m5/regression/do-regression quick

I'm rerunning regressions on zizzer and everything seems fine so far... this looks like an issue with swig on the pool machines. Does anyone have any idea why things might have changed (either with the version of swig on the pool machines, or the version that we require)? Unfortunately the log do

[m5-dev] Cron /z/m5/regression/do-regression quick

scons: *** [build/ALPHA_SE/python/swig/random_wrap.fo] Error 1 scons: *** [build/ALPHA_SE/python/swig/trace_wrap.fo] Error 1 scons: *** [build/ALPHA_SE/python/swig/debug_wrap.fo] Error 1 scons: *** [build/ALPHA_SE/python/swig/stats_wrap.fo] Error 1 scons: *** [build/ALPHA_SE/python/swig/event_wrap.