SCSI: Request Time Out error

[Brian Lee_4]

When I run "dmesg", there is "SCSI: Request Time Out error".
The message is logged when a backup is running.
However, it doesn't happen every time.
Omniback II 3.5 is running on HP-UX 11.0 L3000 server.
I already updated the latest patch bundles

Exact message is like the following:

SCSI: Request Timeout; Abort -- lbolt: 18521689, dev: e7062000, io_id: 6000193

SCSI: Request Timeout; Abort -- lbolt: 164761446, dev: e7062000, io_id: 6000a28

SCSI: Request Timeout; Abort -- lbolt: 321471954, dev: e7062000, io_id: 60012af

Anyone can help me solve this issue ?

[doug mielke]

lbolts are serious indications of hardware failure. These are posting on this site that can decode the messages, but this is likely a call to HP support.

[Bryan D. Quinn]

Hello,

I have had this type of error show up in syslog a couple of times. The first time I saw it, it was on our A4846A DLT library and it would happen when there was a problem loading or unloading a tape. That still happens at random. The other time I saw this was on some of our EMC disks during our nightly sync between our STD's and BCV's. Turned out that the two disks getting the errors had the PV timeout set to default. I changed this to the EMC recommended setting which was something like 90.

Now that I think about it, I did have this happen one other time. It was also on an EMC disk. The problem was the disk was not Read/Write enabled on both paths. I made the change and everything was fine.

Hope this info will help you out.

-Bryan

[Ashwani Kashyap]

Apart from what is mentioned above I have also seen that increasing the disk timeout periods with pvchange also helps . especially if its a disk array .

Use pvcchange -t to increase the time out and it can be done online .

[Brian Lee_4]

I think that the error is from DLT7000 tape drive, not from EMC disks because the problem had happened before I migrated data to EMC disks.

[John Dvorchak]

If I am not mistaken the device giving you the trouble is /dev/xxx/c0t6d2. The xxx may be a dsk or rmt you will have to check. I think the major device number is 231 (e7).
If it is a tape can you nail down the time to a period when someone is changing tapes or otherwise messing with the tape?

[Brian Lee_4]

I found that the device's block number is 231 but couldn't find a driver and a class.
I ran the following command but it didn't show anything.

root@sna:/ > lsdev -b 231
Character Block Driver Class

[Helen French]

Did you check the device on controller 0, scsi ID 6 and device 2? or do an 'ioscan -fnc | grep c0t6d2'. That's probably where the problem is. Run STM tools against it and see if you have any errors. Normally it's a hardware error that needs hardware support assistance. Also check the root mail.

[Helen French]

oops ..typo. The command should be:

# ioscan -fn | grep c6t2d0

Otherwise, check device on controller 6 and SCSI ID 2.

[Brian Lee_4]

I cannot find any error or warning related to the problem in STM.

[John Dvorchak]

Sorry, Siju is correct. The device file is c6t2d0 not the way I had it. Can you post the output of: ls -l /dev/rmt/ so we can confirm that it is a tape device? If so, then I think you are going to have to contact Omniback to get their take on the error. It sure sounds to me like the tape is busy and not signaling as expected. Maybe they have a parameter change you can make to lenghten the timeout value or maybe they have a patch suggestion.

Good luck

[Brian Lee_4]

The device file(/dev/rac/c6t2d0) is for robotic arm of STK tape device.

autoch 0 0/9/0/0.2.0 schgr CLAIMED DEVICE STK 9714
/dev/rac/c6t2d0

[Helen French]

Yes, that's the device that gave error. I am almost positive that you might have got a detailed mail on root account. Check the device with a hardware person or check for any media or I/O errors during backup.