From patchwork Fri Sep 16 21:40:23 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Alan Stern X-Patchwork-Id: 9336779 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id A9AC26077F for ; Fri, 16 Sep 2016 21:40:28 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 93E5B28BF7 for ; Fri, 16 Sep 2016 21:40:28 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 85C992A127; Fri, 16 Sep 2016 21:40:28 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E4BC028BF7 for ; Fri, 16 Sep 2016 21:40:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755951AbcIPVk0 (ORCPT ); Fri, 16 Sep 2016 17:40:26 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:36960 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1755022AbcIPVkZ (ORCPT ); Fri, 16 Sep 2016 17:40:25 -0400 Received: (qmail 4693 invoked by uid 2102); 16 Sep 2016 17:40:23 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 16 Sep 2016 17:40:23 -0400 Date: Fri, 16 Sep 2016 17:40:23 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Ritesh Raj Sarraf cc: Ulf Hansson , USB list , linux-mmc Subject: Re: xHCI problem? [was Re: Erratic USB device behavior and device loss] In-Reply-To: <1474040525.18741.1.camel@researchut.com> Message-ID: MIME-Version: 1.0 Sender: linux-mmc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Fri, 16 Sep 2016, Ritesh Raj Sarraf wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hello Ulf and Alan, > > On Thu, 2016-09-15 at 10:16 -0400, Alan Stern wrote: > > > --- > > >  drivers/mmc/host/rtsx_usb_sdmmc.c | 2 ++ > > >  1 file changed, 2 insertions(+) > > >  > > > 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 > > >  > > > --  > > >  > > > Although, I doubt the above is the main reason to the issues we see. > > > > I don't know -- it could well be the reason.  The symptoms are  > > definitely what you would expect to see if some thread was doing I/O  > > without calling the pm_runtime_* routines. > I was able to hit it again. Please find the usbmon trace at: > https://people.debian.org/~rrs/tmp/usb-4.8.0-rc6ulf1+.log.gz We're still getting runtime suspends, but now at 2-second intervals. This is partly because the driver isn't calling pm_runtime_mark_last_busy(), but there may be more to it. The 2-second period is the default autosuspend timeout for USB devices. However, I don't see the activity that rtsx_usb_get_card_status() should produce when rtsx_usb_suspend() runs; I don't know why not. We're also getting occasional I/O attempts while the device is suspended. They must be on some other pathway, not the one fixed by the patch above. Let's see if we can find out just where they come from. Ritesh, please try applying this patch on top of the previous one. It will produce output in the kernel log whenever these bad I/O attempts occur. Also, enable dynamic debugging for the rtsx_usb driver: echo 'module rtsx_usb =p' >/sys/kernel/debug/dynamic_debug/control before starting the test. (You may need to mount a debugfs filesystem on /sys/kernel/debug first.) Alan Stern --- 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 Index: usb-4.x/drivers/usb/core/hcd.c =================================================================== --- usb-4.x.orig/drivers/usb/core/hcd.c +++ usb-4.x/drivers/usb/core/hcd.c @@ -1647,6 +1647,8 @@ int usb_hcd_submit_urb (struct urb *urb, status = map_urb_for_dma(hcd, urb, mem_flags); if (likely(status == 0)) { status = hcd->driver->urb_enqueue(hcd, urb, mem_flags); + if (status == -EHOSTUNREACH) + dump_stack(); if (unlikely(status)) unmap_urb_for_dma(hcd, urb); }