Hi Laura,

  Would it be possible capture the exact assembler command line that it being used ?  I am trying to reproduce the problem locally, but so far I have had no luck.  Also if you could upload the preprocessed version of the swsup_asm64.S source file that would help a great deal too.

Cheers
  Nick

Created attachment 1078745 [details]
error log with full commands

make V=1 ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- &> errlog.txt

Created attachment 1078748 [details]
preproccesed file

make V=1 ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- arch/powerpc/kernel/swsusp_asm64.s

For reference, I think this is what the tlbia expands into

 li %r4,1024; mtctr %r4; lis %r4,0xc000000000000000@h; 0: tlbie %r4; addi %r4,%r4,0x1000; bdnz 0b

Hi Laura,

  Thanks for those files.  Unfortunately I still cannot reproduce the problem.  I have tried using the binutils and cross-binutils packages, using the F22, F23 and rawhide versions, and they all work. :-(  My best guess now is that it is connected to the cross-gcc that you are using (powerpc64-linux-gnu-gcc).  This invokes the assembler on the preprocessed file, and maybe, just maybe, it is using the wrong set of command line options to do so.  I did try running the gcc command locally, using my own version of powerpc64-linux-gnu-gcc built from the mainline gcc sources, but this failed.  (As in, it worked, it executed the assembler and the assembler created the object file without any warnings).

  Either that, or the cross-binutils that you are using has been configured with a different set of patches to the one that I am using.

  Would it be possible for you to point me at the powerpc64-linux-gnu-as executable that you are using (or upload it here), so that I can try running it myself ?

Cheers
  Nick

The original issue was reproducible without cross compilation. the log file I linked from the koji build was compiling on powerpc64le natively http://ppc.koji.fedoraproject.org/koji/getfile?taskID=2772584&name=build.log&offset=-4000  and http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2772584 . I'll give you the files from my local machine and see if I can get the files from the build machine as well.

Created attachment 1079213 [details]
cross gcc from local machine

Created attachment 1079214 [details]
cross as from local machine

pbrobinson pointed out you can grab see what was installed from the log http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2772584, http://ppc.koji.fedoraproject.org/kojifiles/work/tasks/2584/2772584/root.log

http://ppc.koji.fedoraproject.org/koji/buildinfo?buildID=343648
http://ppc.koji.fedoraproject.org/koji/buildinfo?buildID=326293

Hi Laura,

  Thanks very much for those executables.  With them I was able to reproduce the problem, and find out why I could not reproduce it before.  The powerpc64-linux-gnu-gcc that you are using is set up to produce Power7 binaries by default.  The version that I was using was not.

  This also explains the problem.  The TLBIE instruction needs *two* operands if it is being assembled for the Power7 architecture.  Hence the assembler is correct in issuing its error message.  It looks to me as if the translation from the TLBIA pseudo-instruction to the assembler sequence containing the TLBIE instruction is broken.  (Or rather, the sequence works for most PPC architectures, just not the Power7).

  Do you know where this translation from TLBIA to TLBIE happens ?  In a header file perhaps ?  Wherever it is, I think that it needs to be fixed.

  The reason that this problem has only come to light now is that code to check the number of operands to the TLBIE instruction (for Power7) was only recently added:

  https://sourceware.org/ml/binutils/2015-05/msg00133.html

Cheers
  Nick

Thanks for the analysis, you are spot on. I found the offending sequence in one of the header files:


#if !defined(CONFIG_4xx) && !defined(CONFIG_8xx)
#define tlbia                                   \
        li      r4,1024;                        \
        mtctr   r4;                             \
        lis     r4,KERNELBASE@h;                \
0:      tlbie   r4;                             \
        addi    r4,r4,0x1000;                   \
        bdnz    0b
#endif 


which does indeed need to be updated. I sent a message to the powerpc maintainers upstream. Hopefully they will get back to me soon.

As an update, there is an ongoing thread but apparently someone wants to re-factor the code. No response on anyone doing the refactoring https://lkml.org/lkml/2015/10/2/494

The discussion upstream hasn't come to any conclusion yet. Given this is preventing compilation on rawhide, I'm going to push a patch to disable hibernation in rawhide after discussions with Josh.

I pushed a fix to disable hibernation. I'm marking this as closed. This bug can be re-evaluated if someone wants hibernation.