acpi: Create cppc_notify sysctl before it is checked

[thj]

Summary

Comment #74 on the original issue points out that we are creating/checking
the sysctl after we have configured the notifications on the core.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253288#c74

Move the sysctl creation up to so it is created when the cpu tree is created.
This makes the cppc_notify field only available globally, but I prefer this, it
makes it easier to disable this workaround and it is unlikely that mixing
enabling/disabling these notifications per core is going to make buggy SMMs
happy.

[jhb]

I think the old sysctl was also already global and not per-CPU (just affects the log message I think)

[henrix_camandro.org]

Thanks a lot for this, @thj! I can confirm that this change does indeed help with my hardware. I've tested it, I've been using this patch for a few hours now without any system hanging.

Also, using the debug patch I posted in bug #253288 it looks like messages ordering is now correct, i.e., first we get the sysctl creation.

However, there's another interesting thing I'm seeing that I can't explain, but I'm new to ACPI and FreeBSD kernel code. What I see occasionally is that is sometimes the sysctl creation occurs twice. Here's an example:

$ dmesg | grep DEBUG
cpu0: ==> DEBUG init cppc_notify: 1
cpu0: ==> DEBUG: OK
cpu1: ==> DEBUG: OK
cpu2: ==> DEBUG: OK
cpu3: ==> DEBUG: OK
cpu0: ==> DEBUG init cppc_notify: 1
cpu0: ==> DEBUG: OK
cpu1: ==> DEBUG: OK
cpu2: ==> DEBUG: OK
cpu3: ==> DEBUG: OK

My theory (which I haven't tested it thoroughly, so it can be wrong) is that this tends to happen when a do a simple reboot command. If I do a full shutdown, the next boot will show only a single set, i.e:

cpu0: ==> DEBUG init cppc_notify: 1
cpu0: ==> DEBUG: OK
cpu1: ==> DEBUG: OK
cpu2: ==> DEBUG: OK
cpu3: ==> DEBUG: OK

Maybe that's how it works, just yet another BIOS annoyance, but I thought I should mention it here.

Again, thanks!