From owner-svn-src-all@freebsd.org Tue Apr 18 19:31:55 2017 Return-Path: Delivered-To: svn-src-all@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 092F7D427D6 for ; Tue, 18 Apr 2017 19:31:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 C6D08F37 for ; Tue, 18 Apr 2017 19:31:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x236.google.com with SMTP id a140so1059887ita.0 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=DRSOWCHbZloWoyIpsr+W7tNqC52M9latks4uNr95L8UwgXTMmcf0MBaUbV8w59apvY Fg1eIxzvKExP4I9waeWYqhl3/mAXsthv5ZmDH0qyVCHyBt5UpwIIwSCvmXuAdqYhdMiD pZQxpZxnF/yKiDVS8hsZmCtxAON6+pijoYilLaxV65OoIJbj2wSuMrzVpGEJ0uWEpEys Mguan7jm0ciEaM/U8hXSEMCvuu3jCPVULHtqrxHZQ+3AzT0586+etd8Tj4ls2CEP5rHA En08twX6nKtraPAE5HFn3T+D3DnGGbVw09kl72j4wg7W8KQlfqA3ZIaaho+/4VcQlP8g lZ7Q== X-Gm-Message-State: AN3rC/6c1mTCLP+ybCS5N4zEOmpNjO2IARw+1JonPMcy3/KvLlz23zE5 KJigYjJiwwmxcdM0+QeG0Oxmd8Vsnw== 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-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" 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