> I just tried an x86_64 build with a module also modified to access > softirq_work_list. It did NOT get a CRC error. So the x86_64 > toolchain doesn't seem to have the same issue as ia64. Ok. x86 doesn't see this because the defconfig has CONFIG_MODVERSIONS is not set If I turn MODVERSION off, then the problem disappears for me. If I turn MODVERSIONS on for x86 (and fudge a driver to make use of softirq_work_list), then x86 gets the CRC warning too. So this isn't a tool chain problem. Neither x86 nor ia64 can handle exported per-cpu array objects when CONFIG_MODVERSIONS is set. Looking at the __crc symbols in the vmlinux for x86 with CONFIG_MODVERSIONS=y I see: 000000006dcaeb88 A __crc_per_cpu__kernel_stack 00000000b3994c7a A __crc_per_cpu__kstat 00000000d917c158 A __crc_per_cpu__node_number w __crc_per_cpu__softirq_work_list 0000000036a1f502 A __crc_per_cpu__softnet_data 0000000057adf756 A __crc_per_cpu__this_cpu_off which explains why "modpost" is unable to find a CRC. Maybe the comments in <linux/module.h> are supposed to be a clue? : #ifdef CONFIG_MODVERSIONS /* Mark the CRC weak since genksyms apparently decides not to * generate a checksums for some symbols */ #define __CRC_SYMBOL(sym, sec) \ extern void *__crc_##sym __attribute__((weak)); \ static const unsigned long __kcrctab_##sym \ __used \ __attribute__((section("__kcrctab" sec), unused)) \ = (unsigned long) &__crc_##sym; But not enough of a clue for me :-( -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html