Hello all,

I'm running SCO OSR5.07. My IBM DDS4 SCSI tape drive was getting really
slow durring the night and I noticed a lot of File Syncronization [W011]
and 1 block checksum errors [W033] from BRU

So I got a new tape drive, identical to the old one. All the functions
work except it can't read or write to the tapes. SCSI BIOS detects it
fine, OSR drivers seem to be loaded fine, tape commands rewind and
unload the tape, but BRU hangs when trying to write to the device.

At one point OSR5 complained about a SCSI Parity error, but I could only
get that once, now all I can get it to do is hang BRU so it can't even
be killed.

NOTICE: Stp: Error on SCSI tape 0 (ha=0 bus=0 id=6 lun=0)
Command aborted: Drive detected a SCSI parity error

This error showed up on the screen, and in the syslog, but not in the
BRU log. I shut the system down, checked all cables and connections,
dbl checked the jumpers and started it back up, now all I get is BRU
stuck trying to write a test directory.

Is there anything I need to do to for the new drive, or maybe I just got
lucky and got a bad one?

Any help is appreciated.

cheers

Skot

Skot wrote:

> Hello all,
>
> I'm running SCO OSR5.07. My IBM DDS4 SCSI tape drive was getting really
> slow durring the night and I noticed a lot of File Syncronization [W011]
> and 1 block checksum errors [W033] from BRU
>
> So I got a new tape drive, identical to the old one. All the functions
> work except it can't read or write to the tapes. SCSI BIOS detects it
> fine, OSR drivers seem to be loaded fine, tape commands rewind and
> unload the tape, but BRU hangs when trying to write to the device.
>
> At one point OSR5 complained about a SCSI Parity error, but I could only
> get that once, now all I can get it to do is hang BRU so it can't even
> be killed.
>
> NOTICE: Stp: Error on SCSI tape 0 (ha=0 bus=0 id=6 lun=0)
> Command aborted: Drive detected a SCSI parity error
>
> This error showed up on the screen, and in the syslog, but not in the
> BRU log. I shut the system down, checked all cables and connections,
> dbl checked the jumpers and started it back up, now all I get is BRU
> stuck trying to write a test directory.
>
> Is there anything I need to do to for the new drive, or maybe I just got
> lucky and got a bad one?
>
> Any help is appreciated.
>
> cheers
>
> Skot

Carefully check the dip switches on the old and new drives. Make the new
one look like th old one.

I'll bet hardware compression settings are different between the drives.

--
----------------------------------------------------
Pat Welch, UBB Computer Services, a WCS Affiliate
SCO Authorized Partner
Unix/Linux/Windows/Hardware Sales/Support
(209) 745-1401 Fax: (267) 295-8418
Nationwide pager: (800) 608-7122
E-mail: patubb@inreach.com
----------------------------------------------------

On Mon, 12 Jan 2004 22:24:00 GMT, Skot <skot@canada.com> wrote:

>Hello all,
>
>I'm running SCO OSR5.07. My IBM DDS4 SCSI tape drive was getting really
>slow durring the night and I noticed a lot of File Syncronization [W011]
>and 1 block checksum errors [W033] from BRU
>
>So I got a new tape drive, identical to the old one. All the functions
>work except it can't read or write to the tapes. SCSI BIOS detects it
>fine, OSR drivers seem to be loaded fine, tape commands rewind and
>unload the tape, but BRU hangs when trying to write to the device.
>
>At one point OSR5 complained about a SCSI Parity error, but I could only
>get that once, now all I can get it to do is hang BRU so it can't even
>be killed.
>
>NOTICE: Stp: Error on SCSI tape 0 (ha=0 bus=0 id=6 lun=0)
> Command aborted: Drive detected a SCSI parity error
>
>This error showed up on the screen, and in the syslog, but not in the
>BRU log. I shut the system down, checked all cables and connections,
>dbl checked the jumpers and started it back up, now all I get is BRU
>stuck trying to write a test directory.
>
>Is there anything I need to do to for the new drive, or maybe I just got
>lucky and got a bad one?
>
>Any help is appreciated.
>
>cheers
>
>Skot

What happens if you use the stock tar or cpio? Same problems?

As Pat Welch mentioned, double check dip-switches as well.


Scott McMillan

Scott McMillan wrote:
>
> On Mon, 12 Jan 2004 22:24:00 GMT, Skot <skot@canada.com> wrote:
>
> >Hello all,
> >
> >I'm running SCO OSR5.07. My IBM DDS4 SCSI tape drive was getting really
<sweep>
> >
> >This error showed up on the screen, and in the syslog, but not in the
> >BRU log. I shut the system down, checked all cables and connections,
> >dbl checked the jumpers and started it back up, now all I get is BRU
> >stuck trying to write a test directory.
> >
> >Is there anything I need to do to for the new drive, or maybe I just got

>
> What happens if you use the stock tar or cpio? Same problems?

Yeah, same thing. BRU is not broken.

> As Pat Welch mentioned, double check dip-switches as well.

<snippet>
> >BRU log. I shut the system down, checked all cables and connections,
> >dbl checked the jumpers
</snippet>

Welp, I pulled the box apart again at 03:00 this morning, this time
replaced the terminated cable and re-seated the SCSI card, now the new
drive is working. Freaky.

Cheers, Pat and Scott, for the attempt.

Skot.

In article <7_PMb.41812$8H.97586@attbi_s03>,
Pat Welch <patubb@inreach.com> wrote:
>Skot wrote:
>
>> Hello all,
>>
>> I'm running SCO OSR5.07. My IBM DDS4 SCSI tape drive was getting really
>> slow durring the night and I noticed a lot of File Syncronization [W011]
>> and 1 block checksum errors [W033] from BRU
>>
>> So I got a new tape drive, identical to the old one. All the functions
>> work except it can't read or write to the tapes. SCSI BIOS detects it
>> fine, OSR drivers seem to be loaded fine, tape commands rewind and
>> unload the tape, but BRU hangs when trying to write to the device.
>>
>> At one point OSR5 complained about a SCSI Parity error, but I could only
>> get that once, now all I can get it to do is hang BRU so it can't even
>> be killed.
>>
>> NOTICE: Stp: Error on SCSI tape 0 (ha=0 bus=0 id=6 lun=0)
>> Command aborted: Drive detected a SCSI parity error
>>
>> This error showed up on the screen, and in the syslog, but not in the
>> BRU log. I shut the system down, checked all cables and connections,
>> dbl checked the jumpers and started it back up, now all I get is BRU
>> stuck trying to write a test directory.
>>
>> Is there anything I need to do to for the new drive, or maybe I just got
>> lucky and got a bad one?
>>
>> Any help is appreciated.

>Carefully check the dip switches on the old and new drives. Make
>the new one look like th old one.

>I'll bet hardware compression settings are different between the
>drives.

A funny aside. I had a place that called me in and I diagnosed it
as a bad tape drive. So the owner ordered a new tape drive, set
the DIP switches just like the old one, and put it in place.

He figured he'd save money by not having me come and do something
so simple.

He had bought a different brand of tape drive whose DIP switches
weren't the same, so he had to pay me anyway to come and find out
his self-created problem.



--
Bill Vermillion - bv @ wjv . com

Bill Vermillion wrote:
>
<sweep>
>
> A funny aside. I had a place that called me in and I diagnosed it
> as a bad tape drive. So the owner ordered a new tape drive, set
> the DIP switches just like the old one, and put it in place.
>
> He figured he'd save money by not having me come and do something
> so simple.
>
> He had bought a different brand of tape drive whose DIP switches
> weren't the same, so he had to pay me anyway to come and find out
> his self-created problem.

LMAO

That's almost as funny as the client that figures they don't need a
backup at all because $500 for a new tape drive is more then they are
willing to spend as they are getting a whole new system, HW and SW,
soon. A week later a lightening strike takes out their UW2.x boxen.
Still a year (soon) before they get the new system. I don't know how
they are running their business now. =P

In article <40056F5B.8A155303@canada.com>, Skot <skot@canada.com> wrote:
>Bill Vermillion wrote:
>>
><sweep>
>>
>> A funny aside. I had a place that called me in and I diagnosed it
>> as a bad tape drive. So the owner ordered a new tape drive, set
>> the DIP switches just like the old one, and put it in place.
>>
>> He figured he'd save money by not having me come and do something
>> so simple.
>>
>> He had bought a different brand of tape drive whose DIP switches
>> weren't the same, so he had to pay me anyway to come and find out
>> his self-created problem.

>LMAO

>That's almost as funny as the client that figures they don't need a
>backup at all because $500 for a new tape drive is more then they are
>willing to spend as they are getting a whole new system, HW and SW,
>soon. A week later a lightening strike takes out their UW2.x boxen.
>Still a year (soon) before they get the new system. I don't know how
>they are running their business now. =P

I had a client like that who though the cost of a new tape drive
was too much. I told him "I have an idea on how you can pay for
the new tape drive and have money left over, are you interested".

When he replied in the affirmative I told him "Cancel your fire
insurance, that the money, buy the tape drive, and with what's left
over had a party, because your computer WILL crash before your
building burns down".

I was pretty safe in saying that because I knew his building.

Later he sold that company to another group, and his new company
turned out to a dot.bomb that went through a few million before it
went *poof". The company he sold it got some Linux
people in and took out the SCO and bought a Linux version of their
database, and they did some strange kludges as they had no idea of
how the program worked. But they never got a tape backup running.
The could have easily used the big ?? 1GB QIC tape from the
decomissioned SCO system - but instead of running as is - which was
just fine - they build a new system.

He took this company back as they had defaulted on payments and this
new building DID burn down and took out everything.

The only backup was the one the Linux people had made by dragging
files via samba onto an MS CD-RW disk. The people doing his HW
suggested sending the hard drive to a recovery firm when they found
out how much I'd charge to bring the database back to life.

There were many processing tables that were not unique in the 8
character MS name space, and of course everything was converted to
upper case and all the processing tables called things by their
lower case name. [The application was filePro BTW]. I told him
it would take a minimum of 100 hours work to resureect this file by
file and then test all the processing. That would easily be about
10 times the cost of the tape drive. Recovering the data from the
thoroughly toasted drive would also be in the same neighborhood.

Some days you just can't win.

--
Bill Vermillion - bv @ wjv . com