DAT drive headaches

[Jon Hill]

Hi

I am running Core 2 with a SCSI Controller INITIO INIC 1060P and HP DDS-4 
C5683A DAT drive. I really want to try and get my backup routines sorted for 
Christmas but I am struggling with some errors when creating TAR archives.

the result from mt -f /dev/st0 status is
SCSI 2 tape drive:
File number=-1, block number=-1, partition=0.
Tape block size 0 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (50000):
 DR_OPEN IM_REP_EN

I am getting a lot of the following error messages.

tar: /dev/st0: Cannot read: Input/output error
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers
tar: /dev/st0: Cannot read: Input/output error

On previous attempts (before I manually set the block size), I was seeing a 
lot of these
st0: error 70000 (sugg. bt 0x0, driver bt 0x0, host bt 0x7). inia100:13 0

Can anyone give me some pointers that might help solve this?

Thanks,

Jon

[Terry Polzin]

On Monday 13 December 2004 11:02, Jon Hill wrote:
>  Hi
>
>  I am running Core 2 with a SCSI Controller INITIO INIC 1060P and HP DDS-4
>  C5683A DAT drive. I really want to try and get my backup routines sorted
>  for Christmas but I am struggling with some errors when creating TAR
>  archives.
>
>  the result from mt -f /dev/st0 status is
>  SCSI 2 tape drive:
>  File number=-1, block number=-1, partition=0.
>  Tape block size 0 bytes. Density code 0x0 (default).
>  Soft error count since last status=0
>  General status bits on (50000):
>   DR_OPEN IM_REP_EN
>
>  I am getting a lot of the following error messages.
>
>  tar: /dev/st0: Cannot read: Input/output error
>  tar: Skipping to next header
>  tar: Archive contains obsolescent base-64 headers
>  tar: /dev/st0: Cannot read: Input/output error
>
>  On previous attempts (before I manually set the block size), I was seeing a
>  lot of these
>  st0: error 70000 (sugg. bt 0x0, driver bt 0x0, host bt 0x7). inia100:13 0
>
>  Can anyone give me some pointers that might help solve this?
>  
1) what are the permissions on the device?
2) sample tar command? -- I have found that sometimes hw and sw compression at 
the same time is an issue, and generally use one or the other.

[Wolfgang]

On Mon, 13 Dec 2004 16:02:09 +0000, Jon Hill wrote
>  Hi
>  
>  I am running Core 2 with a SCSI Controller INITIO INIC 1060P and HP 
>  DDS-4 C5683A DAT drive. I really want to try and get my backup 
>  routines sorted for Christmas but I am struggling with some errors 
>  when creating TAR archives.
>  
>  the result from mt -f /dev/st0 status is
>  SCSI 2 tape drive:
>  File number=-1, block number=-1, partition=0.
>  Tape block size 0 bytes. Density code 0x0 (default).
>  Soft error count since last status=0
>  General status bits on (50000):
>   DR_OPEN IM_REP_EN
>  
>  I am getting a lot of the following error messages.
>  
>  tar: /dev/st0: Cannot read: Input/output error
>  tar: Skipping to next header
>  tar: Archive contains obsolescent base-64 headers
>  tar: /dev/st0: Cannot read: Input/output error
>  
>  On previous attempts (before I manually set the block size), I was 
>  seeing a lot of these st0: error 70000 (sugg. bt 0x0, driver bt 0x0, 
>  host bt 0x7). inia100:13 0
>  
>  Can anyone give me some pointers that might help solve this?
>  
>  Thanks,
>  
>  Jon 
Is the Tape drive the ONLY device on that SCSI controller?? If it is shared
with the HDD then you will get these type of errors. If it is, then I'd
suggest to pop in another SCSI controller, and move the Tape Drive there. That
will eliminate those errors. If it's on it's own, then check to see if all the
SCSI bus terminators are correctly installed. As that can also cause these
types of errors.

I had a system here, doing the same thing, putting in another controller
solved that problem.

Wolf
--
Open WebMail Project (http://openwebmail.org)

[Jon Hill]

>  Is the Tape drive the ONLY device on that SCSI controller??  
Yes it is. Its an internal Device. The controller card is supposed to be auto 
terminating, there is no termination plate on the back of the card. The 
system also has SATA drives with a Promise SATA on board controller. I have 
very little knowledge on SCSI, so I could easily have incorrect termination. 
I am not sure what to check for really.

Jon

On Tuesday 14 December 2004 02:55, Wolfgang Gill wrote:
>  On Mon, 13 Dec 2004 16:02:09 +0000, Jon Hill wrote
>
>  > Hi
>  >
>  > I am running Core 2 with a SCSI Controller INITIO INIC 1060P and HP
>  > DDS-4 C5683A DAT drive. I really want to try and get my backup
>  > routines sorted for Christmas but I am struggling with some errors
>  > when creating TAR archives.
>  >
>  > the result from mt -f /dev/st0 status is
>  > SCSI 2 tape drive:
>  > File number=-1, block number=-1, partition=0.
>  > Tape block size 0 bytes. Density code 0x0 (default).
>  > Soft error count since last status=0
>  > General status bits on (50000):
>  >  DR_OPEN IM_REP_EN
>  >
>  > I am getting a lot of the following error messages.
>  >
>  > tar: /dev/st0: Cannot read: Input/output error
>  > tar: Skipping to next header
>  > tar: Archive contains obsolescent base-64 headers
>  > tar: /dev/st0: Cannot read: Input/output error
>  >
>  > On previous attempts (before I manually set the block size), I was
>  > seeing a lot of these st0: error 70000 (sugg. bt 0x0, driver bt 0x0,
>  > host bt 0x7). inia100:13 0
>  >
>  > Can anyone give me some pointers that might help solve this?
>  >
>  > Thanks,
>  >
>  > Jon
>
>  Is the Tape drive the ONLY device on that SCSI controller?? If it is shared
>  with the HDD then you will get these type of errors. If it is, then I'd
>  suggest to pop in another SCSI controller, and move the Tape Drive there.
>  That will eliminate those errors. If it's on it's own, then check to see if
>  all the SCSI bus terminators are correctly installed. As that can also
>  cause these types of errors.
>
>  I had a system here, doing the same thing, putting in another controller
>  solved that problem.
>
>  Wolf
>  --
>  Open WebMail Project (http://openwebmail.org)

[Wolfgang]

On Tue, 2004-12-14 at 20:54, Jon Hill wrote:
>  > Is the Tape drive the ONLY device on that SCSI controller?? 
>  
>  Yes it is. Its an internal Device. The controller card is supposed to be auto 
>  terminating, there is no termination plate on the back of the card. The 
>  system also has SATA drives with a Promise SATA on board controller. I have 
>  very little knowledge on SCSI, so I could easily have incorrect termination. 
>  I am not sure what to check for really.
>  
>  Jon
>  
>  On Tuesday 14 December 2004 02:55, Wolfgang Gill wrote:
>  > On Mon, 13 Dec 2004 16:02:09 +0000, Jon Hill wrote
>  >
>  > > Hi
>  > >
>  > > I am running Core 2 with a SCSI Controller INITIO INIC 1060P and HP
>  > > DDS-4 C5683A DAT drive. I really want to try and get my backup
>  > > routines sorted for Christmas but I am struggling with some errors
>  > > when creating TAR archives.
>  > >
>  > > the result from mt -f /dev/st0 status is
>  > > SCSI 2 tape drive:
>  > > File number=-1, block number=-1, partition=0.
>  > > Tape block size 0 bytes. Density code 0x0 (default).
>  > > Soft error count since last status=0
>  > > General status bits on (50000):
>  > >  DR_OPEN IM_REP_EN
>  > >
>  > > I am getting a lot of the following error messages.
>  > >
>  > > tar: /dev/st0: Cannot read: Input/output error
>  > > tar: Skipping to next header
>  > > tar: Archive contains obsolescent base-64 headers
>  > > tar: /dev/st0: Cannot read: Input/output error
>  > >
>  > > On previous attempts (before I manually set the block size), I was
>  > > seeing a lot of these st0: error 70000 (sugg. bt 0x0, driver bt 0x0,
>  > > host bt 0x7). inia100:13 0
>  > >
>  > > Can anyone give me some pointers that might help solve this?
>  > >
>  > > Thanks,
>  > >
>  > > Jon
>  >
>  > Is the Tape drive the ONLY device on that SCSI controller?? If it is shared
>  > with the HDD then you will get these type of errors. If it is, then I'd
>  > suggest to pop in another SCSI controller, and move the Tape Drive there.
>  > That will eliminate those errors. If it's on it's own, then check to see if
>  > all the SCSI bus terminators are correctly installed. As that can also
>  > cause these types of errors.
>  >
>  > I had a system here, doing the same thing, putting in another controller
>  > solved that problem. 
Yes, the SCSI card will auto terminate, BUT the tape drive will also
have to be terminated as well. There's usually one of two ways, that
this is done. Either the drive has a jumper to enable the terminator, OR
you need to have a terminator on the cable it self. If it's external,
you MAY not have to do that, but it's also possible that it wasn't done,
and will need to be checked. As not having the SCSI bus terminated
properly can/will cause read/write errors.

If that is all ok, then it's also possible that it could be the media,
or the drive itself. I'm not sure what else to suggest.

Wolf

[J. Epperson]

Some folks were allegedly saying:

> >>Is the Tape drive the ONLY device on that SCSI controller?? If
> it is shared
> >>with the HDD then you will get these type of errors. If it is, then I'd
> >>suggest to pop in another SCSI controller, and move the Tape Drive there.
> >>That will eliminate those errors. If it's on it's own, then check to see
> if
> >>all the SCSI bus terminators are correctly installed. As that can also
> >>cause these types of errors.
> >>
> >>I had a system here, doing the same thing, putting in another controller
> >>solved that problem.
>  
>  
>  Yes, the SCSI card will auto terminate, BUT the tape drive will also
>  have to be terminated as well. There's usually one of two ways, that
>  this is done. Either the drive has a jumper to enable the terminator, OR
>  you need to have a terminator on the cable it self. If it's external,
>  you MAY not have to do that, but it's also possible that it wasn't done,
>  and will need to be checked. As not having the SCSI bus terminated
>  properly can/will cause read/write errors.
>  
>  If that is all ok, then it's also possible that it could be the media,
>  or the drive itself. I'm not sure what else to suggest.
>  
The symptoms are consistent with reflectance/termination problems on the 
bus.  Termination for internal drives is usually done at the end of the 
ribbon cable.  It's likely that the cable has at least two device 
connectors, so if there's no terminator, it's often possible to add one 
on the last connector.  Note that something on the bus has to furnish 
TERMPWR--usually one or more devices are jumpered to do so.  Check the 
tape drive doc for jumpers.  I'd also try running a cleaning tape 
through two or three times consecutively.

--W.C. Epperson
***These are my own opinions, but help yourself:  I got a plenty.***

[Gene Heskett]

On Tuesday 14 December 2004 12:16, J. Epperson wrote:
[...]
> The symptoms are consistent with reflectance/termination problems 
on
>  the bus.  Termination for internal drives is usually done at the
>  end of the ribbon cable. 
Correction here.  The scsi cable *is* a transmission line, and
*must* be terminated on both *ends* to control what we in the rf
field call VSWR. A missplaced termination that leaves as little as
4 inches of cable not connected to anything can be enough to make
you start sacrificing virgins, shooting the neighbors cat or
something equally hard on the liguor cabinet.
 
> It's likely that the cable has at least
>  two device connectors, so if there's no terminator, it's often
>  possible to add one on the last connector.  Note that something on
>  the bus has to furnish TERMPWR--usually one or more devices are
>  jumpered to do so.  Check the tape drive doc for jumpers.  I'd also
>  try running a cleaning tape through two or three times
>  consecutively. 
By convention, this is generally furnished by the host
controller, although lots of drives do have a jumper so that they
can furnish this TERMPWR.   IMO it is a mistake to set this jumper
to on, on any drive.  The host controller should furnish this thru
an isolation diode so that no (external to the controller itself)
device connected, is externaly powered, and it has this jumper
set, the resultant nearly 5 volts cannot backfeed into the
computer when the computer is turned off.

Note also that the use of this diode represents a voltage loss,
and for an si (silicon) diode, this is around .7 volts, so TERMPWR
then is not 5 volts, but about 4.3, and that this makes the logic
1 voltage on the buss low enough to have effects on the bus's data
reliability.  Any card found with an si diode in that location
really should have it changed to a schotkey(sp) type as the loss
will then be less than .25 volts, helping that noise margin
considerably.  The so-called 'active terminations' are much more
capable of handling that in comparison to the usual resistive
terminations consisting of a 220 ohm to TERMPWR, and a 330 ohm to
ground on each data line.

> --W.C. Epperson
> ***These are my own opinions, but help yourself:  I got a plenty.*** 
Chuckle, I guess you could say I have a few too.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.30% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.