messages in syslog

[Dave Chamberlin]

I found these messages in my syslog today:
vmunix: scb-> cdb: 28 00 00 3e d0 7e 00 00 0e 00
vmunix: scb-> cdb: 28 00 00 16 ae 80 00 00 20 00

can someone tell me what they mean?

[Sajid_1]

hi,

these are the SCSI errors normally a timeout error. Check these things:
a) TIMEOUT value of SCSI set high
b) SCSI connector/cable/controller/device problem
c) latest SCSI patches.

[Sajid_1]

Hi,

This document explains little better - http://support1.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000059199380

Doc ID - KBRC00001951

[S.K. Chan]

Early indication of SCSI lbolt error maybe. You should also be seeing more that just that, like something to the effect of "SCSI request timeout". Do you ? This could be due to SCSI termination problem, SCSI connection or even low IO timeout value.

[Jeff Schussele]

Hi Dave,

Believe scb is SCSI Command Block

cdb (Command Data Buffer?)is a SCSI buffer holding the SCSI command bytes to be sent to a SCSI device.

No clue why these are in syslog.log or whether they're informational or warnings/errors.

Any SCSI error in the vicinity of these msgs in the log?

Rgds,
Jeff

[Dave Chamberlin]

There are no SCSI or lbolt messages around these errors. I also had one message about a week ago. I recently replaced a faulty UPS that powers a couple of disk arrays on this system, so some of the disks may have been stressed in power bumps.Is there a way to determine just from these errors which device is involved or are there other logs that may have a clue?

Thanks

[Jeff Schussele]

Dave,

No I really don't think there's any way to determine the device here.
I'd exercise all devices with the stm utils OR use dd to copy all blocks to null on all devices.
Will take a while, but you're likely to find the culprit sooner or later.

Good Luck,
Jeff

[Martin Johnson]

Check the stm logs to see if any of the disks are generating errors.

HTH
Marty

[Sajid_1]

hello,

I don't think then you need to worry about the errors. It can be just a timeout error value. Now these things can be done:
a) Keep looking at the log files
b) Run STM tools to check all h/w devices
c) Apply the patches regularly.

gl,

[Frank Slootweg]

How frequent are these errors or/and can you determine something from the timestamps, i.e. do these timestamps indicate a certain event?

If these are frequent and this system is under hardware support, then I advise to log a hardware call.

I am not a hardware type and can not decode these, but I have searched our Knowledge DataBase on a *part* of the error message and found about 100 hits (i.e. too many) for "scb and "scb-> cdb" and "28 00 00"" (without outer quotes) and zero hits for the same with " 3e" or " 16" added to the end. From some reports it seems it may be as simple as a (tape?) drive getting on-line, off-line, etc., but you never know.

[Steven E. Protter]

We got similar messages. We made them go away by increasing the timeouts on the disks we suspected were the problem.

A few days later, the controller cable failed and we were down all night. Yikes.

Every time we've had an lbolt, we've ended up replacing a disk.

I wrote a script that checks hardware nightly and sends off emails if it finds lbolts, its stupid, but it saved me a boot disk failure last week.


#!/bin/sh
#
# checkwardare.sh Created 2/13/2001
# Steven E. Protter
#
# Designed to check for hardware lbolts and send out an alert email
#
/usr/sbin/dmesg | grep lbolt > /tmp/checkwardware
errs=`wc -l /tmp/checkwardware | awk {'print $1'}`
if [ $errs -ne 0 ]
then
# echo "Errors ${errs}"
/usr/sbin/dmesg > /tmp/checkwardware
/usr/sbin/dmesg | mailx -s "Hardware error detected /tmp/checkhardware" stevenprotter@juf.org
/usr/sbin/dmesg | mailx -s "Hardware error detected /tmp/checkhardware" issoperator@juf.org
/usr/sbin/dmesg | mailx -s "Hardware error detected /tmp/checkhardware" arthuraptekar@juf.org
/usr/sbin/dmesg | mailx -s "Hardware error detected /tmp/checkhardware" root
/usr/bin/np -qQhp5000 /tmp/checkwardware
fi

[Dave Chamberlin]

Thanks for the replies. The system has not logged any other more of these messages. All of the disks on that machine have the timeout set to "default", so I am not sure what I would change it to if I were to change the timeout. I think I will just have to keep an eye on things (and do another backup just in case...)