> On 21 Oct 2016, at 18:47, James Clarke wrote: >> On 21 Oct 2016, at 18:26, David Miller wrote: >> >> From: Rob Gardner >> Date: Fri, 21 Oct 2016 09:49:30 -0600 >> >>> That could be either a stray memory write or a boot time patch gone >>> wrong. >> >> It could be that we need to use non-predicting branches in the jump >> label implementation. We could be overflowing the branch displacement >> range if the kernel being built is really huge. >> >> Something like the following would fix it if true: >> >> diff --git a/arch/sparc/kernel/jump_label.c b/arch/sparc/kernel/jump_label.c >> index 59bbeff..841d98e 100644 >> --- a/arch/sparc/kernel/jump_label.c >> +++ b/arch/sparc/kernel/jump_label.c >> @@ -19,13 +19,8 @@ void arch_jump_label_transform(struct jump_entry *entry, >> if (type == JUMP_LABEL_JMP) { >> s32 off = (s32)entry->target - (s32)entry->code; >> >> -#ifdef CONFIG_SPARC64 >> - /* ba,pt %xcc, . + (off << 2) */ >> - val = 0x10680000 | ((u32) off >> 2); >> -#else >> /* ba . + (off << 2) */ >> val = 0x10800000 | ((u32) off >> 2); >> -#endif >> } else { >> val = 0x01000000; >> } >> > > (Was top-post; moved here) > > Yes, I found that. I don't think its overflowing, more negative (hence the > 3ffffff2, which would be fffff88 or something like that for off). Trying with > that masked appropriately. If it works I'll send a patch with appropriate > BUG_ONs. This indeed was the case. The attached patch fixes the problem for me, generating 0x106ffff2, which gdb can verify is sensible (of course, the addresses have shifted slightly): (gdb) x/10xw 0x5c9880 0x5c9880: 0x400f10d0 0x01000000 0x106ffff2 0x01000000 0x5c9890: 0x106fffc8 0x01000000 0xc611a036 0x05002c36 0x5c98a0: 0x8410a038 0x8328f030 (gdb) x/i 0x5c9888 0x5c9888: b %xcc, 0x5c9850 0x5c988c: nop I also took the opportunity to correct the misleading/incorrect comments. Please let me know if you’d like this properly submitted git-send-email style. Regards, James