From patchwork Wed May 5 10:15:06 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tejun Heo X-Patchwork-Id: 51683 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id B2FF1B7D51 for ; Wed, 5 May 2010 20:15:49 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934319Ab0EEKPr (ORCPT ); Wed, 5 May 2010 06:15:47 -0400 Received: from hera.kernel.org ([140.211.167.34]:37700 "EHLO hera.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934221Ab0EEKPr (ORCPT ); Wed, 5 May 2010 06:15:47 -0400 Received: from htj.dyndns.org (localhost [127.0.0.1]) by hera.kernel.org (8.14.3/8.14.3) with ESMTP id o45AF7An019476; Wed, 5 May 2010 10:15:08 GMT X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.2 at hera.kernel.org Received: from [127.0.0.2] (htj.dyndns.org [127.0.0.2]) by htj.dyndns.org (Postfix) with ESMTPSA id 206C210068030; Wed, 5 May 2010 12:15:07 +0200 (CEST) Message-ID: <4BE1452A.6040607@kernel.org> Date: Wed, 05 May 2010 12:15:06 +0200 From: Tejun Heo User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Olof Johansson CC: linux-ide@vger.kernel.org, jgarzik@pobox.com Subject: Re: link resets with SSD on AHCI References: <20100429215935.GA9796@lixom.net> In-Reply-To: <20100429215935.GA9796@lixom.net> X-Enigmail-Version: 1.0.1 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on hera.kernel.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (hera.kernel.org [127.0.0.1]); Wed, 05 May 2010 10:15:09 +0000 (UTC) Sender: linux-ide-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ide@vger.kernel.org Hello, On 04/29/2010 11:59 PM, Olof Johansson wrote: > I did notice that ALPM is enabled at boot, and doesn't seem to be > re-enabled after the error reset. Based on this, I experimented with > disabling it (just returning -EINVAL in ahci_enable_alpm). That did make > the problem not happen after a significant test run (overnight vs 4.5 > minutes above). It could be that libata's ALPM enable sequence isn't liked by the controller. libata first resets the link disabling all powersave transitions, then turn on ALPM then allows powersave transitions. It's possible that the controller or device somehow gets upset by this (ie. the device is told to go to powersave mode only to find out that the host side isn't allowing it). Does the attached patch make any difference? Can you please post the kernel boot log with the patch applied? Thanks. diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index 49cffb6..696be5f 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -3810,7 +3810,7 @@ int sata_link_resume(struct ata_link *link, const unsigned long *params, * cleared. */ do { - scontrol = (scontrol & 0x0f0) | 0x300; + scontrol = (scontrol & 0x0f0)/* | 0x300*/; if ((rc = sata_scr_write(link, SCR_CONTROL, scontrol))) return rc; /* @@ -3823,9 +3823,9 @@ int sata_link_resume(struct ata_link *link, const unsigned long *params, /* is SControl restored correctly? */ if ((rc = sata_scr_read(link, SCR_CONTROL, &scontrol))) return rc; - } while ((scontrol & 0xf0f) != 0x300 && --tries); + } while ((scontrol & 0xf0f) != /*0x300*/0 && --tries); - if ((scontrol & 0xf0f) != 0x300) { + if ((scontrol & 0xf0f) != /*0x300*/0) { ata_link_printk(link, KERN_ERR, "failed to resume link (SControl %X)\n", scontrol);