* build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-atomic passed.
* build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-timing passed.
*
build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic
passed.
*
Nope, it wasn't me. It was changeset f28f020f3006, syscalls: fix latent
brk/obreak bug.
Gabe
Gabe Black wrote:
Unless it's the second change where I refactored my code. That's during
the time with the assertion bug.
Gabe
Gabe Black wrote:
I don't think this is me, actually. I ran it
I just confirmed that
SPARC_SE/tests/opt/long/70.twolf/sparc/linux/simple-timing includes a
brk() call that tries to shrink the heap, which with the old
obreakFunc() triggers the ChunkGenerator assertion I added.
It turns out that in the old broken code if the previous break val was
at a page
changeset c5447915af50 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=c5447915af50
description:
Update stats for brk fix (cset f28f020f3006).
diffstat:
2 files changed, 3 insertions(+), 8 deletions(-)
tests/long/70.twolf/ref/sparc/linux/simple-timing/m5stats.txt |
changeset 54cb03a1a577 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=54cb03a1a577
description:
Minor tracediff bug fixes.
diffstat:
1 file changed, 1 insertion(+), 1 deletion(-)
util/tracediff |2 +-
diffs (25 lines):
diff -r c5447915af50 -r 54cb03a1a577
Ah, so that was you. That makes sense. I seriously wonder if this or
something like it is the problem with 20.parser.
Nate
On Mon, Nov 17, 2008 at 11:11 AM, Steve Reinhardt [EMAIL PROTECTED] wrote:
changeset c5447915af50 in /z/repo/m5
details:
I sort of doubt it... parser has always been a bit nondeterministic,
where this is just a subtle and unforeseen but deterministic side
effect of a bug fix.
Steve
On Mon, Nov 17, 2008 at 11:57 AM, nathan binkert [EMAIL PROTECTED] wrote:
Ah, so that was you. That makes sense. I seriously wonder
I more meant that it seems like an infrequently used syscall that uses
an uninitilaized variable that affects the return value could easily
be the result. The stats differences in both simulations are minimal
and similar.
Nate
On Mon, Nov 17, 2008 at 12:07 PM, Steve Reinhardt [EMAIL
The biggest problem is that I've never been able to find two machines
that behave differently. When things change, I can't find something
that did it the old way.
Nate
If somebody can and wants to get a tracediff between two differently behaving
versions of parser, that would go a long way
Exactly. Or one machine will be in Ann Arbor and the other in California. Maybe
it has something to do with the test checking the actual clock time/date on the
host somehow? It could behave slightly differently depending on some little part
of that like converting it to seconds changing the path
Interestingly, I just ran on my desktop here and on zizzer and both
failed, but when I looked more closely, I see that my desktop is
failing because it's running 5 fewer instructions than the reference
output, while zizzer is failing because it's running 5 extra
instructions. (And yes, I
Yes, I'm sure it's not a timing mode thing. The timing mode regressions didn't
exist for x86 until very recently, and parser has been unstable for maybe as
long as a year.
Gabe
Quoting Steve Reinhardt [EMAIL PROTECTED]:
Interestingly, I just ran on my desktop here and on zizzer and both
12 matches
Mail list logo
