Hi Dibakar,
I recently built a Linux kernel for M5 X86_FS that was based on v2.6.28.4,
but modified and compiled specifically for M5. I have patches for my
changes, but we're still in the debugging phases of bringing up X86_FS with
multicore support, so I'm not confident enough to send them arou
Hi All,
I have few queries regarding the regression tests for X86.
(1) I could build the x86 in FS mode for AtomicSimpleCPU, O3CPU and
SimpleTimingCPU mode (I am using a bunch of x86-specific patches from
http://www.csl.cornell.edu/~vince/projects/m5/m5_x86_64_se_status.html).
I guess that the pr
I guess 1 possible way to incorporate your idea is have the Scons script
create a temporary 'progress' file in the regression output directory. That
file could get continually updated to provide your 'progress bar' so to
speak...
The next question is how would M5 communicate that? You could easily
I'm currently running all the regressions on my patches and was
thinking that it'd be nice to have a progress bar that showed how far
along each regression was. That doesn't fall out of how they're set up
at the moment, but I could imagine something like that using the number
of ticks or instru
Kevin is unavailable, so does anyone have any idea what's going on
here? It seems that we should fix this for the stable release. I
have no idea what this is supposed to be about. Korey, can one of you
look at this?
Nate
On Sun, Aug 24, 2008 at 2:09 PM, Ali Saidi <[EMAIL PROTECTED]> wrote:
>
The changeset that caused this was:
changeset: 5520:cf280b3621cf
user:Steve Reinhardt <[EMAIL PROTECTED]>
date:Sun Aug 03 18:13:29 2008 -0400
summary: Make default PhysicalMemory latency slightly more
realistic.
It must be a latent bug that was exposed when Steve changed th
> I just noticed that the smt regression fails an assertion now, but
> this was never noticed because we only run m5.fast for the regressions
> now. Anyone have time to bisect it?
More details. Gmail has been bizarre today.
We're failing an assertion in:
"ALPHA_SE/tests/fast/quick/01.hello-2T-s
We're failing an assertion in:
"ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing"
I noticed it because I ran a regression with m5.opt, but we normally
only run m5.fast for the nightly regressions.
Anyone have time to figure this out? i.e. use hg bisect and figure
out the offending
I just noticed that the smt regression fails an assertion now, but
this was never noticed because we only run m5.fast for the regressions
now. Anyone have time to bisect it?
Nate
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listin
Sure, they pass, but there are slight changes in stdout and config.ini
and stuff like that. We don't error out on a difference in stdout
(though, we should probably separate the guest's stdout and verify
that)
Nate
On Mon, Jul 21, 2008 at 7:58 PM, Ali Saidi <[EMAIL PROTECTED]> wrote:
> Ummm...
Ummm... why are their output file differences? All the regressions
have been passing just fine.
Ali
On Jul 21, 2008, at 8:12 PM, nathan binkert wrote:
> I'm running a full regression on zizzer right now and I'm going to
> commit all of the changes since there are a bunch of output file
> diffe
I'm running a full regression on zizzer right now and I'm going to
commit all of the changes since there are a bunch of output file
differences right now. Any problems with that?
Nate
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/l
I just noticed that this was in reply to that earlier email. Basically,
I've got one laptop and an ok but not spectacular internet connection
which will get substantially worse tomorrow and then non-existant a
couple days after that, so it would be a big pain for me to try to get
two different stat
If that's restricted to x86 parser I wrote an email about that earlier.
I don't know exactly what's wrong, but if you can get two machines to
pass and fail at the same time and send me a tracediff it would really
help. I don't think this is something that should hold back the release
of the reposit
It failed in the regression on zizzer 3 days ago and it passed today.
The only difference between those two repos is some different
copyright text in comments, so it I would guess initialized variable
or something?
Ali
On Jun 8, 2008, at 3:34 PM, Gabe Black wrote:
> I only have access to o
I only have access to one machine at the moment (my laptop), so if you
could find two computers where this passes and doesn't at least
semi-repeatably and tracediff them, I might be able figure this out in
the near future.
Gabe
Gabe Black wrote:
> Hopefully not. I'd say it's unlikely but I defini
Hopefully not. I'd say it's unlikely but I definitely wouldn't say it's
impossible. For that few of instructions it might be fstat or something
like that passing through some host state which changes execution in the
guest slightly. I think I had problems with parser behaving strangely
before as we
I ran a full regression of the new tree manually. The only thing that
reported a difference was x86/parser. That particular benchmarks seems
to change it stats by 20 instructions kind of frequently. There must
be some uninitialized state or something about 32bit vs 64bit compiles?
Ali
_
18 matches
Mail list logo
