Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp724692pxb; Fri, 14 Jan 2022 15:04:46 -0800 (PST) X-Google-Smtp-Source: ABdhPJzirj+7Y2tHpJ+hw4rAMFiQdZKUkikSGWIJrmwxCZdPzrCMqUtDiIxt0PNoNmCJ+CJC8sWE X-Received: by 2002:a05:6a00:23c2:b0:4c1:3c25:6b65 with SMTP id g2-20020a056a0023c200b004c13c256b65mr11147827pfc.78.1642201486697; Fri, 14 Jan 2022 15:04:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642201486; cv=none; d=google.com; s=arc-20160816; b=CPGPbgkbXckeHtJcGrUY05nOhrjP6zIo/r4U1Grr/1ugXHVLNT2GS4oK/gEQ/FqC1A ZnA/3lVtpjRBxjGjtvMSlUwcbdpBxN1hEe2a8tEQ3PJcVcyC1ij6s0nLiMf28aFqGf80 9s+ozQsCha6P7Dk61ILfpnVqBOIAKJ17UsiDJV2NdSwNHcEOMG8zSTypfU7zIUG0mWBK XCYrDDml2jPRh/AoMzhbPt2JHQuEgTA3vcpXZzcVDYkpCB+80hCJtG67U1XikazHbF4M XF/YyIjIfnk1QLqBVyNAPufBav5dE3f3rkIFv+0gHG/8aTSUdNEGUIDpYN+9T+KYLC38 N7AA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:subject:from :references:cc:to:dkim-signature; bh=VwNFvMTQkbPB8x+fVI8K0pVX+J3DiAlIbIN6J465iEs=; b=wiT7Hz/e9vr4kQm504UU8p4I4Cng7JAY+J7pF9BLpyvA6khgBSp0CuY1b2c58wRFPh UR7od+BDXyJRWzmkywiDo4U0mfVHx1jpoL1Qlw83oBhjw5rvb12zDMLrjj1E5JqUDxP6 v9/OVpfGHBroqURSwTS2KbjJ7lkd10fLUdI8YbD/F3fLJrBBD5tcqtohrzIO3AC7wae/ w+rmcWSql8ozm3Cywnw4Ok/hyECT7i7wDh1KZw43E0Zih9JoYv6mFcggg3pKJwyUzcJm 0z4CHQ7C9NacPSJIeDJ10PA6kNNmGdHXAU/rsq0VaJxkljcTqGTAG3BMZ2Od2ir9hri0 OsTQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=eByvmOD7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s17si6233409pgk.466.2022.01.14.15.04.34; Fri, 14 Jan 2022 15:04:46 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=eByvmOD7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244106AbiANT3y (ORCPT + 99 others); Fri, 14 Jan 2022 14:29:54 -0500 Received: from mga06.intel.com ([134.134.136.31]:63106 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232351AbiANT3x (ORCPT ); Fri, 14 Jan 2022 14:29:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1642188593; x=1673724593; h=to:cc:references:from:subject:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=XOj6k0Xo4PFVlZlfpTezZimtakW+VvnjEotmeHkYF34=; b=eByvmOD7dtOhjTfn3nwH4WQ6IOsLjKo8K8r4N9TOEEDpLmxe0indOW9Q Ay+1enGrS9fNSAA1Car6Ra/4U1Fzhoix0GZmQz2jeupEcdbybFO2rQ5tU p+HXg8LDorXdNOt66VBriiU8WZaipRPSXNyZx0R/QNty+jzfof8tzEpbI zi/hxDSQA7iZrctJX1ZzOYem5Op77R92rn36q86UobjIfxbP7k3eotCwN tIX0jVzn60oJmZ0dDuolUz+tEoqRZL8rFBDl/15X/9q2kq6LzkPR3oEHC e0VvwCa75YhBpi4IIIvH+wejpP0lFj2RrbZIr+uROQoEaNd0/8wYAFx3+ A==; X-IronPort-AV: E=McAfee;i="6200,9189,10227"; a="305044543" X-IronPort-AV: E=Sophos;i="5.88,289,1635231600"; d="scan'208";a="305044543" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jan 2022 11:29:52 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.88,289,1635231600"; d="scan'208";a="624454211" Received: from mattu-haswell.fi.intel.com (HELO [10.237.72.199]) ([10.237.72.199]) by orsmga004.jf.intel.com with ESMTP; 14 Jan 2022 11:29:50 -0800 To: Peter Zijlstra Cc: Greg KH , Dave Hansen , Lu Baolu , x86@kernel.org, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, Chunfeng Yun References: <105f35d2-3c53-b550-bfb4-aa340d31128e@linux.intel.com> <88f466ff-a065-1e9a-4226-0abe2e71b686@linux.intel.com> <972a0e28-ad63-9766-88da-02743f80181b@intel.com> From: Mathias Nyman Subject: Re: earlyprintk=xdbc seems broken Message-ID: Date: Fri, 14 Jan 2022 21:31:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 14.1.2022 10.47, Peter Zijlstra wrote: > On Tue, Dec 21, 2021 at 10:40:50AM +0100, Peter Zijlstra wrote: >> On Fri, Dec 17, 2021 at 02:55:07PM +0100, Peter Zijlstra wrote: >>> On Fri, Dec 17, 2021 at 01:01:43PM +0200, Mathias Nyman wrote: >>>> I can reproduce this. >>>> Looks like problems started when driver converted to readl_poll_timeout_atomic() in: >>>> >>>> 796eed4b2342 usb: early: convert to readl_poll_timeout_atomic() >>> >>> I can confirm, reverting that solves the boot hang, things aren't quite >>> working for me though. >> >> I've been poking at this a little, find debug patch and full dmesg >> below. The TL;DR version of the dmesg seems to be: >> >> [ 4.984148] xhci_dbc:xdbc_start: waiting for connection timed out >> [ 4.984149] xhci_dbc:early_xdbc_setup_hardware: failed to setup the connection to host >> >> Initially I thought this was due to delay not being set up properly, but >> I 'fixed' that, and I've ran out of ideas. I really don't know anything >> about USB :/ > > Any thoughts on this? I'd really like to be able to use this machine but > can't due to lack of console. > Tried to reproduce this with another cable that should have all pins connected, but it still workes for me. It looks like the connection is not even detected in your case. What does the host say? If the cable is connected before CTRL_DBC_ENABLED bit is written on the target side, then the link should go to a inactive "error" state. Host should try to recover the inactive link with a warm reset. On host side dynamic debug for usb core and xhci can be added with: echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control echo -n 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control xHCI documentation also states that Debug capability enable bit (CTRL_DBC_ENABLE) could be toggled to retry failed enumeration. The non-early dbc that works for you does clear the control register before enabling the debug capability, and it also skips port reset. Something like the below could be worth trying out: 8<--- diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c index 4502108069cd..8969c88e8c24 100644 --- a/drivers/usb/early/xhci-dbc.c +++ b/drivers/usb/early/xhci-dbc.c @@ -419,7 +419,9 @@ static int xdbc_start(void) { u32 ctrl, status; int ret; + bool first_try = true; +retry: ctrl = readl(&xdbc.xdbc_reg->control); writel(ctrl | CTRL_DBC_ENABLE | CTRL_PORT_ENABLE, &xdbc.xdbc_reg->control); ret = handshake(&xdbc.xdbc_reg->control, CTRL_DBC_ENABLE, CTRL_DBC_ENABLE, 100000, 100); @@ -429,13 +431,21 @@ static int xdbc_start(void) } /* Reset port to avoid bus hang: */ - if (xdbc.vendor == PCI_VENDOR_ID_INTEL) + if (xdbc.vendor == PCI_VENDOR_ID_INTEL && first_try) xdbc_reset_debug_port(); /* Wait for port connection: */ ret = handshake(&xdbc.xdbc_reg->portsc, PORTSC_CONN_STATUS, PORTSC_CONN_STATUS, 5000000, 100); if (ret) { - xdbc_trace("waiting for connection timed out\n"); + xdbc_trace("waiting for connection timed out, DCPORTSC:0x%x\n", + readl(&xdbc.xdbc_reg->portsc)); + if (first_try) { + first_try = false; + /* Toggle DCE and retry without port reset */ + writel(0, &xdbc.xdbc_reg->control); + handshake(&xdbc.xdbc_reg->control, CTRL_DBC_ENABLE, 0, 100000, 10); + goto retry; + } return ret; }