Received: by 2002:a17:90a:88:0:0:0:0 with SMTP id a8csp78087pja; Fri, 22 Nov 2019 03:43:37 -0800 (PST) X-Google-Smtp-Source: APXvYqzGoBsfc9Zpw5xDGEaeChnI1z2D7XQPOqIi01f/jXNsVSC5acvzDxu1S5rt1ZmgDuhpLHL1 X-Received: by 2002:a50:b63b:: with SMTP id b56mr504577ede.165.1574423016920; Fri, 22 Nov 2019 03:43:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574423016; cv=none; d=google.com; s=arc-20160816; b=GuOh6mbuXwxd7TDpKQbAb1EK9rkwB0j9VI7jVelYUN+9VBMveMdeQXRYmDlun6ZJ12 eBNje1VBEucfPjGvKWzhSVSxaA4DJyvbzBj7UFnAtArK85DmYD6uZ+NF37mipdoPP4JA RmyxGBMG08rksr+Uwm+FQTGVpeMu8fwbGShiW/rZz1dagBiwLAsKIJohmYpMpI9BzQG1 dyfGxbhQseXlxVy96KIlIZn9nigTf9AarB1hqA9rRDZLPAndmBxT4A9TDC+kRfHLvtye 8jIkVFY6nbPnJOSerBNzTCP3iAZVeVv0gu/E8rMu80OCmd/SClV9f3MJgRJnFFkCY2wV eQVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:organization:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=Vq7TxR4n6oMRYoJrGqlsUGSiCDp607TZNjJZtCWaCLk=; b=fCjF77fpec1JgZpmc3a6ctQj5hXodZD2LjJQJG7pd9qeam6ZeAUKLJ2gh4jPHpUXtO 5FsDd2CSIhtrTYIHsCiygapvji1SXHzbglzHW2voHhk+gY7ONNw9QA6N2y8RH7Gn4r00 dO3KxrQVW/+TUl64e+IrvpRnfFj0i0rJ/YbBcyhsfwcq59uwio9LjlRlhpmUFmbmOk7T cmhizuzEHJm7LzGdAH+ffm5CNZjuSue5hW59Maq9IQzQ5CT0ymfjhSnEPflCGDF3kMfI oFhHqmBlRyjo+uwH8rx/+UaTqzIPj7kj3dibt3KwVn8JhjdYVECGEYuAlF0Adj3vfYHz NyBA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y3si4206990edv.423.2019.11.22.03.43.12; Fri, 22 Nov 2019 03:43:36 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727242AbfKVLlQ (ORCPT + 99 others); Fri, 22 Nov 2019 06:41:16 -0500 Received: from mga18.intel.com ([134.134.136.126]:50930 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726548AbfKVLlP (ORCPT ); Fri, 22 Nov 2019 06:41:15 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Nov 2019 03:41:14 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,229,1571727600"; d="scan'208";a="216349730" Received: from lahna.fi.intel.com (HELO lahna) ([10.237.72.163]) by fmsmga001.fm.intel.com with SMTP; 22 Nov 2019 03:41:09 -0800 Received: by lahna (sSMTP sendmail emulation); Fri, 22 Nov 2019 13:41:08 +0200 Date: Fri, 22 Nov 2019 13:41:08 +0200 From: Mika Westerberg To: Paul Menzel Cc: Mario Limonciello , Andreas Noever , Michael Jamet , Yehezkel Bernat , Christian Kellner , linux-kernel@vger.kernel.org, Anthony Wong , Mathias Nyman Subject: Re: USB devices on Dell TB16 dock stop working after resuming Message-ID: <20191122114108.GG11621@lahna.fi.intel.com> References: <20191104154446.GH2552@lahna.fi.intel.com> <20191104162103.GI2552@lahna.fi.intel.com> <20191120105048.GY11621@lahna.fi.intel.com> <20191122105012.GD11621@lahna.fi.intel.com> <20191122112921.GF11621@lahna.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.12.1 (2019-06-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 22, 2019 at 12:33:44PM +0100, Paul Menzel wrote: > Dear Mika, > > > On 2019-11-22 12:29, Mika Westerberg wrote: > > On Fri, Nov 22, 2019 at 12:05:13PM +0100, Paul Menzel wrote: > > >> On 2019-11-22 11:50, Mika Westerberg wrote: > >>> On Wed, Nov 20, 2019 at 12:50:53PM +0200, Mika Westerberg wrote: > >>>> On Tue, Nov 19, 2019 at 05:55:43PM +0100, Paul Menzel wrote: > >> > >>>>> On 2019-11-04 17:21, Mika Westerberg wrote: > >>>>>> On Mon, Nov 04, 2019 at 05:11:10PM +0100, Paul Menzel wrote: > >>>>> > >>>>>>> On 2019-11-04 16:49, Mario.Limonciello@dell.com wrote: > >>>>>>> > >>>>>>>>> From: Mika Westerberg > >>>>>>>>> Sent: Monday, November 4, 2019 9:45 AM > >>>>>>> > >>>>>>>>> On Mon, Nov 04, 2019 at 04:44:40PM +0200, Mika Westerberg wrote: > >>>>>>>>>> On Mon, Nov 04, 2019 at 04:25:03PM +0200, Mika Westerberg wrote: > >>>>>>> > >>>>>>>>>>> On Mon, Nov 04, 2019 at 02:13:13PM +0100, Paul Menzel wrote: > >>>>>>> > >>>>>>>>>>>> On the Dell XPS 13 9380 with Debian Sid/unstable with Linux 5.3.7 > >>>>>>>>>>>> suspending the system, and resuming with Dell’s Thunderbolt TB16 > >>>>>>>>>>>> dock connected, the USB input devices, keyboard and mouse, > >>>>>>>>>>>> connected to the TB16 stop working. They work for a few seconds > >>>>>>>>>>>> (mouse cursor can be moved), but then stop working. The laptop > >>>>>>>>>>>> keyboard and touchpad still works fine. All firmware is up-to-date > >>>>>>>>>>>> according to `fwupdmgr`. > >>>>>>>>>>> > >>>>>>>>>>> What are the exact steps to reproduce? Just "echo mem > > >>>>>>>>>>> /sys/power/state" and then resume by pressing power button? > >>>>>>> > >>>>>>> GNOME Shell 3.34.1+git20191024-1 is used, and the user just closes the > >>>>>>> display. So more than `echo mem > /sys/power/state` is done. What > >>>>>>> distribution do you use? > >>>>>> > >>>>>> I have buildroot based "distro" so there is no UI running. > >>>>> > >>>>> Hmm, this is quite different from the “normal” use-case of the these devices. > >>>>> That way you won’t hit the bugs of the normal users. ;-) > >>>> > >>>> Well, I can install some distro to that thing also :) I suppose Debian > >>>> 10.2 does have this issue, no? > >>>> > >>>>>>>>>> I tried v5.4-rc6 on my 9380 with TB16 dock connected and did a couple of > >>>>>>>>>> suspend/resume cycles (to s2idle) but I don't see any issues. > >>>>>>>>>> > >>>>>>>>>> I may have older/different firmware than you, though. > >>>>>>>>> > >>>>>>>>> Upgraded BIOS to 1.8.0 and TBT NVM to v44 but still can't reproduce this > >>>>>>>>> on my system :/ > >>>>>>> > >>>>>>> The user reported the issue with the previous firmwares 1.x and TBT NVM v40. > >>>>>>> Updating to the recent version (I got the logs with) did not fix the issue. > >>>>>> > >>>>>> I also tried v40 (that was originally on that system) but I was not able > >>>>>> to reproduce it. > >>>>>> > >>>>>> Do you know if the user changed any BIOS settings? > >>>>> > >>>>> We had to disable the Thunderbolt security settings as otherwise the USB > >>>>> devices wouldn’t work at cold boot either. > >>>> > >>>> That does not sound right at all. There is the preboot ACL that allows > >>>> you to use TBT dock aready on boot. Bolt takes care of this. > >>>> > >>>> Are you talking about USB devices connected to the TB16 dock? > >>>> > >>>> Also are you connecting the TB16 dock to the Thunderbolt ports (left > >>>> side of the system marked with small lightning logo) or to the normal > >>>> Type-C ports (right side)? > >>>> > >>>>> So, I built Linux 5.4-rc8 (`make bindeb-pkg -j8`), but unfortunately the > >>>>> error is still there. Sometimes, re-plugging the dock helped, and sometimes > >>>>> it did not. > >>>>> > >>>>> Please find the logs attached. The strange thing is, the Linux kernel detects > >>>>> the devices and I do not see any disconnect events. But, `lsusb` does not list > >>>>> the keyboard and the mouse. Is that expected. > >>>> > >>>> I'm bit confused. Can you describe the exact steps what you do (so I can > >>>> replicate them). > >>> > >>> I managed to reproduce following scenario. > >>> > >>> 1. Boot the system up to UI > >>> 2. Connect TB16 dock (and see that it gets authorized by bolt) > >>> 3. Connect keyboard and mouse to the TB16 dock > >>> 4. Both mouse and keyboard are functional > >>> 5. Enter s2idle by closing laptop lid > >>> 6. Exit s2idle by opening the laptop lid > >>> 7. After ~10 seconds or so the mouse or keyboard or both do not work > >>> anymore. They do not respond but they are still "present". > >>> > >>> The above does not happen always but from time to time. > >>> > >>> Is this the scenario you see as well? > >> > >> Yes, it is. Though I’d say it’s only five seconds or so. > >> > >>> This is on Ubuntu 19.10 with the 5.3 stock kernel. > >> > >> “stock” in upstream’s or Ubuntu’s? > > > > It is Ubuntu's. > > > >>> I can get them work again by unplugging them and plugging back (leaving > >>> the TBT16 dock connected). Also if you run lspci when the problem > >>> occurs it still shows the dock so PCIe link stays up. > >> > >> Re-connecting the USB devices does not help here, but I still suspect it’s > >> the same issue. > > > > Yeah, sounds like so. Did you try to connect the device (mouse, > > keyboard) to another USB port? > > I do not think I did, but I can’t remember. Next week would be the next chance > to test this. > > >> Yesterday, I had my hand on a Dell XPS 13 7390 (10th Intel generation) and > >> tried it with the shipped Ubuntu 18.04 LTS. There, the problem was not > >> always reproducible, but it still happened. Sometimes, only one of the USB > >> device (either keyboard or mouse) stopped working. > > > > I suppose this is also with the TB16 dock connected, correct? > > Correct. > > Can I ask again, how the USB devices connected to the dock can be listed on > the command line? lsusb needs to be adapted for that or is a different > mechanism needed? The TB16 dock has ASMEDIA xHCI controller, which is PCIe device so you can see it by running lsusb and looking at the devices under that controller. I think maybe 'lsusb -t' is helpful. The xHCI controller itself you can see by running lspci.