Date: Wed, 15 Nov 2006 05:37:25 GMT From: Matt Jacob <mjacob@FreeBSD.org> To: Perforce Change Reviews <perforce@freebsd.org> Subject: PERFORCE change 110005 for review Message-ID: <200611150537.kAF5bPcC080191@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://perforce.freebsd.org/chv.cgi?CH=110005 Change 110005 by mjacob@newisp on 2006/11/15 05:36:29 Ignore zero-valued FCP RSP INFO codes. FCP-2 claims that this is 'Task Management Complete'. This is nonsensical when it is getting returned from a normal I/O (non-task management) command. I would guess that targets just set RSP LEN VALID (0x100) in the status word, set the accepted length field for response info (4 or 8) and call it a day. Non-zero values, if we ever see them, *do* indicate a problem with the transfer that has just occurred, so in that case it is indeed correct to set a generic I/O error for the transfer and let the upper layers decide whether to retry. Affected files ... .. //depot/projects/newisp/dev/isp/isp.c#35 edit Differences ... ==== //depot/projects/newisp/dev/isp/isp.c#35 (text+ko) ==== @@ -4861,7 +4861,8 @@ switch (etype) { case RQSTYPE_RESPONSE: XS_SET_STATE_STAT(isp, xs, sp); - if (resp && rlen >= 4) { + if (resp && rlen >= 4 && + resp[FCP_RSPNS_CODE_OFFSET] != 0) { isp_prt(isp, ISP_LOGWARN, "%d.%d FCP RESPONSE: 0x%x", XS_TGT(xs), XS_LUN(xs),
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200611150537.kAF5bPcC080191>