When I built 4.3.0-7-generic on arm64(mustang) Wily with the following steps,

         fakeroot debian/rules clean
         fakeroot debian/rules binary-generic

by this compiler:

ubuntu@ubuntu:~$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/5/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.2.1-22ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++
--prefix=/usr --program-suffix=-5 --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --libdir=/usr/lib
--enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-libquadmath --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-arm64/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-arm64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-arm64
--with-arch-directory=aarch64
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-multiarch
--disable-werror --enable-checking=release --build=aarch64-linux-gnu
--host=aarch64-linux-gnu --target=aarch64-linux-gnu


the built image just works well:

      ubuntu@ubuntu:~$ uname -a
      Linux ubuntu 4.3.0-7-generic #18 SMP Tue Jan 12 10:19:24 EST 2016
      aarch64 aarch64 aarch64 GNU/Linux


But I can see the issue when booting a kernel from the following package[1]:

         http://launchpadlibrarian.net/230287220/linux-image-4.3.0-5-generic_4.3.0-5.16_arm64.deb

It is a build environment issue instead of kernel issue, please see
comments from Ard Biesheuvel <email address hidden> [2]:

        RELA #275 is the relocation against ADRP instructions, which GCC
        should not emit anymore when -mcmodel=large is in effect.

        Can you confirm that the modules have been rebuilt with this config as
        well? Can you double check the GCC command line (with V=1) when doing
        'make modules' to ensure that '-mcmodel=large' is being passed? Can
        you check with 'readelf -r' which objects still contain
        R_AARCH64_ADR_PREL_PG_HI21 relocations?

I have checked the gcc flag in my building environment, and '-mcmodel=large' is
passed, and CONFIG_ARM64_ERRATUM_843419 is enabled too.

I don't know how the image in [1] is built, so could anyone check the build
environment for this building?


[1] http://launchpadlibrarian.net/230287220/linux-image-4.3.0-5-generic_4.3.0-5.16_arm64.deb
[2] http://www.spinics.net/lists/arm-kernel/msg449991.html


On Tue, Jan 12, 2016 at 7:47 PM, Raghuram Kota
<email address hidden> wrote:
> ** Tags added: hs-arm64
>
> --
> You received this bug notification because you are subscribed to linux
> in Ubuntu.
> https://bugs.launchpad.net/bugs/1533009
>
> Title:
>   arm64: "unsupported RELA relocation"
>
> Status in linux package in Ubuntu:
>   Confirmed
>
> Bug description:
>   linux-image-4.3.0-5-generic 4.3.0-5.16 arm64 fails to load modules
>   (and therefore boot). It emits messages like the following for each
>   attempted module load:
>
>   [    2.156817] module libahci: unsupported RELA relocation: 275
>
>   This is reminiscent of LP: #1502946 - except that fix appears to still
>   be in-tact. What has changed, however, is the build environment. If I
>   rebuild the same kernel source in a wily chroot, it boots fine.
>
>   Marking "Confirmed" because Paulo Pisatti reported this to me, and I
>   reproduced.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533009/+subscriptions