I agree with you Gabe that the squashing mechanism could be cleaned up. But I'd also suggest that Nilay should understand/identify the problem first and then implement a first-pass fix without a big squashing revamp (if possible).
That way, when we (nilay, you, me, whoever) gets to revamping the squash code, there is at least a set test case and trace we can use to debug with.. On Fri, Dec 30, 2011 at 2:30 AM, Gabe Black <[email protected]> wrote: > On 12/05/11 05:24, Gabe Black wrote: > > On 12/03/11 13:02, Nilay Vaish wrote: > >> On Wed, 30 Nov 2011, Gabriel Michael Black wrote: > >> > >>> That may be the same thing that's happening with Ali's branch > >>> predictor patch. With Ruby execution changes enough to hit one of the > >>> broken squashing cases. The Ruby integration is probably working. > >>> > >>> Gabe > >>> > >>> Quoting Nilay Vaish <[email protected]>: > >>> > >>>> Gabe, when I boot FS with O3 CPU and Ruby, I get the following > >>>> output on the terminal of the simulated system. > >>>> > >>>> EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended > >>>> VFS: Mounted root (ext2 filesystem). > >>>> Freeing unused kernel memory: 232k freed > >>>> init[1]: segfault at ffffffff802095c0 rip ffffffff802095c8 rsp > >>>> 00007fff38fa81b8 error 15 > >>>> init[1]: segfault at ffffffff802095c0 rip ffffffff802095c8 rsp > >>>> 00007fff38fa81b8 error 15 > >>>> > >>>> The segfault message keeps appearing. Do you know why this might be > >>>> happening? > >>>> > >> Gabe, how can I confirm this? Is there something that I can do to > >> resolve the problem with branch prediction? > >> > >> Thanks > >> Nilay > >> _______________________________________________ > >> gem5-dev mailing list > >> [email protected] > >> http://m5sim.org/mailman/listinfo/gem5-dev > > I'm fairly confident that's what's going on. The stack address is user > > space and the instruction pointer is in kernel space. The page fault is > > from near the ip, and the error code is 15 which means, if I'm not > > mistaken, a permission problem on fetch. You can't easily fix the > > problem, but if you want to get started the first step would be to clean > > up the squashing mechanisms in O3 like I brought up in that email a > > while ago. The real problem is that squashing doesn't always preserve > > enough state (the macroop instance specifically) in all situations, and > > that the squashing stuff is too ad-hoc and all over the place to really > > fix it correctly and know that it's correct. I'd thought I fixed it > > before when I fixed one particular squash path, but obviously I didn't > > get it all. > > > > Gabe > > _______________________________________________ > > gem5-dev mailing list > > [email protected] > > http://m5sim.org/mailman/listinfo/gem5-dev > > What was unclear about this email and the ones before it? Did you not > believe me for some reason? You've spent about a month partially > rediscovering what I explained in them. I've already said how this needs > to be fixed. > > Gabe > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > -- - Korey _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
