Dear Linux folks,
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”?
Kind regards,
Paul
On Wed, May 05, 2021 at 09:57:44AM +0200, Paul Menzel wrote:
> Dear Linux folks,
>
>
> 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. 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?
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?
thanks,
greg k-h
On Wed, May 05, 2021 at 10:27:52AM +0200, Paul Menzel wrote:
> 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?
No idea, it all depends on the device. And is 60ms really that long to
initialize the USB controller? That's a complex beast.
> > 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?
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.
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.
And is this really the slowest thing at startup for you that it is the
last thing that needs to be optimized?
> > 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.
No problem, I was confused as well :)
thanks,
greg k-h
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
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?
> 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.)
>>> 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.
> 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
> And is this really the slowest thing at startup for you that it is the
> last thing that needs to be optimized?
At least with decreasing SMP boot init time of the table, it was the
biggest issue. 400 ms to init on an (old) x86 desktop board seems quite
good. If you see something else in the attached log messages, I am all ears.
(By the way, as the harddisk is not encrypted, I am booting without initrd.)
Kind regards,
Paul
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
On Wed, May 05, 2021 at 02:31:56PM +0200, Greg Kroah-Hartman wrote:
> On Wed, May 05, 2021 at 02:15:26PM +0200, Paul Menzel wrote:
> > 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:
> > > > > 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.
I agree, this doesn't look like a "quirk" in the sense of working
around a hardware defect; the handoff is just a normal part of
operating the device. But can you elaborate on why it must be done
this way?
I'm looking at the xHCI r1.2 spec, sec 4.22.1. It talks about the
handoff synchronization process and says the OS driver shall use the
defined protocol to request ownership before it uses the device. But
AFAICT there's no specific "early-startup" requirement.
quirk_usb_handoff_xhci() is in drivers/usb/host/pci-quirks.c, which is
always built statically and the quirk runs during device enumeration,
even if the xhcd driver itself is a module. It looks like we run the
quirk even if we never load the xhcd driver.
Why can't we just do the handoff in the xhcd driver probe?
> > > 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 :)
So the answer is "to make Linux boot faster, flip this BIOS switch
which means your USB devices no longer work while in BIOS"?
I can see why this helps (BIOS never claims the xHCI, so OS can
immediately claim ownership), but it seems like a sub-optimal user
experience.
Bjorn
On Wed, May 05, 2021 at 10:47:41AM -0500, Bjorn Helgaas wrote:
> On Wed, May 05, 2021 at 02:31:56PM +0200, Greg Kroah-Hartman wrote:
> > On Wed, May 05, 2021 at 02:15:26PM +0200, Paul Menzel wrote:
> > > 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:
>
> > > > > > 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.
>
> I agree, this doesn't look like a "quirk" in the sense of working
> around a hardware defect; the handoff is just a normal part of
> operating the device. But can you elaborate on why it must be done
> this way?
>
> I'm looking at the xHCI r1.2 spec, sec 4.22.1. It talks about the
> handoff synchronization process and says the OS driver shall use the
> defined protocol to request ownership before it uses the device. But
> AFAICT there's no specific "early-startup" requirement.
>
> quirk_usb_handoff_xhci() is in drivers/usb/host/pci-quirks.c, which is
> always built statically and the quirk runs during device enumeration,
> even if the xhcd driver itself is a module. It looks like we run the
> quirk even if we never load the xhcd driver.
>
> Why can't we just do the handoff in the xhcd driver probe?
I think, if we don't do the handoff, then the BIOS/firmware tries to
send the OS fake keyboard/mouse commands, and Linux isn't ready for that
as we didn't allow hotplug PS/2 stuff. But I could be wrong, it's been
a long time since we did that logic.
Someone could try to change this and see :)
> > > > 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 :)
>
> So the answer is "to make Linux boot faster, flip this BIOS switch
> which means your USB devices no longer work while in BIOS"?
>
> I can see why this helps (BIOS never claims the xHCI, so OS can
> immediately claim ownership), but it seems like a sub-optimal user
> experience.
Welcome to UEFI :)
thanks,
greg k-h
On Wed, May 05, 2021 at 05:53:18PM +0200, Greg Kroah-Hartman wrote:
> On Wed, May 05, 2021 at 10:47:41AM -0500, Bjorn Helgaas wrote:
> > On Wed, May 05, 2021 at 02:31:56PM +0200, Greg Kroah-Hartman wrote:
> > > On Wed, May 05, 2021 at 02:15:26PM +0200, Paul Menzel wrote:
> > > > 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:
> >
> > > > > > > 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.
> >
> > I agree, this doesn't look like a "quirk" in the sense of working
> > around a hardware defect; the handoff is just a normal part of
> > operating the device. But can you elaborate on why it must be done
> > this way?
> >
> > I'm looking at the xHCI r1.2 spec, sec 4.22.1. It talks about the
> > handoff synchronization process and says the OS driver shall use the
> > defined protocol to request ownership before it uses the device. But
> > AFAICT there's no specific "early-startup" requirement.
> >
> > quirk_usb_handoff_xhci() is in drivers/usb/host/pci-quirks.c, which is
> > always built statically and the quirk runs during device enumeration,
> > even if the xhcd driver itself is a module. It looks like we run the
> > quirk even if we never load the xhcd driver.
> >
> > Why can't we just do the handoff in the xhcd driver probe?
>
> I think, if we don't do the handoff, then the BIOS/firmware tries to
> send the OS fake keyboard/mouse commands, and Linux isn't ready for that
> as we didn't allow hotplug PS/2 stuff. But I could be wrong, it's been
> a long time since we did that logic.
I have no idea what "BIOS/firmware sending OS fake keyboard/mouse
commands" means. From the OS point of view, does that look like USB
events that cause PCI interrupts? PS/2 interrupts? Are these
commands caused by the user typing or moving the mouse? Or does BIOS
fabricate commands for other reasons?
The way you describe it, this *sounds* like a race, where Linux
mishandles commands that happen before the handoff quirk. Do you
remember what happens if BIOS sends a fake command before Linux is
ready for it? Unexpected interrupt?
Bjorn
On Thu, May 06, 2021 at 10:23:00AM -0500, Bjorn Helgaas wrote:
> On Wed, May 05, 2021 at 05:53:18PM +0200, Greg Kroah-Hartman wrote:
> > I think, if we don't do the handoff, then the BIOS/firmware tries to
> > send the OS fake keyboard/mouse commands, and Linux isn't ready for that
> > as we didn't allow hotplug PS/2 stuff. But I could be wrong, it's been
> > a long time since we did that logic.
>
> I have no idea what "BIOS/firmware sending OS fake keyboard/mouse
> commands" means. From the OS point of view, does that look like USB
> events that cause PCI interrupts? PS/2 interrupts? Are these
> commands caused by the user typing or moving the mouse? Or does BIOS
> fabricate commands for other reasons?
Think of an old MSDOS operating system without USB support. The BIOS
tries to be helpful by translating mouse and keyboard input it receives
over USB into PS/2 events that the operating system can handle.
Originally this was done using SMI; now it presumably is still a legacy
part of UEFI.
> The way you describe it, this *sounds* like a race, where Linux
> mishandles commands that happen before the handoff quirk. Do you
> remember what happens if BIOS sends a fake command before Linux is
> ready for it? Unexpected interrupt?
I would be surprised if anybody still knows. :-)
Perhaps a reasonable experiment would be to boot a kernel with PS/2
support but not USB support (or at least, without CONFIG_USB_PCI) and
see what happens when you type on the USB keyboard or move the USB
mouse.
It might very well turn out that the handoff operation can safely be
delayed until driver probe time.
Alan Stern