> Ted wrote:
> >...
> > --- certain broken IDE controllers will cause MASSIVE FILESYSTEM DAMAGE
> > if the stream of data during a programmed i/o data transfer is
> > interrupted by an interrupt.
> > - Ted
> >
Given this, I don't see how you could even boot such a system. This
simply can't be the problem . PIO is interruptible. It's not very
efficient, but certainly very safe. At the hardware level, PIO works just
like DMA except the CPU functions as the DMA controller which makes it
inefficient because the CPU can't do other things while the I/O operation
is in progress.
It's very simple. You can boot these systems because Linux by default
disables interrupts during IDE PIO operations. That's why you get all
of the serial overflow warning messages during heavy hard disk
operations on slower machines, especially if you have a 16450 UART.
Yes, it's slow, yes it screws up serial file downloads, etc.
However, the IDE driver maintainer considered it better to be safer (and
slower) than sorry, especially since presumably he would get all of the
hate mail if users lost data as a result. Also, consider what kind of
reputation Linux would have if some folks with broken hardware started
complaining far and wide about how "Linux trashed my hard disk". This
kind of allowance for broken hardware is the legacy of the IBM PC
"architecture".... Sigh....
hdparm -u will allow you to enable interrupts during IDE PIO operations,
and if you do this after you finish booting (or in the /etc/rc scripts),
and you have one of the buggy IDE controller chips, then you may have
MASSIVE FILESYSTEM DAMAGE. Since I don't want to be blamed either if
users lose data by using hdparm -u, I always make sure that I warn folks
of the dangers of turning on this flag, even if 95%+ of the machines out
there are actually safe.
Murphy's Law says the one user that I recommend use hdparm -u where I
don't warn them about MASSIVE FILESYSTEM DAMAGE will have one of the
bum controller chips.... :-(
- Ted