Re: [PATCH 3/3] bnx2i: Add bnx2i iSCSI driver.
On Tue, 2008-05-27 at 07:38 -0700, Roland Dreier wrote: 'bnx2id' is the user component in this solution. bnx2id daemon uses socket calls to bind tcp ports in high range and hands them over to driver. This is how iscsi driver tries to solve tcp port collision issue. User daemon communicates with the driver using sysfs and tcp port related functions are bnx2i_read_tcp_portd_*/bnx2i_write_tcp_portd_* (reference: bnx2i_sysfs.c) So you are creating sockets just to reserve TCP ports to avoid host stack clashes with your offload engine? Wasn't this approach strongly rejected (in the context of iWARP) in the past? We're doing it in userspace, so I don't if that makes it any better or any worse. Roland, what do you suggest? We can do it like cma_alloc_any_port() in cma.c. --~--~-~--~~~---~--~~ 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: [PATCH 1/3] bnx2: Add support for CNIC driver.
On Thu, May 22, 2008 at 09:52:48PM -0700, Michael Chan wrote: Paul E. McKenney wrote: So if a second CNIC driver attempts to register, it gets -EBUSY or something, right? There is only one CNIC driver and it will only register once per BNX2 netdevice. I would nevertheless recommend keeping an error check... You are right. We should just unconditionally set up the IRQ information without checking for c_ops. The data structures we set up below are owned by us. OK. Hmmm You cannot even get away with sarcasm these days! ;-) Hmm, not sure what's the sarcasm. The code here is trying to set up the IRQ information so that CNIC driver can see it. Even if the CNIC driver is deregistering or was never registered, it doesn't hurt to set up that information. The sarcasm was that I really didn't expect you to simply be able to remove the check. ;-) Anyway, I'll add some comments to the code to explain this better when I respin. Very good. Could you please add a comment to that effect? Otherwise people search for what data structure is being freed up. Will do. Thanks. Sounds good! Thanx, Paul --~--~-~--~~~---~--~~ 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: [PATCH 2/3] cnic: Add CNIC driver.
+/* Tell compiler that status_blk fields can change. */
+barrier();
+if (status_idx != sblk-status_idx) {
Is a compiler barrier sufficient here? It seems an out-of-order CPU
could still mess things up, so an rmb() or smp_rmb() would be required.
--~--~-~--~~~---~--~~
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: [PATCH 2/3] cnic: Add CNIC driver.
+config CNIC +tristate Broadcom CNIC support +depends on BNX2 I suspect you'll need a depends on INET somewhere (probably here, but maybe only for the iSCSI part). - R. --~--~-~--~~~---~--~~ 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: Connection Errors
swejis wrote:
So sorry for the delay but I have not been able to reboot the machine
until now. Still I had no success getting your test-version to write
more debug info into the logs. I therefor downloaded and compiled the
latest semi-stable version I found meaning 2.0-869.2. When not this
version either wrote any debug-info I started to look around and
realized the kernel modules where far older than expected. It seem
even though I have not installed anything related to open-iscsi suse
still ships the kernel-modules of open-iscsi. I think this cause the
install_kernel function to skip installing the modules and only return
kernel is up to date, anyway after I manually copied the kernel
modules and fired up iscsi.. finally I can see more info in the the
logs. The messages file is found here: http://www.wehay.com/messages.gz
and contains two connections errors.
Ok, could you run this patch over 2.0-869.2. You do not have to compile
it with the DEBUG options. I added some more debug printks in the places
that are interesting.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
--- open-iscsi-2.0-869.2/kernel/libiscsi.c 2008-05-08 19:53:48.0 -0500
+++ open-iscsi-2.0-869.2.work/kernel/libiscsi.c 2008-05-27 13:57:21.0 -0500
@@ -319,8 +319,10 @@ void iscsi_free_mgmt_task(struct iscsi_c
if (conn-login_mtask == mtask)
return;
- if (conn-ping_mtask == mtask)
+ if (conn-ping_mtask == mtask) {
+ printk(KERN_ERR freeing ping mtask %lu\n, jiffies);
conn-ping_mtask = NULL;
+ }
__kfifo_put(conn-session-mgmtpool.queue,
(void*)mtask, sizeof(void*));
}
@@ -479,8 +481,10 @@ static void iscsi_send_nopout(struct isc
struct iscsi_nopout hdr;
struct iscsi_mgmt_task *mtask;
- if (!rhdr conn-ping_mtask)
+ if (!rhdr conn-ping_mtask) {
+ printk(KERN_ERR mtask running %lu\n, conn-last_ping);
return;
+ }
memset(hdr, 0, sizeof(struct iscsi_nopout));
hdr.opcode = ISCSI_OP_NOOP_OUT | ISCSI_OP_IMMEDIATE;
@@ -1381,13 +1385,13 @@ static void iscsi_check_transport_timeou
if (time_before_eq(last_recv + recv_timeout, jiffies)) {
/* send a ping to try to provoke some traffic */
- debug_scsi(Sending nopout as ping on conn %p\n, conn);
+ printk(KERN_ERR Sending nopout as ping on conn %p\n, conn);
iscsi_send_nopout(conn, NULL);
next_timeout = conn-last_ping + (conn-ping_timeout * HZ);
} else
next_timeout = last_recv + recv_timeout;
- debug_scsi(Setting next tmo %lu\n, next_timeout);
+ printk(KERN_ERR Setting next tmo %lu\n, next_timeout);
mod_timer(conn-transport_timer, next_timeout);
done:
spin_unlock(session-lock);
Re: [PATCH] change iscsi discovery on suse's initd
Amir Mehler wrote: Amir Mehler wrote: Hello, On open-iscsi, from April 2008 and on, when performing: (on suse) /etc/init.d/open-iscsi start a discovery is done in line 126: iscsiadm -m discovery -t st -p $TARGET_ADDR /dev/null 21 This line, and others, were added by Hannes Reinecke on Apr 09 2008. The problem with this discovery is that it modifies old session parameters of the nodes. two important session parameters change: iface.transport_name = tcp (was iser after first discovery) node.conn[0].startup = manual (was automatic after first discovery) I do not understand why Hannes used exactly this kind of discovery. when I replaced the original line with this one it solved the problem I had: iscsi_discovery $TARGET_ADDR /dev/null 21 does this change harm the original purpose of the discovery? if it does please explain, otherwise I would like to suggest the patch below. (maybe we can add something to the iscsi_discovery script to make up for it?) Thank you, Amir. The suse init.d file runs discovery via iscsiadm. This causes changes in existing iscsi node parameters. Using iscsi_discovery solves this problem. Mike, if you can take a look, I would to hear your opinion about this. Thanks, Amir. I do not really touch Hannes script unless I am updating it. I am not even sure if suse distributes iscsi_discovery? I ccd Hannes so he could make the call. However, if you do not want to overwrite existing records you can do iscsiadm -m discovery -t st -p ip:port [-o new | -o delete | -o update ] You can actually pass in multiple operations so if you wanted to just add and delete nodes you can do iscsiadm -m discovery -t st -p ip:port -o new -o delete existing records will not get changed. --~--~-~--~~~---~--~~ 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 mike,This time you hit the Bulls eye. So only way(from initiators side) to successfully relogin to blocked target was increasing timeout value which i tried. Now we have to change the IET code to allow relogin.right? IET people are not really responding to my posts.Do you have any vague idea what things should be changed. I do not think IET needs any changes. If I restart IET, it just lets me log back in with no changes. Or if I do /etc/init.d/iscsi-target stop wait a long time /etc/init.d/iscsi-target start the initiator logs back in. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Design Questions
Hi Group! First of all: I've done my research in the eMail Archives before deciding to disturb in here. Maybe I'm not googling for the perfect keyword set. Anyway, here's my question: I have: * a PowerEdge 2950 with two nics with 4 ports total (e1000 and broadcom). * a MD3000i PowerVault * Vmware Server running on the poweredge. I'm storing virtual machines in /vmstore (a big partition on the poweredge's own RAID-5 virtual disk). The local storage is for the OS and applications. Not the data. So, the obvious question here: I want to store the data in the SAN. Should I get my sessions running in the host, or inside each virtual machine? Also, is it OK to use multi path (dual path) using one broadcom port, and one e1000 port (instead of using the two ports of the same nic)? Any hints? Suggestions? Thanks a LOT. I'm very new to this, but I'm doing my best effort. --~--~-~--~~~---~--~~ 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: [PATCH 3/3] bnx2i: Add bnx2i iSCSI driver.
On Tue, 2008-05-27 at 12:52 -0700, David Miller wrote: From: Roland Dreier [EMAIL PROTECTED] Date: Tue, 27 May 2008 07:38:19 -0700 So you are creating sockets just to reserve TCP ports to avoid host stack clashes with your offload engine? Wasn't this approach strongly rejected (in the context of iWARP) in the past? Yes, it was, and likewise similar hacks in other areas will be rejected similarly. If we change the implementation to use a separate IP address and separate MAC address for iSCSI, will it be acceptable? The iSCSI IP/MAC addresses will be unknown to the Linux TCP stack and so no sharing of the 4-tuple space will be needed. The patches will be very similar, except that all inet calls and notifiers will be removed. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Help! On Ubuntu or RHEL 5.1 client I always get: iscsiadm: discovery session to [IP] received unexpected opcode 0x20
As the title says, I get this error when I try to find iscsi targets. I cannot for the life of me get open-iscsi to work and always get this error. I am trying to connect to a working sanfly iscsi target from either RHEL 5.1 client or the latest ubuntu. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
upgrade from 2.0.865 to 2.0.869
Hello, I have already installed 2.0.865 and want to install the latest release 2.0.869. Which files should I remove from the previous installation ? Thanks in advance for your help --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
