Intel® 700 Series Chipset Family Platform Controller Hub (PCH)
Specification Update
Errata Details
SATA Enclosure Management LED Messaging | |
Problem | When sending a SATA enclosure LED message and all SATA ports are either idle or disabled, the PCH may not transmit the LED message due to an internal clock gating issue. |
Implication | The LED status for SATA enclosure may be incorrect. |
Workaround | None identified. Enclosure Management SW can poll the Enclosure Management (EM_CTL) - Offset 20h bit 8 register for a 0 value immediately before writing LED messages. |
Status | For the steppings affected, refer to the Summary Table of Changes. |
eSPI SBLCL Register Bit Not Cleared by PLTRST# | |
Problem | The IOSF-SB eSPI Link Configuration Lock (SBLCL) bit (offset 4000h, bit 27 in eSPI PCR space) is reset by RSMRST# assertion instead of PLTRST# assertion. |
Implication | If the SBLCL bit is set to 1, software will not be able to access the eSPI device Capabilities and Configuration register in the reserved address range (0h - 7FFh) until RSMRST# asserts. |
Workaround | If software needs to access the eSPI device reserved range 0h - 7FFh while SBLCL bit is set to 1, a RSMRST# assertion should be performed. |
Status | For the steppings affected, refer to the Summary Table of Changes. |
PCIe Clock and PCIe Reference Clock to Processor Maximum Rising/Falling Edge Rate and VCROSS | |
Problem | The PCIe Clock Output signals (CLKOUT_PCIE_P/N) and PCIe reference clock signals to processor (CLKOUT_CPUPCIBCLK_P/N) may not meet the maximum Rising/Falling Edge Rate and VCROSS specifications as defined in the PCI Express Card Electromechanical Specification Revision 3.0, section 2.1.3, REFCLK AC Specifications. |
Implication | There are no known functional failures due to this erratum. |
Workaround | None identified. |
Status | For the steppings affected, refer to the Summary Table of Changes. |
USB Audio Offload Traffic with Full-Speed Device Behind Hub | |
Problem | If USB audio offload is enabled for a USB Full-Speed Isochronous audio device connected behind a USB 2.0 or later hub and there is an active concurrent bulk transfer to another device on any port of the xHCI controller or behind the hub, the controller may stall the offloaded audio traffic and a split transaction error may occur. |
Implication | The USB audio offload playback may stop. Audio may be recovered if the audio stream is paused and restarted, the audio device is removed and reconnected, or the audio application is restarted. |
Workaround | None identified. A mitigation for this erratum is available with Intel® Smart Sound Technology version 10.29.00.5574 or later for systems with Microsoft Windows* 11 OS Release or Intel Smart Sound Technology version 10.29.00.7767 or later for systems with Microsoft Windows 10 OS Release. This mitigation will disable audio offload functionality for USB audio devices connected behind a hub. |
Status | For the steppings affected, refer to the Summary Table of Changes. |
005 | Integrated GbE Controller Reset on D3 Exit |
Problem | Upon GbE controller D3 exit, the GbE host driver performs a controller reset. During this reset, software accesses to the GbE MMIO registers may not complete. |
Implication | The system may hang.Note: This erratum has only been observed in a synthetic environment. |
Workaround | None identified. |
Status | For the steppings affected, refer to the Summary Table of Changes. |
xHCI Link Protocol Field Value - USB 3.2 Gen 1x2 and 2x2 | |
Problem | The xHCI Host Controller reports the value of 0h for the Link Protocol (LP) bits [15:14] in register XECP_SUPP_USB3_6 (MMIO offset 8038h) and XECP_SUPP_USB3_7 (MMIO offset 803Ch), which does not meet the xHCI specification revision 1.2. |
Implication | There are no known functional failures due to this erratum. |
Workaround | None identified. |
Status | For the steppings affected, refer to the Summary Table of Changes. |
xHCI Force Header Command Incorrect Return Code | |
Problem | The xHCI controller does not return the correct completion code for the Force Header Command as defined in the Section 4.6.16 of the eXtensible Host Controller Interface for Universal Serial Bus (xHCI) Requirements Specification Rev 1.2. |
Implication | xHCI CV TD4.12 - Force Header Command Test may report an error. Intel has obtained a waiver for TD 4.12. The Force Header Command is only used by the USB-IF Command Verifier (xHCI CV) tool for device testing. There are no known functional failures due to this erratum. |
Workaround | None identified. |
Status | For the steppings affected, refer to the Summary Table of Changes. |
USB VTIO Device Capabilities Field Length | |
Problem | The xHCI spec version 1.2 defines the PCI Express Capability structure offset 04h Device Capabilities (DVSEC) field to be 8 bytes. The USB Virtualization Based Trusted IO (VTIO) Management controller implements the DVSEC field as 12 bytes. |
Implication | An USB controller driver may not be able to enable the USB VTIO controller. |
Workaround | None identified. To mitigate this erratum, an Independent Software Vendor could account for the field length in the USB controller driver. |
Status | For the steppings affected, refer to the Summary Table of Changes. |
SLP_A# Minimum Assertion Width Timer During G3 Exit | |
Problem | Setting the Disable SLP_X Stretching After SUS Well Power Up (DIS_SLP_X_STRCH_SUS_UP) bit (offset 1020h, bit 12 in PMC_MMIO space) to 1 does not disable the SLP_A# Minimum Assertion Width (SLP_A_MIN_ASST_WDTH) timer (offset 1020h, bit 17 and 16 in PMC_MMIO space). |
Implication | G3 exit duration may be extended by the value programmed in the SLP_A_MIN_ASST_WDTH register. |
Workaround | None identified. |
Status | For the steppings affected, refer to the Summary Table of Changes. |
xHCI Dropped ACK Packet after Upstream Truncated Packet with DPPABORT OS | |
Problem | If a USB 3.2 Gen 1x1 hub sends an upstream truncated packet with DPPABORT OS (Data Packet Payload Abort Order Set) framing followed by an ACK packet for a previous OUT transfer from the xHCI controller, the ACK packet may be dropped by the xHCI controller. |
Implication | A timeout may be observed for the OUT transfer packet. Per the xHCI spec, a xHCI controller driver will issue a warm port reset to the device causing a device re-enumeration. |
Workaround | None identified. |
Status | For the steppings affected, refer to the Summary Table of Changes. |
Processor C-States with USB Full-speed or Low-speed Device Hotplug | |
Problem | When doing a hotplug on a USB hub with two or more USB Full-speed or Low-speed devices each with a 1 ms service interval interrupt endpoint, a race condition may occur between the PMC and the xHCI controller. |
Implication | The processor may fail to enter C3 or deeper package C-States. Note: This erratum has only been observed in a synthetic environment. |
Workaround | None identified. This condition is recovered after the xHCI controller has successfully entered D3. |
Status | For the steppings affected, refer to the Summary Table of Changes. |
Timed GPIO Event May Have a Mismatched Time Stamp | |
Problem | When a Timed GPIO event is counted in the Event Counter Capture (TGPIOECCV) register (offset 1238h, bits 31 to 0 in PWRMBASE space), the Time Capture (TGPIOTCV) register (offset 1230h, bits 31 to 0 in PWRMBASE space) value is not immediately updated after that event is counted. |
Implication | A Timed GPIO event may have a mismatched time stamp. |
Workaround | None identified. A Timed GPIO driver can partially mitigate for this erratum by detecting that a TGPIOECCV register change has occurred without a TGPIOTCV register change and then repeatedly re-read the TGPIOTCV register until a change does occur. |
Status | For the steppings affected, refer to the Summary Table of Changes. |
USB 3.2 Gen 1x1 Port Does Not Send 16 Polling LFPS Burst | |
Problem | On USB 3.2 Gen 1x1 only capable ports, including ports configured as USB 3.2 Gen 1x1 by soft strap, the xHCI controller may send only 15 LFPS signals instead of a burst of 16 LFPS signals as specified by the USB 3.2 specification. |
Implication | There are no known functional implications due to this erratum. LFPS handshake requires the receiver link partner to only detect 2 LFPS signals. This issue may impact the SuperSpeed compliance test case which checks for the 16 LFPS burst requirements: TD6.4, TD6.5, and TD7.31. |
Workaround | None identified. |
Status | For the steppings affected, refer to the Summary Table of Changes. |
USB 2.0 Full-speed Device Enumeration With Certain Cables | |
Problem | The xHCI controller may not complete the detection of the End of Packet Single Ended 0 (EOP SE0) when a USB Full-speed device is connected through a USB 2.0 cable that has a connector-to-connector propagation delay greater than 15.6 ns. |
Implication | Due to this erratum, the USB 2.0 Full-speed device may fail to enumerate. |
Workaround | None identified. |
Status | For the steppings affected, refer to the Summary Table of Changes. |
015 | Precision Time Measurement (PTM) Interpretation Capability Bit Incorrect Register Offset |
Problem | The PTM Propagation Delay Adaptation Interpretation B (PTMPDAIB) Bit is implemented at Configuration Space (CFG) Offset 158h instead of at 50h as documented in the PCI-SIG PTM Byte Ordering Adaptation Engineering Change Notice (ECN). |
Implication | Due to this erratum, End Point Device (EPD) software that implements the PTM Byte Ordering Adaptation ECN will not be able to program their PTMPDAIB Bit correctly since it is located at a different register offset. |
Workaround | None identified. To mitigate this issue, EPD software that implements the PTM Byte Ordering Adaptation ECN must access PTMPDAIB at CFG Offset 158h. |
Status | For the steppings affected, refer to the Summary Table of Changes. |
ESPI_CS1#, ESPI_CS2#, and ESPI_CS3# Floating Following Initial eSPI Reset Deassertion | |
Problem | During Deep Sx exit or booting from G3 state, ESPI_CS1#, ESPI_CS2#, and ESPI_CS3# are momentarily high impedance and may float low following the initial ESPI_RESET# deassertion. |
Implication | Due to this erratum, unexpected system behavior may occur on systems with more than one eSPI device. |
Workaround | Implement 10 kohm external pull-up resistors to the VCCPRIM_1P8 voltage rail on ESPI_CS1#, ESPI_CS2#, and ESPI_CS3#. |
Status | For the steppings affected, refer to the Summary Table of Changes. |
USB Low-Speed or Full-Speed Device Enumeration Failures During Hot-Plug | |
Problem | During the hot-plug of a USB 2.0 hub with Low-Speed or Full-Speed device connected behind the hub, a split transaction error may occur during the enumeration of the USB Low-Speed or Full-Speed device. |
Implication | Due to this erratum, the USB Low-Speed or Full-Speed device may fail to enumerate when connected to the USB 2.0 hub. This condition is recovered after the xHCI controller has been reset (for example, software setting the xHCI Host Controller Reset (HCRST) bit or by performing a power button override). |
Workaround | For Intel® 600 Series: A fix for this erratum is available in BIOS. Please see BIOS version 3365_00 release or later. For Intel® 700 Series: A fix for this erratum is available in BIOS. Please see BIOS version 3342_00 release or later. |
Status | For the steppings affected, refer to the Summary Table of Changes. |
018 | |
Problem | When multiple USB 2.0 split transaction errors occur, the xHCI host controller may become unresponsive. |
Implication | Due to this erratum, USB devices connected to the xHCI controller may not function. |
Workaround | None identified. |
Status | For the steppings affected, refer to the Summary Table of Changes. |
019 | |
Problem | The xHCI controller may fail to handle a zero-length data packet when doing concurrent traffic with the following devices connected on three separate root ports: - USB 3.2 Gen 2x1 (or 2x2) hub with at least two USB 3.2 bulk devices. - USB 3.2 Gen 2x1 (or 2x2) hub with at least two USB 3.2 bulk devices. - USB isochronous device that sends zero-length data packets. |
Implication | Due to this erratum, the xHCI controller may hang. Intel has only observed this behavior with USB audio offload enabled and USB 2.0 audio devices that send zero-length data packets. |
Workaround | None identified. |
Status | For the steppings affected, refer to the Summary Table of Changes. |
020 | I2S Audio Channels Swapped With High Frame Polarity in Device Mode |
Problem | When the I2S interface is in device mode, the audio controller may not be correctly configured if the audio codec requires high frame polarity. |
Implication | Due to this erratum, the left and right audio channels may swap when frame polarity is set to high. |
Workaround | None identified. |
Status | For the steppings affected, refer to the Summary Table of Changes. |
021 | |
Problem | A delay in the availability of LCRD1 (Link Credit 1) from a USB 3.2 hub, with two or more downstream USB 3.2 bulk endpoint devices engaged in SuperSpeedPlus concurrent transfers, may lead to the connected xHCI controller sending the ACK and Status of a transfer packet out of order. |
Implication | Due to this erratum, a USB 3.2 bulk endpoint device may not respond to subsequent transfers. It may be possible for a device driver to recover the USB 3.2 device. |
Workaround | None identified. |
Status | For the steppings affected, refer to the Summary Table of Changes. |
022 | SPI0 Dual IO Mode With SPI0_IO2 And SPI0_IO3 Connected to SPI Device |
Problem | On systems with dual IO mode enabled, SPI0_IO2 and SPI0_IO3 may momentarily drive low before these signals are pulled high by internal resistors during boot from the G3 state. |
Implication | Due to this erratum, unexpected system behavior may occur on systems when SPI0_IO2 and SPI0_IO3 signals are connected to an SPI device. |
Workaround | None identified. To mitigate this erratum, do not connect SPI0_IO2 and SPI0_IO3 to an SPI device in SPI0 dual IO mode enabled systems. |
Status | For the steppings affected, refer to the Summary Table of Changes. |
023 | Non-Responsive USB Port After Disconnecting Full-speed Device |
Problem | Disconnecting a USB full-speed device from the USB port while the xHCI controller is in the process of sending the Start of Frame may cause the USB 2.0 functionality to become unresponsive for that specific port. |
Implication | Due to this erratum, USB 2.0 devices may not be recognized on the USB port until a host controller reset occurs. Intel has only observed this behavior in a synthetic test environment. |
Workaround | None identified. |
Status | For the steppings affected, refer to the Summary Table of Changes. |