From owner-freebsd-scsi@freebsd.org Wed Dec 20 16:10:03 2017 Return-Path: Delivered-To: freebsd-scsi@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 A5F5BE92346 for ; Wed, 20 Dec 2017 16:10:03 +0000 (UTC) (envelope-from ken@freebsd.org) Received: from mithlond.kdm.org (mithlond.kdm.org [96.89.93.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 68F4475363; Wed, 20 Dec 2017 16:10:03 +0000 (UTC) (envelope-from ken@freebsd.org) Received: from [10.0.0.26] (mbp2013.int.kdm.org [10.0.0.26]) (authenticated bits=0) by mithlond.kdm.org (8.15.2/8.14.9) with ESMTPSA id vBKG9sBm055937 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 20 Dec 2017 11:09:55 -0500 (EST) (envelope-from ken@freebsd.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: FreeBSD 11 not sending repeated TURs until good status returned? From: Ken Merry In-Reply-To: <30772d0e-2456-a90e-54a2-7575987b25b4@bluestop.org> Date: Wed, 20 Dec 2017 11:09:52 -0500 Cc: Alan Somers , FreeBSD-scsi Content-Transfer-Encoding: quoted-printable Message-Id: <9209CA38-750D-4966-911F-342092309DDF@freebsd.org> References: <87ad0e0a-0183-d123-d7f3-2735c8cf854e@bluestop.org> <30772d0e-2456-a90e-54a2-7575987b25b4@bluestop.org> To: Rebecca Cran X-Mailer: Apple Mail (2.3445.5.20) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [96.89.93.250]); Wed, 20 Dec 2017 11:09:55 -0500 (EST) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 16:10:03 -0000 > On Dec 19, 2017, at 7:53 PM, Rebecca Cran = wrote: >=20 > On 12/19/2017 05:29 PM, Alan Somers wrote: >=20 >>=20 >> What's the problem exactly? Does FreeBSD poll the device or not? = Does FreeBSD give up too soon, or poll with the wrong command, or what? = And if you don't mind me asking, what sort of drive is this that takes = so long to come ready? >=20 > FreeBSD thinks the device is ready before it really is, and ends up = issuing read commands that fail, resulting in the device being removed. > The drive is a SAS SSD, and I don't know why it takes longer than most = to become read. >=20 I have seen this behavior on some HGST SSDs. I haven=E2=80=99t had a = chance to fully chase it down. The polling code is in there and is active in this case. You can tell = because of this message: >=20 > Polling device for readiness It will send a TUR every half second for a minute to wait for the device = to become ready, and then retry the read if the TURs succeeded. I = *think* (I=E2=80=99d have to look more closely), it=E2=80=99ll retry the = READ four more times, and will go through the 1 minute TUR sequence each = time. But the mpssas_prepare_remove message indicates that this disk (or = another one) is getting removed by the controller. IMO, the sense data probably means the SSD is doing something wrong. = They should become ready before they turn on the SAS port. The = initiator is going to try sending commands as soon as the port comes = active. And if an SSD can=E2=80=99t come ready in a minute (spinning = drives take ~10 seconds to spin up), something is wrong. We=E2=80=99ll probably need full logs to get a better idea of what is = going on. Ken =E2=80=94=20 Ken Merry ken@FreeBSD.ORG