From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751366AbeAAPrW (ORCPT + 1 other); Mon, 1 Jan 2018 10:47:22 -0500 Received: from netrider.rowland.org ([192.131.102.5]:60949 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751243AbeAAPrU (ORCPT ); Mon, 1 Jan 2018 10:47:20 -0500 Date: Mon, 1 Jan 2018 10:47:19 -0500 (EST) From: Alan Stern X-X-Sender: stern@netrider.rowland.org To: Paul Menzel cc: Bjorn Helgaas , , , David Woodhouse , Andy Shevchenko , Subject: Re: `pci_apply_final_quirks()` taking half a second In-Reply-To: <92dff466-d0a5-b30c-4d47-48584fac579e@molgen.mpg.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Mon, 1 Jan 2018, Paul Menzel wrote: > > So they are OHCI controllers. You could add some debugging statements > > to quirk_usb_handoff_ohci() to try and locate the part that's taking so > > long. > > As you suggested debugging statements, I guess the Linux kernel doesn’t > offer other ways to instrument functions without modifying the source code. It does. Look into ftrace, for example. However, ftrace only provides tracing at the level of function calls (hence the name -- "ftrace" for "function trace"), not for individual statements within a function. There are other facilities as well, but none of them are likely to help here. > Is it possible to only rebuild the module somehow or is the early > handoff stuff not a module? It is not a module. > > It's also worth mentioning that the same source file contains lots of > > special-case code for AMD and ASmedia hardware. I don't know whether > > any of it is involved in the long time delays you are seeing, however. > > Thank you for already looking into this. I haven’t had to time to read > the commit messages, which might shed some light into the reasoning. Good luck! Alan Stern