HP Tru64 UNIX 5.x - How to Clean up Stale Paths and Null Devices Reported in hwmgr
Information
The following series of commands can be used to clean up stale paths and null devices reported in the Hardware Management Database(HW DB).
Details
1. Use the hwmgr utility to identify stale devices. Example: 
# hwmgr -show scsi -stale 
--------SCSI------------------- DEVICE- DEVICE---- DRIVER-- NUM DEVICE FIRST 
HWID: DEVICEID HOSTNAME TYPE----- SUBTYPE --OWNER ---PATH FILE ---VALID PATH
-------------------------------------------------------------------------------- 
0: 3 dgrdb51 processor none 0 1 (null) 
0: 4 dgrdb51 processor none 0 1 (null) 
0: 25 dgrdb51 processor none 0 1 (null) 
53: 12 dgrdb51 disk none 0 1 (null) 
68: 23 dgrdb51 tape none 0 1 (null)
Devices with a HWID of 0 exist when a previous "hwmgr -delete component -id {HWID}" command failed to complete. Step 2 below provides a means of manually removing these entries:

2. Use hwmgr to delete all "(null)" entries. All of the (null) entries can safely be removed as the identified device is now known as something else or has been removed from the system. The processor DEVICE TYPE entries are a type of intelligent controller, usually HSG or HSZ, or could have been catagorized as this type due to an incomplete HW DB record. This is the case in the above example where the HWID is 0, yet there is remaining datum for the device due to failed hwmgr -delete component command.
# hwmgr -delete component -id {hwid} 
Following the above example, this command will delete HWID 53, which is a disk:
# hwmgr -delete component -id 53 If the HWID is 0, you will need to specify the SCSI Device ID (DID) to delete the entry. The following command will delete SCSI Device ID (DID) 25:
# hwmgr -delete scsi -did 25 
3. On those devices reporting both valid and stale paths, examine the device details with hwmgr -show scsi -did {SCSI Device ID} -full. 
We need to determine which path is stale, the first path or one of the others, and why it is stale. If the first path is stale, generally the only way to correct the stale state (if it is not caused by a hardware problem) is to remove/delete and rescan the device. Later versions of Tru64 UNIX, V5.1B, have made advancements in allowing the first path to be refreshed. So, first attempt the hwmgr -refresh scsi -did {SCSI Device ID} command. Assuming the "hwmgr -refresh scsi" command failed to clear the stale paths, the following outline of steps will help delete, rescan and rename the device back to it's original instance name. 
This set of command examples assumes that dsk3, SCSI Device ID 5, has the first path showing as stale and the DRIVER OWNER count is 0. See below NOTE regarding DRIVER OWNER. 
Example:
# hwmgr -show scsi -did 5 -full 
--------SCSI------------------- DEVICE- DEVICE---- DRIVER-- NUM DEVICE FIRST 
HWID: DEVICEID HOSTNAME TYPE----- SUBTYPE --OWNER ---PATH FILE ---VALID PATH
------------------------------------------------------------------------- 
350: 5 captain disk none 0 8 dsk3 [2/0/3] 
WWID:01000010:6005-08b4-0001-48ce-0001-3000-00fb-0000
BUS TARGET LUN PATH STATE 
---------------------------------
2 6 3 stale
2 5 3 stale
2 0 3 valid
2 1 3 valid
# hwmgr -show scsi 
--------SCSI------------------- DEVICE- DEVICE---- DRIVER-- NUM DEVICE FIRST 
HWID: DEVICEID HOSTNAME TYPE----- SUBTYPE --OWNER ---PATH FILE ---VALID PATH
-------------------------------------------------------------------------
349: 4 captain disk none 0 2 dsk2 [2/0/2]
350: 5 captain disk none 0 2 dsk3 [2/0/3] 
352: 3 captain disk none 0 2 dsk1 [2/0/1]
239: 0 captain cdrom none 0 1 cdrom0 [0/0/0]
240: 1 captain disk none 2 1 dsk0 [1/0/0] 
247: 2 captain raid none 0 2 scp0 [2/1/0] 
# hwmgr -delete scsi -did 5 
hwmgr: The delete operation was successful 
# hwmgr -show scsi 
--------SCSI------------------- DEVICE- DEVICE---- DRIVER-- NUM DEVICE FIRST 
HWID: DEVICEID HOSTNAME TYPE----- SUBTYPE --OWNER ---PATH FILE ---VALID PATH
------------------------------------------------------------------------- 
349: 4 captain disk none 0 2 dsk2 [2/0/2]
352: 3 captain disk none 0 2 dsk1 [2/0/1] 
239: 0 captain cdrom none 0 1 cdrom0 [0/0/0] 
240: 1 captain disk none 2 1 dsk0 [1/0/0] 
247: 2 captain raid none 0 2 scp0 [2/1/0]
# hwmgr -scan scsi 
hwmgr: Scan request successfully initiated
# hwmgr -show scsi 
--------SCSI------------------- DEVICE- DEVICE---- DRIVER-- NUM DEVICE FIRST 
HWID: DEVICEID HOSTNAME TYPE----- SUBTYPE --OWNER ---PATH FILE ---VALID PATH
------------------------------------------------------------------------- 
349: 4 captain disk none 0 2 dsk2 [2/0/2]
352: 3 captain disk none 0 2 dsk1 [2/0/1]
363: 5 captain disk none 0 2 dsk14 [2/0/3] 
239: 0 captain cdrom none 0 1 cdrom0 [0/0/0]
240: 1 captain disk none 2 1 dsk0 [1/0/0] 
247: 2 captain raid none 0 2 scp0 [2/1/0]
- The above command Will cause the device to re-appear with new dskN instance number (i.e. dsk14) which can be identified by it's First Valid Path. So, we will have to use dsfmgr to rename it back to the original name to maintain it's mount point linkages.
# dsfmgr -m dsk14 dsk3 
dsk14a=>dsk3a dsk14b=>dsk3b dsk14c=>dsk3c dsk14d=>dsk3d dsk14e=>dsk3e dsk 14f=>dsk3f dsk14g=>dsk3g dsk14h=>dsk3h dsk14a=>dsk3a dsk14b=>dsk3b dsk14c=> dsk3c dsk14d=>dsk3d dsk14e=>dsk3e dsk14f=>dsk3f dsk14g=>dsk3g dsk14h=>dsk3h
# hwmgr -show scsi 
--------SCSI------------------- DEVICE- DEVICE---- DRIVER-- NUM DEVICE FIRST 
HWID: DEVICEID HOSTNAME TYPE----- SUBTYPE --OWNER ---PATH FILE ---VALID PATH
------------------------------------------------------------------------- 
349: 4 captain disk none 0 2 dsk2 [2/0/2] 
352: 3 captain disk none 0 2 dsk1 [2/0/1]
363: 5 captain disk none 0 2 dsk3 [2/0/3] 
239: 0 captain cdrom none 0 1 cdrom0 [0/0/0]
240: 1 captain disk none 2 1 dsk0 [1/0/0] 
247: 2 captain raid none 0 2 scp0 [2/1/0] 
If a path other than the first path is stale, you can typically get rid of the stale paths by doing a hwmgr -refresh scsi -did {SCSI Device ID}. If this command fails with the following message, make sure the DRIVER OWNER count is 0 and re-attempt the command. See below NOTE regarding DRIVER OWNER count.
hwmgr: Error (95) Cannot start operation.
It is our experience that some cases a stale device must be removed and the device rescanned to correct a stale path condition - assuming the stale path is not caused by a SAN path hardware failure. This case is generally seen when a device fails while being accessed/online. See above outline of steps to delete, rescan and rename the device back to it's original instance name. 
NOTE: A device cannot be removed from the Hardware Database if it is in use. If the "hwmgr -show scsi" DRIVER OWNER count is greater than 0, hwmgr will not allow you to remove the device. The associated device must be umounted (i.e. DRIVER OWNER count must be 0) before it can be removed. The DRIVER OWNER count is a kernel data structure, Peripheral Driver Lock (pd_lock), used at the CAM Layer within the SCSI architecture to signify the device is open and locked by the driver. If the device failed while open by the driver and the DRIVER OWNER is non-zero, then the only way to clear this is a reboot the system. This most often happens with Tape devices that have a hardware failure while in use.