cruff@ncar.ucar.edu (Craig Ruff) (06/10/91)
I'm trying to write a driver for the TEAC MT-2ST/N50 150MB cassette tape drive. (This is going to be a freely available driver, if I can get it working.) While I can talk to the drive, I'm running into problems with missing data. My questions: Does the SCSI subsystem on A/UX 2.0.1 behave the same way as is documented in the device driver kit (for 2.0)? 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? Is it safe to call scsireq from the completion routine? Why does physio insist on 8192 byte sized chunks? This really inhibits streaming the drive. Thanks in advance. -- Craig Ruff NCAR cruff@ncar.ucar.edu (303) 497-1211 P.O. Box 3000 Boulder, CO 80307
tony@tui.marcam.dsir.govt.nz (Tony Cooper) (06/11/91)
In 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. |> Does the SCSI subsystem on A/UX 2.0.1 behave the same way as is |> documented in the device driver kit (for 2.0)? My driver, written under and for A/UX 1.1, works fine with 2.0.1. |> 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? Good question. I'd much rather have the user decide. |> |> Is it safe to call scsireq from the completion routine? I do. Doesn't mean it's safe however. But I think it was designed to be safe since it is a natural way to set up the next req when the first one is done. |> Why does physio insist on 8192 byte sized chunks? This really |> inhibits streaming the drive. Good question. Even more gooder a question is "Why is there just one physio buffer to be shared by all physical I/O? This means that there can be a long queue of processes all waiting for one buffer to be free". I/O usually occurs in pairs when using tape drives ie from disk to kernel, from kernel to tape. Both I/O's have to share the same buffer so overlapping I/O is not possible. Even more gooderer a question "Why is physio not really phys io?" Ie physio is supposed to copy straight from user space to a device but A/UX copies it to kernel memory first. In practice, none of this makes much difference. The physio buffer is nearly always free, and the size of the buffer does not improve streaming. Try it and see. Cheers, Tony Cooper
urlichs@smurf.sub.org (Matthias Urlichs) (06/12/91)
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)/