Hi, Jim!
Trying to kill the keyboard, Jim Rankin ([EMAIL PROTECTED])
produced 6,4K in 143 lines:
> Wolfgang Weisselberg wrote:
> > Trying to kill the keyboard, Jim Rankin ([EMAIL PROTECTED])
> > produced 1,8K in 47 lines:
> > > it turns out that if the tape file is large enough, ftape does lose the
> > > location of beginning of tape still.
> > Hmmm ... BOT (begin of tape) is hardware-detected by a (series
> > of) holes in the tape. So that is probably not the reason ...
> I'm executing
> gunzip -c disktarfile.tgz | dd of=/dev/ftape obs=10k
> where I have used mt to setblk 0 on rft0 first. Yes, ftape points to
> rft0.
ftmt setblk 0 is probably only necessary if you do not pad
the data. dd can do this, if you tell it to (using (ibs or bs)
and sync). On the other hand, with setblk 0 you need not to
use dd at all, IIRC. (Can't test it, don't have the hardware
any more.)
> It starts like this when the file is basically all written (I think):
> Dec 5 04:33:10 jrankin kernel: [054] ftape-io.c
> (ftape_report_error_R999edffd) - errorcode: 39.
./Doc/html/qic117.h says (and so does ./include/linux/qic117.h):
/*39*/ { "EOT/BOT System Failure", 1, },\
> Dec 5 04:33:10 jrankin kernel: [056] ftape-io.c
> (ftape_report_error_R999edffd) - errorcode: 20.
same place:
/*20*/ { "Self-Diagnostic Failed (cannot be cleared)", 1, },\
> (ftape_wait_segment) - Unknown error.
> (ftape_start_tape) - panic: location not known.
Guess you have a flaky drive, then, these errorcodes from the
tape drive are fatal.
-Wolfgang
