Hey folks,
I'm at a conference this weekend and I haven't been able to get to
consistent alpha_se/inorder-timing/twolf regressions just yet. If I
can, I'll carve out some time to knock it out during some break time,
but if not, my full attention to the fix will be this coming Monday
(it will get my 1st priority that day).
Sorry for the continued delay folks.
-Korey
On Wed, Mar 31, 2010 at 1:49 PM, Beckmann, Brad <brad.beckm...@amd.com> wrote:
> 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> 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> 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
>>> http://m5sim.org/mailman/listinfo/m5-dev
>>>
>>>
>>>
>> _______________________________________________
>> m5-dev mailing list
>> m5-dev@m5sim.org
>> http://m5sim.org/mailman/listinfo/m5-dev
>>
>
> _______________________________________________
> m5-dev mailing list
> 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
>
>
--
- Korey
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
