GLOBAL_ENTRY(kernel_execve)
+ rum IA64_PSR_AC
mov r15=__NR_execve // put syscall number in place
break __BREAK_SYSCALL
br.ret.sptk.many rp
I'm not overly happy with this because I still don't understand how
the PSR.ac bit became set in this context. This patch papers
over the problem by clearing psr.ac ... but it shouldn't be
set at this point!
As far as I can see usage of psr.ac is as follows:
1) When Linux first boots the code in head.S transitions to
virtual mode ... this code sets PSR.ac=0.
2) Eight of the code paths in ivt.S set PSR.ac=1 before
transitioning to C code. Thus interrupt handlers, page faults
and other traps are executed with .ac=1. This is controlled by the
PSR_DEFAULT_BITS define ... which is (and I think always has)
been defined to set psr.ac.
[I'm a bit puzzled as to why we want strict alignment checking
in interrupt/fault handlers, but are satisfied with more relaxed
behaivour in base code]
I'm also puzzled why this issue only just surfaced, and why I
only see it on generic kernels.
The problem may be related to some interrupt behavior. If I
tweak just the "__interrupt" code to not set psr.ac (but leave
the other seven fault handlers setting psr.ac=1) then I don't
see any unaligned traps in early init code.
-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|