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:
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
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) Thanks, David
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 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.
http://sourceware.org/ml/binutils/2006-07/msg00360.html should fix it. I'm building binutils-2.17.50.0.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 compile.
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. ***