Deleting build didn't seem to do anything.
Traceback (most recent call last):
File string, line 1, in module
File /z/m5/regression/zizzer/m5/src/python/importer.py, line 73, in
load_module
exec code in mod.__dict__
File /z/m5/regression/zizzer/m5/src/python/m5/__init__.py, line 38,
in
Argh. I guess different versions of python deal with this differently
too. I'll try to fix this tonight. Stupid demandimport.
Nate
Deleting build didn't seem to do anything.
Traceback (most recent call last):
File string, line 1, in module
File
It looks like it was this change which was directly after the one I
pointed out before.
changeset: 8134:b01a51ff05fa
user:Ali Saidi ali.sa...@arm.com
date:Thu Mar 17 19:20:19 2011 -0500
summary: Mem: Fix issue with dirty block being lost when entire
block transferred to
Does anyone have any ideas about when X86_SE parser stopped working? The
last time it passed for sure was the end of February, but on March 16th
Ali updated the stats and so it was presumably working then too. I'm
running at that changeset right now to confirm that. There weren't any
X86 specific
Traceback (most recent call last):
File string, line 1, in module
File /z/m5/regression/zizzer/m5/src/python/m5/main.py, line 348, in main
exec filecode in scope
File tests/run.py, line 70, in module
execfile(joinpath(tests_root, 'configs', test_filename + '.py'))
File
I had committed an error in one of the my recent patches. I have committed
a patch that should fix this error.
--
Nilay
On Sun, 20 Mar 2011, Cron Daemon wrote:
See /z/m5/regression/regress-2011-03-20-03:00:01 for details.
___
m5-dev mailing list
These failed because M5 looked for the disk image on /n/poolfs/... and
I'd only put it on /dist/... on zizzer. I copied it over so this should
work next time, hopefully, and that also means that when I explicitly
setting M5_PATH in the cron tab it actually worked.
The M5_PATH is now set to just
I think we should just use /dist. The automounter is flaky.
Ali
On Mar 13, 2011, at 5:58 PM, Gabe Black wrote:
These failed because M5 looked for the disk image on /n/poolfs/... and
I'd only put it on /dist/... on zizzer. I copied it over so this should
work next time, hopefully, and that
That makes sense. I've changed it.
Gabe
On 03/13/11 21:35, Ali Saidi wrote:
I think we should just use /dist. The automounter is flaky.
Ali
On Mar 13, 2011, at 5:58 PM, Gabe Black wrote:
These failed because M5 looked for the disk image on /n/poolfs/... and
I'd only put it on /dist/...
The problem was that the following directory belonged to root and
couldn't be deleted to rebuild from scratch. If somebody went and ran
this particular regression by hand (and as root) that could explain the
problem.
build/ALPHA_SE/tests/fast/long/60.bzip2/alpha/tru64/inorder-timing/bzip2_m5out/
On Sat, Mar 5, 2011 at 8:54 PM, Gabe Black gbl...@eecs.umich.edu wrote:
The problem was that the following directory belonged to root and
couldn't be deleted to rebuild from scratch. If somebody went and ran
this particular regression by hand (and as root) that could explain the
problem.
Korey,
It doesn't look like anything committed between when you added your regression
test and this failing could have changed the inorder stats. Could you take a
look at it?
Thanks,
Ali
On Feb 27, 2011, at 10:33 AM, Cron Daemon wrote:
*
Sorry about that folks.
Looks like I committed the regression stats from some uncommitted patches.
Should be updated now.
On Sun, Feb 27, 2011 at 1:13 PM, Ali Saidi a...@saidi.cx wrote:
Korey,
It doesn't look like anything committed between when you added your
regression test and this
These are failing because of the following:
cc1plus: warnings being treated as errors
build/SPARC_SE/cpu/o3/inst_queue_impl.hh: In member function 'void
InstructionQueueImpl::scheduleReadyInsts() [with Impl = O3CPUImpl]':
build/SPARC_SE/cpu/o3/inst_queue.cc:35: instantiated from here
14 matches
Mail list logo
