I have seen those same Valgrind errors as well and I've tried to fix them with
little success. When I looked into the problem, it appeared to me that
Valgrind thought the misc reg space was not initialized, but I thought it was
when I stepped through tlb initialization using the debugger. I don't
understand the M5 cpu models very well, so I could be completely wrong on
exactly what the problem is. Below is a small patch I have that simply
identifies the specific place where Valgrind thinks the error occurs. The
comment includes a little more detail on the specific registers involved.
I hope this helps,
Brad
From: Brad Beckmann <brad.beckm...@amd.com>
m5: Flags a possible memory bug in the Alpha TLB
diff --git a/src/arch/alpha/tlb.cc b/src/arch/alpha/tlb.cc
--- a/src/arch/alpha/tlb.cc
+++ b/src/arch/alpha/tlb.cc
@@ -445,6 +445,12 @@
{
Addr pc = tc->readPC();
+ //
+ // Possible fix me! Valgrind sometimes flags this read of a misc. reg.
+ // as uninitialized value read even though the misc reg spaces seems to be
+ // initialized correctly. Specifically MaxInternalProcRegs=536 and
+ // NumInternalProcRegs=74 and IPR_DTB_CM=58, yet an error is flagged
+ //
mode_type mode =
(mode_type)DTB_CM_CM(tc->readMiscRegNoEffect(IPR_DTB_CM));
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of
Korey Sewell
Sent: Tuesday, March 30, 2010 7:41 PM
To: M5 Developer List
Subject: Re: [m5-dev] Cron <m5t...@zizzer> /z/m5/regression/do-regression
--scratch all
I ran this through valgrind and it looks like in ALPHA_SE there may be some
uninitialized values that weren't affecting the simulation output but affecting
timing somewhat (specifically with the TLB translations).
In the next go round of this, I should be able to track that down and verify
what the correct timing should be. That should settle any "non-determinism"
issues but as for any host-state issues I'm hoping I can knock out two birds
w/one stone here!
On Tue, Mar 30, 2010 at 10:16 PM, Gabe Black
<gbl...@eecs.umich.edu<mailto:gbl...@eecs.umich.edu>> wrote:
Those are good questions to answer because they point either to
non-determinism in the CPU or host state leaking into the simulation.
Another thing people suggested way back when when I was trying to fix
something similar was to use netcat with tracediff to compare execution
across two known different machines. For a long benchmark I'd suggest
finding something to keep you occupied while it runs, maybe a quick trip
to Europe for instance, but eventually it might tell you what's going on.
Gabe
Steve Reinhardt wrote:
> Actually they are run weekly, not monthly, though if something goes
> wrong with a run you can miss a week or two.
>
> And yes, if it's not giving consistent results on your machine vs.
> zizzer then that's a problem. Is it consistent on each machine?
> (I.e., your machine is consistent, and zizzer is consistent, but
> they're different?)
>
> If zizzer seems slow, do a 'top' and see what's running... unless
> you're trying to use it while it's running a regression, it should be
> very fast.
>
> Steve
>
> On Sun, Mar 28, 2010 at 9:35 PM, Korey Sewell
> <ksew...@umich.edu<mailto:ksew...@umich.edu>> wrote:
>
>>> haven't we been having problems with inorder-timing for a while?
>>>
>> I didnt notice that the test was failing for awhile since the tests only run
>> once-a-month on the weekend, and as Gabe noted, whether something fails or
>> not gets lost in the avalanche of messages there.
>>
>> So yea, they've been hitting for the past month, but I realized that they
>> were off only recently (thanks to Gabe/Steve's emails).
>>
>> I've kind of desensitized myself to the Cron messages so it's just my fault
>> for not taking more notice when the inorder stuff fails. The actual problem
>> (at least for twolf) was pretty simple (a 2 line fix).
>>
>> --
>> - Korey
>>
>> _______________________________________________
>> m5-dev mailing list
>> m5-dev@m5sim.org<mailto:m5-dev@m5sim.org>
>> http://m5sim.org/mailman/listinfo/m5-dev
>>
>>
>>
> _______________________________________________
> m5-dev mailing list
> m5-dev@m5sim.org<mailto:m5-dev@m5sim.org>
> http://m5sim.org/mailman/listinfo/m5-dev
>
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org<mailto:m5-dev@m5sim.org>
http://m5sim.org/mailman/listinfo/m5-dev
--
- Korey
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
