From owner-freebsd-current@freebsd.org Tue Jul 14 19:49:38 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ADFB09A1E4F for ; Tue, 14 Jul 2015 19:49:38 +0000 (UTC) (envelope-from ken@kdm.org) Received: from doriath.kdm.org (doriath.kdm.org [96.89.93.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "doriath.kdm.org", Issuer "doriath.kdm.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3EB4A1063; Tue, 14 Jul 2015 19:49:38 +0000 (UTC) (envelope-from ken@kdm.org) Received: from doriath.kdm.org (localhost [127.0.0.1]) by doriath.kdm.org (8.14.9/8.14.9) with ESMTP id t6EJnU2V051356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Jul 2015 15:49:30 -0400 (EDT) (envelope-from ken@doriath.kdm.org) Received: (from ken@localhost) by doriath.kdm.org (8.14.9/8.14.9/Submit) id t6EJnTR5051355; Tue, 14 Jul 2015 15:49:29 -0400 (EDT) (envelope-from ken) Date: Tue, 14 Jul 2015 15:49:29 -0400 From: "Kenneth D. Merry" To: Alexander Motin Cc: Kohji Okuno , freebsd-current@freebsd.org Subject: Re: Why shoud we cause panic in scsi_da.c? Message-ID: <20150714194929.GA51157@doriath.kdm.org> References: <20150709.150520.1823457260978955949.okuno.kohji@jp.panasonic.com> <20150713.171110.531869520391748650.okuno.kohji@jp.panasonic.com> <55A37933.3000802@selasky.org> <20150713.175143.290106286605820529.okuno.kohji@jp.panasonic.com> <55A3D960.5000704@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55A3D960.5000704@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (doriath.kdm.org [127.0.0.1]); Tue, 14 Jul 2015 15:49:30 -0400 (EDT) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on doriath.kdm.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 19:49:38 -0000 On Mon, Jul 13, 2015 at 18:29:36 +0300, Alexander Motin wrote: > Hi. > > On 13.07.2015 11:51, Kohji Okuno wrote: > >> On 07/13/15 10:11, Kohji Okuno wrote: > >>> Could you comment on my quesion? > >>> > >>>> I found panic() in scsi_da.c. Please find the following. > >>>> I think we should return with error without panic(). > >>>> What do you think about this? > >>>> > >>>> scsi_da.c: > >>>> 3018 } else if (bp != NULL) { > >>>> 3019 if ((done_ccb->ccb_h.status & CAM_DEV_QFRZN) != 0) > >>>> 3020 panic("REQ_CMP with QFRZN"); > >>>> > >> > >> It looks to me more like an KASSERT() is appropriate here. > > As I can see, this panic() call was added by ken@ about 15 years ago. > I've added him to CC in case he has some idea why it was done. From my > personal opinion I don't see much reasons to allow CAM_DEV_QFRZN to be > returned only together with error. While is may have little sense in > case of successful command completion, I don't think it should be > treated as error. Simply removing this panic is probably a bad idea, > since if it happens device will just remain frozen forever, that will be > will be difficult to diagnose, but I would better just dropped device > freeze in that case same as in case of completion with error. I put it there because it indicates a software error. The queue shouldn't be frozen if the command is successful. The reason for freezing the queue is to allow error recovery to happen. The queue will get unfrozen after error recovery completes. We could alternately just print a diagnostic message, unfreeze the queue and move on, but the idea is to allow the driver writer to detect and correct his error immediately. As for the original poster's problem, he has uncovered a bug that needs to be fixed. (And I don't mean in the da(4) driver. The bug is in the component that left the queue frozen. Most likely in the USB driver, but it will take a little more investigation.) The panic worked as intended. :) Ken -- Kenneth Merry ken@FreeBSD.ORG