Valtteri wrote...

> I just booted a kernel with the new scsi driver, and then
>attempted to untar a file on the old really slow Epson MO
>drive. Suddenly tar started giving io errors until I killed
>it, the drive access light would flash on/off every few seconds
>and umount caused an io error. Turning the drive off and then
>back on allowed me to unmount the disk. Then I ran fsck and
>it happened again. My Fujitsu happily continued working.
>

Well...if the Fujitsu MO runs fine for you and nothing worse happened with
the Epson MO, consider yourself happy.

I got a Fujitsu M2512 two months ago when I had piled up >300MB kernel- and
userland stuff on my hard disk.  It was about time to find a serious backup
solution for a 1 GB disk.  The MO worked like a charm on the MacOS side; it
took me about an hour to do a full backup.  Now I wasn't too optimistic
about the NetBSD side as I remembered some discussions of serious problems
with MOs back in the early days of this list.  But anyway, I gave it a try,
and voil=E0 - the drive was recognized (a kernel built from sup'ed sources o=
f
around 5 Aug).

So I said 'cd /usr/src' and 'tar -cf - * |(cd /mnt; tar -xf -)' and
relaxed.  And after copying about 10 MB the machine gave a rather
unexpected reply like

kernel panic: bad dir
db>

I said 'c sync' and 'c reboot'; and when I booted NetBSD again it dropped
into single user and said it lacked /bin/sh.  To cut a long, sad story
short, everything that had been involved in the act of copying - source,
target, sh, tar and their respective home directories - went down the
drain.  /bin had entirely ceased to exist.  Afterwards I read Ken Nakatas
advice _not_ to do a 'c sync' in such a case since it greatly increases the
damage.  He was right...

In order to do an fsck on the damaged partitions I put up 1.0 binaries on
an MO, added a newer kernel (MRG of 12 Nov 94 did not know what to do with
the MO) and booted without a problem.  It took me quite some time to repair
/ and /usr, and when I tried to copy some binaries from the MO to my HD the
kernel panicked again...  This time I reset the Mac and got away with less
damage.

I have installed a second HD into my SE/30 since (the Thing To Have when
you seriously mess with NetBSD) and copied a lot of stuff to and fro
without ever seeing any problems; on the other hand, accessing the MO as a
raw device with tar gave me another kernel panic after - guess what - 10 MB
of copied data. So it seems I can produce that fault at will.

Any ideas? What is so special about an MO compared to a Syquest or a Zip
drive? At boot-time, the kernel complains about missing geometry data (an
anachronism anyway with current ZBR hard disks...).

Is there any hope that the recent changes in the SCSI driver code may help?
I may even be willing to trash some more partitions if that leads to a
solution. (Be back in a month or so ;-)

        hauke

{
   hauke fath                     "It's never straight up and down"
   saw@sun0.urz.uni-heidelberg.de                            (DEVO)
}