[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: write alignment matters?
>>> 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
Main Index |
Thread Index |