Bug 1295797 - The current rawhide release of glibc causes SIGILL (Illegal instruction) on ppc64le
The current rawhide release of glibc causes SIGILL (Illegal instruction) on p...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
rawhide
ppc64le Unspecified
unspecified Severity urgent
: ---
: ---
Assigned To: Florian Weimer
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F-ExcludeArch-ppc64le/PPC64LETracker
  Show dependency treegraph
 
Reported: 2016-01-05 08:40 EST by Jaromír Cápík
Modified: 2016-01-31 21:02 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-01-05 12:37:54 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jaromír Cápík 2016-01-05 08:40:27 EST
Description of problem:
The current rawhide release of glibc causes SIGILL (Illegal instruction) on ppc64le for all executables and nothing works. I tried to downgrade to glibc-2.22-6.fc23.ppc64le from a rescue system and that release works correctly. I'm testing that on a P7+ guest.

Version-Release number of selected component (if applicable):
glibc-2.22.90-25.fc24.ppc64le

How reproducible:
always
Comment 1 Florian Weimer 2016-01-05 08:58:04 EST
(In reply to Jaromír Cápík from comment #0)
> Description of problem:
> The current rawhide release of glibc causes SIGILL (Illegal instruction) on
> ppc64le for all executables and nothing works. I tried to downgrade to
> glibc-2.22-6.fc23.ppc64le from a rescue system and that release works
> correctly. I'm testing that on a P7+ guest.

Can you provide a backtrace and disassembly showing the faulty instruction?  Thanks.
Comment 2 Jaromír Cápík 2016-01-05 10:34:04 EST
I tried that on P8 and it works. Looks like P8 instructions got to the glibc somehow.
Comment 3 Florian Weimer 2016-01-05 11:58:21 EST
ld.so crashes in memset, at this instruction:

   0x000000002002d61c <+508>:	bdnz    0x2002d610 <memset+496>
   0x000000002002d620 <+512>:	cmpld   cr7,r31,r0
   0x000000002002d624 <+516>:	rldicr  r0,r0,3,60
   0x000000002002d628 <+520>:	add     r12,r12,r0
   0x000000002002d62c <+524>:	bne     cr7,0x2002d59c <memset+380>
   0x000000002002d630 <+528>:	b       0x2002d5a0 <memset+384>
   0x000000002002d634 <+532>:	mtctr   r8
=> 0x000000002002d638 <+536>:	mtvsrd  vs12,r11
   0x000000002002d63c <+540>:	li      r6,16
   0x000000002002d640 <+544>:	li      r7,32
   0x000000002002d644 <+548>:	li      r10,48
Comment 4 Carlos O'Donell 2016-01-05 12:28:17 EST
(In reply to Florian Weimer from comment #3)
> ld.so crashes in memset, at this instruction:
> 
>    0x000000002002d61c <+508>:	bdnz    0x2002d610 <memset+496>
>    0x000000002002d620 <+512>:	cmpld   cr7,r31,r0
>    0x000000002002d624 <+516>:	rldicr  r0,r0,3,60
>    0x000000002002d628 <+520>:	add     r12,r12,r0
>    0x000000002002d62c <+524>:	bne     cr7,0x2002d59c <memset+380>
>    0x000000002002d630 <+528>:	b       0x2002d5a0 <memset+384>
>    0x000000002002d634 <+532>:	mtctr   r8
> => 0x000000002002d638 <+536>:	mtvsrd  vs12,r11
>    0x000000002002d63c <+540>:	li      r6,16
>    0x000000002002d640 <+544>:	li      r7,32
>    0x000000002002d644 <+548>:	li      r10,48

That's the power8 memset.
Comment 5 Carlos O'Donell 2016-01-05 12:36:06 EST
(In reply to Carlos O'Donell from comment #4)
> (In reply to Florian Weimer from comment #3)
> > ld.so crashes in memset, at this instruction:
> > 
> >    0x000000002002d61c <+508>:	bdnz    0x2002d610 <memset+496>
> >    0x000000002002d620 <+512>:	cmpld   cr7,r31,r0
> >    0x000000002002d624 <+516>:	rldicr  r0,r0,3,60
> >    0x000000002002d628 <+520>:	add     r12,r12,r0
> >    0x000000002002d62c <+524>:	bne     cr7,0x2002d59c <memset+380>
> >    0x000000002002d630 <+528>:	b       0x2002d5a0 <memset+384>
> >    0x000000002002d634 <+532>:	mtctr   r8
> > => 0x000000002002d638 <+536>:	mtvsrd  vs12,r11
> >    0x000000002002d63c <+540>:	li      r6,16
> >    0x000000002002d640 <+544>:	li      r7,32
> >    0x000000002002d644 <+548>:	li      r10,48
> 
> That's the power8 memset.

I thought this correlated to sysdeps/powerpc/powerpc64/power8/memset.S, but I see now it doesn't quite match up.
Comment 6 Florian Weimer 2016-01-05 12:37:54 EST
With proper debugging information, I could resolve the crash site to string/memset.c:54:

50	      /* Write 8 `op_t' per iteration until less than 8 `op_t' remain.  */
51	      xlen = len / (OPSIZ * 8);
52	      while (xlen > 0)
53		{
54		  ((op_t *) dstp)[0] = cccc;
55		  ((op_t *) dstp)[1] = cccc;
56		  ((op_t *) dstp)[2] = cccc;
57		  ((op_t *) dstp)[3] = cccc;
58		  ((op_t *) dstp)[4] = cccc;

So it's GCC which creates POWER8 code.  Per

https://fedoraproject.org/wiki/Architectures/PowerPC#Supported_Architectures

this is expected; Fedora does not support POWER7 and earlier on ppc64le.
Comment 7 Carlos O'Donell 2016-01-05 12:44:36 EST
(In reply to Florian Weimer from comment #6)
> With proper debugging information, I could resolve the crash site to
> string/memset.c:54:
> 
> 50	      /* Write 8 `op_t' per iteration until less than 8 `op_t' remain.  */
> 51	      xlen = len / (OPSIZ * 8);
> 52	      while (xlen > 0)
> 53		{
> 54		  ((op_t *) dstp)[0] = cccc;
> 55		  ((op_t *) dstp)[1] = cccc;
> 56		  ((op_t *) dstp)[2] = cccc;
> 57		  ((op_t *) dstp)[3] = cccc;
> 58		  ((op_t *) dstp)[4] = cccc;
> 
> So it's GCC which creates POWER8 code.  Per
> 
> https://fedoraproject.org/wiki/Architectures/PowerPC#Supported_Architectures
> 
> this is expected; Fedora does not support POWER7 and earlier on ppc64le.

That's exactly right. I could not remember if we were still transitionally supporting POWER7, but as of October 2015 all the builders switched to POWER8 for 64-bit and after that point you have to always use POWER8 for ppc64le.

Note You need to log in before you can comment on or make changes to this bug.