SCSI: Request Timeout

[Dr. Martin Bäker]

Dear experts,

this morning it was not possible to log onto my HP-B2000 (HP-UX 10.20) - the system reaction was extremely sluggish and after waiting for a rather long time after typing in my password with nothing happening, I decided to reboot the machine.

It came up alright, but looking into
/var/adm/syslog/OLDsyslog.log, I found lots of messages looking like this:

SCSI: Request Timeout -- lbolt: 405868958, dev: 1f025000
Aug 18 08:38:06 turtle vmunix: lbp->state: 4060
Aug 18 08:38:06 turtle vmunix: lbp->offset: ffffffff
Aug 18 08:38:06 turtle vmunix: lbp->uPhysScript: f4000000
Aug 18 08:38:06 turtle vmunix: From most recent interrupt:
Aug 18 08:38:06 turtle vmunix: ISTAT: 2a, SIST0: 04, SIST1: 00, DSTAT: 80, DSPS: 00000006
Aug 18 08:38:06 turtle vmunix: NCR chip register access history (most recent last): 129 accesses
Aug 18 08:38:06 turtle vmunix: 744148, ISTAT0<-20
Aug 18 08:38:06 turtle vmunix: 749999, ISTAT0<-20
Aug 18 08:38:06 turtle vmunix: 744413, ISTAT0<-20
Aug 18 08:38:06 turtle vmunix: 749931, ISTAT0<-20
Aug 18 08:38:06 turtle vmunix: 744497, ISTAT0<-20
Aug 18 08:38:06 turtle vmunix: 427928, ISTAT0<-20
Aug 18 08:38:06 turtle vmunix: 70527, ISTAT0: 2a
Aug 18 08:38:06 turtle vmunix: 4, SIST0: 04
Aug 18 08:38:06 turtle vmunix: 2, SIST1: 00
Aug 18 08:38:06 turtle vmunix: 2, DSTAT: 80
Aug 18 08:38:06 turtle vmunix: 2, DSPS: 00000006
Aug 18 08:38:06 turtle vmunix: 1, SCRATCHA: ff00086f
Aug 18 08:38:06 turtle vmunix: 2, DSP: f4000058
Aug 18 08:38:06 turtle vmunix: 0, SCRATCHA1<-00
Aug 18 08:38:06 turtle vmunix: 0, CTEST3<-05
Aug 18 08:38:06 turtle vmunix: 0, STEST3<-82
Aug 18 08:38:06 turtle vmunix: lsp: 5807180
Aug 18 08:38:06 turtle vmunix: bp->b_dev: 1f025000
Aug 18 08:38:06 turtle vmunix: scb->io_id: 2a2c076
Aug 18 08:38:06 turtle vmunix: scb->cdb: 28 00 00 00 00 10 00 00 04 00
Aug 18 08:38:06 turtle vmunix: lbolt_at_timeout: 405865851, lbolt_at_start: 405865851
Aug 18 08:38:06 turtle vmunix: lsp->state: 10d
Aug 18 08:38:06 turtle vmunix: lbp->owner: 5807180
Aug 18 08:38:06 turtle vmunix: scratch_lsp: 0
Aug 18 08:38:06 turtle vmunix: Pre-DSP script dump [f4000030]:
Aug 18 08:38:06 turtle vmunix: 78346f00 0000000a 78350800 00000000
Aug 18 08:38:06 turtle vmunix: 0e000004 f4000500 e0100004 f400077c
Aug 18 08:38:06 turtle vmunix: Script dump [f4000050]:
Aug 18 08:38:06 turtle vmunix: 9f0b0000 00000006 0a000000 f4000508
Aug 18 08:38:06 turtle vmunix: 721a0000 00000000 e2100004 f4000580

I suspect that this points to some trouble in the hard disks, but I have no idea what it is and whether I need to take any action.

Thanks for any help,

Martin.

[RAC_1]

Lbolt errors could be due to following.

1 Problem with SCSI connector, Loose/faulty connections etc.
2 Not having latest SCSI/patch level of your system
3 Faulty devices etc.
4 For disks it could be due to timeout specified. It can be changed with pvchange command. (the default if 60)

In your case it seems that you have problems with disk c2t5d0. (grep for minor no - 025000 in ll /dev/dsk)

Check if you can access that disk, can get diskinfo.

[Michael Tully]

The errors indicate that a disk is timing out. This could be due to your SCSI chain under load or during a backup session, classical when you have both tape and disk on the same chain.

If the messages have just started and you do nothing different to before, I would make sure that you have your backups up to date, and make arrangements to have the disk replaced. Is the disk (contents of the logical volumes) mirrored? It makes it much easier to change if the disk is mirrored.

[Dr. Martin Bäker]

Thanks for the clarifications.

Here is the output from diskinfo on both of my hard disks:

# diskinfo /dev/rdsk/c2t6d0
SCSI describe of /dev/rdsk/c2t6d0:
vendor: SEAGATE
product id: ST39236LC
type: direct access
size: 8886762 Kbytes
bytes per sector: 512
# diskinfo /dev/rdsk/c2t5d0
SCSI describe of /dev/rdsk/c2t5d0:
vendor: SEAGATE
product id: ST39140LC
type: direct access
size: 8891620 Kbytes
bytes per sector: 512


No, the disks are not mirrored - as I have no support for the machine anymore, replacing the disk would be expensive, I think.

I have not done anything new on the system. The error occured during our backup script, which tar's a copy of both disks to a different computer.

Is there any way to find out if the disk is faulty in any way? On reboot, there was some fsck running, but no messages about bad blocks etc. (although I had a bad block message some time in the past).

Thanks again,

Martin.

[Bernhard Mueller · Accepted solution]

Martin,

what is typically done in this situation is to do a full dd of the raw disk and let it run so you see it completes.

I.e.

dd if=/dev/rdsk/c2t5d0 of=/dev/null bs=1024k

this should run for a while and if you finally get the messages
# blocks in
# blocks out

then you assume that the disk is basically OK.

Regards,
Bernhard

[Dr. Martin Bäker]

dd'ing the disk - that's a smart idea.

Here's what I got:

# dd if=/dev/rdsk/c2t5d0 of=/dev/null bs=1024k
8683+1 records in
8683+1 records out


So I assume that means the disk is more or less o.k.

BTW, how do you find out that disk number from the file I posted?

[Massimo Bianchi]

Hi,
for the disk resolution mistery: it's wrote here:

dev: 1f025000


1f
major, in decimanl 31.

lsdev | grep 31

gives you disk

250
minor

c2t5d0

Massimo

[Robert-Jan Goossens]

Hello,

SCSI: Request Timeout -- lbolt: 405868958, dev: 1f025000 -----> drop the 1f ----> 025000

# cd /dev/dsk
# ll
brw-r----- 1 root sys 31 0x025000 Jun 10 1996 c2t5d0

Hope it helps,

Robert-Jan.