General feedback is that the kernel isn't perhaps as tidy as it could be when keeping track of its mappings, and that only a reboot will allow a locked device entry such as this to be removed. Consensus was that the problem can be ignored if it isn't causing a problem.
In my case however the device needed to be re-used for LSM and that did cause a problem because LSM was unable to operate on the 'new' device entry active after the dsfmgr swap. For example:
# volrootmir -a dsk1
lsm:voldisk: ERROR: Device dsk1b: define failed:
Disk read failure
HP have investigated this issue and report that it is indeed a bug, a patch is being worked on by HP engineering.
Thanks to Joseph Senulis, Terry Horsnell and Kevin Fleming for their feedback and suggestions.
-----Original Message-----
From: tru64-unix-managers-owner_at_ornl.gov
[mailto:tru64-unix-managers-owner_at_ornl.gov]On Behalf Of Iain Barker
Sent: Wednesday, 25 August, 2004 12:37
To: tru64-unix-managers_at_ornl.gov
Subject: hwmgr: Error (95) Cannot start operation.
Managers,
I had a disk fail on a DS20E server so I installed a replacement and used 'hwmgr scan scsi' followed by 'dsfmgr -e' to swap the make disk name (dsk5) appear as the original (dsk0).
So far, so good. The new replacement drive is working fine as dsk0. But now I can't delete the stale entry for dsk5 in the device table:
# hwmgr show scsi -stale
SCSI DEVICE DEVICE DRIVER NUM DEVICE FIRST
HWID: DEVICEID HOSTNAME TYPE SUBTYPE OWNER PATH FILE VALID PATH
-------------------------------------------------------------------------
69: 0 disk none 0 2 dsk5
# hwmgr -delete component -id 69
hwmgr: Error (95) Cannot start operation.
# hwmgr delete scsi -did 0
hwmgr: Error (95) Cannot start operation.
Any ideas what I am doing wrong?
This has been reported on the list a few times, but the solution given was always to reboot. That's not an option in this case, running on a production server.
thanks,
Iain
Received on Thu Aug 26 2004 - 20:22:07 NZST