On 12/21/11 23:30, Nilay Vaish wrote: > On Mon, 5 Dec 2011, 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, the instruction pointed to by the rip is SYSRET_TO_64. The micro > code for this instrution does not contain any branch. How is it > possible for the O3 bug to show up in this case? In your example using > iret, the problem was that fetch had to re-fetch the macroop from a > kernel page after the mode has been changed. For SYSRET as well the > mode will be change. But since there is no branch prediction, how will > this particular bug manifest it self? > > Thanks > Nilay > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev
I haven't gone to look at the microcode again, but how would a system call return instruction work without branches? Gabe _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
