Please add the following text to section 2.2 "Risk and Assumptions"
of 2008/760 (without re-opening the case):
As of today, architecturally, there's no interface in the Solaris
acpica sub-system to quiesce or "re-init" data structures that are
out-of-sync with the platform state as part of a fast-reboot. CR
6760313 reports a result of not quiescing the ACPI CA
sub-system. However, the problem is potentially more difficult;
even given such an interface, it's not clear that system BIOSes
would universally be accustomed to the OS/ACPI subsystem
stopping/restarting/re-initializing.
Fortunately, the vast majority of BIOSes appear to be idempotent in
this regard.
However, BIOS may maintain "platform" state, with the inherent
assumption that this state is initialized during boot-up. Without
the BIOS being aware of a reboot, the "platform" state may not
properly synchronize with the ACPI namespace when it is
re-created.
Of perhaps more importance - after a reset, a system starts in
"Legacy" mode, which fundamentally means that platform-related
events (power button is the most common example) are handled by the
platform BIOS in SMM code. Starting-up ACPI, the system is
switched to ACPI mode, which permits the OS to handle events (like
the power button, and, on a very few systems for semi-obvious
reasons, thermal/fan control). So, the OS could see interrupt
requests earlier than expected, but we're relatively safe in that
respect.
Some (buggy) BIOSes might perturb the system hardware state as a
result of the Legacy->ACPI mode switch in totally unexpected ways.
It's unclear how that might manifest itself after a fast-reboot -
where the Legacy->ACPI mode switch almost certainly doesn't occur -
the platform had been in ACPI mode all along.
In short, there are risks to turn Fast Reboot on by default that
people should be aware. We do have several mechanism to disable
Fast Reboot should unforeseen problems arise:
a) Black-listing
b) Disabling the boot-config service
c) reboot -p
