sexy actress nude video here
sexy actress nude video here sexy actress nude video here http://makemoney2onlines.blogspot.com http://makemoney2onlines.blogspot.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-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 -~--~~~~--~~--~--~---
vvvvHot and sexy actress nude photos and videos here
Hot and sexy actress nude photos and videos here Hot and sexy actress nude photos and videos here http://prabhuearnings.blogspot.com http://prabhuearnings.blogspot.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-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: iscsid crashes while login/logout
Hi Mike I have just tested your patch. Unfortunately, it does not help. It still crashes on login or logouts. For you information, I have uploaded two files with testresult data: 1. iscsid-patchtest.log - contains the debug-output from iscsid (-d 8), up to the point, where it crashes 2. iscsid-glibc-crashmessages.log - contains the stuff written to the parent shell, when iscsid crashes. Note, that the glic-output has grown to well over 1800 lines. Feel free to request further tests and/or information. Thanks so far Regards Thomas --~--~-~--~~~---~--~~ 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: RFC: do we need a new list for kernel patches
I agree that having just one mailing list is the most convenient for kernel developers. But not everyone who is subscribed to open-iscsi is a kernel developer. Wouldn't it be more convenient for iSCSI users to have two lists -- one intended for iSCSI users, and one for iSCSI developers, such that the users can subscribe to the former only ? Just my two cents. Bart. From my experience this makes users loos on the Kernel guys. Kernel guys are busy, and mind their own business, but if a question comes up, which they know the answer they would occasionally participate. Splitting will loos that. I think Bart is talking about two camps of users: developers (both kernel and user-land), and those seeking help. I think iscsi mailing-list is not that big and still easy to monitor. Just set your mailer to view by thread, and it's easy to jump over threads that are not interesting. I have to agree, Ctrl-D in mutt is wonderfull thing. My $0.017 Boaz --~--~-~--~~~---~--~~ 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: open-iscsi and discover newly created LUN
what are the steps for installing ISCSI on Ubuntu 9.4? I am having a horrible time doin just that I would love to recover or even see the luns I have provisioned Paul Cooper Konrad Rzeszutek wrote: On RHEL 5.3 and newer, upstream and probably ubuntu (not sure what version is in there), you can do iscsiadm -m session -r $SID --rescan Mike - The target can initiates a UNIT ATTENTION with additional sense as Report LUN data changed, I don't see that currently being handled by the SCSI-ML. You get that in dmesg? Or is that something the aray can do, but you have to configure it? A rescan may not be necessary if this information is received by the open-iscsi. Huh? Why not? I mean if the LUN changed (it changed size for example), don't you want to rescan the LUN to pick up the changes? Thought where this is handled is bit complex. You can either handle it in the kernel (and have to deal with re-syncing all of the structures related to the block disk), or run a user-land program that deletes the old block disks and re-creates it (by kicking of a REPORT_LUN scan). --~--~-~--~~~---~--~~ 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: open-iscsi and discover newly created LUN
On 06/15/2009 12:41 AM, shyam_i...@dell.com wrote: -Original Message- From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] On Behalf Of Mike Christie Sent: Saturday, June 13, 2009 8:30 AM To: open-iscsi@googlegroups.com Subject: Re: open-iscsi and discover newly created LUN On 06/12/2009 01:16 AM, TheR wrote: Using open-iscsi as initiator on ubuntu 9.04. I want to set up virtual environment with iscsi target server which is ubuntu based. On target decided to use single tid under which I create multple LUN-s, which represent disks used by initiator which is KVM server. One LUN becomes a disk used by one virtual machine on KVM server. My problem is when I create new LUN on target (under same tid), this LUN doesn't get recognized by initiator without restarting initiator iscsi service. Which in return breaks all curently running machines on KVM server. I have seen same behaviour on Red Hat 5.1. On RHEL 5.3 and newer, upstream and probably ubuntu (not sure what version is in there), you can do iscsiadm -m session -r $SID --rescan Mike - The target can initiates a UNIT ATTENTION with additional sense as Report LUN data changed, I don't see that currently being handled by the SCSI-ML. A rescan may not be necessary if this information is received by the open-iscsi. Do you have a background on the SCSI-ML part ? If the unit attention comes in a iscsi async pdu, then we handle it today in iscsid by kicking off a rescan which adds new devices. It does not delete stale ones, because the scsi-ml sysfs scan interface does not do this. If the unit attention comes with scsi command sense like normal, people have been working on it like here: http://marc.info/?l=linux-scsim=123852561314129w=2 --~--~-~--~~~---~--~~ 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: Iscsid crash at first login targets
On 06/15/2009 03:50 AM, Philippe wrote: Hi, Sorry I put I faulty message as comment of the previous one ... that I have supress (not true to bad work) So, I have tested with an external targets (not loopback) to confirm the fault ... so iscsid crash with a segmentation fault at iscsiadl login request. here after the iscsid debug (-d 8) output : *** iscsid: poll result 1 iscsid: in read_transports iscsid: Adding new transport tcp iscsid: sysfs_attr_get_value: open '/class/iscsi_transport/ tcp'/'handle' iscsid: sysfs_attr_get_value: new uncached attribute '/sys/class/ iscsi_transport/tcp/handle' iscsid: sysfs_attr_get_value: add to cache '/sys/class/iscsi_transport/ tcp/handle' iscsid: sysfs_attr_get_value: cache '/sys/class/iscsi_transport/tcp/ handle' with attribute value '3205103464' iscsid: sysfs_attr_get_value: open '/class/iscsi_transport/tcp'/'caps' iscsid: sysfs_attr_get_value: new uncached attribute '/sys/class/ iscsi_transport/tcp/caps' iscsid: sysfs_attr_get_value: add to cache '/sys/class/iscsi_transport/ tcp/caps' iscsid: sysfs_attr_get_value: cache '/sys/class/iscsi_transport/tcp/ caps' with attribute value '0x39' iscsid: Matched transport tcp iscsid: Allocted session 0x413f0 iscsid: no authentication configured... iscsid: resolved 192.168.1.108 to 192.168.1.108 iscsid: get conn context 0x48838 iscsid: set TCP recv window size to 524288, actually got 262142 iscsid: set TCP send window size to 524288, actually got 262142 iscsid: connecting to 192.168.1.108:3260 iscsid: sched conn context 0x48838 event 2, tmo 0 iscsid: thread 0x48838 schedule: delay 0 state 3 iscsid: Setting login timer 0x467a8 timeout 15 iscsid: thread 0x467a8 schedule: delay 60 state 3 iscsid: exec thread 00048838 callback iscsid: put conn context 0x48838 iscsid: connected local port 42613 to 192.168.1.108:3260 iscsid: in kcreate_session iscsid: in __kipc_call iscsid: in kwritev Segmentation fault hereafter the iscsiadm request (after a good discovery) [~] # iscsiadm -m node 192.168.1.108:3260,1 iqn.2009-03..site:32a27b02-01b1-4fa1- ab5d-8585d7a53c95 [~] # iscsiadm -m node -T iqn.2009-03..site:32a27b02-01b1-4fa1- ab5d-8585d7a53c95 -p 192.168.1.108 -l Logging in to [iface: default, target: iqn.2009-03..site: 32a27b02-01b1-4fa1-ab5d-8585d7a53c95, portal: 192.168.1.108,3260] iscsiadm: got read error (0/0), daemon died? iscsiadm: Could not login to [iface: default, target: iqn. 2009-03..site:32a27b02-01b1-4fa1-ab5d-8585d7a53c95, portal: 192.168.1.108,3260]: iscsiadm: initiator reported error (18 - could not communicate to iscsid) This failed, because iscsid crashed. iscsid crashed because the kernel oops. When you used the loopback maybe we did not connect and so we never even got this far. Above using a real target we at least made the tcp/ip connection. We oopsd just trying to talk to the kernel when we wanted to tell it to create some structs. Are you using gcc? Was there some bug in the network code on arm? --~--~-~--~~~---~--~~ 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: open-iscsi and discover newly created LUN
-Original Message- From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] On Behalf Of Konrad Rzeszutek Sent: Monday, June 15, 2009 8:39 PM To: open-iscsi@googlegroups.com Subject: Re: open-iscsi and discover newly created LUN On RHEL 5.3 and newer, upstream and probably ubuntu (not sure what version is in there), you can do iscsiadm -m session -r $SID --rescan Mike - The target can initiates a UNIT ATTENTION with additional sense as Report LUN data changed, I don't see that currently being handled by the SCSI-ML. You get that in dmesg? Or is that something the aray can do, but you have to configure it? It is usually programmed into the array firmware. A rescan may not be necessary if this information is received by the open-iscsi. Huh? Why not? I mean if the LUN changed (it changed size for example), don't you want to rescan the LUN to pick up the changes? Not anymore.. Rescanning is a parallel scsi thingie ..see http://www.t10.org/ftp/t10/document.06/06-411r0.pdf --~--~-~--~~~---~--~~ 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: open-iscsi and discover newly created LUN
-Original Message- From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] On Behalf Of Mike Christie Sent: Monday, June 15, 2009 9:15 PM To: open-iscsi@googlegroups.com Subject: Re: open-iscsi and discover newly created LUN On 06/15/2009 12:41 AM, shyam_i...@dell.com wrote: -Original Message- From: open-iscsi@googlegroups.com [mailto:open- is...@googlegroups.com] On Behalf Of Mike Christie Sent: Saturday, June 13, 2009 8:30 AM To: open-iscsi@googlegroups.com Subject: Re: open-iscsi and discover newly created LUN On 06/12/2009 01:16 AM, TheR wrote: Using open-iscsi as initiator on ubuntu 9.04. I want to set up virtual environment with iscsi target server which is ubuntu based. On target decided to use single tid under which I create multple LUN-s, which represent disks used by initiator which is KVM server. One LUN becomes a disk used by one virtual machine on KVM server. My problem is when I create new LUN on target (under same tid), this LUN doesn't get recognized by initiator without restarting initiator iscsi service. Which in return breaks all curently running machines on KVM server. I have seen same behaviour on Red Hat 5.1. On RHEL 5.3 and newer, upstream and probably ubuntu (not sure what version is in there), you can do iscsiadm -m session -r $SID --rescan Mike - The target can initiates a UNIT ATTENTION with additional sense as Report LUN data changed, I don't see that currently being handled by the SCSI-ML. A rescan may not be necessary if this information is received by the open-iscsi. Do you have a background on the SCSI-ML part ? If the unit attention comes in a iscsi async pdu, then we handle it today in iscsid by kicking off a rescan which adds new devices. It does not delete stale ones, because the scsi-ml sysfs scan interface does not do this. If the unit attention comes with scsi command sense like normal, people have been working on it like here: http://marc.info/?l=linux-scsim=123852561314129w=2 Ah Ok. Thanks for the link. I guess this is still WIP. --~--~-~--~~~---~--~~ 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: open-iscsi and discover newly created LUN
On Mon, Jun 15, 2009 at 10:48:49PM +0530, shyam_i...@dell.com wrote: -Original Message- From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] On Behalf Of Konrad Rzeszutek Sent: Monday, June 15, 2009 8:39 PM To: open-iscsi@googlegroups.com Subject: Re: open-iscsi and discover newly created LUN On RHEL 5.3 and newer, upstream and probably ubuntu (not sure what version is in there), you can do iscsiadm -m session -r $SID --rescan Mike - The target can initiates a UNIT ATTENTION with additional sense as Report LUN data changed, I don't see that currently being handled by the SCSI-ML. You get that in dmesg? Or is that something the aray can do, but you have to configure it? It is usually programmed into the array firmware. A rescan may not be necessary if this information is received by the open-iscsi. Huh? Why not? I mean if the LUN changed (it changed size for example), don't you want to rescan the LUN to pick up the changes? Not anymore.. Rescanning is a parallel scsi thingie ..see http://www.t10.org/ftp/t10/document.06/06-411r0.pdf I think the majority of storages that are in usage right now (at least for the SMB market) don't employ this standard. Hence to support those storage, you would still need to do the old way (ie, find out what changed, do an SCSI INQ see if the Peripheral Qualifier changed, or if device type has changed from 1fh to 00h, etc). --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[PATCH 2/2 2.6.30-rc v2] cxgb3i -- suppot of different kernel page sizes
[PATCH 2/2 2.6.30-rc v2] cxgb3i -- suppot of different kernel page sizes
From: Karen Xie k...@chelsio.com
The default kernel pages supported are 4K, 8K, 16K, and 64K. Re-calculate
entries if PAGE_SIZE is not one of the defaults.
Signed-off-by: Karen Xie k...@chelsio.com
---
drivers/scsi/cxgb3i/cxgb3i_ddp.c | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/cxgb3i/cxgb3i_ddp.c b/drivers/scsi/cxgb3i/cxgb3i_ddp.c
index 8eb2848..344fd53 100644
--- a/drivers/scsi/cxgb3i/cxgb3i_ddp.c
+++ b/drivers/scsi/cxgb3i/cxgb3i_ddp.c
@@ -206,6 +206,31 @@ int cxgb3i_ddp_find_page_index(unsigned long pgsz)
return DDP_PGIDX_MAX;
}
+/**
+ * cxgb3i_ddp_adjust_page_table - adjust page table with PAGE_SIZE
+ * return the ddp page index, if no match is found return DDP_PGIDX_MAX.
+ */
+int cxgb3i_ddp_adjust_page_table(void)
+{
+ int i;
+ unsigned int base_order, order;
+
+ if (PAGE_SIZE (1UL ddp_page_shift[0])) {
+ ddp_log_info(PAGE_SIZE 0x%lx too small, min. 0x%lx.\n,
+ PAGE_SIZE, 1UL ddp_page_shift[0]);
+ return -EINVAL;
+ }
+
+ base_order = get_order(1UL ddp_page_shift[0]);
+ order = get_order(1 PAGE_SHIFT);
+ for (i = 0; i DDP_PGIDX_MAX; i++) {
+ /* first is the kernel page size, then just doubling the size */
+ ddp_page_order[i] = order - base_order + i;
+ ddp_page_shift[i] = PAGE_SHIFT + i;
+ }
+ return 0;
+}
+
static inline void ddp_gl_unmap(struct pci_dev *pdev,
struct cxgb3i_gather_list *gl)
{
@@ -727,6 +752,17 @@ void cxgb3i_ddp_init(struct t3cdev *tdev)
{
if (page_idx == DDP_PGIDX_MAX) {
page_idx = cxgb3i_ddp_find_page_index(PAGE_SIZE);
+
+ if (page_idx == DDP_PGIDX_MAX) {
+ ddp_log_info(system PAGE_SIZE %lu, update hw.\n,
+ PAGE_SIZE);
+ if (cxgb3i_ddp_adjust_page_table() 0) {
+ ddp_log_info(PAGE_SIZE %lu, ddp disabled.\n,
+ PAGE_SIZE);
+ return;
+ }
+ page_idx = cxgb3i_ddp_find_page_index(PAGE_SIZE);
+ }
ddp_log_info(system PAGE_SIZE %lu, ddp idx %u.\n,
PAGE_SIZE, page_idx);
}
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[PATCH 1/2 2.6.30-rc v2] cxgb3i -- use kref to track ddp usage
[PATCH 1/2 2.6.30-rc v2] cxgb3i -- use kref to track ddp usage
From: Karen Xie k...@chelsio.com
The iscsi ddp functionality could be used by multiple iscsi entities,
add a refcnt to keep track of it, so we would not release it pre-maturely.
Signed-off-by: Karen Xie k...@chelsio.com
---
drivers/scsi/cxgb3i/cxgb3i_ddp.c | 54 +++---
drivers/scsi/cxgb3i/cxgb3i_ddp.h |2 +
2 files changed, 35 insertions(+), 21 deletions(-)
diff --git a/drivers/scsi/cxgb3i/cxgb3i_ddp.c b/drivers/scsi/cxgb3i/cxgb3i_ddp.c
index 99c9125..8eb2848 100644
--- a/drivers/scsi/cxgb3i/cxgb3i_ddp.c
+++ b/drivers/scsi/cxgb3i/cxgb3i_ddp.c
@@ -598,30 +598,40 @@ int cxgb3i_adapter_ddp_info(struct t3cdev *tdev,
* release all the resource held by the ddp pagepod manager for a given
* adapter if needed
*/
-void cxgb3i_ddp_cleanup(struct t3cdev *tdev)
+
+static void ddp_cleanup(struct kref *kref)
{
+ struct cxgb3i_ddp_info *ddp = container_of(kref,
+ struct cxgb3i_ddp_info,
+ refcnt);
int i = 0;
+
+ ddp_log_info(kref release ddp 0x%p, t3dev 0x%p.\n, ddp, ddp-tdev);
+
+ ddp-tdev-ulp_iscsi = NULL;
+ while (i ddp-nppods) {
+ struct cxgb3i_gather_list *gl = ddp-gl_map[i];
+ if (gl) {
+ int npods = (gl-nelem + PPOD_PAGES_MAX - 1)
+PPOD_PAGES_SHIFT;
+ ddp_log_info(t3dev 0x%p, ddp %d + %d.\n,
+ ddp-tdev, i, npods);
+ kfree(gl);
+ ddp_free_gl_skb(ddp, i, npods);
+ i += npods;
+ } else
+ i++;
+ }
+ cxgb3i_free_big_mem(ddp);
+}
+
+void cxgb3i_ddp_cleanup(struct t3cdev *tdev)
+{
struct cxgb3i_ddp_info *ddp = (struct cxgb3i_ddp_info *)tdev-ulp_iscsi;
ddp_log_info(t3dev 0x%p, release ddp 0x%p.\n, tdev, ddp);
-
- if (ddp) {
- tdev-ulp_iscsi = NULL;
- while (i ddp-nppods) {
- struct cxgb3i_gather_list *gl = ddp-gl_map[i];
- if (gl) {
- int npods = (gl-nelem + PPOD_PAGES_MAX - 1)
-PPOD_PAGES_SHIFT;
- ddp_log_info(t3dev 0x%p, ddp %d + %d.\n,
- tdev, i, npods);
- kfree(gl);
- ddp_free_gl_skb(ddp, i, npods);
- i += npods;
- } else
- i++;
- }
- cxgb3i_free_big_mem(ddp);
- }
+ if (ddp)
+ kref_put(ddp-refcnt, ddp_cleanup);
}
/**
@@ -631,12 +641,13 @@ void cxgb3i_ddp_cleanup(struct t3cdev *tdev)
*/
static void ddp_init(struct t3cdev *tdev)
{
- struct cxgb3i_ddp_info *ddp;
+ struct cxgb3i_ddp_info *ddp = tdev-ulp_iscsi;
struct ulp_iscsi_info uinfo;
unsigned int ppmax, bits;
int i, err;
- if (tdev-ulp_iscsi) {
+ if (ddp) {
+ kref_get(ddp-refcnt);
ddp_log_warn(t3dev 0x%p, ddp 0x%p already set up.\n,
tdev, tdev-ulp_iscsi);
return;
@@ -670,6 +681,7 @@ static void ddp_init(struct t3cdev *tdev)
ppmax *
sizeof(struct cxgb3i_gather_list *));
spin_lock_init(ddp-map_lock);
+ kref_init(ddp-refcnt);
ddp-tdev = tdev;
ddp-pdev = uinfo.pdev;
diff --git a/drivers/scsi/cxgb3i/cxgb3i_ddp.h b/drivers/scsi/cxgb3i/cxgb3i_ddp.h
index 0d296de..87dd56b 100644
--- a/drivers/scsi/cxgb3i/cxgb3i_ddp.h
+++ b/drivers/scsi/cxgb3i/cxgb3i_ddp.h
@@ -54,6 +54,7 @@ struct cxgb3i_gather_list {
* struct cxgb3i_ddp_info - cxgb3i direct data placement for pdu payload
*
* @list: list head to link elements
+ * @refcnt:ref. count
* @tdev: pointer to t3cdev used by cxgb3 driver
* @max_txsz: max tx packet size for ddp
* @max_rxsz: max rx packet size for ddp
@@ -70,6 +71,7 @@ struct cxgb3i_gather_list {
*/
struct cxgb3i_ddp_info {
struct list_head list;
+ struct kref refcnt;
struct t3cdev *tdev;
struct pci_dev *pdev;
unsigned int max_txsz;
--~--~-~--~~~---~--~~
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 2.6.30-rc] cxgb3i -- add a refcnt to track ddp usage
Hi, James, Thanks, I've re-submitted the patches to use kref instead. Best regards, Karen -Original Message- From: James Bottomley [mailto:james.bottom...@hansenpartnership.com] Sent: Saturday, June 13, 2009 4:53 PM To: Karen Xie Cc: linux-s...@vger.kernel.org; open-iscsi@googlegroups.com; micha...@cs.wisc.edu Subject: Re: [PATCH 1/2 2.6.30-rc] cxgb3i -- add a refcnt to track ddp usage On Sat, 2009-06-13 at 14:29 -0700, k...@chelsio.com wrote: [PATCH 1/2 2.6.30-rc] cxgb3i -- add a refcnt to track ddp usage From: Karen Xie k...@chelsio.com The iscsi ddp functionality could be used by multiple iscsi entities, add a refcnt to keep track of it, so we would not release it pre-maturely. The code is fine as it stands but, I wonder, would you consider using a kref for this? The reasons are twofold: 1. It's a well understood kernel paradigm that works ... this would be helpful for the far distant time when chelsio no longer wants to maintain this driver. 2. It includes useful and appropriate warnings for common bugs in refcounted code, such as use of a freed reference. James --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
SLES11 install on multipath iSCSI
Hi All, I installed SLES11 on a single path to a dual path iSCSI disk. Then I modified node.startup to automatic in the /etc/iscsi/iscsd.conf file and ran 'iscsiadm -m discovery ...' followed by 'chkconfig boot.open-iscsi on chkconfig open-iscsi on' and then ran 'mkinitrd' to create a new initrd with multipath support at this point. Is this a recommended procedure? With that, the system boots fine but the shutdown/reboot hangs. Upon closer inspection, I found that /etc/init.d/boot.open-iscsi sets node.conn[0].startup to onboot but leaves node.startup to automatic in my case. This causes the /etc/init.d/open-iscsi script logout from the root disk on reboot causing the hang! Fixing the boot.open-iscsi fixed the problem. Is this a good solution? Thanks, Malahal. --~--~-~--~~~---~--~~ 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: iscsi connection error
Hi Mike, First my apologies for a late reply. I have resolved this issue. I changed the install locations and it worked. Earlier i tried shared home install. Basically, i had a shared oracle home and tried to install the oracle software (binaries) to be shared by both nodes. But later i installed the oracle softwares separate on both the nodes and they worked fine. Appreciate your sincere efforts to help noobs like me. On Thu, Jun 11, 2009 at 1:02 PM, Mike Christiemicha...@cs.wisc.edu wrote: On 06/10/2009 10:49 AM, sundar mahadevan wrote: Hi Members, First of all, I'm not too sure if this question is supposed to raise here. Sorry if this is not the right place. Appreciate if you could direct me to the right place. Thanks. OS: Oracle enterprise linux rpm -qa | grep -i scsi scsi-target-utils-0.0-5.20080917snap.el5 iscsi-initiator-utils-6.2.0.868-0.18.el5 what kernel are you using (do uname -a)? I'm trying to install oracle 9i rac. During instllation half way through, i receive the following error messages. I encountered this problem twice. In fact on the second attempt, the connection got dropped at 10:54 and then somehow reconnected itself in a few seconds. But later the connection dropped and did not comeback again. Please help. Noob. Thanks in advance. Jun 10 10:54:37 sunny1pub kernel: connection1:0: iscsi: detected conn error (1011) . . . Jun 10 10:54:40 sunny1pub iscsid: connection1:0 is operational after recovery (1 attempts) Jun 10 10:27:14 sunny1pub kernel: o2net: accepted connection from node sunny2pub.ezhome.com (num 1) at 10.1.1.2: Jun 10 10:27:18 sunny1pub kernel: ocfs2_dlm: Node 1 joins domain 1B9768E4C4FC4165A22E5E95E6A93F80 Jun 10 10:27:18 sunny1pub kernel: ocfs2_dlm: Nodes in domain (1B9768E4C4FC4165A22E5E95E6A93F80): 0 1 Jun 10 10:54:37 sunny1pub kernel: connection1:0: iscsi: detected conn error (1011) Jun 10 10:54:37 sunny1pub iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3) Jun 10 10:54:37 sunny1pub tgtd: abort_task_set(979) found a01 0 Jun 10 10:54:37 sunny1pub tgtd: conn_close(88) connection closed 0x9e370c4 2 Jun 10 10:54:39 sunny1pub kernel: iscsi: host reset succeeded Is the initiator connected to the target running on the same box? It looks like a command took too long. If a command takes longer than the scsi command timeout (/sys/block/sdX/device/timeout) then the scsi layer will try to abort it (if that fails reset the lun and if that fails reset the host). Jun 10 10:54:40 sunny1pub iscsid: received iferror -38 Jun 10 10:54:40 sunny1pub last message repeated 2 times Jun 10 10:54:40 sunny1pub iscsid: connection1:0 is operational after recovery (1 attempts) Jun 10 10:57:57 sunny1pub kernel: ping timeout of 5 secs expired, last rx 1740985, last ping 1745985, now 1750985 The initiator sends a iscsi nop as a ping every x seconds. If we do not get a response we drop the sesison, try to relogin and retry the IO. Jun 10 10:57:57 sunny1pub kernel: connection1:0: iscsi: detected conn error (1011) Jun 10 10:57:59 sunny1pub iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3) Jun 10 10:59:58 sunny1pub kernel: session1: iscsi: session recovery timed out after 120 secs it looks like something happened to the target or connection. We were not able to log back in after trying for 2 minutes (node.session.replacement_timeout). Jun 10 10:59:58 sunny1pub kernel: iscsi: cmd 0x2a is not queued (8) Jun 10 11:06:10 sunny1pub syslogd 1.4.1: restart. --~--~-~--~~~---~--~~ 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: iscsid crashes while login/logout
tweyergraf wrote: Hi Mike I have just tested your patch. Unfortunately, it does not help. It still crashes on login or logouts. For you information, I have uploaded two files with testresult data: 1. iscsid-patchtest.log - contains the debug-output from iscsid (-d 8), up to the point, where it crashes 2. iscsid-glibc-crashmessages.log - contains the stuff written to the parent shell, when iscsid crashes. Note, that the glic-output has grown to well over 1800 lines. My patch had a bug. Feel free to request further tests and/or information. Could you retry your test without the patch. Before you run your test do # ls /sys/class/iscsi_session If there are session dirs in there, then check if iscsid is running # ps -u root | grep iscsid if iscsid is running then logout # iscsiadm -m node -u Then kill iscsid (either just do killall iscisd or service iscsi stop), then restart it (run iscsid or run service iscsi start), then restart your login and logout tests. Also could you let me know if the 'ls' showed any running sessions. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
