* build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby
FAILED!
* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic
passed.
= Statistics differences =*
build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby passed.
*
I see one failure but two occurrences of Statistics differences. You
were the only one to check something in yesterday, Steve.
Gabe
Cron Daemon wrote:
* build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby
FAILED!
*
The Statistics Differences line doesn't mean anything, that gets
printed even if there aren't any changes. It's just a fluke of
interleaved outputs when those get printed out by grep.
They all passed before I committed, so it's probably some minor thing;
I see that it's the Ruby test for the
Hi All,
Yesterday a few of us from AMD and Wisconsin met and discussed the next tasks
for GEM5. Specifically there are a couple (possibly more?) new graduate
students at Wisconsin that are starting to ramp up in the simulator. While we
spent some time discussing short-term projects for the
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/203/
---
Review request for Default.
Summary
---
STATS: Fix off-by-one error in
Hi,
I am currently running a benchmark in X86_FS timing mode (single or
multicore) that crashes due to the page table walker. On a data write (or
read) instruction that causes TimingSimpleCPU::write to split the TLB access
into two accesses (cpu/simple/timing.cc:~560), if the first TLB access
Off hand I would say yes, queuing up a second request behind one that
caused a table walk makes sense. Since there should only be one other
request, just having a variable for the on deck request should be
sufficient instead of a full blown queue. Please let me know if you
think otherwise.
