>> This means that the driver waited for an interrupt and it never happened
>> (This is a known problem with the IDE driver under heavy load).

>Excuse me?  Since when is this is a `known problem'?
>The only time this has ever been reported with IDE disks, AFAIK, is
>when a disk spins down (usually due to APM, but some desktops will
>spin down the disk as well) in the middle of a transfer.  In this
>case, the transfer is retried and unless you get a `hard error
>{read,writ}ing fsbn ...'  message, you can assume that nothing was
>lost.
>Please do *NOT* start wild rumours.

What do you mean, Charles?  You, yourself, worked over the IDE driver
a few years ago to try and make this thing go away.  Granted it
shouldn't happen on modern hardware, but it was a "known" problem with
certain older hardware, where strange IDE controllers and/or drives
didn't always like to get the timing right.

If this is modern hardware, then this shouldn't be the same "known
problem".  The stuff should work.  But if this is a bunch of old
surplus junk, then there is a fairly well-established history.

-----------------------------------------------------------------------------
  Michael L. VanLoon    mvanloon@exmsft.com    michaelv@MindBender.serv.net
      Contract software development for Windows NT, Windows 95 and Unix.
             Windows NT and Unix server development in C++ and C.

        --<  Free your mind and your machine -- NetBSD free un*x  >--
    NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3,
        Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32...
    NetBSD ports in progress: PICA, others...
-----------------------------------------------------------------------------