problem: are floppies from outer space?

["ali (Anders Lindgren)" <dat94ali%ludat.lth.se@localhost>]

If this is not a known problem I will have to try to find a browser
so I can fill out a bugreport. Do tell me if it's just me not
knowing what I'm doing... :)

Problem: currently, my "internet connection" (in terms of means to
download software that is) is reduced to carrying floppies from uni and
home. My system is a recently installed NetBSD-1.3.3/amiga setup on a
stock A4000/040 w/ an ariadne board (the picasso2+ died on me, anyone
selling a CV64(3d)?). The other day I downloaded 10 packages to the local
SUN boxen, and brought them home on floppies. 3 packages were recovered. I
can't understand what is so special about the unix architecture
(regardless the flavour/vendor) that makes it so seemingly impossible to
create reliable floppy-drivers, because this seems to be universal - just
about all unix boxen I have encountered have had severe problems reliably
handling... goddamn floppies. And they sent a bunch of blokes to the moon
thirty years ago.. scary.. Anyway, the corruption of the disks I will
happily blame Solaris for, based on previous experiences with SUNs floppy
"drivers" (Solaris 2.4 *loved* to overwrite your pretty X display with
big, console mode letters spelling out "kernel panic"; more recent
versions just corrupts your disks frequently). I'm ranting, to the point:

  The problem I had with NetBSD-amiga was actually more serious than
simple data corruption - randomly, the kernel will hang indeterminately
until the box is hard-reset(!) when trying to mount an 1.44MB MS-DOS
floppy (mount /dev/fd0b /floppy), seemingly with a 15-20% probability.
  The kernel is the generic m68k port-amiga one as picked up from
netbsd.org, and the drive is of course the internal a4000 HD-floppy one.
  I had problems with Generic 1.3.2 as well, but I can't recall if it was
the same or if it was just the SUN-imposed failure quota of floppies.
  The only other clue I can give about it is that I suspect (but can't
confirm) that the failures only happened after I tried to rm a (seemingly)
corrupt file on one of the floppies (a zero-sized tarball, corrupt fs).
  The nature of the failures are as follows; "mount" will simply hang,
doing nothing and not responding to signals (blocked in syscall I
suppose). All other processes will continue to run, until any IO occur
when they will instead also be deadlocked. Needless to say, it's hard to
do anything without causing IO to occur. :-) On a few occasions I was able
to su to root and halt the system, but usually any IO will deadlock the
process forcing a hard reset. The usage causing this behaviour was as
follows;
    ____
   /    \|
  /     -'
 |  <insert disk>
 |  # mount /dev/fd0b /floppy
 |  # ls /floppy
 |  1234 mytarrball.tgz
 |  # cp /floppy/mytarball.tgz /usr/local/src
 |  # umount /floppy
 |  <eject disk>
 \___/

I know of no other way to change floppies, this is correct right?
I don't have access to any other NetBSD boxen, so I don't know if
this problem is specific to port-amiga, 1.3.3GENERIC or just my box.

Is this a familiar problem, and does anyone have a clue of what's
deadlocking? 

TIA,
ali
-- 
/ali: Computer Science Major and aspiring cartoonist. :-) 
(dept) dat94ali%ludat.lth.se@localhost - http:// www.ludat.lth.se/~dat94ali
* a4ooo/o4o/18Mb/1,5Gb/OS3.o/Ariadne/Picasso2+ - cogito, amiga sum *