Bug 103078 - Unable to install Severn on Cyrix P166 (rpm segfaulting)
Unable to install Severn on Cyrix P166 (rpm segfaulting)
Product: Red Hat Linux Beta
Classification: Retired
Component: rpm (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
Depends On:
  Show dependency treegraph
Reported: 2003-08-26 10:12 EDT by Leonard den Ottolander
Modified: 2007-04-18 12:57 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-08-26 15:49:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
core file created on invocation of rpm -qa (64.83 KB, application/octet-stream)
2003-08-26 10:14 EDT, Leonard den Ottolander
no flags Details
core file created on invocaton of rpm -i <somefile> (65.56 KB, application/octet-stream)
2003-08-26 10:17 EDT, Leonard den Ottolander
no flags Details

  None (edit)
Description Leonard den Ottolander 2003-08-26 10:12:32 EDT
Description of problem:

  I was unable to install Severn on an old Cyrix P166. It would terminate 

the installation immediately after package selection without any error 

other than "exited abnormally".

  At that point tty3 shows:

* everything references package nptl-devel which doesn't exist
* moving (1) to step selectlangpackages
* moving (1) to step package-selection
* moving (1) to step handleX11pkgs
* moving (1) to step checkdeps

 No errors are reported at tty4.

 So I proceeded to install 7.3 on the system and do a Severn installation 

using rpm --root from there. This renders a functional system (apart from 

some missing config files), but with an incorrect rpmdb. After that I supplied a 

correct rpmdb created using rpm --justdb on an other Severn system. Even 

after substituting the rpmdb I was seeing segfaults / non-exec exploits on 

every invocation of rpm.

 To make sure this has nothing to do with the installation being performed 

from a 7.3 system I exported a new partition from the Cyrix Severn system 

and installed a new system from another Severn system, again using rpm --

root /mnt/nfs_cyrix. I am still seeing segfaults on every invocation of 

rpm, also when using the latest 9 kernel and the latest rawhide rpm.

 Backtraces on core files created by invocations of rpm -qa 

(/usr/lib/rpm/rpmq) and rpm -i <pack> (/bin/rpm) show rpmShowRC to be the 

location of the crash:

For rpm -qa:

#0  0x0094b164 in rpmShowRC () from /usr/lib/librpm-4.2.so

For rpm -i:

#0  0x00997164 in rpmShowRC () from /usr/lib/librpm-4.2.so

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

(not sure if I used the above or rpm-4.2.1-0.11 on installation)

How reproducible:

 Try to invoke rpm on a Cyrix P166

Actual results:

 rpm segfaulting
Comment 1 Leonard den Ottolander 2003-08-26 10:14:24 EDT
Created attachment 93935 [details]
core file created on invocation of rpm -qa
Comment 2 Leonard den Ottolander 2003-08-26 10:17:04 EDT
Created attachment 93936 [details]
core file created on invocaton of rpm -i <somefile>
Comment 3 Jeff Johnson 2003-08-26 15:49:52 EDT
Almost certainly rpm has problems on Cyrix P166.

AFAUCT, the cpuid instruction used to detect athlon
may be the problem. I suspect that doing
    echo "i386-redhat-linux" > /etc/rpm/platform
will avoid that.

Then there's bswap that may need removal. Make sure rpm
is compiled with -march=i386 -mcpu=i686 )or equiv)

Next is NPTL, i386 kernel's have not. Find every
occurence of --enable-posixmutexes (in autogen.sh and
rpm.spec) and nuke.

Then there's beecrypt, which has asm optimizations.
I've been told (but have not checked) that the
md5/sha1/dsa/rsa code paths are clean, i.e. will
work on i386.

With the above changes, rpm used to work on i386.

Again, there's little reason to support i386 execution of rpm
too little to justify the fixes listed above. All the changes
are known and desirable.

Those are my marching orders, nothing personal.
Comment 4 Leonard den Ottolander 2003-08-26 19:48:02 EDT
Creating /etc/rpm/platform as you say indeed renders an "Illegal instruction"
instead of a segfault when invoking rpm.

There's two things I don't understand: First, I thought this Cyrix is i686
compatible; second, are you telling the default rpm is *not* built using i386
Comment 5 Jeff Johnson 2003-08-28 14:59:14 EDT
I don't believe Cyrix P166.

Yes, I just described the non-i386 instructions now in rpm, and what to
do about them if you choose.
Comment 6 Leonard den Ottolander 2003-08-29 12:07:34 EDT
Yes your explantation was clear. I am just surprised that a package containing
non-i386 instructions is shipped as an i386.rpm. If it uses i686 instructions,
shouldn't it be shipped as i686.rpm instead?

(By the way I thought the Cyrix was i586 compatible, not i686. Anyway, its
neither. ;)
Comment 7 Leonard den Ottolander 2004-01-12 08:26:50 EST
RPM probably also needs to have db4 built without nptl. See bug #91933
for a patch.
Comment 8 Michael K. Johnson 2004-01-19 13:22:49 EST
For anyone browsing this bug who doesn't realize this:

Despite the "P" in the name, that CPU is really a 486-equivalent at
a slightly higher clock speed, not a pentium-equivalent.
Comment 9 Leonard den Ottolander 2004-01-26 09:42:39 EST
I finally got the correct answer to this question from Arkadiusz
Miskiewicz from PLD (http://www.pld-linux.org/).

The problem is that this Cyrix does not have a TSC flag (the same
applies to WinChips (CentaurHauls)).

Apply the following patch and create an /etc/rpm/platform:

--- rpm-4.2.1/rpmio/rpmsw.c.orig 2003-04-10 20:09:13.000000000 +0200
+++ rpm-4.2.1/rpmio/rpmsw.c 2003-11-17 21:55:44.649426712 +0100
@@ -27,7 +27,7 @@
 static int rpmsw_initialized = 0;
-#if defined(__i386__)
+#if 0 && defined(__i386__)
 /* Swiped from glibc-2.3.2 sysdeps/i386/i686/hp-timing.h */
 #defineHP_TIMING_ZERO(Var)(Var) = (0)

# echo "i386-redhat-linux" > /etc/rpm/platform
Comment 10 Hans de Goede 2004-09-02 02:04:57 EDT
Erm, I just stumbled over this bug following a thread of bugs of a
fedora-devel post.

Why won't this be fixed? I understand that building without NPTL
really is not an option, but in this case the problem isn't NPTL, but
the fact that rpm doesn't handle the cpu-detection correct. It tries
to use TSC which isn't there and it barfs out on the cpu dedection, so
IMHO this is really a bug and should be reopened.

Also since rpm MUST have NPTL, shouldn't rpm (and all other rpm's
which must have NPTL) be .i486.rpm?

BTW this is just my 2¢ I don't have a cpu which cuffers from this.

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