This section defines minimum memory requirements for server systems.
Note: It is recognized that OEMs supply systems with specific feature requirements to corporations, which can include providing servers that do not include any memory pre-installed before shipping. However, for testing purposes, the system must include the minimum required components.
5 Installed system memory meets minimum requirements
Recommended: Larger installed memory configurations, which will increase performance.
All memory visible to the operating system as system memory must be cacheable. All system memory except for 4 MB must be completely available for the system to use at boot time and cannot be locked from use by the operating system.
Note: This minimum requirement for memory available to the operating system does not preclude applications that use dynamically allocated memory for temporary uses.
6 System memory capacity meets minimum requirements
This requirement defines minimum RAM expansion capabilities. For multiprocessor systems, 256 MB is required for each multiprocessor. All memory visible to the operating system as system memory must be cacheable.
7 System memory includes ECC memory protection
The system memory and cache must be protected with Error Correction Code (ECC) memory protection. All ECC RAM visible to the operating system must be cacheable. The ECC hardware must have the ability to detect a double-bit error in one word and to correct a single-bit error in one word, where “word” means the width in bits of the memory subsystem. To detect the failure of a single dynamic RAM (DRAM) device, the ECC must be capable of detecting a 4‑bit or 8‑bit error in one word, with detection of 4‑bit errors preferred. A detected error that cannot be corrected must result in a system fault.
Configuration and Power Management Requirements
This section specifies requirements for system configuration at startup time and for power management.
ACPI and Power Management Requirements
This section defines the system and BIOS requirements for ACPI and power management.
8 System design meets ACPI 1.0 specification and related requirements
The system board must support the Advanced Configuration and Power Interface Specification, Version 1.0 or higher. This requirement ensures that the system correctly supports the Plug and Play and power-management functionality described in this guide. The differences between the ACPI support required on a SOHO server and the support required for Basic servers are defined in Chapter 8, “SOHO System Requirements.”
ACPI support for Basic server systems must include the following required capabilities:
A power-management timer. System control interrupt and necessary Status and Enable (STS/EN) bits must be provided.
Support for a description table that defines the complete hierarchy for system-board devices (including host PCI bridges). The description table must include all non-Plug and Play devices to be enumerated and all other devices for which power management or removal capabilities have been added by the system-board design.
Each bus and device enumerated using ACPI includes the ACPI control methods necessary to configure these devices. This includes requirements defined in these guidelines for automatic device configuration, resource allocation, and dynamic disable capabilities. For information about new Plug and Play support under Windows NT 5.0, see the Windows NT 5.0 DDK. Standard system devices are excluded from related requirements, as described in the “System and device configuration meet Plug and Play requirements” item later in this chapter.
Thermal model and fan control, if implemented, complies with Section 12 of the ACPI 1.0 specification. Notice also that a server which supports thermal controls must have active thermal control such as a fan and cannot use passive thermal control under normal operating circumstances. This requirement does not disallow the addition of proprietary value-added features that cannot be accomplished using ACPI.
Support for at least one processor power state (either C1, C2 or C3).
No capabilities to disable system ACPI support using CMOS or other means. This requirement does not disallow the addition of proprietary value-added features that cannot be accomplished using ACPI.
Recommended ACPI support includes the following:
Power button in compliance with the ACPI 1.0 specification, as described in the “Hardware design supports OnNow initiative” requirement later in this section. If a power button is implemented, either the ACPI-specified override mechanism or a separate reset switch must also be supplied, and system control interrupt and necessary STS/EN bits must be provided.
Optional ACPI support includes the following:
Real-time clock alarm that supports wake up based on a scheduled time and day of the month. If this feature is implemented, the day-of-month feature is defined as a requirement in this guide, although it is an optional feature in the ACPI 1.0 specification. Also, if this feature is implemented, system control interrupt and necessary STS/EN bits must be provided.
The S5 soft-off state, as required in the ACPI 1.0 specification. If a soft-off feature is supported, it must be compliant with the S5 state capabilities defined in the ACPI 1.0 specification.
Implementation of at least one of the S1, S2, or S3 sleep states. If implemented, the S4 sleep states are not sufficient to meet the requirements for this optional feature. For maximum power savings and system response, support of the S3 sleep state is recommended.
A USB host controller that is able to wake the system using ACPI mechanisms.
Note: System-board power management or configuration features present on the server system and covered by the ACPI 1.0 specification must be implemented in compliance with ACPI 1.0, even if those features are not specific requirements or recommendations in these guidelines. This requirement does not disallow the addition of proprietary value-added power management of configuration features that are not covered by ACPI 1.0.
9 Hardware design supports OnNow initiative
Elements of the OnNow design initiative ensure that the operating system and device drivers control the state of individual devices and the system board.
For server hardware, all devices and drivers must support the D0 and D3 power states consistent with the definitions in the Default Class Power Management Specification and the relevant device class power management reference specification. This requirement must be implemented so that each device can successfully survive a system sleep/wake transition (device D3 to D0 transition) without requiring user intervention to restore functionality. This requirement applies whether or not system power is removed while the computer is in
an S1–S4 state.
The operating system supports the S4 state without system-board support, so all devices and drivers must meet this requirement.
Notice that there is no power consumption requirement for devices in the D3 state. It is strongly recommended, however, that devices implement the D3 state such that device power consumption is reduced to near zero, with the recognition that there is no requirement to retain any device context because it will be preserved or restored by the driver when returning to the D0 state.
It is recommended that devices and drivers support the D1, D2, or both low-power states, and that they support the defined wake-up events as designated in the relevant device class power management reference specification.
Power management is supported by the operating system for PCI, USB, and IEEE 1394. It is strongly recommended that these buses support power management requirements as defined in the related bus standards.
Optional OnNow features that designers might want to implement include the following:
The user experiences the server as off when it is in a sleep state. At a minimum, the hard disks, CD drives, display, sound, input devices, and fans should be perceived as off while the system is in a sleep state (for example, no noise or lights other than the status indicator).
The user can easily see whether the server is working or sleeping. A nonflashing indicator (that is, of a different color) is preferred. A slowly blinking — less than 1 Hz — light-emitting diode (LED) is an acceptable implementation of the sleep state indicator. Notice that the non-volatile S4 sleep state should appear to the user as off (that is, the sleep state should use the same indicator as the off state).
At a minimum, the server system should provide one or more indicators to show whether the system is in the working or sleep state.
The user can easily control power through switches and software. The system should provide an easily accessible power switch that can be controlled by software and that supports the functionality required in Section 4.7.2.2.1 of the ACPI 1.0 specification.
To meet the requirements for this optional feature, an OnNow-capable server can have either a power button or sleep button. The recommended implementation is to have both. If both buttons are implemented, the sleep button should be the user’s primary switch interface and should be easily distinguishable from the power button, preferably by hiding the power button.
The function of these buttons is determined by operating system software. In single-button configurations, it can be used for either sleep/wake transitions (G0< – >G1/S1–S4) or off/on transitions (G0< – >G2/S5), depending on user preference and policy set in the operating system and using an operating system–provided user interface.
The default action for the sleep button is to cause the machine to enter a sleep state. The default action for the power button is to shut down the operating system and power off the machine. In a two-button configuration that includes separate power and sleep buttons, the user interface for the operating system allows only the default actions.
In situations where hardware or software failure prevents normal operation of the software-controlled buttons, the switch capabilities must include an override mechanism for turning off the server. Notice that the override mechanism is not to be considered an alternative way for the user to turn off the server in normal operation; it is only a fail-safe function for fault conditions.
The implementation recommended in Section 4.7.2.2.1 of the ACPI 1.0 specification for the override mechanism is a 4‑second override. The override can be on either the power button or the sleep button in a two-button configuration. However, for multi-vendor consistency, the override should be associated with the sleep button in order to establish an industry-standard implementation.
An acceptable but not recommended alternative is a separate hidden or recessed switch that cannot be mistaken for either the power button or the sleep button. Notice that although the ACPI 1.0 specification suggests that the override be associated with the power button, the recommended implementation for an OnNow-capable server is to have the primary and
most-accessible button be the sleep button.
Equivalent button functionality can be provided using the keyboard. If the power switch is provided on the keyboard, the keys must be clearly labeled and must consist of a single key for turning the server on. (Two keystrokes are permissible for turning the server off.) The single keystroke ensures accessibility for persons with disabilities. For information about scan codes for keyboard power switches, see http://www.microsoft.com/hwdev/devdes/.
10 System startup meets requirements for OnNow support
This feature does not apply for RISC-based servers, except for the initial recommendation for fast power-on self test (POST). The intention of this recommendation is to ensure that the end user is not presented with unnecessary visual displays and to ensure that access to error information remains available using a hot key. The following support is suggested:
Fast POST. The system should be available to the user as quickly as possible. Although a specific time limit is not established, the basic recommendation is that power on to the bootstrap loader should occur within 5 seconds, plus hard-disk ready time and time required for ECC scrubbing. The following are recommended ways to reduce processing overhead to make system boot time as fast as possible:
No video memory test and limited test for DRAM size.
No tests for serial or parallel ports.
No floppy disk test or media check (boot from hard disk only).
No tests for hard disk controller or drive type (if the system does not include swappable drives).
Fast POST mode for BIOS can be disabled by the user for troubleshooting.
Minimal time for resume from supported sleep states. Resume from sleep state (S1–S3) to operating system handoff should occur within 500 ms. This recommendation does not apply to the S4 state. For all other sleep states, the time to operating system handoff means when the processor starts running (first instruction) until the BIOS jumps to the Waking Vector in the ACPI firmware control structure table, as described in Section 5.2.6 in the ACPI 1.0 specification.
Minimal startup display. System startup should draw the end user’s attention only when errors occur or when user action is needed.
The default configuration should allow a beep during the boot process only in case of an error, and the only screen display should be the OEM splash screen, which can include information such as copyright notices. By default, the system should be configured so the screen display does not show memory counts, device status, and so on. The display should present a “clean” BIOS startup so that the end user is not presented with cryptic and unnecessary information. However, this recommendation does not preclude the following:
Presenting a blank startup screen.
Providing a hot-key override to display screen messages for troubleshooting or to display user-definable CMOS settings.
Presenting text-based end-user action messages—for example, messages to display the setup hot key, system help hot key, password entry, network log on for remote booting, and so on.
Presenting manufacturer branding messages.
Providing a CMOS option to turn the clean startup screen off and on.
|
