Re: modifying transport_name
Pete Wyckoff wrote: This is important, thanks. Userspace git head fails with stock 2.6.26-rc3 due to the introduction of ISCSI_UEVENT_CREATE_BOUND_SESSION in pass ep to session creation. Guess I should pull in your git kernel tree too. Oh fudge. Yeah, it looks like I only fixed the compat problem for tcp. Let me make the fix generic in the open-iscsi git tree head. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: modifying transport_name
Mike Christie wrote:
[in another mail]
Oh yeah the userspace tools from 869.2 should work with
2.6.26-rc3.
This is important, thanks. Userspace git head fails with stock
2.6.26-rc3 due to the introduction of
ISCSI_UEVENT_CREATE_BOUND_SESSION in pass ep to session
creation. Guess I should pull in your git kernel tree too.
It should not fail. We should drop down to the old behavior. I will
check that out. I think I forgot to copy over a fix from tcp to iser for
compat support.
Here is patch over git head which fixes the problem for me. Sorry about
that.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---
diff --git a/usr/initiator.c b/usr/initiator.c
index 9c3eb49..3048340 100644
--- a/usr/initiator.c
+++ b/usr/initiator.c
@@ -1687,18 +1687,29 @@ static void session_conn_recv_pdu(void *data)
static int session_ipc_create(struct iscsi_session *session)
{
struct iscsi_conn *conn = session-conn[0];
- int err = 0, kern_ep = 1;
+ int err = 0, pass_ep = 1;
uint32_t host_no = -1;
- if (session-t-template-ep_connect == iscsi_io_tcp_connect)
- kern_ep = 0;
-
+ if (session-t-template-ep_connect != ktransport_ep_connect)
+ pass_ep = 0;
+retry_create:
err = ipc-create_session(session-t-handle,
- kern_ep ? conn-transport_ep_handle : 0,
+ pass_ep ? conn-transport_ep_handle : 0,
session-nrec.session.initial_cmdsn,
session-nrec.session.cmds_max,
session-nrec.session.queue_depth,
session-id, host_no);
+ /*
+ * Older kernels were not passed the sessions's leading conn ep,
+ * so we will get -EINVAL || -ENOSYS for iser.
+ *
+ * 2.6.22 and earlier would send -EINVAL instead of -ENOSYS.
+ */
+ if (pass_ep (err == -ENOSYS || err == -EINVAL)) {
+ pass_ep = 0;
+ goto retry_create;
+ }
+
if (!err)
session-hostno = host_no;
return err;
Re: modifying transport_name
Pete Wyckoff wrote: I confess to having lost the plot on the iface rearrangements. I'm trying to mount up a remote iser target using 2.6.26-rc3 and open-iscsi git HEAD userspace plus hacks to read the new sysfs layout. The old style, before login, was to modify node.transport_name, which now has been changed to live on iface, apparently. Doing the obvious switch doesn't work: aib01$ iscsiadm -m node -p 10.100.2.32,3260 --op update \ -n iface.transport_name -v iser iscsiadm: Cannot modify iface.transport_name. Use iface mode to update this value. With the git head you can just do iscsiadm -m discovery -t st -p ip:port -I iser This will setup iser for the portals found. You can then do iscsiadm -m node -I iser -l to log into all the portals bound to iser or do the normal commands iscsiadm -m node -T target -p ip:port -l iscsiadm -m node -T target -l iscsiadm -m node -T target -I iser -l For example f you have a combo of iser and tcp on the target you can do: iscsiadm -m node -T target -I iser -l to log into the ones bound to iser or iscsiadm -m node -T target -I default -l to log into the ones bound to tcp (default is for the old tcp no binding). The default behavior is broken right now. When you do the discovery command it will bind portals to any module you have loaded so if you have tcp and iser loaded when you do iscsiadm -m discovery -t st -p ip:port it will bind the portals found to tcp and iser when you probably just want one or the other (iser also loads automatically by the iscsi scripts so it might always be loaded). I was trying to figure out a way to make bnx2i and iser binding easier. and I can't get the hang of the -m iface syntax. This commit suggests that I'm in over my head: commit 0f1e48cfc07ac5031bf9a4a60487fcb46a46b791 Author: Mike Christie [EMAIL PROTECTED] Date: Sun Apr 20 22:15:32 2008 -0500 Do not allow iface setting to be changed in node mode. This temporarily breaks iscsi_discovery and probably other apps for distros that wanted to set iface.transport_name. In the patch to add default a iser iface we broke node.transport_name, so this means there is no backward compat for that setting and you must use the new default iser iface. Before this is released we will add some compat code somewhere and fix up the check in iscsiadm for iface settings based on Dorn's patch. Are you talking about Doron's parameter categorization work? Yeah. I'm having a hard time finding that again. Any suggestions for a quick fix to play with iser in 2.6.26-rc3? -- Pete --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: modifying transport_name
Mike Christie wrote: Pete Wyckoff wrote: I confess to having lost the plot on the iface rearrangements. I'm trying to mount up a remote iser target using 2.6.26-rc3 and open-iscsi git HEAD userspace plus hacks to read the new sysfs layout. The old style, before login, was to modify node.transport_name, which now has been changed to live on iface, apparently. Doing the obvious switch doesn't work: aib01$ iscsiadm -m node -p 10.100.2.32,3260 --op update \ -n iface.transport_name -v iser iscsiadm: Cannot modify iface.transport_name. Use iface mode to update this value. With the git head you can just do iscsiadm -m discovery -t st -p ip:port -I iser This will setup iser for the portals found. You can then do iscsiadm -m node -I iser -l to log into all the portals bound to iser or do the normal commands iscsiadm -m node -T target -p ip:port -l iscsiadm -m node -T target -l iscsiadm -m node -T target -I iser -l For example f you have a combo of iser and tcp on the target you can do: iscsiadm -m node -T target -I iser -l to log into the ones bound to iser or iscsiadm -m node -T target -I default -l to log into the ones bound to tcp (default is for the old tcp no binding). The default behavior is broken right now. When you do the discovery command it will bind portals to any module you have loaded so if you have tcp and iser loaded when you do iscsiadm -m discovery -t st -p ip:port it will bind the portals found to tcp and iser when you probably just want one or the other (iser also loads automatically by the iscsi scripts so it might always be loaded). I was trying to figure out a way to make bnx2i and iser binding easier. Oh yeah, so let me know what you think would be easier for you? I thought just passing in -I iser during discovery would be nice and save a step. If it is worse then let me know. In the end we will have bnx2i, iser, chelsio and tcp, and we will want a quick way to figure out what the user wants to do. I was thinking that when the discovery command is run we could look over /sys/class/iscsi_host to see if bnx2i or chelsio had loaded and created a scsi/iscsi host for some hba. If it had then it would be safe to assume that the user wanted to use the offload engines and so we would set the transport to one those modules automatically. This does not work for tcp or iser where we allocate a host per session. For iser maybe if there is a infinniband card then maybe we should assume that the user would want to bind to that and we could just do it automaitcally for them? For tcp, if no special hardware is found then we could do the default behavior where we just use tcp. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: modifying transport_name
Pete Wyckoff wrote: Are you talking about Doron's parameter categorization work? I'm having a hard time finding that again. Any suggestions for a quick fix to play with iser in 2.6.26-rc3? Oh yeah the userspace tools from 869.2 should work with 2.6.26-rc3. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
