Re: `quirk_usb_handoff_xhci` takes 60 ms with ASM1042
From: Greg Kroah-Hartman
Date: Wed May 05 2021 - 08:32:03 EST
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