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 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 > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
