On Wed, 16 Aug 1995, der Mouse wrote:

> I've got two problems with NetBSD/sparc.
> 
> The first one is rather bizarre, but I swear this is what happened to
> me....
> 
> I built the NetBSD boot blocks, copied boot to /, ran installboot,
> tried to reboot...and it died with "Memory access not aligned" (or some
> similar message complaining about a memory alignment error).  So I
> figured the boot blocks weren't ready for prime time yet, booted the
> thing diskless under SunOS, and reinstalled the old bootblocks I had
> been using (which I did think to save first :-).  Recently, I tried
> again, and got the same error.  This time, I added a debugging printf
> to bootxx.c, recompiled, reinstalled, and everything worked.  I removed
> the printf, recompiled, reinstalled, and darned if it didn't work!
> 

I've had the same problem trying to install them on a Maxtor LXT-213SY.
I just assumed it wasn't working yet and didn't try too hard.

Dumb question, but what is the 'fixhdr' binary in sparc/stand fixing?

I was also trying to make a bootable floppy (just for kicks) and it 
bombed out with something along the lines of "bad disklabel magic". Can't
remember all of it, I'll check when I get home if anyone is interested.

> 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....

Is anyone out there using the current SCSI driver on an exabyte 8200?

> 
> 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.)
> 
> 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.
> 
> 					der Mouse
> 
> 			    mouse@collatz.mcrcim.mcgill.edu
> 

Jon