Sign In
Problem
System goes panic at panic string "dmp_get_cur_policy()" since there was some change in LUNs at OS & Storage Level.
Error Message
[ ERROR MESSAGES ]
CRASH INFORMATION:
=============================================
CPU 2 CSA F0000000300A7780 at time of crash, error code for LEDs: 30000000
pvthread+023800 STACK:
[0495ECC8]dmp_get_cur_policy+00004C (0000000100000001, F10001006E3D6C00) <<<<<< HERE.
[0496E6A4]dmp_get_subpaths+0005B4 (8000002A0000FFFF, 0000000030F583C0, 0000000100000001, 0000000000000000)
[04975D70]gendmpioctl+000180 (8000002A0000FFFF, 444D5003444D5003, 0000000030F583C0, 0000000100000001, F10001006EE3D1FC, F0000000300A72E8)
[049287A0]vxdmpioctl+000104 (8000002A0000FFFF, 444D5003444D5003, 0000000030F583C0, 0000000100000001, 0000000000000000, 0000000000000000)
[003F68B0]rdevioctl+0000C8 (??, ??, ??, ??, ??, ??)
[004CF01C]spec_ioctl+000078 (??, ??, ??, ??, ??, ??)
[0040C26C]vnop_ioctl+000068 (??, ??, ??, ??, ??, ??)
[0044E600]vno_ioctl+000084 (??, ??, ??, ??, ??)
[00466630]common_ioctl+0000C0 (??, ??, ??, ??)
[00003810].svc_instr+000110 ()
[kdb_get_memory] no real storage @ 30F582F0
[D0382C50]D0382C50 ()
=============================================
Cause
- System went panic in dmp_get_cur_policy() + offset 0x00004C due to mismatching device address at between DMP and OS level.
- This can be seen by checking the /etc/vx/disk.info
# egrep "0xfffffffffff" /etc/vx/disk.info
Solution
[ WHAT TO DO ]
1. In case of LUNs in any changes as follows, Please make sure to scan the devices correctly at OS & Storage level.
- Cleaning up the operating system device tree after removing LUNs
- Adding new LUNs dynamically to a new target ID
- Removing LUNs dynamically from an existing target ID
2. Repeatedly reconfirmed the correct devices were shown(or removed) at OS & Storage level.
3. Then, Make sure that there are no "0xffffffff " entries in /etc/vx/disk.info file.
# grep -i "0xfffffffffff" /etc/vx/disk.info
[ For Example ]
1) On the platform, AIX
# egrep -i 0xffff disk.info
-------------------------------------------------------------------------------------------------------------------------------------------
HP%5F50%5F07E7F%5F50%2007E7F319A hdisk17 0xffffffff 0x1 hdisk17 XP12K 07E7F
HP%5F50%5F07E7F%5F50%2007E7F332F hdisk18 0xffffffff 0x1 hdisk18 XP12K 07E7F
HP%5F50%5F07E7F%5F50%2007E7F16B8 hdisk9 0xffffffff 0x1 hdisk9 XP12K 07E7F
HP%5F50%5F07E7F%5F50%2007E7F1529 hdisk8 0xffffffff 0x1 hdisk8 XP12K 07E7F
HP%5F50%5F07E7F%5F50%2007E7F1528 hdisk7 0xffffffff 0x1 hdisk7 XP12K 07E7F
-------------------------------------------------------------------------------------------------------------------------------------------
2) On the platform, LINUX
# egrep -i 0xffff disk.info
-------------------------------------------------------------------------------------------------------------------------------------------
EMC%5FSYMMETRIX%5F000190101351%5F5104993000 sddk 0xffffffffffffffff 0x2 emc0_4993 EMC 000190101351
EMC%5FSYMMETRIX%5F000190101351%5F5104988000 sddj 0xffffffffffffffff 0x2 emc0_4988 EMC 000190101351
EMC%5FSYMMETRIX%5F000190101351%5F51049A1000 sddn 0xffffffffffffffff 0x2 emc0_49a1 EMC 000190101351
IBM%5F2810XIV%5F0ED3%5F01E1 sdawz 0xffffffffffffffff 0x2 xiv0_01e1 XIV 0ED3
EMC%5FSYMMETRIX%5F000190104348%5F4802BB8000 sdams 0xffffffffffffffff 0x2 emc2_2bb8 EMC 000190104348
EMC%5FSYMMETRIX%5F000190104348%5F4802BC8000 sdamv 0xffffffffffffffff 0x2 emc2_2bc8 EMC 000190104348
EMC%5FSYMMETRIX%5F000190104348%5F4802BB0000 sdamq 0xffffffffffffffff 0x2 emc2_2bb0 EMC 000190104348
EMC%5FSYMMETRIX%5F000190104348%5F4802BA8000 sdamp 0xffffffffffffffff 0x2 emc2_2ba8 EMC 000190104348
EMC%5FSYMMETRIX%5F000190104348%5F4802BC0000 sdamt 0xffffffffffffffff 0x2 emc2_2bc0 EMC 000190104348
EMC%5FSYMMETRIX%5F000190104348%5F4802BA0000 sdamo 0xffffffffffffffff 0x2 emc2_2ba0 EMC 000190104348
IBM%5F2810XIV%5F0ED3%5F01DF sdawx 0xffffffffffffffff 0x2 xiv0_01df XIV 0ED3
IBM%5F2810XIV%5F0ED3%5F01E0 sdaxb 0xffffffffffffffff 0x2 xiv0_01e0 XIV 0ED3
EMC%5FSYMMETRIX%5F000192602244%5F4402F39000 sdbzo 0xffffffffffffffff 0x2 emc3_2f39 EMC 000192602244
-------------------------------------------------------------------------------------------------------------------------------------------
4. If entries are reported, then the /etc/vx/disk.info has not been updated since the last LUN removal operation.
So therefore, the system is able to go panic at panic string "dmp_get_cur_policy()"
5. Take a backup of existing /etc/vx/disk.info file and run the following command to refresh the file:
# vxddladm assign names
Note: Please redo this until there would be no "0xffffffff " entries in /etc/vx/disk.info file.
6. In case of adding New LUNs, the following step will be required as well.
Use Volume Manager to perform a device scan. It must be asked to perform this operation on all nodes in a cluster.
Enter one of the following commands:
# vxdctl enable
# vxdisk scandisks
Note: This issue can arias even at any platform such as Linux, AIX, HPUX and so on.
Applies To
[ ENVIRONMENT ]
- AIX5.3
- SF5.0MP3RP3
Terms of use for this information are found in Legal Notices.
|
Translated Content
Please note that this document is a translation from English, and may have been machine-translated. It is possible that updates have been made to the original version after this document was translated and published. Veritas does not guarantee the accuracy regarding the completeness of the translation. You may also refer to the English Version of this knowledge base article for up-to-date information.
