SCSI LBOT Reset

[Richard Ace]

Afternoon peeps.

HP-UX 11.0
# model
9000/800/D390


Any Ideas

How do I diagnose what is bugging on on the SCSII?

Could it be the card is on its way out

dmesg - (every 5-10 minutes)

scb->cdb: 2a 00 00 01 35 c0 00 00 10 00
scb->cdb: 2a 00 00 01 35 c0 00 00 10 00
SCSI: Resetting SCSI -- lbolt: 7647894, bus: 0
SCSI: Reset detected -- lbolt: 7647894, bus: 0
scb->cdb: 2a 00 00 01 85 7e 00 00 02 00
scb->cdb: 2a 00 00 01 85 7e 00 00 02 00
SCSI: Resetting SCSI -- lbolt: 7655863, bus: 0
SCSI: Reset detected -- lbolt: 7655863, bus: 0
scb->cdb: 2a 00 00 01 85 7e 00 00 02 00
scb->cdb: 2a 00 00 01 85 7e 00 00 02 00
SCSI: Resetting SCSI -- lbolt: 7660474, bus: 0
SCSI: Reset detected -- lbolt: 7660474, bus: 0

ioscan -fn|more

Am I correct that in the SCSI message above it say bus 0 is this the on below on 8/4 H/W Path externally?


ext_bus 0 8/4 c720 CLAIMED INTERFACE GSC add-on Fast/
Wide SCSI Interface
target 0 8/4.1 tgt CLAIMED DEVICE
disk 0 8/4.1.0 sdisk CLAIMED DEVICE SEAGATE ST34573W
C
/dev/dsk/c0t1d0 /dev/rdsk/c0t1d0
target 1 8/4.2 tgt CLAIMED DEVICE
disk 1 8/4.2.0 sdisk CLAIMED DEVICE SEAGATE ST34573W
C
/dev/dsk/c0t2d0 /dev/rdsk/c0t2d0
target 2 8/4.3 tgt CLAIMED DEVICE
disk 2 8/4.3.0 sdisk CLAIMED DEVICE SEAGATE ST34573W
C
/dev/dsk/c0t3d0 /dev/rdsk/c0t3d0
target 3 8/4.4 tgt CLAIMED DEVICE
disk 3 8/4.4.0 sdisk CLAIMED DEVICE SEAGATE ST39173W
C
/dev/dsk/c0t4d0 /dev/rdsk/c0t4d0
target 4 8/4.5 tgt CLAIMED DEVICE
disk 4 8/4.5.0 sdisk CLAIMED DEVICE SEAGATE ST34573W
C

CHEERS RICH

[fg_1]

This has happened to us in the past but not on a D class server and it ended up being a flaky scsi card but also it was discovered to be a disk problem as well.

I would have HP replace the scsi card 1st and see if you get this same message.

GL.

[Richard Ace]

Cheers

Thanks for the help

Have some points

Cheers

Rich

[Michael Lampi]

A SCSI CDB of 2a is a write command. It appears that the SCSI subsystem is having troubles writing to a disk device.

Apparently the disk drive is not responding with a Command Complete. The only thing that the system can do to recover from this is perform a bus reset.

This can be caused by a couple of things:
1. The disk drive is failing, and the number of retry attempts is exceeding the driver timeout limits.
2. The SCSI bus is flaky, and the disk device is not getting all the bytes it should.

If these problems have only just recently started happening, and no one has played with the cables and terminators, then either the disk drive or the host controller is failing.

Otherwise, check the cables and terminator.

[Phillip Renner]

We get these sometimes when the disk drives are real busy. If you do a pvdisplay on the drives check the IO Timeout. If it is default (default is 40MS), you can change it to 180 with a pvchange and that will clear the problem if its caused by busy disks.

[Victor BERRIDGE]

Hi,
I had a case on a D220 running hpux11 with hot swap option, I first blamed the controller because it was crashing the system (external swap) since I coulnt find anything wrong with the external sub-system, then I realized it was in fact a internal hot swap disk in mirror (vg00 with just the system on it) not yet out of order but on its way, the difficult bit was after a crash all was fine for a couple of weeks..., Changing what was believed (luck?) THE bad disk solved the problem

Good luck
Victor