FreeBSD 11 not sending repeated TURs until good status returned?
Ken Merry
ken at freebsd.org
Wed Dec 20 16:10:03 UTC 2017
> On Dec 19, 2017, at 7:53 PM, Rebecca Cran <rebecca at bluestop.org> wrote:
>
> On 12/19/2017 05:29 PM, Alan Somers wrote:
>
>>
>> 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?
>
> 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.
>
I have seen this behavior on some HGST SSDs. I haven’t 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:
>
> 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’d have to look more closely), it’ll 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’t come ready in a minute (spinning drives take ~10 seconds to spin up), something is wrong.
We’ll probably need full logs to get a better idea of what is going on.
Ken
—
Ken Merry
ken at FreeBSD.ORG
More information about the freebsd-scsi
mailing list