So after srp_reconnect_target() returns, SRP has no requests in its
queue. The only way that a command could be put in the queue is if
the SCSI midlayer passes it back into the queuecommand functions.
Yes this is exactly what happening.
static int scsi_eh_host_reset(struct list_head *work_q,
struct list_head *done_q)
{
...
rtn = scsi_try_host_reset(scmd);
if (rtn == SUCCESS) {
list_for_each_entry_safe(scmd, next, work_q,
eh_entry) {
if (!scsi_device_online(scmd->device) ||
(!scsi_eh_try_stu(scmd) &&
!scsi_eh_tur(scmd)) ||
!scsi_eh_tur(scmd))
...
}
1st scsi_try_host_reset() --> srp_host_reset() -->
srp_reconnect_target() return SUCCESS. Then
scsi_eh_try_stu() or scsi_eh_tur() is called right after
scsi_eh_try_stu or scsi_eh_tur --> scsi_send_eh_cmnd() -->
srp_queuecommand()
Also, this really worries me:
Vu> May 5 16:36:24 lab105 kernel: ib_mthca 0000:05:00.0: CQ overrun on CQN
040082
Do you know what's causing this?
I'm guesing that we get qp event 1 without handling it and
we keep posting request
Vu
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
