Tape device busy

[Rumen Ginev_1]

Hi all!

On a N-class server (HPUX 11.00 64-bit) I have a DDS3 tape and a cdrom. I swapped the cdrom with another DDS tape of the absolutely same type as the existing one. I did this on-line.
The first time I switched the new tape on I had forgotten to change the SCSI ID, so both tape devices had same SCSI ID and were connected on the same SCSI bus. I fixed this immediately.

After that I ran STM verify and information tools for the two tapes. They both completed successfully.
ioscan shows the devices CLAIMED.
I created device files for the new tape using insf. ioscan lists them too.

From that point whenever I try to access the new tape I get Device busy. The other device is fine. I swapped the tape devices (and changed the SCSI IDs of cource), but the tape in the slot where the cdrom device was still is not working.
I also swapped the tape media, , so this is not due to a faulty device or media.

Bellow is the output from couple of commands I used to fix the problem, but without any luck.

I stuck completely, so any help will be appreciated!

# ioscan -fnH 0/0/1/0.1.0
Class I H/W Path Driver S/W State H/W Type Description
=====================================================================
tape 3 0/0/1/0.1.0 stape CLAIMED DEVICE HP C1537A
/dev/rmt/3m /dev/rmt/c0t1d0BEST
/dev/rmt/3mb /dev/rmt/c0t1d0BESTb
/dev/rmt/3mn /dev/rmt/c0t1d0BESTn
/dev/rmt/3mnb /dev/rmt/c0t1d0BESTnb


# fuser -u /dev/rmt/3m*
/dev/rmt/3m:
/dev/rmt/3mb:
/dev/rmt/3mn:
/dev/rmt/3mnb:

# fuser -u /dev/rmt/c0t1d0BEST*
/dev/rmt/c0t1d0BEST:
/dev/rmt/c0t1d0BESTb:
/dev/rmt/c0t1d0BESTn:
/dev/rmt/c0t1d0BESTnb:


# st -f /dev/rmt/3mn -r
# st -f /dev/rmt/3mn -s
Device is OK and available


# mt -t /dev/rmt/3mn stat
on tape open: Device busy

# mt -t /dev/rmt/3mn rel
on tape open: Device busy

# diskinfo /dev/rmt/3m
diskinfo: can't open /dev/rmt/3m: Device busy

[Ravi_8]

HI

# fuser -ku /dev/rmt/3m*
#mt -t /dev/rmt/3m stat

what happened after this?

[Rumen Ginev_1]

Did not help

# fuser -ku /dev/rmt/3m*
/dev/rmt/3m:
/dev/rmt/3mb:
/dev/rmt/3mn:
/dev/rmt/3mnb:

# mt -t /dev/rmt/3m stat
on tape open: Device busy

[Ravi_8]

Hi Rumen

can you post the o/p
#ioscan -fnC tape

[Stephen Keane]

Can you confirm that the tape drive is powered on, there is a tape in it, the tape/status light is on, the busy light (if it has one) is off, there is no noise coming from the drive.

The device busy error doesn't actually mean the device is busy BTW, I get device busy on a DLT drive if the key isn't turned away from the locked position.

If you go in to SAM and list tape devices, does the drive show up?

[Rumen Ginev_1]

Guys, I attached the output from ioscan -fnC tape and sam's tape manger.
The tape device in question is connected to 0/0/1/0.1.0.
I can confirm that the device is turned on and there is a healthy tape in it as well.

Dou you think this may be a SCSI bus problem?

[lawrenzo]

have you tried to eject the tape and then run the mt -t /dev/rmt/3mn stat?

give this a whirl, you should get something like;

Drive: HP C1537A
Format:
Status: [0]
File: 0
Block: 0

if it still say's device busy then potentail issue with the device?

[TwoProc]

Rumen, did u generate the new special files?
I'd give insf a go first - see if it solves your problem, as I've not heard you mention that you've done so. Please follow up with an "ls -al /dev/rmt/[03]m" command.

[Bill Hassell · Accepted solution]

You may need lsof to trackdown the reason for the busy. Because it was added while the system was running and had the SCSI address mixup, you may need to shutdown, poweroff for a complete reset) and reboot.

[Rumen Ginev_1]

Thanks for the replys guys!

Lawrenzo, I have alredy tried this couple of times.
John, I had to create the device files (insf -H 0/0/1/0.1), because they did not exist. In addition I removed (rmsf ...) and re-created them again just for any case.
Bill, I think this is what has happened and I am going to reboot when I have chance to do this.
I realy dislike rebooting UNIX servers because of such problems and that is why I started this thread, but that was my fault :-(

[Gerhard Roets]

Hi Rumen

Did you try to power cycle the drive? The drive might have been left in a funny state.

HTH
Gerhard