scons: *** [build/POWER_SE/kern/linux/linux.fo] Error 1
scons: *** [build/POWER_SE/arch/power/insts/branch.fo] Error 1
scons: *** [build/POWER_SE/arch/power/insts/mem.fo] Error 1
scons: *** [build/POWER_SE/arch/power/insts/integer.fo] Error 1
scons: ***
Hi All,
I'm still having a bit of trouble running Ruby with 32+ cores. I am
experimenting w/configs varying the l2-caches. The runs seems to
generate various errors in the SLICC.
Has anybody seen these or have any insight to how to start solving
these type of issues (posted below)?
=
The
Hi Korey,
I believe both of these issues should be easy to solve once we have a protocol
trace leading up to the error. If you could create such a trace and send it to
the list, that would be great. Just zero in on the offending address.
Thanks,
Brad
-Original Message-
From:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/610/#review1025
---
Why do you need this functionality? Why isn't :: sufficient? If it's
On 2011-03-29 09:05:00, Gabe Black wrote:
src/base/statistics.hh, line 265
http://reviews.m5sim.org/r/610/diff/1/?file=11256#file11256line265
The bracket should be on the next line for functions, and should have a
space before it if it were to go on that line.
brad danofsky
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/529/#review1029
---
I agree with the sentiment of this change, but I think you moved too
changeset 6ae58f06a41c in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=6ae58f06a41c
description:
Power: Fix compilation.
diffstat:
src/arch/power/types.hh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diffs (11 lines):
diff -r a8d64545cda6 -r 6ae58f06a41c
Compilation of POWER was broken by this change when the closing bracket
for a namespace was removed:
changeset: 8181:f789b9aac5f4
user:Korey Sewell ksew...@umich.edu
date:Sat Mar 26 09:23:52 2011 -0400
summary: mips: cleanup ISA-specific code
Compilation was unavoidably
Good point about regression carefulness Gabe.
Although I'm pretty sure I compiled MIPS before I committed this, I
had forgot I touched other ISAs and obviously broke one of them.
That's just an error on my part.
This brings up a few issues:
- Should the regressions be more resilient? In other
Thanks for the response Brad.
The 1st trace has 1 L2 and the 2nd has 1 L2 (i had a typo in the
original email).
For each trace, I attach the stdout/stderr (*.out) and then the
protocol trace (*.prottrace).
Also, in the 1st trace, the offending address is clear and I isolate
that in the protocol
On Tue, Mar 29, 2011 at 10:34 AM, Korey Sewell ksew...@umich.edu wrote:
Good point about regression carefulness Gabe.
Although I'm pretty sure I compiled MIPS before I committed this, I
had forgot I touched other ISAs and obviously broke one of them.
That's just an error on my part.
This
On 03/29/11 13:34, Korey Sewell wrote:
Good point about regression carefulness Gabe.
Although I'm pretty sure I compiled MIPS before I committed this, I
had forgot I touched other ISAs and obviously broke one of them.
That's just an error on my part.
Yeah, I didn't want to pick on you,
On Tue, Mar 29, 2011 at 10:54 AM, Gabe Black gbl...@eecs.umich.edu wrote:
That makes sense and was what I was hoping we could use m5-stable for,
but we didn't end up doing that because we wanted m5-stable to be even
more stable than that (although it tends to just be old, not necessarily
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/611/
---
Review request for Default.
Summary
---
Ruby: Add support for functional
Brad, I have posted on the review board my current implementation for
supporting functional accesses in Ruby. This is untested and is mainly
meant for furthering the discussions. I have some questions for you --
1. How do we inform the other end of RubyPort's M5 Port about whether or
not
On 2011-03-29 09:05:00, Gabe Black wrote:
Why do you need this functionality? Why isn't :: sufficient? If it's
because some other piece of software is expecting something else, I'd say
either write a script that munges these stats into a more acceptable
format, or adjust the other
On 2011-03-29 09:05:00, Gabe Black wrote:
Why do you need this functionality? Why isn't :: sufficient? If it's
because some other piece of software is expecting something else, I'd say
either write a script that munges these stats into a more acceptable
format, or adjust the other
I'd prefer to see us just start updating m5-stable more regularly so
it can fulfill its original purpose. We keep discussing this but
never actually follow through.
Is this any harder than just setting up a cronjob to push whatever is
in m5-dev to m5-stable once per month (?)
- Korey
changeset d54b7775a6b0 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=d54b7775a6b0
description:
sim: typecast Tick to UTick for eventQ assert
diffstat:
src/sim/eventq.hh | 6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diffs (23 lines):
diff -r
You could do that, but there is no guarentee you'd pick a non-broken version to
push. We wouldn't want to push anything from the last week with all the
compilation issues.
Ali
On Mar 29, 2011, at 6:19 PM, Korey Sewell wrote:
I'd prefer to see us just start updating m5-stable more regularly
20 matches
Mail list logo
