> So if the NetBSD boot blocks don't work for you, try re-installing them
> a couple of times before giving up.  I don't know if it's a matter of
> caches not getting flushed or what....

Not had any bootblock problems.

> 
> The second one is a bit more serious: the current SCSI driver, at least
> as of the kernel I'm using (whose version string says 7 Aug) croaks on
> large transfers.  I'm not quite sure what "large" is, but I can give
> two data points that I know break it: (a) using dd to attempt to copy
> sd0a a whole cylinder at a time, with "dd if=/dev/rsd0a bs=433152", and
> (b) trying to read the whole inode area from that filesystem via the
> raw device at a single go (dumpfs reports ipg=3200 inopb=64 bsize=8192,
> implying the attempted read size was 409600 bytes).  When attempting a
> read this large, the process hangs hard.  ps reports a D wait, and
> SIGKILL of course won't touch it.  Aside from having a hung process,
> the system is fine - for example, it doesn't poison the disk; provided
> they use small transfers, other processes can access it just fine.
> This hang is reliable; a given transfer size, as far as I can tell,
> either always hangs or always succeeds.  (I haven't, though, tried
> playing with transfer sizes near the boundary of what works; hanging
> the machine that often is too tiresome.)

I've had similiar experiences, which I ended up putting down to a duff
disk, mainly because I got a new disk and moved NetBSD.demon.co.uk on to 
that disk, since then I've not had any problems, Although on the old disk
when my disk hung it hung and stoped, the system was fine processes still
ran aslong as the did not need any disk I/O.

I had this happen during large compiles, untarring large files and when
diskspace was tight on /. I'm convinced enough to put it down to the disk,
but this information maybe of use.
In anycase as pk, pointed out NetBSD should have produced errors telling me
about the lack of disk, but it didn't.

> 
> If someone can tell me how to coax ddb into giving me a kernel stack
> trace for a non-curproc process, I'll investigate more.
> 
If I can do anything that can help let me know also.

Neil.

-- 
Neil J. McRae.                                       Demon Internet
neil@demon.net