From patchwork Thu Sep 15 13:59:43 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ulf Hansson X-Patchwork-Id: 76320 Delivered-To: patch@linaro.org Received: by 10.140.106.72 with SMTP id d66csp2458450qgf; Thu, 15 Sep 2016 06:59:48 -0700 (PDT) X-Received: by 10.66.254.170 with SMTP id aj10mr14702663pad.124.1473947988438; Thu, 15 Sep 2016 06:59:48 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id pv7si4069354pac.166.2016.09.15.06.59.48; Thu, 15 Sep 2016 06:59:48 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-mmc-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org; spf=pass (google.com: best guess record for domain of linux-mmc-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-mmc-owner@vger.kernel.org; dmarc=fail (p=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934452AbcION7r (ORCPT + 3 others); Thu, 15 Sep 2016 09:59:47 -0400 Received: from mail-qk0-f181.google.com ([209.85.220.181]:33706 "EHLO mail-qk0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934451AbcION7q (ORCPT ); Thu, 15 Sep 2016 09:59:46 -0400 Received: by mail-qk0-f181.google.com with SMTP id w204so51347509qka.0 for ; Thu, 15 Sep 2016 06:59:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DM3uu/JFiztQa/hnknswOOMk/hSZwIrnQqTH935iLwM=; b=hp3LI0SeC5ufKvZ9uITZ5ySYu5Y1l2hyYbMb+5Jj0tNr6Hvf1HGcVrTCxtFGRSjkCe ++RDq9Oqzm48q6CbRGr/x52+QAwxlTaKtJW66LgYNAPrI9Wj6/XbgbqYt4IdGFjsKb3D qZE/pWdpCZJ3nwWtAShxjiI8UNWSj3RQu/5ZY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DM3uu/JFiztQa/hnknswOOMk/hSZwIrnQqTH935iLwM=; b=KwvZ5BDV9WIxglcNfEEthml/+u4VLYl8YTuwppE5LetMwbSZjQxB5eRAzuZo4qCBxa xlc7+rBJsqo89E5nFx54Nt+BU5zQelwDZVPsXoK1q9fGfRHFBX/PSKWlRmweoFNyXOam aT0D+YFelWRtvxlouMSn/tgrivfNVq7vy5AK89t/dM2cgoOjcXXSXHM/KLq/hjWTZoqn A4DXbYjPvD4D1VGcDxJW5dluZiqXJDBjPOabMvjyzJ4X7/7jpcQXElqoxmxRXRX8Zhc0 XOnCdmilGiSRD2uMmDNppvhsoflQqpqW4valRQCpNp5GwXi5kNaQv6Pc4rbj1NnNlVCC 0RrQ== X-Gm-Message-State: AE9vXwNoYqFlv9VwUU4STof9bAoo84wndu1FlfoF4P28T2tvCDnEPNmpJgjicfD0bxDztKzcHT66+529gNVnTJSj X-Received: by 10.194.26.69 with SMTP id j5mr557878wjg.209.1473947985180; Thu, 15 Sep 2016 06:59:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.40.167 with HTTP; Thu, 15 Sep 2016 06:59:43 -0700 (PDT) In-Reply-To: References: <1473864634.9913.12.camel@researchut.com> From: Ulf Hansson Date: Thu, 15 Sep 2016 15:59:43 +0200 Message-ID: Subject: Re: xHCI problem? [was Re: Erratic USB device behavior and device loss] To: Alan Stern Cc: Ritesh Raj Sarraf , USB list , linux-mmc Sender: linux-mmc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.org On 14 September 2016 at 17:19, Alan Stern wrote: > On Wed, 14 Sep 2016, Ritesh Raj Sarraf wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> Hello Ulf and Alan, >> >> On Fri, 2016-09-09 at 19:34 +0530, Ritesh Raj Sarraf wrote: >> > For #2, I'm building the 4.8-rc5 kernel with the following change. This build >> > does not include the previous change you had suggested (related to >> > POWER_CYCLE) >> > >> > Date: Fri Sep 9 19:28:03 2016 +0530 >> > >> > Disable pm runtime in mmc core >> > >> > diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c >> > index e55cde6..32388d5 100644 >> > --- a/drivers/mmc/core/core.c >> > +++ b/drivers/mmc/core/core.c >> > @@ -970,9 +970,6 @@ int __mmc_claim_host(struct mmc_host *host, atomic_t >> > *abort) >> > spin_unlock_irqrestore(&host->lock, flags); >> > remove_wait_queue(&host->wq, &wait); >> > >> > - if (pm) >> > - pm_runtime_get_sync(mmc_dev(host)); >> > - >> > return stop; >> > } >> > EXPORT_SYMBOL(__mmc_claim_host); >> > @@ -1000,7 +997,6 @@ void mmc_release_host(struct mmc_host *host) >> > spin_unlock_irqrestore(&host->lock, flags); >> > wake_up(&host->wq); >> > pm_runtime_mark_last_busy(mmc_dev(host)); >> > - pm_runtime_put_autosuspend(mmc_dev(host)); >> > } >> > } >> > EXPORT_SYMBOL(mmc_release_host); >> >> I tried with these changes on 4.8-rc6 and I only saw 2 resets so far. >> I captured the usb trace [1], just in case if you need it. >> >> [1] https://people.debian.org/~rrs/tmp/4.8-rc6-ulf.txt.gz > > The situation isn't any better. At the start of the trace, > the device is in runtime suspend but there are many attempts to > communicate with it, all of which fail. It's really weird. Have this driver ever worked!? :-) > > Then a little less than an hour after the trace started, the device was > resumed. At that point it started working okay. Until there was a > spontaneous disconnect. > > The device reconnected, but after 3 seconds it was runtime suspended > again -- and the I/O attempts continued. Some time later there was > another runtime resume, and the device began working again. Until > another spontaneous disconnect occurred. And so on... > > Ulf, we really need to figure out why the autosuspends are occurring > and why the I/O doesn't stop while the device is suspended. Okay, let's see. I had another look in the rtsx_usb_sdmmc driver. Apparently it registers a led classdev. Updating the led is done from a work, by calling rtsx_usb_turn_on|off_led(), which do access the usb device. These calls are not properly managed by runtime PM, so I have fixed those according to below change: --- drivers/mmc/host/rtsx_usb_sdmmc.c | 2 ++ 1 file changed, 2 insertions(+) -- Although, I doubt the above is the main reason to the issues we see. Instead I think somehow the parent device (usb device) isn't being properly managed through runtime PM, but not due to wrong deployment in the mmc core nor in the rtsx_usb_driver, but at some place else. :-) I started looking for calls to pm_suspend_ignore_children(dev, true), which would decouple the usb device from the mmc platform device from a runtime PM point of view. I found one suspicious case! drivers/usb/storage/realtek_cr.c: pm_suspend_ignore_children(&us->pusb_intf->dev, true); As I am not so familiar with USB, I can't really tell why the above exists, although perhaps just removing that line would be worth a try!? If neither of the above works, the next step could be to start checking error codes in the mmc core and in the rtsx_usb_sdmmc driver, from the calls to pm_runtime_get|put() and pm_runtime_enable(). Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c b/drivers/mmc/host/rtsx_usb_sdmmc.c index 6c71fc9..a59c7fa 100644 --- a/drivers/mmc/host/rtsx_usb_sdmmc.c +++ b/drivers/mmc/host/rtsx_usb_sdmmc.c @@ -1314,6 +1314,7 @@ static void rtsx_usb_update_led(struct work_struct *work) container_of(work, struct rtsx_usb_sdmmc, led_work); struct rtsx_ucr *ucr = host->ucr; + pm_runtime_get_sync(sdmmc_dev(host)); mutex_lock(&ucr->dev_mutex); if (host->led.brightness == LED_OFF) @@ -1322,6 +1323,7 @@ static void rtsx_usb_update_led(struct work_struct *work) rtsx_usb_turn_on_led(ucr); mutex_unlock(&ucr->dev_mutex); + pm_runtime_put(sdmmc_dev(host)); } #endif