wall@ucbvax.ARPA (Steve Wall) (09/28/84)
Yesterday I was trying to read a mag tape with a *very* large block size (I think it was ~80k, but I'm not sure..). I don't know why we received this tape with such a huge block size, but that's not what concerns me. Anyway, I tried to read the thing with the following command: dd if=/dev/rmt12 of=foobar conv=ascii bs=64k and I received the following system error on the read: /dev/rmt12: No such device or address (errno=6, ENXIO) When I changed the dd to: dd if=/dev/rmt12 of=foobar conv=ascii bs=63k NOTE: 63k rather than 64k I no longer got the error message. I'm not extremely knowledgeable about the UNIX I/O system, but this seems rather strange. Is the problem in the I/O system itself, or does it have to do with the device I was talking to (Kennedy 9300 drive, using tm(4) driver)? Is there a maximum buffer size in the I/O system that I was overflowing? The 64k limit suggests something held over from the PDP version of UNIX (We're running 4.2BSD on a 750). I have a feeling it's in the controller or driver, since I don't have trouble reading such large chunks off of a disk. Anyway, I'm fairly confused and would appreciate any help from a wizard or two. I was unable to extract all of the data from the tape because the first (very large) block was truncated. Thanks for the help, Steve Wall ..!ucbvax!wall
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (09/29/84)
The problem is that the tape controller only has a 16-bit register for the byte count to be transferred (via DMA). The number 64K is indistinguishable from 0 using 16-bit arithmetic. Most DMA controllers I have seen would transfer 64K if their byte count register were loaded with 0, although the device driver may decide not to let you try this. Be advised that 80Kb far exceeds the ANSI maximum tape block size.
darrelj@sdcrdcf.UUCP (Darrel VanBuer) (10/03/84)
IBM 360/370 architecture machines can read and write tape blocks over 64k,
but it's tricky; you have to write your own channel program (an I/O program).
(In fact, you have to write your own to go over 32K-1, the OS treats lengths
as 16 bit signed quantity; the hardware count field is 16 bit unsigned, but
you can beat the limit by data chaining [a way to provide another address/
count pair for a continuation of an operation]
--
Darrel J. Van Buer, PhD
System Development Corp.
2500 Colorado Ave
Santa Monica, CA 90406
(213)820-4111 x5449
...{allegra,burdvax,cbosgd,hplabs,ihnp4,orstcs,sdcsvax,ucla-cs,akgua}
!sdcrdcf!darrelj
VANBUER@USC-ECL.ARPAcdl@mplvax.UUCP (Carl Lowenstein) (10/06/84)
Since the TM-11 controller has been around since forever (early 1970's) it has a 16-bit byte count register. The software implication of this hardware feature is that there is no way to read or write a single record containing more than 65536 bytes. This same 16-bit byte count register is present in all the emulated TM-11 hardware that I am aware of, since there is no obvious way to extend the original controller architecture.