Hi Frank,
> Hi Nigel,
>
> Thanks for the links... I followed the instructions to capture the
> DTrace output.
Thank you for providing DTrace output, and for Nigel to offer up a the
use of DTrace.
From the DTrace output, the code path leads to the same place as
noted before, the routine check_access.
-> connection_parameters_get(0x4D1C50,
0x4A5A15, 0x0)
-> find_target_node(0x4A5A15, 0x0, 0x1)
<- find_target_node = 175
>>>>> -> check_access(0x49E2A0, 0x0, 0x0)
-> isns_enabled(0x49E2A0, 0x0, 0x0)
<- isns_enabled = 97
-> conn_process(0x4D1C50, 0x1000000, 0x0)
> I'm attaching it here in the hopes that you or Jim might be so kind
> as to decipher/interpret it for me. :-)
The trace confirms what I stated previously.
1). Right after the return from the function call "<- isns_enabled",
the call stack just stops, where DTrace starts reporting the call
stack of another thread of code at conn_process().
2). As mentioned before, the failure is within the routine
check_access, right after the call to isns_enabled
I have revisited the core, reviewed the connection parameter process
that happened just prior to the call to check_access, and I am now
questioning the following logging messages.
CON0 ErrorRecoveryLevel = 0
Sun Feb 1 19:07:32 2009
CON0 TargetName =
iqn.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXSun Feb 1 19:07:35 2009
MAIN nge0: 0:e0:81:57:11:d0
The IQN value looks suspicious, being all XXXX's, and the character
string spills over into the next time stamp. The code that produces
the above string is as follows, and it clearly has a line-feed
terminator "\n", which does not show up in the logging above.
328 queue_prt(c->c_mgmtq, Q_CONN_LOGIN,
329 "CON%x %24s = %s\n", c->c_num,
"TargetName",
330 targ_name);
Are you using static discovery, the [ + ] option on the [ Target ]
tab, and manually filling the "IP Address or DNS Name:" with a valid
IP address, but the IQN string above with a bunch of XXXXX's. ?
Jim
>
>
> Frank
> --
> This message posted from opensolaris.org
> <dtrace_output.txt>_______________________________________________
> storage-discuss mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/storage-discuss
Jim Dunham
Engineering Manager
Sun Microsystems, Inc.
Storage Platform Software Group
work: 781-442-4042, x24042
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
