This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 200330 - i686 openssl broken on AMD Geode
i686 openssl broken on AMD Geode
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: binutils (Show other bugs)
rawhide
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
:
: 199897 (view as bug list)
Depends On:
Blocks: FC6Target FC6Blocker OLPCBlocker OLPCTracker
  Show dependency treegraph
 
Reported: 2006-07-26 17:12 EDT by David Zeuthen
Modified: 2013-03-05 22:46 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-01 19:32:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
type script from running gdb (2.22 KB, text/plain)
2006-07-27 15:22 EDT, David Zeuthen
no flags Details

  None (edit)
Description David Zeuthen 2006-07-26 17:12:12 EDT
Description of problem:

For OLPC, the i686 version of openssl is broken. When starting sshd for the
first time, key-generation fails with "Illegal Instruction". Running yum just
"segfaults". Replacing the openssl i686 package with the i386 package cures this. 

Version-Release number of selected component (if applicable):

openssl-0.9.8b-4

How reproducible:

Always. I build images fairly frequently, this wasn't an issue 1-2 weeks ago.
Maybe it's a binutils issue?

Steps to Reproduce:
1. Install OLPC images or Rawhide on the AMD Geode
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 David Zeuthen 2006-07-27 11:12:37 EDT
Jakub, do you know if this is related to some recent binutils i686 change that
breaks the AMD geode? Also cf. bug 200409 it looks like the i686 kernel is
acting up too.

Thanks,
David 
Comment 2 Alexandre Oliva 2006-07-27 14:39:32 EDT
We'll need to know the exact instruction at the point of failure to tell more. 
I suspect it's just some i686 instruction that is missing on the Geode.  I found
Gentoo build instructions that recommend against i686 compile flags for Geode,
so it looks like it is indeed missing some instructions.
Comment 3 David Zeuthen 2006-07-27 15:06:46 EDT
OK, ran this through gdb

# gdb /usr/bin/key-gen
..
(gdb) run -q -t rsa1 -f /root/keyout -C '' -N ''

Program received SIGILL, Illegal Instruction
0x00200f3d in CRYPTO_mem_ctrl (mode=3) at mem_dbg.c:162
162             switch (mode)

Do you need more info? (I'm no expert at using gdb)

Thanks,
David
Comment 4 David Zeuthen 2006-07-27 15:22:49 EDT
Created attachment 133189 [details]
type script from running gdb
Comment 5 Alexandre Oliva 2006-07-27 16:03:52 EDT
Thanks.  The problem is that this source file uses some i686-specific
instructions, that Geode happens to support, but this has the side effect of
enabling some newly-introduced code in gas that uses memory nop instructions for
code alignment padding, that Geode does not support.
Comment 6 Alexandre Oliva 2006-07-27 16:56:59 EDT
Geode GX's CPUID has Family ID 5, but according to the ISA specification, these
nops are only available on Families 6 and F.

We now have to decide whether to disable the selection of these nops for some
(or all?) cpus, or realize that Geode GX is not an i686, so we shouldn't use
i686 packages on it.

With the current assembler, it's tricky to get it to not emit such nops if it
sees any i686 instructions whatsoever, but patching it shouldn't be too hard to
avoid such nops on i686 by default, possibly enabling them for other processors.
 It's not my decision, though.

Which way should we go?
Comment 7 Christopher Blizzard 2006-07-27 17:21:31 EDT
On the OLPC side we really want a standard distribution that works on the
hardware, which means fixing our software to support the Geode.
Comment 8 Christopher Blizzard 2006-07-27 17:22:59 EDT
Also, do we now assume that the world is i686?  I seem to remember someone
saying that.  i.e. how long will we have i386 packages for?
Comment 9 Jordan Crouse 2006-07-27 17:29:11 EDT
I personally like the idea of hacking GAS to avoiding the NOPs, but this
demonstrates the dangers of using i686 packages on a i586 platform - we might as
well not keep tempting fate.

In our benchmarking tests using the EEMBC benchmark, -march=i686 scored the
highest, but -march=k6-2 was only about .25% behind.  I don't think that k6-2
suffers from the same opcode worries, so I submit that would be a reasonable
alternative that doesn't involve causing much damage to the binutils team.
Comment 10 Christopher Blizzard 2006-07-27 17:30:04 EDT
So maybe we just say "it's i586"?  Where does that happen?
Comment 11 David Zeuthen 2006-07-27 17:36:15 EDT
Another point is users out there might want to install Fedora Core on AMD Geode
hardware other than OLPC. I think our anaconda installer gets it right though
and selects i586 packages instead (of course for Fedora Core this means i386
versions of openssl and glibc). However, it would be nice if we could just use
the i686 packages, but by and large I agree with comment 9.

Btw, it shouldn't be a problem providing OLPC specific versions of glibc,
openssl and the kernel; in fact we want to do that for the latter for other
reasons. It's just more work the OLPC team when doing e.g. security errata since
we need a rebuild for the OLPC collection.

Re comment #10, there are no i586 versions of openssl nor glibc. Of course we
could request such.
Comment 12 Jesse Keating 2006-07-27 17:38:32 EDT
(In reply to comment #10)
> So maybe we just say "it's i586"?  Where does that happen?

Usually that happens at install time by passing an option to the installer, if
anaconda doesn't figure it out for itself.  Geode is promoting itself as a 686
when it may not be.

IN OLPC case, we may have to fiddle with yum a bit to make it think the basearch
is i568 when we gather packages.
Comment 13 Jesse Keating 2006-07-27 17:40:15 EDT
disregard comment #12, David answered correctly.
Comment 14 Christopher Blizzard 2006-07-28 11:54:48 EDT
I think that Jordan's message (comment #9) is probably the best description.  It
doesn't support the full i686 instruction set so we can't consider it to be a
686 platform.

Ulrich says that the only thing that we need to worry about is support for NTPL.
 The i386 versions don't support it.  He suggests maybe building glibc for i486.
 The AMD variants might emit the instruction, but that's never been tested. 
Right now we only build an i386 and i686 variant.  And we do want NTPL support.

We're going to have our own olpc-kernel package at some point here, so we can
pick our arch then.  It's just a question of getting something that's well
supported.  Don't know about the state of i486 vs. the AMD instruction set.
Comment 15 Alexandre Oliva 2006-07-28 19:17:01 EDT
http://sourceware.org/ml/binutils/2006-07/msg00360.html should fix it.  I'm
building binutils-2.17.50.0.3-2 with it.
Comment 16 Alexandre Oliva 2006-07-28 23:15:26 EDT
And now openssl is rebuilt as well, and a kernel build fired by davej is
underway.  glibc was not rebuilt after the binutils patch so it should be fine.
 Are we all set, or are there any other i686 packages that need rebuilding?
Comment 17 Christopher Blizzard 2006-07-31 09:04:21 EDT
I think that we only stumbled across the kernel, glibc and openssl.  But David
would know more.  We'll do some testing today.
Comment 18 Need Real Name 2006-08-01 09:53:48 EDT
please note that in performance testing with the Geode GX a number of the
sysdeps/i386/i586 implementations are substantially slower on the GX (as much as
5x).  Thus a glibc compilation targeting i586 will be worse than a 386 or 486
compile.
Comment 19 Christopher Blizzard 2006-08-01 10:00:38 EDT
Do you have a pointer to those performance numbers?
Comment 20 David Zeuthen 2006-08-01 19:32:06 EDT
New binutils fixed this. Closing this bug. Thanks!
Comment 21 Jakub Jelinek 2006-08-03 05:36:15 EDT
*** Bug 199897 has been marked as a duplicate of this bug. ***

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