LU Reset TMF can take quite some time to abort all pending
commands. Any other TMF submitted at that time will autmatically
fail. However, there is no reason to not allow another
TMF once we received the response as the only shared resource
here is the complete callback.
Signed-off-by: Hannes
When sending data we should traverse all data-out PDUs,
otherwise the queue will stall during TMF.
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/scsi/libiscsi.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi
When checking for the SUSPEND bit we have to make sure
to transfer complete PDUs, otherwise the target will barf.
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/scsi/iscsi_tcp.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/iscsi_tcp.c b
We should be flushing the workqueue before setting the suspend
bit. If we don't a LU Reset might kill commands which are already
in the queue and waiting to be send, causing the target to barf.
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/scsi/libiscsi.c |2 +-
1 files changed
Mike Christie wrote:
Hannes Reinecke wrote:
Hi Mike,
as you might've seen, I finally found the problem for the MSA dropping
the connection. It seems that it's follows this section from the RFC:
For the LOGICAL UNIT RESET function, the target MUST behave as
dictated by the Logical
yeah, make sure you are not using your cmdns window patch, because
your patch will prevent data-outs from being sent in response to r2ts if
the window is closed.
Yes, did so. Nae bother.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de
Hannes Reinecke wrote:
Hannes Reinecke wrote:
Hi Mike,
finally I've managed to track down the lost TTT issue.
We're continuing to get responses from the target
even after we have send the TMF PDU (no surprise there).
However, the target considers all R2Ts send _before_
the tmf response
Mike Christie wrote:
On 08/03/2009 04:13 AM, Hannes Reinecke wrote:
Mike Christie wrote:
Mike Christie wrote:
On 07/31/2009 09:53 AM, Hannes Reinecke wrote:
Hmm. I must admit I'm slightly at a loss here.
I do have this function:
Did you try my second patch queue-some-io-during-tmfs2.patch
For correct TMF handling we should keep track of outstanding
TTTs; some targets will drop the connections if outstanding
TTTs are not honoured.
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/scsi/libiscsi.c |7 +++
drivers/scsi/libiscsi_tcp.c |2 +-
include/scsi
.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--~--~-~--~~~---~--~~
You received
Mike Christie wrote:
Mike Christie wrote:
Hannes Reinecke wrote:
Sigh. Why do you have to make is so complicated ...
My patch was easy and simple originally. And now this :-)
This gets really ugly if we do it in libiscsi_tcp. I moved the check to
libiscsi and I changed the abort task test
Hannes Reinecke wrote:
Hannes Reinecke wrote:
Mike Christie wrote:
Mike Christie wrote:
Hannes Reinecke wrote:
Sigh. Why do you have to make is so complicated ...
My patch was easy and simple originally. And now this :-)
This gets really ugly if we do it in libiscsi_tcp. I moved the check
Steven Hayter wrote:
On 28/07/2009 06:14 pm, Mike Christie wrote:
On 07/28/2009 06:53 AM, Hannes Reinecke wrote:
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
.
Note we're not actually interested in the outcome
of the TMF task as the I/O will be stopped
anyway even if the TMF task fails.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5
iscsi_tcp_task_xmit() doesn't check for pending TMF
tasks, so we might happily continue sending R2T data
even though we've already aborted the command.
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/scsi/libiscsi_tcp.c | 29 +
1 files changed, 29
called on it and we
are accessing a bad task.
I fully agree, this is something which shouldn't happen.
However, using this patch stops me from receiving invalid R2T PDUs.
So I can't be that far off the mark.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de
Mike Christie wrote:
Mike Christie wrote:
Mike Christie wrote:
Mike Christie wrote:
Mike Christie wrote:
Hannes Reinecke wrote:
Mike Christie wrote:
The second patch is the more important one, as it
fixes an error during LUN Reset handling in the
initiator. When sending a LUN Reset
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
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
---
drivers/scsi
this, so this is just as a
heads up that
something is awry here.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg
.
But as the latter check is far more elaborate than
the iscsi_session_chkready(), I'd advocate for just removing it.
Mike?
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409
Mike Christie wrote:
Hannes Reinecke wrote:
Mike Christie wrote:
On 07/22/2009 12:00 PM, Mike Christie wrote:
No, wrong. The check in queuecommand is by no means relevant
to the actual window.
We're checking the target window at the time queuecommand is run,
but we're _generating_
Mike Christie wrote:
Hannes Reinecke wrote:
[ .. ]
Fsck. You are correct.
But you still might be hitting a problem where the target does not like
data-outs when it closed the window. Maybe they interpreted the RFC
differently. You should ask the HP target guys for more info.
Also
the
(internal) CmdSN window
already. But if not - boom.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg
Hannes Reinecke wrote:
Mike Christie wrote:
[ .. ]
I am not sure if we should be needing this if the target is operating
within the RFC (there is one exception but I am not sure if you are
hitting it).
In 3.2.2.1, I saw this:
An iSCSI target MUST be able to handle at least one immediate
updates to follow.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg
', and 'req' parameters are just !list_empty(cmdqueue),
!list_empty(mgmtqueue), !list_empty(requeue).
(I said I'm running on an older code base).
So at this point there are _no_ requests queued.
Really curious.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de
Hannes Reinecke wrote:
Ulrich Windl wrote:
Hmm, I wonder: If every packet exchange for an iSCSI target re-triggers a
timer
that prevents NOPs from being sent/expected, the problem under heavy load
should
go away as well, right? I see little sense to send extra NOP queries when
-off-by: Hannes Reinecke h...@suse.de
---
drivers/scsi/libiscsi.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 21ed45f..ffb1338 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
, why we're starting to send PDUs with invalid
MaxCmdSN numbers ...
Apologies as I'm running on an older codebase. But the same error / 'behaviour'
is present in mainline as well.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911
longer than expected and it would be more
efficient to route the IO to another path.
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/scsi/libiscsi.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 52d876f
read that correctly and shouldn't our code actually read:
return n1 != n2 ((n1 n2 (n2 - n1 SNA32_CHECK)) ||
(n1 n2 (n1 - n2 SNA32_CHECK)));
?
Otherwise we'd be off by one, or am I missing something here?
Slightly confused,
Hannes
--
Dr. Hannes
to the RFC here.
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/scsi/libiscsi.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 716cc34..52d876f 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi
Mike Christie wrote:
On 06/24/2009 09:40 AM, Hannes Reinecke wrote:
During heavy I/O we might hit a receive timeout as the
xmitworker is still busy sending PDUs. Even as we strictly
speaking didn't receive a reply during the receive timeout,
we didn't actually gave the target a chance
failures to drop quite considerably.
However, as they interfere with error handling I'd like
to have a second or third opinion here.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5
to ensure that cmdqueue really is empty
before start sending NOPs.
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/scsi/libiscsi.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 716cc34..41bb177 100644
During heavy I/O the scsi cmd might be stuck in the cmdqueue
and hasn't even been sent at the time the command timeout
strikes. So we should be resetting the command timer here
and not aborting the command.
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/scsi/libiscsi.c |8
for this.
Well, the obvious solution here is to implement another transport module (eg
iscsi_supersockets.c) much like it's done for iSER.
The rest of the code should be sufficiently abstracted to handle it properly.
There is a reason why it's called iscsi_tcp.c ...
Cheers,
Hannes
--
Dr. Hannes
in
node.startup
and
node.conn[0].startup
sadly, the initiator would respond to both of them.
What we should do here is to enforce that both are identical.
Need to draw up a patch one day ...
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de
if SLES11's initrd image can find more than one iSCSI path?
Yes, I do :-)
I have patched the SUSE initrd to activate all network interfaces which
are configured via ifup in the running system.
You'd need the attached patch to /lib/mkinitrd to achieve this.
Cheers,
Hannes
--
Dr. Hannes Reinecke
see if I can pull it in for SLES11. Care to open a bugzilla?
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
[EMAIL PROTECTED] +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg
bugs.
If you promise to test me the script with the STP fixes I'll be willing
to add it. Sadly I don't have time currently to do any decent testing here,
but I'm always open to patches :-)
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
[EMAIL PROTECTED
a bugzilla open to get this right (Novell bug#392080), you're welcome
to join and get
this sorted out.
Also, what is the purpose of node.startup parameter?
When is it in use?
Don't know. Ask Mike, he implemented it.
Probably a leftover.
Cheers,
Hannes
--
Dr. Hannes Reinecke
Hi Mike,
Mike Christie wrote:
Erez Zilber wrote:
On Mon, Aug 4, 2008 at 7:30 PM, Mike Christie [EMAIL PROTECTED]
wrote:
Erez Zilber wrote:
On Wed, Jul 16, 2008 at 8:26 PM, Mike Christie
[EMAIL PROTECTED] wrote:
Erez Zilber wrote:
On Tue, Jul 15, 2008 at 3:42 AM, Mike Christie
[EMAIL
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.
Yes, it does with the stock open-iscsi distribution.
For SUSE I've added a patch to change the default.
Why do we have to run
, 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.
Yes, it does with the stock open-iscsi distribution.
For SUSE I've added a patch to change the default.
two important session parameters change
Hi Mike,
Mike Christie wrote:
Hannes Reinecke wrote:
For boot from iSCSI we need to the fwparam_ibft program
to setup the network correctly. This patch moves the
fwparam_ibft files into a library and adds a new program
fwparam_ibft to print out the network parameter.
Why do you need
For boot from iSCSI we need to the fwparam_ibft program
to setup the network correctly. This patch moves the
fwparam_ibft files into a library and adds a new program
fwparam_ibft to print out the network parameter.
Signed-off-by: Hannes Reinecke [EMAIL PROTECTED]
---
Makefile
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
Hi Mike,
these have been all patches I had in my queue. So now you
can go ahead and do the release :-)
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
[EMAIL PROTECTED] +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409
Hi Mike,
the debug option for iscsiadm is '-d', not '-g'.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
[EMAIL PROTECTED] +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg
Hi Mike,
iscsid is leaking IPC identifiers when the startup fails.
Please apply.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
[EMAIL PROTECTED] +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB
101 - 152 of 152 matches
Mail list logo
