Date: Mon, 13 Jul 2015 18:29:36 +0300 From: Alexander Motin <mav@FreeBSD.org> To: Kohji Okuno <okuno.kohji@jp.panasonic.com> Cc: freebsd-current@freebsd.org, ken <ken@freebsd.org> Subject: Re: Why shoud we cause panic in scsi_da.c? Message-ID: <55A3D960.5000704@FreeBSD.org> In-Reply-To: <20150713.175143.290106286605820529.okuno.kohji@jp.panasonic.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
--
Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55A3D960.5000704>