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
![]() |