Page MenuHomeFreeBSD

x86: Remove 1 second DELAY from cpu_reset
ClosedPublic

Authored by cperciva on Jul 13 2022, 12:44 AM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Mar 18, 12:43 AM
Unknown Object (File)
Jan 14 2024, 10:21 AM
Unknown Object (File)
Jan 3 2024, 12:21 AM
Unknown Object (File)
Dec 20 2023, 10:37 AM
Unknown Object (File)
Nov 18 2023, 8:44 PM
Unknown Object (File)
Nov 18 2023, 2:14 PM
Unknown Object (File)
Oct 27 2023, 11:33 PM
Unknown Object (File)
Oct 27 2023, 11:22 PM
Subscribers

Details

Summary

On SMP systems, cpu_reset broadcasts a message telling the BSPs to stop
themselves, and then the BSP waits 1 second before actually resetting
itself; this behaviour dates back to 1998-05-17.

I assume that this delay was added in order to allow the APs to stop
themselves before the BSP resets; but we wait until the APs have all
acknowledged entering the "stopped" state, so it no longer seems to
serve any purpose.

Sponsored by: https://www.patreon.com/cperciva

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Adding a few reviewers who know about low-level x86 stuff and might be able to speculate about any purpose the 1-second delay serves (if any).

So this delay only happens when cpu_reset() call itself occurs on BSP. Since cpu_reset_real() does enough delays, indeed I believe this one is not needed.

In the first line of the summary, I believe you mean APs, not BSPs. Also, don't we use EFI_RESET EFI runtime call on machines with EFI RT available? In other words, I suspect that this code is less and less relevant.

This revision is now accepted and ready to land.Jul 14 2022, 10:54 AM

I wonder if this was to give Tor a chance to see the printfs to make sure it was working as expected.

In D35797#812793, @kib wrote:

In the first line of the summary, I believe you mean APs, not BSPs.

Yes, thanks.

Also, don't we use EFI_RESET EFI runtime call on machines with EFI RT available? In other words, I suspect that this code is less and less relevant.

Could be. I noticed this delay with Firecracker, which doesn't have EFI (or ACPI, or even BIOS).

In D35797#812921, @jhb wrote:

I wonder if this was to give Tor a chance to see the printfs to make sure it was working as expected.

You're probably thinking of https://reviews.freebsd.org/D35796 (where I'm disabling-by-default an explicit "give the user a chance to read the console").

This revision was automatically updated to reflect the committed changes.