From owner-p4-projects@FreeBSD.ORG Wed Nov 15 05:37:26 2006 Return-Path: X-Original-To: p4-projects@freebsd.org Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 822F916A407; Wed, 15 Nov 2006 05:37:26 +0000 (UTC) X-Original-To: perforce@freebsd.org Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 454CD16A412 for ; Wed, 15 Nov 2006 05:37:26 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id D35EC43D55 for ; Wed, 15 Nov 2006 05:37:25 +0000 (GMT) (envelope-from mjacob@freebsd.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.13.6/8.13.6) with ESMTP id kAF5bPex080194 for ; Wed, 15 Nov 2006 05:37:25 GMT (envelope-from mjacob@freebsd.org) Received: (from perforce@localhost) by repoman.freebsd.org (8.13.6/8.13.4/Submit) id kAF5bPcC080191 for perforce@freebsd.org; Wed, 15 Nov 2006 05:37:25 GMT (envelope-from mjacob@freebsd.org) Date: Wed, 15 Nov 2006 05:37:25 GMT Message-Id: <200611150537.kAF5bPcC080191@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: perforce set sender to mjacob@freebsd.org using -f From: Matt Jacob To: Perforce Change Reviews Cc: Subject: PERFORCE change 110005 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 05:37:26 -0000 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),