Re: iscsi_sysfs_read_iface
On Jul 26, 2011, at 11:34 PM, Hannes Reinecke wrote:
On 07/26/2011 09:44 PM, Mike Christie wrote:
On 07/26/2011 01:38 AM, Hannes Reinecke wrote:
Hi Eddie,
you beat me to it ...
On 07/26/2011 02:28 AM, Eddie Wai wrote:
Hello Mike,
The following snippet from the 39d4ceb04f051c208ae7509d268a3871ffa194c5
commit is preventing bnx2i from being able to offload when connecting
through the iscsi_sysfs_get_hostinfo_by_host_no code path where the
session argument == NULL. The initiatorname sysfs inquiry failed but
this is expected since it does not exist in the iscsi_host for bnx2i.
Perhaps the error return code should only be propagated upward when
session != NULL specifically for hbas like qla4xxx?
Thanks,
Eddie
- 8 - 8 -
@@ -527,7 +528,10 @@ static int iscsi_sysfs_read_iface(struct iface_rec
*iface, int host_no,
iface_str(iface));
}
}
- return ret;
+ if (ret)
+ return ISCSI_ERR_SYSFS_LOOKUP;
+ else
+ return 0;
}
- 8 - 8 -
Actually, this is the patch I have:
diff --git a/usr/iscsi_sysfs.c b/usr/iscsi_sysfs.c
index e82fe80..145816d 100644
--- a/usr/iscsi_sysfs.c
+++ b/usr/iscsi_sysfs.c
@@ -489,7 +489,7 @@ static int iscsi_sysfs_read_iface(struct iface_rec
*iface, int host_no,
if (ret) {
ret = sysfs_get_str(id, ISCSI_HOST_SUBSYS, initiatorname,
iface-iname, sizeof(iface-iname));
- if (ret)
+ if (ret) {
/*
* default iname is picked up later from
* initiatorname.iscsi if software/partial-offload.
@@ -499,6 +499,8 @@ static int iscsi_sysfs_read_iface(struct iface_rec
*iface, int host_no,
*/
log_debug(7, Could not read initiatorname for
host%d\n, host_no);
+ ret = 0;
+ }
}
/*
(Well, of course it got line-wrapped, but should get you the idea).
I'll be sending the proper patch to the mailing-list shortly.
But yes, that is a real issue.
Yeah, this is right. That is the behavior we had before. I can just fix
this up and merge it if there were no other changes needed.
Not in this area, no.
I've got some minor patches to the SUSE init script but they still
need further testing.
And actually I'm working on an 'iscsi_offload' scripts which
configures the interface definitions for the various offload
engines. If there is enough interest maybe we should include it in
the open-iscsi tarball.
I think this is a good idea.
Ravi
This message and any attached documents contain information from QLogic
Corporation or its wholly-owned subsidiaries that may be confidential. If you
are not the intended recipient, you may not read, copy, distribute, or use this
information. If you have received this transmission in error, please notify the
sender immediately by reply e-mail and then delete this message.
--
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?hl=en.
Re: [PATCH 0/5]: Proposal for iSCSI Network Configuration
On Feb 28, 2011, at 1:34 AM, Vikas Chaudhary wrote: -Original Message- From: Mike Christie [mailto:micha...@cs.wisc.edu] Sent: Monday, February 28, 2011 1:44 PM To: Vikas Chaudhary Cc: open-iscsi@googlegroups.com; James Bottomley; linux- s...@vger.kernel.org; Lalit Chandivade; Harish Zunjarrao; Manish Rangankar; Ravi Anand Subject: Re: [PATCH 0/5]: Proposal for iSCSI Network Configuration On 02/28/2011 12:02 AM, Vikas Chaudhary wrote: - We still need the BSG interface, which we are working on our side, to get the adapter FLASH related read/write operations. So would that be the operations to do something like store/get targets, discovery info, isns, chap, iscsi settings like FirstBurst, etc? We are planning to add BSG for Vendor specific flash updates like, read/write operations of - NVRAM, firmware and bootcode. We will use Netlink interface for target discovery info, iscsi settings, login/logout of target. Basically during last year discussion with you/James/Fujito , two important pieces came out of the discussion : * Common Generic interface which will work for other H/W offload. * iscsiadm support for H/W offload, for ex : qla4xxx in this case, so that user can configure it using Linux native tools. So after looking into iscsiadm interface and how our API interface works, it seemed much more logical to use the iscsidam existing interface rather than trying to reinvent the wheel. The additional work which will be required is to hook up our Application to *Netlink* interface and iscsiadm will work just by extending the existing infrastrutcure for configuration for ex, which is a key element for our flash based H/W offload. As Vikas alluded, BSG will be strictly adhered to just for vendor specific part where we may need to pass *bigger* blob of data in both directions or updating F/W or NVRAM etc. This is unlike what we intially proposed for setting up iscsi settings etc using vendor specific bsg interface which was doing it in a opaque manner. Other discovery element for ex : send target discovery / login/logout etc is being worked on so user can use iscsiadm native interface. So we have provided the iscsiadm+iscsi transport+qla4xxx patch for network configuration, to provide the complete overview the direction we want to go. Looking forward to comments/feedback to continue this discussion and come to an agreement on how to proceed further. Thanks Ravi This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message. -- 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?hl=en.
Re: FW: [PATCH 2/2] RFC: The be2iscsi driver support for bsg
On Thu, 18 Mar 2010 16:02:52 -0500
Mike Christie micha...@cs.wisc.edu wrote:
On 03/18/2010 08:58 AM, FUJITA Tomonori wrote:
- You invent your hardware specific data structure for the simplest
operation such as setting IP address.
I think this is what Jay is not trying to do. I think the patch has some
extra code like the ISCSI_BSG_HST_VENDOR parts that makes it confusing -
it got me too. The ISCSI_BSG_HST_VENDOR code in be2iscsi looks like it
is basically disabled (should remove for a formal patch when he sends
for merging).
It looks like there is a common struct iscsi_bsg_common_format that is
getting passed around, and then in be2iscsi the driver is using that
info to make a be2iscsi specific command. So scsi_transport_iscsi /
ISCSI_SET_IP_ADDR / iscsi_bsg_common_format gets translated by b2iscsi
to b2iscsi / OPCODE_COMMON_ISCSI_NTWK_MODIFY_IP_ADDR / be_modify_ip_addr.
Yeah, seems you are right. But looks like this patchset also adds the
vendor specific message support (ISCSI_BSG_HST_VENDOR)?
I still want to know why vendors can't do this via the existing
netlink interface. open-iscsi uses the netlink interface for some pdu
so I guess that having a different channel for management might be a
good idea.
In the current state *iscsi netlink interface* does not allow the user space
apps for iSCSI H/W offload solution (in our case its qla4xxx) to pass down
bunch
of parameter's in one shot for configuration purposes. As of know one can pass
one param at a time using netlink but that does not fit very well for offload
solution. Basically on the driver/FW side, it needs to use MBX interface for
most of the configuration part which requires payload to be passed back and
forth.
Looking into what was done on bsg side for FC looks a better fit and
provides the flexibility to add vendor specific stuff nicely and supports
dma payloads etc. So I agree with what has been discussed so far, about the
need for *iSCSI bsg interface* support for H/W iSCSI offload solution.
Ditto for flash management stuff - using bsg vendor mechanism makes more sense.
Here's an early snapshot of the patch which we are working on to add
the support using bsg vendor specific part - btw this is based on the previous
iscsi bsg patch and need to be synced up with what was posted recently.
So we hope that this gives you an idea why this needed.
(Please discard the *PING changes* for right now)
diff --git a/drivers/scsi/qla4xxx/ql4_def.h b/drivers/scsi/qla4xxx/ql4_def.h
index 81b5f29..47c3f45 100644
--- a/drivers/scsi/qla4xxx/ql4_def.h
+++ b/drivers/scsi/qla4xxx/ql4_def.h
@@ -443,6 +443,38 @@ struct scsi_qla_host {
struct srb *status_srb;
};
+struct qla4xxx_bsg_cmd {
+ uint32_t cmd;
+ uint32_t sub_cmd;
+ uint32_t data_len;
+ uint32_t instance;
+};
+
+enum ql4_bsg_vendor_priv_cmd {
+ QL4_GET_DATA,
+ QL4_SET_DATA,
+ QL4_RESTORE_FACTORY_DEF,
+ QL4_DISABLE_ACB,
+};
+
+enum ql4_get_data {
+ QL4_GET_FLASH,
+ QL4_GET_DDB_DEF,
+ QL4_GET_DDB,
+ QL4_GET_IFCB_DEF,
+ QL4_GET_IFCB,
+ QL4_GET_ACB,
+ QL4_GET_ISCSI_STAT,
+};
+
+enum ql4_set_data {
+ QL4_SET_FLASH,
+ QL4_SET_DDB,
+ QL4_SET_IFCB,
+ QL4_SET_ACB,
+ QL4_RST_ISCSI_STAT,
+};
+
static inline int is_qla4010(struct scsi_qla_host *ha)
{
return ha-pdev-device == PCI_DEVICE_ID_QLOGIC_ISP4010;
diff --git a/drivers/scsi/qla4xxx/ql4_glbl.h b/drivers/scsi/qla4xxx/ql4_glbl.h
index 96ebfb0..b5f3178 100644
--- a/drivers/scsi/qla4xxx/ql4_glbl.h
+++ b/drivers/scsi/qla4xxx/ql4_glbl.h
@@ -34,6 +34,24 @@ int qla4xxx_get_flash(struct scsi_qla_host * ha, dma_addr_t
dma_addr,
int qla4xxx_get_firmware_status(struct scsi_qla_host * ha);
int qla4xxx_get_firmware_state(struct scsi_qla_host * ha);
int qla4xxx_initialize_fw_cb(struct scsi_qla_host * ha);
+int qla4xxx_get_default_ddb(struct scsi_qla_host *ha,
+ dma_addr_t dma_addr);
+int qla4xxx_set_flash(struct scsi_qla_host *ha, dma_addr_t dma_addr,
+ uint32_t offset, uint32_t option, uint32_t len);
+int qla4xxx_get_acb(struct scsi_qla_host *ha, struct qla4xxx_bsg_cmd
vendor_cmd,
+ dma_addr_t data_dma);
+int qla4xxx_bsg_get_ifcb(struct scsi_qla_host *ha, uint32_t sub_cmd,
+dma_addr_t data_dma);
+int qla4xxx_set_ifcb(struct scsi_qla_host *ha, dma_addr_t data_dma);
+int qla4xxx_set_acb(struct scsi_qla_host *ha, uint32_t instance, uint32_t
acb_len,
+ dma_addr_t data_dma);
+int qla4xxx_restore_factory_defaults(struct scsi_qla_host *ha,
+ struct iscsi_bsg_job *job);
+int qla4xxx_ping(struct iscsi_bsg_job *job);
+int qla4xxx_rst_iscsi_stat(struct scsi_qla_host *ha, uint32_t device_index);
+int qla4xxx_get_iscsi_stat(struct scsi_qla_host *ha, uint32_t device_index,
+ dma_addr_t data_dma);
+int
Re: Non-news on HP MPX100
On Nov 12, 2009, at 12:17 AM, 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. So have you tried enabling CHAP and it does not work ? If you can provide more details I can work with the group who is responsible for this product and help try to address it. Thanks Ravi 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... --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
