On 07/27/2010 04:32 PM, Vasu Dev wrote:
This isn't one of those races where you are blocking the rport, but the IO keeps coming around so the retries are used really quickly right (the driver looks like it has the fc class and internal state checks to prevent this but I wanted to make sure).
I think I am hitting the above problem.
This tiny time windows can be further reduced by use of wmb() on rport state change to block and lport getting out of ready since their states are checked w/o lock in queuecommand path.
I think you need something like this for the lport queue ready check. It looks like the initial failure from __fc_linkdown->fc_fcp_cleanup burned a timeout. Then because it missed the lport ready check, it will use an extra retry just sitting there timing out.
For the rport state check, I think you are supposed to call the fc chkready function under the host lock. The port state and flags are set under it. I did the attached patch for that.
_______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
