Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

A known issue (system hang or panic) in DMP 5.1 SP1

Created: 14 Dec 2011 • Updated: 04 Apr 2012 | 1 comment
This issue has been solved. See solution.

Hi experts,

In the section of Known Issues, I found "A system can hang or panic in a SAN boot environment due to udev device removal after loss of connectivity to some paths on RedHat Linux6(RHEL6)(2219626)". How could I know it's the exact same situation while the similiar thing happens? And is there a way to monitor udev device removal? Thanks for any input.

Regards,

Howard

Comments 1 CommentJump to latest comment

Mark Alleyne's picture

Hello Howard,

The only way would be to look and analyse the crash dump (this would need to be configured and enabled (kdump))

From the etrack all the IO Daemons were stuck in the same trace and you can also cross reference with the data in the messages file to align.

0xffff88042fc22500    18022        2  0    1   D  0xffff88042fc229c0  vxiod^M
sp                ip                Function (args)
0xffff88043445b580 0xffffffff8049b1af thread_return
0xffff88043445b688 0xffffffff8049b3d5 schedule_timeout+0x1e (0x7fffffffffffffff)
0xffff88043445b6f8 0xffffffff8049a95c wait_for_common+0xd5 (0xffff88043445b780, 
invalid, invalid)
0xffff88043445b778 0xffffffff8024c59f call_usermodehelper_exec+0x73 
(0xffff8802db0b97c0, invalid)
0xffff88043445b7c8 0xffffffff8024c7d7 request_module+0x13e (invalid, 0x85, 0x190, 
0xffff88043445b954, 0x0, 0x0)
0xffff88043445b8a8 0xffffffff8033f3c6 base_probe+0x1e (invalid)
0xffff88043445b8b8 0xffffffff803e83c3 kobj_lookup+0x10e (0xffff88043e7cc000, invalid, 
0xffff88043445b954)
0xffff88043445b918 0xffffffff8034056c get_gendisk+0x17 (invalid, invalid)
0xffff88043445b928 0xffffffff802d7a00 do_open+0x6d (0xffff88042f5fdcc0, 
0xffff88043445ba60, invalid)
0xffff88043445b988 0xffffffff802d7d3d __blkdev_get+0x62 (invalid, invalid, invalid, 
invalid)
0xffff88043445bb28 0xffffffffa01c3708 [vxdmp]dmplinux_open_disk_device+0x91 (invalid, 
invalid, 0xffff8803cf5fac38)
0xffff88043445bb58 0xffffffffa01f1d18 [vxdmp]dmp_send_scsireq+0x18 (0xffff8803cf5fabc0)
0xffff88043445bb78 0xffffffffa01ea7ac [vxdmp]dmp_inquiry+0x40 (invalid, invalid, 
invalid, 0xffff88023cc6c000, invalid)
0xffff88043445bba8 0xffffffffa01d6af8 [vxdmp]dmp_def_get_path_state+0x2e (invalid, 
invalid)
0xffff88043445bbc8 0xffffffffa01e2934 [vxdmp]dmp_get_enabled_ctlrs+0x188 
(0xffff88043445bd80, 0xffff88043445bc80, invalid, invalid)
0xffff88043445bc78 0xffffffffa01e2ae4 [vxdmp]dmp_info_ioctl+0x76 (invalid, 
0xffff88043445bd80, invalid, invalid)
0xffff88043445bcd8 0xffffffffa01cfa8b [vxdmp]dmpioctl+0x42 (invalid, invalid, invalid, 
invalid, invalid, 0xffff88043445bd44)
0xffff88043445bce8 0xffffffffa021aab3 [vxio]vol_dmp_ktok_ioctl+0x57 (0xc9fffff, 
0x444d5015, 0xffff88043445bd80, 0x1000, 0x0, 0xffff88043445bd44)
0xffff88043445bd28 0xffffffffa035039c [vxio]dmp_get_enabled_cntrls+0xb3 (0xc9fffff, 
0xffff88043445bd80)
0xffff88043445bd78 0xffffffffa0350875 [vxio]vx_dmp_config_ioctl+0xaa (invalid, 
0xc9000c3, invalid, 0xffff88043445be30)
0xffff88043445bdf8 0xffffffffa0350f42 [vxio]quiescesio_start+0x382
0xffff88043445be88 0xffffffffa02541eb [vxio]voliod_iohandle+0x37 (0xffffffffa04a2630, 
invalid, 0xffff88043445bec0)
0xffff88043445beb8 0xffffffffa02543fc [vxio]voliod_loop+0x1c0

Checking the release notes I see that we have documented a work-around for this. Has this been implemented?  I would also recommend upgrading to the latest SP which we have also enhanced our intergration with udev.

Regards

Mark



SOLUTION