dplatt@coherent.UUCP (07/13/88)
I spent a few hours poking around on my Mac at home (Micah/Rodime
100-meg drive), and I believe I may have located the incompatibility
between System 6.0 and the Rodime disk driver software. This same
incompatibility may be the cause of problems that have cropped up with
other third-party disks.
Executive summary: Disk First Aid 1.4 is now making use of a _Status
trap that wasn't used by Disk First Aid 1.3. If the disk driver
implements this status request correctly, _OR_ returns a "Not
implemented" error code, everything appears to work correctly. If the
driver ignores the status call and returns a "No error" response, Disk
First Aid attempts to examine the (nonexistent) result of the status
call, becomes very confused, and declares that the disk isn't HFS.
I infer that the disk-initialization package may be making use of the
same or a similar trap. If so, the failure of the driver to reply "Not
implemented" could be confusing the disk-initialization package, causing
disks to be misformatted.
Details: the _Status trap is located 0x623E bytes into CODE segment 1 in
Disk First Aid 1.4. It sets up a zero-initialized ParamBlk which it
fills in with the expected parameters (ioVRefNum and ioRefNum, I think).
It sets csCode=6, and fills in a default value of 16 for csParam. On
return from the _Status trap, the _Status operation has returned an
OSErr of 0 (indicating successful completion), and there's still a value
of 16 in the csParam field. DFA then uses this value to generate what
appears to be a mask of some sort (the resulting value is 0xFF) and
returns to a higher-level routine; the scavenge aborts not too long
thereafter.
I've run the same version of Disk First Aid, and the same System, on two
Mac SE machines here at work. Both SEs have Apple internal 20-meg SCSI
drives. One was formatted some months ago with version 1.x of HD SCSI
Setup; the other was formatted yesterday with version 2.0 (which uses a
different driver).
On both of these SEs, the _Status call with csCode=6 returns a code of
-17, indicating "Not implemented". Disk First Aid 1.4 then skips over
the code that attempts to examine the csParam field from the ParamBlk,
and goes on to complete the scavenging without difficulty.
It appears that underlying problem is that the Rodime driver doesn't
return a "Not implemented" code when it receives a status request it
doesn't understand; the Apple drivers do return "Not implemented", and
thus don't trigger the problem.
The fix for this problem is fairly straightforward, for anybody who has
source code for his/her disk's SCSI driver ;-}. All you'd need to do is
to ensure that the status code in the driver returns a "Not
implemented" code in D0 whenever it's passed a csCode that it doesn't
understand. Disk drivers should _not_ simply ignore such status
requests and return with D0=0.
Question for Apple: What is a _Status call with csParam=6 supposed to
return? I've been told that it isn't mentioned in the sample SCSI
driver available to developers (my copy hasn't arrived from APDA yet,
darnit). What value should be returned in csParam?
--
Dave Platt VOICE: (415) 493-8805
USNAIL: Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303
UUCP: ...!{ames,sun,uunet}!coherent!dplatt DOMAIN: dplatt@coherent.com
INTERNET: coherent!dplatt@ames.arpa, ...@sun.com, ...@uunet.uu.net