Re: Help:insmod: error inserting ib_iser.ko
I don't want use th "iser" I want the open-iscsi run normally run,can you help me? 2009/12/16 Erez Zilber > On Tue, Dec 15, 2009 at 12:26 PM, DeepBlue > wrote: > > There is a error with I inserting the ib_iser.ko module as following: > > > > [r...@localhost init.d]# insmod /lib/modules/2.6.18-8.el5/kernel/ > > drivers/infiniband/ulp/iser/ib_iser.ko > > insmod: error inserting '/lib/modules/2.6.18-8.el5/kernel/drivers/ > > infiniband/ulp/iser/ib_iser.ko': -1 Unknown symbol in module > > > > my linux kernel 2.6.18-8.el5 > > who can help me? > > > > This is because your ib_iser module was built against open-iscsi from > the redhat kernel (2.6.18-8.el5). You are currently running open-iscsi > modules that you took from open-iscsi.org. If you run 'dmesg -c', > you'll see the list of symbols that it disagrees on. > > What can you do? Assuming that you want to use iSER, use the > open-iscsi kernel modules from kernel + open-iscsi userspace tools > from open-iscsi.org. Another (easier) option is to install OFED that > has open-iscsi with iSER support. > > Erez > > -- > > You received this message because you are subscribed to the Google Groups > "open-iscsi" group. > To post to this group, send email to open-is...@googlegroups.com. > To unsubscribe from this group, send email to > open-iscsi+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/open-iscsi?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: inserting error with start open-iscsi
I know your meaning because I start the open-iscsi with a error with symbol of ib_iser I don't want use the iser ,can you help me ? 2009/12/16 Ulrich Windl > On 15 Dec 2009 at 18:18, Xintao Zhang wrote: > > > Hey all > > Therer is a error with inserting the ib_iser.ko as following: > > == > > [r...@localhost init.d]# insmod > > Generally you should use "modprobe" instead of "insmod". I have no idea on > your > specific problem, however. > > > /lib/modules/2.6.18-8.el5/kernel/drivers/infiniband/ulp/iser/ib_iser.ko > > insmod: error inserting > > > '/lib/modules/2.6.18-8.el5/kernel/drivers/infiniband/ulp/iser/ib_iser.ko': > > -1 Unknown symbol in module > > == > > who can help me? > > > > -- > > > > You received this message because you are subscribed to the Google Groups > "open-iscsi" group. > > To post to this group, send email to open-is...@googlegroups.com. > > To unsubscribe from this group, send email to > open-iscsi+unsubscr...@googlegroups.com > . > > For more options, visit this group at > http://groups.google.com/group/open-iscsi?hl=en. > > > > > > > > > -- > > You received this message because you are subscribed to the Google Groups > "open-iscsi" group. > To post to this group, send email to open-is...@googlegroups.com. > To unsubscribe from this group, send email to > open-iscsi+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/open-iscsi?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: Help:insmod: error inserting ib_iser.ko
I guess that you want to run open-iscsi over iscsi_tcp which is the default open-iscsi transport. Assuming that all other modules were loaded successfully (libiscsi, iscsi_tcp, scsi_transport_iscsi and libiscsi_tcp (depends on the version of open-iscsi that you use)), you don't need to do anything. open-iscsi has multiple transport (iscsi_tcp, ib_iser, bnx2i, cxgb3i). The error that you got means that the ib_iser transport could not be loaded, but you don't need iSER anyway. Erez On Wed, Dec 16, 2009 at 11:47 AM, Xintao Zhang wrote: > I don't want use th "iser" > I want the open-iscsi run normally run,can you help me? > > 2009/12/16 Erez Zilber >> >> On Tue, Dec 15, 2009 at 12:26 PM, DeepBlue >> wrote: >> > There is a error with I inserting the ib_iser.ko module as following: >> > >> > [r...@localhost init.d]# insmod /lib/modules/2.6.18-8.el5/kernel/ >> > drivers/infiniband/ulp/iser/ib_iser.ko >> > insmod: error inserting '/lib/modules/2.6.18-8.el5/kernel/drivers/ >> > infiniband/ulp/iser/ib_iser.ko': -1 Unknown symbol in module >> > >> > my linux kernel 2.6.18-8.el5 >> > who can help me? >> > >> >> This is because your ib_iser module was built against open-iscsi from >> the redhat kernel (2.6.18-8.el5). You are currently running open-iscsi >> modules that you took from open-iscsi.org. If you run 'dmesg -c', >> you'll see the list of symbols that it disagrees on. >> >> What can you do? Assuming that you want to use iSER, use the >> open-iscsi kernel modules from kernel + open-iscsi userspace tools >> from open-iscsi.org. Another (easier) option is to install OFED that >> has open-iscsi with iSER support. >> >> Erez >> >> -- >> >> You received this message because you are subscribed to the Google Groups >> "open-iscsi" group. >> To post to this group, send email to open-is...@googlegroups.com. >> To unsubscribe from this group, send email to >> open-iscsi+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/open-iscsi?hl=en. >> >> > > -- > > You received this message because you are subscribed to the Google Groups > "open-iscsi" group. > To post to this group, send email to open-is...@googlegroups.com. > To unsubscribe from this group, send email to > open-iscsi+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/open-iscsi?hl=en. > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: Suggestion for new logging mechanism in open-iscsi
On Wed, Dec 2, 2009 at 10:55 AM, Erez Zilber wrote: > I'd like to make some changes in the logging in open-iscsi. The > current status is as follows: > > kernel modules: > > * We use iscsi_cls_session_printk & iscsi_cls_conn_printk in > scsi_transport_iscsi.c. They are sometimes wrapped by macros (e.g. > ISCSI_DBG_TRANS_SESSION). These macros use KERN_INFO and are > controlled by module parameters. > > * We use iscsi_session_printk & iscsi_conn_printk for the rest of the > kernel code.These macros wrap iscsi_cls_session_printk & > iscsi_cls_conn_printk accordingly. They are sometimes wrapped by > macros (e.g. ISCSI_SW_TCP_DBG). These macros use KERN_INFO and are > controlled by module parameters. > > * We sometimes use printk calls. > > userspace: > > We use log_warning, log_error & log_debug. They depend on the logging > level that we use (0-8). if (log_level > level), the log is sent to > syslog with the appropriate log level (LOG_WARNING/LOG_ERR/LOG_DEBUG). > > My motivation: with the current logging mechanism, if an error occurs, > I'm unable to tell exactly what happened. The default logging level is > too low. Increasing it affects performance. Another problem is that > open-iscsi has too many logging mechanisms. > > I suggest that: > 1. For kernel modules, we will have 'events' (or any better name that > you suggest) like 'session', 'conn', 'eh', 'cmd' etc. For each event, > we will have a logging level. For example, the user may want to set > the 'conn' event to 'DEBUG'. It means that we will print all conn > related logs that are DEBUG and above (e.g. WARNING, ERROR). I suggest that each kernel module will have its own events. Each event will be represented by a module parameter (with some default value). > 2. For userspace code, we could do the same (i.e. have events and a > log level per event). Regarding the 'events' in userspace - we will have events A, B & C for iscsid and events D, E & F for iscsiadm. For each event, we will probably have a default logging level. The user may want to run with another logging level for each event. For iscsid, I suggest that we add this to iscsid.conf. For iscsiadm, the user will be able to do something like: iscsiadm -d some_level - this will set all events to 'some_level' iscsiadm -dE level_for_E -dF level_for_F - this will set the event 'E' to 'level_for_E' and the event 'F' to 'level_for_F'. The event 'D' will use the default logging level. Comments? Thanks, Erez -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
RE: minimum password length check
> -Original Message-
> From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com]
> On Behalf Of Ulrich Windl
> Sent: Wednesday, December 16, 2009 1:08 PM
> To: open-iscsi@googlegroups.com
> Subject: Re: minimum password length check
>
> On 15 Dec 2009 at 22:47, shyam_i...@dell.com wrote:
>
> > From the spec:
> > "
> >CHAP secrets MUST be an integral number of bytes (octets). A
> >compliant implementation SHOULD NOT continue with the login step
> in
> >which it should send a CHAP response (CHAP_R, Section 11.1.4
> >Challenge Handshake Authentication Protocol (CHAP)) unless it can
> >verify that the CHAP secret is at least 96 bits, or that IPsec
> >encryption is being used to protect the connection.
> > "
>
> You picked up an "interesting" issue: The Microsoft Initiator limits
> the length of
> the secret to 16 characters (AFAIR). I wrote a lottle program that
> generates
> random secrets and estimated the entropy (i.e. number of bits):
>
> With 16 random letters, you are at about 92 bits (e.g.
mMPuhxfKAYuIFTjZ)
> With 16 random letters with digits you are at about 95 bits (e.g.
> b3v4B8mRoiFWjpF9)
>
> The bad thing is that some characters look quite similar so users,
like
> '0'
> and'O', or '1' and 'l'. When trying to omit those potentially
confusing
> characters
> (plus adding other punctuation characters, leaving out space for
> obvious reasons),
> I'm at about 83 bits (e.g. u\FphNwuuWCT74+h).
>
> As a side note: Passwords with only six letters in one case only make
> about 28
> bits. Now if you think that most users will use words, you can guess
> how poor
> those passwords actually are.
>
> Using the fully printable ASCII characterset without those characters
> that are
> considered "unsafe" in UNIX, 16 characters would have about 102 bits
of
> entropy
> (e.g. !)Zbl(p7%Hd88L>T)
>
> >
> > The spec suggests that a chap secret be at least 96bits or (12
> > characters) but I see that only the AUTH_STR_MAX_LEN of 256
> characters
> > is used for error checking.
>
> Even when just using digits, that would be 850 bits of entropy,
> probably enough ;-
> )
>
> Regards,
> Ulrich
>
> >
> > Am I reading this correctly ?
> >
> > -Shyam Iyer
> >
> > --
> >
> > You received this message because you are subscribed to the Google
> Groups "open-iscsi" group.
> > To post to this group, send email to open-is...@googlegroups.com.
> > To unsubscribe from this group, send email to open-
> iscsi+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> http://groups.google.com/group/open-iscsi?hl=en.
> >
> >
>
Essentially what you are saying is that we haven't implemented the
secret's bit randomness calculation to check if has atleast 96bits of
entropy.
So I guess we should do some thing like this
If (check_96bit_entropy() && secret < AUTH_MAX_STR_LEN) {
Use_secret
}
else {
Secret not strong enough ..throw error...
}
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To post to this group, send email to open-is...@googlegroups.com.
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
Re: Help:insmod: error inserting ib_iser.ko
Thanks Erez 2009/12/16 Erez Zilber > I guess that you want to run open-iscsi over iscsi_tcp which is the > default open-iscsi transport. Assuming that all other modules were > loaded successfully (libiscsi, iscsi_tcp, scsi_transport_iscsi and > libiscsi_tcp (depends on the version of open-iscsi that you use)), you > don't need to do anything. open-iscsi has multiple transport > (iscsi_tcp, ib_iser, bnx2i, cxgb3i). The error that you got means that > the ib_iser transport could not be loaded, but you don't need iSER > anyway. > > Erez > > On Wed, Dec 16, 2009 at 11:47 AM, Xintao Zhang > wrote: > > I don't want use th "iser" > > I want the open-iscsi run normally run,can you help me? > > > > 2009/12/16 Erez Zilber > >> > >> On Tue, Dec 15, 2009 at 12:26 PM, DeepBlue > >> wrote: > >> > There is a error with I inserting the ib_iser.ko module as following: > >> > > >> > [r...@localhost init.d]# insmod /lib/modules/2.6.18-8.el5/kernel/ > >> > drivers/infiniband/ulp/iser/ib_iser.ko > >> > insmod: error inserting '/lib/modules/2.6.18-8.el5/kernel/drivers/ > >> > infiniband/ulp/iser/ib_iser.ko': -1 Unknown symbol in module > >> > > >> > my linux kernel 2.6.18-8.el5 > >> > who can help me? > >> > > >> > >> This is because your ib_iser module was built against open-iscsi from > >> the redhat kernel (2.6.18-8.el5). You are currently running open-iscsi > >> modules that you took from open-iscsi.org. If you run 'dmesg -c', > >> you'll see the list of symbols that it disagrees on. > >> > >> What can you do? Assuming that you want to use iSER, use the > >> open-iscsi kernel modules from kernel + open-iscsi userspace tools > >> from open-iscsi.org. Another (easier) option is to install OFED that > >> has open-iscsi with iSER support. > >> > >> Erez > >> > >> -- > >> > >> You received this message because you are subscribed to the Google > Groups > >> "open-iscsi" group. > >> To post to this group, send email to open-is...@googlegroups.com. > >> To unsubscribe from this group, send email to > >> open-iscsi+unsubscr...@googlegroups.com > . > >> For more options, visit this group at > >> http://groups.google.com/group/open-iscsi?hl=en. > >> > >> > > > > -- > > > > You received this message because you are subscribed to the Google Groups > > "open-iscsi" group. > > To post to this group, send email to open-is...@googlegroups.com. > > To unsubscribe from this group, send email to > > open-iscsi+unsubscr...@googlegroups.com > . > > For more options, visit this group at > > http://groups.google.com/group/open-iscsi?hl=en. > > > > -- > > You received this message because you are subscribed to the Google Groups > "open-iscsi" group. > To post to this group, send email to open-is...@googlegroups.com. > To unsubscribe from this group, send email to > open-iscsi+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/open-iscsi?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: Help:insmod: error inserting ib_iser.ko
I start open-iscsi with you method,but appear a problem. I use the tail -f /var/log/messages can't find iscis device. can you help me? 2009/12/17 Xintao Zhang > Thanks Erez > > > 2009/12/16 Erez Zilber > >> I guess that you want to run open-iscsi over iscsi_tcp which is the >> default open-iscsi transport. Assuming that all other modules were >> loaded successfully (libiscsi, iscsi_tcp, scsi_transport_iscsi and >> libiscsi_tcp (depends on the version of open-iscsi that you use)), you >> don't need to do anything. open-iscsi has multiple transport >> (iscsi_tcp, ib_iser, bnx2i, cxgb3i). The error that you got means that >> the ib_iser transport could not be loaded, but you don't need iSER >> anyway. >> >> Erez >> >> On Wed, Dec 16, 2009 at 11:47 AM, Xintao Zhang >> wrote: >> > I don't want use th "iser" >> > I want the open-iscsi run normally run,can you help me? >> > >> > 2009/12/16 Erez Zilber >> >> >> >> On Tue, Dec 15, 2009 at 12:26 PM, DeepBlue > > >> >> wrote: >> >> > There is a error with I inserting the ib_iser.ko module as following: >> >> > >> >> > [r...@localhost init.d]# insmod /lib/modules/2.6.18-8.el5/kernel/ >> >> > drivers/infiniband/ulp/iser/ib_iser.ko >> >> > insmod: error inserting '/lib/modules/2.6.18-8.el5/kernel/drivers/ >> >> > infiniband/ulp/iser/ib_iser.ko': -1 Unknown symbol in module >> >> > >> >> > my linux kernel 2.6.18-8.el5 >> >> > who can help me? >> >> > >> >> >> >> This is because your ib_iser module was built against open-iscsi from >> >> the redhat kernel (2.6.18-8.el5). You are currently running open-iscsi >> >> modules that you took from open-iscsi.org. If you run 'dmesg -c', >> >> you'll see the list of symbols that it disagrees on. >> >> >> >> What can you do? Assuming that you want to use iSER, use the >> >> open-iscsi kernel modules from kernel + open-iscsi userspace tools >> >> from open-iscsi.org. Another (easier) option is to install OFED that >> >> has open-iscsi with iSER support. >> >> >> >> Erez >> >> >> >> -- >> >> >> >> You received this message because you are subscribed to the Google >> Groups >> >> "open-iscsi" group. >> >> To post to this group, send email to open-is...@googlegroups.com. >> >> To unsubscribe from this group, send email to >> >> open-iscsi+unsubscr...@googlegroups.com >> . >> >> For more options, visit this group at >> >> http://groups.google.com/group/open-iscsi?hl=en. >> >> >> >> >> > >> > -- >> > >> > You received this message because you are subscribed to the Google >> Groups >> > "open-iscsi" group. >> > To post to this group, send email to open-is...@googlegroups.com. >> > To unsubscribe from this group, send email to >> > open-iscsi+unsubscr...@googlegroups.com >> . >> > For more options, visit this group at >> > http://groups.google.com/group/open-iscsi?hl=en. >> > >> >> -- >> >> You received this message because you are subscribed to the Google Groups >> "open-iscsi" group. >> To post to this group, send email to open-is...@googlegroups.com. >> To unsubscribe from this group, send email to >> open-iscsi+unsubscr...@googlegroups.com >> . >> For more options, visit this group at >> http://groups.google.com/group/open-iscsi?hl=en. >> >> >> > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
open-iscsi 2.0.707-0.19 & iface
Version 2.0.707-0.19 of open-iscsi which comes with SUSE SLES 10 SP1 with kernel 2.6.16.46-0.12-default does not seem to support the iface option or parameters. So how do you configure multiple NICs as iSCSI interfaces so that you can leverage devicemapper multipathing? -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
[PATCH] support multidisk iBFTs
Please could the attached patch be considered for inclusion in the open-iscsi
source.
Regards,
Alex Zeffertt
Changelog:
-
iSCSI Boot Firmware Tables are able to specify up to two iSCSI targets, but
until now open-iscsi has only been able to display/attach one of these.
This change enables open-iscsi to display/attach both targets when the iBFT
contains two valid entries. The following commands are affected:
iscsiadm -m fw [-l]
iscsistart -b
iscsistart -f
The primary benefit of this change is that it makes possible for initrds to
mount a multipath device, where the slave devices are iSCSI LUNs specified by
the iBFT.
Signed-off-by: alex.zeffe...@eu.citrix.com
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To post to this group, send email to open-is...@googlegroups.com.
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
diff -urN a/include/fw_context.h b/include/fw_context.h
--- a/include/fw_context.h 2008-07-01 02:14:03.0 +0100
+++ b/include/fw_context.h 2009-12-16 15:33:15.0 +
@@ -40,7 +40,17 @@
char isid[10];
};
-extern int fw_get_entry(struct boot_context *context, const char *filepath);
+/*
+ * Parse the firmware into context[] and return the number of entries written.
+ */
+extern int fw_get_entry(struct boot_context context[], int max_entries, const char *filepath);
+
+/*
+ * Print the contents of context.
+ */
extern void fw_print_entry(struct boot_context *context);
+/* PPC may have 1 entry, iBFT on x86 may have 1 or 2 entries */
+#define FWPARAM_MAX_ENTRIES 2
+
#endif /* FWPARAM_CONTEXT_H_ */
diff -urN a/usr/iscsiadm.c b/usr/iscsiadm.c
--- a/usr/iscsiadm.c 2008-07-01 02:14:03.0 +0100
+++ b/usr/iscsiadm.c 2009-12-16 15:33:15.0 +
@@ -1960,32 +1960,40 @@
static int exec_fw_op(discovery_rec_t *drec, int do_login, int info_level)
{
- struct boot_context context;
- struct node_rec *rec;
+ struct boot_context context[FWPARAM_MAX_ENTRIES];
+ struct boot_context *pcontext = context;
+ int entries = 0;
int ret = 0;
- memset(&context, 0, sizeof(struct boot_context));
- ret = fw_get_entry(&context, NULL);
- if (ret) {
- log_error("Could not read fw values.");
- return ret;
+ memset(context, 0, sizeof(context));
+ entries = fw_get_entry(context, FWPARAM_MAX_ENTRIES, NULL);
+ if (entries == 0) {
+ log_error("Could not find fw values.");
+ return -1;
}
+ while (entries-- && ret == 0) {
+ struct node_rec *rec;
+ rec = fw_create_rec_by_entry(pcontext);
+ if (!rec)
+ return ENODEV;
+
+ /* if discovery, print nodes that were found. */
+ if (drec)
+ /* this looks wrong... aren't we supposed to do something
+ * with drec - like fill it out for example?
+ */
+ print_fw_nodes(rec, info_level);
+
+ if (do_login)
+ ret = login_portal(NULL, NULL, rec);
+ free(rec);
- rec = fw_create_rec_by_entry(&context);
- if (!rec)
- return ENODEV;
-
- /* if discovery, print nodes that were found. */
- if (drec)
- print_fw_nodes(rec, info_level);
-
- if (do_login)
- ret = login_portal(NULL, NULL, rec);
- free(rec);
-
- /* print the fw node info if called in fw mode with no params */
- if (!do_login && !drec)
- fw_print_entry(&context);
+ /* print the fw node info if called in fw mode with no params */
+ if (!do_login && !drec)
+ fw_print_entry(pcontext);
+
+ pcontext++;
+ }
return ret;
}
diff -urN a/usr/iscsistart.c b/usr/iscsistart.c
--- a/usr/iscsistart.c 2008-07-01 02:14:03.0 +0100
+++ b/usr/iscsistart.c 2009-12-16 15:35:20.0 +
@@ -49,8 +49,6 @@
struct iscsi_daemon_config daemon_config;
struct iscsi_daemon_config *dconfig = &daemon_config;
-static node_rec_t config_rec;
-
static char program_name[] = "iscsistart";
static int mgmt_ipc_fd;
@@ -120,7 +118,7 @@
return rc;
}
-static int setup_session(void)
+static int setup_session(node_rec_t *config_rec)
{
iscsiadm_req_t req;
iscsiadm_rsp_t rsp;
@@ -130,18 +128,18 @@
* For root boot we cannot change this so increase to account
* for boot using static setup.
*/
- config_rec.session.initial_login_retry_max = 120;
+ config_rec->session.initial_login_retry_max = 120;
/* we cannot answer so turn off */
- config_rec.conn[0].timeo.noop_out_interval = 0;
- config_rec.conn[0].timeo.noop_out_timeout = 0;
+ config_rec->conn[0].timeo.noop_out_interval = 0;
+ config_rec->conn[0].timeo.noop_out_timeout = 0;
- printf("%s: Logging into %s %s:%d,%d\n", program_name, config_rec.name,
- config_rec.conn[0].address, config_rec.conn[0].port,
- config_rec.tpgt);
+ printf("%s: Logging into %s %s:%d,%d\n", program_name, config_rec->name,
+ config_rec->conn[0].address, config_rec->conn[0].port,
+ config_rec->tpgt);
memset(&req, 0, sizeof(req));
req.command = MGMT_IPC_SESSION_LOGIN;
- memcpy(&req.u.session.rec, &config_rec, sizeof(node_rec_t));
+ mem
Re: Write back cache
Ulrich Windl wrote: > On 15 Dec 2009 at 10:32, Geoff Galitz wrote: > >>> You might want to post to linux-kernel or linux-scsi list. The iscsi >>> initiator does not control this, but I think there are some scsi or >>> block layer tools that can do it if the target/disk supports it. >> I'll do that. I did try to use sgmode to enable this, but that just did not >> work. > > Actually I think if you can't do it on the remote end (i.e. target), the > initiator > will also fail, because iSCSI just transports the request to the target. > I think Geoff and I were talking about using a tool like from sg3_utils, which sends scsi commands to the target. The scsi commands can change settings or do things like fail over a lun/controller. You are right though. The iscsi stuff has nothing to do with it. The scsi commands are just sent over iscsi. And it would be strange not to have a user friendly interface on the target, but allow you to do it with sg utils. -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: [PATCH] Maintain a list of nop-out PDUs that almost timed out
Erez Zilber wrote:
> On Tue, Dec 15, 2009 at 10:34 AM, Mike Christie wrote:
>> Erez Zilber wrote:
>>> Maintain a list of nop-out PDUs that almost timed out.
>>> With this information, you can understand and debug the
>>> whole system: you can check your target and see what caused
>>> it to be so slow on that specific time, you can see if your
>>> network was very busy during that time etc.
>>>
>>> Signed-off-by: Erez Zilber
>>>
>> Sorry for the late reply. Thanks for doing this work!
>>
>>
>> @@ -88,11 +89,12 @@ static struct option const long_options[] =
>> {"killiscsid", required_argument, NULL, 'k'},
>> {"debug", required_argument, NULL, 'd'},
>> {"show", no_argument, NULL, 'S'},
>> + {"noopinfo", required_argument, NULL, 'N'},
>> {"version", no_argument, NULL, 'V'},
>> {"help", no_argument, NULL, 'h'},
>> {NULL, 0, NULL, 0},
>> };
>>
>>
>> Do you think you want something more generic like a get-debug-info type
>> of feature? Maybe in the future we could also show how many times a scsi
>> command has timed out or almost timed out (user can adjust scsi timer
>> then) or how many times the scsi eh has fired and how many times a
>> abort, lu or target reset has timed out?
>>
>> So maybe it would be get like get stats where then the noop info is the
>> first stat and in the future we will have more?
>
> Sounds good. Let's change it to {"debuginfo", required_argument, NULL, 'i'}.
> OK?
Ok with me.
>>
>>
>>
>> @@ -994,8 +997,25 @@ static int iscsi_nop_out_rsp(struct iscsi_task *task,
>> if (iscsi_recv_pdu(conn->cls_conn, (struct iscsi_hdr *)nop,
>>data, datalen))
>> rc = ISCSI_ERR_CONN_FAILED;
>> - } else
>> + } else {
>> + ping_delay = jiffies - conn->last_ping;
>> +
>> + /* Check if the ping has almost timed out */
>> + if (ping_delay >=
>> + (session->noop_threshold * (conn->ping_timeout * HZ)) /
>> + 100) {
>> + mutex_lock(&conn->noop_info_mutex);
>>
>>
>>
>> We annot use a mutex here, because we run from a bottom half (softirq
>> for iscsi and a tasklet for iser), and we cannot sleep in a bh since
>> there is no process context.
>
> You're right. I'll replace the mutex with a spinlock.
>
>>
>> + idx = conn->noop_info_arr_idx;
>> + conn->noop_info_arr[idx].tv = conn->tmp_noop_tv;
>> + conn->noop_info_arr[idx].elapsed_time_msec =
>> ping_delay;
>>
>> I think ping_delay is just in jiffies, so you have to do some sort of
>> jiffies_to_msec call (I cannot rememeber the name of the helper but
>> there is one).
>
> I think it should be: conn->noop_info_arr[idx].elapsed_time_msec =
> ping_delay * HZ / 1000
I think the function is jiffies_to_msecs()
>
>>
>> + conn->noop_info_arr[idx].init = 1;
>> + conn->noop_info_arr_idx =
>> + (conn->noop_info_arr_idx + 1) %
>> NOOP_INFO_ARR_LEN;
>>
>>
>> I am not getting the reason for the division?
>
> Are you talking about "conn->noop_info_arr_idx =
> (conn->noop_info_arr_idx + 1) % NOOP_INFO_ARR_LEN"? It's a cyclic
> array.
>
Ah, nevermind :)
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To post to this group, send email to open-is...@googlegroups.com.
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
Re: open-iscsi on SUSE 11
Stuart Little wrote: > Hi, > Using open-iscsi-2.0.869-8.1 (x86_64) on a SUSE 11.0 based machine, > connecting to an HP D2D. > > Generally operation seems fine but I have some issues:- > > I cannot get the system to reconnect as start, if I configure open-isci to > start at boot > the system hangs, I have to do a force reboot and boot single user, > configure > open-iscsi to off. > Starting open-iscsi by hand always works, but login appears to work on two > interfaces only. > > Messages displayed during manual start:- > > etc/init.d/open-iscsi start > Starting iSCSI initiator service: > done > Setting up iSCSI targets: Logging in to [iface: default, target: > iqn.1986-03.com.hp:storage.d2dbs.hu191248n0.500110a0002b2aa6.autoloader2.drive, > portal: 192.168.2.85,3260] > > Logging in to [iface: iser, target: > iqn.1986-03.com.hp:storage.d2dbs.hu191248n0.500110a0002b2aa6.autoloader2.drive, > portal: 192.168.2.85,3260] > Logging in to [iface: default, target: > iqn.1986-03.com.hp:storage.d2dbs.hu191248n0.500110a0002b2aac.autoloader2.robotic > s, portal: 192.168.2.85,3260] > Logging in to [iface: iser, target: > iqn.1986-03.com.hp:storage.d2dbs.hu191248n0.500110a0002b2aac.autoloader2.robotic > s, portal: 192.168.2.85,3260] > Login to [iface: default, target: > iqn.1986-03.com.hp:storage.d2dbs.hu191248n0.500110a0002b2aa6.autoloader2.drive, > portal: 192.168.2.85,3260]: successful > Login to [iface: default, target: > iqn.1986-03.com.hp:storage.d2dbs.hu191248n0.500110a0002b2aac.autoloader2.robotic > s, portal: 192.168.2.85,3260]: successful > > I can change the constraints in the startup to start open-iscsi after > everything else and it will > still hang. > Could the failure to connect on the iser interfaces be a cause of the > failure > to start at boot? Yes. Is your system completely hung or does it just not proceed. It looks like we cannot log into the iser targets. With the default time outs, it could retry for around 5 minutes, so the system will look hung, but eventually it would proceed. Decrease node.conn[0].timeo.login_timeout and node.session.initial_login_retry_max. > If so is there a way to disable the iser interfaces and stick with the tcp > connections? Set the node.startup to manual for the iser ones. I think you would want to set things up so the infinniband stuff is tarted earlier or iscsi is started later. Then you can leave the node.startup values alone. > > Another problem was uncovered when a real local tape drive was added, while > status messages suggsted that > the open-iscsi interfaces hand changed from using /dev/st0 to /dev/st1 the > system would not actually You lost me. So the tape device is local or accessed through iscsi? > work correctly. I have not tried a reinstall yet, but removal of the > offending > local drive let the system > work sensibly again. > > Cheers, > Stuart > > > > -- > > You received this message because you are subscribed to the Google Groups > "open-iscsi" group. > To post to this group, send email to open-is...@googlegroups.com. > To unsubscribe from this group, send email to > open-iscsi+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/open-iscsi?hl=en. > > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: minimum password length check
shyam_i...@dell.com wrote:
> So I guess we should do some thing like this
>
>
> If (check_96bit_entropy() && secret < AUTH_MAX_STR_LEN) {
> Use_secret
> }
> else {
> Secret not strong enough ..throw error...
> }
>
We do not check. The only problem would be if we added one now lots of
people are going to get errors in existing set ups. Some might not boot.
Maybe add a error message for a while, then make it mandatory in a later
release.
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To post to this group, send email to open-is...@googlegroups.com.
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
Re: [Open-FCoE] [fcoemon PATCH v2 00/11] rfcoemon restructuring
shyam_i...@dell.com wrote: > Shouldn't the requirement to administer DCB be FCoE independent ? After > all DCB is required for other protocols like iscsi as well. > It is not required for iscsi. I think people are thinking it is going to be useful for iscsi though. -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: open-iscsi 2.0.707-0.19 & iface
On 15 Dec 2009 at 21:45, Mark wrote: > Version 2.0.707-0.19 of open-iscsi which comes with SUSE SLES 10 SP1 > with kernel 2.6.16.46-0.12-default does not seem to support the iface > option or parameters. So how do you configure multiple NICs as iSCSI > interfaces so that you can leverage devicemapper multipathing? SLES 10 SP1 is out of support, and SP2 will be soon as well. You should try SP3 (or even SLES 11). -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: Suggestion for new logging mechanism in open-iscsi
Hi! One thing to decide would be whether you want to have hierarchical levels for debugging per subsystem (you call them "events" I think), or whether to have a bitmask-like value to enable or disable specific classes of messages (like openLDAP does it). Personally I think that short debug output is perferrable to long output. With commercial software I have hjad several cases where support really wanted me to capture more than a GB of logs, where the logs contained really every stupid thing the program did. In the end they said they could not find the problem, because they did not log that specific case... 8-( Regards, Ulrich On 16 Dec 2009 at 17:31, Erez Zilber wrote: > On Wed, Dec 2, 2009 at 10:55 AM, Erez Zilber wrote: > > I'd like to make some changes in the logging in open-iscsi. The > > current status is as follows: > > > > kernel modules: > > > > * We use iscsi_cls_session_printk & iscsi_cls_conn_printk in > > scsi_transport_iscsi.c. They are sometimes wrapped by macros (e.g. > > ISCSI_DBG_TRANS_SESSION). These macros use KERN_INFO and are > > controlled by module parameters. > > > > * We use iscsi_session_printk & iscsi_conn_printk for the rest of the > > kernel code.These macros wrap iscsi_cls_session_printk & > > iscsi_cls_conn_printk accordingly. They are sometimes wrapped by > > macros (e.g. ISCSI_SW_TCP_DBG). These macros use KERN_INFO and are > > controlled by module parameters. > > > > * We sometimes use printk calls. > > > > userspace: > > > > We use log_warning, log_error & log_debug. They depend on the logging > > level that we use (0-8). if (log_level > level), the log is sent to > > syslog with the appropriate log level (LOG_WARNING/LOG_ERR/LOG_DEBUG). > > > > My motivation: with the current logging mechanism, if an error occurs, > > I'm unable to tell exactly what happened. The default logging level is > > too low. Increasing it affects performance. Another problem is that > > open-iscsi has too many logging mechanisms. > > > > I suggest that: > > 1. For kernel modules, we will have 'events' (or any better name that > > you suggest) like 'session', 'conn', 'eh', 'cmd' etc. For each event, > > we will have a logging level. For example, the user may want to set > > the 'conn' event to 'DEBUG'. It means that we will print all conn > > related logs that are DEBUG and above (e.g. WARNING, ERROR). > > I suggest that each kernel module will have its own events. Each event > will be represented by a module parameter (with some default value). > > > 2. For userspace code, we could do the same (i.e. have events and a > > log level per event). > > Regarding the 'events' in userspace - we will have events A, B & C for > iscsid and events D, E & F for iscsiadm. For each event, we will > probably have a default logging level. The user may want to run with > another logging level for each event. For iscsid, I suggest that we > add this to iscsid.conf. For iscsiadm, the user will be able to do > something like: > > iscsiadm -d some_level - this will set all events to 'some_level' > iscsiadm -dE level_for_E -dF level_for_F - this will set the event 'E' > to 'level_for_E' and the event 'F' to 'level_for_F'. The event 'D' > will use the default logging level. > > Comments? > > Thanks, > Erez > > -- > > You received this message because you are subscribed to the Google Groups > "open-iscsi" group. > To post to this group, send email to open-is...@googlegroups.com. > To unsubscribe from this group, send email to > open-iscsi+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/open-iscsi?hl=en. > > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
RE: minimum password length check
On 17 Dec 2009 at 0:55, shyam_i...@dell.com wrote: > Essentially what you are saying is that we haven't implemented the > secret's bit randomness calculation to check if has atleast 96bits of > entropy. > No, I just wanted to point out that the quality of a secret key cannot simply be measured with "strlen(password)", and that 96 bits of randomness may require a longer string as one might initially have guessed. Regards, Ulrich -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
