On Wed, 2005-10-05 at 12:29, Jürgen Keil wrote:
> I bfu'ed an old Pentium-II box (was running snv_22, bfu'ed to build 23).
>
> The box doesn't boot any more, it loops with
>
> WARNING: init(1M) exited on fatal signal 9, ....
>
>
> Booting the snv_22 kernel from the failsafe ramdisk, mounting the HDD at /mnt,
> and trying to run any binary from the bfu'ed root gives me:
>
> # chroot /mnt /sbin/sh
> ld.so.1: sh: fatal: /lib/libc.so.1: hardware capability unsupported:
> 0x800 [ SSE ]
> Killed
>
>
> And indeed, the libc.so.1 that I compiled from build 23 sources needs SSE:
>
> % file ./usr/src/lib/libc/i386/libc.so.1
> ./usr/src/lib/libc/i386/libc.so.1: ELF 32-bit LSB dynamic lib 80386
> Version 1 [SSE CX8 FPU], dynamically linked, not stripped, no debugging
> information available
>
> The Pentium-II box supports MMX, but not SSE. Replacing the new
> /lib/libc.so.1 with the old one from the snv_22 failsafe miniroot fixed
> the problem for now.
we just stumbled across this internally ourselves.
there's a "capability" elf section which indicates what hardware
capabilities are required by a particular object.
the assembler was recently changed to fill this in based on what
instructions it saw while assembling a file.
the linker uses this to determine if the object will run.
*but* a bunch of hand-tuned assembler code does its own capability
checks; these instructions can be present without causing the code to
fail to run....
6332924 & 6330877 were filed to track the fix.
workaround is to build with an older assembler.
Here's the internal "heads up" I sent out before we noticed the libc
issue:
----
If you maintain a public or private x86 build machine, or maintain x86
assembly code in the ON gate you should read this note.
New in the snv_24 WOS is an revised x86 assembler which contains the
implementation of the compiler/assembler-x86 RFE:
6290635 x864 compiler fails to mark binaries with instructions used
The assembler is packaged as part of the "SUNWsprot" package, which is
not part of ON; bfu will not update it but a fresh install of snv_24 or
an upgrade to snv_24 will surely pick it up.
Until further notice you should avoid using the snv_24 or newer version
of the assembler; reverting /usr/ccs/bin/as to a copy from an older WOS
seems to be sufficient to avoid this problem.
The new assembler can be identified with "what" as:
RELEASE VERSION SunOS 5.11 snv_24 09/23/2005
while snv_23 and earlier contained:
RELEASE VERSION SunOS 5.10.1 snv_14 04/25/2005
Symptoms:
If you use this assembler to build ON, the resulting BFU archives may
spew errors on boot including:
WARNING: Module verification failed for /kernel/crypto/des.
WARNING: des _init: crypto_register_provider() failed (0x50)
and:
snmpd[100532]: libpkcs11: Cannot load PKCS#11
library /usr/lib/security/pkcs11_softtoken_extra.so. dlerror: ld.so.1:
snmpd: fatal: /usr/lib/security/pkcs11_softtoken_extra.so: hardware
capability unsupported: 0x1000 [ SSE2 ]. See cryptoadm(1M). Skipping
this plug-in.
Unfortunately, the new capability marking is overly conservative; SSE2
instructions may be present but not used if the SSE2 extension isn't
available. Bug 6330877 has been filed to track this specific failure;
it is possible that there may be others lurking within ON. See the bug
for additional details.
---
_______________________________________________
opensolaris-code mailing list
[email protected]
https://opensolaris.org:444/mailman/listinfo/opensolaris-code
