Re: [PATCH] Fix compilation warnings in usr/kernel code
Erez Zilber wrote: > Fix compilation warnings and modify the Makefiles to treat > warnings as errors. > Just a update on this patch. I was doing more testing and on Fedora 9, I get: isns.c: In function ‘build_dev_reg_req’: isns.c:146: error: dereferencing pointer ‘lss.24’ does break strict-aliasing rules isns.c:146: note: initialized from here isns.c:153: error: dereferencing pointer ‘lss.24’ does break strict-aliasing rules isns.c:153: note: initialized from here isns.c:157: error: dereferencing pointer ‘lss.27’ does break strict-aliasing rules isns.c:157: note: initialized from here make[1]: *** [isns.o] Error 1 make[1]: Leaving directory `/home/mnc/kernel/iscsi/open-iscsi/devel/tmp/open-iscsi/usr' --~--~-~--~~~---~--~~ 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 open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: [PATCH] libiscsi back port for RHEL5.{0,1,2,3}/SLES10
Rakesh Ranjan wrote: > Mike Christie wrote: >> Rakesh Ranjan wrote: >>> Hi Mike, >>> >>> Herein attached updated patch based against current open-iscsi head. You >>> can simply rename it to 2.6.14-23_compat.patch. >>> >> the patch does not work with upstream 2.6.21 and 2.6.23. >> >> With 2.6.21 i get: >> >> /home/mnc/open-iscsi/kernel/scsi_transport_iscsi.c:2084: error: too many >> arguments to function ‘netlink_kernel_create’ >> >> I think the patch changed the netlink_kernel_create ifdefs in >> open_iscsi_compat.h. There was a ifdef for 2.6.21 and now it is 2.6.19 >> >> >> In 2.6.32 I get: >> >> /home/mnc/open-iscsi/kernel/scsi_transport_iscsi.c: In function >> ‘iscsi_lookup_endpoint’: >> /home/mnc/open-iscsi/kernel/scsi_transport_iscsi.c:245: error: ‘struct >> kset’ has no member named ‘rwsem’ >> /home/mnc/open-iscsi/kernel/scsi_transport_iscsi.c:252: error: ‘struct >> kset’ has no member named ‘rwsem’ > > Hi mike, > > Fixed patch attached. > Thanks again for your work on this! Merged in commit 428e08c659f2e3792962b90f098f1bb33bfe1411. --~--~-~--~~~---~--~~ 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 open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: [Patch 2/2] iscsiadm: checking return value of iscsid_req_wait() in iscsid_req_by_rec()
Yangkook Kim wrote:
> This patch adds some codes to output logs to reflect the return value
> of iscsid_req_wait() for outputting logging.
>
Thanks for the patch!
It looks like you used the git tree. What branch did you use? I am
asking because I could not find the code below.
> int nsec;
> @@ -231,7 +259,18 @@
> err = iscsid_req_by_rec_async(cmd, rec, &fd);
> if (err)
> return err;
> - return iscsid_req_wait(cmd, fd);
> + err = iscsid_req_wait(cmd, fd);
> + if (err) {
> + log_error("Could not login to [iface: %s, target: %s, "
> + "portal: %s,%d]: ", rec->iface.name,
> + rec->name, rec->conn[0].address,
> + rec->conn[0].port);
> + } else
> + printf("Login to [iface: %s, target: %s, portal: "
> + "%s,%d]: successful\n", rec->iface.name,
> + rec->name, rec->conn[0].address,
> + rec->conn[0].port);
> + return err;
> }
>
> int iscsid_req_by_sid_async(iscsiadm_cmd_e cmd, int sid, int *fd)
> @@ -312,34 +351,6 @@
> iface_setup_defaults(&rec->iface);
> }
>
> -void iscsid_handle_error(mgmt_ipc_err_e err)
> -{
> - static char *err_msgs[] = {
> - /* 0 */ "",
> - /* 1 */ "unknown error",
> - /* 2 */ "not found",
> - /* 3 */ "no available memory",
> - /* 4 */ "encountered connection failure",
> - /* 5 */ "encountered iSCSI login failure",
> - /* 6 */ "encountered iSCSI database failure",
> - /* 7 */ "invalid parameter",
> - /* 8 */ "connection timed out",
> - /* 9 */ "internal error",
> - /* 10 */ "encountered iSCSI logout failure",
> - /* 11 */ "iSCSI PDU timed out",
> - /* 12 */ "iSCSI driver not found. Please make sure it
> is loaded, and retry the operation",
> - /* 13 */ "daemon access denied",
> - /* 14 */ "iSCSI driver does not support requested
> capability.",
> - /* 15 */ "already exists",
> - /* 16 */ "Unknown request",
> - /* 17 */ "encountered iSNS failure",
> - /* 18 */ "could not communicate to iscsid",
> - /* 19 */ "encountered non-retryable iSCSI login failure",
> - /* 20 */ "could not connect to iscsid",
> - };
> - log_error("initiator reported error (%d - %s)", err, err_msgs[err]);
> -}
> -
> int __iscsi_match_session(node_rec_t *rec, char *targetname,
> char *address, int port, struct iface_rec *iface)
> {
>
> >
>
--~--~-~--~~~---~--~~
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
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---
Re: [Patch 1/2] iscsiadm: login_portal() misses outputting logs for iscsid_req_by_rec()
Yangkook Kim wrote:
> This patch tries to fix the lack of outputting logs when
> iscsid_req_by_rec is used.
>
> When using iscsid_req_by_rec, the current codes does not tell you whether you
> are successfully logged in or hitting some errors because you cannot
> get into the
> loop of list_for_each_entry_safe() in iscsid_login_reqs_wait(). I
> modify some codes
> so that iscsid_req_by_rec will output logs.
Thanks for the patch! Some questions.
Are you hitting the non async code path? Did you hit the
iscsid_req_by_rec call? How many targets or portals were you logging into?
Question about the patch below.
>
> --- a/usr/iscsiadm.c2009-11-12 06:22:10.0 +0900
> +++ b/usr/iscsiadm.c2009-11-12 06:23:01.0 +0900
> @@ -597,29 +597,31 @@
> INIT_LIST_HEAD(&async_req->list);
> }
>
> - if (async_req)
> - rc = iscsid_req_by_rec_async(MGMT_IPC_SESSION_LOGIN,
> -rec, &fd);
> - else
> - rc = iscsid_req_by_rec(MGMT_IPC_SESSION_LOGIN, rec);
> - /* we raced with another app or instance of iscsiadm */
> - if (rc == MGMT_IPC_ERR_EXISTS) {
> - if (async_req)
> - free(async_req);
> - return 0;
> - } else if (rc) {
> - iscsid_handle_error(rc);
If iscsid_req_by_rec fails, then won't we log an error here?
> - if (async_req)
> - free(async_req);
> - return ENOTCONN;
> - }
> -
> if (async_req) {
> +rc = iscsid_req_by_rec_async(MGMT_IPC_SESSION_LOGIN,
> +rec, &fd);
> + if (rc == MGMT_IPC_ERR_EXISTS) {
> + if (async_req)
> + free(async_req);
> + return 0;
> + } else if (rc) {
> + iscsid_handle_error(rc);
> + if (async_req)
> + free(async_req);
> + return ENOTCONN;
> + }
> list_add_tail(&async_req->list, list);
> async_req->fd = fd;
> async_req->data = rec;
> + return 0;
> + } else {
> + rc = iscsid_req_by_rec(MGMT_IPC_SESSION_LOGIN, rec);
> + if (rc) {
> + iscsid_handle_error(rc);
> + return ENOTCONN;
> + } else
> + return rc;
Does this do almost the same thing? It looks like the only change is
that if we get MGMT_IPC_ERR_EXISTS then iscsid_req_by_rec will now print
out an error message. Did I miss something?
Your patch actually might be clearer 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-iscsi@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
-~--~~~~--~~--~--~---
Re: Infortrend + "iSCSI: detected conn error (1011)" + "TCP Dup ACK"
oh... also, the "ovm1" server is the dom0. That system is connecting to IETD targets from within the dom0 using iscsi-initiator-utils-6.2.0.871-0.7. There are two ifaces setup to connect to two portal IP's on my CentOS 5.3, aka "storage", system. The result is this: [r...@ovm1 ~]# iscsiadm -m session tcp: [1] 192.168.30.1:3260,1 iqn.2009-09.com.itec.storage:tgtd tcp: [2] 192.168.30.1:3260,1 iqn.2009-09.com.itec.storage:tgtd tcp: [3] 192.168.30.2:3260,1 iqn.2009-09.com.itec.storage:tgtd tcp: [4] 192.168.30.2:3260,1 iqn.2009-09.com.itec.storage:tgtd In my REAL test and production OVM 2.2 environments, we have 2 ifaces setup to connect to one load balanced Dell EqualLogic group IP, which results in something like this: [r...@oir7102901 log]# iscsiadm -m session | grep lun0 tcp: [2] 192.168.0.19:3260,1 iqn.2001-05.com.equallogic:0-8a0906-781989902-5a900114ae5e-ovm-t-lun0 tcp: [5] 192.168.0.19:3260,1 iqn.2001-05.com.equallogic:0-8a0906-781989902-5a900114ae5e-ovm-t-lun0 [r...@oir7102901 log]# In our current TEST environment (Dell EqualLogic + Dell powerconnect switch running MTU=9126 + Dell R710 with OVM 2.2 installed) we've had some strange server issues (possible hardware problems. I'm still diagnosing this). However, with regards to iSCSI, I haven't seen any issues and can see (3) dt threads going for my ovm-t-lun0, ovm-t-lun1, and ovm-t-lun2 volumes. The overall throughput is roughly only about 70MB/s TOTAL (that includes metrics from all three of those luns) for reads and writes. The iowait% is my bottleneck at the moment though. And we have not had any "iscsi disconnect" messsages. In our PROD2 environment (Dell m610 blades + Cisco switch modules in the blade chassis-- I believe m1000e-- + Dell powerconnect switch + Dell EqualLogic members) we've had absolutely no issues thus far. The dt tests have the same throughput and have been running for about 8-9 days so far without a single disconnect. On Nov 12, 2009, at 10:15 AM, Hoot, Joseph wrote: > > sorry... wrong information. Here is the correct information. I was doing > some testing in VMWare Fusion VM's for a presentation that I'm giving. The > "storage" server is CentOS 5.3, which dishes out IETD targets for my OVM > servers. The OVM 2.2 environment is as follows: > > [r...@ovm1 ~]# uname -r > 2.6.18-128.2.1.4.9.el5xen > [r...@ovm1 ~]# rpm -qa | grep iscsi > iscsi-initiator-utils-6.2.0.871-0.7.el5 > [r...@ovm1 ~]# > > > > On Nov 10, 2009, at 2:30 PM, Mike Christie wrote: > >> >> Hoot, Joseph wrote: >>> [r...@storage ~]# uname -r >>> 2.6.18-164.el5 >>> [r...@storage ~]# rpm -qa | grep iscsi >>> iscsi-initiator-utils-6.2.0.868-0.18.el5_3.1 >>> [r...@storage ~]# >>> >> >> Weird. >> >> Is 2.6.18-164.el5 the kernel being used in the virtual machine/DonU? Is >> that where you are using iscsi? It looks like the Oracle enterprise >> linux kernel is 2.6.18-164.el5, which looks like it is based on RHEL >> 5.4. The iscsi code in there is the same as RHEL/upstream. No sendwait >> patch. >> >> However, it looks like there is a 2.6.18-128.2.1.4.9 kernel (comes with >> the Oracle VM rpms). In here we have a different iscsi version. It looks >> a little older than what is in 2.6.18-164.el5, but it has the sendwait >> patch I send to dell. Do you use this kernel in the Dom0? Are you using >> this kernel with iscsi? >> >> >> >>> On Nov 10, 2009, at 12:17 PM, Mike Christie wrote: >>> Hoot, Joseph wrote: > I've had about 3 threads of dt (kicking off a bit randomly) on (3) > separate volumes for over a week and haven't had a single disconnect yet. > I am currently using whatever rpm is distributed with Oracle VM v2.2. > I know for sure that they have included the 871 base, plus I believe at > least a one off patch. I can get more details if you'd like. > > But so far so good for now > I think I have the source they are using. Could you do a uname -r, so I can see what kernel they are using. >>> >>> === >>> Joseph R. Hoot >>> Lead System Programmer/Analyst >>> (w) 716-878-4832 >>> (c) 716-759-HOOT >>> joe.h...@itec.suny.edu >>> GPG KEY: 7145F633 >>> === >>> >>> >> >> >>> > > === > Joseph R. Hoot > Lead System Programmer/Analyst > (w) 716-878-4832 > (c) 716-759-HOOT > joe.h...@itec.suny.edu > GPG KEY: 7145F633 > === > > > > === Joseph R. Hoot Lead System Programmer/Analyst (w) 716-878-4832 (c) 716-759-HOOT joe.h...@itec.suny.edu GPG KEY: 7145F633 === --~--~-~--~~~---~--~~ 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 open-iscsi+unsubscr...@googlegroups.com For more options, visit th
Re: Infortrend + "iSCSI: detected conn error (1011)" + "TCP Dup ACK"
sorry... wrong information. Here is the correct information. I was doing some testing in VMWare Fusion VM's for a presentation that I'm giving. The "storage" server is CentOS 5.3, which dishes out IETD targets for my OVM servers. The OVM 2.2 environment is as follows: [r...@ovm1 ~]# uname -r 2.6.18-128.2.1.4.9.el5xen [r...@ovm1 ~]# rpm -qa | grep iscsi iscsi-initiator-utils-6.2.0.871-0.7.el5 [r...@ovm1 ~]# On Nov 10, 2009, at 2:30 PM, Mike Christie wrote: > > Hoot, Joseph wrote: >> [r...@storage ~]# uname -r >> 2.6.18-164.el5 >> [r...@storage ~]# rpm -qa | grep iscsi >> iscsi-initiator-utils-6.2.0.868-0.18.el5_3.1 >> [r...@storage ~]# >> > > Weird. > > Is 2.6.18-164.el5 the kernel being used in the virtual machine/DonU? Is > that where you are using iscsi? It looks like the Oracle enterprise > linux kernel is 2.6.18-164.el5, which looks like it is based on RHEL > 5.4. The iscsi code in there is the same as RHEL/upstream. No sendwait > patch. > > However, it looks like there is a 2.6.18-128.2.1.4.9 kernel (comes with > the Oracle VM rpms). In here we have a different iscsi version. It looks > a little older than what is in 2.6.18-164.el5, but it has the sendwait > patch I send to dell. Do you use this kernel in the Dom0? Are you using > this kernel with iscsi? > > > >> On Nov 10, 2009, at 12:17 PM, Mike Christie wrote: >> >>> Hoot, Joseph wrote: I've had about 3 threads of dt (kicking off a bit randomly) on (3) separate volumes for over a week and haven't had a single disconnect yet. I am currently using whatever rpm is distributed with Oracle VM v2.2. I know for sure that they have included the 871 base, plus I believe at least a one off patch. I can get more details if you'd like. But so far so good for now >>> I think I have the source they are using. Could you do a uname -r, so I >>> can see what kernel they are using. >>> >> >> === >> Joseph R. Hoot >> Lead System Programmer/Analyst >> (w) 716-878-4832 >> (c) 716-759-HOOT >> joe.h...@itec.suny.edu >> GPG KEY: 7145F633 >> === >> >> >>> > > > > === Joseph R. Hoot Lead System Programmer/Analyst (w) 716-878-4832 (c) 716-759-HOOT joe.h...@itec.suny.edu GPG KEY: 7145F633 === --~--~-~--~~~---~--~~ 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 open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Non-news on HP MPX100
On Thu, Nov 12, 2009 at 09:17:59AM +0100, Ulrich Windl wrote: > > Hi, > > just a short note on the HP MPX100 firmware: Different to the announcement > made > some months ago, the most current firmware for the HP MPX100 (HP EVA iSCSI > connectivity option) included no change regarding Linux and CHAP: The > documenatation still says CHAP ist not supported for Linux. As the product is > actually from Qlogic, I'm not sure who's to blame. > The impression that I get from those software giants is that they completely > unable to react to markets demands. Sorry, but I had to let that off... > And they'll fall on their own trap.. the world is changing :) who needs FC soon.. -- Pasi --~--~-~--~~~---~--~~ 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 open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Help: Driver not found Problem
On 11 Nov, 17:24, Mike Christie wrote: > Could you tell me when you run make install or depmod -a does a file in > /lib/modules/$your_kernel/modules.dep get updated or created? In that > file do you see some info for libiscsi_tcp? When you reboot your system > is the file still there? It works fine after reboot, so any changes the first depmod -a did is still there. And if a now (when its working) run depmod -a again, all the timestamps on the files i the /lib/modules/$your_kernel/ dir is updated, but the filesizes is the same. Output of cat modules.dep | grep -B 2 -A 2 iscsi_tcp : /lib/modules/2.6.26-2-openvz-amd64/kernel/drivers/scsi/qla1280.ko: / lib/modules/2.6.26-2-openvz-amd64/kernel/drivers/scsi/scsi_mod.ko /lib/modules/2.6.26-2-openvz-amd64/kernel/drivers/scsi/ips.ko: /lib/ modules/2.6.26-2-openvz-amd64/kernel/drivers/scsi/scsi_mod.ko /lib/modules/2.6.26-2-openvz-amd64/kernel/drivers/scsi/iscsi_tcp.ko: / lib/modules/2.6.26-2-openvz-amd64/kernel/drivers/scsi/libiscsi.ko /lib/ modules/2.6.26-2-openvz-amd64/kernel/drivers/scsi/ scsi_transport_iscsi.ko /lib/modules/2.6.26-2-openvz-amd64/kernel/ drivers/scsi/scsi_mod.ko /lib/modules/2.6.26-2-openvz-amd64/kernel/drivers/scsi/mvsas.ko: /lib/ modules/2.6.26-2-openvz-amd64/kernel/drivers/scsi/libsas/libsas.ko / lib/modules/2.6.26-2-openvz-amd64/kernel/drivers/ata/libata.ko /lib/ modules/2.6.26-2-openvz-amd64/kernel/drivers/acpi/dock.ko /lib/modules/ 2.6.26-2-openvz-amd64/kernel/drivers/base/firmware_class.ko /lib/ modules/2.6.26-2-openvz-amd64/kernel/drivers/scsi/ scsi_transport_sas.ko /lib/modules/2.6.26-2-openvz-amd64/kernel/ drivers/scsi/scsi_mod.ko /lib/modules/2.6.26-2-openvz-amd64/kernel/drivers/scsi/BusLogic.ko: / lib/modules/2.6.26-2-openvz-amd64/kernel/drivers/scsi/scsi_mod.ko does this help? --~--~-~--~~~---~--~~ 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 open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Non-news on HP MPX100
Hi, just a short note on the HP MPX100 firmware: Different to the announcement made some months ago, the most current firmware for the HP MPX100 (HP EVA iSCSI connectivity option) included no change regarding Linux and CHAP: The documenatation still says CHAP ist not supported for Linux. As the product is actually from Qlogic, I'm not sure who's to blame. The impression that I get from those software giants is that they completely unable to react to markets demands. Sorry, but I had to let that off... 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-iscsi@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 -~--~~~~--~~--~--~---
