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 
>> there is 
>> heavy traffic for a target. (MHO)
> But the point is there _is_ no traffic at that point.
>>> However, after some heavy instrumenting I found this:
> [ .. ]
>>> [ 2666.376858]  connection2:0: mgmtpdu [itt 0xa05 p ffff8100795675c0] 
>>> delayed, cmd 0 mgmt 0 req 0 exp 1913193 max 1913177 queued 1913194
> The 'cmd', 'mgmt', 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.

Jul 21 09:50:01 esk kernel: [  456.807621]  connection2:0: Sending nopout,cmd 0 
mgmt 0 req 0 exp 15661 max 15598 queued 15599

(queued is actually now session->cmdsn, as MikeC suggested).
So it's not ExpCmdSN which is the problem here, it's CmdSN.
We're actually sending a NOP Out with a CmdSN _larger_ than MaxCmdSN.
Which is happily ignored by the target.

And looking further, we indeed never check in the xmit code path if
CmdSN might exceed MaxCmdSN. In which case we really should
wait until we've got an update for MaxCmdSN.



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 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 
For more options, visit this group at http://groups.google.com/group/open-iscsi

Reply via email to