Subject: installation boot fails with standard bootdisk on 486SX/33

From: [email-masked]
Date: Fri, 9 Aug 1996 08:18:47 -0400 (EDT)

Installation fails on this old machine shortly after hitting return at the
'Boot Parameters' prompt using the standard bootdisk. Linux 1.2.13 runs fine.

I suspect (based upon bug reports) that APM is enabled in the kernel on the
standard bootdisk and that this is the problem.

I propose to install on another machine and create a custom bootdisk for this
old (but useful) dog.

Does anyone have any pointers or is there a suitable bootdisk image somewhere I
can use? I am installing from the August Pacific HiTech CD and have internet
access.

Thanks,
Michael Laing

---

From: "Christopher R. Hertel" <[email-masked]>
Date: Fri, 9 Aug 1996 12:40:52 -0500

On Aug 9,  8:18am, [email-masked] wrote:
> Subject: installation boot fails with standard bootdisk on 486SX/33
:
: Installation fails on this old machine shortly after hitting return
: at the 'Boot Parameters' prompt using the standard bootdisk. Linux
: 1.2.13 runs fine.
:
: I suspect (based upon bug reports) that APM is enabled in the kernel
: on the standard bootdisk and that this is the problem.
:
>-- End of excerpt from [email-masked]

On my system (brand-new AMD-486DX4-120), the error that I get tells me
that the failure is occuring as the kernel is being decompressed.  This
would suggest that APM is *not* the problem, as the kernel (if it does
have APM support) has not yet started to run.

I have seen postings on this mailing list that claim that the problem
is level 2 cache, level 1 cache, EDO RAM on a board that doesn't
support it, or generic hardware instability.  Some 486sx system boards
do have cache.  If this is the case, try turning off the cache and see
if that fixes the problem.  If it does, report it as a bug.

...and now for the soapbox...

Given the type of problem you've reported, you might hear the infamous
"hardware instability that doesn't show up when running DOS or older
versions of Linux because the newest Linux makes your machine work
harder" cop-out.  This is a completely invalid argument, IMO.  I've
heard it several times (not in the message quoted above :).  If I can
run older versions of Linux, and a new one shows up that doesn't run,
then I claim that the problem is in the new software.

I've already had this happen once.  I ran Linux 1.0.8 without problems
on a board with a Cyrix 486DLC-40.  When I installed 1.2.8 I started
getting frequent, random SIGVEC errors.  These would often bring the
system to its knees, forcing a power cycle.  I heard from several
others who had the same problem, but the only help we ever got were
suggestions that we should buy new motherboards.  I finally gave in,
because I wanted a math co-processor and a faster CPU, and I wanted to
get the *&^&@#%^! machine running (and because I'd finally saved up
enough money).

So, I have just purchased my new motherboard (with the AMD chip), and
1.2.8 runs very well.  I have not seen any SIGVECs at all since the
upgrade.  Now I'm being told that I can't install Debian with the 2.0.x
kernel because my hardware is incompatible?  This just doen't make
sense!

>>From what I've seen in the few days I've been on this mailing list,
there are several people out there who are having trouble installing
Debian because of conflicts with the cache.  Of those, several are
running an older version of Linux successfully, or have managed to
install the system by temporarily turning off the cache, and have no
problems decompressing the kernel from the hard disk.

Sorry if I sound a bit peeved about all this...

...but I am.

Chris -)-----

-- 
Christopher R. Hertel -)-----                   University of Minnesota
[email-masked]              Networking and Telecommunications Services

---

From: [email-masked] (Bruce Perens)
Date: Sun, 11 Aug 96 19:25 PDT

The kernel should print a few lines of information before it first touches
APM, this is not the problem.

From: "Christopher R. Hertel" <[email-masked]>
> that the failure is occuring as the kernel is being decompressed.

OK - if this is true that means:

1. Bad data on the floppy. Most common. Re-download and write another.
2. "LFB" setting in your BIOS wrong. See the installation document. Rare.
3. Bad RAM or other hardware. Happens _rarely_, but has indeed happened.

> try turning off the cache and see

It is best reported to [email-masked] and copied to us.
It's not really our job to fix the kernel - we just distribute it.

> then I claim that the problem is in the new software.

Sigh. I wish you'd spend some time supporting new users booting their
systems for a while. We really do need the help. It might change your
opinions, too.

You could start by reading the kernel source for the code that decompresses
Linux once it's been loaded into memory. Get a good idea of what can go
wrong with that code, and what it will say when something does go wrong.
Then help all the people who don't get anywhere after the boot: prompt.

> Now I'm being told that I can't install Debian with the 2.0.x

Huh? What hardware? Who said it was incompatible?

> Sorry if I sound a bit peeved about all this...

Pardon me for saying so, but please try to be a bit more constructive. This
is an all volunteer unpaid project.

	Thanks

	Bruce

---

From: "Christopher R. Hertel" <[email-masked]>
Date: Mon, 12 Aug 1996 14:20:06 -0500

> Subject: installation boot fails with standard bootdisk on 486SX/33
: From: "Christopher R. Hertel" <[email-masked]>
: > On my system (brand-new AMD-486DX4-120), the error that I get tells
: > me that the failure is occurring as the kernel is being
: > decompressed.
:
: OK - if this is true that means:
:
: 1. Bad data on the floppy. Most common. Re-download and write
: another.

Have done.  Several times from several sources using several floppies.
I've also used several tools (including DOS format, Win95 format,
Norton Utilities Format, Scandisk, chkdsk, and other Norton stuff) to
verify that the floppies are in good condition before I write to them.
I am using dd under Linux 1.2.8 to write the floppies.  I am also using
the same floppy drive to format & write the disks, and to boot.

I think I've covered this aspect.

: 2. "LFB" setting in your BIOS wrong. See the installation document.
: Rare.

There is no LFB setting in my BIOS setup.  I have read the installation
documentation.

: 3. Bad RAM or other hardware. Happens _rarely_, but has indeed
: happened.
:
: > try turning off the cache and see
: > if that fixes the problem. If it does, report it as a bug.
:
: It is best reported to [email-masked] and copied to
: us.
: It's not really our job to fix the kernel - we just distribute it.

I disabled the internal cache and--*poof*--the problem went away.
I will send a report to [email-masked].

Based on my results, and the results of others (as posted to this
mailing list) I believe that this is *not* a kernel problem because, as
you pointed out when discussing the possibility of an APM problem, the
kernel is not yet loaded when the decompression error occurs.  The
problem, it appears, is in the decompression code.

  *QUERY*: those of you who have had this problem and gotten around it
  by turning off the internal cache, did you turn the cache back on
  once you had installed the system on your hard disk?  Did that work?

I'd like to know whether the decompression code in the floppy is the
same as that which gets loaded on the hard drive.  If so, does the
problem persist when the kernel is being decompressed from the hard
drive or does it only appear when booting from floppy?  Is the kernel
decompressed directly from the floppy, or is it transferred to the RAM
disk first?

: Sigh. I wish you'd spend some time supporting new users booting their
: systems for a while. We really do need the help. It might change your
: opinions, too.

It seems that you've overlooked a couple of points:

 1) I *was* providing support for a new user attempting to boot his
    system.  I explained, as you did, that APM probably wasn't the
    problem.  I also suggested turning off the cache.  In my own case,
    and in several others, this (unfortunately) worked.  (I say
    "unfortunately", because I believe that I should be able to use the
    internal cache, unless you're telling me that Linux is intended
    *not* to run with internal cache enabled.)

 2) I spent a *year* trying to figure out the SIGVEC problem, which was
    reported by several Linux users via newsgroups and mailing lists.
    The problem appeared on a variety of motherboards using a variety
    of CPU types, controller types, and memory configurations.  Those
    of us who experienced this problem tried to combine our resources
    to solve it, but we did not have the technical expertise, or the
    support, or the stable platform we needed in order to accomplish
    much.  Think about it: how am I supposed to test a fix to the
    kernel if I can't compile a new kernel because the system crashes
    whenever I try?  (The SIGVEC problem was random, but typically
    occurred when an attempt was made to compile anything large.  No,
    it did *not* always appear at the same point in the compilation.)

    At first, I got a great deal of helpful advice regarding the SIGVEC
    problem.  Unfortunately, all of the suggestions that I received
    failed to correct it.  Eventually, people started telling me and
    the others that the problem was in our hardware.  When I explained
    that other operating systems (including DOS, Taos, and older
    versions of Linux) worked fine, I was told that those systems did
    not "exercise" the hardware as much as Linux does.  Great.

: > Now I'm being told that I can't install Debian with the 2.0.x
: > kernel because my hardware is incompatible?  This just doesn't make
: > sense!
:
: Huh? What hardware? Who said it was incompatible?

    So I've finally saved enough money to buy a new motherboard.  Linux
    1.2.8 now runs well.  I've never figured out why the old one caused
    random SIGVEC errors, which is a shame, because that problem is
    probably still biting others out there (several of whom may have
    given up in disgust).

    So, now that 1.2.x is stable, I've decided to upgrade to 2.0.x.
    Unfortunately, a new "hardware" bug has appeared:  I can't
    decompress the 2.0.x kernel from the installation disk because,
    based on what I have been told (via this mailing list) and have
    since tested, the decompression code is incompatible with the
    internal cache on my new motherboard.  If I turn off internal
    cache, the kernel decompresses.

    You might say "So?  Disable the cache and be done with it."  I
    would reply that internal cache is a fairly standard feature these
    days, and I'm pretty sure that Linux runs on other systems that
    have it.  I believe that the fact that the decompression fails on a
    small subset of systems is sufficient to justify investigation of a
    possible bug.

: Pardon me for saying so, but please try to be a bit more
: constructive. This is an all volunteer unpaid project.

That was low.

It implies that I've never contributed, never tried to help anyone
else, never volunteered myself, and never spent any time trying to fix
problems for myself or anyone else on the net.  All false.  Perhaps I'm
not the kernel-hacker guru that you are, but I do what I can.

In this case, the message to which you replied included my best attempt
to help someone else with whom I shared a common problem.  It also
included a warning regarding obscure hardware incompatibility bugs.  I
believe that the kernel decompression problem is such a bug, though I'm
certainly willing to be proven incorrect.

My warning, just to be clear, is this:

These problems do exist, but it is unlikely that they will be resolved
unless the people who *don't* experience them take them seriously.  In
most cases hardware will be blamed, even though the problem appears on
a variety of memory/CPU/motherboard/add-on configurations, and the same
configurations can run other OSs (*including* older versions of Linux)
without the same failures.

In effect, it's a warning that we *have* to be involved or we may find
ourselves cut out, as I was.  Quite the opposite of your accusation.

I hope that that clarifies my position.

Sincerely,

Chris Hertel -)-----

---

From: [email-masked] (Bruce Perens)
Date: Mon, 12 Aug 96 13:04 PDT

> I will send a report to [email-masked].

I have one other report matching this, and two anecdotes, all
reproduced below. I suspect that BIOS floppy I/O is breaking when the
cache is enabled, and you are thus feeding bad data to the disk
uncompression code in the kernel. This could perhaps be a bug in
syslinux, (the boot loader we are using) or a bug in the decompression
code (which is in the kernel, but is sort of a 16-bit prelude to the
actual kernel).  You might try other ways of starting the kernel (LILO
on a floppy rather than a hard disk, LOADLIN from DOS, etc.) to see if
any of them fail with the cache enabled.  That might tell you if it's
the uncompression code or the loader that is at fault. About the only
way to fix this is will be someone with the susceptible hardware to
drive the process.

Please forgive me for ignoring the ways in which you were being
constructive.

	Thanks

	Bruce

Steve Gaarder:
> I am installing Debian 1.1.1 on a generic clone with an AMD 486 on an
> Opti-based motherboard. If I have the internal cache enabled in setup,
> I get the error "invalid compressed format" after the "uncompressing
> Linux" message.  If I disable the cache, it boots fine.  It boots ok
> from the hard drive either way.  Anyone know what is going on?

> From: Dan Bergman <[email-masked]>
> I had problems like this a couple years back when I was installing OS/2
> on a Dell Machine (486,66mhz).. The installation would fail if I didn't
> disabel both L1 and L2 caches.. But I ripped out the TsengLab GFX card
> (VLB)
> and all troubles went away.. Ripping out gfx card is often not a option 
> but the Dell MB had a Cyrrus Logic Chip on it...

mike cotherman:
> I had this problem when I used EDO RAM on a motherboard that did not
> support EDO...just a thought