urlichs@smurf.sub.org (Matthias Urlichs) (04/01/91)
In comp.unix.aux, article <50924@apple.Apple.COM>, chuq@Apple.COM (Chuq Von Rospach, net.god {retired}) writes: < domo@tsa.co.uk (Dominic Dunlop) writes: < < >>For example SCSIProbe2.01 crashes. < < As will anything that diddles directly with the hardware or wants to play < with the SCSI bus, since neither aciton is allowed by A/UX right now. < Actually, it's possible to hack rudimentary SCSI support into A/UX. The stuff I wrote actually works, but only for playing around; i.e. you can use SCSIProbe or SEdit without any problems whatever, but try actually installing a driver and the system hangs. Debugging SCSI without an appropriate analyzer (and also no terminal to use with the kernel debugger, if necessary) is next to impossible. I'd like some help from anybody with the appropriate facilities and/or expertise, in order to get that bug out... Hardware like Apple's tape (which tend to hang the bus when given wrong data lengths, but only under A/UX of course or life would be too easy) doesn't help either. Neither does not having the 2.0.1 device driver development kit, assuming that it even exists by now... -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\ Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49-721-621127(0700-2330) \o)/
ksand@Apple.COM (Kent Sandvik) (04/02/91)
In article <B+M_L3.@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: >In comp.unix.aux, article <50924@apple.Apple.COM>, > chuq@Apple.COM (Chuq Von Rospach, net.god {retired}) writes: >< domo@tsa.co.uk (Dominic Dunlop) writes: >< >>For example SCSIProbe2.01 crashes. >< As will anything that diddles directly with the hardware or wants to play >< with the SCSI bus, since neither aciton is allowed by A/UX right now. >Actually, it's possible to hack rudimentary SCSI support into A/UX. The _SCSIDispatch trap is not implemented, so anything that tries to use this trap would have problems. >The stuff I wrote actually works, but only for playing around; i.e. you can >use SCSIProbe or SEdit without any problems whatever, but try actually >installing a driver and the system hangs. I'm curious to know what traps and parameter blocks you used. >Debugging SCSI without an appropriate analyzer (and also no terminal to use >with the kernel debugger, if necessary) is next to impossible. >I'd like some help from anybody with the appropriate facilities and/or >expertise, in order to get that bug out... Try to use the kernel debugger available in A/UX 2.0. Information about using the debugger should be in the A/UX Dev Driver's manual. Hope this helps, Kent -- Disclaimer: *Private* activity on the Net, in no way connected to any company. Any sexually or racially sounding statements in the text are not intentional. Please send email about grammar or spelling errors to ksand@apple.com This .signature starts to resemble a legal contract...
urlichs@smurf.sub.org (Matthias Urlichs) (04/03/91)
In comp.unix.aux, article <12852@goofy.Apple.COM>,
ksand@Apple.COM (Kent Sandvik) writes:
<
< The _SCSIDispatch trap is not implemented, so anything that tries to
< use this trap would have problems.
<
So you write an INIT which implements _SCSIDispatch. The trap then opens the
appropriate device and translates your command into meaningful ioctl calls.
Not really difficult if you concentrate on a 95% solution (which in the real
world is sufficient for 99.5% of all existing drivers).
< I'm curious to know what traps and parameter blocks you used.
<
Standard Inside Mac IV, except that there's no SCSIstatus, the timeout is
calculated from the command, and TIBs must contain one data transfer and one
optional loop command. (No driver I tested did anything else anyway.)
The notable exception is SilverLining, which even in its present form insists
on directly accessing SCSI hardware to test the bus status instead of using
the appropriate SCSIDispatch call. Not good.
I had to set the appropriate bit in the HWConf flags because too many
applications test that bit when they really want to test whether
_SCSIDispatch exists.
< >Debugging SCSI without an appropriate analyzer (and also no terminal to use
< >with the kernel debugger, if necessary) is next to impossible.
< >I'd like some help from anybody with the appropriate facilities and/or
< >expertise, in order to get that bug out...
<
< Try to use the kernel debugger available in A/UX 2.0. Information
< about using the debugger should be in the A/UX Dev Driver's manual.
The problem is that the kernel debugger needs a second Mac with the
appropriate sources available, and a serial connection. I don't have kernel
sources (the dev driver stuff is not really sufficient for that kind of
hangup problem -- the most common case is that the A/UX itself still runs
without problems, but the SCSI subsystem hangs) and a second Mac is also not
available either.
A related problem is that I don't know how to prevent my driver and another
SCSI driver (eg. the standard A/UX SCSI stuff) to access the same drive at
the same time without locking the entire bus.
As I said, knowledgeable help with this would be appreciated.
--
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49-721-621127(0700-2330) \o)/