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.luck@xxxxxxxxx> 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, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>