Re: Maximum LUN support
Hi, After a little more experimenting, I think this iscsi-targets fault. I agree this does not have any relevance to the open-iscsi code, nevertheless, I though it would nice to post here as well to keep this post updated. Do apologize if that is against the principles of this mailing-list. Interesting. That does seem like a limitation in that code. Did you try to change the INCOMING_BUFSIZE to a higher value? Or to decrease the length of the target's name? So: iqn.2008.com:t1, iqn.2008.com:t2, and so on? As suggested by someone on this list earlier, I tried to reduce the target name and instantly I was able to add (made discoverable) more of the devices at the initiator side. Initially the target names consisted of about 44 characters (when only 89 devices were getting transferred across to initiator). I changed the name such that it took about 15 characters - and this time I was able to add 139 devices with the same configuration of IETd. :) Also, I changed a variable INCOMING_BUFFER (again, as suggested by Konrad) to 16384 - then I was able to add (discoverable on initiator) 179 devices with target name consisting of 44 chars. :) By add I mean, rest all the devices defined at target were being dropped by target and not sent to initiator. I had a target config list of about 1000 soft links to a valid device. On Wed, May 21, 2008 at 12:28 AM, Mike Christie [EMAIL PROTECTED] wrote: If you are using 869.* then the problem is most likely on the IET side. Like I said before I think you need to upgrade. I had the same problem when I was testing my fixes for lots of targets support. This would certainly mean that iscsi-target is playing a game with me :D Regards Shreyansh --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: recommended volume size
In thinking further about this, the application pool could scale up to 40 TB. Is a 40 TB volume out of reality? On May 21, 11:51 am, Terry [EMAIL PROTECTED] wrote: Hello, I am going to be connecting to an equallogic san using RHEL5 x86_64 and serving up NFS volumes. I don't have any requirement as to the size on the application side. I am thinking 4TB volumes but anyone have any advice in this area? The data will be a lot of small files mostly so I'll be sticking to a 4k block size with ext3. Thanks! --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Compiling openiscsi against self-compiled-xen ?
Hi Tomasz (or maybe other who can help ??) could you compile openiscsi for a self-compiled xen ? Could your please so kind and tell me, how to modify the xen-source-directory structure and/or the openiscsi-source-directory structure (copy/move/edit) to build openiscsi from scratch. For compile xen, i did hg clone http://xenbits.xensource.com/xen-3.2-testing.hg cd xen* make -j8 world make -j8 install make -j9 linux-2.6-xen-install mkinitrd /boot/initrd-2.6.18.8-xen.img 2.6.18.8-xen # and edit /boot/grub/menu.lst But how can i compile openiscsi ? wget http://www.open-iscsi.org/bits/open-iscsi-2.0-869.tar.gz # tar xfvz open-iscsi-2.0-869.tar.gz cd open-iscsi-2.0-869 make KSRC=/root/xen-3.2.1/xen3.2.1/build-linux-2.6.18-xen_x86_64 # or make # or make install # or make KSRC=/root/xen-3.2.1/linux-2.6.18-xen.hg does not work ... because of the 2-tree-xen-directory structure ... Merci for your information regards Danny On 23 Mai 2007, 19:08, Tomasz Chmielewski [EMAIL PROTECTED] wrote: Mike Christie schrieb: Tomasz Chmielewski wrote: Tomasz Chmielewski schrieb: I'm having hard time trying to compile Open-iSCSI (2.0-754) withXen3.1 (source package, 2.6.18 kernel). The kernel part build of Open-iSCSI complains about kernel not supported - which one can understand, asXenhas a bit curious build system and several separated kernel sources. Does anyone have a short recipe on how to compile Open-iSCSI withXen3.1? I looked at the kernel/Makefile, and it looks like it would be enough to copy all kernel/2.6.16-2.6.19/*.c and kernel/2.6.16-2.6.19/*.h files intoXen3.1 kernel source to integrate it permanently - am I correct? It might not work because the sources in the open-iscsi.org/svn release are modified to use the headers from the release and not the ones with the kernel you are building against. And I think the include statements that are coded will not pick things up correctly if you just move the files around. Yes, I also had to copy the content of include/ directory to drivers/scsi/, and modify one file there. I thinkXencompiled, I still have to check tomorrow if it works (Xen 3.1 uses kernel 2.6.18). -- Tomasz Chmielewskihttp://wpkg.org --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: recommended volume size
On Wed, May 21, 2008 at 10:18:22AM -0700, Terry wrote: In thinking further about this, the application pool could scale up to 40 TB. Is a 40 TB volume out of reality? On May 21, 11:51 am, Terry [EMAIL PROTECTED] wrote: Hello, I am going to be connecting to an equallogic san using RHEL5 x86_64 and serving up NFS volumes. I don't have any requirement as to the size on the application side. I am thinking 4TB volumes but anyone have any advice in this area? The data will be a lot of small files mostly so I'll be sticking to a 4k block size with ext3. Check RHEL releasenotes or other information for supported volume/filesystem max sizes. I think RHEL5 with ext3 supports max 16 TB filesystems. Also note that you can't use normal partition tables because they're limited to 2 TB. So you have to use LVM on raw volumes/luns or then GPT partition tables. -- Pasi --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: Should connection restored?
HIMANSHU wrote: Yeah..I am using IET. I was getting session recovery timed out after 120 secs when it was 120. Now as it is 86400,I never observed after 86400sec. that session recovery timed out after 86400 secs. Otherwise is it NORMAL behavior of IET that the connection is lost of existing targets after restarting target daemon? I am not sure what you mean by connection is lost. If you mean that you see those 1011 errors then yes. When IET and open-iscsi are running normally we have a tcp connection to the IET. When you reboot IET, it closes it, so we try to reconnect. When we detect the problem we spit out an error 1011. If a nop/ping times out first though you might see a slightly different error, but normally when the tcp connection changes state we are notified and you see 1011 errors. If when you say the connection is lost is that we cannot do disk IO and you get FS errors and the iscsi session and its disks are basically dead and unusable because they only spit out errors then it is sort of expected :) We will not begin to fail IO until that replacement/recovery timer expires. So if you reboot IET and it takes longer than that timer to relogin then you will get FS/IO/SCSI/BLOCK errors. In Open-e,it was the case that disk blocked only some time,after it was recovered. But in my case,it is blocked forever. When you say blocked, do you mean if you run iscsiadm -m session -P 3 that the disks state says blocked or do you mean something else? Like I said before, when the connection is detected we block the scsi disks. When we are logged back or if the replacement/recovery timer fires we unblock them. If we are logged in we execte IO. If we are not then we fail IO. Open-e might changed IET to suit this persistent connection or they might be using something else?Thoughts - --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
compilation error on SLES10SP2
I go this message wihle compiling 869.2 I didn't had problem with previous kernel version 865.4 865.8 865.12 865.15 have the same result Any ideas ? node1:/download/open-iscsi-2.0-869.2 # uname -a Linux node1 2.6.16.60-0.23-xen #1 SMP Thu May 15 06:38:31 UTC 2008 x86_64 x86_64 x86_64 GNU/Linux node1:/download/open-iscsi-2.0-869.2 # node1:/download/open-iscsi-2.0-869.2 # make KSRC=/usr/src/linux KBUILD_OUTPUT=/usr/src/linux-obj/x86_64/xen/ cp 2.6.14-19_compat.patch has_14to19_patch ln -s has_14to19_patch cur_patched make -C /usr/src/linux M=`pwd` KBUILD_OUTPUT=/usr/src/linux-obj/x86_64/ xen/ V=0 modules make[2]: Entering directory `/usr/src/linux-2.6.16.60-0.23' CC [M] /download/open-iscsi-2.0-869.2/kernel/scsi_transport_iscsi.o In file included from /download/open-iscsi-2.0-869.2/kernel/ scsi_transport_iscsi.h:33, from /download/open-iscsi-2.0-869.2/kernel/ scsi_transport_iscsi.c:33: /download/open-iscsi-2.0-869.2/kernel/iscsi_compat.h:73: error: redefinition of ‘struct hash_desc’ /download/open-iscsi-2.0-869.2/kernel/iscsi_compat.h:79: error: redefinition of ‘crypto_hash_init’ /usr/src/linux-2.6.16.60-0.23/include/linux/crypto.h:949: error: previous definition of ‘crypto_hash_init’ was here /download/open-iscsi-2.0-869.2/kernel/iscsi_compat.h: In function â €˜crypto_hash_init’: /download/open-iscsi-2.0-869.2/kernel/iscsi_compat.h:80: error: implicit declaration of function ‘crypto_digest_init’ /download/open-iscsi-2.0-869.2/kernel/iscsi_compat.h: At top level: /download/open-iscsi-2.0-869.2/kernel/iscsi_compat.h:87: error: redefinition of ‘crypto_hash_digest’ /usr/src/linux-2.6.16.60-0.23/include/linux/crypto.h:968: error: previous definition of ‘crypto_hash_digest’ was here /download/open-iscsi-2.0-869.2/kernel/iscsi_compat.h: In function â €˜crypto_hash_digest’: /download/open-iscsi-2.0-869.2/kernel/iscsi_compat.h:88: error: implicit declaration of function ‘crypto_digest_digest’ /download/open-iscsi-2.0-869.2/kernel/iscsi_compat.h: At top level: /download/open-iscsi-2.0-869.2/kernel/iscsi_compat.h:95: error: redefinition of ‘crypto_hash_update’ /usr/src/linux-2.6.16.60-0.23/include/linux/crypto.h:956: error: previous definition of ‘crypto_hash_update’ was here /download/open-iscsi-2.0-869.2/kernel/iscsi_compat.h: In function â €˜crypto_hash_update’: /download/open-iscsi-2.0-869.2/kernel/iscsi_compat.h:96: error: implicit declaration of function ‘crypto_digest_update’ /download/open-iscsi-2.0-869.2/kernel/iscsi_compat.h: At top level: /download/open-iscsi-2.0-869.2/kernel/iscsi_compat.h:101: error: redefinition of ‘crypto_hash_final’ /usr/src/linux-2.6.16.60-0.23/include/linux/crypto.h:961: error: previous definition of ‘crypto_hash_final’ was here /download/open-iscsi-2.0-869.2/kernel/iscsi_compat.h: In function â €˜crypto_hash_final’: /download/open-iscsi-2.0-869.2/kernel/iscsi_compat.h:102: error: implicit declaration of function ‘crypto_digest_final’ /download/open-iscsi-2.0-869.2/kernel/iscsi_compat.h: At top level: /download/open-iscsi-2.0-869.2/kernel/iscsi_compat.h:108: error: conflicting types for ‘crypto_alloc_hash’ /usr/src/linux-2.6.16.60-0.23/include/linux/crypto.h:886: error: previous definition of ‘crypto_alloc_hash’ was here /download/open-iscsi-2.0-869.2/kernel/iscsi_compat.h:114: error: conflicting types for ‘crypto_free_hash’ /usr/src/linux-2.6.16.60-0.23/include/linux/crypto.h:900: error: previous definition of ‘crypto_free_hash’ was here /download/open-iscsi-2.0-869.2/kernel/scsi_transport_iscsi.c: In function ‘__iscsi_unblock_session’: /download/open-iscsi-2.0-869.2/kernel/scsi_transport_iscsi.c:381: warning: unused variable ‘ihost’ make[4]: *** [/download/open-iscsi-2.0-869.2/kernel/ scsi_transport_iscsi.o] Error 1 make[3]: *** [_module_/download/open-iscsi-2.0-869.2/kernel] Error 2 make[2]: *** [modules] Error 2 make[2]: Leaving directory `/usr/src/linux-2.6.16.60-0.23' make[1]: *** [all] Error 2 make[1]: Leaving directory `/download/open-iscsi-2.0-869.2/kernel' make: *** [all] Error 2 node1:/download/open-iscsi-2.0-869.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: compilation error on SLES10SP2
hg wrote:
I go this message wihle compiling 869.2
I didn't had problem with previous kernel
version 865.4 865.8 865.12 865.15 have the same result
Any ideas ?
I think you need the attached patch. I have not merged it because it
ends up breaking other builds. We need someone with some makefile and
scripting skills to fix it properly.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---
---BeginMessage---
These are some Makefile updates to build on system without
kernel-sources installed.
And cleanups to have it build properly on SUSE systems.
Signed-off-by: Hannes Reinecke [EMAIL PROTECTED]
---
Makefile|9 ++---
kernel/Makefile | 21 +
usr/Makefile|4 +++-
3 files changed, 26 insertions(+), 8 deletions(-)
diff --git a/Makefile b/Makefile
index 7661daa..e6dc435 100644
--- a/Makefile
+++ b/Makefile
@@ -32,9 +32,12 @@ all:
@echo
@echo Compilation completeOutput file
@echo ---
- @echo Built iSCSI Open Interface module:
kernel/scsi_transport_iscsi.ko
- @echo Built iSCSI library module: kernel/libiscsi.ko
- @echo Built iSCSI over TCP kernel module: kernel/iscsi_tcp.ko
+ @if [ -f kernel/scsi_transport_iscsi.ko ] ; then \
+ echo Built iSCSI Open Interface module:
kernel/scsi_transport_iscsi.ko; fi
+ @if [ -f kernel/libiscsi.ko ] ; then \
+ echo Built iSCSI library module: kernel/libiscsi.ko; fi
+ @if [ -f kernel/iscsi_tcp.ko ] ; then \
+ echo Built iSCSI over TCP kernel module: kernel/iscsi_tcp.ko; fi
@echo Built iSCSI daemon: usr/iscsid
@echo Built management application: usr/iscsiadm
@echo
diff --git a/kernel/Makefile b/kernel/Makefile
index 7281a60..8209473 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -32,11 +32,16 @@ V ?= 0
# eg to compile for a kernel that you aren't currently running
KERNELRELEASE ?= $(shell uname -r)
KSRC ?= /lib/modules/$(KERNELRELEASE)/build
+KSRC := $(shell test -f $(KSRC)/Makefile || echo )
KBUILD_OUTPUT ?=
# this is the basic Kbuild invocation, just append your make target
KBUILD_BASE = +$(MAKE) -C $(KSRC) M=`pwd` KBUILD_OUTPUT=$(KBUILD_OUTPUT)
$(KARCH) V=$(V)
-all: kernel_check
+all: kernel_src
+
+kernel_src: $(shell test -n $(KSRC) echo has_kernel_src)
+
+has_kernel_src: kernel_check
$(KBUILD_BASE) modules
# BEGIN code for kernel_check and source patching
@@ -59,9 +64,11 @@ cur_patched=cur_patched
# check to see if code is unpatched
unpatch_code=$(shell test -e $(cur_patched) echo do_unpatch_code )
-KSUBLEVEL = $(shell cat $(KSRC)/Makefile | awk -F= '/^SUBLEVEL =/ {print $$2}'
| \
+KSUBLEVEL = $(shell cat $(KSRC)/Makefile 2 /dev/null | awk -F= '/^SUBLEVEL =/
{print $$2}' | \
sed 's/^[ \t]*//;s/[ \t]*$$//')
+KSUBLEVEL?=$(shell echo $(KERNELRELEASE) | sed -n
's/.\..\.\([[:digit:]]*\)\..*/\1/p')
+
KERNEL_TARGET=linux_2_6_$(KSUBLEVEL)
kernel_check: $(KERNEL_TARGET)
@@ -126,7 +133,11 @@ has_24_patch: $(24_patch)
# END code for kernel_check and source patching =
-clean: $(unpatch_code)
+clean: clean_kernel_src
+
+clean_kernel_src: $(shell test -n $(KSRC) echo has_clean_kernel_src)
+
+has_clean_kernel_src: $(unpatch_code)
$(KBUILD_BASE) clean
rm -f Module.symvers
@@ -165,7 +176,9 @@ ko = $(patsubst %.o,%.ko,$(obj-m))
$(ko): all
# now the actual command
-install_kernel: $(ko)
+install_kernel: $(shell test -n $(KSRC) echo install_kernel_obj);
+
+install_kernel_obj: $(ko)
$(KBUILD_BASE) modules_install INSTALL_MOD_DIR=$(INSTALL_MOD_DIR)
INSTALL_MOD_PATH=$(INSTALL_MOD_PATH)
dpkg_divert:
diff --git a/usr/Makefile b/usr/Makefile
index 358d62c..42a8788 100644
--- a/usr/Makefile
+++ b/usr/Makefile
@@ -7,9 +7,11 @@ OSNAME=$(shell uname -s)
KERNELRELEASE ?= $(shell uname -r)
KSRC ?= /lib/modules/$(KERNELRELEASE)/build
-KSUBLEVEL=$(shell cat $(KSRC)/Makefile | awk -F= '/^SUBLEVEL =/ {print $$2}' |
\
+KSUBLEVEL=$(shell cat $(KSRC)/Makefile 2 /dev/null | awk -F= '/^SUBLEVEL =/
{print $$2}' | \
sed 's/^[ \t]*//;s/[ \t]*$$//')
+KSUBLEVEL?=$(shell echo $OSNAME | sed -n 's/.\..\.\([[:digit:]]*\)\..*/\1/p')
+
ifeq ($(OSNAME),Linux)
ifeq ($(KSUBLEVEL),11)
IPC_CFLAGS=-DNETLINK_ISCSI=12 -D_GNU_SOURCE
--
1.5.3.4
---End Message---
[PATCH 0/3] bnx2: Add iSCSI support.
Please review our new version of the iSCSI drivers for Broadcom BNX2 devices. We've reworked the bnx2i driver quite a bit with the help of Mike Christie in the last few months. It is now one scsi host per adapter and has a single iscsi transport name. It is also more tightly coupled to scsi_transport_iscsi and libiscsi. The bnx2i driver depends on the latest patches in Mike Christie's git tree. Thanks. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
[PATCH 1/3] bnx2: Add support for CNIC driver.
Add interface for a separate CNIC driver to drive additional rings
and other resources for iSCSI.
A probe function is exported so that the CNIC driver can get
information about bnx2 devices. After calling the probe function,
the CNIC driver can then register with the BNX2 driver before
initializing the hardware for iSCSI.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
---
drivers/net/bnx2.c | 202 ++--
drivers/net/bnx2.h | 21 ++
2 files changed, 218 insertions(+), 5 deletions(-)
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index b32d227..ba12daf 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -48,6 +48,11 @@
#include linux/cache.h
#include linux/zlib.h
+#if defined(CONFIG_CNIC) || defined(CONFIG_CNIC_MODULE)
+#define BCM_CNIC 1
+#include cnic_drv.h
+#endif
+
#include bnx2.h
#include bnx2_fw.h
#include bnx2_fw2.h
@@ -302,6 +307,170 @@ bnx2_ctx_wr(struct bnx2 *bp, u32 cid_addr, u32 offset,
u32 val)
spin_unlock_bh(bp-indirect_lock);
}
+#ifdef BCM_CNIC
+static int
+bnx2_drv_ctl(struct net_device *dev, struct drv_ctl_info *info)
+{
+ struct bnx2 *bp = netdev_priv(dev);
+ struct drv_ctl_io *io = info-data.io;
+
+ switch (info-cmd) {
+ case DRV_CTL_IO_WR_CMD:
+ bnx2_reg_wr_ind(bp, io-offset, io-data);
+ break;
+ case DRV_CTL_IO_RD_CMD:
+ io-data = bnx2_reg_rd_ind(bp, io-offset);
+ break;
+ case DRV_CTL_CTX_WR_CMD:
+ bnx2_ctx_wr(bp, io-cid_addr, io-offset, io-data);
+ break;
+ default:
+ return -EINVAL;
+ }
+ return 0;
+}
+
+static void bnx2_setup_cnic_irq_info(struct bnx2 *bp)
+{
+ struct cnic_ops *c_ops;
+ struct cnic_eth_dev *cp = bp-cnic_eth_dev;
+ struct bnx2_napi *bnapi = bp-bnx2_napi[0];
+ int sb_id;
+
+ rcu_read_lock();
+ c_ops = rcu_dereference(bp-cnic_ops);
+ if (!c_ops)
+ goto done;
+
+ if (bp-flags BNX2_FLAG_USING_MSIX) {
+ cp-drv_state |= CNIC_DRV_STATE_USING_MSIX;
+ bnapi-cnic_present = 0;
+ sb_id = BNX2_CNIC_VEC;
+ cp-irq_arr[0].irq_flags |= CNIC_IRQ_FL_MSIX;
+ } else {
+ cp-drv_state = ~CNIC_DRV_STATE_USING_MSIX;
+ bnapi-cnic_tag = bnapi-last_status_idx;
+ bnapi-cnic_present = 1;
+ sb_id = 0;
+ cp-irq_arr[0].irq_flags = !CNIC_IRQ_FL_MSIX;
+ }
+
+ cp-irq_arr[0].vector = bp-irq_tbl[sb_id].vector;
+ cp-irq_arr[0].status_blk = (void *) ((unsigned long) bp-status_blk +
+ (BNX2_SBLK_MSIX_ALIGN_SIZE * sb_id));
+ cp-irq_arr[0].status_blk_num = sb_id;
+ cp-num_irq = 1;
+
+done:
+ rcu_read_unlock();
+}
+
+static int bnx2_register_cnic(struct net_device *dev, struct cnic_ops *ops,
+ void *data)
+{
+ struct bnx2 *bp = netdev_priv(dev);
+ struct cnic_eth_dev *cp = bp-cnic_eth_dev;
+
+ if (ops == NULL)
+ return -EINVAL;
+
+ if (!try_module_get(ops-cnic_owner))
+ return -EBUSY;
+
+ bp-cnic_data = data;
+ rcu_assign_pointer(bp-cnic_ops, ops);
+
+ cp-num_irq = 0;
+ cp-drv_state = CNIC_DRV_STATE_REGD;
+
+ bnx2_setup_cnic_irq_info(bp);
+
+ return 0;
+}
+
+static int bnx2_unregister_cnic(struct net_device *dev)
+{
+ struct bnx2 *bp = netdev_priv(dev);
+ struct bnx2_napi *bnapi = bp-bnx2_napi[0];
+ struct cnic_eth_dev *cp = bp-cnic_eth_dev;
+
+ cp-drv_state = 0;
+ module_put(bp-cnic_ops-cnic_owner);
+ bnapi-cnic_present = 0;
+ rcu_assign_pointer(bp-cnic_ops, NULL);
+ synchronize_rcu();
+ return 0;
+}
+
+struct cnic_eth_dev *bnx2_cnic_probe(struct net_device *dev)
+{
+ struct bnx2 *bp = netdev_priv(dev);
+ struct cnic_eth_dev *cp = bp-cnic_eth_dev;
+
+ cp-chip_id = bp-chip_id;
+ cp-pdev = bp-pdev;
+ cp-io_base = bp-regview;
+ cp-drv_ctl = bnx2_drv_ctl;
+ cp-drv_register_cnic = bnx2_register_cnic;
+ cp-drv_unregister_cnic = bnx2_unregister_cnic;
+
+ return cp;
+}
+EXPORT_SYMBOL(bnx2_cnic_probe);
+
+static void
+bnx2_cnic_stop(struct bnx2 *bp)
+{
+ struct cnic_ops *c_ops;
+ struct cnic_ctl_info info;
+
+ rcu_read_lock();
+ c_ops = rcu_dereference(bp-cnic_ops);
+ if (c_ops) {
+ info.cmd = CNIC_CTL_STOP_CMD;
+ c_ops-cnic_ctl(bp-cnic_data, info);
+ }
+ rcu_read_unlock();
+}
+
+static void
+bnx2_cnic_start(struct bnx2 *bp)
+{
+ struct cnic_ops *c_ops;
+ struct cnic_ctl_info info;
+
+ rcu_read_lock();
+ c_ops = rcu_dereference(bp-cnic_ops);
+ if (c_ops) {
+ if (!(bp-flags BNX2_FLAG_USING_MSIX)) {
+ struct bnx2_napi *bnapi = bp-bnx2_napi[0];
+
+
