J Scott Berg (jsberg@indiana.edu)
Sun, 23 Aug 1998 13:13:12 -0500 (EST)
Hello folks--
I couldn't find an archive for this list, so hopefully I'm not
repeating old stuff here.
I have a Colorado 8GB parallel port TR4 tape drive, and the
associated pain, suffering, and misery. I have thus far been unable
to successfully back up my system. I'm using the 2.0.35 kernel.
Here's what I've figured out so far:
1. The first thing I noticed was an abysmally slow transfer rate.
First, I found I needed to set my parallel port to EPP and not
ECP. Found this by looking through the kernel source--in most
places, HP implies that either ECP or EPP will work (if you're
lucky you find the one obscure place where they say to use EPP).
Even with that,
dd if=/dev/zero of=/dev/pt0 count=xxx
only goes at 44K/s or so (this is measured by using large counts
and finding the marginal incrase in time, so I am taking into
account the initial junk it does).
I hacked into the kernel to get the continuous transfer limit from
the mode_sense call, which was 32K; if I use that as the block size
for the above dd command, things seem to approach the expected
transfer rate. There's also a 32K in pt.c, so I'm not sure if this
is a device related success or a driver related success.
2. Now, I tried a backup using cpio and that blocksize. Two things
happen: the first is that I get a "write DSC timeout" at some point
a little way into the backup. I though this might be a tape
problem, but it occurred with two different tapes. I suspect this
is realted to point 3:
3. I've done the same thing using an internal ATAPI TR4 drive, and the
noises it makes generally consist of long periods of whirring with
occasional breaks. With the dd from /dev/zero, I get a pretty
continuous whir. However, with the cpio backup, I get only short
periods of whirring (few seconds at best) interspersed with short
(<1s) high-pitched whirs. My suspicion of what's happening is that a
block of data is written, the write blocks until it's done; then
nothing is written while the next batch of data is read in by cpio.
Thus the tape must stop, and this stop-and-go process slows everything
down. The write DSC timeout occurs because it takes too long for the
drive to start up after one of these stops (why it doesn't happen
immediately I don't know--is the drive rewinding itself between
writes?).
Right now I'm trying to add a buffering pipeline after cpio to see if
that helps. Any help or insight would be appreciated.
By the way, I patched my kernel to print out the continuous transfer
limit--it would probably be good to have an ioctl return this (as for
ide-tape). My patched pt.c follows. Note also I changed the 128's
to 36's in a couple of the command strings. In practice, it really
doesn't matter, but those numbers do give the buffer size to the ATAPI
controller, so to be safe they should be 36. Note also I store (but
don't print at this point) the buffer size. This is reported as 512K,
but I'm not entirely sure what to do with that figure at this point.
On another note, it would probably be better to print the information
at boot only, not every time the device is opened.
Any hints are appreciated. You're also free to tell me I'm stupid and
tell me the one little thing I need to do to get this all working
smoothly. Thanks
-Scott Berg
*** pt.c.orig Mon Jul 13 15:47:28 1998
--- pt.c Sat Aug 22 22:26:16 1998
***************
*** 569,580 ****
static int pt_identify( int unit )
! { int dt, s;
char *ms[2] = {"master","slave"};
char mf[10], id[18];
char id_cmd[12] = { ATAPI_IDENTIFY,0,0,0,36,0,0,0,0,0,0,0};
! char ms_cmd[12] = { ATAPI_MODE_SENSE,0,0x2a,0,128,0,0,0,0,0,0,0};
! char ls_cmd[12] = { ATAPI_LOG_SENSE,0,0x71,0,0,0,0,0,128,0,0,0};
char buf[36];
s = pt_atapi(unit,id_cmd,36,buf,"identify");
--- 569,580 ----
static int pt_identify( int unit )
! { int dt, s, ctl, bufsz;
char *ms[2] = {"master","slave"};
char mf[10], id[18];
char id_cmd[12] = { ATAPI_IDENTIFY,0,0,0,36,0,0,0,0,0,0,0};
! char ms_cmd[12] = { ATAPI_MODE_SENSE,0,0x2a,0,36,0,0,0,0,0,0,0};
! char ls_cmd[12] = { ATAPI_LOG_SENSE,0,0x71,0,0,0,0,0,36,0,0,0};
char buf[36];
s = pt_atapi(unit,id_cmd,36,buf,"identify");
***************
*** 594,605 ****
PT.flags = 0;
PT.capacity = 0;
PT.bs = 0;
if (!pt_ready_wait(unit,PT_READY_TMO)) PT.flags |= PT_MEDIA;
if (!pt_atapi(unit,ms_cmd,36,buf,"mode sense")) {
if (!(buf[2] & 0x80)) PT.flags |= PT_WRITE_OK;
! PT.bs = xn(buf,10,2);
}
if (!pt_atapi(unit,ls_cmd,36,buf,"log sense"))
--- 594,608 ----
PT.flags = 0;
PT.capacity = 0;
PT.bs = 0;
+ ctl = 0;
if (!pt_ready_wait(unit,PT_READY_TMO)) PT.flags |= PT_MEDIA;
if (!pt_atapi(unit,ms_cmd,36,buf,"mode sense")) {
if (!(buf[2] & 0x80)) PT.flags |= PT_WRITE_OK;
! PT.bs = xn(buf,9,3);
! ctl = xn(buf,24,2);
! bufsz = xn(buf,28,2);
}
if (!pt_atapi(unit,ls_cmd,36,buf,"log sense"))
***************
*** 613,618 ****
--- 616,622 ----
printk(", blocksize %d, %d MB\n",
PT.bs,PT.capacity/1024);
}
+ printk("Recommended block size = %d*%d bytes\n",ctl,PT.bs);
return 0;
}
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2.0b3 on Wed 30 Dec 1998 - 10:18:06 EST