* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic-ruby
passed.
* build/ALPHA_SE/tests/fast/long/50.vortex/alpha/tru64/simple-timing passed.
* build/ALPHA_SE/tests/fast/long/70.twolf/alpha/tru64/simple-timing passed.
*
I might be able to help with this, but I'm not sure exactly what the
problem is. It might be caused by a reference to the libruby_file
variable in ruby_se.py. I can't (or don't know how to) access
/z/m5/regression/regress-2009-10-18-03:00:01 to confirm, but
memtest-ruby is working for me with
changeset a1d8c53d92b8 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=a1d8c53d92b8
description:
removed libruby file reference from ruby_se.py
diffstat:
1 file changed, 1 deletion(-)
configs/example/ruby_se.py |1 -
diffs (11 lines):
diff -r e93e6d7b48a0 -r
Actually, it looks like a reference miscorrelation error (see below).
It appears this problem has existed since Polina's checkin on 8/28. The
difference is rather minor, do we want to just go ahead and update the
reference?
Brad
-Exiting @ tick 31749698 because maximum number of loads
I believe that the issue was that the checkin wasn't supposed to
change stats, yet it did. It's ok for stat values to change, but we
only want them to change when we actually change something that should
affect them. She was going to verify that it made sense.
Nate
On Sun, Oct 18, 2009 at
Right,
I'm not sure if it does make sense, but I will check it.
Polina
On Sun, Oct 18, 2009 at 2:22 PM, nathan binkert n...@binkert.org wrote:
I believe that the issue was that the checkin wasn't supposed to
change stats, yet it did. It's ok for stat values to change, but we
only want them
Thinking about this more, it also seems that NO_FAULT doesn't quite
capture what a prefetch is. If you're doing a load that shouldn't fault
but still (assuming it worked) return data, that's different from a
prefetch that doesn't return anything. In one case you'd potentially
block execution, and
Nate,
So my understanding is that mem-test is on MI_example. I pulled the
repository before my changes on August 28 and ran mem-test for MI, then
applied changes one by one and I can't see the test fail. I see it fail for
MOESI, but that's because the stats are different for MOESI and MI.
I
My opinion is that a prefetch should abort on any fault it encounters.
So if a prefetch fails translation it should become a nop at that
point. I don't know how the x86 hardware table walker plays into that
though. Although it appears as though all of the flags are never
checked. Once the
My opinion is that a prefetch should abort on any fault it encounters.
So if a prefetch fails translation it should become a nop at that
point. I don't know how the x86 hardware table walker plays into that
though. Although it appears as though all of the flags are never
checked. Once the
10 matches
Mail list logo
