Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1295797
| Summary: | The current rawhide release of glibc causes SIGILL (Illegal instruction) on ppc64le | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jaromír Cápík <jcapik> |
| Component: | glibc | Assignee: | Florian Weimer <fweimer> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | arjun.is, codonell, fweimer, jakub, law, mfabian, ovasik, pfrankli, siddhesh |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | ppc64le | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-01-05 17:37:54 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1051573 | ||
|
Description
Jaromír Cápík
2016-01-05 13:40:27 UTC
(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. I tried that on P8 and it works. Looks like P8 instructions got to the glibc somehow. 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 (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. (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. 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.
(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. |