From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966373AbdEOQLj (ORCPT ); Mon, 15 May 2017 12:11:39 -0400 Received: from esa2.dell-outbound.iphmx.com ([68.232.149.220]:28932 "EHLO esa2.dell-outbound.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965950AbdEOQLh (ORCPT ); Mon, 15 May 2017 12:11:37 -0400 From: X-LoopCount0: from 10.175.216.249 X-IronPort-AV: E=Sophos;i="5.38,345,1491282000"; d="scan'208";a="1109480468" To: CC: , , , , , , Subject: RE: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe Thread-Topic: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe Thread-Index: AQHSytUdBkAUc+SsG06Yu2RhBlD+VqHyhtmAgAMLk5A= Date: Mon, 15 May 2017 16:11:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.143.18.86] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v4FGCBAv000701 > -----Original Message----- > From: Andy Lutomirski [mailto:luto@kernel.org] > Sent: Saturday, May 13, 2017 7:28 AM > To: Andy Lutomirski > Cc: Jens Axboe ; linux-kernel@vger.kernel.org; Kai-Heng Feng > ; linux-nvme ; > Christoph Hellwig ; Sagi Grimberg ; Keith Busch > ; Limonciello, Mario > Subject: Re: [PATCH] nvme: Change our APST table to be no more aggressive than > Intel RSTe > > On Thu, May 11, 2017 at 9:06 PM, Andy Lutomirski wrote: > > It seems like RSTe is much more conservative with transition timing > > that we are. According to Mario, RSTe programs APST to transition from > > active states to the first idle state after 60ms and, thereafter, to > > 1000 * the exit latency of the target state. > > Bad news, folks: this appears to be merely more stable, not all the way stable: > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1678184/comments/65 > > I maintain my hypothesis that no one ever validated these disks and > that the very conservative parameters set by RSTe merely make it rare > to trigger the bug. But maybe something else is going on. This is really unfortunate to hear. I think the conservative parameters set by Intel are still best though. I've been talking to folks about this. There has been mentions to a possible signal integrity issue specifically on the quirked Dell systems and how it relates to this. The current (working) theory is that when the drive is in PS4 and is supposed to transition back that crosstalk causes problems with the link negotiation and thus fails. So there's two possible ways I see to approach solving this (from Linux side): 1) Keep quirking those systems from going into PS4. This isn't ideal as the jump to PS4 gets you the most power savings, but of course stable system > power savings 2) Quirk those systems to redo link negotiation a few times if it fails I don't know if this is actually possible. Where is link negotiation invoked? If our partners come up with a way to solve this from drive firmware though I'll let this group know. Thanks,