name@Portia.Stanford.EDU (tony cooper) (12/14/88)
Symantec Utilities for the Macintosh provide a generic SCSI driver to access the physical blocks of a disk drive. This driver works fine with the SyQuest 44Mb removable disk drive. It is possible to read and write to the device using this driver. But the generic SCSI driver that A/UX uses does not work with the Syquest. It produces the error "More data than SCSI device requested" when trying to read or write to the drive. Does anyone know why this happens? What is different about the Syquest that it does not work well with the A/UX driver. Many other drives work fine with the A/UX driver. Thanks, Tony Cooper name@portia.stanford.EDU
falken@caen.engin.umich.edu (David R Falkenburg) (12/15/88)
In article <4370@Portia.Stanford.EDU>, name@Portia.Stanford.EDU (tony cooper) writes: > But the generic SCSI driver that A/UX uses does not work with the Syquest. > It produces the error "More data than SCSI device requested" when trying > to read or write to the drive. > > Thanks, > Tony Cooper > > name@portia.stanford.EDU You wouldn't happen to know what the formmated block size is set to on that drive? It sounds like the drive may be using 1024 byte blocks (instead of the "normal" 512 byte variety) This shouldn't cause a problem under MacOS because the software driver could handle the data shuffling easily, while A/UX WANTS a 512 byte/block device. Most MacOS SCSI Drivers (i.e. one's whcih utilize the ROM SCSI driver) usually ignore any extra data that might be associated with a transfer durning teh data phase. If you have SCSI Tool 1.1 from ArborWorks Software, you *could* issue a MODE_SELECT command & issue a FORMAT_UNIT to try and hack it to work. If you can get 512 byte blocks, AU/X will probably work on it -dave falkenburg -- Dave Falkenburg @ University of Michigan Computer Aided Engineering Network ARPA: falken@caen.engin.umich.edu UUCP: umix!caen.engin.umich.edu!falken
michael@xanadu.COM (Michael McClary) (01/03/89)
In article <4370@Portia.Stanford.EDU>, name@Portia.Stanford.EDU (tony cooper) writes: > But the generic SCSI driver that A/UX uses does not work with the Syquest. > It produces the error "More data than SCSI device requested" when trying > to read or write to the drive. > > Thanks, > Tony Cooper > > name@portia.stanford.EDU Are you hanging the Syquest and another drive on the SCSI bus at the same time? I saw that same error message under 1.0 when I mixed a Jasmine (300 MB Wren) with a Quantum (80 MB 3-1/2"). (I'm not sure if the non-disclosure agreement covers posting the symptoms under 1.1 Beta 3.) Turned out the Quantum firmware (6.8 00) had a bug. When disconnecting, it neglected to tell the initiator to save pointers. Come the reconnect, blooie! Solution was to get new firmware from Quantum. ((7.9 00) fixes that bug, but poses another: It runs a 20+ second self-test. Mix it with a drive that wakes up faster and the finder decides it isn't there.) Suggestion for Apple: Think seriously about having the SCSI driver save the pointers even if the drive doesn't ask you to. Sure, it means a little more code, to support somebody else's bug. But the bug doesn't manefest under finder, so when it shows up under A/UX it looks like YOUR fault, not the drive's. - - - - - - - - - - - michael@xanadu.com (Haveta move my .signature one of these daze...) - - - - - - - - - - -
elliston@rob.UUCP ( Keith Elliston) (01/03/89)
Hi I need some info on AUX supplied from Apple. We just purchased a IIx from apple, supposedly ready to run AUX. We got this from a local dealer. He now tells us that AUX must be purchased separately. WOuld some kind soul please fill me in on the specifics of getting AUX? THanks much Keith uunet!rob!elliston
kaufman@polya.Stanford.EDU (Marc T. Kaufman) (01/04/89)
In article <eakdo#+=michael@xanadu.COM> michael@xanadu.UUCP (Michael McClary) writes: >Suggestion for Apple: Think seriously about having the SCSI driver save the >pointers even if the drive doesn't ask you to. Sure, it means a little more >code, to support somebody else's bug. But the bug doesn't manefest under >finder, so when it shows up under A/UX it looks like YOUR fault, not the >drive's. Please don't. There is a specific use for disconnect without saving pointers, which is to allow restart of an operation after an error. This is documented (in the SCSI standard? I forget... but I remember reading it). If the device is broken, fix it. But please don't break every other device in order to cover up one failing (shades of Excel!). Marc Kaufman (kaufman@polya.stanford.edu)
buck@siswat.UUCP (A. Lester Buck) (01/04/89)
In article <eakdo#+=michael@xanadu.COM>, michael@xanadu.COM (Michael McClary) writes: > Turned out the Quantum firmware (6.8 00) had a bug. When disconnecting, it > neglected to tell the initiator to save pointers. Come the reconnect, blooie! > Solution was to get new firmware from Quantum. ((7.9 00) fixes that bug, > > Suggestion for Apple: Think seriously about having the SCSI driver save the > pointers even if the drive doesn't ask you to. Sure, it means a little more > code, to support somebody else's bug. But the bug doesn't manefest under > finder, so when it shows up under A/UX it looks like YOUR fault, not the > drive's. Sure, and break all those drives that *do* conform to the SCSI-1 standard! The updating of the SCSI pointers is a tricky business, and the target controls everything in a SCSI transfer. Just for example, what if the target detects and recovers from an error, and needs to resend some data - it disconnects and reconnects WITHOUT saving the pointers. In SCSI, the action of saving pointers means at least that much data is, in the target's opinion, error free. Just because some clowns at Quantum didn't simultaneously test run two of their drives on a single bus (by rev 6 of their firmware, yet!), don't ask Apple to destroy their own systems. -- A. Lester Buck ...!uhnix1!moray!siswat!buck
jlohmeye@entec.Wichita.NCR.COM (John Lohmeyer) (01/05/89)
In article <368@siswat.UUCP> buck@siswat.UUCP (A. Lester Buck) writes: >In SCSI, the action of saving pointers means at least that much >data is, in the target's opinion, error free. > Lester, actually saving the pointers means that the target probably doesn't intend to re-transmit the data up to that point. But it could if both the Host Adapter and the Target have implemented the MODIFY DATA POINTER message. In any case, the host really doesn't know that the data is "error free" until it receives GOOD status. A target may transmit erroneous data and THEN tell the host that the data is bad. Some people have implemented host designs that assume all data sent prior to a SAVE DATA POINTER message is "good" data -- they will probably get burned some day... John Lohmeyer J.Lohmeyer@Wichita.NCR.COM
ts@cup.portal.com (Tim W Smith) (01/06/89)
It's not nice for a driver to save pointers if the drive hasn't told it to. Consider a high performance drive that transfers data directly from the disk to the SCSI bus. In most cases, this will not cause any problems. However, suppose an error occurs that the ECC fails to correct. The drive will have to try to re-read the data off the disk. This could take a while, so the drive might disconnect, then reconnect when it has finished re-reading the data. Since it has not issued a SAVE DATA POINTERS, it expects the data it sends to overwrite the bad data it previously sent. If the driver assumed that the drive just "forgot" to issue a SAVE DATA POINTERS command, this won't work. I don't know if anyone has tried this trick of sending bad data and then overwriting it with a disk drive, but I believe that there are tape drives that do this. Tim Smith