>This box failed to run 386BSD equally well. That doesn't prove
>it wasnt just a pile of **** of a box or that 386BSD at the time had
>identical or different bugs (given the price I paid for the 386sx board
>anything is possible)
Just the other day I threw together some old parts to build a machine
to run Windows95 on. But after installing and running for only a few
minutes, W95 complained about registry corruption. I repeated the
install several times, with the same result every time.
I started swapping components in a long ordeal of dozen or so
installs, and after replacing the disk drive with a different one and
lowering the controller chip's default PIO speed, I eliminated the
registry corruption. I repeated the successful install several more
times to make sure the problem was gone, and it's rock solid now.
After spending so many hours to reach my real objective of running
Windows95 on this machine, I have not felt sufficiently motivated to
further diagnose the problem and determine whether it was caused by
the disk drive itself, or the combination of disk drive and the higher
default PIO speed of the controller chip.
But either way, there is no doubt the registry corruption was caused
by hardware.
Several years ago I had a similar problem with a 386 motherboard. I
called the company and the support technician told me the local bus
default PIO speed was too fast for my hard drive and I should change
the jumpers to a lower speed. At the time, I refused to believe him
because the specs for my hard drive said it SHOULD run at the higher
speed. But in retrospect, I am convinced he was absolutely correct.
The bottom line is that hard drives don't always reliably perform as
advertised, especially when pushing them to the limit with higher PIO
speeds. Microid Research used to have some info on their web page
about this very problem, perhaps it's still there.
>> Richard's suggestion.
>
>His suggestion doesnt explain the 386 cases. I can believe it is valid
>for 486's in some forms.
No matter whether on a 386, 486, or a Pentium, bad disk drives and
controller chips are not proper justification for running IDE disk I/O
with interrupts disabled. Some such problems can be circumvented by
defensive programming of the chipset (CMD640) while in other cases the
hardware must be replaced.
But in no case should Linux BY DEFAULT disable interrupts during IDE
disk I/O. If FreeBSD does not, why should Linux?
John