From owner-svn-src-head@freebsd.org Tue Apr 18 19:31:55 2017 Return-Path: Delivered-To: svn-src-head@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 02EADD427D5 for ; Tue, 18 Apr 2017 19:31:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C6CC3F36 for ; Tue, 18 Apr 2017 19:31:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22c.google.com with SMTP id b15so16401419iti.1 for ; Tue, 18 Apr 2017 12:31:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=dBG2HVQIhaB/OYwdkfY7z4N+52GdfizX0COHF9r07Mk=; b=diP2UE93u0l31TGaFlU1XYnpQ+mo0cuUH8rc3lmx929LOM7I1tTZ8Om1yVAVs6UyTV IuMmY2c7qIT02TjetVwVyH3u2ygRuKOM/4eTOEyG4zRAwh34sPNp3apOVt7RG75tOBfm kDv+Bv+RoycRPOI4T901EE4CAGNt84xz4IPm8fZsLyO1Clx13/46F7A+/tj2riYjTrSu pK5F8txTSDNmXrfpZNFSMPtn06EDVPqi/OP01Et/qOnlmimShTTSekVgHemQI3tPNY2e GMcPD77nkNrRORcDh/Ukx4zz5veNxYC+Uli8e8iTXa4Ho3/hBlZYOcESKZaWyw8W16c+ AvXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=dBG2HVQIhaB/OYwdkfY7z4N+52GdfizX0COHF9r07Mk=; b=QMcVS6e3QoH5KEzI78mhhbhOErEuzt+1N1JzJbgIKNByosdBPo094eFAjSV3TsvMEO QvG98IVZHRbYXfy/uJQEux6E9DcPS3CFcY7+QrDwUh2gsGTlJf4zB60bthApxWTo9HUw LqpVz6P8zPqCiorlPnyeD09NTRlTGRG2i+KsFoVd10vbLQoEbH90ohirz4LzgL6Xequw DO+6qjXUZzlKsJoahxxBxgY18KSlM+tjxcVZTEtVsa66/yFEZFZyn+8+qiiKOWEz1sbz Sl3Mg5x2QlyMnaxZwgIx4go0kQUpwCAwFoYqyJx1m6DFmaCT3jYlJTj2evJrh+zaBSxg VNnw== X-Gm-Message-State: AN3rC/7YqgnauGHH6hfijFyJMbXxHaVdtUjRcueXmIsWNaHDs0nV+Mnf 6fztB+Phzf5VQEHzzOydC2xoeETEzg== X-Received: by 10.36.31.200 with SMTP id d191mr15375104itd.85.1492543913942; Tue, 18 Apr 2017 12:31:53 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.146.69 with HTTP; Tue, 18 Apr 2017 12:31:53 -0700 (PDT) X-Originating-IP: [2607:fb10:7021:1::fb3e] In-Reply-To: References: <201610312309.u9VN9qGk027956@repo.freebsd.org> From: Warner Losh Date: Tue, 18 Apr 2017 13:31:53 -0600 X-Google-Sender-Auth: 9Ju4leGsU1RYOi9HJB1pb9r5I1I Message-ID: Subject: Re: svn commit: r308155 - in head/sys: amd64/conf cam cam/scsi conf dev/mps geom geom/part kern sys vm To: "Conrad E. Meyer" Cc: Alan Somers , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 19:31:55 -0000 On Tue, Apr 18, 2017 at 1:15 PM, Conrad Meyer wrote: > Hi Alan, > > On Tue, Apr 18, 2017 at 12:02 PM, Alan Somers 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