Searched hist:"883 a337c" (Results 1 – 1 of 1) sorted by relevance
| /openbmc/linux/drivers/scsi/libfc/ |
| H A D | fc_disc.c | 883a337c Tue Aug 25 16:02:27 CDT 2009 Joe Eykholt <jeykholt@cisco.com> [SCSI] libfc: handle discovery failure more correctly.
Abhijeet Joglekar wrote: "In gpn_ft_resp, if the payload is short,
or unexpected response or out of sequence frame, then we just
return and do nothing. We should either enter fc_disc_done()
with DISC_EV_FAIL which will then restart any queued discovery
requests or call lport module which will reset local port,
or we should call fc_disc_error() so that the gpn_ft is retried.
The situation as is causes discovery to remain pending and never
get restarted, in these rare cases. We saw this due to a coding
bug in fc_disc before. The only ways it could happen would be
bugs, packet corruption or an FC fabric problem.
Change it to fail discovery. The local port will restart
discovery, although it probably should just give up until
the next link flap.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
883a337c Tue Aug 25 16:02:27 CDT 2009 Joe Eykholt <jeykholt@cisco.com> [SCSI] libfc: handle discovery failure more correctly.
Abhijeet Joglekar wrote: "In gpn_ft_resp, if the payload is short,
or unexpected response or out of sequence frame, then we just
return and do nothing. We should either enter fc_disc_done()
with DISC_EV_FAIL which will then restart any queued discovery
requests or call lport module which will reset local port,
or we should call fc_disc_error() so that the gpn_ft is retried.
The situation as is causes discovery to remain pending and never
get restarted, in these rare cases. We saw this due to a coding
bug in fc_disc before. The only ways it could happen would be
bugs, packet corruption or an FC fabric problem.
Change it to fail discovery. The local port will restart
discovery, although it probably should just give up until
the next link flap.
Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
|