SEO

I replaced a failed SCSI tape drive on an OSR507 system and subsequently
get this message at start-up:

NOTICE: cha: SCSI bus has been reset ha=1
Attached SCSI peripherals will return to power up state \
(cha N04)
NOTICE: cha: Unexpected SCSI phase change \
ha=1 id=6 lun=0 cmd=12 blk=0 len=36
A SCSI peripheral behaved unexpectedly
Use Compaq diagnostics to confirm a hardware failure \
(chaN02)

After that, the new tape drive works fine!

The server is a 1999 Compaq Proliant 1600 with a dual channel integrated
Ultra-Wide SCSI-3 controller. The tape is the only device on the
secondary channel (non-RAID discs on the primary).

The old tape drive was a C1539 4/8GB DAT. This was connected to the SCSI
cable via an adapter since it was a plain SCSI-2 device with older style
connector (50 pin SE?). This had been working fine since 1999.

The new drive is a C5686B 40Gb DAT which is an Ultra Wide LVD device
with a 68-pin high density connector. The manual says it should work on
almost any SCSI bus (with performance degradation) except HVD. The
68-pin connector on the drive matched those on the existing SCSI cable
so I plugged it in directly. The SCSI cable has a terminator on the
end. Drive jumpers/DPI-switches were left at default (except SCSI ID
changed from 3 to 6 to match old drive).

The new tape drive was supplied with a SCSI cable which is clearly of a
later design (twisted pair ribbon in a tubular sleeve) than the 1999
proliant part (flat ribbon cable) but I didn't fit that since the
connector on the motherboard is relatively inaccessible.

Since the tape works fine in the tests I have done (3x faster than old
drive), I'm not sure whether I should worry about the error message.

Choices seem to be:
- Run HP diagnostics and see if anything is clarified.
- Replace the SCSI cable.
- ignore it and see what happens.

Has anyone encountered anything similar?
Can anyone explain what the error messages really mean?

Thanks for any thoughts on this.

Ian Wilson wrote:
> I replaced a failed SCSI tape drive on an OSR507 system and subsequently
> get this message at start-up:
>
> NOTICE: cha: SCSI bus has been reset ha=1
> Attached SCSI peripherals will return to power up state \
> (cha N04)
> NOTICE: cha: Unexpected SCSI phase change \
> ha=1 id=6 lun=0 cmd=12 blk=0 len=36
> A SCSI peripheral behaved unexpectedly
> Use Compaq diagnostics to confirm a hardware failure \
> (chaN02)


http://aplawrence.com/SCOFAQ/FAQ_scotec6cha.html ?


--
Tony Lawrence
Unix/Linux/Mac OS X resources: http://aplawrence.com
Geek Yard Sale: http://geekyardsale.com

Tony Lawrence wrote:
> Ian Wilson wrote:
>
>> I replaced a failed SCSI tape drive on an OSR507 system and
>> subsequently get this message at start-up:
>>
>> NOTICE: cha: SCSI bus has been reset ha=1
>> Attached SCSI peripherals will return to power up state \
>> (cha N04)
>> NOTICE: cha: Unexpected SCSI phase change \
>> ha=1 id=6 lun=0 cmd=12 blk=0 len=36
>> A SCSI peripheral behaved unexpectedly
>> Use Compaq diagnostics to confirm a hardware failure \
>> (chaN02)
>
>
>
> http://aplawrence.com/SCOFAQ/FAQ_scotec6cha.html ?
>
>

Doh! I should have looked there before posting.
Thanks Tony.

Ian Wilson wrote:

> Tony Lawrence wrote:
> > Ian Wilson wrote:
> >
> >> I replaced a failed SCSI tape drive on an OSR507 system and
> >> subsequently get this message at start-up:
> >>
> >> NOTICE: cha: SCSI bus has been reset ha=1
> >> Attached SCSI peripherals will return to power up state \
> >> (cha N04)
> >> NOTICE: cha: Unexpected SCSI phase change \
> >> ha=1 id=6 lun=0 cmd=12 blk=0 len=36
> >> A SCSI peripheral behaved unexpectedly
> >> Use Compaq diagnostics to confirm a hardware failure \
> >> (chaN02)
> >
> > http://aplawrence.com/SCOFAQ/FAQ_scotec6cha.html ?
>
> Doh! I should have looked there before posting.
> Thanks Tony.

The advice it gives:

"int cha_print_warnings=0;"

seems a little questionable to me. You don't know what other warnings
it might turn off (media error messages? "The controller hardware
reports it's about to die"?) I recommend leaving the warning on and
simply ignoring it.

>Bela<

Bela Lubkin wrote:
> Ian Wilson wrote:
>
>
>>Tony Lawrence wrote:
>>
>>>Ian Wilson wrote:
>>>
>>>
>>>>I replaced a failed SCSI tape drive on an OSR507 system and
>>>>subsequently get this message at start-up:
>>>>
>>>>NOTICE: cha: SCSI bus has been reset ha=1
>>>> Attached SCSI peripherals will return to power up state \
>>>> (cha N04)
>>>>NOTICE: cha: Unexpected SCSI phase change \
>>>> ha=1 id=6 lun=0 cmd=12 blk=0 len=36
>>>> A SCSI peripheral behaved unexpectedly
>>>> Use Compaq diagnostics to confirm a hardware failure \
>>>> (chaN02)
>>>
>>>http://aplawrence.com/SCOFAQ/FAQ_scotec6cha.html ?
>>
>>Doh! I should have looked there before posting.
>>Thanks Tony.
>
>
> The advice it gives:
>
> "int cha_print_warnings=0;"
>
> seems a little questionable to me. You don't know what other warnings
> it might turn off (media error messages? "The controller hardware
> reports it's about to die"?) I recommend leaving the warning on and
> simply ignoring it.
>

Ideally you'd be able to suppress notices and still receive warnings.

I looked in /etc/conf/pack.d/cha/space.c and found this:

/* Should NOTICE messages from the driver be printed?
Each possible NOTICE message is associated with one
bit in cha_print_notices. The value -1 turns on all the bits.
The value 0 suppresses all NOTICE messages.
To turn off message CHAN03, turn off bit 03.
*/
int cha_print_notices = -1; /* 0 to supress all notices */

Tony - you might like to update the SCOFAQ? If I get time, I'll try
setting cha_print_notices to 0 and report back here.

The documentation (man HW cha) says "Although they may be recoverable,
you should attempt to determine their root cause and correct it." I
don't think I want to play around with the hardware too much.

I'll just ignore the messages for now.

Ian Wilson wrote:

>
> Tony - you might like to update the SCOFAQ? If I get time, I'll try
> setting cha_print_notices to 0 and report back here.
>
> The documentation (man HW cha) says "Although they may be recoverable,
> you should attempt to determine their root cause and correct it." I
> don't think I want to play around with the hardware too much.
>
> I'll just ignore the messages for now.

Faq updated with a link to that post.


--
Tony Lawrence
Unix/Linux/Mac OS X resources: http://aplawrence.com
Geek Yard Sale: http://geekyardsale.com

Ian>>>>> I replaced a failed SCSI tape drive on an OSR507 system and
Ian>>>>> subsequently get this message at start-up:
Ian>>>>>
Ian>>>>> NOTICE: cha: SCSI bus has been reset ha=1
Ian>>>>> Attached SCSI peripherals will return to power up state \
Ian>>>>> (cha N04)
Ian>>>>> NOTICE: cha: Unexpected SCSI phase change \
Ian>>>>> ha=1 id=6 lun=0 cmd=12 blk=0 len=36
Ian>>>>> A SCSI peripheral behaved unexpectedly
Ian>>>>> Use Compaq diagnostics to confirm a hardware failure \
Ian>>>>> (chaN02)

Tony>>>> http://aplawrence.com/SCOFAQ/FAQ_scotec6cha.html ?

Bela>> The advice it gives:
Bela>>
Bela>> "int cha_print_warnings=0;"
Bela>>
Bela>> seems a little questionable to me. You don't know what other warnings
Bela>> it might turn off (media error messages? "The controller hardware
Bela>> reports it's about to die"?) I recommend leaving the warning on and
Bela>> simply ignoring it.

Ian> Ideally you'd be able to suppress notices and still receive warnings.
Ian>
Ian> I looked in /etc/conf/pack.d/cha/space.c and found this:
Ian>
Ian> /* Should NOTICE messages from the driver be printed?
Ian> Each possible NOTICE message is associated with one
Ian> bit in cha_print_notices. The value -1 turns on all the bits.
Ian> The value 0 suppresses all NOTICE messages.
Ian> To turn off message CHAN03, turn off bit 03.
Ian> */
Ian> int cha_print_notices = -1; /* 0 to supress all notices */
Ian>
Ian> Tony - you might like to update the SCOFAQ? If I get time, I'll try
Ian> setting cha_print_notices to 0 and report back here.
Ian>
Ian> The documentation (man HW cha) says "Although they may be recoverable,
Ian> you should attempt to determine their root cause and correct it." I
Ian> don't think I want to play around with the hardware too much.
Ian>
Ian> I'll just ignore the messages for now.

Well, it seems odd that the FAQ says to set `cha_print_warnings' to 0
when the messages you're trying to silence are labeled "NOTICE".

But, all that aside, I would recommend against suppressing the message
even if you were able to pinpoint a single bit in `cha_print_notices'
which controlled it. The fact that the controller burps up that notice
at boot time is well enough known to appear in the FAQ. The drive
works. So just ignore the notice.

If you get the _same_ notices later, during actual drive operation,
you'll want to see them -- otherwise the drive will seem to have just
mysteriously failed.

>Bela<

Bela Lubkin wrote:
> Ian>>>>> I replaced a failed SCSI tape drive on an OSR507 system and
> Ian>>>>> subsequently get this message at start-up:
> Ian>>>>>
> Ian>>>>> NOTICE: cha: SCSI bus has been reset ha=1
> Ian>>>>> Attached SCSI peripherals will return to power up state \
> Ian>>>>> (cha N04)
> Ian>>>>> NOTICE: cha: Unexpected SCSI phase change \
> Ian>>>>> ha=1 id=6 lun=0 cmd=12 blk=0 len=36
> Ian>>>>> A SCSI peripheral behaved unexpectedly
> Ian>>>>> Use Compaq diagnostics to confirm a hardware failure \
> Ian>>>>> (chaN02)
>
> Tony>>>> http://aplawrence.com/SCOFAQ/FAQ_scotec6cha.html ?
>
> Bela>> The advice it gives:
> Bela>>
> Bela>> "int cha_print_warnings=0;"
> Bela>>
> Bela>> seems a little questionable to me. You don't know what other warnings
> Bela>> it might turn off (media error messages? "The controller hardware
> Bela>> reports it's about to die"?) I recommend leaving the warning on and
> Bela>> simply ignoring it.
>
> Ian> Ideally you'd be able to suppress notices and still receive warnings.
> Ian>
> Ian> I looked in /etc/conf/pack.d/cha/space.c and found this:
> Ian>
> Ian> /* Should NOTICE messages from the driver be printed?
> Ian> Each possible NOTICE message is associated with one
> Ian> bit in cha_print_notices. The value -1 turns on all the bits.
> Ian> The value 0 suppresses all NOTICE messages.
> Ian> To turn off message CHAN03, turn off bit 03.
> Ian> */
> Ian> int cha_print_notices = -1; /* 0 to supress all notices */
> Ian>
> Ian> Tony - you might like to update the SCOFAQ? If I get time, I'll try
> Ian> setting cha_print_notices to 0 and report back here.
> Ian>
> Ian> The documentation (man HW cha) says "Although they may be recoverable,
> Ian> you should attempt to determine their root cause and correct it." I
> Ian> don't think I want to play around with the hardware too much.
> Ian>
> Ian> I'll just ignore the messages for now.
>
> Well, it seems odd that the FAQ says to set `cha_print_warnings' to 0
> when the messages you're trying to silence are labeled "NOTICE".
>
> But, all that aside, I would recommend against suppressing the message
> even if you were able to pinpoint a single bit in `cha_print_notices'
> which controlled it. The fact that the controller burps up that notice
> at boot time is well enough known to appear in the FAQ. The drive
> works. So just ignore the notice.
>
> If you get the _same_ notices later, during actual drive operation,
> you'll want to see them -- otherwise the drive will seem to have just
> mysteriously failed.
>
>


My memory of this is that it happens every time the drive is accessed.
I've never been able to convince a customer to just "ignore it" though..

My feeling is to silence it. If the drive fails, you either know it
because it failed completely or you start getting flaky verification
errors. If it supports TapeTell then you can get more info from that
anyway.




--
Tony Lawrence
Unix/Linux/Mac OS X resources: http://aplawrence.com
Geek Yard Sale: http://geekyardsale.com

> Bela Lubkin wrote:

> > But, all that aside, I would recommend against suppressing the message
> > even if you were able to pinpoint a single bit in `cha_print_notices'
> > which controlled it. The fact that the controller burps up that notice
> > at boot time is well enough known to appear in the FAQ. The drive
> > works. So just ignore the notice.
> >
> > If you get the _same_ notices later, during actual drive operation,
> > you'll want to see them -- otherwise the drive will seem to have just
> > mysteriously failed.
>
> My memory of this is that it happens every time the drive is accessed.
> I've never been able to convince a customer to just "ignore it" though..
>
> My feeling is to silence it. If the drive fails, you either know it
> because it failed completely or you start getting flaky verification
> errors. If it supports TapeTell then you can get more info from that
> anyway.

I didn't know it was issuing the warning on every access. That ups the
annoyance factor considerably. Then I would say: go ahead and disable
the warning (preferably by determining exactly what bit(s) to set in
those space.c variables) _if and only if_ the tape drive is the only
device on that adapter. If you have any other drives on the same
adapter, you'd be unwise to turn off warnings that might alert you to a
real problem...

>Bela<

----- Original Message -----
From: "Tony Lawrence" <foo@pcunix.com>
Newsgroups: comp.unix.sco.misc
To: <distro@jpr.com>
Sent: Tuesday, September 06, 2005 7:36 PM
Subject: Re: "Unexpected SCSI phase change" messages after Tape-Drive
replaced.


> Bela Lubkin wrote:
>> Ian>>>>> I replaced a failed SCSI tape drive on an OSR507 system and
>> Ian>>>>> subsequently get this message at start-up:
>> Ian>>>>> Ian>>>>> NOTICE: cha: SCSI bus has been reset ha=1
>> Ian>>>>> Attached SCSI peripherals will return to power up state
>> \
>> Ian>>>>> (cha N04)
>> Ian>>>>> NOTICE: cha: Unexpected SCSI phase change \
>> Ian>>>>> ha=1 id=6 lun=0 cmd=12 blk=0 len=36
>> Ian>>>>> A SCSI peripheral behaved unexpectedly
>> Ian>>>>> Use Compaq diagnostics to confirm a hardware failure \
>> Ian>>>>> (chaN02)
>>
>> Tony>>>> http://aplawrence.com/SCOFAQ/FAQ_scotec6cha.html ?
>>
>> Bela>> The advice it gives:
>> Bela>> Bela>> "int cha_print_warnings=0;"
>> Bela>> Bela>> seems a little questionable to me. You don't know what
>> other warnings
>> Bela>> it might turn off (media error messages? "The controller hardware
>> Bela>> reports it's about to die"?) I recommend leaving the warning on
>> and
>> Bela>> simply ignoring it.
>>
>> Ian> Ideally you'd be able to suppress notices and still receive
>> warnings.
>> Ian> Ian> I looked in /etc/conf/pack.d/cha/space.c and found this:
>> Ian> Ian> /* Should NOTICE messages from the driver be printed?
>> Ian> Each possible NOTICE message is associated with one
>> Ian> bit in cha_print_notices. The value -1 turns on all the
>> bits.
>> Ian> The value 0 suppresses all NOTICE messages.
>> Ian> To turn off message CHAN03, turn off bit 03.
>> Ian> */
>> Ian> int cha_print_notices = -1; /* 0 to supress all notices */
>> Ian> Ian> Tony - you might like to update the SCOFAQ? If I get time,
>> I'll try Ian> setting cha_print_notices to 0 and report back here.
>> Ian> Ian> The documentation (man HW cha) says "Although they may be
>> recoverable, Ian> you should attempt to determine their root cause and
>> correct it." I Ian> don't think I want to play around with the hardware
>> too much.
>> Ian> Ian> I'll just ignore the messages for now.
>>
>> Well, it seems odd that the FAQ says to set `cha_print_warnings' to 0
>> when the messages you're trying to silence are labeled "NOTICE".
>>
>> But, all that aside, I would recommend against suppressing the message
>> even if you were able to pinpoint a single bit in `cha_print_notices'
>> which controlled it. The fact that the controller burps up that notice
>> at boot time is well enough known to appear in the FAQ. The drive
>> works. So just ignore the notice.
>>
>> If you get the _same_ notices later, during actual drive operation,
>> you'll want to see them -- otherwise the drive will seem to have just
>> mysteriously failed.
>>
>>
>
>
> My memory of this is that it happens every time the drive is accessed.
> I've never been able to convince a customer to just "ignore it" though..
>
> My feeling is to silence it. If the drive fails, you either know it
> because it failed completely or you start getting flaky verification
> errors. If it supports TapeTell then you can get more info from that
> anyway.


When things like that come up I just magic away the problem with the power
of terminology.

When telling a customer they need 16 or 32 filepro licences for 6 or 8
users, I don't call them "users" even though filepro does. I call them
"instances".
Which is really what they are and so there is no longer a disparity between
what they will be using and what they have to buy.

Something like this tape drive message, if I determine that it should be
ignored, then I tell the user I'ts not an "error" or a "warning" it's just a
"message".
Now that it's a message instead of a warning or an error, it's magically no
problem.

--
Brian K. White -- brian@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!