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
