Re: write alignment matters?

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>> It's a 53c8xx:  we load the "firmware" into it from our own driver.
>> I just had a look at esiop.ss, and it looks high-level enough that
>> it's plausible to me that the problem is with whatever's backing
>> that code, whether silicon or ROMed firmware or whatever.
> I just verified that I see the same on a 53c875 using esiop(4), and
> it also does the same thing with siop(4).

That's good news, in that it means the problem is probably relatively
well-contained and probably common to all chips of a specific type,
possibly a family of closely related types.  This makes it more likely
it'll get found and fixed. :)

> I also found that it works fine if the buffer is at an even address
> and only failed on odd addresses.

That's not what I saw; my initial failure was with a buffer that was
aligned to, IIRC, a multiple of 32 bytes (I think the address in hex
ended in a0).  The test program I quoted uses an odd address for the
misaligned test - I wanted it to be as misaligned as possible - but, at
least on the hardware I initially saw this on, that's not necessary.
(It may help, though.)

The SCSI geek I mentioned wrote back saying this could be caused by
bugs in the sequencer program; he pointed me at the Linux sequencer
program, which I'll compare to NetBSD's esiop.ss and see if I can see
anything useful there.  (He's worked with this stuff mostly on Linux,
so that's what he knows.  Come to think of it, I wonder if I can find a
Linux livecd to try my test on this hardware under the penguin.)

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B