On Wed, May 05, 2021 at 02:15:26PM +0200, Paul Menzel wrote: > Dear Greg, > > > Am 05.05.21 um 10:33 schrieb Greg Kroah-Hartman: > > On Wed, May 05, 2021 at 10:27:52AM +0200, Paul Menzel wrote: > > > > 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? > > > > No idea, it all depends on the device. And is 60ms really that long to > > initialize the USB controller? > > For the goal of “instant” startup, I’d say yes. > > I also guess, this is all the ASMedia ASM1042 firmware taking so long, > right? Probably, yes. And you proved that below.... > > That's a complex beast. > > I miss the PS/2 controller, which seemed to be simpler for *input* devices > like keyboard and mouse. (No idea regarding power usage even.) The PS/2 controller was horrible, even for keyboard and mice. Many motherboards and devices were blown up by hot-plugging them. There's a reason we all came up with USB back in the day, please don't make us go back to that mess... > > > > 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 control do you need here? > > Good question, as I do not know the USB spec. I’d say, disabling certain > quirks, or just run them, when the actual driver is loaded. This is not a "quirk", it is part of how USB works. > > And yeah, I see, but this code has to be run at early-startup to match > > the USB spec requirements for handing off the USB control from the > > BIOS/firmware/whatever, to the kernel. > > That makes the second option above a moot point. > > > Try changing your BIOS settings to not have "legacy" USB support in it, > > that could cause this transition to go faster, at the expense of not > > being able to use a USB device before Linux boots. > > The firmware of the Asus F2A85-M PRO allows to disable *legacy* USB support > for only the ASMedia ASM1042. And, thank you for the suggestion, it helped. > `quirk_usb_early_handoff()` does not show up in the logs now, meaning it’s > below 50 ms. And it is well below: less than one millisecond. > > [ 0.308343] pci 0000:00:15.1: PCI->APIC IRQ transform: INT A -> IRQ > 16 > [ 0.308359] pci 0000:03:00.0: PCI->APIC IRQ transform: INT A -> IRQ > 17 > [ 0.308376] pci 0000:03:00.0: hc_init reached > [ 0.308380] pci 0000:03:00.0: second handshake done > [ 0.308384] pci 0000:03:00.0: third handshake done > [ 0.308395] PCI: CLS 64 bytes, default 64 > […] > [ 0.401722] Run /lib/systemd/systemd as init process Nice! Go blame your bios vendor now :) But realize just what is happening here, the hand-off of the USB hardware from one "owner" to another is not a trivial operation. Gotta love solutions that don't touch the kernel, thanks for following up and letting us know. greg k-h
