Re: lio-target crashes when windows initiator logs in
On Tue, Dec 08, 2009 at 10:13:16AM -0800, ablock wrote: > > Hi, > I have problems with the lio-target software. I tried lio-core-2.6.31 > and lio-core-2.6. > I compiled it together with lio-utils under ubuntu 9.10 and debian > 5.0. > Ubuntu and debian was installed in a virtual machine. I used virtual > box 3.0.12. > I tried it also on bare metal with the same problems. > Hello, You're posting to a wrong mailinglist.. This list is about the open-iscsi linux iscsi initiator, not lio target. I don't know how many people here can help you with the lio target.. -- Pasi > > I can get it working when i use a block device like /dev/sdb. > It crashes completely when i use a block device like /dev/sdb1 (The > Partition exists!!!) > It also crashes completely when i use a logical volume or a md-device. > > The crash happens whenever a Windows Initiator logs in. I tried > Windows Vista and Windows Server 2008. > > When I start the target module I get the following output: > > Loading target_core_mod/ConfigFS core: [OK] > Calling ConfigFS script /etc/target/tcm_start.sh for > target_core_mod: [OK] > Calling ConfigFS script /etc/target/lio_start.sh for > iscsi_target_mod: [OK] > > > In /var/log/messages I get: > > Dec 8 18:50:51 debian kernel: [ 106.480865] TARGET_CORE[0]: Loading > Generic Kernel Storage Engine: v3.1.0 on Linux/x86_64 on 2.6.31.4v3.1 > Dec 8 18:50:51 debian kernel: [ 106.481007] TARGET_CORE[0]: > Initialized ConfigFS Fabric Infrastructure: v2.0.0 on Linux/x86_64 on > 2.6.31.4v3.1 > Dec 8 18:50:51 debian kernel: [ 106.481036] SE_PC[0] - Registered > Plugin Class: TRANSPORT > Dec 8 18:50:51 debian kernel: [ 106.481061] PLUGIN_TRANSPORT[1] - > pscsi registered > Dec 8 18:50:51 debian kernel: [ 106.481084] PLUGIN_TRANSPORT[2] - > stgt registered > Dec 8 18:50:51 debian kernel: [ 106.481212] CORE_STGT[0]: Bus > Initalization complete > Dec 8 18:50:51 debian kernel: [ 106.481232] PLUGIN_TRANSPORT[4] - > iblock registered > Dec 8 18:50:51 debian kernel: [ 106.481250] PLUGIN_TRANSPORT[5] - > rd_dr registered > Dec 8 18:50:51 debian kernel: [ 106.481268] PLUGIN_TRANSPORT[6] - > rd_mcp registered > Dec 8 18:50:51 debian kernel: [ 106.481285] PLUGIN_TRANSPORT[7] - > fileio registered > Dec 8 18:50:51 debian kernel: [ 106.481307] SE_PC[1] - Registered > Plugin Class: OBJ > Dec 8 18:50:51 debian kernel: [ 106.481326] PLUGIN_OBJ[1] - dev > registered > > > I then initialize the iscsi target with the following commands > > tcm_node --block iblock_0/my_dev2 /dev/vg1/lv1 > lio_node --addlun iqn.2009-11.local.schule.target.i686:sn.123456789 1 > 0 my_dev_port iblock_0/my_dev2 > lio_node --disableauth iqn.2009-11.local.schule.target.i686:sn. > 123456789 1 > lio_node --addnp iqn.2009-11.local.schule.target.i686:sn.123456789 1 > 192.168.56.101:3260 > lio_node --addlunacl iqn.2009-11.local.schule.target.i686:sn.123456789 > 1 iqn.1991-05.com.microsoft:andreas-pc 0 0 > lio_node --enabletpg iqn.2009-11.local.schule.target.i686:sn.123456789 > 1 > > They produce the following output: > Output tcm_node: > > Status: DEACTIVATED Execute/Left/Max Queue Depth: 0/32/32 > SectorSize: 512 MaxSectors: 255 > iBlock device: dm-0 > Major: 253 Minor: 0 CLAIMED: IBLOCK > ConfigFS HBA: iblock_0 > Successfully added TCM/ConfigFS HBA: iblock_0 > ConfigFS Device Alias: my_dev2 > Device Params ['/dev/vg1/lv1'] > Set T10 WWN Unit Serial for iblock_0/my_dev2 to: 57f6b040-3159-49df- > a5bd-2acdb948ef6f > Successfully created TCM/ConfigFS storage object: /sys/kernel/config/ > target/core/iblock_0/my_dev2 > > Output lio_node --addlun: > Successfully created iSCSI Target Logical Unit > > Output lio_node --disableauth: > Successfully disabled iSCSI Authentication on iSCSI Target Portal > Group: iqn.2009-11.local.schule.target.i686:sn.123456789 1 > > Output lio_node --addnp: > Successfully created network portal: 192.168.56.101:3260 created iqn. > 2009-11.local.schule.target.i686:sn.123456789 TPGT: 1 > > Output von lio_node --addlunacl: > Successfully added iSCSI Initiator Mapped LUN: 0 ACL iqn. > 1991-05.com.microsoft:andreas-pc for iSCSI Target Portal Group: iqn. > 2009-11.local.schule.target.i686:sn.123456789 1 > > Output von lio_node --enabletpg: > Successfully enabled iSCSI Target Portal Group: iqn. > 2009-11.local.schule.target.i686:sn.123456789 1 > > > In /var/log/messages the initialization leads to the following: > > Dec 8 18:53:11 debian kernel: [ 246.679996] Target_Core_ConfigFS: > Located se_plugin: 88000dd630e0 plugin_name: iblock hba_type: 4 > plugin_dep_id: 0 > Dec 8 18:53:11 debian kernel: [ 246.680398] CORE_HBA[0] - Linux- > iSCSI.org iBlock HBA Driver 3.1 on Generic Target Core Stack v3.1.0 > Dec 8 18:53:11 debian kernel: [ 246.680425] CORE_HBA[0] - Attached > iBlock HBA: 0 to Generic Target Core TCQ Depth: 512 > Dec 8 18:53:11 debian kernel: [ 246.680452] CORE_HBA[0] - Attached > HBA to Generic Target Core > Dec 8 18:53:11 debian kernel: [ 246.680
Re: lio-target crashes when windows initiator logs in
Hello, sorry, I realized my mistake when the submit button was pressed. I also posted the Question in the lio-target-group. You can delete the posting in this group or leave it. Maybe somebody can also help me in this group. A. Block On 9 Dez., 11:55, Pasi Kärkkäinen wrote: > On Tue, Dec 08, 2009 at 10:13:16AM -0800, ablock wrote: > > > Hi, > > I have problems with the lio-target software. I tried lio-core-2.6.31 > > and lio-core-2.6. > > I compiled it together with lio-utils under ubuntu 9.10 and debian > > 5.0. > > Ubuntu and debian was installed in a virtual machine. I used virtual > > box 3.0.12. > > I tried it also on bare metal with the same problems. > > Hello, > > You're posting to a wrong mailinglist.. > This list is about the open-iscsi linux iscsi initiator, not lio target. > > I don't know how many people here can help you with the lio target.. > > -- Pasi > > > > > > > I can get it working when i use a block device like /dev/sdb. > > It crashes completely when i use a block device like /dev/sdb1 (The > > Partition exists!!!) > > It also crashes completely when i use a logical volume or a md-device. > > > The crash happens whenever a Windows Initiator logs in. I tried > > Windows Vista and Windows Server 2008. > > > When I start the target module I get the following output: > > > Loading target_core_mod/ConfigFS core: [OK] > > Calling ConfigFS script /etc/target/tcm_start.sh for > > target_core_mod: [OK] > > Calling ConfigFS script /etc/target/lio_start.sh for > > iscsi_target_mod: [OK] > > > In /var/log/messages I get: > > > Dec 8 18:50:51 debian kernel: [ 106.480865] TARGET_CORE[0]: Loading > > Generic Kernel Storage Engine: v3.1.0 on Linux/x86_64 on 2.6.31.4v3.1 > > Dec 8 18:50:51 debian kernel: [ 106.481007] TARGET_CORE[0]: > > Initialized ConfigFS Fabric Infrastructure: v2.0.0 on Linux/x86_64 on > > 2.6.31.4v3.1 > > Dec 8 18:50:51 debian kernel: [ 106.481036] SE_PC[0] - Registered > > Plugin Class: TRANSPORT > > Dec 8 18:50:51 debian kernel: [ 106.481061] PLUGIN_TRANSPORT[1] - > > pscsi registered > > Dec 8 18:50:51 debian kernel: [ 106.481084] PLUGIN_TRANSPORT[2] - > > stgt registered > > Dec 8 18:50:51 debian kernel: [ 106.481212] CORE_STGT[0]: Bus > > Initalization complete > > Dec 8 18:50:51 debian kernel: [ 106.481232] PLUGIN_TRANSPORT[4] - > > iblock registered > > Dec 8 18:50:51 debian kernel: [ 106.481250] PLUGIN_TRANSPORT[5] - > > rd_dr registered > > Dec 8 18:50:51 debian kernel: [ 106.481268] PLUGIN_TRANSPORT[6] - > > rd_mcp registered > > Dec 8 18:50:51 debian kernel: [ 106.481285] PLUGIN_TRANSPORT[7] - > > fileio registered > > Dec 8 18:50:51 debian kernel: [ 106.481307] SE_PC[1] - Registered > > Plugin Class: OBJ > > Dec 8 18:50:51 debian kernel: [ 106.481326] PLUGIN_OBJ[1] - dev > > registered > > > I then initialize the iscsi target with the following commands > > > tcm_node --block iblock_0/my_dev2 /dev/vg1/lv1 > > lio_node --addlun iqn.2009-11.local.schule.target.i686:sn.123456789 1 > > 0 my_dev_port iblock_0/my_dev2 > > lio_node --disableauth iqn.2009-11.local.schule.target.i686:sn. > > 123456789 1 > > lio_node --addnp iqn.2009-11.local.schule.target.i686:sn.123456789 1 > > 192.168.56.101:3260 > > lio_node --addlunacl iqn.2009-11.local.schule.target.i686:sn.123456789 > > 1 iqn.1991-05.com.microsoft:andreas-pc 0 0 > > lio_node --enabletpg iqn.2009-11.local.schule.target.i686:sn.123456789 > > 1 > > > They produce the following output: > > Output tcm_node: > > > Status: DEACTIVATED Execute/Left/Max Queue Depth: 0/32/32 > > SectorSize: 512 MaxSectors: 255 > > iBlock device: dm-0 > > Major: 253 Minor: 0 CLAIMED: IBLOCK > > ConfigFS HBA: iblock_0 > > Successfully added TCM/ConfigFS HBA: iblock_0 > > ConfigFS Device Alias: my_dev2 > > Device Params ['/dev/vg1/lv1'] > > Set T10 WWN Unit Serial for iblock_0/my_dev2 to: 57f6b040-3159-49df- > > a5bd-2acdb948ef6f > > Successfully created TCM/ConfigFS storage object: /sys/kernel/config/ > > target/core/iblock_0/my_dev2 > > > Output lio_node --addlun: > > Successfully created iSCSI Target Logical Unit > > > Output lio_node --disableauth: > > Successfully disabled iSCSI Authentication on iSCSI Target Portal > > Group: iqn.2009-11.local.schule.target.i686:sn.123456789 1 > > > Output lio_node --addnp: > > Successfully created network portal: 192.168.56.101:3260 created iqn. > > 2009-11.local.schule.target.i686:sn.123456789 TPGT: 1 > > > Output von lio_node --addlunacl: > > Successfully added iSCSI Initiator Mapped LUN: 0 ACL iqn. > > 1991-05.com.microsoft:andreas-pc for iSCSI Target Portal Group: iqn. > > 2009-11.local.schule.target.i686:sn.123456789 1 > > > Output von lio_node --enabletpg: > > Successfully enabled iSCSI Target Portal Group: iqn. > > 2009-11.local.schule.target.i686:sn.123456789 1 > > > In /var/log/messages the initialization leads to the following: > > > Dec 8 18:53:11 debian kernel: [ 246.679996] Target_Core_ConfigFS: > > Located se_plugin: 88000dd630e0 plugin
[PATCH RFC] use _bh locking in iscsi_queuecommand
Both the TX (iscsi_queuecommand, iscsi_xmit_task, iscsi_conn_send_pdu)
and the RX (iscsi_complete_pdu and iser/tcp as well) code flows compete
on the session lock. Since the RX flow runs in softirq/bh/tasklet context,
if it cuts the TX flow on the same cpu, a deadlock may happen. To prevent
that, make iscsi_queuecommand use the _bh form of spin lock/unlock in
the same manner done by iscsi_xmit_task and iscsi_conn_send_pdu
Signed-off-by: Or Gerlitz
---
Mike, I am debugging some enhancement to iser and came a cross this.
I really don't see why it haven't hit anyone in the past, any idea?
Index: linux-2.6.32-rc5/drivers/scsi/libiscsi.c
===
--- linux-2.6.32-rc5.orig/drivers/scsi/libiscsi.c
+++ linux-2.6.32-rc5/drivers/scsi/libiscsi.c
@@ -1524,7 +1524,7 @@ int iscsi_queuecommand(struct scsi_cmnd
cls_session = starget_to_session(scsi_target(sc->device));
session = cls_session->dd_data;
- spin_lock(&session->lock);
+ spin_lock_bh(&session->lock);
reason = iscsi_session_chkready(cls_session);
if (reason) {
@@ -1610,7 +1610,7 @@ int iscsi_queuecommand(struct scsi_cmnd
}
session->queued_cmdsn++;
- spin_unlock(&session->lock);
+ spin_unlock_bh(&session->lock);
spin_lock(host->host_lock);
return 0;
@@ -1618,7 +1618,7 @@ prepd_reject:
sc->scsi_done = NULL;
iscsi_complete_task(task, ISCSI_TASK_COMPLETED);
reject:
- spin_unlock(&session->lock);
+ spin_unlock_bh(&session->lock);
ISCSI_DBG_SESSION(session, "cmd 0x%x rejected (%d)\n",
sc->cmnd[0], reason);
spin_lock(host->host_lock);
@@ -1628,7 +1628,7 @@ prepd_fault:
sc->scsi_done = NULL;
iscsi_complete_task(task, ISCSI_TASK_COMPLETED);
fault:
- spin_unlock(&session->lock);
+ spin_unlock_bh(&session->lock);
ISCSI_DBG_SESSION(session, "iscsi: cmd 0x%x is not queued (%d)\n",
sc->cmnd[0], reason);
if (!scsi_bidi_cmnd(sc))
@@ -1638,7 +1638,7 @@ fault:
scsi_in(sc)->resid = scsi_in(sc)->length;
}
done(sc);
- spin_lock(host->host_lock);
+ spin_lock_bh(host->host_lock);
return 0;
}
EXPORT_SYMBOL_GPL(iscsi_queuecommand);
--
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 RFC] use _bh locking in iscsi_queuecommand
> Mike, I am debugging some enhancement to iser and came a cross this. > I really don't see why it haven't hit anyone in the past, any idea? One more thing which I'd be happy to understand are what the rational behind the spin_unlock(host->host_lock) call in iscsi_queuecommand beginning and spin_lock(host->host_lock) in the its end, thanks Or. -- 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: Unable to apply kernel/2.6.26_compat.patch from git master branch
On 12/08/2009 09:15 PM, Yangkook Kim wrote: > Hi, you are back. > >> I think for your patch, you want to include open_iscsi_compat.h in it. > > I included open_iscsi_compat.h and created a patch. Please check it. > > I have a quetion about creating a patch agaist files in sub-directory. > I used "git diff" to output the patch, but each hunk of outputted > patch includes "kernel/" sub-directory. > > e.g > diff --git a/kernel/libiscsi.c b/kernel/libiscsi.c > index 0b810b6..6ffb49c 100644 > --- a/kernel/libiscsi.c > +++ b/kernel/libiscsi.c > > However, "kernel/" sub-directory in the compat patch will prevent you > from making and your current compat patch is actually > does't have "kernel/" sub-directory. > > e.g > diff --git a/libiscsi.c b/libiscsi.c > index 149d5eb..467abbf 100644 > --- a/libiscsi.c > +++ b/libiscsi.c > > How do I make a patch without the sub-directory? > Since I didn't know how to do it, I simply remove the sub-directory by,,, > > sed -i 's%a\/kernel%a%g' update_2.6.26_compat.patch2 > sed -i 's%b\/kernel%b%g' update_2.6.26_compat.patch2 > > But, this obviously isn't the way to do it...It will be very appriciated > if you tell me the right way to do it. > > Thanks. > At the time I wrote the "patching" in Makefile we were using svn. I even included instructions on how to generate the patch file for submission. Now when we are using git, the procedure should be fixed. I think all you have to do is put a -p0 on the "patch" command line (In Makefile). Please experiment with it and send a patch to fix the Makefile. (Do you need that I do it? Just that I haven't checked out a tree for a year) 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-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 RFC] use _bh locking in iscsi_queuecommand
Or Gerlitz wrote:
> Both the TX (iscsi_queuecommand, iscsi_xmit_task, iscsi_conn_send_pdu)
> and the RX (iscsi_complete_pdu and iser/tcp as well) code flows compete
> on the session lock. Since the RX flow runs in softirq/bh/tasklet context,
> if it cuts the TX flow on the same cpu, a deadlock may happen. To prevent
> that, make iscsi_queuecommand use the _bh form of spin lock/unlock in
> the same manner done by iscsi_xmit_task and iscsi_conn_send_pdu
The scsi_host_template->queuecommand function is called by scsi-ml with
irqs disabled spin_lock_irqsave(host->host_lock, flags). I thought bhs
are run from interrupt context, so scsi-mls disabling irqs did what we
needed (see the bottom of Rusty Russells locking guide
http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/c188.html#HARDIRQ-SOFTIRQ
or I think there is more detail in the Linux Device Driver book).
As for optimizations, disabling irqs for libiscsi's case is overkill
since all drivers using iscsi_queuecommand/iscsi_complete_pdu use bhs
for the iscsi processing. You could do something like
iscsi_queuecommand
{
spin_unlock_irq(host lock)
spin_lock_bh(session lock)
.
spin_unlock_bh(session lock)
spin_lock_irq(host lock)
}
I think it would be a little harder than this because of scsi-ml's use
of spin_lock_irqsave/spin_lock_irqrestore. Will that do the right thing
still if we have enabled and disabled irqs or is it a nice way to use
the api. For the latter I mean, I think most drivers do not need the
host lock taken in the queuecommand function and so we could just change
scsi-ml) and benefit everyone?
--
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 RFC] use _bh locking in iscsi_queuecommand
Mike Christie wrote: > The scsi_host_template->queuecommand function is called by scsi-ml with > irqs disabled spin_lock_irqsave(host->host_lock, flags) thanks for clarifying that, specifically do you refer to scsi.c :: scsi_dispatch_cmd()? at some point I was LXR-ing for queuecommand and somehow got a bit confused thinking that this isn't the only flow the invokes queuecommand. If this --is-- the case, then I'm back to my 2nd question... why iscsi_queuecommand does spin_unlock(host->host_lock) in its beginning and spin_lock(host->host_lock) in its end? > I thought bhs are run from interrupt context, so scsi-mls disabling irqs did > what we > needed (see the bottom of Rusty Russells locking guide > http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/c188.html#HARDIRQ- > SOFTIRQ I think there is more detail in the Linux Device Driver book). mmm, understood, yes from Rusty's wording I understand that indeed the ML irq disabling does what we want for the cpu queuecommand runs on. Or. -- 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 RFC] use _bh locking in iscsi_queuecommand
Or Gerlitz wrote: > Mike Christie wrote: > >> The scsi_host_template->queuecommand function is called by scsi-ml with >> irqs disabled spin_lock_irqsave(host->host_lock, flags) > > thanks for clarifying that, specifically do you refer to scsi.c :: > scsi_dispatch_cmd()? at some point I was LXR-ing for queuecommand and scsi_dispatch_cmd and then there is a scsi_host_template->queuecommand call in scsi_err.c used to inject error handling cmds (for example if we return success in eh_abort then scsi-ml will call queuecommand to send a TUR). The host lock is also taken in the scsi-ml completion paths, and some other places like for checking some state. It is actually taken a little before scsi_lib.c calls scsi_dispatch_cmd to check some state, then dropped before scsi_dispatch_cmd is called then taken again in there. > somehow got a bit confused thinking that this isn't the only flow the > invokes queuecommand. If this --is-- the case, then I'm back to my 2nd > question... why iscsi_queuecommand does spin_unlock(host->host_lock) > in its beginning and spin_lock(host->host_lock) in its end? We do not use the host lock for anything really. We just grab it a couple times to check some host values that are set under the host lock, but we do not need the host lock for any send/complete synchronization reasons, and there is no scsi-ml reason that drivers have to have the host lock in their queuecommand in the current code. I think a long time ago drivers used the host lock like how we use the session lock, but if you look at newer drivers like qla2xxx or lpfc or fnic, etc they drop the host lock then grab their own private locks. There has been discussion on linux-scsi to just remove the host lock and let drivers use their own. The problem is that we have to figure out what the older drivers were using the host lock for and fix them up. -- 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 4/5] BNX2I - Task management ABORT TASK fixes
Anil Veerabhadrappa wrote: > * Due to typo error driver was failing TMF Abort Task request > when ctask->sc != NULL. Fixed code to fail TMF ABORT Task > request only when ctask->sc == NULL > * Clear age component (19 most significant bits) of reference ITT > carried in iSCSI TMF PDU. Age component is internal to initiator > side and only lower bits of ITT as defined by ISCSI_ITT_MASK is > is sent on wire > * Retrieve LUN directly from the ref_sc and update SQ wqe as per > chip HSI (Host Software Interface) specification > > Signed-off-by: Anil Veerabhadrappa Looks ok Reviewed-by: Mike Christie -- 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 1/5] BNX2I - Add 5771E device support to bnx2i driver
Anil Veerabhadrappa wrote: > * Add code to enumerate 5771E device > > Signed-off-by: Anil Veerabhadrappa > --- > drivers/scsi/bnx2i/bnx2i_init.c |6 +- > 1 files changed, 5 insertions(+), 1 deletions(-) > > diff --git a/drivers/scsi/bnx2i/bnx2i_init.c b/drivers/scsi/bnx2i/bnx2i_init.c > index 0c4210d..3c46458 100644 > --- a/drivers/scsi/bnx2i/bnx2i_init.c > +++ b/drivers/scsi/bnx2i/bnx2i_init.c > @@ -83,8 +83,12 @@ void bnx2i_identify_device(struct bnx2i_hba *hba) > set_bit(BNX2I_NX2_DEV_5709, &hba->cnic_dev_type); > hba->mail_queue_access = BNX2I_MQ_BIN_MODE; > } else if (hba->pci_did == PCI_DEVICE_ID_NX2_57710 || > -hba->pci_did == PCI_DEVICE_ID_NX2_57711) > +hba->pci_did == PCI_DEVICE_ID_NX2_57711 || > +hba->pci_did == PCI_DEVICE_ID_NX2_57711E) > set_bit(BNX2I_NX2_DEV_57710, &hba->cnic_dev_type); > + else > + printk(KERN_ALERT "bnx2i: unknown device, 0x%x\n", > + hba->pci_did); > } > > Ok. Reviewed-by: Mike Christie -- 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 2/5 ] BNX2I - Adjust sq_size module parametr to power of 2 only if a non-zero value is specified
Anil Veerabhadrappa wrote: > * This issue was discovered during 10G iscsi testing > * Default value of 'sq_size' module parameter is '0' which means > driver should use predefined SQ queue size when setting up iscsi > connection. > * roundup_pow_of_two(0) results in '1' and forces driver to setup > connections with send queue size of '1' and results in lower > performance as well > > Signed-off-by: Anil Veerabhadrappa > --- > drivers/scsi/bnx2i/bnx2i_init.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/scsi/bnx2i/bnx2i_init.c b/drivers/scsi/bnx2i/bnx2i_init.c > index 3c46458..dc6b56c 100644 > --- a/drivers/scsi/bnx2i/bnx2i_init.c > +++ b/drivers/scsi/bnx2i/bnx2i_init.c > @@ -367,7 +367,7 @@ static int __init bnx2i_mod_init(void) > > printk(KERN_INFO "%s", version); > > - if (!is_power_of_2(sq_size)) > + if (sq_size && !is_power_of_2(sq_size)) > sq_size = roundup_pow_of_two(sq_size); > > mutex_init(&bnx2i_dev_lock); Ok. Reviewed-by: Mike Christie -- 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 5/5] BNX2I - minor code cleanup and update driver version
Anil Veerabhadrappa wrote: > * Removed duplicate function call and not-so-useful comment line > > Signed-off-by: Anil Veerabhadrappa > --- > drivers/scsi/bnx2i/bnx2i_init.c |4 ++-- > drivers/scsi/bnx2i/bnx2i_iscsi.c |2 -- > 2 files changed, 2 insertions(+), 4 deletions(-) > > diff --git a/drivers/scsi/bnx2i/bnx2i_init.c b/drivers/scsi/bnx2i/bnx2i_init.c > index ad551c5..1e111ac 100644 > --- a/drivers/scsi/bnx2i/bnx2i_init.c > +++ b/drivers/scsi/bnx2i/bnx2i_init.c > @@ -17,8 +17,8 @@ static struct list_head adapter_list = > LIST_HEAD_INIT(adapter_list); > static u32 adapter_count; > > #define DRV_MODULE_NAME "bnx2i" > -#define DRV_MODULE_VERSION "2.0.1e" > -#define DRV_MODULE_RELDATE "June 22, 2009" > +#define DRV_MODULE_VERSION "2.1.0" > +#define DRV_MODULE_RELDATE "Dec 06, 2009" > > static char version[] __devinitdata = > "Broadcom NetXtreme II iSCSI Driver " DRV_MODULE_NAME \ > diff --git a/drivers/scsi/bnx2i/bnx2i_iscsi.c > b/drivers/scsi/bnx2i/bnx2i_iscsi.c > index 070118a..54dc251 100644 > --- a/drivers/scsi/bnx2i/bnx2i_iscsi.c > +++ b/drivers/scsi/bnx2i/bnx2i_iscsi.c > @@ -485,7 +485,6 @@ static int bnx2i_setup_cmd_pool(struct bnx2i_hba *hba, > struct iscsi_task *task = session->cmds[i]; > struct bnx2i_cmd *cmd = task->dd_data; > > - /* Anil */ > task->hdr = &cmd->hdr; > task->hdr_max = sizeof(struct iscsi_hdr); > > @@ -765,7 +764,6 @@ struct bnx2i_hba *bnx2i_alloc_hba(struct cnic_dev *cnic) > hba->pci_svid = hba->pcidev->subsystem_vendor; > hba->pci_func = PCI_FUNC(hba->pcidev->devfn); > hba->pci_devno = PCI_SLOT(hba->pcidev->devfn); > - bnx2i_identify_device(hba); > > bnx2i_identify_device(hba); > bnx2i_setup_host_queue_size(hba, shost); Reviewed-by: Mike Christie -- 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 3/5] BNX2I - update CQ arming algorith for 5771x chipsets
Anil Veerabhadrappa wrote: > * Only affects 5771x (10G chipsets) devices Why don't you do it on 1 gig? Is it just not worth it or is it no possible due to some limitation? -- 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: Need help with multipath and iscsi in CentOS 5.4
Kyle Schmitt wrote: > I'm cross-posting here from linux-iscsi-users since I've seen no linux-scsi-users would be for centos 4. Centos 5 uses a different initiator, but you are the right place finally :) > traffic in the weeks since I posted this. > > Hi, I needed a little help or advice with my setup. I'm trying to > configure multipathed iscsi on a CentOS 5.4 (RHEL 5.4 clone) box. > > Very short version: One server with two NICs for iSCSI sees storage on > EMC. Storage shows up as four discs, but only one works. > > So far single connections work: If I setup the box to use one NIC, I > get one connection and can use it just fine. > > When I setup multiple connections I have problems... > I created two interfaces, and assigned each one to a NIC > iscsiadm -m iface -I iface0 --op=new > iscsiadm -m iface -I iface0 --op=update -n iface.net_ifacename -v eth2 > iscsiadm -m iface -I iface1 --op=new > iscsiadm -m iface -I iface1 --op=update -n iface.net_ifacename -v eth3 > > Each interface saw two paths to their storage, four total, so far so > good. > I logged all four of them them in with: > iscsiadm -m node -T -l > > I could see I was connected to all four via > iscsiadm-m session > > At this point, I thought I was set, I had four new devices > /dev/sdb /dev/sdc /dev/sdd /dev/sde > > Ignoring multipath at this point for now, here's where the problem > started. I have all four devices, but I can only communicate through > one of them: /dev/sdc. > > As a quick test I tried to fdisk all four partitions, to see if I saw > the same thing in each place, and only /dev/sdc works. What do you mean by works? Can you dd it, or fdisk it? > > Turning on multipath, I got a multipathed device consisting of sdb sdc > sdd and sde, but sdb sdd and sde are failed with a message of > checker msg is "emc_clariion_checker: Logical Unit is unbound or LUNZ" > Have you created a lun that is accessible to the initiator defined in /etc/iscsi/initiatorname.iscsi? Could you send the /var/log/messages for when you run the login command so I can see the disk info? -- 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: SLES10 SP3 x86_64 - connection2:0: detected conn error (1011)
avora wrote: > I do not see ping/nop timeout message in the logs > (probably that's why changing the noop timeouts did not work). > Simply starting the session does not cause these errors. > On starting the second session, I start a daemon > that does SCSI commands like INQUIRY on all the paths. > After that I see these messages, and the daemon gets stuck > for a very long time waiting for SCSI commands to finish. > > At the backend I have EMC CLARiiON. > > # iscsiadm -m node -P 1 > Target: iqn.1992-04.com.emc:cx.ckm00091100683.a2 > Portal: 192.168.10.1:3260,1 > Iface Name: iface0 > Target: iqn.1992-04.com.emc:cx.ckm00091100683.b2 > Portal: 192.168.12.1:3260,3 > Iface Name: iface1 Does the same path always fail? If you log into one can you use it, then if you logout and log into the other does that other one then work? Is there any info the clarrion logs? -- 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: Another Kernel Oops?
Qinghua(Kevin) Ye wrote: > Hi All, > > I encountered another kernel oops in the open-iscsi code. Not sure if it is > fixed in the new code, but I would like to have some idea about it. Thanks. > > My setup: > Ubuntu 8.04 with kernel 2.6.24-24-generic. > Open-iscsi 2.0-870.3 > > > The kernel oops happens after my iscsi target node crashed. > Here is the kernel message. > Dec 7 10:08:21 qye-serv1 kernel: [1459378.575584] connection3903:0: > detected conn error (1011) > Dec 7 10:08:21 qye-serv1 kernel: [1459378.826718] sd 18028:0:0:16: timing > out command, waited 180s > Dec 7 10:08:21 qye-serv1 kernel: [1459378.826827] sd 18028:0:0:16: [sdd] > Result: hostbyte=DID_BUS_BUSY driverbyte=DRIVER_OK,SUGGEST_OK > Dec 7 10:08:21 qye-serv1 kernel: [1459378.826840] end_request: I/O error, > dev sdd, sector 4505344 > Dec 7 10:08:21 qye-serv1 kernel: [1459378.826897] Buffer I/O error on > device sdd, logical block 563168 > Dec 7 10:10:21 qye-serv1 kernel: [1459498.629142] session3903: session > recovery timed out after 120 secs > Dec 7 10:10:21 qye-serv1 kernel: [1459498.629618] BUG: unable to handle > kernel paging request at virtual address fcb8d006 > Dec 7 10:10:21 qye-serv1 kernel: [1459498.629815] printing eip: e0a49ff7 > *pde = > Dec 7 10:10:21 qye-serv1 kernel: [1459498.630090] Oops: [#1] SMP > Dec 7 10:10:21 qye-serv1 kernel: [1459498.630290] Modules linked in: > iscsi_tcp libiscsi scsi_transport_iscsi iscsi_trgt nls_iso8859_1 nls_cp437 > vfat fat nfsd auth_rpcgss exportfs crc32c libcrc32c vmmemctl > cpufreq_conservative cpufreq_ondemand cpufreq_userspace cpufreq_stats > freq_table cpufreq_powersave sbs video output sbshc dock battery nfs lockd > nfs_acl sunrpc iptable_filter ip_tables x_tables vmhgfs lp loop ipv6 > intel_agp i2c_piix4 serio_raw container ac button agpgart i2c_core shpchp > pci_hotplug parport_pc parport evdev psmouse pcspkr ext3 jbd mbcache ide_cd > cdrom sg sd_mod floppy pcnet32 mptspi mptscsih mptbase mii pata_acpi > ata_generic scsi_transport_spi ata_piix libata scsi_mod ide_generic ide_core > raid10 raid456 async_xor async_memcpy async_tx xor raid1 raid0 multipath > linear md_mod dm_mirror dm_snapshot dm_mod thermal processor fan fbcon > tileblit font bitblit softcursor fuse vmxnet > Dec 7 10:10:21 qye-serv1 kernel: [1459498.631597] > Dec 7 10:10:21 qye-serv1 kernel: [1459498.631735] Pid: 32010, comm: > iscsi_eh Not tainted (2.6.24-24-generic #1) > Dec 7 10:10:21 qye-serv1 kernel: [1459498.631837] EIP: 0060:[] > EFLAGS: 00010097 CPU: 0 > Dec 7 10:10:21 qye-serv1 kernel: [1459498.632168] EIP is at > iscsi_queuecommand+0x47/0x260 [libiscsi] > Dec 7 10:10:21 qye-serv1 kernel: [1459498.632273] EAX: e09776fa EBX: > d8384500 ECX: e09775e0 EDX: e0979560 > Dec 7 10:10:21 qye-serv1 kernel: [1459498.632370] ESI: d8384500 EDI: > c38d9400 EBP: c38d9400 ESP: ce921eb8 > Dec 7 10:10:21 qye-serv1 kernel: [1459498.632467] DS: 007b ES: 007b FS: > 00d8 GS: SS: 0068 > Dec 7 10:10:21 qye-serv1 kernel: [1459498.632583] Process iscsi_eh (pid: > 32010, ti=ce92 task=c61aa000 task.ti=ce92) > Dec 7 10:10:21 qye-serv1 kernel: [1459498.633296] Stack: e0979560 > d8384500 0287 c38d9400 0031 e0979da7 > Dec 7 10:10:21 qye-serv1 kernel: [1459498.633508]dc501600 dc501600 > c38d9400 d8926000 d81dc810 e098018a 0036 0016452a > Dec 7 10:10:21 qye-serv1 kernel: [1459498.633660]0006 d8926028 > d8926148 d89260b0 d8384500 d81dc810 d81dc810 > Dec 7 10:10:21 qye-serv1 kernel: [1459498.633816] Call Trace: > Dec 7 10:10:21 qye-serv1 kernel: [1459498.634045] [] > scsi_done+0x0/0x20 [scsi_mod] > Dec 7 10:10:21 qye-serv1 kernel: [1459498.708347] [] > scsi_dispatch_cmd+0x147/0x280 [scsi_mod] > Dec 7 10:10:21 qye-serv1 kernel: [1459498.708502] [] > scsi_request_fn+0x1ea/0x380 [scsi_mod] > Dec 7 10:10:21 qye-serv1 kernel: [1459498.749813] [] > device_unblock+0x0/0x10 [scsi_mod] > Dec 7 10:10:21 qye-serv1 kernel: [1459498.749930] [] > blk_start_queue+0x32/0x90 > Dec 7 10:10:21 qye-serv1 kernel: [1459498.832531] [] > get_device+0xe/0x20 > Dec 7 10:10:21 qye-serv1 kernel: [1459498.879473] [] > scsi_device_get+0x1e/0x50 [scsi_mod] > Dec 7 10:10:22 qye-serv1 kernel: [1459498.879592] [] > scsi_internal_device_unblock+0x35/0x60 [scsi_mod] > Dec 7 10:10:22 qye-serv1 kernel: [1459498.879714] [] > starget_for_each_device+0x72/0x80 [scsi_mod] > Dec 7 10:10:22 qye-serv1 kernel: [1459498.879966] [] > target_unblock+0x0/0x20 [scsi_mod] > Dec 7 10:10:22 qye-serv1 kernel: [1459498.880094] [] > target_unblock+0x1b/0x20 [scsi_mod] > Dec 7 10:10:22 qye-serv1 kernel: [1459498.880201] [] > device_for_each_child+0x22/0x40 > Dec 7 10:10:22 qye-serv1 kernel: [1459498.880290] [] > session_recovery_timedout+0x0/0xc0 [scsi_transport_iscsi] > Dec 7 10:10:22 qye-serv1 kernel: [1459498.880439] [] > run_workqueue+0xbf/0x160 > Dec 7 10:10:22 qye-serv1 kernel: [1459498.933133] [] > worker_thread+0x0/0xe0 > Dec 7 10:10:22 qye-serv1
Re: SLES10 SP3 x86_64 - connection2:0: detected conn error (1011)
avora wrote: > I got a similar issue while browsing > http://groups.google.com/group/open-iscsi/browse_thread/thread/3c9c37903e40cd6f > > I wanted to enable logging as mentioned in above link. > > echo 1 > /sys/module/libiscsi/parameters/debug_libiscsi_conn > echo 1 > /sys/module/libiscsi/parameters/debug_libiscsi_session > echo 1 > /sys/module/libiscsi/parameters/debug_libiscsi_eh > echo 1 > /sys/module/iscsi_tcp/parameters/debug_iscsi_tcp > echo 1 > /sys/module/libiscsi_tcp/parameters/debug_libiscsi_tcp > --- > > But on my machine I only see. > > # ls /sys/module/libiscsi/ > refcnt sections srcversion > > # ls /sys/module/iscsi_tcp/ > parameters refcnt sections srcversion > > # ls /sys/module/iscsi_tcp/parameters/max_lun > /sys/module/iscsi_tcp/parameters/max_lun > Your open-iscsi version is older and does not have those settings. > > # iscsiadm -m session -P 1 > Target: iqn.1992-04.com.emc:cx.ckm00091100683.a3 > > iSCSI Connection State: TRANSPORT WAIT > iSCSI Session State: FAILED > Internal iscsid Session State: REPOEN > > You might be seeing something else. >>> Dec 7 18:42:06 cdc-r710s1 iscsid: connection2:0 is operational after >>> recovery (1 attempts) After the conn error message do you see one of these right away? -- 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: SLES10 SP3 x86_64 - connection2:0: detected conn error (1011)
Mike Christie wrote: > avora wrote: >> I do not see ping/nop timeout message in the logs >> (probably that's why changing the noop timeouts did not work). >> Simply starting the session does not cause these errors. >> On starting the second session, I start a daemon >> that does SCSI commands like INQUIRY on all the paths. >> After that I see these messages, and the daemon gets stuck >> for a very long time waiting for SCSI commands to finish. >> >> At the backend I have EMC CLARiiON. >> >> # iscsiadm -m node -P 1 >> Target: iqn.1992-04.com.emc:cx.ckm00091100683.a2 >> Portal: 192.168.10.1:3260,1 >> Iface Name: iface0 >> Target: iqn.1992-04.com.emc:cx.ckm00091100683.b2 >> Portal: 192.168.12.1:3260,3 >> Iface Name: iface1 > > > Does the same path always fail? > > If you log into one can you use it, then if you logout and log into the > other does that other one then work? > > Is there any info the clarrion logs? > If this is easy to reproduce could you get a wireshark/ethereal trace and send it? -- 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: Another Kernel Oops?
Hi Mike, Yes, as I said the target node crashed and then the open-icssi kernel oops happens. So far I only hit it once. I'll try to see if I can reproduce it. Kevin On Wed, Dec 9, 2009 at 8:00 PM, Mike Christie wrote: > Qinghua(Kevin) Ye wrote: > > Hi All, > > > > I encountered another kernel oops in the open-iscsi code. Not sure if it > is > > fixed in the new code, but I would like to have some idea about it. > Thanks. > > > > My setup: > > Ubuntu 8.04 with kernel 2.6.24-24-generic. > > Open-iscsi 2.0-870.3 > > > > > > The kernel oops happens after my iscsi target node crashed. > > Here is the kernel message. > > Dec 7 10:08:21 qye-serv1 kernel: [1459378.575584] connection3903:0: > > detected conn error (1011) > > Dec 7 10:08:21 qye-serv1 kernel: [1459378.826718] sd 18028:0:0:16: > timing > > out command, waited 180s > > Dec 7 10:08:21 qye-serv1 kernel: [1459378.826827] sd 18028:0:0:16: [sdd] > > Result: hostbyte=DID_BUS_BUSY driverbyte=DRIVER_OK,SUGGEST_OK > > Dec 7 10:08:21 qye-serv1 kernel: [1459378.826840] end_request: I/O > error, > > dev sdd, sector 4505344 > > Dec 7 10:08:21 qye-serv1 kernel: [1459378.826897] Buffer I/O error on > > device sdd, logical block 563168 > > Dec 7 10:10:21 qye-serv1 kernel: [1459498.629142] session3903: session > > recovery timed out after 120 secs > > Dec 7 10:10:21 qye-serv1 kernel: [1459498.629618] BUG: unable to handle > > kernel paging request at virtual address fcb8d006 > > Dec 7 10:10:21 qye-serv1 kernel: [1459498.629815] printing eip: e0a49ff7 > > *pde = > > Dec 7 10:10:21 qye-serv1 kernel: [1459498.630090] Oops: [#1] SMP > > Dec 7 10:10:21 qye-serv1 kernel: [1459498.630290] Modules linked in: > > iscsi_tcp libiscsi scsi_transport_iscsi iscsi_trgt nls_iso8859_1 > nls_cp437 > > vfat fat nfsd auth_rpcgss exportfs crc32c libcrc32c vmmemctl > > cpufreq_conservative cpufreq_ondemand cpufreq_userspace cpufreq_stats > > freq_table cpufreq_powersave sbs video output sbshc dock battery nfs > lockd > > nfs_acl sunrpc iptable_filter ip_tables x_tables vmhgfs lp loop ipv6 > > intel_agp i2c_piix4 serio_raw container ac button agpgart i2c_core shpchp > > pci_hotplug parport_pc parport evdev psmouse pcspkr ext3 jbd mbcache > ide_cd > > cdrom sg sd_mod floppy pcnet32 mptspi mptscsih mptbase mii pata_acpi > > ata_generic scsi_transport_spi ata_piix libata scsi_mod ide_generic > ide_core > > raid10 raid456 async_xor async_memcpy async_tx xor raid1 raid0 multipath > > linear md_mod dm_mirror dm_snapshot dm_mod thermal processor fan fbcon > > tileblit font bitblit softcursor fuse vmxnet > > Dec 7 10:10:21 qye-serv1 kernel: [1459498.631597] > > Dec 7 10:10:21 qye-serv1 kernel: [1459498.631735] Pid: 32010, comm: > > iscsi_eh Not tainted (2.6.24-24-generic #1) > > Dec 7 10:10:21 qye-serv1 kernel: [1459498.631837] EIP: 0060:[] > > EFLAGS: 00010097 CPU: 0 > > Dec 7 10:10:21 qye-serv1 kernel: [1459498.632168] EIP is at > > iscsi_queuecommand+0x47/0x260 [libiscsi] > > Dec 7 10:10:21 qye-serv1 kernel: [1459498.632273] EAX: e09776fa EBX: > > d8384500 ECX: e09775e0 EDX: e0979560 > > Dec 7 10:10:21 qye-serv1 kernel: [1459498.632370] ESI: d8384500 EDI: > > c38d9400 EBP: c38d9400 ESP: ce921eb8 > > Dec 7 10:10:21 qye-serv1 kernel: [1459498.632467] DS: 007b ES: 007b FS: > > 00d8 GS: SS: 0068 > > Dec 7 10:10:21 qye-serv1 kernel: [1459498.632583] Process iscsi_eh (pid: > > 32010, ti=ce92 task=c61aa000 task.ti=ce92) > > Dec 7 10:10:21 qye-serv1 kernel: [1459498.633296] Stack: e0979560 > > > d8384500 0287 c38d9400 0031 e0979da7 > > Dec 7 10:10:21 qye-serv1 kernel: [1459498.633508]dc501600 > dc501600 > > c38d9400 d8926000 d81dc810 e098018a 0036 0016452a > > Dec 7 10:10:21 qye-serv1 kernel: [1459498.633660]0006 > d8926028 > > d8926148 d89260b0 d8384500 d81dc810 d81dc810 > > Dec 7 10:10:21 qye-serv1 kernel: [1459498.633816] Call Trace: > > Dec 7 10:10:21 qye-serv1 kernel: [1459498.634045] [] > > scsi_done+0x0/0x20 [scsi_mod] > > Dec 7 10:10:21 qye-serv1 kernel: [1459498.708347] [] > > scsi_dispatch_cmd+0x147/0x280 [scsi_mod] > > Dec 7 10:10:21 qye-serv1 kernel: [1459498.708502] [] > > scsi_request_fn+0x1ea/0x380 [scsi_mod] > > Dec 7 10:10:21 qye-serv1 kernel: [1459498.749813] [] > > device_unblock+0x0/0x10 [scsi_mod] > > Dec 7 10:10:21 qye-serv1 kernel: [1459498.749930] [] > > blk_start_queue+0x32/0x90 > > Dec 7 10:10:21 qye-serv1 kernel: [1459498.832531] [] > > get_device+0xe/0x20 > > Dec 7 10:10:21 qye-serv1 kernel: [1459498.879473] [] > > scsi_device_get+0x1e/0x50 [scsi_mod] > > Dec 7 10:10:22 qye-serv1 kernel: [1459498.879592] [] > > scsi_internal_device_unblock+0x35/0x60 [scsi_mod] > > Dec 7 10:10:22 qye-serv1 kernel: [1459498.879714] [] > > starget_for_each_device+0x72/0x80 [scsi_mod] > > Dec 7 10:10:22 qye-serv1 kernel: [1459498.879966] [] > > target_unblock+0x0/0x20 [scsi_mod] > > Dec 7 10:10:22 qye-serv1 kernel: [1459498.880094] [] > > target_unblock+0x1b/0
[PATCH 1/1]: fixed cxgb3i to always use negative errno in case of error
[PATCH 1/1]: fixed cxgb3i to always use negative errno in case of error
From: Karen Xie
Fixed cxgb3i to use negative errno in case of error.
Signed-off-by: Karen Xie
---
drivers/scsi/cxgb3i/cxgb3i_offload.c | 24
drivers/scsi/cxgb3i/cxgb3i_pdu.c |4 ++--
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/scsi/cxgb3i/cxgb3i_offload.c
b/drivers/scsi/cxgb3i/cxgb3i_offload.c
index c1d5be4..26ffdcd 100644
--- a/drivers/scsi/cxgb3i/cxgb3i_offload.c
+++ b/drivers/scsi/cxgb3i/cxgb3i_offload.c
@@ -291,7 +291,7 @@ static void act_open_req_arp_failure(struct t3cdev *dev,
struct sk_buff *skb)
c3cn_hold(c3cn);
spin_lock_bh(&c3cn->lock);
if (c3cn->state == C3CN_STATE_CONNECTING)
- fail_act_open(c3cn, EHOSTUNREACH);
+ fail_act_open(c3cn, -EHOSTUNREACH);
spin_unlock_bh(&c3cn->lock);
c3cn_put(c3cn);
__kfree_skb(skb);
@@ -792,18 +792,18 @@ static int act_open_rpl_status_to_errno(int status)
{
switch (status) {
case CPL_ERR_CONN_RESET:
- return ECONNREFUSED;
+ return -ECONNREFUSED;
case CPL_ERR_ARP_MISS:
- return EHOSTUNREACH;
+ return -EHOSTUNREACH;
case CPL_ERR_CONN_TIMEDOUT:
- return ETIMEDOUT;
+ return -ETIMEDOUT;
case CPL_ERR_TCAM_FULL:
- return ENOMEM;
+ return -ENOMEM;
case CPL_ERR_CONN_EXIST:
cxgb3i_log_error("ACTIVE_OPEN_RPL: 4-tuple in use\n");
- return EADDRINUSE;
+ return -EADDRINUSE;
default:
- return EIO;
+ return -EIO;
}
}
@@ -817,7 +817,7 @@ static void act_open_retry_timer(unsigned long data)
spin_lock_bh(&c3cn->lock);
skb = alloc_skb(sizeof(struct cpl_act_open_req), GFP_ATOMIC);
if (!skb)
- fail_act_open(c3cn, ENOMEM);
+ fail_act_open(c3cn, -ENOMEM);
else {
skb->sk = (struct sock *)c3cn;
set_arp_failure_handler(skb, act_open_req_arp_failure);
@@ -966,14 +966,14 @@ static int abort_status_to_errno(struct s3_conn *c3cn,
int abort_reason,
case CPL_ERR_BAD_SYN: /* fall through */
case CPL_ERR_CONN_RESET:
return c3cn->state > C3CN_STATE_ESTABLISHED ?
- EPIPE : ECONNRESET;
+ -EPIPE : -ECONNRESET;
case CPL_ERR_XMIT_TIMEDOUT:
case CPL_ERR_PERSIST_TIMEDOUT:
case CPL_ERR_FINWAIT2_TIMEDOUT:
case CPL_ERR_KEEPALIVE_TIMEDOUT:
- return ETIMEDOUT;
+ return -ETIMEDOUT;
default:
- return EIO;
+ return -EIO;
}
}
@@ -1563,7 +1563,7 @@ free_tid:
s3_free_atid(cdev, c3cn->tid);
c3cn->tid = 0;
out_err:
- return -1;
+ return -EINVAL;
}
diff --git a/drivers/scsi/cxgb3i/cxgb3i_pdu.c b/drivers/scsi/cxgb3i/cxgb3i_pdu.c
index 7091050..1fe3b0f 100644
--- a/drivers/scsi/cxgb3i/cxgb3i_pdu.c
+++ b/drivers/scsi/cxgb3i/cxgb3i_pdu.c
@@ -388,8 +388,8 @@ int cxgb3i_conn_xmit_pdu(struct iscsi_task *task)
if (err > 0) {
int pdulen = err;
- cxgb3i_tx_debug("task 0x%p, skb 0x%p, len %u/%u, rv %d.\n",
- task, skb, skb->len, skb->data_len, err);
+ cxgb3i_tx_debug("task 0x%p, skb 0x%p, len %u/%u, rv %d.\n",
+ task, skb, skb->len, skb->data_len, err);
if (task->conn->hdrdgst_en)
pdulen += ISCSI_DIGEST_SIZE;
--
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 1/1] cxgb3i: Fix a login over vlan issue
[PATCH 1/1] cxgb3i: Fix a login over vlan issue
From: Karen Xie
Fix a login over vlan issue, when parent interface is vlan and we are using
cxgb3i sepecific private ip address in '/etc/iscsi/ifaces/' iface file.
Acked-by: Karen Xie
Signed-off-by: Rakesh Ranjan
---
drivers/scsi/cxgb3i/cxgb3i_offload.c | 33 -
1 files changed, 32 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/cxgb3i/cxgb3i_offload.c
b/drivers/scsi/cxgb3i/cxgb3i_offload.c
index 26ffdcd..1aef364 100644
--- a/drivers/scsi/cxgb3i/cxgb3i_offload.c
+++ b/drivers/scsi/cxgb3i/cxgb3i_offload.c
@@ -1440,6 +1440,10 @@ void cxgb3i_c3cn_release(struct s3_conn *c3cn)
static int is_cxgb3_dev(struct net_device *dev)
{
struct cxgb3i_sdev_data *cdata;
+ struct net_device *ndev = dev;
+
+ if (dev->priv_flags & IFF_802_1Q_VLAN)
+ ndev = vlan_dev_real_dev(dev);
write_lock(&cdata_rwlock);
list_for_each_entry(cdata, &cdata_list, list) {
@@ -1447,7 +1451,7 @@ static int is_cxgb3_dev(struct net_device *dev)
int i;
for (i = 0; i < ports->nports; i++)
- if (dev == ports->lldevs[i]) {
+ if (ndev == ports->lldevs[i]) {
write_unlock(&cdata_rwlock);
return 1;
}
@@ -1566,6 +1570,25 @@ out_err:
return -EINVAL;
}
+/**
+ * cxgb3i_find_dev - find the interface associated with the given address
+ * @ipaddr: ip address
+ */
+static struct net_device *cxgb3i_find_dev(__be32 ipaddr)
+{
+ struct flowi fl;
+ int err;
+ struct rtable *rt;
+
+ memset(&fl, 0, sizeof(fl));
+ fl.nl_u.ip4_u.daddr = ipaddr;
+
+ err = ip_route_output_key(&init_net, &rt, &fl);
+ if (!err)
+ return (&rt->u.dst)->dev;
+
+ return NULL;
+}
/**
* cxgb3i_c3cn_connect - initiates an iscsi tcp connection to a given address
@@ -1581,6 +1604,7 @@ int cxgb3i_c3cn_connect(struct net_device *dev, struct
s3_conn *c3cn,
struct cxgb3i_sdev_data *cdata;
struct t3cdev *cdev;
__be32 sipv4;
+ struct net_device *dstdev;
int err;
c3cn_conn_debug("c3cn 0x%p, dev 0x%p.\n", c3cn, dev);
@@ -1591,6 +1615,13 @@ int cxgb3i_c3cn_connect(struct net_device *dev, struct
s3_conn *c3cn,
c3cn->daddr.sin_port = usin->sin_port;
c3cn->daddr.sin_addr.s_addr = usin->sin_addr.s_addr;
+ dstdev = cxgb3i_find_dev(usin->sin_addr.s_addr);
+ if (!dstdev || !is_cxgb3_dev(dstdev))
+ return -ENETUNREACH;
+
+ if (dstdev->priv_flags & IFF_802_1Q_VLAN)
+ dev = dstdev;
+
rt = find_route(dev, c3cn->saddr.sin_addr.s_addr,
c3cn->daddr.sin_addr.s_addr,
c3cn->saddr.sin_port,
--
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 1/1] cxgb3i: Fix a login over vlan issue
Hi, thanks, Mike.
It looks like the original patch somehow did not make into the linux-scsi list
at all for some reason: tried to search for it but could not find it.
We are re-submitting it just to make sure.
Best regards,
Karen
-Original Message-
From: Mike Christie [mailto:micha...@cs.wisc.edu]
Sent: Mon 12/7/2009 8:34 AM
To: open-iscsi@googlegroups.com
Cc: james.bottom...@hansenpartnership.com; da...@davemloft.net; Steve Wise;
Karen Xie; linux-s...@vger.kernel.org; linux-ker...@vger.kernel.org;
net...@vger.kernel.org; Rakesh Ranjan
Subject: Re: [PATCH 1/1] cxgb3i: Fix a login over vlan issue
Rakesh Ranjan wrote:
> Fix a login over vlan issue, when parent interface is vlan and we are using
> cxgb3i sepecific
> private ip address in '/etc/iscsi/ifaces/' iface file.
>
> Acked-by: Karen Xie
> Signed-off-by: Rakesh Ranjan
> ---
> drivers/scsi/cxgb3i/cxgb3i_offload.c | 34
> +-
> 1 files changed, 33 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/scsi/cxgb3i/cxgb3i_offload.c
> b/drivers/scsi/cxgb3i/cxgb3i_offload.c
> index c1d5be4..66d52e4 100644
> --- a/drivers/scsi/cxgb3i/cxgb3i_offload.c
> +++ b/drivers/scsi/cxgb3i/cxgb3i_offload.c
> @@ -1440,6 +1440,10 @@ void cxgb3i_c3cn_release(struct s3_conn *c3cn)
> static int is_cxgb3_dev(struct net_device *dev)
> {
> struct cxgb3i_sdev_data *cdata;
> + struct net_device *ndev = dev;
> +
> + if (dev->priv_flags & IFF_802_1Q_VLAN)
> + ndev = vlan_dev_real_dev(dev);
>
> write_lock(&cdata_rwlock);
> list_for_each_entry(cdata, &cdata_list, list) {
> @@ -1447,7 +1451,7 @@ static int is_cxgb3_dev(struct net_device *dev)
> int i;
>
> for (i = 0; i < ports->nports; i++)
> - if (dev == ports->lldevs[i]) {
> + if (ndev == ports->lldevs[i]) {
> write_unlock(&cdata_rwlock);
> return 1;
> }
> @@ -1566,6 +1570,26 @@ out_err:
> return -1;
> }
>
> +/**
> + * cxgb3i_find_dev - find the interface associated with the given address
> + * @ipaddr: ip address
> + */
> +static struct net_device *
> +cxgb3i_find_dev(__be32 ipaddr)
> +{
> + struct flowi fl;
> + int err;
> + struct rtable *rt;
> +
> + memset(&fl, 0, sizeof(fl));
> + fl.nl_u.ip4_u.daddr = ipaddr;
> +
> + err = ip_route_output_key(&init_net, &rt, &fl);
> + if (!err)
> + return (&rt->u.dst)->dev;
> +
> + return NULL;
> +}
>
> /**
> * cxgb3i_c3cn_connect - initiates an iscsi tcp connection to a given address
> @@ -1581,6 +1605,7 @@ int cxgb3i_c3cn_connect(struct net_device *dev, struct
> s3_conn *c3cn,
> struct cxgb3i_sdev_data *cdata;
> struct t3cdev *cdev;
> __be32 sipv4;
> + struct net_device *dstdev;
> int err;
>
> c3cn_conn_debug("c3cn 0x%p, dev 0x%p.\n", c3cn, dev);
> @@ -1591,6 +1616,13 @@ int cxgb3i_c3cn_connect(struct net_device *dev, struct
> s3_conn *c3cn,
> c3cn->daddr.sin_port = usin->sin_port;
> c3cn->daddr.sin_addr.s_addr = usin->sin_addr.s_addr;
>
> + dstdev = cxgb3i_find_dev(usin->sin_addr.s_addr);
> + if (!dstdev || !is_cxgb3_dev(dstdev))
> + return -ENETUNREACH;
> +
> + if (dstdev->priv_flags & IFF_802_1Q_VLAN)
> + dev = dstdev;
> +
> rt = find_route(dev, c3cn->saddr.sin_addr.s_addr,
> c3cn->daddr.sin_addr.s_addr,
> c3cn->saddr.sin_port,
Looks sane. I am not a expert on the networks apis being used 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.
