>>> 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 mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
