Somehow this didn't get sent ... found it in the "Drafts" folder. But it's rubbish, skip to the bottom.
On Thu, Dec 31, 2015 at 12:30 PM, Tony Luck <tony.l...@gmail.com> wrote: > I switched to BIAS 0xC0000000 ... and now I should get class 1 entries > (bit31=0, bit30=1). > > New patch series coming soon. Or not :-( arch/x86/lib/lib.a(memcpy_64.o):(__ex_table+0x4): relocation truncated to fit: R_X86_64_PC32 against `.fixup' arch/x86/lib/lib.a(memcpy_64.o):(__ex_table+0xc): relocation truncated to fit: R_X86_64_PC32 against `.fixup' ... I guess it was something like this that made you do the 0x20000000 and subtract the BIAS? I have a bad feeling that we may not really have four classes, just three: 00: no funny arithmetic 10: BIAS = 0x80000000 ... doesn't trigger truncation warning because sign bit is set 11: BIAS = 0x40000000 ... ditto 01: BIAS = ? ... Is there some magic value for BIAS that gets this? --- end of Draft ... now to the real bit Not sure why I was hung up on *subtracting* values to get the desired class bits. Just blindly copying the initial case from your patch? If you can't get from A to B one way, try going around the other direction. Subtracting 0xC0000000 is the same as adding 0x40000000 (when playing with u32 values). That doesn't upset the linker. I rebased: git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git mcsafev6 still needs a little cleanup, but it all works, and seems to be a much cleaner approach. So clean that I wonder whether I really need the CONFIG_MCE_KERNEL_RECOVERY any more?? The only place it is used now is around the __mcsafe_copy() -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/