Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!ira.uka.de!smurf!urlichs
From: urlichs@smurf.sub.org (Matthias Urlichs)
Newsgroups: comp.unix.aux
Subject: Re: SCSI Subsystem questions
Message-ID: <1+A-K9#@smurf.sub.org>
Date: 11 Jun 91 21:47:22 GMT
References: <11748@ncar.ucar.edu>
Organization: University of Karlsruhe, FRG
Lines: 37

In comp.unix.aux, article <11748@ncar.ucar.edu>,
  cruff@ncar.UCAR.EDU (Craig Ruff) writes:
< I'm trying to write a driver for the TEAC MT-2ST/N50 150MB cassette tape drive.
< While I can talk to the drive, I'm running into problems with missing data.
Not just you...

< My questions:
< 
< 	Why does the SCSI subsystem insist on aborting a command that
< 	does not transfer as much data as you requested (i.e. SST_MORE)?
< 	Why not complete normally and let the caller decide?
< 
Because that's an A/UX bug.

In fact, the data did get transmitted but the SCSI subsystem still says "zero
bytes -- error". If it said "xxx bytes -- error" I (and several other people)
could live with it.
After such an error, BTW, things like the Apple tape tend to lock the bus
until you turn them off. Uggh. Does anybody know a way to avoid that?

< 	Is it safe to call scsireq from the completion routine?
< 
Seems so.

< 	Why does physio insist on 8192 byte sized chunks?  This really
< 	inhibits streaming the drive.
< 
In most cases, the bottleneck is the program that writes to / reads from the
tape (no double-buffering). Granted that physio should lock down the chunks
in user space and let the program get its data directly from there, but at
physio time there's no such thing as a user data space, and so it seems that
the A/UX people took the easy way out; as it is, it seems not to be the
bottleneck, so why bother.

-- 
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de     /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49-721-621127(0700-2330)   \o)/