1. Support
  2. Knowledge base
  3. 100005511

System goes panic at panic string "dmp_get_cur_policy()" since there was some change in LUNs at OS & Storage Level.

Article: 100005511
Last Published: 2011-05-04
Ratings: 0 0
Product(s): InfoScale & Storage Foundation

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

Was this content helpful?

Article Languages