From patchwork Mon Sep 19 17:48:20 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alan Stern X-Patchwork-Id: 9340285 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 B46E7607D0 for ; Mon, 19 Sep 2016 17:48:24 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id AAF1F2960F for ; Mon, 19 Sep 2016 17:48:24 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9FDD229614; Mon, 19 Sep 2016 17:48:24 +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 E69722960F for ; Mon, 19 Sep 2016 17:48:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751441AbcISRsW (ORCPT ); Mon, 19 Sep 2016 13:48:22 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:37512 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1750867AbcISRsW (ORCPT ); Mon, 19 Sep 2016 13:48:22 -0400 Received: (qmail 2898 invoked by uid 2102); 19 Sep 2016 13:48:20 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 19 Sep 2016 13:48:20 -0400 Date: Mon, 19 Sep 2016 13:48:20 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Ulf Hansson , Alex Dubov cc: Ritesh Raj Sarraf , USB list , linux-mmc Subject: Re: xHCI problem? [was Re: Erratic USB device behavior and device loss] In-Reply-To: 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 Mon, 19 Sep 2016, Ulf Hansson wrote: > On 18 September 2016 at 03:42, Alan Stern wrote: > > Well, this is pretty clear: > > > > Sep 17 15:55:52 learner kernel: CPU: 1 PID: 535 Comm: rtsx_usb_ms_1 Tainted: G U 4.8.0-rc6ulf1alan1+ #19 > > Sep 17 15:55:52 learner kernel: Hardware name: LENOVO 20344/INVALID, BIOS 96CN31WW(V1.17) 07/21/2015 > > Sep 17 15:55:52 learner kernel: 0000000000000000 ffffffff81314be5 ffff8802476746c0 0000000002400000 > > Sep 17 15:55:52 learner kernel: ffffffffa016f719 00000000523bec00 ffff88025f255780 ffff88024feff600 > > Sep 17 15:55:52 learner kernel: 0000000000018080 0000000000000000 ffff88025f258080 ffffffff815a0e60 > > Sep 17 15:55:52 learner kernel: Call Trace: > > Sep 17 15:55:52 learner kernel: [] ? dump_stack+0x7d/0xb8 > > Sep 17 15:55:52 learner kernel: [] ? usb_hcd_submit_urb+0x3c9/0xad0 [usbcore] > > Sep 17 15:55:52 learner kernel: [] ? _raw_spin_lock_irqsave+0x20/0x47 > > Sep 17 15:55:52 learner kernel: [] ? lock_timer_base.isra.24+0x7b/0xa0 > > Sep 17 15:55:52 learner kernel: [] ? try_to_del_timer_sync+0x49/0x60 > > Sep 17 15:55:52 learner kernel: [] ? usb_start_wait_urb+0x5d/0x140 [usbcore] > > Sep 17 15:55:52 learner kernel: [] ? rtsx_usb_send_cmd+0x5e/0x80 [rtsx_usb] > > Sep 17 15:55:52 learner kernel: [] ? rtsx_usb_read_register+0x67/0xb0 [rtsx_usb] > > Sep 17 15:55:52 learner kernel: [] ? rtsx_usb_detect_ms_card+0x61/0xe0 [rtsx_usb_ms] > > Sep 17 15:55:52 learner kernel: [] ? rtsx_usb_ms_set_param+0x770/0x770 [rtsx_usb_ms] > > Sep 17 15:55:52 learner kernel: [] ? kthread+0xbd/0xe0 > > Sep 17 15:55:52 learner kernel: [] ? __switch_to+0x2b1/0x6a0 > > Sep 17 15:55:52 learner kernel: [] ? ret_from_fork+0x1f/0x40 > > Sep 17 15:55:52 learner kernel: [] ? kthread_create_on_node+0x180/0x180 > > > > This is the rtsx_usb_detect_ms_card() routine in > > drivers/memstick/host/rtsx_usb_ms.c, which runs as a kthread. It > > doesn't do any runtime PM. So it looks like the bug is present in both > > the MMC and MemoryStick interfaces. > > I think the problem is even worse in the MemoryStick case, as the > memstick core doesn't help with runtime PM. I am pretty sure there are > other cases when the MemoryStick driver accesses the usb device > without first runtime resuming it. Maybe we should get a MemoryStick maintainer involved in this thread. I CC'ed Alex Dubov. Alex, the problem here is that drivers/memstick/host/rtsx_usb_ms.c tries to communicate with the host USB device while it is runtime suspended. > Of course we could start simple an fix the bug observed above and see > if that solves the reported problem. Alan, do you want to post to > patch or you want me? This ought to help. Ritesh, please apply this patch on top of the two earlier ones and let's see what happens. 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/memstick/host/rtsx_usb_ms.c =================================================================== --- usb-4.x.orig/drivers/memstick/host/rtsx_usb_ms.c +++ usb-4.x/drivers/memstick/host/rtsx_usb_ms.c @@ -681,6 +681,7 @@ static int rtsx_usb_detect_ms_card(void int err; for (;;) { + pm_runtime_get_sync(ms_dev(host)); mutex_lock(&ucr->dev_mutex); /* Check pending MS card changes */ @@ -703,6 +704,7 @@ static int rtsx_usb_detect_ms_card(void } poll_again: + pm_runtime_put(ms_dev(host)); if (host->eject) break;