chris@com50.c2s.mn.org (Chris Johnson) (07/26/90)
Has anyone out there gotten an Optimem 2400 WORM to work connected to a Sun Sparcstation? The problem seems to be an interaction between the Optimem and Sun's "new" SCSA [sic] SCSI drivers or the Sun hardware. These same drives work fine with the Sun 3 series systems running SunOS3.5. But connected to my Sparcstation, I get all kinds of strange SCSI bus data transfer and reset errors from device "esp0". We are migrating our products from the Sun 3 machines to Sparcstations, and being able to use optical WORMs is an absolute necessity. Help! ...Chris Johnson chris@c2s.mn.org ..uunet!bungia!com50!chris Com Squared Systems, Inc. St. Paul, MN USA +1 612 452 9522
chris@com50.c2s.mn.org (Chris Johnson) (07/31/90)
In article <10332@brazos.Rice.edu> chris@com50.c2s.mn.org (Chris Johnson) writes: > >Has anyone out there gotten an Optimem 2400 WORM to work connected to a >Sun Sparcstation? The problem seems to be an interaction between the >Optimem and Sun's "new" SCSA [sic] SCSI drivers or the Sun hardware. > >These same drives work fine with the Sun 3 series systems running >SunOS3.5. But connected to my Sparcstation, I get all kinds of strange >SCSI bus data transfer and reset errors from device "esp0". Well, I found the problems: Optimem's SCSI interface is still grossly outside of specification, as far as I can tell by inference. I didn't have a SCSI bus analyzer to check it this time, but I've reported other such "bad" behavior to them before. Presumably they will fix their firmware some day soon. In this instance, if the initiator (Sun) asks for less data than the Optimem is interested in sending, the Optimem goes out to lunch, and throws a lot of out-of-protocol garbage onto the SCSI bus. Specifically, with Sun OS 4.1, the SCSA [sic] library routine scsi_slave() does a SCSI Inquiry command for you. Only thing is, the caller has no control over how much data it requests, and the SCSI Inquiry command has vendor specific quantities and values of data returned. You can probably see why this doesn't sit too well with the Optimem. I've kludged around the problem for the moment. But my wish list looks like this: 1) It'd be nice if Optimem would get it together in their SCSI bus protocol firmware. 2) It'd be nice if Sun would write and provide as part of the standard OS release a generic, configurable SCSI device driver. At this point, I'd even willing to help them figure out how to do it! 3) It'd be nice if Sun Consulting would sell products that actually worked, and actually had complete documentation. I'm using the SIP driver as the high-level driver adjunct to the SCSA [sic] low-level routines, since that's the only way I'm going to talk to a "unsupported" device. Or write my own driver -- and I'm sorely tempted, but I lack the time. Unfortunately, their software is full of bugs, and their documentation is incomplete. 4) As part of #3, I'd love a complete copy of Matt Jacob's "SparcStation1 SCSI Implementation Notes", which Sun Consulting sent me all the odd pages from, leaving me to guess what was on the even numbered pages. If there's a more up-to-date version of the "Sun Common SCSI Architecture" manual beyond revision 5.0, I'd love that, too. As you might imagine, talking to Sun Consulting or the local Sun sales people is unproductive. ...Chris Johnson chris@c2s.mn.org ..uunet!bungia!com50!chris Com Squared Systems, Inc. St. Paul, MN USA +1 612 452 9522
mjacob@wonky.eng.sun.com (Matt Jacob) (07/31/90)
Send me the manual for the Optimem and error logs. Also, do you expect the 'sd' driver to handle a read-only optical disk? 'ESP' chattiness can also come about by a lot of urk on the bus (this would be true independent of SCSA). I designed, implemented and wrote 90% of the SCSA code. Matt Jacob