Date: Wed, 27 Mar 1996 00:07:20 +0100 (MET) From: J Wunsch <j@uriah.heep.sax.de> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: hackers@freefall.freebsd.org, gibbs@freebsd.org Subject: Re: Can't read this stupid DAT tape - ARGH! Message-ID: <199603262307.AAA16445@uriah.heep.sax.de> In-Reply-To: <199603262031.MAA00692@time.cdrom.com> from "Jordan K. Hubbard" at Mar 26, 96 12:31:18 pm
next in thread | previous in thread | raw e-mail | index | archive | help
As Jordan K. Hubbard wrote:
> Anyone familar enough with DAT drives to know what an extended-sense
> return of 0x20 (SSD_ILI) means?
``An incorrect length indicator (ILI) bit of one usually indicates that the
requested logical block length did not match the logical block length of the
data on the medium.''
> I'm trying to read a DAT from SGI and the driver returns this code,
> printing it as `st0: 262144-byte record too big' on my console.
Are you sure your DAT drive is able to read 256K blocks at all?
Does ``mt blocksize 0'' and ``dd if=/dev/rst0 ibs=256k ...'' work?
Hmmmmm. It seems that our driver imposes artificial limitations:
j@uriah 262% /sbin/scsi -f /dev/st0ctl.0 -v -c "5 0 0 0 0 0" -i 6 "\
*i1\
{max} i3\
{min} i2"
max: 16777215
min: 1
So my tape drive would support any block length between 1 byte and
16MB-1. However, the biggest tape block i've been able to write was
64 KB, so something on top of st_read() must be chopping the request...
can only by physio()... yup, here's the culprit:
j@uriah 268% fgrep MAXPHYS /usr/include/machine/*
/usr/include/machine/param.h:#define MAXPHYS (64 * 1024) /* max raw I/O transfer size */
I think you gotta bump this one to 256 K, and recompile your world.
--
cheers, J"org
joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603262307.AAA16445>