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 for each changeset starting
> from right before my timing simple CPU changes, and it's worked each
> time up until that assertion bug from Steve. That wasn't fixed until
> just recently, I think, so finding where it starts failing beyond that
> might be annoying. I won't be working on it any more tonight, but if I
> get a chance over the next week I'll see if I can figure it out.
>
> Gabe
>
> Gabe Black wrote:
>   
>> I just ran it myself, and the number of instructions is exactly the same
>> so it's probably not anything like a syscall where it would change the
>> path of execution. It's probably because my change to the the CPU caused
>> the timing of some corner case to change slightly, hopefully not because
>> of a memory error although I wouldn't rule it out. Fortunately it seems
>> to be a reproducible failure, which is surprising since I ran
>> regressions more than once, so it'll hopefully be easy to pin down.
>>
>> Gabe
>>
>> nathan binkert wrote:
>>   
>>     
>>> Though the fact that a TimingSimpleCPU test failed is a bit suspicious
>>> since it didn't in the past and you just modified it.
>>>
>>>  Nate
>>>
>>> On Sun, Nov 16, 2008 at 8:45 PM, nathan binkert <[EMAIL PROTECTED]> wrote:
>>>   
>>>     
>>>       
>>>> My guess is that it's an uninitialized variable.  My further guess is
>>>> that it's related to some specific system call since it only happens
>>>> in SE mode.
>>>>
>>>>  Nate
>>>>
>>>> On Sun, Nov 16, 2008 at 8:29 PM, Gabe Black <[EMAIL PROTECTED]> wrote:
>>>>     
>>>>       
>>>>         
>>>>> parser seems to have a long standing and hard to identify problem where
>>>>> it changes a little bit every now and then for no apparent reason. I'm
>>>>> not sure what would be the problem with SPARC. Did the disk image change
>>>>> recently? Which one does that regression use?
>>>>>
>>>>> Gabe
>>>>>
>>>>> nathan binkert wrote:
>>>>>       
>>>>>         
>>>>>           
>>>>>> That's odd.  I just ran it and it worked fine.  The ones  I just had 
>>>>>> fail are:
>>>>>> SPARC_SE/tests/opt/long/70.twolf/sparc/linux/simple-timing
>>>>>> X86_SE/tests/opt/long/20.parser/x86/linux/simple-timing
>>>>>>
>>>>>> They differ in about the same way from the base stats.
>>>>>>
>>>>>> Are you sure you have the right disk image?
>>>>>>
>>>>>>   Nate
>>>>>>
>>>>>> On Sun, Nov 16, 2008 at 8:17 PM, Gabe Black <[EMAIL PROTECTED]> wrote:
>>>>>>
>>>>>>         
>>>>>>           
>>>>>>             
>>>>>>>    I've significantly reworked the ide controller device, and while
>>>>>>> running the regressions to test it out I noticed that
>>>>>>> build/ALPHA_FS/tests/opt/long/10.linux-boot/alpha/linux/tsunami-o3/ is
>>>>>>> failing even in the head. I tried it out with a slightly older version
>>>>>>> of the head, updated and tried it out with my changes in place, and now
>>>>>>> I'm trying out just a clean and up to head, but it seems to consistently
>>>>>>> fail with slightly different stats in the o3. Is this something that the
>>>>>>> o3 serialization/unserialization changes would have done?
>>>>>>>
>>>>>>> Gabe
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>
>>>>>
>>>>>       
>>>>>         
>>>>>           
>>> _______________________________________________
>>> 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
>   

_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Reply via email to