svn commit: r308155 - in head/sys: amd64/conf cam cam/scsi conf dev/mps geom geom/part kern sys vm

[Warner Losh]

On Tue, Apr 18, 2017 at 1:15 PM, Conrad Meyer <cem at freebsd.org> wrote:
> Hi Alan,
>
> On Tue, Apr 18, 2017 at 12:02 PM, Alan Somers <asomers at freebsd.org> wrote:
>> This change is causing panics when I try to create a zpool on an SSD.
>>
>> ... (reordered slightly)
>>
>> The
>> offending line is the biotrack call in scsi_da.c at line 4172; bp is
>> apparently null.  Could you please review this change and ensure that
>> biotrack is appropriately guarded?
>
> If it is valid for bp to be NULL in that path, then of course a NULL
> guard needs to be added.
>
> I'm a little confused on why or if it is valid for bp to be NULL in
> that path.  You are the only one who has reported this since October
> of last year.  Is it possible some other issue is now resulting in a
> NULL bp?
>
>> The SSD is obviously having problems; it fails UNMAP commands with
>> ILLEGAL REQUEST, and then fails WRITE SAME with a timeout.
>
> Well, that could definitely explain a weird error case.  Still,
> shouldn't the CCB keep the bp associated through CCB completion?

The NULL test is needed. We keep a list of TRIM BIOs that we collapse
down into one CCB. We'll have already completed it and set bp to NULL
in that case, so we need to test at the end of the loop to see if bp
is NULL or not. We only have to collapse TRIMs occasionally, which may
explain the rarity of the crash.

Warner