Re: [PATCH] iscsi_tcp: Evaluate socket state in data_ready()

2009-07-28 Thread Hannes Reinecke
Hi Mike, Mike Christie wrote: On 07/27/2009 06:22 AM, Hannes Reinecke wrote: The network core will call state_change() callback prior to the data_ready() callback, which might cause us to lose a connection state change. So we have to evaluate the socket state at the end of the data_ready()

[PATCH] iscsi_tcp: Evaluate socket state in data_ready()

2009-07-28 Thread Hannes Reinecke
The network core will call the state_change() callback prior to the data_ready() callback, which might cause us to lose a connection state change. So we have to evaluate the socket state at the end of the data_ready() callback, too. Signed-off-by: Hannes Reinecke h...@suse.de ---

LUN Reset TMF and R2T

2009-07-28 Thread Hannes Reinecke
Hi all, when my device-reset testcase I've come across this: Jul 28 12:46:08 tyne kernel: session1: iscsi_eh_device_reset LU Reset [sc 8800731e9480 lun 6] Jul 28 12:46:08 tyne kernel: session1: iscsi_exec_task_mgmt_fn tmf set timeout Jul 28 12:46:08 tyne kernel: session1: mgmtpdu [op

Re: New iSCSI configuration

2009-07-28 Thread Clint
Going to try to replay to this again... I am stopped now with a message 12 - iSCSI driver not found I performed the yum install of the iscsi-initiator-utils and service iscsi starts clean with the only message of No records found! Here is what I have on boot now: [r...@iscsi ~]# service iscsi

Re: [PATCH] cnic: Fix ISCSI_KEVENT_IF_DOWN message handling.

2009-07-28 Thread David Miller
From: Michael Chan mc...@broadcom.com Date: Wed, 22 Jul 2009 20:01:55 -0700 When a net device goes down or when the bnx2i driver is unloaded, the code was not generating the ISCSI_KEVENT_IF_DOWN message properly and this could cause the userspace driver to crash. This is fixed by sending

Re: open-iscsi 868 chap on el5 ( Centos 5.3 and RedHat 5.2 )

2009-07-28 Thread Mike Christie
On 07/28/2009 04:08 AM, Joris wrote: error from /var/log/messages is at the bottom On 27 jul, 23:29, Mike Christiemicha...@cs.wisc.edu wrote: On 07/24/2009 01:05 PM, Joris wrote: Hi Mike, In the meantime i've kind of got it to work but i feel like acting blind. I've not followed any of

Re: open-iscsi 868 chap on el5 ( Centos 5.3 and RedHat 5.2 )

2009-07-28 Thread Mike Christie
Joris wrote: Is there no way at all to kill an initiator session manually ? One must be able to reset a session from the client side i figure. iscsiadm -m session -R $SID -u in newer tools iscsiadm -m node -T target -p ip -u It is quite frustrating there's so little to read on open-iscsi

Re: New iSCSI configuration

2009-07-28 Thread Mike Christie
Clint wrote: Going to try to replay to this again... I am stopped now with a message 12 - iSCSI driver not found I performed the yum install of the iscsi-initiator-utils and service iscsi starts clean with the only message of No records found! That just means you have not run the

Re: New iSCSI configuration

2009-07-28 Thread Clint Tinsley
I have it working now. I am guessing that when I did the Tarball install for open-iscsi, it polluted the CentOS kernel drivers. Since this was a fresh build, I just did a new install of CentOS 5.3, followed your instructions and everything just worked. Life is good and I learned alot along the

Re: [PATCH] iscsi_tcp: Evaluate socket state in data_ready()

2009-07-28 Thread Mike Christie
Hannes Reinecke wrote: The network core will call the state_change() callback prior to the data_ready() callback, which might cause us to lose a connection state change. So we have to evaluate the socket state at the end of the data_ready() callback, too. Signed-off-by: Hannes Reinecke

Unable to discover targets after initrd boot because iscsid database is lost.

2009-07-28 Thread Matthew Schumacher
Hello Group, I'm working out the config to boot a host from an iscsi target and have everything pretty much working, but once the host is up, I can't connect to any other iscsi targets. My initrd script calls the following:

Re: LUN Reset TMF and R2T

2009-07-28 Thread Mike Christie
Mike Christie wrote: The nasty problem with the code and this scenario is that we preallcoate the tasks and itts. Once iscsi_eh_device_reset returns SUCCESS and cleans up the tasks, the scsi layer can start sending us commands. We could then allocate a task/itt that was used before and

Re: Unable to discover targets after initrd boot because iscsid database is lost.

2009-07-28 Thread Mike Christie
Matthew Schumacher wrote: Hello Group, I'm working out the config to boot a host from an iscsi target and have everything pretty much working, but once the host is up, I can't connect to any other iscsi targets. My initrd script calls the following:

Re: Unable to discover targets after initrd boot because iscsid database is lost.

2009-07-28 Thread Mike Christie
On 07/28/2009 06:59 PM, Matthew Schumacher wrote: Mike Christie wrote: This is what we do in Red Hat. It is a little tricky, because when iscsid restarts it relogins into the target to make sure its state is all in sync with the kernel and session. So the network has to be up first, then