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.netdplatt@coherent.com (Dave Platt) (07/15/88)
I've received some confirmation from various quarters that Apple has, in
fact, changed the SCSI-disk-driver interface somewhat in System 6.0, and
that this change is causing a number of third-party SCSI drivers to
malfunction.
All drivers (disk drivers, sound drivers, desk accessories, etc.)
provide a "status" interface which accepts a ParamBlk. The ParamBlk
contains a "csCode" in which the caller identifies the particular kind
of status information being requested, and a "csParam" record in which
the driver stores the resulting status information. Inside Mac states
that the meanings of the csCode and csParam are driver-specific.
In its sample SCSI driver (on which many third-party drivers are based),
Apple simply stubbed out the status routine... it returned a "not
implemented" error code for all csCode inputs. Prior to the release of
System 6.0, Apple system software apparently did not call the _Status
trap for disk drivers, and did not require drivers to return status
information.
Some third-party SCSI drivers (including the one used by Micah, and
perhaps the one used by Rodime as well) use the _Status call to retrieve
device-specific information from the driver... Micah's driver apparently
returns a portion of the SCSI "sense" information to the caller, based
on the csCode. Based on what I've been able to read in IM, the tech
notes, etc., this is a legitimate use of the _Status call; it doesn't
seem to violate any of Apple's published guidelines.
In System 6.0, Apple has added code to Disk First Aid 1.4, and
apparently to the disk-initialization package, that assumes that a
_Status call with csCode=6 returns some driver information having to do
with disk capacities. If a driver can't return the indicated data, it
_must_ return an error code of some sort (Apple's drivers for the HD20SC
return a "not implemented" code). In effect, Apple has preempted all
other vendors' uses of a csCode=6 status call.
This wouldn't have been a terrible problem, except that it appears that
Apple made this change without notifying third-party disk developers
that the change was going to occur (let alone documenting what this code
is supposed to do)! As a result, disk drivers that use the _Status
interface for vendor-specific purposes tend to break under System 6.0.
I've looked through IM and the tech notes available to me (most of
them), and I can't see any indication that Apple ever declared a
specific range of csCode values to be "reserved for Apple use" (as
they've done with resource numbers, etc.).
BOO! HISS!
I seem to call that Apple has taken some hits in the past, for changing
The Rules "on the fly" and breaking programs that had previously been
entirely legitimate and by-the-book. Apple has certainly taken some bad
press for releasing System 6.0 in a not-entirely-debugged state, without
allowing adequate time for third-party testing and compatibility
checking. Based on what I've seen, it appears that Apple goofed in both
of these ways when it decided to change the disk-driver interface.
[Robert Heinlein once wrote that every army, regardless of its formal
organization structure, is actually composed of three parts: the
Surprise Party Department, the Practical Joke Department, and the Fairy
Godmother Department (the latter consisting of a single GS-3 clerk who's
usually out sick). I think the Surprise Party Department gets the
credit for this latest little snafu.]
Fortunately, the problems that result from this little bobble aren't too
hard to work around... boot System 4.2 before formatting, initializing,
or erasing your third-party disk drives if you've noticed problems under
6.0. I haven't seen any problems occur while actually _using_ one of
the affected disks under 6.0, as long as it was initialized under an
earlier version of the system.
--
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.netearleh@eleazar.dartmouth.edu (Earle R. Horton) (07/16/88)
In article <6683@coherent.com> dplatt@coherent.com (Dave Platt) writes: ... >I've received some confirmation from various quarters that Apple has, in >fact, changed the SCSI-disk-driver interface somewhat in System 6.0, and >that this change is causing a number of third-party SCSI drivers to >malfunction. ... >Fortunately, the problems that result from this little bobble aren't too >hard to work around... boot System 4.2 before formatting, initializing, >or erasing your third-party disk drives if you've noticed problems under >6.0. I haven't seen any problems occur while actually _using_ one of >the affected disks under 6.0, as long as it was initialized under an >earlier version of the system. WELL, I HAVE!! The NOVA 30 by MicroTech won't work AT ALL with System Tools 6.0 on a Mac Plus. This is a unit which was initialized under System 4.2, and used successfully for months. Booting from the Version 6.0 System Tools floppy, with the NOVA turned on, gets me a "This Disk is Damaged, Do You Want to Initialize It?" dialog, with the NOVA HD Icon in it. I shudder to think what would have happened had I chosen "Initialize!" A call to MicroTech resulted in assurances that they were working on a driver which would be ready "real soon now" and the technician taking my name, address, and disk serial number so they could mail me one. He also said something to the effect: "Yeah, Apple changed a bunch of stuff and didn't tell us about it." The way they are working around the new SCSI interface is they have disassembled the new Apple code, and are working on a new driver/formatter. Disassembling the code? Doesn't Apple tell their 3rd-party developers anything? Nice goin' Apple! Disassembly of resource 'PTCH' #117 in the new System file reveals that Apple seems to have hung a bunch of stuff on top of the SCSIDispatch trap call, to what end I can only guess. Personally, I don't think I really need any of this stuff, and would like to try out the new System BEFORE MicroTech fixes their format program. Since I think Disk First Aid is useless, and use the MicroTech driver for my disk, and only have the one hard disk on my Mac Plus, I figured I would find where SCSIDispatch gets patched and rip the little sucker out for now: File: System Resource: 'PTCH' #117 Offset: 000045E8 Patch: 303C 0015 A647 --> 303C 0015 4E71 ^^^^ ^^^^ The NOVA has worked all day with System Tools 6.0 installed on it, and the SCSIDispatch patch bypassed. Performance appears normal, and everybody is happy. The Mac Plus goes "Clink-Klank" when I hit ^G in emacs, etc., etc... Earle Horton Disclaimer: Apply this patch at your own risk. Use Apple Computer Company equipment under the same conditions. Earle R. Horton. H.B. 8000, Dartmouth College, Hanover, NH 03755