Mike Christie wrote:
On 07/23/2009 05:20 AM, Boaz Harrosh wrote:
On 07/23/2009 12:24 PM, Mike Christie wrote:
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
Hey Hannes,
Do you only need this patch with your cmdsn patch?
The code below is a leftover from when I had the cmdsn check in
iscsi_datra_xmit. I am not sure why we would need to wake the xmit
thread. The reasons I have:
1. queuecommand or __iscsi_conn_send_pdu adds new task.
2. sendpage
Mike Christie wrote:
Hey Hannes,
Do you only need this patch with your cmdsn patch?
The code below is a leftover from when I had the cmdsn check in
iscsi_datra_xmit. I am not sure why we would need to wake the xmit
thread. The reasons I have:
1. queuecommand or __iscsi_conn_send_pdu
On 07/23/2009 05:20 AM, Boaz Harrosh wrote:
On 07/23/2009 12:24 PM, Mike Christie wrote:
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.
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_ the CmdSN only much later
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_ the
Hannes Reinecke wrote:
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
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
On 07/23/2009 12:24 PM, Mike Christie wrote:
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 your patch might be working because
Hannes Reinecke wrote:
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
On 07/23/2009 07:01 PM, Mike Christie wrote:
Boaz Harrosh wrote:
I think I can replicate this problem now too. It was by accident. I am
using a EQL target remotely (I am in the middle of the US and the target
is on the west coast so there is a good deal of space between us and the
Mike Christie wrote:
Hannes Reinecke wrote:
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
Mike Christie wrote:
Mike Christie wrote:
Hannes Reinecke wrote:
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
Amazingly the RFC says The target MUST silently ignore any non-immediate
command
outside of this range(...), but it does not say something like the Initiator
SHOULD NOT send ... any command out of range...
Regards,
Ulrich
On 21 Jul 2009 at 15:21, Mike Christie wrote:
On 07/21/2009 11:35
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 task
management
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
On 07/22/2009 05:57 AM, 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
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_ the CmdSN only much later after we've
dequeued the command.
The check in
On 07/22/2009 12:24 PM, 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_ the CmdSN only much later
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_ the CmdSN only much later after we've
dequeued the command.
The check in
On 07/22/2009 03:01 PM, 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_ the CmdSN only much later
When sending a PDU we're just increase the CmdSN number
without any check for MaxCmdSN. This results in unexpected
ping timeouts and even connection stalls.
So we should make sure to check CmdSN against MaxCmdSN
before transferring a PDU, and just retry until MaxCmdSN
has been updated.
On 07/21/2009 11:35 AM, Boaz Harrosh wrote:
On 07/21/2009 03:33 PM, Hannes Reinecke wrote:
When sending a PDU we're just increase the CmdSN number
without any check for MaxCmdSN. This results in unexpected
ping timeouts and even connection stalls.
So we should make sure to check CmdSN
Mike Christie wrote:
If we send too many nops marked as immediate we should be getting a
reject pdu right? If so then I think we just need the attached patch
which adds some code to handle rejected immediate pdus. The patch is
made over scsi-rc-fixes and is only compile tested.
I tested
24 matches
Mail list logo
