This content has been marked as final. Show 2 replies
Hi guys!! I have updated info. In the recovered dump from Solaris11 crashes, I forgot to include a crash dump. The next is an example:
panicstr = BAD TRAP: type=30 rp=2a102164f50 addr=1881e000 mmu_fsr=9
panicstack = unix:die+a0 (30, 2a102164f50, 1881e000, 9, 9, 60048) | unix:trap+708 (2a102164f50, 6001b4cb400, 1881e000, 0, 3001ad5e3a0, 1d585) | unix:ktl0+64 (2600001881e800, 7, 2, 6001bf911f8, 2600001881e800, 60048) | fcp:fcp_commoncap+18 (6001881e800, 7ae73888, 0, 1, 0, 7b302cf0) | IBMtape:IBM_open+246c (7010a43d, 7, 2, 6001bf911f8, a58, 300024fe000) | specfs:spec_open+5b4 (2, 1, 6001bf911f8, 2, 2a102165910, 0) | genunix:fop_open+184 (2a102165910, 6001cf56a00, 6001bf911f8, 0, 0, 7) | genunix:vn_openat+6b4 (4013c, 4, 7, 2a102165910, 0, 0) | genunix:copen+434 (4013c, 600000, 7, 40148, 0, 0) |
I got many crashes exactly in the same point: scsi_ifgetcap() is causing the crashes. This does not happen during the device attachment, but only in open() entry point. In order for our issue to be reproduced, the open() system call needs to be executed.
Got the stack dumps from all the crashes, and all the crashes happens exactly in the same point. ( fcp_commoncap+18 )
Somebody has information about this weird issue?
Edited by: user9048712 on 09-ene-2012 12:34
I discovered that crashes are caused by setting values in a scsi_device_t variable, right before scsi_ifsetcap() function.
/* next two lines causes system crashes */
scsi_device.sd_address.a_target = target;
scsi_device.sd_address.a_lun = lun;
rc = scsi_ifgetcap( scsi_device, "xxxxx", THIS);
Checking those lines, I realized that those values (scsi_device.sd_address.a_target and a_lun ) has incorrect data. Older Solaris versions has correct data, but solaris 11 does not. Something changed in Solaris 11 and that source code now hangs the entire system in scsi_ifgetcap function and this didn't happen before.
Thanks in advance