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):
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
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.
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.
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)
Created attachment 133189 [details]
type script from running gdb
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.
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?
On the OLPC side we really want a standard distribution that works on the
hardware, which means fixing our software to support the Geode.
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?
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.
So maybe we just say "it's i586"? Where does that happen?
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.
(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.
disregard comment #12, David answered correctly.
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
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.
http://sourceware.org/ml/binutils/2006-07/msg00360.html should fix it. I'm
building binutils-18.104.22.168.3-2 with it.
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?
I think that we only stumbled across the kernel, glibc and openssl. But David
would know more. We'll do some testing today.
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
Do you have a pointer to those performance numbers?
New binutils fixed this. Closing this bug. Thanks!
*** Bug 199897 has been marked as a duplicate of this bug. ***