[784] in linux-scsi channel archive
Re: SCSI scanner project
daemon@ATHENA.MIT.EDU (Kenneth Stailey)
Wed Nov 8 23:20:21 1995
Date: Wed, 8 Nov 1995 11:58:49 -0500
From: Kenneth Stailey <kstailey@owl.dol-esa.gov>
To: johnsonm@nigel.vnet.net
CC: linux-scsi@vger.rutgers.edu, kstailey@owl.dol-esa.gov
In-reply-to: <199511081721.MAA17252@nigel.vnet.net> (johnsonm@nigel.vnet.net)
Note that only the bottom part of this message is general enough to go
to "linux-scsi" but my mailer doesn't forward on a byte-by-byte level.
"Michael K. Johnson" <johnsonm@nigel.vnet.net> writes:
> I'd suggest that before redistributing [the UMAX scanner CDB docs]
> further in the future, check with me first to make sure I haven't
> improved it again.
OK I'll do that.
I have a paper copy of the UC-630 version of the document you e-mailed to me.
I will be able to compare them to see how similar they are.
The UMAX UC-630 scanner does some nasty undocumented stuff too. It has a
behavior I called "falling off the bus" where after sending certain
commands it would return a SCSI message (or something) that suggested it
was ready for another command when this simply wasn't the case. To work
around this I added a routine to loop doing TEST UNIT READY and sleeping
a couple of seconds until TEST UNIT READY returns OK. My guess is that
they were trying to do a bogus version of SCSI disconnect since the
scanner didn't support disconnect, but you could get to other peripherals
while the scanner was in this state. The scanner would enter this state
when it was done sending data and moving the lamp back to the home
position and certain other times (look inside PINT for the "find_umax"
routine in pint-0.5d/sunos4.1/driver/scan.c and see when it was called.)
Has anyone ever seen another SCSI peripheral that does this?
Just curious,
~Ken
