Problems with RedHat 4.9.1 on Cyrix processors due to kernel

Willem Riede (wriede@monmouth.com)
Sun, 26 Oct 1997 13:29:35 -0500


On the redhat-mustang list, there have been a number of problems raised that
may trace back to a problem in the kernel (please bear with me as I present
the case and see my request at the end):

On Sun, 26 Oct 1997, Erik Troan <ewt@redhat.com> wrote:
> On Sun, 26 Oct 1997, Willem Riede <wriede@monmouth.com> wrote:
>
> > If this is true, owners of Cyrix based PCs will NOT be able to upgrade to the
> > next RedHat release! Note that I don't even get to the point where I can
> > manipulate glibc/gcc - my upgrade fails before it does anything useful!
> >
> > Does anyone from RedHat care to comment?
>
> Sure.
>
> This is almost defintely a bproblem with the kernel we're using on
> Cyrix and AMD processors which shows up under heavy load. We don't
> have the expertise to fix this, so I strongly suggest that you
> post something to the kernel list. If you want to verify that this
> is the problem, boot a Mustang system with a 4.2 kernel and see if
> that lets you build a new kernel under GCC.
>
> The chance that this is a gcc bug which only shows up on Cyrix processors
> is slim to none. Almost by definition, anything that lets a user
> process tell the difference between running on a Cyrix and Intel
> processor is a kernel problem.
>
> Erik
>

Other reports seem to implicate GCC 2.7.2.3, but for me the 31-pre10 kernel supplied to boot the mustang installation does not run. Here is my initial report of what happened:

-------
I decided to try a hard-disk based upgrade to 4.9.1 of my 4.2 configuration
(Cyrix P166+, 64 MB ram, two ide hard disks, ide-atapi CD-Rom, ide-atapi PD/CD
drive - more about that last drive another time).

I downloaded a mustang version of all the RPMS I have installed in
~/mustang/RedHat/RPMS, downloaded ~/mustang/RedHat/base (these are on hdb4),
the boot.img and the supp.img, and put the latter two on floppies.

I boot from boot.img, and get to where it looks at the packages and I get
complaints like:

package bootpc at line 16 does not exist

and 110 more like it (111 total if I counted right), ending with:

package faq at line 664 does not exist

I recall from several RedHat releases ago when I did a hard disk install that
if you don't have all the packages on your hard disk (and I don't since I'm
not interested to fetch those that I don't want to install over my modem line)
that you have to run genhdlist yourself (which it does not say in the
installation guide!). So I download genhdlist, but the downloaded version of
genhdlist keeps complaining:

[wriede@linnie mustang]$ ./genhdlist
bash: ./genhdlist: No such file or directory

in spite of

[wriede@linnie mustang]$ ls -l genhdlist
-rwxr-xr-x 1 wriede wriede 191221 Oct 6 14:12 genhdlist

So I suspect a lib mismatch or something, so I set out to recompile genhdlist.
Problem is, it needs gettext.o, but the gettext.c file is zero length on the
RedHat ftp server. Not one to be stopped easily I see if I can find a gettext
somewhere else, and I find a gettextstub.c in rpm-2.3.11.src.rpm.

Link that in, and the result will run, and produce a smaller hdlist. But when
booting with that file in ~/mustang/RedHat/base yields the same set of errors
of type

package bootpc at line 16 does not exist

So I put the downloaded hdlist back and see what happens if I ignore the error
messages. Well, it gets to where it goes to check the installed packages (I
tell it what my root partition is first - I have a 2.0.29 kernel based root
and a 2.1.42 based root - I tell it to use the 2.0.29 one) and then install
gives up with:

install exited abnormally -- received signal 11

And it goes into a shutdown (the output from that is staircased) ending with

you may safely reboot your system

But before I did that I first note what is on the other ttys:

Alt-F2 reveals nothing more than:

#

Alt-F3 output ends with:

* device hdb4 is already mounted -- using symlink
* in ugFindUpgradePackages() with /tmp/rhimage/RedHat/base/hdlist
* read config files
* opened database
* added lost files
* found basic packages to upgrade
* removed extra files which have moved
* found packages with relocated files
* closed RPM database

Alt-F4 output ends with

<5>RAMDISK: Compressed image found at block 0
<4>VFS: Mounted root (ext2 filesystem)
<7>VFS: Disk change detected on device 02:00
<4>Adding Swap: 130748k swap-space (priority -1)

None of this looks too spectacular. I want to add that my hardware is
rock-solid. I've compiled many kernels, and do not believe that the usual "sig
11 is a memory problem" applies.

Please tell me what I am doing wrong - or what experiment I could do to see
what is wrong.

Thanks. Willem Riede.

------- end of included message

Some information on my system:

[wriede@linnie wriede]$ cat /proc/cpuinfo
processor : 0
cpu family : 5
model : 6x86 2x Core/Bus Clock
vendor_id : CyrixInstead
stepping : 1 rev 7
fdiv_bug : no
hlt_bug : no
sep_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu
bogomips : 106.50
[wriede@linnie wriede]$ cat /proc/meminfo
MemTotal: 63128 kB
MemFree: 3228 kB
MemShared: 29428 kB
Buffers: 10084 kB
Cached: 15960 kB
SwapTotal: 261496 kB
SwapFree: 261476 kB
[wriede@linnie wriede]$ cat /proc/pci
PCI devices found:
Bus 0, device 10, function 0:
Ethernet controller: DEC DC21041 (rev 33).
Medium devsel. Fast back-to-back capable. IRQ 10. Master Capable. Latency=32.
I/O at 0x6000.
Non-prefetchable 32 bit memory at 0xe2000000.
Bus 0, device 9, function 0:
VGA compatible controller: S3 Inc. Vision 968 (rev 0).
Medium devsel. IRQ 11.
Non-prefetchable 32 bit memory at 0xf8000000.
Bus 0, device 7, function 1:
IDE interface: Intel 82371SB Natoma/Triton II PIIX3 (rev 0).
Medium devsel. Fast back-to-back capable. Master Capable. Latency=32.
I/O at 0xf000.
Bus 0, device 7, function 0:
ISA bridge: Intel 82371SB Natoma/Triton II PIIX3 (rev 1).
Medium devsel. Fast back-to-back capable. Master Capable. No bursts.
Bus 0, device 0, function 0:
Host bridge: Intel 82439HX Triton II (rev 1).
Medium devsel. Master Capable. Latency=32.
[wriede@linnie wriede]$

------ end of system info

I don't have the knowledge to find out why this happens, which is why I turn to this list, but I'll be happy to perform any experiment that you think might help figure out why this happens.

Thanks. Willem Riede.