From: Paul Menzel <pmenzel@molgen.mpg.de>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
Mathias Nyman <mathias.nyman@intel.com>,
linux-pci@vger.kernel.org
Subject: Re: `quirk_usb_handoff_xhci` takes 60 ms with ASM1042
Date: Wed, 5 May 2021 10:27:52 +0200 [thread overview]
Message-ID: <e4d36cdd-3998-3ed3-76d9-56541d89a182@molgen.mpg.de> (raw)
In-Reply-To: <YJJTQzJS/8Loz8kV@kroah.com>
Dear Greg,
Thank you for the quick reply.
Am 05.05.21 um 10:11 schrieb Greg Kroah-Hartman:
> On Wed, May 05, 2021 at 09:57:44AM +0200, Paul Menzel wrote:
>> On an Asus F2A85-M PRO, BIOS 6601 11/25/2014, with an ASM1042 SuperSpeed USB
>> Host Controller [1b21:1042], and the xHCI drivers built as modules
>>
>> CONFIG_USB_XHCI_PCI=m
>> CONFIG_USB_XHCI_HCD=m
>>
>> `quirk_usb_handoff_xhci` takes 60 ms, which is 15 % of the time to reaching
>> `run_init_process()`. I addded some prints, showing the f
>>
>> [ 0.308841] pci 0000:03:00.0: PCI->APIC IRQ transform: INT A -> IRQ 17
>> [ 0.369858] pci 0000:03:00.0: handshake done with timeout = 0
>> [ 0.369862] pci 0000:03:00.0: hc_init reached
>> [ 0.369865] pci 0000:03:00.0: second handshake done
>> [ 0.369869] pci 0000:03:00.0: third handshake done
>> [ 0.369909] pci 0000:03:00.0: quirk_usb_early_handoff+0x0/0x670 took 59661 usecs
>> […]
>> [ 0.415223] Run /lib/systemd/systemd as init process
>>
>> Is there a way to optimize this, or move it out “the hot path”?
>
> That's the hardware taking so long, all that function does is make some
> PCI calls to the device.
In your experience, do most devices take that long?
> If the driver is built as a module, there should not be any "hot
> path" here as the module is loaded async when the device is
> discovered, right?
obj-$(CONFIG_USB_PCI) += pci-quirks.o
So all quirks are run independently of the USB “variant” (UHCI, OHCI,
EHCI, xHCI).
Indeed, this driver is built into the Linux kernel.
$ grep USB_PCI .config
CONFIG_USB_PCI=y
So, should `pci-quirks.c` be split up to have more fine grained control?
> What is waiting for this module to load in order to cause your init to
> stall? Perhaps fix your initramfs logic or build the driver into the
> kernel itself to take it off of this "load all the modules and wait"
> path?
Sorry, for causing some confusion. But as written above, this all
happens before the initrd is involved.
Kind regards,
Paul
next prev parent reply other threads:[~2021-05-05 8:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-05 7:57 `quirk_usb_handoff_xhci` takes 60 ms with ASM1042 Paul Menzel
2021-05-05 8:11 ` Greg Kroah-Hartman
2021-05-05 8:27 ` Paul Menzel [this message]
2021-05-05 8:33 ` Greg Kroah-Hartman
2021-05-05 12:15 ` Paul Menzel
2021-05-05 12:31 ` Greg Kroah-Hartman
2021-05-05 15:47 ` Bjorn Helgaas
2021-05-05 15:53 ` Greg Kroah-Hartman
2021-05-06 15:23 ` Bjorn Helgaas
2021-05-06 15:59 ` Alan Stern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e4d36cdd-3998-3ed3-76d9-56541d89a182@molgen.mpg.de \
--to=pmenzel@molgen.mpg.de \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).