> this i believe builds an implicit dependency between the mca_asm.o > position within the image and the ia64_mca_data percpu variable it > accesses - it relies on the immediate 22 addressing mode that has 4MB of > scope. Per chance, the .config you sent creates a 14MB image, and the > percpu variables moved too far away for the linker to be able to fulfill > this constraint.
Sounds very plausible. > The workaround is to define PER_CPU_ATTRIBUTES to link percpu variables > back into the .percpu section on UP too - which ia64 links specially > into its vmlinux.lds. But ultimately i think the better solution would > be to remove this dependency between arch/ia64/kernel/mca_asm.S and the > position of the percpu data. Yup. That fixes the build ... the resulting binary doesn't boot though :-( I just realized that it has been a while since I tried booting a UP kernel ... so the problem may be unrelated bitrot elsewhere. Overall you are right that the mca_asm.S code should not be dependent on the relative location of the data objects. I'll start digging on why this doesn't boot ... but you might as well send the fixes so far upstream to Linus so that the SMP fix is available (which is all anyone really cares about ... there are very, very few UP ia64 systems in existence). Acked-by: Tony Luck <[EMAIL PROTECTED]> -Tony - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
