3

I have a Fedora 32 install with a HP Probook 450 G0. The BIOS with administrator privileges does not let me disable "fast boot". Why not? What to do? Somehow my Fedora turns on automatically again after shutting down, and within 3 seconds. So I figured it had to do with my enabled "fast boot", but unfortunately there is no way to disable it. My other settings:

  • Wake on LAN > follow boot order
  • enabled Embedded WLAN device
  • enabled Embedded LAN controller
  • USB device boot
  • Customised boot
  • "Fast boot" is enabled
  • Secure boot is OFF
  • Boot mode > UEFI native (without CSM)
  • UEFI boot order > Generic USB device > Customised boot > OS Boot manager

As said, I enter my BIOS as an "administrator". I have DriveLock enabled and set a password too (= that was a requirement for "fast boot" to turn on/off).

2
  • As this is a BIOS question, please ask in a dedicated website, not unix.stackexchange.com.
    – Stefan M
    Nov 1, 2021 at 0:43
  • Fedora 32 is no longer supported (since May), it is recommended to upgrade to at least Fedora 33, preferably to Fedora 34.
    – Jeroen
    Nov 1, 2021 at 10:49

1 Answer 1

4

This sounds just like the problem I had with my previous home desktop system.

HP Probook 450 G0 uses a Mobile Intel HM76 Express chipset, which is also known by Intel development codename "Panther Point". My desktop that had this problem also had a Panther Point chipset.

The actual problem is that the XHCI USB controllers of the Panther Point and Lynxpoint chipsets need to be shut down in a particular, controlled way, or else they will promptly wake up the system again. Infuriatingly, different versions of the chipsets will need different shutdown steps, and the fix for one version actually triggers the problem for another. Some (perhaps most?), but not all, BIOSes handle it automatically, so the problem only exists on some subset of systems using these chipsets.

You'll find a long discussion about this problem in: https://bugzilla.kernel.org/show_bug.cgi?id=66171

In a nutshell, there are two quirks defined in the Linux XHCI driver code for this issue: XHCI_SPURIOUS_WAKEUP and XHCI_SPURIOUS_REBOOT. Depending on the exact chipset version, you might need one or both of these quirks enabled.

You can enable the XHCI_SPURIOUS_REBOOT quirk by /etc/modprobe.d/*.conf line options xhci-hcd quirks=8192, or with kernel boot option xhci_hcd.quirks=8192.

To activate the XHCI_SPURIOUS_WAKEUP option, use the value 262144 in place of 8192; to activate both quirks at once, use the value 270336 (= the sum of the two values).

Try the kernel boot option route first: it will work regardless of whether the XHCI driver is built into the main kernel or loaded as a kernel module. If you find an option that fixes it for you, adding it to a /etc/modprobe.d/*.conf file might be a "cleaner" way to make it persistent if the XHCI driver is loaded as a module.

Since USB drivers are essential for USB keyboards, the XHCI driver may get loaded early in initramfs phase of the boot process, so after making a change to /etc/modprobe.d/*.conf, remember to rebuild your initramfs file (dracut is the current initramfs tool in Fedora, I think?).

Leaving the XHCI driver unloaded will also exhibit the problem, as with no XHCI driver present, the kernel won't know that the XHCI controller needs special attention at shutdown.

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.