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