WHQL Test Specification

Next

September 2002


Copyright and Disclaimer

This document is provided for informational purposes only and Microsoft makes no warranties, either express or implied, in this document. Information in this document, including URL and other Internet Web site references, is subject to change without notice. The entire risk of the use or the results of the use of this document remains with the user. Unless otherwise noted, the example companies, organizations, products, people and events depicted herein are fictitious and no association with any real company, organization, product, person or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Portions of this document specify software that is still in development. Some of the information in this documentation may be inaccurate or may not be an accurate representation of the functionality of final documentation or software. Microsoft assumes no responsibility for any damages that might occur directly or indirectly from these inaccuracies.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 2000 - 2002 Microsoft Corporation. All rights reserved.

Portions of this content were first published as PC 99 Test Specification and PC 2001 Test Specification, Copyright © 1999, 2000 Intel Corporation and Microsoft Corporation. All rights reserved.

Direct3D, DirectDraw, DirectInput, DirectShow, DirectSound, DirectX, Microsoft, Microsoft Office, MS-DOS, Windows, the Windows logo, Win32, Win64, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

Other product and company names mentioned herein may be the trademarks of their respective owners.


Chapter 1: Introduction to HCT Test Specifications

Windows Hardware Quality Lab (WHQL) Test Specification provides foundation information about the test assertions and methodologies for system and peripheral tests that are part of the Hardware Compatibility Test (HCT) Kit for the Microsoft® Windows® XP; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition; and Windows .NET Server 2003, Datacenter Edition operating systems.

This specification is intended for engineers who build personal computers, expansion cards, and peripheral devices designed to comply with the requirements for the "Designed for Windows" logo, and for testers who administer tests from the HCT.

Note: This test specification is not a comprehensive description of all tests provided in the HCTs. This specification describes new tests introduced in the HCTs for the Windows .NET Server 2003 family, and Windows XP, plus many tests first introduced for Windows 2000 and Windows Millennium Edition (Windows Me).

This test specification is owned and managed by Microsoft Corporation.


What’s new

About this Release

This release of the Microsoft® Windows® HCT 11.1 kit Test Specifications provides preliminary information about new and proposed tests and test assertions, as well as updates and revisions to existing tests. Public comment is encouraged and appreciated. This release of the test specification document identifies the new and changed content using labels and revision numbers. For example, the label [NEW v0.7] indicates that the information is awaiting acceptance and that the content is generally complete. By the release of the HCT 11.1 kit, all new material is at revision v1.0, and the labels identifying the new material are removed.

WHQL will provide updates to the test specification based on new information and feedback on the existing specification. You can download the latest test specifications from the WHQL Web site at (www.microsoft.com/hwdq/hwtest/search/details.asp?ID=394). Check this site frequently for changes to the test specifications.

Please direct any comments or questions about the preview test specifications document to WHQL Test Specifications Review at whqltsr@microsoft.com

New Tests

The WHQL Test Specifications includes new tests that verify new logo requirements for Windows XP; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition; and Windows .NET Server 2003, Datacenter Edition, as well as tests that verify existing logo requirements. In addition, a number of tests included in previous HCT kits have been improved for the Windows HCT 11.1 kit.

Click to show or hide information. The following tests are new or have been updated since the HCT 10.0 release:

Chapter 3: Advanced Configuration and Power Interface Test Specification

  • TD-3.35 Unreported Memory/IO Port
  • TD-3.36 ACPI Errors
  • TD-3.37 CPU P-State and CPU P-State Battery
  • TD-3.38 ACPI Stress Tests

Chapter 4: PCI Test Specification

  • TD-4.50 PCI Compliance

Chapter 5: Graphics Adapter Test Specification

  • TD-5.81 Fill Modes
  • TD-5.82 Invalid Parameter (DirectX 6 through DirectX 9) [New]
  • TD-5.150 Display Windows 2000 GDI [The Check Resolution Test]
  • TD-5.170 Video Rendering Display [Updated]

Chapter 6: Video Test Specification

  • TD-6.23 Audio or Video Capture and Control
  • TD-6.24 AV/C Tape Subunit Compliance
  • TD-6.25 DVD ViewGraph

Chapter 9: USB Test Specification

  • TD-9.24 USB Descriptor
  • TD-9.25 USB Device Framework (CV)
  • TD-9.26 USB Hub Compliance (CV)
  • TD-9.27 USB HIDview (CV)
  • TD-9.28 USB High Speed Hub Basic
  • TD-9.29 USB High Speed Hub Basic Transfer
  • TD-9.30 USB High-Speed Hub Advanced Transfer

Chapter 21: Anti-Virus File System Filter Test Specification

  • TD-21.31 DCDP 14-Day Stress (Anti-Virus) [New]

Chapter 22: Driver Quality Test Specification

  • TD-22.1 ChkINF
  • TD-22.2 Device Path Exerciser
  • TD-22.3 Driver Verifier
  • TD-22.9 Signability
  • TD-22.12 Sysparse

Chapter 23: Network Adapter Test Specification

  • TD-23.1 NDIS (LAN) [Updated]
  • TD-23.2 VPN Compliance
  • TD-23.3 NDIS (IPSec)
  • TD-23.4 DCDP 14-Day Stress (Network) [New]

Chapter 24: Cluster Test Specification

  • Updated tests, guidelines

Chapter 28: Storage Test Specification

  • TD-28.14 Storage Data Verification Filter
  • TD-28.15 DCDP 14-Day Stress (Storage) [New]

Chapter 30: Datacenter Server Test Specification

  • TD-30.14 IIS Stress
  • TD-30.16 DTC Shutdown/Restart

Chapter 32: Bluetooth Test Specification

  • TD-32.1 Bluetooth Controller Test

Chapter 33: Fault Tolerant Server Test Specification

  • TD-33.7 Kernel Stress Tests (BPStress)

Chapter 34: Intel® Itanium™ Machine Check Architecture (MCA) Test Specification

  • TD-34.1 Machine Check Errors

Chapter 35: Media Appliance Test Specification

  • TD-35.1 WMDM Content Transfer
  • TD-35.2 WMDM Service Provider

Chapter 36: Server Appliance Test Specification

  • TD-36.1 Server Appliance Local Display
  • TD-36.2 Server Appliance Local Keypad
  • TD-36.4 Server Appliance NVRAM
  • TD-36.3 Server Appliance Watchdog
  • TD-36.5 Server Appliance Failover


How to Use this Document

WHQL Test Specification provides information that can be used for two key purposes, in support of the testing process for the Windows Logo Program for hardware:

  • During the component design phase: Designers and engineers can confirm the precise elements of Windows compatibility and industry specification compliance that are validated in the HCTs.
  • During HCT Kit testing: Test engineers can check the assertion numbers cited in test logs to determine the precise points of failure in relation to Logo Program requirements, Windows DDK guidelines, and industry specifications.

To use the WHQL Test Specification to support the component design process

  1. Read each technology-specific chapter related to the component.

For example, for a PCI-based graphics adapter, see these chapters:

Chapter 4, PCI Test Specification
Chapter 5, Graphics Adapter Test Specification
Chapter 6: Digital and Broadcast Video Test Specification
Chapter 22: Driver Quality Test Specification
Windows Experience and Ease-of-Use Assertions in this chapter

  2. Verify the technical details of the related Windows Logo Program requirements, design guidelines, and industry specifications cited as the "Reference document" sections for each test assertion.

For example, see the related hyperlinked references for assertion 3.45.1, "Systems identified as legacy free must implement the ACPI reset mechanism …":

Reference documents: PC 2001 System Design Guide, BIOS–0015; "Proposed ACPI Specification Changes for Legacy Free," Section 4.7.5, at http://www.microsoft.com/hwdev/tech/onnow/LF-ACPI.asp.

Note: Windows Logo Program requirements and PC and server design guidelines are provided as hyperlink pop-ups in the test assertions. For links to industry specifications, see Bibliography of Standards and Specifications.

To use the WHQL Test Specification to understand errors reported during HCT testing

  1. In the WHQL Test Specification help file, click the Search tab.
  2. In the Type in the keyword to find box, type the assertion number that appears in the HCT log file, and then click List Topics.
  3. Read each topic listed in the Select Topic to display box to ensure that you have viewed all the related information.
  4. Verify the technical details of the related Windows Logo Program requirements, design guidelines, and industry specifications cited as the "Reference document" section for the specific test assertion.


Structure of this Document

Each test specification chapter covers information for a specific technology, and follows this basic structure:

Introduction

Test Coverage - Indicates areas of the technology for which test assertions are provided.

Test Methodology - States any general requirements for the test environment.

Test Assertions

Provides lists of assertions in each test suite, with pointers to source requirements documents and related test description.

The assertions in this test specification are derived from the Windows Logo Program requirements and other source documents such as industry standards and the Windows DDK. Each assertion is a truth statement declaration of a single feature criterion in the Logo Program requirement. For more information about assertions, see Development Process for Test Specifications.

Each assertion has a unique three-part number, intended to match numbers used in the related test log. This number scheme consists of:
<chapter number>.<assertion group>.<item>

For example, assertion number 3.2.4 refers to assertion item 4 in the group of assertions related to ACPI Processor Power State Transition Test (ACPIPPST) in Chapter 3.

Test Descriptions

Explains the characteristics and function of each test suite. Each test description maps to a set of assertions defined in the Test Assertions section. Generally, each test descriptions provides the following information

Overview of Test Steps - Provides a summary of the algorithm or steps provided. Issues and known problems are listed.

Setup - Provides information about required hardware and software setup to define the correct test environment.

Results Interpretation - Provides information that can be used for resolving failure messages in the test log.

Each Test Description section has a unique number in this pattern:
TD-<chapter number>.<test description number>


Development Process for Test Specifications

WHQL Test Specification strives to provide a set of objective, non-arbitrary test criteria for the hardware elements contained in Microsoft Windows Logo Program System and Device Requirements.

Figure 1 shows the process used for deriving the WHQL Test Specification from the Windows Logo Program requirements.

Figure 1-Test Specification Process

Figure 1. Test Specification Process

The following are key definitions used in WHQL Test Specification:

Assertion

A truth statement declaration of a single feature criterion, made as if no additional proof or confirmation is required, with clearly defined Pass/Fail criteria. Assertions include criteria that are both testable and non-testable. Each set of assertions provides definitive pass/fail criteria for requirements defined in Microsoft Windows Logo Program System and Device Requirements. However, some elements specified in the Logo Program requirements are not covered by this document.

Test Algorithms

Derived from the assertions. The algorithm defines both the method to be used to validate an assertion statement and the logical process followed to execute the test and interpret the results. The algorithm is concerned with measuring the outcome and not how the result was achieved, except in those cases where the algorithm itself becomes an assertion because the assertion defines a specific way the result is to be achieved.

Some common functions of the test specification are to identify assertions that are pre-requisite to testing other assertions and to the sequence in which the testing progresses. The test specification describes test output and ensures that test results can be mapped back to both the original assertion statement and to the appropriate reference document.

Reference document

A reference in Microsoft Windows Logo Program System and Device Requirements or documents referred to in the Logo requirements, such as:

  • Microsoft Windows DDK
  • Other Microsoft documents defining the requirements for compatibility with Windows operating systems, generally available from the Hardware and Driver Developers web site
  • Industry specifications and standards documents (see Bibliography of Standards and Specifications)
  • Design guides such as PC 2001 System Design Guide and Hardware Design Guide Version 3.0 for Microsoft Windows 2000 Server

Tip: The following help files are available as online references if you installed the WHQL Test Specifications as part of the HCT test documentation:

  • Microsoft Windows Logo Program System and Device Requirements
  • PC 2001 System Design Guide, coauthored by Intel Corporation and Microsoft Corporation
  • Hardware Design Guide v. 3.0 for Microsoft Windows Server, coauthored by Intel Corporation and Microsoft Corporation

Test Description

Describes the intent of how the test is to be performed, including a specific set of steps and conditions that must be performed to validate compliance with the related test assertion. The test description generally includes the following information:

  • Overview that states how the test validates the test assertion.
  • Algorithm or steps performed in the test including specific conditions and action
  • Issues and known problems with assertion coverage or procedure related issues
  • Interpretation of results which includes information on how the operator will assess success or failure of the test

Industry Review

Both the requirements for the Windows Logo Program for hardware and the related test assertions have been published in early draft forms and provided for industry review in the following ways:

  • Tests developed at Microsoft are based on test specifications published in review draft form by WHQL, with notification and call for comments published in the WHQL Weekly News. To receive this publication, see the WHQL web site.
  • Tests based on test assertions developed through the System Test Implementers Forum are reviewed through Forum events. The Forum is a group of industry system builders and PC platform developers working to review implementation of test specifications. The System Test-IF is sponsored by Intel Corporation and Microsoft Corporation, and is open to all developers who want to participate by providing their inputs during development of PCxx Test Specifications and related compliance tests. For information, see the System Test Implementers Forum web site.

Scope of Testing

Microsoft will incorporate hardware compatibility tests that implement the test assertions contained in this Test Specification into Hardware Compatibility Test (HCT) kit releases. Such tests represent a subset of the compatibility testing coverage provided in the HCT Kits. For more information about the HCT Kit releases, see the WHQL web site.

The current versions of the supporting documents for the HCTs are available on the web:

  • WHQL Test Specifications, available from the WHQL web site
  • Microsoft Windows Logo Program System and Device Requirements, available from the Windows Logo Program for Hardware web site
  • PC 2001 System Design Guide, available from the PC Design Guide web site
  • Hardware Design Guide v. 3.0 for Microsoft Windows Server, available from the Server Design Guide web site


Bibliography of Standards and Specifications

This section includes a list of supporting specifications and standards documents referenced in this Test Specification. Additional detailed reference bibliography citations are provided in Microsoft Windows Logo Program System and Device Requirements (http://www.microsoft.com/hwdev/winlogo/).

Note: In this chapter, "WLP Requirements" refers to Microsoft Windows Logo Program System and Device Requirements

1394 Open Host Controller Interface Specification, Release 1.0

ftp://ftp.austin.ibm.com/pub/chrptech/1394ohci/ohcir100.pdf

1394 Open Host Controller Interface Specification, Release 1.1

http://www.microsoft.com/hwdev/bus/1394/default.asp
http://developer.intel.com/technology/1394/download/ohci_11.htm

1394 Trade Association Power Specification, Part 1: Cable Power Distribution
1394 Trade Association Power Specification, Part 3: Power State Management

ftp://ftp.p1394pm.org/pub/p1394pm/

1394 Trade Association

E-mail: 1394-sig@1394ta.org
http://www.1394ta.org

1999 Version of National ISDN Basic Rate Interface Terminal Equipment Generic Guidelines, Document Number SR-4620 (replaced by 2000 Version, SR-4995)

http://telecom-info.telcordia.com/site-cgi/ido/index.html

AC ‘97 and AMR Plug and Play Design (for Windows)

http://www.microsoft.com/hwdev/tech/audio/AMR.asp

AC '97 Component Specification and related publications

http://developer.intel.com/ial/scalableplatforms/audio/index.htm

AC '97 System BIOS Codec/Function Detection Algorithm

ftp://download.intel.com/ial/scalableplatforms/audio/ac97bios.pdf

Accelerated Graphics Port Interface Specification, Revision 2.0

http://developer.intel.com

ACPI Changes for Legacy Free

http://www.microsoft.com/hwdev/tech/onnow/LF-ACPI.asp

ACPI Docking for Windows

http://www.microsoft.com/hwdev/tech/onnow/ACPIdock.asp

Advanced Configuration and Power Interface Specification, Revision 1.0b and Revision 2.0
(ACPI 1.0b and ACPI 2.0)

http://www.acpi.info/

AGP Pro Specification, Revision 1.1a

http://www.agpforum.org/downloads/apro_r10.pdf

An Interoperable End-to-End Broadband Service Architecture over ADSL Systems, Version 3.0

http://www.microsoft.com/hwdev/tech/network/dsl/default.asp

ANSI NCITS T10 Multi-Media Command Set-2 (MMC-2)

Global Engineering Documents at http://global.ihs.com/

ANSI/SMPTE standards

http://www.smpte.org/smpte_store/standards/

Application Specification for Microsoft Windows, for desktop applications, Version 1.0

http://msdn.microsoft.com/certification/appspec.asp

AT Attachment with Packet Interface – 5 (ATA/ATAPI-5)

ftp://fission.dt.wdc.com/pub/standards/x3t13/project/d1321r3.pdf

ATA and ATAPI draft standards and other working documents

Global Engineering Documents at http://global.ihs.com/

ATA Packet Interface for CD-ROM, SFF 8020i

Global Engineering Documents at http://global.ihs.com/

ATAPI Removable Media Device BIOS Specification (ARMD), Version 1.0

http://www.phoenix.com/en/support/white+papers-specs/default1.htm

ATAPI Removable Rewriteable Media Devices (SFF-8070i)

ftp://ftp.p1394pm.org/pub/p1394pm

ATM User Network Interface (UNI) Specification, Version 3.1, 1/e

Prentice Hall; 1995
ISBN 0-13-393828-X
http://www.atmforum.com/

ATSC Digital Television Standard and Amendment No.1 (A/53)

E-mail: mktg@smpte.org
http://www.atsc.org/standards.html

Audio and Windows web page

http://www.microsoft.com/hwdev/tech/audio/default.asp

Audio Codec ’97, Revision 2.1

http://developer.intel.com/ial/scalableplatforms/audio/index.htm

Audio Device Class Power Management Reference Specification, Version 1.0

http://www.microsoft.com/hwdev/resources/specs/pmref/default.asp

Audio/Modem Riser Card Specification, Revision 1.01

http://developer.intel.com/ial/scalableplatforms/audio/index.htm

AV/C Digital Interface Command Set VCR Subunit Specification, V. 2.0.1

http://www.1394ta.org/Technology/Specifications/Descriptions/AVC_VCR_201.htm

Bellcore Technical References

http://www.telcordia.com/index.html

BIOS Boot Specification, Version 1.01

http://www.phoenix.com/en/support/white+papers-specs/default1.htm

Bluetooth Implementation and Windows web page

http://www.microsoft.com/hwdev/tech/network/bluetooth/default.asp

Bluetooth Special Interest Group (SIG): see Specification of the Bluetooth System

Boot Integrity Services Application Programming Interface, Version 1.0

http://developer.intel.com/ial/wfm/wfmspecs.htm

Cable Modems and Windows web page

http://www.microsoft.com/hwdev/tech/network/cable/default.asp

CardBus Host Controllers and Windows Compatibility

http://www.microsoft.com/hwdev/bus/cardbus/cardbus1.asp

CardBus Technology and Windows web page

http://www.microsoft.com/hwdev/bus/cardbus/default.asp
See also "Explanation of CardBus Registry Entries In PCMCIA.INF" at http://support.microsoft.com/support/kb/articles/q201/0/18.asp

Caution for Display Driver Dependencies on GDI

http://www.microsoft.com/hwdev/archive/devdes/gdi.asp

Color Coding for Connectors

http://www.microsoft.com/hwdev/platform/pcdesign/desguide/pcguides.asp

Color Management and Windows Operating Systems web page

http://www.microsoft.com/hwdev/tech/color/default.asp

Common Application Environment (CAE) Specification

http://www.opengroup.org/onlinepubs/9629399/toc.htm

Common Information Model (CIM)

http://www.dmtf.org/standards/standard_cim.php

Communications Device Class Power Management Reference Specification, Version 1.0

http://www.microsoft.com/hwdev/resources/specs/pmref/default.asp

Compaq, Intel, Phoenix BIOS Boot Specification, Version 1.01 (CIP BIOS Boot 1.01)

http://www.phoenix.com/en/support/white+papers-specs/default1.htm

Compatibility Testing for Hot-Plugging Support for PCI Devices

http://www.microsoft.com/hwdev/bus/pci/hotplugpci.asp

Compatibility Testing Requirements for Display and Video Miniport Drivers

http://www.microsoft.com/hwdev/tech/display/vidminiport.asp

Computer Display Monitor Timing Specifications, Version 1, Revision 0.8

http://www.vesa.org/standards.htm

Configuring PCI-PCI Bridges on Windows 2000 and Windows XP

http://www.microsoft.com/hwdev/bus/pci/default.asp

Configuring PCI-to-PCI Bridges with VGA Cards

http://www.microsoft.com/hwdev/bus/pci/pcibridge-cardbus.asp

Data-Over-Cable Service Interface Specifications (DOCSIS)

http://www.cablemodem.com/

Debug Port Specification

http://www.microsoft.com/hwdev/platform/PCdesign/LR/debugspec.asp

Default Device Class Power Management Reference Specification, Version 1.0

http://www.microsoft.com/hwdev/resources/specs/pmref/default.asp

Designing HID Game Controllers for DirectInput

http://www.microsoft.com/hwdev/tech/input/hidgame.asp

Designing Multifunction Devices for Windows Operating Systems

http://www.microsoft.com/hwdev/tech/MF/default.asp

Design Rule for Camera File system (DCF) Specification

http://www.pima.net/standards/it10/PIMA15740/dcf.htm

Desktop Management Interface Specification, Version 2.0
DMI Compliance Guidelines, Version 1.0

http://www.dmtf.org/standards/standard_dmi.php

Device class power management reference specifications

http://www.microsoft.com/hwdev/resources/specs/pmref/default.asp

Digital Audio and Windows white papers

http://www.microsoft.com/hwdev/tech/audio/default.asp

Digital Video Camcorder Support in Windows

http://www.microsoft.com/hwdev/archive/vidcap/DVCam.asp

Digital Visual Interface (DVI), Revision 1.0

http://www.ddwg.org

Display Adapter Drivers and Windows Millennium Hibernation

http://msdn.microsoft.com/library/en-us/graphics/hh/graphics/ddraw_4aw7.asp

Display Adapters and Windows web page

http://www.microsoft.com/hwdev/tech/display/default.asp

Display Device Class Power Management Reference Specification, Version 1.0b

http://www.microsoft.com/hwdev/resources/specs/pmref/default.asp

Display Technology web page

http://www.microsoft.com/hwdev/tech/display/default.asp

Distributed Management Task Force (DMTF)

http://www.dmtf.org

DLS Specification, V. 1.0

http://www.midi.org/

DOCSIS: See Data-Over-Cable Service Interface Specifications

DSL Devices and Windows web page

http://www.microsoft.com/hwdev/tech/network/dsl/default.asp

DVB/DAVIC (Digital Video Broadcasting/Digital Audio Visual Council)

http://www.dvb.org
http://www.davic.org

DVD and Microsoft Operating Systems

http://www.microsoft.com/hwdev/tech/stream/DVD/DVDwp.asp

DVD Multifunction Devices: Avoiding Multiple Logical Unit Devices

http://www.microsoft.com/hwdev/hwdev/tech/stream/DVD/multiLUN.asp

DVD Physical Format documents

Global Engineering Documents at http://global.ihs.com/

DVD Playback and Windows web page

http://www.microsoft.com/hwdev/tech/stream/DVD/default.asp

DVD Specification, Version 1.0

Toshiba Corporation
http://www.toshiba.com

DVD Specifications for Rewritable Disc, Part 1: Physical Specifications

Toshiba Corporation
http://www.toshiba.com

Easy PC Initiative and legacy-free design

http://www.microsoft.com/hwdev/platform/PCdesign/LR/default.asp

ECMA Standards: ECMA-267 (DVD-ROM), ECMA-272, 273 (DVD-RAM) and ECMA-274 (+RW)

http://www.ecma.ch/

EIA Standard #ANSI/EIA-516-88:
Other EIA standards

Global Engineering Documents at http://global.ihs.com/

El Torito - Bootable CD-ROM Format Specification, Version 1.0

http://www.phoenix.com/en/support/white+papers-specs/default1.htm

Enhanced BIOS Services for Disk Drives [T13-1226DT], Revision 7

Global Engineering Documents at http://global.ihs.com/

Ensuring Digital Audio Quality on CD-ROM Drives

http://www.microsoft.com/hwdev/archive/devdes/cddigital.asp

Enumerating Serial Devices in Windows

http://www.microsoft.com/hwdev/tech/IO/superio/serddvr.asp

EPS Power Supply: A Server System Infrastructure (SSI) Specification for Entry Chassis Power Supplies

http://www.ssiforum.org/docs/entrylevelpowersupply.pdf

European Telecommunications Standards Institute (ETSI) or Global System for Mobile (GSM) standards

E-mail: secretariat@etsi.fr
http://www.etsi.org/

Extensible Firmware Interface Specification (EFI)

http://developer.intel.com/technology/efi/download.htm

Extensions to VT100 Terminal Definition

http://www.microsoft.com/hwdev/platform/server/headless/default.asp

External DSL Modems Design Guidelines

http://www.microsoft.com/hwdev/tech/network/dsl/extDSLmodems.asp

Fibre Channel Physical (FC-PH), Revision 4.3

http://www.fibrechannel.com

GDI+: Next-Generation Graphics Device Interface

http://www.microsoft.com/hwdev/archive/video/GDInext.asp

Global Engineering Documents

http://global.ihs.com

Guidelines for WDM-based Software Modems

http://www.microsoft.com/hwdev/tech/network/modem/softmodem.asp

Handshake procedures for digital subscriber line (DSL) transceivers

http://www.itu.int/

Hardware Design Guide Version 3.0 for Microsoft Windows Server

http://www.microsoft.com/hwdev/platform/pcdesign/desguide/serverdg.asp

HID Support Routines for Minidrivers

http://www.microsoft.com/DDK/

HID Usage Tables, Version 1.1
Other HID-related specifications

http://www.usb.org/developers/hidpage.html

Home Phoneline Networking Alliance (Home PNA) Specification, Version 1.0

http://www.homepna.org

Home Radio Frequency (HomeRF) Working Group

http://www.homerf.org

Hot-Plug PCI and Windows web page

http://www.microsoft.com/hwdev/bus/pci/hotplugpci.asp

I2O (Intelligent I/O) Architecture Specification, Version 1.5

http://www.intelligent-io.com/

IBM Personal System/2 Common Interfaces, Part No. S84F-9809
IBM Personal System/2 Mouse Technical Reference, Part No. S68X-2229

International Business Machines Corporation
IBM Customer Publications Support: (800) 879-2755
Or contact an IBM sales representative

ICC Profile Format Specification, Spec ICC.1:1988-09 and Addendum 2, ICC.1A:1999-04

http://www.color.org/info_profiles2.html

Icons for PCs web page

http://www.microsoft.com/hwdev/platform/pcdesign/desguide/pcguides.asp

IEC 61883 Digital Interface for Consumer Electronic Audio/Video Equipment

http://www.iec.ch/webstore/

IEC 61966-2-1 Multimedia systems and equipment – Colour measurement and management – Part 2-1: Colour management – Default RGB colour space – sRGB

http://www.iec.ch

IEEE 802.14 Cable TV Working Group

http://www.cs.virginia.edu/~mngroup/projects/802.14/

IEEE 1212-2000
IEEE 1284-1994
IEEE 1394-1995 Standard for a High Performance Serial Bus
IEEE 1394a-2000 amendment to IEEE 1394-1995
IEEE P1394b
Other IEEE standards

http://standards.ieee.org/reading/ieee/std/busarch/1394-1995.pdf
http://standards.ieee.org/index.html
http://global.ihs.com

IEEE 1394 and Windows web page

http://www.microsoft.com/hwdev/bus/1394/default.asp

Implementing Display Control Panel Extensions in Windows 95/98

http://www.microsoft.com/hwdev/archive/devdes/displaycpl.asp

Implementing Legacy Audio Devices on the PCI Bus

http://developer.intel.com/ial/scalableplatforms/audio/

InfiniBand Trade Association

http://www.infinibandta.org/home.php3

Infrared Data Association (IrDA) documents

E-mail: info@irda.org
http://www.irda.org/standards/specifications.asp

Infrared Devices and Windows web page

http://www.microsoft.com/hwdev/tech/network/infrared/default.asp

Infrared Extensions to the NDIS Version 4.0 Functional Specification

http://www.cablemodem.com/

Infrared Transfer Picture Specification (IrTran-P), Version 1.0

http://www.irda.org/standards/specifications.asp

Input Device Class Power Management Reference Specification, Version 1.0

http://www.microsoft.com/hwdev/resources/specs/pmref/PMinput.asp

Input Device Drivers and Windows

http://www.microsoft.com/hwdev/tech/input/drv.asp

Input Devices and Windows web page

http://www.microsoft.com/hwdev/tech/input/default.asp

Instantly Available PC System Power Delivery Requirements and Recommendations

http://developer.intel.com/design/power/supply98.htm

Instantly Available Power Managed Desktop PC Design Guide

http://developer.intel.com/technology/iapc/tech.htm

International Color Consortium (ICC)

http://www.color.org

Interoperability Specification for ICCs and Personal Computer Systems Specification, Revision 1.0 (PC/SC Specification)

http://www.pcscworkgroup.com/

Introducing Digital Rights Management

http://www.microsoft.com/hwdev/tech/audio/DRM.asp

IP Multicast over Token-Ring Local Area Networks

RFC 1469
http://www.rfc-editor.org/rfc.html

IrDA Bridge Device Definition, 1.0

http://www.usb.org/developers

IrDA Control Specification
IrDA Serial Infrared Data Link Standard Specifications

http://www.irda.org/standards/specifications.asp

Other IrDA specifications
http://www.irda.org

IrDA Plug and Play Issues and Windows

http://msdn.microsoft.com/library/en-us/network/hh/network/210irda_15yf.asp

IrTran-P, IrLPT, and IrDA Networking Support under Windows

See the Windows DDK

ISO 13491-1:1998 Banking—Secure cryptographic devices (retail)—Part 1: Concepts, requirements and evaluation methods

http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=19521

E-mail: sales@iso.ch
http://www.iso.ch/cate/cat.html

ISO/IEC 7811-1:1995 Identification Cards—Recording technique—Part 1: Embossing

http://www.iso.ch/cate/cat.html

ISO/IEC 7811-3:1995 Identification Cards—Recording technique—Part 3: Location of embossed characters on ID-1 cards

http://www.iso.ch/cate/cat.html

ISO/IEC 7813:1995 Identification Cards—Financial transaction cards

http://www.iso.ch/cate/cat.html

ISO/IEC 7816-1:1998 Identification cards—Integrated circuit(s) cards with contacts—Part 1: Physical characteristics

http://www.iso.ch/cate/cat.html

ISO/IEC 7816-2:1999 Identification cards—Integrated circuit(s) cards with contacts—Part 2: Dimensions and location of the contacts

http://www.iso.ch/cate/cat.html

ISO/IEC 7816-3:1997 Identification cards—Integrated circuit(s) cards with contacts—Part 3: Electronic signals and transmission protocols

http://www.iso.ch/cate/cat.html

ISO/IEC 10373:1993 Identification cards—Test methods

http://www.iso.ch/cate/cat.html

ITU (International Telecommunication Union) communications standards

E-mail: sales@itu.ch
http://www.itu.int/publications/index.html

Joint EIA/CVCC Recommended Practice for Teletext: North American Basic Teletext Specification (NABTS)

http://www.tiaonline.org/

Kernel Streaming Overview

http://www.microsoft.com/ddk/

Key Benefits of the I/O APIC

http://www.microsoft.com/hwdev/platform/proc/IO-APIC.asp

Key Support and Keyboard Scan Codes for Windows web page

http://www.microsoft.com/hwdev/tech/input/Scancode.asp

Legacy-Free Hardware and BIOS Requirements

http://www.microsoft.com/hwdev/platform/PCdesign/LR/Lf.asp

Legacy PCI Interrupt Routing and CardBus in Windows

http://www.microsoft.com/hwdev/bus/cardbus/Spir.asp

Legacy Plug and Play Guidelines

http://www.pcdesguide.org/LegacyPnP/

Legacy Support for USB Keyboards and Mice and the Host Controller Driver

http://www.microsoft.com/hwdev/tech/input/usbhost.asp

Low Pin Count (LPC) Interface Specification

http://developer.intel.com/design/chipsets/industry/lpc.htm

MCNS Documents

http://www.cablemodem.org

Media Status Notification Support Specification, Version 1.03

http://www.microsoft.com/hwdev/resources/specs/storspec.asp

Microsoft Developer Network (MSDN) Professional membership

http://msdn.microsoft.com/subscriptions/

Microsoft DirectInput DDK provided with the Windows 98 DDK

http://www.microsoft.com/ddk/

Microsoft DirectShow

http://msdn.microsoft.com/directx/

Microsoft Extensible Firmware Interface FAT32 File System Specification,
Microsoft Extensible Firmware Interface Long File Name Specification,
Microsoft Portable Executable and Common Object File Format Specification,
plus other EFI-related specifications and guidelines

http://www.microsoft.com/hwdev/platform/firmware/EFI/default.asp

Microsoft information for hardware manufacturers

http://www.microsoft.com/hwdev/default.asp
E-mail: ihv@microsoft.com

Microsoft Platform SDK, including Win32® and Win64™ APIs

http://www.microsoft.com/msdownload/platformsdk/sdkupdate/
Also provided through MSDN Professional subscription

Microsoft TV Platform web page

http://www.microsoft.com/tv/

Microsoft Windows Driver Development Kit (DDK)

http://www.microsoft.com/ddk/
Also provided through MSDN Professional subscription

Microsoft Windows Hardware Compatibility List (HCL)

http://www.microsoft.com/hcl/

Microsoft Windows Hardware Compatibility Testkits (HCT)
Microsoft Windows Hardware Quality Laboratory (WHQL) testing information

http://www.microsoft.com/hwdq/hwtest/

Microsoft Windows Logo Program System and Device Requirements v.2.0
Microsoft Windows Logo Program for Hardware web page

http://www.microsoft.com/hwdev/winlogo/

Mini PCI Specification, Revision 1.0

http://www.pcisig.com/specifications

MMC-2 Multi-Media Command Set-2 standard
including SCSI Multimedia Commands

Global Engineering Documents: http://global.ihs.com/

Modem Technology web page

http://www.microsoft.com/hwdev/tech/network/modem/default.asp

Mount Rainier Drag and Drop Data on CD-RW

http://www.mt-rainier.org

MSDN Professional membership

E-mail: msdn@microsoft.com
http://msdn.microsoft.com/subscriptions/

Multifunction Device web page

http://www.microsoft.com/hwdev/tech/MF/default.asp

Multimedia Commands – 2 (MMC-2)

Global Engineering Documents: http://global.ihs.com/

Multiprocessor Specification, Version 1.4

Intel part number: 242016-002
http://developer.intel.com/design/intarch/MANUALS/242016.htm

Multiprocessor Systems and Windows Processor Steppings Support

http://www.microsoft.com/hwdev/platform/proc/SMP.asp

MultiRead Specifications for CD-ROM, CD-R, CD-R/RW, & DVD-ROM Devices, Revision 1.11

http://www.osta.org/specs/multiread.htm

Multisession Compact Disc Specification Enhanced Music CD Specification, Version 1.0

Replaced by Multi-Media Command Set-2 (MMC-2) standard

NCITS Reduced Block Commands Standard
NCITS Serial Bus Protocol-2 (SBP-2) transport protocols [ANSI NCITS 3.25-1998]

http://www.ncits.org/standards/standards.htm

NDIS 5.0

See Microsoft Windows DDK

Network Devices and Windows web page

http://www.microsoft.com/hwdev/tech/network/default.asp

Network Device Class Power Management Reference Specification, Version 1.0a

http://www.microsoft.com/hwdev/resources/specs/pmref/default.asp

Network PC System Design Guidelines, Version 1.0b

Preboot Execution Environment (PXE) Specification, Version 2.1

New Key Support for Windows web page

http://www.microsoft.com/hwdev/platform/pcdesign/desguide/pcguides.asp

OnNow and Power Management web page (OnNow and ACPI implementation guidelines under Windows operating systems)

http://www.microsoft.com/hwdev/tech/onnow/default.asp

OpenCable specification

http://www.opencable.com

OpenHCI: Open Host Controller Interface Specification for USB, Release 1.0a

http://www.microsoft.com/hwdev/resources/specs/default.asp

PAE Server Design web page

http://www.microsoft.com/hwdev/platform/server/PAE/default.asp

Parallel and Serial (COMM) Technology and Windows web page

http://www.microsoft.com/hwdev/tech/IO/superio/default.asp

PC 2001 System Design Guide

http://www.microsoft.com/hwdev/platform/pcdesign/desguide/pcguides.asp

PC '99 3.3Vaux FAQ Power Delivery/Consumption Clarifications

http://developer.intel.com/technology/iapc/pc99vqa.htm

PC Card and CardBus Guidelines, Version 1.1

http://www.microsoft.com/hwdev/platform/pcdesign/desguide/pcguides.asp

PC Card Controller Device Class Power Management Reference Specification, V. 1.0

http://www.microsoft.com/hwdev/resources/specs/pmref/PMcard.asp

PC Card Standard, Release 7

http://www.pcmcia.org/bookstore.htm

PC Card Voltage Requirements for Windows Operating Systems

http://www.microsoft.com/hwdev/bus/cardbus/pccardvlt.asp

PC Design Guides web page

http://www.microsoft.com/hwdev/platform/pcdesign/desguide/pcguides.asp

PCI Bus Power Management Interface Specification for PCI-to-CardBus Bridges, (in Volume 11 of the PC Card Standard, Release 7)

http://www.pcmcia.org/bookstore.htm

PCI Bus Power Management Interface Specification, Revision 1.1 (PCI-PM)

http://www.pcisig.com/specifications

PCI and Windows web page

http://www.microsoft.com/hwdev/bus/pci/default.asp

PCI Device Subsystem IDs and Windows

http://www.microsoft.com/hwdev/bus/pci/pciids.asp

PCI Hot-Plug Specification, Revision 1.0

http://www.pcisig.com/specifications

PCI IDE Controller Specification, Revision 1.0

http://www.pcisig.com/specifications

PCI IRQ Routing on a Multiprocessor ACPI System

http://www.microsoft.com/hwdev/bus/PCI/ACPI-MP.asp

PCI Local Bus Specification, Revision 2.2 (PCI 2.2)

http://www.pcisig.com/specifications

PCI Power Management and Device Drivers

http://www.microsoft.com/hwdev/bus/PCI/PCIpm.asp

PCI Subsystem IDs and PCI-to-PCI Bridge Devices

http://www.microsoft.com/hwdev/bus/pci/pcibridge.asp

PCI to PCI Bridge Architecture Specification, Revision 1.1

PCI SIG
http://www.pcisig.com/specifications

PCI-X Specification, Revision 1.0 (PCI-X 1.0)

http://www.pcisig.com/specifications

Personal Computer Audio Quality Measurements

by Dr. Steven Harris and Cliff Sanchez, Crystal Semiconductor
http://www.cirrus.com/design/products/pubs/

PIAFS - PHS Internal Access Forum Specification

http://www.arib.or.jp/

PIMA 15740:2000 Photography – Electronic still picture imaging – Picture Transfer Protocol (PTP) for Digital Still Photography Devices

http://www.pima.net/standards/it10/IT10_POW.htm#15740
See also the implementation guidelines in the Windows DDK.

Plug and Play External COM Device Specification, Version 1.0
Plug and Play ISA Specification, Version 1.0a and Clarifications to the Plug and Play ISA Specification, Version 1.0a
Plug and Play Parallel Port Devices, Version 1.0b
Plug and Play Design Specification for IEEE 1394, Version 1.0c

http://www.microsoft.com/hwdev/tech/pnp/default.asp

Porting Your Driver to 64-bit Windows

http://www.microsoft.com/hwdev/platform/64bit/default.asp

Preboot Execution Environment (PXE) Specification, Version 2.1

http://developer.intel.com/ial/wfm/wfmspecs.htm

Printers and Windows web page

http://www.microsoft.com/hwdev/tech/print/default.asp

QIC 157 Revision D, "Common SCSI/ATAPI Command Set For Streaming Tape"

http://www.qic.org/html/standards/15x.x/qic157d.pdf

Reduced Block Commands (RBC)

ftp://ftp.t10.org/t10/drafts/rbc/rbc-r10a.pdf

Removable Storage Management and Windows

http://www.microsoft.com/hwdev/archive/storage/RSM.asp

RFC 1469: See "IP Multicast over Token-Ring Local Area Networks."
RFC 1179; RFC 1662; RFC 1663

http://www.rfc-editor.org/rfc.html

RS-IA-64 System Abstraction Layer (SAL) Specification, Revision 2.7

http://www.intel.com/design/Itanium/Downloads/245359.htm

SBP-2 Support and Windows

http://www.microsoft.com/hwdev/tech/print/sbp2_w2000.asp

Scan Code Mapper for Windows

http://www.microsoft.com/hwdev/tech/input/w2kscan-map.asp

Scan Codes for Keyboard Power Switches

http://www.microsoft.com/hwdev/tech/input/Scancode.asp

SCSI-3 Block Commands (SBC)
SCSI-3 Primary Commands (SCSI-3 PC)
SCSI Parallel Interface-3 (SPI-3) [ANSI/NCITS T10-1302D] standard
Small Computer Interface (SCSI-2) [X3.131:1994] standard
Other SCSI standards and documents

Global Engineering Documents: http://global.ihs.com/

Serial Bus Protocol 2 (SBP-2)

ANSI NCITS 325-1998
http://web.ansi.org/public/std_info.html

Serial Port Console Redirection Table

http://www.microsoft.com/hwdev/platform/server/headless/default.asp

SFF 8070i; SFF 8090
Other SFF publications

Global Engineering Documents: http://global.ihs.com/

Shared Wireless Access Protocol (SWAP) Specification, Version 1.1

http://www.homerf.org/

SII NS-2482-30

http://www.sii.co.jp/js/nshp/product/index-e.html (English);
http://www.sii.co.jp/js/nshp/product/ (Japanese)

Simple Boot Flag Specification, Version 1.0

http://www.microsoft.com/hwdev/resources/specs/simp_bios.asp

Smart Battery Charger Specification, Revision 1.1
Smart Battery Data Specification, Revision 1.1
Smart Battery System Manager Specification, Revision 1.0

http://www.sbs-forum.org/specs/

Smart Card and Windows web page

http://www.microsoft.com/hwdev/tech/input/smartcard/default.asp

Specification for Exchangeable image file format (EXIF)

http://www.pima.net/standards/it10/PIMA15740/exif.htm

Specification ICC.1:1998-09 File Format for Color Profiles

http://www.color.org/ICC-1_1998-09.PDF

Specification for Use of PCI IDs with Windows Operating Systems

http://www.microsoft.com/hwdev/bus/pci/pciidspec.asp

Specification of the Bluetooth System, Volume 1: Core, Version 1.0 B
Specification of the Bluetooth System, Volume 2: Profiles, Version 1.0 B

http://www.bluetooth.com

Standard Modem Command Sets and Standard Modem INFs

http://www.microsoft.com/hwdev/tech/network/modem/comndset.asp

STD-201: Extensions to NDIS for Wireless WANs

http://www.pcca.org/standards/standards.htm

Still Image Architecture and Windows

http://www.microsoft.com/hwdev/archive/stillimage/w2STI.asp

Still Image Devices and Windows web page

http://www.microsoft.com/hwdev/tech/WIA/default.asp

Storage Device Class Power Management Reference Specification, Version 1.0a

http://www.microsoft.com/hwdev/resources/specs/pmref/default.asp

Storage Technology web page

http://www.microsoft.com/hwdev/tech/storage/default.asp

Streaming Media Technology

http://www.microsoft.com/hwdev/tech/stream/default.asp

Supporting PAE Memory under Windows

http://www.microsoft.com/hwdev/platform/server/PAE/PAEdrv.asp

Supporting Removable Devices under Windows

http://www.microsoft.com/hwdev/tech/PnP/rem_devs.asp

System Management BIOS Reference Specification, Version 2.3

http://www.phoenix.com/en/support/white+papers-specs/default1.htm

TIA and other standards

http://global.ihs.com/

TWAIN Specification, Version 1.7

http://www.twain.org/docs/

Unimodem Diagnostics Command Reference Specification

http://www.microsoft.com/hwdev/resources/specs/commspec.asp

Universal Disk Format Specification, Version 1.5 and Version 2.0

http://www.osta.org

Universal HCI (UHCI) Specification

http://developer.intel.com/design/usb/

Universal Host Controller Interface (UHCI) Design Guide, Revision 1.1

http://developer.intel.com/design/USB/UHCI11D.htm

Universal Serial Bus Specification, Revision 1.1
Universal Serial Bus Specification, Revision 2.0

http://www.usb.org/developers/docs.html

Update on ClearType Font Technology and LCD Displays web page

http://www.microsoft.com/hwdev/tech/display/clrtype.asp

UPS Applet for Windows

http://www.microsoft.com/hwdev/tech/onnow/ups.asp

Usage Tables for HID Power Devices, Version 1.0
Other HID-related specifications

http://www.usb.org/developers/hidpage.html

USB and Windows web page

http://www.microsoft.com/hwdev/bus/USB/default.asp

USB Class Definitions for Communication Devices, Version 1.0
USB Common Class Specification, Revision 1.1
USB Communications Class Device 1.1
USB Definitions for Communications Devices, Version 1.0
USB Device Class Definition for Audio Devices, Release 1.0
USB Device Class Definition for Device Bay Controllers
USB Device Class Definition for Human Interface Devices (HID), Version 1.1
USB Device Class Definition for MIDI Devices, V. 0.9
USB Device Class Definition for Printing Devices, Version 1.1
USB Mass Storage Class Specification Overview, Revision 1.0
USB Monitor Control Class Specification, Revision 1.0
USB PC Legacy Compatibility Specification, 0.9 Draft Revision
USB Still Image Capture Device Definition Specification, Revision 1.0
Other USB device class specifications

http://www.usb.org/developers/devclass_docs.html

USB Plug and Play IDs and Selecting Device Drivers to Load

See the Windows DDK

U.S. T1 committee Technical Report TR-59, Single-Carrier Rate Adaptive Digital Subscriber Line (RADSL)

http://www.t1.org/html/trs.htm

VCOMM Port Driver Power Management Interface

http://www.microsoft.com/hwdev/archive/devdes/vcomm.asp

VESA BIOS Extension Standard/Core Functions 2.0 (VBE/Core 2.0)

VESA Display Data Channel (DDC) Standard, Version 3

VESA Enhanced Extended Display Data Channel Standard (E-DDC), Version 1

VESA Enhanced Extended Display Identification Data Standard (E-EDID), Release A

VESA Extended Display Identification Data (EDID) Standard, Version 3

VESA Generalized Timing Formula (GTF), Version 1.1

Video Electronics Standards Association (VESA)
http://www.vesa.org/standards.htm

Video Capture

http://www.microsoft.com/hwdev/tech/stream/vidcap/default.asp

Videophone-ready Modem Handbook, Version 1.0

http://developer.intel.com/ial/vidred/index.htm

WDM Audio Drivers for Windows

http://www.microsoft.com/hwdev/tech/audio/wdmaudio.asp

WDM Kernel Streaming Architecture

http://www.microsoft.com/hwdev/tech/stream/csa1.asp

WDM Video Capture Overview

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwbgen/html/vidcap.asp

Web-Based Enterprise Management (WBEM) information

http://www.dmtf.org/

Windows Support for Mobile System Displays

http://www.microsoft.com/hwdev/tech/display/mobiledisplay.asp

Windows 98 MS-DOS Box Game Compatibility

ftp://download.intel.com/ial/sm/compatibility.pdf

Windows Color Quality Specifications for Printer OEMs

http://www.microsoft.com/hwdev/tech/color/default.asp

Windows DDK, including Windows 95 DDK; Windows 98 DDK; Windows DDK (incorporates Windows Me DDK, Windows DDK, DirectX DDK, and information about WDM and NDIS)

http://www.microsoft.com/ddk/
http://msdn.microsoft.com/library/default.asp

Windows Driver Model (WDM) Technology web page

http://www.microsoft.com/hwdev/driver/WDM/default.asp

Windows Hardware Instrumentation Implementation Guidelines (WHIIG), Version 1.0

http://www.microsoft.com/hwdev/platform/pcdesign/desguide/pcguides.asp

Windows Image Acquisition web page

http://www.microsoft.com/hwdev/tech/WIA/default.asp

Windows Logo Program for Hardware

http://www.microsoft.com/hwdev/winlogo/

Windows Management Instrumentation (WMI) and Win32 Extensions schema

http://www.microsoft.com/hwdev/driver/WMI/default.asp

Windows Modem Update

See the Windows DDK

WMI web page

http://www.microsoft.com/hwdev/driver/WMI/default.asp

Windows NT Removable Storage Manager Programming Documentation

http://msdn.microsoft.com/library/psdk/zaw/proguide_912q.htm

Windows Support for HID-based Audio Controls

http://www.microsoft.com/hwdev/tech/input/audctrl.asp

Windows Update web page

http://windowsupdate.microsoft.com


Windows Experience and Ease-of-Use Assertions

The test assertions in this section relate to the Windows Experience and ease-of-use requirements defined for the Windows Logo Program for hardware.

Driver Availability Ease-of-Use/Manual Assertions

1.1.1 System provides plus driver support for all Windows operating systems that will be preinstalled on the system.

Reference document: WLP Requirements - WL-1
Test description: TD-1.1 Driver Availability and Installation Ease-of-Use Checklist

1.1.2 System manufacturer provides the customer with drivers for all devices for all operating systems for which the system has received the Windows Logo

The exception is if a particular device class is not supported on one of the operating systems.

Reference document: WLP Requirements - WL-1
Test description: TD-1.1 Driver Availability and Installation Ease-of-Use Checklist


Device Installation and Removal Ease-of-Use/Manual Assertions

1.2.1 Device with USB, PCI, IEEE 1394, or PC Card external connectivity capabilities correctly supports hot plugging or unplugging per its bus class

Reference document: WLP Requirements - B5.1.4.2; SYS–0030
Test description: TD-1.1 Driver Availability and Installation Ease-of-Use Checklist

1.2.2 Device does not use jumpers or DIP switches for configuration during installation.

Reference document: WLP Requirements - B1.4.1; SYS–0029.2
Test description: TD-1.1 Driver Availability and Installation Ease-of-Use Checklist

1.2.3 Driver and any supporting software install correctly from hard disk drive, if that installation method is supported in the INF.

Reference document: WLP Requirements - WL-4;
Test description: TD-1.1 Driver Availability and Installation Ease-of-Use Checklist

1.2.4 Driver and any supporting software install correctly from compact disc, if that installation method is supported in the INF.

Reference document: WLP Requirements - WL-4; B1.4.1; SYS–0029
Test description: TD-1.1 Driver Availability and Installation Ease-of-Use Checklist

1.2.5 Driver and any supporting software install correctly from network share point, if that installation method is supported in the INF.

Reference document: WLP Requirements - WL-4; B1.4.1; SYS–0029
Test description: TD-1.1 Driver Availability and Installation Ease-of-Use Checklist

1.2.6 Driver and any supporting software install correctly from floppy disk, if that installation method is supported in the INF.

Reference document: WLP Requirements - WL-4; B1.4.1; SYS–0029
Test description: TD-1.1 Driver Availability and Installation Ease-of-Use Checklist

1.2.7 Driver and any supporting software installation meet Windows standards

Reference document: WLP Requirements - WL-4; B1.4.1; SYS–0029
Test description: TD-1.1 Driver Availability and Installation Ease-of-Use Checklist

1.2.8 Removal of vendor-supplied driver uses Windows-based methods, as defined in the Windows DDK

Reference document: WLP Requirements - B1.4.11
Test description: TD-1.1 Driver Availability and Installation Ease-of-Use Checklist

1.2.9 All software components and other keys added by the INF in the registry can be removed using the Add/Remove Programs utility in the Windows Control Panel.

This includes Desktop Shortcuts, Start Menu items, and toolbox applets. The availability of a Vendor-supplied remove utility in addition to the Add/Remove Programs entry is optional.

Reference document: WLP Requirements - WL-4; B1.4.11
Test description: TD-1.1 Driver Availability and Installation Ease-of-Use Checklist

1.2.10 Software installation does not replace any Microsoft-authored system components

Reference document: WLP Requirements - WL-4; B1.4.2
Test description: TD-1.1 Driver Availability and Installation Ease-of-Use Checklist

1.2.11 Software does not bypass any operating system components.

Reference document: WLP Requirements - WL-4; B1.4.2
Test description: TD-1.1 Driver Availability and Installation Ease-of-Use Checklist

1.2.12 Installation and loading of a driver does not reduce or eliminate the functionality of other devices installed on the system.

Reference document: WLP Requirements - WL-4; B1.4.3; SYS-0025.1; SDG3:68
Test description: TD-1.1 Driver Availability and Installation Ease-of-Use Checklist

1.2.13 If the manufacturer’s INF copies any files supplied by the operating system, those files are copied from the Windows product disk

The exception to this is if the component is a licensed, redistributable component.

Reference document: WLP Requirements - WL-4
Test description: TD-1.1 Driver Availability and Installation Ease-of-Use Checklist

1.2.14 Driver must not use initialization files (INI) for configuration settings

Reference document: WLP Requirements - WL-4; SYS-0025.4; SDG3:68
Test description: TD-1.1 Driver Availability and Installation Ease-of-Use Checklist

1.2.15 Driver supports unattended installation.

Reference document: WLP Requirements - WL-4; B1.4.6
Test description: TD-1.1 Driver Availability and Installation Ease-of-Use Checklist

1.2.16 Driver with special parameters includes Help file that is installed as part of the driver installation routine.

Reference document: WLP Requirements - WL-4; B1.4.7
Test description: TD-1.1 Driver Availability and Installation Ease-of-Use Checklist

1.2.17 Any supporting software included with the device must install using Windows-based installation methods, without any manual steps or file editing

Reference document: WLP Requirements - WL-7; B1.4.10
Test description: TD-1.1 Driver Availability and Installation Ease-of-Use Checklist

1.2.18 Driver and utility installation do not require a system reboot.

Reference document: WLP Requirements - WL-7; B1.4.4; for exceptions and guidelines, see Installing Drivers and Utilities without Rebooting on Windows at http://www.microsoft.com/hwdev/tech/PnP/no_reboot.asp.
Test description: TD-1.1 Driver Availability and Installation Ease-of-Use Checklist

1.2.19 After manual removal from Device Manager, the device is detected and reinstalled automatically at system reboot if it is physically present on the system

Reference document: WLP Requirements - WL-4; B1.4.1; SYS-0027, 0029; SDG3:17
Test description: TD-1.1 Driver Availability and Installation Ease-of-Use Checklist

1.2.20 For any application included in device installation that is not required for full functionality of the device, the user is given an option to install or not install the application.

Reference document: WLP Requirements - B1.4.10
Test description: TD-1.1 Driver Availability and Installation Ease-of-Use Checklist

1.2.21 Any Advanced tab in the device's Properties Dialog Box accurately reflects features the device supports.

Reference document: WLP Requirements - WL-4; B1.1.1
Test description: TD-1.1 Driver Availability and Installation Ease-of-Use Checklist

1.2.22 If the device's Properties dialog box includes an Advanced tab, all INF strings displaced are spelled correctly.

Reference document: WLP Requirements - WL-4; B1.1.1
Test description: TD-1.1 Driver Availability and Installation Ease-of-Use Checklist

1.2.23 If the device's Properties dialog box includes an Advanced tab, the driver stops and restarts dynamically if the user changes the properties and clicks Apply.

Reference document: WLP Requirements - WL-4; B1.1.1
Test description: TD-1.1 Driver Availability and Installation Ease-of-Use Checklist


Windows Compatibility Ease-of-Use/Manual Assertions

1.3.1 Implementation of the device technology does not adversely affect the performance or stability of all functionality provided under the preinstalled operating system and under Windows 2000/Windows XP.

Reference document: WLP Requirements - WL-4; B1.4.3
Test description: TD-1.2 Windows Compatibility Ease-of-Use/Manual Checklist

1.3.2 New technology (not defined in Windows Logo requirements) uses native operating system support whenever possible.

Reference document: WLP Requirements - WL-4
Test description: TD-1.2 Windows Compatibility Ease-of-Use/Manual Checklist

1.3.3 New technology (not defined in Windows Logo requirements) follows general Plug and Play and power management guidelines as defined in the DDK

Reference document: WLP Requirements - WL-4
Test description: TD-1.2 Windows Compatibility Ease-of-Use/Manual Checklist

1.3.4 All software included with a system or peripheral device must be Microsoft Win32®- or Win64®-based software.

Reference document: WLP Requirements - WL-5; B1.4.10
Test description: TD-1.2 Windows Compatibility Ease-of-Use/Manual Checklist

1.3.5 No software included with a system or peripheral device requires MS-DOS®-based decompression or installers.

This requirement does not apply for the emergency recovery software or boot device software.

Reference document: WLP Requirements - WL-5; B1.4.10
Test description: TD-1.2 Windows Compatibility Ease-of-Use/Manual Checklist

1.3.6 Drivers and utilities not use Config.sys or Autoexec.bat for configuration or to launch related software under Windows Me.

This requirement does not apply for the emergency recovery software or boot device software.

Reference document: WLP Requirements - WL-5; B1.4.10
Test description: TD-1.2 Windows Compatibility Ease-of-Use/Manual Checklist


Windows Supported Features Assertions

Windows Power Management Ease-of-Use/Manual Assertions

1.4.1 x86-based client system ensures optimal user experience for suspend and hibernate

Reference document: WLP Requirements - WL-6; A1.4.2
Test description: TD-1.3 Windows Supported Features Checklist

1.4.2 If a two-button design is used, the sleep button is the user’s primary switch interface and is easily distinguished from the power button.

Reference document: WLP Requirements - WL-6; A1.4.2; SYS-0003.3
Test description: TD-1.3 Windows Supported Features Checklist

Manageability Ease-of-Use/Manual Assertions

1.5.1 Hardware management instrumentation, if implemented, is provided per WHIIG

Reference document: WLP Requirements - B1.4.8; BIOS-0014; SDG3:229
Test description: TD-1.3 Windows Supported Features Checklist

1.5.2 Expansion devices on Windows XP Profession/Server systems can be remotely managed

Reference document: WLP Requirements - A2.4.6; SYS-0049
Test description: TD-1.3 Windows Supported Features Checklist


General Ease-of-Use Assertions

1.6.1 Connections use icons, plus keyed or shrouded connectors

Reference document: WLP Requirements - WL-7; B1.4.9
Test description: TD-1.4 General Ease-of-Use Checklist


Legacy Removal Ease-of-Use/Manual Assertions

1.7.1 Peripherals included with client system offer a non-legacy interface such as PCI, USB, IEEE 1394, or CardBus

Reference document: WLP Requirements - A1.4.7; SYS-0042
Test description: TD-1.5 Legacy Removal Ease-of-Use/Manual Checklist

1.7.2 System, or subsystem, includes no legacy audio components, i.e., no ISA, no legacy hardware interfaces, no DB-15 analog joystick/MIDI port

Reference document: WLP Requirements - B3.1.4.1; SYS-0041; AUD-0322
Test description: TD-1.5 Legacy Removal Ease-of-Use/Manual Checklist


Upgrade Migration Ease-of-Use/Manual Assertions

1.8.1 System components migrate correctly upon upgrade to later operating system

Reference document: WLP Requirements - WL-8
Test description: TD-1.6 Upgrade Migration Ease-of-Use/Manual Checklist

1.8.2 x86-based client system is capable of recovery and upgrade of the hard drive image and BIOS independent of an FDC-based floppy disk drive

Reference document: WLP Requirements - A1.4.8; SYS-0067
Test description: TD-1.6 Upgrade Migration Ease-of-Use/Manual Checklist


Multifunction Devices Ease-of-Use/Manual Assertions

1.9.1 Each function on a multifunction device has a separate driver

Reference document: WLP Requirements - B12.1.4.1, SYS-0032; SDG3:13
Test description: TD-1.7 Multifunction Devices Ease-of-Use/Manual Checklist

1.9.2 No start order dependencies exist among the separate function drivers for a multifunction device

Reference document: WLP Requirements - B12.1.4.1, SYS-0032; SDG3:13
Test description: TD-1.7 Multifunction Devices Ease-of-Use/Manual Checklist

1.9.31 Each independent function on a multifunction device can be used concurrently, without interfering with each other or with other devices on the system

Reference document: WLP Requirements -B12.1.4.3, SYS-0032; SDG3:13
Test description: TD-1.7 Multifunction Devices Ease-of-Use/Manual Checklist

1.9.4 There are no hidden dependencies for each independent function on a multifunction device

Reference document: WLP Requirements -B12.1.4.3, SYS-0032; SDG3:13
Test description: TD-1.7 Multifunction Devices Ease-of-Use/Manual Checklist

1.9.5 Each function on a multifunction device can be power managed independently

Reference document: WLP Requirements - B12.1.4.4, SYS-0032; SDG3:13
Test description: TD-1.7 Multifunction Devices Ease-of-Use/Manual Checklist

1.9.6 Each function on a multifunction device successfully completes a system transition D0 to D3cold to D0

Reference document: WLP Requirements - B12.1.4.4, SYS-0032; SDG3:13
Test description: TD-1.7 Multifunction Devices Ease-of-Use/Manual Checklist

1.9.7 Each function that supports wakeup capabilities on a multifunction device correctly supports wake from D3cold

Reference document: WLP Requirements - B12.1.4.4, SYS-0032; SDG3:13
Test description: TD-1.7 Multifunction Devices Ease-of-Use/Manual Checklist


IEEE 1394 Ease-of-Use/Manual Assertions

1.10.1 IEEE 1394 device enumeration was correct for all ports on Test device or controller after install/uninstall

Reference document: WLP Requirements - B2.2.4; 1394-0098
Test description: TD-1.8 IEEE 1394 Ease-of-Use/Manual Checklist


USB Ease-of-Use/Manual Assertions

1.11.1 USB devices and drivers support maximum flexibility of hardware interface options

Reference document: WLP Requirements - B2.6.4.4; USB-0084; SDG3:58
Test description: TD-1.9 USB Ease-of-Use/Manual Checklist

1.11.2 USB devices install and perform at least some functions expected by end users for that class of device, without preloading software

Reference document: WLP Requirements - B2.6.4.7; USB-0089; SDG3:62
Test description: TD-1.9 USB Ease-of-Use/Manual Checklist


CardBus Ease-of-Use/Manual Assertions

1.12.1 PC Card or CardBus device installs without user intervention and without restarting the system

The exception to this is when the operating system requires a system reboot for a particular device class.

Reference document: WLP Requirements - B2.1.4.4; PCCard-20, 21; SYS-0024
Test description: TD-1.10 CardBus Ease-of-Use/Manual Checklist


Systems - Device and Port Ease-of-Use/Manual Assertions

Desktop System Device and Port Ease-of-Use/Manual Assertions

1.13.1 Desktop system includes two USB ports

Reference document: WLP Requirements - A2.4.1; SYS-0021
Test description: TD-1.11 Systems - Device and Port Ease-of-Use/Manual Checklist

1.13.2 Desktop system with IEEE 1394 has at least two externally-accessible sockets

Reference document: WLP Requirements - A2.4.1; SYS-0022
Test description: TD-1.11 Systems - Device and Port Ease-of-Use/Manual Checklist

Mobile PC Device and Port Ease-of-Use/Manual Assertions

1.14.1 Every device in a mobile PC system functions fully on both AC and DC power.

Does not include power management functionality however the user should never see degradation in performance (unless set as such in the PM applet) or loss of functionality in the system.

Reference document: WLP Requirements - A3.4.1
Test description: TD-1.11 Systems - Device and Port Ease-of-Use/Manual Checklist

1.14.2 Mobile system contains at least one USB port free for end-user expansion

Reference document: WLP Requirements - A3.4.4
Test description: TD-1.11 Systems - Device and Port Ease-of-Use/Manual Checklist

1.14.3 Mobile system contains at least one 32-bit Type-2 CardBus slot

Reference document: WLP Requirements - A3.4.4; MOBL-0065
Test description: TD-1.11 Systems - Device and Port Ease-of-Use/Manual Checklist

1.14.4 Mobile system with IEEE 1394 includes at least one externally-accessible socket

Reference document: WLP Requirements - A3.4.10; SYS-0022
Test description: TD-1.11 Systems - Device and Port Ease-of-Use/Manual Checklist

Server Device and Port Ease-of-Use/Manual Assertions

1.15.1 Server includes USB controller with at least one USB port

Reference document: WLP Requirements - A6.4.2; SDG3:56
Test description: TD-1.11 Systems - Device and Port Ease-of-Use/Manual Checklist

1.15.2 Parallel port design present on IA-32 server system provides sufficient space for connector assembly

Reference document: WLP Requirements - A6.4.6; SDG3:207
Test description: TD-1.11 Systems - Device and Port Ease-of-Use/Manual Checklist


Audio Ease-of-Use/Manual Assertions

1.16.1 Audio on PC client system does not utilize analog mixing of audio sources for output

Reference document: WLP Requirements - A1.4.10
Test description: TD-1.12 Audio Ease-of-Use/Manual Checklist

1.16.2 All audio sources on PC client system are available as digital audio streams accessible to the system-wide kernel mixer.

Reference document: WLP Requirements - A1.4.10
Test description: TD-1.12 Audio Ease-of-Use/Manual Checklist

1.16.3 All audio content on PC client system is available at both the analog jack and USB port.

Reference document: WLP Requirements - A1.4.10
Test description: TD-1.12 Audio Ease-of-Use/Manual Checklist

1.16.4 SNR, measured at the output jack using line level back termination, is greater than or equal to 80 dBr, A weighted.

Reference document: WLP Requirements - B3.1.4.4; AUD-0325, 0329
Test description: TD-1.12 Audio Ease-of-Use/Manual Checklist -- based on test method TM002 in "Audio Quality Test Methods at http://www.cirrus.com/design/products/pubs/

1.16.5 SNR, measured at the input jack using line level back termination, is greater than or equal to 70 dBr, A weighted.

Reference document: WLP Requirements - B3.1.4.4; AUD-0325, 0329
Test description: TD-1.12 Audio Ease-of-Use/Manual Checklist -- based on test method TM003 in "Audio Quality Test Methods" at http://www.cirrus.com/design/products/pubs/


Printer Ease-of-Use/Manual Assertions

1.17.1 Network Point-and-Print capability accommodate file-number limits and other differences between operating systems that might run on the client and server

Reference document: WLP Requirements - B8.1.4.1; PRNT-0303
Test description: TD-1.13 Printer Ease-of-Use/Manual Checklist

1.17.2 Network printer supports standard port monitor

Reference document: WLP Requirements - B8.1.4.3; PRNT-0295
Test description: TD-1.13 Printer Ease-of-Use/Manual Checklist

1.17.3 Printer is available immediately following installation

Reference document: WLP Requirements - B8.1.4.5; PRNT-0304
Test description: TD-1.13 Printer Ease-of-Use/Manual Checklist

1.17.4 After device installation, registry shows correct information for ICM profile

Reference document: WLP Requirements - B8.1.4.2
Test description: TD-1.13 Printer Ease-of-Use/Manual Checklist

1.17.5 Print device provides non-legacy port connection

Reference document: WLP Requirements - B8.1.4.6; PRNT-0294, 0297
Test description: TD-1.13 Printer Ease-of-Use/Manual Checklist

1.17.6 Printer driver installs correctly when sharing the printer on the network.

Reference document: WLP Requirements - B8.1.1.1; B8.1.3.6
Test description: TD-1.13 Printer Ease-of-Use/Manual Checklist

1.17.7 User is not prompted for driver location when attempting to use a printer that is shared on the network.

Reference document: WLP Requirements - B8.1.1.1; B8.1.3.6
Test description: TD-1.13 Printer Ease-of-Use/Manual Checklist

1.17.8 User can print correctly after installing a printer that is shared on the network.

Reference document: WLP Requirements - B8.1.1.1; B8.1.3.6
Test description: TD-1.13 Printer Ease-of-Use/Manual Checklist

1.17.9 Print capabilities that were available before a system was suspended are all available immediately after the system resumes from Standby.

Reference document: WLP Requirements - B1.4.5
Test description: TD-1.13 Printer Ease-of-Use/Manual Checklist


Monitor Ease-of-Use/Manual Assertions

1.18.1 After device installation, registry information matches INF values for manufacturer name, Hardware ID, device description, and device capabilities

Reference document: WLP Requirements - B4.2.1.1
Test description: TD-1.14 Monitor Ease-of-Use/Manual Checklist

1.18.2 After device installation, registry shows correct information for ICM profile

Reference document: WLP Requirements - B4.2.4.2
Test description: TD-1.14 Monitor Ease-of-Use/Manual Checklist

1.18.3 USB functionality from either an HID or USB hub, if implemented, must be installed separately from the monitor INF

Reference document: WLP Requirements - B4.2.4.7; MON-0236
Test description: TD-1.14 Monitor Ease-of-Use/Manual Checklist

1.18.4 USB hub, if implemented, must be self powered or externally powered, not bus-powered

Reference document: WLP Requirements - B4.2.4.8; MON-0236
Test description: TD-1.14 Monitor Ease-of-Use/Manual Checklist

1.18.5 After device installation, DPMS is enabled

Reference document: WLP Requirements - A1.4.2
Test description: TD-1.14 Monitor Ease-of-Use/Manual Checklist

Monitor Multimedia Features Ease-of-Use/Manual Assertions

These assertions are related to any multimedia features that might be included with a monitor, such as speakers, headphone jacks, and related controls.

1.19.1 If audio features are included, there is no interference with the display functionality when a media source is connected.

Reference document: WLP Requirements - B11.4.4.6; VID-0215
Test description: TD-1.14 Monitor Ease-of-Use/Manual Checklist

1.19.2 All controls work as documented and expected when a media source is connected.

Reference document: WLP Requirements - B11.4.4.6; VID-0215
Test description: TD-1.14 Monitor Ease-of-Use/Manual Checklist

1.19.3 If audio features are included, sound quality is clear, with no excessive static, buzzing, or popping.

Reference document: WLP Requirements - B11.4.4.6; VID-0215
Test description: TD-1.14 Monitor Ease-of-Use/Manual Checklist

Monitor Tele/Video Conferencing Features Ease-of-Use/Manual Assertions

These assertions are related to any teleconferencing features that might be included with a monitor, such as microphone, video camera, and related controls. For a proprietary solution, the entire device, including the monitor, is tested together.

1.20.1 If teleconferencing features are included, there is no interference with the display functionality when a media output and input sources are connected.

Reference document: WLP Requirements - B11.4.4.6; VID-0215
Test description: TD-1.14 Monitor Ease-of-Use/Manual Checklist

1.20.2 All controls work as documented and expected when a media source is connected.

Reference document: WLP Requirements - B11.4.4.6; VID-0215
Test description: TD-1.14 Monitor Ease-of-Use/Manual Checklist

1.20.3 If teleconferencing features are included, sound quality is clear, with no excessive static, buzzing, or popping.

Reference document: WLP Requirements - B11.4.4.6; VID-0215
Test description: TD-1.14 Monitor Ease-of-Use/Manual Checklist

Television CRTs Ease-of-Use/Manual Assertions

These assertions are related to any television CRT features that might be included, such as speakers, audio pass through, video pass through, and related controls

1.21.1 CRT-based monitor synchronizes to a new format in less than three seconds

Reference document: WLP Requirements - B4.2.4.9; MON-0238
Test description: TD-1.14 Monitor Ease-of-Use/Manual Checklist

1.21.2 If television CRT features are included, there is no interference with the display functionality when a media output and input sources are connected.

Reference document: WLP Requirements - B11.4.4.6; VID-0215
Test description: TD-1.14 Monitor Ease-of-Use/Manual Checklist

1.21.31 All controls work as documented and expected when a media source is connected.

Reference document: WLP Requirements - B11.4.4.6; VID-0215
Test description: TD-1.14 Monitor Ease-of-Use/Manual Checklist

1.21.41 If television CRT features are included, sound quality is clear, with no excessive static, buzzing, or popping.

Reference document: WLP Requirements - B11.4.4.6; VID-0215
Test description: TD-1.14 Monitor Ease-of-Use/Manual Checklist

1.21.51 Video devices connected via S-Video, RCA/Composite, SVGA, or other connections receive a clean and correct video signal.

Reference document: WLP Requirements - B11.4.4.6; VID-0215
Test description: TD-1.14 Monitor Ease-of-Use/Manual Checklist


Still Image Device Ease-of-Use/Manual Assertions

1.22.1 Imaging device includes IEEE 1394 or USB connection

Reference document: WLP Requirements - B9.1.4.1; IMAG-0309
Test description: TD-1.15 Still Image Device Ease-of-Use/Manual Checklist


Video Capture Ease-of-Use/Manual Assertions

Step/Single Frame Capture Ease-of-Use/Manual Assertions

1.23.1 Color and satisfactory image quality are preserved

Reference document: WLP Requirements - B11.4.4.6; VID-215
Test description: TD-1.16 Video Capture Ease-of-Use/Manual Checklist

1.23.2 Device that supports time code control accurately controls all ViSCA and Time code capable hardware

Reference document: WLP Requirements - B11.4.4.7; VID-224
Test description: TD-1.16 Video Capture Ease-of-Use/Manual Checklist

Full Motion Capture Ease-of-Use/Manual Assertions

1.24.1 Device can capture video at all supported resolutions for all color depths over a sustained duration of 5 minutes.

Reference document: WLP Requirements - B11.4.3.1; VID-0215
Test description: TD-1.16 Video Capture Ease-of-Use/Manual Checklist

Video Capture Utilities and Applications Ease-of-Use/Manual Assertions

1.25.1 No unexpected or undesired behavior occurs when running any application provided with the device.

This includes no artifacts, lines, discoloration, contrast/brightness irregularities, corruption, or any other unexpected items.

Reference document: WLP Requirements - B11.4.4.6; B11.4.4.7; VID-215; VID-224
Test description: TD-1.16 Video Capture Ease-of-Use/Manual Checklist

1.25.2 Multi-tasking capabilities of the operating system are not hampered in any way when any application provided with the device is running.

Reference document: WLP Requirements - B11.4.4.6; B11.4.4.7; VID-215; VID-224
Test description: TD-1.16 Video Capture Ease-of-Use/Manual Checklist

1.25.3 Colors are similarly matched and are of tolerable quality for any application provided with the device.

Reference document: WLP Requirements - B11.4.4.6; B11.4.4.7; VID-215; VID-224
Test description: TD-1.16 Video Capture Ease-of-Use/Manual Checklist

1.25.4 Background applications do not affect the performance of any application provided with the device.

Example activities include sending or receiving e-mail or facsimile, telephone dialing, downloading files via Internet, or running Notepad or a similar accessory.

Reference document: WLP Requirements - B11.4.4.6; B11.4.4.7; VID-215; VID-224
Test description: TD-1.16 Video Capture Ease-of-Use/Manual Checklist


DVD-MPEG Playback Ease-of-Use/Manual Assertions

DVD Installation - Ease-of-Use/Manual Assertions

1.26.1 Vendor-supplied driver for DVD-MPEG playback hardware solution installs correctly

Reference document: WLP Requirements - B1.4
Test description: TD-1.17 DVD-MPEG Playback Ease-of-Use/Manual Checklist

1.26.2 Vendor-supplied driver for DVD-MPEG playback hardware solution works without rebooting.

Reference document: WLP Requirements - B1.4.4
Test description: TD-1.17 DVD-MPEG Playback Ease-of-Use/Manual Checklist

1.26.3 Vendor-supplied DVD software solution installs correctly.

Reference document: WLP Requirements - B1.4.10
Test description: TD-1.17 DVD-MPEG Playback Ease-of-Use/Manual Checklist

DVD Playback Quality & Applications - Ease-of-Use/Manual Assertions

1.27.1 End-user perception of playback experience is the same or better than with a stand-alone player

Reference document: WLP Requirements - B11.2.4.1
Test description: TD-1.17 DVD-MPEG Playback Ease-of-Use/Manual Checklist

1.27.2 Multiple aspect ratio content is displayed correctly, with the default being the information in the MPEG header

This includes support of widescreen and full screen DVD multi-layer format verification.

Reference document: WLP Requirements - B11.2.4.2, VID-215.5
Test description: TD-1.17 DVD-MPEG Playback Ease-of-Use/Manual Checklist

1.27.3 No unexpected or undesired behavior or video degradation occurs when running any application provided with the device.

This includes no artifacts, lines, discoloration, contrast/brightness irregularities, corruption, or any other unexpected items. Parental Control and Parental Control Override must be supported so that a title of higher parental setting cannot automatically begin play back.

Reference document: WLP Requirements - B11.4.4.6; B11.4.4.7; VID-215; VID-224
Test description: TD-1.17 DVD-MPEG Playback Ease-of-Use/Manual Checklist

1.27.4 General performance and functionality of the operating system are not hampered in any way when any application provided with the device is running.

Reference document: WLP Requirements - B11.4.4.6; B11.4.4.7; VID-215; VID-224
Test description: TD-1.17 DVD-MPEG Playback Ease-of-Use/Manual Checklist

1.27.5 General performance and functionality of the operating system are not hampered in any way after any application provided with the device is closed.

Reference document: WLP Requirements - B11.4.4.6; B11.4.4.7; VID-215; VID-224
Test description: TD-1.17 DVD-MPEG Playback Ease-of-Use/Manual Checklist

1.27.6 Colors are similarly matched and are of tolerable quality for any application provided with the device.

Reference document: WLP Requirements - B11.4.4.6; B11.4.4.7; VID-215; VID-224
Test description: TD-1.17 DVD-MPEG Playback Ease-of-Use/Manual Checklist

1.27.7 Background applications do not affect the performance of any application provided with the device.

Example activities include sending or receiving e-mail or facsimile, telephone dialing, downloading files via Internet, or running Notepad or a similar accessory.

Reference document: WLP Requirements - B11.4.4.6; B11.4.4.7; VID-215; VID-224
Test description: TD-1.17 DVD-MPEG Playback Ease-of-Use/Manual Checklist

1.27.8 No unexpected or undesired behavior or video degradation.

This includes enabling and disabling closed captioning via the player without using authored menus. Captioning must appear and be removed from the overlay without causing video artifacts such as dropped frames.

Reference document: WLP Requirements - B11.2.4.3
Test description: TD-1.17 DVD-MPEG Playback Ease-of-Use/Manual Checklist

1.27.9 All DVD player test cases pass when the vendor-provided DVD player application is running

Reference document: WLP Requirements - B11.2
Test description: TD-1.17 DVD-MPEG Playback Ease-of-Use/Manual Checklist

1.27.10 Microsoft DVD Player application runs on any system that support DVD playback.

Reference document: WLP Requirements - B11.2.5.2
Test description: TD-1.17 DVD-MPEG Playback Ease-of-Use/Manual Checklist


General Input Device Installation Ease-of-Use/Manual Assertions

1.28.1 Keyboard and other input devices work correctly with the Microsoft Accessibility features in Windows.

Reference document: WLP Requirements - WL-7, SYS-0020
Test description: TD-1.18 General Input Device Installation Ease-of-Use/Manual Checklist

1.28.2 All modifier keys are capable of being read and operated by software, including Fn and similar OEM-specific keys.

Reference document: WLP Requirements - WL-7, SYS-0020
Test description: TD-1.18 General Input Device Installation Ease-of-Use/Manual Checklist

1.28.3 Miniport driver that supports Microsoft DirectInput can be dynamically loaded and unloaded

Reference document: WLP Requirements - B5.1.4.3; INPT-0133
Test description: TD-1.18 General Input Device Installation Ease-of-Use/Manual Checklist

1.28.4 Miniport driver that supports Microsoft DirectInput is immediately available without rebooting the system.

Reference document: WLP Requirements - B5.1.4.3; INPT-0133
Test description: TD-1.18 General Input Device Installation Ease-of-Use/Manual Checklist

1.28.5 If the input device uses a vendor-supplied driver, all keys and buttons are fully functional at the end-user level after the INF installation.

This includes hot buttons or function keys.

Reference document: WLP Requirements - B5.1.3.2
Test description: TD-1.18 General Input Device Installation Ease-of-Use/Manual Checklist

1.28.6 Hot-plugging of input device does not damage system or device.

Reference document: WLP Requirements - B5.1.4.2; SYS-0030; SDG3:47
Test description: TD-1.18 General Input Device Installation Ease-of-Use/Manual Checklist

1.28.7 All non-PS/2 input devices use USB or external bus connections rather than legacy serial or parallel

Reference document: WLP Requirements - B5.1.4.6; INPT-0135
Test description: TD-1.18 General Input Device Installation Ease-of-Use/Manual Checklist

1.28.8 All USB input devices meet USB HID specifications

Reference document: WLP Requirements - B5.1.4.5; INPT-0133
Test description: TD-1.18 General Input Device Installation Ease-of-Use/Manual Checklist

1.28.9 Installation of USB input device does not require reboot

Reference document: WLP Requirements - B1.4.1; SYS-0029.1
Test description: TD-1.18 General Input Device Installation Ease-of-Use/Manual Checklist


Game Devices Ease-of-Use/Manual Assertions

1.29.1 Installation routine for analog game device launches the Joystick Control Panel applet for calibration

Reference document: WLP Requirements - B5.4.2
Test description: TD-1.19 Game Devices Ease-of-Use/Manual Checklist

1.29.2 Manual calibration for analog game device works correctly

Reference document: WLP Requirements - B5.4.2
Test description: TD-1.19 Game Devices Ease-of-Use/Manual Checklist

1.29.3 Installation routine for digital game device correctly updates calibration information in the Registry based on the device's .INF file

Reference document: WLP Requirements - B5.4.5.1
Test description: TD-1.19 Game Devices Ease-of-Use/Manual Checklist

1.29.4 Device performs as expected with common Windows-based multimedia applications

Reference document: WLP Requirements - B5.4.4.2
Test description: TD-1.19 Game Devices Ease-of-Use/Manual Checklist


Keyboard Ease-of-Use/Manual Assertions

1.30.1 No interference occurs between multiple keyboards.

Reference document: WLP Requirements - B5.2.4.4; INPT-0143
Test description: TD-1.20 Keyboard Ease-of-Use/Manual Checklist


Keyboard/Video/Mouse Ease-of-Use/Manual Assertions

1.31.1 KVM implements cascading switch boxes

Reference document: WLP Requirements - B5.5.4.1
Test description: TD-1.21 Keyboard/Video/Mouse Ease-of-Use/Manual Checklist

1.31.2 KVM supports on-screen display for switching between machines

Reference document: WLP Requirements - B5.5.4.2
Test description: TD-1.21 Keyboard/Video/Mouse Ease-of-Use/Manual Checklist

1.31.3 KVM supports ability to switch between machines using a keyboard

Reference document: WLP Requirements - B5.5.4.3
Test description: TD-1.21 Keyboard/Video/Mouse Ease-of-Use/Manual Checklist

1.31.4 Computer recognizes any Plug and Play keyboard, mouse, or monitor connected to the KVM

Reference document: WLP Requirements - B5.5.4.4
Test description: TD-1.21 Keyboard/Video/Mouse Ease-of-Use/Manual Checklist

1.31.5 Computer resets the KVM device ports in case a corruption results in an incorrect output signal sent from a connected device to the operating system

Reference document: WLP Requirements - B5.5.4.5
Test description: TD-1.21 Keyboard/Video/Mouse Ease-of-Use/Manual Checklist

1.31.6 All devices and cables connected to the KVM are hot pluggable and have proper icons and colors

Reference document: WLP Requirements - B5.5.4.6
Test description: TD-1.21 Keyboard/Video/Mouse Ease-of-Use/Manual Checklist


Pointing Device Ease-of-Use/Manual Assertions

1.32.1 After physically installing the device and starting Windows, an external PS/2-compatible device is immediately functional without a system reboot.

Reference document: WLP Requirements - B5.3.3.3
Test description: TD-1.22 Pointing Device Ease-of-Use/Manual Checklist

1.32.2 On a mobile PC, the internal pointing device is disabled when an external PS/2 pointing device is installed; alternately, an option is provided in the BIOS to enable dual operation of the internal and external PS/2 pointing devices.

Reference document: WLP Requirements - B5.3.3.4
Test description: TD-1.22 Pointing Device Ease-of-Use/Manual Checklist

1.32.3 After wheel mouse software is installed on the system, the wheel can be used for scrolling in application windows.

Reference document: WLP Requirements - B5.3.4.1
Test description: TD-1.22 Pointing Device Ease-of-Use/Manual Checklist

1.32.4 Wheel mouse supports additional wheel mouse features as advertised in Microsoft Office 2000 products and Internet Explorer 5.0.

Reference document: WLP Requirements - B5.3.4.1
Test description: TD-1.22 Pointing Device Ease-of-Use/Manual Checklist

1.32.5 Pointing device functions correctly in multimedia applications that require mouse support, such as Microsoft Encarta® 99 and MS-DOS-based applications.

Reference document: WLP Requirements - B5.3.4.1
Test description: TD-1.22 Pointing Device Ease-of-Use/Manual Checklist

1.32.6 Pointing device functions correctly when switching on-the-fly from MS-DOS-based applications to Windows

Reference document: WLP Requirements - B5.3.4.1
Test description: TD-1.22 Pointing Device Ease-of-Use/Manual Checklist


Smart Card Ease-of-Use/Manual Assertions

1.33.1 Smart card driver supports multiple instances of the same device on system without problems

Reference document: WLP Requirements - B5.6.4.2
Test description: TD-1.23 Smart Card Ease-of-Use/Manual Checklist

1.33.2 Smart card device on COM1 or COM2 is properly enumerated upon removal and reconnection

Reference document: WLP Requirements - B1.4.1
Test description: TD-1.23 Smart Card Ease-of-Use/Manual Checklist

1.33.3 Smart card device on COM1 or COM2 is properly enumerated upon system reboot

Reference document: WLP Requirements - B1.4.1
Test description: TD-1.23 Smart Card Ease-of-Use/Manual Checklist


General Storage Device Ease-of-Use/Manual Assertions

1.34.1 Storage device driver runs in 32-bit protected mode under Windows 98/Me after installation

Reference document: WLP#- B10.2.4.1; PC2001 - SYS-0025
Test description: TD-1.24 General Storage Device Ease-of-Use/Manual Checklist

1.34.2 Bus type is clearly indicated using ANSI-approved icons on external connectors for all adapters, peripherals, cables, and terminators

Reference document: WLP#- B10.3.4.5.1; PC2001 - SCSI-0108; SDG3:163
Test description: TD-1.24 General Storage Device Ease-of-Use/Manual Checklist

1.34.3 Terminator power is supplied to the SCSI bus with overcurrent protection

Reference document: WLP#- B10.3.4.5.4; PC2001 - SCSI-0111; SDG3:140
Test description: TD-1.24 General Storage Device Ease-of-Use/Manual Checklist

1.34.4 External connector meets SCSI-2 or later standard

Reference document: WLP#- B10.3.4.5.5; PC2001 - SCSI-0108; SDG3:167
Test description: TD-1.24 General Storage Device Ease-of-Use/Manual Checklist

1.34.5 Controller and peripheral connections include Pin 1 cable designation; shielded device connector meets SCSI-2 or later standard

Reference document: WLP#- B10.3.4.5.6; PC2001 - SCSI-0108; SDG3:169
Test description: TD-1.24 General Storage Device Ease-of-Use/Manual Checklist

1.34.6 External devices use automatic termination or an accessible on-board termination switch

Not required for Fault-Tolerant RAID devices where the terminators are considered to be a Field Replaceable Unit (FRU).

Reference document: WLP#- B10.3.4.5.7; PC2001 - STOR-0345; SDG3:170
Test description: TD-1.24 General Storage Device Ease-of-Use/Manual Checklist

1.34.7 Option ROM supports virtual DMA services

Reference document: WLP#- B10.3.4.5.8; PC2001 - SCSI-0104; SDG3:146
Test description: TD-1.24 General Storage Device Ease-of-Use/Manual Checklist

1.34.8 Controller and peripherals implement SCSI bus data protection signal

Reference document: WLP Requirements - B10.3.4.6; SDG3:142; SDG3:168
Test description: TD-1.24 General Storage Device Ease-of-Use/Manual Checklist

1.34.9 Hardware supports the SCSI-3 STOP/START UNIT command to decrease power consumption

Reference document: WLP Requirements - B10.3.4.7; STOR-0346; SDG3:172
Test description: TD-1.24 General Storage Device Ease-of-Use/Manual Checklist

1.34.10 SCSI controller provides multi-initiator support if the controller provides external device connection capability for use as a cluster node

Reference document: WLP Requirements - B10.3.4.10; SDG3:162
Test description: TD-1.24 General Storage Device Ease-of-Use/Manual Checklist

1.34.11 For ATA controller, DVD drive attached and functionality tested (movie playback)

Reference document: WLP Requirements - B10.2.3.1.5
Test description: TD-1.24 General Storage Device Ease-of-Use/Manual Checklist

1.34.12 ATA controller meets Windows installation requirements - Windows 98/Me > Windows 2000/Windows XP Upgrade Test (FAT16 > FAT32 upgrade; FAT32 > NTFS conversion)

Reference document: WLP Requirements - B10.1.3.2.7
Test description: TD-1.24 General Storage Device Ease-of-Use/Manual Checklist

1.34.13 For ATA controller, adapter is capable of sharing IRQ and works behind a PCI-PCI bridge

Reference document: WLP Requirements - B10.3.4.4
Test description: TD-1.24 General Storage Device Ease-of-Use/Manual Checklist


Hard Disk Drive Ease-of-Use/Manual Assertions

1.35.1 Hot-swappable drive offered for server systems includes a local disk drive replacement indicator

Reference document: WLP#- B10.4.4.4; SDG3:224
Test description: TD-1.25 Hard Disk Drive Ease-of-Use/Manual Checklist


CD/DVD Drives Ease-of-Use/Manual Assertions

1.36.1 CD device provides 8x minimum transfer rate or better performance

Reference document: WLP#- B10.5.4.2.1; PC2001 - STOR-0362; SDG3:185
Test description: TD-1.26 CD/DVD Drives Ease-of-Use/Manual Checklist

1.36.2 DVD storage device provides 2 MB per second minimum transfer rate or better performance anywhere on the disc

Reference document: WLP#- B10.5.4.3; PC2001 - STOR-0360; SDG3:191
Test description: TD-1.26 CD/DVD Drives Ease-of-Use/Manual Checklist

1.36.3 DVD drive supports logical and physical CD formats

Reference document: WLP#- B10.5.4.3.2; PC2001 - STOR-0361; SDG3:192
Test description: TD-1.26 CD/DVD Drives Ease-of-Use/Manual Checklist

1.36.4 DVD drive supports MMC-2

Reference document: WLP#- B10.5.4.3.2; PC2001 - STOR-0361; SDG3:192
Test description: TD-1.26 CD/DVD Drives Ease-of-Use/Manual Checklist

1.36.5 DVD drive supports defect management

Reference document: WLP#- B10.5.4.3.2; PC2001 - STOR-0361; SDG3:192
Test description: TD-1.26 CD/DVD Drives Ease-of-Use/Manual Checklist


Tape Drive Ease-of-Use/Manual Assertions

1.37.1 ATAPI tape device supports the termination scheme defined in ATA/ATAPI-5

Reference document: WLP#- B10.5.4.3.2
Test description: TD-1.27 Tape Drive Ease-of-Use/Manual Checklist

1.37.2 Driver for ATAPI tape device is integrated with Removable Storage Manager

Reference document: WLP#- B10.5.4.3.2, B10.7.4.2; SDG3:198

Test description: TD-1.27 Tape Drive Ease-of-Use/Manual Checklist

1.37.3 Single-backup tape device designed for Windows Server meets 10 GB minimum capacity requirements

Reference document: WLP#- B10.7.4.3 ; SDG3:196
Test description: TD-1.27 Tape Drive Ease-of-Use/Manual Checklist

1.37.4 Single-backup tape device designed for Windows Advanced Server meets 20 GB minimum capacity requirements

Reference document: WLP#- B10.7.4.3 ; SDG3:196
Test description: TD-1.27 Tape Drive Ease-of-Use/Manual Checklist


Media Changer Devices Ease-of-Use/Manual Assertions

1.38.1 CD changer device that supports 7 discs or less complies with MMC-2

Reference document: WLP#- B10.8.4.1; PC2001 - STOR-0356; SDG3:199
Test description: TD-1.28 Media Changer Devices Ease-of-Use/Manual Checklist

1.38.2 SCSI tape changer and driver support auto-configuration

Reference document: WLP#- B10.8.4.2; SDG3:200
Test description: TD-1.28 Media Changer Devices Ease-of-Use/Manual Checklist

1.38.3 SCSI tape and optical disk changer support auto-configuration

Reference document: WLP#- B10.8.4.3; SDG3:201
Test description: TD-1.28 Media Changer Devices Ease-of-Use/Manual Checklist


RAID Ease-of-Use/Manual Assertions

1.39.1 All external connectors for RAID are labeled with ANSI approved icon for bus type

Reference document: WLP#- B10.9.4.1
Test description: TD-1.29 RAID Ease-of-Use/Manual Checklist

1.39.2 RAID supports include notification of failed drive

Reference document: WLP#- B10.9.4.3; SDG3:219
Test description: TD-1.29 RAID Ease-of-Use/Manual Checklist

1.39.3 RAID subsystem supports automatic replacement of failed drive

Reference document: WLP#- B10.9.4.4; SDG3:220
Test description: TD-1.29 RAID Ease-of-Use/Manual Checklist

1.39.4 RAID subsystem supports manual replacement of failed drive (SDG3:221)

Reference document: WLP#- B10.9.4.5; SDG3:221
Test description: TD-1.29 RAID Ease-of-Use/Manual Checklist


UPS Ease-of-Use/Manual Assertions

UPS Ease-of-Use/Manual Assertions

1.40.1 Device can take over and properly notify the user that the device is on battery, or shut down applications and the system, or both

Reference document: WLP Requirements - B12.2.4.1
Test description: TD-1.30 UPS Ease-of-Use/Manual Checklist

1.40.2 UPS device load is measured accurately

Reference document: WLP Requirements - B12.2.4.2
Test description: TD-1.30 UPS Ease-of-Use/Manual Checklist

1.40.3 UPS device battery modules on larger units are hot swappable

Reference document: WLP Requirements - B12.2.4.3
Test description: TD-1.30 UPS Ease-of-Use/Manual Checklist

1.40.4 UPS device can notify the user that the power is down via email, pager, or both

Reference document: WLP Requirements - B12.2.4.4
Test description: TD-1.30 UPS Ease-of-Use/Manual Checklist

1.40.5 UPS device built-in functionality can properly support the device

Reference document: WLP Requirements - B12.2.4.5
Test description: TD-1.30 UPS Ease-of-Use/Manual Checklist

UPS Device PnP Ease-of-Use/Manual Assertions

1.41.1 UPS device on COM1 or COM2 is properly enumerated upon removal and reconnection

Reference document: WLP Requirements - B1.4.1
Test description: TD-1.30 UPS Ease-of-Use/Manual Checklist

1.41.2 UPS device on COM1 or COM2 is properly enumerated upon system reboot

Reference document: WLP Requirements - B1.4.1
Test description: TD-1.30 UPS Ease-of-Use/Manual Checklist


Checklists for Windows Experience and Ease-of-Use Requirements

The following checklists are provided:

TD-1.1 Driver Availability and Installation Ease-of-Use Checklist

TD-1.2 Windows Compatibility Ease-of-Use/Manual Checklist

TD-1.3 Windows Supported Features Checklist

TD-1.4 General Ease-of-Use Checklist

TD-1.5 Legacy Removal Ease-of-Use/Manual Checklist

TD-1.6 Upgrade Migration Ease-of-Use/Manual Checklist

TD-1.7 Multifunction Devices Ease-of-Use/Manual Checklist

TD-1.8 IEEE 1394 Ease-of-Use/Manual Checklist

TD-1.9 USB Ease-of-Use/Manual Checklist

TD-1.10 CardBus Ease-of-Use/Manual Checklist

TD-1.11 Systems - Device and Port Ease-of-Use/Manual Checklist

TD-1.12 Audio Ease-of-Use/Manual Checklist

TD-1.13 Printer Ease-of-Use/Manual Checklist

TD-1.14 Monitor Ease-of-Use/Manual Checklist

TD-1.15 Still Image Device Ease-of-Use/Manual Checklist

TD-1.16 Video Capture Ease-of-Use/Manual Checklist

TD-1.17 DVD-MPEG Playback Ease-of-Use/Manual Checklist

TD-1.18 General Input Device Installation Ease-of-Use/Manual Checklist

TD-1.19 Game Devices Ease-of-Use/Manual Checklist

TD-1.20 Keyboard Ease-of-Use/Manual Checklist

TD-1.21 Keyboard/Video/Mouse Ease-of-Use/Manual Checklist

TD-1.22 Pointing Device Ease-of-Use/Manual Checklist

TD-1.23 Smart Card Ease-of-Use/Manual Checklist

TD-1.24 General Storage Device Ease-of-Use/Manual Checklist

TD-1.25 Hard Disk Drive Ease-of-Use/Manual Checklist

TD-1.26 CD/DVD Drives Ease-of-Use/Manual Checklist

TD-1.27 Tape Drive Ease-of-Use/Manual Checklist

TD-1.28 Media Changer Devices Ease-of-Use/Manual Checklist

TD-1.29 RAID Ease-of-Use/Manual Checklist

TD-1.30 UPS Ease-of-Use/Manual Checklist


TD-1.1 Driver Availability and Installation Ease-of-Use Checklist

Driver Availability Ease-of-Use/Manual Assertions
1.1.1 | System provides plus driver support for all Windows operating systems that will be preinstalled on the system.
1.1.2 | System manufacturer provides the customer with drivers for all devices for all operating systems for which the system has received the Windows Logo
Device Installation and Removal Ease-of-Use/Manual Assertions
1.2.1 | Device with USB, PCI, IEEE 1394, or PC Card external connectivity capabilities correctly supports hot plugging or unplugging per its bus class
1.2.2 | Device does not use jumpers or DIP switches for configuration during installation.
1.2.3 | Driver and any supporting software install correctly from hard disk drive, if that installation method is supported in the INF.
1.2.4 | Driver and any supporting software install correctly from compact disc, if that installation method is supported in the INF.
1.2.5 | Driver and any supporting software install correctly from network share point, if that installation method is supported in the INF.
1.2.6 | Driver and any supporting software install correctly from floppy disk, if that installation method is supported in the INF.
1.2.7 | Driver and any supporting software installation meet Windows standards
1.2.8 | Removal of vendor-supplied driver uses Windows-based methods, as defined in the Windows DDK
1.2.9 | All software components and other keys added by the INF in the registry can be removed using the Add/Remove Programs utility in the Windows Control Panel.
1.2.10 | Software installation does not replace any Microsoft-authored system components
1.2.11 | Software does not bypass any operating system components.
1.2.12 | Installation and loading of a driver does not reduce or eliminate the functionality of other devices installed on the system.
1.2.13 | If the manufacturer’s INF copies any files supplied by the operating system, those files are copied from the Windows product disk
1.2.14 | Driver must not use initialization files (INI) for configuration settings
1.2.15 | Driver supports unattended installation.
1.2.16 | Driver with special parameters includes Help file that is installed as part of the driver installation routine.
1.2.17 | Any supporting software included with the device must install using Windows-based installation methods, without any manual steps or file editing
1.2.18 | Driver and utility installation do not require a system reboot.
1.2.19 | After manual removal from Device Manager, the device is detected and reinstalled automatically at system reboot if it is physically present on the system
1.2.20 | For any application included in device installation that is not required for full functionality of the device, the user is given an option to install or not install the application.
1.2.21 | Any Advanced tab in the device's Properties Dialog Box accurately reflects features the device supports.
1.2.22 | If the device's Properties dialog box includes an Advanced tab, all INF strings displaced are spelled correctly.
1.2.23 | If the device's Properties dialog box includes an Advanced tab, the driver stops and restarts dynamically if the user changes the properties and clicks Apply.


TD-1.2 Windows Compatibility Ease-of-Use/Manual Checklist

1.3.1 | Implementation of the device technology does not adversely affect the performance or stability of all functionality provided under the preinstalled operating system and under Windows 2000/Windows XP.
1.3.2 | New technology (not defined in Windows Logo requirements) uses native operating system support whenever possible.
1.3.3 | New technology (not defined in Windows Logo requirements) follows general Plug and Play and power management guidelines as defined in the DDK
1.3.4 | All software included with a system or peripheral device must be Microsoft Win32®- or Win64®-based software.
1.3.5 | No software included with a system or peripheral device requires MS-DOS®-based decompression or installers.
1.3.6 | Drivers and utilities not use Config.sys or Autoexec.bat for configuration or to launch related software under Windows Me.


TD-1.3 Windows Supported Features Checklist

Windows Power Management Ease-of-Use/Manual Assertions
1.4.1 | x86-based client system ensures optimal user experience for suspend and hibernate
1.4.2. | If a two-button design is used, the sleep button is the user’s primary switch interface and is easily distinguished from the power button.
Manageability Ease-of-Use/Manual Assertions
1.5.1 | Hardware management instrumentation, if implemented, is provided per WHIIG
1.5.2 | Expansion devices on Windows XP Professional /Server systems can be remotely managed


TD-1.4 General Ease-of-Use Checklist

1.6.1

Connections use icons, plus keyed or shrouded connectors


TD-1.5 Legacy Removal Ease-of-Use/Manual Checklist

1.7.1 | Peripherals included with client system offer a non-legacy interface such as PCI, USB, IEEE 1394, or CardBus
1.7.2 | System, or subsystem, includes no legacy audio components, i.e., no ISA, no legacy hardware interfaces, no DB-15 analog joystick/MIDI port


TD-1.6 Upgrade Migration Ease-of-Use/Manual Checklist

1.8.1 | System components migrate correctly upon upgrade to later operating system
1.8.2 | x86-based client system is capable of recovery and upgrade of the hard drive image and BIOS independent of an FDC-based floppy disk drive


TD-1.7 Multifunction Devices Ease-of-Use/Manual Checklist

1.9.1 | Each function on a multifunction device has a separate driver
1.9.2 | No start order dependencies exist among the separate function drivers for a multifunction device
1.9.31 | Each independent function on a multifunction device can be used concurrently, without interfering with each other or with other devices on the system
1.9.4 | There are no hidden dependencies for each independent function on a multifunction device
1.9.5 | Each function on a multifunction device can be power managed independently
1.9.6 | Each function on a multifunction device successfully completes a system transition D0 to D3cold to D0
1.9.7 | Each function that supports wakeup capabilities on a multifunction device correctly supports wake from D3cold


TD-1.8 IEEE 1394 Ease-of-Use/Manual Checklist

1.10.1

IEEE 1394 device enumeration was correct for all ports on Test device or controller after install/uninstall


TD-1.9 USB Ease-of-Use/Manual Checklist

1.11.1 | USB devices and drivers support maximum flexibility of hardware interface options
1.11.2 | USB devices install and perform at least some functions expected by end users for that class of device, without preloading software


TD-1.10 CardBus Ease-of-Use/Manual Checklist

1.12.1

PC Card or CardBus device installs without user intervention and without restarting the system


TD-1.11 Systems - Device and Port Ease-of-Use/Manual Checklist

Desktop System Device and Port Ease-of-Use/Manual Assertions
1.13.1 | Desktop system includes four USB ports
1.13.2 | Desktop system with IEEE 1394 has at least two externally-accessible sockets
Mobile PC Device and Port Ease-of-Use/Manual Assertions
1.14.1 | Every device in a mobile PC system functions fully on both AC and DC power
1.14.2 | Mobile system contains at least one USB port free for end-user expansion
1.14.3 | Mobile system contains at least one 32-bit Type-2 CardBus slot
1.14.4 | Mobile system with IEEE 1394 includes at least one externally-accessible socket
Server Device and Port Ease-of-Use/Manual Assertions
1.15.1 | Server includes USB controller with at least one USB port
1.15.2 | Parallel port design present on IA-32 server system provides sufficient space for connector assembly


TD-1.12 Audio Ease-of-Use/Manual Checklist

1.16.1 | Audio on PC client system does not utilize analog mixing of audio sources for output
1.16.2 | All audio sources on PC client system are available as digital audio streams accessible to the system-wide kernel mixer.
1.16.3 | All audio content on PC client system is available at both the analog jack and USB port.
1.16.4 | SNR, measured at the output jack using line level back termination, is greater than or equal to 80 dBr, A weighted.
1.16.5 | SNR, measured at the input jack using line level back termination, is greater than or equal to 70 dBr, A weighted.


TD-1.13 Printer Ease-of-Use/Manual Checklist

1.17.1 | Network Point-and-Print capability accommodate file-number limits and other differences between operating systems that might run on the client and server
1.17.2 | Network printer supports standard port monitor
1.17.3 | Printer is available immediately following installation
1.17.4 | After device installation, registry shows correct information for ICM profile
1.17.5 | Print device provides non-legacy port connection
1.17.6 | Printer driver installs correctly when sharing the printer on the network.
1.17.7 | User is not prompted for driver location when attempting to use a printer that is shared on the network.
1.17.8 | User can print correctly after installing a printer that is shared on the network.
1.17.9 | Print capabilities that were available before a system was suspended are all available immediately after the system resumes from Standby.


TD-1.14 Monitor Ease-of-Use/Manual Checklist

1.18.1 | After device installation, registry information matches INF values for manufacturer name, Hardware ID, device description, and device capabilities
1.18.2 | After device installation, registry shows correct information for ICM profile
1.18.3 | USB functionality from either an HID or USB hub, if implemented, must be installed separately from the monitor INF
1.18.4 | USB hub, if implemented, must be self powered or externally powered, not bus-powered
1.18.5 | After device installation, DPMS is enabled
Monitor Multimedia Features Ease-of-Use/Manual Assertions
1.19.1 | If audio features are included, there is no interference with the display functionality when a media source is connected.
1.19.2 | All controls work as documented and expected when a media source is connected.
1.19.3 | If audio features are included, sound quality is clear, with no excessive static, buzzing, or popping.
Monitor Tele/Video Conferencing Features Ease-of-Use/Manual Assertions
1.20.1 | If teleconferencing features are included, there is no interference with the display functionality when a media output and input sources are connected.
1.20.2 | All controls work as documented and expected when a media source is connected.
1.20.3 | If teleconferencing features are included, sound quality is clear, with no excessive static, buzzing, or popping.
Television CRTs Ease-of-Use/Manual Assertions
1.21.1 | CRT-based monitor synchronizes to a new format in less than three seconds
1.21.2 | If television CRT features are included, there is no interference with the display functionality when a media output and input sources are connected.
1.21.31 | All controls work as documented and expected when a media source is connected.
1.21.41 | If television CRT features are included, sound quality is clear, with no excessive static, buzzing, or popping.
1.21.51 | Video devices connected via S-Video, RCA/Composite, SVGA, or other connections receive a clean and correct video signal.


TD-1.15 Still Image Device Ease-of-Use/Manual Checklist

1.22.1

Imaging device includes IEEE 1394 or USB connection


TD-1.16 Video Capture Ease-of-Use/Manual Checklist

Step/Single Frame Capture Ease-of-Use/Manual Assertions
1.23.1 | Color and satisfactory image quality are preserved
1.23.2 | Device that supports time code control accurately controls all ViSCA and Time code capable hardware
Full Motion Capture Ease-of-Use/Manual Assertions
1.24.1 | Device can capture video at all supported resolutions for all color depths over a sustained duration of 5 minutes.
Video Capture Utilities and Applications Ease-of-Use/Manual Assertions
1.25.1 | No unexpected or undesired behavior occurs when running any application provided with the device.
1.25.2 | Multi-tasking capabilities of the operating system are not hampered in any way when any application provided with the device is running.
1.25.3 | Colors are similarly matched and are of tolerable quality for any application provided with the device.
1.25.4 | Background applications do not affect the performance of any application provided with the device.


TD-1.17 DVD-MPEG Playback Ease-of-Use/Manual Checklist

DVD Installation - Ease-of-Use/Manual Assertions
1.26.1 | Vendor-supplied driver for DVD-MPEG playback hardware solution installs correctly
1.26.2 | Vendor-supplied driver for DVD-MPEG playback hardware solution works without rebooting.
1.26.3 | Vendor-supplied DVD software solution installs correctly.
DVD Playback Quality & Applications - Ease-of-Use/Manual Assertions
1.27.1 | End-user perception of playback experience is the same or better than with a stand-alone player
1.27.2 | Multiple aspect ratio content is displayed correctly, with the default being the information in the MPEG header
1.27.3 | No unexpected or undesired behavior or video degradation occurs when running any application provided with the device.
1.27.4 | General performance and functionality of the operating system are not hampered in any way when any application provided with the device is running.
1.27.5 | General performance and functionality of the operating system are not hampered in any way after any application provided with the device is closed.
1.27.6 | Colors are similarly matched and are of tolerable quality for any application provided with the device.
1.27.7 | Background applications do not affect the performance of any application provided with the device.
1.27.8 | No unexpected or undesired behavior or video degradation.
1.27.9 | All DVD player test cases pass when the vendor-provided DVD player application is running
1.27.10 | Microsoft DVD Player application runs on any system that support DVD playback.


TD-1.18 General Input Device Installation Ease-of-Use/Manual Checklist

1.28.1 | Keyboard and other input devices work correctly with the Microsoft Accessibility features in Windows.
1.28.2 | All modifier keys are capable of being read and operated by software, including Fn and similar OEM-specific keys.
1.28.3 | Miniport driver that supports Microsoft DirectInput can be dynamically loaded and unloaded
1.28.4 | Miniport driver that supports Microsoft DirectInput is immediately available without rebooting the system.
1.28.5 | If the input device uses a vendor-supplied driver, all keys and buttons are fully functional at the end-user level after the INF installation.
1.28.6 | Hot-plugging of input device does not damage system or device.
1.28.7 | All non-PS/2 input devices use USB or external bus connections rather than legacy serial or parallel
1.28.8 | All USB input devices meet USB HID specifications
1.28.9 | Installation of USB input device does not require reboot


TD-1.19 Game Devices Ease-of-Use/Manual Checklist

1.29.1 | Installation routine for analog game device launches the Joystick Control Panel applet for calibration
1.29.2 | Manual calibration for analog game device works correctly
1.29.3 | Installation routine for digital game device correctly updates calibration information in the Registry based on the device's .INF file
1.29.4 | Device performs as expected with common Windows-based multimedia applications


TD-1.20 Keyboard Ease-of-Use/Manual Checklist

1.30.1

No interference occurs between multiple keyboards.


TD-1.21 Keyboard/Video/Mouse Ease-of-Use/Manual Checklist

1.31.1 | KVM implements cascading switch boxes
1.31.2 | KVM supports on-screen display for switching between machines
1.31.3 | KVM supports ability to switch between machines using a keyboard
1.31.4 | Computer recognizes any Plug and Play keyboard, mouse, or monitor connected to the KVM
1.31.5 | Computer resets the KVM device ports in case a corruption results in an incorrect output signal sent from a connected device to the operating system
1.31.6 | All devices and cables connected to the KVM are hot pluggable and have proper icons and colors

Note: Connect the test keyboard/video/mouse switch to two or more systems, and then verify that the switch supports the items in the checklist. The systems must be listed on the current Microsoft Windows 2000 Hardware Compatibility List (HCL).


TD-1.22 Pointing Device Ease-of-Use/Manual Checklist

1.32.1 | After physically installing the device and starting Windows, an external PS/2-compatible device is immediately functional without a system reboot.
1.32.2 | On a mobile PC, the internal pointing device is disabled when an external PS/2 pointing device is installed; alternately, an option is provided in the BIOS to enable dual operation of the internal and external PS/2 pointing devices.
1.32.3 | After wheel mouse software is installed on the system, the wheel can be used for scrolling in application windows.
1.32.4 | Wheel mouse supports additional wheel mouse features as advertised in Microsoft Office 2000 products and Internet Explorer 5.0.
1.32.5 | Pointing device functions correctly in multimedia applications that require mouse support, such as Microsoft Encarta® 99 and MS-DOS-based applications.
1.32.6 | Pointing device functions correctly when switching on-the-fly from MS-DOS-based applications to Windows

Verification Tips

To verify PS/2 mouse and port enumeration

Note: This test does not apply to pointing drawing devices embedded in laptop systems

  • the wheel.


TD-1.23 Smart Card Ease-of-Use/Manual Checklist

1.33.1 | Smart card driver supports multiple instances of the same device on system without problems
1.33.2 | Smart card device on COM1 or COM2 is properly enumerated upon removal and reconnection
1.33.3 | Smart card device on COM1 or COM2 is properly enumerated upon system reboot

Verification Tips

To verify enumeration on installation for smart card device

  1. Use the system's BIOS setup program to verify that COM1 and COM2 are enabled.
  2. Connect the Test system and monitor power cables to the electrical connections.
  3. Run Windows.
  4. Connect the Test Smart Card Reader via the serial port to COM1, using the manufacturer’s supplied cable.
  5. In the Windows Control Panel, double-click the System icon, and click the Device Manager tab.
  6. Click Refresh.

The Test Smart Card Reader should be properly enumerated by the operating system during the enumeration process. If the driver is not among the operating system driver collection, a New Hardware Device dialog box will appear.

  7. If applicable, click Have Disk, insert the disk containing the driver, and then complete the driver installation.
  8. Verify that the Test Smart Card Reader appears in Device Manager and was enumerated properly.
  9. Delete the Test Smart Card Reader in Device Manager.
  10. Delete all supporting Smart Card software from the Windows StartUp directory, if applicable
    ( \%Windows%\Start Menu\Programs\StartUp).
  11. Delete all supporting Smart Card software from any subdirectories created during the device installation.
  12. Repeat steps 3-11, with the Test Smart Card Reader connected to COM2.

To verify enumeration after a disconnect for smart card device

  1. Connect the Test Smart Card Reader to COM1, using the manufacturer-supplied cable.
  2. Run Windows.

Important: Verify that no vendor-supplied Smart Card software is loaded.

  3. In the Windows Control Panel, double-click the System icon, and click Device Manager tab.
  4. Verify that the Test Smart Card Reader is listed in Device Manager and is enumerated properly.
  5. Disconnect the Test Smart Card Reader from COM1.
  6. Click Refresh.
  7. Verify that the Test Smart Card Reader is not listed in Device Manager.
  8. Reconnect the Test Smart Card Reader to COM1.
  9. Click Refresh.
  10. Verify that the Test Smart Card Reader is listed in Device Manager and is enumerated properly.
  11. Repeat steps 1-10 with the Test Smart Card Reader connected to COM2.

To verify enumeration on installation/uninstallation for smart card device

  1. Connect the Test Smart Card Reader to COM1, using the manufacturer-supplied cable.
  2. Run Windows.
  3. In the Windows Control Panel, double-click the System icon, and click Device Manager tab.
  4. Verify that the Test Smart Card Reader is listed in Device Manager, and is enumerated properly.
  5. After the Test system is up and running, close all software supporting the SCard Reader.
  6. Select the Test Smart Card Reader entry in Device Manager.
  7. Delete the Test Smart Card Reader by clicking the Remove button.
  8. Click Refresh.
  9. Verify that the Test Smart Card Reader is listed in Device Manager, and is enumerated properly.
  10. Repeat steps 1-9, with the Test Smart Card Reader connected to COM2.


TD-1.24 General Storage Device Ease-of-Use/Manual Checklist

1.34.1 | Storage device driver runs in 32-bit protected mode under Windows 98/Me after installation.
1.34.2 | Bus type is clearly indicated using ANSI approved icons on connectors for all adapters and peripherals
1.34.3 | Terminator power is supplied to the SCSI bus with overcurrent protection
1.34.4 | External connector meets SCSI-2 or later standard
1.34.5 | Controller and peripheral connections include Pin 1 cable designation; shielded device connector meets SCSI-2 or later standard
1.34.6 | External devices use automatic termination or an accessible on-board termination switch
1.34.7 | Option ROM supports virtual DMA services
1.34.8 | Controller and peripherals implement SCSI bus data protection signal
1.34.9 | Hardware supports the SCSI-3 STOP/START UNIT command to decrease power consumption
1.34.10 | SCSI controller provides multi-initiator support if the controller provides external device connection capability for use as a cluster node
1.34.11 | For ATA controller, DVD drive attached and functionality tested (movie playback
1.34.12 | ATA controller meets Windows installation requirements - Windows 98/Me > Windows 2000/Windows XP Upgrade Test (FAT16 > FAT32 upgrade; FAT32 > NTFS conversion
1.34.13 | For ATA controller, adapter is capable of sharing IRQ and works behind a PCI-PCI bridge


TD-1.25 Hard Disk Drive Ease-of-Use/Manual Checklist

1.35.1

Hot-swappable drive offered for server systems includes a local disk drive replacement indicator

See TD-28.3 Hard Disk Drive Manual Test Checklist Test Description


TD-1.26 CD/DVD Drives Ease-of-Use/Manual Checklist

1.36.1 | CD device provides 8x minimum transfer rate or better performance
1.36.2 | DVD storage device Provides 2 MB per second minimum transfer rate or better performance anywhere on the disc
1.36.3 | DVD drive supports logical and physical CD formats
1.36.4 | DVD drive supports MMC-2
1.36.5 | Read/Write (the FAQ referenced specifies that this applies only to R/W DVD drives). DVD drive supports defect management


TD-1.27 Tape Drive Ease-of-Use/Manual Checklist

1.37.1 | ATAPI tape device supports the termination scheme defined in ATA/ATAPI-5
1.37.2 | Driver for tape device is integrated with Removable Storage Manager
1.37.3 | Single-backup tape device designed for Windows Server meets 10 GB minimum capacity requirements
1.37.4 | Single-backup tape device designed for Windows Advanced Server meets 20 GB minimum capacity requirements


TD-1.28 Media Changer Devices Ease-of-Use/Manual Checklist

1.38.1 | CD changer device that supports 7 discs or less complies with MMC-2
1.38.2 | SCSI tape changer and driver support auto-configuration
1.38.3 | SCSI tape and optical disk changer support auto-configuration


TD-1.29 RAID Ease-of-Use/Manual Checklist

1.39.1 | All external SCSI connectors for RAID are labeled with ANSI approved icon for bus type
1.39.2 | RAID support includes notification of failed drive
1.39.3 | RAID subsystem supports automatic replacement of failed drive
1.39.4 | RAID subsystem supports manual replacement of failed drive


TD-1.30 UPS Ease-of-Use/Manual Checklist

UPS Ease-of-Use/Manual Assertions
1.40.1 | Device can take over and properly notify the user that the device is on battery, or shut down applications and the system, or both
1.40.2 | UPS device load is measured accurately
1.40.3 | UPS device battery modules on larger units are hot swappable
1.40.4 | UPS device can notify the user that the power is down via email, pager, or both
1.40.5 | UPS device built-in functionality can properly support the device
UPS Device PnP Ease-of-Use/Manual Assertions
1.41.1 | UPS device on COM1 or COM2 is properly enumerated upon removal and reconnection
1.41.2 | UPS device on COM1 or COM2 is properly enumerated upon system reboot

To verify UPS device removal and reconnection enumeration

  1. Connect the UPS to COM1, using the manufacturer-supplied cable.
  2. Boot to the operating system.

Note: Verify that no customer-supplied UPS software is loaded.

  3. Click the Windows Start button, and choose Settings > Control Panel.
  4. Double-click the System icon, and click Device Manager tab.
  5. Verify that the UPS is listed in Device Manager, and is enumerated properly.
  6. Disconnect the UPS from COM1.
  7. Click the Refresh button.
  8. Run the Serial PnP Test for Serial Connected Devices test from the Test Manager. The enumeration for the Test device is displayed in the lower half of the window.
  9. Verify that the UPS is NOT listed in Device Manager.
  10. Reconnect the UPS to COM1.
  11. Click the Refresh button.
  12. Verify that the UPS is listed in Device Manager, and is enumerated properly.
  13. Repeat the same steps with the UPS connected to COM2.

To verify UPS device enumeration upon system reboot

  1. Delete the UPS from Device Manager.
  2. Connect the UPS to COM1, using the manufacturer-supplied cable.
  3. Reboot the Test system.
  4. The UPS should be properly enumerated by the operating system during the reboot process.
  5. Run the Serial PnP Test for Serial Connected Devices test from the Test Manager. The enumeration for the Test device is displayed in the lower half of the window.
  6. Select the Driver from the disk provided by the hardware manufacturer.
  7. Install the driver/application provided by the manufacturer, using the manufacturer-supplied
    .INF file.
  8. Verify that the UPS is listed in Device Manager on COM1 and was enumerated properly.
  9. Repeat the same steps with the UPS connected to COM2.


Chapter 2: Extensible Firmware Interface Test Specification

The Extensible Firmware Interface (EFI) is an interface between the operating system and the platform interface. This document describes the tests designed and implemented to verify the consistency and functionality of the different services documented in the EFI Specification.

Test Coverage

Table of Tests

Assertions Covered | Test Name | Test Description
2.1.1, 2.1.2, 2.1.5, 2.2.3, 2.2.4, 2.2.9 2.2.11, 2.2.14 | TD-2.1.3 Wait Periodic Timer Events Test (WaitPeriodicTimerEvents) | Verifies that asynchronous events (of type EVT_TIMER) with periodic timers set upon them are fired correctly when waited upon using WaitForEvent.
2.1.1, 2.1.2, 2.1.5, 2.2.7, 2.2.9, 2.2.10, 2.2.13, 2.2.14 | TD-2.1.5 Signal Relative Timer Events Test (SignalRelativeTimerEvents) | Verifies that events of type EVT_TIMER are signaled and a corresponding notify-function is executed whenever a timer that is set upon the events is triggered.
2.1.1, 2.1.2, 2.1.5, 2.2.7, 2.2.9, 2.2.11, 2.2.13, 2.2.14 | TD-2.1.6 Signal Periodic Timer Events Test (SignalPeriodicTimerEvents) | Verifies that events of type EVT_TIMER are signaled and a corresponding notify-function is executed whenever a corresponding periodic timer set upon the events is triggered.
2.1.1, 2.1.2, 2.1.5, 2.2.3, 2.2.4, 2.2.6, 2.2.9, 2.2.10 | TD-2.1.2 Wait Relative Timer Events Test (WaitRelativeTimerEvents) | Verifies that asynchronous events of type (EVT_TIMER) with timers set upon them are fired correctly when waited upon using WaitForEvent.
2.1.1, 2.1.2, 2.1.5, 2.2.7, 2.2.15 | TD-2.1.4 Signal Events Test (SignalEvents) | Verifies that events of type EVT_NOTIFY_SIGNAL can be created and that their respective notify functions are queued for execution when the events are signaled.
2.1.1, 2.1.2, 2.1.5, 2.2.3, 2.2.4, 2.2.6 | TD-2.1.1 Wait Events Test (WaitEvents) | Verifies that events of type EVT_NOTIFY_WAIT can be created and that their respective notify functions are queued for execution when the events are being waited upon. Also verifies that the NoitfyContext parameter is passed correctly to the notify functions.
2.3.1-2.3.5, 2.5.2-2.5.4 | TD-2.2.1 Memory Allocate Pool Types Test (MemoryAllocatePoolTypes) | Verifies that all and only the permissible allocation types succeed when using AllocatePool service.
2.3.1- 2.3.5, 2.5.1, 2.5.4 | TD-2.2.2 Memory Allocate Free Pool Test (MemoryAllocateFreePool) | Verifies that repeated memory allocations and freeing of variable allocations sizes are successful.
2.3.1-2.3.5, 2.5.1, 2.5.5, 2.5.12 | TD-2.2.4 Memory Allocate Free Pages Test (MemoryAllocateFreePages) | Verifies that repeated memory allocations and freeing of variable allocation sizes using AllocPages successful.
2.3.1-2.3.5, 2.5.1, 2.5.12, 2.5.13, 2.5.17 | TD-2.2.8 Memory Frequent Allocations Test (MemoryFrequentAllocations) | Attempts to maximize the total number of allocations and the total amount of memory allocated using AllocPages.
2.3.1-2.5.5, 2.5.7, 2.5.12, 2.5.13, 2.5.16 | TD-2.2.6 Memory Allocate Free Pages at Address Test (MemoryAllocateFreePagesAtAddress) | Verifies that repeated memory allocations and freeing of variable allocation sizes and at specified address bases using AllocPages are successful.
2.3.1-2.5.5, 2.5.7, 2.5.12, 2.5.13, 2.5.16 | TD-2.2.5 Memory Allocate Free Pages Below 8MB Test (MemoryAllocateFreePagesBelow8MB) | Verifies that repeated memory allocations and freeing of variable allocation sizes and below 8MB address range using AllocPages are successful.
2.3.1-2.5.5, 2.5.7, 2.5.10, 2.5.12, 2.5.13, 2.5.15, 2.5.18, 2.5.26, 2.5.27 | TD-2.2.7 Memory Allocate All Test (MemoryAllocateAll) | Verifies that all available free pages can be allocated successfully in a single AllocPages request.
2.3.1-2.5.5, 2.5.8-2.5.10, 2.5.12 | TD-2.2.3 Memory Allocate Page Types Test (MemoryAllocatePageTypes) | Verifies that all valid allocation types, when allocated using AllocPages are successfully allocated.
2.6.1 – 2.6.27 | TD-2.3.1 Protocols Consistency Test (Protocols Consistency) | The Protocols Consistency test performs consistency checks on the following EFI protocol services: InstallProtocolInterface, UnInstallProtocolInterface, ReinstallProtocolInterface, LocateHandle, HandleProtocol, LocateDevicePath.
2.6.4 | TD-2.3.7 Required Protocols Present Test (RequiredProtocolsPresent) | Checks if all the required protocols as per section 2.5.1 of the EFI Specification are present.
2.7.1, 2.7.2, 2.7.4-2.7.9 | TD-2.3.2 Protocol Services Test (ProtocolServices) | Verfies consistency of protocol services, section 3.3 of the EFI Spec; functionality of the protocol services, and functionality of the image service Unload.
2.7.4, 2.7.6, 2.7.7, 2.8.1, 2.8.2 | TD-2.3.5 Protocol Install Notify Test (ProtocolInstallNotify) | Generates stress on the event notification services through repeated protocol installations and deinstallations
2.7.4, 2.7.7, 2.8.1, 2.8.2, 2.8.4, 2.8.5, 2.8.7- 2.8.9 | TD-2.3.3 Register Protocol Notify Test (RegisterProtocolNotify) | Creates an event that registers for a protocol installation and waits to be notified. Installs the protocol. Reinstall over the same protocol handle to verify that correct number of notifications have occurred.
2.10.1- 2.10.3 | TD-2.4.1 LoadImage Test (LoadImage) | Verification of LoadImage() function
2.10.1, 2.10.8 | TD-2.4.2 ImageStart Test (ImageStart) | Verification of the StartImage() function.
2.10.4, 2.10.6 | TD-2.4.3 MultipleLoadStart Test (MultipleLoadStart) | Verification of the StartImage() function and LoadImage() function when multiple images are loaded.
2.10.7, 2.10.8 | TD-2.4.4 LoadMemoryImage Test (LoadMemoryImage) | Verification of LoadImage() and StartImage() function by loading an Image from memory SourceBuffer.
2.11.1, 2.11.2 | TD-2.5.1 NV_Variables Test (NV_Variables) | Check for consistency of SetVariable() and GetVariable() for the NV+BS+RT attributes.
2.11.18, 2.11.19 | TD-2.8.2 MonotonicCountCheck Test (MonotonicCountCheck) | Verification of GetNextMonotonicCount() function.
2.11.20 – 2.11.38, 2.12.6 – 2.12.15, 2.13.1 – 2.13.4, 2.14.5 – 2.14.9 | TD-2.4.5 Runtime Services Test (Runtime Services) | Creates some variables, using SetVariable(), with known attributes (size, value, etc.), and then verifies that GetVariable() returns the correct information.
2.11.4-2.11.9 | TD-2.5.2 MandatoryVSVariables Test (MandatoryVSVariables) | Check for consistency of SetVariable(), GetVariable() and GetNextVariableName(). The mandatory variables that should be present in the variable store are also checked.
2.11.10-2.11.17 | TD-2.4.5 Runtime Services Test (BootRunVariableStore) | Verification of SetVariable(), GetVariable() and the GetNextVariableName() function.
2.12.1-2.12.5 | TD-2.6 Time Services Test (TimeCheck) | This test is designed to test the various time functions provided in the EFI library.
2.14.1 | TD-2.8.1 SystemReset Test (SystemReset) | ResetSystem() functions call is checked.
2.14.4 | TD-2.8.3 WatchDogTimer Test (WatchDogTimer) | The test checks for the SetWatchDogTimer() functionality.
2.16.1-2.16.5 | TD-2.10 Device Path Protocol Test (DevPath) | Enumerates all devices in the system. Accesses all installed instances of the Device Path protocol and checks for correct length, types and subtypes for each of them.
2.17.1 – 2.17.24 | TD-2.11.1 Device I/O Test (Device I/O) | Verifies that the EFI_DEVICE_IO_INTERFACE structure itself is a valid pointer to either EfiBootServicesData or EfiRuntimeData.
2.18.1 – 2.18.4 | TD-2.11.3 Console I/O Protocol Test (Console I/O) | Verifies that the Console IO protocol is implemeted and present. It also verifies that all the services required to be implemented by the ConsoleIO protocol are present in the system.
2.19.1, 2.19.2 | TD-2.13 Disk I/O Protocol Test (Disk I/O) | Verifies disk I/O reads (EFI_DISK_READ) are performed on every accessible byte and disk I/O writes (EFI_DISK_WRITE) are perfomed on every accessible block.
2.19.1 – 2.19.6 | TD-2.12 Block I/O Protocol Test (Block I/O Test) | Isolates the EFI handle to the protocol representing the target test device. The test application examines and validates the members of the returned EFI_BLOCK_IO_MEDIA structure. It is assumed that the information provided by the OS is accurate.
2.21.6 – 2.21.20 | TD-2.14 File System Protocol Test (SimpleFileTest) | Tests all of the interfaces that implement the Simple File System Protocol, including File Io, Volume Open and File Handle.
2.22.1 – 2.22.4 | TD-2.15 Load File Protocol Test (ImageFile) | Verifies the functionality and consistency of the LoadFile protocol when an instance of the LoadFile protocol is installed over the PXE protocol.
2.23.1-2.23.5, 2.23.8- 2.23.11 | TD-2.16 Serial I/O Protocol Test (SerialTest) | Loads a serial loopback driver that controls an imaginary serial port and uses it to verify that all of the serial I/O methods work.
2.24.1-2.24.15 | TD-2.17 Unicode Collation Protocol Test (UnicodeT) | Accesses a handle to the Unicode Protocol and does various string operations to check each operation for correctness.
2.25.1 – 2.25.10 | TD-2.18 PXE Base Code Protocol Test (PXE Protocol) | The PXE Protocol test tries to locate a device that supports the Base Code Protocol on the system.
2.27.1-2.27.9 | TD-2.21 Boot Manager Variables Test BootOrderTest) | Verifies the functionality of the mandatory EFI NVRAM variable BootOrder by creating some arbitrary Boot#### options and resetting the platform to see that the applications are started, run in the required sequence and receive their load options correctly.


EFI Test Assertions

The following is a list of EFI assertions derived from the Extensible Firmware Interface Specification. The EFI tests verify compliance with these assertions.

Detailed cross-references replaced "See Table of Tests" throughout this section.


Reference Document Sources for EFI Assertions

Functional requirements are defined in the following documents:

Advanced Configuration and Power Interface Specification, Revision 1.0, 1.0(a) and 1.0b, and 2.0

http://www.acpi.info/index.html

Errata for ACPI, Revision 1.0 and 1.0a, have been incorporated into Revision 1.0b

Extensible Firmware Interface Specification (EFI)

http://developer.intel.com/technology/efi/download.htm

Hardware Design Guide Version 3.0 for Microsoft Windows 2000 Server, Intel Corporation and Microsoft Corporation

http://www.microsoft.com//hwdev/platform/pcdesign/desguide/serverdg.asp

Microsoft Extensible Firmware Interface FAT32 File System Specification,
Microsoft Extensible Firmware Interface Long File Name Specification,
Microsoft Portable Executable and Common Object File Format Specification,
plus other EFI-related specifications and guidelines

http://www.microsoft.com//hwdev/platform/firmware/EFI/default.asp

Microsoft Windows Logo Program System and Device Requirements, Version 2.0

http://www.microsoft.com/hwdev/winlogo/
(listed as "WLP#" in these assertions)

Note: EFI-related requirements for the Windows Logo Program for hardware are defined in WLP#A5.0, with detailed implementation guidelines defined in Hardware Design Guide Version 3.0 for Microsoft Windows 2000 Server


Event, Timer and Task Priority Services Assertions

Assertions in this section include:


Consistency of Event Services Assertions

Tests for these assertions are described in TD-2.1 Event, Timer and Task Priority Services Tests and TD-2.2 Memory Allocation Services Tests.

2.1.1 The EFI boot services structure must contain a non-null function pointer corresponding to all the EFI event creation and management services: CreateEvent, CloseEvent, SignalEvent, WaitForEvent, SetTimer, RaiseTPL and RestoreTPL.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Sections 3.1, and 3.1.1 – 3.1.7.
Test description: TD-2.1.3 Wait Periodic Timer Events Test; TD-2.1.5 Signal Relative Timer Events Test; TD-2.1.6 Signal Periodic Timer Events Test; TD-2.1.2 Wait Relative Timer Events Test; TD-2.1.4 Signal Events Test; TD-2.1.1 Wait Events Test

2.1.2 The event creation service CreatEvent succeeds for each of the following event types, and their permissible combinations, viz. (EVT_TIMER, EVT_RUNTIME, EVT_RUNTIME_CONTEXT) | (EVT_NOTIFY_WAIT, EVT_NOTIFY_SIGNAL, EVT_NOTIFY_PCODE_INTERFACE), EVT_SIGNAL_EXIT_BOOT_SERVICES, EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.1.1
Test description: TD-2.1.3 Wait Periodic Timer Events Test; TD-2.1.5 Signal Relative Timer Events Test; TD-2.1.6 Signal Periodic Timer Events Test; TD-2.1.2 Wait Relative Timer Events Test; TD-2.1.4 Signal Events Test; TD-2.1.1 Wait Events Test

2.1.3 CreatEvent fails and returns EFI_INVALID_PARAMETER for invalid combinations of event types viz. (EVT_NOTIFY_WAIT | EVT_NOTIFY_SIGNAL), (EVT_SIGNAL_EXIT_BOOT_SERVICES | *), (EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE | *).

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.1.1
Test description: TD-2.1 Event, Timer and Task Priority Services Tests and TD-2.2 Memory Allocation Services Tests.

2.1.4 Invalid (that is either non existent or NULL) event arguments to the following services would fail the services and result in an EFI_INVALID_PARAMETER return value: CloseEvent, SignalEvent, WaitForEvent, and SetTimer.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Sections 3.1.2 – 3.1.5.
Test description: TD-2.1 Event, Timer and Task Priority Services Tests and TD-2.2 Memory Allocation Services Tests.

2.1.5 Events successfully created using CreateEvent can be closed successfully with CloseEvent, that is with a return value of EFI_SUCCESS.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Sections 3.1.1 and 3.1.2.
Test description: TD-2.1.3 Wait Periodic Timer Events Test; TD-2.1.5 Signal Relative Timer Events Test; TD-2.1.6 Signal Periodic Timer Events Test; TD-2.1.2 Wait Relative Timer Events Test; TD-2.1.4 Signal Events Test; TD-2.1.1 Wait Events Test

2.1.6 Closed events may not be operated upon, that is, calls to the following services accept event arguments: CloseEvent, SignalEvent, WaitForEvent, SetTimer must fail immediately by returning EFI_INVALID_PARAMETER.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Sections 3.1.1 - 3.1.5.
Test description: TD-2.1 Event, Timer and Task Priority Services Tests and TD-2.2 Memory Allocation Services Tests.


Functionality of Event Services Assertions

2.2.1 For every event of type EVT_NOTIFY_WAIT, the event is signaled and its notify function is queued for execution when the event is waited upon (using WaitForEvent).

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.1.1.
Test description: TD-2.1 Event, Timer and Task Priority Services Tests and TD-2.2 Memory Allocation Services Tests.

2.2.2 A task is interrupted by an event notification only if the TPL at which the task is running is less than the TPL of the event, set when it is created.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.1.
Test description: TD-2.1 Event, Timer and Task Priority Services Tests and TD-2.2 Memory Allocation Services Tests.

2.2.3 For every event of type EVT_NOTIFY_WAIT that is being waited upon using WaitForEvent, the index of the event should be returned after the event is signaled.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Sections 3.1.1 and 3.1.4.
Test description: TD-2.1.3 Wait Periodic Timer Events Test; TD-2.1.2 Wait Relative Timer Events Test; TD-2.1.1 Wait Events Test

2.2.4 When multiple events of type EVT_NOTIFY_WAIT are being waited upon using WaitForEvent, the smallest index among the indices of the signaled events is returned.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.1.4.
Test description: TD-2.1.3 Wait Periodic Timer Events Test; TD-2.1.2 Wait Relative Timer Events Test; TD-2.1.1 Wait Events Test

2.2.5 SignalEvent results in one of the notify function being invoked for either EVT_NOTIFY_WAIT or EVT_NOTIFY_SIGNAL.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification,
Test description: TD-2.1 Event, Timer and Task Priority Services Tests and TD-2.2 Memory Allocation Services Tests.

2.2.6 For a task that is running at a TPL lower than the TPL of the event and is waiting upon the event, WaitForEvent having created the event with type EVT_NOTIFY_WAIT returns the ‘identity’ of the event.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.1.2 Wait Relative Timer Events Test; TD-2.1.1 Wait Events Test

2.2.7 For a task that has registered a notify function having created the event with type EVT_NOTIFY_SIGNAL and is running at a TPL lower than the TPL of the event, the notify function is invoked.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.1.5 Signal Relative Timer Events Test; TD-2.1.6 Signal Periodic Timer Events Test; TD-2.1.4 Signal Events Test

2.2.8 No result occurs when the task is running at a TPL equal to or greater than the TPL of the event.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Sections 3.1.1 and 3.1.3 – 3.1.4.
Test description: TD-2.1 Event, Timer and Task Priority Services Tests and TD-2.2 Memory Allocation Services Tests.

2.2.9 When an event is created with EVT_TIMER type and associated with a trigger time using SetTimer service, the event is signaled according to the specified timer delay type.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.1.3 Wait Periodic Timer Events Test; TD-2.1.5 Signal Relative Timer Events Test; TD-2.1.6 Signal Periodic Timer Events Test; TD-2.1.2 Wait Relative Timer Events Test

2.2.10 When the trigger time is typed TimerRelative, the event signaled exactly once after the timer expires.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.1.5 Signal Relative Timer Events Test; TD-2.1.2 Wait Relative Timer Events Test

2.2.11 When the trigger time is typed TimerPeriodic, the event signaled exact period until the trigger is cancelled by specifying TimerCancel.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.1.3 Wait Periodic Timer Events Test; TD-2.1.6 Signal Periodic Timer Events Test

2.2.12 The event is signaled no more after the timer is cancelled by specifying TimerCancel.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Sections 3.1.1 and 3.1.5.
Test description: TD-2.1 Event, Timer and Task Priority Services Tests and TD-2.2 Memory Allocation Services Tests.

2.2.13 SetTimer succeeds for events of time EVT_TIMER.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.1.5 Signal Relative Timer Events Test; TD-2.1.6 Signal Periodic Timer Events Test

2.2.14 SetTimer cancels the timer set upon events of type EVT_TIMER.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.1.3 Wait Periodic Timer Events Test; TD-2.1.5 Signal Relative Timer Events Test; TD-2.1.6 Signal Periodic Timer Events Test

2.2.15 Events can be signaled using SignalEvent.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.1.4 Signal Events Test


Memory Allocation Services Assertions

Assertions in this section include:


Availability of Memory Services Assertions

Tests for assertions in this section are defined in TD-2.2 Memory Allocation Services Tests.

2.3.1 The EFI boot services structure must contain a non-null function pointer corresponding to all the EFI memory allocation service AllocatePages.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3, page 23 and Sections 3.2 and 3.2.1.
Test description: TD-2.2 Memory Allocation Services Tests.

2.3.2 The EFI boot services structure must contain a non-null function pointer corresponding to all the EFI memory allocation service FreePages.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3, page 23 and Sections 3.2 and 3.2.2.
Test description: TD-2.2 Memory Allocation Services Tests.

2.3.3 The EFI boot services structure must contain a non-null function pointer corresponding to all the EFI memory allocation service GetMemoryMap.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3, page 23 and Sections 3.2 and 3.2.3.
Test description: TD-2.2 Memory Allocation Services Tests.

2.3.4 The EFI boot services structure must contain a non-null function pointer corresponding to all the EFI memory allocation service AllocatePool.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3, page 23 and Sections 3.2 and 3.2.4.
Test description: TD-2.2 Memory Allocation Services Tests.

2.3.5 The EFI boot services structure must contain a non-null function pointer corresponding to all the EFI memory allocation service FreePool.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Sections 3, page 23 and Sections 3.2 and 3.2.5.
Test description: TD-2.2 Memory Allocation Services Tests.


Correctness and Consistency of the EFI Memory Map Assertions

Tests for assertions in this section are defined in TD-2.2 Memory Allocation Services Tests.

2.4.1 Each entry of the memory map table returned by the GetMemoryMap service must have a valid memory type attribute. This attribute should not be of the following types: EfiReservedMemoryType, EfiACPIMemoryNVS, EFIFirmwareReserved.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.2, Table 3-2.
Test description: TD-2.2 Memory Allocation Services Tests.

2.4.2 The VirtualStart field of each memory map entry must be zero when EFI boot services are active, that is, before ExitBootServices is called.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Sections 3.
Test description: TD-2.2 Memory Allocation Services Tests.

2.4.3 The memory attribute of each memory entry must have valid ‘syntactic’ form, that is, it must be of the form [(Valid Caching Type) | (Valid memory protection type) | (Requires run time mapping)].

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.2.3.
Test description: TD-2.2 Memory Allocation Services Tests.

2.4.4 The cacheability part of the memory attribute of each memory descriptor entry is valid, that is, it must be one of the following values {0x01, 0x02, 0x04, 0x08}.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.2.3.
Test description: TD-2.2 Memory Allocation Services Tests.

2.4.5 The cacheability attributes of each memory descriptor must be consistent, that is usage(s) of multiple attributes among (EFI_MEMORY_UC, EFI_MEMORY_WC, EFI_MEMORY_WT, EFI_MEMORY_WB) should not conflict with one another.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.2.3.
Test description: TD-2.2 Memory Allocation Services Tests.

2.4.6 Every pair of memory descriptor entries found in the memory map table returned by GetMemoryMap should correspond to mutually non-overlapping regions of memory.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.2.3.
Test description: TD-2.2 Memory Allocation Services Tests.


Memory Allocations Assertions

Tests for assertions in this section are defined in TD-2.2 Memory Allocation Services Tests.

2.5.1 The memory map found before and after invoking either of the memory services AllocatePool must be consistent.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.2.3.
Test description: TD-2.2 Memory Allocation Services Tests.

2.5.2 Invocation of AllocatePool for a one-page allocation should return EFI_SUCCESS for valid pool types, viz. (EfiLoaderData, EfiBootServicesData, RuntimeServiceData).

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.2.4.
Test description: TD-2.2 Memory Allocation Services Tests.

2.5.3 Invocation of AllocatePool for a one-page allocation should return EFI_INVALID_PARAMETER for invalid pool types, that is all pool types other than:EfiLoaderData, EfiBootServicesData, and RuntimeServiceData.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.2.4.
Test description: TD-2.2 Memory Allocation Services Tests.

2.5.4 Pages previously allocated using AllocatePool can be freed successfully by invoking FreePool on the allocation, that is, a call to FreePool should return EFI)_SUCCESS.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.2.5.
Test description: TD-2.2 Memory Allocation Services Tests.

2.5.5 The memory map found before and after invoking either of the memory services AllocatePages must be consistent.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.2.3.
Test description: TD-2.2 Memory Allocation Services Tests.

2.5.6 For each of the valid pool types viz., (EfiLoaderData, EfiBootServicesData, RuntimeServiceData), whenever a request size is less than the available free page pool, an allocation request using AllocatePool must succeed with a return value of EFI_SUCCESS.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.2.4.
Test description: TD-2.2 Memory Allocation Services Tests.

2.5.7 The memory map found before and after invoking either of the memory services AllocatePages must be consistent.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.2.3.
Test description: TD-2.2 Memory Allocation Services Tests.

2.5.8 Invocation of AllocatePages for a one-page allocation should return EFI_SUCCESS for valid memory types viz., (EfiLoaderData, EfiuntimeServicesCode, EfiRuntimeServicesData, EfiBootServicesData, EfiBootServicesData, EfiLoaderData).

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.2.1.
Test description: TD-2.2 Memory Allocation Services Tests.

2.5.9 Invocation of AllocatePages for a one-page allocation should return EFI_INVALID_PARAMETER for invalid memory types viz., all memory types other than (EfiLoaderData, EfiuntimeServicesCode, EfiRuntimeServicesData, EfiBootServicesData, EfiBootServicesData, EfiLoaderData).

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.2.4.
Test description: TD-2.2 Memory Allocation Services Tests.

2.5.10 For each of the valid memory types viz., (EfiLoaderData, EfiuntimeServicesCode, EfiRuntimeServicesData, EfiBootServicesData, EfiBootServicesData, EfiLoaderData), whenever a request size is less than the available free page pool, an allocation request using AllocatePages must succeed with a return value of EFI_SUCCESS.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.2.1.
Test description: TD-2.2 Memory Allocation Services Tests.

2.5.11 For each of the valid memory types viz., (EfiLoaderData, EfiuntimeServicesCode, EfiRuntimeServicesData, EfiBootServicesData, EfiBootServicesData, EfiLoaderData), whenever a request size is more than the available free page pool, an allocation request using AllocatePages must fail with a return value of EFI_OUT_OF_RESOURCES.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Sections 3.2.1.
Test description: TD-2.2 Memory Allocation Services Tests

2.5.12 Pages previously allocated using AllocatePages can be freed successfully by invoking FreePages on the allocation. That is, a call to FreePages should return EFI_SUCCESS.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.2.2.
Test description: TD-2.2 Memory Allocation Services Tests

2.5.13 Whenever a memory descriptor entry from the memory map refers free pages (that is memory type = EfiConventionalMemory), then AllocPages succeeds with a return value of EFI_SUCCESS whenever an allocation request at address within that page range fits within the range specified by the memory descriptor entry.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.2.1.
Test description: TD-2.2 Memory Allocation Services Tests

2.5.14 Whenever a memory descriptor entry from the memory map refers free pages, that is memory type = EfiConventionalMemory, then AllocPages fails with a return value of EFI_OUT_OF_RESOURCES whenever an allocation request at address within that page range does not fit within the range of pages specified by the memory descriptor entry. This applies to oversized requests and requests that cross the bounds of the range described by the memory descriptor entry.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.2.1.
Test description: TD-2.2 Memory Allocation Services Tests

2.5.15 When the allocation request size equal to the size of largest free memory block found in the memory map, AllocatePages should succeed and return an EFI_SUCCESS value.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.2.1.
Test description: TD-2.2 Memory Allocation Services Tests

2.5.16 The success or failure of an AllocPages request depends only on the availability of free memory and does not depend on the total number of allocations made by an application.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.2.1.
Test description: TD-2.2 Memory Allocation Services Tests

2.5.17 The success or failure of a FreePages request does not depend on the total number of allocations made by an application.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.2.1.
Test description: TD-2.2 Memory Allocation Services Tests

2.5.18 AllocPages should return EFI_OUT_OF_RESOURCES when all the available memory is allocated.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.2.1.
Test description: TD-2.2 Memory Allocation Services Tests

2.5.19 The success or failure of an AllocPages request does not depend on the actual sequence of allocations tried out, but only upon the available free pages.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Sections 3.2.1.
Test description: TD-2.2 Memory Allocation Services Tests

2.5.20 Allocating below minimum memory address using AllocPages should return EFI_OUT_OF_RESOURCES.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Sections 3.2.1.
Test description: TD-2.2 Memory Allocation Services Tests

2.5.21 Allocating above maximum memory address using AllocPages should return EFI_OUT_OF_RESOURCES.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.2.1.
Test description: TD-2.2 Memory Allocation Services Tests

2.5.22 Trying to allocate more than the available number of pages using AllocPages should result in EFI_OUT_OF_RESOURCES.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.2.1.
Test description: TD-2.2 Memory Allocation Services Tests

2.5.23 Trying to allocate zero pages using AllocPages should result in a failure.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.2.1.
Test description: TD-2.2 Memory Allocation Services Tests

2.5.24 Trying to allocate at boundaries between the regions should succeed whenever the allocation request does not include the boundaries.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.2.1.
Test description: TD-2.2 Memory Allocation Services Tests

2.5.25 For valid parameter combination and valid buffersize, GetMemoryMap succeeds and returns the EFI memory descriptor table.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.2.1.
Test description: TD-2.2 Memory Allocation Services Tests

2.5.26 When free memory is available AllocatePages succeeds for requests that are specified with AllocateAtAddress.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.2.1.
Test description: TD-2.2 Memory Allocation Services Tests

2.5.27 FreePages must release all successful memory allocation requests, irrespective of their preferred allocation ranges viz., AllocateAtAddress, AllocateAnyAddress and AllocateMaxAddress.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.2.1.
Test description: TD-2.2 Memory Allocation Services Tests


Protocol Handler Services Assertions

Assertions in this section include:

Protocol Services Consistency Assertions
Protocol Services: Functionality Assertions
Protocol Services: Installation and Notifications Assertions
Protocol Services: Mandatory Protocols Assertions


Protocol Services Consistency Assertions

The assertions in this section are tested in TD-2.3.1 Protocols Consistency Test.

2.6.1 InstallProtocolInterface should not succeed with a NULL GUID: FAILED.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3.1 Protocols Consistency Test

2.6.2 InstallProtocolInterface should not succeed with a NULL protocol interface: FAILED.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3.1 Protocols Consistency Test

2.6.3 InstallProtocolInterface should not succeed with an invalid interface type: FAILED.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3.1 Protocols Consistency Test

2.6.4 InstallProtocolInterface should not succeed upon a spurious handle.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3.1 Protocols Consistency Test

2.6.5 InstallProtocolInterface should succeed with all valid parameters.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3.1 Protocols Consistency Test

2.6.6 LocateHandle should not succeed with a NULL GUID.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3.1 Protocols Consistency Test

2.6.7 LocateHandle should return EFI_NOT_FOUND for a GUID that was never installed.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3.1 Protocols Consistency Test

2.6.8 LocateHandle should return EFI_NOT_FOUND for an invalid search type.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3.1 Protocols Consistency Test

2.6.9 LocateHandle should succeed with all valid and related arguments.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3.1 Protocols Consistency Test

2.6.10 HandleProtocol should return EFI_UNSUPPORTED with a valid but unrelated device handle.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3.1 Protocols Consistency Test

2.6.11 HandleProtocol should not succeed when queried with a NULL GUID.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3.1 Protocols Consistency Test

2.6.12 HandleProtocol should not succeed when queried with protocol (GUID) not installed on the handle.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3.1 Protocols Consistency Test

2.6.13 HandleProtocol should succeed when queried with all valid parameters.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3.1 Protocols Consistency Test

2.6.14 UninstallProtocolInterface should succeed with all valid and related parameters.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3.1 Protocols Consistency Test

2.6.15 ReinstallProtocolInterface should not succeed with a NULL GUID.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3.1 Protocols Consistency Test

2.6.16 ReinstallProtocolInterface should not succeed with a spurious GUID.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3.1 Protocols Consistency Test

2.6.17 ReinstallProtocolInterface should not succeed with spurious old protocol interface.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3.1 Protocols Consistency Test

2.6.18 ReinstallProtocolInterface should not succeed with a NULL new protocol.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3.1 Protocols Consistency Test

2.6.19 LocateHandle must succeed for an installed protocol.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3.1 Protocols Consistency Test

2.6.20 HandleProtocol should succeed with all valid and related arguments.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3.1 Protocols Consistency Test

2.6.21 ReinstallProtocolInterface should succeed with all valid parameters.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3.1 Protocols Consistency Test

2.6.22 ReinstallProtocolInterface should succeed with all valid parameters.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3.1 Protocols Consistency Test

2.6.23 UninstallProtocolInterface should not succeed with a NULL GUID.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3.1 Protocols Consistency Test

2.6.24 UninstallProtocolInterface should not succeed with a spurious GUID.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3.1 Protocols Consistency Test

2.6.25 UninstallProtocolInterface should not succeed with a NULL interface.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3.1 Protocols Consistency Test

2.6.26 UninstallProtocolInterface should not succeed with a spurious interface.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3.1 Protocols Consistency Test

2.6.27 All the protocol handle services have non-null function pointers.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3.1 Protocols Consistency Test


Protocol Services: Functionality Assertions

Assertions in this section are tested in TD-2.3 Protocol Handler Services Tests.

2.7.1 LocateHandle should return EFI_NOT_FOUND when a queried protocol is not present.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3 Protocol Handler Services Tests

2.7.2 For a successfully installed protocol (installed using InstallProtocolInterface), LocateHandle must succeed and return the interface of the protocol when the protocol is successfully installed.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3 Protocol Handler Services Tests

2.7.3 LocateHandle must succeed when the search type is ByRegisterNotify and a valid search key as passed as arguments.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3 Protocol Handler Services Tests

2.7.4 Any valid EFI driver image present in the file system can be loaded and started.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3 Protocol Handler Services Tests

2.7.5 For a successfully installed protocol, the services implemented by the protocol must be available and be executed correctly.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3 Protocol Handler Services Tests

2.7.6 A protocol interface that is successfully installed on a valid device handle can be uninstalled using UninstallProtocolInterface.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3 Protocol Handler Services Tests

2.7.7 For a driver image that is successfully loaded and started it should be possible to unload it.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3 Protocol Handler Services Tests

2.7.8 InstallProtocolInterface must succeed when valid protocol interfaces are installed on an existing and valid device handle.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3 Protocol Handler Services Tests

2.7.9 UninstallProtocolInterface must succeed on previously installed valid protocol interfaces.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3 Protocol Handler Services Tests


Protocol Services: Installation and Notifications Assertions

Tests for assertions in this section are described in TD-2.3 Protocol Handler Services Tests, TD-2.3.5 Protocol Install Notify Test, and TD-2.3.3 Register Protocol Notify Test.

2.8.1 CreateEvent succeeds for valid parameter combination.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3 Protocol Handler Services Tests, TD-2.3.5 Protocol Install Notify Test, and TD-2.3.3 Register Protocol Notify Test

2.8.2 RegisterProtocolNotify succeeds for valid parameter combination.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3 Protocol Handler Services Tests, TD-2.3.5 Protocol Install Notify Test, and TD-2.3.3 Register Protocol Notify Test

2.8.3 Any valid EFI driver image present in the file system can be loaded and started.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3 Protocol Handler Services Tests, TD-2.3.5 Protocol Install Notify Test, and TD-2.3.3 Register Protocol Notify Test

2.8.4 Event that has registered for a protocol installation should be signaled after the protocol has been installed successfully and before the watchdog timer expires.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3 Protocol Handler Services Tests, TD-2.3.5 Protocol Install Notify Test, and TD-2.3.3 Register Protocol Notify Test

2.8.5 After a successful installation of a protocol and its notification LocateHandle must succeed when the search type is ByRegisterNotify and a valid search key is passed as an argument.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3 Protocol Handler Services Tests, TD-2.3.5 Protocol Install Notify Test, and TD-2.3.3 Register Protocol Notify Test

2.8.6 For a driver image that is successfully loaded and started it should be possible to unload it.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3 Protocol Handler Services Tests, TD-2.3.5 Protocol Install Notify Test, and TD-2.3.3 Register Protocol Notify Test

2.8.7 For a valid protocol interface that is successfully installed on a device handle HandleProtocol must successfully return a pointer to the protocol's interface.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3 Protocol Handler Services Tests, TD-2.3.5 Protocol Install Notify Test, and TD-2.3.3 Register Protocol Notify Test

2.8.8 For a valid protocol interface that is successfully installed upon a valid handle, it should be possible to reinstall the protocol's interface using ReinstallProtocolInterface.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3 Protocol Handler Services Tests, TD-2.3.5 Protocol Install Notify Test, and TD-2.3.3 Register Protocol Notify Test

2.8.9 The actual number of event notifications observed upon protocol installations and reinstallations must be equal to the number of installations and reinstallations.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3 Protocol Handler Services Tests, TD-2.3.5 Protocol Install Notify Test, and TD-2.3.3 Register Protocol Notify Test

2.8.10 After a successful installation of a protocol and its notification LocateHandle must succeed when the search type is ByRegisterNotify and a valid search key as passed as arguments.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3 Protocol Handler Services Tests, TD-2.3.5 Protocol Install Notify Test, and TD-2.3.3 Register Protocol Notify Test

2.8.11 For a driver image that is successfully loaded and started it should be possible to unload it.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3 Protocol Handler Services Tests, TD-2.3.5 Protocol Install Notify Test, and TD-2.3.3 Register Protocol Notify Test

2.8.12 The observed number of notifications upon protocol installations must match the expected number.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.3 Protocol Handler Services Tests, TD-2.3.5 Protocol Install Notify Test, and TD-2.3.3 Register Protocol Notify Test


Protocol Services: Mandatory Protocols Assertions

Assertions in this section are tested in TD-2.5.2 MandatoryVSVariables Test.

2.9.1 Boot services should return a list of handles for all installed protocols.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.5.2 MandatoryVSVariables Test

2.9.2 For valid parameters, HandleProtocol must return either EFI_SUCCESS or EFI_INVALID_PARAMETER.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.5.2 MandatoryVSVariables Test

2.9.3 All required protocols viz., BLOCK_IO, DEVICE_IO, DEVICE_PATH, DISK_IO, LOAD_FILE, LOADED_IMAGE, SIMPLE_FILE_SYSTEM, SIMPLE_INPUT, SIMPLE_TEXT_OUTPUT, and UNICODE_COLLATION must be installed in the FW.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.5.2 MandatoryVSVariables Test


Image Services and EFI Image Assertions

Assertions in this section are tested in TD-2.4 Image Services Tests.

2.10.1 LoadImage() returns the value EFI_SUCCESS upon loading an Image.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.4 Image Services Tests

2.10.2 When a non-existent Image name is passed, LoadImage fails by returning EFI_NOT_FOUND.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.4 Image Services Tests

2.10.3 When an invalid Image is passed, LoadImage fails by returning EFI_LOAD_ERROR.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.4 Image Services Tests

2.10.4 LoadImage() loads images in succession.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.4 Image Services Tests

2.10.5 StartImage starts an image already loaded in memory.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.4 Image Services Tests

2.10.6 StartImage starts images in succession.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.4 Image Services Tests

2.10.7 LoadImage() returns a value EFI_SUCCESS upon loading an Image from Buffer.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.4 Image Services Tests

2.10.8 StartImage starts an image loaded in memory.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.4 Image Services Tests


Variable Services Assertions

Assertions in this section are tested in TD-2.5 Variable Services Tests and TD-2.4.5 Runtime Services Test.

2.11.1 SetVariable() could set a variable with the NV+BS+RT attribute setting.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.5 Variable Services Tests

2.11.2 GetVariable() could get a variable with the NV+BS+RT attribute setting.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.5 Variable Services Tests

2.11.3 GetNextVariableName(). The mandatory variables that should be present in the variable store are also checked.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.5 Variable Services Tests

2.11.4 SetVariable() would not work if given an invalid argument.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.5 Variable Services Tests

2.11.5 SetVariable() would not work if the size of the variable to be stored were more than 1024 bytes.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.5 Variable Services Tests

2.11.6 GetVariable() returns a EFI_NOT_FOUND in case the variable is not present in the variable store.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.5 Variable Services Tests

2.11.7 GetVariable() returns an EFI_BUFFER_TOO_SMALL in case the buffer size given for the variable to be retrieved is smaller than the actual variable size.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.5 Variable Services Tests

2.11.8 GetVariable() would not work if given an invalid argument.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.5 Variable Services Tests

2.11.9 The Globally Defined Variables should be present in the Variable Store.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.5 Variable Services Tests

2.11.10 The SetVariable() sets a variable in the variable store, which is an integer.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.5 Variable Services Tests

2.11.11 The SetVariable() sets a variable in the variable store, which is a character.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.5 Variable Services Tests

2.11.12 The SetVariable() sets a variable in the variable store, which is a structure.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.5 Variable Services Tests

2.11.13 The GetVariable() gets a variable specified in the variable store, which is an integer.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.5 Variable Services Tests

2.11.14 The GetVariable() gets a variable specified in the variable store, which is a character.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.5 Variable Services Tests

2.11.15 The GetVariable() gets a variable specified in the variable store, which is a structure.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.5 Variable Services Tests

2.11.16 The GetNextVariableName() gets the next variable in the variable store list.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.5 Variable Services Tests

2.11.17 The SetVariable() function deletes the specified variable if a size of zero is specified.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.5 Variable Services Tests

2.11.18 GetNextMonotonicCount() returns the next monotonically increasing count each time it is called.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.5 Variable Services Tests

2.11.19 GetNextHighMonotonicCount() returns the next monotonically increasing count of the higher order 32 bits each time it is called.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.5 Variable Services Tests

2.11.20 GetVariable() returns EFI_SUCCESS when called with valid values for the VariableName, VendorGuid, DataSize, and Data parameters, and a NULL value for the Attributes parameter.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.5.1, page 74-75.
Test description: TD-2.4.5 Runtime Services Test

2.11.21 GetVariable() returns EFI_SUCCESS when called with valid values for the VariableName, VendorGuid, DataSize, and Data parameters, and with Attributes being a valid non-NULL pointer.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.5.1, page 74-75.
Test description: TD-2.4.5 Runtime Services Test

2.11.22 GetVariable() returns EFI_NOT_FOUND when called with a value for VariableName that does not exist, and a valid value for VendorGuid.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.5.1, page 74-75.
Test description: TD-2.4.5 Runtime Services Test

2.11.23 GetVariable() returns EFI_NOT_FOUND or EFI_INVALID_PARAMETER when called with a valid value for VariableName and a value for VendorGuid that doesn’t exist.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.5.1, page 74-75.
Test description: TD-2.4.5 Runtime Services Test

2.11.24 GetVariable() returns EFI_NOT_FOUND when called at runtime attempting to get a variable that does not have the attribute set for runtime.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.5.1, page 74-75.
Test description: TD-2.4.5 Runtime Services Test

2.11.25 When GetVariable() returns EFI_NOT_FOUND, the buffer pointed to by Data is not modified.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.5.1, page 74-75.
Test description: TD-2.4.5 Runtime Services Test

2.11.26 GetVariable() returns EFI_BUFFER_TOO_SMALL when called with the value of the BufferSize parameter being less than the actual size of the variable.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.5.1, page 74-75.
Test description: TD-2.4.5 Runtime Services Test

2.11.27 When GetVariable() returns EFI_BUFFER_TOO_SMALL, BufferSize is updated with the size needed to complete the request.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.5.1, page 74-75.
Test description: TD-2.4.5 Runtime Services Test

2.11.28 GetNextVariableName() returns EFI_SUCCESS and enumerates through all of the existing variables in the current store before returning EFI_NOT_FOUND..

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.5.2, page 76-77.
Test description: TD-2.4.5 Runtime Services Test

2.11.29 GetNextVariableName() returns EFI_NOT_FOUND when there are no variables in the current store.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.5.2, page 76-77.
Test description: TD-2.4.5 Runtime Services Test

2.11.30 GetNextVariableName() returns EFI_BUFFER_TOO_SMALL when called with the value of the VariableNameSize parameter being less than the actual size of a known variable.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.5.2, page 76-77.
Test description: TD-2.4.5 Runtime Services Test

2.11.31 SetVariable() returns EFI_SUCCESS and creates a new variable when called with correct parameters.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.5.3, page 78-79.
Test description: TD-2.4.5 Runtime Services Test

2.11.32 SetVariable() returns EFI_SUCCESS and updates an existing variable when called with correct parameters.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.5.3, page 78-79.
Test description: TD-2.4.5 Runtime Services Test

2.11.33 SetVariable() returns EFI_SUCCESS and deletes a variable when the DataSize parameter is zero.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.5.3, page 78-79.
Test description: TD-2.4.5 Runtime Services Test

2.11.34 SetVariable() returns EFI_SUCCESS and deletes a variable when the Attributes parameter doesn’t have either of the access bits set.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.5.3, page 78-79.
Test description: TD-2.4.5 Runtime Services Test

2.11.35 SetVariable() returns EFI_INVALID_PARAMETER when called with an invalid combination of Attributes bits.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.5.3, page 78-79.
Test description: TD-2.4.5 Runtime Services Test

2.11.36 SetVariable() returns EFI_INVALID_PARAMETER when called with the VariableSize parameter exceeding the maximum allowed.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.5.3, page 78-79.
Test description: TD-2.4.5 Runtime Services Test

2.11.37 SetVariable() returns EFI_OUT_OF_RESOURCES when not enough storage is available to hold the variable and its data.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.5.3, page 78-79.
Test description: TD-2.4.5 Runtime Services Test

2.11.38 When SetVariable() is called at runtime, it does not update a variable that doesn’t have both the EFI_VARIABLE_RUNTIME_ACCESS and EFI_VARIABLE_NON_VOLATILE bits set.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.5.3, page 78-79.
Test description: TD-2.4.5 Runtime Services Test


Time Services Assertions

Assertions in this section are tested in TD-2.6 Time Services Test and TD-2.4.5 Runtime Services Test.

2.12.1 GetTime() gets the current local time and fills in a structure of type EFI_TIME.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.6 Time Services Test

2.12.2 SetTime() sets the current local time by taking a structure of type EFI_TIME.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.6 Time Services Test

2.12.3 Invalid parameter would be returned if the value of one of the elements in the time structure were invalid.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.6 Time Services Test

2.12.4 The function Stall() stalls the processor for the specified seconds.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.6 Time Services Test

2.12.5 Daylight savings time is activated and the time is adjusted.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.6 Time Services Test

2.12.6 GetTime() returns EFI_SUCCESS when called with a valid Time parameter and a NULL value for the Capabilities parameter.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.6.1, page 83.
Test description: TD-2.4.5 Runtime Services Test

2.12.7 GetTime() returns EFI_SUCCESS when called with a valid Time parameter and a valid Capabilities parameter.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.6.1, page 83.
Test description: TD-2.4.5 Runtime Services Test

2.12.8 The time returned by GetTime() is within one second of the time and not less than that time set by a call to SetTime() immediately before the call to GetTime().

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.6.1, page 83.
Test description: TD-2.4.5 Runtime Services Test

2.12.9 SetTime() returns EFI_SUCCESS when called with valid numbers for the various fields in the Time data structure

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.6.2, page 84.
Test description: TD-2.4.5 Runtime Services Test

2.12.10 The Daylight and TimeZone set by SetTime() are correctly returned by GetTime().

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.6.2, page 84.
Test description: TD-2.4.5 Runtime Services Test

2.12.11 SetTime() returns EFI_INVALID_PARAMETER when called with out-of-range values for the fields in the Time data structure.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.6.2, page 84.
Test description: TD-2.4.5 Runtime Services Test

2.12.12 GetWakeupTime() returns EFI_SUCCESS when called with valid parameters.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.6.3, page 85.
Test description: TD-2.4.5 Runtime Services Test

2.12.13 The time returned by GetWakeupTime() is the time set by a previous call to SetWakeupTime().

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.6.3, page 85.
Test description: TD-2.4.5 Runtime Services Test

2.12.14 SetWakeupTime() returns EFI_SUCCESS when called with valid numbers for the various fields in the Time data structure.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.6.4, page 86.
Test description: TD-2.4.5 Runtime Services Test

2.12.15 SetWakeupTime() returns EFI_INVALID_PARAMETER when called with out-of-range values for the fields in the Time data structure.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.6.4, page 86.
Test description: TD-2.4.5 Runtime Services Test


Virtual Memory Services Assertions

The assertions in this section are tested in TD-2.4.5 Runtime Services Test.

2.13.1 SetVirtualAddressMap() returns EFI_SUCCESS when called with valid parameters.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.7.1, page 88 - 89.
Test description: TD-2.4.5 Runtime Services Test

2.13.2 SetVirtualAddressMap() returns EFI_UNSUPPORTED when called at boot time.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.7.1, pages 88 - 89.
Test description: TD-2.4.5 Runtime Services Test

2.13.3 SetVirtualAddressMap() returns EFI_UNSUPPORTED when called when the firmware is already in virtual address mapped mode.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.7.1, pages 88 - 89.
Test description: TD-2.4.5 Runtime Services Test

2.13.4 SetVirtualAddressMap() returns EFI_INVALID_PARAMETER when the VirtualMap parameter does not contain virtual address mapping information for all of the runtime components.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.7.1, pages 88 - 89.
Test description: TD-2.4.5 Runtime Services Test


Miscellaneous Services Assertions

The tests for assertions in this section are described in TD-2.8 Miscellaneous Services and TD-2.4.5 Runtime Services Test.

2.14.1 Invocation of ResetSystem() resets the platform.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.8 Miscellaneous Services

2.14.2 GetNextMonotonicCount() returns the next monotonically increasing count each time it is called.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.8 Miscellaneous Services

2.14.3 GetNextHighMonotonicCount() returns the next monotonically increasing count of the higher order 32 bits each time it is called.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.8 Miscellaneous Services

2.14.4 SetWatchdogTimer sets the time out value for the seconds specified and resets the system.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.8 Miscellaneous Services

2.14.5 ResetSystem() resets the system when called with valid parameters and the ResetData parameter is NULL.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.8.1, pages 92 - 93.
Test description: TD-2.4.5 Runtime Services Test

2.14.6 ResetSystem() resets the system when called with valid parameters and a non-NULL value for the ResetData parameter.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.8.1, pages 92 - 93.
Test description: TD-2.4.5 Runtime Services Test

2.14.7 GetNextHighMonotonicCount() returns the next high 32 bits of the platform’s monotonic counter.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.8.5, page 98.
Test description: TD-2.4.5 Runtime Services Test

2.14.8 After the system is reset, the number returned by GetNextHighMonotonicCount() is one greater than the last number returned.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.8.5, page 98.
Test description: TD-2.4.5 Runtime Services Test

2.14.9 If the low 32 bits of the monotonic counter overflows, the number returned by GetNextHighMonotonicCount() is one greater than the last number returned.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 3.8.5, page 98.
Test description: TD-2.4.5 Runtime Services Test


Device Path Protocol Assertions

Tests for assertions in this section are described in TD-2.10 Device Path Protocol Test.

2.16.1 Enumeration of devices that support Device Path protocol returns at least one device.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.10 Device Path Protocol Test

2.16.2 The device supports Device Path protocol.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.10 Device Path Protocol Test

2.16.3 The Device Path Type is valid.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.10 Device Path Protocol Test

2.16.4 The Device Path Sub Type is valid.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.10 Device Path Protocol Test

2.16.5 The Device Path Length is valid.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.10 Device Path Protocol Test


Device I/O Protocol Assertions

Tests for assertions in this section are described in TD-2.11.1 Device I/O Test

2.17.1 EFI_DEVICE_IO_INTERFACE must be allocated from EfiBootServicesData or EfiRuntimeServicesData.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 6.2, page 132.
Test description: TD-2.11.1 Device I/O Test

2.17.2 EFI_DEVICE_IO_INTERFACE function pointers must be valid pointers to either EfiBootServicesCode or EfiRuntimeServicesCode.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 6.2, page 132.
Test description: TD-2.11.1 Device I/O Test

2.17.3 I/O Read must be able to read from 8, 16, and 32 bit I/O ports when aligned on natural boundaries.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 6.2.1, pages 135 and 136.
Test description: TD-2.11.1 Device I/O Test

2.17.4 I/O Write must be able to write to 8, 16, and 32 bit I/O ports when aligned on natural boundaries.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 6.2.1, pages 135 and 136.
Test description: TD-2.11.1 Device I/O Test

2.17.5 I/O Read must be able to read multiple values from 8, 16, and 32 bit I/O ports when aligned on natural boundaries.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 6.2.1, pages 135 and 136.
Test description: TD-2.11.1 Device I/O Test

2.17.6 I/O Write must be able to write multiple values from 8, 16, and 32 bit I/O ports when aligned on natural boundaries.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 6.2.1, pages 135 and 136.
Test description: TD-2.11.1 Device I/O Test

2.17.7 I/O read and write to a memory address > 2^32 should return EFI_UNSUPPORTED.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 6.2.1, pages 135 and 136.
Test description: TD-2.11.1 Device I/O Test

2.17.8 I/O Read, I/O Write, Mem Read, Mem Write, Pci Read and Pci Write must return EFI_INVALID_PARAMETER when called with invalid parameters.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 6.2.1, pages 135 and 136.
Test description: TD-2.11.1 Device I/O Test

2.17.9 I/O Read, I/O Write, Mem Read, Mem Write, Pci Read and Pci Write must either function correctly even when there is no memory available or return EFI_OUT_OF_RESOURCES.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 6.2.1, pages 135 and 136.
Test description: TD-2.11.1 Device I/O Test

2.17.10 Mem Read must be able to read from any valid address in 8, 16, 32 and 64 bit chunks, including transfers that cross page and cache boundaries.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 6.2.1, pages 135 and 136.
Test description: TD-2.11.1 Device I/O Test

2.17.11 Mem Write must be able to write to any valid address with any alignment in 8, 16, 32 and 64 bit chunks, including transfers that cross page and cache boundaries.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 6.2.1, pages 135 and 136.
Test description: TD-2.11.1 Device I/O Test

2.17.12 Mem Read must return correct data for multi-segment transfers of arbitrary length, where the segment size is 8, 16, 32 or 64 bits.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 6.2.1, pages 135 and 136.
Test description: TD-2.11.1 Device I/O Test

2.17.13 Mem Write correctly writes data for multi-segment transfers of arbitrary length, where the segment size is 8, 16, 32 or 64 bits.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 6.2.1, pages 135 and 136.
Test description: TD-2.11.1 Device I/O Test

2.17.14 Mem Read and Mem Write to a memory address > 2^32 should return EFI_UNSUPPORTED on a 32 bit machine.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 6.2.1, pages 135 and 136.
Test description: TD-2.11.1 Device I/O Test

2.17.15 PCI Read must be able to read from 8, 16, and 32 bit configuration registers when aligned on natural boundaries.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 6.2.1, pages 135 and 136.
Test description: TD-2.11.1 Device I/O Test

2.17.16 PCI Write must be able to write to 8, 16, and 32 bit configuration registers when aligned on natural boundaries.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 6.2.1, pages 135 and 136.
Test description: TD-2.11.1 Device I/O Test

2.17.17 PCI Read must be able to read multiple values from 8, 16, and 32 bit registers when aligned on natural boundaries.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 6.2.1, pages 135 and 136.
Test description: TD-2.11.1 Device I/O Test

2.17.18 PCI Write must be able to write multiple values from 8, 16, and 32 bit registers when aligned on natural boundaries.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 6.2.1, pages 135 and 136.
Test description: TD-2.11.1 Device I/O Test

2.17.19 For each bus physically present in the machine, PciDevicePath must return a valid device path for all valid combinations of PCI Device and Function Ids.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 6.2.2, page 137.
Test description: TD-2.11.1 Device I/O Test

2.17.20 DEVICE_IO Map function operates correctly.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 6.2.3, pages 138 and 139.
Test description: TD-2.11.1 Device I/O Test

2.17.21 DEVICE_IO.Unmap function operates correctly.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 6.2.4, page 140
Test description: TD-2.11.1 Device I/O Test

2.17.22 DEVICE_IO.AllocateBuffer operates correctly.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 6.2.5, pages 141 and 142
Test description: TD-2.11.1 Device I/O Test

2.17.23 DEVICE_IO.Flush operates correctly.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 6.2.6, page 143.
Test description: TD-2.11.1 Device I/O Test

2.17.24 PCI Read must be able to read multiple values from 8, 16, and 32 bit IO ports when aligned on natural boundaries.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 6.2.1, pages 135 and 136.
Test description: TD-2.11.1 Device I/O Test

2.17.25 PCI Write must be able to write to 8, 16, and 32 bit PCI configuration registers.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Section 6.2.1, pages 135 and 136
Test description: TD-2.11.1 Device I/O Test


Console I/O Protocol Assertions

The assertions in this section are tested in TD-2.11.3 Console I/O Test

2.18.1 Pointer to the Console Output protocol is available from the system table.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.11.3 Console I/O Test

2.18.2 OutputString succeeds in printing the given unicode string.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.11.3 Console I/O Test

2.18.3 All SIMPLE_TEXT_OUTPUT protocol services have non-NULL function pointers.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.11.3 Console I/O Test

2.18.4 All the characters in the ISO Latin1 and boxdraw characters sets can be output.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification
Test description: TD-2.11.3 Console I/O Test


Block I/O Protocol Assertions

Tests for the assertions in this section are described in TD-2.12 Block I/O Protocol Test

2.19.1 Validation of MediaID in EFI_BLOCK_IO_MEDIA structure.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Version 0.91, Section 8.1, page 151.
Test description: TD-2.12 Block I/O Protocol Test

2.19.1.1 Validation of MediaID in EFI_BLOCK_IO_MEDIA structure.

2.19.1.2 Validation of RemovableMedia in EFI_BLOCK_IO_MEDIA structure.

2.19.1.3 Validation of MediaPresent in EFI_BLOCK_IO_MEDIA structure.

2.19.1.4 Validation of LogicalPartition in EFI_BLOCK_IO_MEDIA structure.

2.19.1.5 Validation of ReadOnly in EFI_BLOCK_IO_MEDIA structure.

2.19.1.6 Validation of WriteCaching in EFI_BLOCK_IO_MEDIA structure.

2.19.1.7 Validation of BlockSize in EFI_BLOCK_IO_MEDIA structure.

2.19.1.8 Validation of IoAlign in EFI_BLOCK_IO_MEDIA structure.

2.19.1.9 Validation of LastBlock in EFI_BLOCK_IO_MEDIA structure.

2.19.2 Block I/O reads (EFI_BLOCK_READ) are performed on every accessible block. Verify accessible range is accurate and appropriate.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Version 0.91, Section 8.1.2, page 154.
Test description: TD-2.12 Block I/O Protocol Test

2.19.3 Block I/O writes (EFI_BLOCK_WRITE) are performed on every accessible block. Verify accessible range is accurate and appropriate. Verify that data written to the disk is correct.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Version 0.91, Section 8.1.3, page 155.
Test description: TD-2.12 Block I/O Protocol Test

2.19.4 Block I/O writes (EFI_BLOCK_WRITE) are performed on every accessible block. Verify accessible range is accurate and appropriate. Verify that data written to the disk is correct.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Version 0.91, Section 8.1.3, page 155.
Test description: TD-2.12 Block I/O Protocol Test

2.19.4.1 Block I/O Read/Write Hard Disk – Read/Write Phase I.

2.19.4.2 Block I/O Read/Write Hard Disk – Read/Write Phase II.

2.19.4.3 Block I/O Read/Write Hard Disk – Read/Write Phase III.

2.19.4.4 Block I/O Read/Write Removable Disk – Read/Write Phase I.

2.19.4.5 Block I/O Read/Write Removable Disk – Read/Write Phase II.

2.19.4.6 Block I/O Read CD-Rom.

2.19.4.7 Block I/O Read/Write LS-120.

2.19.4.8 Block I/O Read/Write Removable/Hard Disk – Flush.

2.19.4.9 Block I/O Read/Write EFI_INVALID_PARAMETER.

2.19.4.10 Block I/O Read/Write EFI_MEDIA_CHANGE.

2.19.4.11 Block I/O Read/Write EFI_NO_MEDIA.

2.19.4.12 Block I/O Read/Write EFI_WRITE_PROTECTED.

2.19.5 Block I/O reset mechanism operates correctly.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Version 0.91, Section 8.1.1, page 153.
Test description: TD-2.12 Block I/O Protocol Test

2.19.5.1 Block I/O reset – Sequential.

2.19.5.2 Block I/O reset – Random.

2.19.6 Block I/O flushing mechanism operates correctly.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Version 0.91, Section 8.1.4, page 156.
Test description: TD-2.12 Block I/O Protocol Test

2.19.6.1 Block I/O flushing – Hard Disk.

2.19.6.2 Block I/O flushing – Removable Disk.

2.19.6.3 Block I/O flushing – Removable Disk (EFI_NO_MEDIA).


Disk I/O Protocol Assertions

Tests for assertions in this section are described in TD-2.13 Disk I/O Protocol Test

2.20.1 Disk I/O reads (EFI_DISK_READ) are performed on every accessible byte. Verify range is accurate and appropriate.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Version 0.91, Section 9.1.1, page 159.
Test description: TD-2.13 Disk I/O Protocol Test

2.20.2 Disk I/O writes (EFI_DISK_WRITE) are performed on every accessible block. Verify accessible range is accurate and appropriate. Verify that data written to the disk is correct.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification, Version 0.91, Section 9.1.2, page 160.
Test description: TD-2.13 Disk I/O Protocol Test

2.20.2.1 Disk I/O Read/Write Hard Disk – Read/Write Phase I.

2.20.2.2 Disk I/O Read/Write Hard Disk - Read/Write Phase II.

2.20.2.3 Disk I/O Read/Write Hard Disk - Read/Write Phase III.

2.20.2.4 Disk I/O Read/Write Removable Disk – Read/Write Phase I.

2.20.2.5 Disk I/O Read/Write Removable Disk - Read/Write Phase II.

2.20.2.6 Disk I/O Read CD-Rom.

2.20.2.7 Disk I/O Read/Write LS-120.

2.20.2.8 Disk I/O Read/Write Random.

2.20.2.9 Disk I/O Read/Write Random Mixed Block/Disk I/O.

2.20.2.10 Disk I/O Read/Write EFI_INVALID_PARAMETER.

2.20.2.11 Disk I/O Read/Write EFI_MEDIA_CHANGE.

2.20.2.12 Disk I/O Read/Write EFI_NO_MEDIA.

2.20.2.13 Disk I/O Read/Write EFI_WRITE_PROTECTED.


File System Protocol Assertions

Tests for assertions in this section are described in TD-2.14 File System Protocol Test.

2.21.1 It is possible, using LocateHandle to locate a handle that supports the Simple File System.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.14 File System Protocol Test

2.21.2 The Simple File System handle can be used to open a File I/O Interface for the handle.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.14 File System Protocol Test

2.21.3 The handle to the File I/O Interface can be used to open the root directory.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.14 File System Protocol Test

2.21.4 The handle to the root directory can be used to create directory EFICTEST at the root level.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.14 File System Protocol Test

2.21.5 The handle to the directory can be used to create and open the file EFICTEST.DAT in the current directory.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.14 File System Protocol Test

2.21.6 The handle to the file can be used to write data to the file on the disk.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.14 File System Protocol Test

2.21.7 The handle to the file can be used to flush test data to the disk.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.14 File System Protocol Test

2.21.8 The file position is at the end of the file.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.14 File System Protocol Test

2.21.9 The file handle can be used to set file position to the beginning of the file.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.14 File System Protocol Test

2.21.10 The file position is at the beginning of the file.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.14 File System Protocol Test

2.21.11 The file handle can be used to read data back from the file.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.14 File System Protocol Test

2.21.12 The file position is at the beginning of the file.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.14 File System Protocol Test

2.21.13 Data read from the test file matches data written to the file.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.14 File System Protocol Test

2.21.14 The file handle can be used to close the test file.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.14 File System Protocol Test

2.21.15 It is not possible to write to a closed file.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.14 File System Protocol Test

2.21.16 The directory handle can be used to re-open the test file.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.14 File System Protocol Test

2.21.17 The file handle can be used to close and delete test file.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.14 File System Protocol Test

2.21.18 It is not possible to open a previously deleted test file for read access.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.14 File System Protocol Test

2.21.19 The directory handle can be used to close and delete the test directory.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.14 File System Protocol Test

2.21.20 The root directory handle can be used to close the root directory.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.14 File System Protocol Test


Load File Protocol Assertions

The assertions in this section are tested in TD-2.15 Load File Protocol Test

2.22.1 At least the handle with EFI_LOAD_FILE_INTERFACE must be present.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.15 Load File Protocol Test

2.22.2 The call to LoadFile() succeeds.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.15 Load File Protocol Test

2.22.3 The number of bytes read by LoadFile() is correct.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.15 Load File Protocol Test

2.22.4 The date read from the file through LoadFile() must match the data expected.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.15 Load File Protocol Test


Serial I/O Protocol Assertions

Assertions in this section are tested in TD-2.16 Serial I/O Protocol Test.

2.23.1 Can open the serial protocol on the serial loopback device.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.16 Serial I/O Protocol Test

2.23.2 A handle can be opened to the serial loopback driver.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.16 Serial I/O Protocol Test

2.23.3 The serial loopback driver can be reset.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.16 Serial I/O Protocol Test

2.23.4 The attributes of serial loopback port can be set.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.16 Serial I/O Protocol Test

2.23.5 The serial loopback port attributes are set correctly.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.16 Serial I/O Protocol Test

2.23.6 The baud rate in the mode structure is incorrect.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.16 Serial I/O Protocol Test

2.23.7 The FIFO depth in the mode structure is incorrect.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.16 Serial I/O Protocol Test

2.23.8 DTR and RTS can be set.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.16 Serial I/O Protocol Test

2.23.9 DTR and RTS are set correctly.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.16 Serial I/O Protocol Test

2.23.10 A byte can be written to the serial loopback port.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.16 Serial I/O Protocol Test

2.23.11 The correct byte was read back from the serial loopback port.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.16 Serial I/O Protocol Test


Unicode Collation Protocol Assertions

The assertions in this section are tested in TD-2.17 Unicode Collation Protocol Test.

2.24.1 A Unicode Collation Protocol exists on the system.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.17 Unicode Collation Protocol Test

2.24.2 A handle can be opened to the Unicode Collation.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.17 Unicode Collation Protocol Test

2.24.3 String "abc" is less than string "xyz".

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.17 Unicode Collation Protocol Test

2.24.4 String "789" is greater than string "123".

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.17 Unicode Collation Protocol Test

2.24.5 String "ABC" is equal to string "ABC".

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.17 Unicode Collation Protocol Test

2.24.6 String "abc" is equal to string "ABC".

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.17 Unicode Collation Protocol Test

2.24.7 String *def* is found in string "abcdefghij".

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.17 Unicode Collation Protocol Test

2.24.8 String *DEF* is found in string "abcdefghij".

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.17 Unicode Collation Protocol Test

2.24.9 String ?b*E?[gz]* is found in string "abcdefghij".

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.17 Unicode Collation Protocol Test

2.24.10 String ?b*Y?[gz]* is not found in string "abcdefghij".

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.17 Unicode Collation Protocol Test

2.24.11 String intel8086 can be converted to uppercase.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.17 Unicode Collation Protocol Test

2.24.12 String "INTEL8086" can be converted to lowercase.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.17 Unicode Collation Protocol Test

2.24.13 String "intel" equals string "INTEL".

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.17 Unicode Collation Protocol Test

2.24.14 A string can be converted to a FAT filename and back.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.17 Unicode Collation Protocol Test

2.24.15 The language string has valid languages in it.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.17 Unicode Collation Protocol Test


PXE Base Code Protocol Assertions

Assertions in this section are tested in TD-2.18 PXE Base Code Protocol Test.

2.25.1 Initiating PXE Basecode Protocol successfully.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.18 PXE Base Code Protocol Test

2.25.2 Accessing PXE Basecode Interface.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.18 PXE Base Code Protocol Test

2.25.3 Setting up and starting the PXE Boot Environment.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.18 PXE Base Code Protocol Test

2.25.4 DHCP Protocol loaded successfully.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.18 PXE Base Code Protocol Test

2.25.5 DHCP Discover Protocol executed successfully.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.18 PXE Base Code Protocol Test

2.25.6 Initiating MTFTP Hand shake.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.18 PXE Base Code Protocol Test

2.25.7 Downloading remote file over local machine.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.18 PXE Base Code Protocol Test

2.25.8 Accessing remote file to get file size.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.18 PXE Base Code Protocol Test

2.25.9 Validity of Remote Image.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.18 PXE Base Code Protocol Test

2.25.10 Cleaning up the PXE Boot Environment.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.18 PXE Base Code Protocol Test


Boot Manager Variables Assertions

Assertions in this section are tested in TD-2.21 Boot Manager Variables Test.

2.27.1 Existing Boot#### variables can be saved to alternative NVRAM variables.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.21 Boot Manager Variables Test

2.27.2 Test is able to create new Boot#### (1000, 1001, 1002, 1004) variables with their respective load options.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.21 Boot Manager Variables Test

2.27.3 All Boot#### (1000, 1001, 1002, 1004) variables successfully saved by the test must be present in the NVRAM.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.21 Boot Manager Variables Test

2.27.4 Test is able to create new BootOrder to correspond to the boot option sequence 1000-1001-1002-1003.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.21 Boot Manager Variables Test

2.27.5 The BootOrder variable saved by the test must be present and preserve the boot option sequence 1000-1001-1002-1003.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.21 Boot Manager Variables Test

2.27.6 The test is able to create a new NVRAM variable called DIG64TEST_ExecuteOrder for the test applications that correspond to Boot1000, Boot1001, Boot1002 and Boot1003 to post their results into.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.21 Boot Manager Variables Test

2.27.7 All the applications designated in the BootOrder variable must be loaded and executed.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.21 Boot Manager Variables Test

2.27.8 All the applications designated in the BootOrder variable must be sequenced correctly by the boot manager.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.21 Boot Manager Variables Test

2.27.9 All the applications designated in the BootOrder variable must receive their load options correctly through their respective image handles.

Reference Document: WLP# - A5.2.2; Extensible Firmware Interface Specification.
Test description: TD-2.21 Boot Manager Variables Test


EFI Test Descriptions

This section describes the EFI tests. The descriptions include an overview of each test, hardware and software setup, test algorithm/steps, and test results interpretation.


TD-2.1 Event, Timer and Task Priority Services Tests

These tests include:
TD-2.1.1 Wait Events Test
TD-2.1.2 Wait Relative Timer Events Test
TD-2.1.3 Wait Periodic Timer Events Test
TD-2.1.4 Signal Events Test
TD-2.1.5 Signal Relative Timer Events Test
TD-2.1.6 Signal Periodic Timer Events Test


TD-2.1.1 Wait Events Test

Overview

The Wait Events test creates a set of events of type EVT_NOTIFY_WAIT, each of which is associated with a notify-function NotifyWait. For each event, this function keeps count of the respective number of times the NotifyWait is triggered while the events are being waited upon. When this number reaches a preset target, the event is signaled from within the NotifyWait function. The wait upon the events continues until all the events are signaled at least twice. The test fails if all the events cannot signal at least twice before a watchdog timer (set to 10 seconds) for the test expires. The Wait Events test performs the following steps:

  1. The test first verifies by looking up the boot services structure in the system table that all the EFI event services have non-null function pointers. If one or more of the function pointers are NULL, then the test fails immediately.
  2. A watchdog timer of duration equal to 10 seconds is set on the maximum duration allowed for the test.
  3. It then creates a set of 10 events of type EVT_NOTIFY_WAIT at TPL_CALLBACK priority level. Each event is associated with the same notify function called NotifyWait and a notify-context parameter called NotifyWaitCounters. If any of the events cannot be created, the test fails but does not terminate.
  4. The NotifyWaitCounters[i] parameter associated with the i-th event has two fields: a counter variable that keeps track of the number of times the NotifyWait function is executed for that event; a trigger parameter which is set fixed to (3*i+5).
  5. For each event, the NotifyWait function increments the counter field whenever the function is executed. If counter is greater than trigger, the event is signaled and counters is signaled.
  6. The test waits upon all the events using the WaitForEvent service.
  7. When any of the events are signaled, that is the blocking upon WaitForEvent ends, it updates the ‘signaled’ tally on the signaled event. The test fails if WaitForEvent does not return EFI_SUCCESS.
  8. If all the events are signaled at least twice, the test proceeds to close the events. If not, the test checks to see if the watchdog timer has expired. In the latter case, the test fails and proceeds to close all the events. If the watchdog timer did not expire, the test proceeds to another round of waiting upon all the events.
  9. At the end of steps 6-8, all the events opened in step 3 are attempted to be closed. The test fails if any of the events cannot be closed.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

If the test fails in steps 1-9, it fails the test.


TD-2.1.2 Wait Relative Timer Events Test

Overview

The Wait Relative Timer Events test creates a set of events of type EVT_TIMER at TPL_CALLBACK priority level. A trigger time is associated with each event using the SetTimer service. The events are then waited upon and the test passes when all the events are signaled once. The Wait Relative Timer Events test performs the following steps:

  1. The test first verifies by looking up the boot services structure in the system table that all the EFI event services have non-null function pointers. If one or more of the function pointers are NULL, then the test fails immediately.
  2. A watchdog timer of duration equal to 10 seconds is set on the maximum duration allowed for the test.
  3. A set of 10 events of time EVT_TIMER are created with TPL_CALLBACK priority. All the events have a NULL pointer for their respective notify functions. The test fails if any of the events cannot be created, and continues if at least one of the requested events is created.
  4. Using the SetTimer service, the ith (I = 1 to 10) event is associated with a timer that is required to be triggered after (3*I+5)/10 seconds. If SetTimer is not successful for any of the events, the test fails but continues with the events that are successfully created and set timer upon.
  5. A watchdog timer of duration 10 seconds is started. The test waits upon all the events using the WaitForEvent service.
  6. Whenever an event is signaled, that is, its timer has triggered the test, it:

a. Updates the ‘signaled’ count associated with the signaled event.

b. Checks if all the events are signaled at least once; in this case, ‘spinning upon’ the WaitForEvent completed and the test proceeds to step 7.

c. Checks if the watchdog timer expired before all the events are signaled. If the watchdog timer expired, the test fails and proceeds to step 7.

  7. The test proceeds to cancel using SetTimer with a TimerCancel type all the timers and close all the events. If any of the timers are not to be canceled or any of the events cannot be closed, the test fails.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

If the test fails in steps 1-7, it fails the test.


TD-2.1.3 Wait Periodic Timer Events Test

Overview

The Wait Periodic Timer Events test is very similar to Wait Relative Timer Events test in that it creates a set of events of type EVT_TIMER at TPL_CALLBACK priority level, the only difference is that the triggering timers associated with the events are periodic. A trigger time is associated with each event using the SetTimer service. The events are then waited upon and the test passes when all the events are signaled at least thrice. The Wait Periodic Timer Events test performs the following steps:

  1. The test verifies by looking up the boot services structure in the system table that all the EFI event services have non-null function pointers. If one or more of the function pointers are NULL, then the test fails immediately.
  2. A watchdog timer of duration equal to 30 seconds is set on the maximum duration allowed for the test.
  3. A set of 10 events of time EVT_TIMER are created with TPL_CALLBACK priority. All the events have a NULL pointer for their respective notify functions. The test fails if any of the events cannot be created, and continues if at least one of the requested events is created.
  4. Using the SetTimer service, the ith (i = 1 to 10) event is associated with a timer that is required to be triggered periodically after every (3*i+5)/10 seconds. The type of the timer is set to TimerPeriodic. If SetTimer is not successful for any of the events, the test fails but continues with the events that are successfully created and set timer upon.
  5. A watchdog timer of duration 40 (in relation to the number of events created and being waited upon) seconds is started. The test waits upon all the events using the WaitForEvent service.
  6. Whenever an event is signaled, that is, its timer has triggered the test, it:

Updates the ‘signaled’ count associated with the signaled event. The test fails if WaitForEvent does not return EFI_SUCCESS.

Checks if either all the events are signaled at least thrice; in this case, ‘spinning upon’ the WaitForEvent completed and the test proceeds to step 7.

Checks if the watchdog timer expired before all the events are signaled. If the watchdog timer expired, the test fails and proceeds to step 7.

  7. The test proceeds to cancel using SetTimer with a TimerCancel type all the timers and close all the events. If any of the timers cannot be canceled or any of the events cannot be closed, the test fails.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

If the test fails in steps 1-7, it fails the test.


TD-2.1.4 Signal Events Test

Overview

The Signal Events test creates a set of events of type EVT_NOTIFY_SIGNAL, each of which is associated with a notify-function NotifySignal. For each event, this function keeps count of the respective number of times the NotifySignal is triggered as a result of the event being signaled. The main thread of the test keeps checking until all the events are signaled at least 3 times each or until a preset watchdog timer expires. The test fails if the watchdog timer expires before all the events are fired at least 3 times each.

The Signal Events test performs the following steps:

  1. The test verifies by looking up the boot services structure in the system table that all the EFI event services have non-null function pointers. If one or more of the function pointers are NULL, then the test fails immediately.
  2. It then creates a set of 10 events of type EVT_NOTIFY_SIGNAL at TPL_CALLBACK priority level. Each event is associated with the same notification function called NotifySignal and a notify-context parameter called Fired. If any of the events cannot be created, the test fails some assertions and proceeds.
  3. The Fired[i] parameter associated with the i-th event is an integer variable that keeps tally of the number of timers the event signals.
  4. For each event, the NotifySignal function increments the value of the Fired[i] variable when the I-th event is signaled and consequently the NotifySignal function is executed.
  5. The main thread of the test signals each of the events three times using the SignalEvent service. Inability to execute SignalEvent successfully will generate an assertion failure.
  6. In the next phase, the test sets a watchdog timer for a duration of 10 seconds ‘spins’ a loop, checking if each of the events is signaled at least 3 times.
  7. If the watchdog timer expires before all the events are fired (3 times each), they generate an assertion failure. The assertion passes otherwise.
  8. The test proceeds using the CloseEvent() service to close the events. Failure to close any of the events generates an assertion failure.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

If the test fails in steps 1-7, it fails the test.


TD-2.1.5 Signal Relative Timer Events Test

Overview

The Signal Relative Timer Events test creates a set of events of type (EVT_TIMER | EVT_NOTIFY_SIGNAL) at the TPL_CALLBACK priority level. Using SetTimer each event is associated with a timer of type TimerRelative. The test passes when all the events are signaled and the corresponding notify functions are executed.

The Signal Relative Timer Events test performs the following steps:

  1. The test verifies by looking up the boot services structure in the system table that all the EFI event services have non-null function pointers. If one or more of the function pointers are NULL, then the test fails immediately.
  2. A watchdog timer of duration equal to 10 seconds is set on the maximum duration allowed for the test.
  3. It then creates a set of 10 events of type (EVT_TIMER | EVT_NOTIFY_SIGNAL) at TPL_CALLBACK priority level. Each event is associated with the same notify function called NotifySignal and a notify-context parameter called Fired that counts the number times the event is signaled. If any of the events cannot be created, the test fails but does not terminate.
  4. Using the SetTimer service, the ith (i = 1 to 10) event is associated with a timer that is required to be triggered only once after (3*i+5)/10 seconds. The type of the timer is set to TimerRelative. If SetTimer is not successful for any of the events, the test fails but continues with the events that are successfully created and set timer upon.
  5. For each event, the NotifySignal function increments the corresponding Fired variable whenever the function is executed, that is, its timer is triggered.
  6. A watchdog timer with duration 7 seconds depending upon the number of maximum number of events created is started. The test waits and spins in a loop, checking if all the events are fired at least once. If successful, it proceeds to step 8. It also checks to see if the watchdog timer is expired. If the watchdog timer expires, the test fails and proceeds to step 7.
  7. The test fails if it fails to cancel all the timers set in step 4. It also fails if it cannot close all the events opened in step 3.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

If the test fails in steps 1-7, it fails the test.


TD-2.1.6 Signal Periodic Timer Events Test

Overview

The Signal Periodic Timer Events test is similar to Signal Relative Timer Events test and differs only in that it checks whether periodic timer events are being signaled correctly. The test creates a set of events of type (EVT_TIMER | EVT_NOTIFY_SIGNAL) at the TPL_CALLBACK priority level. Using SetTimer, each event is associated with a timer of type TimerPeriodic. The test passes when all the events are signaled at least thrice and the corresponding notify functions are executed. The Signal Periodic Timer Events test perform the following steps:

  1. The test verifies by looking up the boot services structure in the system table that all the EFI event services have non-null function pointers. If one or more of the function pointers are NULL, then the test fails immediately.
  2. A watchdog timer of duration equal to 30 seconds is set on the maximum duration allowed for the test.
  3. It then creates a set of 10 events of type (EVT_TIMER | EVT_NOTIFY_SIGNAL) at TPL_CALLBACK priority level. Each event is associated with the same notify function called NotifySignal and a notify-context parameter called Fired that counts the number of times the event is signaled. If any of the events cannot be created, the test fails but does not terminate.
  4. Using the SetTimer service, the ith (i = 1 to 10) event is associated with a timer that is required to be triggered periodically after (3*i+5)/10 seconds. The type of the timer is set to TimerPeriodic. If SetTimer is not successful for any of the events, the test fails but continues with the events that are successfully created and set timer upon.
  5. For each event, the NotifySignal function increments the corresponding Fired variable whenever the function is executed, that is, its timer is triggered and the event is signaled.
  6. A watchdog timer with duration of 21 seconds depending upon the number of maximum number of events created is started. The test waits and spins a loop, checking if all the events are fired at least 3 times. If successful, it proceeds to step 7. It also checks to see if the watchdog timer expired. If the watchdog timer expires, the test fails and proceeds to step 7.
  7. The test attempts to cancel all the timers and closes all the events. It fails if it cannot cancel all the timers set in step 4. It also fails if it cannot close all the events opened in step 3.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

If the test fails in steps 1-7, it fails the test.


TD-2.2 Memory Allocation Services Tests

The tests in this section include:

TD-2.2.1 Memory Allocate Pool Types Test
TD-2.2.2 Memory Allocate Free Pool Test
TD-2.2.3 Memory Allocate Page Types Test
TD-2.2.4 Memory Allocate Free Pages Test
TD-2.2.5 Memory Allocate Free Pages Below 8MB Test
TD-2.2.6 Memory Allocate Free Pages at Address Test
TD-2.2.7 Memory Allocate All Test
TD-2.2.8 Memory Frequent Allocations Test


TD-2.2.1 Memory Allocate Pool Types Test

Overview

The Memory Allocate Pool Types test allocates one page each for all the permissible allocation types (viz., EfiLoaderData, EfiBoot ServicesData and RuntimeServicesData), which can be allocated successfully using the AllocPool service. It also checks that calls to AllocPool with all other allocation types with an allocation size equal to one physical page, return an EFI_INVALID_PARAMETER.. The Memory Allocate Pool Types test perform the following steps:

  1. This test first verifies by looking up the boot services structure in the system table that all the EFI memory services have non-null function pointers. If one or more of the function pointers are NULL, then the test fails immediately.
  2. The EFI system memory map is constructed using GetMemoryMap and is then checked for correctness and consistency. If these criteria are not satisfied by the system memory map, the test fails immediately.
  3. It then attempts to allocate, using the AllocPool service, successively one page of memory of each of the known memory types (all those listed in table 3-4 of EFI Specification V0.92) including the invalid allocation types.
  4. If the memory type is one of the following (EfiLoaderData, EfiBootServicesData, RuntimeServicesData), and the call to AllocPool does not return EFI_SUCCESS, the test fails, but continues until all remaining memory types are tried out.
  5. If the call to AllocPool succeeds, that is, it returns EFI_SUCCESS or returns a non-null pointer for the space allocated for invalid memory types, then the test fails and continues until all the remaining memory types are tried out.
  6. After all the allocations are complete, the test checks the system memory map and fails, but does not terminate, if the memory map is found to be either incorrect or inconsistent.
  7. The test attempts to free all successful allocations that have resulted in steps 2-4 above. The test fails if any of these allocations cannot be freed.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

If the test fails in steps 1-7, it fails the test.


TD-2.2.2 Memory Allocate Free Pool Test

Overview

The Memory Allocate Free Pool test verifies that repeated memory allocations and freeing of variable allocation sizes using AllocPool are successful. It consists of several ‘rounds’ of allocation. All allocations are typed EfiLoaderData. All the allocations during the ith round are all of size 2I bytes. The largest allocation size tried out is limited by the amount of free memory available when the test begins. The smallest allocation size tried out is 1 byte. The Memory Allocate Free Pool test performs the following steps:

  1. This test verifies by looking up the boot services structure in the system table that all the EFI memory services have non-null function pointers. If one or more of the function pointers are NULL, then the test fails and returns immediately.
  2. The EFI system memory map is constructed using GetMemoryMap and is then checked for correctness and consistency. If these criteria are not satisfied by the system memory map, the test fails and returns immediately.
  3. It then attempts to allocate, using the AllocPool service, 2I bytes of the EfiLoaderData type, where I is the round number.
  4. If the call to AllocPool does not return EFI_SUCCESS, the test fails, but continues until all remaining allocations are tried out.
  5. The total number of allocations tried out in a given round is limited by the maximum amount of memory available, or 1024, whichever is smaller.
  6. After all the allocations in the (ith) round are attempted, the test checks the system memory map and fails but does not terminate if the memory map is found to be either incorrect or inconsistent.
  7. The test attempts to free all successful allocations that have resulted in step 3 above. The test fails if any of these allocations cannot be freed.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

If the test fails in steps 1-6, it fails the test.


TD-2.2.3 Memory Allocate Page Types Test

Overview

The Memory Allocate Page Types test is very similar to Memory Allocate Pool Types test in that it verifies that allocations of one page of each of all the permissible allocation types: EfiLoaderData, EfiBootServicesCode, EfiBootServicesData, EfiRuntimeServicesCode, or EfiRuntimeServicesData can be allocated successfully using the AllocPages service. It also checks that calls to AllocPages with all other allocation types with an allocation size equal to one physical page returns an EFI_INVALID_PARAMETER. The Memory Allocate Page Types test performs the following steps.

  1. This test verifies by looking up the boot services structure in the system table that all the EFI memory services have non-null function pointers. If one or more of the function pointers are NULL, then the test fails and returns immediately.
  2. The EFI system memory map is constructed using GetMemoryMap and is then checked for correctness and consistency. If these criteria are not satisfied by the system memory map, the test fails and returns immediately.
  3. It then attempts to allocate, using the AllocPages service, successively one page of memory of each of the known memory types listed in table 3-4 of EFI Specification V0.92 including the invalid allocation types.
  4. If the memory type is one of the following: EfiLoaderData, EfiBootServicesCode, EfiBootServicesData, EfiRuntimeServicesCode, or EfiRuntimeServicesData, and the call to AllocPool does not return EFI_SUCCESS, the test fails, but continues until all remaining memory types are tried out.
  5. If the call to AllocPages succeeds, that is, returns EFI_SUCCESS or returns a non-null pointer for the space allocated for invalid memory types, then the test fails and continues until all the remaining memory types are tried out.
  6. After all the allocations are complete, the test checks the system memory map and fails, but does not terminate, if the memory map is found to be either incorrect or inconsistent.
  7. The test attempts to free all successful allocations that have resulted in steps 2-4 above. The test fails if any of these allocations cannot be freed.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

If the test fails in steps 1-7, it fails the test.


TD-2.2.4 Memory Allocate Free Pages Test

Overview

The Memory Allocate Free Pages test verifies that repeated memory allocations and freeing of variable allocation sizes using AllocPages are successful. It consists of several ‘rounds’ of allocation. All allocations are typed EfiLoaderData and may be located anywhere that is AllocateType = AllocateAnyPages. All the allocations during the ith round are all of size 2I physical pages. The largest allocation size tried out is limited by the amount of free memory available when the test begins. The smallest allocation size tried out is 1 page. The largest allocation tried out by the test is 2**14 pages = 64 MB. The Memory Allocate Free Pages test performs the following steps:

  1. This test verifies by looking up the boot services structure in the system table that all the EFI memory services have non-null function pointers. If one or more of the function pointers are NULL, then the test fails and returns immediately.
  2. The EFI system memory map is constructed using GetMemoryMap and is then checked for correctness and consistency. If these criteria are not satisfied by the system memory map, the test fails and returns immediately.
  3. It then attempts to allocate, using the AllocPages service, 2I pages of the EfiLoaderData type, where I is the round number.
  4. If the call to AllocPages does not return EFI_SUCCESS, the test fails, but continues until all remaining allocations are tried out.
  5. The total number of allocations tried out in a given round is limited by the maximum amount of memory available, or 1024, whichever is smaller.
  6. After all the allocations in the (ith) round are attempted, the test checks the system memory map and fails, but does not terminate if the memory map is found to be either incorrect or inconsistent.
  7. The test attempts to free all successful allocations that have resulted in step 3 above. The test fails if any of these allocations cannot be freed.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

If the test fails in steps 1-7, it fails the test.


TD-2.2.5 Memory Allocate Free Pages Below 8MB Test

Overview

The Memory Allocate Free Pages Below 8MB test verifies that repeated memory allocations and freeing of variable allocation sizes below the 8MB address range using (Allocate_Type = AllocateMaxAddress) using AllocPages are successful. It consists of several ‘rounds’ of allocation. All allocations are typed EfiLoaderData and may be located anywhere that AllocateType = AllocateMaxAddress. All the allocations during the ith round are all of size 2I physical pages. The largest allocation size tried out is limited by the amount of free memory available below the 8MB range when the test begins. The smallest allocation size tried out is 1 page. The Memory Allocate Free Pages Below 8MB test performs the following steps:

  1. This test verifies by looking up the boot services structure in the system table that all the EFI memory services have non-null function pointers. If one or more of the function pointers are NULL, then the test fails and returns immediately.
  2. The EFI system memory map is constructed using GetMemoryMap and is then checked for correctness and consistency. If these criteria are not satisfied by the system memory map, the test fails and returns immediately.
  3. Using the memory map obtained from step 2, it prepares a list of free regions of memory. It uses this free list to identify regions that are below the 8MB range.
  4. The test proceeds to allocate 2i in each free memory range below 8MB (identified in step 3). The allocations made in the range below 8MB are freed before attempting to allocate in another region below 8MB. It then attempts to allocate, using the AllocPages service, 2i pages of the EfiLoaderData type below the 8MB address range, where I is the round number.
  5. If the call to AllocPages does not return EFI_SUCCESS, the test fails, but continues until all remaining allocations are tried out.
  6. The total number of allocations tried out in a given "free range" is limited by the maximum amount of memory available below the 8MB range, or 500, whichever is smaller.
  7. After all the allocations in the (ith) round are attempted, the test checks the system memory map and fails, but does not terminate if the memory map is found to be either incorrect or inconsistent.
  8. The test attempts to free all successful allocations that have resulted in step 3 above. The test fails if any of these allocations cannot be freed.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

If the test fails in steps 1-7, it fails the test.


TD-2.2.6 Memory Allocate Free Pages at Address Test

Overview

The Memory Allocate Free Pages at Address test verifies that repeated memory allocations and freeing of variable allocation sizes and at specified base addresses using (Allocate_Type = AllocateMaxAddress) using AllocPages are successful. It consists of several ‘rounds’ of allocation. All allocations are typed EfiLoaderData. All the allocations during the ith round are all of size 2i physical pages. The largest allocation size tried out is limited by the amount of free memory available in the ‘free’ list created from the system memory map. The smallest allocation size tried out is 1 page. The Memory Allocate Free Pages at Address test performs the following steps:

  1. This test verifies by looking up the boot services structure in the system table that all the EFI memory services have non-null function pointers. If one or more of the function pointers are NULL, then the test fails and returns immediately.
  2. The EFI system memory map is constructed using GetMemoryMap and is then checked for correctness and consistency. If these criteria are not satisfied by the system memory map, the test fails and returns immediately.
  3. Using the system memory map obtained in step 2, it prepares a list to be referred as the ‘free list’ henceforth, of available blocks of free pages, that is memory type of the corresponding memory descriptor entries = Type == EfiConventionalMemory.
  4. The test proceeds to allocate 2i in each free memory range, identified in step 3. The allocations made in one are freed before attempting to allocate in another range. It then attempts to allocate, using the AllocPages service, 2i pages of the EfiLoaderData type at a fixed base address obtained from the start address of the next available free memory block in the ‘free list’. Here I is the round number. This is accomplished by setting the type argument of the AllocPages to AllocateAddress and the memory address (4th) argument to the required base address.
  5. If the call to AllocPages does not return EFI_SUCCESS or if the returned base address is not equal to the requested base address, the test fails, but continues until all remaining allocations are tried out.
  6. The total number of allocations tried out in a given free memory range is limited by the maximum amount of memory available in the range, or 500, whichever is smaller.
  7. After all the allocations in the (ith) round are attempted, the test checks the system memory map and fails, but does not terminate if the memory map is found to be either incorrect or inconsistent.
  8. The test attempts to free all successful allocations that have resulted in step 3 above. The test fails if any of these allocations cannot be freed.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

If the test fails in steps 1-8, it fails the test.


TD-2.2.7 Memory Allocate All Test

Overview

For each of the valid memory types, this test verifies that all the available free pages can be allocated successfully in a single AllocPages request. In order to account for any overhead that may be incurred by the boot services, the test attempts at the largest possible allocation smaller than the total number of available free pages. The test fails if the difference between the two is greater than or equal to than 2% of the available free pages. The Memory Allocate All test proceeds in the following steps:

  1. The test verifies by looking up the boot services structure in the system table that all the EFI memory services have non-null function pointers. If one or more of the function pointers are NULL, then the test fails immediately.
  2. The EFI system memory map is constructed using GetMemoryMap and is then checked for correctness and consistency. If these criteria are not satisfied by the system memory map, the test fails immediately.
  3. Using the system memory map obtained in step 2, the test prepares a list to be referred to as the ‘free list,’ henceforth of available blocks of free pages, that is memory type of the corresponding memory descriptor entries = Type == EfiConventionalMemory.
  4. For a valid memory type, that is, type = one of (EfiLoaderData, EfiBootServicesCode, EfiBootServicesData, EfiRuntimeServicesCode, or EfiRuntimeServicesData ), it attempts to allocate using the AllocPages service, all the available free pages. This is done by using the ‘free list’ computed in step 3. For every free memory region identified, the test attempts to allocate all the pages available in the region. If the call to AllocPool does not succeed, that is returns EFI_OUT_OF_RESOURCES, the request size is decreased by one page and an allocation is attempted again. The process is repeated until either an allocation succeeds or until the request size decreases to zero.
  5. Upon successful allocation in one free region, allocation is attempted in the next available free memory region in the ‘free list’. Return to step 4.
  6. Upon completing all the available free regions in the ‘free list’, the test computes the total amount of memory allocated. If the amount of memory allocated is less than 98% of the available free memory when the test began, then an assertion failure is declared.
  7. All the memory allocated in step 4 is released. Failure to free the allocations results in an assertion failure.
  8. The memory map is checked for consistency before and after the allocation is freed. Inconsistencies in the memory map result in assertion failures.
  9. The test proceeds with step 4-7 until all the valid memory types are tried out for an ‘exhaustive allocation’ of all the available free memory.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

If the test fails in steps 1-7, it fails the test.


TD-2.2.8 Memory Frequent Allocations Test

Overview

For each valid memory type that can be allocated using AllocPages, this test attempts to maximize the total number of allocations by restricting each allocation to 1 page and the total amount of memory allocated. The test fails if the total amount of memory allocated is less than 97% of the available free pages when the test begins. The Memory Frequent Allocations test performs the following steps:

  1. The test verifies by looking up the boot services structure in the system table that all the EFI memory services have non-null function pointers. If one or more of the function pointers are NULL, then the test fails immediately.
  2. The EFI system memory map is constructed using GetMemoryMap and is then checked for correctness and consistency. If these criteria are not satisfied by the system memory map, the test fails immediately.
  3. The number of available free pages is computed from the memory map.
  4. For a valid memory type (that is type = one of {EfiLoaderData, EfiBootServicesCode, EfiBootServicesData, EfiRuntimeServicesCode, or EfiRuntimeServicesData}), it attempts to allocate 1 page using the AllocPages service.
  5. If the memory type is one of the following (EfiLoaderData, EfiBootServicesData, RuntimeServicesData) and the call to AllocPages does not return EFI_SUCCESS, the test fails, but repeats step 5 until all remaining allocations are tried out. Also, if the returned memory address is NULL, the test fails and continues. The number of allocations tries out is equal to the number of free pages when the test begins. The test keeps tally of the number of successful allocations.
  6. The number of successful allocations is compared against the number of free pages when the test begins. If the difference is greater than 5% of the number of available free pages, the test fails, but continues until all the allocations are tried out.
  7. The test checks the system memory map and fails but does not terminate if the memory map is found to be either incorrect or inconsistent.
  8. The test attempts to free all successful allocations in step 5. The test fails if any of the allocations cannot be freed.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

Steps 5-8 are repeated until all the valid memory types are tried out. If the test fails in steps 1-8, it fails the test.


TD-2.3 Protocol Handler Services Tests

The tests in this section include:

TD-2.3.1 Protocols Consistency Test
TD-2.3.2 Protocol Services Test
TD-2.3.3 Register Protocol Notify Test
TD-2.3.4 Nested Protocol Notify Test
TD-2.3.5 Protocol Install Notify Test
TD-2.3.6 Multiple Protocol Install Test
TD-2.3.7 Required Protocols Present Test


TD-2.3.1 Protocols Consistency Test

Overview

The Protocols Consistency test performs consistency checks on the following EFI protocol services: InstallProtocolInterface, UnInstallProtocolInterface, ReinstallProtocolInterface, LocateHandle, HandleProtocol, LocateDevicePath. For each of these protocol services, the test verifies that services are present in the boot services (BS) structure as non-NULL pointers. For each of the functions that make up the EFI protocol handler services, the test attempts to use the service with various combinations of invalid arguments or unavailable resources. The service(s) should fail and in no case should return EFI_SUCCESS. Every invalid combination of parameters has all but one of its parameters set to an inadmissible value. The service is then called to see that an EFI_SUCCESS is not returned and, whenever applicable, an appropriate status code indicating an inappropriate use of the service is returned. The Protocols Consistency test performs the following steps:

  1. The Boot Services structure is accessed to see if all the protocol handler services (InstallProtocolInterface, UnInstallProtocolInterface, ReinstallProtocolInterface, LocateHandle, HandleProtocol, and LocateDevicePath) have non-null function pointers. An assertion failure is otherwise generated.
  2. InstallProtocolInterface function is called several times, once each with all valid parameters, but without: a NULL GUID in the first instance, a NULL protocol interface pointer (in the second instance), and then with an invalid interface type, and a spurious device handle.
  3. InstallProtocolInterface function is called with all valid parameters and checked for a successful installation of a specific protocol on a specific handle.
  4. LocateHandle is called several times, once each with all valid parameters, but a NULL GUID, an uninstalled protocol’s GUID, and an invalid search type.
  5. LocateHandle is called with all valid parameters and checked for a successful completion and correct handle value returned.
  6. The protocol installed in step-2 is uninstalled from the handle.
  7. ReinstallProtocolInterface is called several times, once each with all valid parameters, but without: a NULL GUID, a spurious GUID, a spurious old-protocol interface, and a NULL new protocol interface.
  8. ReinstallProtocolInterface is invoked with all valid parameters and checked for a successful installation.
  9. UninstallProtocolInterface is called several times, once each with all valid parameters, but without: a NULL GUID, a spurious GUID, a NULL protocol interface, and a spurious protocol interface.
  10. UninstallProtocolInterface is called with all valid parameters and checked for successful deinstallation of the protocol.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-2.3.2 Protocol Services Test

Overview

The Protocol Services test performs a consistency check on the following EFI protocol services: InstallProtocolInterface, UnInstallProtocolInterface, ReinstallProtocolInterface, LocateHandle, HandleProtocol and LocateDevicePath. For each of these services, the test verifies that services are present in the boot services (BS) structure as non-NULL pointers. For each of the services, the test attempts to use the service with either invalid arguments or unavailable resources. The service(s) should fail and in no case should EFI_SUCCESS. It also installs a device driver called DIG64GCD1 with a protocol associated with it. It verifies that LocateHandle successfully identifies the installed protocol. It installs additional protocols on the same device handle and verifies that they are accessible using LocateHandle. It uninstalls them and verifies that they are no longer accessible. After a successful installation of the DIG64GCD1 protocol, the test accesses the services published by the protocol and verifies the results.

Note: Most of this test centers around a specially defined protocol DIG64GCD1. The protocol is intended only to verify if a protocol can be installed and then uninstalled using the protocol services. Details of this protocol are not documented in this specification.

  1. The steps in this test are wrapped inside LogPassFail macros. The LogPassFail macro calls a function that performs some checks given as its first parameter and expects to be equal to the value specified by its second parameter. If the returned value matches the expected value, the assertion indicated by the third parameter is passed. The assertion fails otherwise.
  2. In the first step, the test uses CheckForInstalledHandles() to see if the DIG64GCD1 protocol is already installed and expects a FALSE in return, because it has not been installed.
  3. The test installs a DIG64GCD1 driver by calling the LoadGCDDriver() function. This loads the driver and starts it. Starting the driver also installs the DIG64GCD1 protocol.
  4. If the LoadGCDDriver() function returns an error, the test fails and exits.
  5. The test calls CheckForInstalledHandles() again and checks if the protocol is installed and available. This time a return value of TRUE is expected. If successful, the function uses LocateHandle() using the GUID of the protocol to see if it is installed and available. If the return value is not EFI_SUCCESS, an assertion failure is reported.
  6. The function UseGCDProtocol() tries to get a handle to the interface supported by the protocol. The handle is then used to acquire the corresponding protocol interface. Upon successful acquisition of the handle, the test attempts to uses the interfaces published by the protocol. Assertion failures are reported if it is not possible to perform any of these tests successfully.
  7. The test then tries to install four additional protocols identified by their respective GUIDs on the same device handle returned from installing the DIG64GCD1 protocol. The GUIDs pertaining to these additional protocols are #defined at the start of the test (EFI_DIG64GCD1_PROTOCOL1, EFI_DIG64GCD1_PROTOCOL2, EFI_DIG64GCD1_PROTOCOL3, and EFI_DIG64GCD1_PROTOCOL4). Failure to install any of the protocol generates an assertion failure.
  8. The test then attempts to uninstall the four additional protocols that were installed. If the uninstalls are not successful, then assertion failures are generated.
  9. The test then uninstalls the DIG64GCD1 driver, which in turn uninstalls the DIG64GCD1 protocol.
  10. The test concludes by calling CheckForInstalledHandles() again and expects a return value of FALSE indicating that the protocol has been uninstalled successfully. Any other return value triggers an assertion failure.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-2.3.3 Register Protocol Notify Test

Overview

The Register Protocol Notify test verifies that events registered using RegisterProtocolNotify are signaled whenever the protocol (that the event is waiting to be installed) is installed using InstallProtocolInterface. The test creates an event and registers it for being signaled by the installation of a specific protocol. It then proceeds with the installation of the protocol, while waiting upon a flag that is set by the event's notify function. The test succeeds if the event is signaled before a watchdog timer, preset to 10 seconds, is fired. It fails otherwise.

The test also checks to see that events that have registered for protocol notifications are signaled whenever a protocol is reinstalled several times on the same handle. The test verifies that the exact number of times the event is signaled is equal to the total number of protocol installations and reinstallations upon the same handle.

The test creates an event of type EVT_NOTIFY_SIGNAL at TPL_CALLBACK priority level. The event's notify function simply keeps track of the fact that the event is signaled and keeps count of the number of times that the event is signaled. The test registers the event using the "RegisterProtocolNotify" service for the installation of a specific protocol identified by the GUID EfiDIG64GCDGuid. It then sets a watchdog timer. The Register Protocol Notify test performs the following steps:

  1. The test creates an event using the CreateEvent() boot-time services function.
  2. The test creates, using the CreateEvent() service, an event of type EVT_NOTIFY_SIGNAL at the TPL_CALLBACK priority level and associates the event with the NotifyProtocolInstallation notify function, that is used as the ‘handler’ when that event is signaled. If the event cannot be created successfully, an assertion failure is generated. If the event cannot be created successfully, the test exits.
  3. The NotifyProtocolInstallation() handler function keeps track of the number of times it is called by incrementing the ActualNumberofNotifications variable. If a notification ever occurred on the event, the context variable is set to true.
  4. The test attempts to register the event using the RegisterProtocolNotify() service. The event becomes active in the system and is expected to be signaled when the protocol identified with the EfiDIG64GCDGuid is installed successfully. If the registration does not succeed, the test exits after logging an assertion failure.
  5. The test then waits for the notification to occur. The test sets a watchdog timer for 10 seconds upon this waiting period.
  6. While waiting, the test installs the protocol.
  7. The test waits in a while loop until a flag called ‘notified’ is turned on indicating that the event has been signaled or the watchdog timer indicates that 10 seconds have passed. The notify function turns that ‘notified’ flag on when it runs.
  8. The while loop ends either by the notified flag being turned on, or the watchdog timer signaling that 10 seconds has passed.
  9. The test installs the protocol using the InstallProtocol interface. The LoadGCDDriver() function installs the driver, which installs the protocol.
  10. If the installation of the protocol does not succeed, the test fails and exits.
  11. If the test gets the notification, it tries to determine if the newly installed protocol is available using LocateHandle(). Failure to return the handle results in an assertion failure.
  12. It acquires an interface to the protocol using the HandleProtocol() boot time services function. If unsuccessful at this operation, an assertion failure is generated.
  13. The test attempts to repeatedly (Ntimes) install the protocol to make sure that repeat installations do not cause a problem and result in the event being signaled upon every installation.
  14. The ReinstallProtocolInterface() service function replaces an existing installed interface with another interface. The two calls to ReinstallProtocolInterface() exchange the interfaces identified with OldInterface and NewInterface during each iteration of the ‘for’ loop. This tests if it's possible to replace an existing interface with a new interface. Also, a re-installation triggers a notification and this increments the count kept by the ActualNumberofNotifications variable incremented each time the notify function is called.
  15. The test then unloads the protocol which was installed using the UninstallGCDProtocol() function. Failure to uninstall the protocol generates an assertion failure.
  16. The test then checks that the ActualNumberofNotifications variable is equal to the expected number of event notifications (1 + 2 * NTimes). If these numbers match the test passes, otherwise, the test fails.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-2.3.4 Nested Protocol Notify Test

Overview

This Test is obsolete and no longer performed

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-2.3.5 Protocol Install Notify Test

Overview

The Protocol Install Notify test generates stress on the event notification services through repeated protocol installations and deinstallations. It checks for the ability of a test application to be notified when drivers repeatedly install and reinstall protocol interfaces on a handle. The test creates several events of type RegisterProtocolNotify. Each of these events is registered for notification upon the installation of a specific protocol, associated with its GUID. It then repeatedly installs and uninstalls several drivers. The function of each driver is to associate itself to a handle and install a unique protocol upon that handle repeatedly using ReinstallProtocolInterface. The notify function of the test application keeps count of the number of times each protocol is installed. The test generates assertion failure in either of the following cases:

  • Unable to load or unload the drivers
  • When the number of (protocol installation) events observed for each driver does not match the number of events expected.

The test uses 10 sample drivers called TestDriver1.efi, TestDriver2.efi, ..., TestDriver10.efi. All the driver files are required to be present in the same directory as the test's executable when the test is run.

The Protocol Install Notify test performs the following steps:

  • The test creates a set of 10 events of type EVT_NOTIFY_SIGNAL. The notify function associated with each of these events (called NotifySignal) keeps count of the number of times the event is signaled.
  • Using RegisterProtocolNotify service each event is registered for notification upon the installation of a unique and different protocol. Thus the notify function of each event counts the number of times the respective protocol is installed.
  • The test continues in 24 iterations. Each iteration is identical to the other iterations and consists of steps 4 – 5.
  • Using the LoadImage() service, all the test drivers TestDriver[xx].efi {xx = 1 to 10}are installed in sequence. Failure to install any of the drivers results in an assertion failure. When loaded, each of the test drivers installs a unique protocol and generates signal one of the events registered by the test.
  • Using the UnloadImage() service, all the test drivers are unloaded. Failure to unload any of the drivers results in an assertion failure.
  • When all the iterations are complete, the test checks if each of the events is signaled 24 times. An assertion failure is generated if this is not the case.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-2.3.6 Multiple Protocol Install Test

Overview

This Test is obsolete and no longer performed

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-2.3.7 Required Protocols Present Test

Overview

The Required Protocols Present test verifies that all the mandatory protocols as specified in section 2.5.1 of the EFI specification are implemented. The test uses the LocateHandle service to obtain handles to all the mandatory protocols, viz. (BLOCK_IO, DEVICE_IO, DEVICE_PATH, DISK_IO, LOAD_FILE, LOADED_IMAGE, SIMPLE_FILE_SYSTEM, EFI_FILE_HANDLE, SIMPLE_INPUT, SIMPLE_TEXT_OUTPUT, UNICODE_COLLATION). The test reports assertion failures if LocateHandle returns a NULL handle list when queried for each of the mandatory protocols. The Required Protocols Present test performs the following steps:

  1. The test uses the LocateHandle service (LibLocateHandle is a library version of the service) with the SearchType parameter set to AllHandles. This returns handles to all of the protocols that are installed and stores the list of handles. If the function returns an error or if the handles variable is NULL after the function call, the test reports an assertion failure and exits.
  2. Each of the handles returned in step 1 is checking against each of the mandatory protocols to see if a given handle supports a given protocol. The test loops through all of the mandatory protocols using a for loop (the outermost ‘for’ loop). The mandatory protocols are listed in the RequiredGUIDstruts structure.
  3. For each protocol in the RequiredGUIDStructs structure, the test initializes the MyGuid variable to be that protocol's GUID, the GUID member of that array element.
  4. MyGuid variable represents the mandatory protocol that the inner ‘for’ loop is looking for during the execution of the outermost ‘for’ loop.
  5. In an inner ‘for’ loop, the test cycles through the list of protocols using the handles it acquired in step 1 to see if the mandatory protocol set in step 3 is supported by the handle.
  6. As the inner ‘for’ loop walks through the handles of the installed protocols, the test uses the HandleProtocol() service to see if that protocol matches the mandatory protocol it is looking for.
  7. If the return value of HandleProtocol() is EFI_UNSUPPORTED or EFI_INVALID_PARAMETER, the inner loop continues and checks if the next mandatory protocol in the array is installed. The Result member pertaining to each mandatory protocol keeps track of the fact whether any of the installed handles supports the protocol & in this case, will be tuned to TRUE from FALSE. If the return value is EFI_SUCCESS, the protocol is present, so the test changes the Result member of the RequiredGuidStructs array for that element to be True.
  8. After checking if each of the mandatory protocols are present, that is when the outermost ‘for’ loop exits, the test checks the results.
  9. The test again loops though steps 3-8, once for each of the mandatory protocol in the RequiredGuidStructs array.
  10. The test checks if the Result members fields pertain to all the mandatory variables. If the result member is false, it logs a message that the protocol is absent.
  11. The test generates an assertion failure if any of the mandatory protocols are found to be absent.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-2.4 Image Services Tests

The tests in this section include:


TD-2.4.1 LoadImage Test

Overview

The LoadImage test is designed to test the correct functionality of the LoadImage function. Right parameters are passed and a check for EFI_SUCCESS is made to see whether the test passed or failed. Here the correct executable name is given. This test requires two files to be present. The two files are imagechild.efi and test.efi. The LoadImage test performs the following steps:

  1. The test determines the path of the image to load. It starts by determining the file path of the parent test.
  2. The test determines the path for the child file, which is the EFI image it tries to load. The test appends the child image path to the parent path.
  3. The test attempts to load a valid image by calling LoadImage, the fourth parameter is NULL indicating it is loading an image from a file path rather than from a buffer in memory.
  4. If the image is not loaded, the LOAD_DETECT macro displays a message: "LoadImage() returns a value EFI_SUCCESS upon loading an Image: Failed".
  5. If the image is successfully loaded, log pass calls the LOAD_DETECT macro to display a message that the test was successful.
  6. Next, the test attempts to load an image that is not present. If the status returned is not EFI_NOT_FOUND, the test fails. Otherwise, the test passes.
  7. Then, the test attempts to load an invalid image. If the test does not return an EFI_LOAD_ERROR, the test fails. Otherwise, the test passes.
  8. The Exit() function unloads the image from memory.

Note: this is only required when the image is not run with StartImage(). Since this test only loads the image without running it, an explicit Exit() is needed to unload the image from memory.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-2.4.2 ImageStart Test

Overview

For this test, the Imagechild.efi file is required. This test attempts to load the image of a ‘child’ application and start the image. The boot services functions LoadImage() and StartImage() are used. This test is used to check the functionality of StartImage() function. It also passes some specific load options to the child applications. The child application recovers them through its image handle and verifies them for consistency. The ImageStart test performs the following steps:

  1. InitializeLib() initializes the system table with the current image handle.
  2. The test then gets the parent test's path and the child test's path.
  3. MaxFreeMem() gets the total memory of the system and stores the value in the before_call variable. This is to store the amount of free memory before calling LoadImage() or StartImage().
  4. The test calls LoadImage().
  5. The test passes the Check_Exchange structure with three members set to specific values into the child image (imagechild.efi).
  6. The Check_Exchange structure has three members x, y, and z which are integer, string and floating point variables, respectively.
  7. Imagechild.c uses HandleProtocol() to get a handle to the parent test, which called it. (Imagechild.c can run stand-alone, but only when called from a parent is it passed the variables in Check_Exchange.)
  8. If the handle to the parent is valid, which is tested by the LoadOptions size not being equal to 0, the values of the Check_Exchange structure's x, y, and z variables are checked against expected values.
  9. If the three values match what is expected to be passed into imagechild, imagechild sets the error member of the Check_Exchange structure to 0. This also verifies that the correct child image was run.
  10. After StartImage() returns, MaxFreeMem() is called again to check the total free memory of the system and the result is stored in the after_call variable.
  11. If StartImage() returns EFI_success and the 3 variables of the Check_Exchange structure matched expected values, that is the error member of Check_Exchange is 0 and the free memory in the system after StartImage() returned, which should cause the system to unload the image matches the stored value in before_call, then if those three conditions are true, the test passes, otherwise the test fails.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-2.4.3 MultipleLoadStart Test

Overview

The MultipleLoadStart test is similar to ImageStart test in that it loads a set of child images using the LoadImage service and verifies that they can all be started and executed successfully. This test uses a specific child application called "imagechild". This image is loaded and started repeatedly to generate the effect of spawning multiple child applications one after another. The MultipleLoadStart test performs the following steps:

  1. The test gets the parent image handle and from that gets the parent path.
  2. Using the parent handle and path, the test gets the child image handle and path.
  3. Before loading any images, the test uses MaxFreeMem() to load the free system memory into the before_call variable.
  4. The test loads the image defined as EXEC_1. If the status returned is an error, the test fails.
  5. The test uses StartImage() to run EXEC_1.
  6. After StartImage() returns, MaxFreeMem() is called again and stores the amount of free system memory in after_call. StartImage() does not return control to the test until after the image is finished running and is unloaded.
  7. If StartImage() did not return an error and the amount of free system memory before loading and after loading and running the image is the same; in other words if the image was unloaded successfully, the test passes. Otherwise, the test fails.
  8. The test repeats steps 3 - 7 for the EXEC_2 image; checks the free memory, loads the image, starts the image, then checks free memory again.
  9. This test repeats steps 3 - 7 again for the EXEC_3 image.

Note: Although EXEC_1, EXEC_2 and EXEC_3 are actually #defined as the same EFI file (imagechild.efi), the test uses three separate child device paths (Child1DevicePath, Child2DevicePath, Child3DevicePath) when calling LoadImage(), the three different times.

Note: This test checks three separate times after each call to StartImage to see if the test passes or fails.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-2.4.4 LoadMemoryImage Test

Overview

The LoadMemoryImage test is similar to the ImageStart test in that to load an image by calling the LoadImage service. It differs from ImageVer2 in that it uses the SourceBuffer argument of the function, thus attempting to start on a ‘preloaded’ memory image of the child application. If the LoadImage is a success, StartImage() is called to start the image from the specified location in memory. An image is read and loaded into memory. The LoadImage() is then provided with the address where the LoadImage() is stored in memory. The LoadMemoryImage test performs the following steps:

  1. The test accesses the imagechild.EFI file by getting the parent handle and parent path and uses that to determine the child path. It appends the child path to the parent path.
  2. The test gets a Volume handle where the file is located and gets a handle to the directory where the file is located.
  3. The test opens the file for reading in read-only mode.
  4. The first ‘While’ loop determines the size of the file in bytes.
  5. The size of the image is determined by the number of times through the ‘While’ loop minus 1 (the last time through the loop, less than 1000 bytes are read) times 1000 plus the final value of the size variable. This number is needed to allocate enough space to hold the image in memory.
  6. AllocatePool allocates enough memory for the image and returns the starting location of the memory allocated into the image_load_point variable.
  7. The test remembers the starting location of the buffer by copying image_load_point into remember_image_load_point.
  8. A second While loop reads the imagechild.EFI image file into memory byte-by-byte using the copymem function (1000 bytes at a time, until the last time through the loop, when the remaining bytes are read).
  9. Each time through the loop image_load_point, which initially points to the start of the memory buffer, is moved forward by the value of the size variable times the size of a char8, that is one byte.
  10. When the ‘While’ loop ends, there is an area of memory of size image_size, which begins at the memory address location remember_image_load_point, which has the image.
  11. LoadImage loads the image starting at that specified address. When a memory location is specified as the fourth parameter of LoadImage(), the function ignores the image indicated by the file path.
  12. If you supply LoadImage() with a memory address as the fourth parameter, it ignores the file path parameter. Note, however, the file path must still be valid.
  13. If LoadImage() returns an error, the test fails.
  14. If LoadImage() succeeds, the test passes and StartImage() executes the image.
  15. If StartImage() succeeds, the test passes. Otherwise, the test fails.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-2.4.5 Runtime Services Test

Overview

GetVariable() operates correctly.

The basic plan for testing GetVariable() is to create some variables, using SetVariable(), with known attributes (size, value, etc.), and then verify that GetVariable() returns the correct information. The application also tests that appropriate status codes are returned when attempting to get a variable that doesn’t exist. It also checks that the OUT parameters aren’t changed if the variable doesn’t exist. It also deletes the variables it creates.

Assertion 2.11.20

The application verifies that Data contains the correct value as previously set by SetVariable().

It also verifies that Attributes contain a valid value.

Assertion 2.11.21

The application verifies that Data contains the correct value as previously set by SetVariable().

It also verifies that Attributes contain a valid value.

A reboot/power cycle is performed and the application verifies that a variable with the EFI_VARIABLE_NON_VOLATILE attribute set contains the same values as before the reboot/power cycle. Also, the application verifies that variables that didn’t have the EFI_VARIABLE_NON_VOLATILE bit set are no longer present after the reboot.

Assertions 2.11.22 - 2.11.26

The application calls SetVariable() to create a variable with a known size.

Assertion 2.11.27

The test application creates its own variable store with its own GUID. It use this variable store to test the main functionality of GetNextVariableName(). It also uses the Global Variable store to verify it can be iterated through. The test application creates a set of known variables, restoring the original variables when done with the tests. Tests are run at boot time and runtime.

Assertion 2.11.28

The application calls SetVariable() to create a known set of variables. Then it calls GetNextVariableName() to enumerate through those variables, and verify that they are returned at some point during the enumeration process (there’s nothing in the spec that says SetVariable() must add a new variable to the end of the list, so we can’t assume the order of the variables).

Assertions 2.11.29 and 2.11.30

This requires knowing the size of an existing variable—this will be done by calling SetVariable().

There is only one variable, so we know which variable we’re trying to get.

It verifies that VariableNameSize has been updated with the size needed to complete the request, and then calls GetNextVariableName() with the new size and verifies successful completion.

SetVariable() operates correctly.

The test application uses its own variable store to test SetVariable(). The test application calls SetVariable() with valid and invalid parameters to verify that it returns correct status codes. Tests are performed at both boot time and runtime.

Assertion 2.11.31.

After creating the variable, GetVariable() is called to verify that the variable was created correctly.

Assertion 2.11.32

After updating the variable, GetVariable() is called to verify that the variable was updated correctly.

Assertion 2.11.33

After deleting the variable, GetVariable() is called and it should return EFI_NOT_FOUND.

Assertion 2.11.34

After deleting the variable, GetVariable() is called and it should return EFI_NOT_FOUND.

Assertion 2.11.35

Attributes parameter is zero.

Attributes parameter has the EFI_VARIABLE_RUNTIME_ACCESS bit set, but not the EFI_VARIABLE_BOOTSERVICE_ACCESS bit set.

Assertion 2.11.36

EFI Specification states, "The size of the VariableName, including the Unicode Null in bytes plus the DataSize is limited to a maximum size of 1024 bytes."

Assertion 2.11.37

The test application fills up volatile memory and verifies that EFI_OUT_OF_RESOURCES is returned.

The test application fills up non-volatile memory and verifies that EFI_OUT_OF_RESOURCES is returned.

Assertion 2.11.38

The EFI Specification states, "Variables that have runtime access but that are not non-volatile are effective read-only data variables once ExitBootServices() is performed."

Validation of EFI_TIME structure.

The test application calls GetTime() in order to fill out an EFI_TIME structure. The test application validates that the members of the returned EFI_TIME structure are within the ranges specified in the EFI Specification. The validation is done at both boot time and runtime.

  • Year [16bit unsigned integer]- Verify that the value returned is in the range 1998 to 2099.
  • Month [8bit unsigned integer]- Verify that the value returned is in the range 1 to 12.
  • Day [8bit unsigned integer]- Verify that the value returned is in the range 1 to 31.
  • Hour [8bit unsigned integer]- Verify that the value returned is in the range 0 to 23.
  • Minute [8bit unsigned integer] - Verify that the value returned is in the range 0 to 59.
  • Second [8bit unsigned integer] – Verify that the value returned is in the range 0 to 59.
  • Nanosecond [32bit unsigned integer] – Verify that the value returned is in the range 0 to 999,999,999.
  • TimeZone [16bit unsigned integer] – Verify that the value returned is in the range -1440 to 1440, or is 2047.
  • Daylight [8bit unsigned integer] – Verify that the value returned is a valid bitmask: bits 0 and 1 can be set to 0 or 1; all other bits must be 0 (>=0x00, <0x04).

GetTime() returns valid status codes.

The test application calls GetTime() several times and validates the Time structure. Calls to SetTime() is made and then GetTime() is called to verify that the time returned is not less than the time previously set and is also within a one second range from that time. The test application performs tests at both boot time and runtime.

Assertions 2.12.6 - 2.12.8

SetTime() function operates correctly.

The test application calls SetTime() with valid and invalid parameters to determine that SetTime() returns valid status codes. After calls to SetTime() are made, GetTime() is called to determine that the time was set correctly. The test application performs tests at both boot time and runtime.

Assertion 2.12.9

Instead of trying all valid combinations, the application calls SetTime() four different times: once with all fields at their minimum, once with all fields at their maximum, and twice with fields at a value in between. After each call to SetTime(), GetTime() is called to determine that the time returned is close to what SetTime() was called with.

Assertion 2.12.10

The values for the Daylight field are 0x0, 0x01, 0x02, and 0x03.

The values for the TimeZone field are –1440, 0, 1440, and 2047.

Assertion 2.12.11

For all fields in Time whose value is supposed to be within a certain range, SetTime() is called with a value that is one less than the minimum in the range, and one greater than the maximum in the range. This is done one field at a time while all other fields contain valid values. The values for the Daylight field is greater than 0x03.

GetWakeupTime() function operates correctly.

The test application calls GetWakeupTime() with valid and invalid parameters to determine that GetWakeupTime() returns valid status codes. The test application performs tests at both boot time and runtime.

Assertions 2.12.12 and 2.12.13

SetWakeupTime() function operates correctly.

The test application calls SetWakeupTime() with valid and invalid parameters to determine that SetWakeupTime() returns valid status codes. After calls to SetWakeupTime() are made, GetWakeupTime() is called to determine that the time was set correctly. The test application performs tests at both boot time and runtime.

Assertion 2.12.14

  • Instead of trying all valid combinations, the application calls SetWakeupTime() four different times: once with all fields at their minimum, once with all fields at their maximum, and twice with fields at a value in between.
  • SetWakeupTime() is called with differing values for the Enable parameter. It is called twice with Enable being FALSE, once where the Time parameter is NULL and once where it is a pointer to a valid EFI_TIME structure.
  • The values for the Daylight field are 0x0, 0x01, 0x02, and 0x03.
  • The values for the TimeZone field are –1440, 0, 1440, and 2047.
  • After each call to SetWakeupTime(), GetWakeupTime() is called to determine that the time returned is the same as that with which SetWakeupTime() was called.

Assertion 2.12.15

For all fields in Time whose value is supposed to be within a certain range, SetWakeupTime() is called with a value that is one less than the minimum in the range, and one greater than the maximum in the range. This is done one field at a time while all other fields contain valid values. The values for the Daylight field, are greater than 0x03. It is also called with the Enable parameter being TRUE and the Time parameter being NULL.

SetVirtualAddressMap() function operates correctly.

The test application calls SetVirtualAddressMap() to verify that it returns valid status codes. It creates a fake mapping and then verifies that the contents of memory (for some known memory locations) at the new virtual address match the contents at the physical address before the call.

Assertion 2.13.1

The test application fills some memory with known values. Then, it calls ExitBootServices(). Next, it creates a new virtual memory map and calls SetVirtualAddressMap(). After calling SetVirtualAddressMap() it verifies that the contents of the memory are the same, according to the mapping.

Assertions 2.13.2 and 2.13.3

Calling the function a second time after successfully setting the virtual address map tests this.

Assertion 2.13.4

The test application goes through all but one of the memory descriptors and provides a mapping.

ConvertPointer() function operates correctly.

The test application calls ConvertPointer() and verifies that it returns valid status codes and operates correctly.

  • EFI_SUCCESS – The runtime component calls ConvertPointer() when it is notified of an address map change. It is called once with the EFI_OPTIONAL_PTR flag specified, and once without it specified. After calling ConvertPointer(), the component verifies that the information pointed to by the pointer is correct.
  • EFI_NOT_FOUND – The runtime component calls ConvertPointer() with the Address parameter pointing to a pointer that is not part of the current memory map.
  • EFI_INVALID_PARAMETER – The runtime component calls ConvertPointer() with a NULL value for the Address parameter. It calls the function with the DebugDisposition parameter having invalid bits set.

ResetSystem() function operates correctly.

The test application verifies that calls to ResetSystem() with different parameters reset the system.

Assertion 2.14.5

  • The test application calls ResetSystem() with ResetType set to EFIResetCold and EFIResetWarm.
  • The test application calls ResetSystem() with ResetStatus set to EFI_SUCCESS and something other than EFI_SUCCESS.
  • The test application calls ResetSystem() with DataSize set to 0 and the size of ResetData.

Assertion 2.14.6

  • The test application calls ResetSystem() with ResetType set to EFIResetCold and EFIResetWarm.
  • The test application calls ResetSystem() with ResetStatus set to something other than EFI_SUCCESS.
  • The test application calls ResetSystem() with DataSize set to 0 and the size of ResetData.
  • The test application calls ResetSystem() with ResetData being a pointer to a buffer that contains a Null-terminated Unicode string. It also calls the function with ResetData being a pointer to a buffer that contains a Null-terminated Unicode string, with binary data.

GetNextHighMonotonicCount() function operates correctly.

The test application calls GetNextHighMonotonicCount() and verifies that it returns valid status codes, and correct information. The tests only run at runtime because GetNextHighMonotonicCount() can only be called at runtime.

Assertion 2.14.7 - 2.14.9

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required hardware: Fixed disk drive containing an EFI recognized file system with free space to hold application logs.

Required software: EFI shell from which the test application can be started.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-2.5 Variable Services Tests

The tests in this section include:


TD-2.5.1 NV_Variables Test

Overview

The NV_Variables test is used to set the NV type of variables. A variable is set using the SetVariable service with an NV+BS+RT attribute. The test then resets the platform. When the system is rebooted to EFI, the test regains control and checks for the presence and value of the variable previously saved with the NV attribute.

Note: The test is tested under manual rebooting, but will be tested with auto reboots whenever the DIG64 Test Sequencer implements the ‘RESET’ feature.

The NV_Variables test performs the following steps:

  1. The first time through the test, ExecutionCount equals 0.
  2. The test stores an integer variable initialized to some arbitrary value in the variable store as a non-volatile variable using the SetVariable() runtime function having the NV+BS+RT attribute.
  3. If the Status returned by SetVariable() is EFI_SUCCESS, the test passes. Otherwise, the test fails.
  4. Using the ResetSystem() runtime function, the test re-boots the system in order to test if the non-volatile variable is retained after a re-boot.
  5. After the system reboots, ExecutionCount does not equal 0, so the else block is executed.
  6. The test gets the store_nvram_x variable from the variable store using the GetVariable() runtime function.
  7. If the Status returned by GetVariable() is EFI_SUCCESS and the value of store_nvram_x is the same as stored before the reboot, the test passes. Otherwise, the test fails.
  8. The ‘store_nvram_x’ variable is deleted.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-2.5.2 MandatoryVSVariables Test

Overview

The MandatoryVSVariables test verifies the consistency of the three variable store functions with the EFI specifications: SetVariable, GetVariable and GetNextVariable. It checks to see that the services fail when spurious arguments are passed. It also checks to see that all the mandatory EFI variables are present in the variable store. These are for BS and RT attributes only. The MandatoryVSVariables test performs the following steps:

  1. The test initializes a structure called mandatory_variables that contains the names of the variables that must be present in the variable store, LangCodes, Lang, Timeout, and so on. The test checks if each of these mandatory variables are present in the variable store.
  2. The test attempts to set a variable using an invalid attribute (INVALID_ATTRIBUTE), which is not a valid attribute, that is not EFI_VARIABLE_NON_VOLATILE, EFI_VARIABLE_RUNTIME_ACCESS, or EFI_VARIABLE_BOOTSERVICE_ACCESS.
  3. If the return value of the SetVariable() function is EFI_INVALID_PARAMETER, the test passes. Otherwise, the test fails.
  4. The test attempts to store a variable with a size of 1025 bytes, exceeding the upper limit of 1024 bytes that a variable can have.
  5. If the status returned by the SetVariable() function is EFI_INVALID_PARAMETER, the test passes. Otherwise, the test fails.
  6. The test then uses SetVariable() to delete the variable if it was stored in the variable store. If the fourth parameter of SetVariable, which is the size of the variable to set, is 0, SetVariable() deletes the variable from the variable store.
  7. The test then stores a variable called store_a_variable using the SetVariable() function.
  8. The test uses GetVariable() to attempt to get a variable called unknown_variable that has not been stored in the variable store.
  9. If the status returned is EFI_NOT_FOUND, the test passes. Otherwise, the test fails.
  10. Next, the GetVariable() function attempts to get a variable with a size of 0 bytes, a value too small to hold a variable returned.
  11. If the return value is EFI_BUFFER_TOO_SMALL, the test passes. Otherwise, the test fails.
  12. The test then tries to get the value of the variable store_a_variable using an invalid attribute (INVALID_ATTRIBUTE). If the return value is EFI_INVALID_PARAMETER, the test passes, which is expected since an invalid parameter was passed.
  13. The test deletes the variable store_a_variable by calling SetVariable() with a fourth parameter of 0, which deletes the variable from the variable store.
  14. The test then checks to see whether the mandatory variables are present.
  15. A ‘for’ loop loops 10 times and in each loop GetVariable() is called looking for one of the elements in the mandatory_variables array; as count goes from 0 to 9, it is used as the array subscript to search for each of the 10 elements in the mandatory_variables array.
  16. If a mandatory variable is not found, that is the status returned by GetVariable() is EFI_NOT_FOUND, the test fails and a flag is set to 1.
  17. After the ‘for’ loop exits, if the flag is 0, meaning it was never set to 1 because a mandatory variable was not found, the test passes.


TD-2.5.3 BootRunVariableStore Test

Overview

The BootRunVariableStore test verifies the functionality of the SetVariable and GetVariable services by writing several variables with known values and reading them back. The purpose is to check whether the right values are returned or not. These tests are just for BS and RT services only.

Functionality is checked for the SetVariable, GetVariable and GetNextVariableName functions. The test also verifies that the variables could be deleted using the SetVariable() function. The BootRunVariableStore test performs the following steps:

  1. The test defines a set of GUID values in an array called guid_values. Each variable is uniquely identified by a GUID. This is needed because duplicate names of variables are allowed.
  2. The SetVariable() function stores a variable called store_x as an integer initialized to a value.
  3. SetVariable() takes the name of the variable to store (store_x), a GUID guid_values is the address of the first GUID in the array. The third argument indicates the attributes of the variable, which here is run-time access or'ed with boot service access, so the variable will be available at runtime and at boot time. The value of the variable is set into the location of the fifth parameter, the address of store_x.
  4. Note that a third possible attribute, non-volatile variable is not tested in this test but is tested in NV_variables test. Testing a non-volatile variable requires rebooting the computer to test if the non-volatile variable retains its value after a reboot.
  5. If the status returned by SetVariable() is a success, the test passes. Otherwise, the test fails.
  6. SetVariable() then stores the value of store_y as a variable of type array of char. The GUID for the variable is the address of the second element in the guid_values array.
  7. If SetVariable returns a success, the test passes. Otherwise, the test fails.
  8. The test stores a third variable, a structure called an_instance that has 2 members (an array of char and integer).
  9. After storing the variables, the test attempts to read their values using the GetVariable() function.
  10. The values of store_x, store_y, and an_instance are retrieved using GetVariable() and stored in variables remember _x, remember_char and instance_remember. If any value does not match the expected values, the test fails. Otherwise, the test succeeds.
  11. The test then tests the functionality of the GetNextVariableName() function by storing 17 CHAR16 variables using an array called array_to_store that is initialized to the first 17 letters of the alphabet (‘a’ to ‘o’).
  12. The GetNextVariableName() function gets the first variable in the variable store. It gets the first variable because a null GUID is used as a parameter.
  13. GetNextVariableName() fills in the first variable's GUID to the vendor_guid variable, so the next call to that function uses that GUID and retrieves the next variable in the object store. Each time it is called, GetNextVariableName() uses the current value of vendor_guid to retrieve the next variable in the variable store.
  14. Next, the test does a ‘Do While’ loop.
  15. The check_if_present() function checks if the variable returned is one of the 17 CHAR16 variables it is looking for.
  16. If check_if_present() returns a 1, the variable was not one the test is looking for (it could be store_x or store_y, for example). GetNextVariableName() gets the next variable in the variable store and the ‘continue’ statement returns to the top of the loop. If GetNextVariableName() returns an error, the test fails.
  17. If check_if_present() return_value is not 1, a match has been found with one of the 17 CHAR variables previously stored, such as variable "a".
  18. The test gets the next variable in the variable store and increments a count of matches found. If the count reaches the number of matches it is looking for (NO_OF_VARS constant), the test breaks out of the ‘Do While’ loop.
  19. Next, the test attempts to delete the store_x variable using SetVariable(). Whenever a 0 is passed as the fourth argument, SetVariable() deletes that variable.
  20. The test then tries to get the deleted variable store_x using GetVariable().
  21. If the status return value is not EFI_NOT_FOUND, the test passes. Otherwise, the test fails.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-2.6 Time Services Test

Overview

The TimeCheck test verifies the functionality and consistency of the GetTime and SetTime services. The TimeCheck test performs the following steps:

  1. The GetTime() function gets the local time of the machine and stores it into a variable called retrieve. Each time this test sets the system time, it restores the correct time.
  2. The test should take only a millisecond run, so after the test concludes, the stored time in the variable retrieve is used to set the time to the correct time.
  3. If GetTime() returns an error, the test fails. Otherwise, the test passes.
  4. The SetTime() function sets the current time using the instance structure, which has been initialized to an arbitrary time.
  5. If SetTime() returns an error, the test fails. Otherwise, the test passes.
  6. The current time is restored.
  7. The test attempts to set a time using an invalid parameter, the hour equal to 25.
  8. If the return of SetTime() is EFI_INVALID_PARAMETER, the test passes. Otherwise, the test fails. The test then restores the current time in case setting the hour to 25 did not fail as expected.
  9. The test sets the time to an arbitrary value and calls the Stall() function for 5000000 milliseconds (5 seconds). This stops the processor for five seconds.
  10. The test then gets the current time and stores it into the variable called check.
  11. If the value in seconds between the time set and retrieved before and after the stall() function is not 4 or greater and less than or equal to 6 (that is, it must take at least 4 but no more than 6 seconds), the test fails. Otherwise, the test passes.
  12. If the Stall() function succeeds, the test increments the variable holding the current time by 5 seconds and restores the current time using SetTime().
  13. Next, the test checks for daylight savings time. The test saves the current time and sets the time to the last second in April 2000 before daylight savings time begins.
  14. The test waits five seconds using the Stall() function, and then gets the current time.
  15. If daylight savings time has been adjusted correctly, the hour should equal 1, it advanced one hour. If the hour equals one, the test passes. Otherwise, the test fails.
  16. The test then restores the current system time.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-2.7 Virtual Memory Services Test

Overview

This is an Intel Test and no information is available

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-2.8 Miscellaneous Services

This section includes the following tests:


TD-2.8.1 SystemReset Test

Overview

The SystemReset test tests the functionality of the ResetSystem() service. This program requires a reset of the system. The test verifies its results by accessing the high monotonic count and storing it in the variable store as an NV+BS+RT type variable. This value is compared against the value of the high monotonic count when the test gains control after the system is reset. The SystemReset test performs the following steps:

  1. The ExecutionCount variable is initialized to 0. The ‘If’ condition is initially true, so that block is executed the first time the test runs.
  2. The GetNextHighMonotonicCount() function gets the higher 32-bits of a 64-bit register and stores this value in a variable called high. This value indicates the number of times the system has been booted.
  3. The high variable is stored in the variable store using the SetVariable() function. Note: the attributes are non-volatile, run time, and boot service access. The non-volatile attribute means the variable is retained after the system reboots.
  4. Next, the test resets the system using the ResetSystem() function. This has the effect of incrementing the higher 32-bits of the 64-bit register.
  5. When the system comes back up after the reset, the ExecutionCount is not 0, so the ‘else’ block of the ‘if’ statement is executed.
  6. The test calls GetNextHighMonotonicCount() again and compares the result to the value retrieved.
  7. The test gets the value of the higher 32-bits of a 64-bit register by calling GetNextHighMonotonicCount() and saves it into a variable called retrieve.
  8. If the current value is greater by 1 than the previously stored value, the test passes. Otherwise, the test fails.
  9. The variable monotonic_count is deleted by calling SetVariable() with a size of 0, the fourth parameter.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-2.8.2 MonotonicCountCheck Test

Overview

The MonotonicCountCheck test checks for the functionality of the GetNextMonotonicCount() function. It runs for 2 to the 32 times plus one to check if the lower order 32-bits overflow, the higher order 32 bits change. This test takes a long time to run. It might be better to let this test run overnight. The MonotonicCountCheck test performs the following steps:

  1. GetNextMonotonicCount() gets the value of the lower order 32-bits of the 64-bit register and stores that value into the variable value_remembered.
  2. A ‘for’ loop is executed 232 + 1 times to fill the lower order 32-bits to overflow.

Important: This test requires several hours to run, so it is recommended you allow the test to run overnight, since there is no way to interrupt the test after it starts.

  3. For each execution of the ‘for’ loop, the test calls GetNextMonotonicCount() to increment the lower 32-bits of the 64-bit register.
  4. GetNextMonotonicCount() stores the value of the lower order 32-bits of the 64-bit register in the value_retrieved variable.
  5. If the function did not return EFI_SUCCESS or if value_retrieved is not 1 more than value_remembered, flag_fail is set to 1 and the test fails and breaks out of the ‘for’ loop.
  6. At the end of the ‘for’ loop, value_remembered is set to the value of the value_retrieved variable.
  7. When the ‘for’ loop exits, and the flag_fail is 0, the test passes.
  8. The test then gets the value of the upper order 32-bits by calling GetNextHighMonotonicCount().

Note: GetNextHighMonotonicCount() gets the higher order 32-bits, while GetNextMonotonicCount() is a different function, which gets the lower order 32-bits.

  9. If the function returns an error, the test fails.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-2.8.3 WatchDogTimer Test

Overview

The WatchDogTimer test verifies the functionality of the SetWatchDogTimer() service. The WatchDogTimer test performs the following steps:

  1. The first time through the test, ExecutionCount equals 0.
  2. The test gets the higher order 32-bits of the 64-bit register using GetNextHighMonotonicCount() and stores the value into a variable called high.
  3. The test stores the value of the high variable as monotonic_count as a non-volatile variable in the variable store.
  4. The SetWatchDogTimer() function is a boot services function, which waits a specified number of seconds (5 in this case), then resets the system.

The second parameter can be any value that is not between 0x0000 and 0xFFFF.

The third and fourth parameters are set to zero and NULL.

SetWatchDogTimer() can have a string message logged with the NULL parameter being the string to be logged and the 0 parameter the size of the message in bytes. At this time, however, the location where that message is logged cannot be determined, so zero and NULL must be used as the third and fourth parameters.

  5. The system should reboot after the 5 second wait. When the test resumes, ExecutionCount is not equal 0, so the ‘else’ block is executed.
  6. To test if the system actually is rebooted, the test gets the variable monotonic_count using the GetVariable() runtime function and stores the value in the retrieve variable. It then deletes the monotonic_count variable from the variable store.
  7. Note: there is no way to check if the system actually waited 5 seconds before rebooting, only if the system actually did reboot.
  8. Rebooting the computer should cause the high monotonic count to increment by one. The test checks if EFI_ERROR is returned or if the retrieve variable is not one greater than the value of the high variable.
  9. If the Status returned by SetVariable() is EFI_UNSUPPORTED, the test fails. Otherwise, the test passes.


TD-2.10 Device Path Protocol Test

The DevicePathTest ("DevicePathT") test enumerates all devices on the system. It then locates all the instance of the Device Path protocol in the system. It then examines the structure of each of the path to verify that they have the correct length, correct types and subtypes. The DevicePathTest ("DevicePathT") test performs the following steps:

  1. Enumerate all devices on the system that support Device Path protocol.
  2. For each device:

a. Open the Device Path Protocol

b. Verify that the Type member is correct

c. Verify that the Type member is correct

d. Verify that the Length is valid

  3. Test is complete

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-2.11 Device I/O Protocol Tests

The tests in this section include:


TD-2.11.1 Device I/O Test

Overview

EFI_DEVICE_IO_INTERFACE must be allocated from EfiBootServicesData or EfiRuntimeData.

The test application verifies that the EFI_DEVICE_IO_INTERFACE structure itself is a valid pointer to either EfiBootServicesData or EfiRuntimeData.

The test application verifies that each member of the EFI_DEVICE_IO_INTERFACE structure is a valid pointer to either EfiBootServicesCode or EfiRuntimeCode. Further verification of this structure is done implicitly during the rest of the test.

Assertion 2.17.3

The test reads 8, 16, and 32 bit values from the test adapter’s device registers via IO.Read. These registers are accessible through both memory-mapped I/O and I/O port reads. All port I/O (IO.Read and IO.Write) is compared with the data read by Mem.Read with a width of 32-bits.

Assertion 2.17.4

A 32-bit register is written in 8, 16 and 32-bit chunks with each valid alignment. After writing, the register is read back and compared with the expected values.

Assertion 2.17.5

A scratch area of the test card’s I/O space is read from as a single call to IO.Read (such as Count > 1), using widths of 8, 16, and 32-bits. This is compared with the same area read by individual calls to Mem.Read.

Assertion 2.17.6

A scratch area of the test card’s I/O space is written as a single call to IO.Write (such as Count > 1), using widths of 8, 16, and 32-bits. This is compared with the same area read by individual calls to Mem.Read.

Assertion 2.17.10

The test reads a single 32-bit device register via Mem.Read. This register has a known value based on known information about the test adapter. If this operation fails, the test exits. Subsequently for all memory-mapped and port I/O, it is assumed that single 32-bit Mem.Reads always work.

All subsequent memory mapped I/O tests are done using the 8k of RAM onboard the test card. This is sufficient to guarantee that significant borders can be crossed, such as page and cache line boundaries.

The test reads 8, 16, and 64-bit values from the test adapter’s device registers and compares the results with a 32-bit read.

The test allocates the highest free address in the machine and tries to read to that address.

Assertion 2.17.12

The test reads the entire scratch area in the test adapter’s register space as a single call to Mem.Read. This is done for each transfer width.

Assertion 2.17.11

For each byte position in the 8k scratch space, the test writes to scratch space on the test adapter and reads back the result, using each transfer width in succession.

The test allocates the highest free address in the machine and tries to write from that address.

Assertion 2.17.13

For each byte position in the 8k scratch space, the test writes to scratch space on the test adapter and reads back the result, using each transfer width in succession.

Assertion 2.17.15

The test reads a single 32-bit configuration register via Pci.Read. This register has a known value based on known information about the test adapter. If this operation fails, the test exits. Subsequently for all PCI configuration I/O, it is assumed that a single 32-bit Pci.Reads always work.

The test reads 8, 16, and 64-bit values from the test device’s PCI configuration registers and compares the results with a 32 bit read.

The test allocates the highest free address in the machine and tries to read to that address to PCI configuration space.

Assertion 2.17.23

The entire PCI configuration space of the test device is read in a single call (using Count >1) with widths of 8, 16, and 32-bits. These are compared to single 32-bit reads.

Assertion 2.17.23

The test writes 8-bits to the interrupt line register of the test card then reads back the same register in order to certify that the value was actually written.

The test writes 32-bits to the upper 32-bits of BAR1, ascertains that the correct value has been written, then returns the previous value to the register so that the card can continue to decode addresses correctly.

Since there is no 16-bit PCI configuration register that can be written to, no test is done for 16-bit PCI writes.

Assertion 2.17.18

Call PciDevicePath for each bus, device, and function (multi-function devices only). Parse the device path for each valid PCI device and ensure its validity.

Assertion 2.17.21

To test common buffer DMA (such as DMA to/from the buffer allocated by AllocateBuffer), the test device to fill the buffer is programmed, which is located in physical memory with a certain pattern. The test then verifies that the pattern is correct. Likewise, the device is programmed to read from the buffer and report whether the contents are what was expected.

The test verifies that DMA to/from single page common buffers work.

Allocate the largest common buffer possible and verify that DMA can be done to the whole thing.

Make sure that common buffer DMA can be done to memory above 4 GB, if enough physical memory is present.

EFI_OUT_OF_RESOURCES – Make sure that allocating too large of a common buffer returns EFI_OUT_OF_RESOURCES.

EFI_INVALID_PARAMETER – The test calls AllocateBuffer with each memory type of EFI_MEMORY_TYPE.

Assertion 2.17.19 and 2.17.20

Testing packet DMA (DMA using memory mapping) builds off common buffer DMA. The test first maps a buffer for writing and then instructs the test adapter to do a DMA transfer from the mapped buffer to a common buffer. After the common buffer is checked for consistency, then a buffer then mapped for reading and the device transfers the memory from the common buffer back to the mapped buffer.

The test verifies that packet DMA with small badly aligned buffers work correctly. Badly aligned means crossing page and cache lines.

The test verifies that packet DMA works with very large transfers.

Make sure that packet DMA can be done to memory above 4 GB, if enough physical memory is present.

EFI_INVALID_PARAMETER – For the Operation parameter, the test passes in –1.

EFI_UNSUPPORTED – The test passes in NULL as the HostAddress parameter.

EFI_OUT_OF_RESOURCES – The test application repeatedly allocates pool until AllocatePool returns EFI_OUT_OF_RESOURCES. The test calls DEVICE_IO.Map with the expected result being EFI_OUT_OF_RESOURCES. The test then releases its pool allocation.

Assertion 2.17.22

Flush is tested implicitly. It must be called after every DMA write transaction in order to make sure processor caches have been flushed. If Flush does not work, the other tests fail.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required hardware: Symbios 22910 SCSI adapter (in addition to whatever is controlling the boot device). This card is necessary in order to provide a "known" piece of hardware for the test to converse with. The particular card was chosen because its scripting capabilities make it a versatile DMA engine.

Required software: Windows 2000 operating system is necessary only in as much as the test runs in the context of the HCT test manager.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-2.11.3 Console I/O Protocol Test

Overview

This test verifies that the Console IO protocol is implemented and present. It also verifies that all the services required to be implemented by the ConsoleIO protocol are present in the system. It uses the test service to verify that all the ISO Latin 1 characters and the box draw characters as specified by the EFI V0.99 can be output to the target device. The exact set of characters tested can be found in sections 7.4 and 7.5 of the EFI Specification, V0.99.

  1. The Simple Text Output protocol interface is accessed from the EFI system table. It is used to verify that all the services required to be published by this protocol have non-null function pointers. If not an assertion failure is generated.
  2. All the characters required to be displayed as per the EFI Specification, V0.99 (viz., the ISO Latin1 set and boxdraw character set) are stored in a table as individual strings.
  3. An alphanumeric Latin1 character string is output to the screen using the OutputString service.
  4. The TestString() service is applied to each of the characters stored in the table. A character is marked as ‘unavailable’ whenever TestString() does not return EFI_SUCCESS.
  5. The output of the test clearly logs all those characters that have failed the TestString() test.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-2.12 Block I/O Protocol Test

Overview

Validation of EFI_BLOCK_IO_MEDIA structure.

Additional Notes: The test application has information collected by the OS portion of the test application regarding the reported size of the target device (SeeSetup section below).

The test application isolates the EFI handle to the protocol representing the target test device. The test application examines and validates the members of the returned EFI_BLOCK_IO_MEDIA structure. It is assumed that the information provided by the OS is accurate.

Assertion: 2.19.1.1

MediaId [32bit unsigned integer]- Verify that the media ID returned by EFI matches the known media ID from the operating system portion of the test.

Assertion: 2.19.1.2

RemovableMedia [BOOLEAN] - Verify the correct value is returned by EFI. This data should also be provided by the operating system portion of the test. Testing should require the use of both a removable media device and a non-removable media device to confirm the correct value is returned in both cases. What the OS defines as removable media is what the test defines as removable media.

Assertion: 2.19.1.3

MediaPresent [BOOLEAN] - (Presumably refers to removable media devices only) Verify the correct value is returned by EFI. This data should also be provided by the operating system portion of the test. Testing should require the use of a removable media drive containing a media, and a removable media drive containing no media.

Assertion: 2.19.1.4

LogicalPartition [BOOLEAN] - Verify the correct value is returned by EFI. This data should also be provided by the operating system portion of the test. Testing should require the use of both a disk drive containing one partition, and zero partitions to confirm the correct value is returned in both cases.

Assertion: 2.19.1.5

ReadOnly [BOOLEAN] - (Presumably refers to removable media devices only for which "write-protection" can be enabled) Verify the correct value is returned by EFI. This data should also be provided by the operating system portion of the test. Testing should require the use of both a write-capable media, and a read-only media to confirm the correct value is returned in both cases.

Assertion: 2.19.1.6

WriteCaching [BOOLEAN] – Verify the correct value is returned by EFI. This data should also be provided by the operating system portion of the test. WriteCaching is not a required component and need not be enabled. If the writecaching is enabled then it will be tested and verified.

Assertion: 2.19.1.7

BlockSize [32bit unsigned integer] – Verify the correct value is returned by EFI. This data should also be provided by the operating system portion of the test.

Assertion: 2.19.1.8

IoAlign [32bit unsigned integer] – Verify the correct value is returned by EFI.

Assertion: 2.19.1.9

LastBlock [EFI_LBA] – Verify the correct value is returned by EFI. This data should be provided by the operating system portion of the test and verified against the data EFI presents.

Block I/O reads (EFI_BLOCK_READ) are performed on every accessible block.
Block I/O writes (EFI_BLOCK_WRITE) are performed on every accessible block.

Additional Notes: The primary hard drive should have three partitions. First partition is the EFI partition, second partition is the OS, and third partition is RAW. The operating system portion of the test needs to write a certain amount of files to the removable media.

The test application isolates the EFI handle to the protocol representing the target test device.

Assertion: 2.19.4.1

Starting at block 0, a block of data is read and the checksum of this data is stored in an application buffer at which point the test application writes the data back to the same location the read is from. This processes continues until enough data has been read to cause a flush of the buffer.

Assertion: 2.19.4.2

The test then seeks back to block 0, reads the data back, and compares it to the checksum stored in the application buffer.

Assertion: 2.19.4.3

Seek to the third RAW partition and write an identifiable pattern onto the partition. After which seek to the beginning of the partition and verify the correct pattern is written.

Assertion: 2.19.4.4

Starting at block 0, a block of data is read and the checksum of this data is stored in an application buffer at which point the test application writes the data back to the same location of the read. This processes continues until enough data has been read to cause a flush of the buffer.

Assertion: 2.19.4.5

The test then seeks back to block 0, reads the data back, and compares it to the checksum stored in the application buffer.

Assertion: 2.19.4.6

CD-Rom/DVD-Rom – The operating system portion of the test reads enough different blocks throughout the CD and stores the checksum data for the EFI portion of the test to retrieve and use as a control. The EFI portion of the test then reads from the CD the locations off the CD and verifies that it is the same as the control from the OS.

Assertion: 2.19.4.7

LS-120 – This test starts out with the 120mb media in the drive and runs the hard disk test against it. Once completed the user is asked to remove the 120mb media and insert a 1.44mb media into the drive and the hard disk test continues to run.

Assertion: 2.19.4.8

This test reads from a number of locations on the drive that are random and are not in sequential order and store the checksum of the data in a location in the application buffer. Then a flush takes place; this is to cause the cache to be cleared out to disk. Once all the data has been stored then in a determined loop the test reads from the block of data and writes it back down. The test does this for every block stored for about two hundred times. At the end of the reading and writing the test goes back to all locations, reads the data, and verifies it against the checksum.

Assertion: 2.19.4.9

EFI_INVALID_PARAMETER - A read and write is done past the given blocks of all device classes to verify that the error EFI_INVALID_PARAMETER is returned.

Assertion: 2.19.4.10

EFI_MEDIA_CHANGE - On media that is removable a check is done by ejecting the media from the device and inserting a piece of media that has a different volume label and then doing a read and assuring that EFI_MEDIA_CHANGE is returned.

Assertion: 2.19.4.11

EFI_NO_MEDIA – On media that is removable, the media is ejected from the device and a read and write is conducted and the return code is checked and verified that the EFI_NO_MEDIA is returned.

Assertion: 2.19.4.12

EFI_WRITE_PROTECTED – On media that is removable, the media is ejected from the device and the write protection is set and the media is re-inserted into the device. At this time, the application attempts a write and checks to assure that EFI_WRITE_PROTECTED is returned.

Block I/O reset mechanism operates correctly.

Additional Notes: The primary hard drive should have three partitions. First partition is the EFI partition, second partition is the OS, and third partition is RAW.

The test application isolates the EFI handle to the protocol representing the target test device.

Assertion: 2.19.5.1

Sequential (Hard Disk) – The test application does a seek to the RAW partition and two hundred consecutive reads. The checksum data then is stored in the test application buffer. After the last read a reset is issued. After completion of the reset, the test application seeks back to the initial starting point and two hundred consecutive reads occur and are verified against the first initial reads. After the verification another reset is issued with the ExitendedVerification bit set. After completion of the reset, the test application seeks back to the starting point of the reads and again verifies the data.

Assertion: 2.19.5.2

Random (Hard Disk) – The test application does a seek to the RAW partition and two hundred random reads. The checksum data then is stored in the test application buffer. After the last read a reset is issued. After completion of the reset, the test application seeks back to the initial starting point and two hundred random reads occur and are verified against the first initial reads. After the verification, another reset is issued with the ExitendedVerification bit set. After completion of the reset, the test application seeks back to the starting point of the reads and again verifies the data.

Block I/O flushing mechanism operates correctly.

Additional Notes: The primary hard drive should have three partitions. First partition is the EFI partition, second partition is the OS and third partition is RAW.

The test application isolates the EFI handle to the protocol representing the target test device.

Assertion: 2.19.6.1

The test application does a seek to the RAW partition. At this point, the test writes twenty consecutive writes with a known pattern to the disk. On the twentieth write, the test application causes a flush and then a reset. Once the reset is completed, the test application then seeks back to the RAW partition, reads the data, and verifies that the data was written correctly. This process is repeated ten times.

Assertion: 2.19.6.2

The test application does twenty consecutive reads and stores the data in a buffer. Then the test application writes this data back in the same location and issues a flush and a reset. Once the reset is completed, the test application verifies that the data was written correctly. This process is repeated ten times. Then the test does ten writes and causes the media to be ejected. Once the media is ejected, the test does one more read and verifies that the media is ejected. Then it re-inserts the media and verifies the data was flushed to the media.

Assertion: 2.19.6.2

EFI_NO_MEDIA – On media that is removable, the media is ejected from the device and a flush is conducted and the return code is checked and verified that the EFI_NO_MEDIA is returned.


TD-2.13 Disk I/O Protocol Test

Overview

Disk I/O reads (EFI_DISK_READ) are performed on every accessible byte.

Disk I/O writes (EFI_DISK_WRITE) are performed on every accessible block.

Additional Notes: The primary hard drive should have three partitions. First partition is the EFI partition, second partition is the OS, and the third partition is RAW. The operating system portion of the test needs to write a certain amount of files to the removable media.

The test application isolates the EFI handle to the protocol representing the target test device.

Assertion 2.20.1.1

Starting at block 0, a block of data is read and the checksum of this data is stored in an application buffer at which point the test application writes the data back to the same location read from. This processes continues until enough data has been read to cause a flush of the buffer.

Assertion 2.20.1.2

The test then seeks back to block 0, reads the data back, and compares it to the checksum stored in the application buffer.

Assertion 2.20.1.3

Seek to the third RAW partition and write an identifiable pattern onto the partition. After which seek to the beginning of the partition and verify the correct pattern is written.

Assertion 2.20.1.4

Starting at block 0, a block of data is read and the checksum of this data is stored in an application buffer at which point the test application writes the data back to the same location read from. This processes continues until enough data has been read to cause a flush of the buffer.

Assertion 2.20.1.5

The test then seeks back to block 0, reads the data back, and compares it to the checksum stored in the application buffer.

Assertion 2.20.1.6

CD-Rom/DVD-Rom – The operating system portion of the test reads enough different blocks throughout the CD and stores the checksum data for the EFI portion of the test to retrieve and use as a control. The EFI portion of the test then reads from the CD the locations off the CD and verifies that it is the same as the control from the OS.

Assertion 2.20.1.7

LS-120 – This test starts out with the 120mb media in the drive and runs the hard disk test against it. Once completed the user is asked to remove the 120mb media and insert a 1.44mb media into the drive and the hard disk test runs again.

Assertion 2.20.1.8

Random (Hard Disk/Removable Disk) – On hard disk drives, the test uses the first partition. This test reads from a number of locations on the drive that are random and are not in sequential order and store the checksum of the data in a location in the application buffer. Then a flush takes place; this is to cause the cache to be cleared out to disk. Once all the data has been stored then in a determined loop the test reads from the block of data and writes it back down. The test does this for every block stored for about two hundred times. At the end of the reading and writing the test goes back to all locations, reads the data, and verifies it against the checksum.

Assertion 2.20.1.9

Mixed Block/Disk I/O (Hard Disk/Removable Disk) – On hard disk drives the test uses the first partition. The test reads from a number of locations on the drive that are random and are not in sequential order and stores the checksum of the data in a location in the application buffer. These reads are mixed in Block and Disk I/O format. Then a flush takes place; this is to cause the cache to be cleared out to disk. Once all the data has been stored, then in a determined loop, the test reads from the block of data and writes it back down. The test does this for every block stored for about thirty times using mixed Block and Disk I/O. At the end of the reading and writing the test goes back to all locations, reads the data, and verifies it against the checksum.

Assertion 2.20.1.10

EFI_INVALID_PARAMETER - A read and write is done past the given blocks of all device classes to verify that the error EFI_INVALID_PARAMETER is returned.

Assertion 2.20.1.11

EFI_MEDIA_CHANGE - On media that is removable, a check is done by ejecting the media from the device and inserting a piece of media that has a different volume label and then doing a read and assuring that EFI_MEDIA_CHANGE is returned.

Assertion 2.20.1.12

EFI_NO_MEDIA – On media that is removable, the media is ejected from the device and a read and write is conducted and the return code is checked and verified that the EFI_NO_MEDIA is returned.

Assertion 2.20.1.13

EFI_WRITE_PROTECTED – On media that is removable, the media is ejected from the device and the write protection is set and the media is re-inserted into the device. At this time, the application attempts a write and checks to assure that EFI_WRITE_PROTECTED is returned.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required hardware:

  • Fixed disk drive that is 10 GB or greater.
  • Removable disk drive capable of being made read-only.
  • CD-ROM drive.
  • DVD Drive.
  • LS-120.

Required software:

  • Windows operating system capable of generating necessary data to perform parameter validation.
  • The following information is generated by an OS-supported application in an encrypted data file, stored on a non-volatile media:
  • Size (in logical blocks) of the disk drive.
  • Size (in bytes) of the logical blocks.
  • Whether the device is a removable-media device or not.
  • Whether the device contains media or not.
  • Whether the device is "read-only" or not.
  • Whether the device contains any EFI recognized partitions or not (FAT12, FAT16, FAT32, EFI-FS)
  • Whether the device is capable of supporting write-caching or not. Note, it may be impossible for the operating system to determine if the controller/device combination can support write-caching in the EFI environment or not.
  • Store data blocks read from a CD to compare in the EFI portion of the test.
  • CD disk that is a different volume than the test CD.
  • Removable Media with different volume name than test piece.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-2.14 File System Protocol Test

Overview

The SimpleFileTest tests all of the interfaces that implement the Simple File System Protocol, including File I/O, Volume Open and File Handle. It does this by opening a volume, creating a directory, creating a file and doing various file operations on the file. When done, the test file and test directory are removed.

The DevicePathTest ("DevicePathT") test performs the following steps:

  1. The test searches for a device that supports the Simple File System Protocol and uses the first device enumerated. If no device is found, then the test fails.
  2. Using the handle to the located device, the test opens the volume and gets a handle to the root directory. Using this handle, the test creates and opens a directory to be used for the test.
  3. The handle to the directory is used to create a test file.
  4. Once the test file is successfully opened, data is written to the file.
  5. The position of the file pointer is checked, moved to the beginning of the file and then checked again.
  6. Then the data is read back and checked for accuracy. The data pattern is a simple count where each data item is set to its index.
  7. Then the file is closed and the test tries to access the closed file. (This should fail.)
  8. The file is re-opened for read access and then simply closed and deleted.
  9. The test directory is closed and deleted and then the root directory is closed.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-2.15 Load File Protocol Test

Overview

This LoadFile test verifies the functionality and consistency of the LoadFile protocol when an instance of the LoadFile protocol is installed over the PXE protocol. If no instance of LoadFile is installed over a PXE device, the test fails all assertions. The test requires the same difficult HW and SW setup as required for TD-2.18 PXE Base Code Protocol Test. The test uses the LoadFile protocol to download a remote text file and compares its contents with the data expected.

The LoadFile test performs the following steps:

  1. The test uses LocateHandle() service to locate all instances of the LoadFile Protocol. If no handles are found, the test fails all assertions and exits; since LoadFile is a required protocol according to the EFI V0.99 spec. Steps 2-5 are repeated for each instance of the handle located.
  2. HandleProtocol() is used to acquire the LoadFile protocol interface.
  3. The LoadFile() service of the protocol interface is applied to download the remote file into a memory buffer. If LoadFile() fails with any status other than EFI_BUFFER_TOO_SMALL, the test skips this instance of the LoadFile handle and proceeds with the next handle. When a first instance of the interface upon which LoadFile() succeeds is detected, other instances are not tested.
  4. The number of bytes returned by LoadFile() is compared against the expected number of bytes an assertion failure is generated if they do not match.
  5. The data returned in the memory buffer by the LoadFile() call is compared against the expected data an assertion failure is generated, if they do not match.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

  • Set up a PXE boot server as described in the hardware and software setup for TD-2.18 PXE Base Code Protocol Test.
  • Copy the file "NshellEfi.0" found in the "bin\LoadFileProtocol" directory of the CD/ floppy release to the "...pdk\system\images\IA64PC\UNDI\EFI64\NShellEfi.0", where "pdk" is the root directory for the PXE PDK installation on the PXE boot server.
  • Important: Both TD-2.18 PXE Base Code Protocol Test and TD-2.15 Load File Protocol Test require a target file that is identically named and located on the PXE boot server. However, the specific PXE boot files used by these tests are different. What this means is that both tests cannot be run in automated mode, since the PXE boot file assumed by one of the tests cannot be present on the PXE boot server. Before running the second test, it is necessary to swap the "...pdk\system\images\IA64PC\UNDI\EFI64\ NShellEfi.0" file on the PXE boot server.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-2.16 Serial I/O Protocol Test

Overview

The SerialTest test first checks to see if any legacy COM ports are present in the system. The test exits if none are present. It then verifies, by looking at the handles of all the protocols installed in the system, if the Serial I/O protocol is installed. It then probes all instances of the serial I/O protocol to see if any of the devices (on which Serial I/O protocol is installed) are physical Serial I/O ports. If not, the test bails out by observing that Serial I/O protocol is not mandatory to the system. Otherwise, the test uses the installed serial loopback connector(s) to open, write to, read back, and verify data written to each of the serial ports (& Serial I/O protocols), thus detected. Each assertion is passed if any one of the serial I/O interfaces passes the assertion.

The SerialTest test performs the following steps:

  1. Using the legacy I/O port addresses known for the scratchpad registers of the COM1, COM2, COM3 and COM4 ports, the test first performs a write-read test on the scratchpad registers. Presence of the respective COM ports is deduced from the results of this test. If no COM ports are detected, the test exits without reporting any assertions. This is because neither the COM ports nor the Serial I/O Protocol is mandatory as per EFI Spec V0.99.
  2. The test then uses the LocateHandle service to detect instances of the Serial I/O protocol installed in the system. If none are found, the test exits without reporting any assertions.
  3. Using the handles detected in step 2, the test extracts the respective device paths on which the instance of the Serial I/O protocol is installed. Each of these paths is parsed to see if it corresponds to a legacy (ISA) serial port. If none corresponds, the test exits.
  4. The test begins to use the Serial I/O protocol services upon the Serial I/O ports (that are physically correlated with instances of the serial I/O protocol as in step 3). Steps 5-9 are repeated for each instance of the serial I/O protocol.
  5. Once the correct device is found, a handle is opened to the Serial I/O Interface for that device.
  6. The serial loopback device is reset and the status is checked for that call.
  7. The attributes of the serial loopback device are set and the resulting entries in the mode member of the Serial I/O Interface are checked for accuracy.
  8. Control bits DTR and RTS are set and then verified by checking the settings of DSR and CTS. (Note that since the serial loopback driver doesn't actually control a device, the functionality of a loopback connector is emulated in the driver by setting DSR and CTS anytime DTR and RTS are set.)
  9. Next, a byte is written to the device and then read back. The loopback driver simply holds on to the byte written and then returns it on the read.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires one or more serial port loopback connectors. The user needs to plug serial port loopback connectors into each of the ISA COM ports found at the back of the IA64 (system) under test.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-2.17 Unicode Collation Protocol Test

Overview

The Unicode test finds and opens a handle to a Unicode Collation interface. It then uses the handle to do various string operations and checks each operation for correctness. The Unicode test performs the following steps:

  1. The test enumerates all devices that support the Unicode Collation
    protocol on the system and opens the first one enumerated. If no device is found, the test fails.
  2. It then uses the handle to verify that the following string operations work correctly:

"abc" < "xyz"

"789" > "123"

"ABC" = "ABC"

"abc" = "ABC"

pattern "*DEF*" matches "abcdefghij"

pattern "?b*E?[gz]*" matches "abcdefghij"

pattern "?b*Y?[gz]*" does not match "abcdefghij"

  3. It then converts a string to uppercase and converts a string to lower case and verifies that both operations worked correctly.
  4. Then the test converts a string to a FAT filename and back and verifies that both operations worked.
  5. Finally, the test verifies that the SupportedLanguages member of the Unicode Collation Interface structure has a valid language string in it.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-2.18 PXE Base Code Protocol Test

Overview

The PXE Protocol test tries to locate a device that supports the Base Code Protocol on the system. If a device is found, the test starts the protocol and tests DHCP and boot image discovery. Then trivial FTP is tested.

The PXE Protocol test performs the following steps:

  1. The test enumerates all of the devices on the system that support the PXE Base Code Protocol and opens the first one found.
  2. It establishes a handle to the PXE Base Code Interface and starts the service.
  3. Next it attempts to complete a DHCP sequence. If this operation fails, the test cannot continue.
  4. If the DHCP sequence is successful, it tries to discover a boot server.
  5. Reading a file on the DHCP server tests trivial FTP. A file is downloaded from the server that is a valid EFI image. The remote Image is then executed locally. Value is returned back to the parent to check whether the right file was downloaded and executed.
  6. Finally, the test stops the service and closes the protocol.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires additional hardware and software setup in addition to the IA64 platform (under test) and the test binary:

  • An Intel x86 based server platform running Windows NT4.0 Server with the following SW components/services installed on it:
  • Windows NT DHCP service.
  • Intel PXE PDK V3.0 (installed and configured to serve DOS UNDI to a remote PXE client).
  • The PXE PDK must also be configured to talk to an IA64 PXE client.
  • An Ethernet hub.

Note: Complete details regarding the installation and configuration of the PXE boot server are provided in the next section titled "PXE Boot Server Setup Required for the PXE Protocol Test".

This test requires two EFI applications. One residing on the client side (Client.efi) and the other on the server (such as the PXE boot server) side (Server.efi). These files are provided as part of the standard DIG64 test suite kit.

PXE Boot Server Hardware Setup (PXE Protocol Test)

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

  • Install Windows NT4.0 server on an IA-32 platform. This platform is used as the DHCP server and PXE boot server (henceforth referred to as the "PXE Server").
  • Disconnect any existing network connections and connect both the IA64 platform (under test) and the PXE server to the Ethernet hub.
  • Configure the network card on the PXE server to use static IP for its TCP protocol stack.
PXE Boot Server Software Setup (PXE Protocol Test)

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

It’s assumed that the DHCP and the PXE servers reside on the same machine and the servers are setup for an IA64 platform. To set up the software, perform the following steps:

1. Download and Install the PXE PDK.

PXE PDK Instructions should be referred for configuring the DHCP server to support PXE. To check whether the install was successful or not, an IA32 machine should be used as a client and DOS boot should be tried.

2. Configure the server for an IA64 client. This is done as follows:

a. Start PXE Config Utility. It can be done by going to Start -> Programs -> PXE PDK -> PXE Config Utility.

b. Add EFI Arch and NIC definitions. It can be done by expanding the ‘proxyDhcp’ tree. Right click on 'Client Boot Menu' and select 'Add Client Support'. Click on 'Define New Client Types'. Enter Arch Type # = 2, Arch Name = IA64PC, NIC Type = UNDI and click 'OK'. Click 'OK' on 'Add/Select Client Support' box. Two branch entries under the expanded 'Client Boot Menu’ are displayed.

c. Add EFI to the menu. Right click on 'EFI (UNDI)' and click 'Add Boot Server to this menu'. Enter Boot Server Type = 15 (this is the next unused number), Description = 'DIG64' (this is the boot menu on the client side) and click 'Add'. Click 'OK' .Now you have one entry in the boot menu. If you need, you can add more entries similarly.

d. Add EFI Boot Server type information. Right click on the BStrap subtree under proxyDhcp and select 'Add client support'. Select Client Architecture = IA64PC and Client NIC Type = UNDI and click OK. You should see two entries on the right hand side.

Right click on 'Boot Server' and choose 'Add/Remove Bootserver types'. Enter Boot Server Type = 15 (or the number you entered in bullet c) and Boot Server Name = EFI64. Then click 'Install New Boot Server'. This adds an entry to the list on top.

Click 'OK'. You now see an 'EFI64' subtree under the expanded 'Boot Server'. Right click on 'EFI64' and click 'Add client support'. Select Client Architecture = IA64PC and Client NIC Type = UNDI. Enter Boot File Base Name = Server. (As you type, a file name entry is generated in the list below. This means that PDK is taking the file from that dir location and so it must be there. It follows the format - .pdk\ system\ images\ <ArchType>\ <NICType>\ <BootServerName>\ <BaseFileName>.0) Click 'OK'.

The next step is to put files in the appropriate location on the server side. Creating the needed directory structure and putting files at the right place does this. If you have been following these instructions precisely then you need the following file at its absolute path given- ...pdk\system\images\IA64PC\UNDI\EFI64\Server.0. Server.0 is nothing but renamed Server.efi.

e. Start the PXE Services. Right click on Pxe server name and choose 'Start/Stop Services' from the menu. Click the 'Stop' button on the top, and then click 'OK'.

Before running the test, PXE support on the client side should be checked by booting the client machine. For the PXEBoot option to appear in the Bootmanager, follow these steps:

f. When the Bootmanager appears, choose "Boot Option Maintenance Menu"

g. Choose "Add Boot Option"

h. Choose "Removable Media [ACPI/ PCI/ MAC]"

i. Enter a Boot option name and Exit.

The next time system comes up, choose the PXE Boot option and the client should boot through the PXE Server executing the remote image (Server.0) ensuring that the client supports PXE Protocol.

3. Set the Base file directory at the server side. For this:

Run PXE PDK Config Utility. Click on the Boot Server , choose "Configure Boot Server" and in "General Options" look for an Edit box mentioned "Base directory for (M)TFTP files". Set it to a suitable directory in your system and copy the file Server.efi onto that directory.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-2.21 Boot Manager Variables Test

Overview

The BootOrder test verifies the functionality of the mandatory EFI NVRAM variable 'BootOrder'. To test this feature, this test creates a set of new Boot Load Options called Boot1000, Boot1001, Boot1002 and Boot1003. The test then alters the BootOrder variable to represent the boot sequence 1000-1001-1002-1003 and then resets the system. Upon reset, the applications corresponding to Boot1000 (bmsampleapp0.efi), Boot1001 (bmsampleapp1.efi), Boot1002 (bmsampleapp2.efi) and Boot1003 (bmsampleapp3.efi) are expected to be started in sequence with a set of predetermined 16-byte load options each. Each of these applications records in an NVRAM variable, three aspects of its startup from the EFI boot manager:

  1. That it is started automatically by the boot manager
  2. That it is in the sequence as implied by the BootOrder variable as set in the ‘BootOrder’ variable.
  3. That the optional data (load options) that it receives through its image handle match what has been set in its respective Boot100x (x = 1 to 4) variable.

After the test regains control (after the completion of the BootOrder sequence), the test checks the results from the above observations saved by the individual applications in the NVRAM. Assertion failures are generated.

  4. LoadOptionsRawData (defined in bmtest.h) contains an array of four executable sample applications: bmsampleapp0.efi, bmsampleapp1.efi, bmsampleapp2.efi, and bmsampleapp3.efi.
  5. Each of the four sample applications has a name tag (the first member for each element of the array), such as DIG64TEST_LoadOption_0x100x (x = 0 to 3). Associated with each sample application is a 16-byte value to be used as that application's option data, similar to command line options. The test calls GenerateLoadOptions() to create the load options, which consist of the option string, target application to run (bmsampleapp0.efi, etc.), and the 16-byte option data associated with that application.
  6. The test tries to create NV variables called Boot1000, Boot1001, Boot1002 and Boot1003. Before creating them, the test checks if variables with these names already exist in the NVRAM. It saves this information in the NVRAM using the SetVariable() service. If variables with those names exist, the test attempts to save them by creating new variables with a prefix prepended to their names so they are not overwritten. This is done in the SavePreExistingBootOptions() function, which uses the GetVariable() and SetVariable() services.
  7. The NV variables Boot1000, Boot1001, Boot1002 and Boot1003 are then saved into the NVRAM using the SetVariable service. The CheckForBootVariables() function verifies that the four variables (Boot1000, Boot1001, Boot1002 and Boot1003) are present in the NV RAM.
  8. The test indicates its preference of boot order for the sample applications by setting the BootOrder variable. Before doing this, it saves the existing boot order variable in an NVRAM variable called DIG64TEST_BootOrderSave to be restored when the test concludes. The new boot order is set in the SetNewBootOrder() function to "1000 1001 1002 1003" indicating the new boot sequence preference.
  9. The value of the BootOrder variable is retrieved using the GetVariable service and checked for consistency.
  10. In the CreateExecuteOrder() function, the test creates a variable called DIG64TEST_ExecuteOrder. The sample applications, when run, post their results in this variable.
  11. The DIG64TEST_ExecuteOrder variable consists of 10 bytes. Each test uses 2 bytes of data of this variable.
  12. Bytes 0 and 1 are used by all four of the sample applications. They are used as a counter for the number of applications that are run and are incremented by each application as it runs. bmsampleapp0 writes its results in bytes 2 and 3, bmsampleapp1 writes in bytes 4 and 5, bmsampleapp2 writes in bytes 6 and 7, and bmsampleapp3 writes in bytes 8 and 9. Exactly what is written to this variable is described later in this algorithm.
  13. At this point, the test invokes ResetSystem() to reboot the system.
  14. When the system reboots, the four sample applications are expected to run automatically in the order indicated by the BootOrder variable. This implies that bmsampleapp0 runs first, bmsampleapp1 runs second, bmsampleapp2 runs third and bmsampleapp3 runs fourth.
  15. Byte 0 and 1 of the DIG64TEST_ExecuteOrder variable contains a 0 to begin with. When a sample application starts, it does not know what order it is started in. It looks to bytes 0 and 1 of the DIG64TEST_ExecuteOrder variable variable to determine the order in which the application ran. Each application reads this value from bytes 0 and 1 and posts the same in the second byte of its allocated two bytes (for example, bytes 4 and 5 for bmsampleapp1).
  16. The first application to start sees a 0 in bytes 0 and 1, and writes that result to the second of its allocated two bytes. It then increments the 0 in bytes 0 and 1 to 1, so the next application to run knows it is the second application to run. If bmsampleapp0 is the first application to run, for example, it writes a 0 to byte 3, which is the second of its allocated two bytes, then increments the value in bytes 0 and 1 to 1.
  17. In addition, each sample application uses its image handle to look for all the load options it has received from the boot manager and verifies the option data it has received is what was expected. Each application knows the option data it should receive because this information is hard-coded into each of the sample applications.
  18. The variable DIG64TEST_ExecuteOrder initially contains ‘FF’ in bytes 2, 4, 6 and 8. Each application posts whether it received the correct load options using the first byte of its allocated two bytes (bmsampleapp0 posts this information to byte 2, bmsampleapp1 posts this information to byte 4, and so forth.). If a sample application received the correct options data, it posts a 1 to the first byte of its allocated two bytes.
  19. The test then writes the edited DIG64TEST_ExecuteOrder variable back into the NV RAM.
  20. The boot manager should then give control over to the next application to run what it sees in the boot order variable. After all the startup options specified in the BootOrder variable are run, BootOrderTest is resumed.
  21. The boot order test uses the CheckExecuteOrder() function to verify that the DIG64TEST_ExecuteOrder variable, which it gets using the GetVariable() function, contains the expected values. These are the results, the BootOrderTest expects for the DIG64TEST_ExecuteOrder variable:

Bytes 0 and 1: 00 04

Bytes 2 and 3: 01 00

Bytes 4 and 5: 01 01

Bytes 6 and 7: 01 02

Bytes 8 and 9: 01 03

  22. If the variable does not match the expected results, an assertion failure occurs. This could be because one of the sample applications did not run, ran in an incorrect order, or had received the wrong option data.
  23. The test concludes by deleting the boot option variables Boot1000, Boot1001, Boot1002, Boot1003 and restoring any boot option variables present with names Boot1000, Boot1001, Boot1002 and Boot1003 before the test ran. It also restores the BootOrder variable to its value prior to the beginning of the test. Also, the DIG64TEST_ExecuteOrder variable is deleted. Failure to either delete the new variable values and restore them to prior values generates assertion failures.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special set up is required.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


Chapter 3: Advanced Configuration and Power Interface Test Specification

This chapter describes platform hardware and BIOS tests for Advanced Configuration and Power Interface (ACPI) support.

The Advanced Configuration and Power Interface tests validate implementations of the hardware and BIOS functional requirements.

If there are conflicts between the hardware and software specifications, refer to Microsoft Windows Logo Program (WLP) System and Device Requirements for guidance.

This test design specification documents requirements and test cases covering requirements for mobile platforms. When this ACPI test is run on a target platform, mobile test cases are only run against mobile platforms. Similarly, multi-processor test cases are only run on a target platform supporting multiple processors.

This chapter also provides test coverage information to facilitate initial development and review cycle processes focusing on ACPI hardware and BIOS test coverage.

Absence of items that are recommended but not required by the specifications listed above does not cause failures. All items that are implemented on a platform must be complete and function correctly, whether required or only recommended.

Test Coverage

The assertions listed in this chapter are referenced to the document from which they are derived.

The following hardware and BIOS features are not addressed by this test specification.

  • Cross-device dependencies or back-to-back I/O requirements for all devices in the system are not verified.
  • Legacy (non-ACPI) mode Plug and Play 1.0a support test coverage is not covered by this document.
  • Legacy (non-ACPI) mode Advanced Power Management (APM) 1.2 support test coverage is not covered by this document.
  • This document does not describe power supply or backplane power routing power management tests.
  • Any bus that has an alternative configuration and power management specification supersedes the Advanced Configuration and Power Interface feature, which is provided to support power management for legacy motherboard devices. This document does not address ISA, Plug and Play, PCI, USB, and 1394 bus / device class configuration and power management test cases.
  • This document describes only functional, not performance related Advanced Configuration and Power Interface support requirements.
  • This document does not describe application, operating system, and/or driver ACPI tests.

Test Methodology

By utilizing platform BIOS supplied ACPI tables, these tests run on all IA-32 processor-based ACPI-enabled platforms. No tests are dependent on known PCI chipset implementations.

The test descriptions document the MS-DOS real-mode implementations of these tests.


ACPI Test Assertions

All ACPI test assertions are split into two major groups: ACPI Hardware assertions and ACPI BIOS assertions. Each assertion listed includes an assertion description, a list of reference documents, and a reference to the "Test Description" section that explains the test suite.

The tests implemented to test these assertions are described in the "Test Descriptions" section, which includes an overview of each test, set up requirements, and test results interpretation.


Reference Document Sources for ACPI Assertions

Hardware and BIOS functional requirements specified in the following documents:

  • Advanced Configuration and Power Interface Specification, Revision 2.0, 1.0, 1.0(a) and 1.0b; 2.0 ERRATA Revision 1.5
    http://www.acpi.info/

Errata for ACPI, Revision 1.0 and 1.0a, have been incorporated into Revision 1.0b

  • PC 2001 System Design Guide and PC 99 System Design Guide,
    http://www.microsoft.com/hwdev/platform/pcdesign/desguide/pcguides.asp
  • Microsoft Windows Logo Program System and Device Requirements, Version 2.0
    http://www.microsoft.com/hwdev/winlogo/
    (listed as "WLP#" in these assertions)


ACPI Hardware Assertions

The following sections describe the ACPI hardware assertions tested.

ACPI Minimum Hardware Assertions

The following assertions are the minimum hardware implementation features required to support ACPI.

These assertions are tested in:
TD-3.3 ACPI Processor Power State Transition (ACPIPPST) Test Description
TD-3.11 ACPI Pre-OS: Legacy to ACPI State Transition (ACPILAST) Test Description
TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT)
TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) Test Description
TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

Also, see "ACPI Assertions Not Tested" for a list of the register hardware assertions to implement ACPI that are not tested.

3.1.1 A power management timer must be supported.

Reference documents: WLP# - A1.1.2; A1.4.2; ACPI Specification, Revision 1.0a; Sections 1.7, 4.6 and 4.7.2.1; PC 2001 System Design Guide - SYS-0002; PC 99 System Design Guide - 3.2.1.
Test descriptions: TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.11 Legacy / ACPI State Transition (ACPILAST)

3.1.2 A power or sleep button must be supported

Reference documents: WLP# - A1.1.2; A1.4.2; ACPI Specification, Revision 1.0a; Sections 1.7, 4.6 and 4.7.2.2, PC 2001 System Design Guide - SYS-0002, and PC 99 System Design Guide - 3.2.1.
Test description: TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT)

3.1.3 A real-time clock wakeup alarm must be supported

Reference documents: WLP# - A1.1.2; A1.4.2; ACPI Specification, Revision 1.0a, Sections 1.7 and 4.6, PC 2001 System Design Guide - SYS-002, and PC 99 System Design Guide - 3.2.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.1.4 At least one S1-S3 system sleep state must be supported

Reference documents: WLP# - A1.1.2; A1.4.2; ACPI Specification, Revision 1.0a; Sections 1.7, 4.7.2.3 and 9.1; PC 2001 System Design Guide - SYS-0002.1, and the PC 99 System Design Guide - 3.2.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.1.5 The C1 processor power state must be supported.

Reference document: WLP# - A1.1.2; A1.4.2; ACPI Specification, Revision 1.0a, Sections 4.6, 4.7.2.6, 4.7.2.6.3, 5.2.5 and 8.2.2.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.1.6 Interrupt events generate System Control Interrupts (SCIs) (instead of SMI’s).

Reference documents: WLP# - A1.1.2; A1.4.2; ACPI Specification, Revision 1.0, Section 1.7, PC 2001 System Design Guide - SYS-0002, and PC 99 System Design Guide - 3.2.1.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT) and TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT)

3.1.7 A legacy / ACPI power management model status bit (SCI_EN) is required.

Reference document: WLP# - A1.1.2; A1.4.2; ACPI Specification, Revision 1.0, Section 4.6.
Test description: TD-3.11 Legacy / ACPI State Transition (ACPILAST)

3.1.8 The PM1a_EVT_BLK event register block and the PM1a_CNT_BLK control register block are required.

Reference document:WLP# - A1.1.2; A1.4.2; ACPI Specification, Revision 1.0, Sections 4.7.1.1 and 4.7.1.2.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT) and TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT)

3.1.9 A user accessible fail-safe mechanism to either unconditionally reset or turn off the machine is required.

Reference document: WLP# - A1.1.2; A1.4.2; ACPI Specification, Revision 1.0, Sections 1.7 and 4.6.
Test description: TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT)

3.1.10 The system must provide status and enable bits for the power management timer, power button, and real-time clock.

Reference document: WLP# - A1.1.2; A1.4.2; PC99 System Design Guide, 3.2.1.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description


ACPI Processor Hardware Assertions

These assertions are tested in:
TD-3.3 ACPI Processor Power State Transition (ACPIPPST) Test Description
TD-3.26 ACPI Pre-OS: ACPI Unique P_BLK Test

3.2.1 In the G1 sleeping state, the processors are not executing instructions.

Reference document: WLP# - A1.1.2; A1.4.2; ACPI Specification, Revision 1.0a, Sections 4.5, 8.2 and 9.1
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.2.2 Processors with built-in victim caches do not support the manual flush mechanism so they must support the WBINVD mechanism to use the S2 or S3 system sleep states.

Reference document: WLP# - A1.1.2; A1.4.2; ACPI Specification, Revision 1.0a, Section 9.2.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.2.3 In the C1 CPU power state, the processor maintains system cache context.

Reference document: WLP# - A1.1.2; A1.4.2; ACPI Specification, Revision 1.0a, Section 4.7.2.6.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.2.4 The C1 CPU power state assumes no chipset hardware support.

Reference document: WLP# - A1.1.2; A1.4.2; ACPI Specification, Revision 1.0a, Section 4.7.2.6.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.2.5 Processor power state support is symmetric; all processors in a system support the same clock states and clock logic.

Reference document: WLP# - A1.1.2; A1.4.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.6 and 4.7.2.6.3.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.2.6 In the C0 CPU power state, the processor executes instructions.

Reference document: WLP# - A1.1.2; A1.4.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.6, 4.7.2.6.4 and 8.2.1.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.2.7 The C1 CPU power state is a low power state in which the processor consumes less power and dissipates less heat than when in the C0 state.

Reference document: WLP# - A1.1.2; A1.4.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.6, 4.7.2.6.5 and 8.2.2.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.2.8 The C1 CPU power state is supported through a native processor instruction (for example, STI-HLT for current IA-32-PC processors).

Reference document: WLP# - A1.1.2; A1.4.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.6, 4.7.2.5.5 and 8.2.2.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.2.9 In the optional C2 CPU power state, the processor maintains system cache context.

Reference document: WLP# - A1.1.2; A1.4.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.6 and 4.7.2.6.6.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.2.10 The C2 CPU power state is equal to or lower power and dissipates less heat than the C1 power state.

Reference document: WLP# - A1.1.2; A1.4.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.6, 4.7.2.6.6, 8.2 and 8.2.3.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.2.11 In the C3 CPU power state, the processor does not necessarily maintain coherency of the processor caches with respect to other system activity.

The processor's caches maintain state but ignore any snoops.

Reference document: WLP# - A1.1.2; A1.4.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.6, 4.7.2.6.7 and 8.2.4.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.2.12 The C3 CPU power state is equal to or lower power and dissipates less heat than the C2 power state.

Reference document: WLP# - A1.1.2; A1.4.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.6, 8.2 and 8.2.4.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.2.13 The C3 CPU power state puts the designated processor and system into a power state where the processors cache context is maintained, but it is not required to snoop the bus master or multiprocessor CPU accesses to memory.

Reference document: WLP# - A1.1.2; A1.4.2; ACPI Specification, Revision 1.0a, Section 4.7.2.6.2.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.2.14 To support the C3 CPU power state without using the ARB_DIS feature, the hardware must provide functionality to flush and invalidate the processors' caches (WBINVD instruction on IA processors).

Reference document: WLP# - A1.1.2; A1.4.2; ACPI Specification, Revision 1.0a, Section 4.7.2.6.2.1.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.2.15 All platforms must support the local CPU instruction for flushing system caches, with support in both the CPU and chipset.

Reference document: WLP# - A1.1.2; A1.4.2; ACPI Specification, Revision 1.0a, Section 4.7.2.6.2.1.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.2.16 To support the S2 or S3 sleeping states, the hardware must provide functionality to flush the platform caches.

Reference document: WLP# -A1.1.2; A1.4.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.6.2.1 and 9.2.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.2.17 If the platform supports neither of the WBINVD/WBINVD_FLUSH options, flushing caches can be achieved by a cache-enabled sequential read of contiguous physical memory of not more than 2 MBytes.

Reference document: WLP# - A1.1.2; A1.4.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.6.2.1 and 9.2.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.2.18 In the C0 CPU power state, the CPU's clock is running at full frequency or is running at a reduced performance.

Reference document: WLP# - A1.1.2; A1.4.2; ACPI Specification, Revision 1.0a, Section 4.7.2.6.4.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.2.19 Aside from putting the processor in a power state, the C1 processor power state has no other software-visible effects.

Reference document: WLP# - A1.1.2; A1.4.2; ACPI Specification, Revision 1.0a, Section 8.2.2.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.2.20 Aside from putting the processor in a power state, the C2 processor power state has no other software-visible effects.

Reference document: WLP# - A1.1.2; A1.4.2; ACPI Specification, Revision 1.0a, Section 8.2.3.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.2.21 Hardware must always exit the C1, C2 and C3 power states whenever an interrupt is to be presented to the processor.

Reference document: WLP# - A1.1.2; A1.4.2; ACPI Specification, Revision 1.0, Sections 8.2.2, 8.2.3 and 8.2.4.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.2.22 Multi-processor systems implement multi-processor configuration support with a unique P_BLK register for each CPU in the system and with APIC tables as defined in ACPI 1.0b, Section 5.2.8.

Reference document: WLP# - A1.1.5; ACPI Specification, Revision 1.0b, Sections 4.7.2.6.3 and 5.2.8; PC 2001 System Design Guide - A1.1.5
Test Description: TD-3.26 ACPI Pre-OS: ACPI Unique P_BLK Test


ACPI Device Hardware Assertions

The following device hardware assertions implement ACPI.

These assertions are tested in TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT) Test Description.

3.3.1 Hardware must maintain individual device wake enable bits.

Reference document: WLP# - B1.4.5; ACPI Specification, Revision 1.0a, Sections 5.6.2.2.4 and 7.3.7.
Test description: TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT)

3.3.2 A device in the D3 device power state must no longer be using its resources (I/O ports, memory space, etc.).

Reference document: WLP# - B1.4.5; ACPI Specification, Revision 1.0a, Sections 5.6.2.2.4 and 7.3.7.
Test description: TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT)


ACPI Embedded Controller, SMBus, Docking and Undocking Hardware Assertion

The following embedded controller, SMBus, docking, and undocking hardware assertion implements ACPI. This assertion is tested in TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK) Test Description.

3.4.1 In ACPI mode, when the computer is docked, the core logic must set the status bit and assert a GPE (SCI).

Reference document: WLP# - A1.1.2; A1.4.2; ACPI Specification, Revision 1.0b, Sections 3.7 and 4.5.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)


ACPI Embedded Controller, SMBus, Battery and AC Adapter Hardware Assertions

The following embedded controller, SMBus, battery, and AC adapter hardware assertions implement ACPI.

These assertions are tested in TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description and TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB) Test Description.

3.5.1 The smart battery selector provides event notification (battery insertion/removal, and so forth.) and charger SMBus routing capability for any smart battery subsystem.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0a, Section 11.1.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.5.2 A smart battery selector provides event notification for battery insertion and removal.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 11.1.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.5.3 A smart battery selector provides event notification for AC power connected or disconnected.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 11.1.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.5.4 A smart battery selector provides status/control of which battery is communicating with the SMBus host controller.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 11.1.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.5.5 A smart battery selector provides status/control of which battery is powering the system.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 11.1.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.5.6 A smart battery selector provides status/control of which battery is connected to the charger

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 11.1.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.5.7 A smart battery selector provides status of which batteries are present in the system.

Reference document: WLP# - A3.4.11; ACPI Specification, Revision 1.0b, Section 11.1.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.5.8 A smart battery selector provides event notification when the selector switches from one power source to another.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 11.1.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.5.9 A smart battery selector provides hardware switching to AC.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 11.1.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.5.10 The smart battery system charger notifies the system of the battery and AC status in a single battery system.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 11.1.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.5.11 When the smart battery selector function is present in the smart charger, battery and AC status changes should be reported through the SelectorState() notify and not the ChargerStatus() notify.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 11.1.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.5.12 The hardware generates a general-purpose event when a control method battery device is inserted or removed.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 11.2.1.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.5.13 The hardware generates a general-purpose event (SCI) when a control method battery device has changed present state (Battery State _BST field value changes).

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 11.2.2.2.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.5.14 Hardware generates a general-purpose event (SCI) when a control method battery device Battery Remaining Capacity (_BST field) crosses a trip point set by the _BTP control method.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b. Sections 11.2.1, 11.2.2.2, and 11.2.2.3.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.5.15 Any changes in control method battery status should generate an SCI system control interrupt

This must happen in a timely manner to keep the system power state user interface consistent with the actual state of the system battery or batteries.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 11.2.1.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.5.16 An ACPI compatible smart battery subsystem consists of a SMBus host controller interface, at least one smart battery, a smart battery charger, and if more than one smart battery is supported, a smart battery selector.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Sections 11.1 and 13.7.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.5.17 All batteries in the system have the same SMBus address.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Sections 11.1 and 13.7.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.5.18 A smart battery selector provides hardware switching to a secondary battery upon the primary battery running low.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Sections 11.1 and 13.7.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.5.19 The smart battery system charger is a SMBus device that provides a standard programming model to control the charging of smart batteries present in a smart battery subsystem.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Sections 11.1 and 13.7.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.5.20 A battery or AC status change activates the SMBus Alarm Notify.

The SMBus Alarm Notify generates an SMBus host controller event after SelectorState() command register contents are placed in SMBus host slave data port and a messaging device slave address is placed in SMBus host slave command port.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Sections 11.1.1 and 11.1.2.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.5.21 A Power Source Status Changed notification is issued when the power source status has changed.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 5.6.3, Table 5-27.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.5.22 A control method battery's _STA method returns bit 4: Set if the battery is present.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Sections 5.6.4, 6.3.5, 11.2.2, and Figure 11.4.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)


ACPI Embedded Controller, SMBus, Thermal Management and Lid Assertions

The following embedded controller, SMBus, thermal management assertions implement ACPI. These assertions are tested by the ACPI Thermal Management test (ACPITHRM). The following ACPI lid switch hardware assertions are tested by the ACPILID test.

3.6.1 In ACPI mode, hardware generates a thermal event notification with the SCI system control interrupt.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.5 and 12.1.3.
Test description: TD-3.19 ACPI Thermal Management (ACPITHRM) Test Description

3.6.2 The system must disable the power either after the temperature reaches some hardware-determined level above _CRT critical temperature, if critical temperature trip point is supported, or after a predetermined time has passed.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 12.1.6.
Test description: TD-3.19 ACPI Thermal Management (ACPITHRM) Test Description

3.6.3 When the system is in ACPI mode, LID open/close external events generate SCI events and not SMIs.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 4.5.
Test description: TD-3.12 ACPI Pre-OS: ACPI Lid Switch (ACPILID) Test Description


ACPI Mode Switching and SCI Hardware Assertions

The following legacy (non-ACPI) / ACPI mode switching and system control interrupt hardware assertions implement ACPI.

These assertions are tested in TD-3.11 ACPI Pre-OS: Legacy to ACPI State Transition (ACPILAST) Test Description

3.7.1 The minimum requirements for an ACPI-compatible system include implementation of interrupt events generating System Control Interrupts (SCIs).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 1.7.
Test description: TD-3.11 Legacy / ACPI State Transition (ACPILAST)

3.7.2 In the legacy state, the ACPI event model is disabled (no SCIs System Control Interrupts are generated).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.5.
Test description: TD-3.11 Legacy / ACPI State Transition (ACPILAST)

3.7.3 For ACPI systems, interrupt events need to generate an operating system-visible interrupt that is shareable, level-sensitive, active low; edge-style interrupts do not work as specified in Sections 4.5, 4.7.2.5, 5.2.5 and 5.6.1.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.5, 4.7.2.5, 5.2.5 and 5.6.1.
Test description: TD-3.11 Legacy / ACPI State Transition (ACPILAST)

3.7.4 When the system is placed into ACPI mode, power management events generate SCI events and not SMIs.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.5.
Test description: TD-3.11 Legacy / ACPI State Transition (ACPILAST)

3.7.5 An ACPI-only platform (does not support legacy power management mode) directly boots into the G0 working state by always returning status bit SCI_EN HIGH and ignores SCI_EN writes.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.5 and 4.7.2.5.
Test description: TD-3.11 Legacy / ACPI State Transition (ACPILAST)

3.7.6 If the platform supports both legacy and ACPI operations, it always boots into the legacy state (for example, by returning SCI_EN LOW).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.5.
Test description: TD-3.11 Legacy / ACPI State Transition (ACPILAST)

3.7.7 The legacy system state can be entered from either the G3 "mechanical off," the G2 "soft off," or the G0 "working" states only if the hardware supports both legacy and ACPI modes.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.5.
Test description: TD-3.11 Legacy / ACPI State Transition (ACPILAST)

3.7.8 When exiting G2 soft off state, an ACPI-only machine re-enters the G0 working state directly (hardware returns SCI_EN bit HIGH).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.5.
Test description: TD-3.11 Legacy / ACPI State Transition (ACPILAST)

3.7.9 When exiting the G2 soft off state, an ACPI/legacy machine transitions to the legacy state (hardware returns the SCI_EN bit LOW).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.5.
Test description: TD-3.11 Legacy / ACPI State Transition (ACPILAST)

3.7.10 All ACPI implementations are required to support system I/O space.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.
Test description: TD-3.11 Legacy / ACPI State Transition (ACPILAST)

3.7.11 PM1a_EVT_BLK and, if implemented, PM1b_EVT_BLK register blocks contain a status register (PM1a_STS and PM1b_STS, respectively) and an enable register (PM1a_EN and PM1b_EN, respectively).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.
Test description: TD-3.11 Legacy / ACPI State Transition (ACPILAST)

3.7.12 PM1a_CNT_BLK and, if implemented, PM1b_CNT_BLK register blocks contain a single fixed feature control register (PM1a_CNT and PM1b_CNT, respectively).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.
Test description: TD-3.11 Legacy / ACPI State Transition (ACPILAST)

3.7.13 The general-purpose event register space is contained in the GPE0_BLK and/or the GPE1_BLK register blocks.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.
Test description: TD-3.11 Legacy / ACPI State Transition (ACPILAST)

3.7.14 Each GPEx_BLK register block has a GPEx_STS status register and a GPEx_EN enable register.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.
Test description: TD-3.11 Legacy / ACPI State Transition (ACPILAST)

3.7.15 The status and enable registers in the general-purpose event register follows the event model for the fixed-event registers.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.5.
Test description: TD-3.11 Legacy / ACPI State Transition (ACPILAST)

3.7.16 While in the legacy state, writing ACPI_ENABLE to the SMI_CMD register generates an event to the hardware to transition the platform to its ACPI mode (G0 working state).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.5, 4.7.2.5 and 9.3.1.
Test description: TD-3.11 Legacy / ACPI State Transition (ACPILAST)

3.7.17 When the hardware has finished transitioning to its ACPI mode, it sets SCI_EN bit HIGH and returns control back to the operating system.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.5 and 9.3.1.
Test description: TD-3.11 Legacy / ACPI State Transition (ACPILAST)

3.7.18 While in the ACPI G0 working state, writing ACPI_DISABLE to the SMI_CMD register results in the hardware transitioning into legacy mode and resetting the SCI_EN bit LOW.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.5, 4.7.2.5 and 9.3.4.
Test description: TD-3.11 Legacy / ACPI State Transition (ACPILAST)

3.7.19 The PM1a_EVT_BLK event register block and the PM1a_CNT_BLK control register block are required register blocks that must be supported.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.1.1 and 4.7.1.2.
Test description: TD-3.11 Legacy / ACPI State Transition (ACPILAST)

3.7.20 If PM1 event grouping is split between two register blocks, the bit positions are maintained between the registers.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.1.
Test description: TD-3.11 Legacy / ACPI State Transition (ACPILAST)

3.7.21 If PM1 event grouping is split between two register blocks, the register block with unimplemented bits (those implemented in the other register block) always return zeros, and writes have no side effects.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.1.
Test description: TD-3.11 Legacy / ACPI State Transition (ACPILAST)

3.7.22 No SCI system control interrupt can occur immediately after ACPI is on.

The SCI interrupt can only fire once one of the GPE/PM1 enable bits has been enabled.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 9.3.1.
Test description: TD-3.11 Legacy / ACPI State Transition (ACPILAST)


ACPI Power Button and Sleep Button Hardware Assertions

The following power button and sleep button hardware assertions implement ACPI.

These assertions are tested in TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT) Test Description.

3.8.1 User presses of the ACPI power button generates an event (to the power button driver).

Reference document: WLP# - A1.1.2, B5.1.4.1; ACPI Specification, Revision 1.0a, Section 4.5.
Test description: TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT)

3.8.2 Control of the power button events follow either the fixed or the generic (control method based) programming model.

Reference document: WLP# - A1.1.2, B5.1.4.1; ACPI Specification, Revision 1.0a, Section 4.7.2.2.
Test description: TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT)

3.8.3 If the power button is pressed for more than four seconds while system is in working state, a hardware power button override event is generated, hardware clears the PWRBTN_STS power button status bit, and the system unconditionally transitions to G2/S5 soft off state.

Reference document: WLP# - A1.1.2, B5.1.4.1; ACPI Specification, Revision 1.0a, Sections 4.7.2.2.1, 4.7.2.2.1.3, 4.7.2.3 and 4.7.3.1.1.
Test description: TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT)

3.8.4 If a fixed power button model is implemented, the fixed power button has its event programming model in PM1x_EVT_BLK register block, consisting of a single enable bit and a sticky status bit.

Reference document: WLP# - A1.1.2, B5.1.4.1; ACPI Specification, Revision 1.0a, Section 4.7.2.2.1.1.
Test description: TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT)

3.8.5 The power button logic provides debounce logic that sets the PWRBTN_STS power button status bit on the button press "edge."

Reference document: WLP# - A1.1.2, B5.1.4.1; ACPI Specification, Revision 1.0a, Section 4.7.2.2.1.1.
Test description: TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT)

3.8.6 If the fixed power button model is implemented, PWRBTN_STS power button status bit (bit 8) is unconditionally set when power button is pressed.

Reference document: WLP# - A1.1.2, B5.1.4.1; ACPI Specification, Revision 1.0a, Sections 4.7.2.2.1.1, 4.7.3.1.1 and 4.7.3.1.2.
Test description: TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT)

3.8.7 If the PWRBTN_EN power button enable bit is set and the PWRBTN_STS power button status bit is set due to a button press while the system is in the G0 state, an SCI System Control Interrupt is generated.

Reference document: WLP# - A1.1.2, B5.1.4.1; ACPI Specification, Revision 1.0a, Section 4.7.2.2.1.1, 4.7.3.1.1 and 4.7.3.1.2.
Test description: TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT)

3.8.8 If the fixed sleep button model is implemented, the fixed sleep button has its event programming model in the PM1x_EVT_BLK register block, consisting of a single enable bit and a sticky status bit.

Reference document: WLP# - A1.1.2, B5.1.4.1; ACPI Specification, Revision 1.0a, Section 4.7.2.2.1.1.
Test description: TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT)

3.8.9 The sleep button logic provides debounce logic that sets the SLPBTN_STS sleep button status bit on the button press "edge".

Reference document: WLP# - A1.1.2, B5.1.4.1; ACPI Specification, Revision 1.0a, Sections 4.7.2.2.1.1, 4.7.3.1.1 and 4.7.3.1.2.
Test description: TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT)

3.8.10 If fixed sleep button model is implemented, SLPBTN_STS sleep button status bit (bit 9) is unconditionally set when sleep button is pressed.

Reference document: WLP# - A1.1.2, B5.1.4.1; ACPI Specification, Revision 1.0a, Sections 4.7.2.2.1.1, 4.7.3.1.1 and 4.7.3.1.2.
Test description: TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT)

3.8.11 If the SLPBTN_EN sleep button enable bit is set and the SLPBTN_STS sleep button status bit is set, due to a button press while the system is in the G0 state, an SCI System Control Interrupt is generated.

Reference document: WLP# - A1.1.2, B5.1.4.1; ACPI Specification, Revision 1.0a, Sections 4.7.2.2.2.1, 4.7.3.1.1 and 4.7.3.1.2.
Test description: TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT)

3.8.12 The PM1x_STS register PWRBTN_STS power button status bit (bit 8) is set only by hardware and can be reset only by software writing a one to this bit position.

Reference document: WLP# - A1.1.2, B5.1.4.1; ACPI Specification, Revision 1.0a, Section 4.7.3.1.1.
Test description: TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT)

3.8.13 If the power button was the cause of the wakeup from an S1-S3 state, the PM1x_STS register PWRBTN_STS power button status bit is set prior to returning control to the operating system.

Reference document: WLP# - A1.1.2, B5.1.4.1; ACPI Specification, Revision 1.0a, Section 4.7.3.1.1.
Test description: TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT)

3.8.14 The PM1x_STS register SLPBTN_STS sleep button status bit (bit 9) is only set by hardware and can only be reset by software writing a one to this bit position.

Reference document: WLP# - A1.1.2, B5.1.4.1; ACPI Specification, Revision 1.0a, Section 4.7.3.1.1.
Test description: TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT)


ACPI Power Management Timer Hardware Assertions

The following power management timer (PMT) hardware assertions implement ACPI.

These assertions are tested in TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) Test Description.

3.9.1 The power management timer can be accessed through the PM_TMR_BLK register block PM_TMR register.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.1.4 and 4.7.2.1.
Test description: TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT)

3.9.2 The power management timer is contained in fixed register space to increase the accuracy of reading the timer.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.2.1.
Test description: TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT)

3.9.3 The power management timer-programming model can be partitioned in up to three different register blocks.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.2.1.
Test description: TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT)

3.9.4 The power management timer event bits are contained in the PM1_EVT register grouping (PM1a_EVT_BLK and PM1b_EVT_BLK).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.2.1.
Test description: TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT)

3.9.5 The power management timer consists of event logic (event status and event enable) and a read port to the counter value.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.2.1.
Test description: TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT)

3.9.6 If the power management timer PM1x_EN register TMR_EN timer carry interrupt enable bit (bit 0) is set, setting TMR_STS generates an ACPI event in the PM1_EVT register grouping (causing an SCI).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.1, 4.7.3.1.1 and 4.7.3.1.2.
Test description: TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT)

3.9.7 The PM1x_STS power management timer status register TMR_STS timer carry status bit (bit 0) is set any time the last (most significant) bit of the timer (bit 23/31 of a 24/32-bit counter) changes from HIGH to LOW or LOW to HIGH.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.1, 4.7.3.1.1 and 4.7.3.3.
Test description: TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT)

3.9.8 The power management timer is either a 24-bit or a 32-bit fixed rate free running count-up timer that runs off a 3.579545 MHz clock to provide an accurate time value while in the G0/S0 working state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.1 and 4.7.3.3.
Test description: TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT)

3.9.9 The power management PM_TMR register TMR_VAL field is read-only and contains the current value of the power management timer.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.1 and 4.7.3.3.
Test description: TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT)

3.9.10 Power management timer on PC system does not need to reset to an initial value of 0; and the timer immediately begins counting (functioning) from the place/value at which it stopped when the system transitions into the G0/S0 working state.

This applies to PC systems only.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.1 and 4.7.3.3.
Test description: TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT)

3.9.11 If the PM1x_EN register TMR_EN timer carry interrupt enable bit (bit 0) is reset, no SCI system control interrupt event is generated when the TMR_STS bit is set.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.1.2.
Test description: TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT)

3.9.12 The PM_TMR power management (PM) timer register is accessed as 32-bits.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.3.
Test description: TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT)

3.9.13 The PM timer is reset to any initial value and continues counting until the system's 14.31818 MHz clock is stopped upon entering its Sx system power state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.3.
Test description: TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT)

3.9.14 If the system's 14.31818 MHz clock is restarted without a reset, the PM timer counter continues counting from where it stopped.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.3.
Test description: TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT)

3.9.15 If the hardware only supports a 24-bit PM timer, the PM_TMR PM timer register read-only E_TMR_VAL field returns zero.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.3.
Test description: TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT)


ACPI Power State Transition Hardware Assertions

The following power state transition support hardware assertions implement ACPI.

These assertions are tested in TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description.

3.10.1 System enters the specified sleeping state when PM1x_CNT register SLP_TYPx field is programmed with the desired sleeping state and SLP_EN is HIGH/set.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.5, 4.7.2.3 and 4.7.3.2.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.2 In Global System State G3, power consumption is very close to zero.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.5 and 4.7.2.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.3 While in a sleeping state, an enabled wakeup event occurrence transitions the system to the working state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.5 and 4.7.2.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.4 The system enters G2 soft off state when SLP_TYPx field is programmed with S5 soft off system state and SLP_ENx is HIGH.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.5 and 4.7.2.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.5 If the single power button model is implemented, the power button generates events for both sleeping and entering soft off state.

Reference document: WLP# - A1.1.2, B5.1.4.1; ACPI Specification, Revision 1.0a, Sections 4.5 and 4.7.2.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.6 If the dual power button model is implemented, the power button generates a waking or soft off transition request and the sleeping button generates a sleeping transition request.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.5 and 4.7.2.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.7 While the system is in G1 or G2 states (S1, S2, S3, S4, or S5), any power button press after button press that transitioned the system into the sleeping state unconditionally sets PWRBTN_STS bit and awakens the system, regardless of PWRBTN_EN bit value.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.2.1.1, 4.7.3.1.1 and 9.1.5.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.8 If control method power button model (generic programming model) is implemented, the power button bit can reside in any of the generic address spaces.

Reference document: WLP# - A1.1.2, B5.1.4.1; ACPI Specification, Revision 1.0a, Section 4.7.2.2.1.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.9 While the system is in either the S1, S2, S3, or S4 state and after the button press that caused the system to transition to the sleeping state any sleep button press sets SLPBTN_STS bit and awakens the system (wakeup event), if the SLPBTN_EN bit is set.

Reference document: WLP# - A1.1.2, B5.1.4.1; ACPI Specification, Revision 1.0a, Sections 4.7.2.2.2.1 and 4.7.3.1.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.10 If the control method sleep button model (generic programming model) is implemented, the sleep button bit can reside in any of the generic address spaces.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.2.2.2.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.11 Upon assertion of SLP_EN sleep enable, hardware sequences the system into the sleeping state specified in SLP_TYPx sleep type.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.2.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.12 When the hardware is in an S1-S5 sleep state, it can use any motors or other devices to eject the device.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.13 If the system was in a sleep state during an ejection request, hardware wakes the computer to an S0 state immediately after ejection request.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.3, sequence of events for dynamically removing a device, step 7.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.14 While in the G1 sleeping state, hardware devices are not operating, except to generate a wakeup event.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 9.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.15 While in the G1 sleeping state, wakeup event bits are enabled in the corresponding fixed or general-purpose registers according to enabled wakeup options.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 9.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.16 If the system does not support the S1 sleeping state, the WAK_STS wake status bit can always return zero.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.2.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.17 When the hardware has sequenced the system into any G1 sleeping state, any enabled wakeup event is allowed to set the WAK_STS wake status bit and sequence the system back on to the G0 working state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.2.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.18 The PM1x_STS power management 1 status registers are accessed through byte or word accesses.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.1.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.19 The PM1x_STS power management 1 status register reserved bits 6-7 and 12-14 always return a value of zero.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.1.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.20 The PM1x_STS register WAK_STS wake status bit 15 is set when an enabled wakeup event occurs while system is in a sleeping state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.1.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.21 The PM1x_STS register WAK_STS wake status bit 15 is only set by hardware and can only be reset by software writing a one to this bit position.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.3.1.1 and 9.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.22 Upon setting the PM1x_STS register, WAK_STS wake status bit 15, the system transitions to the working state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.1.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.23 The PM1_EVT register grouping must start on a 32-bit aligned address that is pointed to by PM1a_EVT_BLK or PM1b_EVT_BLK.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.1.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.24 Access to the PM1x_EN enable registers is done through byte or word accesses.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.1.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.25 PM1X_EN power management 1 enable always returns a value of zero for the register reserved bits 1-4 and 14-15.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.1.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.26 The PM1x_EN register GBL_EN enable bit 5, if set, enables an SCI system control interrupt event to be generated any time that the GBL_STS bit is set.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.1.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.27 If PM1 control grouping is split between two register blocks, the bit position is maintained between the registers.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.28 If PM1 control grouping is split between two register blocks, the register block with unimplemented bits (those implemented in the other register block) always return zeros, and writes have no side effects.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.29 The PM1_CNT register grouping must start on a 32-bit aligned address that is pointed to by PM1a_CNT_BLK or PM1b_EVT_BLK.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.3.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.30 Access to the PM1x_CNT power management 1 control registers is done through byte or word accesses.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.2.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.31 The PM1x_CNT register SCI_EN bit 0 routes the power management event to either an SCI (set) or SMI (reset).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.2.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.32 The hardware must set or reset the PM1x_CNT register SCI_EN bit.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.2.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.33 Reads from the PM1x_CNT register SLP_EN write-only bit 13 always returns zero.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.2.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.34 The PM2_CNT power management 2 control register block is naturally aligned and is accessed based on its length.

For ACPI 1.0, this register is byte-aligned and accessed as a byte.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.4.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.35 General-purpose register block registers are not required to maintain context across sleeping or soft off states.

Only those events with enable bits that are set on entering sleeping or soft off states may wake the system.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.4.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.36 Each available GPE0_STS general-purpose event 0 status register status bit can optionally wake the system if asserted when the system is in a sleeping state with its respective enable bit set.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.4.1.1.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.37 Each available GPE1_STS general-purpose event 1 status register status bit can optionally wake the system if asserted when the system is in a sleeping state with its respective enable bit set.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.4.1.2.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.38 Events that wake the system are not intermixed with events that do not wake the system on the same GPE input.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.6.2.2.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.39 All wake events not exclusively tied to a GPE input need to have individual enable and status bits in order to properly handle the semantics used by the system.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.6.2.2.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.40 If the system is in a sleeping state when the enabled GPE bit is asserted, hardware transitions the system into the S0 state, if possible.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.6.2.2.4.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.41 To enter any system sleep state, PM1a_CNT.SLP_TYP register must be written before PM1b_CNT.SLP_TYP register is written.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.5.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.42 In the S0 working system state, the processors are in the C0, C1, C2, or C3 states, the processor complex context is maintained, and instructions are executed as defined by any of these Cx processor states.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.5.2.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.43 In the S0 working system state, dynamic RAM context is maintained and is read/write by the processors.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 7.5.2.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.44 In the S0 working system state, power resources are in a state compatible with the current device states.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.5.2.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.45 In the S1 system sleep state, power resources are in a state compatible with the system S1 state.

All power resources that supply a system level reference of S0 are in the OFF state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.5.2.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.46 In S1 system state, device states are compatible with the current power resource states.

Only devices that solely reference power resources and are in an ON state for a given device state can be in that device state. Other devices are in a D3 OFF state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.5.2.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.47 In the S1 system sleep state, devices that are enabled to wake the system and that can do so from their current device state can initiate a hardware event which transitions the system state to S0, causing the processor to continue execution where it left off.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.5.2.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.48 In the S1 system sleep state, the processors are not executing instructions, and the processor complex context (MSR, MTRR and cache) is maintained.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 7.5.2.2 and 9.1.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.49 In the S1 system sleep state, the dynamic RAM context is maintained.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 7.5.2.2 and 9.1.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.50 In the S2 system sleep state, power resources are in a state compatible with the system S2 state.

All power resources that supply a system level reference of S0 or S1 are in the OFF state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.51 In the S2 system state, device states are compatible with the current power resource states.

Only devices that solely reference power resources and that are in an ON state for a given device state can be in that device state. Other devices are in D3 OFF state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.5.2.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.52 In the S2 system sleep state, processors are not executing instructions, and processor complex context (MSR, MTRR and cache) is not maintained.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 7.5.2.3 and 9.1.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.53 In the S2 system sleep state, dynamic RAM context is maintained.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 7.5.2.3 and 9.1.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.54 In the S2 system sleep state, devices that are enabled to wake the system, and can do so from their current device state, can initiate a hardware event which transitions the system state to S0, causing the processor to continue execution at its boot location.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 7.5.2.3 and 9.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.55 In the S3 system sleep state, power resources are in a state compatible with the system S3 state.

All power resources that supply a system level reference of S0, S1, or S2 are in the OFF state.

Reference document: WLP# - A1.1.2, B1.4.5; ACPI Specification, Revision 1.0a, Section 7.5.2.4.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.56 In the S3 system state, device states are compatible with the current power resource states.

Only devices which solely reference power resources, which are in ON state for a given device state can be in that device state. Other devices are in D3 OFF state.

Reference document: WLP# - A1.1.2, B1.4.5; ACPI Specification, Revision 1.0a, Section 7.5.2.4.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.57 In the S3 system sleep state, the processors are not executing instructions, and the processor complex context (MSR, MTRR, and cache) is not maintained.

Reference document: WLP# - A1.1.2, B1.4.5; ACPI Specification, Revision 1.0a, Sections 7.5.2.4 and 9.1.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.58 In the S3 system sleep state, dynamic RAM context is maintained.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 7.5.2.4 and 9.1.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.59 In the S3 system sleep state, devices that are enabled to wake the system and can do so from their current device state can initiate a hardware event which transitions the system state to S0, causing the processor to continue execution at its boot location.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 7.5.2.4 and 9.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.60 In the S4 system sleep state, the processors are not executing instructions, and the processor complex context is not maintained.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.5.2.5.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.61 In the S4 system sleep state, dynamic RAM context is not maintained.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.5.2.5.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.62 In the S4 system sleep state, power resources are in a state compatible with the system S4 state.

All power resources that supply a system level reference of S0, S1, S2, or S3 are in the OFF state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.5.2.5.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.63 In the S4 system state, device states are compatible with the current power resource states and all the devices are in D3 OFF state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 7.5.2.5 and 9.1.4.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.64 In the S4 system sleep state, devices that are enabled to wake the system and can do so from their current device state can initiate a hardware event which transitions the system state to S0, causing the processor to continue execution at its boot location.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 7.5.2.5 and 9.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.65 In the S1 system sleep state, all chipset I/O context is maintained by hardware.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 9.1.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.66 After a wakeup event from the S2 system sleep state, software control starts from the processor's reset vector.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 9.1.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.67 In the S2 system sleep state, chipset and memory context is maintained by hardware.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 9.1.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.68 After a wakeup event from the S3 system sleep state, software control starts from the processor's reset vector.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 9.1.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.69 In the S3 system sleep state, chipset and memory context is maintained by hardware.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 9.1.3.
Test description: Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.70 In the S5 soft off system state, no context (memory, I/O) is saved by the hardware.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a. Section 9.1.5.
Test description: Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.71 When a S5 soft off system state transition is initiated, the hardware sequences the system to a state similar to the off state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 9.1.5.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.10.72 During transitions between the working and sleeping state, the context of the user’s operating environment is maintained.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 9.
Test description: "SUSPENDER"

3.10.73 When a machine is in a G1 (S1 – S4) power state, a press of the power button shall unconditionally set the power button status bit and awaken the system from the power state that it is in to the G0 (S0) power state.

Reference document: WLP# - A1.1.2, B5.1.4.1; ACPI Specification revision 1.0b section 4.7.2.2.1.1,
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description


ACPI Resource Configuration Hardware Assertions

The following resource configuration hardware assertions implement ACPI.

These assertions are tested in TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description and TD-3.29 Docking Test Description.

3.11.1 This assertion is made obsolete by assertion 3.10.13.
3.11.2 The hardware generates an SCI system control interrupt general-purpose event if a device is dynamically inserted while the computer is in the working state (hot insertion).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.3.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.11.3 When an eject button is pressed, the hardware generates an SCI system control interrupt general-purpose event.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.3.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.11.4 The hardware generates a general-purpose event in response to a surprise-style removal request.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.3.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.11.5 When a device is disabled, it must not be decoding any hardware resources.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.2.2.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.11.6 Low-true, level-sensitive interrupts may be electrically shared.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 6.4.2.1 and 6.4.3.6.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.11.7 System implements "Device Check" and "Eject Request" notify values as defined in ACPI 1.0b, Section 5.6.3, Table 5-21.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 5.6.3, Table 5-21.
Test Description: TD-3.29 Docking Test


ACPI Ejectable Media Hardware Assertions

The following ejectable media hardware assertions implement ACPI.

These assertions are tested in TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking (ACPIDOCK) Test Description

3.12.1 The device must be immediately ejected when the _EJ0 control method is called.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.3.2.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.12.2 For warm removal, the hardware ejects the device only after the system has entered sleep state by writing to SLP_EN register.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.3.2.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)


ACPI Register Implementation Hardware Assertions

The following register hardware assertions implement ACPI.

These assertions are tested in TD-3.3 ACPI Processor Power State Transition (ACPIPPST) Test Description and TD-3.26 ACPI Pre-OS: ACPI Unique P_BLK Test Description

3.13.1 If the P_BLK processor control block is implemented for any system processor, it must be implemented for every system processor.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.1.5, 4.7.2.6.3 and 4.7.3.5.
Test description: TD-3.26 ACPI Pre-OS: ACPI Unique P_BLK Test

3.13.2 If implemented, the P_BLK processor control block register contains the P_CNT, P_LVL2, and the P_LVL3 registers.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.1.5 and 4.7.2.6.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.13.3 If implemented, the C2 CPU power state is supported through chipset hardware: reads of the P_LVL2 register cause the hardware (clock control logic) to enter the C2 CPU power state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.1.5, 4.7.2.6, 4.7.2.6.6, 4.7.3.5.2 and 8.2.3.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.13.4 If implemented, the C3 CPU power state is supported through chipset hardware: reads of the P_LVL3 register cause the hardware (clock control logic) to enter the C3 CPU power state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.1.5, 4.7.2.6, 4.7.2.6.7, 4.7.3.5.3 and 8.2.4.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.13.5 Additional support for the C3 CPU power state is provided through the BM_STS (in PM1_STS) bus master status and ARB_DIS (in PM2_CNT) arbiter disable bits.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.2.6.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.13.6 Hardware is required to put the processor into the proper clock state precisely on the read operation to the appropriate P_LVLx register.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.2.6.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.13.7 The hardware must always exit the C2 processor power state whenever an interrupt is to be presented to the processor.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.6.1 and 8.2.3.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.13.8 The PM1x_STS register optional BM_STS bus master status bit (bit 4) is set any time a system bus master requests the system bus.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.6.2 and 4.7.3.1.1.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.13.9 The BM_RLD bit determines whether the Cx power state is exited based on bus master requests: set indicates from bus master request, reset indicates not from bus master request.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.2.6.2.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.13.10 C3 can be supported by requiring software to flush and invalidate caches prior to entering the C3 state or by providing hardware mechanisms to prevent masters from writing to memory in uni-processor systems.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.2.6.2.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.13.11 If a uni-processor platform prevents the bus master from writing into memory while in the C3 CPU power state, bus masters are disabled prior to entering a C3 power state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.2.6.2.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.13.12 If a uni-processor platform prevents bus master from writing into memory while in the C3 CPU power state, the CPU awakens from the C3 state upon a bus master requesting an access.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.2.6.2.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.13.13 When the PM1x_CNT register BM_RLD bit (bit 1) is set, the generation of a bus master request causes any processor in the C3 state to transition to the C0 state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.6.2, 4.7.3.2.1 and 8.2.4.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.13.14 CPU clock control is in fixed (I/O) space.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.1.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.13.15 The 32-bit clock control configuration register P_CNT controls the behavior of the processor clock logic for that processor.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.1.5.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.13.16 The clock-throttling hardware logic supports a programmable register within P_CNT processor control register to specify percentage of maximum CPU execution performance.

Zero is a reserved value.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.2.6.3.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.13.17 The PM1x_STS register BM_STS bus master status bit (bit 4) can only be cleared by writing a 1 to this bit position.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.1.1.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.13.18 If PM1x_CNT register BM_RLD bit 1 is reset, generation of a bus master request does not affect any processor in the C3 state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.2.1.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.13.19 The PM2_CNT power management 2 control register ARB_DIS bit (bit 0) enables (LOW) and disables (HIGH) the system arbiter.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.4.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.13.20 When the PM2_CNT register ARB_DIS bit is set to enabled (LOW), the arbiter can grant the bus to other bus masters.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.4.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.13.21 When PM2_CNT register ARB_DIS bit is disabled (HIGH), the arbiter is disabled and the default CPU has ownership of the system.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.4.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.13.22 The context of the P_BLK processor register block is not maintained across either the S3 or S4 sleeping states or the S5 soft off state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.5.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.13.23 The P_CNT processor control register is accessed as a DWORD (32-bits).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.5.1.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.13.24 The P_CNT processor control register CLK_VAL field (bits 0-3 and 5-31) lists possible clock throttling value locations.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.3.5.1.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.13.25 The P_CNT processor control register THT_EN bit (bit 4) enables clock throttling, as set in the CLK_VAL field.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.3.5.1.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.13.26 The P_LVL2 processor LVL2 register is accessed as a byte.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.5.2.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.13.27 Writing to the P_LVL2 processor LVL2 register has no effect.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.5.2.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.13.28 Reading from the P_LVL2 processor; LVL2 register returns all zeros.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.5.2.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.13.29 The P_LVL3 processor LVL3 register is accessed as a byte.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.5.3.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.13.30 Writes to the P_LVL3 processor LVL3 register has no effect.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.5.3.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.13.31 Reading from the P_LVL3 processor; LVL3 register returns all zeros.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.5.3.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.13.32 The hardware must always exit the C1 processor power state before an interrupt is presented to the processor.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 8.2.2.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.13.33 The hardware must always exit the C3 processor power state before an interrupt is presented to the processor.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 8.2.4.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)


ACPI Register Hardware Assertions

The following register hardware assertions implement ACPI.

These assertions are tested in TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP) Test Description.

3.14.1 The PM1x_EVT_BLK event register block has a minimum size of 4 bytes.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.1.1 and 4.7.1.2.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.14.2 The PM1x_CNT_BLK control register block has a minimum size of 2 bytes.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.1.1 and 4.7.1.2.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.14.3 Each PM1x_STS power management 1 status register has a 32-bit aligned address.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.1.1.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.14.4 The P_BLK processor register block is DWORD (32-bit) aligned.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.5.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.14.5 Each register in the general-purpose register block is 32-bit aligned.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.4.1.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)


Various ACPI Register Hardware Assertions

The following register hardware assertions implement ACPI.

These assertions are tested in:
TD-3.11 ACPI Pre-OS: Legacy to ACPI State Transition (ACPILAST) Test Description
TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT) Test Description
TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) Test Description
TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.1 A register block of the status/enable type contains a register with status bits and a corresponding register with enable bits.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.2 Status bits can only be cleared by software writing a 1 to the bit position.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.3 The enable bit has no effect on the setting or resetting of the status bit.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.4 The SET status bit only generates an "event output," which generates an SCI System Control Interrupt, if its enable bit is set.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.5 Bits within a register grouping can be split between two register blocks to allow those register grouping bits to reside in either or both register blocks.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.6 All generic events and fixed events generate SCIs System Control Interrupts.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.7 Fixed register space is required to be implemented by all ACPI-compatible hardware.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.8 Each bit location within a register grouping is fixed and cannot be changed.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.9 PM1x_EVT_BLK register blocks contain equal length status (PM1x_STS) and enable (PM1x_EN) registers.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.1.1.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.10 If implemented, the PM2_CNT_BLK register block contains the PM2 control register.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.1.3.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.11 Each general-purpose event register block (GPE0_BLK and GPE1_BLK) contains equal length status (GPEx_STS) and enable (GPEx_EN) registers.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.1.6.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.12 Fixed feature space registers are accessed with any width up to its register width (byte granular).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.13 Up to two general-purpose register blocks are supported.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.4.1.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.14 Each general-purpose register block contains two registers: an enable and a status register.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.4.1.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.15 Each register in the general-purpose register block is accessed as a byte.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.4.1.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.16 The GPE0_STS status and GPE0_EN enable registers length are each exactly half the length of the GPE0 register block.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.4.1.1.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.17 The GPE0_STS general-purpose event 0 status register contains the general-purpose event status bits in bank zero of the general-purpose registers.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.4.1.1.1.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.18 Each available GPE0_STS general-purpose event 0 status register status bit is set when the event is active, and this bit can only be cleared by using software to write a 1 to its respective bit position.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.4.1.1.1.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.19 Each available GPE0_STS general-purpose event 0 status register supports byte accesses, regardless of its length.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.4.1.1.1.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.20 Each available GPE0_STS general-purpose event 0 status register bit corresponds to GPE0_EN register bit with same bit position.

Reference documents: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.4.1.1.2.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.21 The GPE0_EN general-purpose event 0 enable register contains the general-purpose event enable bits.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.4.1.1.2.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.22 Each available GPE0_EN general-purpose event 0 enable register bit corresponds to the bit with the same bit position in the GPE0_STS register.

Reference documents: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.4.1.1.2.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.23 Each available GPE0_EN general-purpose event 0 enable register supports byte accesses, regardless of its length.

Reference documents: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.4.1.1.2.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.24 When a GPE0_EN general-purpose event 0 enable bit is set, a set status bit in the corresponding GPE0_STS status bit generates an SCI system control interrupt.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.74.1.1.2.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.25 The GPE1_STS status and GPE1_EN enable registers length are each exactly half the length of the GPE1 register block.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.4.1.2.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.26 The GPE1_STS general-purpose event 1 status register contains the general-purpose event status bits in bank one of the general-purpose registers.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.4.1.2.1.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.27 Each available GPE1_STS general-purpose event 1 status register bit corresponds to the GPE1_EN register bit with the same bit position.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.4.1.2.1.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.28 Each available GPE1_STS general-purpose event 1 status register status bit is set when the event is active, and this bit can only be cleared by having software write a one to its respective bit position.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.4.1.2.1.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.29 Each available GPE1_STS general-purpose event 1 status register supports byte accesses, regardless of its length.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.4.1.2.1.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.30 The GPE1_EN general-purpose event 1 enable register contains the general purpose event enable bits.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.4.1.2.2.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.31 Each available GPE1_EN general-purpose event 1 enable register bit corresponds to the GPE1_STS register bit with the same bit position.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.4.1.2.2.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.32 Each available GPE1_EN general-purpose event 1 enable register supports byte accesses, regardless of its length.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.4.1.2.2.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.33 When a GPE1_EN general-purpose event 1 enable bit is set, a set status bit in the corresponding GPE1_STS status bit generates an SCI system control interrupt.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.4.1.2.2.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.34 GPEx_BLK blocks enable bits must be read/write.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.6.2.2.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.35 GPEx_BLK blocks status bits must be latching.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.6.2.2.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.15.36 GPEx_BLK blocks status bits must be read/clear, and cleared by writing "1" to the status bit as specified in Section 5.6.2.2.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.6.2.2.
Test descriptions: TD-3.11 Legacy / ACPI State Transition (ACPILAST), TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description


Unconnected Interrupt Assertion

This register hardware assertion is used to implement ACPI. This assertion is tested by the ACPI Hardware Assertions Checklist.

3.16.1 Unutilized GPE event pins are tied inactive so that the corresponding GPE register SCI status bit is not set by a floating input pin.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.4.1.1.
Test description: TD-3.23 ACPI BIOS Assertion Checklist


Register Hardware Assertions

The following register hardware assertions are tested using the checklist specified in this chapter. For a list of the register hardware assertions to implement ACPI that are not tested, see "ACPI Assertions Not Tested".

Many of these assertions are tested in TD-3.22 ACPI Hardware Register Assertion Checklist

3.17.1 Fixed-space features are limited to performance sensitive features, feature drivers required during wakeup, and features that enable catastrophic failure recovery.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.1 and 4.5.
Test description: TD-3.22 ACPI Hardware Register Assertion Checklist

3.17.2 "Child" interrupt status bits can reside in generic address space but, they have a "parent" interrupt status bit in the GP_STS register.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.1 and 4.5.
Test description: TD-3.22 ACPI Hardware Register Assertion Checklist

3.17.3 Generic location power management feature bits can reside in system I/O space, system memory space, PCI configuration space, embedded controller space, or SMBus device space.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.1 and 4.5.
Test description: TD-3.22 ACPI Hardware Register Assertion Checklist

3.17.4 ACPI (for example, event and control) hardware register reserved and unimplemented bits always return zero, and data writes to them have no side effects.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.5.1 and 4.7.
Test description: TD-3.22 ACPI Hardware Register Assertion Checklist

3.17.5 ACPI hardware register write-only control bits are activated by software by writing a 1 to each bit’s position.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.53.
Test description: Test Not Specified

3.17.6 Cross-device dependencies, such as configuration mode blocks access to another device, or atomic back-to-back write access requirements, are not supported and devices should not exhibit this behavior.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.5.4.
Test description: TD-3.22 ACPI Hardware Register Assertion Checklist

3.17.7 Status bits are set by hardware event input HIGH.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.
Test description: TD-3.22 ACPI Hardware Register Assertion Checklist

3.17.8 The general-purpose event registers contain the root-level events for all generic features.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.1.6.
Test description: TD-3.22 ACPI Hardware Register Assertion Checklist

3.17.9 ACPI-compatible hardware programming bits can reside in any of the defined generic address spaces (system I/O, system memory, PCI configuration, embedded controller, or SMBus), but the top-level event bits are contained in the general-purpose registers.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.4.
Test description: TD-3.22 ACPI Hardware Register Assertion Checklist

3.17.10 The top-level "parent" event status and enable bits must reside in either the GPE0_STS or the GPE1_STS registers.

"Child" event status bits can reside in generic address space.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.4.
Test description: TD-3.22 ACPI Hardware Register Assertion Checklist

3.17.11 Systems that support both APIC and dual 8259 interrupt models must map interrupt vectors 0-15 to 8259 IRQs 0-15.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.2.8.2.
Test description: TD-3.22 ACPI Hardware Register Assertion Checklist

3.17.12 Hardware can cascade other general-purpose events from a bit in the GPEx_BLK through status and enable bits in Operational Regions (I/O space, memory space, PCI configuration space, or embedded controller space).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.6.2.2.
Test description: TD-3.22 ACPI Hardware Register Assertion Checklist

3.17.13 The system can have multiple devices using the same general-purpose event bit by using OEM-specific hardware to provide second-level status and enable bits.

Reference document: WLP# - A1.1.2 , B12.1.4.4; ACPI Specification, Revision 1.0a, Section 5.6.2.2.4.
Test description: TD-3.22 ACPI Hardware Register Assertion Checklist


ACPI Real-time Clock and RTC Alarm Hardware Assertions

The following real-time clock (RTC) and RTC alarm hardware assertions implement ACPI.

These assertions are tested in TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.18.1 In G3, the real-time clock device runs off a battery.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.5 and 4.7.2.4.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.18.2 The real-time clock (RTC) can be programmed to generate an alarm.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.5 and 4.7.2.4.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.18.3 An enabled real-time clock alarm generates a hardware wake-up event from the S1-S3 sleeping states.

S4 wakeup is optional.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.5 and 4.7.2.4.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.18.4 If S4 wakeup is supported, the RTC_S4 flag is set HIGH.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.5 and 4.7.2.4.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.18.5 If DAY_ALRM day alarm is supported, a CMOS RAM location is provided to select day within month to generate an RTC alarm.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.5 and 4.7.2.4.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.18.6 If MON_ALRM month alarm is supported (PC 99 requirement), a CMOS RAM location is provided to select month within year to generate an RTC alarm when DAY_ALRM is set.

Reference documents: WLP# - A1.1.2; ACPI Specification, Revision 1.0 and PC 99 System Design Guide - SYS-002.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.18.7 If CENTURY value is supported, a CMOS RAM location is provided to select date century value to generate RTC alarm when DAY_ALRM is set.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.2.4.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.18.8 The RTC_STS RTC status bit is set through the RTC interrupt (IRQ 8 in PC architecture systems).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.2.4.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.18.9 The RTC's interrupt pin serves as the source for the RTC_STS bit generation.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.2.4.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.18.10 If the MON_ALRM RTC month alarm is supported, the DAY_ALRM RTC day alarm function must also be supported.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.2.4.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.18.11 The optional PM1x_STS register RTC_STS RTC alarm status bit (bit 10) is set when the RTC generates an alarm by asserting the RTC IRQ signal.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.1.1.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.18.12 The PM1x_STS register RTC_STS RTC alarm status bit (bit 10) is only set by hardware and can only be reset by software by writing a 1 to this bit position.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.1.1.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.18.13 If the RTC was the cause of the wakeup from an S1-S3 state, the PM1x_STS register RTC_STS RTC alarm status bit is set prior to returning control to the operating system.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.1.1.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.18.14 If the RTC was the cause of the wakeup from an S4 state and the RTC_S4 flag within the FACP table is set, the PM1x_STS register RTC_STS RTC alarm status bit is set prior to returning control to the operating system.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.5 and 4.7.2.4.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.18.15 If the RTC_EN bit is set, the setting of the PM1x_STS register RTC_STS RTC alarm status bit generates a power management event (SCI, SMI, or resume event).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.1.1.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.18.16 The optional PM1x_EN register RTC_EN RTC alarm enable bit (bit 10), if set, enables an SCI system control interrupt or wakeup event to be generated any time the RTC_STS bit is set (when the RTC generates an alarm).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.1.2.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description


ACPI BIOS Assertions

The following sections describe the ACPI BIOS assertions tested by this test suite.

ACPI Minimum BIOS Assertions

The following assertions are the minimum BIOS implementation features required to support ACPI.

These assertions are tested in TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP) Test Description and TD-3.23 ACPI BIOS Assertion Checklist

3.19.1 BIOS must implement platform system (main) board description table.

Reference documents: WLP# - A1.1.2; ACPI Specification, Revision 1.0, Section 1.7, PC 2001 System Design Guide - s, SYS-0002, and PC 99 System Design Guide - 3.2.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.19.2 BIOS must implement _PRT control method for all root PCI bridges.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 1.7.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.19.3 System provides no user-accessible method for disabling ACPI in the BIOS.

Reference document: WLP# - A1.1.2; PC 2001 System Design Guide - s, SYS-0002.3, PC 99 System Design Guide - 3.2.5.
Test description: TD-3.23 ACPI BIOS Assertion Checklist


Battery BIOS Assertions

The following battery and AC adapter BIOS assertions implement ACPI.

These assertions are tested in TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB) Test Description and TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.20.1 A battery device is required to either have an ACPI Smart Battery Table or a Control Method Battery (CMBatt) interface.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Sections 10.2 and 11.
Test descriptions: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB) and TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.20.2 Systems with an ACPI Smart Battery Table must include a corresponding bus / device package for the SMBus host controller in an ACPI table

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Sections 10.2 and 11.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.20.3 If the system implements an ACPI Smart Battery System, the _SBS system indicator control method specifies the system battery configuration state.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Sections 11.1.3, and 11.1.4.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.20.4 The AML code handler for a battery insertion issues a Notify (battery_device,0x81) on the battery device.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Sections 11.2.1and 5.6.3, Table 5-26.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.20.5 The AML code handler for a battery removal issues a Notify (battery_device,0x81) on the battery device.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Sections 11.2.1and 5.6.3, Table 5-26.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.20.6 The AML code handler for a battery whose present state changes or crosses the trip point issues a Notify (battery_device, 80h) on the battery device.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 11.2.1.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.20.7 The AML code handler for a battery whose present state changes to critical issues a Notify (battery_device, 80h) on the battery device and reports the battery critical flag in the _BST object.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 11.2.1.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.20.8 Each CMBatt device object contains the _BIF, _BST, _PCL, _STA, and, optionally, the _BTP control methods.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 11.2.2.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.20.9 When the system has two or more control method batteries, each battery has an independent device object in the name space.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 11.2.2.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.20.10 The CMBatt interface _BIF object returns the static portion of the Control Method Battery information.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 11.2.2.1.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.20.11 If the OEM platform does not support the _BIF object OEM Information field, it should be set to 0.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 11.2.2.1.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.20.12 On a CMBatt interface multiple battery system, all batteries in the system should return the same granularity.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 11.2.2.1, Table 11-4 footnote.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.20.13 The CMBatt interface _BST object returns the present battery status.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 11.2.2.2.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.20.14 CMBatt interface _BST object battery state field must never set both charging bit and discharging bit at the same time.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 11.2.2.2, Table 11-5.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.20.15 The CMBatt interface _BST object battery present rate field must return a valid value for batteries that are rechargeable and are in the discharging state.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0a, Section 11.2.2.2, Table 11-5.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.20.16 The CMBatt interface _BST object battery remaining capacity field must return a valid value for batteries that are rechargeable and are in the discharging state.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 11.2.2.2, Table 11-5.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.20.17 The CMBatt interface _BST object battery present voltage field must return a valid value for batteries that are rechargeable and are in the discharging state.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 11.2.2.2, Table 11-5.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.20.18 The CMBatt interface _BST object battery present voltage field can only return unknown voltage for a primary (non-rechargeable) battery.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 11.2.2.2, Table 11-5.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.20.19 The CMBatt interface _BTP object sets a trip-point to generate an SCI when the battery remaining capacity reaches the value specified in the _BTP object.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 11.2.2.3.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.20.20 If the CMBatt interface battery does not support generating an SCI when the battery remaining capacity reaches a specified value, the _BTP control method is not located in the name space.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 11.2.2.3.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.20.21 A Smart Battery Table is required if the platform supports batteries, as defined by the Smart Battery Specification 1.0.

Reference documents: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 5.2.10 and the Smart Battery Specification 1.0.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.20.22 A Battery Status Changed notification is issued when the control method battery device status has changed.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 5.6.3, Table 5-26.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.20.23 A Battery Information Changed notification is issued when the control method battery device information has changed (the battery has been replaced).

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 5.6.3, Table 5-26.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.20.24 Battery information changed notification is only generated when a battery is replaced.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0a, Section 5.6.3.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.20.25 A Power Source Status Changed notification is issued when the power source status has changed.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 5.6.3, Table 5-27.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.20.26 The PNP0C0A ACPI Device ID identifies a device that solely implements the ACPI control method battery functions.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 5.6.4, Table 5-32.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.20.27 The ACPI0003 ACPI Device ID identifies an AC adapter device.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 5.6.4, Table 5-32.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.20.28 The ACPI0002 ACPI Device ID identifies a smart battery subsystem.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 5.6.4, Tables 5-32 and 11.1.3.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.20.29 Device object _STA bit 4 should be set if the battery is present or cleared if the battery is not present.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 6.3.5.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.20.30 The _BIF power unit field must report 0 indicating remaining capacity information is reported in mWh and battery present charge/discharge rate is reported in mW.

Reference documents: WLP# - A1.1.2; PC 2001 System Design Guide -MOBL-0062.2; PC 99 System Design Guide - 6.2.2 and ACPI Specification, Revision 1.0b, Section 11.2.2.1, Table 11-4.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.20.31 Control method battery _BIF design capacity is reported (0 - 7FFFFFFFh) in mWh.

Reference documents: WLP# - A1.1.2; PC 2001 System Design Guide - MOBL-0062.2, PC 99 System Design Guide - 6.2.2 and ACPI Specification, Revision 1.0b, Section 11.2.2.1, Table 11-4.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.20.32 Control method battery _BIF last full charge capacity is reported (0 - 7FFFFFFFh) in mWh.

Reference documents: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 11.2.2.1, Table 11-4.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.20.33 Control method battery _BIF design capacity of low must be reported (0 - 7FFFFFFFh) in mWh.

Reference documents: WLP# - A1.1.2; PC 2001 System Design Guide - MOBL-0062.2,PC 99 System Design Guide - 6.2.2 and ACPI Specification, Revision 1.0b, Section 11.2.2.1, Table 11-4.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.20.34 Control method battery _BIF design capacity of warning must be reported (0 - 7FFFFFFFh) in mWh.

Reference documents: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 11.2.2.1, Table 11-4.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.20.35 Control method battery _BIF battery technology is reported as 0 (primary, non-rechargeable) or 1 (secondary, rechargeable).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 11.2.2.1, Table 11-4.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.20.36 Control method battery _BIF design voltage is reported as 0-0x7FFFFFFF or 0xFFFFFFFF.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 11.2.2.1, Table 11-4.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.20.37 Control method battery _BST battery remaining capacity is reported (0 - 7FFFFFFFh) in mWh.

Reference documents: WLP# - A1.1.2; PC 2001 System Design Guide - MOBL-0062.2, PC 99 System Design Guide - 6.2.2 and ACPI Specification, Revision 1.0b, Section 11.2.2.2, Table 11-5.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.20.38 Control method battery _BST battery present rate is reported (0 - 7FFFFFFFh) in mW.

Reference documents: WLP# - A1.1.2; PC 2001 System Design Guide -MOBL-0062.2; PC 99 System Design Guide - 6.2.2 and ACPI Specification, Revision 1.0b, Section 11.2.2.2, Table 11-5.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.20.39 Batteries must be able to supply at least the battery remaining capacity they report at all times, even when the system is running on AC power.

Batteries must never report more battery remaining capacity than they can supply.

Reference document: WLP# - A1.1.2; PC 2001 System Design Guide -MOBL-0062.2; PC 99 System Design Guide - 6.2.2.
Test description: TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface Test (ACPICMB)

3.20.40 If implemented, the system implements AC Adapter Device ACPI Device ID as defined in ACPI 1.0b, Section 5.6.4, Table 5-28.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 5.6.4, Table 5-28.
Test Description: Test Not Specified


ACPI Processor BIOS Assertions

The following processor BIOS assertions implement ACPI.

These assertions are tested in TD-3.3 ACPI Processor Power State Transition (ACPIPPST) Test Description

3.21.1 A processor object is declared for each processor in the system using an ASL processor statement that provides processor configuration information and points to the P_BLK register, if it exists.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 8.1.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.21.2 Optional processor power state transition logic is defined on a per-CPU basis described through FACP table and processor objects.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.6, 4.7.2.6.1 and 5.2.5.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.21.3 If processors do not support symmetric power state, the BIOS chooses and uses the lowest common power states supported by all the processors in the system through the FACP table.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.6, 4.7.2.6.1 and 5.2.5.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.21.4 The system software automatically causes an idle processor complex to enter a C2 power state (to enable memory snooping) if bus masters or multiprocessor processors are active.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.6, 4.7.2.6.1 and 5.2.5.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.21.5 If the platform supports manual flushing of caches, the FLUSH_SIZE and FLUSH_STRIDE FACP fields are required.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.6.2.1, 5.2.5 and 9.2.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.21.6 The Fixed ACPI Description Table FLUSH_SIZE field value is typically two times the cache size.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.6.2.1, 5.2.5 and 9.2.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.21.7 Fixed ACPI Description Table FLUSH_STRIDE field value is typically the smallest processor cache line width.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.6.2.1, 5.2.5 and 9.2.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.21.8 If the platform properly supports the processor's write back and invalidate instruction (WBINVD for IA processors), the WBINVD flag in the FACP table is set.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.6.2.1 and 9.2.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.21.9 If the platform supports the write back and invalidate instruction but does not invalidate after its execution (only flushes), then the WBINVD_FLUSH flag is set and WBINVD flag is clear.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.6.2.1 and 9.2.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.21.10 The FACP table contains the CPU clock throttling hardware logic register duty offset (offset within P_CNT) and duty width (number of duty value bits used) values.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.2.6.3.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.21.11 The Fixed ACPI Description Table P_LVL2_LAT field must contain a value greater than 100 if the system does not support a C2 state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.6, 4.7.2.6.1 and 5.2.5.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.21.12 The Fixed ACPI Description Table P_LVL3_LAT field must contain a valuegreater than 1000 if the system does not support a C3 state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.6, 4.7.2.6.1 and 5.2.5.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.21.13 The Fixed ACPI Description Table FLUSH_SIZE field must contain zero, if the system does not support a method for flushing the processor's caches.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.6, 4.7.2.6.1 and 5.2.5.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.21.14 The maximum allowed value for FLUSH_SIZE multiplied by FLUSH_STRIDE is 2 MBs.

Reference document: WLP# - A1.1.2; ACPI Specification Advanced Configuration and Power Interface Revision 1.0, Errata Sections 4.7.2.6.2.1, 4.7.2.6.1, 5.2.5 and 9.2.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.21.15 If the processor's cache size is greater than 1 MB, flushing cache support must utilize the WBINVD=1 mechanism.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.6, 4.7.2.6.1 and 5.2.5.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.21.16 On Intel® Pentium Pro processor machines, the WBINVD instruction must flush and invalidate the caches.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.6, 4.7.2.6.1 and 5.2.5.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.21.17 The Fixed ACPI Description Table Feature Flags PROC_C1 field must contain 1 if the C1 power state is supported on all processors or 0 otherwise.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.6, 4.7.2.6.1 and 5.2.5.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.21.18 Intel Pentium Pro processor multi-processor C3 support third level victim caches require Fixed ACPI Description Tabled Fixed Feature Flags WBINVD=1 support.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.2.5 and 9.2.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.21.19 The worst-case hardware latency for the C2 processor power state is declared in the FACP table.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 8.2.3.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

3.21.20 The worst-case hardware latency for the C3 processor power state is declared in the FACP table.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 8.2.4.
Test description: TD-3.3 ACPI Processor Power State Transition (ACPIPPST)


Assertion To Implement Processor BIOS

This processor BIOS assertion implements ACPI. This assertion is tested by the ACPI processor throttle test (CPUTHRTL).

3.22.1 The Fixed ACPI Description Table DUTY_WIDTH field must contain zero if processor duty cycle is not supported.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.2.5.
Test description: TD-3.20 ACPI Pre-OS: Processor Throttling (CPUTHRTL) Test Description


ACPI Docking and Undocking BIOS Assertions

The following docking and undocking BIOS assertions implement ACPI.

These assertions are tested in TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking (ACPIDOCK) Test Description and TD-3.29 Docking Test Description

3.23.1 Only an unload operation of a definition Block can remove names from the name space.

Reference document: WLP# - A1.1.2, A3.1.1; ACPI Specification, Revision 1.0a, Section 5.3.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.23.2 Contents of the ACPI name space only change on a load or unload operation.

Reference document: WLP# - A1.1.2, A3.1.1; ACPI Specification, Revision 1.0a, Section 5.3.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.23.3 The Fixed ACPI Description Table Feature Flags DCK_CAP field must be 0 if the system does not support docking, or 1 if the system does support docking.

Reference document: WLP# - A1.1.2, A3.1.1; ACPI Specification, Revision 1.0b, Section 5.2.5, Table 5-26.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.23.4 The _DCK control method is located in the device object that represents the docking station to indicate that the device is really a docking station.

Reference document: WLP# - A3.1.1; ACPI Specification, Revision 1.0b, Section 6.5.2.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.23.5 The _DCK control method controls the isolation logic on the docking connector.

Reference document: WLP# - A3.1.1; ACPI Specification, Revision 1.0b, Section 6.5.2.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.23.6 The _BDN control method returns the Plug and Play GetDockingStationIdentifier EISA-packed DockID DWORD that correlates a docking station reported via ACPI and the same docking station reported via legacy (Plug and Play) interfaces.

Reference document: WLP# - A3.1.1; ACPI Specification, Revision 1.0b, Section 6.5.3.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.23.7 The _BDN control method must appear in the device object that represents the dock (the device object with the _EJx control methods).

Reference document: WLP# - A3.1.1; ACPI Specification, Revision 1.0b, Section 6.5.3.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.23.8 If the system supports Plug–n-Play, ACPI, and docking, the _BDN control method object is required.

Reference document: WLP# - A3.1.1; ACPI Specification, Revision 1.0b, Section 6.5.3.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.23.9 After a warm dock, the BIOS should not configure the docking bridge (connector) or any other devices in the docking station.

Non Plug-and-Play devices must be enumerated, configured, and disabled using ACPI-based methods.

Reference document: WLP# - A3.1.1; PC 2001 System Design Guide - MOBL-0078, PC 99 System Design Guide - 6.26 and 6.32.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.23.10 When a mobile PC is docked to a mini-dock or docking station, notification must occur during a hot docking event or when the system returns from a warm or cold dock.

Reference document: WLP# - A3.1.1; PC 2001 System Design Guide - MOBL-0078, PC 99 System Design Guide - 6.27 and 6.32.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.23.11 The mobile PC and docking station as a whole must be capable of completely and dynamically disabling static onboard and add-on devices, and of freeing all the resources used by that device when the mobile unit is docked.

Reference document: WLP# - A3.1.1; PC 2001 System Design Guide - MOBL-0076, PC 99 System Design Guide - 6.33.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.23.12 Docking or undocking a mobile unit from a docking or mini-dock station must not require powering off the system and must not require a system reboot.

Reference document: WLP# - A3.1.1; PC 2001 System Design Guide -MOBL-0079; PC 99 System Design Guide - 6.34 and 6.39.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.23.13 A hardware undock button must be provided for the docking or mini-dock station.

This button sends a signal to the operating system indicating the user’s intent to undock the system.

Reference document: WLP# - A3.1.1; PC 2001 System Design Guide - MOBL-0080, PC 99 System Design Guide - 6.35 and 6.40.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.23.14 If the system supports docking, the system implements the _DCK control method and generates docking and undocking event notifications as specified in ACPI 1.0b, Sections 5.6.3 and 6.5.2.

Reference documents: WLP# - A3.1.1; PC 2001 System Design Guide - - MOBL-0078, and ACPI Specification, Revision 1.0b, Section 5.6.3, Table 5-21 and Section 6.5.2.
Test Description: TD-3.29 Docking Test Description

3.23.15 If the system supports docking, the system implements the _BDN control method as specified in ACPI 1.0b, Section 6.5.3.

Reference document: WLP# - A3.1.1; ACPI Specification, Revision 1.0b, Section 6.5.3.
Test Description: TD-3.29 Docking Test Description


ACPI Device Power Management BIOS Assertions

The following device power management BIOS assertions implement ACPI.

These assertions are tested in TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT) Test Description

3.24.1 Device objects do not list power resources for the OFF power state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.3.
Test description: TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT)

3.24.2 The only transition allowed from the D3 device state is to the D0 device state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.3.
Test description: TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT)

3.24.3 The _GTF get task file control method returns a buffer containing ATA commands to restore the drive to boot defaults.

The buffer is a list consisting of seven, eight-bit register values corresponding to ATA task registers 1F1-1F7h or 171h-177h.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0, Errata Section 10.8.1.
Test description: TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT)

3.24.4 The _STM control method sets the IDE controller transfer timings to the setting requested.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0, Errata Sections 10.8.1 through 10.8.3.
Test description: TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT)

3.24.5 The _STM control method AML code must convert and set the ns timing to the appropriate transfer mode settings for the IDE controller.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0, Errata Sections 10.8.1 through 10.8.3.
Test description: TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT)

3.24.6 The _GTM Get Timing Mode control method returns the current settings for the IDE channel.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0, Errata Section 10.8.2.
Test description: TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT)

3.24.7 The _GTM Get Timing Mode control method is listed under each channel device object.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0, Errata Section 10.8.2.
Test description: TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT)

3.24.8 The _GTM control method result codes specify PIO bus-cycle timing and DMA Speed for drives 0 and 1.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0, Errata Section 10.8.2.
Test description: TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT)

3.24.9 The _GTM control method result codes specify PIO bus-cycle timing and DMA Speed values FFFFFFFFh for drive 0 when the mode is not supported by the channel.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0, Errata Section 10.8.2.
Test description: TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT)

3.24.10 The _GTM control method result codes specify PIO bus-cycle timing and DMA Speed values FFFFFFFFh for drive 1 when the chipset cannot set timing parameters independently for each drive.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0, Errata Section 10.8.2.
Test description: TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT)

3.24.11 The _GTM control method result codes Flags field indicates whether drives 0 and 1 user UltraDMA and/or IOChannelReady.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0, Errata Section 10.8.2.
Test description: TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT)

3.24.12 The _GTM control method result codes Flags field indicates whether the chipset can set timing independently for each drive.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0, Errata Section 10.8.2.
Test description: TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT)

3.24.13 The _STM control method is responsible for correcting for drives that misreport their timing information.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0, Errata Section 10.8.3.
Test description: TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT)

3.24.14 If the _PCL power source object lists point to a bus, this power source device powers all devices under the bus.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 11.3.2.
Test description: TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT)

3.24.15 The _PSR power source object specifies the present power source devices.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5 and 11.3.1.
Test description: TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT)

3.24.16 The _PCL power source object lists pointers to devices powered by a power source as specified in Sections 5.6.5 and 11.3.2.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5 and 11.3.2.
Test description: TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT)

3.24.17 The _PR0 power management object specifies a device's power requirements in the D0 device state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5 and 7.2.2.
Test description: TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT)

3.24.18 The _PR1 power management object specifies a device's power requirements in the D1 device state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5 and 7.2.3.
Test description: TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT)

3.24.19 The _PR2 power management object specifies a device's power requirements in the D2 device state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5 and 7.2.4.
Test description: TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT)

3.24.20 The _IRC inrush current load/draw object must be used to specify to the operating system and drivers serialization requirements while transitioning devices to the D0 power state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.3.1.
Test description: TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT)

3.24.21 The _PSC power management object specifies a device's current power state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5 and 7.3.3.
Test description: TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT)

3.24.22 The _PS0 power management control method puts the device in the D0 device state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5 and 7.3.4.
Test description: TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT)

3.24.23 The _PS1 power management control method puts the device in the D1 device state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5 and 7.3.5.
Test description: TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT)

3.24.24 The _PS2 power management control method puts the device in the D2 device state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5 and 7.3.6.
Test description: TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT)

3.24.25 The _PS3 power management control method puts the device in the D3 device state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5 and 7.3.7.
Test description: TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT)

3.24.26 The _STA power resource object specifies the current on/off state of the power resource.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5 and 7.4.1.
Test description: TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT)

3.24.27 The _ON power resource object sets the resource into its on state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5 and 7.4.2.
Test description: TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT)

3.24.28 The _OFF power resource object sets the resource into its off state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5 and 7.4.3.
Test description: TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT)


ACPI Table and Name Space BIOS Assertions

The following ACPI table and name space BIOS assertions implement ACPI.

These assertions are tested in:
TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP) Test Description
TD-3.24 Reserved Name Usage Test Description
TD-3.28 USB Root Hub _ADR Test Description

3.25.1 ACPI name space describes all generic location features.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.6.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.2 Each register block gets a separate pointer from the FACP ACPI table.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7, 5.2.5 and 5.3.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.3 Each of GPE0_BLK and GPE1_BLK general-purpose event register blocks has a separate 32-bit pointer within the FACP ACPI table.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7, 5.2.5 and 5.3.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.4 Numeric values in description tables, blocks, and structures are always encoded in little endian format.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.2.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.5 All signature values in description tables, blocks, and structures are stored as fixed-length strings.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.2.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.6 AML code returns bit value 0 for all reserved bits in ACPI tables or in other software values such as resource descriptors.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.2.1.1.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.7 AML code returns only defined values and does not return reserved values.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.2.1.2.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.8 All Definition Blocks load into the same (single) hierarchical name space.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7, 5.2.5 and 5.3.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.9 ACPI name space collisions must be avoided.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a. Sections 4.7, 5.2.5 and 5.3.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.10 All name references use a 32-bit fixed-length name or use a name extension prefix to concatenate multiple 32-bit fixed-length name components together.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7, 5.2.5 and 5.3.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.11 The first byte of a name is inclusive of the ‘A’-‘Z’ and ‘_’ characters.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7, 5.2.5 and 5.3.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.12 The last three bytes of a name are inclusive of the ‘A’-‘Z’, ‘0’-‘9’, and ‘_’ characters.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7, 5.2.5 and 5.3.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.13 For a padded name, padding is done with trailing underscores (‘_’).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7, 5.2.5 and 5.3.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.14 Definition Blocks can only use (reserved) names beginning with the underscore character ‘_’ as defined by the ACPI specification.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7, 5.2.5 and 5.3.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.15 A name preceded with the backslash character ‘ \ ’ causes the name to refer to the root of the name space.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7, 5.2.5 and 5.3.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.16 The current name space determines where in the name space hierarchy a name being created goes and where a name being referenced is found, except for names preceded by the backslash character ‘\.’

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7, 5.2.5 and 5.3.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.17 A name is located by finding the matching name in the current name space, then in the parent name space.

If the name space does not have a parent (the root of the name space), the name is not found.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7, 5.2.5 and 5.3.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.18 A package contained within another package must be fully contained within the outer package; the same is true for implicit length datum.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.4.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.19 The first object present in a Definition Block must be a named (initialization) control method.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.4.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.20 On initial control method execution, the local data objects are NULL.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.5.4.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.21 Unnamed objects cannot be created in the "root" of the ACPI name space.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.4.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.22 The _GTF Get Task File control method is listed under each drive device object.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0, Errata Section 10.8.1.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.23 The _PSR power source devices control method must be located under the AC adapter object in name space.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 11.3.1.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.24 The PM1_EVT_LEN FACP table field indicates the total length of the PM1x_EVT_BLK event register block in bytes.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.1.1.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.25 The PM1x_EVT_BLK event register block has a minimum size of 4 bytes (PM1_EVT_LEN value).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.1.1 and 5.2.5.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.26 PM1a_EVT_BLK and PM1b_EVT_BLK event register blocks have unique 32-bit aligned 32-bit pointers in the Fixed ACPI Table (FACP).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.1.1, 4.7.3.1, 4.7.3.1.1 and 4.7.3.1.2.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.27 If the PM1b_EVT_BLK event register block is not supported, its FACP table entry pointer contains a value of zero.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.1.1, 4.7.3.1.2 and 5.2.5.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.28 PM1a_CNT_BLK and PM1b_CNT_BLK control register blocks have unique 32-bit aligned 32-bit pointers in the Fixed ACPI Table (FACP).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.1.2.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.29 The PM1_CNT_LEN FACP table field indicates the total length of the PM1x_CNT_BLK control register block in bytes.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.1.2.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.30 The PM1x_CNT_BLK event register block has a size of 2 bytes, minimum (PM1_CNT_LEN value).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.1.2 and 5.2.5.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.31 If the PM1b_CNT_BLK control register block is not supported, its FACP table entry pointer contains a value of zero.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.1.2 and 5.2.5.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.32 The Fixed ACPI Table (FACP) contains a length variable (PM2_CNT_LEN) for the PM2_CNT_BLK control register block that is equal to the size in bytes of the PM2_CNT register.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.1.3.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.33 If PM2_CNT_BLK control register block is not supported, its FACP table entry pointer and length entries contain a value of zero.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.1.3 and 5.2.5.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.34 Each GPEx_BLK general-purpose event register block contains its own length variable (GPEx_LEN) in the FACP table.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.1.6.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.35 If a GPEx_BLK general-purpose register block is not supported, its FACP table entry pointer and length entries contain a value of zero.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.1.6 and 5.2.5
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.36 Root System Description Pointer structure is located on a 16-byte boundary in either the first kilobyte of the Extended BIOS Data Area (EBDA) or in the BIOS read-only memory space between 0E0000h and 0FFFFFh.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.2.2.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.37 The entire Root System Description Pointer structure, including the checksum field, must add up to zero.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.2.2.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.38 The Root System Description Pointer structure reserved field must be zero.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.2.2.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.39 The Description table/structure headers length field includes table length, in bytes, including header, starting from offset 0.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.2.3.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.40 The Description table/structure header's revision field: larger revision numbers are backward compatible to lower revision numbers with the same signature.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.2.3.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.41 The description table/structure header's checksum field and the entire table including the checksum field, must add up to zero.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.2.3.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.42 In the description table/structure header's OEM table ID field, the OEM assigns each dissimilar table a new OEM table ID.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.2.3.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.43 The Root System Description Table contains an array of physical pointers to other System Description Tables.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.2.4.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.44 Each of the description table/structure header (36 bytes) to which the Root System Description Table points is addressable memory, such as accesses to the headers do not cause memory access faults.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.2.4.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.45 The Fixed ACPI Description Table PM1a_EVT_BLK field is a required field (non-zero).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7, 5.2.5 and 5.3.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.46 The Fixed ACPI Description Table PM1a_CNT_BLK field is a required field (non-zero).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7, 5.2.5 and 5.3.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.47 The Fixed ACPI Description Table PM_TMR_BLK field is a required field (non-zero).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7, 5.2.5 and 5.3.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.48 The Fixed ACPI Description Table PM2_CNT_LEN field value is >= 1.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7, 5.2.5 and 5.3.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.49 The Fixed ACPI Description Table PM_TM_LEN field value is >= 4.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7, 5.2.5 and 5.3.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.50 The Fixed ACPI Description Table GPE0_BLK_LEN field value is a non-negative multiple of 2.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7, 5.2.5 and 5.3.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.51 The Fixed ACPI Description Table GPE1_BLK_LEN field value is a non-negative multiple of 2.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7, 5.2.5 and 5.3.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.52 The Firmware ACPI Control Structure is a structure in read/write memory that the BIOS has set aside for ACPI usage.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.2.6.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.53 The BIOS aligns the FACS on a 64-byte boundary anywhere within the 0-4GB memory address space.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.2.6.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.54 The Differentiated System Description Table is part of the system fixed description in Definition Block Format.

It contains the Differentiated Definition Block to be loaded during operating system initialization and cannot be unloaded.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.2.7 and 5.2.7.1.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.55 A Secondary System Description Table can rely only on the Differentiated System Description Table being loaded prior to it.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.2.7.2.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.56 All general events in GPE register blocks are defined in the \_GPE name space.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.3.1.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.57 All processor objects are defined in the \_PR name space.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.3.1.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.58 All device and bus objects are defined in the \_SB name space.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.3.1.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.59 All thermal zone objects are defined in the \_TZ name space.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.3.1.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.60 All system indicator objects are defined in the \_SI name space.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.3.1 and 10.1.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.61 All objects, except locals, have a global scope.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.3.2.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.62 Local data objects have a per-invocation scope and life, and they are used to process the current invocation from beginning to end.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.3.2.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.63 Control methods can be passed up to seven arguments.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.5.4.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.64 Each control method argument is an object and could, in turn, be a package style object that refers to other objects.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.5.4.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.65 The number of arguments passed to any control method is fixed and is defined when the control method package is created.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.5.4.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.66 Control methods can access up to eight local data objects.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.5.4.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.67 DDR objects associate a logical software name with a device.

Reference document: WLP# - A1.1.2; ACPI Specification, Errata, Revision 1.0, Section 6.1.2a.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.68 A _HID object evaluates to either a numeric 32-bit compressed EISA type ID or a string.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.1.3.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.69 Memory that is identified by the BIOS and that contains the ACPI tables can be any place that is identified as Reserved Memory by Interrupt 15h function E820h.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 9.3.2.
Test description: TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP)

3.25.70 Implementations that use ACPI control method and object names reserved by the ACPI Specification, Revision 1.0b that were not previously defined in ACPI Specification 1.0 implement those names according to ACPI Specification, Revision 1.0b: _BBN, _BDN, _DCK, _DDC, _DDN, _DGS, _DOD, _DOS, _DSS, _FDE, _FDI, _GLK, _INI, _PIC, _REG, _ROM, and _SxD.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b.
Test Description: Test Not Specified

3.25.71 The _SBC object name is not defined by the ACPI Specification, Revision 1.0b and must not be implemented in a system that claims to be 1.0b compliant. This object was previously defined in ACPI Specification 1.0.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b.
Test Description: TD-3.24 Reserved Name Usage Test

3.25.72 The system implements _ADR for the USB root hub and ports as defined in ACPI 1.0b, Section 6.1, Table 6-1.

Reference document: WLP# - A1.1.2, B2.6.4.1, B2.6.4.8; ACPI Specification, Revision 1.0b, Section 6.1, Table 6-1.
Test Description: TD-3.28 USB Root Hub _ADR Test Description

3.25.73 If implemented, the system implements the _INI control method as specified in ACPI 1.0b, Section 6.5.1.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 6.5.1.
Test Description: Test Not Specified


ACPI Interrupt 15h Function E820h Query System Address Map BIOS Assertions

The following ACPI interrupt 15h function E820h Query System Address Map BIOS assertions implement ACPI.

These assertions are tested in TD-3.21 ACPI Pre-OS: Interrupt 15h Function E820h System Address Map (I15_E820) Test Description.

3.26.1 The BIOS interrupt 15h function E820h Query System Address Map function returns a memory map of all installed RAM and of physical memory ranges reserved by the BIOS.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 14.1 and 14.2.
Test description: TD-3.21 ACPI Pre-OS: Interrupt 15h Function E820h System Address Map (I15_E820)

3.26.2 The BIOS interrupt 15h function E820h Query System Address Map function returns a memory map through successive calls to this API, each returning physical address information.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 14.1 and 14.2.
Test description: TD-3.21 ACPI Pre-OS: Interrupt 15h Function E820h System Address Map (I15_E820)

3.26.3 The BIOS interrupt 15h function E820h Query System Address Map function implements the input and output register interface.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0, Section 14.1.
Test description: TD-3.21 ACPI Pre-OS: Interrupt 15h Function E820h System Address Map (I15_E820)

3.26.4 A minimum buffer size of 20 bytes is required for the BIOS interrupt 15h function E820h Query System Address Map.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 14.1 and 14.2.
Test description: TD-3.21 ACPI Pre-OS: Interrupt 15h Function E820h System Address Map (I15_E820)

3.26.5 The BIOS interrupt 15h function E820h Query System Address Map function returns address ranges describing base board memory and ISA or PCI memory that is contiguous with that base board memory.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 14.1 and 14.2.
Test description: TD-3.21 ACPI Pre-OS: Interrupt 15h Function E820h System Address Map (I15_E820)

3.26.6 The BIOS interrupt 15h function E820h Query System Address Map function does not return a range description for the memory mapping of PCI devices, ISA Option ROMs, and ISA Plug and Play cards.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 14.1 and 14.2.
Test description: TD-3.21 ACPI Pre-OS: Interrupt 15h Function E820h System Address Map (I15_E820)

3.26.7 The BIOS interrupt 15h function E820h Query System Address Map function returns address holes, defined by the chip set, which are not being used by devices as reserved.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 14.1 and 14.2.
Test description: TD-3.21 ACPI Pre-OS: Interrupt 15h Function E820h System Address Map (I15_E820)

3.26.8 The BIOS interrupt 15h function E820h Query System Address Map function returns reserved address ranges defined for base board memory-mapped I/O devices, such as Advanced Programmable Interrupt Controllers (APIC)s.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 14.1 and 14.2.
Test description: TD-3.21 ACPI Pre-OS: Interrupt 15h Function E820h System Address Map (I15_E820)

3.26.9 The BIOS interrupt 15h function E820h Query System Address Map function reserves all occurrences of the system BIOS, including the areas that are below 1 MB, at 16 MB (if present), and at the end of the 4 GB address space.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 14.1 and 14.2.
Test description: TD-3.21 ACPI Pre-OS: Interrupt 15h Function E820h System Address Map (I15_E820)

3.26.10 The BIOS interrupt 15h function E820h Query System Address Map function does not report standard PC address ranges, such as video memory at A0000h-BFFFFh.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 14.1 and 14.2.
Test description: TD-3.21 ACPI Pre-OS: Interrupt 15h Function E820h System Address Map (I15_E820)

3.26.11 The BIOS interrupt 15h function E820h Query System Address Map function reports the range from E0000h-EFFFFh that applies to the base board because it is specific to that base board.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 14.1 and 14.2.
Test description: TD-3.21 ACPI Pre-OS: Interrupt 15h Function E820h System Address Map (I15_E820)

3.26.12 The BIOS interrupt 15h function E820h Query System Address Map function reports all of lower memory as normal memory.

The operating system handles standard RAM locations that are reserved for specific uses, such as the IVT at 0:0 and the BIOS data area at 40:0.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 14.1 and 14.2.
Test description: TD-3.21 ACPI Pre-OS: Interrupt 15h Function E820h System Address Map (I15_E820)

3.26.13 The memory where the FACS structure resides must not be reported as system memory in the system's memory map.

E820h memory reporting interface reports the region as AddressRangeReserved (ACPI Non-Volatile-Sleeping memory).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.2.6 and 9.3.2.
Test description: TD-3.21 ACPI Pre-OS: Interrupt 15h Function E820h System Address Map (I15_E820)

3.26.14 Memory identified by the BIOS that contains the ACPI tables must be marked as ACPI Reclaim Memory in the interrupt 15h function E820h memory map.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 9.3.2.
Test description: TD-3.21 ACPI Pre-OS: Interrupt 15h Function E820h System Address Map (I15_E820)

3.26.15 The memory information that is returned from interrupt 15h function E820h should be the same before and after an S4 sleep.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 9.3.2.
Test description: TD-3.21 ACPI Pre-OS: Interrupt 15h Function E820h System Address Map (I15_E820)


ACPI Embedded Controller BIOS Assertions

The following ACPI embedded controller BIOS assertions implement ACPI.

These assertions are tested in TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description.

3.27.1 The embedded controller's SMBus host controller's device object must contain _HID and _EC control methods.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 13.12.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.27.2 If the embedded controller firmware supports a shared interface between the ACPI operating system and the BIOS SMI handler, the SMI handler must use the SMI_EVT flag and an SMI query command to receive event notifications.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 13.5.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.27.3 The BIOS must acquire ownership of the Global Lock prior to interfacing with an embedded controller.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 13.7.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.27.4 All SMBus smart battery devices must be declared in ACPI name space (only a single device per smart battery subsystem).

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 11.1.4.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.27.5 The BIOS must follow the embedded controller interface protocol when communicating with an embedded controller.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Sections 13.7 and 13.9.2.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.27.6 The SMBus register set occupies 40 bytes of the embedded controller's I/O space.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 13.9.3.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.27.7 The embedded controller is defined as a device and must contain _HID, _CRS, and _GPE control methods.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Sections 4.7.4.4.2, 10.5 and 13.11.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.27.8 The _GPE embedded device control method returns the general purpose event bit to which this embedded controller is wired (SCI interrupt within the GPx_STS register -- bit assignment).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Sections 4.7.4.4.2, 10.5, and 13.11.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.27.9 The embedded device control _CRS current resource method returns the resources being consumed by the embedded controller, including the data port and the status/command port addresses.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Sections 4.7.4.4.2, 10.5, and 13.11.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.27.10 The _HID embedded device control method contains the ACPI device ID _HID value PNP0C09.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.4.4.2 and 13.11.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.27.11 Embedded controller query event handles are defined within the embedded controller's device as control methods.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 4.7.4.4.2.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.27.12 Embedded controller GPE event control methods must use the naming convention _QXX where XX is the hex format of the query code.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Sections 5.6.2.2.2 and 5.6.2.2.3.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.27.13 The PNP0C09 ACPI Device ID identifies a host embedded controller that is controlled through an ACPI-aware driver as specified in Sections 5.6.4 and 10.5.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Sections 4.7.4.2.2, 5.6.4, 10.5 and 13.11.1.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.27.14 The ACPI0001 ACPI Device ID identifies a SMBus host controller using the embedded controller interface.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Sections 5.6.4 and 13.12.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.27.15 The _EC control method defines the address offset and query value of a SMBus host controller defined within an embedded controller device.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Sections 5.6.5, 13.8, and 13.12.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description


ACPI Global Lock BIOS Assertions

The following ACPI BIOS / operating system global lock BIOS assertions implement ACPI.

These assertions are tested in TD-3.8 ACPI Global Lock (ACPIGLCK) Test Description.

3.28.1 The global lock is owned exclusively by either the operating system or the BIOS at any one time.

If the global lock is busy when ownership is attempted, the requesting environment exits and waits for the signal that the lock has been released.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.2.6.
Test description: TD-3.8 ACPI Global Lock (ACPIGLCK)

3.28.2 The global lock is a DWORD within read/write memory within the Firmware ACPI Control Structure.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.2.6.1.
Test description: TD-3.8 ACPI Global Lock (ACPIGLCK)

3.28.3 When global lock ownership fails, the requesting environment sets a pending state within the lock, exits its attempt to acquire the lock, and waits for the owning environment to signal that a lock has been released before attempting to reacquire a lock.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.2.6.1.
Test description: TD-3.8 ACPI Global Lock (ACPIGLCK)

3.28.4 When releasing the global lock, if the pending bit is set after the lock is released, a signal is sent using an inter-environment interrupt mechanism to the other environment to inform it that the lock has been released.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.2.6.1.
Test description: TD-3.8 ACPI Global Lock (ACPIGLCK)

3.28.5 During interrupt handling for a "lock released" event, an attempt to acquire the lock is made if lock ownership is still desired.

If ownership is not acquired, the pending bit is reset and the BIOS waits for another "lock release" signal.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.2.6.1.
Test description: TD-3.8 ACPI Global Lock (ACPIGLCK)

3.28.6 The global lock is required when a logical register in the hardware is shared.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.2.6.1.
Test description: TD-3.8 ACPI Global Lock (ACPIGLCK)

3.28.7 The operating system supplied \_GL global lock mutual exclusion object acquires the shared environment global lock.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.6.6.
Test description: TD-3.8 ACPI Global Lock (ACPIGLCK)

3.28.8 Devices requiring global lock ownership when accessing the device are implemented with the _GLK control method as specified in ACPI 1.0b, Section 6.5.6.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 6.5.6.
Test Description: Test Not Specified


ACPI Insert and Eject Media BIOS Assertions

The following ACPI insert and eject removable media BIOS assertions implement ACPI.

These assertions are tested in TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking (ACPIDOCK) Test Description.

3.29.1 The dynamic device insertion event control method uses the Notify(device,0) command to specify the bus the new device is on or the device object for the new device.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 6.3.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.29.2 If the Notify command points to the device object for the newly inserted device, the control method must have changed the device's status returned by _STA to indicate that the device is now present.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 6.3.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.29.3 The Notify command can also be used from the _WAK control method to indicate device changes that have occurred while the computer was sleeping.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 6.3.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.29.4 The dynamic device removal event control method uses the Notify(device,3) command to specify the device the user has requested to eject.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 6.3, sequence of events for dynamically removing a device, step 2; and Section 5.6.3, Table 5-21.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.29.5 If any mechanical failures were encountered while dynamically removing the device, _STA returns the message "3: device present and not functioning."

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 6.3.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.29.6 The surprise-style dynamic device removal event control method must use the Notify command to specify the bus from which the device was removed.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 6.3.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.29.7 An Ejection Request event can be notified only in response to a physical user action to remove the device (eject button pressed).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 5.6.3, Table 5-25.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.29.8 Whenever a device is ejected, the dependent device must receive an ejection notification as specified in Section 5.6.5.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 5.6.5, Table 5-33.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.29.9 The _EJD device insertion/removal object specifies the name of a device object upon which a device is dependent.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Sections 5.6.5, Table 5-33 and 6.3.1.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.29.10 The _EJx device insertion/removal control method ejects a device utilizing a software-controlled VCR-style ejection mechanism.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Sections 5.6.5, Table 5-33 and 6.3.2.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.29.11 The _LCK device insertion/removal control method utilizes a software-controlled locking mechanism to lock or unlock a device.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Sections 5.6.5, Table 5-33 and 6.3.3.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.29.12 The _RMV device insertion/removal object indicates that a device is removable while the system is in the working state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 5.6.5, Table 5-33 and 6.3.4.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.29.13 The _STA device insertion/removal control method specifies a device's status: enabled, disabled, or removed.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 5.6.5, Table 5-33 and 6.3.5.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.29.14 Devices that can be ejected include a _EJx control method for each sleeping state the device supports a maximum of 2 _EJx objects can be listed.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Sections 6.3 and 6.3.2.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.29.15 Devices that have a _EJD object cannot have any _EJx control methods.

This assertions is INVALID. The way _EJx methods works has changed. Windows 98 and Windows 2000 currently handle both handle _EJx/_EJD on the same node, and there are cases where both _EJD and _EJx must exist on the same device for it to work properly.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 6.3.1.

3.29.16 A _EJx control method is listed for each sleep state from which the device supports removal, where x is sleeping state supported.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Sections 6.3 and 6.3.2.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.29.17 Device must be immediately ejected when the _EJ0 control method is called.

The _EJ0 control method does not return until ejection is complete.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Sections 6.3 and 6.3.2.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.29.18 The EJ1-EJ4 control methods do not cause the device to be immediately ejected.

They set proprietary registers to prepare the hardware to eject when the system enters the specified sleep state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Sections 6.3 and 6.3.2.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.29.19 The first listed _EJx control method is the preferred sleeping state in which to eject the device.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Sections 6.3 and 6.3.2.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)

3.29.20 Any (working state) removable device that does not have _LCK or _EJx control methods must have a _RMV object.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 6.3.4.
Test description: TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK)


Legacy / ACPI State Transition BIOS Assertions

The following legacy / ACPI state transition and system control interrupt BIOS assertions implement ACPI.

These assertions are tested in TD-3.11 ACPI Pre-OS: Legacy to ACPI State Transition (ACPILAST) Test Description.

3.30.1 Traditional idle timers, trap monitors, and global standby timer are not used in ACPI mode.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.5 and 4.7.2.5.
Test description: TD-3.11 ACPI Pre-OS: Legacy to ACPI State Transition (ACPILAST) Test Description

3.30.2 The BIOS sets the SCI_EN bit to indicate that the system has successfully entered the ACPI mode.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.5 and 4.7.2.5.
Test description: TD-3.11 ACPI Pre-OS: Legacy to ACPI State Transition (ACPILAST) Test Description

3.30.3 Each GPEx_BLK general-purpose event register block contains equal length status (GPEx_STS) and enable (GPEx_EN) registers that are half the length of the GPEx_LEN value.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.1.6,4.7.4, 4.7.4.1.1 and 4.7.4.1.2.
Test description: TD-3.11 ACPI Pre-OS: Legacy to ACPI State Transition (ACPILAST) Test Description

3.30.4 When software issues an ACPI activate command to the SMI handler through the SMI command port, the BIOS acknowledges switching to ACPI mode by setting the SCI_EN system control interrupt enable bit.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.5 and 4.7.2.5.
Test description: TD-3.11 ACPI Pre-OS: Legacy to ACPI State Transition (ACPILAST) Test Description

3.30.5 The ACPI FACP table has an entry that indicates the interrupt to which the SCI system control interrupt is mapped.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.5 and 4.7.2.5.
Test description: TD-3.11 ACPI Pre-OS: Legacy to ACPI State Transition (ACPILAST) Test Description

3.30.6 Within the FACP tables are three values that signify the system I/O address (SMI_CMD) of the power management mode switch port, and the data values written to enable (ACPI_ENABLE) and disable (ACPI_DISABLE) the ACPI state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.5 and 4.7.2.5.
Test description: TD-3.11 ACPI Pre-OS: Legacy to ACPI State Transition (ACPILAST) Test Description

3.30.7 The SCI system control interrupt is a shareable, level-sensitive, active low interrupt, and mapped to a declared interrupt vector.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.5, 5.2.5 and 5.6.1.
Test description: TD-3.11 ACPI Pre-OS: Legacy to ACPI State Transition (ACPILAST) Test Description

3.30.8 When transitioning from legacy mode to ACPI G0 working state, BIOS clears the PM1x_STS and PM1x_EN registers prior to setting SCI_EN System Control Interrupt enable bit.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.3.1.1 and 4.7.3.1.2.
Test description: TD-3.11 ACPI Pre-OS: Legacy to ACPI State Transition (ACPILAST) Test Description

3.30.9 For ACPI-only platforms, the PM1x_STS and PM1x_EN registers are cleared before entering the G0 working state when transitioning from either the G3 mechanical off state or the soft off state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.3.1.1 and 4.7.3.1.2.
Test description: TD-3.11 ACPI Pre-OS: Legacy to ACPI State Transition (ACPILAST) Test Description

3.30.10 When transitioning ownership of the ACPI hardware registers from SMI (legacy mode) to ACPI mode, the system releases SMI ownership as timely as possible.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.2.5.
Test description: TD-3.11 ACPI Pre-OS: Legacy to ACPI State Transition (ACPILAST) Test Description

3.30.11 When transitioning from ACPI mode to legacy mode, the BIOS remaps all SCI events to legacy events and resets the SCI_EN bit.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 9.3.4.
Test description: TD-3.11 ACPI Pre-OS: Legacy to ACPI State Transition (ACPILAST) Test Description


ACPI Lid Switch BIOS Assertions

The following ACPI lid switch BIOS assertions implement ACPI.

These assertions are tested in TD-3.12 ACPI Pre-OS: ACPI Lid Switch (ACPILID) Test Description.

3.31.1 For systems with a lid, the lid status is implemented in AML code as a control method.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Sections 10.3 and 4.7.4.2.1.
Test description: TD-3.12 ACPI Pre-OS: ACPI Lid Switch (ACPILID)

3.31.2 The lid switch GPE event handler AML code re-configures the lid switch hardware (if it needs to) to generate an event in the other direction, clear the status, and notify the operating system of the event.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 4.7.4.2.1.
Test description: TD-3.12 ACPI Pre-OS: ACPI Lid Switch (ACPILID)

3.31.3 The lid switch device must contain a _LID control method that returns its status (open or closed).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Sections 4.7.4.2.1, 10.3, and 10.3.1.
Test description: TD-3.12 ACPI Pre-OS: ACPI Lid Switch (ACPILID)

3.31.4 If used, the lid switch must be defined as a (control method) device with _HID object value (ACPI Device ID) of "_PNP0C0D".

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Sections 4.7.4.2.1, 5.6.4, and 10.3.
Test description: TD-3.12 ACPI Pre-OS: ACPI Lid Switch (ACPILID)

3.31.5 A Lid Status Changed notification is issued when the control method lid device status has changed.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 5.6.3, Table 5-31.
Test description: TD-3.12 ACPI Pre-OS: ACPI Lid Switch (ACPILID)

3.31.6 This assertion was made obsolete by assertion 3.31.4.


ACPI Interrupt Routing BIOS Assertions

The following ACPI interrupt routing BIOS assertions implement ACPI.

These assertions are tested in TD-3.10 ACPI Pre-OS: Interrupt Routing (ACPIIRT) Test Description.

3.32.1 The Fixed ACPI Description Table INT_MODEL Interrupt Model field value is not allowed to change for a given machine, even across reboots.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.2.5.
Test description: TD-3.10 ACPI Pre-OS: Interrupt Routing (ACPIIRT) Test Description

3.32.2 The ACPI interrupt model describes all interrupts for the entire system in a uniform interrupt model implementation.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 10.3 and 4.7.4.2.1.
Test description: TD-3.10 ACPI Pre-OS: Interrupt Routing (ACPIIRT) Test Description

3.32.3 The ACPI interrupt model must remain constant for all time on any given system.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 10.3 and 4.7.4.2.1.
Test description: TD-3.10 ACPI Pre-OS: Interrupt Routing (ACPIIRT) Test Description

3.32.4 When using the APIC interrupt model, each processor is required to have a processor local APIC record and an ACPI processor object.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 10.3 and 4.7.4.2.1.
Test description: TD-3.10 ACPI Pre-OS: Interrupt Routing (ACPIIRT) Test Description

3.32.5 Processor information cannot change during the life of an operating system boot.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 10.3 and 4.7.4.2.1.
Test description: TD-3.10 ACPI Pre-OS: Interrupt Routing (ACPIIRT) Test Description

3.32.6 The Processor Local APIC Structure must be appended to the end of the Multiple APIC Descriptor Table and any other APIC structures present, and the length field of the Multiple APIC table updated accordingly.

Reference document: WLP# - A1.1.2; ACPI Specification, Errata, Revision 1.0, Section 5.2.8.2.
Test description: TD-3.10 ACPI Pre-OS: Interrupt Routing (ACPIIRT) Test Description

3.32.7 There is one IO APIC structure per IO APIC in the system.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.2.8.2.
Test description: TD-3.10 ACPI Pre-OS: Interrupt Routing (ACPIIRT) Test Description

3.32.8 The IO APIC Structure must be appended to the end of the Multiple APIC Descriptor Table and any other APIC structures present, and the length field of the Multiple APIC table updated accordingly.

Reference document: WLP# - A1.1.2; ACPI Specification, Errata, Revision 1.0, Section 5.2.8.2.
Test description: TD-3.10 ACPI Pre-OS: Interrupt Routing (ACPIIRT) Test Description

3.32.9 Systems that support both APIC and dual 8259 interrupt models must map interrupt vectors 0-15 to 8259 IRQs 0-15, except where Interrupt Source Overrides are provided.

Reference document: WLP# - A1.1.2; ACPI Specification, Errata, Revision 1.0, Section 5.2.8.3.
Test description: TD-3.10 ACPI Pre-OS: Interrupt Routing (ACPIIRT) Test Description

3.32.10 The Interrupt Source Override Structure must describe all ISA interrupts that are not identity-mapped into APIC interrupt space.

Reference document: WLP# - A1.1.2; ACPI Specification, Errata, Revision 1.0, Section 5.2.8.3.1.
Test description: TD-3.10 ACPI Pre-OS: Interrupt Routing (ACPIIRT) Test Description

3.32.11 The Interrupt Source Override Structure must be appended to the end of the Multiple APIC Descriptor Table and any other APIC structures present, and the length field of the Multiple APIC table updated accordingly.

Reference document: WLP# - A1.1.2; ACPI Specification, Errata, Revision 1.0, Section 5.2.8.3.1.
Test description: TD-3.10 ACPI Pre-OS: Interrupt Routing (ACPIIRT) Test Description

3.32.12 The non-maskable interrupt (NMI) Source Structure must be appended to the end of the Multiple APIC Descriptor Table and any other APIC structures present, and the length field of the Multiple APIC table updated accordingly.

Reference document: WLP# - A1.1.2; ACPI Specification, Errata, Revision 1.0, Section 5.2.8.3.2.
Test description: TD-3.10 ACPI Pre-OS: Interrupt Routing (ACPIIRT) Test Description

3.32.13 The _PRT device configuration object specifies the PCI interrupt routing table that describes the mapping of PCI interrupt pins to the interrupt vectors to which the pins are connected.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 6.2 and 6.2.3.
Test description: TD-3.10 ACPI Pre-OS: Interrupt Routing (ACPIIRT) Test Description

3.32.14 The function number in the _PRT packages must be FFFFh (any function number).

Reference document: WLP# - A1.1.2; ACPI Specification, Errata, Revision 1.0, Section 6.2.3.
Test description: TD-3.10 ACPI Pre-OS: Interrupt Routing (ACPIIRT) Test Description

3.32.15 If a PCI interrupt is hard-wired to specific interrupt vectors on the interrupt controller (not configurable), the _PRT source field is NULL and the _PRT source index field contains the global interrupt vector to which the PCI interrupt is hard wired.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.2.3.
Test description: TD-3.10 ACPI Pre-OS: Interrupt Routing (ACPIIRT) Test Description

3.32.16 If implemented, the system implements the _PIC control method as defined in ACPI Specification, Revision 1.0b Section 5.8.1.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Sections 5.8.1.
Test Description: Test Not Specified


ACPI Power Management Timer BIOS Assertions

The following ACPI power management timer BIOS assertions implement ACPI.

These assertions are tested in TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) Test Description.

3.33.1 The Fixed ACPI Table (FACP) contains a length variable (PM_TMR_LEN) for the PM_TMR_BLK register block that is equal to the size in bytes of the PM_TMR register.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.1.4 and 4.7.2.1.
Test description: TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT)

3.33.2 The FACP table indicates whether the power management timer is a 24-bit or 32-bit timer.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.1.4 and 4.7.2.1.
Test description: TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT)

3.33.3 The Fixed ACPI Description Table Feature Flags TMR_VAL_EXT field must be zero if TMR_VAL is implemented as a 24-bit value or 1 if TMR_VAL is implemented as a 32-bit value.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.2.5.
Test description: TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT)


ACPI Resource Configuration BIOS Assertions

The following ACPI resource configuration BIOS assertions implement ACPI.

These assertions are tested in D-3.16 ACPI Resource Configuration Test (ACPIRCT) Test Description.

3.34.1 Register block pointer addresses are set by the OEM as static resources, so they are never changed except that a Plug and Play driver cannot re-map ACPI resources.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.2 BIOS must supply a _HID object plus an optional _CID object for each device that is not on an enumerable type of bus such as, ISA.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.1.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.3 Device configuration objects must be provided only for devices that cannot be configured by any other hardware standard.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 6.2, 6.1.5 and 6.2.5.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.4 Devices that share a resource must use the extended resource descriptors (7-0Ah).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 6.2, 6.1.5 and 6.2.5.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.5 The PNP0C08 ACPI Device ID identifies the hardware resources consumed by the ACPI fixed register spaces and the operation regions used by the AML code.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.6.4.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.6 The PNP0C0F ACPI Device ID identifies a device that allocates an interrupt connected to a PCI interrupt pin.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.6.4.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.7 PNP0A05 ACPI Device ID identifies a bus device whose bus settings are totally controlled by its ACPI resource information.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.4 and 10.7.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.8 PNP0A06 ACPI Device ID identifies a device that is only a bus and whose bus settings are totally controlled by its ACPI resource information.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.4 and 10.7.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.9 The _ADR device identification object specifies a device's address on its parent bus.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5 and 6.1.1.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.10 The _CID device identification object specifies a device's Plug and Play Compatible ID list, in the order of preference.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5 and 6.1.2.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.11 The _HID device identification object specifies a device's Plug and Play Hardware ID.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5 and 6.1.3.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.12 The _UID device identification object specifies a device's unique persistent ID numeric value or string, or the object is a control method that generates it (for example, docking station ID) as specified in Sections 5.6.5 and 6.1.5.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5 and 6.1.5.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.13 The _CRS device identification object byte stream specifies a device's current resource settings or is a control method that generates such an object.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5 and 6.2.1.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.14 The _DIS device configuration control method disables a device.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5 and 6.2.2.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.15 The _PRS device configuration object specifies a device's possible resource settings or is a control method that generates such an object.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5 and 6.2.4.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.16 The _SRS device configuration control method specifies a new resource allocation for a device.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5 and 6.2.5.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.17 The ACPI BIOS must supply a _ADR object for each device on an enumerable type of bus (for example, PCI).

A _ADR object must be used to specify the address of any device on a bus that has a standard enumeration algorithm.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 6.1 and 6.1.1.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.18 The _SUN device identification object specifies the DWORD slot unique identification (UI) number for a slot.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 6.1 and 6.1.4.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.19 A _ADR object information must be static.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.1.1.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.20 The _CID objects must be used when a device has no other defined hardware standard method to report its compatible IDs.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.1.2.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.21 A _HID object must be used to describe any device that is enumerated by the ACPI driver.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.1.3.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.22 The _UID object is required when the device has no other way to report a persistent unique device ID.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 6.2, 6.1.5 and 6.2.5.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.23 When a system has two devices that report the same _HID, each device must have a _UID object.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 6.2, 6.1.5 and 6.2.5.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.24 The _UID must be unique amongst all devices with the same device ID.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 6.2, 6.1.5 and 6.2.5.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.25 The _FDI device configuration object returns the same floppy drive information as that returned by the Int 13h function 8.

Reference document: WLP# - A1.1.2; ACPI Specification, Errata, Revision 1.0, Sections 6.2 and 6.2.5a.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.26 The _CRS object for a bus device must supply the resources that the bus device decodes and can assign to its children devices.

Reference document: WLP# - A1.1.2; ACPI Specification, Errata, Revision 1.0, Section 6.2.1.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.27 If a device is disabled, _CRS returns a valid resource template for the device.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.2.1.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.28 If the device is disabled when _CRS is called, it must remain disabled.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a. Section 6.2.1.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.29 When a device is disabled via the _DIS disable control method, the _STA current status control method for this device must return with the disabled bit set.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.2.2.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.30 A _PRS object must be specified for all configurable devices as specified in Section 6.2.4.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.2.4.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.31 If the device is disabled when _PRS is called, it must remain disabled.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.2.4.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.32 Resource descriptors in the _SRS byte stream argument must be specified in the same order as they are listed in the _CRS byte stream.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 6.2, 6.1.5 and 6.2.5.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.33 The new resource allocation settings must take effect before the _SRS control method returns.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 6.2, 6.1.5 and 6.2.5.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.34 If the device is disabled, _SRS enables the device at the specified resources.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 6.2, 6.1.5 and 6.2.5.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.35 The _SRS control method is not used to disable a device; use the _DIS control method instead.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 6.2, 6.1.5 and 6.2.5.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.36 If a device is decoding its hardware resources, both _STA bits 0 (present) and 1 (enabled and decoding resources) must be set.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.3.5.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.37 If _STA bit 0 is cleared (device not present), bit 1 must also be cleared (disabled and not decoding resources).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.3.5.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.38 The IRQ small resource data structure indicates that the device uses an interrupt level and supplies a mask with bits set to indicate the level implemented in the device.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.4.2.1.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.39 The IRQ small resource data structure is repeated for each separate interrupt required by a device.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.4.2.1.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.40 If the IRQ small resource data structure byte 3 is not specified, the default structure is high, true, edge sensitive and non-shareable.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.4.2.1.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.41 The DMA small resource data structure indicates that the device uses a DMA channel and supplies a mask with bits set to indicate the channels actually implemented in the device.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.4.2.2.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.42 The DMA small resource data structure is repeated for each separate DMA channel required by a device.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.4.2.2.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.43 Dependent functions are used to express device resource interdependencies.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.4.2.3.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.44 If multiple dependent functions have the same priority, they are further prioritized by the order in which they appear in the resource data structure.

The dependent function that appears earliest in the structure has highest priority.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.4.2.3.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.45 Only one end-dependent function item is allowed per logical device. Dependent functions cannot be nested.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.4.2.4.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.46 The I/O Port Descriptor small resource data structure indicates that a device uses I/O ports.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.4.2.5.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.47 The small resource data structure for the Fixed Location I/O Port Descriptor indicates that a device use 10-bit ISA address decode I/O locations.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 6.4.2.5 and 6.4.2.6.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.48 The End Tag identifies the end of resource data.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.4.2.8.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.49 If the End Tag checksum field is zero, the resource data is treated as if the checksum operation succeeded.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.4.2.8.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.50 The large resource data structure for the 24-bit Memory Range Descriptor specifies a device's memory range resources within a 24-bit address space.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.4.3.1.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.51 Address bits [7:0] of 24-bit memory base addresses are assumed to be 0.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.4.3.1.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.52 A 24-bit memory range descriptor can be used to describe a fixed memory address by setting the range minimum base address and the range maximum base address to the same value.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.4.3.1.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.53 Mixing of 24-bit and 32-bit memory descriptors on the same device is not allowed.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 6.4.3.1, 6.4.3.3 and 6.4.3.4.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.54 The large resource data structure for the 32-bit Memory Range Descriptor specifies a device's memory range resources within a 32-bit address space, as specified in Section 6.4.3.3.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.4.3.3.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.55 The large resource data structure for the 32-bit Fixed Location Memory Range Descriptor specifies a device's memory range resources within a 32-bit address space.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.4.3.4.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.56 The large resource data structure for the QWORD Address Space Descriptor reports resource usage in a 64-bit address space.

Reference document: WLP# - A1.1.2; ACPI Specification, Errata, Revision 1.0, Section 6.4.3.5.0a.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.57 QWORD, DWORD, and WORD Address Space Descriptors must set all Address Space Granularity bits lower than the most significant set bit.

Reference document: WLP# - A1.1.2; ACPI Specification, Errata, Revision 1.0, Sections 6.4.3.5.0a, 6.4.3.5.1 and 6.4.3.5.3.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.58 Bridge devices that implement QWORD, DWORD, or WORD Address Space Descriptors must specify the address space on the primary side of the bridge for the Address Range Minimum and Address Range Maximum fields.

Reference document: WLP# - A1.1.2; ACPI Specification, Errata, Revision 1.0, Sections 6.4.3.5.0a, 6.4.3.5.1 and 6.4.3.5.3.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.59 Bridge devices that implement QWORD, DWORD, or WORD Address Space Descriptors must specify the offset that must be added to the address on the primary side to obtain the address on the secondary side for the Address Translation Offset fields.

Reference document: WLP# - A1.1.2; ACPI Specification, Errata, Revision 1.0, Sections 6.4.3.5.0a, 6.4.3.5.1 and 6.4.3.5.3.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.60 Non-bridge devices that implement QWORD, DWORD, or WORD Address Space Descriptors must specify 0 for all Address Translation Offset fields.

Reference document: WLP# - A1.1.2; ACPI Specification, Errata, Revision 1.0, Sections 6.4.3.5.0a, 6.4.3.5.1 and 6.4.3.5.3.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.61 A device that implements QWORD, DWORD, or WORD Address Space Descriptors that consume resources from its hierarchical parent must specify valid values for the Resource Source Index and the Resource Source.

Reference document: WLP# - A1.1.2; ACPI Specification, Errata, Revision 1.0, Sections 6.4.3.5.0a, 6.4.3.5.1 and 6.4.3.5.3.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.62 The large resource data structure for the DWORD Address Space Descriptor reports resource usage in a 32-bit address space.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.4.3.5.1.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.63 The large resource data structure for the WORD Address Space Descriptor reports resource usage in a 16-bit address space.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.4.3.5.3.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.64 The Memory Resource Flag in the Type Specific Flags field of the Address Space Descriptors defines the cacheability and read-write versus read-only memory access status.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.4.3.5.5.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.65 The I/O Resource Flag in the Type Specific Flags field of the Address Space Descriptors defines the ISA and non-ISA I/o address handling.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.4.3.5.5.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.66 Systems that support interrupts above 15 must use the large resource data structure for the Extended Interrupt Descriptor.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.4.3.6.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.67 If the system supports interrupts above 15, but the operating system uses the 8259 interrupt model, only interrupt number values of 0-15 are used and interrupt numbers greater than 15 are ignored as specified in Section 6.4.3.6.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.4.3.6.
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

3.34.68 The _BBN control method returns the PCI bus number the BIOS sets up in a multi-root PCI system.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 6.5.5
Test description: TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description


ACPI Real-time Clock and RTC Alarm BIOS Assertions

The following ACPI real-time clock and real-time clock alarm BIOS assertions implement ACPI.

These assertions are tested in TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description.

3.35.1 If the S4 wakeup by RTC is supported, the RTC_S4 within the FACP table flag is set HIGH.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.4 and 4.7.3.1.1.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.35.2 If the day alarm field (DAY_ALRM) is supported, DAY_ALRM points to a CMOS RAM location to select a day within a month to generate an RTC alarm.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.4 and 4.7.3.1.1.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.35.3 If the month alarm field (MON_ALRM) is supported, MON_ALRM points to a CMOS RAM location to select the month within the year to be used to generate an RTC alarm with DAY_ALARM.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.4 and 4.7.3.1.1.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.35.4 If the century value field (CENT) is supported, CENT points to a CMOS RAM location to select the century value of the date to generate an RTC alarm with DAY_ALARM.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.4 and 4.7.3.1.1.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.35.5 DAY_ALRM is an 8-bit value that can represent 0x01-0x31 days in BCD or 0x01-0x1F days in binary.

Bits 6 and 7 are ignored.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.4 and 4.7.3.1.1.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.35.6 The RTC is initialized so that the DAY_ALRM RTC field contains any unused value, often called a "don't care value," when the BIOS switches from legacy to ACPI mode.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.4 and 4.7.3.1.1.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.35.7 When DAY_ALRM RTC day alarm field contains a don't care (any unused value), the RTC reverts back to a 24 hour alarm.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.4 and 4.7.3.1.1.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.35.8 MON_ALRM is an 8-bit value that can represent 0x01-0x12 months in BCD or 0x01-0x0C months in binary.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.4 and 4.7.3.1.1.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.35.9 The RTC is initialized so the month alarm field (MON_ALRM RTC) contains any unused value when the BIOS switches from legacy to ACPI mode.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.4 and 4.7.3.1.1.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.35.10 When the MON_ALRM RTC month alarm field contains a don't care (any unused value), the RTC reverts back to a 24 hour and/or 31 day alarm.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.4 and 4.7.3.1.1.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.35.11 The CENT is an 8-bit BCD or a binary value that indicates the thousand and hundred year values of the RTC alarm date used with DAY_ALARM.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.4 and 4.7.3.1.1.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.35.12 The Fixed ACPI Description Table Feature Flags field (FIX_RTC) must contain 0 if the RTC wake-up status and enable bits are supported in fixed register space or 1 if they are not supported in fixed register space.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.4 and 5.2.5.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.35.13 Fixed ACPI Description Table field (DAY_ALRM) must contain zero if RTC day of month alarm feature is not supported.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.4 and 5.2.5.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.35.14 Fixed ACPI Description Table field (MON_ALRM) must contain zero if RTC month of year alarm feature is not supported.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.4 and 5.2.5.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.35.15 If the RTC month alarm (MON_ALRM) is supported, the DAY_ALRM RTC day alarm function must also be supported.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.4 and 5.2.5.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.35.16 The Fixed ACPI Description Table CENTURY field must contain zero if the RTC century feature is not supported.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.4 and 5.2.5.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.35.17 If the RTC was the cause of the wakeup from an S1-S3 state, the PM1x_STS register RTC_STS RTC alarm status bit is set prior to returning control to the operating system.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.4 and 4.7.3.1.1.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.35.18 If the RTC was the cause of the wakeup from an S4 state and the RTC_S4 flag within the FACP table is set, the PM1x_STS register RTC_STS RTC alarm status bit is set before returning control to the operating system.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.4 and 4.7.3.1.1.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.35.19 The Fixed ACPI Description Table RCT_S4 Feature Flags field must contain 0 if the RTC alarm function can't wake the system from the S4 sleep state or 1 if the RTC alarm function can wake the system from the S4 sleep state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.2.5.
Test description: TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

3.35.20 If supported, the system implements RTC_EN as specified in ACPI Specification, Revision 1.0b, Section 4.7.3.1.2, Table 4-10.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 4.7.3.1.2, Table 4-10.
Test Description: Test Not Specified


ACPI Sleep / Wake Power State Transition BIOS Assertions

The following ACPI sleep / wake power state transition BIOS assertions implement ACPI. These assertions are tested in TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.1 The PowerResource statement or object must specify the lowest power system sleep level needed to keep this power resource on.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 7.1 and 9.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.2 Each power-managed ACPI device lists the resources it requires for its supported power levels.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 7.1 and 9.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.3 Each power resource object must have each of _STA, _ON, and _OFF control methods.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.4.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.4 The power resource description for each device specifies lowest Dx device power state in which that device still supports wakeup.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 9.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.5 To initiate a transition into S4 BIOS sleeping state, the ACPI driver passes control to the BIOS by writing the S4 BIOS_REQ value to the SMI_CMD port.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 9.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.6 The BIOS determines which Sx system sleep state was awakened from by examining the SLP_TYP register.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 7.1 and 9.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.7 When waking from an S2 system sleep state, the BIOS enables the memory controller to accept memory accesses and reconfigures the caches prior to calling the ACPI waking vector.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 7.1 and 9.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.8 When waking from an S3 or S4 system sleep state or when booting, the BIOS enables the memory controller to accept memory accesses and reconfigures the caches which enables system access to memory and caches.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 7.1 and 9.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.9 If the memory controller's configuration is lost while in the S3 system sleep state, this configuration information should be stored in BIOS non-volatile memory (such as, RTC CMOS memory) before suspending.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 7.1 and 9.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.10 Power button support is indicated by one of the three following conditions: no PB => PWR_BUTTON=1 and device object absent, the fixed feature PB => PWR_BUTTON=0 and device object absent, or the control method PB => PWR_BUTTON=1 and device object present.

Reference document: WLP# - A1.1.2, B5.1.4.1; ACPI Specification, Revision 1.0a, Sections 4.7.2.2.1, 4.7.3.1.1, 4.73.1.2 and 5.2.5.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.11 If the power button programming model uses the generic programming model, the AML event handler must generate a Notify command for each power button event generated.

Reference document: WLP# - A1.1.2, B5.1.4.1; ACPI Specification, Revision 1.0a, Sections 4.7.2.2.1.2 and 10.4.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.12 While the system is in the S0 working state, and if the power button programming model uses the generic programming model, the power button AML event handler issues Power Button Pressed Notify command with the device specific code of 0x80.

Reference document: WLP# - A1.1.2, B5.1.4.1; ACPI Specification, Revision 1.0a, Sections 4.7.2.2.1.2, 5.6.3 and 10.4.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.13 Upon waking from a G1 (S1-S4) sleeping state, and if the power button programming model uses the generic programming model, the power button AML event handler issues the Device Wake Notify command with the device specific code of 0x2.

Reference document: WLP# - A1.1.2, B5.1.4.1; ACPI Specification, Revision 1.0a, Sections 4.7.2.2.1.2, 5.6.3 and 10.4.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.14 If the power button programming model uses the generic programming model, the power button device must be defined within ACPI name space with a _HID object value (ACPI Device ID) of "PNP0C0C" which identifies this device as the power button.

Reference document: WLP# - A1.1.2, B5.1.4.1; ACPI Specification, Revision 1.0a, Sections 4.7.2.2.1.2 and 5.6.4.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.15 Sleep button support is indicated by one of the three following conditions: no SB => SLEEP_BUTTON=1 and device object absent, the fixed feature SB => SLEEP_BUTTON=0 and device object absent, or the control method SB =>SLEEP_BUTTON=1 and device object present.

Reference document: WLP# - A1.1.2, B5.1.4.1; ACPI Specification, Revision 1.0a, Sections 4.7.2.2.2, 4.7.3.1.1, 4.7.3.1.2 and 5.2.5.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.16 If the sleep button programming model uses the generic programming model, the AML event handler must generate a Notify command for each sleep button event generated.

Reference document: WLP# - A1.1.2, B5.1.4.1; ACPI Specification, Revision 1.0a, Sections 4.7.2.2.2.2 and 10.4.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.17 If the sleep button programming model uses the generic programming model, while the system is in the S0 working state, the sleep button AML event handler issues the Sleep Button Pressed Notify command with the device specific code of 0x80.

Reference document: WLP# - A1.1.2, B5.1.4.1; ACPI Specification, Revision 1.0a, Sections 4.7.2.2.2.2, 5.6.3 and 10.4.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.18 Upon waking from a G1 (S1-S4) sleeping state and if the sleep button programming model uses the generic programming model, the sleep button AML event handler issues the Device Wake Notify command with the device specific code of 0x2.

Reference document: WLP# - A1.1.2, B5.1.4.1; WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7.2.2.2.2, 5.6.3 and 10.4.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.19 If the sleep button programming model uses the generic programming model, the sleep button device must be defined within the ACPI name space with a _HID object value (ACPI Device ID) of "PNP0C0E" which identifies this device as the sleep button.

Reference document: WLP# - A1.1.2, B5.1.4.1; ACPI Specification, Revision 1.0a, Sections 4.7.2.2.2.2 and 5.6.4.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.20 The sleeping/wake logic is controlled by two bit fields: SLP_EN Sleep Enable and SLP_TYPx Sleep Type.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.2.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.21 Supported values for the SLP_TYPx field are included in the \_Sx objects defined in the static definition block.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.2.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.22 When waking from the S2-S5 states, the execution control is passed to BIOS software and execution begins at CPU's reset vector.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.2.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.23 If the power button was the cause of the wakeup from an S1-S4 state, the power button status bit (PM1x_STS register PWRBTN_STS) is set before to returning control to the operating system.

Reference document: WLP# - A1.1.2, B5.1.4.1; ACPI Specification, Revision 1.0a, Section 4.7.3.1.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.24 If the sleep button was the cause of the wakeup from an S1-S4 state, the sleep button status bit (PM1x_STS register SLPBTN_STS) is set before to returning control to the operating system.

Reference document: WLP# - A1.1.2, B5.1.4.1; ACPI Specification, Revision 1.0a, Section 4.7.3.1.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.25 If general-purpose register block registers do not maintain context across sleeping or soft off states, the BIOS must reset the respective enable bit prior to passing control to the operating system upon awakening.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.4.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.26 The Firmware ACPI Control Structure Flags field S4BIOS_F flag value must be zero if the Fixed ACPI Description Table S4BIOS_REQ capability is not supported.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.2.5.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.27 On PC platforms with Intel Architecture, the A20 address line must be enabled when the BIOS jumps to the real mode address derived from the physical address stored in the Firmware ACPI Control Structure firmware waking vector.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.2.6.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.28 During POST, the BIOS checks the Firmware ACPI Control Structure firmware waking vector field value and transfers control to the specified address, if the waking vector field value is non-zero.

Control is transferred while in real mode.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.2.6 and 9.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.29 A device's _PRW object provides the zero-based bit index into the general purpose status register block to indicate the general-purpose status bit from either GPE0_BLK or GPE1_BLK that is used as the specific device wake mask.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.62.2.4.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.30 The OEM AML code (_PSW control method) is responsible for the second-level GPE enable and status bits.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.6.2.2.4.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.31 A Device Wake event notification is issued when a device has signaled its wake event and the operating system needs to notify device driver.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.6.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.32 Device Wake notification type is only used for devices that support power management object (_PRW).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.6.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.33 The _PRW power management object specifies a device's power requirements to wake the system from a system sleeping state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5 and 7.2.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.34 The _PSW power management control method enables or disables a device's wake function, the device's ability to wake a sleeping system.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5 and 7.3.2.
Test description: Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.35 The \_PTS power management control method allows the BIOS to perform maintenance and so on, prior to the system going to sleep.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5 and 7.5.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.36 The \_S0 power management package defines the system \_S0 working state mode.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5, 7.5.2.1 and 9.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.37 The \_S1 power management package defines the system \_S1 sleeping state mode.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5, 7.5.2.2 and 9.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.38 The \_S2 power management package defines the system \_S2 sleeping state mode.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5, 7.5.2.3 and 9.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.39 The \_S3 power management package defines the system \_S3 sleeping state mode.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5, 7.5.2.4 and 9.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.40 The \_S4 power management package defines the system \_S4 sleeping state mode.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5, 7.5.2.5 and 9.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.41 The \_S5 power management package defines the system \_S5 soft off state mode.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5, 7.5.2.6 and 9.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.42 The \_WAK power management control method is run when the system is awakened.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5 and 7.5.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.43 The power resource object resource order field is an unique value for each power resource and provides the system with the sequencing and serialization order that power resources must be enabled or disabled (for example, due to inrush current load).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 7.1 and 7.3.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.44 The _PRW wake power requirements object must be supported for devices that have the ability to wake the system from a sleeping state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.2.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.45 The _PRW wake power requirements package must specify the GPEx_EN enable bit index for the wake event.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.2.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.46 The _PRW wake power requirements package must specify the lowest power system sleeping state that can be entered while still providing wake functionality.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.2.1
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.47 The _PRW wake power requirements package must specify all dependent power resource object references.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.2.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.48 The _PRx power requirements package must specify the lowest power system sleeping state in which the device can still maintain the specified power state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.2.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.49 The _PSW control method only can access operation regions that are either always available while in a system working state, or that are only available when the power resources referenced by the _PRW object are all ON.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.3.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.50 The _PS0 control method only can access operation regions that are either always available while in a system working state or are available when the power resources referenced by the _PR0 object are all ON.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.3.4.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.51 The _PS1 control method only can access operation regions that are either always available while in a system working state, or that are available when the power resources referenced by the _PR1 object are all ON.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.3.5.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.52 The _PS2 control method only can access operation regions that are either always available while in a system working state, or that are available when the power resources referenced by the _PR2 object are all ON.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.3.6.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.53 The _PS3 control method only can access operation regions that are always available while in a system working state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.3.7.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.54 The _ON control method execution flow does not complete (return) until the power resource is on.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.4.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.55 The _OFF control method does not complete until the power resource is on.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.4.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.56 The _PTS prepare to sleep control method cannot modify the current configuration or power state of any device in the system.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.5.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.57 All system states supported by the system must provide a _Sx object/package for that state in the static Definition Block.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.5.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.58 The system state package must specify the PM1a_CNT.SLP_TYP register value for the specified system state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.5.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.59 The system state package must specify the PM1b_CNT.SLP_TYP register value for the specified system state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.5.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.60 When waking from an S2 system sleep state, the BIOS begins execution at its boot location, performs initialization of core functions as needed, then passes control to the FACS firmware resume vector.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.5.2.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.61 When waking from the S2 system sleep state, the BIOS is required to program the initial boot configuration of the CPU, such as MSRs and MTRRs, initialize the cache controller to its initial boot size and configuration, enable the memory controller to accept memory accesses, and call the waking vector.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 9.1.2.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.62 When waking from an S3 system sleep state, the BIOS begins execution at its boot location, performs initialization of core functions as needed, and passes control to the FACS firmware resume vector.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.5.2.4.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.63 When waking from the S3 system sleep state, the BIOS is required to program the initial boot configuration of the CPU, such as MSRs and MTRRs, then initialize the cache controller to its initial boot size and configuration, enable the memory controller to accept memory accesses, and jump to the waking vector.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 9.1.3.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.64 Any system that supports S4BIOS is required to support entering the S4 state via the direct operating system mechanism (S4 operating system).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 7.5.2.5 and 9.1.4.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.65 When waking from an S4 operating system sleep state, BIOS begins execution at its boot location, performs initialization of core functions, such as chipset or memory controller as needed, loads the operating system loader, then passes control to the operating system loader.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 7.5.2.5, 9.1.4.4 and 9.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.66 When transitioning into the S4BIOS system sleep state, the BIOS saves a copy of chipset and memory context to disk and initiates the hardware S4 sequence.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 7.5.2.5 and 9.1.4.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.67 When waking from the S4BIOS system sleep state, the BIOS begins execution at its boot location, performs initialization of core functions as needed, restores memory from disk, then transfers control to the FACS waking vector.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 75.2.5, 9.1.4.2 and 9.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.68 The BIOS maintains a state value to distinguish whether or not the boot is going to wake from a saved memory image.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.5.2.6.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.69 The _WAK system wake control method occurs asynchronously with other driver notifications in the system and is not the first action to be taken when the system wakes up.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.5.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.70 The _WAK system wake control method AML code issues device, thermal, and other notifications to ensure that the operating system checks the state of devices, thermal zones, and so on, that could not be maintained during the system sleeping state.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.5.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.71 The _WAK system wake control method returns a status bit mask indicating pass/fail and cause of failure status.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.5.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.72 If the _WAK system wake control method returns a non-zero PSS value, it must specify the effective Sx system state the power supply really entered.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 7.5.3.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.73 If the hardware configuration has changed during an S4 transition that was initiated by the operating system, the BIOS should update the hardware signature in the FACS table before passing control to the operating system.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 9.1.4.1.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.74 If the platform supports the S4BIOS state, the FACS memory structure S4BIOS_F flag must be set before the operating system issues the ACPI_ENABLE command.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 9.1.4.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.75 Coming out of the S4BIOS state, the BIOS must only configure boot devices.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 9.1.4.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.76 In the S5 soft off system state, no context (such as, memory and I/O) is saved by the BIOS.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 9.1.5.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.77 Upon waking from an S5 soft off system state, BIOS does a normal power-on reset, loading and executing the boot sector.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 9.1.5.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

3.36.78 The BIOS must provide a package containing 4 bytes defined by table 7-7 System State Package for all system states supported by the system.

The first package byte is the value to be written to PM1a_CNT.SLP_TYP register to enter this system state. The second package byte is the value to be written to PM1b_CNT.SLP_TYP register to enter this system state. The third and fourth package bytes are reserved.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 7.5.2.
Test description: TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description


ACPI Thermal Management BIOS Assertions

The following ACPI thermal management BIOS assertions implement ACPI.

These assertions are tested in TD-3.19 ACPI Thermal Management (ACPITHRM) Test Description and TD-3.25 Thermal Model Test and TD-3.27 ACPI Pre-OS: ACPI BBN Resolution Test Description.

3.37.1 Thermal zones reference fan device(s) as being responsible for primarily cooling within that zone.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 10.6.
Test description: TD-3.19 ACPI Thermal Management (ACPITHRM) Test Description

3.37.2 The AML code must execute a Notify (thermal_zone, 81h) statement to request the operating system to re-evaluate each policy temperature by running the _PSV and _ACx control methods.

Reference document: WLP# - A1.1.2; ACPI Specification, Errata, Revision 1.0, Section 12.1.2.
Test description: TD-3.19 ACPI Thermal Management (ACPITHRM) Test Description

3.37.3 The system must disable the power either after the temperature reaches some hardware-determined level above _CRT critical temperature or after a predetermined time has passed.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 12.16.
Test description: TD-3.19 ACPI Thermal Management (ACPITHRM) Test Description

3.37.4 If the active cooling device has one cooling level ("on"), that cooling level control method is named _AC0.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 12.3.1 and 5.6.3.
Test description: TD-3.19 ACPI Thermal Management (ACPITHRM) Test Description

3.37.5 The smaller the value of x, the greater the cooling strength that the _ACx active cooling device control method represents.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 12.3.1 and 5.6.3.
Test description: TD-3.19 ACPI Thermal Management (ACPITHRM) Test Description

3.37.6 Every active cooling device control method (_ACx), must have a matching _ALx active cooling device list control method.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 12.3.1 and 5.6.3.
Test description: TD-3.19 ACPI Thermal Management (ACPITHRM) Test Description

3.37.7 A (fan) device that causes cooling when "on" (D0 device state) is defined with the Plug and Play ACPI Device ID of "PNP0C0B".

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.7, 4.4.3, 5.6.4 and 10.6.
Test description: TD-3.19 ACPI Thermal Management (ACPITHRM) Test Description

3.37.8 A Thermal Zone Status Change notification is issued when the thermal zone temperature has changed enough to put the thermal zone into a different state (e.g. active, passive, etc.).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 12.3.1 and 5.6.3.
Test description: TD-3.19 ACPI Thermal Management (ACPITHRM) Test Description

3.37.9 A Thermal Zone Trip Points Changed notification is issued when the thermal zone trip points have changed.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 12.3.1 and 5.6.3.
Test description: TD-3.19 ACPI Thermal Management (ACPITHRM) Test Description

3.37.10 The _DCL thermal zone object lists pointers to bay device objects within the thermal zone.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.6.5.
Test description: TD-3.19 ACPI Thermal Management (ACPITHRM) Test Description

3.37.11 The _ACx thermal zone object returns the active trip point, the temperature at which the active cooling is enabled or disabled in Kelvin to 0.1 degrees.

The value of x lies between 0 and 9, designating multiple active cooling levels of the thermal zone.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5, 12.1.4 and 12.3.1.
Test description: TD-3.19 ACPI Thermal Management (ACPITHRM) Test Description

3.37.12 The _ALx thermal zone object lists pointers to the active cooling device objects to be turned on when the associated _ACx trip point is exceeded.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5, 12.1.4 and 12.3.2.
Test description: TD-3.19 ACPI Thermal Management (ACPITHRM) Test Description

3.37.13 The _TSP thermal zone object specifies the passive cooling thermal sampling period.

The operating system uses this time interval for polling the hardware to sample the temperature.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5, 12.1.5 and 12.3.10.
Test description: TD-3.19 ACPI Thermal Management (ACPITHRM) Test Description

3.37.14 The _TC1 thermal zone object specifies the thermal constant for passive cooling.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5, 12.1.5 and 12.3.7.
Test description: TD-3.19 ACPI Thermal Management (ACPITHRM) Test Description

3.37.15 The _TC2 thermal zone object specifies the thermal constant for passive cooling.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5, 12.15 and 12.3.8.
Test description: TD-3.19 ACPI Thermal Management (ACPITHRM) Test Description

3.37.16 The _TMP thermal zone object specifies the thermal zone's current operating temperature in Kelvin to 0.1 degrees.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5, 12.15 and 12.3.9.
Test description: TD-3.19 ACPI Thermal Management (ACPITHRM) Test Description

3.37.17 The _CRT thermal zone object specifies the critical temperature trip point in Kelvin to 0.1 degrees.

When the trip point is reached, the operating system must shut down the system.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5, 12.15 and 12.3.3.
Test description: TD-3.19 ACPI Thermal Management (ACPITHRM) Test Description

3.37.18 The _PSL thermal zone object lists pointers to passive cooling device objects.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6 and 12.3.4.
Test description: TD-3.19 ACPI Thermal Management (ACPITHRM) Test Description

3.37.19 The _PSV thermal zone object specifies the passive temperature trip point in Kelvin to 0.1 degrees.

When the trip point is reached, the operating system must activate CPU throttling.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6 and 12.3.5.
Test description: TD-3.19 ACPI Thermal Management (ACPITHRM) Test Description

3.37.20 The _SCP thermal zone object notifies the hardware (sets) of the current user cooling mode setting.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6 and 12.3.6.
Test description: TD-3.19 ACPI Thermal Management (ACPITHRM) Test Description

3.37.21 If software fan control is implemented, thermal design and fan control comply with ACPI 1.0b, Section 12.

Reference documents: WLP# - A1.1.2; PC 2001 System Design Guide -SYS-0002.4; PC 2001 System Design Guide - 3.2.6 and ACPI Specification, Revision 1.0b, Section 12.
Test Description: Not Implemented

3.37.22 A Thermal Zone contains at least a _TMP and one of _ACx, _CRT, or _PSV control methods.

Reference documents: WLP# - A1.1.2; PC 2001 System Design Guide - 0002.4 and ACPI Specification, Revision 1.0b, Section 12.
Test Description: TD-3.25 Thermal Model Test Description

3.37.23 For each _ACx control method in a Thermal Zone, there is a corresponding _ALx object.

Reference documents: WLP# - A1.1.2; PC 2001 System Design Guide - 0002.4 and ACPI Specification, Revision 1.0b, Section 12.
Test Description: TD-3.25 Thermal Model Test Description

3.37.24 If a Thermal Zone contains a _PSV control method, it also includes _PSL, _TC1, _TC2, and _TSP objects.

Reference documents: WLP# - A1.1.2; PC 2001 System Design Guide - 0002.4 and ACPI Specification, Revision 1.0b, Section 12.
Test Description: TD-3.25 Thermal Model Test Description


ACPI BIOS Assertions Checklist

The following ACPI BIOS assertions are tested with the checklist. While some test cases might test the assertions implicitly, none are tested explicitly. See TD-3.23 ACPI BIOS Assertion Checklist

3.38.1 ASL/AML code does not manipulate fixed feature space registers.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.
Test description: TD-3.23 ACPI BIOS Assertion Checklist

3.38.2 ASL/AML code cannot access the general-purpose event registers.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.4.1.1.
Test description: TD-3.23 ACPI BIOS Assertion Checklist

3.38.3 A control method only can assume that access to global objects is exclusive for any period that the control method does not block.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.5.3.
Test description: TD-3.23 ACPI BIOS Assertion Checklist

3.38.4 Operation Regions are required to have exclusive access to the hardware registers.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.5.3.1 and 5.6.3.
Test description: TD-3.23 ACPI BIOS Assertion Checklist

3.38.5 Control methods do not directly access any other hardware registers, including the ACPI-defined register blocks.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.5.3.1 and 5.6.3.
Test description: TD-3.23 ACPI BIOS Assertion Checklist

3.38.6 Control methods for GPE events must use the naming convention _GPE._TXX, where: ‘T’ is the event handling type, 'E' is for edge event, 'L' for level event and XX is the hex value format of the event.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.2.2 and 5.6.2.2.3.
Test description: TD-3.23 ACPI BIOS Assertion Checklist

3.38.7 Event values for status bits in GPE0_BLK start at zero (_T00) and end at GPE0_BLK_LEN - 1.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.2.2 and 5.6.2.2.3.
Test description: TD-3.23 ACPI BIOS Assertion Checklist

3.38.8 Event values for status bits in GPE1_BLK start at GPE1_BASE and end at GPE1_BASE + GPE1_BLK_LEN - 1.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.2.2 and 5.6.2.2.3.
Test description: TD-3.23 ACPI BIOS Assertion Checklist

3.38.9 All ACPI operating system notifications of various object-related events are done with the Notify operator that supplies the ACPI object and with a notification value that signifies the type of notification being performed.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.5.3.1 and 5.6.3.
Test description: TD-3.23 ACPI BIOS Assertion Checklist

3.38.10 Notification values from 0 through 7Fh are common across any device object type.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.5.3.1 and 5.6.3.
Test description: TD-3.23 ACPI BIOS Assertion Checklist

3.38.11 Notification values above 7Fh are device-specific and defined by each such device.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.5.3.1 and 5.6.3.
Test description: TD-3.23 ACPI BIOS Assertion Checklist

3.38.12 It is the responsibility of the ACPI AML code to notify the operating system at times other than boot that the Plug and Play re-enumeration operation is required by issuing a Device Check notification.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.5.3.1 and 5.6.3.
Test description: TD-3.23 ACPI BIOS Assertion Checklist

3.38.13 The _SLN device identification object specifies the slot number for a slot.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.6.5.
Test description: TD-3.23 ACPI BIOS Assertion Checklist

3.38.14 The _SST system indicator control method specifies or sets the system status indicator.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5 and 10.1.1.
Test description: TD-3.23 ACPI BIOS Assertion Checklist

3.38.15 The _MSG system indicator control specifies messages are waiting.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 5.6.5 and 10.1.2.
Test description: TD-3.23 ACPI BIOS Assertion Checklist

3.38.16 If a device is present in the machine and should not be displayed in the operating system user interface, device object _STA bit 2 is cleared.

Reference document: WLP# - A1.1.2; ACPI Specification, Errata, Revision 1.0, Section 6.3.5.
Test description: TD-3.23 ACPI BIOS Assertion Checklist

3.38.17 The _INI device initialization object performs device-specific initialization.

Reference document: WLP# - A1.1.2; ACPI Specification, Errata, Revision 1.0, Section 6.5.1.
Test description: TD-3.23 ACPI BIOS Assertion Checklist

3.38.18 The _INI device initialization object is located under the device object to which it applies.

Reference document: WLP# - A1.1.2; ACPI Specification, Errata, Revision 1.0, Section 6.5.1.
Test description: TD-3.23 ACPI BIOS Assertion Checklist

3.38.19 The _INI device initialization object only can access system I/O, system memory, and the PCI configuration space.

It cannot access the embedded controller or the SMBus.

Reference document: WLP# - A1.1.2; ACPI Specification, Errata, Revision 1.0, Section 6.5.1.
Test description: TD-3.23 ACPI BIOS Assertion Checklist

3.38.20 The _REG control method informs the BIOS AML code whether the device driver that controls an operation region is ready or no longer ready for access.

Reference document: WLP# - A1.1.2; ACPI Specification, Errata, Revision 1.0, Section 6.5.4.
Test description: TD-3.23 ACPI BIOS Assertion Checklist

3.38.21 Before an operation region device driver is ready, AML cannot access registers in that operation region.

Reference document: WLP# - A1.1.2; ACPI Specification, Errata, Revision 1.0, Section 6.5.4.
Test description: TD-3.23 ACPI BIOS Assertion Checklist

3.38.22 If implemented, the system implements the _REG control method as specified in ACPI 1.0b, Section 6.5.4.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 6.5.4.
Test Description: Test Not Specified

3.38.23 If the system implements a PCI root bus other than bus 0, the system implements the _BBN control method as specified in ACPI 1.0b, Section 6.5.5.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 6.5.5.
Test Description: TD-3.27 ACPI Pre-OS: ACPI BBN Resolution Test Description

3.38.24 If SxD objects are present, the system implements the _SxD objects as defined in ACPI 1.0b, Sections 7.2.5-7.2.10 and Section 7.2, Table 7-1.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Sections 7.2.5-7.2.10 and Section 7.2, Table 7-1.
Test Description: Test Not Specified


ACPI Assertions Not Tested

The following sections identify ACPI hardware and BIOS assertions not tested by this test suite.

Note: Assertions labeled "Not Tested" may be tested in future tests.


ACPI Embedded Controller, SMBus, and Battery Hardware Assertions Not Tested

Embedded controller and SMBus controller implementations are a mechanism for PC motherboard vendors to provide value-add in product lines. Implementations of embedded controllers vary from one implementation to another. Therefore, most embedded controller assertions are not tested. See TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description and TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description.

The following lists the embedded controller, SMBus, battery, and AC adapter hardware assertions to implement ACPI that are not tested. For test specification and test coverage information for these assertions, see the Smart Battery Implementers forum at http://www.sbs-forum.org/.

3.39.1 General purpose register space is required for any events generated by value-added hardware.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 4.7.
Test description: N/A

3.39.2 Smart Batteries must support the Smart Management Bus Specification, Smart Battery Data Specification, Smart Battery Selector Specification, and the Smart Battery Charger Specification.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 11.1, PC 2001 System Design Guide - MOBL-0062.1, and PC 99 System Design Guide - 6.2.1.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.39.3 An ACPI compatible smart battery subsystem consists of a SMBus host controller interface, at least one smart battery, a smart battery charger, and, if more than one smart battery is supported, a smart battery selector.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Sections 11.1 and 13.7.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description
(See assertion 3.5.16)

3.39.4 All batteries in the system have the same SMBus address.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Sections 11.1 and 13.7.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description
(See assertion 3.5.17)

3.39.5 The SMBus host controller resides in embedded controller address space.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0a, Sections 11.1 and 13.7.
Test description: N/A

3.39.6 A smart battery selector provides hardware switching to a secondary battery upon the primary battery running low.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Sections 11.1 and 13.7.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description
(See assertion 3.5.18)

3.39.7 If both smart charger and stand-alone smart battery selectors are present in the same smart battery subsystem, the stand alone selector is wired to the batteries.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 11.1.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.39.8 The smart battery system charger is a SMBus device that provides a standard programming model to control the charging of smart batteries present in a smart battery subsystem.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Sections 11.1 and 13.7.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description
(See assertion 3.5.19)

3.39.9 The smart battery provides intelligent chemistry-independent power to the system.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Sections 11.1.
Test description: Test Not Specified

3.39.10 The smart battery is capable of informing the smart charger of its charging requirements and providing battery status and alarm features that are needed for platform battery management.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 11.1.
Test description: Test Not Specified

3.39.11 Each embedded controller has a flat byte-addressable I/O space, currently defined as 256 bytes.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 13.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.39.12 The embedded controller interface requires its own unique host resources (interrupt event and access registers).

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 13.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.39.13 The embedded controller contains three registers at two address locations: EC_SC and EC_DATA.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 13.2.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.39.14 If the embedded controller firmware supports a shared interface, it must use a separate command set for communicating with each environment and must generate the correct environment interrupts and notification values.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 13.5.
Test description: Test Not Specified

3.39.15 If the embedded controller firmware supports a shared interface between the ACPI operating system and the BIOS SMI handler, it must be able to queue a notification if it receives a command.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 13.5.
Test description: Test Not Specified

3.39.16 The embedded controller interrupt model uses pulsed interrupts.

The interrupt is generated by firmware using an embedded controller general-purpose output.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 13.6.
Test description: Test Not Specified

3.39.17 The embedded controller SCI system control interrupt is always wired directly to a GPE input.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 13.6.
Test description: Test Not Specified

3.39.18 When the host processor writes data to the embedded controller command or data register, the status register input buffer flag (IBF) bit is set within 1 microsecond.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 13.7.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.39.19 When the embedded controller reads data from the input buffer, the status register input buffer flag (IBF) bit is reset.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Sections 13.2.1 and 13.7.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.39.20 When the embedded controller writes data to the output buffer, the status register output buffer flag (OBF) bit is set.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Sections 13.2.1 and 13.7.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.39.21 When the host processor reads data from the output buffer, the status register output buffer flag (OBF) bit is reset.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Sections 13.2.1 and 13.7.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.39.22 The SMBus Host Interface must follow the SMBus Specification published by Intel Corporation.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 13.9.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.39.23 The smart charger in a charger only device must generate a SMBus Alarm Notify upon a battery or AC status change.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0a, Section 11.1.1.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.39.24 The mechanism for notifying the system of a change in the smart battery or AC status is the SMBus Alarm Notify mechanism.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0a, Sections 11.1.1 and 11.1.2.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.39.25 A battery or AC status change activates the SMBus Alarm Notify.

The SMBus Alarm Notify generates an SMBus host controller event after SelectorState() command register contents are placed in SMBus host slave data port and a messaging device slave address is placed in SMBus host slave command port.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Sections 11.1.1 and 11.1.2.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description
(See assertion 3.5.20)

3.39.26 For smart battery selector device, the smart battery selector must generate a SMBus Alarm Notify upon battery or AC status change.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0a, Section 11.1.2.
Test description: TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

3.39.27 If the _PCL power source object lists point to a bus, all devices under the bus are powered by this power source device.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 11.3.2.
Test description: Test Not Specified

3.39.28 The embedded controller must support the ACPI embedded controller interface general register interface model.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Sections 13.1 through 13.9.3.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.39.29 The embedded controller EC_SC status and command register acts as a status register for reads from this port and a command register for writes to this port.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Sections 13.2, 13.2.1 and 13.2.2.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.39.30 The embedded controller EC_DATA data register acts as a port for transferring data between the host CPU and an embedded controller.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Sections 13.2 and 13.2.3.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.39.31 The embedded controller must support the ACPI defined embedded controller interface command set.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Sections 13.3 through 13.3.5.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.39.32 The embedded controller must generate an SCI system control interrupt to signal that the embedded controller has read the last command or data from the input buffer and the host is free to send more data.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 13.6.1.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.39.33 The embedded controller must generate an SCI system control interrupt to signal that the embedded controller has written a byte of data into the output buffer and that the host is free to read the returned data.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 13.6.1.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.39.34 The embedded controller must generate an SCI system control interrupt to signal that the embedded controller has detected an event that requires operating system attention.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 13.6.1.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.39.35 The SMBus host interface is a flat array of registers that are arranged sequentially in address space.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Sections 13.9.1 through 13.9.1.8.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.39.36 The embedded controller SMBus host controller implements the SMBus register set format.

Reference document: WLP# - A3.4.1; ACPI Specification, Revision 1.0b, Section 13.9.3.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.39.37 The embedded controller can support up to 255 generic "query" events per embedded controller.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 4.7.4.4.2.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.39.38 The embedded controller reports GPE events by using the Query command.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 5.6.2.2.2.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.39.39 The queries that the embedded controller driver exchanges with the embedded controller are numbered from 0 through FFh, yielding event codes 01 through FF.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 5.6.2.2.3.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

3.39.40 A query response of 0 from the embedded controller is reserved for the "no outstanding events" message.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 5.6.22.3.
Test description: TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description


ACPI Register Implementation Hardware Assertions Not Tested

The following lists the remaining register hardware assertions to implement ACPI that are not tested.

3.40.1 ACPI hardware register-ignored bits can return zero or one (undefined).

Reference document: WLP# - A1.1.21; ACPI Specification, Revision 1.0a, Sections 4.5.2 and 4.5.3.
Test description: Test Not Specified

3.40.2 Reads from ACPI hardware register write-only control bits generate undefined results.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.5.2 and 4.5.3.
Test description: Test Not Specified

3.40.3 Between zero and 255 general-purpose event inputs can be implemented in hardware, each as either a level or an edge event.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 5.6.2.2.
Test description: Test Not Specified

3.40.4 Hardware platforms that support both legacy and ACPI operating systems support a method of remapping the interrupt events between SMIs when switching between ACPI and legacy modes.

Specifically, SMIs when SCI_EN bit is cleared in legacy mode, and SCIs when SCI_EN bit is set in ACPI mode.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 4.5 and 4.7.2.5.
Test description: Test Not Specified

3.40.5 When the system is in ACPI mode, the modem ring indicate and status change external events generate SCI events and not SMIs.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.5.
Test description: Test Not Specified

3.40.6 In the legacy state, the hardware uses legacy power management and configuration mechanisms.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.5.
Test description: Test Not Specified

3.40.7 The PM2_CNT_BLK register block contains a single bit for the arbiter disable function, as specified in Section 4.7.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.
Test description: Test Not Specified

3.40.8 PM1x_STS register GBL_STS global lock status bit (bit 5) generates an SCI system control interrupt when the BIOS sets this bit.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.3.1.1.
Test description: Test Not Specified

3.40.9 If the P_BLK register is implemented, each processor in the system must have a unique P_BLK register.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Section 4.7.3.5.
Test description: TD-3.26 ACPI Pre-OS: ACPI Unique P_BLK Test


System Power Management Assertions

The system power management test assertions are divided into three major groups: minimum BIOS assertions, minimum system assertions, and general functionality assertions.

The software which implements these assertions is SUSPENDER (suspend.exe), a Windows-based application compliant with Windows 98/Me and Windows 2000. Suspender verifies that the system complies with relevant specifications and confirms that system components function properly after resuming from low-power states.


ACPI System Assertions

The following sections contain the system power management assertions.

Minimum BIOS Assertions

The following assertions are the minimum BIOS requirements necessary to satisfy the system power management requirements.

3.41.1 The system BIOS must be compliant with the ACPI Specification, Revision 1.0b or later.

Reference documents:WLP# - A1.1.2; PC 2001 System Design Guide - SYS-002
Test description: SUSPENDER verifies the presence of a fully functional ACPI BIOS device.

3.41.2 The system BIOS must support a real-time clock wakeup alarm.

Reference documents: WLP# - A1.1.2; ACPI Specification v1.0b, section 1.7
Test description: SUSPENDER verifies this attribute via the Win32 API function SetWaitableTimer, which returns an error on machines which lack this capability.

3.41.3 The system BIOS must implement at least one system sleep state

Reference documents: WLP# - A1.1.2; ACPI Specification v1.0b, sections 1.7 and 9.1
Test description: SUSPENDER verifies the presence of sleep states S1, S2, S3, and S4 via the OS power policy manager.

Minimum System Assertions

The following assertions are the minimum system requirements.

3.42.1 The real-time clock wakeup alarm must wake the system from each supported S1, S2, and S3 system sleep states.

Reference Documents: WLP# - A1.1.2; ACPI Specification v1.0b, section 5.2.5; PC 2001 System Design Guide - 0002.
Test description: SUSPENDER places the system into each of the supported S1, S2, or S3 states and then verifies that the real-time clock wakeup alarm wakes the system.

3.42.2 The real-time clock wakeup alarm must wake the system from S4 if so indicated by the Fixed ACPI Description Table.

Reference Documents: WLP# - A1.1.2; ACPI Specification v1.0b, section 5.2.5; PC 2001 System Design Guide - 0002.
Test description: If the system is capable of OS hibernation, SUSPENDER places the system into the S4 state and then verifies that the real-time clock wakeup alarm wakes the system.

General System Functionality Requirements Assertions

The following assertions are general system functionality assertions required to satisfy the requirements of the system power management test

3.43.1 The system audio device must function after resuming from low-power states.

Reference Documents: WLP# - B1.4.5; PC 2001 System Design Guide - 0002.
Test description: If the system successfully plays a WAV file before entering a low-power state, then SUSPENDER verifies the system audio device properly plays a WAV file after resuming from all supported low-power states.

3.43.2 The serial communications port must function after resuming from low-power states.

Reference Documents: WLP# - B1.4.5; PC 2001 System Design Guide - 0002.
Test description: If SUSPENDER detects a serial communications port before entering a low power state, then it will prompt the user to attach a loopback device to the serial port's external connector. SUSPENDER then verifies that the serial communications port transmits and receives properly after resuming from all supported low-power states.

3.43.3 The network interface card must be able to ping the default gateway after resuming from low-power states.

If Suspender cannot find a Gateway to ping then it will try to find a system in its network neighbor to ping. If that is unsuccessful then it will prompt the user to setup a machine to ping.

Reference Documents: WLP# - B1.4.5; PC 2001 System Design Guide - 0002.
Test description: If SUSPENDER is able to ping the default gateway before entering a low-power state, then it will verify that the system can successfully ping the gateway after resuming from all supported low-power states.

3.43.4 The number of functioning devices in the system before and after resuming from low-power states must remain the same.

Reference Documents: WLP# - B1.4.5; PC 2001 System Design Guide - 0002.
Test description: SUSPENDER determines the total number of devices in the system and the number of devices with problem codes before entering a low-power state. After resuming, it verifies these numbers remain the same.

3.43.5 The system floppy disk drive must function after resuming from low-power states.

Reference Documents: WLP# - B1.4.5; PC 2001 System Design Guide - 0002.
Test description: If SUSPENDER detects a floppy disk controller before entering a low-power state and determines a floppy disk is present, then it inputs multiple files from the floppy disk after resuming from all supported low-power states.

3.43.6 The system hard disk drive must function after resuming from low-power states.

Reference Documents: WLP# - B1.4.5; PC 2001 System Design Guide - 0002.
Test description: SUSPENDER exercises the file system by inputting multiple files from the Windows directory after resuming from all supported low-power states.

3.43.7 LPT communications port must function after resuming from low-power states.

Reference Documents: WLP# - B1.4.5; PC 2001 System Design Guide - 0002.
Test description: If SUSPENDER detects a LPT communications port before entering a low power state, then it will prompt the user to attach a loopback device to the LPT communications port's external connector. SUSPENDER then verifies that the LPT communications port transmits and receives properly after resuming from all supported low-power states.

3.43.8 The MODEM must function after resuming from low-power states.

Reference Documents: WLP# - B1.4.5; PC 2001 System Design Guide - 0002.
Test description: SUSPENDER verifies that Modem echo a command after resuming from all supported low-power states.

3.43.9 The system’s CDROM drive must function after resuming from low-power states.

Reference Documents: WLP# - B1.4.5; PC 2001 System Design Guide - 0002.
Test description: If SUSPENDER detects a floppy disk controller before entering a low-power state and determines a floppy disk is present, then it inputs multiple files from the floppy disk after resuming from all supported low-power states.


System Sleep State Support Assertions

3.44.1 All single processor desktop system hardware, BIOS, and operating system drivers must support system sleep states S3, S4, and S5 as defined by the ACPI Specification, Revision 1.0b.

Reference document: WLP# - A1.4.2; PC 2001 System Design Guide - 0002.1.
Test Description: Test Not Specified

3.44.2 For multi-processor systems, the system Dynamic System Descriptor Table (DSDT) and /or Secondary System Descriptor Tables (SSDTs) contains an \_S1 object.

Reference documents: WLP# - A1.4.2; PC 2001 System Design Guide - 0002.1 and ACPI Specification, Revision 1.0b, Sections 7.5.2.5, 9.1, and 5.6.5 Table 5-29.
Test Description: Test Not Specified

3.44.3 For desktop and single-processor workstation systems, the system Dynamic System Descriptor Table (DSDT) and /or Secondary System Descriptor Tables (SSDTs) contains an \_S3 object.

Reference documents: WLP# - A1.4.2; PC 2001 System Design Guide - 0002.1 and ACPI Specification, Revision 1.0b, Sections 7.5.2.4, 9.1, 9.1.3.1, and 5.6.5, Table 5-29.
Test Description: Test Not Specified

3.44.4 The system Dynamic System Descriptor Table (DSDT) and /or Secondary System Descriptor Tables (SSDTs) contains an \_S4 object.

Reference documents: WLP# - A1.4.2; PC 2001 System Design Guide - 0002.1 and ACPI Specification, Revision 1.0b, Sections 7.5.2.5, 9.1, 9.1.4, and 5.6.5 Table 5-29.
Test Description: Test Not Specified

3.44.5 The system Dynamic System Descriptor Table (DSDT) and /or Secondary System Descriptor Tables (SSDTs) contains an \_S5 object.

Reference documents: WLP# - A1.4.2; PC 2001 System Design Guide - 0002.1 and ACPI Specification, Revision 1.0b, Sections 7.5.2.6, 9.1, 9.1.5, and 5.6.5 Table 5-29.
Test Description: Test Not Specified


Legacy Free Support Assertions

3.45.1 Systems identified as legacy free must implement the ACPI reset mechanism.

Reference documents: WLP# - A4.1.1; PC 2001 System Design Guide - BIOS-0015.
Test Description: Test Not Specified

3.45.2 Systems identified as legacy free must implement the LEGACY_DEVICES and 8042 flags set.

Reference documents: WLP# - A4.1.1; PC 2001 System Design Guide - BIOS-0015.
Test Description: Test Not Specified

3.45.3 Systems identified as legacy free must implement the Debug Port Table in the BIOS.

Reference documents: WLP# - A4.1.1; PC 2001 System Design Guide - BIOS-0015.
Test Description: Test Not Specified

3.45.4 On systems identified as legacy free, the debug port I/O range is fixed. The location of these registers is described using the ACPI FADT.

Reference documents: A4.1.1; PC 2001 System Design Guide - BIOS-0015.
Test Description: Test Not Specified

3.45.5 On systems identified as legacy free, the debug port and I/O range must be reported as system resources in the ACPI BIOS.

Reference documents: WLP# - A4.1.1; PC 2001 System Design Guide - BIOS-0015.
Test Description: Test Not Specified

3.45.6 On systems identified as legacy free, the debug port must be claimed by the PNP0C02 device node, so its resources are not allocated to anything else and detection does not try to find it.

Reference documents: WLP# - A4.1.1; PC 2001 System Design Guide - BIOS-0015.
Test Description: Test Not Specified

3.45.7 Systems identified as legacy free must implement the Fixed ACPI Description Table (FACP/FADT) BOOT_ARCH boot architecture flags (byte offset 109).

Reference documents: WLP# - A4.1.1; PC 2001 System Design Guide - BIOS-0015.
Test Description: Test Not Specified

3.45.8 Systems identified as legacy free must implement the Fixed ACPI Description Table (FACP/FADT) RESET_REG_SUP (byte offset 112, bit offset 10), RESET_REG reset register address structure (byte offset 116), and RESET_VALUE (byte offset 128).

Reference documents: WLP# - A4.1.1; PC 2001 System Design Guide - BIOS-0015.
Test Description: Test Not Specified


Docking Support Assertions

These assertions are tested in TD-3.29 Docking Test

3.46.1 A mobile PC supporting docking, must set DCK_CAP to 1 in the FADT.

Reference document: WLP# - A3.2.2; PC 2001 System Design Guide - MOBL-0078.
Test Description: TD-3.29 Docking Test

3.46.2 Mobile/docking station interface uses ACPI-defined mechanisms.

Reference document: WLP# - A3.2.2; PC 2001 System Design Guide - MOBL-0078.
Test Description: TD-3.29 Docking Test

3.46.3 An _Lxx, _Exx or _Qxx control method must handle the dock insertion event and must include a Notify to the dock object..

Reference document: WLP# - A3.2.2; PC 2001 System Design Guide - MOBL-0078.
Test Description: TD-3.29 Docking Test

3.46.4 _Lxx (or _Exx) control methods must handle the Fail Safe Ejection notification.

Reference document: WLP# - A3.2.2; PC 2001 System Design Guide - MOBL-0078. .
Test Description: TD-3.29 Docking Test

3.46.5 ACPI descriptions for ports located on the mobile PC and passed through the docking connector must include a _EJD method.

WLP# - A3.2.2; PC 2001 System Design Guide - MOBL-0078.
Test Description: TD-3.29 Docking Test

3.46.6 On systems supporting docking stations, the _WAK control method must perform a Notify to the dock object.

Reference document: WLP# - A3.2.2; PC 2001 System Design Guide - MOBL-0078.
Test Description: TD-3.29 Docking Test

3.46.7 On systems supporting docking station, a dock object must be specified and must include a device name to represent the dock, a UID control method for presenting the dock’s model number and unique ID to the operating system, a _DCK control method connecting and disconnecting the docking bus, a _STA control method for checking the dock status, and an _EJx control method that identifies in which sleep state docking can occur.

Reference document: WLP# - A3.2.2; PC 2001 System Design Guide - MOBL-0078.
Test Description: TD-3.29 Docking Test

3.46.8 Removable ATA devices in a docking station and in mobile PCs must report changes using ACPI-based methods.

Reference document: WLP# - A3.2.2; PC 2001 System Design Guide - MOBL-0078.
Test Description: TD-3.29 Docking Test

Power Button Assertion

Assertion 3.47.1 moved to 3.10.73


Video Extensions Assertions

These assertions are tested in TD-3.30 Video Extensions Test.

3.48.1 The system implements video extensions as defined in ACPI Specification, Revision 1.0b, Appendix A, including correct implementation of the _BCL, _BCM, _DCS, _DDC, _DGS, _DOD, _DOS, _DSS, and _ROM control methods and objects.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Appendix A.
Test Description: TD-3.30 Video Extensions Test

3.48.2 Whenever the state of one of the output devices attached to the VGA controller has been switched or toggled, a Notify (VGA, 0x80) event is generated, unless the _DOS method has been called with a value of one.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Appendix A.5.
Test Description: TD-3.30 Video Extensions Test

3.48.3 Whenever the state of any output devices attached to the VGA controller has been changed, a Notify (VGA, 0x81) event is generated.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Appendix A.5.
Test Description: TD-3.30 Video Extensions Test

3.48.4 If the _DOS control method is implemented, it is implemented for all display output devices.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Appendix A.6.2.
Test Description: TD-3.30 Video Extensions Test

3.41.24 Every child device enumerated in the ACPI namespace under the graphics adapter is specified in the list of devices returned by the _DOD control method.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Appendix A.6.3.
Test Description: TD-3.30 Video Extensions Test

3.48.5 Every child device enumerated in the ACPI namespace under the graphics adapter is specified in the list of devices returned by the _DOD control method.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Appendix A.6.3.
Test Description: TD-3.30 Video Extensions Test

3.48.6 All display output devices have an unique hardware ID returned by the _ADR control method

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Appendix A.7.1.
Test Description: TD-3.30 Video Extensions Test

3.48.7 The _DCS control method is required for each display output device.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0b, Appendix A.7.5.
Test Description: TD-3.30 Video Extensions Test


Wakedevs Test Assertions

Assertions in this section are tested in TD-3.32 Wakedevs Test Description

3.48.1 Devices must have a _PRW namespace object associated to the device itself of the devices parent controller.

The system ACPI BIOS must provide a _PRW for the device or the devices parent controller if the device is to report wake capability.

  • The first item in the PRW object returns the GPEx_EN bit to be used by the device when it is enabled to wake the system.
  • The second item reports the deepest sleep state that the system can enter and the device can still wake the system. This tells wakedevs which sleep states need to be tested.

Reference document: WLP# - A1.5.15
Test description: TD-3.32 Wakedevs Test Description

3.48.2 The system must provide adequate power to preserve the power management event (PME) context of the device and determine if the device is signaling to wake the system.

If inadequate power is supplied, the device will not wake the system and the test will fail.

Reference document: WLP# - A1.5.15, B2.1.5.3, B7.1.4.4, B12.1.4.4
Test description: TD-3.32 Wakedevs Test Description

3.48.3 General Purpose Event (GPE) enable bits defined in the _PRW need to be set to the on position.

Reference document: WLP# - A1.5.15, B2.1.5.3, B7.1.4.4, B12.1.4.4
Test description: TD-3.32 Wakedevs Test Description

3.48.4 When the wake signal is sent, the GPE status bits need to be set to the on position.

Reference document: WLP# - A1.5.15, B2.1.5.3, B7.1.4.4, B12.1.4.4
Test description: TD-3.32 Wakedevs Test Description

3.48.5 All controllers that support wake must have a device attached to send the proper wake signal.

If a device is not attached to a controller that reports wake capability, the test will fail.

Reference document: WLP# - A1.5.15, B2.1.5.3, B7.1.4.4, B12.1.4.4
Test description: TD-3.32 Wakedevs Test Description

3.48.6 PCI devices have a power management configuration space that must be set properly.

PCI devices that support wake need to correctly implement the PMC register in the devices PCI configuration space. Incorrect settings can cause the device to fail to wake from some or all sleep states.

Reference document: WLP# - A1.5.15, B2.1.5.3, B7.1.4.4, B12.1.4.4
Test description: TD-3.32 Wakedevs Test Description


Enable/Disable - Device I/O Test Assertions

These assertions are tested in TD-3.33 Enable/Disable - Device I/O Test

3.49.1 Device driver and related software are removable using Windows-based software

At a minimum, any "virtual drivers" and software components installed with the driver must be capable of being removed.

Reference document: WLP# - B1.4.1
Test description: TD-3.33 Enable/Disable - Device I/O Test Description

3.49.2 Device can be enumerated and automatically disabled

Reference document: WLP# - B1.4.1
Test description: TD-3.33 Enable/Disable - Device I/O Test Description


ACPI Verifier Test Assertions

These assertions are tested in TD-3.34 ACPI Verifier Test Description

3.50.1 For each active trip point (_ACX) control method in a Thermal Zone, there is a corresponding list of active trip point objects (_ALX).

Reference document: WLP# - A1.1.2; PC 2001 System Design Guide - 0002.4 and ACPI Specification, Revision 1.0b, Section 12.
Test description: TD-3.34 ACPI Verifier Test Description

3.50.2 For each list of active trip point objects (_ALX) in a Thermal Zone, there is a corresponding active trip point (_ACX) control method.

Reference document: WLP# - A1.1.2; PC 2001 System Design Guide - 0002.4 and ACPI Specification, Revision 1.0b, Section 12.
Test description: TD-3.34 ACPI Verifier Test Description

3.50.3 The cooling strength values of x must be consecutive (no gaps) for the active trip point (_ACX) control method in a Thermal Zone.

Reference document: WLP# - A1.1.2, ACPI Specification,
Test description: TD-3.34 ACPI Verifier Test Description

3.50.4 The return value of active trip point (_ACX) control method in a Thermal Zone, must be larger then the return value of _AC (X+1).

Reference document: WLP# - A1.1.2, ACPI Specification, Section 12.
Test description: TD-3.34 ACPI Verifier Test Description

3.50.5 The return value of _CRT (the system shutdown temp) in a Thermal Zone, must be larger then any of the _ACX or _PSV return values.

Reference document: WLP# - A1.1.2, ACPI Specification,
Test description: TD-3.34 ACPI Verifier Test Description

3.50.6 In active mode, the BIOS must notify when _TMP (current temperature) changes in a Thermal Zone.

Reference document: WLP# - A1.1.2, ACPI Specification, Section 12.
Test description: TD-3.34 ACPI Verifier Test Description

3.50.7 The BIOS should not notify of _TMP (current temperature) change in a Thermal Zone when _TMP does not change (Error > 20%).

For each notification where the temperature did not change , a Warning will be logged.

Reference document: WLP# - A1.1.2, ACPI Specification, Section 12.
Test description: TD-3.34 ACPI Verifier Test Description

3.50.8 All active trip point (_ACX) devices references, must be unique.

Reference document: WLP# - A1.1.2, ACPI Specification, Section 12.
Test description: TD-3.34 ACPI Verifier Test Description

3.50.9 The return value of active trip point (_ACX) control method in a Thermal Zone, must be less then or equal to the return value of _CRT (the system shutdown temp) when the matching _ALX device is powered ON.

Reference document: WLP# - A1.1.2, ACPI Specification, Section 12.
Test description: TD-3.34 ACPI Verifier Test Description

3.50.10 The _BIF Method Result Code "Power Unit" must be in the form of DWORD.

Reference document: WLP# - A1.1.2, ACPI Specification Section 11.2.2.1 BIF (Battery Information)
Test description: TD-3.34 ACPI Verifier Test Description

3.50.11 The return value of _BIF Method Result Code "Power Unit" must be either a 1 or a 0.

Reference document: WLP# - A1.1.2, ACPI Specification 11.2.2.1 BIF (Battery Information)
Test description: TD-3.34 ACPI Verifier Test Description

3.50.12 The _BIF Method Result Code "Design Capacity" must be in the form of DWORD.

Reference document: WLP# - A1.1.2, ACPI Specification Section 11.2.2.1 BIF (Battery Information)
Test description: TD-3.34 ACPI Verifier Test Description

3.50.13 The return value of _BIF Method Result Code "Design Capacity" must not be in the range of 0x8FFFFFFF to 0xEFFFFFFF.

Reference document: WLP# - A1.1.2, ACPI Specification 11.2.2.1 BIF (Battery Information)
Test description: TD-3.34 ACPI Verifier Test Description

3.50.14 The _BIF Method Result Code "Last Full Charge Capacity" must be in the form of DWORD.

Reference document: WLP# - A1.1.2, ACPI Specification Section 11.2.2.1 BIF (Battery Information)
Test description: TD-3.34 ACPI Verifier Test Description

3.50.15 The return value of _BIF Method Result Code "Last Full Charge Capacity" must not be in the range of 0x8FFFFFFF to 0xEFFFFFFF.

Reference document: WLP# - A1.1.2, ACPI Specification 11.2.2.1 BIF (Battery Information)
Test description: TD-3.34 ACPI Verifier Test Description

3.50.16 The return value of _BIF Method Result Code "Last Full Charge Capacity" must not be higher then the actual design capacity

Reference document: WLP# - A1.1.2, ACPI Specification 11.2.2.1 BIF (Battery Information)
Test description: TD-3.34 ACPI Verifier Test Description

3.50.17 The _BIF Method Result Code "Battery technology" must be in the form of DWORD.

Reference document: WLP# - A1.1.2, ACPI Specification Section 11.2.2.1 BIF (Battery Information)
Test description: TD-3.34 ACPI Verifier Test Description

3.50.18 The return value of _BIF Method Result Code "Battery technology" must not be either a 1 or 0.

Reference document: WLP# - A1.1.2, ACPI Specification 11.2.2.1 BIF (Battery Information)
Test description: TD-3.34 ACPI Verifier Test Description

3.50.19 The _BIF Method Result Code "Design voltage" must be in the form of DWORD.

Reference document: WLP# - A1.1.2, ACPI Specification Section 11.2.2.1 BIF (Battery Information)
Test description: TD-3.34 ACPI Verifier Test Description

3.50.20 The return value of _BIF Method Result Code "Design voltage" must not be in the range of 0x8FFFFFFF to 0xEFFFFFFF.

Reference document: WLP# - A1.1.2, ACPI Specification 11.2.2.1 BIF (Battery Information)
Test description: TD-3.34 ACPI Verifier Test Description

3.50.21 The _BIF Method Result Code "Design capacity of warning" must be in the form of DWORD.

Reference document: WLP# - A1.1.2, ACPI Specification Section 11.2.2.1 BIF (Battery Information)
Test description: TD-3.34 ACPI Verifier Test Description

3.50.22 The return value of _BIF Method Result Code "Design capacity of warning" must not be in the range of 0x8FFFFFFF to 0xEFFFFFFF.

Reference document: WLP# - A1.1.2, ACPI Specification 11.2.2.1 BIF (Battery Information)
Test description: TD-3.34 ACPI Verifier Test Description

3.50.23 The return value of _BIF Method Result Code "Design capacity of warning" must not be greater then 40% of Last full charge capacity.

Reference document: WLP# - A1.1.2, ACPI Specification 11.2.2.1 BIF (Battery Information) & 3.9.4 Low Battery Levels
Test description: TD-3.34 ACPI Verifier Test Description

3.50.24 The _BIF Method Result Code "Design Capacity of Low" must be in the form of DWORD.

Reference document: WLP# - A1.1.2, ACPI Specification Section 11.2.2.1 BIF (Battery Information)
Test description: TD-3.34 ACPI Verifier Test Description

3.50.25 The return value of _BIF Method Result Code "Design Capacity of Low" must not be in the range of 0x8FFFFFFF to 0xEFFFFFFF.

Reference document: WLP# - A1.1.2, ACPI Specification 11.2.2.1 BIF (Battery Information)
Test description: TD-3.34 ACPI Verifier Test Description

3.50.26 The return value of _BIF Method Result Code "Design Capacity of Low" must not be greater then 20% of Last full charge capacity.

Reference document: WLP# - A1.1.2, ACPI Specification 11.2.2.1 BIF (Battery Information) & 3.9.4 Low Battery Levels
Test description: TD-3.34 ACPI Verifier Test Description

3.50.27 The _BIF Method Result Code "Battery Capacity granularity 1" must be in the form of DWORD.

Reference document: WLP# - A1.1.2, ACPI Specification Section 11.2.2.1 BIF (Battery Information)
Test description: TD-3.34 ACPI Verifier Test Description

3.50.28 The _BIF Method Result Code "Battery Capacity granularity 2" must be in the form of DWORD.

Reference document: WLP# - A1.1.2, ACPI Specification Section 11.2.2.1 BIF (Battery Information)
Test description: TD-3.34 ACPI Verifier Test Description

3.50.29 The _BIF Method Result Code "Model Number" must be in the form of a string (ASCIIZ).

Reference document: WLP# - A1.1.2, ACPI Specification Section 11.2.2.1 BIF (Battery Information)
Test description: TD-3.34 ACPI Verifier Test Description

3.50.30 The _BIF Method Result Code "Serial Number" must be in the form of a string (ASCIIZ).

Reference document: WLP# - A1.1.2, ACPI Specification Section 11.2.2.1 BIF (Battery Information)
Test description: TD-3.34 ACPI Verifier Test Description

3.50.31 The _BIF Method Result Code "Battery Type" must be in the form of a string (ASCIIZ).

Reference document: WLP# - A1.1.2, ACPI Specification Section 11.2.2.1 BIF (Battery Information)
Test description: TD-3.34 ACPI Verifier Test Description

3.50.32 The _BIF Method Result Code "OEM Information" must be in the form of a string (ASCIIZ).

Reference document: WLP# - A1.1.2, ACPI Specification Section 11.2.2.1 BIF (Battery Information)
Test description: TD-3.34 ACPI Verifier Test Description

3.50.33 The _STA object returns the status of a device as present after device gets a Notify (Battery_Device, 0x1).

Reference document: WLP# - A1.1.2, ACPI Specification Section 11.2.1 Battery Events
Test description: TD-3.34 ACPI Verifier Test Description

3.50.34 The _STA object returns the status of a device as not present after device gets a Notify (Battery_Device, 0x0).

Reference document: WLP# - A1.1.2, ACPI Specification Section 11.2.1 Battery Events
Test description: TD-3.34 ACPI Verifier Test Description

3.50.35 The _BST object returns the present battery status changes after the device gets a Notify (Battery_Device, 0x80).

Reference document: WLP# - A1.1.2, ACPI Specification Section 11.2.2.2 _BST (Battery Status)
Test description: TD-3.34 ACPI Verifier Test Description

3.50.36 Notification (Battery_Device, 0x80) must be issued when the value of Battery Remaining Capacity crosses the trip point _BTP object value.

Reference document: WLP# - A1.1.2, ACPI Specification Section 11.2.2.3 BTP (Battery Trip Point)
Test description: TD-3.34 ACPI Verifier Test Description

3.50.37 The _BST Method Result Code "Battery state" must be in the form of DWORD.

Reference document: WLP# - A1.1.2; ACPI Specification Chapter 11.2.2.2 BST (Battery Status)
Test description: TD-3.34 ACPI Verifier Test Description

3.50.38 The bit values of Bit0 (battery discharging) and Bit1(battery charging) of _BST Method Result Code "Battery state" must not be set at the same time.

Reference document: WLP# - A1.1.2; ACPI Specification Chapter 11.2.2.2 BST (Battery Status)
Test description: TD-3.34 ACPI Verifier Test Description

3.50.39 The bit value of Bit2 (battery in critical energy state) of _BST Method Result Code "Battery state" must not be set if Remaining battery Capacity is greater then Design Capacity of Low (_BIF).

Reference document: WLP# - A1.1.2; ACPI Specification Chapter 11.2.2.2 BST (Battery Status)
Test description: TD-3.34 ACPI Verifier Test Description

3.50.40 The _BST Method Result Code "Battery Present Rate" must be in the form of DWORD.

Reference document: WLP# - A1.1.2, ACPI Specification Chapter 11.2.2.2 BST (Battery Status)
Test description: TD-3.34 ACPI Verifier Test Description

3.50.41 The return value of _BST Method Result Code "Battery Present Rate" must not be in the range of 0x8FFFFFFF to 0xFFFFFFFF.

Reference document: WLP# - A1.1.2, ACPI Specification Chapter 11.2.2.2 BST (Battery Status)
Test description: TD-3.34 ACPI Verifier Test Description

3.50.42 The _BST Method Result Code "Battery Remaining Capacity" must be in the form of DWORD.

Reference document: WLP# - A1.1.2, ACPI Specification Chapter 11.2.2.2 BST (Battery Status)
Test description: TD-3.34 ACPI Verifier Test Description

3.50.43 The return value of _BST Method Result Code "Battery Remaining Capacity" must not be in the range of 0x8FFFFFFF to 0xFFFFFFFF.

Reference document: WLP# - A1.1.2, ACPI Specification Chapter 11.2.2.2 BST (Battery Status)
Test description: TD-3.34 ACPI Verifier Test Description

3.50.44 The _BST Method Result Code "Battery Present voltage" must be in the form of DWORD.

Reference document: WLP# - A1.1.2, ACPI Specification Chapter 11.2.2.2 BST (Battery Status)
Test description: TD-3.34 ACPI Verifier Test Description

3.50.45 The return value of _BST Method Result Code "Battery Present voltage" must not be in the range of 0x8FFFFFFF to 0xFFFFFFFF.

Reference document: WLP# - A1.1.2, ACPI Specification Chapter 11.2.2.2 BST (Battery Status)
Test description: TD-3.34 ACPI Verifier Test Description


Unreported Memory and I/O Port Test Assertions

These assertions are tested in TD 3.35 Unreported Memory and I/O Port Test.

3.51.1 The system and device decoded memory addresses must be reported correctly to the operating system.

Reference document: WLP# - A.1.2.2; Plug and Play Bios Specification, Chapter 2
Test description: TD 3.35 Unreported Memory and I/O Port Test

3.51.2 The system and device decoded I/0 port addresses must be reported correctly to the operating system.

Reference document: WLP# - A1.2.2; Plug and Play Bios Specification, Chapter 2
Test description: TD 3.35 Unreported Memory and I/O Port Test


ACPI Errors Test Assertions

This assertion is tested in TD-3.36 ACPI Errors Test.

3.52.1 The system event log must not contain ACPI errors.

Reference document: WLP# - A1.2.1; ACPI Specification (versions 1.0b and 2.0), Section 9.3.3 and Appendix A.; Windows Platform Development Whitepaper: I/O Ports Blocked from BIOS AML on Windows XP
Test description: TD 3.36 ACPI Errors Test


CPU P-State and CPU P-State Battery Test Assertions

This section contains the detailed list of test assertions. These assertions are tested in TD-3-37 CPU P-State and CPU P-State Battery Test.

3.53.1 This system must sustain an average processor utilization under 5% as a precondition for this test to run.

This assertion exists to enforce the context in which this test should run.

Reference document: None.
Test description: TD-3.37.1 Idle System Test Description

3.53.2 The highest performance P-state must correspond to the maximum processor speed while on AC power.

This assertion exists to enforce the context in which this test should run.

Reference document: WLP# - A3.4.1; ACPI 2.0 Specification, Section 8.3.3.
Test description: TD-3.37.2 Maximum Processor Speed Available Test Description

3.53.3 Some P-states may not be entered due to restrictions temporarily imposed by the operating system, thus preventing the test from passing at this time.

This assertion exists to enforce the context in which this test should run.

Reference document: None.
Test description: TD-3.37.3 Situational Factors Preclude Testing Test Description

3.53.4 The processor throttle policy must not change outside the test's control.

This assertion exists to enforce the context in which this test should run.

Reference document: None
Test description: TD-3.37.4 Processor Policy Changes Outside HCT Control Test Description

3.53.5 All P-states must be verified within the duration of the test.

Reference documents: WLP# A3.4.1; ACPI 2.0 Specification, Section 8.3.3, Section 3.1; ACPI 2.0 Errata, Revision 1.2 or later, Section 5.2.8; "Windows XP Native Processor Performance Control" whitepaper at http://www.microsoft.com/hwdev/tech/onnow/default.asp; Mobile Pentium III Processor Featuring Intel SpeedStep Technology BIOS Writer’s Guide; Gemini SMI API Specification version 0.80, available from AMD
Test description: TD-3.37.5 State Validation Test Description

3.53.6 If no P-states are reported, distinct frequency groupings must not exist.

Reference document: WLP# A3.4.1; ACPI 2.0 Specification, Section 3.1
Windows Logo for Hardware Requirements 2.0, Appendix A, Section A3.4.1
Test description: TD-3.37.6 Unreported P-States Found Test Description

3.53.7 Performance states must be in descending order by power dissipation and hence by frequency.

Reference document: WLP# A3.4.1; ACPI 2.0 Specification, Section 8.3.3.2 "_PSS (Performance Supported States)"
Test description: TD-3.37.7 P-state Order Test Description

3.53.8 The BIOS must not specify a P-state with a frequency of zero.

Reference document: WLP# A3.4.1; ACPI 2.0 Specification, Section 3.2 "Power States"; Section 8.1 "Processor Power States"; Chapter 9 "Waking and Sleeping"
Test description: TD-3.37.8 P-state Frequency Out Of Range Test Description

3.53.9 Neither this test nor the OS is designed to accommodate P-states in combination with multiple processors.

Reference document: none
Test description: TD-3.37.9 P-states On Multiple Processors Not Supported Test Description


ACPI Stress Test Assertions

Assertions in this section are tested in TD-3.38 ACPI Stress Tests.

3.54.1 The OS must enable wake from real-time clock (RTC) on all supported sleep states and that it works on the target test system.

Reference document: Windows Logo Requirements Document, B1.4.5
Test description: TD-3.38 ACPI Stress Tests

3.54.2 If RTC from S4 is supported then the target test system must do so.

Reference document: Windows Logo Requirements Document, B1.4.5
Test description: TD-3.38 ACPI Stress Tests

3.54.3 The OS must survive cycling through each supported sleep states repeatedly on the target test system.

Reference document: Windows Logo Requirements Document, B1.4.5
Test description: TD-3.38 ACPI Stress Tests

3.54.4 The devices must still work after each S state transition.

Reference document: Windows Logo Requirements Document, B1.4.5
Test description: TD-3.38 ACPI Stress Tests

3.54.5 The system must support the S1, S3, and the S4 system power states.

Reference document: Windows Logo Requirements Document, B1.4.5
Test description: TD-3.38 ACPI Stress Tests


ACPI Test Descriptions

This section describes the ACPI tests. Test descriptions include a description of each test, set up requirements, and results interpretations. Each named test is referenced by various assertions at the beginning of this chapter.


TD-3.1 ACPI Namespace Test Infrastructure Test Description

Overview

To perform meaningful ACPI test activity, test software must access the ACPI name space contained in the Differentiated System Description Table (DSDT). The name space provides both data that indicates the system’s hardware architecture and control methods for manipulating devices. These data and control methods are provided in the form of ACPI Machine Language (AML). Accessing the AML requires a software component that can interpret the data and execute the control methods.

The AML scanner operates as a two-pass recursive recognizer: a recognition function examines the current part of the AML stream and either does or does not recognize the construct it is examining. The first pass loads all the names and the number of arguments required for the control methods. This allows forward references to exist in the AML. In the course of identifying the target construct, a recognition function often calls other recognition functions to identify constructs embedded in the target.

At any given time, the scanner operates on one of two distinct modes: load mode or execute mode. In load mode, the scanner parses and dumps the AML string, and it builds the name space. In execute mode, the scanner interprets an AML method.

Setup

Test is not implemented

Results Interpretation

Test is not implemented


TD-3.2 ACPI Pre-OS: ACPI Control Method Battery Interface (ACPICMB) Test Description

Overview

The ACPI Control Method Battery Interface test (ACPICMB) verifies the control method battery, charger and AC adapter device control methods. Physical battery testing is outside the scope of this effort.

The ACPICMB test implements the following algorithm.

  1. Load the ACPI namespace, chain SCI/GPE interrupt, transition into ACPI mode.
  2. If a device with _HID == PNP0C0A (control method battery device id) is specified in the ACPI namespace.

a. Verify that the control method battery device object is independent from any other control method battery device objects.

b. Verify required _BIF control method is within the control method battery device.

Execute _BIF and display the battery static information.

(a.) Verify power unit is 0.

(b.) If this is not the first battery, verify capacity granularity is identical to all other batteries in the system.

(c.) Verify design capacity is 0-7FFFFFFFh.

(d.) Verify design capacity of low is 0-7FFFFFFFh.

(e.) Verify OEM Information field is valid or reserved as 0x00.

c. Verify required _STA control method is within the control method battery device.

Execute _STA and display the current battery status information.

d. Verify required _PCL control method is within the control method battery device.

Execute _PCL and display the list of devices powered by the battery.

e. Instruct user to connect AC power source and remove all batteries.

f. Instruct user to insert any untested battery.

(a.) Verify battery insertion generated SCI/GPE notification.

(b.) Verify SCI/GPE AML code handler generated a
Notify(battery_device, 0x81).

g. Verify required _BST control method is within the control method battery device.

(a.) Instruct user to disconnect AC power source.

(b.) Delay 2 seconds to allow system to update _BST current battery status information.

(c.) Execute _BST and display the present battery status information.

(i.) Verify charging bit is not set and discharging bit is set.

(ii.) If this is not the first battery, verify that at most one battery reports unknown battery present voltage value.

(iv.) Use OEM-supplied instrumented battery to measure battery voltage and current discharge to compare to the _BST reported values. The test passes if the values are within plus or minus 5%.

(d.) Monitor _BST return values until present capacity changes to verify monotonic decreasing values during constant load (drain).

(e.) Verify _BST present capacity return value change generated a SCI/GPE notification.

h. If optional _BTP control method is within the control method battery device.

(a.) Execute _BTP to set the battery trip point to a value slightly below the current battery capacity (battery is currently powering system).

(b.) Verify SCI / GPE handler receives battery capacity trip point notification via notify (battery_device, 80h).

(c.) Execute _BST to confirm the battery’s remaining capacity did pass the trip point.

(d.) Execute _BTP to set the battery trip point to a value above the current battery capacity and have user connect AC power.

(e.) Verify the SCI / GPE handler receives battery capacity trip point information either immediately, or after the next _BST present capacity change.

(f.) Execute _BTP to clear the battery trip point.

i. Instruct user to insert AC if not connected and remove this tested battery.

(a.) Verify battery removal generated SCI/GPE notification.

(b.) Verify SCI/GPE AML code handler generated a
Notify(battery_device, 0x81).

j. Repeat steps f. through i. until all batteries have been tested.

  3. Transition to legacy mode and unchain SCI / GPE interrupt handler.

Issues and Known Problems

This test must utilize the information that many systems require removal of one or more devices to facilitate a second battery.

This test must utilize the information that a mobile platform may be powered solely from the batteries, or also from an AC power source.

This test algorithm needs to be updated to measure the latency of reporting _BST power discharge present rate changes based on transitions between processor (1) low power and (2) high power with active processor activity states. This latency is expected to be two seconds or less to pass this test case.

Setup

This test requires the target platform’s BIOS to implement the ACPI name space and the hardware supports docking and undocking.

This test requires the operating system to be configured to not utilize ACPI to avoid conflicts.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-3.3 ACPI Processor Power State Transition (ACPIPPST) Test Description

Overview

The ACPI Processor Power State Transition (ACPIPPST) test suite verifies CPU identification and cycles each processor through each supported power state. See "ACPI Processor Hardware Assertions" for a list of the processor power state transition hardware assertions tested and "ACPI Processor BIOS Assertions" for a list of the processor power state transition BIOS assertions tested.

The ACPIPPST test performs the following steps:

  1. Enumerate all processors in the system with the CPUID instructions.
  2. Locate the ACPI tables and identify the SCI vector.
  3. Cross-reference processors detected with ACPI name space processor information.
  4. Disable all known ACPI event interrupt sources.
  5. Install the system control interrupt handler and transition the system to ACPI mode.
  6. Enable RTC alarm SCI wake event.
  7. For each processor,

a. Ensure C1 is a supported power state.

b. For each supported processor power state,

(a.) Set a real-time clock alarm wakeup event.

(b.) Transition each processor to each supported processor power state.

  • If C1, execute STI-HLT sequence.
  • If C2, use P_LVL2 register.
  • If C3, flush cache, disable arbitor (PM2_CNT.ARB_DIS on uniprocessor system), and use P_LVL3 register.

(c.) Ensure RTC alarm wake-up event woke system in timely manner using RTC and/or PMT.

(d.) If current processor power state is C3 and PM1_CNT.BM_RLD is set, indicating bus master activity awakens processor from C3 state,

  • Bus master activity wake event sequence.
  • Verify PM1_EVT_BLK.BM_STS register and SCI wake event.
  8. Disable RTC alarm and RTC alarm SCI wake event.
  9. Return to legacy (non-ACPI) mode and uninstall SCI handler.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires that the target platform’s BIOS implement the ACPI name space and the processors support at least one C1-C3 processor power state. Support for a real-time alarm wake event is also required.

This test requires that the operating system be configured to not utilize ACPI to avoid conflicts.

This test must run in real mode to support accessing CPU MSRs.

Results Interpretation

This test creates a detailed test results log file and displays pass/fail status on the screen when the test completes. In addition, the test exit value returned to the operating system follows the ETDE test interface standard. The test results log file is specified as a test invocation parameter. Review the test results log file for specific details regarding failures.


TD-3.4 ACPI Pre-OS: ACPI Docking/Undocking Test (ACPIDOCK) Test Description

Overview

The ACPI Docking and Undocking test (ACPIDOCK) focuses only on the hardware and ACPI BIOS event notification requirements to inform the operating system and its drivers that a dock or undock has occurred.

The ACPI docking and undocking test addresses full docking stations and mini-docking stations. The assertions addressed by this test algorithm are identical for both the full docking station and the mini-docking station.

Hot docking, warm docking, and cold docking are also addressed.

The ACPIDOCK test implements the following algorithm:

  1. Report the value interpretation of the FACP DCK_CAP field.
  2. If the FACP DCK_CAP field indicates the system supports docking,

a. Instruct user to ensure system is docked.

b. Load ACPI namespace, chain SCI / GPE interrupt, transition into ACPI mode.

c. Locate the _DCK control method in the ACPI namespace.

d. Verify the _DCK control method controls the isolation logic on the docking connector.

e. If the ACPI namespace for the docking device contains a _BDN control method, report the GetDockingStationIdentifier EISA Dock ID value.

(a.) Report the GetDockingStationIdentifier EISA Dock ID value.

(b.) Verify that the _BDN control method appears in the device object that represents the dock (the device object with the _EJx control methods).

f. Verify no other ACPI namespace devices contain a _BDN control method.

g. Verify that undocking the system generates an SCI/GPE with the GPEx_STS bit set.

h. Verify that docking the system generates an SCI/GPE with the GPEx_STS bit set.

i. Transfer to legacy mode and unchain the SCI/GPE interrupt handler.

Setup

This test requires the target platform’s BIOS to implement the ACPI name space and the hardware supports docking and undocking.

This test requires the operating system to be configured to not utilize ACPI to avoid conflicts.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-3.5 ACPI Pre-OS: Device Power Management (ACPIDPMT) Test Description

Overview

The ACPI Device Power Management (ACPIDPMT) test suite verifies correctness of all device power management operations that can be performed on each device defined by the ACPI name space: device related hardware registers, Dx device power state transitions, and ACPI name space support. See "ACPI Device Hardware Assertions" for a list of the device power management hardware assertions tested and "ACPI Device Power Management BIOS Assertions" for a list of the device power management BIOS assertions tested.

The ACPIDPMT test performs the following steps:

  1. Locate the ACPI tables and identify the SCI vector.
  2. Disable all known ACPI event interrupt sources.
  3. Install the system control interrupt handler and transition system to ACPI mode.
  4. Enumerate all motherboard devices in the ACPI name space using _ADR, _HID, _STA, _CRS, and _PRS control methods.
  5. Determine if the system has a _PSR control method. If the method exists, execute it and display whether the AC adapter is on-line or off-line.
  6. Determine if the system has a _PCL control method. If the method exists, execute it and display the devices powered by this power source.
  7. Determine if the system has a _ON control methods. If any _ON methods exist, list the devices that support each _ON method.
  8. Determine if the system has a _OFF control methods. If any _OFF methods exist, list the devices that support each _OFF method.
  9. Select the first or next enumerated device.

a. Display each device's power resource requirements for each state (D0-D2) by executing the _PR0, _PR1, and _PR2 control methods if they exist.

b. Determine whether the _IRC control method exists for the current device. If so, this device has an inrush current when transitioning to the D0 state that requires serialization with other devices with inrush currents.

c. Obtain and save the state of the current device via _CRS, _PSC, and _STA control methods.

d. Verify the current state, if possible, by directly examining the device hardware registers.

e. Identify all child devices, save their state, and transition them to the D3 off device power state.

f. For each device where _CRS, _PSC, and _PSx (x=1,...., 3) exist.

(a.) Save the current power state using the _PSC control method.

(b.) Save the current resources using the _CRS control method.

(c.) For each supported device power state (D0-D3) where _PSx (x=1,...., 3) exists:

  • Set the next device power state using the _PSx control method.
  • Verify the device is in the specified device power state using the _PSC and _STA control methods and, if possible, by directly examining the device hardware registers.

(d.) Restore the original device power state using the saved power state and resource configuration. Verify the device is in the specified device power state using the _PSC and _STA control methods and, if possible, by directly examining the device hardware registers.

  10. Restore all devices to their original device power state and verify using the _PSC and _STA control methods and, if possible, by directly examining the device hardware registers.
  11. Return to legacy (non-ACPI) mode and uninstall SCI handler.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires the target platform’s BIOS to implement the ACPI name space and the hardware supports docking and undocking.

This test requires the operating system to be configured to not utilize ACPI to avoid conflicts.

Results Interpretation

This test creates a detailed test results log file and displays pass/fail status on the screen when the test completes. In addition, the test exit value that is returned to the operating system follows the ETDE test interface standard. The test results log file is specified as a test invocation parameter. Review the test results log file for specific details regarding failures.


TD-3.6 ACPI Pre-OS: ACPI Table and Namespace Dump (ACPIDUMP) Test Description

Overview

The ACPI name space dump (ACPIDUMP) test suite verifies the ACPI tables and name space. The ACPIDUMP test verifies implementation of the minimum ACPI BIOS support assertions by the target platform.

The ACPIDUMP test verifies implementation of the minimum ACPI BIOS support assertions by the target platform. See "ACPI Device Hardware Assertions" for a list of the register hardware assertions, and "ACPI Processor BIOS Assertions" for a list of the ACPI name space BIOS assertions verified.

See Section 16 of the ACPI Specification, Revision 1.0a for the current ACPI Machine Language (AML) Specification, including the AML grammar definition and AML byte stream byte values. The following is quoted from the ACPI Machine Language (AML) Specification

"AML is the ACPI Control Method virtual machine language, a machine code for a virtual machine that is supported by an ACPI-compatible operating system. ACPI control methods can be written in AML, but humans ordinarily write control methods in ASL.

AML is the language processed by the ACPI method interpreter. It is primarily a declarative language. It’s best not to think of it as a stream of code, but rather as a set of declarations that the ACPI interpreter compiles into the ACPI name space at definition block load time. For example, notice that DefByte allocates an anonymous integer variable with a byte size initial value in ACPI space, and passes in an initial value. The byte in the AML stream that defines the initial value is not the address of the variable’s storage location."

The ACPIDUMP test performs the following steps:

  1. Locate and display all tables, validating checksums for all table checksums.
  2. For the DSDT, perform the following name space validate.

a. Verify each reserved name (name beginning with "_") is defined by the ACPI specification.

b. Verify all names are unique at their scope level.

c. Verify each name has a definition block.

d. Verify internal checksums for objects with checksums.

e. Verify minimal length values.

f. Verify register alignment values.

g. Verify required control methods and registers.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires the target platform’s BIOS to implement the ACPI name space, and the motherboard support of the minimum BIOS ACPI requirements.

This test requires the operating system is configured to not utilize ACPI to avoid conflicts.

Results Interpretation

This test creates a detailed test results log file and displays pass/fail status on the screen when the test finishes. In addition, the test exit value returned to the operating system follows the ETDE test interface standard. The test results log file is specified as a test invocation parameter. Review the test results log file for specific details regarding failures.

If this test reports a failure, see Section 16 of the ACPI Specification, Revision 1.0a for the current ACPI Machine Language (AML) Specification, including the AML grammar definition and AML byte stream byte values. The test reports as much context as possible surrounding the failure and resorts to a hex dump of the values within the ACPI name space that are undecipherable due to errors. The display re-synchronizes on the next root-level ACPI name space control method.


TD-3.7 ACPI Embedded Controller Interface (ACPIECIT) Test Description

Note: This test is currently not implemented.

Overview

The ACPI Embedded Controller Interface test (ACPIECIT) addresses the embedded controller. Test coverage for the Embedded Controller is specifically included under the Smart Battery test (ACPISBIT) and in general through all the mobile tests. Embedded Controller accesses are made by the interpreter and EC SCI events are handled by the SCI handler.

The ACPIECIT test implements the following algorithm.

  1. Load ACPI namespace, chain SCI / GPE interrupt, transition into ACPI mode.
  2. Identify all embedded controller ACPI namespace entities based on _HID == PNP0C09, the presence of _CRS and _GPE control methods, and a flat byte-addressable I/O space of 256 bytes.

a. Execute the embedded controller _GPE control method and display the GPE event bit to which the embedded controller is wired.

b. Execute the embedded controller _CRS control method and display the command (EC_SC), data (EC_DATA), and status (EC_SC) port addresses.

  3. Verify embedded controller SCI/GPE event generation.

a. Verify that an SCI is generated when the embedded controller reads the last command or data from the input buffer.

b. Verify that an SCI is generated when the embedded controller has written a byte of data into the output buffer.

c. Verify that an SCI is generated when the embedded controller detects an event that requires operating system attention.

  4. Transfer to legacy mode and unchain the SCI/GPE interrupt handler.

Setup

Test is not implemented

Results Interpretation

Test is not implemented


TD-3.8 ACPI Global Lock (ACPIGLCK) Test Description

Overview

The ACPI global lock (ACPIGLCK) test suite verifies correctness of the BIOS / operating system global lock. See "ACPI Global Lock BIOS Assertions" for a list of the global lock BIOS assertions tested.

The ACPIGLCK test performs the following steps:

  1. Locate the ACPI tables and identify the SCI vector.
  2. Disable all known ACPI event interrupt sources.
  3. Install the system control interrupt handler and transition system to ACPI mode.
  4. Locate global lock address in the Firmware ACPI Control Structure.
  5. Verify the global lock DWORD is in read/write memory.
  6. Obtain global lock and generate sequence where BIOS must wait to obtain global lock.
  7. Return to legacy (non-ACPI) mode and uninstall SCI handler.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires the target platform’s BIOS to implement the ACPI name and the operating system to be configured to not utilize ACPI to avoid conflicts.

Results Interpretation

This test creates a detailed test results log file and displays pass/fail status on the screen when the test completes. In addition, the test exit value returned to the operating system follows the ETDE test interface standard. The test results log file is specified as a test invocation parameter. Review the test results log file for specific details regarding failures.


TD-3.9 ACPI Pre-OS: ACPI Smart Battery Interface (ACPISBIT) Test Description

Overview

The ACPI Smart Battery Interface test (ACPISBIT)verifies the smart battery, smart charger and ACPI BIOS device control methods. Physical battery testing is outside the scope of effort. For information on physical battery test specifications, see the Smart Battery Implementers forum at http://www.sbs-forum.org/

The ACPISBIT test implements the following algorithm:

  1. Locate the ACPI tables and determine the presence of the Smart Battery Specification Table (SBST).
  2. If the SBST is present,

a. Display the SBST contents.

b. Load the ACPI namespace, chain the SCI/GPE interrupt handler, and transfer into ACPI mode.

c. Identify smart battery objects in ACPI namespace (_HID == ACPI0002).

d. Identify the smart battery _SBS object in the ACPI namespace.

Identify the smart battery subsystem configuration.

e. Identify the SMBus host controller bus / device package.

Display the SMBus host controller bus / device configuration.

f. Prompt the user to connect the AC power source (_HID == ACPI0003).

g. Query the smart battery selector and report which batteries are present in the system by examining device object _STA bit 4.

h. Prompt the user to disconnect the AC power source.

i. Verify the smart battery selector generated an event notification for AC power disconnect.

j. Verify the smart battery selector generated an event notification for power source change.

k. Query the smart battery selector and report which battery is communicating with the SMBus host controller.

l. Query the smart battery selector and report which battery is powering the system.

m. Prompt the user to connect the AC power source.

n. Verify the smart battery selector generated an event notification for AC power connect.

(a.) If the smart battery selector function is present in the smart charger, verify this notification was through SelectorState(), not ChargerStatus().

(b.) Verify the smart battery selector generated an event notification for power source change.

(c.) Query the smart battery selector and report which battery is connected to the charger.

o. For each smart battery in the system

(a.) Prompt the user to remove the smart battery.

(b.) Verify the smart battery selector generated an event notification.

(c.) Prompt the user to insert the smart battery.

(d.) Verify the smart battery selector generated an event notification.

p. If the system has more than one smart battery

(a.) Verify all batteries have the same SMBus address.

(b.) Configure the smart battery selector to switch which battery is communicating with the SMBus host controller.

(c.) Query the smart battery selector to verify.

(d.) Configure the smart battery selector to switch back to the original battery communicating with the SMBus host controller.

(e.) Query the smart battery selector to verify.

(f.) Configure the smart battery selector to switch which battery is powering the system.

(g.) Query the smart battery selector to verify.

(h.) Configure the smart battery selector to switch back to the original battery powering the system.

(i.) Query the smart battery selector to verify.

(j.) Configure the smart battery selector to switch which battery is connected to the charger.

(k.) Query the smart battery selector to verify.

(l.) Configure the smart battery selector to switch back to the original battery connected to the charger.

(m.) Query the smart battery selector to verify.

q. Transfer to legacy mode and unchain the SCI/GPE interrupt handler.

Issues and Known Problems

This test must utilize the information that many systems require removal of one or more devices to facilitate a second battery.

This test must utilize the information that a mobile platform may be powered solely from the batteries, or also from an AC power source.

This algorithm needs to be updated to distinguish expected selector and programming behaviors between a smart battery selector and a battery system manager.

Setup

This test requires the target platform’s BIOS to implement the ACPI name space and the hardware supports docking and undocking.

This test requires the operating system to be configured to not utilize ACPI to avoid conflicts.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-3.10 ACPI Pre-OS: Interrupt Routing (ACPIIRT) Test Description

Overview

The ACPI interrupt routing table (ACPIIRT) test suite cross references the interrupt routing information contained in the ACPI name space (control methods) with the interrupt routing information contained in the $PIR PCI interrupt routing table. See "ACPI Interrupt Routing BIOS Assertions" for assertions not yet verified.

This test does not verify the actual routing of an interrupt signal.

The ACPIIRT test performs the following steps:

  1. Obtain ACPI table (control methods) PCI bus 0 _PRT PCI interrupt routing information.
  2. Display ACPI _PRT data.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires the target platform’s BIOS to implement the ACPI name space and the motherboard supports the minimum BIOS ACPI requirements.

This test requires the operating system to be configured to not utilize ACPI to avoid conflicts.

Results Interpretation

This test creates a detailed test results log file and displays pass/fail status on the screen when the test completes. In addition, the test exit value returned to the operating system follows the ETDE test interface standard. The test results log file is specified as a test invocation parameter. Review the test results log file for specific details regarding failures.


TD-3.11 ACPI Pre-OS: Legacy to ACPI State Transition (ACPILAST) Test Description

Overview

The Legacy / ACPI State Transition (ACPILAST) test suite verifies the hardware correctly sequences between the legacy non-ACPI and ACPI modes. While other test cases perform this sequence, ACPILAST focuses on these transitions and makes the transition n times before declaring success. See "ACPI Mode Switching and SCI Hardware Assertions" for a list of the legacy / ACPI state transition and system control interrupt hardware assertions tested, and "Legacy/ACPI State Transition BIOS Assertions" for a list of the legacy / ACPI state transition BIOS assertions tested.

The ACPILAST test also verifies that the implementation of the minimum ACPI support hardware assertions are implemented by the target platform. See the "ACPI Minimum Hardware Assertions" for a list of the minimum ACPI support hardware assertions tested.

The ACPILAST test performs the following steps:

  1. Locate the ACPI tables and identify the SCI vector.
  2. Disable all known ACPI event interrupt sources.
  3. Install the system control interrupt handler and transition system to ACPI mode.
  4. Enable the power management timer (PMT) event.
  5. If the system is an ACPI-only system, skip to step 7.
  6. Validate legacy (non-ACPI) mode to ACPI mode transition and ACPI mode to legacy (non-ACPI) mode transition. (repeat for n iterations).

a. Transition system to legacy (non-ACPI) mode.

b. Verify that the system is in legacy (non-ACPI) mode by verifying SCI_EN is low.

c. Wait for PMT roll-over and ensure that no system control interrupt occurs.

d. Transition system to ACPI mode.

e. Verify that the system is in ACPI mode by verifying that SCI_EN is high.

f. Wait for PMT roll-over and ensure that system control interrupt does occur.

  7. Validate ACPI mode to ACPI mode transitions.

a. Transition the system to ACPI mode.

b. Verify that the system is in ACPI mode by verifying that SCI_EN is high.

  8. Return to legacy (non-ACPI) mode and uninstall system control interrupt handler.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires the target platform’s BIOS to implement the ACPI name space and the motherboard supports the minimum hardware and BIOS ACPI requirements.

This test requires the operating system to be configured to not utilize ACPI to avoid conflicts.

Results Interpretation

This test creates a detailed test results log file and displays pass/fail status on the screen when the test completes. In addition, the test exit value returned to the operating system follows the ETDE test interface standard. The test results log file is specified as a test invocation parameter. Review the test results log file for specific details regarding failures.


TD-3.12 ACPI Pre-OS: ACPI Lid Switch (ACPILID) Test Description

Overview

The ACPI Lid Switch test (ACPILID) addresses hardware and ACPI BIOS lid event generation and notification and ACPI BIOS lid capabilities representation and implementation.

The ACPILID test performs the following steps:

  1. Load ACPI namespace, chain SCI / GPE interrupt, transition into ACPI mode.
  2. Find a single device with _HID == PNP0C0D specified in the ACPI namespace.

a. Verify presence of lid device’s _LID status control method.

Verify _LID status control method returns "open" (non-zero). If not open, prompt the user to open the lid.

b. Instruct user to close the lid, then open the lid.

(a.) Upon GPE event, execute the associated _Qnn or _[L|E]nn control method.

(b.) Verify lid status change notification: Notify(LID,0x80).

(c.) Verify the _LID status control method returns "closed" (zero).

(d.) Upon GPE event, execute the associated _Qnn or _[L|E]nn control method.

(e.) Wait for lid status change notification: Notify(LID,0x80).

(f.) Verify the _LID status control method returns "open" (non-zero).

c. Instruct user to close the lid, then open the lid. A second pass is made for thoroughness.

(a.) Upon GPE event, execute the associated _Qnn or _[L|E]nn control method.

(b.) Verify lid status change notification: Notify(LID,0x80).

(c.) Verify the _LID status control method returns "closed" (zero).

(d.) Upon GPE event, execute the associated _Qnn or _[L|E]nn control method.

(e.) Wait for lid status change notification: Notify(LID,0x80).

(f.) Verify the _LID status control method returns "open" (non-zero).

  3. Transition to legacy mode, unchain SCI / GPE interrupt.

Issues and Known Problems

This test does not test the ability for a lid switch open event to wake the system, if PSW control method is present in the ACPI namespace for the LID device.

Setup

This test requires the target platform’s BIOS to implement the ACPI name space and the hardware supports docking and undocking.

This test requires the operating system to be configured to not utilize ACPI to avoid conflicts.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-3.13 ACPI Multi-Processor Table (ACPIMPT) Test Description

Note: ACPIMPT is not implemented in the initial ACPI compliance test suite.

Overview

The ACPI multi-processor table (ACPIMPT) test suite checks to be sure that the ACPI name space and the PC-MP 1.4 table contain identical data. See "ACPI Processor BIOS Assertions" for a list of the ACPI multi-processor table BIOS assertions tested.

Setup

Test is not implemented

Results Interpretation

Test is not implemented


TD-3.14 ACPI Pre-OS: Power Button and Sleep Button (ACPIPBT) Test Description

Overview

The ACPI Power Button and Sleep Button (ACPIPBT) test verifies the functionality of the ACPI power and/or sleep buttons. See "ACPI Power Button and Sleep Button Assertions" for a list of power button and sleep button hardware assertions tested.

This test does not verify sleep state transitions initiated by the power button and sleep button or the four-second power button override. The sleep state transitions are tested by the ACPISWCT test, and the four-second override is tested by the ACPI4SEC test. For more information on sleep state transition testing, see "ACPI Sleep Wake Control Assertions".

The ACPIPBT test performs the following steps:

  1. Locate ACPI tables and identify SCI vector and location of the power button status and enable bits.
  2. Disable all known ACPI event interrupt sources.
  3. Install the system control interrupt handler and transition system to ACPI mode.
  4. If the power button is a fixed feature:

a. Clear power button status bit (PWRBTN_STS) and power button enable bit (PWRBTN_EN).

b. Verify PWRBTN_STS is set and SCI is not generated when power button is pressed.

c. Clear power button status bit (PWRBTN_STS) and set (enable) power button enable bit (PWRBTN_EN).

d. Verify PWRBTN_STS is set and SCI is generated when power button is pressed.

  5. If the power button is implemented via generic programming model (control method):

a. Enable all General Purpose Events.

b. Prompt user to press power button.

c. Upon GPE event, execute the associated _Qnn or _[L|E]nn control method.

d. Verify power button status change notification: Notify(PBT,0x80).

  6. If the sleep button is implemented as a fixed feature:

a. Clear sleep button status bit and sleep button enable bit.

b. Verify sleep button status is set and SCI is not generated when sleep button is pressed.

c. Clear sleep button status bit and set (enable) sleep button enable bit.

d. Verify sleep button status is set and SCI is generated when sleep button is pressed.

e. Clear sleep button status bit and sleep button enable bit.

  7. If the sleep button is implemented via generic programming model (control method):

a. Enable all General Purpose Events.

b. Prompt user to press sleep button.

c. Upon GPE event, execute the associated _Qnn or _[L|E]nn control method.

d. Verify sleep button status change notification: Notify(SLP,0x80).

  8. If the power button is a fixed feature, verify it can wake the system for each supported sleep state Sx (S1-S3, S4BIOS and S4 not tested).

a. Set the power button enable bit and clear the status bit.

b. Put the system in the Sx supported sleep state.

c. User presses power button to wake system.

d. Clear the power button enable bit and clear the status bit.

  9. If the power button is a generic device with a _PRW object, verify it can wake the system for each supported sleep state Sx (S1-S3, S4BIOS and S4 not tested) where x is less than or equal to the lowest sleep state returned in the _PRW object.

a. Run the _PSW control method associated with the power/sleep button device to enable the power/sleep button device's ability to wake a sleeping system.

b. Clear the GPE status bit and set the GPE enable bit of the GPE returned by the _PRW object.

c. Put the system in the Sx supported sleep state.

d. Prompt user to press power/sleep button to wake system.

e. Upon GPE receiving event, execute the associated _Qnn or _[L|E]nn control method.

f. Verify power button status change notification: Notify(PBT,0x80).

  10. If the sleep button is a generic device with a _PRW object, verify it can wake the system for each supported sleep state Sx (S1-S3, S4BIOS and S4 not tested) where x is less than or equal to the lowest sleep state returned in the _PRW object.

a. Run the _PSW control method associated with the power/sleep button device to enable the power/sleep button device's ability to wake a sleeping system..

b. Clear the GPE status bit and set the GPE enable bit of the GPE returned by the _PRW object.

c. Put the system in the Sx supported sleep state.

d. Prompt user to press power/sleep button to wake system.

e. Upon GPE receiving event, execute the associated _Qnn or _[L|E]nn control method.

f. Verify sleep button status change notification: Notify(SLP,0x80).

  11. If the power button is implemented as a control method:

a. Transition system to legacy (non-ACPI) mode and uninstall system control interrupt handler.

b. Exit test. Future algorithm to be determined.

  12. If the power button is implemented as a fixed feature device, verify power button over-ride.

a. Validate Power Management Timer. This will be used to calculate time stamps.

b. Clear power button status bit (PWRBTN_STS) and set (enable) power button
enable bit (PWRBTN_EN).

c. Flush and disable disk caches, close files.

d. Prompt user to press and hold power button.

e. When PWRBTN_STS is set (SCI occurs), get initial PM Timer value.

f. Calculate elapsed time by getting current PM Timer value and PM Timer rollover SCI count.

g. Open one of two files, write time stamp to it, and close it. The next time the time stamp is written to the other file. This is to ensure that one and only one file is open at the time the machine powers off.

h. If timer exceeds 8 seconds and system is still powered, fail power button over-ride.

  13. After powering down, the time stamps from the files are checked for a shutdown time between 3 and 5 seconds. Systems that do not power down within this time window fail.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires the target platform’s BIOS to implement the ACPI name space with hardware support of the power button.

This test requires the operating system to be configured to not utilize ACPI to avoid conflicts.

Results Interpretation

This test creates a detailed test results log file and displays pass/fail status on the screen when the test completes. In addition, the test exit value returned to the operating system follows the ETDE test interface standard. The test results log file is specified as a test invocation parameter. Review the test results log file for specific details regarding failures.

This test requires the user to interpret the log file for the correct power button over-ride timeout value.


TD-3.15 ACPI Pre-OS: Power Management Timer (ACPIPMT) Test Description

Overview

The ACPI Power Management Timer (ACPIPMT) test suite verifies the power management timer (PMT) related hardware registers and events. See "ACPI Power Management Timer Hardware Assertions" for a list of the power management timer hardware assertions tested, and "ACPI Power Management Timer BIOS Assertions" for a list of the power management timer BIOS assertions tested.

The ACPIPMT test performs the following steps:

  1. Locate ACPI tables and identify SCI vector and location of the power button status and enable bits.
  2. Disable all known ACPI event interrupt sources.
  3. Install the system control interrupt handler and transition system to ACPI mode.
  4. Enable the PMT event.
  5. Verify the PMT is implemented in fixed I/O register space.
  6. Verify that TMR_VAL and E_TMR_VAL are read-only registers.
  7. Verify that PMT MSB toggles generate PMT events.

a. Disable PMT event (clear TMR_EN).

b. Verify that MSB toggle sets TMR_STS and does not generate a PMT event.

(a.) While awaiting MSB toggle, verify that TMR_STS is not set and no PMT event is generated.

(b.) While awaiting MSB toggle, verify that PMT is strictly a count-up timer in G0/S0 power state.

(c.) While awaiting MSB toggle, if PMT is 24-bit timer, verify that E_TMR_VAL always returns zero.

c. Verify that MSB toggle (other direction) sets TMR_STS and does not generate a PMT event.

d. Enable PMT event (set TMR_EN).

e. Verify that MSB toggle sets TMR_STS and generates a PMT event.

f. Verify that MSB toggle (other direction) sets TMR_STS and generates a PMT event.

  8. Verify that PMT clock is running at 3.579545 MHz by comparing elapsed PMT time to elapsed RTC time. (RTC vs. PMT performance can only be reliably measured to within 2% due to software overhead.)
  9. Return to legacy (non-ACPI) mode and uninstall system control interrupt handler.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires the target platform’s BIOS to implement the ACPI name space, and the hardware support of the power management timer (PMT) in fixed I/O register space and PMT events.

This test requires the operating system to be configured to not utilize ACPI to avoid conflicts.

Results Interpretation

This test creates a detailed test results log file and displays pass/fail status on the screen when the test completes. In addition, the test exit value returned to the operating system follows the ETDE test interface standard. The test results log file is specified as a test invocation parameter. Review the test results log file for specific details regarding failures.


TD-3.16 ACPI Resource Configuration (ACPIRCT) Test Description

Overview

The ACPI Resource Configuration (ACPIRCT) test suite verifies correctness of all device resource configuration operations that can be performed on each device defined by the ACPI name space. See "ACPI Resource Configuration Hardware Assertions" for a list of the resource configuration hardware assertions tested and "ACPI Resource Configuration BIOS Assertions" for a list of the resource configuration BIOS assertions tested.

The ACPIRCT test performs the following steps:

  1. Locate the ACPI tables and identify the SCI vector.
  2. Disable all known ACPI event interrupt sources.
  3. Install the system control interrupt handler and transition system to ACPI mode.
  4. Enumerate all motherboard devices in the ACPI name space using _HID, and _CRS control methods.
  5. Disable as many (ISA Plug-n-Play, PCI, and ACPI) devices as possible to free up resources for configuration testing.
  6. Select the first or next device.

a. While the device is disabled, invoke the _CRS control method and the _PRS control method, if _PRS is present. Ensure these methods do not enable the device.

b. Display the device's _HID along with the control methods it supports.

c. Display the device's current resources and its possible resource configurations.

d. If the device has a _UID control method, display its unique ID.

e. Obtain and save the state of current device via _CRS, _PSC, and _STA control methods.

f. Verify the current state, if possible, by directly examining the device hardware registers.

g. Identify all child devices, save their state, and transition them to the D3 off device power state.

h. Validate disabling and enabling the device:

(a.) Disable the device using the _DIS control method.

(b.) Verify the device is disabled using the _STA control method, and, if possible, by directly examining the device hardware registers.

(c.) Restore the device to saved state using the _SRS control method.

(d.) Verify the device is restored using the _CRS and _STA control methods, and, if possible, by directly examining the device hardware registers.

i. Validate configuring device resources.

(a.) Obtain possible resources with the _PRS control method.

  • Using the _SRS control method, configure the device to first/next possible configuration defined in configuration space returned by the _PRS control method.
  • Verify the new configuration with the _CRS control method, and, if possible, by directly examining the device hardware registers.

(b.) Restore the device to its saved configuration state using the _SRS and _PSx control methods.

(c.) Verify the restored device configuration state using the _CRS, _PSC, and _STA control methods, and, if possible, by directly examining the device hardware registers.

  7. Restore all devices to their original device configuration state.
  8. Return to legacy (non-ACPI) mode and uninstall the system control interrupt handler.

Results Interpretation

This test creates a detailed test results log file and displays pass/fail status on the screen when the test completes. In addition, the test exit value returned to the operating system follows the ETDE test interface standard. The test results log file is specified as a test invocation parameter. Review the test results log file for specific details regarding failures.


TD-3.17 ACPI Real-Time Clock (ACPIRTC) Test Description

Overview

The ACPI real-time clock (ACPIRTC) test suite verifies correctness of real-time clock and real-time clock alarm functions required to support ACPI. See "ACPI Real-time Clock and RTC Alarm Hardware Assertions" [page 4.59] for a list of resource configuration hardware assertions tested and "ACPI Real-time Clock and RTC Alarm BIOS Assertions" for a list of resource configuration BIOS assertions tested.

ACPIRCT performs the following steps:

  1. Locate ACPI tables and identify SCI vector and location of the power button status and enable bits.
  2. Disable all known ACPI event interrupt sources.
  3. If ACPI namespace indicates support for MON_ALRM (MON_ALRM > 0), verify that ACPI namespace indicates support for DAY_ALRM (DAY_ALRM > 0).
  4. If ACPI namespace indicates support for DAY_ALRM (DAY_ALRM > 0),

a. Install the system control interrupt handler and transition system to ACPI mode.

b. Verify that DAY_ALRM specifies "don’t care".

c. If MON_ALRM is supported (MON_ALRM > 0), verify that MON_ALRM specified "don’t care".

d. If CENTURY value is supported, set CENTURY to current date’s century.

e. For each supported Sx sleep state, x<4 or (x==4 and FACP RTC_S4 flag is set).

(a) Set RTC alarm 5 seconds in the future.

(b) Enter Sx sleep state.

(c) Verify system awoke from RTC alarm (vs. user keyboard/button input).

  • Verify PM1x_STS register RTC_STS RTC alarm status bit is set.
  • Verify keyboard, power button, and sleep button status bits are not set.

(d) If ACPI namespace indicates support for CENTURY value, validate CENTURY increments at each of the next years roll-over.

f. Return to legacy (non-ACPI) mode and uninstall system control interrupt handler.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires that the target platform’s BIOS implements the ACPI name space, and the motherboard supports the minimum hardware and BIOS ACPI requirements.

This test requires the operating system to be configured to not utilize ACPI to avoid conflicts.

Results Interpretation

This test creates a detailed test results log file and displays pass/fail status on the screen when the test completes. In addition, the test exit value returned to the operating system follows the ETDE test interface standard. The test results log file is specified as a test invocation parameter. Review the test results log file for specific details regarding failures.


TD-3.18 ACPI Sleep Wake Control (ACPISWCT) Test Description

Overview

The ACPI Sleep Wake Control (ACPISWCT) test suite verifies the hardware, corrects sequencing between the various sleeping states and the working state. Only sleeping states with _Sx packages in the ACPI name space are tested. See "ACPI Power State Transition Hardware Assertions" for a list of the power state transition hardware assertions tested and "ACPI Sleep/Wake Power State Transition BIOS Assertions" for a list of the power state transition BIOS assertions tested.

The ACPISWCT test performs the following steps:

  1. Locate ACPI tables and identify system control interrupt vector and location of the power button status and enable bits.
  2. Disable all known ACPI event interrupt sources.
  3. Install system control interrupt handler and transition the system to ACPI mode.
  4. For each of the supported sleep states (S1, S2, S3, S4, S4BIOS).
  5. For each possible wake event (i.e., power button, RTC alarm, and others identified through the ACPI name space tables such as ring indicator).

a. Execute _PTS and prepare for sleep control method.

b. Clear all general-purpose event status and enable bits.

c. Program wake device (such as, RTC alarm), if necessary.

d. Enable wake event.

e. Satisfy all operating system requirements for the current sleep state (i.e., flush caches, write entry point into FACP, etc.).

f. Write the SLP_TYP register with the value specified in the \_Sx package.

  6. Sequence hardware into specified sleep state.
  7. When the system awakens from enabled wake event, verify wake event status bit.
  8. Execute _WAK control method.
  9. Clear all general-purpose event status and enable bits.
  10. Return to legacy (non-ACPI) mode and uninstall system control interrupt handler.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires the target platform’s BIOS to implement the ACPI name space and the hardware to support at least one Sx (x>0) sleeping state and at least the real-time clock alarm and power button wake events.

The S2 and S3 (if supported) wake states start at processor initialization vector and transfer execution to the ACPI wake vector specified in the FACP.

This test requires the operating system to be configured to not utilize ACPI to avoid conflicts.

Results Interpretation

This test creates a detailed test results log file and displays pass/fail status on the screen when the test completes. In addition, the test exit value returned to the operating system follows the ETDE test interface standard. The test results log file is specified as a test invocation parameter. Review the test results log file for specific details regarding failures.


TD-3.19 ACPI Thermal Management (ACPITHRM) Test Description

Note: ACPITHRM is not implemented in the initial ACPI compliance test suite.

Overview

The ACPI thermal management (ACPITHRM) test suite verifies the hardware's correct reporting of thermal events and the BIOS ACPI thermal management control methods. See "ACPI Embedded Controller, SMBus, and Battery Hardware Assertions" for a list of the thermal management hardware assertions tested and "ACPI Thermal Management BIOS Assertions" for a list of the thermal management BIOS assertions tested.

Setup

Test is not implemented

Results Interpretation

Test is not implemented


TD-3.20 ACPI Pre-OS: Processor Throttling (CPUTHRTL) Test Description

Overview

The ACPI Processor Throttling (CPUTHRTL) test suite verifies CPU throttling support. See "ACPI Processor Hardware Assertions" for processor throttling hardware assertions tested and "ACPI Processor BIOS Assertions" for processor throttling BIOS assertions tested.

The CPUTHTRL test performs the following steps:

  1. Locate ACPI tables and identify system control interrupt vector.
  2. Verify the ACPI name space supports processor throttling. If not supported, exit test.
  3. Disable all known ACPI event interrupt sources.
  4. Install system control interrupt handler and transition the system to ACPI mode.
  5. Measure the time required to perform a specific task.
  6. Enable processor throttling.
  7. Measure the time required to perform the same task.
  8. Return the processor to full speed.
  9. Compare the execution times to determine pass/fail status.
  10. Return to legacy (non-ACPI) mode and uninstall system control interrupt handler.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires the target platform’s BIOS to implement the ACPI name space and the processors to support at least one C1-C3 processor power state. Support for a real-time alarm wake event is also required.

This test only executes on processors that support the Intel® IA32 instruction set.

This test requires the operating system be configured to not utilize ACPI to avoid conflicts.

This test must run in real mode to support accessing CPU MSRs.

Results Interpretation

This test creates a detailed test results log file and displays pass/fail status on the screen when the test completes. In addition, the test exit value returned to the operating system follows the ETDE test interface standard. The test results log file is specified as a test invocation parameter. Review the test results log file for specific details regarding failures.


TD-3.21 ACPI Pre-OS: Interrupt 15h Function E820h System Address Map (I15_E820) Test Description

Overview

The ACPI Interrupt 15h Function E820h Query System Address Map (I15_E820) test suite verifies the BIOS interrupt 15h function E820h. See "ACPI Interrupt 15h Function E820h Query System Address Map Assertions" for a list of the interrupt 15h function E820h query system address map BIOS assertions tested.

The 15_E820 test performs the following steps:

  1. Obtain addresses of all ACPI tables.
  2. Verify presence of interrupt 15h function E820h.
  3. Execute interrupt 15h function E820h.
  4. Verify all memory claimed by ACPI tables outside of F000h BIOS block other than the RSDP and RSDT is included in the ACPI reclaim memory.
  5. Verify that interrupt 15h function DA88h (if supported) and interrupt 15h function E801h return memory size that agrees with the memory size returned by the interrupt 15h function E820h.
  6. Verify memory ranges defined do not overlap.
  7. Verify that ACPI tables are properly defined in AddressRange and AddressRangeNVS memory ranges.
  8. Verify that interrupt 15h function E820h returns carry flag set if called with an invalid signature value of 0FFFFFFFFh.
  9. Verify that interrupt 15h function E820h returns carry flag set if called with an invalid continuation value of 0FFFFh.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires the target platform’s BIOS to implement the ACPI name space and the motherboard supports the minimum BIOS ACPI requirements.

This test requires the operating system to be configured to not utilize ACPI to avoid conflicts.

Results Interpretation

This test creates a detailed test results log file and displays pass/fail status on the screen when the test completes. In addition, the test exit value returned to the operating system follows the ETDE test interface standard. The test results log file is specified as a test invocation parameter. Review the test results log file for specific details regarding failures.


TD-3.22 ACPI Hardware Register Assertion Checklist

Overview

The following ACPI hardware register assertions checklist (Table 3-2) verifies the assertions listed in "ACPI Register Implementation Hardware Assertions". Some of these assertions may be implicitly tested by existing test cases, but none are explicitly tested by an existing test case.

This test requires the person(s) filling in the checklist to have access to and be familiar with the hardware register and board design documents and files.

Answer each line item in the following checklist.

TD-3.22. ACPI Hardware Register Assertions Checklist

Assertion | Description | Confirm
3.17.1 | Fixed space features are limited to performance sensitive features, feature drivers required during wakeup, and features that enable catastrophic failure recovery. |
3.17.2 | "Child" interrupt status bits residing in generic address space have a "parent" interrupt status bit in the GP_STS register. |
3.17.3 | Generic location power management feature bits reside in system I/O space, system memory space, PCI configuration space, embedded controller space, or SMBus device space. |
3.17.4 | ACPI (e.g., event and control) hardware register reserved and unimplemented bits always return zero, and data writes to them have no side effects. |
3.17.5 | ACPI hardware register write-only control bits are activated by software writing a 1 to their bit position. |
3.17.6 | The target platform contains no cross device dependencies (i.e., configuration mode blocks access to another device, or atomic back-to-back write access requirements). |
3.17.7 | Status bits are set by hardware event input HIGH. |
3.17.8 | The general-purpose event registers contain the root level events for all generic features. |
3.17.9 | ACPI-compatible hardware programming bits reside in any of the system I/O, system memory, PCI configuration, embedded controller, or SMBus address spaces, but the top-level event bits are contained in the general-purpose registers. |
3.17.10 | The top level "parent" event status and enable bits reside in either the GPE0_STS or the GPE1_STS registers. ("Child" event status bits can reside in generic address space.) |
3.17.11 | System that support both APIC and dual 8259 interrupt models map interrupt vectors 0-15 to 8259 IRQs 0-15. |
3.17.12 | Cascaded general-purpose events from a bit in the GPEx_BLK are through status and enable bits in I/O space, memory space, PCI configuration space, or embedded controller space. |
3.17.13 | Multiple devices using the same general-purpose event bit utilize OEM-specific hardware to provide second-level status and enable bits. |
3.16.1 | Unutilized GPE event pins are tied inactive such that the corresponding GPE register SCI status bit is not set by a floating input pin. |

Results Interpretation

If any of the line items in the preceding checklist were not confirmed, this test fails.

If all line items in the preceding checklist were confirmed, this test passes.


TD-3.23 ACPI BIOS Assertion Checklist

Overview

The following ACPI BIOS assertions checklist (Table 3-4) verifies the assertions listed previously. The section "ACPI BIOS Assertions Checklist" contains a list of specification pointers that identify these assertions. Some of these assertions may be implicitly tested by existing test cases, but none are explicitly tested by an existing test case.

This test requires that the person(s) filling in the checklist to have access to and be familiar with the ACPI BIOS source code.

Answer each line item in the following checklist.

TD-3.23. ACPI BIOS Assertions Checklist

Assertion | Description | Confirm
3.19.3 | System provides no user-accessible method for disabling ACPI in the BIOS. |
3.38.1 | ASL/AML code does not manipulate fixed feature space registers. |
3.38.2 | ASL/AML code does not access the general-purpose event registers. |
3.38.3 | A control method only assumes that access to global objects is exclusive for any period the control method does not block. |
3.38.4 | Operation Regions have exclusive access to the hardware registers. |
3.38.5 | Control methods do not directly access any other hardware registers, including the ACPI-defined register blocks. |
3.38.6 | Control methods for GPE events use the naming convention \_GPE._TXX where T (event handling type) is 'E' for edge event or 'L' for level event and XX is the hex value format of the event. |
3.38.7 | Event values for status bits in GPE0_BLK start at zero (_T00) and end at GPE0_BLK_LEN - 1. |
3.38.8 | Event values for status bits in GPE1_BLK start at GPE1_BASE and end at GPE1_BASE + GPE1_BLK_LEN - 1. |
3.38.9 | All ACPI operating system notifications of various object-related events are done with the Notify operator that supplies the ACPI object and a notification value that signifies the type of notification being performed. |
3.38.10 | Notification values from 0 through 7Fh are common across all device object types implementing notification. |
3.38.11 | Notification values above 7Fh are device-specific and defined by each such device implementing notification. |
3.38.12 | The ACPI AML code notifies the operating system at all times other than boot that the Plug and Play re-enumeration operation is required by issuing a Device Check notification. |
3.38.13 | The _SLN device identification object specifies the slot number for each slot. |
3.38.14 | The _SST system indicator control method is used to specify/sets the system status indicator. |
3.38.15 | The _MSG system indicator control is used to specify when messages are waiting. |
3.38.16 | If a device is present in the machine but should not be displayed in the operating system user interface, device object _STA bit 2 is cleared. |
3.38.17 | The _INI device initialization object performs all device-specific initialization for all devices. |
3.38.18 | All _INI device initialization objects are located under the device object to which they apply. |
3.38.19 | All _INI device initialization objects only accesses system I/O, system memory, and the PCI configuration space. They do not access the embedded controller or the SMBus. |
3.38.20 | AML utilizes the _REG control method to ensure that AML does not access registers in a driver’s operation region before an operation region device driver is ready. |
3.38.21 | Before an operation region device driver is ready, AML cannot access registers in that operation region. |

Results Interpretation

If any of the line items in the preceding checklist were answered as No, this test fails.

If all line items in the preceding checklist were answered as Yes, this test passes.


TD-3.24 Reserved Name Usage Test Description

Overview

The Reserved Name Usage Test verifies that the _SBC and _SBS objects do not exist in the target system’s ACPI tables. These objects were valid under ACPI 1.0 compliant systems, but are undefined under ACPI 1.0b.

The Reserved Name Usage test performs the following steps:

  1. If test environment’s ACPI namespace is not initialized, locate ACPI tables in memory.
  2. Parse tables and creates an internal ACPI namespace.
  3. If any of the _SBC or _SBS objects found, mark ACPI 1.0b compliance failure.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test is a Win32 application with WDM drivers running in both Windows 2000 and Windows XP.

Results Interpretation

This test creates a detailed test results log file and displays pass/fail status on the screen when the test completes. Review the test results log file for specific details regarding failures.


TD-3.25 Thermal Model Test Description

Overview

The Thermal Model Test verifies that existing thermal zones have the minimum objects needed and that any paired objects have their respective partners. See ACPI 1.0b Specification, Section 12 for more details.

The Thermal Model test performs the following steps:

  1. If the test environment’s ACPI namespace is not initialized, locate ACPI tables in memory.
  2. Parse tables and creates internal ACPI namespace.
  3. For each Thermal Zone in the ACPI namespace, validate that _TMP and at least one of _ACx, _CRT, or _PSV exist in the Thermal Zone.
  4. Validate that for each _ACx, there is a corresponding _ALx.
  5. Validate that if _PSV is implemented, _PSL, _TC1, _TC2, and _TSP are also implemented.

Setup

This test requires the target platform’s BIOS to implement the ACPI name space and the hardware supports docking and undocking.

This test requires the operating system to be configured to not utilize ACPI to avoid conflicts.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-3.26 ACPI Pre-OS: ACPI Unique P_BLK Test Description

Overview

The Unique P_BLK test verifies that there is a unique P_BLK for each CPU in the system, if any P_BLK objects are declared in the ACPI tables. Having a unique P_BLK per CPU allows the OS to control individual CPU's throttling and Cx states.

The Unique P_BLK test performs the following steps:

  1. If MP Floating Pointer is found in memory,

a. Check Physical Address Pointer to see if MP Configuration Table exists.

b. If MP Configuration Table exists,

(a) Step through all table entries.

(b) Sum total number of processors.

c. Else, If MP Feature Information Byte is non-zero, system supports two processors

  2. If test environment’s ACPI namespace not initialized,

a. Locate ACPI tables in memory

b. Parse tables and creates internal ACPI namespace

  3. Search namespace for P_BLK objects
  4. If either none exist or the same number exist as declared in the MP tables, verify that each is truly unique.

Setup

This test requires the target platform’s BIOS to implement the ACPI name space and the hardware supports docking and undocking.

This test requires the operating system to be configured to not utilize ACPI to avoid conflicts.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-3.27 ACPI Pre-OS: ACPI BBN Resolution Test Description

Overview

The _BBN Resolution test is applicable on systems with multiple host bridges declared in the ACPI tables. PCI devices declared in the ACPI tables have their device and function information available from the _ADR method, but the bus number needs to be resolved. This is done through evaluating the ACPI device structure and the _BBN method on machines with more than one host bridge. This test verifies that the device structure declared in the ACPI tables is consistent with the device tree obtained through PCI configuration space. Note that it is not a requirement to have all PCI devices declared in the ACPI tables; rather the overall structure must be correct. The ultimate goal of this test is to ensure that devices declared in the ACPI tables can be addressed by the operating system correctly.

The _BBN Resolution test performs the following steps:

  1. If the test environment’s ACPI namespace is not initialized, locate ACPI tables in memory
  2. Parse tables and creates internal ACPI namespace
  3. Search for multiple devices with a _HID of PNP0A03 and corresponding _BBN objects.
  4. If multiple host bridges are found,

a. Create PCI device tree with bus/dev/function information gathered from the ACPI tables.

b. Overlay created PCI device tree on information returned from PCI configuration space.

c. Verify device identified by bus/dev/func information from ACPI tables exists in PCI configuration space.

Setup

This test requires the target platform’s BIOS to implement the ACPI name space and the hardware supports docking and undocking.

This test requires the operating system to be configured to not utilize ACPI to avoid conflicts.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-3.28 USB Root Hub _ADR Test Description

Overview

The USB Root Hub _ADR test verifies that USB root hubs declared in the ACPI tables have an _ADR of 0. The test determines if there are any USB host controllers in the system by scanning PCI configuration space and determining if there are any matching devices declared under ACPI. If so, the test then searches for any child devices whose _ADR evaluates to zero. The test then verifies that this device is a USB root hub.

The USB Root Hub _ADR test performs the following steps:

  1. Query PCI space for all USB Host Controllers.
  2. If any USB Host Controllers found,

a. If the test environment’s ACPI namespace not initialized, locate ACPI tables in memory.

b. Parse tables and creates internal ACPI namespace

c. For all hosts found, search ACPI namespace for devices with bus/dev/func information that matches.

d. For each matching ACPI device found,

(a) For each direct child device,

If _ADR = 0, verify it is a USB root hub

Setup

This test requires the target platform’s BIOS to implement the ACPI name space and the hardware supports docking and undocking.

This test requires the operating system to be configured to not utilize ACPI to avoid conflicts.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-3.29 Docking Test Description

Overview

The Docking test verifies that systems claiming docking support have the required minimal control methods and objects. Systems with the DCK_CAP bit set in the FACP table are checked for _DCK, _EJD, _WAK and _UID methods.

The Docking test performs the following steps:

  1. If the test environment’s ACPI namespace is not initialized, locate ACPI tables in memory.
  2. Parse tables and creates internal ACPI namespace.
  3. If DCK_CAP set, search namespace for required _DCK control method.
  4. Verify parent device of _DCK control method contains an _STA method.
  5. Search namespace for required _EJD control method.
  6. Search namespace for required _WAK control method.
  7. Search namespace for required _UID control method.
  8. Search namespace for optional _BDN control method.

Setup

This test requires the target platform’s BIOS to implement the ACPI name space and the hardware supports docking and undocking.

This test requires the operating system to be configured to not utilize ACPI to avoid conflicts.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-3.30 Video Extensions Test Description

Overview

The Video Extensions test verifies that all declared video output devices have the required _DCS method. This test determines if the video controller is present in the ACPI tables. If it is, the test continues to check the video controller’s child devices for the required _DCS method. This test assumes that all children of a video controller are display output devices.

The Video Extensions test performs the following steps:

  • If video controller(s) found in PCI configuration space,

a. If the test environment’s ACPI namespace is not initialized, locate the ACPI tables in memory.

b. Parse tables and creates internal ACPI namespace

c. Search ACPI namespace for devices with bus/dev/func information that matches

d. For each matching ACPI device found, verify that all children of the video device have a _DCS method in their scope.

Setup

This test requires the target platform’s BIOS to implement the ACPI name space and the hardware supports docking and undocking.

This test requires the operating system to be configured to not utilize ACPI to avoid conflicts.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-3.31 ACPI Sleep Test Description

Test Kit: HCT 11, HCT 10

Overview

The computer system does not need to be in any special configuration to perform this test. If the system is running Windows 2000 and not in a ACPI mode the system sleep state S4 (a.k.a. Hibernation) may be supported on the computer and for this reason the test should be run on all systems. What the test is designed to do is to place the computer into various sleep states, wait for the user to press the power button to wake the system back up, and then the user needs to respond to the question of "Did it sleep or not?". Each supported sleep state is tested twice; once doing a standard sleep and once for a critical sleep action. To achieve the test’s desired effect the following steps are taken:

  1. Look at the SYSTEM_POWER_CAPABILITIES structure and based on the structure create a list of the sleep states to test.
  2. Signal to the user, which system sleep state is to be tested via a dialog box.
  3. The user must press OK to initiate the transition to the specified sleep state.
  4. The machine is signaled to transition to the specified sleep state by:

a. Modifying the Administrative Power Policy’s MinSleep and MaxSleep settings so the are the same and are equal to the specified sleep state the machine will be transitioning into.

b. Using the NtInitiatePowerAction function call and passing in as the minimum sleep state to be the specified sleep state.

  5. When the computer has returned from the specified sleep state the user is asked to acknowledge that the computer actually did go to sleep.
  6. This is repeated for each supported system sleep state and then is repeated but this time setting the critical action flag so a critical sleep into the supported system sleep state will occur.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test must be run from the local hard disk drive or various issues may arise (including failure of transitioning into a specified sleep state).

Results Interpretation

This test creates a detailed test results log file using NTLOG.DLL type logging or if it is not available a custom logging scheme. For each sleep state entered a pass or a failure will be written to the log file. If it is detected that machine had to be restarted due to a hang or what not then the restart is logged and the previous system sleep state attempted is marked as a failing. The log file to consult for test results is located in the same folder as the test was ran from and is name acpislp.log

Test Execution Flowchart

TD 3-31 Test Flow


TD-3.32 Wakedevs Test Description

Test Kit: HCT 11, HCT 10

Note In the HCT kit, this test is the USB Device Wake Up test and the LAN Device Wake Up test.

Overview

Wakedevs first determines which devices support wake on the system then it validates that the system correctly reports the ACPI wake capabilities of these devices. Any device that reports this capability but can not wake the system will fail the test. This test is a high level test to exercise wake functionality, and will not be able to pinpoint what exactly is wrong on the OEM platform.

This test indirectly validates the requirements listed below have been correctly implemented by the OEM:

  • Devices must have a _PRW namespace object associated to the device itself of the devices parent controller.
  • PCI devices that support wake need to correctly implement the PMC register in the devices PCI configuration space.

Every device will be tested individually and every sleep state the device supports wake from will be tested. If a device reports that it can wake the system from every sleep state then wakedevs will enter each sleep state before testing the next device.

Wakedevs will inform the user as to which device is to be tested. Testing will conclude after every device has been tested in every sleep state supported by that device.

Testing will fail if the system is waked via the power button or real time clock. The option to retest the device is available.

Failures will need to be examined to determine if the point of failure is BIOS related, Windows XP related, or an issue with the test.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Devices must have a _PRW namespace object associated to the device itself of the devices parent controller.

PCI devices that support wake need to correctly implement the PMC register in the devices PCI configuration space.

Results Interpretation

Failures will need to be examined to determine if the point of failure is BIOS related, Windows XP related, or an issue with the test. Further debugging is required to pinpoint the exact cause of the failure.


TD-3.33 Enable/Disable - Device I/O Test Description

Test Kit: HCT 11, HCT 10

Overview

The Enable/Disable - Device I/O test (DEnumCmd) ensures that Plug and Play device drivers can be disabled and removed without error. This test does the following:

  • Test device driver to ensure it is functioning.
  • Perform a surprise removal of the device under test.
  • Should not crash on removal (blue screen)
  • Check that driver is removed.
  • Check for resource leaks
  • Re-enumerate device.
  • Test device driver to ensure it is functioning.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Only one instance of a device per driver is allowed for this test.

Results Interpretation

Review log files for error messages.


TD-3.34 ACPI Verifier Test Description

Test Kit: HCT 11, HCT 10

Overview

The ACPI Verifier (ACPIVer) test verifies that the Advanced Configuration and Power Interface (ACPI) return values are accurate.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires the target platform’s BIOS to implement the ACPI name space and the hardware supports docking and undocking.

This test requires the operating system to be configured to not utilize ACPI to avoid conflicts.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-3.35 Unreported Memory and I/O Port Test Description

Test Kit: HCT 11

Overview

This is a global system test that searches out all free memory and I/O resources and decodes them to ensure that they are truly free. It is the responsibility of the BIOS to report all built-in system devices and legacy hardware resources to the operating system (OS). If the BIOS fails to report a range that is really in use, the OS could, in theory, put another device in this range, potentially causing the system to crash. In addition to BIOS problems, this test can also detect problems with hardware. For example, if there is a device on the system that is supposed to only decode 20 bytes of an I/O port range, but in reality decodes 30 bytes, this also causes a test failure.

Unreported I/O Port Test

A resource tree is mapped from the arbiter of all claimed I/O ports. All unclaimed ports are read. If the memory read of the I/0 port range returns 0xFF, the test passes. If the read returns anything other than 0xFF, the test fails.

Unreported Memory Test

A resource tree is mapped from the arbiter of all claimed memory ranges. All unclaimed memory ranges are read.

A pass is indicated in the following cases:

  • BYTE read returns 0xFF
  • WORD read returns 0xFFFF
  • DWORD read returns 0xFFFFFFFF

A failure is indicated in the following cases:

  • BYTE read returns anything other than 0xFF
  • WORD read returns anything other than 0xFFFF
  • DWORD read returns anything other than 0xFFFFFFFF

Note Memory and I/O port addresses that are claimed, but not used, are not validated in this test.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Hardware

  • x86-based systems

Results Interpretation

The test program displays and logs the pass/fail indication of compliance with this requirement. The test will show all memory and I/0 port addresses that fail, but will have a single pass/fail objective.

Note It might be difficult to pinpoint the exact component that causes the failure. All that is known is that a "free resource" is being decoded by something in the system. You might need to do some investigative work to figure out what is decoding the range in question.


TD-3.36 ACPI Errors Test Description

Test Kit: HCT 11

This test checks the system event log for the presence of any errors reported by the ACPI driver. If an error is found, the test writes the failure to a log file, along with the description of the error as reported by the operating system. To successfully pass this test, no ACPI errors must occur in the system event log.

The errors include, but are not limited to, BIOS ACPI machine language (AML) reads from or writes to specific addresses. For ACPI BIOS implementations that are compatible with Windows XP, the BIOS AML code must not directly access or attempt to modify certain hardware resources. The operating system blocks all read and write accesses to the addresses associated with these resources and records the error in the system event log.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Hardware

A system running in ACPI mode.

Required Software

A system running Windows XP or Windows .Net Server 2003.

Results Interpretation

The test program displays and logs the pass/fail indication of compliance with this requirement. The name of the log file is ACPIErrors.log.


TD-3.37 CPU P-State and CPU P-State Battery Test Description

Test Kit: HCT 11

Overview

This hardware compatibility test validates processor performance states and processor throttle states, collectively referred to in this document as P-states. Performance states are based on voltage and frequency for a given processor. Throttle states are those states corresponding to processor frequencies implemented using stop-clock throttling, where the processor is essentially stopped for some percentage of clock ticks. Throttle states are applied to the lowest voltage performance state to effectively extend the range of frequencies below that state’s frequency.

Each P-state has a corresponding processor speed and an average power consumption level, where voltage, power consumption, and processor speed are directly, though not necessarily linearly, proportional. When the processor is put into P-state n, it runs at the speed corresponding to that state. The processor speed can change dynamically depending on processor utilization, user policy, and thermal and other conditions. The rationale behind this technology is primarily twofold: to conserve power, particularly when running on battery, and to regulate heat dissipation to avoid overheating. This test validates each P-state by verifying that the processor is actually running at the advertised speed, within a certain tolerance.

The processor is one of several components needed to support P-states. Chipset support is required to control regulation of voltage to the processor. For ACPI systems, tables in the BIOS convey the P-states to the operating system. Older systems sometimes use a processor-specific legacy interface for publishing and changing the processor performance states. The legacy interface was created to bring this functionality to pre-ACPI 2.0 systems, and its implementation is processor-vendor specific.

This test does not address processor power states (C0, C1, etc.).

Click to show or hide information. Additional Information

P-states are optional. Not all systems will support P-states, including many ACPI systems. This is perfectly valid. Many desktop systems without the hardware to support P-states fall into this category. If a system supports them, there are several cases:

  • ACPI 1.0. ACPI 1.0 processor throttle states are supported by Windows XP and covered by this test. Throttle states are entered in response to thermal events in order to cool the system, and in low battery situations in order to further conserve power. Throttle states are described in the FADT section of the ACPI 1.0 namespace. ACPI 1.0 throttle states can and often do coexist on the same system with ACPI 2.0 performance states. Further details are beyond the scope of this document; see the ACPI 1.0b specification. Systems can support ACPI 1.0 throttle states along with any one of the other types of performance states described here.
  • ACPI 2.0. ACPI 2.0 processor performance states are supported by Windows XP and covered by this test. All performance states are described entirely by two ACPI 2.0 packages and one method in an ACPI 2.0-compliant BIOS. Information provided by these includes processor speed, average power consumption, maximum transition latency to this state, and maximum duration that bus masters are unable access memory during transition per performance state. Also provided are two addresses for performance state control and status.
  • Legacy interface to performance states. A legacy interface provides access to performance states by means of a mechanism specific to a processor vendor. These interfaces are not in any ACPI specification. Standard implementations are supported by Windows XP and are covered by this test. The only way non-ACPI systems can support performance states is through a legacy interface.
  • Proprietary legacy interface to performance states. A proprietary legacy interface provides access to performance states in a non-standard way. Windows does not recognize these performance states. Likewise, this test is ignorant of their existence initially, but will attempt to detect their presence. Some older laptops use a proprietary legacy interface.

Processor driver WMI interface

All processor drivers, including those from third parties, need to support the WMI interface for querying the existence and properties of P-states for testing purposes. WMI provides a user-mode interface for reading the ACPI 2.0 _PSS and _PPC processor objects, or a simulated version of such objects in the ACPI 1.0 and legacy interface cases. Microsoft will conduct a code review of all third party processor driver code, and Microsoft reserves the right to change this code before release.

Click to show or hide information. Test Methodology

The internal test logic has several distinct phases.

  1. Validate the context the test is running in.

Make sure the operating system is not temporarily constraining available P-states such that the test has no chance to pass. For example, a system with a thermal zone that reports an overheated condition will cause the operating system to temporarily render the fastest P-state(s) unavailable. A system running on DC power with a low battery while in the degrade processor throttle policy will cause the operating system to render the fastest throttle state(s) unavailable.

  2. Determine whether the system supports P-states or not.

This is queried via the WMI interface to the processor driver. If P-states are reported, go to step 3. If P-states are not reported, go to step 4.

  3. Validate all P-states.

To do this, the test cycles through all four processor throttle policies, where each policy constrains the processor to a subset of P-states that can be entered. For each policy, the goal is to validate the P-state(s) associated with that policy. This is done by gradually changing the CPU utilization up and down through its entire range with a worker thread. The operating system dynamically selects the appropriate P-state given the processor throttle policy and the current CPU utilization. Each time the processor makes the transition to a different P-state, a timing loop runs to measure the processor frequency. If all P-states are validated within the timeout period, the test passes. Otherwise, it fails.

  4. Validate that no P-states exist.

This test attempts to trigger third party mechanisms (distinct from the operating system) for implementing/changing P-states. As in step 3, the test cycles through processor throttling policies and CPU utilization levels while periodically measuring the CPU speed with a timing loop. If distinct CPU speeds are detected during the test, the test fails. Otherwise it passes.

The CPU P-state test runs twice: once on AC power and once on DC power.

Click to show or hide information. Results Interpretation

The test generates a detailed log file of test results and displays on-screen pass or fail status. The test creates two test logs: one when the test is run on AC power (Pstatehct.log), and one when the test is run on battery power (Pstatebat.log). Examine the test logs for specific information about the test results. The individual test descriptions provide example log files showing successful and unsuccessful test runs.

To assist you in debugging test failures, the test log provides detailed information about the state of the processor at the beginning of the test. The log file records the values for some of the members of the PROCESSOR_POWER_INFORMATION data structure. For information about this data structure and power management functions, see the Platform SDK in the MSDN library at http://msdn.microsoft.com/library/.

Member | Description
MaxMhz | Maximum specified clock frequency, in MHz, of the system processor.
CurrentMhz | Processor clock frequency, in MHz. This number is the maximum specified processor clock frequency multiplied by the current processor throttle.
MhzLimit | Limit on the processor clock frequency, in MHz. This number is the maximum specified processor clock frequency multiplied by the current processor thermal throttle limit, where 0 < thermal throttle limit <= 1.


TD-3.37.1 Idle System Test Description

Overview

This test requires that the aggregate CPU utilization from other processes (not the test process itself) be very close to zero throughout the duration of the test. Therefore, the system must be in a relatively stable idle-state with no other tests running concurrently. This test manipulates CPU utilization so that the system can enter the range of supported P-states. If the CPU is busy running other tasks, the test may not be able to force entry into some P-states.

Test Steps

While the system is running at the maximum CPU speed, the test needs to find at least 10 contiguous seconds, over a time span of up to 30 seconds, where the average CPU utilization per second is less than 5%.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Software

This test requires Windows XP or later.

Results Interpretation

The test generates a detailed log file of test results and displays on-screen pass or fail status. Review the test results log file for specific details regarding failures.


TD-3.37.2 Maximum Processor Speed Available Test Description

Overview

This test checks the system to determine whether the maximum processor speed is equal to the highest P-state available for the system.

The system must pass this test when running on AC power. If necessary, a system can be docked and running on AC power, as long as a configuration exists where the highest performance P-state is available. The test has no way of knowing what configuration(s) the BIOS requires the system to be in for the highest P-state (100%) to be available.

The highest available P-state will not always correspond to the maximum processor speed. This condition might be true for some laptops when they are undocked or running on battery power. This is perfectly valid behavior and depends on the BIOS. Hence, this requirement is not part of the overall DC power test.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Software

This test requires Windows XP or later.

Results Interpretation

The test generates a detailed log file of test results and displays on-screen pass or fail status. Review the test results log file for specific details regarding failures.

The following example log file shows a test that failed. Note that the test fails because the percent frequency for P-state 0 is only 82%, instead of the required 100%.

-----Advertised------ -Valid Range- -Measured (Freq,Count)-

State Freq Prcnt Type [ low - high] Valid Invalid

----- ---- ----- ---- ---- ---- -------- --------

0 700 82 (P) [ 686 - 714]

1 600 70 (P) [ 586 - 614]

2 500 58 (P) [ 486 - 514]

3 437 51 (T) [ 423 - 451]

4 375 44 (T) [ 361 - 389]

5 312 36 (T) [ 298 - 326]

6 250 29 (T) [ 236 - 264]


TD-3.37.3 Situational Factors Preclude Testing Test Description

Overview

This test enforces the requirements for running the P-state tests, which include prohibiting any limits on the use of P-states by the operating system. Outside of this test, it is perfectly valid for the operating system to restrict the use of some P-states.

In some circumstances, the operating system limits the P-states it allows the system to enter. These limits do not necessarily imply that the hardware is incapable of passing this test. To test the hardware properly, you might need to change some external conditions.

There are several reasons the operating system may limit the allowable P-states:

  1. The system operating temperature is too hot. This condition can prevent the system from entering the faster P-states (both performance and throttle states). To fix this condition, let the system cool down before starting the test.
  2. The system is on DC power, and there is not enough battery capacity remaining. This can keep the system from entering the faster throttle states. To avoid this problem, recharge the battery before starting the test.
  3. The system is spending too much time in the C3 processor power state. This keeps the system from entering throttle states. The operating system chooses the less power consumptive C3 processor power state, if it is available and applicable, over slower throttle states. This can only occur on systems that support the optional C3 state. If this is the case with your system, you might try installing and configuring a bus-mastering device like a network adapter configured and connected to a network. Bus master activity brings the CPU out of the C3 state. In general, by increasing the CPU utilization, you can bring the CPU out of the C3 idle state, but the test already cycles through a range CPU utilization levels.
To determine if C3 is supported, see the test log file. The following log file example shows a system where C3 is supported: Max C State: C3 The following is an example of a system where C3 is not supported: Max C State: C2

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Software

This test requires Windows XP or later.

Results Interpretation

The test generates a detailed log file of test results and displays on-screen pass or fail status. Review the test results log file for specific details regarding failures.


TD-3.37.4 Processor Policy Changes Outside HCT Control Test Description

Overview

This test ensures that power option properties do not change outside of the context of this test. Because the P-State tests validate that all available P-states are attainable, and because the operating system limits the P-states that are enterable based on the processor throttle policy in effect, changing policy during the test can lead to unnecessary failure. Outside the context of this test, it is perfectly valid for the processor throttle policy to change dynamically, usually as a result of the user choosing a new power scheme in the Power Options Properties (Powercfg.cpl).

This test checks periodically to confirm that no entity is changing the throttle policy other than the test itself.

  1. Record original processor throttle policy setting.
  2. Set throttle policy to "none."
  3. Validate P-states associated with this policy setting.
  4. Check that throttle policy is still "none."
  5. Set throttle policy to "none."
  6. Validate P-states associated with this policy setting.
  7. Check that throttle policy is still "none."
  8. Set throttle policy to "degrade."
  9. Validate P-states associated with this policy setting.
  10. Check that throttle policy is still "degrade."
  11. Set throttle policy to "adaptive."
  12. Validate P-states associated with this policy setting.
  13. Check that throttle policy is still "adaptive."
  14. Restore the initial pre-test policy.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Software

This test requires Windows XP or later.

Results Interpretation

The test generates a detailed log file of test results and displays on-screen pass or fail status. Review the test results log file for specific details regarding failures.


TD-3.37.5 P-State Validation Test Description

Overview

This test validates every P-state is working as expected. The actual validation criteria can vary by processor and type of P-state, but it at least entails checking that the processor is able to successfully make the transition to each P-state. The validation may also include measuring the processor frequency and verifying that it is sufficiently close to that specified by the BIOS. The test fails if all P-states are not validated within the timeout period.

Intel and AMD processor speeds are validated as independently as possible from what the operating system (OS) kernel believes the processor speeds to be, by means of an independent timing loop. Transmeta processors are queried directly using a Transmeta-specific instruction that reports the current processor speed; they do not use a timing loop.

Failure to pass this test may be due to many factors including, but not limited to, an incorrect processor frequency in an ACPI 2.0 BIOS, other BIOS problems, hardware failure, poor OEM tuning of the default OS parameters that affect how the OS makes transitions between P-states, or the presence of third party software that is controlling P-states alongside the operating system. Identifying the exact cause of failure in all instances is beyond the scope of this test.

An incorrect processor speed associated with a P-state can indicate a couple problems. The legacy interface or the ACPI tables could advertise the wrong speed for the hardware. Or an entity other than the operating system could be changing P-states along with the operating system.

Systems implementing processor performance states must use native Windows support. This means that all performance policy and switching must be done by the operating system. For example, the BIOS or third party software must not influence P-states. This restriction is outlined in the Microsoft Windows Logo Program System and Device Requirements, version 2.0 for Windows XP.

For this test, the Microsoft Windows Logo requirements override the ACPI 2.0 specification. According to the ACPI 2.0 specification, until the OS assumes ownership of P-states, any non-OS-based entity can control them. In the context of this test, however, the OS has already assumed control of the P-states because the OS reported their existence.

Note that assuming control of P-states relies on cooperation. There are no semantics that exclude multiple entities from controlling P-states concurrently. Therefore, after the OS assumes control of performance policy and P-state switching, no non-OS entity can interfere. Failing this test might imply that a non-OS entity is changing the P-states.

Click to show or hide information. Example Log File (Passing)

In the following example log file, all P-states were found, and the measured values in the column "Measured Freq [MHz]" fall within their valid ranges.

Number of measurements: 32

-----Advertised------ -Valid Range- -Measured (Freq,Count)-

State Freq Prcnt Type [ low - high] Valid Invalid

----- ---- ----- ---- ---- ---- -------- --------

0 800 100 (P) [ 776 - 840] ( 798, 1)

1 750 94 (P) [ 728 - 773] ( 720, 1)

2 700 88 (P) [ 665 - 721] ( 698, 3)

3 600 75 (P) [ 570 - 630] ( 599, 12)

4 500 63 (T) [ 475 - 525] ( 495, 6)

5 400 50 (T) [ 380 - 420] ( 395, 5)

6 300 38 (T) [ 285 - 315] ( 295, 2)

7 200 25 (T) [ 190 - 210] ( 195, 2)

The Type values (P) and (T) indicate performance and throttle states, respectively.

Click to show or hide information. Example Log Files (Failing)

In the following example log file, none of the throttle states were validated. P-states 4 through 7 were measured, meaning the OS believed it was in each throttle state, but the measured speed was always 500 MHz. This has been seen with certain CPUs. In this case, the BIOS reported the P-state transitions to throttle states succeeded, so the operating system believed it was in each of the throttle states. However, the CPU did not actually make the transitions, as revealed by the frequency measurements reflecting the speed of the unthrottled state. In this case, the hardware is not functioning properly, perhaps even by design, according to the CPU or system manufacturer. Nevertheless, the advertised capabilities do not match the actual capabilities.

The proper resolution for this situation is to eliminate throttle states from the BIOS. The proper way to eliminate throttle states (applicable to ACPI BIOSs) is to set the DUTY_WIDTH field in the Fixed ACPI Description Table (FADT) to zero. This is stated explicitly in the Advanced Configuration and Power Interface Specification, Revision 2.0, Section 5.2.8. For a detailed description of how throttling uses the DUTY_WIDTH setting, refer to Section 8.1.1. The ACPI 2.0 specification is available online at http://www.acpi.info/index.html.

-----Advertised------ -Valid Range- -Measured (Freq,Count)-

State Freq Prcnt Type [ low - high] Valid Invalid

----- ---- ----- ---- ---- ---- -------- --------

0 850 100 (P) [ 833 - 867] ( 850, 1)

1 700 82 (P) [ 686 - 714] ( 700, 1)

2 600 70 (P) [ 586 - 614] ( 600, 1)

3 500 58 (P) [ 486 - 514] ( 500, 38)

4 437 51 (T) [ 423 - 451] ( 500, 41)

5 375 44 (T) [ 361 - 389] ( 500, 45)

6 312 36 (T) [ 298 - 326] ( 500, 62)

7 250 29 (T) [ 236 - 264] ( 500, 68)

In the following example, P-state 6 has been measured four times, but the measurements have been found invalid each time. The measured frequencies correspond to P-states 5, 6, and 7. Here, the measurement thread detected a P-state transition during the measurement and logged it as invalid. These transitions are fairly typical of throttle states, which change rather frequently while in the degrade processor throttle policy. P-state 5 had one invalid measurement, but was validated because it had at least one valid measurement.

-----Advertised------ -Valid Range- -Measured (Freq,Count)-

State Freq Prcnt Type [ low - high] Valid Invalid

----- ---- ----- ---- ---- ---- -------- --------

0 850 100 (P) [ 833 - 867] ( 850, 1)

1 700 82 (P) [ 686 - 714] ( 700, 1)

2 600 70 (P) [ 586 - 614] ( 600, 1)

3 500 58 (P) [ 486 - 514] ( 500, 38)

4 437 51 (T) [ 423 - 451] ( 436, 9)

5 375 44 (T) [ 361 - 389] ( 375, 2) ( 436, 1)

6 312 36 (T) [ 298 - 326] ( 375, 2)

( 311, 1)

( 250, 1)

7 250 29 (T) [ 236 - 264] ( 250, 6)

In the next example, P-state 1 has not been measured at all. This indicates the processor did not make the transition to P-state 1. This missing measurement can be an artifact of the proper combination of processor throttle policy and CPU utilization not being met during the course of the test. In this case, you should run the test over several times to attempt passing. If the test still does not pass, it may be the case that the unmeasured state is very close to an adjacent state, that is, the percent column differs from that of adjacent states by 5 percent or less. This narrow range can make it difficult to sustain the correspondingly narrow CPU utilization range necessary to make the transition into this state. If such an unmeasured state is a performance state (Type P), and it is not the fastest or the slowest performance state, it may be beneficial to manually consume some CPU cycles with another process during the period when the test is exercising the adaptive (3) processor throttle policy. This type of failure is rare, and on a truly valid system it should not persist across several test runs.

-----Advertised------ -Valid Range- -Measured (Freq,Count)-

State Freq Prcnt Type [ low - high] Valid Invalid

----- ---- ----- ---- ---- ---- -------- --------

0 850 100 (P) [ 833 - 867] ( 850, 7)

1 700 82 (P) [ 686 - 714]

2 600 70 (P) [ 586 - 614] ( 600, 12)

3 500 58 (P) [ 486 - 514] ( 500, 38)

4 437 51 (T) [ 423 - 451] ( 436, 9)

5 375 44 (T) [ 361 - 389] ( 375, 13)

6 312 36 (T) [ 298 - 326] ( 311, 1)

7 250 29 (T) [ 236 - 264] ( 250, 8)

It is not uncommon for a test failure to occur in a system where the BIOS does not correctly match the hardware. For example, the system may use a BIOS that was designed for a faster CPU than the actual CPU installed. In this case, as shown in the following example, the BIOS reports P-state frequencies that differ from the hardware.

-----Advertised------ -Valid Range- -Measured (Freq,Count)-

State Freq Prcnt Type [ low - high] Valid Invalid

----- ---- ----- ---- ---- ---- -------- --------

0 844 100 (T) [ 828 - 860] ( 696,353)

( 695, 1)

( 88, 4)

1 739 87 (T) [ 725 - 753] ( 696, 1)

( 599, 13)

( 598,119)

( 88, 4)

( 87, 3)

2 634 75 (T) [ 620 - 648] ( 514, 9)

Click to show or hide information. CPU Frequency Tolerances

For every P-state frequency (Freq) advertised by the BIOS, a range (Range) of acceptable frequencies is calculated based on a +/- tolerance (Tolerance) expressed in MHz.

Tolerance = max ( Tolerance1, Tolerance2 )

where:

Tolerance1 = Freq * 0.02

Tolerance2 = 14

Tolerance2 has the effect of maintaining a wider margin of error in percentage terms for slower states.

The range of acceptable frequencies can be further constrained by adjacent P-states whose frequencies are within a few percentage points of Freq since ranges are not allowed to overlap except at the boundaries of adjacent ranges. Ranges are inclusive.

Range = [lowerBound, upperBound]

where:

lowerBound = max ( Freq - Tolerance, (Freq + FreqOfNextSlowerState)/2 )

upperBound = min ( Freq + Tolerance, (Freq + FreqOfNextFasterState)/2 )

For example, consider the following table of P-states.

-----Advertised------ -Valid Range-

State Freq Prcnt Type [ low - high]

----- ---- ----- ---- ---- ----

0 800 100 (P) [ 784 - 816]

1 750 93 (P) [ 735 - 765]

2 700 87 (P) [ 686 - 714]

3 600 75 (P) [ 586 - 614]

4 500 62 (T) [ 486 - 514]

5 400 50 (T) [ 386 - 414]

6 300 37 (T) [ 286 - 314]

7 200 25 (T) [ 186 - 214]

The Type values (P) and (T) indicate performance and throttle states, respectively.

The valid frequency range for P0 is calculated as follows:

=[ Max( 800 – 800*.02, (800 + 750)/2 ),

Min(800 + 800*.02, <some number much larger than 800+800*.05>) ]

=[ Max( 800-16, 775 ), 816 ]

=[ 784, 816 ]

The valid frequency range for P1 is calculated as follows:

=[ Max(750-750*.02, (750+700)/2),

Min(750+750*.02, (750+800)/2) ]

=[ Max(750-15, 725),

Min(750+15, 775) ]

=[ 735, 765 ]

There is little practical value for adjacent P-states to be very close in frequency. Nevertheless, to illustrate the validation logic, had adjacent frequencies been much closer (P1 = 775 MHz instead of 750 MHz), interference would have limited the ranges for states P0 and P1 as shown in the following example:

-----Advertised------ -Valid Range- -Measured (Freq,Count)-

State Freq Prcnt Type [ low - high] Valid Invalid

----- ---- ----- ---- ---- ---- -------- --------

0 800 100 (?) [ 787 - 816]

1 775 97 (?) [ 760 - 787]

2 700 88 (P) [ 686 - 714]

In the example below, the special valid frequency range [xxxx – xxxx] denotes that measured frequencies are not considered in the validation criteria for a given P-state. This is the case when independent measurements cannot be taken for some reason. Validation is then typically based on successfully entering the state at least once. Frequency "measurements" are still displayed.

-----Advertised------ -Valid Range- -Measured (Freq,Count)-

State Freq Prcnt Type [ low - high] Valid Invalid

----- ---- ----- ---- ---- ---- -------- --------

0 600 100 (P) [xxxx - xxxx] ( 600, 7)

2 500 83 (P) [xxxx - xxxx] ( 500, 4)

3 400 66 (P) [xxxx - xxxx] ( 400, 1)

4 300 50 (P) [xxxx - xxxx] ( 300, 33)

Because the test knows which P-state the system is in whenever it measures the processor frequency, there is no difficulty attributing a frequency measurement to the appropriate P-state, even if it happens to be valid frequency for two adjacent P-states (787 MHz in this example). Frequency measurements where the timing loop duration spans a P-state transition are automatically considered invalid, even though the measurement happens to fall within the valid range of the P-state for which the timing loop started.

Click to show or hide information. Overall Timeout Period

This test has a timeout period of 30 seconds for each of the four processor throttle policies tested. The test remains in each policy until all the P-states reachable in that policy are validated, or until the 30 second timeout period expires, whichever comes first. If the test does not validate all throttle polices within this two-minute period, the system fails the test. The reported measurements will differ from run to run. This is due to the test’s indirect manner of influencing P-state changes through a combination of setting the processor throttle policy and fluctuating work load on the processor. For example, the number of measurements taken could differ by a factor of two or three, and the measured frequencies sometimes vary by a percentage point or two. It is conceivable that the test could fail to validate a state on one run and pass on a subsequent run. Empirical results indicate very few systems experience occasional failures like this, and of these systems where indeed the hardware is capable of entering all P-states, several runs will result in a passing test. Several external conditions like overheating and low battery power can cause P-states not to be entered, and hence not verified.

Click to show or hide information. Overriding Default Tuning Parameters

Using optional registry-based parameters, it is possible to override the operating system's default tuning parameters for processor performance states. These overrides may render some P-states unreachable or difficult to sustain for a reasonable duration, making it difficult for this test to validate them. A system designer may have valid reasons for not allowing a system to enter a given P-state. For instance, it may take too long to flush cache buffers to make it practical to enter a given performance state. In the case of an ACPI 2.0 system, you should eliminate unwanted performance states from the BIOS’s _PSS object, rather than make them unreachable using the tuning parameters. In the case of an ACPI 1.0 system with legacy interface, there is no choice but to modify the tuning parameters, rendering the test unable to know for sure whether this is a bug or intentional behavior. However, if the legacy interface advertises P-states, the test expects them all to be reachable; if they are not, the test fails. In practice, few systems override the default tuning parameters.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Software

This test requires Windows XP or later.

Results Interpretation

The test generates a detailed log file of test results and displays on-screen pass or fail status. Review the test results log file for specific details regarding failures.


TD-3.37.6 Unreported P-States Found Test Description

Overview

This test checks for the existence of P-states when the operating system (OS) reports there are none. The existence of P-states is determined by processor frequency measurements showing changes as a result of fluctuations in processor utilization and processor throttle policy.

An ACPI-compatible OS is designed to control a system’s power management functions. The central role of this OS is to consider power consumption, thermal conditions, user-specified policy, and system utilization in a more all-encompassing and integrated manner than the BIOS or third party software are able to do.

Some manufacturers do not implement the ACPI 2.0 interface, nor do they follow the standard implementation of the legacy interface to the change P-state. Hence, the OS knows only one fixed processor speed. However, some of these systems are able to change their P-states by means of a non-standard legacy interface using proprietary software. For example, some older laptops using a proprietary legacy interface fall into this category. Such systems fail this test if P-state changes are detected.

This test checks compliance with the Windows Microsoft Windows Logo Program System and Device Requirements that constrain processor performance control solely to the operating system. All performance policy and switching must be done by the operating system.

Click to show or hide information. Example Test Log

The following example log file shows results of a failing test. Note that the test fails because more than one frequency was measured.

Number of measurements: 158

-----Advertised------ -Valid Range- -Measured (Freq,Count)-

State Freq Prcnt Type [ low - high] Valid Invalid

----- ---- ----- ---- ---- ---- -------- --------

n/a 498 100 n/a [ 484 - 512] ( 648, 47)

( 498,111)

No P-states were reported, but significant frequency groupings suggest they exist

Note that frequencies are measured at least twice before being reported in this case. The test reports only frequencies that are unique within a given tolerance (+/- 5%).

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Software

This test requires Windows XP or later.

Results Interpretation

The test generates a detailed log file of test results and displays on-screen pass or fail status. Review the test results log file for specific details regarding failures.


TD-3.37.7 P-state Order Test Description

Overview

This test verifies that P-states are listed in the BIOS in the proper descending order by power dissipation. This user-mode test only has access to the frequency values provided by the BIOS and not the power dissipation values. However, the test is based upon the logical inference that P-states must be listed in the BIOS in strictly descending order by processor frequency. This is because frequency and power dissipation are directly proportional, given that optional throttle states are implemented on the slowest performance state. There is no way to have a faster frequency P-state dissipate less power than a slower frequency P-state. Also, there is no way to have two identical frequency P-states dissipate different amounts of power. Power dissipation values are at best approximations that can be arbitrarily assigned and are generally not testable. Processor frequency on the other hand is more readily testable.

Click to show or hide information. Example Test Logs

The following example test logs show the results of two failing test. Note that in each case, the test actually fails because some states are not validated. At issue here are those states that are not even entered as shown by the lack of any measurements, valid or invalid. The kernel will not attempt to enter states that are not strictly decreasing by power dissipation. A system with a BIOS that improperly reports increasing or identical frequency values for P-states, even if P-states are listed properly by descending power dissipation order, generates the failure that P-states are not in strictly descending order. In this case, multiple test assertions fail, but the test reports only one.

To rectify this failure, the BIOS should represent P-states with power dissipation and frequency values that are as true as possible. This might require changing values or eliminating states.

-----Advertised------ -Valid Range- -Measured (Freq,Count)-

State Freq Prcnt Type [ low - high] Valid Invalid

----- ---- ----- ---- ---- ---- -------- --------

0 1400 100 (P) [1372 - 1428] (1395, 13)

1 1000 71 (P) [ 980 - 1020] ( 997, 2)

2 700 50 (P) [ 686 - 714] ( 698, 4)

3 600 42 (P) [ 586 - 614] ( 598, 33)

4 500 35 (P) [ 650 - 514] ( 498, 54)

5 800 57 (P) [ 784 - 650]

6 650 46 (P) [ 636 - 664]

7 500 35 (P) [ 675 - 514]

8 850 60 (P) [ 833 - 675]

9 650 46 (P) [ 636 - 664]

10 609 43 (T) [ 595 - 623]

11 568 40 (T) [ 554 - 582]

12 528 37 (T) [ 514 - 542]

13 487 34 (T) [ 473 - 501] ( 648, 28)

14 446 31 (T) [ 432 - 460] ( 648, 30)

15 406 29 (T) [ 392 - 420] ( 648, 42)

16 365 26 (T) [ 351 - 379] ( 648, 61)

17 325 23 (T) [ 311 - 339] ( 648, 56)

18 284 20 (T) [ 270 - 298] ( 648, 70)

19 243 17 (T) [ 229 - 257] ( 648, 73)

20 203 14 (T) [ 189 - 217] ( 648, 53)

-----Advertised------ -Valid Range- -Measured (Freq,Count)-

State Freq Prcnt Type [ low - high] Valid Invalid

----- ---- ----- ---- ---- ---- -------- --------

0 600 100 (P) [xxxx - xxxx] ( 600, 7)

1 600 100 (P) [xxxx - xxxx]

2 500 83 (P) [xxxx - xxxx] ( 500, 4)

3 400 66 (P) [xxxx - xxxx] ( 400, 1)

4 300 50 (P) [xxxx - xxxx] ( 300, 33)

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Software

This test requires Windows XP or later.

Results Interpretation

The test generates a detailed log file of test results and displays on-screen pass or fail status. Review the test results log file for specific details regarding failures.


TD-3.37.8 P-state Frequency Out Of Range Test Description

Overview

This test verifies that no P-state frequency is zero. A processor speed of zero makes no sense when the system is in the running state. The ACPI specification provides other mechanisms for turning off a processor in part or in full. For information on how to do this, refer to processor power states and system sleep states in the ACPI specification. This test rarely fails in practice. A failure typically points to an oversight in the BIOS.

To rectify this failure, the BIOS should represent P-states with power frequency values that are as true as possible. This might require changing values or eliminating states.

Click to show or hide information. Example Test Log

The following example log file shows results of a failing test. Note that the test fails because one P-state’s frequency is zero.

-----Advertised------ -Valid Range- -Measured (Freq,Count)-

State Freq Prcnt Type [ low - high] Valid Invalid

----- ---- ----- ---- ---- ---- -------- --------

0 650 100 (P) [ 636 - 664] ( 648, 1)

1 0 0 (P) [ 0 - 14]

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Software

This test requires Windows XP or later.

Results Interpretation

The test generates a detailed log file of test results and displays on-screen pass or fail status. Review the test results log file for specific details regarding failures.


TD-3.37.9 P-states On Multiple Processors Not Supported Test Description

Overview

This test verifies that multiprocessor systems do not contain P-states. In the context of this document, P-states refer to both performance and throttle states. Windows XP and Windows .NET Server 2003 do not support this configuration.

To correct a test failure, you must remove P-states from the BIOS.

Click to show or hide information. Example Test Log

No systems are known to exist with this configuration at this time. The following example log file output is contrived and shows what a failing test log would look like.

2 logical processors found

-----Advertised------ -Valid Range-

State Freq Prcnt Type [ low - high]

----- ---- ----- ---- ---- ----

0 1000 100 (P) [ 980 - 1020]

1 800 80 (P) [ 784 - 816]

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Software

This test requires Windows XP or later.

Results Interpretation

The test generates a detailed log file of test results and displays on-screen pass or fail status. Review the test results log file for specific details regarding failures.


TD-3.38 ACPI Stress Tests

Test Kit: HCT 11, HCT 10

In the HCT 10 kit, this test was TD-22.6 PMTE Test.

Overview

The ACPI Stress tests (Pmte.exe) are power management tests that examine the devices in the system, and then put the system into a sleep/hibernation states. When the system returns from sleep/hibernation, the tests verify that the devices function properly. These tests examine all the sleep/hibernation states that the system supports.

The devices tested include:

Disks
CD-ROMS
Serial ports
Modems
Sound output
IrDA
Parallel ports

The ACPI Stress tests include the following test cases:

Click to show or hide information. ACPI Stress - Device I/O (Extended) test

This test examines the devices in the system, and then puts the system into a sleep/hibernation state. When the system returns from sleep/hibernation, the test verifies that the devices function properly after sleep/hibernation. This test examines all sleep/hibernation states that the system supports.

An ACPI system must support one of the following states: S1, S2, or S3. Support of S4 or S4BIOS is optional.

The ACPI Stress Extended Device I/O test runs through 50 iterations of testing the system I/O and sleep/hibernation.

ACPI supports a Real Time Clock (RTC). To test this functionality, the clock is set to 60 seconds per state for system testing. Systems that do not have RTC support for a hibernation state restart without the normal 60-second delay.

Click to show or hide information. ACPI Stress - Device I/O (Varied RTC) test

This test examines the devices in the system and then puts the system into a sleep/hibernation state. When the system returns from sleep/hibernation, it tests the devices in the system again to verify that the devices function properly after sleep/hibernation. This test examines all sleep/hibernation states that the system supports.

An ACPI system must support one of the following states: S1, S2, or S3. Support of S4 or S4BIOS is optional.

The ACPI Stress - Device I/O (Varied RTC) test runs through 3 iterations of testing the device input/output (I/O) and sleep/hibernation.

ACPI supports a Real Time Clock (RTC). The clock is set to test each system state for a random interval. Systems that don't have RTC support for a hibernation state reboot immediately.

Click to show or hide information. ACPI S1 Stress test

This test examines the sleep/hibernation states supported by the test device, and then puts the system into a series of sleep/hibernation states. When the system returns from sleep/hibernation, the test verifies that the test device functions properly after returning from each sleep/hibernation state. This test examines the S1 and S4 sleep/hibernation states.

The ACPI S1 Stress test runs through 10 iterations of testing for device I/O and sleep/hibernation.

ACPI supports a Real Time Clock (RTC). To test this functionality, the RTC clock is set to one minute per sleep/hibernation state.

Click to show or hide information. ACPI S3 Stress test

This test examines the sleep/hibernation states supported by the test device, and then puts the system into a series of sleep/hibernation states. When the system returns from sleep/hibernation, the test verifies that the test device functions properly after returning from each sleep/hibernation state. This test examines the S3 and S4 sleep/hibernation states.

The ACPI S3 Stress test runs through 10 iterations of testing for device I/O and sleep/hibernation.

ACPI supports a Real Time Clock (RTC). To test this functionality, the RTC clock is set to one minute per sleep/hibernation state.

Click to show or hide information. ACPI Stress test

This test examines the sleep/hibernation states supported by the test device, and then puts the system into a series of sleep/hibernation states. When the system returns from sleep/hibernation, the test verifies that the test device functions properly after returning from each sleep/hibernation state. This test examines the S4 sleep/hibernation state.

The ACPI Stress test runs through 10 iterations of testing for device I/O and sleep/hibernation.

ACPI supports a Real Time Clock (RTC). To test this functionality, the RTC clock is set to one minute per sleep/hibernation state.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Results Interpretation

The ACPI Stress tests write the test results to the file Pmte.log and display on-screen pass or fail status.

The test log records errors for non-working devices (before or after going into a sleep state) and errors if the system fails to change states.

Click to show or hide information. Reading Pmte.log

The ACPI tests (Pmte.exe) basically pause and restart all the device tests, and put the system into different sleep states. These actions are done synchronously. In the log file, these actions are preceded with the character string: ===. If one of these major actions fails, the log file contains a line like following:

ERROR Work item completed with Error Code: ####

These are not the only errors that get reported. See the Logging Errors section below for a list of all the different errors the ACPI Stress tests report.

The following is a sample log file, with the major actions highlighted in red.

=== Initialize all tests === (D:25 H:18 M:25 S:49)

Test C:\ (DISK_0_C__.log)

Test D:\ (DISK_1_D__.log)

Test E:\ (CD_ROM_2_E__.log)

Test \\.\COM2 (COMPORT_3___._COM2.log)

Test Video (VIDEO_4_Video.log)

Test Devnodes (DEVNODES_5_Devnodes.log)

Test NET:\\acpisrv\pmte\io (NET_6_NET___acpisrv_pmte_io.log)

=== Start script run ===

Script file name: boot_test.psf

Test cycles: till: M:9 D:26 H:6 M:0

Number of Sleep states: 2

Sx State Sequence Skip : 0

=== TME_MEDIA_CHECK all tests === (D:25 H:18 M:25 S:50)

Video ,Video

Devnodes ,Seach for devnodes with problems

\\acpisrv\pmte\io\PMTE_ACPI-INTNIG-1 ,Net Read Write I/O

D:\PMTE_ACPI-INTNIG-1 ,Disk Read Write I/O

C:\PMTE_ACPI-INTNIG-1 ,Disk Read Write I/O

\\.\COM2 ,COMX Read Write I/O

E:\ ,CD-ROM Read test

=== Enable Hiberfile (D:25 H:18 M:25 S:54)

=== TME_RESTART_TESTING all tests === (D:25 H:18 M:25 S:55)

C:\PMTE_ACPI-INTNIG-1 ,Disk Read Write I/O

\\acpisrv\pmte\io\PMTE_ACPI-INTNIG-1 ,Net Read Write I/O

D:\PMTE_ACPI-INTNIG-1 ,Disk Read Write I/O

Video ,Video

E:\ ,CD-ROM Read test

\\.\COM2 ,COMX Read Write I/O

Devnodes ,Seach for devnodes with problems

=== Wait for 30 seconds (D:25 H:18 M:26 S:07)

=== TME_PAUSE_TESTING all tests === (D:25 H:18 M:26 S:38)

Devnodes ,Seach for devnodes with problems

D:\PMTE_ACPI-INTNIG-1 ,Disk Read Write I/O

Video ,Video

\\acpisrv\pmte\io\PMTE_ACPI-INTNIG-1 ,Net Read Write I/O

C:\PMTE_ACPI-INTNIG-1 ,Disk Read Write I/O

E:\ ,CD-ROM Read test

\\.\COM2 ,COMX Read Write I/O

=== Wait for 5 seconds (D:25 H:18 M:26 S:39)

=== S1 , Wake method: RTC . Set to wake in 4 Min. Latency 420 Sec. Count 0 === (D:25 H:18 M:26 S:44)

Flags = POWER_ACTION_QUERY_ALLOWED, POWER_ACTION_UI_ALLOWED,

PBT_APMQUERYSUSPEND (D:25 H:18 M:26 S:44)

PBT_APMSUSPEND (D:25 H:18 M:26 S:44)

PBT_APMRESUMEAUTOMATIC (D:25 H:18 M:30 S:51)

System woke up in time: Elapsed time=0:0:4:7:298

=== Wait for 20 seconds (D:25 H:18 M:30 S:52)

=== TME_RESTART_TESTING all tests === (D:25 H:18 M:31 S:12)

D:\PMTE_ACPI-INTNIG-1 ,Disk Read Write I/O

C:\PMTE_ACPI-INTNIG-1 ,Disk Read Write I/O

Video ,Video

\\acpisrv\pmte\io\PMTE_ACPI-INTNIG-1 ,Net Read Write I/O

\\.\COM2 ,COMX Read Write I/O

E:\ ,CD-ROM Read test

Devnodes ,Search for devnodes with problems

This log snippet indicates that the test completed the following:

  1. Initialized all the tests,
  2. Checked media for all devices
  3. Enabled the hiberfile
  4. Restarted testing all devices
  5. Waited for 30 seconds
  6. Paused testing of all devices
  7. Waited for 5 seconds
  8. Then enabled the RTC timer to wake in 4 minutes, and put the system to S1 sleep

Click to show or hide information. Detailed Description of Actions in Pmte.log

The ACPI tests record a time along with the action. The times in Pmte.log use the following format: (D:25 H:18 M:26 S:44)

These are absolute times.

Action:

    === TME_RESTART_TESTING all tests ===

This action starts or restarts testing devices. A list of devices follows.

Action:

    === TME_PAUSE_TESTING all tests ===

This action pauses testing of devices. A list of devices follows. Depending on how the ACPI test was started, not all tests will actually pause I/O. Device types that can support I/O without getting errors before suspending will usually not pause I/O. Disks and sound devices are an example of these devices. However, COM ports and modems will pause I/O before suspending.

Action:

    === S# , Wake method: # Set to wake in # Min. Latency ### Sec. Count # ===

    === S# , Wake method: # . Count # ===

This action states that the system is going to sleep/hibernate.

S#

The number after the S is the type of sleep state. S4 would indicate system is going to hibernate. S1 through S3 are sleep states.

Wake method

Possible wake methods are:

  • 1. "Manual" - The user needs to press the power button to wake the system.
  • 2. "RTC" - System will wake automatically using the RTC timer.
  • 3. "Reset Hibernate" - where system will go into hibernate but the system will not turn off the power to the system, but instead will reset the system.

# Min

Indicates in how many minutes it will take to wake the system from this sleep state.

Latency ### Sec.

This number indicates how much later than the Min value a system can actually wake before it is flagged as an error. This number is in seconds.

Count #

Indicates how many sleep cycles have already been tested.

Click to show or hide information. Detailed Description of Errors in Pmte.log

Errors are reported after the pause testing or restart testing of a device. Each error reported consists of multiple lines and each line will be preceded with the word ERROR, as shown in the following examples:

=== TME_PAUSE_TESTING all tests === (D:27 H:18 M:20 S:55)

Devnodes ,Seach for devnodes with problems

ERROR \\.\COM2 , Status=3221235498 , COMX Read Write I/O

ERROR There is no serial loop back attached.

C:\PMTE_ACPI-HPLH4-1 ,Disk Read Write I/O

D:\PMTE_ACPI-HPLH4-1 ,Disk Read Write I/O

Video ,Video

E:\ ,CD-ROM Read test

\\acpisrv\pmte\io\PMTE_ACPI-HPLH4-1 ,Net Read Write I/O

Errors caused by a test that is not responding usually means that there is some problem with the device. Depending on how the ACPI Stress test is started, the test will do different things when a test fails to respond. It any case, the test records an error stating that the test timed out while waiting to ACK (acknowledge) the state change (see first red line below). After that line, the name of the test is listed. The following example from a log file shows the devnodes test failing to respond.

=== TME_RESTART_TESTING all tests === (D:18 H:00 M:58 S:47)

C:\PMTE_SMITTYDBG15 ,Disk Read Write I/O

\\.\IRDA ,Irda test

D:\PMTE_SMITTYDBG15 ,Disk Read Write I/O

\\.\Sound ,Sound (Did you hear sound?)

\\acpisrv\pmte\io\PMTE_SMITTYDBG15 ,Net Read Write I/O

ERROR Timed out waiting on test to ACK the state change.Time=480

ERROR Test DEVNODES, Device Devnodes, Test terminated=NO

ERROR Failed to terminate one or more test processes

Errors because the system wakes too late or too soon will also be preceded with the word ERROR. The test also logs the elapsed time. In the following example, the system woke too soon. The RTC timer was programmed to wake the system in 4 minutes, while the system actually woke in 1.46 minutes.

=== S1 , Wake method: RTC . Set to wake in 4 Min. Latency 420 Sec. Count 0 === (D:28 H:14 M:21 S:21)

Flags = POWER_ACTION_QUERY_ALLOWED, POWER_ACTION_UI_ALLOWED,

PBT_APMQUERYSUSPEND (D:28 H:14 M:21 S:21)

PBT_APMSUSPEND (D:28 H:14 M:21 S:21)

ERROR System woke too soon: Elapsed time=0:0:1:47:381

PBT_APMRESUMEAUTOMATIC (D:28 H:14 M:23 S:09)

PBT_APMRESUMESUSPEND (D:28 H:14 M:23 S:09)

Errors because the system failed to go to sleep, are shown in the following example. It shows that the system failed to go into S4 (hibernate). This error is also preceded with the word ERROR. The first line reads:

ERROR Work item completed with Error Code: ####

Where #### is the error number the going to sleep API returned. The next error line explains what this error code means.

=== S4 , Wake method: Reset Hibernate Count 197 === (D:21 H:05 M:16 S:31)

Flags = POWER_ACTION_QUERY_ALLOWED, POWER_ACTION_UI_ALLOWED,

PBT_APMQUERYSUSPEND (D:21 H:05 M:16 S:31)

PBT_APMSUSPEND (D:21 H:05 M:16 S:31)

PBT_APMRESUMEAUTOMATIC (D:21 H:05 M:16 S:32)

ERROR Work item completed with Error Code: 2001

ERROR The specified driver is invalid.

ERROR PO_ERROR_FAILED_SLEEP_STATE

=== Wait for 20 seconds (D:21 H:05 M:16 S:32)

* * *


Chapter 4: PCI Test Specification

This chapter describes the PCI compliance test tools and the features that are exclusive to PCI 2.2, PCI Power Management, Revision 1.1 and the D3 power-management support of PCI and AGP add-in hardware required under Microsoft Windows Logo Program System and Device Requirements.

Test Coverage

Almost all of today’s PCI devices require that both system board and add-in cards adhere to the PCI Local Bus Specification, Revision 2.1 standard or below. Starting with the PCI Local Bus Specification, Revision 2.2, PCI system, device, and peripheral vendors have opportunities to implement new features in their products using a standard method for detecting new device capabilities (for example, power management).

The PCI Local Bus Specification, Revision 2.2 specification added many new capabilities to PCI Local Bus Specification, Revision 2.1 without resulting in a major change to the PCI bus architecture. Table 4-1 lists the changes that are currently included in version 2.2.

Table 4-1. PCI 2.2 Capability Changes

Change Request | Description | Type of Change | Required vs. Optional
New Capabilities Reporting | Allows PCI devices to declare and use new capabilities such as power management. | Enhancement | Optional
PME# Signal | Assigns a reserved pin (pin19A) as a PME# signal for device wake-up function. | Enhancement | Optional
3.3Vaux Signal | Assigns a reserved pin (pin 14A) as a 3.3Vaux power supply for device-awakening event logic. | Enhancement | Optional
Vital Product Data (Revised) | Provides alternate access method to vital product data. | Enhancement | Optional
Message Signaled Interrupt | Provides a method to deliver message-based interrupt signal for requesting device service. | Enhancement | Optional
Subsystem ID and Subsystem Vendor ID | Required feature in PCI 2.2. | Enhancement | Required
Maximum Completion Time | PCI devices cannot retry a target memory transaction for longer than 10 microseconds. | Enhancement | Required
3.3V Required | Requires system to provide 3.3V power to all PCI connectors. | Enhancement | Required
RST# Timing | Minimum time from "Deassert" to Reset before access to device configuration can occur. | Enhancement | Required
Tprop | Clarifies measurement and determination of Tprop times for 33/66 MHz. | Clarification | Optional
Posted Memory Writes | Adds clarification and closes loophole in transaction ordering to prevent deadlock. | Correction | Required
Six Mechanical ECNs | Changes various mechanical form factors, e.g., bracket mounting, riser connector add-in card interface. | 6 Enhancement | 3 Required; 3 Optional

The PCI Local Bus Specification, Revision 2.2, defines a standard method for allowing new PCI bus features, such as power management, to be detected and controlled. Through this new mechanism, software can identify both legacy and non-legacy PCI functions and control the device based on its set of capabilities. The currently defined capability IDs for PCI Local Bus Specification, Revision 2.2 are as follows:

  • PCI Power Management (PM) Interface
  • Accelerated Graphics Port (AGP)
  • Vital Product Data (VPD)
  • Slot Identification
  • Message Signaled Interrupt (MSI)
  • Compact PCI Hot Swap

For more details on the new capability list structure and capability IDs, see Chapter 6 and Appendix H, respectively, in the PCI Local Bus Specification, Revision 2.2.

In addition to new capability IDs, this specification covers PCI D3 power-management support of PCI and AGP add-in hardware.

Power-managed PCs that are compliant with the Windows Logo program requirements can go into one of many different sleep states. While in these sleep states, in the presence of power-managed peripherals, the systems can be awakened due to external events including button-push, incoming modem calls (Wake-on-ring) and network-based triggers (Wake on LAN). Microsoft Windows Logo Program System and Device Requirements requires that the various devices support specific capabilities in order to support system-wide power management.

This specification covers the tests needed to validate PCI add-in hardware and associated drivers for compliance with the Windows Logo Program requirements.

This PCI D3 test assertions are organized into the following categories:

  • PCI D3 Graphics Adapter
  • PCI D3 Modem Device
  • PCI D3 Network Adapter
  • PCI D3 Audio Device

Note: This test specification is specifically targeted at D3 compliance for the various classes of devices. It augments the existing WHQL tests for each of these devices.

Definition of D3 State

This document refers to D3 device-state as outlined in the ACPI Specification 1.0b.

"Power has been fully removed from the device. The device context is lost when this state is entered, so the OS software will reinitialize the device when powering it back on. Since device context and power are lost, devices in this state do not decode their address lines. Devices in this state have the longest restore times. All classes of devices define this state".

Test Methodology

All PCI tests are designed to run on all IA-32 processor-based platforms. No dependencies on PCI chipset implementation are presently known.

Tests are currently implemented through DOS real-mode testing. The current test descriptions document the DOS real-mode implementation. To avoid memory limitations, this implementation will be ported to Windows.

PCI Test Adapter

Most PCI tests require a special PCI-PM-compliant test adapter, which is similar to the PCI SIG card but provides additional functionality to support PCI power management requirements. The key requirements of this test adapter are

  • Assertion of PME# pin 19A via software controls
  • Implementation of the D0, D1, D2, D3 Hot, and D3 Cold states
  • Support for PME# assertion from the D0, D1, D2, D3 Hot, and D3 Cold states
  • Support for 3.3Vaux auxiliary power for device wake-up circuitry via pin 14A
  • A programmable current consumption level of 375mA, 160mA, or 20mA
  • PCI SIG card capabilities

For a complete description of the PCI test adapter features, see the Platform PCI Compliance Test Adapter, External Design Specification.


PCI Test Assertions

For a summary of the current PCI requirements, see Table 4-2.

The PCI assertions that address the requirements are classified into the following categories:

PCI Peripheral Assertions

The PCI peripheral category includes assertions to verify that the

  • System correctly implements the power management register interface for all on-board PCI peripherals.
  • System correctly implements subsystem ID and subsystem vendor ID of PCI devices.

PCI Test Adapter Diagnostic Assertions

The PCI power management diagnostic category includes assertions to verify that the

  • PCI test adapter functions as required at various combinations of the PCI bus and function power states.
  • Power state transitions for the PCI test adapter occur as required.
  • PCI test adapter’s specific registers function correctly.

PCI System Assertions

The PCI system category includes assertions to check and/or validate the

  • PME# signal routing mechanism on motherboards.
  • System wake-up logic.
  • Power requirements for 3.3Vaux auxiliary power.

To review all PCI tests by assertion categories, see Table 4-3. To review the PCI tests, see the "Test Descriptions" section. The test descriptions include an overview of each test; instructions for hardware and software setup, test results interpretation and if needed a list of outstanding issues related to each test.

Table 4-2. PCI Requirements

Req.# | Requirement Description | Test Coverage
WLP# B2.5. PC 2001 SYS-0023, 3.27 | If PCI is used in a PC system, the PCI bus must meet the following requirements: * PCI Local Bus Specification, Revision 2.2 or greater * PCI Power Management Interface Specification, Revision 1.1 * Systems and devices must support PCI Local Bus Specification, Revision 2.2 or greater * PCI-based modem and network adapters must support generation of power management event signal from D3 Cold. * System must provide 3.3V to all PCI connectors. * If the system supports S3 or S4 states, it must provide 3.3Vaux power to all PCI connectors. | PCICAP*, PMDIAG, PCIPME1, PCIPME2. PCIWAKE, PCIVAUX, PCISID*, SYSCHK, PCIVOLT, PERICHK
PCI-0123,9.1 | All components must comply with the PCI 2.2 specification. | PCICAP*
PCI-0123,9.4 | System provides 3.3V to all PCI connectors. | SYSCHK, PCIVOLT
PCI-0123,9.5 | PCI add-in devices are recommended to support both 5V and 3.3V signaling. | Not tested
PCI-0125,9.9 | All PCI devices complete the memory write transaction as a target within specified times. | PCIMCT
PCI-0126,9.11 | Device IDs must include subsystem IDs. | PCISID*
PCI-0130, 9.17 | All PCI components must comply with the PCI Bus Power Management Interface specification. | PCICAP*, PMDIAG, PCIPME1, PCIPME2, PCIWAKE, PCIVAUX, SYSCHK, PERICHK, PCIVOLT, BIOSINIT
PCI-0131,9.18 | If the system supports S3 or S4 states, it must provide support for 3.3Vaux. | PCIVAUX, SYSCHK
PCI-0130, 9.19 | Bus power states must be correctly implemented. | PMDIAG
PCI-0132, 9.20 | PCI-based modem and network adapters must support wake-up. No modems and/or network adapters must be used for this testing. Only PCI test adapters must be employed to verify the system wake-up mechanism. | PCIWAKE, PERICHK
*Tests with an asterisk in this list apply for Windows 2000 and Windows Millennium Edition, but not for Windows XP.

Table 4-3. PCI Tests

Test Name | Requires PCI Test Adapter? | PCI Test Type
PCICAP | Yes | PCI Peripheral Test
PCISID |  | PCI Peripheral Test
PCIMCT | Yes | PCI Peripheral Test
PERICHK (checklist) |  | PCI Peripheral Test
PMDIAG | Yes | PCI PM Diag nostic Test
PCIVOLT | Yes | PCI System Test
BIOSINIT | This test has been removed | PCI System Test
PCIPME1 | Yes | PCI System Test
PCIPME2 | Yes (1/slot) | PCI System Test
PCIWAKE | Yes | PCI System Test
PCIVAUX | Yes (1/slot) | PCI System Test
SYSCHK |  | PCI System Test

For each of the above test categories, the following subsections identify test assertions. Not all aspects of these test assertions can be tested through self-testing. Some test assertions are considered Not Tested if any of the following statements are true:

  • The assertion is not testable.
  • The assertion is not easily testable through self-testing.
  • The test requires expensive test equipment.

Some of these assertions are described in checklists so that both system and device manufacturers can use them to verify PCI device compliance. See "Test Descriptions" for a description of all implemented tests.


Reference Document Sources for PCI Assertions

Hardware and BIOS functional requirements specified in the following documents:

Default Device Class Power Management Reference Specification, Version 1.0 or later, and

http://www.microsoft.com/hwdev/resources/specs/pmref/default.asp

Microsoft Windows Driver Development Kit

http://www.microsoft.com/ddk/
See "WDM Audio Driver Design Guide," "Audio Miniport Drivers," and "DirectMusic Synths and Synth Sinks" in the Windows XP DDK

Microsoft Windows Logo Program System and Device Requirements, Version 2.0

http://www.microsoft.com/hwdev/winlogo/
(listed as "WLP#" in these assertions)

PC 2001 System Design Guide and PC 99 System Design Guide

http://www.microsoft.com/hwdev/platform/pcdesign/desguide/pcguides.asp

PCI 2.1 Specification ECN
PCI Bus Power Management Interface Specification, Revision 1.1 (PCI-PM)

http://www.pcisig.com/specifications

PCI IDE Controller Specification, Revision 1.0

http://www.pcisig.com/specifications

PCI Local Bus Specification, Revision 2.2 (PCI 2.2)

http://www.pcisig.com/specifications

Platform PCI Compliance Test Adapter, External Design Specification

http://www.pcisig.com/specifications


PCI Peripheral Assertions

The PCI peripheral group includes the following assertions used to verify that the system correctly implements the power management register interface for all on-board PCI peripherals, and the system correctly implements subsystem ID and subsystem vendor ID of PCI devices.

Power Management Register Interface Assertions

The following sections list the PCI power management interface assertions required to implement PCI-based power-managed systems and device functions.

Note: This test applies for Windows 2000 and Windows Millennium Edition, but not for Windows XP.

This section includes:

Status Register and Cap_Ptr Register Assertions (4.1.1 - 4.1.8)

Capability Identifier Register Assertions (4.2.1 - 4.2.5)

Power Management Capabilities (PMC) Register Assertions (4.3.1 - 4.3.15)

Power Management Control/Status Register Assertions (PMCSR) (4.4.1 - 4.4.18)

Data Register Assertions (4.5.1 - 4.5.7)

PMCSR to PCI Bridge Support Extensions -- PMCSR_BSE Assertions (4.6.1 - 4.6.6)

Subsystem ID and Subsystem Vendor ID Assertions (4.7.1 - 4.7.6)

Subsystem ID and Subsystem Vendor ID Assertions Not Tested (4.8.1 - 4.8.2)

PCI Power State Transition Assertions Not Tested (4.9.1 - 4.9.11)

PCI Function Power Management State Assertions Not Tested (4.10.1 - 4.10.30)

PCI Bus Power State Transition Assertions Not Tested (4.11.1 - 4.11.16)


Status Register and Cap_Ptr Register Assertions

The following status register and Cap_Ptr register assertions are tested—for Windows 2000 and Windows Millennium Edition, but not for Windows XP—in TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP).

4.1.1 The Capabilities bit (bit 4) in the PCI Status Register determines whether or not the function implements new capabilities.

When this bit is set to a value other than 0b, it indicates that the function implements capabilities. If the value is set at 0b, the function does not implement new capabilities.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.1.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.1.2 The Capabilities bit is read-only and its reset value is 1b.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.1.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.1.3 The Cap_Ptr register is located in PCI configuration space at offset 34h for header-type 0 devices.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.1.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.1.4 The Cap_Ptr register is located in PCI configuration space at offset 34h for header-type 1 devices (PCI-to-PCI bridges).

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.1.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.1.5 The values of 00h-3Fh are not valid for the Cap_Ptr register.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.1.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.1.6 The Cap_Ptr register offset is double word aligned so that the two least-significant bits are always assigned 0 values.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.1.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.1.7 PCI based network controllers/display controllers/modem devices/audio devices must support the PCI power management register interface.

Reference document: WLP# - B2.5; PC 2001 System Design Guide - PCI-0130, PCI-0132, GRPH-0163 and SYS-0003.4; PC 99 System Design Guide - 9.17, 9.20, 14.51 and 17.28.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.1.8 PCI-To-PCI Bridge devices must support the PCI power management register interface.

Reference documents: WLP# - B2.5.4.1; PC 2001 System Design Guide - PCI-0130, PC 99 System Design Guide - 9.17
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)


Capability Identifier Register Assertions

The following capability identifier assertions are tested—for Windows 2000 and Windows Millennium Edition, but not for Windows XP— TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP).

4.2.1 The power management registers can be accessed as bytes, 16-bit words, or 32-bit double words.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.1.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.2.2 The Capability ID register is read-only.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.1.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.2.3 The NextItemPtr field (bits 8-15) must point to the next item in the capabilities list.

This address must be double word-aligned. If this capability entry is the last, it must have a value of 00h.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.1.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.2.4 The NextItemPtr field (bits 8-15) is read-only.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.1.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.2.5 Each function of a PCI device has only one item in its capabilities list with Cap_ID register value set to a value of 01b.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.1.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)


Power Management Capabilities (PMC) Register Assertions

The following power management capabilities register assertions are tested—for Windows 2000 and Windows Millennium Edition, but not for Windows XP— TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP).

4.3.1 The PMC Register is a 16-bit read-only register.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.3.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.3.2 The Version field (bits 0-2) must have a value of 010b or 001b to indicate that this function complies with Revision 1.1 or 1.0, respectively, of the PCI Power Management Interface Specification.

Network and Modem controllers have to support PCI PM 1.1. Audio and Video must support PCI PM 1.0 or later.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.3.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.3.3 The PME_Clock (bit 3) must have a value of 0b for functions that do not support PME# generation in any state.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.3.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.3.4 The reset value for the PME_Clock bit is 0b.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 3.2.3.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.3.5 If the function relies on the presence of the PCI clock for PME# operation, the PME_Clock bit must be set to a value of 1b; otherwise, it must be set to a value of 0b.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 3.2.3.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.3.6 The DSI bit (bit 5) indicates whether special initialization of this function is required. This bit is read only.

Reference document: WLP# - B2.5; PCI Bus Power Management1.1 Specification, Section 3.2.3.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.3.7 If PME# generation from the D3 Cold state is not supported by the PCI function, when system software reads the Aux_Current field (bits 6-8), the PCI function must return a value of 000b.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 3.2.3.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.3.8 If the PCI function implements the Data Register, the Aux_Current field’s read operation must return a value of 000b.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 3.2.3.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.3.9 For PCI functions that support PME# from the D3 Cold state and do not implement the Data Register, the Aux_Current field returns the maximum current required for 3.3Vaux auxiliary power.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 3.2.3.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.3.10 The D1_Support bit (bit 9) must be set to a value of 1b for any function that supports the D1 power management state.

If the function does not support D1, it must always return a value of 0b for this bit.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 3.2.3.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.3.11 The D1_Support bit is read-only.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 3.2.3.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.3.12 The D2_Support bit (bit 10) must be set to a value of 1b for any function that supports the D2 power management state.

If the function does not support D2, it must always return a value of 0b for this bit.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 3.2.3.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.3.13 The D2_Support bit is read-only.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 3.2.3.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.3.14 The PME_Support field (bits 11-15) indicates the power states in which the function may assert the PME# signal.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 3.2.3.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.3.15 All reserved bits in the PMC Register (bit 4) must always return a value of 0b when they are read.

Write operations on these bits have no effect.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 3.2.3.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)


Power Management Control/Status Register Assertions (PMCSR)

The following power management control/status register assertions are tested—for Windows 2000 and Windows Millennium Edition, but not for Windows XP— TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP).

4.4.1 The PowerState field (bits 0-1) in the PMCSR Register is used both to determine the current power state of a PCI function and to set the function into a new power state.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 3.2.4.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.4.2 The PowerState field is read/write.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 3.2.4.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.4.3 The reset value for the PowerState field is 00b.

Reference document: PCI Bus Power Management 1.1 Specification, Section 3.2.4.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.4.4 If system software attempts to write an unsupported optional state to the PowerState field, the write operation must complete normally on the bus.

The data is then discarded, and no state change occurs.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 3.2.4.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.4.5 The PME_En bit (bit 8) is read/write.

Reference document: WLP# - B2.5; PCI Bus Power Management1.1 Specification, Section 3.2.4.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.4.6 If the function does not support PME# generation from the D3 Cold state, the PME_En bit must default to a value of 0b.

Reference document: WLP# - B2.5; PCI Bus Power Management1.1 Specification, Section 3.2.4.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.4.7 PCI functions that do not support PME# generation from any Dx state may treat the PME_En bit as read-only.

When system software reads the bit, the bit must always return a value of 0b.

Reference document: WLP# - B2.5; PCI Bus Power Management1.1 Specification, Section 3.2.4.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.4.8 If the PCI function supports the PME# signal generation from the D3 Cold state, the PME_En bit is sticky, and the operating system must explicitly clear it upon each initial loading.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.4.9 The PME_Status (bit 15) supports read/write/clear.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.4.10 Writing a value of 1b to the PME_Status bit clears it and causes the function to stop asserting a PME#, if enabled.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.4.11 Writing a value of 0b to the PME_Status bit has no effect.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.4.12 If the PCI function does not support PME# generation from the D3 Cold state, the PME_Status bit defaults to a value of 0b.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.4.13 The Data_Select field (bits 9-12) is required for any function that implements the Data Register.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.4.14 The Data_Select field is read/write.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.4.15 The reset value of the Data_Select field is 0000b.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.4.16 The Data_Scale field (bits 13-14) is required for any function that implements the Data Register.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.4.17 The Data_Scale field is read-only.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.4.18 All reserved fields in the PMCSR Register (bits 2-7) must always return a value of 0 when they are read.

Write operations on these fields have no effect.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)


Data Register Assertions

The following data register assertions are tested — for Windows 2000 and Windows Millennium Edition, but not for Windows XP— in TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.5.1 The Data Register is an optional, 8-bit read-only register.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.6.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.5.2 If the Data Register is implemented, the Data_Select and Data_Scale fields must also be implemented.

If the data register is not implemented, it must always return a value of 0b. The Data_Select and Data_Scale fields must also return a value of 0b.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.6.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.5.3 The default value of the Data Register is 00h.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 3.2.6.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.5.4 If the Data Register is implemented, writing an appropriate value to the Data_Select field in the PMCSR Register and reading both the Data_Scale field and Data Register causes the binary value read from the Data Register to be multiplied by the Data_Scale field’s scaling factor to calculate the value for the desired measurement.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 3.2.6.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.5.5 Only values ranging from 0 through 8 are valid for the Data_Select field.

Values ranging from 9 through 15 are reserved.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 3.2.6.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.5.6 Multifunction devices that implement power reporting must report the power that each function consumes in each corresponding function’s configuration space.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 3.2.6.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.5.7 If the Data_Select field of the function 0’s PMCSR Register has been programmed to a value of 1000b, the Data Register must be used to report the common logic power consumption via function 0’s configuration space in a multifunction device.

Reference document: WLP# - B2.5; PCI Bus Power Management1.1 Specification, Section 3.2.6.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)


PMCSR to PCI Bridge Support Extensions -- PMCSR_BSE Assertions

The following PMCSR to PCI bridge support extensions assertions are tested— for Windows 2000 and Windows Millennium Edition, but not for Windows XP—in TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.6.1 The B2_B3# bit (bit 6) determines the action to result from programming the function to the D3 Hot state.

A value of 1b indicates that when the bridge function is programmed to this state, its secondary bus PCI clock is stopped (B2). A value of 0b indicates that its secondary bus has its power removed (B3).

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 3.2.5.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.6.2 The B2_B3# bit is read-only.

Reference document: WLP# - B2.5; PCI Bus Power Management1.1 Specification, Section 3.2.5.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.6.3 If the BPCC_En bit is set to a value of 1b, only the B2_B3# bit becomes significant.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 3.2.5.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.6.4 The BPCC_En bit (bit 7) indicates the presence of the bus power and clock control mechanism.

A value of 1b indicates that the bus power/clock control mechanism is enabled. A value of 0b indicates that the bus power and clock control policies have been disabled.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 3.2.5.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.6.5 When the bus power and clock control mechanism is disabled, the system software cannot use the bridge’s PMCSR Register PowerState field to control the power or clock of the bridge’s secondary bus.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 3.2.5.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

4.6.6 All reserved fields in the PMCSR_BSE Register (bits 0-5) must always return a value of 0b when they are read.

Write operations on these fields have no effect.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 3.2.5.
Test description: TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)


Subsystem ID and Subsystem Vendor ID Assertions

These assertions are tested by —for Windows 2000 and Windows Millennium Edition, but not for Windows XP—in TD-4.2 PCI Subsystem Device ID and Subsystem Vendor ID Test (PCISID).

4.7.1 Each PCI device must implement the Subsystem ID and Subsystem Vendor ID registers of the PCI configuration space.

Reference document: WLP#-B2.5.1.7; PC 2001 System Design Guide - PCI-0126, PC 99 System Design Guide - 9.11.
Test description: TD-4.2 PCI Subsystem Device ID and Subsystem Vendor ID Test (PCISID)

Note: PCI devices with base class of 6 and Subclass of 0 through 4, and base class of 8 and subclass 0 through 3 are excluded from this requirement.

4.7.2 Support for the Subsystem Device ID and Subsystem Vendor ID registers requires nonzero values to be populated for both of these registers.

Reference document: WLP#-B2.5.1.7; PC 2001 System Design Guide - PCI-0126, PC 99 System Design Guide - 9.11.
Test description: TD-4.2 PCI Subsystem Device ID and Subsystem Vendor ID Test (PCISID)

4.7.3 Each subsystem ID must be the assigned value that the PCI SIG provides.

Reference document: WLP#-B2.5.1.7; PC 2001 System Design Guide - PCI-0126, PC 99 System Design Guide - 9.11.
Test description: TD-4.2 PCI Subsystem Device ID and Subsystem Vendor ID Test (PCISID)

4.7.4 Each subsystem ID must be unique for each subsystem configuration.

Reference document: WLP#-B2.5.1.7; PC 2001 System Design Guide - PCI-0126, PC 99 System Design Guide - 9.11.
Test description: TD-4.2 PCI Subsystem Device ID and Subsystem Vendor ID Test (PCISID)

4.7.5 Each subsystem ID must not be directly writable.

Reference document: WLP#-B2.5.1.7; PC 2001 System Design Guide - PCI-0126, PC 99 System Design Guide - 9.11.
Test description: TD-4.2 PCI Subsystem Device ID and Subsystem Vendor ID Test (PCISID)

4.7.6 All PCI functions must ensure that each subsystem ID is in place before the operating system accesses the function’s configuration space registers.

Subsystem IDs must be in place both at the loading of the initial operating system and after any transition of the PCI bus from the B3 Cold state back to that of B0.

Reference document: WLP#-B2.5.1.7; PC 2001 System Design Guide - PCI-0126, PC 99 System Design Guide - 9.11.
Test description: TD-4.2 PCI Subsystem Device ID and Subsystem Vendor ID Test (PCISID)


Subsystem ID and Subsystem Vendor ID Assertions Not Tested

The PCISID test does not cover the following test assertions related to the PCI subsystem ID and subsystem vendor ID registers.

Note: Assertions labeled "Not Tested" may be tested in future tests.

4.8.1 For add-in cards, hardware on the card itself, for example, via serial EEPROM—not an extension BIOS or device driver—must populate each subsystem ID.

Reference document: WLP#-B2.5.1.7; PC 2001 System Design Guide - PCI-0126, PC 99 System Design Guide - 9.11.
Test description: Not Tested in PCISID test

4.8.2 For devices that are integrated on the system board, the system BIOS at power-on self-test or ACPI control methods (PS0 for B0 transitions) can be used to program subsystem IDs.

This code must run before the operating system accesses a function’s configuration space registers.

Reference document: WLP#-B2.5.1.7; PC 2001 System Design Guide - PCI-0126, PC 99 System Design Guide - 9.11.
Test description: Not Tested in PCISID test


PCI Power State Transition Assertions Not Tested

PCI bus and function power state assertions that implement PCI power management compliant systems and device functions are listed below. There are no specific tests to verify the following assertions.

Note: Assertions labeled "Not Tested" may be tested in future tests.

4.9.1 The PCI originating device can support one or more power states.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 4.
Test description: Not Tested

4.9.2 All PCI buses support the B0 state by default.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 4.1.
Test description: Not Tested

4.9.3 A PCI bus in B0 state is capable of running any legal PCI transaction.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 4.1.
Test description: Not Tested

4.9.4 Before attempting to program the bus to a non-BO power management state, programmers must have previously coded all of its resident functions to a state precluding additional bus activity initiated by these functions.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 4.1.
Test description: Not Tested

4.9.5 For legacy PCI functions, system software must rely on means such as disabling the Bus Master Enable bit within the PCI Command Register.

This ensures that the function does not attempt to initiate any bus transactions.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 4.1.
Test description: Not Tested

4.9.6 A programmable interface for placing a bus in, or restoring it from, the B3 state is optional.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 4.4.
Test description: Not Tested

4.9.7 A system reset must always return the PCI bus to the B0 state.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 4.5.
Test description: Not Tested

4.9.8 Removing power always takes the bus to the B3 state.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 4.5.
Test description: Not Tested

4.9.9 Each state of PCI bus power management must track its associated originating device’s power management state.

System software can write to the originating bridge function’s PMCSR PowerState field to make the following bus transitions:

B0->B1 | B1->B2
B1->B0 | B1->B3
B0->B2 | B2->B3
B2->B0 | B3->B0

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 4.7.
Test description: Not Tested

4.9.10 A PCI function residing on a particular bus must be set at a power management state equal to or greater than that bus.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 4.1.
Test description: Not Tested

4.9.11 The D3 Hot state of the originating device’s bridge may cause the power management state of its secondary bus to transition to either a B2 or B3 state.

The B2_B3# bit in the PMCSR_BSE Register determines whether the transition state is B2 or B3.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 4.7.1.
Test description: Not Tested


PCI Function Power Management State Assertions Not Tested

The following PCI function power management state assertions are not tested.

Note: Assertions defined as "Not Tested" under the provisions of this specification may be subject to testing through alternative test facilities.

4.10.1 Each PCI function must implement its own power management interface.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.
Test description: Not Tested

4.10.2 PCI functions operating in D0, D1, D2, or D3 Hot state must be compliant with PCI Local Bus Specification, Revision 2.1.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.
Test description: Not Tested

4.10.3 All functions must support the D0 state.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.1.
Test description: Not Tested

4.10.4 Immediately after a power-on reset, the function must be in Uninitialized D0 state.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.1.
Test description: Not Tested

4.10.5 Upon entering the D0 state from that of D3 Hot, the function must be in Uninitialized D0 state.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.1.
Test description: Not Tested

4.10.6 After initializing the function, this function must be in D0 Active state.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.1.
Test description: Not Tested

4.10.7 After a bus reset, all PCI functions must be in Uninitialized D0 state.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.1.
Test description: Not Tested

4.10.8 Implementing the D1 power management state is optional.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.2.
Test description: Not Tested

Note: For certain device classes, the D1 power management state may be required. If this state is not implemented, the test program reports a warning message.

4.10.9 Implementing the D2 power management state is optional.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.3.
Test description: Not Tested

Note: For certain device classes, the D2 power management state may be required. If this state is not implemented, the test program reports a warning message.

4.10.10 System software must restore the function to D0 Active state before it can access memory or input/output (I/O) space.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.3.
Test description: Not Tested

4.10.11 Initiated actions, such as bus mastering and generation of functional interrupt requests, can commence only after the function has been restored to D0 Active state.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.3.
Test description: Not Tested

4.10.12 All PCI functions that adhere to the PCI Power Management Interface Specification, Revision 1.1, are required to support the D3 Cold states.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.4.
Test description: Not Tested

4.10.13 When the function returns to the D0 state from that of D3, a full re-initialization of the function, including the PCI configuration space, is required.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.4.
Test description: NOT TESTED

4.10.14 The only legal state transition from either the D3 Hot or D3 Cold states is to that of Uninitialized D0.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.4.
Test description: NOT TESTED

4.10.15 Functions in the D3 Hot state can be transitioned to an Uninitialized D0 state either by software writing to the function’s PMCSR register or by the bus segment reset (PCI RST#) being asserted.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.
Test description: NOT TESTED

4.10.16 If Vcc is removed from a PCI device, all of its PCI functions must transition immediately to D3 Cold state.

All PCI device functions support this state by default.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.4.2.
Test description: NOT TESTED

4.10.17 Only reapplying Vcc and asserting the bus segment reset (RST#) to the function’s host PCI device can cause functions in the D3 Cold state to transition to the Uninitialized D0 state.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.
Test description: NOT TESTED

4.10.18 When power is restored, the PCI RST# must be asserted and functions return to Uninitialized D0 state with a full PCI 2.1-compliant power-on reset/restoration of power after a reset occurs.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.4.2.
Test description: NOT TESTED

4.10.19 Functions that support PMEs from D3 Cold state must preserve their PME context through the D3 Cold to D0 state transition.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.4.2.
Test description: NOT TESTED

4.10.20 When the PCI bus is in B0 state and the PCI function is in Uninitialized D0 state, the PCI function must permit PCI configuration cycles.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.6.
Test description: NOT TESTED

4.10.21 When the PCI bus is in B0 state and the PCI function is in D0 Active state, the PCI function must permit any PCI transactions.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.6.
Test description: NOT TESTED

4.10.22 When the PCI bus is in B0 state and the PCI function is in D1 state, the PCI function must permit PCI configuration cycles.

The function behavior is device-class specific.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.6.
Test description: NOT TESTED

4.10.23 When the PCI bus is in B0 state and the PCI function is in D2 state, the PCI function must permit PCI configuration cycles.

The function behavior is device-class specific.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.6.
Test description: NOT TESTED

4.10.24 When the PCI bus is in B0 state and the PCI function is in D3 Hot state, the PCI function must permit PCI configuration cycles.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.6.
Test description: NOT TESTED

4.10.25 When the PCI bus is in B1 state and the PCI function is in D1 state, no action to the PCI function is allowed.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.6.
Test description: NOT TESTED

4.10.26 When the PCI bus is in B1 state and the PCI function is in D2 state, no action to the PCI function is allowed.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.6.
Test description: NOT TESTED

4.10.27 When the PCI bus is in B1 state and the PCI function is in D3 Hot state, no action to the PCI function is allowed.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.6.
Test description: NOT TESTED

4.10.28 When the PCI bus is in B2 state and the PCI function is in D1 state, no action to the PCI function is allowed.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.6.
Test description: NOT TESTED

4.10.29 When the PCI bus is in B2 state and the PCI function is in D3 Hot state, no action to the PCI function is allowed.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.6.
Test description: NOT TESTED

4.10.30 When the PCI bus is in B3 state and the PCI function is in D3 Cold state, the PCI function allows only bus segment reset.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.6.
Test description: NOT TESTED


PCI Bus Power State Transition Assertions Not Tested

The PCI test adapter diagnostics test, PMDIAG, does not cover the following assertions related to PCI bus power and/or PCI function power management states. There are no specific tests to verify the following assertions.

Note: Assertions labeled "Not Tested" may be tested in future tests.

4.11.1 If an access is attempted to a function residing downstream from a bus that is not in B0 state, the transaction must be treated as if a Master Abort has occurred.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 4.1.
Test description: NOT TESTED

4.11.2 When a PCI bus is in B1 state, Vcc is still applied to all devices residing on the bus.

However, no transactions are allowed to take place on the PCI bus, with the B1 state indicating that the bus is idle.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 4.2.
Test description: NOT TESTED

4.11.3 Parking a PCI bus is allowed in B1 state.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 4.2.
Test description: NOT TESTED

4.11.4 When a PCI bus is in B2 state, Vcc is still applied to all devices residing on the bus, but the clock is stopped and held in the low state.

All PCI bus signals must always be held in valid logic states.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 4.3.
Test description: NOT TESTED

4.11.5 Parking a PCI bus is allowed in B2 state.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 4.3.
Test description: NOT TESTED

4.11.6 When a PCI bus is in B3 state, Vcc has been removed from all devices on the PCI bus segment.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 4.3.
Test description: NOT TESTED

4.11.7 When Vcc is reapplied to the PCI bus, the RST# must be asserted for that bus segment and the bus returned to an active, idle state.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 4.3.
Test description: NOT TESTED

4.11.8 All PCI 2.1-compliant systems must indicate the B3 state when their power is removed.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 4.4.
Test description: NOT TESTED

4.11.9 For functions that comply with the PCI 2.1 66-MHz clock specification, the power management capabilities reported to the system must indicate that its clock may not be stopped.

While operating on a 66-MHz bus segment, the D2_Support bit in the PMC Register must always return a 0b value for these functions.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 4.6.
Test description: NOT TESTED

4.11.10 System software is responsible for determining the clocking requirements for all 66-Mhz components on a given bus segment.

If any of these components cannot meet the 33-MHz clocking requirements while operating at 66-MHz, the system software must ensure that the bus segments are never placed into B2 state.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.6.
Test description: NOT TESTED

4.11.11 Immediately after power-on reset (restoration of power after a reset occurs), all PCI legacy functions must be in D0 state.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.1.
Test description: NOT TESTED

4.11.12 If a function supports the D1 state when operating on a 33-MHz PCI bus, the function must also support this state if it is operating on a 66-MHz PCI bus, provided that 66 MHz is supported.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.2.
Test description: NOT TESTED

4.11.13 When the PCI bus is in B0 state and the legacy PCI function is in D0 state, the PCI function must permit any PCI transaction.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.6.
Test description: NOT TESTED

4.11.14 When the PCI bus is in B3 state and the legacy PCI function is in D3 state, the PCI function must allow only bus segment resetting.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.6.
Test description: NOT TESTED

4.11.15 The recovery time requirements for PCI function state transition are not tested.

Recovery time represents the minimum time duration from when a function is programmed to change its state and when the function is next accessed, including the PCI configuration space. In some cases, hardware causes this time delay, and in others, system software causes this delay.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.6.
Test description: NOT TESTED

4.11.16 The PCI function restoration time requirements are not tested.

Restoration time represents the total time duration from when a PCI function transitions from its current power management state to its fully configured D0 active state.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 4.1.
Test description: NOT TESTED


PCI Test Adapter Diagnostic(s) Assertions

The PCI bus and function power state assertions that implement PCI power management compliant systems and device functions are intended to verify that all PCI system tests run correctly on this hardware. These assertions are tested in TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG).

4.12.1 The status register bit 4 of the PCI test adapter function 0 must be hard-wired to read a value of 1b.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1 Section 3.2.1.
Test description: TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

4.12.2 The Power Management Register block of the PCI test adapter must be hard-wired for a setting of 0x80.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1 Section 3.2.1.
Test description: TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

4.12.3 When system software reads the PCI test adapter’s Capability ID Register, the device must be hard-wired to return a value of 01h.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.1.
Test description: TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

4.12.4 The PCI test adapter’s NextPtr/Next_Ptr bit/field/value in the Power Management Register block must be set to 0x00 for the PCI test adapter.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.1.
Test description: TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

4.12.5 When the PCI test adapter is in D3 Cold state and the system can support 3.3Vaux auxiliary power, the adapter’s PME_Support bit (bit 15) must be set to a value of 1b.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1 Section 3.2.3.
Test description: TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

4.12.6 The PCI test adapter must be capable of supporting PME# signal generation from the D3 Hot state.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.3.
Test description: TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

4.12.7 The PCI test adapter must be capable of supporting PME# signal generation from the D2 state.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.3.
Test description: TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

4.12.8 The PCI test adapter must be capable of supporting PME# signal generation from the D1 state.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.3.
Test description: TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

4.12.9 The PCI test adapter must be capable of supporting PME# signal generation from the D0 state.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.3.
Test description: TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

4.12.10 The PCI test adapter must support the state of D2 power management.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.3.
Test description: TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

4.12.11 The PCI test adapter must support the state of D1 power management.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.3.
Test description: TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

4.12.12 The PCI test adapter’s DSI bit (bit 5) must be set to a value of 0b.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.3.
Test description: TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

4.12.13 The PCI test adapter’s Reserved bit (bit 4) in the PMC Register must be set to a value of 0b.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.3.
Test description: TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

4.12.14 The PCI test adapter’s PMC_Clock bit (bit 3) must be hard-wired to return a value of 0b.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.3.
Test description: TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

4.12.15 The PCI test adapter must be compliant with PCI Power Management (PM) specification, Revision 1.1.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.3.
Test description: TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

4.12.16 When the PCI test adapter’s SW1.2 switch is set to On, its PME_Status bit value must be set to a value of 0b, and its PME_En bit must be set to a value of 0b.

Reference document: WLP# - B2.5.2; Platform PCI Bus Compliance Test Adapter.
Test description: TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

4.12.17 The PME_En bit in the PMCSR Register is read-write.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

4.12.18 By default, the PowerState field in the PMCSR Register must be set to a value of 00b.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

4.12.19 The PowerState field (bits 0-1) in the PMCSR Register is read-write and therefore must support the device power states of D0, D1, D2, and D3 Hot.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

4.12.20 Both of the Data_Select bits 9-12 in the PMCSR Register must be hard-wired to return a value of 0000b.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

4.12.21 The Reserved field (bits 2-7) in the PMCSR Register must be hard-wired to return a value of 000000b.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

4.12.22 When system software reads the PCI test adapter’s LoadSelect field (bits 1-2) in its Misc_PMCTL Register, the device function must return a value of 10b.

Reference document: WLP# - B2.5.2; Platform PCI Bus Compliance Test Adapter, External Design Specifications
Test description: TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

4.12.23 When system software reads the PCI test adapter’s Reserved field (bits 3-15) in its Misc_PMCTL Register, the device function must return a value of all zeros.

Reference document: WLP# - B2.5.2; Platform PCI Bus Compliance Test Adapter, External Design Specifications.
Test description: TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

4.12.24 If the PCI test adapter is configured to consume 375mA @ 3.3Vaux and can generate a PME# assertion while in D3 Cold state, the bits in the Aux_Current Register must return a value of 111b.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

4.12.25 If the PCI test adapter is configured to consume 160mA and can generate a PME# assertion while in D3 Cold state, the bits in the Aux_Current field Register must return a value of 011b.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

4.12.26 If the PCI test adapter is not configured to or otherwise cannot generate a PME# signal assertion from D3 Cold state, the bits in the Aux_Current field in PMC register must return a value of 000b.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1 Section 3.2.4.
Test description: TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

4.12.27 The default value of the PCI test adapter’s Assert_PME bit (0) must be set to a value of 0b.

Reference document: WLP# - B2.5.2; Platform PCI Bus Compliance Test Adapter, External Design Specifications.
Test description: TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

4.12.28 If the PCI test adapter’s Assert_PME bit (0) is set to a value of 1b and its PME_En bit is set to a value of 0b, the device’s PME_Status bit must not be set to a value of 1b.

Reference document: WLP# - B2.5; Platform PCI Bus Compliance Test Adapter, External Design Specifications.
Test description: TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

4.12.29 If the PCI test adapter’s Assert_PME bit (0) is set to a value of 1b and its PME_En bit is set to a value of 1b, the device’s PME_Status bit must also be set to a value of 1b.

Reference document: WLP# - B2.5; Platform PCI Bus Compliance Test Adapter, External Design Specifications.
Test description: TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

4.12.30 Whenever system software clears the PCI test adapter’s PME_Status bit, the device must clear its Assert_PME bit.

Reference document: WLP# - B2.5; Platform PCI Bus Compliance Test Adapter, External Design Specifications.
Test description: TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

4.12.31 When the PCI test adapter is in D1, D2, or D3 Hot state it must permit PCI configuration cycles to occur.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

PCI Maximum Completion Time Requirement Assertions

All PCI devices must comply with the Maximum Completion Time ECN that has been approved for the PCI 2.1 specification. Complying with this requirement ensures that the PCI bus yields shorter PCI transaction latencies, allowing more robust handling of isochronous streams in the system. Assertions associated with the maximum completion time (MCT) that the PCIMCT test evaluates are listed as follows.

Assertions in this section are tested in TD-4.3 PCI Maximum Completion Time Test (PCIMCT)

4.14.1 All PCI devices under test must complete the memory write transaction within an MCT of 10 microseconds.

This target is specified in PCI clocks as 334 clock cycles for PCI speeds of 33MHz or less and as 668 clock cycles for PCI speeds of 66MHz or more.

Reference document: WLP# - B2.5; PCI 2.1 Specification, ECN.
Test description: TD-4.3 PCI Maximum Completion Time Test (PCIMCT)

4.14.2 All PCI devices under test that are bridges (such as, device with base class of 0x06) are exempt from the MCT requirements for any requests that move data across the bridge.

Bridge devices must follow the MCT requirement for requests that access information within the bridge.

Reference document: WLP# - B2.5; PCI 2.1 Specification, ECN.
Test description: TD-4.3 PCI Maximum Completion Time Test (PCIMCT)

4.14.3 MCT requirements are not in effect during initialization time, which is defined as 2**25 PCI clocks after the RST# signal is "deasserted."

Reference document: WLP# - B2.5; PCI 2.1 Specification, ECN.
Test description: TD-4.3 PCI Maximum Completion Time Test (PCIMCT)

4.14.4 All PCI devices under test, except host bridges, must complete the Target Initial Latency within the specified time.

This time is specified in PCI clocks cycles as 16 clock cycles.

Reference document: WLP# - B2.5; PCI 2.1 Specification, ECN, PCI 2.2 Specification 3.5.1.1
Test description: PCILat32.exe

4.14.5 All PCI devices under tests that are host bridges are exempt from the Target Initial Latency requirements.

They are instead required to complete the Target Initial latency within 32 clock cycles.

Reference document: WLP# - B2.5; PCI 2.1 Specification ECN, PCI 2.2 Specification 3.5.1.1
Test description: PCILat32.exe

4.14.6 Target Initial Latency requirements are not in effect during the initialization time, which is defined as 2**25 PCI Clock after the RST# signal is "de-asserted."

Reference document: WLP# - B2.5; PCI 2.1 Specification ECN, PCI 2.2 Specification 3.5.1.1
Test description: PCILat32.exe


PCI Latency 3.2 Test

The PCI Latency 3.2 test, tests for the PCI Latency of device/driver combinations, and the following assertions:

4.15.1 Target Initial Latency: Time: device/driver combination must start within 16 PCI clocks

Reference document: WLP# - B2.5; PCI 2.1, section 3.5.1.1
Test description: Test Not Specified

4.15.2 Maximum Completion Time: device/driver combination must finish write transaction and stop using bus bandwidth within 10 microseconds (approximately 334 PCI clocks)

Reference document: WLP# - B2.5;
Test description: Test Not Specified


PCI System Assertions

PCI System Assertions listed in this section include:

PME # Signal Assertions
PME# Signal Assertions Not Tested
3.3Vaux Auxiliary Power Assertions
3.3Vaux Auxiliary Power Assertions Not Tested
PCI Voltage Requirement Assertions Tested
System BIOS Initialization Requirement Assertions


PME # Signal Assertions

The following PME # signal assertions are tested by TD-4.7 PCI PME# Signal Routing Test (PCIPME1) and
TD-4.8 PME# Signal Routing - Simultaneous (PCIPME2) Test Description.

4.16.1 System software must enable PCI functions before asserting the PME# signal.

Reference document: WLP# - B2.5.2; PCI Bus Power Management 1.1 Specification, Section 7.
Test descriptions: TD-4.7 PCI PME# Signal Routing Test (PCIPME1) and
TD-4.8 PME# Signal Routing - Simultaneous (PCIPME2) Test Description

4.16.2 Once the PME# signal is asserted, the device must continue to drive the signal low until software explicitly clears the PME_Status bit in the function’s PMCSR Register.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 7.
Test descriptions: TD-4.7 PCI PME# Signal Routing Test (PCIPME1) and
TD-4.8 PME# Signal Routing - Simultaneous (PCIPME2) Test Description

4.16.3 Software must enable the PME# signal by setting the PME_En bit in the PMCSR Register.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 7.
Test descriptions: TD-4.7 PCI PME# Signal Routing Test (PCIPME1) and
TD-4.8 PME# Signal Routing - Simultaneous (PCIPME2) Test Description

4.16.4 When a PCI function detects an event that requires the system to change its power state, the function must assert the PME# signal.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 7.
Test descriptions: TD-4.7 PCI PME# Signal Routing Test (PCIPME1) and
TD-4.8 PME# Signal Routing - Simultaneous (PCIPME2) Test Description

4.16.5 The PME# signal network must continue to work when a mixture of powered and "unpowered" PCI devices have their PME# outputs wire-ORed together.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 7.
Test descriptions: TD-4.7 PCI PME# Signal Routing Test (PCIPME1) and
TD-4.8 PME# Signal Routing - Simultaneous (PCIPME2) Test Description

4.16.6 The PME# signal is an optional open-drain, active low signal.

Reference document: WLP# - B2.5.2; PCI Bus Power Management 1.1 Specification, Section 7.
Test descriptions: TD-4.7 PCI PME# Signal Routing Test (PCIPME1) and
TD-4.8 PME# Signal Routing - Simultaneous (PCIPME2) Test Description

4.16.7 The PME# signal must be assigned to pin 14A of the standard PCI connector.

Reference document: WLP# - B2.5.2; PCI Bus Power Management 1.1 Specification, Section 7.
Test descriptions: TD-4.7 PCI PME# Signal Routing Test (PCIPME1) and
TD-4.8 PME# Signal Routing - Simultaneous (PCIPME2) Test Description

4.16.8 The downstream PCI function’s PME# signal must be routed around the PCI-to-PCI bridge and be connected with the PME# signal network of the primary bus bridge.

Reference document: WLP# - B2.5.2; PCI Bus Power Management 1.1 Specification, Section 7.1.
Test descriptions: TD-4.7 PCI PME# Signal Routing Test (PCIPME1) and
TD-4.8 PME# Signal Routing - Simultaneous (PCIPME2) Test Description

4.16.9 Systems must route the PME# signal to the appropriate system logic to awaken the system.

ACPI-compliant systems may route this signal to the SCI# Interrupt.

Reference document: WLP# - B2.5.2; PCI Bus Power Management 1.1 Specification, Section 7.32.
Test descriptions: TD-4.7 PCI PME# Signal Routing Test (PCIPME1) and
TD-4.8 PME# Signal Routing - Simultaneous (PCIPME2) Test Description

4.16.10 If a function supports PME# generation from the D3 Cold state, either a PCI bus signal reset or the internal "soft" reinitialization, which occurs when a function is restored from the D3 Hot state, does not affect its PME context.

The PME context must be preserved.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 3.2.4.
Test descriptions: TD-4.7 PCI PME# Signal Routing Test (PCIPME1) and
TD-4.8 PME# Signal Routing - Simultaneous (PCIPME2) Test Description

4.16.11 If PME# generation is not supported from the D3 Cold state, all PME contexts must be initialized with the assertion of a bus segment reset.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 3.2.4.
Test descriptions: TD-4.7 PCI PME# Signal Routing Test (PCIPME1) and
TD-4.8 PME# Signal Routing - Simultaneous (PCIPME2) Test Description

4.16.12 The system software must be able to write to a function’s PME_Status and PME_En bits with the appropriate values after a PME generation clears these bits.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 3.2.4.
Test descriptions: TD-4.7 PCI PME# Signal Routing Test (PCIPME1) and
TD-4.8 PME# Signal Routing - Simultaneous (PCIPME2) Test Description

4.16.13 The PME# signal must generate some form of System Control Interrupt (SCI).

System software must be responsible for handling the PME# service routine.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 8.4.1.
Test descriptions: TD-4.7 PCI PME# Signal Routing Test (PCIPME1) and
TD-4.8 PME# Signal Routing - Simultaneous (PCIPME2) Test Description

4.16.14 The system software must be able to service multiple PME# signals that different functions generate simultaneously.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 8.4.1.
Test descriptions: TD-4.8 PME# Signal Routing - Simultaneous (PCIPME2) Test Description

4.16.15 The system software must be able to restore power to the primary PCI bus by first restoring it to the B0 state and then restoring it to any "unpowered" slots and devices.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 8.4.1.
Test descriptions: TD-4.7 PCI PME# Signal Routing Test (PCIPME1) and
TD-4.8 PME# Signal Routing - Simultaneous (PCIPME2) Test Description


PME # Signal Assertions Not Tested

The PCIPME1 and PCIPME2 tests do not cover the following aspects related to PCI power management events.

Note: Assertions labeled "Not Tested" may be tested in future tests.

4.17.1 The assertion and "deassertion" of PME# signal is asynchronous to the PCI clock.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.
Test description: NOT TESTED

4.17.2 The PME# signal is bused between all PCI connectors in a system.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.
Test description: NOT TESTED

4.17.3 Even if a particular PCI component’s Vcc inputs are not powered, voltage applied to the PME# network must never cause damage to that component.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.
Test description: NOT TESTED

4.17.4 The PME# input signal into the system may be "deasserted" as long as 100ns after the PME# output signal from the function is "deasserted."

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.
Test description: NOT TESTED

4.17.5 PCI to CardBus bridges require that the PME# signal must be routed through the bridge.

Reference document: PCI Bus Power Management1.1 Specification, Section 7.1.
Test description: NOT TESTED

4.17.6 All sources of the PME# signal must be interconnected so that they can be singly connected to the system.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.1.
Test description: NOT TESTED

4.17.7 System software maintains a table of PCI functions that have been enabled for PME# generation.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.1.
Test description: NOT TESTED

4.17.8 When the PME service routine starts, system software traverses to determine each PCI function that has requested a change in its power management state or that has experienced a PME.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.2.
Test description: NOT TESTED

4.17.9 Any function that supports a PME# signal from the D3 Cold state has "sticky" PME_Status and PME_En bits.

This means that power-on reset or transitions from the D3 Cold state to the Uninitialized D0 state do not affect their states.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 3.2.4.
Test description: NOT TESTED

4.17.10 For any function that supports a PME# signal from the D3 Cold state, the system software must explicitly initialize all PME contexts for all functions.

The PME_En bit must be written as value 0, and the PME_Status bit must be written as value 1.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 3.2.4.
Test description: NOT TESTED

4.17.11 The system hardware must be able to restore the host processor subsystem to a state that enables the system software to function.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 8.4.1.
Test description: NOT TESTED

4.17.12 The DC-operating voltage band for a 3.3Vaux-enabled system must range from 3.0V <= 3.3Vaux <= 3.6V.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 7.2.1.
Test description: NOT TESTED


3.3Vaux Auxiliary Power Assertions

The following 3.3Vaux auxiliary power assertions are tested by in TD-4.10 PCI 3.3 Volt Auxiliary Power Load (PCIVAUX) Test Description.

4.18.1 A 3.3Vaux power supply must be present whenever AC power is applied to the system.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.
Test description: TD-4.10 PCI 3.3 Volt Auxiliary Power Load (PCIVAUX) Test Description

4.18.2 If PCI systems implement 3.3Vaux auxiliary power, the power source must be connected to pin 14A of its PCI slot connectors.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.2.
Test description: TD-4.10 PCI 3.3 Volt Auxiliary Power Load (PCIVAUX) Test Description

4.18.3 Power-managed systems that support PME# generation while in D3 Cold state require an auxiliary power source.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.2.
Test description: TD-4.10 PCI 3.3 Volt Auxiliary Power Load (PCIVAUX) Test Description

4.18.4 When the PCI function is in D0, D1, D2, D3 Hot, or D3 Cold states with its PME_En bit set, the maximum 3.3Vaux current power requirement must be 375mA.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.2.1.
Test description: TD-4.10 PCI 3.3 Volt Auxiliary Power Load (PCIVAUX) Test Description

4.18.5 When the PCI function is in D3 Cold state with its PME_En bit set to value 0b, the maximum 3.3Vaux current power requirement must be 20mA.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.2.1.
Test description: TD-4.10 PCI 3.3 Volt Auxiliary Power Load (PCIVAUX) Test Description

4.18.6 If 3.3Vaux power is supported, it must be routed to all PCI slots on the motherboard.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.2.1.
Test description: TD-4.10 PCI 3.3 Volt Auxiliary Power Load (PCIVAUX) Test Description

4.18.7 When the bus is in B3 state, the minimum required 3.3Vaux current capacity for a system with four PCI slots must be 435mA.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.2.2.
Test description: TD-4.10 PCI 3.3 Volt Auxiliary Power Load (PCIVAUX) Test Description

4.18.8 When the bus is in B0, B1, or B2 state, the minimum required 3.3Vaux current capacity for a system with four PCI slots must be 1.5A.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.2.2.
Test description: TD-4.10 PCI 3.3 Volt Auxiliary Power Load (PCIVAUX) Test Description

4.18.9 When the PCI bus is in B3 state, systems that support 3.3Vaux auxiliary power must be capable of fully powering at least one 3.3Vaux-enabled PCI slot.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.2.2.
Test description: TD-4.10 PCI 3.3 Volt Auxiliary Power Load (PCIVAUX) Test Description

4.18.10 When the PCI bus is in B0, B1, or B2 state, systems supporting 3.3Vaux auxiliary power must be capable of fully powering all slots in the system.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.2.1.
Test description: TD-4.10 PCI 3.3 Volt Auxiliary Power Load (PCIVAUX) Test Description

4.18.11 System software controls which slots are enabled for PME# generation from the D3 Cold state.

This software usage must remain within the system’s auxiliary power budget.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.3.1.
Test description: TD-4.10 PCI 3.3 Volt Auxiliary Power Load (PCIVAUX) Test Description

4.18.12 The system must be capable of delivering up to 1.24W (375mA @ 3.3VDC) to each enabled PCI expansion slot.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.3.1.
Test description: TD-4.10 PCI 3.3 Volt Auxiliary Power Load (PCIVAUX) Test Description

4.18.13 The system must be capable of delivering up to 66mW (20mA @ 3.3VDC) to each disabled PCI expansion slot.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.3.1.
Test description: TD-4.10 PCI 3.3 Volt Auxiliary Power Load (PCIVAUX) Test Description

4.18.14 The load on the 3.3Vaux auxiliary power attributed to each 3.3Vaux-enabled PCI add-in card must not exceed 375mA, regardless of how many PCI functions are implemented by the PCI device.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.4.1.
Test description: TD-4.10 PCI 3.3 Volt Auxiliary Power Load (PCIVAUX) Test Description

4.18.15 When the PCI bus is in B0 state and the PCI function is in Uninitialized D0 state, the bus does not allow the PCI function to perform any actions on the device.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.6.
Test description: TD-4.10 PCI 3.3 Volt Auxiliary Power Load (PCIVAUX) Test Description

4.18.16 When the PCI bus is in B0 state and the PCI function is in D0 Active state, the PCI function must be capable of initiating any PCI transaction, PCI Interrupt, or, if PME is supported in the B0/D0 Active state, PME.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.6.
Test description: TD-4.10 PCI 3.3 Volt Auxiliary Power Load (PCIVAUX) Test Description

4.18.17 When the PCI bus is in B0 state and the PCI function is in D1 state, the PCI function’s action is device-class-specific.

The function can initiate a PME event, if PME is supported in the B0/D1 state.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.6.
Test description: TD-4.10 PCI 3.3 Volt Auxiliary Power Load (PCIVAUX) Test Description

4.18.18 When the PCI bus is in B0 state and the PCI function is in D2 state, the PCI function’s action is device-class-specific.

The function can only initiate PME events, if PME is supported in the B0/D2 state.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.6.
Test description: TD-4.10 PCI 3.3 Volt Auxiliary Power Load (PCIVAUX) Test Description

4.18.19 When the PCI bus is in B0 state and the PCI function is in D3 Hot state, the PCI function can only initiate PME events, if PME is supported in the B0/D0 Hot state.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.6.
Test description: TD-4.10 PCI 3.3 Volt Auxiliary Power Load (PCIVAUX) Test Description


3.3Vaux Auxiliary Power Assertions Not Tested

The following 3.3Vaux auxiliary power assertions are not tested by the PCIVAUX test.

Note: Assertions labeled "Not Tested" may be tested in future tests.

4.19.1 The system must provide an auxiliary power source for any system wake-up circuitry.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.3.1.
Test description: NOT TESTED

4.19.2 PCI functions in the D0, D1, D2, or D3 Hot state are unconditionally enabled to consume up to 1.24W via the 3.3Vaux power, even in dual-mode power sources.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.3.1.
Test description: NOT TESTED

4.19.3 When the system supports 3.3Vaux auxiliary power, each PCI connector pin 14A must read this support as the logical OR of a high- and low-capacity 3.3V source.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.3.1.
Test description: NOT TESTED

4.19.4 While the PCI bus is in B0, B1, or B2 state, all PCI add-in cards that connect to pin 14A and support D3 Cold functionality may draw up to 375mA through the 3.3Vaux auxiliary power.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.3.1.
Test description: NOT TESTED

4.19.5 Systems that support the 3.3Vaux auxiliary power must ensure that the PCI RST# signal remains asserted whenever the PCI bus is in B3 state.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.3.2.
Test description: NOT TESTED

4.19.6 Functions in D3 Cold state that are capable of generating a PME# signal from this state must be able to accept PCI bus cycles, including PCI configuration cycles, no later than 10 ms after the PCI RST# signal’s low-to-high transition.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 7.3.2.
Test description: NOT TESTED

4.19.7 PCI functions that awaken the system with power management events must take no longer than 10 ms to initialize themselves to where they can accept the PCI cycles that target them.

Reference document: WLP# - B2.5; PCI Bus Power Management1.1 Specification, Section 7.3.2.
Test description: NOT TESTED

4.19.8 The 3.3Vaux auxiliary power source must be independent of the PCI bus 3.3V and 5V voltage rails.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.3.3.
Test description: NOT TESTED

4.19.9 Only the PCI add-in cards that implement functions supporting the PME# signal from the D3 Cold state by design may physically connect to the 3.3Vaux pin 14A.

All other designs must exclude electrical contact with pin 14A and must allow for current to be drawn only from the main PCI bus voltage rails.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.4.2.
Test description: NOT TESTED

4.19.10 When a PCI add-in card is plugged into a system that supports the 3.3Vaux auxiliary power, the card must ensure that the 3.3Vaux auxiliary power is always electrically isolated from the main PCI 3.3V rails.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.4.3.
Test description: NOT TESTED

4.19.11 Before reporting its power support for a PME# signal from the D3 Cold state, a PCI add-in card that implements any function generating a power management event from the D3 Cold state must determine whether the 3.3Vaux power on pin 14A exists.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.4.4.
Test description: NOT TESTED

4.19.12 A PCI add-in card that implements any function generating a power management event from the D3 Cold state must be compatible with PCI systems that do not support 3.3Vaux auxiliary power.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.4.4.
Test description: NOT TESTED

4.19.13 Every PCI add-in card must be implemented with a weak pulldown attached to pin 14A.

This creates a logical low-reference when the card is plugged into a motherboard that does not support the delivery of 3.3Vaux auxiliary power.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 7.4.4.
Test description: NOT TESTED

4.19.14 When the PCI bus is in B3 state and the PCI function is in legacy PCI D3 state, the PCI function is not allowed to perform any actions.

Reference document: WLP# - B2.5; PCI Bus Power Management 1.1 Specification, Section 5.6.
Test description: NOT TESTED


PCI Voltage Requirement Assertions Tested

PCI voltage requirement assertions are tested in TD-4.6 PCI Voltage Requirement Test (PCIVOLT).

4.20.1 If a PCI-based system supports one or more PCI connectors, it must provide 3.3V power to all connectors.

Reference documents: PCI Bus Power Management Interface Specification, Revision 1.1, Section 7.2 and 7.3; WLP#-B2.5.4.1; PC 2001 System Design Guide - PCI-0123; PC 99 System Design Guide.
Test description: TD-4.6 PCI Voltage Requirement Test (PCIVOLT)

4.20.2 The PCI-based system must regulate the 3.3V power within the 3.0V-3.6V band.

Reference documents: PCI Bus Power Management Interface Specification, Revision 1.1, Section 7.2 and 7.3; WLP#-B2.5.4.1; PC 2001 System Design Guide - PCI-0123; PC 99 System Design Guide.
Test description: TD-4.6 PCI Voltage Requirement Test (PCIVOLT)

4.20.3 If 3.3Vaux power is supported, system must route this power to all PCI connectors on the motherboard.

Reference documents: PCI Bus Power Management Interface Specification, Revision 1.1, Section 7.2 and 7.3; WLP#-B2.5.4.1; PC 2001 System Design Guide - PCI-0123; PC 99 System Design Guide.
Test description: TD-4.6 PCI Voltage Requirement Test (PCIVOLT)

4.20.4 If PCI systems implement 3.3Vaux power, the 3.3Vaux auxiliary power must be connected to pin 14A of its PCI connectors.

Reference documents: PCI Bus Power Management Interface Specification, Revision 1.1, Section 7.2 and 7.3; WLP#-B2.5.4.1; PC 2001 System Design Guide - PCI-0123; PC 99 System Design Guide.
Test description: TD-4.6 PCI Voltage Requirement Test (PCIVOLT)

4.20.5 The 3.3Vaux power supply must be present whenever AC power is applied to the system.

Reference documents: PCI Bus Power Management Interface Specification, Revision 1.1, Section 7.2 and 7.3; WLP#-B2.5.4.1; PC 2001 System Design Guide - PCI-0123; PC 99 System Design Guide.
Test description: TD-4.6 PCI Voltage Requirement Test (PCIVOLT)

4.20.6 The DC operating voltage band for a 3.3Vaux-enabled system must range from 3.0V-3.6V.

Reference document: WLP#-B2.5.4.1; PCI Bus Power Management Interface Specification, Revision 1.1, Section 7.2 and 7.3; PC 2001 System Design Guide - PCI-0123; PC 99 System Design Guide.
Test description: TD-4.6 PCI Voltage Requirement Test (PCIVOLT)

4.20.7 All PCI-based systems must provide 5V power to all PCI connectors.

Reference documents: PCI Bus Power Management Interface Specification, Revision 1.1, Section 7.2 and 7.3; WLP#-B2.5.4.1; PC 2001 System Design Guide - PCI-0123; PC 99 System Design Guide.
Test description: TD-4.6 PCI Voltage Requirement Test (PCIVOLT)


System BIOS Initialization Requirement Assertions

Requirement assertions for system BIOS initialization are tested in TD-4.11 PCI System BIOS Initialization Requirement Test (BIOSINIT).

4.21.1 During a power-on situation, the system BIOS must mask off the PME# signal through whatever system-specific method is available.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 8.8.
Test description: TD-4.11 PCI System BIOS Initialization Requirement Test (BIOSINIT)

4.21.2 During a warm-boot ([Ctrl+Alt+Del]) sequence, the system BIOS must mask off PME# events until the PME# event handler loads.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 8.8.
Test description: TD-4.11 PCI System BIOS Initialization Requirement Test (BIOSINIT)

4.21.3 If a PCI power-managed function is programmed so that both PME_Status and PME_En bits are set to a value of 1b during system power-up, the system BIOS must clear PME_En and PME_Status bit in its POST routines.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 8.8.
Test description: TD-4.11 PCI System BIOS Initialization Requirement Test (BIOSINIT)

4.21.4 During a warm-boot ([Ctrl+Alt+Del]) sequence, the system BIOS must restore all PCI power-managed functions to D0 state.

Reference document: WLP# - B2.5; PCI Bus Power Management Interface Specification, Revision 1.1, Section 8.8.
Test description: TD-4.11 PCI System BIOS Initialization Requirement Test (BIOSINIT)


PCI D3 Graphics Adapter Assertions

The following PCI D3 graphics adapter assertions are tested by tests described in TD-4.13 PCI D3 Graphics Adapter Basic Compliance Test and TD-4.15 PCI-D3 Graphics Adapter Functionality Test Under Windows 2000.

4.22.1 Graphics adapter devices and drivers must support the D0 and D3 power states consistent with the definitions in the relevant device class power management specification and the Default Device Class Power Management Specification, Version 1.0 or later.

Reference documents: WLP# -B4.1.4.12; PC 2001 System Design Guide - SYS-0003.4, PC 99 System Design Guide - 3.3.4; Default Device Class Power Management Specification, Version 1.0 or later.
Test description: TD-4.13 PCI D3 Graphics Adapter Basic Compliance Test

4.22.2 Graphics adapters must comply with the Display Device Class Power Management Reference Specification, Version 1.0 or later, which provides definitions of the OnNow device power states (D0-D3) for display and graphics devices.

The specification also covers device functionality expected in each power state and the possible wake-up event definitions for the class, if any. Power states D0 and D3 are required; D1 and D2 are optional for graphics adapters.

Reference documents: WLP# -B4.1.4.12; PC 2001 System Design Guide - GRPH-0203, PC 99 System Design Guide - 14.54; Default Device Class Power Management Specification, Version 1.0 or later.
Test descriptions: TD-4.14 PCI-D3 Graphics Adapter Functionality Test Under Windows and TD-4.15 PCI-D3 Graphics Adapter Functionality Test Under Windows 2000


PCI D3 Modem Assertions

The following PCI D3 modem assertions are tested by tests described in TD-4.16 PCI D3 Modem Basic Compliance Test and Modem tests TD-4.17, TD-4.18, TD-4.19, and TD-4.20.

4.23.1 Modem D3 devices and drivers must support the D0 and D3 power states consistent with the definitions in the relevant device class power management specification and the Default Device Class Power Management Specification, Version 1.0 or later.

Reference documents: WLP# -B1.4.5; PC 2001 System Design Guide - SYS-0003.4; PC 99 System Design Guide - 3.3.4; Default Device Class Power Management Specification, Version 1.0 or later.
Test description: TD-4.16 PCI D3 Modem Basic Compliance Test

4.23.2 Modem Device and System Power states D0 and D3 are required for modems on power-managed buses, including PCI, CardBus, and USB.

Modem adapters that use the PCI bus must be capable of generating a power management event (PME# assertion) from the D3 cold device state.

Reference document: WLP#-B6.1.5.9; B1.4.5; PC 2001 System Design Guide - MOD-0381, PC 99 System Design Guide - 19.38.
Test descriptions: Modem tests TD-4.17, TD-4.18, TD-4.19, and TD-4.20


PCI D3 Network Device Assertions

The following PCI D3 network device assertions are tested in TD-4.21 PCI D3 Network Device Basic Compliance Test and Network device tests TD-4.22, TD-4.23, TD-4.24, and TD-4.25.

4.24.1 Network devices and drivers must support the D0 and D3 power states consistent with the definitions in the relevant device class power management specification and the Default Device Class Power Management Specification, Version 1.0 or later.

Reference documents: WLP# -B1.4.5; PC 2001 System Design Guide - SYS-0003.4, PC 99 System Design Guide- 3.3.4; Default Device Class Power Management Specification, Version 1.0 or later.
Test description: TD-4.21 PCI D3 Network Device Basic Compliance Test

4.24.2 PCI-based network adapters must support the generation of a power management event (PME# assertion) from the D3 cold device state, if the physical layer technology is generally capable of operating under the voltage and current constraints of the D3 cold device state.

Reference documents: WLP# -B1.4.5; PC 2001 System Design Guide - 20.56; PC 99 System Design Guide - 20.56.
Test descriptions: Network device tests TD-4.22, TD-4.23, TD-4.24, and TD-4.25


PCI D3 Audio Device Assertions

The following audio device assertions are tested in TD-16.2 Audio Power Management Test (Lullaby)

4.25.1 Audio devices and drivers must support the D0 and D3 power states consistent with the definitions in the relevant device class power management specification and the Default Device Class Power Management Specification, Version 1.0 or later.

Reference documents: WLP# -B1.4.5; PC 2001 System Design Guide - SYS-0003.4, PC 99 System Design Guide - 3.3.4; Default Device Class Power Management Specification, Version 1.0 or later.
Test description: TD-16.2 Audio Power Management Test (Lullaby)

4.25.2 Audio devices must comply with Audio Device Class Power Management Reference Specification, Version 1.0 or later, which provides definitions of the OnNow device power states (D0-D3) for these devices.

The specification also covers the device functionality expected in each power state and the possible wake-up event definitions for the class. The device and driver are required to implement support for power states D0, D2, and D3. Other power states are optional.

Reference documents: WLP# -B1.4.5; B3.1.5.7; PC 2001 System Design Guide - AUD-0336, PC 99 System Design Guide - 17.29; Audio Device Class Power Management Reference Specification, Version 1.0 or later.
Test description: TD-16.2 Audio Power Management Test (Lullaby)


PCI Configuration Space Header Assertions

These assertions are tested in TD-4.29 PCI 2.2 Compliance (PCITest) Test Description.

General Assertions

4.26.1 The device must use a valid header type.

Reference Documents: PCI Local Bus Specification 2.2 Section 6.2.1.
Test Description: TD-4.29 PCI 2.2 Compliance (PCITest) Test Description

4.26.2 Some bytes at the given offset should be read only. See PCI 2.2 Specification sections 6.1 through 6.2.5.2 for further clarification.

Reference Documents: PCI Local Bus Specification 2.2 Sections 6.1 - 6.2.5.2
Test Description: TD-4.29 PCI 2.2 Compliance (PCITest) Test Description

Interrupt Setting Assertions

4.27.1 The Interrupt Pin register tells which interrupt pin the device (or device function uses).

A value of 1 corresponds to INTA#, 2 to INTB#, 3 to INTC#, and 4 to INTD#. Devices that do not use an interrupt must put a 0 in this register. The values 05h through FFh are reserved.

Reference Documents: WLP# - B2.5; PCI 2.2 Specification section 6.2.4.
Test Description: TD-4.29 PCI 2.2 Compliance (PCITest) Test Description

4.27.2 For x86 based PCs, the values in the Interrupt Line Register correspond to IRQ numbers 0-15(00h-0Fh).

Values between 15 (0Fh) and 254 (FEh) are reserved.

Reference Documents: WLP# - B2.5; PCI Local Bus Specification 2.2 Section 6.2.4 (see footnote #43).
Test Description: TD-4.29 PCI 2.2 Compliance (PCITest) Test Description

Vendor ID / Device ID / Subsystem Vendor ID / Subsystem Device ID assertions

4.29.1 Support for the Subsystem Device ID and Subsystem Vendor ID registers requires nonzero values to be populated for both of these registers.

Reference Documents: PC 2001 System Design Guide, Section, PCI-0126, PC 99 System Design Guide, ECN Section 9.11.
Test Description: TD-4.29 PCI 2.2 Compliance (PCITest) Test Description

4.29.2 Each subsystem ID register must be Read Only.

Reference Documents: PC 2001 System Design Guide - PCI-0126, PC 99 System Design Guide - Section 9.11.
Test Description: TD-4.29 PCI 2.2 Compliance (PCITest) Test Description


PCI Base Address Register Assertions

These assertions are tested in TD-4.29 PCI 2.2 Compliance (PCITest) Test Description.

I/O Base Address Register Assertions

4.30.1 For I/O Base Address Registers, bit 1 is reserved and must return 0.

Reference Documents: WLP# - B2.5; PCI Local Bus Specification 2.2 Section 6.2.5.1
Test Description: TD-4.29 PCI 2.2 Compliance (PCITest) Test Description

4.30.2 Devices that map control functions into I/O space must not consume more than 256 bytes per I/O Base Address Register.

Reference Documents: WLP# - B2.5; PCI Local Bus Specification 2.2 Section 6.2.5.1
Test Description: TD-4.29 PCI 2.2 Compliance (PCITest) Test Description

Memory Base Address Register Assertions

4.31.1 The PCI memory range specified for this BAR is invalid if the ending address is smaller than the beginning address.

Reference Documents: WLP# - B2.5; PCI Local Bus Specification 2.2 Section 6.2.5.1
Test Description: TD-4.29 PCI 2.2 Compliance (PCITest) Test Description

4.31.2 The memory Range specified for this BAR is invalid if it has specified the ending address to be the same as the beginning address, thus specifying a range of 0 bytes.

Reference Documents: WLP# - B2.5; PCI Local Bus Specification 2.2 Section 6.2.5.1
Test Description: TD-4.29 PCI 2.2 Compliance (PCITest) Test Description

PCI IDE Specific Assertions

4.32.1 If the Primary IDE channel is set to support switching between native and compatibility modes (i.e., bit 1 is set), then the bit 0 of the low byte (Programming Interface) of the Class Code field, which is used to change modes, must be writeable.

Reference Documents: WLP# - B2.5; PCI IDE Specification 1.0 Section 2.3.
Test Description: TD-4.29 PCI 2.2 Compliance (PCITest) Test Description

4.32.2 If the Primary IDE channel is not set to support switching between native and compatibility modes (i.e., bit 1 is reset), then the bit 0 of the low byte (Programming Interface) of the Class Code field, which is used to change modes, must be read only.

Reference Documents: WLP# - B2.5; PCI IDE Specification 1.0 Section 2.3.
Test Description: TD-4.29 PCI 2.2 Compliance (PCITest) Test Description

4.32.3 If the Secondary IDE channel is set to support switching between native and compatibility modes (i.e., bit 3 is set), then the bit 2 of the low byte (Programming Interface) of the Class Code field, which is used to change modes, must be writeable.

Reference Documents: WLP# - B2.5; PCI IDE Specification 1.0 Section 2.3.
Test Description: TD-4.29 PCI 2.2 Compliance (PCITest) Test Description

4.32.4 If the Secondary IDE channel is not set to support switching between native and compatibility modes (i.e., bit 3 is reset), then the bit 2 of the low byte (Programming Interface) of the Class Code field, which is used to change modes, must be read only.

Reference Documents: WLP# - B2.5; PCI IDE Specification 1.0 Section 2.3.
Test Description: TD-4.29 PCI 2.2 Compliance (PCITest) Test Description


PCI Power Management Register Assertions

These assertions are tested in TD-4.29 PCI 2.2 Compliance (PCITest) Test Description.

Capability Pointer Assertions

4.33.1 The value returned from the Device Capability Identifier must be a SIG assigned ID code.

Reference Documents: WLP# - B2.5; PCI Local Bus Specification 2.2 Appendix H.
Test Description: TD-4.29 PCI 2.2 Compliance (PCITest) Test Description

4.33.2 Each Capability Pointer in the Capabilities list must be DWORD aligned.

Reference Documents: WLP# - B2.5; PCI Local Bus Specification 2.2 Section 6.7
Test Description: TD-4.29 PCI 2.2 Compliance (PCITest) Test Description

4.33.3 The Device Capabilities pointer must not point to the first 40 bytes of PCI configuration space, which is reserved for the header, and must allow for at least 8 bytes at the end of configuration space (the Capability structure is 8 bytes long).

Reference Documents: WLP# - B2.5; PCI Power Management Specification 1.1 Section 3.1
Test Description: TD-4.29 PCI 2.2 Compliance (PCITest) Test Description

Power Management Control Block Assertions

4.34.1 There must be valid version information in the Power Management Capabilities register (bits 2:0). This device must support the PCI-PM 1.1.

Reference Documents: WLP# - B2.5; PCI Power Management Specification 1.1 Section 3.2.3
Test Description: TD-4.29 PCI 2.2 Compliance (PCITest) Test Description

4.34.2 The Power Management register block defined for this device must match the Power Management Register Block Definition defined in section 3.2 of the PCI-PM 1.1.

Reference Documents: WLP# - B2.5; PCI Power Management Interface Specification 1.1 section 3.2
Test Description: TD-4.29 PCI 2.2 Compliance (PCITest) Test Description

4.34.3 The 16-bit Power Management Capabilities register must be Read Only.

Reference Documents: WLP# - B2.5; PCI Power Management Specification 1.1 Section 3.2.3.
Test Description: TD-4.29 PCI 2.2 Compliance (PCITest) Test Description

4.34.4 Bits 08:06 in the Power Management capabilities structure are set to something other than 000b, but D3(cold) is not supported by this device. If D3 cold is not supported, this field must return 000b.

Reference Documents: WLP# - B2.5; PCI Power Management Specification 1.1 Section 3.2.3.
Test Description: TD-4.29 PCI 2.2 Compliance (PCITest) Test Description

4.34.5 The device does not support Vaux capabilities, but has bits 08:06 in the Power Management Capabilities Register set to something other than 000b. These must be set to 000b if the device does not support Vaux.

Reference Documents: WLP# - B2.5; PCI Power Management Specification 1.1, Section 3.2.3.
Test Description: TD-4.29 PCI 2.2 Compliance (PCITest) Test Description

4.34.6 If, for any reason, the operating system software attempts to put a function into a power management state that the function does not support, the function should handle this gracefully and remain in whatever state it was in before the request.

The PowerState bits for the PMSCR will reflect the current state of the function, not the intended invalid state that was written.

Reference Documents: WLP# - B2.5; PCI Power Management Specification 1.1 section 8.1.
Test Description: TD-4.29 PCI 2.2 Compliance (PCITest) Test Description

4.34.7 The device has bit 0 of the Command Register (I/O enable) set, but it is read only.

Reference Documents: WLP# - B2.5; PCI Local Bus Specification 2.2 section 6.2.2.
Test Description: TD-4.29 PCI 2.2 Compliance (PCITest) Test Description

4.34.8 The device has bit 1 of the Command Register (Memory Enable) set, but it is read only.

Reference Documents: WLP# - B2.5; PCI Local Bus Specification 2.2 section 6.3.3.
Test Description: TD-4.29 PCI 2.2 Compliance (PCITest) Test Description

4.34.9 Bits 15:11 of the Power Management Capabilities register are set, indicating that the device supports #PME.

However, bits 02:00 (Version Information) are not set to 10b, which indicates that the device supports Revision 1.1 of the PCI Power Management Interface Specification.

Reference Documents: WLP# - B2.5; PCI Power Management Specification 1.1, Section 3.2.3.
Test Description: TD-4.29 PCI 2.2 Compliance (PCITest) Test Description

4.34.10 Bit 15 in the Power Management Capabilities register was not Read Only.

Reference Documents: WLP# - B2.5; PCI Power Management Specification 1.1, Section 3.2.3.
Test Description: TD-4.29 PCI 2.2 Compliance (PCITest) Test Description

4.34.11 The indicated bits in the Power Management Control Block were not read only.

Reference Documents: WLP# - B2.5; PCI Power Management Specification 1.1, Section 3.2.3.
Test Description: TD-4.29 PCI 2.2 Compliance (PCITest) Test Description


PCI Compliance Test Assertions

The PCI compliance test assertions listed in this section include the following:

Common Configuration Space Assertions

Power Management Assertions

PCI-to-PCI Bridge Specific Register Assertions


Common Configuration Space Assertions

The following common configuration space assertions are tested in the TD-4.50 PCI Compliance Test.

Header Type Assertions

VendorID/DeviceID/SubsystemID/RevisionID Assertions

Interrupt Pin/ Interrupt Line Assertions

Command Register Assertions

Status Register Assertions

Class Code Assertions

Capability Pointer Assertions

Base Address Register (BAR) Assertions

Header Type Assertions

4.50.1 The Header Type field must be read only.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification, Revision 2.2, Sections 6.1  6.2.5.2
Test Description: TD-4.50 PCI Compliance Test Description

4.50.2 Invalid Header Type.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification, Revision 2.2, Section 6.2.1.
Test Description: TD-4.50 PCI Compliance Test Description

4.50.3 Devices implementing a single function header type must not expose additional functions when queried.

If function 0 of a PCI device has a header type indicating single function (the multi-function bit in the Header Type field is not set), configuration cycles reads for all other function numbers for the device must respond in one of the following manners:

  1. Vendor ID is 0xFFFF and Device ID is 0xFFFF
  2. Vendor ID is 0x0000 and Device ID is 0x0000
  3. Returns an entire configuration space region that is exactly the same as function 0.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification, Revision 2.2, Section 6.2.1.
Test Description: TD-4.50 PCI Compliance Test Description

VendorID/DeviceID/SubsystemID/RevisionID Assertions

4.51.1 The Vendor ID field must not contain an invalid (0 or FFFF) value.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification, Revision 2.2, Section 6.2.1; PC 2001 System Design Guide - PCI-0126, PC 99 System Design Guide - 9.11.
Test Description: TD-4.50 PCI Compliance Test Description

4.51.2 The Vendor ID field must be read only.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification, Revision 2.2, Section 6.2.1; PC 2001 System Design Guide - PCI-0126, PC 99 System Design Guide - 9.11.
Test Description: TD-4.50 PCI Compliance Test Description

4.51.3 The Device ID field must be read only.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification, Revision 2.2, Section 6.2.1; PC 2001 System Design Guide - PCI-0126, PC 99 System Design Guide - 9.11.
Test Description: TD-4.50 PCI Compliance Test Description

4.51.4 The Subsystem Vendor ID field must not contain an invalid (0 or FFFF) value.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification, Revision 2.2, Section 6.2.1; PC 2001 System Design Guide - PCI-0126, PC 99 System Design Guide - 9.11.
Test Description: TD-4.50 PCI Compliance Test Description

4.51.5 The Subsystem Vendor ID field must be read only.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification, Revision 2.2, Section 6.2.1; PC 2001 System Design Guide - PCI-0126, PC 99 System Design Guide - 9.11.
Test Description: TD-4.50 PCI Compliance Test Description

4.51.6 The Subsystem ID field must be read only.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification, Revision 2.2, Section 6.2.1; PC 2001 System Design Guide - PCI-0126, PC 99 System Design Guide - 9.11.
Test Description: TD-4.50 PCI Compliance Test Description

4.51.7 The Revision ID field must be read only.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification, Revision 2.2, Section 6.2.1; PC 2001 System Design Guide - PCI-0126, PC 99 System Design Guide - 9.11.
Test Description: TD-4.50 PCI Compliance Test Description

Interrupt Pin/ Interrupt Line Assertions

4.52.1 The Interrupt Pin field contains an invalid (Greater than 4) value.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Section 6.2.4.
Test Description: TD-4.50 PCI Compliance Test Description

4.52.2 The Interrupt Pin field must be read only.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Section 6.2.4.
Test Description: TD-4.50 PCI Compliance Test Description

4.52.3 If the device uses an interrupt, the Interrupt Line field must be implemented as read/write.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Section 6.2.4.
Test Description: TD-4.50 PCI Compliance Test Description

4.52.4 If the device does not use an interrupt, the Interrupt Line field must always return 0.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Section 6.2.4.
Test Description: TD-4.50 PCI Compliance Test Description

Command Register Assertions

4.53.1 If the IO Space Enable bit in the Command Register is implemented, it must be read/write.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Section 6.2.2.
Test Description: TD-4.50 PCI Compliance Test Description

4.53.2 If the Memory Space Enable bit in the Command Register is implemented, it must be read/write.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Section 6.2.2.
Test Description: TD-4.50 PCI Compliance Test Description

4.53.3 If the Bus Master Enable bit in the Command Register is implemented, it must be read/write.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Section 6.2.2.
Test Description: TD-4.50 PCI Compliance Test Description

4.53.4 The reserved bits in the Command Register (bits 15:10) must always return 0.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Section 6.2.2.
Test Description: TD-4.50 PCI Compliance Test Description

4.53.5 If the device supports an interrupt, the Interrupt Disable bit in the Command Register must be read/write.

This assertion will be enforced beginning 1 January 2004.

The assertion tests compliance with the PCI Local Bus Specification, Revision 2.3. Systems can incorporate devices individually logo'd before that date, but no new device (or systems incorporating one) will receive a logo after that date unless they are PCI 2.3 compliant.

Reference Documents: WLP# - B2.5; PCI Local Bus Specification Revision 2.3.
Test Description: TD-4.50 PCI Compliance Test Description

Status Register Assertions

4.54.1 The New Capabilities bit in the Status Register must be read only.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Section 6.2.3.
Test Description: TD-4.50 PCI Compliance Test Description

4.54.2 The 66MHZ Capable bit in the Status Register must be read only.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Section 6.2.2.
Test Description: TD-4.50 PCI Compliance Test Description

4.54.3 The Fast Back To Back bit in the Status Register must be read only.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Section 6.2.2.
Test Description: TD-4.50 PCI Compliance Test Description

4.54.4 The DevSel# bits in the Status Register must be read only.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Section 6.2.2.
Test Description: TD-4.50 PCI Compliance Test Description

Class Code Assertions

4.55.1 The Base Class in the Class Code register must be read only.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Section 6.2.1, Appendix D.
Test Description: TD-4.50 PCI Compliance Test Description

4.55.2 The SubClass in the Class Code register must be read only.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Section 6.2.1, Appendix D.
Test Description: TD-4.50 PCI Compliance Test Description

4.55.3 The Programming Interface in the Class Code register must be read only.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Section 6.2.1, Appendix D.
Test Description: TD-4.50 PCI Compliance Test Description

4.55.4 If the primary channel of a PCI IDE controller supports dual operation mode, the first bit of the Programming Interface must be read/write.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Section 6.2.1, Appendix D.
Test Description: TD-4.50 PCI Compliance Test Description

4.55.5 If the primary channel of a PCI IDE controller supports only single operation mode, the first bit of the Programming Interface must be read only.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Section 6.2.1, Appendix D.
Test Description: TD-4.50 PCI Compliance Test Description

4.55.6 If the secondary channel of a PCI IDE controller supports dual operation mode, the first bit of the Programming Interface must be read/write.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Section 6.2.1, Appendix D.
Test Description: TD-4.50 PCI Compliance Test Description

4.55.7 If the secondary channel of a PCI IDE controller supports only single operation mode, the first bit of the Programming Interface must be read only.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Section 6.2.1, Appendix D.
Test Description: TD-4.50 PCI Compliance Test Description

Capability Pointer Assertions

4.56.1 If the device implements a capability pointer, the Capabilities List bit (bit 4) in the Status Register must be set.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Sections 6.2.3 and 6.7, Appendix H.
Test Description: TD-4.50 PCI Compliance Test Description

4.56.2 The capability pointer must point to a valid area of configuration space.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Sections 6.2.3 and 6.7, Appendix H.
Test Description: TD-4.50 PCI Compliance Test Description

4.56.3 The new capability must be at an offset that is DWORD aligned.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Sections 6.2.3 and 6.7, Appendix H.
Test Description: TD-4.50 PCI Compliance Test Description

4.56.4 The value of the capability ID must be one approved by the PCI SIG.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Sections 6.2.3 and 6.7, Appendix H.
Test Description: TD-4.50 PCI Compliance Test Description

4.56.5 There cannot be multiple capability pointers with the same Capability ID.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Sections 6.2.3 and 6.7, Appendix H.
Test Description: TD-4.50 PCI Compliance Test Description

4.56.6 The Next Capability pointer cannot point to a previous capability.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Sections 6.2.3 and 6.7, Appendix H.
Test Description: TD-4.50 PCI Compliance Test Description

Base Address Register (BAR) Assertions

4.57.1 Base Address registers may not consume more than 256 bytes of I/O space.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Section 6.2.5.1
Test Description: TD-4.50 PCI Compliance Test Description

4.57.2 Bit 0 in any BAR must always be read only.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Section 6.2.5.1
Test Description: TD-4.50 PCI Compliance Test Description

4.57.3 I/O BARs must implement bit 1 as read only, and always return a 0 value.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Section 6.2.5.1
Test Description: TD-4.50 PCI Compliance Test Description

4.57.4 All read/write bits in a BAR must be consecutive.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Section 6.2.5.1
Test Description: TD-4.50 PCI Compliance Test Description

4.57.5 Memory BARs must implement bit 1 as read only.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Section 6.2.5.1
Test Description: TD-4.50 PCI Compliance Test Description

4.57.6 Memory BARs must implement bit 2 as read only.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Section 6.2.5.1
Test Description: TD-4.50 PCI Compliance Test Description

4.57.7 Memory BARs cannot have both bits 1 and 2 set. This is a reserved value.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Section 6.2.5.1
Test Description: TD-4.50 PCI Compliance Test Description

4.57.8 20-bit Memory BARs are not allowed on PCI 2.2 Compliant Devices.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Section 6.2.5.1
Test Description: TD-4.50 PCI Compliance Test Description

4.57.9 Bit 3 on memory bars must be read only.

Reference Documents: WLP# - B2.5.1.7; PCI Local Bus Specification Revision 2.2, Section 6.2.5.1
Test Description: TD-4.50 PCI Compliance Test Description


Power Management Assertions

The following power management assertions are tested in the TD-4.50 PCI Compliance Test.

  • Power Management Capabilities (PMC)
  • PMCSR
  • PMCSR_BSE
  • Data Register
  • Power State Transition

PMC Assertions

4.58.1 The PMC Block must be read only.

Reference document: WLP# - B2.5.2.1; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.3.
Test description: TD-4.50 PCI Compliance Test

4.58.2 Bit 4 in the PMC Block is reserved and must return 0.

Reference document: WLP# - B2.5.2.1; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.3.
Test description: TD-4.50 PCI Compliance Test

4.58.3 This Device must support PCI Power Management Specification revision 1.1.

Reference document: WLP# - B2.5.2.1; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.3.
Test description: TD-4.50 PCI Compliance Test

4.58.4 [Deleted]
4.58.5 [Deleted]

PMCSR Assertions

4.59.1 Bits 07:02 in the PMCSR are reserved and must always return 0.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-4.50 PCI Compliance Test Description

4.59.2 If PME# from D3 Cold is not supported, the PME_Status bit in PMCSR must default to 0.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-4.50 PCI Compliance Test Description

4.59.3 If PME# from D3 Cold is not supported, the PME_En bit in the PMCSR must default to 0.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-4.50 PCI Compliance Test Description

PMCSR_BSE Assertions

4.60.1 The PMCSR_BSE must be read only.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.5.
Test description: TD-4.50 PCI Compliance Test Description

4.60.2 The Reserved field in the PMCSR_BSE (bits 5:0) is reserved and must always return 0.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.5.
Test description: TD-4.50 PCI Compliance Test Description

Data Register Assertions

4.61.1 The Data register of the PCI Power Management Capability must be read only.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.6.
Test description: TD-4.50 PCI Compliance Test Description

4.61.2 If the Data register is implemented, the Data_Select field must be read/write.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1 Section 3.2.6.
Test description: TD-4.50 PCI Compliance Test Description

4.61.3 If the Data register is implemented, the Data_Scale field in the PMCSR must also be implemented.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.6.
Test description: TD-4.50 PCI Compliance Test Description

4.61.4 If the Data Register is not implemented, the Data_Scale field in the PMCSR must always return 0.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.6.
Test description: TD-4.50 PCI Compliance Test Description

4.61.5 If the Data Register is not implemented, the Data_Select field in the PMCSR must always return 0.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.6.
Test description: TD-4.50 PCI Compliance Test Description

Power State Transition Assertions

4.62.1 If the PMC claims D1 support (bit 9), the PowerState field of the PMCSR must retain a D1 value (01b) when written.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-4.50 PCI Compliance Test

4.62.2 If the PMC claims D2 support (bit 10), the PowerState field of the PMCSR must retain a D2 value (10b) when written.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-4.50 PCI Compliance Test

4.62.3 The PowerState field of the PMCSR must retain a D3 value (11b) when written.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-4.50 PCI Compliance Test

4.62.4 The Device ID must be read only and must not change when the device is placed in a D3 state.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-4.50 PCI Compliance Test

4.62.5 The Vendor ID must be read only and must not change when the device is placed in a D3 state.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-4.50 PCI Compliance Test

4.62.6 The Subsystem ID must be read only and must not change when the device is placed in a D3 state.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-4.50 PCI Compliance Test

4.62.7 The Subsystem Vendor ID must be read only and must not change when the device is placed in a D3 state.

Reference document: WLP# - B2.5.2; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-4.50 PCI Compliance Test


PCI-to-PCI Bridge Specific Register Assertions

The following PCI-to-PCI bridge assertions are tested in the TD-4.50 PCI Compliance Test.

4.63.1 The Primary Bus Number Register for a PCI to PCI bridge must be read/write.

Reference document: WLP# - B2.5.2.4; PCI-to-PCI Bridge Architecture Specification, Revision 1.1, Section 3.2.5.2.
Test description: TD-4.50 PCI Compliance Test

4.63.2 The Secondary Bus Number Register for a PCI to PCI bridge must be read/write.

Reference document: WLP# - B2.5.2.4; PCI-to-PCI Bridge Architecture Specification, Revision 1.1, Section 3.2.5.3.
Test description: TD-4.50 PCI Compliance Test

4.63.3 The Subordinate Bus Number Register for a PCI to PCI bridge must be read/write.

Reference document: WLP# - B2.5.2.4; PCI-to-PCI Bridge Architecture Specification, Revision 1.1, Section 3.2.4.
Test description: TD-4.50 PCI Compliance Test

4.63.4 Bits 4:0 in the Secondary Status Register must be read only and always return 0.

Reference document: WLP# - B2.5.2.4; PCI-to-PCI Bridge Architecture Specification, Revision 1.1, Section 3.2.5.7.
Test description: TD-4.50 PCI Compliance Test

4.63.5 The Fast Back To Back bit in the Secondary Status Register must be read only.

Reference document: WLP# - B2.5.2.4; PCI-to-PCI Bridge Architecture Specification, Revision 1.1, Section 3.2.5.7.
Test description: TD-4.50 PCI Compliance Test

4.63.6 The DevSel# bits in the Secondary Status Register must be read only.

Reference document: WLP# - B2.5.2.4; PCI-to-PCI Bridge Architecture Specification, Revision 1.1, Section 3.2.5.7.
Test description: TD-4.50 PCI Compliance Test

4.63.7 The I/O Base and I/O Limit registers must both indicate the same value for either 16 or 32-bit I/O address support.

Reference document: WLP# - B2.5.2.4; PCI-to-PCI Bridge Architecture Specification, Revision 1.1, Section 3.2.5.6.
Test description: TD-4.50 PCI Compliance Test

4.63.8 If 32-bit I/O Addressing is supported, the I/O Base Upper 16 Bits Register must be read/write.

Reference document: WLP# - B2.5.2.4; PCI-to-PCI Bridge Architecture Specification, Revision 1.1, Section 3.2.5.6.
Test description: TD-4.50 PCI Compliance Test

4.63.9 If 32-bit I/O Addressing is supported, the I/O Limit Upper 16 Bits Register must be read/write.

Reference document: WLP# - B2.5.2.4; PCI-to-PCI Bridge Architecture Specification, Revision 1.1, Section 3.2.5.6.
Test description: TD-4.50 PCI Compliance Test

4.63.10 The I/O Base and I/O Limit registers must both indicate the same value for either 16- or 32-bit IO address support.

Reference document: WLP# - B2.5.2.4; PCI-to-PCI Bridge Architecture Specification, Revision 1.1, Section 3.2.5.6.
Test description: TD-4.50 PCI Compliance Test

4.63.11 If 32-bit I/O Addressing is not supported, the I/O Base Upper 16 Bits Register must be read only and always return 0.

Reference document: WLP# - B2.5.2.4; PCI-to-PCI Bridge Architecture Specification, Revision 1.1, Section 3.2.5.6.
Test description: TD-4.50 PCI Compliance Test

4.63.12 If 32-bit I/O Addressing is not supported, the I/O Limit Upper 16 Bits Register must be read only and always return 0.

Reference document: WLP# - B2.5.2.4; PCI-to-PCI Bridge Architecture Specification, Revision 1.1, Section 3.2.5.6.
Test description: TD-4.50 PCI Compliance Test

4.63.13 Bits 3:0 in the Memory Base register for a PCI Bridge must be read only and always return 0.

Reference document: WLP# - B2.5.2.4; PCI-to-PCI Bridge Architecture Specification, Revision 1.1, Section 3.2.5.6.
Test description: TD-4.50 PCI Compliance Test

4.63.14 Bits 3:0 in the Memory Limit register for a PCI Bridge must be read only and always return 0.

Reference document: WLP# - B2.5.2.4; PCI-to-PCI Bridge Architecture Specification, Revision 1.1, Section 3.2.5.6.
Test description: TD-4.50 PCI Compliance Test

4.63.15 The ISA Enable bit in the Bridge Control Register must be read/write.

Reference document: WLP# - B2.5.2.4; PCI-to-PCI Bridge Architecture Specification, Revision 1.1, Section 3.2.5.17.
Test description: TD-4.50 PCI Compliance Test

4.63.16 The VGA Enable bit in the Bridge Control register must be read/write.

Reference document: WLP# - B2.5.2.4; PCI-to-PCI Bridge Architecture Specification, Revision 1.1, Section 3.2.4.
Test description: TD-4.50 PCI Compliance Test

4.63.17 Bit 4 in the Bridge Control register is reserved and must always return 0.

Reference document: WLP# - B2.5.2.4; PCI-to-PCI Bridge Architecture Specification, Revision 1.1, Section 3.2.5.17.
Test description: TD-4.50 PCI Compliance Test

4.63.18 The Secondary Bus Reset bit in the Bridge Control register must be read/write.

Reference document: WLP# - B2.5.2.4; PCI-to-PCI Bridge Architecture Specification, Revision 1.1, Section 3.2.5.17.
Test description: TD-4.50 PCI Compliance Test


PCI Test Descriptions

This section describes the PCI tests. Test descriptions include, a description of each test, set up requirements, and results interpretations with any associated issues and problems discussed. Each named test is referenced by the various assertions at the beginning of this chapter.

All PCI tests, including PCICAP (for Windows Millennium Edition and Windows 2000), are linked with a test utility library. This library provides several standard, generic, command-line options that are available to all tests.


TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

Note: This test applies or Windows Millennium Edition and Windows 2000, but not for Windows XP.

Overview

The purpose of the PCICAP test is to probe PCI configuration space for each of the PCI device functions and to verify that the power management registers for the network adapter, modem, graphics controller, and audio controller device classes have been implemented correctly. These devices reside on either the motherboard or add-in cards and may be integrated with the core chipset. For a list of assertions tested, see "TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)."

The PCICAP test accesses PCI configuration space via the PCI run-time BIOS functions in Real Mode, including PCI Read Configuration Byte, Word, and Double Word; and PCI Write Configuration Byte, Word, and Double Word. In addition, the test invokes the BIOS functions, Find BIOS Present and Find PCI Device.

As directed, the PCICAP test performs the following steps:

  1. Scans the system to build a linked list of all PCI devices and gathers available information about the configuration header and the new capability list for all PCI devices.
  2. Locates all devices in PCI bus 0.
  3. Does the following for the previously mentioned device classes:

a. Determines whether a device class supports any new capabilities.

b. Locates all functions that this device implements.

c. For each PCI function with power management capability, PCICAP verifies that the system has correctly implemented its new power management capability register.

  4. Repeats steps 2 and 3 for devices in all remaining PCI buses.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The PCI Power Management (PM) Register Interface test (PCICAP) requires the target platform to implement the PCI 2.1 specification with the power management register interface.

The PCICAP test requires that the target platform’s BIOS implement the ACPI name space. To avoid conflicts, the PCICAP test requires the operating system to be configured to not use ACPI mode. The platform further requires a special PCI-PM-compliant test adapter described in "PCI Test Adapter" in the introduction to this chapter. The PCI test adapter must be installed in any PCI slot on PCI bus 0.

Results Interpretation

This test creates a detailed log file of test results and displays the Pass or Fail status of the PCI devices on the screen when completed. The log file is specified as a test invocation parameter. Review the log file for specific details about PCICAP failures.


TD-4.2 PCI Subsystem Device ID and Subsystem Vendor ID Test (PCISID)

Note: This test applies or Windows Millennium Edition and Windows 2000, but not for Windows XP.

Overview

The purpose of the PCI Subsystem Device ID and Subsystem Vendor ID (PCISID) test is to verify correct implementation of the subsystem IDs.

The PCISID test accesses PCI configuration space via the PCI run-time BIOS functions in Real Mode.

As directed, PCISID performs the following steps:

  1. Scans the system to build a linked list of all PCI devices and gathers available information about the configuration header and the new capability list for all PCI devices.
  2. Locates all devices in PCI bus 0.
  3. Does the following for each of the device classes, except the core chipsets and PCI-to-PCI bridges:

a. Determines whether the system has implemented the PCI Subsystem Device ID (SID) and Subsystem Vendor ID (SVID).

b. Determines whether both the SID and SVID values are nonzero and legal.

c. Determines whether both the SID and SVID values are not directly writable.

d. Does the following to verify that both the SID and SVID values are not lost after transitioning the system to S3 Sleep state:

(a.) Saves the current values of both the SID and SVID.

(b.) Enters ACPI mode and installs the SCI handler.

(c.) Programs the Power Button Event to awaken the system.

(d.) Transitions the system to the S3 state via ACPI mode.

(e.) When the Power Button Event awakens the system, the test retrieves the current values of both the SID and SVID.

(f.) Compares the original values of the SID and SVID with the current ones.

(g.) If the test determines that a mismatch exists, it generates an error report.

(h.) Returns to legacy (non-ACPI) mode and uninstalls the SCI handler.

  4. Repeats steps 2 and 3 for devices in all remaining PCI buses.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The following hardware and software setup is required to run the test.

Required Hardware

PCISID requires a target platform that implements a PCI 2.1-based bus. The target platform must also be ACPI-compliant.

Required Software

No special software setup is necessary.

Results Interpretation

This test creates a detailed log file of test results and displays the Pass or Fail status of the subsystem IDs on the screen when completed. The log file is specified as a test invocation parameter. Review the log file for specific details about PCISID failures.


TD-4.3 PCI Maximum Completion Time Test (PCIMCT)

Overview

Since the PCI SIG Group currently provides tests to verify the maximum completion time (MCT) requirements within Windows environments, these tests are not duplicated here. However, they are made available as part of the PCI hardware compliance test suite.

Successfully running this test requires the use of the special PCI test adapter described in "PCI Test Adapter" in the introduction to this chapter and the adapter’s operation in one of the PCISIG card-compatible modes.


TD-4.4 PCI Peripheral Test Assertion Checklist (PERICHK)

Overview

The purpose of the following PCI assertions checklist is to verify the assertions listed in "PCI Bus Power State Transition Assertions Not Tested." All PCI test assertions are listed in the following checklist. The checklist is included in this document because it is intended for use as an internal tool.

Note: The checklist is not part of the certification test.

To complete the test, answer each line item in the PME# Signal Support Checklist
(Table 4-5), the 3.3Vaux Auxiliary Power Checklist (Table 4-6) and the Subsystem ID and Subsystem Vendor ID Checklist (Table 4-7).

Table 4-5. PME# Signal Support Checklist

Assertion | Description | Confirm
 | When the device asserts the PME# signal, does it continue to drive the signal low until the system software clears either the PME_En or PME_Status bit in the function’s PMCSR Register? |
 | If the system does not support PME# generation from the D3 Cold state, does the assertion of a bus segment reset cause the system to initialize the PME context? |

Table 4-6. 3.3Vaux Auxiliary Power Checklist

Assertion | Description | Confirm
 | When the PCI bus is in B0, B1, or B2 state, does the PCI add-in card, with support for PME# signal generation from the D3 Cold state, draw more than 375mA through the 3.3Vaux auxiliary power? |
 | Can the PCI function that supports PME# signal generation from the D3 Cold state accept PCI bus cycles within 10ms following the low-to-high transition of the PCI RST# signal? |
 | Does the PCI function that applies power management events to wake the system take longer than 10 ms to self-initialize to where it is ready to accept PCI cycles? |
 | Is the PCI add-in card, without support for PME# signal generation from the D3 Cold state, by design not physically connected to the 3.3Vaux pin 14A? |
 | When a PCI add-in card is plugged into a system that supports the 3.3Vaux auxiliary power, is it always electrically isolated from the main PCI 3.3V rails? |
 | Does the PCI add-in card that implements functions generating power management events from the D3 Cold state determine whether the 3.3V on pin 14A is present before reporting its power support for PME# signal generation from the D3 Cold state? |
 | Is the PCI add-in card that implements functions generating power management events from the D3 Cold state backward-compatible with PCI systems that do not support the 3.3Vaux auxiliary power? |
 | Does the PCI add-in card, when plugged into a system that does not support delivery of the 3.3Vaux auxiliary power, implement a weak pulldown, attached to pin 14A, to create a logical low-reference? |
 | When the PCI bus is in B3 state and the PCI function is in legacy D3 state, does the function allow any PCI actions? |

Table 4-7. Subsystem ID and Subsystem Vendor ID Checklist

Assertion | Description | Confirm
 | Does the PCI add-in card populate its subsystem ID and subsystem vendor ID by hardware on the card itself and not by an extension BIOS or device driver? |

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The PERICHK test requires that the person(s) completing the checklist be familiar with the PCI 2.1 and PCI Bus Power Management Interface Specification, Revision 1.1, specifications, system board design documents, and PCI add-in card design documents.

No special software setup is necessary.

Results Interpretation

If any line item in the preceding checklists is checked No, the device or peripheral fails the PERICHK test. The device or peripheral passes the test only if all line items in the checklists are checked Yes.


TD-4.5 PCI Power Management Diagnostic(s) Test (PMDIAG)

Test Kit: HCT 11, HCT 10

Overview

The purpose of the Power Management Diagnostic(s) (PMDIAG) test is to verify the functional behavior of the PCI test adapter for the combinations of the PCI bus power state B0 and the function power states, D0, D1, D2, and D3 Hot. This test is also intended to verify all possible function power state transitions from each function’s power state. See "PCI Test Adapter Diagnostic(s) Assertions" earlier in this chapter. The PMDIAG test accesses PCI configuration space via the PCI run-time BIOS functions in real-mode. It uses the following BIOS functions: PCI Read Configuration Byte, Word, and Double Word, and PCI Write Configuration Byte, Word, and Double Word. The test also invokes the BIOS functions, Find BIOS Present and Find PCI Device.

The test writes an appropriate value to the PowerState field in the PMCSR Register to set the PCI function being evaluated to a new power state. Successfully running this test requires the use of the special PCI test adapter described previously in "PCI Test Adapter" in the introduction to this chapter.

  1. As directed, the PMDIAG test performs the following steps:
  2. Determines whether the PCI bus 0 is in B0 state.
  3. Determines whether the PCI test adapter is in Uninitialized D0 state.
  4. Identifies the PCI configuration space of the installed PCI test adapter.
  5. Performs multiple PCI configuration cycles for each PCI test adapter function.
  6. Verifies access to the PCI configuration space.
  7. Initializes the installed PCI test adapter and transitions its function power state to D0 Active.
  8. Verifies the power management register functionality of the PCI test adapter.
  9. For each of the PCI test adapter’s function power states, D0 Active, D1, D2, and D3 Hot, PMDIAG does the following:

a. Performs PCI configuration cycles.

b. Verifies access to the PCI configuration space.

  10. Verifies every possible transition from each function’s power states.
  11. Verifies the functionality of the PCI test adapter’s specific registers, e.g., Misc_PMCTL Register.
  12. Repeats the preceding steps after installing the PCI test adapter in each remaining PCI slot.
  13. If a PCI-to-PCI bridge exists, PMDIAG repeats the preceding steps after installing the PCI test adapter behind this bridge.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The PMDIAG test requires a target platform that implements a PCI bus, based on the PCI 2.1 or later specification, with at least two distinct power states, B0 and B3. The target platform must also be ACPI-compliant, with support for the S3 power state. The platform further requires a special PCI-PM-compliant test adapter described previously in "PCI Test Adapter" in the introduction to this chapter. The adapter is similar to a PCI SIG card but provides more functionality to support PCI power management requirements. The PCI test adapter must be installed in any PCI slot on PCI bus 0.

No special software setup is necessary.

Results Interpretation

This test creates a detailed log file of test results and displays the Pass or Fail status of the PCI test adapter on the screen when completed. The log file is specified as a test invocation parameter. Review the log file for specific details about PMDIAG failures.


TD-4.6 PCI Voltage Requirement Test (PCIVOLT)

Test Kit: HCT 11, HCT 10

Overview

The purpose of the PCI Voltage Requirement (PCIVOLT) test is to verify that PCI-based systems support the appropriate voltages to all PCI connectors. See "PCI Voltage Requirement Assertions Tested" for a list of the assertions tested.

The PCIVOLT test accesses PCI configuration space via the PCI run-time BIOS functions in Real Mode, including PCI Read Configuration Byte, Word, and Double Word, and PCI Write Configuration Byte, Word, and Double Word.

Successfully running the test requires the use of the special PCI test adapter previously described in "PCI Test Adapter" in the introduction to this chapter.

As directed, the PCIVOLT test performs the following steps:

  1. Identifies the PCI configuration space of the installed PCI test adapter.
  2. Initializes the PCI test adapter and transitions its power state to D0 Active.
  3. Reads the PCI test adapter’s Misc_PMCTL Register to determine the presence of a 3.3Vaux, 3.3V, and/or 5V power supply.

If any of these PCI voltages is not detected, PCIVOLT reports an error. The test also verifies that the appropriate LEDs on the back-panel bracket of the PCI test adapter are lit for each PCI voltage detected.

  4. Programs the PCI test adapter’s power state to D3 Hot.
  5. Transitions the system to S1 system power state (S0-S1) and then awakens the system using PME# signal assertion (S1-S0).

During these system power transitions, PCIVOLT measures the 3.3Vaux voltage using a voltmeter. The DC operating voltage band for a 3.3Vaux-enabled system must range from 3.0V-3.6V; otherwise, PCIVOLT reports an error.

  6. Programs the PCI test adapter’s power state to D0.
  7. Repeats the preceding three steps with S3 system power state instead of S1.
  8. Repeats steps 1 through 6 after installing the PCI test adapter in each remaining PCI slot.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The PCIVOLT test requires a target platform that is capable of managing PCI power. It also requires a PCI test adapter as described in the introduction to this chapter. After the target system has been shut down, the PCI test adapter must be installed in any PCI slot on PCI bus 0. A voltmeter must then be attached to the PCI test adapter’s 3.3Vaux test stake pins.

No special software setup is necessary.

Results Interpretation

This test creates a detailed log file of test results and displays the Pass or Fail status of the PCI test adapter on the screen when completed. The log file is specified as a test invocation parameter. Review the log file for specific details about PCIVOLT failures.


TD-4.7 PCI PME# Signal Routing Test (PCIPME1)

Test Kit: HCT 11, HCT 10

Overview

The purpose of the PME# Signal Routing (PCIPME1) test is to verify that the PCI system hardware correctly sequences between S3 system sleep state and working state in response to the PME# signal assertion from the PCI test adapter. This enables the test to validate whether each PME# signal assertion tested invokes a service routine. See "PME # Signal Assertions" for a list of the assertions tested.

Successfully running this test requires the use of the special PCI test adapter as described in the introduction to this chapter.

As directed, PCIPME1 performs the following steps:

  1. Identifies the PCI configuration space of the installed PCI test adapter. The PCI test adapter must be in Uninitialized D0 state.
  2. Initializes the PCI test adapter and transitions its power state to D0 Active.
  3. Locates ACPI tables and identifies the SCI vector.
  4. Disables all known ACPI event interruption sources.
  5. Installs the SCI handler and transitions the system to ACPI mode.
  6. Sets the value in the PCI test adapter’s LoadSelect field (bits 1-2) in its Misc_PMCTL Register to 160mA.
  7. Transitions the PCI test adapter to D3 Hot state.
  8. Clears the PME_Status bit.
  9. Sets the PME_En bit to a value of 1.
  10. Executes the _PRW object for Root PCI Bus device.
  11. Determines which General Purpose Event (GPE) Register bit is dedicated to PME# signal generation.
  12. Determines the lowest power-sleep state allowed.
  13. Clears all status bits in each GPE Register.
  14. Clears all ACPI chipset status bits.
  15. Sets the GPE register enable bit.
  16. Resets the SCI count for the general-purpose event.
  17. Instructs the user to do the following:

a. Press any key to enter the S3 Sleep state.

b. Press the PCI test adapter’s PME# assertion button to awaken the system.

  18. Places the system S3 system sleep state.
  19. When the system awakens from the sleep state, check the SCI count.
  20. Determines which card asserted the PME# signal.
  21. Clears the PME_Status bit.
  22. Clears the PME_En bit.
  23. Sets the PCI test adapter to D1 Active state via its PowerState field.
  24. Verifies the GPE status bit.
  25. Clears the GPE status bit.
  26. Clears the GPE enable bit.
  27. Returns to legacy (non-ACPI) mode and uninstalls the SCI handler.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The PCIPME1 test requires that the target platform’s BIOS implement the ACPI name space and hardware to support the S3 system power state. The PCI test adapter required for this test must support the PME# signal assertion necessary to notify awakening events.

The PCI test adapter must be installed in any PCI slot on PCI bus 0.

Results Interpretation

This test creates a detailed log file of test results and displays the Pass or Fail status of the PCI test adapter on the screen when completed. Review the log file for specific details about PCIPME1 failures.


TD-4.8 PME# Signal Routing - Simultaneous (PCIPME2) Test Description

Test Kit: HCT 11, HCT 10

Overview

The purpose of the Multiple PME# Assertion (PCIPME2) test is to verify that the PCI system hardware sequences between the various system sleep states and working states in response to the PME# signal assertions from multiple PCI test adapters simultaneously. See "PME # Signal Assertions" for a list of the assertions tested.

This test is functionally the same as "TD-4.7 PCI PME# Signal Routing Test (PCIPME1)" except that multiple test adapters are used. Successfully running this test requires the use of multiple special PCI test adapters with at least two that have PME pins daisy-chained, the type of which is described in the introduction to this chapter. Follow the steps outlined in "TD-4.7 PCI PME# Signal Routing Test (PCIPME1)."

Setup

The PCI test adapter must be installed in any PCI slot on PCI bus 0.

Results Interpretation

This test creates a detailed log file of test results and displays the Pass or Fail status of the PCI test adapter on the screen when completed. Review the log file for specific details about PCIPME2 failures.


TD-4.9 PCI Device Wake-up (PCIWAKE) Test Description

Test Kit: HCT 11, HCT 10

Note In the HCT kit, this test is called the System Wake Up test

Overview

The purpose of the Device Wake-Up (PCIWAKE) test is to verify the PCI function’s awakening behavior for various combinations of bus and function power states. The PCI function must support the assertion of the PME# signal that indicates the awakening event. See "PME # Signal Assertions" and "TD-4.10 PCI 3.3 Volt Auxiliary Power Load (PCIVAUX) Test Description" for a list of the assertions tested.

Successfully running this test requires the use of the special PCI test adapter, described in the introduction to this chapter.

As directed, PCIWAKE performs the following steps:

  1. Identifies the PCI configuration space of the installed PCI test adapter. The PCI test adapter must be in Uninitialized D0 state.
  2. Initializes the PCI test adapter and transitions its power state to D0 Active.
  3. Locates ACPI tables and identifies the SCI vector.
  4. Disables all known ACPI event interruption sources.
  5. Installs the SCI handler and transitions the system to ACPI mode.
  6. Does the following for each supported Sleep state, S1, S2, and S3; for each PCI test adapter power state (D3 Hot and D3 Cold).

a. Sets the value in the PCI test adapter’s LoadSelect field (bits 1-2) in its b.b.b. Misc_PMCTL Register to 160mA.

b. Transitions the PCI test adapter to D3 Hot state.

c. Clears the PME_Status bit.

d. Sets the PME_En bit to a value of 1.

e. Executes the _PRW object for Root PCI Bus device.

f. Determines which General Purpose Event (GPE) Register bit is dedicated to PME# signal generation.

g. Determines the lowest power-sleep state allowed.

h. Clears all status bits in each GPE Register.

i. Clears all ACPI chipset status bits.

j. Sets the GPE register enable bit.

k. Resets the SCI count for the general-purpose event.

l. Instructs the user to do the following:

(a.) Press any key to enter the S3 Sleep state.

(b.) Press the PCI test adapter’s PME# assertion button to awaken the system.

m. Places the system S3 system sleep state.

n. When the system awakens from the sleep state, check the SCI count.

o. Determines which card asserted the PME# signal.

p. Clears the PME_Status bit.

q. Clears the PME_En bit.

r. Sets the PCI test adapter to D1 Active state via its PowerState field.

s. Verifies the GPE status bit.

t. Clears the GPE status bit.

u. Clears the GPE enable bit.

  7. Clears all general-purpose event status and enabling bits.
  8. Returns to legacy (non-ACPI) mode and uninstalls the SCI handler.
  9. Repeats the preceding steps after installing the test adapter in each of the remaining PCI slots.
  10. If a PCI-to-PCI bridge exists, PCIWAKE repeats the preceding steps after installing the test adapter behind the bridge.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The PCIWAKE test requires that the target platform’s BIOS implement the ACPI name space and hardware to support at least one Sx (where x > 0) sleep state. The PCI test adapter required for this test must support the PME# signal assertion necessary to notify awakening events.

The PCI test adapter must be installed in any PCI slot on PCI bus 0.

Results Interpretation

This test creates a detailed log file of test results and displays the Pass or Fail status of the PCI test adapter on the screen when completed. The log file is specified as a test invocation parameter. Review the log file for specific details about the PCIWAKE test failures.


TD-4.10 PCI 3.3 Volt Auxiliary Power Load (PCIVAUX) Test Description

Test Kit: HCT 11, HCT 10

Overview

The purpose of the 3.3Vaux Auxiliary Power (PCIVAUX) test is to verify whether systems that support 3.3Vaux power are capable of fully powering at least one 3.3Vaux-enabled PCI slot while the PCI bus is in B3 state. Another purpose of this test is to verify whether such systems are capable of powering all slots in the system when the PCI bus is in B0, B1, or B2 state. See "TD-4.10 PCI 3.3 Volt Auxiliary Power Load (PCIVAUX) Test Description" for a list of assertions tested.

The PCIVAUX test accesses PCI configuration space via the PCI run-time functions in Real Mode.

Successfully running this test requires the use of multiple special PCI test adapters (at least 3), described in the introduction to this chapter.

As directed, the PCIVAUX test performs the following steps:

  1. Identifies the PCI configuration of the first installed PCI test adapter.
  2. Initializes the PCI test adapter and transitions its power state to D0 Active.
  3. Installs the SCI handler and transitions to ACPI mode.
  4. Locates ACPI tables and identifies the SCI vector.
  5. Disables all known ACPI event interruption sources.
  6. Checks to see if 3.3 Vaux power is supported by the system. If so, whether it is routed to all slots on the motherboard.
  7. Put the system in S3 and check that when PME# is asserted, the system is capable of fully powering at least one 3.3Vaux enabled PCI Slot.

a. Puts all PCI tester cards in D3 Hot state and puts the system into state S3.

b. Programs one of the cards to consume 375mA and the rest to consume 20mA.

c. This test verifies that the system is capable of fully powering at least one 3.3Vaux enabled PCI Slot after wake up through PME# signal assertion.

  8. Puts the system in S1 and checks that when PME# is asserted, the system is capable of fully powering all 3.3Vaux enabled PCI Slots.

a. Puts all PCI tester cards in D3 Hot state and puts the system into the power state S1\S2.

b. Programs all the cards to consume 375mA.

c. This test verifies that the system is capable of fully powering all 3.3Vaux enabled PCI Slots after wake up through PME# assertion.

  9. Puts the system in S1/S2 and measures the voltage when system switches between S0-S1, S1-S0 and S0-S2, S2-S0. This test verifies that the 3.3Vaux is maintained within 3.0V - 3.6V range whenever system transitions between S0/S1/S2 states.
  10. Puts the system in S3 and measures the voltage when system switches between
    S0-S3. Programs one of the cards to consume 375 mA and the rest to consume 20 mA. This test verifies that the 3.3Vaux is maintained within 3.0V - 3.6V range whenever system transitions between S0/S3 states. This takes care of programming the system to go to S3 state as described in the PCIPME1 test.
  11. Puts the system in S3 and measures the voltage when system switches between
    S0-S3. Programs all the cards to consume 20mA. This test verifies that the 3.3Vaux is maintained within 3.0V - 3.6V range whenever system transitions between S0/S3 states. This takes care of programming the system to go to S3 state as described in the PCIPME1 test.
  12. Returns to legacy (non-ACPI) mode and un-installs the SCI handler.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The PCIVAUX test requires that the target platform’s BIOS implement the ACPI name space and hardware to support at least one Sx (where x > 0) Sleep state. The PCI test adapter that is required for this test must provide software control for varying its 3.3Vaux current requirements. The adapter card must also exercise software control to support PME# signal assertion capability.

The PCI test adapter must be installed in any PCI slot on PCI bus 0. Because multiple PCI test adapters must be installed to successfully run this test, the number of these adapters used depends on the number of PCI slots available on the system.

Results Interpretation

This test creates a detailed log file of test results and displays the Pass or Fail status of the PCI test adapter on the screen when completed. The log file is specified as a test invocation parameter. Review the log file for specific details about PCIVAUX failures.


TD-4.11 PCI System BIOS Initialization Requirement Test (BIOSINIT)

Overview

The purpose of the System BIOS Initialization Requirement (BIOSINIT) test is to verify that the system BIOS masks off the PME# signal during both system power-on and warm-boot (Ctrl+Alt+Del) sequences. See "System BIOS Initialization Requirement Assertions" for a list of the assertions tested.

The BIOSINIT test accesses PCI configuration space via the PCI run-time functions in Real Mode.

Successfully running this test requires the use of the special PCI test adapter described in the introduction to this chapter.

As directed, BIOSINIT performs the following steps:

  1. Initializes the PCI test adapter and transitions its power state to D0 Active.
  2. Identifies the PCI configuration space of the installed PCI test adapter.
  3. Reads the PCI test adapter’s PMCSR Register to determine the current bit settings for both PME_Status and PME_En. If BIOSINIT does not read the PME_Status bit as value 0b and the PME_En bit as value 1b, BIOSINIT reports an error.
  4. Determines whether the PCI test adapter’s power state is D0. If its state is not D0, BIOSINIT reports an error.
  5. Repeats the preceding steps during the system power-on and warm-boot (Ctrl+Alt+Del) sequences.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The BIOSINIT test requires a target platform that is capable of managing PCI power. It also requires a PCI test adapter described in the introduction to this chapter.

After the target system has been shut down, the PCI test adapter must be installed in any PCI slot on PCI bus 0. The PCI test adapter’s dip-switch #2, located on the back-panel bracket of the adapter, must be set to the On position. This setting forces the PCI test adapter’s PME_Status and PME_En bits to a value of 1b during the system boot sequence. The factory setting of this switch must be the Off position.

No special software setup is necessary.

Results Interpretation

This test creates a detailed log file of test results and displays the Pass or Fail status of the PCI test adapter on the screen when completed. The log file is specified as a test invocation parameter. Review the log file for specific details about BIOSINIT failures.


TD-4.12 PCI System Test Assertion Checklist (SYSCHK)

Overview

The purpose of the following PCI system test assertion checklist is to verify the assertions listed in section "PCI Bus Power State Transitions Assertions Not Tested." The checklist is included in this document because it is intended for use as an internal tool.

Note: This checklist is not part of the certification test.

To complete the test, answer each line item in the PME# Signal Support Checklist (Table 4-9), the 3.3Vaux Auxiliary Power Checklist (Table 4-10), and the 3.3V Power to PCI Connectors ChecklistTable 4-11).

Table 4-9. PME# Signal Support Checklist

Check List # | Description of Power Management Checklist for PCI Based Systems | Confirm
1 | Is the PME# signal a level-sensitive—not edge-triggered—and active low signal? |
2 | Is the PME# signal assertion and "deassertion" asynchronous to the PCI clock? |
3 | Is the PME# signal bused between all PCI connectors in the system? |
4 | Is the PME# signal assigned to pin 19A of the standard PCI connector pin-out? |
5 | Are all sources of the PME signal interconnected to singly connect to the system ACPI controller? |

Table 4-10. 3.3Vaux Auxiliary Power Checklist

Check List # | Description of Power Management Checklist for PCI Based Systems | Confirm
6 | Does the 3.3Vaux auxiliary power supply provide power to system wake-up circuitry? |
7 | Is the PCI system capable of delivering up to 1.24W (375mA @ 3.3VDC) to each enabled PCI expansion slot? |
8 | Is the PCI system capable of delivering up to 66mW (20mA @ 3.3VDC) to each disabled PCI expansion slot? |
9 | When the system supports the 3.3Vaux auxiliary power supply 3.3Vaux, does each PCI connector pin 14A read the power supply as logical OR of a high- and low-capacity, 3.3V source? |
10 | When the system supports the 3.3Vaux auxiliary power supply, does the PCI RST# signal remain asserted whenever the PCI bus is in B3 state? |
11 | Is the 3.3Vaux power source independent of the PCI bus 3.3V and 5V voltage rails? |

Table 4-11. 3.3V Power to PCI Connectors Checklist

Check List # | Description of Power Management Checklist for PCI Based Systems | Confirm
12 | Does the PCI system regulate the 3.3V power supply within the 3.0V-3.6V band? |
13 | Is the current requirement per PCI connector for the 3.3V rail less than 7.6A? |
14 | Is each connector slot keyed correctly for its voltage? |

Table 4-12. Subsystem ID and Subsystem Vendor ID Checklist

Check List # | Description of Power Management Checklist for PCI Based Systems | Confirm
15 | Does the system BIOS, at the power-on, self-test stage, or the ACPI control method program the subsystem IDs for devices that are integrated on the system board? |

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The SYSCHK checklist/test requires that the person(s) completing the checklist be familiar with the PCI 2.2 and PCI Bus Power Management 1.1 Specification specifications, system board design documents, and PCI add-in card design documents.

No special software setup is necessary.

Results Interpretation

If any line item in the preceding checklists is checked No, the device or peripheral fails the PERICHK test. The device or peripheral passes this test only if all line items in the checklists are checked Yes.


TD-4.13 PCI D3 Graphics Adapter Basic Compliance Test

Overview

The following basic test verifies that the PCI or AGP card supports the power state requirements in the Windows Logo Program requirements.

It is required to run this test on a system that supports the S3 sleep state. All other peripherals on the system should be referenced.

To run the Graphics Adapter Basic Compliance Test, perform the following steps:

  1. Install Windows Millennium Edition.
  2. Run PCIPMTEST.exe. It is a console application that prints out details of the add-in cards.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The following hardware and software setup is required to perform the test procedure.

Required Hardware

  • A desktop platform that supports the ACPI S3-sleep state and passes the WHQL ACPI Compliance tests.

Required Software

  • WHQL Graphics Adapter D3-support test suite.

Results Interpretation

After execution, the PCIPMTEST.EXE displays a dialog box if the display adapter hardware does not advertise support for D3 state.


TD-4.14 PCI-D3 Graphics Adapter Functionality Test Under Windows

Overview

The following PCI-D3 Graphics Adapter Functionality Test Under Windows ensures that,

  • Hardware allows the system to successfully go to S3 sleep state.
  • Hardware allows the system to successfully wake from S3 state.
  • Hardware is fully functional on resume from S3 sleep state.

The following tests must be run on a system that correctly supports the S3 sleep state. Windows Millennium Edition is required to be installed on the system prior to running these tests. Install the target graphics hardware and associated drivers before starting the following test-sequence.

The Graphics Adapter PCI-D3 Functionality Test Under Windows test runs the following test cases:

  1. Suspend/Resume Switch Test (S3 state).

a. Use Power-switch to force system to enter S3 sleep-state.

b. Using the FoxFire II PCI adapter, verify that the system is in the S3 sleep state as indicated by all LEDs (except the 3.3Vaux LED) on the FoxFire II PCI adapter being off.

c. Use Power-switch again to wake the system up.

  2. Suspend/Resume Staging Test (S3 state).

a. Launch Power Management properties (through Control Panel)

b. Under Settings for AlwaysOn Power Scheme, set System Standby = 2min, Turn-Off Monitor=1 min, Turn-off hard disk= Never.

c. Allow system to time-out to sleep.

d. Using the FoxFire II PCI adapter, verify that the system is in the S3 sleep state as indicated by all LEDs (except the 3.3Vaux LED) on the FoxFire II PCI adapter being off.

e. Use Power-switch again to wake the system up.

  3. Reference Application (Microsoft* Combat Flight Simulator) Switch test (S3 state).

a. Launch Microsoft Combat Flight Simulator application.

b. Using Free-Flight option, launch aircraft and get to steady-state.

c. Use Power-switch to force system to go to sleep state.

d. Using the FoxFire II PCI adapter, verify that the system is in the S3 sleep state as indicated by all LEDs (except the 3.3Vaux LED) on the FoxFire II PCI adapter being off.

e. Use Power-switch again to wake the system up.

f. Is audio working as expected?

g. Is the video working as expected?

h. If game-controller is supported, does it work as expected?

  4. Suspend/Resume testing of Video cards using DirectDraw samples from DirectX* 6.1 SDK.

a. Install DirectX 6.1 SDK on the system.

b. Launch PCID3 VideoTest.exe.

c. PCID3 VideoTest.exe runs the following DirectX samples in sequence: 2D Flip-Cube, Donut, Ex1 Page-flipping, EX2 Page-flipping, Font, FSWindows, and Switcher and Stretch.

d. After running each sample, the test puts the system into S3 sleep state and programs the system for RTC-based wakeup.

e. On resume, the test attempts to continue playing the sample.

f. It displays a dialog box to get user feed-back if video is functioning normally (or otherwise).

g. It logs the results and launches the next sample and repeats the process.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The following hardware and software setup is required to perform the test.

Required Hardware

  • A desktop platform that supports the ACPI S3-sleep state and passes the WHQL ACPI Compliance tests.
  • A FoxFire II PCI adapter is required to monitor power-supply status of the PCI bus. When all the LEDs except the 3.3Vaux LED on the card are off, the PCI bus is shown to have lost primary power. In the following test, the LEDs are used to verify that the system goes to a S3 sleep state, which is confirmed by the LEDs being off.

Required Software

  • WHQL Graphics Adapter D3-support test suite.
  • Reference power-managed application (Microsoft Combat Flight Simulator).
  • Microsoft DirectX 6.1 (or later) SDK.

Results Interpretation

Test Case 1 - System should resume (return to S0 state) and be fully functional.

Test Case 2 - System should resume (return to S0 state) and be fully functional.

Test Case 3 - System should resume (return to S0 state). The application should be fully functional and no video artifacts should be seen.

Test Case 4 - The test should pass.


TD-4.15 PCI-D3 Graphics Adapter Functionality Test Under Windows 2000

Overview

The following PCI-D3 Graphics Adapter Functionality Test Under Windows 2000 ensures that:

  • Hardware allows the system to successfully go to S3 sleep state.
  • Hardware allows the system to successfully wake from S3 state.
  • Hardware is fully functional on resume from S3 sleep state.

System Requirement

The following test must be run on a system that correctly supports the S3 sleep state. Windows 2000 must be installed on the system prior to running these tests. Install the target graphics hardware and associated drivers before starting the following test-sequence.

The Graphics Adapter PCI-D3 Functionality Test Under Windows 2000 test, runs the following test cases:

  1. Suspend/Resume Switch Test (S3 state).

a. Use Power-switch to force system to enter S3 sleep-state.

b. Using the FoxFire II PCI adapter, verify that the system is in the S3 sleep state as indicated by all LEDs (except the 3.3Vaux LED) on the FoxFire II PCI adapter being off.

c. Use Power-switch again to wake the system up.

  2. Suspend/Resume Staging Test (S3 state).

a. Launch Power Management properties (through Control Panel).

b. Under Settings for AlwaysOn Power Scheme, set System Standby = 2min, Turn-Off Monitor=1 min, Turn-off hard disk= Never.

c. Allow system to time-out to sleep.

d. Using the FoxFire II PCI adapter, verify that the system is in the S3 sleep state as indicated by all LEDs (except the 3.3Vaux LED) on the FoxFire II PCI adapter being off.

e. Use Power-switch again to wake the system up.

  3. Reference application (Microsoft Combat Flight Simulator) Switch test (S3 state).

a. Launch Microsoft Combat Flight Simulator application.

b. Using Free-Flight option, launch aircraft and get to steady-state.

c. Use Power-switch to force system to go to sleep state.

d. Using the FoxFire II PCI adapter, verify that the system is in the S3 sleep state as indicated by all LEDs (except the 3.3Vaux LED) on the FoxFire II PCI adapter being off.

e. Use Power-switch again to wake the system up.

f. Is audio working as expected?

g. Is the video working as expected?

h. If game-controller is supported, does it work as expected?

  4. Suspend/Resume testing of Video cards using DirectDraw samples (from DirectX 6.1 SDK).

a. Install DirectX 6.1 SDK on the system.

b. Launch PCID3 VideoTest.exe.

c. PCID3 VideoTest.exe runs the following DirectX samples in sequence: 2D Flip-Cube, Donut, Ex1 Page-flipping, EX2 Page-flipping, Font, FSWindows, and Switcher and Stretch.

d. After running each sample, the test puts the system into S3 sleep state and programs the system for RTC-based wakeup.

e. On resume, the test attempts to continue playing the sample.

f. It displays a dialog box to get user feedback if video is functioning normal (or otherwise).

g. It logs the results and launches the next sample and repeats the process.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The following hardware and software setup is required to perform the test procedures.

Required Hardware

  • A desktop platform that supports the ACPI S3-sleep state and passes the WHQL ACPI Compliance tests.
  • Although it is possible to do it by some other means, for example, by using a POST card, or by observing the fans and other devices on the system, it is recommended that one uses a FoxFire II PCI adapter to monitor power-supply status of the PCI bus, and in the parts of this document that are related to PCI-D3 tests, it is assumed that a card is used. When all the LEDs except the 3.3Vaux LED on the card are off, the PCI bus is shown to have lost primary power. In the following test, the LEDs are used to verify that the system goes to a S3 sleep state, which is confirmed by the LEDs being off.

Required Software

  • WHQL Graphics Adapter D3-support test suite.
  • Reference power-managed application (Microsoft Combat Flight Simulator).
  • Microsoft DirectX 6.1 (or later) SDK.

Results Interpretation

Test Case 1 - System should resume (return to S0 state) and be fully functional.

Test Case 2 - System should resume (return to S0 state) and be fully functional.

Test Case 3 - System should resume (return to S0 state). The application should be fully functional and no video artifacts should be seen.

Test Case 4 - The test should Pass.


TD-4.16 PCI D3 Modem Basic Compliance Test

Overview

The following basic test verifies that the PCI or AGP card supports the power state requirements for the Windows Logo Program.

This test must run on a system that supports the S3 sleep state. All other peripherals on the system should be referenced.

To run the Modem Basic Compliance Test, perform the following steps:

  1. Install Windows Millennium Edition.
  2. Run PCIPMTEST.exe. It is a console application that prints out details of the add-in cards.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The following hardware and software setup is required to perform the test procedure.

Required Hardware

  • A desktop platform that supports the ACPI S3-sleep state and passes the WHQL ACPI Compliance tests.

Required Software

  • WHQL tests for Modem D3 support.

Results Interpretation

After execution, the PCIPMTEST.EXE displays a dialog box if the modem hardware does NOT advertise support for the D3 state.


TD-4.17 PCI-D3 Modem Functionality Test Under Windows

Overview

The PCI-D3 Modem Functionality Test Under Windows tests the following functionality:

  • Verify that the modem allows the Target system to correctly enter S3 sleep-and wakeup states.
  • Verify that the modem is fully functional after the Target system goes to S3 sleep state and back.

The following test must run on a system that correctly supports the S3 sleep state. Windows Millennium Edition needs to be installed on the system prior to running these tests. Install the target Modem and associated drivers before starting the following test-sequence.

The Modem PCI-D3 Functionality Tests Under Windows test runs the following test cases:

  1. Suspend/Resume Switch Test (S3 state).

a. Use Power-switch to force system to enter S3 sleep-state.

b. Using the FoxFire II PCI adapter, verify that the system is in the S3 sleep state as indicated by all LEDs (except the 3.3Vaux LED) on the FoxFire II PCI adapter being off.

c. Use Power-switch again to wake the system up.

  2. Suspend/Resume Staging Test (S3 state).

a. Launch Power Management properties (through Control Panel).

b. Under Settings for AlwaysOn Power Scheme, set System Standby = 2min, Turn-Off Monitor=1 min, Turn-off hard disk= Never.

c. Allow system to time-out to sleep.

d. Using the FoxFire II PCI adapter, verify that the system is in the S3 sleep state as indicated by all LEDs (except the 3.3Vaux LED) on the FoxFire II PCI adapter being off.

e. Use the Power-switch again to wake the system up.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The following hardware and software setup is required to run the test.

Required Hardware

  • A desktop platform that supports the ACPI S3-sleep state and passes the WHQL ACPI Compliance tests in which the target modem is installed.
  • Although it is possible to do it by some other means, for example, by using a POST card, or by observing the fans and other devices on the system, it is recommended that one uses a FoxFire II PCI adapter to monitor power-supply status of the PCI bus, and in the parts of this document that are related to PCI-D3 tests, it is assumed that a card is used. When all the LEDs except the 3.3Vaux LED on the card are off, the PCI bus is shown to have lost primary power. In the following test, the LEDs are used to verify that the system goes to a S3 sleep state, which is confirmed by the LEDs being off.

Required Software

  • WHQL tests for Modem D3 support.

Results Interpretation

Test Case 1 - System should resume (return to S0 state) and be fully functional.

Test Case 2 - System should resume (return to S0 state) and be fully functional.


TD-4.18 PCI-D3 Modem Wake On Ring Test Under Windows Millennium

Overview

The PCI-D3 Modem Wake On Ring Test Under Windows tests the following functionality:

  • The successful transition from the D3 sleep state to the waking state when an incoming call is received by the modem while the Target system is in the S3 state.
  • The modem in the Target system is fully functional after the system resumes from S3 sleep state due to a Wake on Ring event.
  • For those modems that support Caller-ID functionality, verify that this feature works when the modem wakes up the Target system from S3 sleep-state due to an incoming ring indication.

The following test must run on a Target system that correctly supports the S3 sleep state. Windows Millennium Edition needs to be installed on the system prior to running these tests. Install the Target Modem hardware and associated drivers before starting the following test-sequence.

The Modem PCI-D3 Wake On Ring Test Under Windows test, runs the following test case:

  • D3 Wake On Ring test.

a. Launch the D3 Wake On Ring (target.exe) on the Target machine.

b. Launch the D3 Wake On Ring (master.exe) on the Master machine.

The test is an automated, repetitive process that marks the modem as the wake-up device and puts the Target system into S3 sleep state. Another computer, designated as the Master, attempts to wake the machine using a phone call. Once the target system wakes up successfully from the S3 sleep state, the test ensures that the Target machine is capable of accurately receiving and sending data over the Target modem.

The test also verifies that caller ID can be retrieved after incoming ring wakes the PC for modems supporting the +VRID command. It is only relevant for modems that support the Caller-ID capability.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The following hardware and software setup is required to run the test.

Required Hardware

  • A desktop platform (Target machine) that supports the ACPI S3-sleep state and passes the WHQL ACPI Compliance tests in which the target modem is installed.
  • A second system (Master machine) that runs Windows Millennium Edition, which has a WHQL certified modem and driver installed on it. This machine does not have to support S3 sleep state.
  • Two phone lines with caller-ID support connected to the modems on each machine.
  • Although it is possible to do it by some other means, for example, by using a POST card, or by observing the fans and other devices on the system, it is recommended that one uses a FoxFire II PCI adapter to monitor power-supply status of the PCI bus, and in the parts of this document that are related to PCI-D3 tests, it is assumed that such a card is used. When all the LEDs except the 3.3Vaux LED on the card are off, the PCI bus is shown to have lost primary power. In the following test, the LEDs are used to verify that the system goes to a S3 sleep state, which is confirmed by the LEDs being off.

Required Software

  • WHQL tests for Modem D3 support.

Results Interpretation

Test Case 1 - System should resume (return to S0 state) and the D3 Wake-on-Ring test should pass. For modems that support Caller-ID, this capability should be functional after wakeup from the S3 state.


TD-4.19 PCI-D3 Modem Functionality Test Under Windows 2000

Overview

The PCI-D3 Modem Functionality Tests Under Windows 2000 tests the following functionality:

  • The modem allows the system to correctly enter S3 sleep-and wakeup states.
  • The modem is fully functional after the system goes to S3 sleep state and back.

The following tests run on a system that correctly supports the S3 sleep state. Windows 2000 needs to be installed on the system prior to running these tests. Install the target Modem and associated drivers before starting the following test-sequence.

The Modem PCI-D3 Functionality Tests Under Windows 2000 test, runs the following test cases:

  1. Suspend/Resume Switch Test (S3 state).

a. Use Power-switch to force system to enter S3 sleep-state.

b. Using the FoxFire II PCI adapter, verify that the system is in the S3 sleep state as indicated by all LEDs (except the 3.3Vaux LED) on the FoxFire II PCI adapter being off.

c. Use Power-switch again to wake the system up.

  2. Suspend/Resume Staging Test (S3 state).

a. Launch Power Management properties (through Control Panel).

b. Under Settings for AlwaysOn Power Scheme, set System Standby = 2min, Turn-Off Monitor=1 min, Turn-off hard disk= Never.

c. Allow system to time-out to sleep

d. Using the FoxFire II PCI adapter, verify that the system is in the S3 sleep state as indicated by all LEDs (except the 3.3Vaux LED) on the FoxFire II PCI adapter being off.

e. Use Power-switch again to wake the system up.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The following hardware and software setup is required to run the test.

Required Hardware

  • A desktop platform that supports the ACPI S3-sleep state and passes the WHQL ACPI Compliance tests in which the target modem is installed.
  • Although it is possible to do it by some other means, for example, by using a POST card, or by observing the fans and other devices on the system, it is recommended that one uses a FoxFire II PCI adapter to monitor power-supply status of the PCI bus, and in the parts of this document that are related to PCI-D3 tests, it is assumed that a card is used. When all the LEDs except the 3.3Vaux LED on the card are off, the PCI bus is shown to have lost primary power. In the following test, the LEDs are used to verify that the system goes to a S3 sleep state, which is confirmed by the LEDs being off.

Required Software

  • WHQL tests for Modem D3 support.

Results Interpretation

Test Case 1 - System should resume (return to S0 state) and be fully functional.

Test Case 2 - System should resume (return to S0 state) and be fully functional.


TD-4.20 PCI-D3 Modem Wake On Ring Test Under Windows 2000

Overview

The PCI-D3 Modem Wake On Ring Test Under Windows 2000 tests the following functionality:

  • Successful transition from the D3 sleep state to the waking state when an incoming call is received by the modem while the Target system is in the S3 state.
  • The modem in the Target system is fully functional after the system resumes from S3 sleep state due to a Wake on Ring event.
  • For modems that support Caller-ID functionality, this feature works when the modem wakes up the Target system from S3 sleep-state due to an incoming ring indication.

The following tests is required to run on a Target system that correctly supports the S3 sleep state. Windows 2000 is required to be installed on the system prior to running these tests. Install the Target Modem hardware and associated drivers before starting the following test-sequence.

The PCI-D3 Modem Wake On Ring Test Under Windows 2000 test runs the following test case:

  • D3 Wake On Ring test.

a. Launch the D3 Wake On Ring (target.exe) on the Target machine.

b. Launch the D3 Wake On Ring (master.exe) on the Master machine.

The test is an automated, repetitive process that marks the modem as the wake-up device and puts the Target system into S3 sleep state. Another computer, designated as the Master, attempts to wake the machine using a phone call. Once the target system wakes up successfully from the S3 sleep state, the test ensures that the Target machine is capable of accurately receiving and sending data over the Target modem.

This test also verifies that caller ID can be retrieved after incoming ring wakes the PC (for modems supporting +VRID command). It is only relevant for modems that support the Caller-ID capability.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The following hardware and software setup is required to run the test.

Required Hardware

  • A desktop platform (Target machine) that supports the ACPI S3-sleep state and passes the WHQL ACPI Compliance tests in which the target modem is installed.
  • A second system (Master machine) that runs Windows Millennium Edition, which has a Logo'd modem and driver installed on it. This machine does not have to support S3 sleep state.
  • Two phone lines with caller-ID support connected to the modems on each machine.
  • Although it is possible to do it by some other means, for example, by using a POST card, or by observing the fans and other devices on the system, it is recommended that one uses a FoxFire II PCI adapter to monitor power-supply status of the PCI bus, and in the parts of this document that are related to PCI-D3 tests, it is assumed that a card is used. When all the LEDs except the 3.3Vaux LED on the card are off, the PCI bus is shown to have lost primary power. In the following test, the LEDs are used to verify that the system goes to a S3 sleep state, which is confirmed by the LEDs being off.

Required Software

  • WHQL tests for Modem D3 support.

Results Interpretation

Test Case 1 - System should resume (return to S0 state) and the D3 Wake-on-Ring test should pass. For modems that support Caller-ID, this capability should be functional after wakeup from S3 state.


TD-4.21 PCI D3 Network Device Basic Compliance Test

Overview

The following network device basic test verifies that the PCI or AGP card supports the power state requirements for the Windows Logo Program.

This test must be run on a system that supports the S3 sleep state. All other peripherals on the system should be referenced.

To run the Network Device Compliance Test, perform the following steps:

  1. Install Windows Millennium Edition.
  2. Run PCIPMTEST.exe. It is a console application that prints out details of the add-in cards.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The following hardware and software setup is required to run the test procedure.

Required Hardware

  • A desktop platform that supports the ACPI S3-sleep state and passes the WHQL ACPI Compliance tests.

Required Software

  • WHQL tests for Network Device D3 support.

Results Interpretation

After execution, the PCIPMTEST.EXE displays a dialog box if the network device hardware does NOT advertise support for D3 state.


TD-4.22 PCI D3 Network Device Functionality Test Under Windows Millennium

Overview

The PCI-D3 Network Device Functionality Test Under Windows tests for the following functionality:

  • Verify that the Network Device allows the system to correctly enter S3 sleep-state and wakeup.
  • Verify that the Network Device is fully functional after the system goes to S3 sleep state and back.

The following tests must be run on a system that correctly supports the S3 sleep state. Windows Millennium Edition needs to be installed on the system prior to running the tests. Install the target Network Device and associated drivers before starting the following test-sequence.

The PCI-D3 Network Device Functionality Test Under Windows test, runs the following test cases:

  1. Suspend/Resume Switch Test (S3 state).

a. Use Power-switch to force system to enter S3 sleep-state.

b. Using the FoxFire II PCI adapter, verify that the system is in the S3 sleep state as indicated by all LEDs (except the 3.3Vaux LED) on the FoxFire II PCI adapter being off.

c. Use Power-switch again to wake the system up.

  2. Suspend/Resume Staging Test (S3 state).

a. Launch Power Management properties (through Control Panel).

b. Under Settings for AlwaysOn Power Scheme, set System Standby = 2min, Turn-Off Monitor=1 min, Turn-off hard disk= Never

c. Allow system to time-out to sleep.

d. Using the FoxFire II PCI adapter, verify that the system is in the S3 sleep state as indicated by all LEDs (except the 3.3Vaux LED) on the FoxFire II PCI adapter being off.

e. Use Power-switch again to wake the system up.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The following hardware and software setup is required to run the test.

Required Hardware

  • A desktop platform that supports the ACPI S3-sleep state and passes the WHQL ACPI Compliance tests in which the target network device will be installed.
  • A LAN connection to the machine either through a local Hub or a network.
  • A FoxFire II PCI adapter is required to monitor power-supply status of the PCI bus. When all the LEDs except the 3.3Vaux LED on the card are off, the PCI bus is shown to have lost primary power. In the following test, the LEDs are used to verify that the system goes to a S3 sleep state, which is confirmed by the LEDs being off.

Required Software

  • WHQL tests for Network Device D3 support.

Results Interpretation

Test Case 1 - System should resume (return to S0 state) and be fully functional.

Test Case 2 - System should resume (return to S0 state) and be fully functional.


TD-4.23 PCI D3 Network Device Wake On LAN Test Under Windows Millennium

Overview

The PCI D3 Network Device Wake On LAN Test Under Windows tests for the following functionality:

  • Successful transition from the D3 sleep state to the waking state when the networking device receives an incoming network event, while the Target system is in S3 state.
  • The networking device in the Target system is fully functional after the system resumes from S3 sleep state due to a Wake on LAN event.

The following tests need to be run on a Target system that correctly supports the S3 sleep state. Windows Millennium Edition needs to be installed on the system prior to running these tests. Install the Target Networking device hardware and associated drivers before commencing the following test-sequence.

The PCI-D3 Network Device Wake On LAN Test Under Windows test, runs the following test case:

  • D3 Wake On LAN test.

a. Launch the D3 Wake On LAN (target.exe) on the Target machine.

b. Launch the D3 Wake On LAN (master.exe) on the Master machine.

The test is an automated, repetitive process that marks the Target NIC as the wake-up device and puts the Target system into S3 sleep state. Another computer, designated as the Master, attempts to wake the machine using a Wake on LAN event. Once the target system wakes up successfully from the S3 sleep state, the test ensures that the Target machine is capable of accurately receiving and sending data over the Target NIC.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The following hardware and software setup is required to run the test.

Required Hardware
  • A desktop platform (Target machine) that supports the ACPI S3-sleep state and passes the WHQL ACPI Compliance tests in which the target network device will be installed.
  • A second system (Master machine) that runs Windows Millennium Edition and has a WHQL certified networking device (includes on-board networking device as well as add-in network adapters) and driver installed on it. This machine does not have to support S3 sleep state.
  • A LAN connection to each machine (either through a local Hub or a network).
  • A FoxFire II PCI adapter is required to monitor power-supply status of the PCI bus. When all the LEDs except the 3.3Vaux LED on the card are off, the PCI bus is shown to have lost primary power. In the following test, the LEDs are used to verify that the system goes to a S3 sleep state, which is confirmed by the LEDs being off.
Required Software
  • WHQL tests for Network Device D3 support.

Results Interpretation

Test Case 1 - System should resume (return to S0 state) and the D3 Wake on LAN test should pass.


TD-4.24 PCI D3 Network Device Functionality Test Under Windows 2000

Overview

The PCI D3 Network Device Functionality Test Under Windows 2000 tests for the following functionality:

  • Verify that the Network Device allows the Target system to correctly enter S3 sleep-state and wakeup.
  • Verify that the Network Device is fully functional after the Target system goes to S3 sleep state and back.

The following tests must be run on a Target system that correctly supports the S3 sleep state. Windows 2000 needs to be installed on the system prior to running these tests. Install the target network Device and associated drivers before commencing the following test-sequence.

The PCI D3 Network Device Functionality Tests Under Windows 2000 test, runs the following test cases:

  1. Suspend/Resume Switch Test (S3 state).

a. Use Power-switch to force system to enter S3 sleep-state.

b. Using the FoxFire II PCI adapter, verify that the system is in the S3 sleep state as indicated by all LEDs (except the 3.3Vaux LED) on the FoxFire II PCI adapter being off.

c. Use Power-switch again to wake the system up.

  2. Suspend/Resume Staging Test (S3 state).

a. Launch Power Management properties (through Control Panel).

b. Under Settings for AlwaysOn Power Scheme, set System Standby = 2min, Turn-Off Monitor=1 min, Turn-off hard disk= Never

c. Allow system to time-out to sleep.

d. Using the FoxFire II PCI adapter, verify that the system is in the S3 sleep state as indicated by all LEDs (except the 3.3Vaux LED) on the FoxFire II PCI adapter being off.

e. Use Power-switch again to wake the system up.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The following hardware and software setup is required to run the test.

Required Hardware
  • A desktop platform that supports the ACPI S3-sleep state and passes the WHQL ACPI Compliance tests in which the target network device will be installed.
  • A LAN connection to the machine either through a local Hub or a network.
  • A FoxFire II PCI adapter is required to monitor power-supply status of the PCI bus. When all the LEDs except the 3.3Vaux LED on the card are off, the PCI bus is shown to have lost primary power. In the following test, the LEDs are used to verify that the system goes to a S3 sleep state, which is confirmed by the LEDs being off.
Required Software
  • WHQL tests for Network Device D3 support.

Results Interpretation

Test Case 1 - System should resume (return to S0 state) and be fully functional.

Test Case 2 - System should resume (return to S0 state) and be fully functional.


TD-4.25 PCI D3 Network Device Wake On LAN Test Under Windows 2000

Overview

The PCI D3 Network Device Wake On LAN Test Under Windows 2000 tests for the following functionality:

  • Verify successful transition from the D3 sleep state to the waking state when the networking device receives an incoming network event while Target system is in the S3 state.
  • Verify that the networking device in the Target system is fully functional after the system resumes from S3 sleep state due to a Wake on LAN event.

The following tests must be run on a Target system that correctly supports the S3 sleep state. Windows 2000 must be installed on the Target system prior to running these tests. Install the Network device hardware and associated drivers on the Target system before starting the following test-sequence.

The PCI D3 Network Device Wake On LAN Test Under Windows 2000 test, runs the following test case:

  • D3 Wake On LAN test.

a. Launch the D3 Wake On LAN (target.exe) on the Target machine.

b. Launch the D3 Wake On LAN (master.exe) on the Master machine.

The test is an automated, repetitive process that marks the Target NIC as the wake-up device and puts the Target system into the S3 sleep state. Another computer, designated as the Master, attempts to wake the machine using a Wake on LAN event. Once the target system wakes up successfully from the S3 sleep state, the test ensures that the Target machine is capable of accurately receiving and sending data over the Target NIC.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The following hardware and software setup is required to run the test.

Required Hardware

  • A desktop platform (Target machine) that supports the ACPI S3-sleep state and passes the WHQL ACPI Compliance tests in which the target network device will be installed.
  • A second system (Master machine) that runs Windows 2000, which has a WHQL certified networking device (includes on-board networking device as well as add-in NICs) and driver installed on it. This machine does not have to support S3 sleep state.
  • A LAN connection to each machine (either through a local Hub or a network).
  • A FoxFire II PCI adapter is required to monitor power-supply status of the PCI bus. When all the LEDs except the 3.3Vaux LED on the card are off, the PCI bus is shown to have lost primary power. In the following test, the LEDs are used to verify that the system goes to a S3 sleep state, which is confirmed by the LEDs being off.

Required Software

  • WHQL tests for Network Device D3 support.

Results Interpretation

Test Case 1 - System should resume (return to S0 state) and the D3 Wake on LAN test should pass.


TD-4.29 PCI 2.2 Compliance (PCITest) Test Description

Test Kit: HCT 10

Overview

This test will attempt to read from and write to various regions of PCI configuration space in order to verify compliance with the PCI Local Bus Specification (rev 2.2), the PCI Power Management Specification (rev 1.1), as well as applicable device class specific specifications (i.e. the PCI IDE Controller Specification).

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The following hardware and software setup is required to run the test.

Required Hardware

None. Only the machine or specific hardware that is being certified is needed.

Required Software

Comes from the HCT kit itself. Specifically the pcitest.exe executable, the appropriate driver for the system, and pcitest.dll are necessary for the test to run properly.

Results Interpretation

The test should pass.


TD-4.50 PCI Compliance Test Description

Test Kit: HCT 11

Overview

This test determines whether or not a single PCI device or all relevant PCI devices in a system are compliant with industry standards for PCI devices as well as several specific Microsoft requirements for PCI devices that may exceed requirements in standard PCI related specifications. The criteria for passing this test is based upon successfully meeting the requirements described in Windows Logo Program System and Device Requirements and one or more of the following publications (depending on system configuration) from the PCI Special Interest Group (SIG) available at http://www.pcisig.com:

PCI Local Bus Specification Revision 2.2

PCI Bus Power Management Specification Revision 1.1

PCI-to-PCI Bridge Architecture Specification Revision 1.1

PCI Hot-Plug Specification Rev. 1.1

PCI Standard Hot-Plug Controller and Subsystem Specification Revision 1.0

PCI Bios Specification Revision 2.1

Mini PCI Specification Revision 1.0

PCI Mobile Design Guide Revision 1.1

Click to show or hide information. Test Steps

The test scans the system to find all currently installed and functional PCI devices. It then narrows the list of devices to test by automatically excluding devices with a base class that does not need testing (base classes 0x05h and 0x0Bh) or a base class/subclass combination that does not need testing (base class 0x06 with all subclasses except 0x04 and 0x07; and base class 0x08 with all subclasses except for 0x04). If the test is launched to verify the entire system, all remaining devices are tested. If single device testing is selected, the test prompts you with the list to choose from. You can alternately launch the test with the PNP ID as an argument to target a single device automatically.

The test then verifies that the PCI Configuration space region of each device behaves as defined in the PCI specification (see documentation). The test is divided into sections that test specific parts of the configuration space that may be found. Specifically, tests are run on the following regions of the configuration space:

Click to show or hide information. Regions covered:

  • Device ID Register
  • Vendor ID Register
  • Status Register
  • Command Register
  • Class Code Register
  • Revision ID Register
  • Header Type Register
  • Base Address Registers
  • Subsystem ID Register
  • Subsystem Vendor ID Register
  • Capabilities Pointer Register
  • Interrupt Pin Register
  • Interrupt Line Register
  • BIST Register
  • Extended Capability Generic Registers
  • Capability Identifier Register
  • Next Item Pointer Register
  • Power Management Extended Capability Registers
  • Power Management Capabilities Register
  • Power Management Control/Status Register
  • Power Management Control/Status PCI to PCI Bridge Support Extensions Register
  • Data Register
  • PCI -PCI Bridge Specific Registers
  • Subordinate Bus Number Register
  • Secondary Bus Number Register
  • Primary Bus Number Register
  • Secondary Status Register
  • I/O Limit Register
  • I/O Base Register
  • Memory Limit Register
  • Memory Base Register
  • Prefetchable Memory Limit Register
  • Prefetchable Memory Base Register
  • I/O Limit Upper 16 Bits Register
  • I/O Base Upper 16 Bits Register
  • Bridge Control Register

The test begins by taking a snapshot of the entire configuration space region for each device being testing. This allows it to determine if any registers contain invalid values. The test will then compare the values in each register against failure cases contained in assertions documented for the compliance test. In the case of registers that have specified behavior of either "read only" or "read/write," the test will attempt to perform both reads and writes to determine if the register responds as defined.

Before attempting any write operations to configuration space, the test firsts disables the device so that it is no longer attempting to decode memory or I/O ranges assigned to it. This is necessary because several of the tests may change the values that the card believes belong to it, and could otherwise cause the card to decode ranges that don't belong to it. After testing is complete on the card, the test releases control of the device and asks the Windows Configuration Manager to re-enable the device, thus causing the operating system to reinitialize all appropriate registers to proper values. This will avoid system instability.

Because devices in the boot or paging paths cannot be disabled, testing of these devices will be skipped in system tests. If the test is targeted at one of these devices for single device tests, the test will fail and you will be prompted to reconfigure the system so that the device is not in the paging path.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires the system implement the following configuration:

  • Windows 2000 or later
  • PCI HCT bus filter driver installed (requires reboot)
  • Administrative account privileges
  • PCI bus present on the system

Results Interpretation

The test creates a detailed log file of test results and displays on-screen pass or fail status.


Chapter 5: Graphics Adapter Test Specification

The Graphics Adapter Test Specification contains two test specifications. The first specification focuses on software (Part A: Software), and the second focuses on hardware (Part B: Hardware). Since the operations between graphics adapters and the operating system are optimized, the divisions, dependencies, and assumptions of the assertions become less clear. For this reason the hardware-centric assertions may make references to software requirements and software-centric assertions may make references to hardware requirements. If there are conflicts between the hardware and software specifications, refer to Microsoft Windows Logo Program System and Device Requirements for guidance.

This chapter describes display platform hardware and display device tests for requirements defined in Microsoft Windows Logo Program System and Device Requirements.

This chapter is intended as an overview of tests for Original Equipment Manufacturers (OEMs) and Independent Hardware Vendors (IHVs), and as a guide to actual test development for software engineers. It is not designed to provide a complete test plan or testing procedure for graphics subsystems.

The Display Test Specification is divided into two main sections. The first covers test coverage, functional requirements, and test assertions; the second covers the actual test implementations.

Test Coverage

This test specification and associated tests rely on the presence of a Direct3D HAL (Hardware Abstraction Layer) and graphics driver in order to access and test 3D hardware acceleration features. Systems that only support OpenGL are not covered by this test specification.

The test assertions listed in this section are derived from the Microsoft Windows Logo Program System and Device Requirements and the following reference materials:

  • DirectX Software Development Kit (SDK)
  • DirectX Driver Development Kit (DDK)
  • Windows Driver Development Kit (DDK)

Test Methodology

Each individual test case is composed of two parts: confirmation that the required feature is present, as reported by the graphics driver, and verification that the feature is truly supported by the hardware (or by a combination of hardware and driver software). The critical issue is that reported capabilities always match correctly implemented capabilities.

The methodologies for verifying compliance with a particular test assertion can be divided into four general categories:

  • Visual – The test relies upon user interaction to visually inspect or compare images. In all instances where a visual test is necessary, the pass or fail criteria is explicit to help the tester make objective decisions. For example, a displayed test image is designed to accentuate wrong implementations and make the failure case obvious.
  • Comparison to pre-computed baseline – The test renders an image and compares pixels in the resultant primary surface buffer to a computed result. A tolerance value can be specified to allow for mathematical precision differences in 3D graphics accelerators.
  • Comparison to Direct3D reference rasterizer – The test renders an image and compares pixels in the source image to an image created by the Direct3D reference (software rasterizer). A tolerance value is always specified to allow for mathematical precision differences between 3D graphics accelerators and the Direct3D reference. For all tests that use this methodology, a difference image is generated that reveals the specific pixel errors (see Common Direct3D Test Options below). The Direct3D reference code is provided in the DirectX DDK.
  • Procedural – The test is able to procedurally determine required pixel values in result images and does not require comparison to a pre-computed or Direct3D reference image.

While each test case may use a single test method or several in combination, the majority of the tests use the Direct3D reference comparison method. The choice of a methodology is based on the complexity of the feature tested and the test assertions defined for the original Windows Logo Program requirement.

Common Direct3D Test Options

The majority of 3D graphics tests are written with a framework that provides some useful command line options. Run these tests with the -? option (for example, foo.exe -?) to see the available options which are useful to examine scenarios which may assist in determining why a feature is not exhibiting compliant behavior. One of the most commonly used options of the test framework is <F8> which indicates the difference between the source and Direct3D reference images, which should be displayed as the test runs.

The following table identifies assertions and requirements tested for Windows Millennium Edition and Windows 2000.

Table 5-1. Windows Graphics Adapter Test Assertion Summary

Assertion Numbers | Requirements | Test Coverage Section and Test Name
5.1.1-2 | WLD - B1.1.1 | TD -5.1: Terminal Services – Console Disconnect/Reconnect
5.2.1 | WL-B4.2.1 | GDI Escapes
5.3.1 |  | Illegal Imports
5.4.1 | WLD – B4.1.4.8 | PC99TA 14.33 Z Compare Caps
5.4.2 | WLD – B4.1.4.8 | PC99TA 14.27.3 Alpha Blending Caps
5.4.3 | WLD – B4.1.4.8 | PC99 14.27.2 MipFilter Caps
5.9.1-35 | DX DDK | 5.9 Ddraw
5.9.1 | WLD – B4.1.4.7 | TD – 5.9: Blt – Basic – System to Primary
5.9.2 | WLD – B4.1.4.7 | TD – 5.9: Blt – Basic – Vmem to Primary
5.9.3 | WLD – B4.1.4.11 | TD – 5.9: Blt – Color Key – Sys to Primary
5.9.4 | WLD – B4.1.4.11 | TD – 5.9: Blt – Color Key – Vmem to Primary
5.9.5 | WLD – B4.1.4.2 | TD – 5.9: Blt – Stretch – System to Primary
5.9.6 | WLD – B4.1.4.2 | TD – 5.9: Blt – Stretch – Vmem to Primary
5.9.7 | WLD – B4.1.4.2 & 11 | TD – 5.9: Blt – Stretch & Color Key – Sys to Primary
5.9.8 | WLD – B4.1.4.2 & 11 | TD – 5.9: Blt – Stretch & Color Key – Vid to Primary
5.9.9 |  | TD – 5.9: DDraw Blt – ColorFill - AGP
5.9.10 |  | TD – 5.9: DDraw Blt – ColorFill – Video Memory
5.9.11 |  | TD – 5.9: BLT Unused Pixel Bits
5.9.12 | WLD – B4.1.4.7 | TD – 5.9: Read Scan Line
5.9.13 | WLD – B4.1.4.2 | TD – 5.9: Surface Flipping
5.9.14 | WLD – B4.1.4.7 | TD – 5.9: Video Memory Management
5.9.15 | WLD – B4.1.4.5 | TD – 5.9: Palette
5.9.16 | WLD – B4.1.4.11 | TD – 5.9: Overfly
5.9.17 |  | TD – 5.9: Blt – Raster Ops – Vid Mem
5.9.18 | WLD – B4.1.4.11 | TD – 5.9: VPE and Kernel
5.9.19 |  | TD – 5.9: Blt – Exotic
5.9.20 | WLD – B4.1.4 | TD – 5.9: Stereo
5.9.21 |  | TD – 5.9: Automatic Stereo
5.9.22 |  | TD – 5.9: DDRAW Cubic
5.9.23 |  | TD – 5.9: PC00 #3 system uses WC
5.9.24 |  | TD – 5.9: PC99 14.23 Low-res mode support
5.9.25 |  | PC99 #14.8 min res & local mem amt
5.9.26 | WLD – B4.1.4.6 | TD – 5.9: PC99 #12 Downloadable RAMDAC
5.9.27 | WLD – B4.1.4.7 | TD – 5.9: PC99 #25 Double Buffer Swaps with no tearing
5.9.28 |  | TD – 5.9: DDraw AGP Memory
5.9.29 |  | TD – 5.9: DDraw Blt – Basic – AGP to Primary
5.9.30 |  | TD – 5.9: DDraw Blt – Color Key – AGP to Primary
5.9.31 |  | TD – 5.9: DDraw Blt – Stretch – AGP to Primary
5.9.32 |  | TD – 5.9: DDraw Blt – Stretch & Color Key – AGP to Primary
5.9.33 | WLD – B4.1.4.5 | TD – 5.9: PC99 #10 supported pixel orderings
5.9.34 |  | TD – 5.9: DDraw Blt – ColorFill – System Memory
5.9.35 |  | TD – 5.9: Blt - Textures
5.10.1 | SDK | 5.10 Video Output
5.13.1 | DirectX8 DDK, SDK | 5.11 DirectX 8 CopyRects Functionality
5.15.1 | PC99 14.27.2, 14.30, 14.31 | 5.15 Texture Handle Test
5.20.1-6 | DirectX DDK & SDK | 5.20 Display Basic 3D
5.21.1 | DirectX DDK & SDK | 5.21 Wire Frame
5.22.1-12 | DirectX DDK & SDK | 5.22 Texture
5.23.1 | DirectX DDK & SDK | 5.23 Z Compare
5.24.1 | DirectX DDK & SDK | 5.24 Basic Rasterization
5.25.1 | DirectX DDK & SDK | 5.25 Overdraw/Underdraw
5.26.1-2 | DirectX DDK & SDK | 5.26 Perspective
5.27.1 | DirectX DDK & SDK | 5.27 SubPixel Texture
5.28.1 | DirectX DDK & SDK | 5.28 Display Texture Handle
5.29.1-19 | DirectX DDK & SDK | 5.29 Alpha Blending
5.30.1 | DirectX DDK & SDK | 5.30 Z Write Test
5.31.1 | DirectX DDK & SDK | 5.31 W Buffer
5.32.1 | DirectX DDK & SDK | 5.32 Palettized textures – Force Update
5.33.1-5 | DirectX DDK & SDK | 5.33 Fogging
5.34.1-8 | DirectX DDK & SDK | 5.34 Lighting
5.35.1 | DirectX DDK & SDK | 5.35 Compressed Texture
5.36.1 | DirectX DDK & SDK | 5.36 Stencil
5.37.1-3 | DirectX DDK & SDK | 5.37 Multi-texturing Tests
5.38.1 | DirectX DDK & SDK | 5.38 Mip-mapped Texture Tests
5.39.1 | DirectX DDK & SDK | 5.39 Display Simultaneous Features
5.40.1 | DirectX DDK & SDK | 5.40 Specular Highlighting
5.41.1 | DirectX DDK & SDK | 5.41 Clear Offscreen/Texture Surface
5.42.1-2 | DirectX DDK & SDK | 5.42 Multi-sampling
5.43.1 | DirectX DDK & SDK | 5.43 Present Validation
5.44.1 | DirectX DDK & SDK | 5.44 Matrix Palette Skinning
5.45.1 | DirectX DDK & SDK | 5.45 The Blt Queue Test
5.46.1 | DirectX DDK & SDK | 5.46 The Lockable Depth Buffer Test
5.47.1-2 | DirectX DDK & SDK | 5.47 The Point Sprite Test
5.53.1-2 | DirectX DDK & SDK | 5.53 Set Render Target Tests
5.54.1 | DirectX DDK & SDK | 5.54 GetRasterStatus
5.55.1 | DirectX DDK & SDK | 5.55 Vertex Buffer and Index
5.56.1-3 | DirectX DDK & SDK | 5.56 Clipping
5.57.1-3 | DirectX DDK & SDK | 5.57 Multipass Z-Fighting
5.58.1 | DirectX DDK & SDK | 5.58 State Blocks
5.59.1 | DirectX DDK & SDK | 5.59 Vertex Buffer Rendering Tests
5.60.1 | DirectX DDK & SDK | 5.60 Vertex Tweening Tests
5.61.1 | DirectX DDK & SDK | 5.61 Vertex Blending Tests
5.62.1 | DirectX DDK & SDK | 5.62 Texture Coordinate Generation Tests
5.63.1 | DirectX DDK & SDK | 5.63 Pixel Shader
5.64.1 | DirectX DDK & SDK | 5.64 Surfaces
5.65.1 | DirectX DDK & SDK | 5.65 Texture Update
5.66.1 | DirectX DDK & SDK | 5.66 Vertex Shaders
5.67.1 | DirectX DDK & SDK | 5.67 Volume Texture
5.68.1 | DirectX DDK & SDK | 5.68 MipMapping
5.69.1 | DirectX DDK & SDK | 5.69 High Order Surfaces
5.70.1 | DirectX DDK & SDK | 5.70 Memory/Texture Management
5.71.1 | DirectX DDK & SDK | 5.71 DDI Version Level Check
5.72.1 | DirectX DDK & SDK | 5.72 Morph – Invalid Parameters
5.100.1-6 | DirectX7 DDK & SDK | 5.20 Display Basic 3D Requirements
5.101.1-7 | DirectX7 DDK & SDK | 5.22 Texture
5.102.1 | DirectX7 DDK & SDK | 5.36 Stencil
5.103.1 | DirectX7 DDK & SDK | 5.37 Multi-texturing
5.104.1 | DirectX7 DDK & SDK | 5.40 Specular Highlighting
5.105.1 | DirectX7 DDK & SDK | 5.39 Display Simultaneous Features
5.106.1 | DirectX7 DDK & SDK | 5.106 Overdraw/Underdraw
5.107.1 | DirectX7 DDK & SDK | 5.36 Stencil
5.108.1-2 | DirectX7 DDK & SDK | 5.53 Set Render Target
5.109.1 | DirectX7 DDK & SDK | TD-5.56 Clipping Test Description "TL Vertex Clip"
5.110.1 | PC99 , DirectX7 DDK & SDK | TD-5.37 Multi-texturing Tests Description
5.111.1 | PC99 , DirectX7 DDK & SDK | TD-5.22 Texture Tests Description
5.112.1 | PC99 , DirectX7 DDK & SDK | TD-5.42 Multi-sampling Tests Description
5.113.1 | DirectX7 DDK & SDK | 5.113 Palettized Textures
5.120.1-6 | DirectX6 DDK & SDK | 5.20 Display Basic 3D Requirements
5.121.1-4 | DirectX6 DDK & SDK | 5.22 Texture Tests
5.122.1 | DirectX6 DDK & SDK | 5.36 Stencil
5.123.1 | DirectX6 DDK & SDK | 5.31 W Buffer
5.124.1 | DirectX6 DDK & SDK | TD-5.56 Clipping Test Description "TL Vertex Clip"
5.129.1-7 | Windows DDK | 5.129 OpenGL
5.130.1-7 | Windows DDK | 5.130 Display Windows 9x GDI
5.131.1-4 | Windows DDK | 5.130 Display Windows 9x GDI
5.132.1-4 | Windows DDK | 5.130 Display Windows 9x GDI
5.134.1 | Windows DDK | 5.130 Display Windows 9x GDI
5.135.1 | Windows DDK | 5.130 Display Windows 9x GDI
5.136.1-3 | Windows DDK | 5.130 Display Windows 9x GDI
5.137.1 | Windows DDK | 5.137 Direct Show Test Description
5.150.1-17 | Windows DDK | 5.150 Display Windows 2000 GDI
5.170.1-13 | WLD – B4.1.4.11 | 5.170 Video Rendering Display
5.170.14-17 | WLD – B4.1.4.19 | 5.170 Video Rendering Display
5.171.1 | WLD – B4.1.1.9 | 5.170 Video Rendering Display
5.190.1-3 | DirectX DDK & SDK | Assertion 3.41.1-3
5.191.1-3 | DirectX DDK & SDK | Assertion 3.42.1-3
5.192.1-6 | DirectX DDK & SDK | Assertion 3.43.1-6
5.192.7 | DirectX DDK & SDK | 5.192 APM/ACPI Display Class Power
5.200.1-4 | PC99 14.54 | 5.200 Display PCI D3 Graphics Adapter Functionality, Windows 98
5.200.1-3 | APG Spec. 8.1 | 5.210 Display AGP Interface


Reference Documents for Display Assertions

Accelerated Graphics Port Interface Specification, Revision 1.0 or later

http://developer.intel.com/technology/agp/agp_index.htm

Digital Video Interface (DVI) Revision 1.0

http://www.ddwg.org/

Display Data Channel Standard, V. 3.0, Level 2B protocols

Video Electronics Standards Association (VESA) BIOS Extension Standard/Core Functions 2.0 (VBE/Core 2.0) at http://www.vesa.org/standards.htm

Display Device Class Power Management Specification, V. 2.0

http://www.microsoft.com//hwdev/resources/specs/pmref/PMdisplay.asp

Ergonomic timings for supported resolutions, based on VESA standards

http://www.vesa.org/standards.htm
VESA Computer Display Monitor Timing Specification Version 1.0, Revision 0.8
VESA Generalized Timing Formula Standard, Version 1.1
Or DVI 1.0 (if DVI is implemented)

Microsoft Windows Logo Program System and Device Requirements, Version 2.0

http://www.microsoft.com/hwdev/winlogo/
(listed as "WLP#" in these assertions)

Microsoft Windows Driver Development Kit

http://www.microsoft.com/ddk/
Windows 98/Me: "Display Drivers" and "Multiple Monitor Support Implementation Design Notes" in the Windows Me DDK
Windows XP/Windows 2000: "Display and Video Miniport Drivers" (includes DirectX DDKs) and "Multiple Monitor Support in the Display Driver" in the Windows DDK

Microsoft Windows Hardware Development: Display

http://www.microsoft.com/hwdev/tech/display/default.asp Development support and White Papers for Display Hardware Development.

PC 2001 System Design Guide and PC 99 System Design Guide

http://www.microsoft.com/hwdev/platform/pcdesign/desguide/pcguides.asp


Display Test Assertions: Part A - Software

The software assertions in this section (Part A: Software) complement the requirements described in the hardware section (Part B: Hardware). If any conflicts between the hardware and software specifications arise, refer to Microsoft Windows Logo Program System and Device Requirements.


Terminal Services – Console Disconnect Assertions

5.1.1 Disconnecting the console session should unload the display driver for the current session, create a new session, reload the display driver and show the logon UI on this session.

Reference Document: Personal Terminal Services – Console Disconnect Specification, Page 5: Physical display driver supports driver unloading and reloading
Test Description: TD-5.1 Terminal Services – Console Disconnect

5.1.2 While logging on to a disconnected session, the display driver should be unloaded for the current console session, then reloaded for the disconnected session.

Reference Document: Personal Terminal Services – Console Disconnect Specification, Page 5: Physical display driver supports driver unloading and reloading
Test Description: TD-5.1 Terminal Services – Console Disconnect


ExtEscape Test Assertions

Calling ExtEscape for GDI drivers, such as Display or Print drivers, should not cause kernel mode breaks (system stops responding) when called with valid or invalid data.

This section contains the detailed list of test assertions.

5.2.1 Calling ExtEscape for GDI drivers, such as Display or Print drivers, should not cause kernel mode breaks (a.k.a. Blue Screen of Death) when called with valid or invalid data.

Reference document: WL-B4.2.1 (PC 2001 Ch 10)
Test description: TD-5.2 ExtEsc Test Description


Illegal Imports Test Assertions

5.3.1 Illegal Imports Test

Tracks illegal imports in miniport video drivers.

Reference document: WLP# - B12.1.5.2
Test description: TD-5.3 Illegal Imports Test Description


Caps Detection Test Assertions

5.4.1 PC99 14.33 Z Compare Caps

The driver will declare (through 3D caps) support for all Z comparison modes.
TRI Z CMP CAPS : ALWAYS
TRI Z CMP CAPS : EQUAL
TRI Z CMP CAPS : GREATER
TRI Z CMP CAPS : GREATEREQUAL
TRI Z CMP CAPS : LESS
TRI Z CMP CAPS : LESSEQUAL
TRI Z CMP CAPS : NEVER
TRI Z CMP CAPS : NOTEQUAL

Reference document: PC99 Chapter 14 Section 33
Test description: TD-5.4 Compare Caps Test Description

5.4.2 PC99 14.27.3 Alpha Blending Caps

The driver will declare (through 3D caps) support for the following blending modes:
TRI SRC BLEND CAPS : DESTCOLOR
TRI SRC BLEND CAPS : INVDESTCOLOR
TRI SRC BLEND CAPS : INVSRCALPHA
TRI SRC BLEND CAPS : ONE
TRI SRC BLEND CAPS : SRCALPHA
TRI SRC BLEND CAPS : ZERO
TRI DEST BLEND CAPS : INVSRCALPHA
TRI DEST BLEND CAPS : INVSRCCOLOR
TRI DEST BLEND CAPS : ONE
TRI DEST BLEND CAPS : SRCALPHA
TRI DEST BLEND CAPS : SRCCOLOR
TRI DEST BLEND CAPS : ZERO

Reference document: PC99 Chapter 14 Section 27.3
Test description: TD-5.4 Compare Caps Test Description

5.4.3 PC99 14.27.2 MipFilter Caps

The driver will declare (through 3D caps) support for MIP-mapped textures.
TRI TFILTER CAPS : MIPLINEAR
TRI TFILTER CAPS : MIPNEAREST

Reference document: PC99 Chapter 14 Section 27.2
Test description: TD-5.4 Compare Caps Test Description


DirectDraw Graphics Adapter Test Assertions

The DirectDraw Graphics Adapter Test Assertions tests for basic DirectDraw functionality.

5.9.1 Blt - Basic - System to Primary test

This test ensures that a simple DirectDraw Blt from system to video memory is performed correctly. Support for these blts is not required.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.2 Blt - Basic - VMem to Primary test

Performs a variety of Blt tests where both the source and destination are in video memory. Drivers are required to support these blts.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.3 Blt - Color Key - Sys to Primary test

Test ensures that the DirectDraw graphics adapter is able to perform SOURCE and DESTINATION Color Key blts from system memory to Video Memory.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.4 Blt - Color Key - VMem to Primary test

Test ensures the DirectDraw graphics adapter is able to perform SOURCE and DESTINATION Color Key blts from video memory to the primary surface.

Drivers are required to support Source Color key blts.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.5 Blt - Stretch - System to Primary test

Test ensures the DirectDraw graphics adapter is able to process a variety of DirectDraw stretch (and shrink) blts from system memory to the primary surface.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.6 Blt - Stretch - VMem to Primary test

Test ensures that the DirectDraw graphics adapter is able to process a variety of DirectDraw stretch (and shrink) blts from video memory to the primary surface.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.7 Blt - Stretch & Color Key - Sys to Primary test

Test ensures that the DirectDraw graphics adapter is able to process combinations of stretched (and shrunk) blts as well as SOURCE and DESTINATION Color Key blts from system memory to the primary surface.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.8 Blt - Stretch & Color Key - Vid to Primary test

Test ensures that the DirectDraw graphics adapter is able to process combinations of stretched (and shrunk) blts as well as SOURCE and DESTINATION Color Key blts from video memory to the primary surface.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.9 Blt – Colorfill - AGP

The purpose of these tests is to verify that color fill blt operations can be successfully performed on AGP (non-local video) memory surfaces.

Reference document: AGP Support chapter of the DirectX 8.0 DDK
Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.10 Blt – Colorfill – Video Memory

The purpose of these tests is to verify that color fill blt operations can be successfully performed on video memory surfaces.

Reference document: The DirectX 8.0 DDK and the DirectX8.0 SDK

Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.11 Blt – Unused Pixel Bits

This test verifies that the display driver ignores unused portions of a pixel when performing a color key blt operation. Unused portions of a pixel (such as the high byte in 32bpp modes) should not be included in the color key comparison.

Reference document: The DirectX 8.0 DDK

Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.12 Read Scan Line test

Test ensures that the DirectDraw graphics adapter blts are able to report the current scan-line being drawn.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.13 Surface Flipping test

Test ensures that the DirectDraw graphics adapter supports blt surface flipping, flip status reporting, and vertical blank querying.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.14 Video Memory Management test

Test verifies that video memory is accurately reported and managed.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.15 Palette test

The Palette test ensures that the DirectDraw graphics adapter verifies palette manipulation.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.16 The Overfly test

The Overfly test ensures the proper functionality of overlays. This test requires MANUAL VERIFICATION.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.17 The Blt - Raster Ops - Vid Mem test

Test ensures that the DisplayDriver correctly performs all reported DirectDraw Blt Raster Operations. Only SRCCOPY is required.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.18 The VideoPort and VP Kernel tests

Tests perform a variety of sub tests including VideoPort flipping, scan-line and vblank synchronization, and bandwidth and pixel format reporting.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.19 The Blt - Exotic test analyzes the GetBltStatus, Zbuffer Blt, Blt FOURCC, BLT FourCC to RGB stretch, and Copy FOURCC functions.

Blts between pixel formats that are different from the primary.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.20 The Stereo test

Test ensures that the DirectDraw graphics adapter is capable of displaying a stereo image.

Reference Documents: DirectX DDK, DirectX SDK..
Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.21 The Automatic Stereo test

Test ensures that the DirectDraw graphics adapter must verify consistent stereo caps reporting, and ensure that stereo flipping can be enabled and disabled.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.22 The Cubic test

Test ensures that the DirectDraw graphics adapter handles cubic mapping surfaces created with all allowable combinations of flags.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.23 The PC99 #3 system test

Test determines whether a display adapter driver meets PC98 requirement no. 2 for Graphics Adapters (System uses WC with higher-performance processors).

The test works by invoking DirectDraw to allocate an off-screen buffer in video memory, performing row-wise and column-wise fills of the buffer and computing the ratio of the speed of the row-wise fill to the speed of the column-wise fill. If the buffer is implemented with write-combining, the row-wise fill will be dramatically faster than the column-wise fill---a pass is reported as long as the ratio >=2.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.24 PC99 14.23 Low-Res Mode Support

This test verifies that the following low-res modes are supported by the display adapter:

  • 320x200 [8 and 16 bpp]
  • 320x240 [8 and 16 bpp]
  • 640x400 [8 and 16 bpp]

Reference document: PC99 System Design Guide – Section 14.23

Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.26 PC99 #12 Downloadable RAMDAC

This test verifies that the display adapter supports DirectDraw’s gamma ramp API. Test maps blue and green components to zero leaving only red.

For details on implementing Gamma Support, see the "Gamma Control" chapter of the DirectX8.0 DDK documentation.

Reference document: DirectX 8.0 DDK, and the DirectX 8.0 SDK
Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.27 PC99 #25 Double Buffer Swaps with no tearing

Test tries to ensure that page flips occur during the vertical blank period. Test does this by comparing the rate at which flips are accepted to the current refresh rate.

Reference document: PC 99 14.25
Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.28 DDraw AGP Memory test

The DDraw AGP Memory test ensures that the DirectDraw graphics adapter creates basic AGP surfaces.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.29 DDraw Blt Basic - AGP to Primary test

Test ensures that the DirectDraw graphics adapter FNDDRAW blt function is capable of handling several conversion blts from various memory surfaces.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.30 DDraw Blt - Color Key - AGP to Primary test

Test ensures that the DirectDraw graphics adapter is able to process Color key blts from AGP surfaces to the primary surface.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.31 DDraw Blt - Stretch - AGP to Primary test

Test ensures that the DirectDraw graphics adapter is able to process blts stretched from AGP surfaces to the primary surface.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.32 DDraw Blt - Stretch & Color Key - AGP to Primary test

Test ensures that the DirectDraw graphics adapter is able to process various combinations of stretch and color key blts from AGP surfaces to the primary surface.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.33 PC99 #10 Supported Pixel Orderings

Drivers must support these pixel orderings for their various display modes.

  • 15-Bit RGB 555
  • 16-Bit RGB 565
  • 24-Bit RGB 888
  • 32-Bit ARGB 8888

Reference Documents: PC99 14.10
Test description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.34 Blt – Colorfill – System Memory

The purpose of these tests is to verify that color fill blt operations can be successfully performed on system memory surfaces.

Reference document: The DirectX 8.0 DDK and the DirectX8.0 SDK
Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

5.9.35 Blt – Textures

Display Adapters/Drivers that support hardware accelerated blts, must support blitting of textures. The same level of Blt support afforded to plain-offscreen surfaces, must also be provided for texture surfaces (Such as Stretching and/or Color Keying). The DirectDraw Blt caps apply equally to all surfaces whether they be plain-offscreen, overlays, or textures.. As with offscreen-plain surfaces, pixel format conversion is NOT required. Drivers need only support Blts between textures where the source and destination are the same pixel format.

NOTE: Textures with pixel formats that do not lend themselves to expressing a single pixel in a DWORD are exempt from the color key requirement. Examples of this are the many YUV formats where multiple pixels share components. DirectDraw does not facilitate a means of expressing a color key for these formats.

Reference document: The DirectX 8.0 DDK and the DirectX8.0 SDK
Test Description: TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description


Video Output Test Assertions

5.10.1 CDS Video Parameters

Tests the display driver’s ability to handle a call to ChangeDisplaySettingsEx() with the CDS_VIDEOPARAMETERS parameter. It also checks for MacroVision support if available.

Reference Documents: Platform SDK
Test description: TD-5.10 Video Output Test Description


DirectX 8 CopyRects Functionality Test Assertions

5.13.1 Automatic Verification of IDirect3DDevice8::CopyRects

The CopyRects test verifies correct implementation of the driver functionality that supports the IDirect3DDevice8::CopyRects method. It is an automated test that compares the results of each tested operation with a test-generated reference result.

Reference Documents: DirectX 8.0 DDK, DirectX 8.0 SDK.
Test description: TD-5.13 DirectX 8 CopyRects Functionality Test Description


Direct3D Graphics Hardware Test Assertions

Only RGB rasterization requirements specified in the Graphics Adapter section of PC 2001 System Design Guide are covered by this test specification. The following is a summary of the assertions to be tested. This section of the Document will be making references to the DirectX DDK and the DirectX SDK. For the purpose of this document, items that do not specify a DirectX version refer the most recent version. As newer versions of DirectX are developed and released, the assertions in this section will be updated as required such that the device driver interface (DDI) can be adequately tested.

Basic 3D Test Assertions – DirectX

5.20.1 Features to be supported in full-screen mode

The following adapter features must be supported in full-screen mode: 3D graphics mode, 800 x 600 resolution 16 bpp color depth, double buffering, 16-bit Z buffer, and 75 Hz refresh rate.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.20 Display Basic 3D Requirements Test Description

5.20.2 Rasterization features must be available at the same time

All required rasterization features must be available at the same time. This includes Textures, Alpha blending, Lighting, and Fogging.

Reference Documents: The DirectX DDK, the Reference Rasterizer Source section of the DirectX DDK, and the DirectX SDK.
Test Description: TD-5.20 Display Basic 3D Requirements Test Description

5.20.3 Graphics adapter/driver must conform to Microsoft Direct3D rasterization rules.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.20 Display Basic 3D Requirements Test Description

5.20.4 Exposed features must work in concert with each other.

The Driver Scenario test verifies that exposed features work in concert with each other. Providing the hardware supports the required caps for each feature (it will log any caps which failed to detect), the test runs all combinations of the features in a dynamic scene. The scene is composed of a central, unmoving sphere and six orbiting cubes. Additionally, there are three planes oriented (usually) such that they face the viewer. Each of the objects takes on various attributes over the course of the test.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.20 Display Basic 3D Requirements Test Description

5.20.5 MIP-mapped textures must be supported.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.20 Display Basic 3D Requirements Test Description

5.20.6 Bilinear or better-filtered textures must be supported.

Bilinear or better-filtered textures rather than point-sampled with perspective correction must be supported.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.20 Display Basic 3D Requirements Test Description


Wire Frame Test Assertions - DirectX

5.21.1 The Wireframe Test

The Wireframe test verifies viewport clipping and rasterization in wireframe mode.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.21 Wire Frame Test Description


Textures Test Assertions - DirectX

5.22.1 The Texture Gradient test

Test renders a texture, rotates texture mapping, tiles texture from one to four times, varies mesh size, and compares with the Reference rasterizer. The does this with the following sizes of rendered textures:

  • 8x8
  • 16x16
  • 32x32
  • 64x64
  • 128x128
  • 256x256
  • 512x512
  • 1028x1028

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.22 Texture Tests Description

5.22.2 The Texture Mapping Test

Test renders a Point sampled and Bi-Linear filtered texture while cycling through all possible non-tiled combinations of UV texture coordinates, tiles texture from 1/8 to 8, and compares with the Reference rasterizer.

Reference Documents: The DirectX DDK, the Reference Rasterizer Source section of the DirectX DDK, and the DirectX SDK.
Test Description: TD-5.22 Texture Tests Description

5.22.3 The Texture Filter – No MipMapping Test

Test renders a striped texture with various filter modes, uses both a 16x16 texture, and then a 256x256 texture, varies the mesh size, and compares with the reference rasterizer. The different filter modes used are:

  • MinFilter: Nearest and MagFilter: Nearest
  • MinFilter: Nearest and MagFilter: Linear
  • MinFilter: Linear and MagFilter: Nearest
  • MinFilter: Linear and MagFilter: Linear

Reference Documents: The DirectX DDK, the Reference Rasterizer Source section of the DirectX DDK, and the DirectX SDK.
Test Description: TD-5.22 Texture Tests Description

5.22.4 The Texture Filter – MipMapping Test

Test renders a striped mip-mapped texture with the various mip filter modes, uses three different colored mip-maps, the highest being 256x256, varies the mesh size, and compares with the Reference rasterizer. The different mip filter modes used are:

  • MipNearest
  • MipLinear
  • LinearMipNearest
  • LinearMipLinear

Reference Documents: The DirectX DDK, the Reference Rasterizer Source section of the DirectX DDK, and the DirectX SDK.
Test Description: TD-5.22 Texture Tests Description

5.22.5 The Texture Address test

Test verifies different texture addressing, draws a textured mesh, rotates texture mapping, and compares with the Reference rasterizer.

  • Wrap U texture addressing
  • Wrap V texture addressing
  • Wrap U and Wrap V texture addressing
  • Wrap texture addressing
  • Clamp texture addressing
  • Mirror texture addressing
  • Border texture addressing (border color is altered with default, blue, red, and green, after rotating texture mapping)
  • IndependentUV texture addressing with Wrap for U and Mirror for V
  • IndependentUV texture addressing with Wrap for U and Clamp for V
  • IndependentUV texture addressing with Wrap for U and Border for V
  • IndependentUV texture addressing with Mirror for U and Wrap for V
  • IndependentUV texture addressing with Mirror for U and Clamp for V
  • IndependentUV texture addressing with Mirror for U and Border for V
  • IndependentUV texture addressing with Clamp for U and Wrap for V
  • IndependentUV texture addressing with Clamp for U and Mirror for V
  • IndependentUV texture addressing with Clamp for U and Border for V (border color is altered with default, blue, red, and green, after rotating texture mapping)
  • IndependentUV texture addressing with Border for U and Wrap for V (border color is altered with default, blue, red, and green, after rotating texture mapping)
  • IndependentUV texture addressing with Border for U and Mirror for V (border color is altered with default, blue, red, and green, after rotating texture mapping)
  • IndependentUV texture addressing with Border for U and Clamp for V (border color is altered with default, blue, red, and green, after rotating texture mapping)

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.22 Texture Tests Description

5.22.6 The Texture Load test

Test tests texture loading from various surface types to local video memory. It also tests the case of texture loading from a mip-map with more source levels than the destination. Finally, it loads textures from system memory to video memory. These are the different cases it tests:

  • Video test loads textures from video memory to video memory
  • AGP test loads textures from AGP memory to video memory
  • MipMap_System test loads a 9-mip level system texture to a 7-mip level video texture
  • MipMap_Video test loads a 9-mip level video texture to a 7-mip level video texture
  • MipMap_AGP test loads a 9-mip level AGP texture to a 7-mip level video texture
  • Manage test loads textures from system memory to video memory and uses "Managed Textures"
  • MipMap_Manage test loads a 9-mip level system texture to a 7-mip level video texture and uses "Managed Textures"

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.22 Texture Tests Description

5.22.7 The Texture Blend

Test renders a striped types of textures, varies alpha values (none, mesh alpha, texture alpha, or both), rotates texture mapping, alters mesh color, tiles texture from 1 to 4, cycles texture formats, and compares with the reference rasterizer. The different types of textures rendered are as follows:

  • Decal Texture
  • Modulate Texture
  • DecalAlpha Texture
  • ModulateAlpha Texture
  • Copy Texture
  • Add Texture
  • Default Texture (using default blend settings)

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.22 Texture Tests Description

5.22.8 The Texture Formats

Test renders a striped texture, rotates texture mapping, cycles texture formats, and compares with the reference rasterizer. It also validates the following texturing functions:

  • Verifies all texture formats not support by the reference rasterizer
  • Makes sure the driver doesn’t interfere with system memory textures
  • Ensures that 2D textures are properly rendered when using 3D FvF values
  • Ensures that 2D textures are properly rendered when using 4D FvF values

Reference Documents: The DirectX DDK, the Reference Rasterizer Source section of the DirectX DDK, and the DirectX SDK.
Test Description: TD-5.22 Texture Tests Description

5.22.9 The Texture ColorKey test

Test verifies proper color keying of textures when a color key is requested. It then compares them with the reference rasterizer and cycles through all available texture formats. This is done for the following color keys:

  • Default Settings
  • White
  • Red
  • Green
  • Blue
  • Yellow
  • Magenta
  • Cyan
  • Grey
  • Black

Reference Documents: The DirectX DDK, the Reference Rasterizer Source section of the DirectX DDK, and the DirectX SDK.
Test Description: TD-5.22 Texture Tests Description

5.22.10 The Texture Management test

Tests for driver texture management. This is a Dx7 feature that is not supported in Dx8. As of DirectX 8 all texture management is performed by the runtime.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.22 Texture Tests Description

5.22.11 The Textured Lines test

Conformance test verifies texturing of line primitives.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.22 Texture Tests Description

5.22.12 The Textured Points test

This is a conformance test that tests texturing of point primitives.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.22 Texture Tests Description


Z Compare Test Assertions - DirectX

5.23.1 The Z Compare test

Test verifies the Z compare mode of different types by rendering triangles with various Z values and comparing with the Direct3D reference. The different types of Z compares tested are:

  • Never
  • Less
  • Equal
  • LessEqual
  • Greater
  • Not Equal
  • GreaterEqual
  • Always

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.23 Z Compare Test Description


Basic Rasterization Test Assertions - DirectX

5.24.1 The Mesh (D3D Vertex) test

The Basic Rasterization test tests various capabilities that are considered to be the most common capabilities. The following list describes all of the different capabilities that are tested.

  • Mesh – D3D Vertex - Test draws various meshes using D3Dvertex and compares with the Reference rasterizer.
  • The Mesh (TL Vertex) test - Test draws various meshes using D3DTLVertex and compares with Reference rasterizer.
  • The Mesh (L Vertex) test - Test draws various meshes using D3DLVertex and compares with the Reference rasterizer.
  • The Fill Rule test - Test verifies the Top-Left fill rule by drawing triangles that highlight the top-left fill rule and compares with the Reference rasterizer.
  • The Culling test - Test verifies the culling modes by drawing triangles with different vertex ordering (clockwise and counterclockwise) and compares with the Reference rasterizer.
  • The Dithering test - Test verifies dithering by drawing a simple mesh with and without dithering, in comparison with the Reference rasterizer.
  • The Colorwrite Test.
  • The Shading – Flat/Gouraud test - Test ensures that the graphics adapter supports Flat and Gouraud shading.
  • The Modulating – No Diffuse test.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.24 Basic Rasterization Tests Description


Overdraw/Underdraw Test Assertions - DirectX

5.25.1 The Overdraw/Underdraw test

verifies that no Overdraw or Underdraw of pixels happen when rendering. However, in this test, fill rules typically have a 0% error tolerance (instead of the usual 15%). The test renders alternating Red & Green triangles and then OR blts it to the buffer. The test checks the resulting buffer for any Yellow pixels (overdraw case) or any Black pixels (underdraw case).

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.25 Overdraw/Underdraw Test Description


Perspective Test Assertions - DirectX

5.26.1 The Texture Perspective test

Test verifies perspective correct textures by drawing a textured mesh with various Z values at the corners and compares with the Reference rasterizer.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.26 Perspective Test Description

5.26.2 The Color Perspective test

Test verifies perspective correct colors by drawing a colored mesh with various Z values at the corners and compares with the Reference rasterizer.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.26 Perspective Test Description


Subpixel Texture Test Assertions - DirectX

5.27.1 The Subpixel Texture test

Test verifies perspective correct textures by drawing a textured mesh with various Z values at the corners and compares with the Reference rasterizer.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.27 SubPixel Texture Test Description


Texture Handle Test Assertions - DirectX

5.28.1 The Texture Handle test

The D3D Texture Handle test verifies that the hardware fails texture creation when the limit of useable texture handles is reached.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.28 Display Texture Handle Test Description


Alpha Blending Test Assertions - DirectX

5.29.1 The following eight Direct3D source alpha blending modes are required:
D3DBLEND_DESTCOLOR | D3DBLEND_INVDESTCOLOR
D3DBLEND_INVSRCALPHA | D3DBLEND_INVSRCCOLOR
D3DBLEND_ONE | D3DBLEND_SRCALPHA
D3DBLEND_SRCCOLOR | D3DBLEND_ZERO

The following Direct3D source and destination alpha blending modes are recommended:

D3DBLEND_BOTHINVSRCALPHA | D3DBLEND_BOTHSRCALPHA
D3DBLEND_DESTALPHA | D3DBLEND_INVDESTALPHA
D3DBLEND_SRCALPHASAT |

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.29 Alpha Blending Test Description

5.29.2 The Alpha Blending - FALSE/TRUE test

Test verifies all supported alpha blending modes (source and destination), and draws triangles with various alpha values, and compares with the reference rasterizer.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.29 Alpha Blending Test Description

5.29.3 The Alpha Compare test

Test assesses the AlphaFunc, AlphaTestEnable, and AlphaRef render states by drawing various triangles with specific alpha values, setting up the various AlphaFunc compare modes, turning on AlphaTestEnable, setting an AlphaRef value, and compares with the reference rasterizer. The various compare modes tested are:

  • Never - triangles should never be drawn regardless of the incoming alpha value or the value stored in AlphaRef.
  • Less - the alpha value coming in must be less than the value stored in AlphaRef in order for the triangles to be drawn
  • LessEqual - the alpha value coming in must be less than or equal to the value stored in AlphaRef in order for the triangles to be drawn
  • Greater - the alpha value coming in must be greater than the value stored in AlphaRef in order for the triangles to be drawn
  • NotEqual - the alpha value coming in must not be equal to the value stored in AlphaRef in order for the triangles to be drawn
  • GreaterEqual - the alpha value coming in must be greater than or equal to the value stored in AlphaRef in order for the triangles to be drawn
  • Always - the triangles should always be drawn regardless of the incoming alpha value or the value stored in AlphaRef
  • Equal - the alpha value coming in must be equal to the value stored in AlphaRef in order for the triangles to be drawn

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.29 Alpha Blending Test Description


Z Write Test Assertions - DirectX

5.30.1 The Z Write test

Test verifies the ZEnable and ZWriteEnable render states by altering the values of these render states, drawing two overlapping triangles, and compares with the reference rasterizer.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.30 Z Write Test Description


W Buffer Test Assertions - DirectX

5.31.1 The W Buffer test

Test the W buffer by drawing three meshes on top of each other, altering the depth, and comparing with the reference rasterizer.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.31 W Buffer Test Description

5.31.2 The W Compare – Never test

Test verifies the various modes of W compare by rendering triangles with various RHW values and comparing with the reference rasterizer. The modes of W compare that are tested are:

  • Always
  • Equal
  • Greater
  • GreaterEqual
  • Less
  • LessEqual
  • Never
  • NotEqual

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.31 W Buffer Test Description


Palettized textures – Force Update Test Assertions - DirectX

5.32.1 The Alpha Palette - Force Update test

Test verifies palletized texture conformance.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.32 Palettized textures – Force Update Test Description"


Fogging Test Assertions – DirectX

5.33.1 The Vertex Fog test

Test ensures that the graphics adapter supports Fog of an arbitrary color, calculated on a per-vertex basis.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.33 Fogging Test Description

5.33.2 The Table Fog test

Test verifies different table fogs, draw triangles with various Z values, applies a blue fog, alters the start and end fog values, and compares with the reference rasterizer. The different fogs this test verifies are:

  • Linear table fog
  • Exponential table fog
  • ExponentialSquared table fog

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.33 Fogging Test Description

5.33.3 The Textured Table Fog test

Test verifies different table fog modes, draw triangles with various Z values, applies a blue fog, alters the start and end fog values when being applied to a textured mesh, and compares with the reference rasterizer. The different fog modes this test verifies are:

  • Linear table fog
  • Exponential table fog
  • ExponentialSquared table fog

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.33 Fogging Test Description

5.33.4 The W Fog test

Test verifies different W fogs, draw triangles with various RHW values, applies a red fog, alters the start and end fog values, and compares with the reference rasterizer. The different W fogs this test verifies are:

  • Linear W fog
  • Exponential W fog
  • ExponentialSquared W fog

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.33 Fogging Test Description

5.33.5 The Textured W Fog test

Test verifies different W fog modes, draw triangles with various RHW values, applies a red fog, alters the start and end fog values when being applied to a textured mesh, and compares with the reference rasterizer. The different W fog modes this test verifies are:

  • Linear W fog
  • Exponential W fog
  • ExponentialSquared W fog

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.33 Fogging Test Description


Lighting Test Assertions - DirectX

5.34.1 Bump Env Map

Test verifies compliant support ofbump environment map textures (DuDv[Lu]), D3DTOP_BUMPENVMAP and D3DTOP_BUMPENVMAPLUMINANCE.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.34 Lighting Test Description

5.34.2 Luminance

Test verifies compliant support for [alpha] luminance textures.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.34 Lighting Test Description

5.34.3 Lightmap

Test verifies compliant support of D3DTOP_DOTPRODUCT3 with respect to RGB.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.34 Lighting Test Description

5.34.4 Texture Transformations

Test verifies texture transformation capabilities with different types of input vertex data, number, and type of out texture coordinates. The test application renders a sphere in orthogonal and perspective (on hardware that supports projected textures) projections with texture that was "projected" from the background image with magnification. During the loop, the test tries to create from one to three output texture coordinate sets from one input set. A verification algorithm compares the result image with the image rendered by the reference device.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.34 Lighting Test Description

5.34.5 Lighting

Test analyzes lighting calculations and verifies any following features of device lighting pipeline: ambient (including per-light ambient), diffuse, specular, and emissive lighting with directional, point, and spotlight types, local and non-local viewer specular highlights, and material source settings.

Lighting verification is based on rendering points mesh lit by one or two lights, with different properties, reading results from the back buffer and comparison with results of internal reference calculations. To avoid test fails caused by difference in rasterization rules, the test reads back a 3x3 pixel rectangle for comparison.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.34 Lighting Test Description

5.34.6 Multiple Lights

Test creates different number of lights in each test case using five different scenarios: (1) disable lights prior to initialization, (2) enable lights in 0 to MAX order, (3) enable lights in MAX to 0 order, (4) enable lights in pseudo random order, (5) enable lights without initialization to test default parameters.

Verification performed by image comparison with image rendered by reference device.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.34 Lighting Test Description

5.34.7 Lightmap - Alpha

Test verifies compliant support of D3DTOP_DOTPRODUCT3 with respect to alpha.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.34 Lighting Test Description

5.34.8 Lightmap - Factor

Test verifies compliant support of D3DTOP_DOTPRODUCT3 with respect to D3DTA_TFACTOR.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.34 Lighting Test Description

5.34.9 Lightmap - Mix

Test verifies compliant support of D3DDEVCAPS_TEXTURESYSTEMMEMORY and applies a mixture of valid and invalid scenarios with system and video memory textures.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.34 Lighting Test Description


Compressed Texture Test Assertions - DirectX

5.35.1 Compressed Texture

Test renders a striped various DXT textures, varies alpha values (none, mesh alpha, texture alpha, or both), rotates texture mapping, alters mesh color, tiles texture from one to four, varies Z values of mesh for perspective correction, cycles texture formats used to blt from, and compares with the reference rasterizer. The DXT textures that are rendered and used are:

  • DXT1
  • DXT2
  • DXT3
  • DXT4
  • DXT5

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.35 Compressed Texture Test Description


Stencil Test Assertions - DirectX

5.36.1 Stencil

Test each of the following: stencil caps, stencil/z clear, stencil functions, stencil ops, stencil buffer corruption, and z buffer corruption.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.36 Stencil Test Description"


Multi-texturing Test Assertions - DirectX

5.37.1 Texture Stage test

Test assesses combinations of exposed multi-texturing features. The test fails if any image is less than 85% conformant. This test only analyzes combinations for which ValidateDevice() returns OK.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.37 Multi-texturing Tests Description

5.37.2 Cubic Mapping test

Test renders a cubic mapped sphere with different textures for each face, rotates in the various directions, and then compares with the reference rasterizer. The directions the sphere is rotated is as follows:

  • Yaw
  • Pitch

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.37 Multi-texturing Tests Description

5.37.3 Cubic Mapping – MipMapping test

Test renders a cubic mip-mapped sphere with different textures for each mip level, with three mip levels used, varies the size of the sphere, and then compares with the reference rasterizer.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.37 Multi-texturing Tests Description


MIP-mapped Textures Test Assertions - Direct X

5.38.1 The MipFilter Test

Test renders a striped mip-mapped texture with various mip filter modes, uses different colored mip-maps, uses different top texture sizes, varies the mesh size, cycles through all available texture formats, and compares with the reference rasterizer. The various mip filter modes are:

  • MipFilter Point/Linear, MinFilter Point/Linear, and three mip levels with a top texture size of 256x256.
  • MipFilter Point/Linear and three mip levels with a top texture size of 64x256.
  • MipFilter Point/Linear and three mip levels with a top texture size of 256x64.
  • MipFilter Point/Linear and nine mip levels with a top texture size of 256x256.
  • MipFilter Point/Linear and nine mip levels with a top texture size of 16x256.
  • MipFilter Point/Linear and nine mip levels with a top texture size of 256x16.
  • MipFilter Point/Linear varies MaxMipLevels from 8 to 0, and nine mip levels with a top texture size of 256x256.
  • MipFilter Point/Linear varies LODBias from 3 to –3, and nine mip levels with a top texture size of 256x256.

Reference Documents: The DirectX DDK, the Reference Rasterizer Source section of the DirectX DDK, and the DirectX SDK.
Test Description: TD-5.38 MIP-mapped Texture Tests Description


Simultaneous Features Test Assertions - DirectX

5.39.1 Driver Scenario

Test verifies that exposed features work in concert with each other. Providing the hardware supports the required caps for each feature (it will log any caps which failed to detect), the test runs all combinations of the features in a dynamic scene. The scene is composed of a central, unmoving sphere and six orbiting cubes. Additionally, there are three planes oriented (usually) such that they face the viewer. Each of the objects takes on various attributes over the course of the test.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.39 Display Simultaneous Features Test Description


Specular Highlighting Test Assertions - DirectX

5.40.1 Specular Highlighting

Test ensures that the graphics adapter supports Specular highlighting.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.40 Specular Highlighting Test Description


Initialization & Resetting Test Assertions - DirectX

5.41.1 Clear offscreen/texture surface

Clearing of texture and offscreen surfaces are tested. Fullscreen clearing and List of Rectangles clearing are tested. Clearing Z-buffer, Stencil-buffer and Render-target are tested. In clearing Render-target, clearing RGB and clearing Alpha are tested separately. The independency of clearing Alpha, color, stencil and Z are also tested. Image is compared to refrast image to get conformance.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.41 Clear Offscreen/Texture Surface Test Description


Multi-sampling Test Assertions - DirectX

5.42.1 Multi-sampling - Antialiasing

Edge between two different colors are drawn with different inclinations in multisample mode. Then the color of the edge is read and analyzed algorithmically to determine the quality of multisample antialiasing.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.42 Multi-sampling Tests Description

5.42.2 Multi-sampling - Masking

For Multisample_N mode, N triangles are drawn with the first one just using one sample, the second one using two samples, and so on until N. The first triangle is algorithmically analyzed for intensity 1/N, the second triangle for intensity 2/N, and so on until N.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.42 Multi-sampling Tests Description


Present Validation Test Assertions - DirectX

5.43.1 Present Validation

Test ensures that the graphics adapter is able to perform Idirect3Ddevice8::Present() calls correctly in all situations, including stretching, shrinking, and destination window overrides.

Reference Documents: DirectX DDK, DirectX SDK.

Test Description: TD-5.43 Present Validation Test Description


Matrix Palette Skinning Test Assertions - DirectX

5.44.1 Matrix Palette Skinning

Test compares images from hardware-transformed vertex blending images with those from the reference device. The tests run through non-indexed blending, the full range of indexed blending, and a vertex shader version of blending to test argument correctness. Should only be applicable to Transform and Lighting (TnL) devices.

Reference Documents: DirectX DDK, DirectX SDK.

Test Description: TD-5.44 Matrix Palette Skinning Test Description


Buffered Blts Test Assertions - DirectX

5.45.1 Blt Queue

Test verifies that drivers do not queue more than 3 presentation blts. A series of presentation blts are sent to the hardware driver, followed by a call to LockRect to flush the blt queue and determine the number of blts that were outstanding.

Reference Documents: DirectX DDK, DirectX SDK.

Test Description: TD-5.45 The Blt Queue Test Description


Lock Depth Buffer Test Assertions - DirectX

5.46.1 Lockable Depth Buffer

Test verifies that if a lockable z-buffer format is exposed, its functionality is consistent with expected behavior. This test locks the z-buffer and populates it with data, unlocks and renders primitives, locks the z-buffer again to compare the depth values against the Reference Rasterizer, and then compares final RGB image against the Reference Rasterizer.

Reference Documents: DirectX DDK, DirectX SDK.

Test Description: TD-5.46 The Lockable Depth Buffer Test Description


Point Sprite Test Assertions

5.47.1 Point Sprite

This test is to verify a hardware driver’s implementation of point sprites.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.47 The Point Sprite Test Description


Set Render Target Test Assertions - DirectX

5.53.1 Set Render Target

Test verifies rendering to a texture for all texture formats that can be specified as a render target. It compares all renders with the reference rasterizer while performing the following render to texture techniques:

  • Renders directly to the texture for all texture formats with each Z buffer formats.
  • Renders directly to the texture for all texture formats with Z buffers disabled.
  • Renders to an offscreen surface and blts to the texture for all texture formats with each Z buffer formats.
  • Renders to an offscreen surface and blts to the texture for all texture formats with Z buffers disabled.

Reference Documents: The DirectX DDK, the Reference Rasterizer Source section of the DirectX DDK, and the DirectX SDK.

Test Description: TD-5.53 Set Render Target Tests Description

5.53.2 Set Render Target – Invalid

Test verifies that there are no ill effects (system corruption, blue screen, etc) when rendering to a texture that is currently set.

Reference Documents: The DirectX DDK, the Reference Rasterizer Source section of the DirectX DDK, and the DirectX SDK.

Test Description: TD-5.53 Set Render Target Tests Description

5.53.3 Multiple SwapChains

Test verifies that there are no ill effects (image corruption, blue screen, etc) when rendering to multiple swapchains using multitexturing(if supported).

Reference Documents: The DirectX DDK, the Reference Rasterizer Source section of the DirectX DDK, and the DirectX SDK.

Test Description: TD-5.53 Set Render Target Tests Description


GetRasterStatus Test Assertions - DirectX

5.54.1 GetRasterStatus

Test ensures that the graphics adapter will return valid data in calls to Idirect3Ddevice8::GetRasterStatus() verified against the refresh rate of the current display mode.

Reference Documents: DirectX DDK, DirectX SDK.

Test Description: TD-5.54 GetRasterStatus Test Description


VBIB – Vertex and Index Buffer Test Assertions - DirectX

5.55.1 Vertex and Index Buffer

Test ensures that the graphics adapter is able to perform vertex processing with a variety of different vertex and index buffers.

Reference Documents: DirectX DDK, DirectX SDK.

Test Description: TD-5.55 Vertex Buffer and Index Test Description


Clipping Test Assertions - DirectX

5.56.1 TL Vertex Clip

This test verifies that a driver clips lines, generated from transformed and light vertices, correctly to a view port.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.56 Clipping Test Description

5.56.2 Viewport Clipping

Test verifies accuracy of the viewport clipping and interpolation of diffuse and specular colors, alpha and vertex fog values and texture coordinates.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.56 Clipping Test Description

5.56.3 Arbitrary Clipping Planes

Test verifies device accuracy of clipping with arbitrary clipping planes and interpolation of diffuse and specular colors, alpha and vertex fog values and texture coordinates.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.56 Clipping Test Description


Multipass Z-Fighting Test Assertions - DirectX

5.57.1 Multipass Z-Fighting

Test verifies independence of drawing method and vertex order with respect to multipass rendering. Independence requires no z fighting issues to be present during multipass rendering.

Reference Documents: DirectX DDK, DirectX SDK.

Test Description: TD-5.57 Multipass Z-Fighting Test Description


State Blocks Test Assertions - DirectX

5.58.1 State Blocks

Test verifies various states such as textures, lighting, and blending modes can be recorded and set through the use of state blocks.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.58 State Blocks Test Description


Vertex Buffer Test Assertions - DirectX

5.59.1 Vertex Buffer Rendering

Test verifies device capabilities to render primitives from different types of vertex buffers.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.59 Vertex Buffer Rendering Tests Description


Vertex Tweening Test Assertions - DirectX

5.60.1 Vertex Tweening

Test compares output from hardware-transformed vertex-tweened geometry with that from the reference device. The test also runs a vertex shader version of tweening.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.60 Vertex Tweening Tests Description


Vertex Blending Test Assertions - DirectX

5.61.1 Vertex Blending

Test verifies vertex blending capabilities of the device with different numbers of transformation matrices (up to maximum number supported by the device) in following scenarios: (1) geometry only, (2) texture, (3) texture with texture coordinate generation.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.61 Vertex Blending Tests Description


Texture Coordinate Generation Test Assertions - DirectX

5.62.1 Texture Coordinate Generation

Test verifies texture coordinate generation capabilities of the device in camera space coordinate, camera space normal and camera space reflection vector with local and non-local viewer modes.

Reference Documents: DirectX DDK, DirectX SDK.

Test Description: TD-5.62 Texture Coordinate Generation Tests Description


Pixel Shaders Test Assertions - DirectX

5.63.1 Pixel Shaders

Test verifies pixel shader capabilities of the device.

Reference Documents: DirectX DDK, DirectX SDK.

Test Description: TD-5.63 Pixel Shaders Tests Description


Surface Test Assertions - DirectX

5.64.1 Surfaces test

Test verifies device abilities to create different formats and multisampling types of surfaces (image surface, render target and depth stencil surface) if the device exposes the capacities.

Reference Documents: DirectX DDK, DirectX SDK.

Test Description: TD-5.64 Surfaces Tests Description


Texture Update Test Assertions - DirectX

5.65.1 Texture Update

Test verifies device capacities to load textures (mipmap, cubemap) from system memory to video memory using UpdateTexture function. The test includes the following scenarios: (1) Load the entire texture. (2) Load a portion of the texture. (3) source and destination texture are square or non square. (4) Source and destination texture have different levels.

Reference Documents: DirectX DDK, DirectX SDK.

Test Description: TD-5.65 Texture Update Test Description


Vertex Shaders Test Assertions - DirectX

5.66.1 Vertex Shaders

Test verifies vertex shader capabilities of the device.

Reference Documents: DirectX DDK, DirectX SDK.

Test Description: TD-5.66 Vertex Shaders Test Description


Volume Texture Test Assertions - DirectX

5.67.1 Volume Textures

Test verifies the proper rendering of volume textures. It does this by comparing all renders to the reference rasterizer while using volume textures in the following ways:

  • Renders all volume texture formats while displaying a variety of depths.
  • Renders all volume texture formats while using five mip levels.
  • Renders volume textures while using all texture generation modes.
  • Renders volume textures while using all volume texture filtering modes.
  • Renders all volume texture formats while using a variety of common texture blending modes.
  • Renders volume textures while using all volume texture addressing modes.

Reference Documents: The DirectX DDK, the Reference Rasterizer Source section of the DirectX DDK, and the DirectX SDK.

Test Description: TD-5.67 Volume Texture Test Description


MipMapping Test Assertions - DirectX

5.68.1 MipMapping

Test verifies that if the device exposes the capacities, it is able to create various kinds of mipmaps (different formats, different levels, as render target or depth stencil surface, square/non-square/non-power-of-two texture)

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.68 MipMapping Test Description


High Order Surfaces Test Assertions - DirectX

5.69.1 High Order Surfaces

Test verifies that if the device exposes the capabilities, it can render RT-Patches and/or N-Patches. The test includes scenarios for Iinear, cubic and quintic(if cap is set) order, bezier, b-spline and interp(Catmull-Rom) surface types, and various levels of tesselation.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.69 High Order Surfaces Test Description


Memory/Texture Management Test Assertions - DirectX

5.70.1 Memory/Texture Management test

Display Driver must accurately report and manage video memory. Requests to place resources (Surfaces, Textures, Vertex Buffers) in particular memory pool type should be respected. If a particular memory pool is exhausted, the resource creation call should fail. It's especially important that drivers do not create resources in system memory when video memory is full. This will defeat DX7/DX8's resource manager, which is capable of moving resources in an out of video memory as needed. Drivers which implement their own Resource Management must behave in a fashion similar to the runtime implementation.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.70 Memory/Texture Management Test Description


DDI Version Level Check Test Assertions - DirectX

5.71.1 DDI Version Level Check test

Verifies that the driver is of DX DDI level 6.0 or greater.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: "No Test needed"


Morph – Invalid Params Test Assertions - DirectX

5.72.1 Morph – Invalid Params

Morph is an invalid parameter test suite targeting display driver robustness on Windows 2000. The test is designed using the IDirect3DDevice::Execute() API. Valid scenarios (5) have been added for IDirect3DDevice::SwapTextureHandles() to account for test coverage deemed critical by OEMs. OEMs were applying Dx3 D3D SDK samples to validate texture swapping capabilities through IDirect3DDevice::SwapTextureHandles().

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.72 Morph – Invalid Params Test Description


Video Memory Volume Texture Test Assertions - DirectX

5.73.1 Video Memory Volume Texture

This test verifies device capacities to load volume textures from system memory to video memory using Update Texture function. The test loads volume textures with both REF and HAL devices, and then renders the textures and compares the result. The test includes the following scenarios: (1) Load the entire texture. (2) Load a portion of the texture.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.73 Volume Texture Update Test Description


Anisotropic Texture Filtering Test Assertions - DirectX

5.74.1 Anisotropic Texture Filtering Test

The test renders a high frequency (narrow lines, curves, checkerboard, etc) texture with the various anisotropic filter modes, varies the mesh size, varies the Z values on the mesh, varies the MaxAnisotropy value, and compares with the Reference rasterizer. The different anisotropic filter modes used are:

  • MinFilter: Point and MagFilter: Anisotropic
  • MinFilter: Linear and MagFilter: Anisotropic
  • MinFilter: Anisotropic and MagFilter: Point
  • MinFilter: Anisotropic and MagFilter: Linear
  • MinFilter: Anisotropic and MagFilter: Anisotropic

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.74 Anisotropic Texture Filtering Test Description


Line Style Test Assertions - DirectX

5.75.1 Line Style

Test ensures consistent driver caps and proper functionality are exposed for line pattern and line pattern repetition.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.75 Line Style Test Description


Resource Management / Lost Device Test Assertions - DirectX

5.76.1 Resource Management / Lost Device

Drivers which implement their own resource management must make resources appear persistent to the application during "Lost Device" scenarios.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.76 Resource Management / Lost Device Test Description


GetInfo() Test Assertions

This section contains detailed test assertions for the Direct3D GetInfo() functions.

IDirect3DDevice7::GetInfo() Test Assertions

5.77.1 IDirect3DDevice7::GetInfo() conformance test

The Dx7 GetInfo() API has been changed in Dx8.1 to behave identically thru debug and retail builds of the Dx graphics core. The Dx8.1 SDK documentation has been updated to reflect these changes. The conformance test is designed to validate conformance behavior of this API and the associated D3dGetDriverStatus() driver entry. The Dx8.1 DDK has been updated to such that appropriate behavior is illustrated in the sample driver code.

Reference document: Dx8.1 DDK, Dx8.1 SDK
Test description: TD-5.77 IDirect3DDevice7::GetInfo() Test Description


IDirect3DDevice8::GetInfo() Test Assertions

5.78.1 IDirect3DDevice8::GetInfo() conformance test

The Dx8 GetInfo() API has been changed in Dx8.1 to behave identically thru debug and retail builds of the Dx graphics core. The Dx8.1 SDK documentation has been updated to reflect these changes. The conformance test is designed to validate conformance behavior of this API and the associated D3dGetDriverStatus() driver entry. The Dx8.1 DDK has been updated to such that appropriate behavior is illustrated in the sample driver code.

Reference document: Dx8.1 DDK, Dx8.1 SDK
Test description: TD-5.78 IDirect3DDevice8::GetInfo() Test Description


D3DContextSwitch Test Assertions

5.78.1 D3DContextSwitch test

Test ensures that context switching by the graphics hardware and driver from one D3D application to another happens correctly. The emphasis is on switching of RenderStates, TextureStageStates and Textures.

Reference document: Dx8.1 DDK, Dx8.1 SDK
Test description: TD-5.79 D3DContextSwitch Test Description


Fill Modes Test Assertions

5.79.1 Fill Modes

This test verifies a hardware driver’s implementation of Windows® Direct3D® fill modes.

Reference Documents: DirectX DDK, DirectX SDK.

Test Description: TD-5.81 Fill Modes Test Description


Vertex Buffer Renaming Test Assertions - DirectX

5.80.1 Vertex Buffer Swap

Test ensures that the graphics adapter is able to successfully accomplish vertex buffer renaming and return a valid aliased pointer to a successive lock caller.

Reference document: Dx8.1 DDK, Dx8.1 SDK
Test description: TD-5.80 Vertex Buffer Renaming Test Description


Invalid Parameter Test Assertions

[This is preliminary documentation and is subject to change]

The following test assertions are tested in the TD-5.82 Invalid Parameter Test. The test verifies driver stability by sending all possible D3dDrawPrimitives2 (DP2) tokens to video adapter drivers with both invalid and valid parameters associated with those tokens.

5.82.1 [NEW v0.5] Draw Primitive Test

The test renders randomly placed primitives by using all DrawPrimitive APIs (for example, DrawPrimitiveUP, DrawIndexedPrimitive), primitive types, and a variety of primitive counts, including invalid primitive counts (0) and more primitives than the device capabilities support.

Reference document: DirectX 9.0 Software Development Kit (SDK)
Test description: TD-5.82 Invalid Parameter Test

5.82.2 [NEW v0.5] Viewport Test

The test changes all viewport parameters using both w-buffering and z-buffering. The test sends the D3DDP2OP_VIEWPORTINFO, D3DDP2OP_WINFO, and D3DDP2OP_ZRANGE tokens followed by invalid and valid parameters associated with those tokens.

Reference document: DirectX 9.0 SDK
Test description: TD-5.82 Invalid Parameter Test

5.82.3 [NEW v0.5] Texture Palette Test

The test renders a scene using a palletized texture with the D3DDP2OP_SETPALETTE, D3DDP2OP_UPDATEPALETTE tokens. The index of the texture palette cycles through valid and invalid palette indices (including very high indices).

Reference document: DirectX 9.0 SDK
Test description: TD-5.82 Invalid Parameter Test

5.82.4 [NEW v0.5] Lighting Test

The test renders a scene with lighting enabled and uses the D3DDP2OP_SETMATERIAL, D3DDP2OP_SETLIGHT, and D3DDP2OP_CREATELIGHT tokens. The test sets both valid and invalid counts of lights.

Reference document: DirectX 9.0 SDK
Test description: TD-5.82 Invalid Parameter Test

5.82.5 [NEW v0.5] Rect Patch Test

The test sends the D3DDP2OP_DRAWRECTPATCH token to render randomly placed rectangular patches. The test attempts to render rectangular patches even if the device does not support them.

Reference document: DirectX 9.0 SDK
Test description: TD-5.82 Invalid Parameter Test

5.82.6 [NEW v0.5] Tri Patch Test

The test renders randomly placed triangular patches using the D3DDP2OP_DRAWTRIPATCH token. The test attempts to render triangular patches even if the device does not support them.

Reference document: DirectX 9.0 SDK
Test description: TD-5.82 Invalid Parameter Test

5.82.7 [NEW v0.5] RenderState Test

The test renders a scene with randomly set render states without regard to the capabilities of the device. The test uses the D3DDP2OP_RENDERSTATE and D3DDP2OP_SETCLIPPLANE tokens.

Reference document: DirectX 9.0 SDK
Test description: TD-5.82 Invalid Parameter Test

5.82.8 [NEW v0.5] Texture Stage State Test

The test renders a scene with randomly set texture stage states without regard to the capabilities of the device. The test uses the D3DDP2OP_TEXTURESTAGESTATE token.

Reference document: DirectX 9.0 SDK
Test description: TD-5.82 Invalid Parameter Test

5.82.9 [NEW v0.5] StretchRect Test

The test sends the D3DDP2OP_BLT token and asks the device to stretch a rectangular region from one off-screen plain surface to another off-screen surface, using a variety of valid and invalid texture filters and rectangle geometries.

Reference document: DirectX 9.0 SDK
Test description: TD-5.82 Invalid Parameter Test

5.82.10 [NEW v0.5] ColorFill Test

Using the D3DDP2OP_COLORFILL token, the test asks the device to fill a rectangular region of an off-screen plain surface with a solid color. The test cycles through both valid and invalid rectangles. For example, an invalid rectangle occurs when the device is asked to fill a region that is larger than the target surface.

Reference document: DirectX 9.0 SDK
Test description: TD-5.82 Invalid Parameter Test

5.82.11 [NEW v0.5] Set Priority Test

The test creates a texture resource in a variety of resource pools and then uses the D3DDP2OP_SETPRIORITY token to set the priority of that texture to a random value.

Reference document: DirectX 9.0 SDK
Test description: TD-5.82 Invalid Parameter Test

5.82.12 [NEW v0.5] Set LOD Test

The test creates a texture resource in a variety of resource pools and uses the D3DDP2OP_SETTEXLOD token to set the level of detail (LOD) of that texture (the highest resolution image in memory) to both valid and invalid values.

For example, if the texture was created with the dimensions of 256 x 256, setting the most detailed level to 0 indicates that 256 x 256 is the largest MIP map available; setting the most detailed level to 1 indicates that 128 x 128 is the largest MIP map available, and so on, up to the most detailed MIP-level (the smallest texture size) for the chain.

Reference document: DirectX 9.0 SDK
Test description: TD-5.82 Invalid Parameter Test

5.82.13 [NEW v0.5] Texture Filter Count Test

The test sends the D3DDP2OP_SURFACEBLT and D3DDP2OP_TEXBLT tokens to the driver and renders a scene with a variety of valid and invalid texture filter settings.

Reference document: DirectX 9.0 SDK
Test description: TD-5.82 Invalid Parameter Test

5.82.14 [NEW v0.5] Clip Plane Test

The test sends the D3DDP2OP_SETCLIPPLANE token to the driver and renders a scene with both valid and invalid numbers of clip planes enabled.

Reference document: DirectX 9.0 SDK
Test description: TD-5.82 Invalid Parameter Test

5.82.15 [NEW v0.5] State Block Test

The test sends the D3DDP2OP_STATESET to the driver and attempts to record the state of a device with valid and invalid parameters (that is, with nonexistent state categories).

Reference document: DirectX 9.0 SDK
Test description: TD-5.82 Invalid Parameter Test

5.82.16 [NEW v0.5] Set Render Target Test

The test uses the D3DDP2OP_SETRENDERTARGE token and creates rendering targets and z-buffers.

Reference document: DirectX 9.0 SDK
Test description: TD-5.82 Invalid Parameter Test

5.82.17 [NEW v0.5] Vertex Shader Test

The test renders a scene with a vertex shader and attempts to set vertex shader constant registers with invalid indices. The test sets a vertex shader using the D3DDP2OP_SETVERTEXSHADER token and changes vertex shader constant registers with the D3DDP2OP_SETVERTEXSHADERCONST token.

Reference document: DirectX 9.0 SDK
Test description: TD-5.82 Invalid Parameter Test

5.82.18 [NEW v0.5] Pixel Shader Test

The test renders a scene with a pixel shader and attempts to set pixel shader constant registers with invalid indices. The test sets the pixel shader using the D3DDP2OP_SETPIXELSHADER token and sets the pixel shader constant registers using the D3DDP2OP_SETPIXELSHADERCONST token.

Reference document: DirectX 9.0 SDK
Test description: TD-5.82 Invalid Parameter Test

5.82.19 [NEW v0.5] Add Dirty Rect Test

The test creates a two-dimensional texture resource and then adds a dirty rectangular region to it. The test uses the D3DDP2OP_ADDDIRTYRECT token and is performed with both valid and invalid region geometry. Invalid region geometry includes rectangles with zero area and rectangles that extend outside of the texture size.

Reference document: DirectX 9.0 SDK
Test description: TD-5.82 Invalid Parameter Test

5.82.20 [NEW v0.5] Add Dirty Box Test

The test creates a three-dimensional resource and then specifies that the volume texture has been dirtied in system memory. The test uses the D3DHAL_DP2ADDDIRTYBOX structure and the DP2OP_ADDDIRTYBOX token and specifies both valid and invalid volume geometry (the D3DBOX structure). Once marked as dirty, the volume must be reloaded into video memory before being used.

Reference document: DirectX 9.0 SDK
Test description: TD-5.82 Invalid Parameter Test

5.82.21 [NEW v0.5] Multiply Transform Test

The test uses the D3DHAL_DP2MULTIPLYTRANSFORM structure and verifies that the driver can support modifications to the various transformation matrices. The test is performed with both valid and invalid transform identifiers (D3DTRANSFORMSTATETYPE).

Reference document: DirectX 9.0 SDK
Test description: TD-5.82 Invalid Parameter Test

5.82.22 [NEW v0.5] Buffer Blt Test

The test creates managed vertex and index buffers then updates them. As a result, the DirectX runtime requests the driver to perform a buffer blt between the managed resource and the driver resource. The test is performed with both valid and invalid blt ranges. The test uses the D3DHAL_DP2BUFFERBLT structure and D3DDP2OP_BUFFERBLT command token.

Reference document: DirectX 9.0 SDK
Test description: TD-5.82 Invalid Parameter Test

5.82.23 [NEW v0.5] Volume Blt Test

The test creates a managed volume texture and then updates it. As a result, the Direct3D runtime asks the driver to perform a buffer blt between the managed resource and the driver resource. The test is performed with both valid and invalid blt ranges and uses the D3DHAL_DP2VOLUMEBLT structure and D3DDP2OP_VOLUMEBLT command token.

Reference document: DirectX 9.0 SDK
Test description: TD-5.82 Invalid Parameter Test

5.82.24 [NEW v0.5] ScissorRect Test

The test uses the D3DDP2OP_SETSCISSORRECT token and renders a scene with a randomly set scissor rectangle.

Reference document: DirectX 9.0 SDK
Test description: TD-5.82 Invalid Parameter Test

5.82.25 [NEW v0.5] Query Test

The test uses the D3DDP2OP_CREATEQUERY, D3DDP2OP_DELETEQUERY, and D3DDP2OP_ISSUEQUERY tokens and queries the device for both valid and invalid device statistics.

Reference document: DirectX 9.0 SDK
Test description: TD-5.82 Invalid Parameter Test

5.82.26 [NEW v0.5] Auto Generated MIP Map Test

The test creates Direct3D texture maps with the D3DUSAGE_AUTOGENMIPMAP flag and then renders into the top-level surface of the MIP chain. Next, the test passes down the D3DDP2OP_GENERATEMIPSUBLEVELS token to the driver so that the driver will fill in the rest of the MIP map chain using the currently set texture filter. This test sets both valid and invalid texture filters, and this test runs even if the device does not support autogenerated MIP maps.

Reference document: DirectX 9.0 SDK
Test description: TD-5.82 Invalid Parameter Test

5.82.27 [NEW v0.5] Set Stream Source Frequency

The test binds vertex buffers to one or more vertex streams and then sets the frequency of each stream by using the D3DDP2OP_SETSTREAMSOURCEFREQ token. This test cycles through both valid and invalid vertex buffer sizes and runs even if the device does not support version 3.0 of the vertex shader specification.

Reference document: DirectX 9.0 SDK
Test description: TD-5.82 Invalid Parameter Test


Direct3D DirectX 7 Test Assertions

Only RGB rasterization requirements defined for Windows Logo Program 1.1 are covered by this test specification.


Basic 3D Test Assertions - DirectX 7

5.100.1 The following adapter features must be supported in full-screen mode:

3D graphics mode, 800 x 600 resolution 16 bpp color depth, double buffering, 16-bit Z buffer, and 75 Hz refresh rate.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.20 Display Basic 3D Requirements Test Description

5.100.2 All required rasterization features must be available at the same time (Textures, Alpha blending, Lighting, Fogging).

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.20 Display Basic 3D Requirements Test Description

5.100.3 Graphics adapter/driver must conform to Microsoft Direct3D rasterization rules.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.20 Display Basic 3D Requirements Test Description

5.100.5 MIP-mapped textures must be supported.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.20 Display Basic 3D Requirements Test Description

5.100.6 Bilinear or better-filtered textures must be supported.

Bilinear or better-filtered textures rather than point-sampled with perspective correction must be supported.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.20 Display Basic 3D Requirements Test Description


Textures Test Assertions – DirectX 7

5.101.1 Texture Color Key – Default

Test verifies proper color keying of textures when a color key is requested. It then compares them with the reference rasterizer and cycles through all available texture formats. This is done for the following color keys:

  • Default Settings
  • White
  • Red
  • Green
  • Blue
  • Yellow
  • Magenta
  • Cyan
  • Grey
  • Black

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.22 Texture Tests Description

5.101.2 Texture Filter – No MipMapping

Test renders a striped texture with various filter modes, uses both a 16x16 texture, and then a 256x256 texture, varies the mesh size, and compares with the reference rasterizer. The different filter modes used are:

  • Nearest min and Nearest mag
  • Nearest min and Bi-Linear mag
  • Bi-Linear min and Nearest mag
  • Bi-Linear min and Bi-Linear mag

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.22 Texture Tests Description

5.101.3 Texture Filter – MipMapping

Test renders a striped mip-mapped texture with different filters, uses three different colored mip-maps, the highest being 256x256, varies the mesh size, and compares with the Reference rasterizer. The different filters used are as follows:

  • MipNearest min
  • MipLinear min
  • MipLinear min
  • LinearMipLinear min

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.22 Texture Tests Description

5.101.4 Texture Blend

Test renders a striped types of textures, varies alpha values (none, mesh alpha, texture alpha, or both), rotates texture mapping, alters mesh color, tiles texture from 1 to 4, cycles texture formats, and compares with the reference rasterizer. The different types of textures rendered are as follows:

  • Decal Texture
  • Modulate Texture
  • DecalAlpha Texture
  • ModulateAlpha Texture
  • Copy Texture
  • Add Texture
  • Default Texture (using default blend settings)

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.22 Texture Tests Description

5.101.5 Texture Load

Test tests texture loading from various surface types to local video memory. It also tests the case of texture loading from a mip-map with more source levels than the destination. Finally, it loads textures from system memory to video memory. These are the different cases it tests:

  • Video test loads textures from video memory to video memory
  • AGP test loads textures from AGP memory to video memory
  • MipMap_System test loads a 9-mip level system texture to a 7-mip level video texture
  • MipMap_Video test loads a 9-mip level video texture to a 7-mip level video texture
  • MipMap_AGP test loads a 9-mip level AGP texture to a 7-mip level video texture
  • Manage test loads textures from system memory to video memory and uses "Managed Textures"
  • MipMap_Manage test loads a 9-mip level system texture to a 7-mip level video texture and uses "Managed Textures"

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.22 Texture Tests Description

5.101.6 Texture Management

Tests for driver texture management.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.22 Texture Tests Description

5.101.7 Texture Format – System Memory

Test renders a striped texture from system memory in order to make sure the driver doesn’t interfere with system memory textures.

Reference Documents: The DirectX 7.0 DDK, the Reference Rasterizer Source section of the DirectX 7.0 DDK, and the DirectX 7.0 SDK.
Test Description: TD-5.22 Texture Tests Description


Stencil Test Assertions – DirectX 7

5.102.1 Stencil

Test each of the following: stencil caps, stencil/z clear, stencil functions, stencil ops, stencil corruption, and z corruption.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.36 Stencil Test Description


Texture Handle Test Assertions – DirectX 7

5.103.1 D3D Texture Handle

This test verifies that the hardware driver fails texture creation gracefully when the limit of usable texture handles is reached.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.37 Multi-texturing Tests Description


Specular Highlighting Test Assertions – DirectX 7

5.104.1 Specular Highlighting

Test ensures that the graphics adapter supports Specular highlighting.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.40 Specular Highlighting Test Description


Simultaneous Features Test Assertions – DirectX 7

5.105.1 Driver Scenario

Test verifies that exposed features work in concert with each other. Providing the hardware supports the required caps for each feature (it will log any caps which failed to detect), the test runs all combinations of the features in a dynamic scene. The scene is composed of a central, unmoving sphere and six orbiting cubes. Additionally, there are three planes oriented (usually) such that they face the viewer. Each of the objects takes on various attributes over the course of the test.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.39 Display Simultaneous Features Test Description


Overdraw/Underdraw Test Assertions – DirectX 7

5.106.1 Overdraw/Underdraw

verifies that no Overdraw or Underdraw of pixels happen when rendering. However, in this test, fill rules typically have a 0% error tolerance (instead of the usual 15%). The test renders alternating Red & Green triangles and then OR blts it to the buffer. The test checks the resulting buffer for any Yellow pixels (overdraw case) or any Black pixels (underdraw case).

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.25 Overdraw/Underdraw Test Description


Initialization & Resetting Test Assertions – DirectX 7

5.107.1 Clear Offscreen/Texture Surface

Clearing of texture and offscreen surfaces are tested. Fullscreen clearing and List of Rectangles clearing are tested. Clearing Z-buffer, Stencil-buffer and Render-target are tested. In clearing Render-target, clearing RGB and clearing Alpha are tested separately. The independency of clearing Alpha, color, stencil and Z are also tested. Image is compared to refrast image to get conformance.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.41 Clear Offscreen/Texture Surface Test Description


Set Render Target Test Assertions – DirectX 7

5.108.1 Set Render Target

Test verifies rendering to a texture for all texture formats that can be specified as a render target. It compares all renders with the reference rasterizer while performing the following render to texture techniques:

  • Renders directly to the texture for all texture formats with each Z buffer formats.
  • Renders directly to the texture for all texture formats with Z buffers disabled.
  • Renders to an offscreen surface and blts to the texture for all texture formats with each Z buffer formats.
  • Renders to an offscreen surface and blts to the texture for all texture formats with Z buffers disabled.

Reference Documents: The DirectX 7.0 DDK, the Reference Rasterizer Source section of the DirectX 7.0 DDK, and the DirectX 7.0 SDK.
Test Description: TD-5.53 Set Render Target Tests Description

5.108.2 Set Render Target – Invalid Params

Test verifies that there are no ill effects (system corruption, blue screen, etc) when rendering to a texture that is currently set.

Reference Documents: The DirectX 7.0 DDK, the Reference Rasterizer Source section of the DirectX 7.0 DDK, and the DirectX 7.0 SDK.
Test Description: TD-5.53 Set Render Target Tests Description


Clipping Test Assertions – DirectX 7

5.109.1 TL Vertex Clipping.

This test verifies that a driver clips lines, generated from transformed and light vertices, correctly to a view port.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.56 Clipping Test Description "TL Vertex Clip"


Multitexturing Test Assertions – DirectX 7

5.110.1 PC99 #29 Multitexturing

This test verifies multi-texturing works fine on the card. It also sees if driver responds correctly to validate device for texture stages.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.37 Multi-texturing Tests Description


Texture Sizes Test Assertions – DirectX 7

5.111.1 PC99 #31 Texture Sizes

PC99 Guide

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.22 Texture Tests Description


AntiAlias Test Assertions – DirectX 7

5.112.1 PC99 #28 AntiAlias

PC99 Guide

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.42 Multi-sampling Tests Description


Palettized Textures Test Assertions – DirectX 7

5.113.1 Palettized Textures

Test verifies palettized texture conformance.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.113 Palettized Textures Test Description


Direct3D DirectX 6 Test Assertions

Only RGB rasterization requirements defined for Windows Logo Program 1.1 are covered by this test specification.


Basic 3D Test Assertions - DirectX 6

5.120.1 The following adapter features must be supported in full-screen mode:

3D graphics mode, 800 x 600 resolution 16 bpp color depth, double buffering, 16-bit Z buffer, and 75 Hz refresh rate.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.20 Display Basic 3D Requirements Test Description

5.120.2 All required rasterization features must be available at the same time (Textures, Alpha blending, Lighting, Fogging).

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.20 Display Basic 3D Requirements Test Description

5.120.3 Graphics adapter/driver must conform to Microsoft Direct3D rasterization rules.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.20 Display Basic 3D Requirements Test Description

5.120.5 MIP-mapped textures must be supported.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.20 Display Basic 3D Requirements Test Description

5.120.6 Bilinear or better-filtered textures must be supported.

Bilinear or better-filtered textures rather than point-sampled with perspective correction must be supported.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.20 Display Basic 3D Requirements Test Description


Textures Test Assertions – DirectX 6

5.121.1 Texture Address

Test verifies different texture addressing, draws a textured mesh, rotates texture mapping, and compares with the Reference rasterizer.

Wrap U texture addressing

Wrap V texture addressing

Wrap U and Wrap V texture addressing

Wrap texture addressing

Clamp texture addressing

Mirror texture addressing

Border texture addressing (border color is altered with default, blue, red, and green, after rotating texture mapping)

IndependentUV texture addressing with Wrap for U and Mirror for V

IndependentUV texture addressing with Wrap for U and Clamp for V

IndependentUV texture addressing with Wrap for U and Border for V

IndependentUV texture addressing with Mirror for U and Wrap for V

IndependentUV texture addressing with Mirror for U and Clamp for V

IndependentUV texture addressing with Mirror for U and Border for V

IndependentUV texture addressing with Clamp for U and Wrap for V

IndependentUV texture addressing with Clamp for U and Mirror for V

IndependentUV texture addressing with Clamp for U and Border for V (border color is altered with default, blue, red, and green, after rotating texture mapping)

IndependentUV texture addressing with Border for U and Wrap for V (border color is altered with default, blue, red, and green, after rotating texture mapping)

IndependentUV texture addressing with Border for U and Mirror for V (border color is altered with default, blue, red, and green, after rotating texture mapping)

IndependentUV texture addressing with Border for U and Clamp for V (border color is altered with default, blue, red, and green, after rotating texture mapping)

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.22 Texture Tests Description

5.121.2 Texture Filter – No MipMapping

Test renders a striped texture with various filter modes, uses both a 16x16 texture, and then a 256x256 texture, varies the mesh size, and compares with the reference rasterizer. The different filter modes used are:

  • Nearest min and Nearest mag
  • Nearest min and Bi-Linear mag
  • Bi-Linear min and Nearest mag
  • Bi-Linear min and Bi-Linear mag

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.22 Texture Tests Description

5.121.3 Texture Filter – MipMapping

Test renders a striped mip-mapped texture with different filters, uses three different colored mip-maps, the highest being 256x256, varies the mesh size, and compares with the Reference rasterizer. The different filters used are as follows:

  • MipNearest min
  • MipLinear min
  • MipLinear min
  • LinearMipLinear min

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.22 Texture Tests Description

5.121.4 Texture Blend

Test renders a striped types of textures, varies alpha values (none, mesh alpha, texture alpha, or both), rotates texture mapping, alters mesh color, tiles texture from 1 to 4, cycles texture formats, and compares with the reference rasterizer. The different types of textures rendered are as follows:

  • Decal Texture
  • Modulate Texture
  • DecalAlpha Texture
  • ModulateAlpha Texture
  • Copy Texture
  • Add Texture
  • Default Texture (using default blend settings)

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.22 Texture Tests Description


Stencil Test Assertions – DirectX 6

5.122.1 Stencil

Test each of the following: stencil caps, stencil/z clear, stencil functions, stencil ops, stencil corruption, and z corruption.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.36 Stencil Test Description


Texture Handle Test Assertions – DirectX 6

5.123.1 Texture Handle

The D3D Texture Handle test verifies that the hardware fails texture creation when the limit of useable texture handles is reached.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.31 W Buffer Test Description


Clipping Test Assertions – DirectX 6

5.124.1 The TL Vertex Clipping test.

This test verifies that a driver clips lines, generated from transformed and light vertices, correctly to a view port.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.56 Clipping Test Description "TL Vertex Clip"


OpenGL Test Assertions

The OpenGL Test analyzes basic OpenGL functionality.

5.129.1 The GL Coverage test

The GL Coverage test ensures that OpenGL implementation covers all the GL APIs.

Reference Documents: Windows 98 DDK and 2000 DDK
Test Description: TD-5.129 OpenGL Test Description

5.129.2 The GL Utilities Coverage test

The GL Utilities Coverage test ensures that OpenGL implementation covers all the GL Utility APIs.

Reference Documents: Windows 98 DDK and 2000 DDK
Test Description: TD-5.129 OpenGL Test Description

5.129.3 The Conformance ECP [-] test

Test analyzes pixel-by-pixel verification. The concept of an equivalent computational path, ECP, is introduced to test the same functionalities.

Reference Documents: Windows 98 DDK and 2000 DDK
Test Description: TD-5.129 OpenGL Test Description

5.129.4 The Conformance ECP [1] test

Test analyzes pixel-by-pixel verification. The concept of an equivalent computational path, ECP, is introduced to test the same functionalities.

Reference Documents: Windows 98 DDK and 2000 DDK
Test Description: TD-5.129 OpenGL Test Description

5.129.5 The Conformance ECP [2] test

Test analyzes pixel-by-pixel verification. The concept of an equivalent computational path, ECP, is introduced to test the same functionalities.

Reference Documents: Windows 98 DDK and 2000 DDK
Test Description: TD-5.129 OpenGL Test Description

5.129.6 The Conformance ECP [3] test

Test analyzes pixel-by-pixel verification. The concept of an equivalent computational path, ECP, is introduced to test the same functionalities.

Reference Documents: Windows 98 DDK and 2000 DDK
Test Description: TD-5.129 OpenGL Test Description

5.129.7 The GL Primitive test

Test analyzes pixel-by-pixel verification, drawing primitively in various rendering modes.

Reference Documents: Windows 98 DDK and 2000 DDK
Test Description: TD-5.129 OpenGL Test Description


Windows 9x GDI Test Assertions

The Windows 9x GDI Tests check for basic Graphics Device Interface functionality of the Windows 98 operating system.

5.130.1 The Win GDI test

Test uses Guiman.exe to play .emf files; "extended metafiles" to test "Brush Alignment", "Text Output", "Region Output", "FloodFill Output", "MaskBlt Output", "BitBlt Output", "StretchBlt Output", "SetDIBitsTpDevice Output", "StretchDIBits Output", "Pen Output", "PlgBlt Output", "Binary Ropcode", "Path", and "StretchBltMode."

Reference Document: Windows 98 DDK
Test Description: TD-5.130 Display Windows 9x GDI Test Description

5.130.2 The GDI w/rect clip test

Test uses Guiman.exe to play .emf files; "extended metafiles" to test "Brush Alignment", "Text Output", "Region Output", "FloodFill Output", "MaskBlt Output", "BitBlt Output", "StretchBlt Output", "SetDIBitsTpDevice Output", "StretchDIBits Output", "Pen Output", "PlgBlt Output", "Binary Ropcode", "Path", and "StretchBltMode, using a rectangular clipping region during all blts.

Reference Document: Windows 98 DDK
Test Description: TD-5.130 Display Windows 9x GDI Test Description

5.130.3 The GDI w/poly clip test

I10engn fires INT 10h according to standard VGA and VESA specs, except for INT 10h AX=4F14. The software interrupt and register definitions for the test are defined in an easy-to-read script. Register sets are compared before and after the execution of the software interrupts, according to the definitions in the script file. If any discrepancy is noted, the test attempts to log an error or faults.

Reference Document: Windows 98 DDK
Test Description: TD-5.130 Display Windows 9x GDI Test Description

5.132.4 The GDI Stretch Blt test

Test uses BitBlt with MM_ANISOTROPIC from an off screen memory surface that is wider than the primary surface, and one-pixel high, to fill a window. If the window is not completely black after the blt, the test fails.

Reference Document: Windows 98 DDK
Test Description: TD-5.130 Display Windows 9x GDI Test Description

5.130.5 The BugZapper test

Test first checks for presence of a mini driver, then calls Escape (hDC, QUERYESCSUPPORT, &QUERYDIBSUPPORT, NULL). MiniDrivers are required to forward QUERYDIBSUPPORT escape. For mini drivers to pass this test, they must pass the escape call onto the DIBENG, which returns 21072 (0x5250).

Reference Document: Windows 98 DDK
Test Description: TD-5.130 Display Windows 9x GDI Test Description

5.130.6 The VFW AVI test

Test ensures that the graphics adapter is able to play an .avi file in a window as well as full screen in all modes.

Reference Document: Windows 98 DDK
Test Description: TD-5.130 Display Windows 9x GDI Test Description

5.130.7 The Magic School Bus test

The test uses INT 0x2F AX=0x4001 and INT 0x2F AX=0x4002, without calling the mini drivers Enable() and Disable() functions first. This code is demonstrated in the sample driver file Sswitch.asm (screen switch sample code). Purpose: shipping 16-bit applications needed this support.

Reference Document: Windows 98 DDK
Test Description: TD-5.130 Display Windows 9x GDI Test Description


DTA Test Assertions

5.131.1 The DTA Pen test

The DTA Pen test is a Visual test to automate the use of a wide variety of GDI "Pen" operations.

Reference Document: Windows 98 DDK
Test Description: TD-5.130 Display Windows 9x GDI Test Description

5.131.2 The DTA Brush test

The DTA Brush test is a Visual test to automate the use of a wide variety of GDI "Brush" operations.

Reference Document: Windows 98 DDK
Test Description: TD-5.130 Display Windows 9x GDI Test Description

5.131.3 The DTA Prim test

The DTA Prim test is a Visual test to automate the use of a wide variety of GDI Drawing operations.

Reference Document: Windows 98 DDK
Test Description: TD-5.130 Display Windows 9x GDI Test Description

5.131.4 The DTA Misc test

The DTA Misc test is a Visual test to automate the use of a wide variety of GDI Drawing, Fill, Pen, and Brush operations.

Reference Document: Windows 98 DDK
Test Description: TD-5.130 Display Windows 9x GDI Test Description


DIBView Test Assertions

5.132.1 The DibView BMP Palette test

Test executes a generic Bitmap Viewer that opens a variety of picture formats and applies logical vs. physical palette to them.

Reference Document: Windows 98 DDK
Test Description: TD-5.130 Display Windows 9x GDI Test Description

5.132.2 The DibView BMP Stretch test

Test executes a generic Bitmap Viewer that opens a variety of picture formats and applies stretch operations to them.

Reference Document: Windows 98 DDK
Test Description: TD-5.130 Display Windows 9x GDI Test Description

5.132.3 The DibView BMP Scroll test

Test executes a generic Bitmap Viewer that opens a variety of picture formats and uses scrolling in a window.

Reference Document: Windows 98 DDK
Test Description: TD-5.130 Display Windows 9x GDI Test Description

5.132.4 The DibView BMP Format test

Test executes a generic Bitmap Viewer that opens a variety of picture formats.

Reference Document: Windows 98 DDK
Test Description: TD-5.130 Display Windows 9x GDI Test Description


Ratetest Test Assertions

5.133.1 The Rate test

The test switches to all enumerated GDI display modes, all available low-resolution GDI low-resolution modes (< 640x480 pixels), and enumerated DirectDraw full-screen modes. The test then intersects these two sets of modes, and validates that the set of DirectX enumerated modes exist in the set of GDI enumerated modes. The test switches to these modes, and validates that the refresh rate actually produced by the card matches the refresh rate that the driver says is being output. Refresh rate is validated using IDirectDraw::GetVerticalBlankStatus. After each mode is set, the test puts up a DOS box, to ensure that virtualization of VGA hardware works correctly for each mode.

Reference Document: Windows 98 DDK
Test Description: TD-5.130 Display Windows 9x GDI Test Description


GUIMan Display Test Assertions

5.134.1 The GUIMan Display

Tests basic functionality. The test uses Guiman.exe to "play" .emf files. Briefly Covers "Brush Alignment", "Text Output", "Region Output", "FloodFill Output", "Pen Output", "Binary Ropcode", and "Path."

Reference Document: Windows 98 DDK
Test Description: TD-5.130 Display Windows 9x GDI Test Description


AMovie Test Assertions

5.135.1 The AMovie test

Test plays a variety of video formats in all available video modes. Verifies completion of each playback.

Reference Document: Windows 98 DDK
Test Description: TD-5.130 Display Windows 9x GDI Test Description


Character Mode Test Assertions

5.136.1 The Character Mode Test 1

Test creates a DOS box and performs "dir .. /s" in several column widths and line heights, including full-screen mode. Next, it displays characters in positions to form a rectangle, then displays several lines of extended character text in 16 "colors" in mode "3." Next, it displays a long stream of extended character text in mode "3", then mode "11", and then mode "12."

Reference Document: Windows 98 DDK
Test Description: TD-5.130 Display Windows 9x GDI Test Description

5.136.2 The Character Mode Test 2

Test creates a DOS box and displays characters in positions to form a rectangle, then displays several lines of extended character text in 16 "colors" in mode "11."

Reference Document: Windows 98 DDK
Test Description: TD-5.130 Display Windows 9x GDI Test Description

5.136.3 The Character Mode Test 3

Test creates a DOS box and displays characters in positions to form a rectangle, then displays several lines of extended character text in 16 "colors" in mode "12."

Reference Document: Windows 98 DDK
Test Description: TD-5.130 Display Windows 9x GDI Test Description


Direct Show Test Assertions

5.137.1 The Direct Show Test

The Direct Show test verifies the completion of a video along with a mixture of Direct Show API calls to test the performance of the driver.

Reference Documents: The DirectX DDK, the Reference Rasterizer Source section of the DirectX DDK, and the DirectX SDK.

Test Description: TD-5.137 Direct Show Test Description


Windows 2000 GDI Test Assertions

The Win2000 GDI Test checks for basic Graphics Device Interface functionality on the Windows 2000 operating system.

5.150.1 The GUIMAN Win GDI (gmvideo3) test

Test assesses playback .emf files in every enumerated mode and compares Screen Blt to Memory Reference. Tests "Brush Alignment", "Text Output", "Region Output", "FloodFill Output", "MaskBlt Output", "BitBlt Output", "StretchBlt Output", "SetDIBitsTpDevice Output", "StretchDiBits Output", "Pen Output", "PlgBlt Output", "Binary Ropcode", "Path", "StretchBltMode", and "TransparentBlt."

Reference Document: Windows 2000 DDK
Test Description: TD-5.150 Display Windows 2000 GDI Test Description

5.150.2 The GUIMAN GDI w/poly clip (gmvideo6) test

Test assesses playback .emf files in every enumerated mode and compares Screen Blt to Memory Reference. This test evaluates "Brush Alignment", "Text Output", "Region Output", "FloodFill Output", "MaskBlt Output", "BitBlt Output", "StretchBlt Output", "SetDIBitsTpDevice Output", "StretchDiBits Output", "Pen Output", "PlgBlt Output", "Binary Ropcode", "Path", "StretchBltMode", and "TransparentBlt"with a star-shaped clipping region applied to it.

Reference Document: Windows 2000 DDK
Test Description: TD-5.150 Display Windows 2000 GDI Test Description

5.150.3 The GUIMAN GDI w/rect clip (gmvideo9) test

Test plays back .emf files in every enumerated mode and compares Screen Blt to Memory Reference. This test evaluates "Brush Alignment", "Text Output", "Region Output", "FloodFill Output", "MaskBlt Output", "BitBlt Output", "StretchBlt Output", "SetDIBitsTpDevice Output", "StretchDiBits Output", "Pen Output", "PlgBlt Output", "Binary Ropcode", "Path", "StretchBltMode", and "TransparentBlt"with a rectangular-shaped clipping region applied to it.

Reference Document: Windows 2000 DDK
Test Description: TD-5.150 Display Windows 2000 GDI Test Description

5.150.4 [Updated v0.7] The Check Resolution (chndsp) test

Test changes to every enumerated display mode, and validates the mode if the change was successful. Tests also include verification of mode changes that support rotated screen orientations.

Reference Document: Windows 2000 DDK
Test Description: TD-5.150 Display Windows 2000 GDI Test Description

5.150.5 The GDIMAN General StretchBlt (gdimvb1m) test

Test creates an abstract image, then does StretchBlt from a source rectangle of the image to a destination rectangle in the same image cycling through the following Rops: BLACKNESS, DSTINVERT, MERGECOPY, MERGEPAINT, NOTSRCCOPY, NOTSRCERASE, PATCOPY, WHITENESS, PATINVERT, PATPAINT, SRCAND, SRCCOPY, SRCERASE, SRCINVERT, SRCPAINT, and these StretchBltModes = COLORONCOLOR BLACKONWHITE WHITEONBLACK. The test then repeats the process using BitBlt and the same Rops. Each case verifies against a guaranteed offscreen GDI Reference.

Reference Document: Windows 2000 DDK
Test Description: TD-5.150 Display Windows 2000 GDI Test Description

5.150.6 The GDIMAN Off Screen In->Out (gdimv8b2) test

Test creates an abstract image, then does StretchBlt from a source rectangle of the image to a destination rectangle in the same image cycling through the following Rops: BLACKNESS, DSTINVERT, MERGECOPY, MERGEPAINT, NOTSRCCOPY, NOTSRCERASE, PATCOPY, WHITENESS, PATINVERT, PATPAINT, SRCAND, SRCCOPY, SRCERASE, SRCINVERT, SRCPAINT, as well as the following StretchBltModes = COLORONCOLOR BLACKONWHITE WHITEONBLACK. The test then repeats the process using BitBlt and the same Rops. Each case verifies against a guaranteed offscreen GDI Reference and the destination rectangle lies partially outside of the screen area. This tests all four corners in this manner.

Reference Document: Windows 2000 DDK
Test Description: TD-5.150 Display Windows 2000 GDI Test Description

5.150.7 The GDIMAN Off Screen Out->In (gdimv8b3) test

Test creates an abstract image, then does StretchBlt from a source rectangle of the image to a destination rectangle in the same image cycling through these Rops: BLACKNESS, DSTINVERT, MERGECOPY, MERGEPAINT, NOTSRCCOPY, NOTSRCERASE, PATCOPY, WHITENESS, PATINVERT, PATPAINT, SRCAND, SRCCOPY, SRCERASE, SRCINVERT, SRCPAINT, and these StretchBltModes = COLORONCOLOR BLACKONWHITE WHITEONBLACK. The test then repeats the process using BitBlt and the same Rops. Each case verifies against a guaranteed offscreen GDI Reference and the source rectangle lies partially outside of the screen area. This tests all four corners in this manner.

Reference Document: Windows 2000 DDK
Test Description: TD-5.150 Display Windows 2000 GDI Test Description

5.150.8 The GDIMAN Degenerate StretchBlt – scaling up (gdimvb4m) test

Test creates an abstract image, then does StretchBlt from a source rectangle of the image to a destination rectangle in the same image cycling through these Rops: BLACKNESS, DSTINVERT, MERGECOPY, MERGEPAINT, NOTSRCCOPY, NOTSRCERASE, PATCOPY, WHITENESS, PATINVERT, PATPAINT, SRCAND, SRCCOPY, SRCERASE, SRCINVERT, SRCPAINT, and these StretchBltModes = COLORONCOLOR BLACKONWHITE WHITEONBLACK. The test then repeats the process using BitBlt and the same Rops. Each case verifies against a guaranteed offscreen GDI and the source rectangle has zero or one pixel height or width.

Reference Document: Windows 2000 DDK
Test Description: TD-5.150 Display Windows 2000 GDI Test Description

5.150.9 The GDIMAN Degenerate StretchBlt – scaling down (gdimvb5m) test

Test creates an abstract image, then does StretchBlt from a source rectangle of the image to a destination rectangle in the same image cycling through these Rops: BLACKNESS, DSTINVERT, MERGECOPY, MERGEPAINT, NOTSRCCOPY, NOTSRCERASE, PATCOPY, WHITENESS, PATINVERT, PATPAINT, SRCAND, SRCCOPY, SRCERASE, SRCINVERT, SRCPAINT, and these StretchBltModes = COLORONCOLOR BLACKONWHITE WHITEONBLACK. The test then repeats the process using BitBlt and the same Rops. Each case verifies against a guaranteed offscreen GDI and the destination.

Reference Document: Windows 2000 DDK
Test Description: TD-5.150 Display Windows 2000 GDI Test Description

5.150.10 The GuiJr Fonts test

Test exercises PolyTextOut, varying the following: String, Bounding Coordinates, Height, Width, Opacity, Clipping, BackColor, TextColor, Spacing, Center, Left, Right, Top, and Bottom.

Reference Document: Windows 2000 DDK
Test Description: TD-5.150 Display Windows 2000 GDI Test Description

5.150.11 The Gradient Fill test

Test executes and assesses a series of gradient fill operations, using horizontal rectangles, triangles, and clipped areas. The test compares onscreen with off-screen surface.

Reference Document: Windows 2000 DDK
Test Description: TD-5.150 Display Windows 2000 GDI Test Description

5.150.12 The Transparent Blt test

Test assesses TransparentBlt. Varies: DestRect, DestColor, TransparentColor, and the source bitmap.

Reference Document: Windows 2000 DDK
Test Description: TD-5.150 Display Windows 2000 GDI Test Description

5.150.13 The Unalign test

Test creates a chunk of memory in such a way that there are no accessible virtual addresses after it. Then, it converts this memory into a DIBSection (1bpp, 4bpp, 8bpp, 16bpp, 24bpp, and 32bpp) and uses it as a source to BitBlt, StretchBlt, TransparentBlt, and AlphaBlend. The ultimate goal is to cause an AV in the system.

Reference Document: Windows 2000 DDK
Test Description: TD-5.150 Display Windows 2000 GDI Test Description

5.150.14 The GDIMAN Rops

Test tests every combination of MaskBlt source Rops with destination Rops tested.

Reference Document: Windows 2000 DDK
Test Description: TD-5.150 Display Windows 2000 GDI Test Description

5.150.15 The GDI Stretched Blt test

Test creates compatible bitmaps of one pixel height and 1.5-screen width. I.e. in 800x600 mode the bitmap will be 1200x1. The test paints the bitmap with black. The MapMode is set to MM_ANISOTROPIC, ViewportExt and WindowExt are set so that the bitmap will match the application window. BitBlt is used to copy from bitmap to whole window. If everything works, the window is black.

Reference Document: Windows 2000 DDK
Test Description: TD-5.150 Display Windows 2000 GDI Test Description

5.150.16 The Alpha Blended Cursor test

Test invokes a program that displays a message saying that clicking the mouse means OK and right-clicking the mouse means failure. Then, it tests each cursor on each background: it fills the entire screen with the background color, places the ideal image in the center and places the mouse cursor to the left of it. The tester should visually compare the cursor with the image.

Reference Document: Windows 2000 DDK
Test Description: TD-5.150 Display Windows 2000 GDI Test Description

5.150.17 The GDI Alpha Blend Stretch Test

The GDI Alpha Blended test performs a series of blends on the display surface using various alpha blending configurations. These images are then compared against a mathematical calculation of what each pixel in the result. Each pixel has to be within a tolerance of +/- 1 in each color channel for the test to pass. Some of these configurations include constant and per-pixel alpha.

Reference Document: Windows 2000 DDK
Test Description: TD-5.150 Display Windows 2000 GDI Test Description


Video Rendering Test Assertions

5.170.1 The Overlay Scale test

Test examines the horizontal and vertical upscaling and downscaling. Specifically, this test verifies the correct overlay scaling capabilities for YUV surfaces. The surface is filled with a checkerboard pattern. Resizing the window should display a properly scaled pattern.

Correct Output: checkerboard pattern properly scaled or stretched.

Reference documents: WLP# - B4.1.4.11, DirectX SDK – DirectShow Reference, DirectX DDK – Design Guide – DirectDraw DDI
Test Description: TD-5.170 Video Rendering Display Test Description

5.170.2 The Overlay Luminance test

Test examines the correct luminance in a scaled or unscaled overlay surface. This test verifies the correct luminance of overlay surface. The luminance test shows a brightness flow from top to bottom. It is horizontally split into a left part, which is the overlay scaler, and the right part, which is the primary (this test is best performed in 24 or 32 bits). The operator should scale the window and check that the left side and the right side match (no discoloring on the left side).

Correct Output: gradient pattern.

Reference documents: WLP# - B4.1.4.11, DirectX SDK – DirectShow Reference, DirectX DDK – Design Guide – DirectDraw DDI
Test Description: TD-5.170 Video Rendering Display Test Description

5.170.3 The Flip Lock Delay test

Test analyzes the correct implementation of DirectDraw Flip, Lock and GetFlipStatus functions. Time measurements are used to check for correctness since these are usually a dead giveaway. What typically is found is that a Flip on one surface affects a different backbuffer on GetFlipStatus or a Lock on one backbuffer is dependent on a different backbuffer, which should not be the case.

Specifically, this test allocates an overlay flip chain with three buffers: frontbuffer, backbuffer and thirdbuffer. The test flips the frontbuffer with the backbuffer. If the thirdbuffer returns DERR_WASSTILLDRAWING on a call to GetFlipStatus, the implementations of this function is not surface specific, and therefore wrong.

The test then waits for the backbuffer to return DD_OK on a call to GetFlipStatus. This should take between 6 ms and 12 ms. If it takes less, then the implementation is not correct; the test locks the backbuffer. This should take about 60 microseconds. If the GetFlipStatus function is implemented incorrectly, this function will probably take some milliseconds. Then, the test flips the frontbuffer with the backbuffer. The test locks the thirdbuffer, without waiting for the flip to complete.

This should take 60 microseconds. If this takes in the range of milliseconds, then the implementation of Lock is wrong, because it waits on a flip of a different surface.

The results of the test are displayed on the caption bar: Flip [time for flip < 200] (Check [OK if GetFlipStatus is surface specific]); Delay [time for surface flip to complete > 6000]; LockBack [time for lock of backbuffer < 200]; LockThird [time for lock of thirdbuffer < 200].

Correct Output: black window with numeric output in caption bar

Reference documents: WLP# - 4.1.4.2; DirectX SDK – DirectShow Reference, DirectX DDK – Design Guide – DirectDraw DDI
Test Description: TD-5.170 Video Rendering Display Test Description

5.170.4 The Flip Status test

Test examines the implementation of GetFlipStatus. This tests that GetFlipStatus on one buffer is not affected by a Flip on a different buffer. Specifically, this test verifies the correct implementation of Flip, Lock and GetFlipStatus. This test allocates an overlay flip chain with three buffers: frontbuffer, backbuffer and thirdbuffer. All buffers are filled with black. The test flips the frontbuffer with the backbuffer. The third buffer is then flipped with the front buffer.

This should not affect any of the other buffers. If it does, the buffer fills with green. If the result is black, the function is correct. As the test runs, a white line appears to move horizontally across the window. If the line does not appear, the test failed.

If the thirdbuffer returns DDERR_WASSTILLDRAWING on a call to GetFlipStatus, the implementations of this function is not surface specific, and therefore wrong. This shows the correct behavior of GetFlipStatus(DDGFS_ISFLIPDONE). GetFlipStatus should only affect the two surfaces actually flipped, and not all in the flip chain.

Correct Output: white vertical bar on black background moving from left to right

Reference documents: WLP# - B4.1.4.2; DirectX SDK – DirectShow Reference, DirectX DDK – Design Guide – DirectDraw DDI
Test Description: TD-5.170 Video Rendering Display Test Description

5.170.5 The Flip BOB Order test

Test verifies whether flipping with several BOB'ed surfaces works in a random surface order. This test allocates an overlay flip chain with three buffers: frontbuffer, backbuffer and thirdbuffer. All buffers are filled with black. The surfaces are randomly flipped using the BOB and INTERLEAVE flags. The correct behavior would show a vertical white bar moving from left to right. The bar should not be split, and it should not jump around erratically.

Correct Output: white vertical bar on black background moving from left to right.

Reference documents: WLP# - B4.1.4.2; DirectX SDK – DirectShow Reference, DirectX DDK – Design Guide – DirectDraw DDI
Test Description: TD-5.170 Video Rendering Display Test Description

5.170.6 The Flip Lock Fill test

Test verifies whether the frame buffer writes have long-term stability. This test allocates an overlay flip chain with three buffers: frontbuffer, backbuffer and thirdbuffer.

Correct Output: random noise pattern.

Reference documents: WLP# - B4.1.4.2; DirectX SDK – DirectShow Reference, DirectX DDK – Design Guide – DirectDraw DDI
Test Description: TD-5.170 Video Rendering Display Test Description

5.170.7 The Flip-Multi Surface test

Test verifies the functionality of a flip-chain with five surfaces. The surfaces are filled with black and are then randomly flipped. The correct display shows a vertical white bar moving from left to right. The bar should not be split, and it should not jump around erratically.

Correct Output: white vertical bar on black background moving from left to right.

Reference documents: WLP# - B4.1.4.2; DirectX SDK – DirectShow Reference, DirectX DDK – Design Guide – DirectDraw DDI
Test Description: TD-5.170 Video Rendering Display Test Description

5.170.8 The Flip test

Test verifies whether interlocking of flipped surfaces works correctly. This test allocates two overlay buffers: a frontbuffer and a backbuffer. Both buffers are filled with black and a white vertical line. The buffers are flipped and filled with the inverse color and then filled with black again. The correct display will show a vertical white bar moving from left to right. The bar should not be split, and it should not jump around erratically.

Correct Output: white vertical bar on black background moving from left to right.

Reference documents: WLP# - B4.1.4.2; DirectX SDK – DirectShow Reference, DirectX DDK – Design Guide – DirectDraw DDI
Test Description: TD-5.170 Video Rendering Display Test Description

5.170.9 DELETED  See 5.170.14
5.170.10 CopyFourCC Test

This test that a video driver correctly implements the COPYFOURCC flag as defined by ddCaps.dwCaps2. First it verifies that the flag exists, then ensures that it is implemented properly. It does this by creating 2 YUV surfaces in video memory, writing an image to one of these surfaces, blting this image to the other surface and verifying that the correct image was blted. This blt function must take less than 8 ms.

Output: Pass/Fail Messages,

Reference documents: WLP# - B4.1.4.11, DirectX SDK – DirectShow Reference, DirectX DDK – Design Guide – DirectDraw DDI
Test Description: TD-5.170 Video Rendering Display Test Description

5.170.11 FlipBuffer Test:

This test verifies that video cards handle YUV surface flipping properly. A filter graph is created using a ball filter that will verify that the proper order of surfaces is being flipped. It does this by creating 3 surfaces and saving the memory location where these buffers are located. The surfaces are flipped sequentially, and if the memory location pointed to matches one of the other 2 surfaces, the test will fail.

Output: Pass/Fail Messages,

Reference documents: WLP# - B4.1.4.2; DirectX SDK – DirectShow Reference, DirectX DDK – Design Guide – DirectDraw DDI
Test Description: TD-5.170 Video Rendering Display Test Description

5.170.12 RGB Flip Buffer Test:

This creates a 16-bit RGB 3D render target overlay surface with 2 backbuffers. It then creates 2 additional 16-bit RGB surfaces. On one surface, an image is placed on one surface, on the other; a blue background is painted with a moving green box. Both of these surfaces are blended to the backbuffer of the overlay surface, then flipped. If any part of the blending or flipping fails, the test fails. If the image on the screen does not match what is expected, the test fails. An additional command line flag "/perf" will verify that the frame rate exceeds 40, if not the test fails. This perf test if fully automated and is added as its own test to the DCT.

Output: Pass/Fail Messages, Blue background is painted with a moving green box

Reference documents: WLP# - B4.1.4.2, B4.1.4.11; DirectX SDK – DirectShow Reference, DirectX DDK – Design Guide – DirectDraw DDI
Test Description: TD-5.170 Video Rendering Display Test Description

5.170.13 NonPower2Cond Test

The NonPower2Conditional test will verify if the D3DPTEXTURECAPS_NONPOW2CONDITIONAL cap is enabled (see D3DPRIMCAPS). If so the test precedes as below, if not, the test will proceed but will not fail. If the card appears capable of supporting the cap but the cap is not enabled, the test will issue a warning.

The test creates a textured surface, which is not a power of two in either dimension. A back buffer is created and colored with alternating black and white stripes. It will then 3D alpha blend that texture to the back buffer and then blit the results to the primary surface. If the texture creation fails or if the blend fails to produce the proper results, the test will fail.

Output: Pass/Fail Messages, black and white background with a moving red box alpha blended over it.

Reference documents: WLP# - B4.1.4.2; DirectX SDK – DirectShow Reference, DirectX DDK – Design Guide – DirectDraw DDI
Test Description: TD-5.170 Video Rendering Display Test Description

5.170.14 [Revised v0.5] FOURCC Blt, Stretch, and Performance Test

Test Description: The Four Character Codes (FOURCC) Blt, Stretch, and Performance test includes two tests. The first test checks the accuracy of the YUV-to-RGB conversion. The second test checks the speed of the converting bit-block transfer (blt).

The first test creates a YUV off-screen surface in various YUV formats and an RGB texture off-screen surface. (The test checks 32-bit RGB 8888, 16-bit 565, and 16-bit 555 formats.) The test then initializes the YUV surface to black, starting in the upper-left corner with linearly increasing intensity that progresses toward the lower-right corner. The test does several YUV-to-RGB stretch blts and verifies the output by locking the RGB surface and checking the output pixel values to ensure that they are converted to the appropriate format.

Output: Pass/Fail Messages.

The second test verifies the blt performance of YUV surfaces (needed for multiple decode). The test creates four off-screen surfaces and fills the surfaces with different shades of gray. The first test measures blt performance by blitting an off-screen YUV surface into the primary surface and waiting for the blt status to return that the flip is done. The second test performs an off-screen YUV surface blt into the primary surface and then attempts to lock a different off-screen surface.

The results of the test are displayed on the caption bar:

Blit: The time spent in the blt function, which should be less than 50 microseconds.

Wait: The time spent doing the blt, which should be greater than 1 millisecond and less than 6 milliseconds. If this is less than 1 millisecond, it indicates that the GetBltStatus function is not working properly.

Lock1: The time to lock the primary surface and wait for a safe scan line position to perform the blt, which should be between 4 and 8 milliseconds, depending on the current video refresh rate.

Lock2: The time to lock an off-screen surface after a blt, which should be less than 100 microseconds. The locked surface is not used in a previous blt, so the lock should succeed immediately. If the lock takes more than 100 microseconds, there might be a problem in hardware or the lock function might not be implemented properly.

Output: Pass/Fail Messages. A flashing pattern indicates correct output.

Reference documents: WLP# - B4.1.4.2; B4.1.4.11; DirectX SDK – DirectShow Reference, DirectX DDK – Design Guide – DirectDraw DDI
Test Description: TD-5.170 Video Rendering Display Test Description

5.170.15 Switch Flip Bob Weave Test

Tests how smoothly graphics cards can switch between BOB and WEAVE. This test updates the overlay surface alternating between normal update (no flags) and updating with the DDOVER_BOB and DDOVER_INTERLEAVED flags. There should be no flickering in the display.

Reference documents: WLP# - B4.1.4.11; DirectX SDK – DirectShow Reference, DirectX DDK – Design Guide – DirectDraw DDI
Test Description: TD-5.170 Video Rendering Display Test Description

5.170.15 Switch Flip Bob Weave Test

This tests that the implementation of UpdateOverlay is atomic. This test flips between three different surfaces using update overlay from different areas of memory. The scaling and the position should take effect at the same point during display, e.g. in vertical blank or at the end of the overlay rectangle. If the scaling changes first, this causes the previous overlay buffer to be displayed with the scaling for the next one. This test shows this effect quite clearly. This test checks whether update overlay happens flicker free.

Reference documents: WLP# - B4.1.4.11; DirectX SDK – DirectShow Reference, DirectX DDK – Design Guide – DirectDraw DDI
Test Description: TD-5.170 Video Rendering Display Test Description

5.170.17 Flip Bob Interleaved/Non-Interleaved Test

Flip Bob Non-Interleaved: Tests correct implementation of Flip using BOB. This test uses the DirectDraw Flip function to flip even and odd surfaces using the DDOVER_BOB flag to update the overlay. The buffer is filled with a checkerboard pattern. Since the test is flipping between odd and even surfaces, the checkerboard should jump up and down by one line. It should not flicker or jump uncontrolled.

Flip Bob Interleaved: Tests correct implementation of Flip using BOB and INTERLEAVED. This test uses the DirectDraw Flip function to flip even and odd surfaces using the DDOVER_BOB and DDOVER_INTERLEAVED flags to update the overlay. The correct behavior would be jumping up and down, and flashing on the outer border. If there is no flashing then there is no switch between the two source fields. The usage of interleaved BOBBING is necessary to switch between BOB and WEAVE on the fly, which is needed for most DVD titles. Otherwise the full movie has to be played as either BOB or WEAVE. This results in all movies played as BOB, because there is no way for the decoder to know ahead of time, and it therefore has to take the safe way.

Reference documents: WLP# - B4.1.4.2; DirectX SDK – DirectShow Reference, DirectX DDK – Design Guide – DirectDraw DDI
Test Description: TD-5.170 Video Rendering Display Test Description


DXVA Test Assertions - DirectX

5.171.1 DXVA Display Test – Logo Requirement B4.1.1.9

This test is designed to test DirectX Video Acceleration (DXVA) enabled VGA Display Drivers. It will test for support of at least one of the minimal DXVA configurations and will test all supported configurations including subpicture/alpha blending configurations. Testing will be through a combination of automated and visual verifications.

Output: Pass/Fail Messages, Intelligible video should be output to the screen. In configurations supporting alpha blending, the word "Test!" should fade in and out over the top of the video. The word should be white (not blue) and should not be underlined or have any markings other than the characters. The frame rate will vary depending on the amount of acceleration available on the display device. The video may be slow and/or jerky. This is expected. This test is concerned with the quality of the decoded frames, not the rate at which they are delivered. The video is short and will only display ~40 frames or 8 seconds, whichever comes sooner. The log will say "Overall Test Passed" or "Overall Test Failed" depending on the supported configurations and responses from the tester.

Reference documents: WLP# - B4.1.1.9, DirectX 8 SDK – DirectShow – Decoder Development
Test Description: TD-5.170 Video Rendering Display Test Description


Display Power Management Test Assertions

The system power management test assertions are divided into three major groups: minimum BIOS assertions, minimum system assertions, and general functionality assertions.

The software which implements these assertions is SUSPENDER (suspend.exe), a Windows-based application compliant with Windows 98/Me and Windows 2000. Suspender verifies that the system complies with relevant specifications and confirms that system components function properly after resuming from low-power states.


Minimum BIOS

5.190.1 The system BIOS must be compliant with the Advanced Configuration and Power Interface (ACPI) Specification version 1.0b or later and the BIOS must be running in ACPI mode.

SUSPENDER verifies the presence of a fully functional ACPI BIOS device.

Reference Documents: DirectX DDK, DirectX SDK.
Test description: WHQL Test Specification, assertion 3.41.1

5.190.2 The system BIOS must support a real-time clock wakeup alarm.

SUSPENDER verifies this attribute via the Win32 API function SetWaitableTimer, which returns an error on machines that lack this capability.

Reference Documents: DirectX DDK, DirectX SDK.
Test description: WHQL Test Specification, assertion 3.41.2

5.190.3 The system BIOS must implement at least one system sleep state.

SUSPENDER verifies the presence of sleep states S1, S2, S3, and S4 via the OS power policy manager.

Reference Documents: DirectX DDK, DirectX SDK.
Test description: WHQL Test Specification, assertion 3.41.3


Minimum System

5.191.1 The real-time clock wakeup alarm must wake the system from each supported S1, S2, and S3 system sleep states.

SUSPENDER places the system into each of the supported S1, S2, or S3 states and then verifies that the real-time clock wakeup alarm wakes the system.

Reference Documents: DirectX DDK, DirectX SDK.
Test description: WHQL Test Specification, assertion 3.42.1

5.191.2 The real-time clock wakeup alarm must wake the system from S4, if so indicated, by the Fixed ACPI Description Table.

If the system is capable of OS hibernation, SUSPENDER places the system into the S4 state and then verifies that the real-time clock wakeup alarm wakes the system.

Reference Documents: DirectX DDK, DirectX SDK.
Test description: WHQL Test Specification, assertion 3.42.2

5.191.3 The system must be able to enter S4 or S5 if it supports OS hibernation.

If the system is capable of OS hibernation, SUSPENDER places the system into the S4 or S5 state and either reboots the machine or wakes from the real-time clock wakeup alarm as appropriate.

Reference Documents: DirectX DDK, DirectX SDK.
Test description: WHQL Test Specification, assertion 3.42.3


General System Functionality

5.192.1 The system audio device must function after resuming from low-power states.

If the system successfully plays a WAV file before entering a low-power state, then SUSPENDER verifies the system audio device properly plays a WAV file after resuming from all supported low-power states.

Reference Documents: DirectX DDK, DirectX SDK.
Test description: WHQL Test Specification, assertion 3.43.1

5.192.2 The serial communications port must function after resuming from low-power states.

If SUSPENDER detects a serial communications port before entering a low-power state, then it prompts the user to attach a loopback device to the serial port's external connector. SUSPENDER then verifies that the serial communications port transmits and receives properly after resuming from all supported low-power states.

Reference Documents: DirectX DDK, DirectX SDK.
Test description: WHQL Test Specification, assertion 3.43.2

5.192.3 The network interface card must be able to ping the default gateway after resuming from low-power states.

If SUSPENDER is able to ping the default gateway before entering a low-power state, then it verifies that the system can successfully ping the gateway after resuming from all supported low-power states.

Reference Documents: DirectX DDK, DirectX SDK.
Test description: WHQL Test Specification, assertion 3.43.3

5.192.4 The number of functioning devices in the system before and after resuming from low-power states must remain the same.

SUSPENDER determines the total number of devices in the system and the number of devices with problem codes before entering a low-power state. After resuming, it verifies that these numbers remain the same.

Reference Documents: DirectX DDK, DirectX SDK.
Test description: WHQL Test Specification, assertion 3.43.4

5.192.5 The system floppy disk drive must function after resuming from low-power states.

If SUSPENDER detects a floppy disk controller before entering a low-power state and determines a floppy disk is present, then it inputs multiple files from the floppy disk after resuming from all supported low-power states.

Reference Documents: DirectX DDK, DirectX SDK.
Test description: WHQL Test Specification, assertion 3.43.5

5.192.6 The system hard disk drive must function after resuming from low-power states.

exercises the file system by inputting multiple files from the Windows directory after resuming from all supported low-power states.

Reference Documents: DirectX DDK, DirectX SDK.
Test description: WHQL Test Specification, assertion 3.43.6

5.192.7 APM/ACPI Display Class Power Test

APMDISP uses the undocumented WM_MONITORPOWER message to initiate User.exe's power management state setting code. This is the same code that is executed when a suspend/resume cycle is initiated. This, in effect, causes the main VDD to set the display card into D0, D2, or D3. On a transition from any sleep state greater than D0 to D0, the test polls the refresh rate using an IDirectDraw, IDirectDraw4, or IDirectDraw7 interface coupled with GetMonitorFrequency(failing on NT only), GetVerticalBlackStatus, and WaitForVerticalBlanck(). The test then compares its results against each other against a tolerance of 1Hz.

Reference Documents: DirectX DDK, DirectX SDK.
Test description: TD-5.192 APM/ACPI Display Class Power Test Description


PCI D3 Windows 98 Graphics Adapter Functionality Test Assertions

5.200.1 Suspend/Resume Switch Test (S3 state).

Reference Documents: PC 99 System Design Guide, section 14.54 and "Default Device Class Power Management Specification," Version 1.0 or later.
Test description: TD-5.200 Display PCI D3 Graphics Adapter Functionality, Windows 98 Test Description

5.200.2 Suspend/Resume Staging Test (S3 state).

Reference Documents: PC 99 System Design Guide, section 14.54 and "Default Device Class Power Management Specification," Version 1.0 or later.
Test description: TD-5.200 Display PCI D3 Graphics Adapter Functionality, Windows 98 Test Description

5.200.3 Reference Application (Microsoft* Combat Flight Simulator) Switch test (S3 state).

Reference Documents: PC 99 System Design Guide, section 14.54 and "Default Device Class Power Management Specification," Version 1.0 or later.
Test description: TD-5.200 Display PCI D3 Graphics Adapter Functionality, Windows 98 Test Description

5.200.4 Suspend/Resume testing of Video cards using DirectDraw samples from DirectX.

Reference Documents: PC 99 System Design Guide, section 14.54 and "Default Device Class Power Management Specification," Version 1.0 or later.
Test description: TD-5.200 Display PCI D3 Graphics Adapter Functionality, Windows 98 Test Description


AGP Interface Test Assertions

5.210.1 The AGP Interface Test

Test ensures that AGP configuration registers, used by the operating system to initialize AGP features, are correctly implemented by both the master and target (chipset) device.

Reference Documents: Chapter 8, section 8.1, "AGP Interface Test."
Test description: TD-5.210 Display AGP Interface Test Description

5.210.2 The AGP memory management test

Test verifies that non-local video memory can be allocated and used directly for AGP operations, support for a Graphics Address Remapping Table (GART) and Write Combining (WC) Memory (for processors which provide WC) is confirmed, un-cached memory mapping of the Graphics Aperture is verified for processors which do not support WC and Integrity of the GART allocation/alignment and allocation/free is confirmed.

Reference Documents: Chapter 8, section 8.1, "AGP Interface Test."
Test description: TD-5.210 Display AGP Interface Test Description

5.210.3 The AGP transfer mode test

Test involves moving a known bit pattern through AGP system memory into local video memory. The test then checks for data corruption by comparing the results of the transfer with the known bit pattern.

Reference Documents: Chapter 8, section 8.1, "AGP Interface Test."
Test description: TD-5.210 Display AGP Interface Test Description


Monitor Test Assertions

5.220.1 The EDID Test

Test involves retrieving EDID data from monitor software key, verifying key fields of EDID structure, and comparing modes reported from monitor with the modes reported by the associated display adapter.

EDID Version 1: For devices that are required to have an EDID, all fields of the EDID must be decodable and usable according to the respective VESA E-EDID specification. For devices that are not required to have an EDID but need to create a monitor devnode for the OS, the EDID must have a valid header, established timing descriptor, & checksum, along with a manufacture ID of either "PNP" or "MS_". All other parts of the EDID must be zero.

Reference document: WLP# - B4.2.2.1, VESA E-EDID Standard Release A, Revision 1
Test description: TD-5.220 Monitor Tests Description


3D Graphics Hardware Requirements Not Tested

The requirements not tested include:

  • Hardware acceleration for video playback
  • Hardware acceleration for 2D graphics
  • Multiple-adapter and multiple monitor support
  • Television output
  • Plug and play
  • Bus design
  • Power management
  • Device driver requirements


Display Test Assertions: Part B - Hardware

This section defines assertions based on WLP# - that refer to the Graphics Adapter chapter in the PC 2001 System Design Guide. Because the interactions between Windows and graphics hardware are optimized in the operating system, no tests have been provided with this hardware section of the test specification.

All of software and hardware assertions (in Section A and Section B) replace earlier assertions.

Assertion | Assertion Description | Status
5.20.1 5.100.1 | The following adapter features must be supported in full-screen mode: 3D graphics mode, 800 x 600 resolution 16 bpp color depth, double buffering, 16 bit Z buffer, and 75 Hz refresh rate. | Superseded by 5.553.1
5.20.2 5.100.2 | All required rasterization features must be available at the same time (Textures, Alpha blending, Lighting, Fogging). | Superseded by 5.554.5
5.20.3 5.100.3 | Graphics adapter/driver must conform to Microsoft* Direct3D rasterization rules. | Superseded by Section A
5.20.5 5.100.5 | MIP mapped textures must be supported. | Intent carried forward by 5.554.1
5.20.6 5.100.6 | Bilinear or better filtered textures rather than point-sampled with perspective correction must be supported. | Intent carried forward by 5554.2
5.29.1 | The following eight Direct3D source alpha blending modes are required: D3DBLEND_DESTCOLOR, D3DBLEND_INVDESTCOLOR, D3DBLEND_INVSRCALPHA, D3DBLEND_INVSRCCOLOR, D3DBLEND_ONE, D3DBLEND_SRCALPHA, D3DBLEND_SRCCOLOR, D3DBLEND_ZERO. The following five Direct3D source and destination alpha blending modes are recommended: D3DBLEND_BOTHINVSRCALPHA, D3DBLEND_BOTHSRCALPHA, D3DBLEND_DESTALPHA, D3DBLEND_INVDESTALPHA, D3DBLEND_SRCALPHASAT | Superseded by 5.555.1 and 5.555.2
5.24.1 | Flat and Gouraud shading must be supported. | Intent carried forward by 5.556.1
5.33.1 | Fog of an arbitrary color, calculated on a per vertex basis, must be supported. | Superseded by 5.556.3
5.40.1 5.104.1 | Specular highlighting must be supported. | Intent carried forward by 5.556.2

Each assertion describes its relationship to the PC 2001 and PC 99 System Design Guide, to help OEMs and IHVs in tracking the changes. This information is found in the PC99 Notes portion of each assertion.


2D Graphics Assertions

5.550.1 Graphics adapter must enumerate and initialize an appropriate monitor to the following resolutions 640x480, 800x600, and 1024x768, using 32 bits/pixel color depth, a double-buffered memory solution, and a refresh rate of 85Hz.

Reference Documents: PC 2001 System Design Guide, GRPH-0168, GRPH-0169
PC99 Notes: No PC 99 assertion available; supersedes intent of PC 99 System Design Guide Requirement 14.8

5.550.2 Graphics adapters (when attached to DDC-compliant monitors and monitors that support 1024x768 non-interlaced modes) must default to a non-interlaced refresh rate when initialized to a 1024x768 video mode.

Reference Document: PC 2001 System Design Guide, GRPH-0169
PC99 Notes: No PC 99 assertion available; carries forward intent of PC 99 System Design Guide Requirement 14.9

5.550.3 Additional supported resolutions must conform to timings specified by the VESA Computer Display Monitor Timing Specification Version 1.0, Revision 0.8 or the VESA Generalized Timing Specification, Version 1.1.

Reference Document: PC 2001 System Design Guide, GRPH-0169
PC99 Notes: No PC 99 assertion available; carries forward intent of PC 99 System Design Guide Requirement 14.9.

5.550.4 Graphics adapters must support frame buffers that are accessible asynchronously by the CPU and graphics adapter.

Reference Document: PC 2001 System Design Guide, GRPH-0182
PC99 Notes: No PC 99 Assertion available; Carries forward intent of PC99 System Design Guide Requirement 14.9

5.550.5 Graphics adapters must support direct, synchronous operations, while asynchronous operations are being executed.

Reference Document: PC 2001 System Design Guide, GRPH-0182
PC99 Notes: No PC99 assertion available; carries forward intent of PC 99 System Design Guide Requirement 14.22

5.550.6 Graphics adapters must support asynchronous blt operations between the CPU and graphics adapter.

Reference Document: PC 2001 System Design Guide, GRPH-0183
PC99 Notes: No PC 99 assertion available; carries forward intent of PC99 System Design Guide Requirement 14.22

5.550.7 Graphics adapters must default to executing blt operations during vertical blanking interval, unless DirectX operations request otherwise.

Reference Document: PC 2001 System Design Guide, GRPH-0184
PC99 Notes: No PC 99 assertion available; carries forward intent of PC 99 System Design Guide Requirement 14.25

5.550.8 Graphics adapters must implement a mechanism to prevent the visible artifact known as tearing during the vertical blanking interval (VBI).

Reference Document: PC 2001 System Design Guide, GRPH-0184
PC99 Notes: No PC 99 Assertion available; carries forward intent of PC 99 System Design Guide Requirement 14.25


Color and Gamma Assertions

5.551.1 If 32-bit/pixel color capability is enumerated, it must have the following color ordering for the bits (listed from most significant bit to least significant bit): 8 bits alpha, 8 bits red, 8 bits green, 8 bits blue.

Reference Document: PC 2001 System Design Guide, GRPH-0170
PC99 Notes: No PC 99 assertion available; carries forward intent of PC 99 System Design Guide Requirement 14.10.

5.551.2 If 24-bit/pixel color capability is enumerated, it must have the following color ordering for the bits (listed from most significant bit to least significant bit): 8 bits red, 8 bits green, 8 bits blue.

Reference Document: PC 2001 System Design Guide, GRPH-0170
PC99 Notes: No PC99 assertion available; carries forward intent of PC 99 System Design Guide Requirement 14.10.

5.551.3 If hardware supports 16-bit/pixel color depth capability then it must enumerate it and have the following color ordering for the bits (listed from most significant bit to least significant bit): 5 bits red, 6 bits green, 5 bits blue.

Reference Document: PC 2001 System Design Guide, GRPH-0170
PC99 Notes: No PC 99 assertion available; carries forward intent of PC 99 System Design Guide Requirement 14.10.

5.551.4 If hardware supports 15-bit/pixel color depth, then it must have the following color ordering for the bits: (listed from most significant bit to least significant bit): 5 bits red, 5 bits green, 5 bits blue.

Reference Document: PC 2001 System Design Guide, GRPH-0170
PC99 Notes: No PC 99 assertion available; carries forward intent of PC 99 System Design Guide Requirement 14.10.

5.551.5 If hardware supports 15-bit/pixel color depth, and it does not support 16-bit/pixel color depths, then it must enumerate the color depth to be 16-bit/pixel capable.

Reference Document: PC 2001 System Design Guide, GRPH-0170
PC99 Notes: No PC 99 assertion available; carries forward intent of PC 99 System Design Guide Requirement 14.10.

5.551.6 Graphics adapters must perform gamma correction in a downloadable RAM digital-to-analog convert (RAMDAC) for 24-bit and 32-bit color modes without using base VGA registers.

Reference Document: PC 2001 System Design Guide, GRPH-0178
PC99 Notes: No PC 99 assertion available; carries forward intent of PC 99 System Design Guide Requirement 14.10.


NTSC Refresh Rate Assertion

5.552.1 Discrete graphics adapters must support the target NTSC refresh rate of 59.94Hz (no tolerance implied by this number) with an acceptable error margin of +/- 0.2% (as measured over 1 minute) for these desktop resolutions: 640x480, 800x600, and 1024x768.

Reference Document: PC 2001 System Design Guide, GRPH-0169
PC99 Notes: New since PC 99.


3D Graphics Assertions: General

5.553.1 Graphics adapters must have resolutions up to 1024x768, with 32-bit/pixel, a 32-bit Z-buffer, and a refresh rate of 85Hz.

Reference Document: PC 2001 System Design Guide, GRPH-0168, GRPH-0169
PC99 Notes: Supersedes PC 99 assertion 5.1.1; supersedes intent of PC 99 System Design Guide Requirement 14.27.1.

5.553.2 The 32-bit Z-buffer (24-bit precision, with 8-bit stencil, unsigned and lockable) must support the following Direct3D Z comparison modes:
  • Z Compare Never
  • Z Compare Less
  • Z Compare Equal
  • Z Compare Less Equal
  • Z Compare Greater
  • Z Compare Not Equal
  • Z Compare Greater Equal
  • Z Compare Always

Reference Document: PC 2001 System Design Guide, GRPH-0189
PC99 Notes: No PC 99 assertion available; supersedes intent of PC 99 System Design Guide Requirements 14.8, 14.33.

5.553.3 Hardware must support the clearing of color, Z buffers, and destination surfaces using DirectDraw depth-fill blt mechanism.

Reference Document: PC 2001 System Design Guide, GRPH-0189
PC99 Notes: New since PC 99; supersedes intent of PC 99 System Design Guide Requirement 14.8.

5.553.4 Graphics adapters must use a 32-bit linear packed-pixel frame buffer that is relocatable to areas above the 16MB memory boundary.

Reference Document: PC 2001 System Design Guide, GRPH-0197
PC99 Notes: No PC 99 assertion available; carries forward intent of PC 99 System Design Guide Requirement 14.47.


3D Graphics Assertions: Textures

5.554.1 Graphics adapters must support Direct3D compliant MIP-mapped textures.

Reference Documents: PC 2001 System Design Guide, GRPH-0185.1
PC99 Notes: Carries forward assertion 5.2.1; carries forward intent of PC 99 System Design Guide Requirement 14.27.2.

5.554.2 Graphics adapters must support Direct3D compliant bilinear or better filtered textures.

Reference Documents: PC 2001 System Design Guide, GRPH-0185.1)
PC99 Notes: Carries forward assertion 5.2.2; carries forward intent of PC 99 System Design Guide Requirement 14.27.2.

5.554.3 Graphics adapters properly support the required Direct3D texture sizes: 8x8, 16x16, 32x32, 64x64, 128x128, 256x256, 512x512, and 1024x1024.

Reference Document: PC 2001 System Design Guide, GRPH-0188
PC99 status: No PC 99 assertion available; carries forward intent of PC 99 System Design Guide Requirement 14.31

5.554.4 Graphics adapters must support the following Direct3D texture combination operations: MODULATERGB, MODULATEALPHA, ADD, and BLEND.

Reference Document: PC 2001 System Design Guide, GRPH-0186
PC99 status: No PC 99 assertion available; carries forward intent of PC 99 System Design Guide Requirement 14.29.

5.554.5 Graphics adapters must support Direct3D texture combination operations simultaneously with fogging and alpha blending.

Reference Document: PC 2001 System Design Guide, GRPH-0186
PC99 Notes: Supersedes PC 99 assertion 5.1.2; supersedes intent of PC 99 System Design Guide Requirement 14.27.1.

5.554.6 Graphics adapters must implement the following color texture formats:
  • 16 bpp non-palletized with a bit pattern of 1:5:5:5 Alpha:Red:Green:Blue
  • 16 bpp non-palletized with a bit pattern of 4:4:4:4 Alpha:Red:Green:Blue
  • 32 bpp non-palletized with a bit pattern of 8:8:8:8 Alpha:Red:Green:Blue

Reference Document: PC 2001 System Design Guide, GRPH-0187
PC99 Notes: No PC 99 assertion available; carries forward intent of PC 99 System Design Guide Requirement 14.30.


3D Graphics Assertions: Alpha Blending

5.555.1 Graphics adapters must support source alpha blending for the following Direct3D alpha blend modes:
  • D3DBLEND_BOTHINVSRCALPHA
  • D3DBLEND_BOTHSRCALPHA
  • D3DBLEND_DESTALPHA
  • D3DBLEND_DESTCOLOR
  • D3DBLEND_INVDESTALPHA
  • D3DBLEND_INVDESTCOLOR
  • D3DBLEND_INVSRCALPHA
  • D3DBLEND_ONE
  • D3DBLEND_SRCALPHA
  • D3DBLEND_SRCALPHASAT
  • D3DBLEND_ZERO

Reference Document: PC 2001 System Design Guide, GRPH-0185.2
PC99 Notes: Supersedes PC 99 assertion 5.3.1; supersedes intent of PC 99 System Design Guide Requirement 14.27.3

5.555.2 Graphics adapters must support destination alpha blending for the following Direct3D alpha blend modes:
  • D3DBLEND_DESTALPHA
  • D3DBLEND_INVDESTALPHA
  • D3DBLEND_INVSRCALPHA
  • D3DBLEND_INVSRCCOLOR
  • D3DBLEND_ONE
  • D3DBLEND_SRCALPHA
  • D3DBLEND_SRCCOLOR
  • D3DBLEND_ZERO

Reference Document: PC 2001 System Design Guide, GRPH-0185.2
PC99 Notes: Supersedes PC 99 assertion 5.3.1; supersedes intent of PC 99 System Design Guide Requirement 14.27.3.


3D Graphics Assertions: Shading, Lightning, and Fogging

5.556.1 Graphics adapters must have a Direct3D compliant implementation for Flat and Gouraud shading.

Reference Document: PC 2001 System Design Guide, GRPH-0185.3
PC99 Notes: Carries forward PC 99 assertion 5.4.1; carries forward intent of PC 99 System Design Guide Requirement 14.27.4.

5.556.2 Graphics adapters must have a Direct3D compliant implementation for Specular Hilighting, that uses an RGB specular color, interpolated from a per-vertex specular color attributes.

Reference Document: PC 2001 System Design Guide, GRPH-0185.3.
PC99 Notes: Carries forward PC 99 assertion 5.4.3; carries forward intent of PC 99 System Design Guide Requirement 14.27.4.

5.556.3 Graphics adapters must have a Direct3D compliant implementation to handle per-pixel blended, arbitrary RGB-colored fog that is ranged-based or depth-based.

Reference Documents: PC 2001 System Design Guide, GRPH-0185.3
PC99 Notes: Supersedes PC 99 assertion 5.4.2; supersedes intent of PC 99 System Design Guide Requirements 14.27.4 and 14.28.

5.556.4 Graphics adapters must support Direct3D compliant triangle strips and fans.

Reference Document: PC 2001 System Design Guide, GRPH-0185.3
PC99 Notes: No PC 99 assertion available; carries forward intent of PC 99 System Design Guide Requirement 14.28.


DVI Specific Assertions

5.557.1 A graphics adapter that implements a Digital Visual Interface (DVI) port must comply with the DVI Test Specification.

Reference Document: PC 2001 System Design Guide, GRPH-0165
PC99 Notes: New since PC 99; carries forward DVI recommendations

5..57.2 A graphics adapter that implements a DVI port does not implement a VGA port for an analog display connection.

Reference Document: PC 2001 System Design Guide, GRPH-0165
PC99 Notes: New since PC 99; carries forward DVI recommendations

5.557.3 A graphics adapter that implements a DVI port must convert a 70Hz refresh rate to 60Hz timing standard for displays that do not support 70 Hz.

Reference Document: PC 2001 System Design Guide, GRPH-0169
PC99 Notes: New since PC99; Carries forward DVI recommendations


Hardware, Plug and Play, and Driver Assertions

5.558.1 A discrete graphics solution, intended to be the primary display, must have an AGP 2.x or later interface. Please refer to Chapter 8, AGP Test Specification.

Reference Documents: PC 2001 System Design Guide, GRPH-0163
PC99 Notes: No PC 99 assertion available; supersedes intent of PC 99 System Design Guide Requirement 14.1.

5.558.2 An integrated graphics solutions, intended to be the primary display, must implement an AGP 1.x or later interface. Please refer to Chapter 8, AGP Test Specification.

Reference Document: PC 2001 System Design Guide, GRPH-0163
PC99 Notes: No PC 99 assertion available; supersedes intent of PC 99 System Design Guide Requirement 14.1.

5.558.3 The graphics solution used for the primary display must support all of the functions implemented by the default VGA driver provided by a Windows operating system.

Reference Document: PC 2001 System Design Guide, GRPH-0166
PC99 Notes: No PC 99 assertion available; carries forward intent of PC 99 System Design Guide Requirement 14.4.

5.558.4 Graphics adapters must have the driver support to support multiple adapters and monitors.

Reference Document: PC 2001 System Design Guide, GRPH-0167
PC99 Notes: No PC 99 assertion available; carries forward intent of PC 99 System Design Guide Requirement 14.5.

5.558.5 The graphics solution used for the primary display must support 4-bit planar VGA mode, described by the Windows 98 DDK and Windows 2000 DDK.

Reference Document: PC 2001 System Design Guide, GRPH-0166
PC99 Notes: No PC 99 assertion available; Carries forward intent of PC 99 System Design Guide Requirement 14.4.

5.558.6 Graphics solutions must never use VGA based registers for Windows GDI, DirectX, or Direct Media display operations with the exception of startup and setting video modes.

Reference Document: PC 2001 System Design Guide, GRPH-0171
PC99 Notes: No PC 99 assertion available; carries forward intent of PC 99 System Design Guide Requirement 14.11.

5.558.7 Graphics adapter (and its option ROM) must support DDC2B level communication with a Plug-and-Play capable display, as specified in the Enhanced Extended Display Data Channel Standard, Version 1.0 (E-EDDC).

Reference Document: PC 2001 System Design Guide, GRPH-0179 and GRPH-0198
PC99 Notes: No PC 99 assertion available; supersedes intent of PC 99 System Design Guide Requirement 14.13.

5.558.8 All non-VGA based resources (extended resources) must be dynamically relocatable after completing the system’s Power-On Self-Test (POST).

Reference Document: PC 2001 System Design Guide, GRPH-0180 and GRPH-0171
PC99 Notes: No PC 99 assertion available; carries forward intent of PC 99 System Design Guide Requirements 14.11, 14.46, and 14.47.

5.558.9 Graphics solutions must ship with a solution that can tell the adapter’s driver to disable the adapter from decoding standard VGA addresses and resources.

Reference Document: PC 2001 System Design Guide, GRPH-0181.
PC99 Notes: New since PC 99; resembles an addendum to the intent of PC 99 System Design Guide Requirements 14.46.

5.558.10 Graphics adapters must remain fully functional after VGA addresses and resources are disabled.

Reference Document: PC 2001 System Design Guide, GRPH-0181
PC99 Notes: New since PC 99; resembles an addendum to the intent of PC 99 System Design Guide Requirement 14.46.

5.558.11 Systems with integrated graphics solutions must populate the Subsystem ID (SID) at power on.

Reference Document: PC 2001 System Design Guide, GRPH-0195
PC99 Notes: No PC 99 assertion available; supersedes or carries forward intent of PC 99 System Design Guide Requirement 14.51.

5.558.12 Systems using discrete graphics adapters must populate the SID at the point when power is applied and the device is initialized to the state that is ready for POST.

Reference Document: PC 2001 System Design Guide, GRPH-0195
PC99 Notes: No PC 99 assertion available; supersedes or carries forward intent of PC 99 System Design Guide Requirement 14.51.

5.558.13 Graphics adapters must not require setting jumpers or switches on hardware cards or system boards.

Reference Document: PC 2001 System Design Guide, GRPH-0196
PC99 Notes: No PC 99 assertion available; carries forward intent of PC 99 System Design Guide Requirement 14.46.

5.558.14 Systems must automatically relocate resources used by a graphics adapter when additional graphics adapters are added to the system, or disable one of the adapters in the event of irreconcilable resource conflicts.

Reference Document: PC 2001 System Design Guide, GRPH-0196
PC99 Notes: No PC 99 Assertion available; carries forward intent of PC 99 System Design Guide Requirement 14.46.

5.558.15 If a VGA BIOS exists on the graphics adapter, it must be able to configure its base address to C0000h and one alternate address.

Reference Document: PC 2001 System Design Guide, GRPH-0196
PC99 Notes: No PC 99 Assertion available; carries forward intent of PC 99 System Design Guide Requirement 14.46.

5.558.16 The Windows configuration manager must be able to use alternate configuration for each non-VGA display resource.

Reference Documents: PC 2001 System Design Guide, GRPH-0196
PC99 Notes: No PC 99 Assertion available; Carries forward intent of PC 99 System Design Guide Requirement 14.46.

5.558.17 Systems that have integrated graphics solutions and mobile PCs that have docking stations with PCI slots, must provide a means in the BIOS setup utility to force the system to boot using the onboard graphics device, even when an add-in graphics adapter is installed.

Reference Document: PC 2001 System Design Guide, GRPH-0199
PC99 Notes: No PC 99 assertion available; supersedes or carries forward intent of PC99 System Design Guide Requirement 14.49.

5.558.18 A system’s BIOS must support graphics adapter frame-buffer in sizes up to 256 MB.

Reference Document: PC 2001 System Design Guide, GRPH-0200
PC99 Notes: No PC 99 assertion available; carries forward intent of PC 99 System Design Guide Requirement 14.50.

5.558.19 Graphics devices that do not support IRQs must set the Interrupt Pin Register (3Dh) to be zero.

Reference Document: PC 2001 System Design Guide, GRPH-0201
PC99 Notes: No PC 99 assertion available; carries forward intent of PC 99 System Design Guide Requirement 14.52.

5.558.20 Graphics devices must correctly populate PCI base address registers (BARs).

Reference Document: PC 2001 System Design Guide, GRPH-0201
PC99 Notes: No PC 99 assertion available; carries forward intent of PC 99 System Design Guide Requirement 14.52.

5.558.21 System-board graphics devices must properly enumerate during Plug-and-play enumeration, except when integrated graphics devices are disabled by the presence of an AGP-slot graphics adapter.

Reference Document: PC 2001 System Design Guide, GRPH-0202
PC99 Notes: No PC 99 assertion available; supersedes or carries forward intent of PC 99 System Design Guide Requirement 14.53.

5.558.22 Graphics adapter drive does not bypass or patch the following Microsoft-provided system components.
  • For Windows, this includes: Gdi.exe, Kernel.exe, User.exe, Dibeng.dll, Mmsystem.dll, Ddraw.dll, D3d*.dll
  • For Windows 2000, this includes: all files normally installed in the System32 directory, Win32k.sys, Ntoskrnl.exe, Gdi32.dll, User32.dll, and Mcdsrv32.dll

Reference Document: PC 2001 System Design Guide, GRPH-0205
PC99 Notes: No PC 99 assertion available; supersedes or carries forward intent of PC99 System Design Guide Requirement 14.57.

5.558.23 Graphics adapter must properly operate when asked by the OS to change the color depth or resolution without restarting or rebooting.

Reference Document: PC 2001 System Design Guide, GRPH-0206
PC99 Notes: No PC 99 assertion available; carries forward intent of PC 99 System Design Guide Requirement 14.59.

5.558.24 Graphics adapters respond to operating system power management for OnNow power states.

Reference Document: PC 2001 System Design Guide, GRPH-0203
PC99 Notes: No PC 99 assertion available; carries forward intent of PC 99 System Design Guide Requirement 14.54.

5.558.25 Graphics adapters responds to VESA BIOS Power Management Functions (VBE/Core Functions 2.0).

Reference Document: PC 2001 System Design Guide, GRPH-0203
PC99 Notes: No PC 99 Assertion available; Carries forward intent of PC 99 System Design Guide Requirement 14.54.


Display Test Descriptions

This section contains the detailed Graphics Adapter test descriptions.

TD-5.1 Terminal Services – Console Disconnect Test

Overview

  1. On the system under test, a user will be logged on the console. Then, the session will be disconnected and wait until the logon UI on the newly created session appears or a timeout occurs.
  2. On the system under test, a user will be logged on the console. Then, the session will be disconnected and after getting the logon UI, the same user will be logged on to the console and reconnected to the disconnected session.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

On the system under test, a user with administrator rights needs to be logged before starting the test. Also, the system must have the classic logon UI, which can be achieved by making the system a member of a domain. The operating system will be Windows XP.


TD-5.2 ExtEsc Test Description

Overview

The ExtEsc tests supported and unsupported escapes by passing valid and invalid data to ExtEscape().

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Results Interpretation

The test writes the results to the log file Extesc.log and displays on-screen pass or fail status. A test failure might cause a system stop.


TD-5.3 Illegal Imports Test Description

Overview

Illegal imports are import calls not allowed by MS policy for OEM drivers to use. By definition only calls to VIDEOPRT.SYS are considered completely legal, but many OEMs used also other calls, and this is hard to track. The purpose of this utility is to track illegal imports in OEMs miniport video driver.

E.g.: Some drivers call to IoGetCurrentProcess() and change their behavior according to what application is running, trying to get better benchmarks.

For now as we have almost every driver having illegal imports we define all the currently existing imported calls as "warnings". However, no new imports are allowed. Using an import which is not allowed will cause driver to fail the test, producing "error" message in the log. In ideal case driver should be clean of warnings as well as of errors. Requirement for any new driver added to our test base is to be free of both errors and warnings.

The names of the known illegal imports are hard-coded in the utility.

Miniport Drivers:

Display miniport drivers may link to any function within the VideoPort driver. In general, linking to functions other than those found in the VideoPort driver is not allowed and will result in a DCT failure. The following exceptions are permitted but not encouraged; linking to these will generate warnings in the DCT suite but will not cause a failure:

in HAL.dll:

HalGetAdapter

HalGetBusData

HalGetBusDataByOffset

HalSetBusData

HalSetBusDataByOffset

in NTOSKRNL.EXE:

MmQuerySystemSize

_except_handler3

ZwMapViewOfSection

ZwUnmapViewOfSection

IoAllocateMdl

IoFreeMdl

MmBuildMdlForNonPagedPool

MmGetPhysicalAddress

ObReferenceObjectByHandle

RtlUnwind

ZwOpenSection

Display Driver

Display drivers are only permitted to link to WIN32K.SYS and its associated functions. Linking to any other module will result in the display driver being unloaded by the OS.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Warnings will not be counted as failures until next version of Windows is released.


TD-5.4 Compare Caps Test Description

Overview

The PC99 Guide describes requirements for certain 3D capabilities. Since our 3D tests are designed to test only what is available, we designed the "Compare Caps" test to simply fail if caps are not detected. The actual functionality of these features will be tested elsewhere.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

To pass the Z Compare test you must expose these caps:

TRI Z CMP CAPS : ALWAYS
TRI Z CMP CAPS : EQUAL
TRI Z CMP CAPS : GREATER
TRI Z CMP CAPS : GREATEREQUAL
TRI Z CMP CAPS : LESS
TRI Z CMP CAPS : LESSEQUAL
TRI Z CMP CAPS : NEVER
TRI Z CMP CAPS : NOTEQUAL

To pass the Alpha Blending test you must expose these caps:

TRI SRC BLEND CAPS : DESTCOLOR
TRI SRC BLEND CAPS : INVDESTCOLOR
TRI SRC BLEND CAPS : INVSRCALPHA
TRI SRC BLEND CAPS : ONE
TRI SRC BLEND CAPS : SRCALPHA
TRI SRC BLEND CAPS : ZERO
TRI DEST BLEND CAPS : INVSRCALPHA
TRI DEST BLEND CAPS : INVSRCCOLOR
TRI DEST BLEND CAPS : ONE
TRI DEST BLEND CAPS : SRCALPHA
TRI DEST BLEND CAPS : SRCCOLOR
TRI DEST BLEND CAPS : ZERO

To pass the MIP Filter test you must expose these caps:

TRI TFILTER CAPS : MIPLINEAR
TRI TFILTER CAPS : MIPNEAREST

Results Interpretation

If any of the caps are not exposed, they will be listed as failures in the log. If all the caps are found, the test will pass.


TD-5.9 DirectDraw Accelerated Graphics Port (AGP) Memory Test Description

Test Kit: HCT 11, HCT 10

Overview

Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the "Tests->Select Tests" menu item.

The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.

Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.

Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.

Click to show or hide information. TD-5.9.1 Blt - Basic - System to Primary test

This test performs a simple DirectDraw Blt from a system memory surface to the Primary.

The test compares the resulting image against it’s own simulation. Since this is a simple 1 to 1 copy Blt, the test expects the DirectDraw Blt and the simulation to match exactly.

This test runs in all reported display modes.

Because all blts are performed directly to the Primary, you can visually inspect the results. Use the <Pause> key to give yourself more time.

DirectDraw is capable of performing this Blt operation in it’s emulation layer if the driver does not support it. Driver support is indicated by means of the DDCAPS_CANBLTSYSMEM flag, and the various dwSVB fields of the DDNTCORECAPS struct.

Support for System to Video Blts is not required. If the driver does not report the appropriate caps, the DCT will not even run this test.

Test Executable: Fnddraw.exe

Click to show or hide information. 5.9.2 Blt - Basic - VMem to Primary test

Performs a variety of Blt tests where both the source and destination are in video memory. Drivers are required to support these blts. Support is expressed by means of the DDCAPS_BLT flag.

The test compares the Blt results against it’s own simulation. Since these are simple 1 to 1 copy Blts, the test expects the DirectDraw Blt and the simulation to match exactly.

The following Fnddraw cases make up this test

BLT_OnscreenOverlap – Performs blts where the source and destination are on the same surface. To further complicate things, the blt rectangles are chosen such that they overlap.

BLT_BltFrontToBackBuff – Performs a blt from the front buffer of a primary flipping chain to the back buffer.

BLT_BltFast From/To Same Surface – This is the original overlapping blt test. From a driver standpoint it’s a simpler version of Blt_OnscreenOverlap mentioned above.

BLT Basic, VMem to Primary – Performs a basic blt from an offscreen video memory surface to the Primary. The blt is compared against a test generated reference image. The images are expected to match exactly.

BLT Basic, Offscreen Surfaces – Performs blts from a variety of memory types.

Test Executable: Fnddraw.exe

Click to show or hide information. 5.9.3 Blt - Color Key - Sys to Primary test

These tests ensure that display drivers which claim to support system to video color key blts, perform them correctly. The tests perform simple source and destination color key blts from system memory to the primary surface. Blt results are compared against a simulation using either GDI operations or the test’s internal software blitter. Images are expected to match exactly.

The follow Fnddraw cases make up this test

BLT, single DESTKEY, System to Primary

BLT, single SRCKEY, System to Primary

Test Executable: Fnddraw.exe

Click to show or hide information. 5.9.4 Blt - Color Key - VMem to Primary test

This series of tests performs color keyed blts from offscreen video memory to the primary. Blt results are compared against a simulation using either GDI operations or the test’s internal software blitter. Images are expected to match exactly.

Drivers are required to support Source Color Key Blts between video memory surfaces. Destination color key blts and "space" blts are optional.

The follow Fnddraw cases make up this test

BLT, DESTKEY Space, VMem to Primary

BLT, single DESTKEY, VMem to Primary

BLT, SRCKEY Space, VMem to Primary

BLT, single SRCKEY, VMem to Primary

Test Executable: Fnddraw.exe

Click to show or hide information. 5.9.5 Blt - Stretch - System to Primary test

Test ensures the DirectDraw graphics adapter is able to process a variety of DirectDraw stretch (and shrink) blts from system memory to the primary surface.

The follow Fnddraw cases make up this test

BLT, Stretch (Wx2, Hx.75), Sys to Pri

BLT, Shrink, (3/4), Sys To Primary

BLT Stretch(width only) x 1.5, System to Pri

BLT Shrink (1/2), System to Primary

BLT Stretch x 1.5, System to Primary

BLT Stretch x 2, System to Primary

Test Executable: Fnddraw.exe

Click to show or hide information. 5.9.6 Blt - Stretch - VMem to Primary test

Test ensures that the DirectDraw graphics adapter is able to process a variety of DirectDraw stretch (and shrink) blts from video memory to the primary surface.

The follow Fnddraw cases make up this test

BLT, Stretch (Wx2, Hx.75), VMem to Pri

BLT, Shrink, (3/4), VMem To Primary

BLT Shrink (1/2), VMem to Primary

BLT Stretch x 1.5, VMem to Primary

BLT Stretch x 2, VMem to Primary

Test Executable: Fnddraw.exe

Click to show or hide information. 5.9.7 Blt - Stretch & Color Key - Sys to Primary test

Test ensures that the DirectDraw graphics adapter is able to process combinations of stretched (and shrunk) blts as well as SOURCE and DESTINATION Color Key blts from system memory to the primary surface.

The follow Fnddraw cases make up this test

BLT,Stretch(width only), SRCKEY, Sys to pri

BLT,Stretch, SRCKEY, System to primary

Test Executable: Fnddraw.exe

Click to show or hide information. 5.9.8 Blt - Stretch & Color Key - Vid to Primary test

Test ensures that the DirectDraw graphics adapter is able to process combinations of stretched (and shrunk) blts as well as SOURCE and DESTINATION Color Key blts from video memory to the primary surface.

The follow Fnddraw cases make up this test

BLT,Stretch(width only), SRCKEY, VMem to pri

BLT,Stretch, SRCKEY, VMem to primary

Test Executable: Fnddraw.exe

Click to show or hide information. 5.9.9 Blt – Colorfill - AGP

The purpose of these tests is to verify that color fill blt operations can be successfully performed on AGP (non-local video) memory surfaces.

The test performs a series of color fill operations on an AGP surface whose pixel format matches the current display mode. Fill regions (RECTs) are chosen such that a variety of sizes and memory alignments are tested. The results of the color fills are compared against a reference image generated using GDI.

Drivers are not required to support color fill operations on AGP surfaces. DirectDraw is capable of performing these operations in it’s emulation layer. Flags passed to DirectDraw indicate whether or not a display driver supports color fill operations on AGP surfaces. If the driver sets flags indicating support, it must match the reference image exactly.

The DirectX8 DDK documents which flags a driver sets to indicate support for AGP color fills.

Test Executable: Fnddraw.exe

Fnddraw Test Case: BLT Color Fill AGP Mem

Click to show or hide information. 5.9.10 Blt – Colorfill – Video Memory

The purpose of these tests is to verify that color fill blt operations can be successfully performed on video memory surfaces.

The test performs a series of color fill directly onto the primary surface. Fill regions (RECTs) are chosen such that a variety of sizes and memory alignments are tested. The results of the color fills are compared against a reference image generated using GDI.

Display Drivers are required to support hardware accelerated color fills. Support is indicated by setting the DDCAPS_BLTCOLORFILL flag.

Test Executable: Fnddraw.exe

Fnddraw Test Case: BLT Color Fill Primary

Click to show or hide information. 5.9.11 Blt – Unused Pixel Bits

This test verifies that the display driver ignores unused portions of a pixel when performing a color key blt operation. Unused portions of a pixel (such as the high byte in 32bpp modes) should not be included in the color key comparison.

Test Executable: Fnddraw.exe

Fnddraw Test Case: BLT, SRCKEY (from VMem) with unused pixel bits set

Click to show or hide information. 5.9.12 Read Scan Line test

Test ensures that the DirectDraw graphics adapter blts are able to report the current scan-line being drawn. Test ensures that reported scan lines are reasonable based on display resolution.

Test Executable: Fnddraw.exe

Test Case Name: API_GetScanLine

Click to show or hide information. 5.9.13 Surface Flipping test

Test ensures that the DirectDraw graphics adapter supports surface flipping, flip status reporting, and vertical blank querying.

The follow Fnddraw cases make up this test

SURF_GetFlipStatus

API_GetVerticalBlankStatus

PC98_22 (PC97 20) Perform Double Buffer Swaps with no tearing

Test Executable: Fnddraw.exe

Click to show or hide information. 5.9.14 Video Memory Management test

Test verifies that video memory is accurately reported and managed.

The following Fnddraw cases make up this test

MEMMAN_GetAvailableVidMem

This test case examines compares memory values returned by various GetAvailableVidMem calls. The sum of AGP and local video memory amounts should equal the total video memory.

MEMMAN - Video Memory Reuse Test

This test verifies that freed video memory can be reallocated.

MEMMAN - Rand Create/Release Video Memory surfaces 100X Test

This test randomly creates and releases video memory surfaces. As each surface is created, a byte pattern is written to it. Upon release of that surface, the byte pattern is read back to verify surface integrity.

MEMMAN - Consume All Video Mem Test

This test tries to allocate all video memory (local and AGP). As each surface is allocated a byte pattern is written to it. The byte pattern is read back before all surfaces are released to verify integrity.

Test Executable: Fnddraw.exe

Click to show or hide information. 5.9.15 Palette test

The Palette test ensures that the DirectDraw graphics adapter verifies palette manipulation.

This test is only partially automated and requires some manual verification.

PAL_GetEntries/SetEntries (8-Bit)(TC 4.5.7, 4.7.7)

PAL_CreatePalette - ALLOW256 Test(TC 2.6.12)

PAL_CreatePalette - Init 256 clrs(TC 2.6.9)

Test Executable: Fnddraw.exe

Click to show or hide information. 5.9.16 Overfly test

The Overfly test ensures the proper functionality of overlays. This test requires MANUAL VERIFICATION.

Test Executable: Overfly.exe (in coordination with overfly.pc6 test script)

Click to show or hide information. 5.9.17 Blt - Raster Ops - Vid Mem test

Test ensures that the DisplayDriver correctly performs all reported DirectDraw Blt Raster Operations. Only SRCCOPY is required.

Test Executable: Fnddraw.exe

Click to show or hide information. 5.9.18 VideoPort and VP Kernel tests

Tests perform a variety of sub tests including VideoPort flipping, scan-line and vblank synchronization, and bandwidth and pixel format reporting.

If the display driver claims to support VPE (via the DDCAPS_VPE flag), then there must be DVD and/or Analog Capture hardware available for the test. The analog decoder must have a valid video signal, and the DVD player should have a disc loaded.

KERNEL_ReleaseKernelHandle
KERNEL_GetKernelHandle
VPE_UpdateVideo
VPE_GetVideoPortConnectInfo
VPE_StopVideo
VPE_StartVideo
VPE_CreateVideoPort
VPE_QueryVideoPortStatus
VPE_GetFieldPolarity
VPE_GetVideoSignalStatus
VPE_SetTargetSurface
VPE_Flip
VPE_WaitForSync
VPE_GetBandwidthInfo
VPE_GetInput/OutputFormats

Test Executable: Fnddraw.exe

Click to show or hide information. 5.9.19 The Blt - Exotic test analyzes the GetBltStatus, Zbuffer Blt, Blt FOURCC, and Copy FOURCC functions.

This group of tests evaluates a variety of miscellaneous Blt operations.

3D_Depth Fill Blt Test

Performs a Z-Fills operations on both 16 and 32bpp z-buffers.

BLT_OffscreenOverlap

Performs blts on a variety of offscreen surfaces where the source and destination surface are the same. Blt rects are chosen such that they overlap. The blts are simulated by the tests internal software bltter and compared. Because the blts are simple copies, the expectation is that the real blt and simulation will match exactly.

BLT_GetBltStatusPostFlip

Tests the reliability of the GetBltStatus function before, during, and after a Flip operation.

BLT_GetBltStatusMultBlts

Tests the reliability of the GetBltStatus function before, during, and after a Blt operation.

BLT_ZBuffer

Performs blts between Z-buffer surfaces, and compares.

BLT, FourCC to FourCC

Performs simple copy blts between a variety of offscreen surface formats including FourCC formats. FourCC formats are only tested if the driver sets the DDCAPS2_COPYFOURCC flag which drivers are required to set.

BLT, FourCC to RGB conversion

Performs Blts from YUV (FOURCC) surfaces to an RGB primary. This test is only run if the driver sets the DDCAPS_BLTFOURCC flag.

BLT, FourCC to RGB stretch

Performs Stretched Blts from YUV (FOURCC) surfaces to an RGB primary. This test is only run if the driver sets the DDCAPS_BLTFOURCC and DDCAPS_BLTSTRETCH flags.

Test Executable: Fnddraw.exe

Click to show or hide information. 5.9.20 The Stereo test

Test ensures that the DirectDraw graphics adapter is capable of displaying a stereo image.

LCD shutter glasses are helpful for running these tests, but are not required.

Test Executable: Stereo.exe

Click to show or hide information. 5.9.21 The Automatic Stereo test

Test ensures that the DirectDraw graphics adapter reports stereo caps consistent, and that stereo flipping can be enabled and disabled.

Test Executable: Fnddraw.exe

Click to show or hide information. 5.9.22 DDraw Cubic

This creates attempts to create a variety of valid and invalid cubic maps, and verifies the driver handles it properly. This test only runs if the driver supports cubic environment maps for 3D.

Test Executable: Fnddraw.exe

Click to show or hide information. 5.9.23 The PC99 #3 system test

Test determines whether a display adapter driver meets PC98 requirement no. 2 for Graphics Adapters (System uses WC with higher-performance processors).

The test works by invoking DirectDraw to allocate an off-screen buffer in video memory, performing row-wise and column-wise fills of the buffer and computing the ratio of the speed of the row-wise fill to the speed of the column-wise fill. If the buffer is implemented with write-combining, the row-wise fill will be dramatically faster than the column-wise fill---a pass is reported as long as the ratio >=2.

Test Executable: Fnddraw.exe

Click to show or hide information. 5.9.24 PC99 14.23 Low-Res Mode Support

This test verifies that the following low-res modes are supported by the display adapter:

  • 320x200 [8 and 16 bpp]
  • 320x240 [8 and 16 bpp]
  • 640x400 [8 and 16 bpp]

Test Executable: Fnddraw.exe

Click to show or hide information. 5.9.26 PC99 #12 Downloadable RAMDAC

This test verifies that the display adapter supports DirectDraw’s gamma ramp API. Test maps blue and green components to zero leaving only red.

For details on implementing Gamma Support, see the "Gamma Control" chapter of the DirectX8.0 DDK documentation.

Test Executable: Fnddraw.exe

Click to show or hide information. 5.9.27 PC99 #25 Double Buffer Swaps with no tearing

Test tries to ensure that page flips occur during the vertical blank period. Test does this by comparing the rate at which flips are accepted to the current refresh rate.

Test Executable: Fnddraw.exe

Click to show or hide information. 5.9.28 DDraw AGP Memory test

The DDraw AGP Memory test ensures that the DirectDraw graphics adapter creates basic AGP surfaces.

Test Executable: Fnddraw.exe

Click to show or hide information. 5.9.29 DDraw Blt Basic - AGP to Primary test

Test ensures that the DirectDraw graphics adapter FNDDRAW blt function is capable of handling several conversion blts from various memory surfaces.

Test Executable: Fnddraw.exe

Click to show or hide information. 5.9.30 DDraw Blt - Color Key - AGP to Primary test

Test ensures that the DirectDraw graphics adapter is able to process Color key blts from AGP surfaces to the primary surface.

Test Executable: Fnddraw.exe

Click to show or hide information. 5.9.31 DDraw Blt - Stretch - AGP to Primary test

Test ensures that the DirectDraw graphics adapter is able to process blts stretched from AGP surfaces to the primary surface.

Test Executable: Fnddraw.exe

Click to show or hide information. 5.9.32 DDraw Blt - Stretch & Color Key - AGP to Primary test

Test ensures that the DirectDraw graphics adapter is able to process various combinations of stretch and color key blts from AGP surfaces to the primary surface.

Test Executable: Fnddraw.exe

Click to show or hide information. 5.9.35 Blt - Textures test

This series of tests verify that graphics adapters correctly perform blts between a variety of texture formats. The tests are broken out by the memory type of the source and destination textures (System, Video and AGP). The tests are implemented in the Fnddraw.exe, and consist of the following specific tests:

Blt_Texture Vid to Vid

Blt_Texture Sys to AGP

Blt_Texture Sys to Vid

Blt_Texture Sys to Sys

Each test runs through a variety of pixel formats, blitting between the memory types expressed in the test name. Each blt is a simple copy (no stretching or color keying in this revision of the test). The test expects the destination to perfectly match the source after the blt. Any deviation is considered a failure.

All blts are performed on off-screen surfaces (textures). However, the results are copied to the screen to aid in debugging. (Some detail is likely lost in converting from the texture pixel format to the pixel format of the primary.)

Currently the test will tolerate a driver returning DDERR_UNSUPPORTED on the Blt call, and not consider it a failure. This is likely to change in the future.

In our internal testing we discovered a vast number of failures resulted from drivers allowing textures to be created in unsupported pixel formats. Drivers should be sure to fail CanCreateSurface() for all non-system memory textures whose pixel formats they do not support. The test blindly runs through a pre-determined list of pixel formats. It trusts that the driver will fail the surface creation, if the pixel format is not supported.

Test Executable: Fnddraw.exe

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows 98/ME or Windows 2000 operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

The test logs individual test/fail results, as well as summary information. You can find individual failures by searching for "Fail :". By default, the test will create an FNDDRAW.LOG file in the current directory. The LOG file is in a simple text format, and can be viewed with any text editor such as NOTEPAD.


TD-5.13 DirectX 8 CopyRects Functionality Test Description

Overview

The test performs automatic verification of the functionality provided by the IDirect3DDevice8::CopyRects method by comparing surfaces generated by tested operations with reference surfaces generated by the test itself.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows 98 or Windows 2000 operating system must be installed, as well as DirectX version 8.0 or higher.

Results Interpretation

The test reports a failure by inserting a log file entry that describes the source and destination surfaces and the set of rectangles involved in the tested operation. It also provides a command line that may be used to execute the test independently of the DCT shell to view the reference and test surfaces generated by the failing test case.


TD-5.20 Display Basic 3D Requirements Test Description

Overview

The Direct3D API defines rasterization rules to determine which pixels apply to a given triangle. These guidelines are necessary when polygon edges fall directly on pixel centers. Direct3D specifies the following triangle rasterization rules:

  • Top-left filling convention for filling geometry (same as Windows GDI and OpenGL).
  • Decisions are made based on the center of each pixel.
  • Pixel centers are at integer coordinates.
  • If a pixel center is inside boundaries of triangle, pixel is considered part of the triangle.

Refer to the DirectX 5 or DirectX 6 Programmer’s Reference for details on the triangle rasterization rules.

In order to verify compliance with these requirements, the display adapter is programmed via the Direct3D HAL to render multiple patterns of filled triangles to the primary surface frame buffer. The pixel values contained in the buffer are verified against the expected results, generated by rendering the same triangles via the DirectX 6 software-based Reference rasterizer. A 15% error tolerance is allowed between the hardware-generated image and the Reference rasterizer image—this error value is calculated as the cumulative pixel value differences between any two scenes.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-5.21 Wire Frame Test Description

Overview

The test verifies the accuracy of viewport clipping and rasterization of primitives in wireframe mode as well as interpolation of diffuse and specular colors, alpha and vertex fog values, and texture coordinates. During the test run, its circles throw different primitive types, rendering APIs as well as running a few sets of rendering properties in gouraud and flat shading modes.

To perform verification in wireframe mode, the test sets smaller viewport for the testing device. The Reference device has the usual viewport settings and the application locks and paints its back buffer after rendering to emulate the results of smaller viewport settings.

Command Line options:

General options | Description
-src:<device> | choose device to run the test
-ref:<device> | choose reference device
-triangle:<n>[-[<n>]] | specify a test or range of single triangle clipping tests to run
-tfan:<n>[-[<n>]] | specify a test or range of triangle fan tests to run
-tstrip:<n>[-[<n>]] | specify a test or range of triangle strip tests to run
-line:<n>[-[<n>]] | specify a test or range of single line tests to run
-lstrip:<n>[-[<n>]] | specify a test or range of line strip tests to run
-point:<n>[-[<n>]] | specify a test or range of point tests to run
-debug | run the test in debug mode


TD-5.22 Texture Tests Description

Click to show or hide information. MipMapped Textures

To verify proper implementation of MIP-mapped textures, the test program first queries the graphics driver via the DirectX HAL to ensure support is present.

Next, the test program conducts an automated verification that MIP maps can be initialized and displayed properly. The following steps are performed using the DirectX HAL device:

  1. A series of three different striped color texture MIP maps are initialized.
  2. The three-level MIP-mapped texture is applied to nine meshes of various sizes and each rendered to the primary surface buffer.
  3. Pixel color values in the primary surface buffer are compared to identical images generated by the Direct3D Reference rasterizer. This comparison confirms that each MIP map is present and can be activated in the rendered image.
  4. A 15% error tolerance is allowed between each hardware-generated image and each Reference rasterizer image. This error value is calculated as the cumulative pixel value differences between any two scenes.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases, which includes the details of the original MIP map textures and the specific comparison step that failed.

Click to show or hide information. Texture Filter

This test verifies that the graphics adapter supports bilinear (or better) texture filtering with perspective correction, as opposed to simple point-sampled texturing methods.

The test first verifies that linear texture filtering and perspective corrections are reported capabilities of the hardware. The DirectX HAL device capabilities are queried for confirmation of this feature.

The next phase of this test renders and displays two textured scenes. A striped texture pattern is used for these images.

The leftmost scene activates bilinear texture filtering (HAL device with filtering), while the rightmost scene is generated by the Direct3D Reference rasterizer. The test then automatically confirms that the HAL texture-filtered scene closely resembles the Reference rasterizer for various mesh sizes.

To confirm support for perspective correction, the DirectX HAL device is used to render a square mesh with various texture images applied. The z-value of each individual corner of the mesh is varied to skew each image. A pixel comparison to an identical scene created using the DirectX6 Reference rasterizer is performed.

For both the filter test and the perspective correction test, a 15% error tolerance is allowed between each hardware-generated image and corresponding Reference rasterizer image—this error value is calculated as the cumulative pixel value differences between any two scenes.

Click to show or hide information. Texture Management tests

This test assesses driver texture management when run with the following command line switches "texman –HWTexMan –dx7". This verifies that texture memory is managed correctly for the following types of textures in the following order

  • 16 bit RGB textures
  • 16 bit RGB mip mapped textures
  • 8 bit palletized textures
  • 8 bit palletized mip mapped textures
  • Set LOD on 16 bit mip mapped RGB textures
  • 16 bit RGB Cube mapped textures
  • 16 bit RGB Cube mapped mip mapped textures
  • 8 bit palletized Cube mapped textures
  • 8 bit palletized Cube mapped mip mapped textures.

This test generates 120 textures of the texture type. So for mip mapped 16 bit RGB textures 120, 7 level mip maps are created starting at a 256*256 texture. This means that during this test the amount of textures allocated ranges from around 7.8 M to over 40 M of textures. Set LOD is tested with 16 bit RGB mip mapped textures only and purely tests that the Level of Detail or mip level can be set.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows 98, ME or Windows 2000 operating system must be installed, as well as DirectX version 7 or higher.

Results

A pass or fail indication of compliance with this requirement is displayed and logged by the test program.

Click to show or hide information. Textured lines and textured point tests

Two short tests to verify that the driver applies textures on line and point list primitives correctly. The application renders a number of textured lines or point to completely fill a rectangle in the center of the screen.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with these requirements is displayed and logged by the test program. All results are recorded in a detailed log file.


TD-5.23 Z Compare Test Description

Overview

Test verifies the Z compare mode of different types by rendering triangles with various Z values and comparing with the Direct3D reference. The different types of Z compares tested are:

  • Never
  • Less
  • Equal
  • LessEqual
  • Greater
  • Not Equal
  • GreaterEqual
  • Always

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases.


TD-5.24 Basic Rasterization Tests Description

Overview

Shading – Flat/Gouraud

To verify support for both flat and Gouraud shading, a test program first verifies that the triangle primitives structure, returned by Direct3D function GetCaps, specifies the following flags:

  • D3DPSHADECAPS_COLORFLATRGB
  • D3DPSHADECAPS_COLORGOURAUDRGB

Using the Direct3D HAL, the test program then renders a series of eight flat and Gouraud shaded triangles. Each vertex of a given triangle is assigned an unique color. Pixel values in the primary surface frame buffer are compared to an identical image generated by the Direct3D reference rasterizer.

The following characteristics are confirmed:

  • Flat shaded triangles – Color components of triangle faced pixels match color component of the first triangle vertex.
  • Gouraud shaded triangles – Color components of the triangle face are linearly interpolated between all three of the triangle’s vertices.

A 15% error tolerance is allowed between each hardware-generated image and each corresponding reference rasterizer image. This error value is calculated as the cumulative pixel value differences between any two scenes.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases, which includes the vertex color values and a summary of incorrectly rasterized images.


TD-5.25 Overdraw/Underdraw Test Description

Overview

Verifies that no Overdraw or Underdraw of pixels happen when rendering. However, in this test, fill rules typically have a 0% error tolerance (instead of the usual 15%). The test renders alternating Red & Green triangles with 50% alpha. The test checks the resulting buffer for Yellow pixels (overdraw case), Bright Green pixels (overdraw case), Bright Red pixels (overdraw case), or Black pixels (underdraw case).

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases.


TD-5.26 Perspective Test Description

Overview

The Perspective Test verifies perspective correct textures and color by drawing a textured mesh and a non-textured mesh with various Z values at the corners and compares with the Reference rasterizer.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases.


TD-5.27 SubPixel Texture Test Description

Overview

The SubPixel Texture Test verifies subpixel accurate textures by drawing a textured mesh with lots of random subpixel triangles and compares with the Reference rasterizer.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases.


TD-5.28 Display Texture Handle Test Description

Overview

The Texture Handle test is simple test that creates textures, 10 at a time, and verifies that they can be used in rasterization, and that they rasterize correctly. It does this by drawing a small square and sampling a pixel within the result, and verifying it against the data known to have been stored in that texture. The test continues to run until 10,000 handles have been created. Texture handles are not released until the entire test run has been completed.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results

A pass or fail indication of compliance with this requirement is displayed and logged by the test program.


TD-5.29 Alpha Blending Test Description

Overview

Filtered Textures and Perspective Correction

Support is required for the following Direct3D alpha blending modes:

D3DBLEND_DESTCOLOR | D3DBLEND_INVDESTCOLOR
D3DBLEND_INVSRCALPHA | D3DBLEND_INVSRCCOLOR
D3DBLEND_ONE | D3DBLEND_SRCALPHA
D3DBLEND_SRCCOLOR | D3DBLEND_ZERO

Source alpha blending support for each of these modes satisfies the minimum requirement. Destination alpha blending is only recommended, but is verified if reported as a capability.

Support for the following Direct3D alpha blending modes is recommended:

D3DBLEND_BOTHINVSRCALPHA | D3DBLEND_BOTHSRCALPHA
D3DBLEND_DESTALPHA | D3DBLEND_INVDESTALPHA
D3DBLEND_SRCALPHASAT |

Source and destination alpha blending is tested for each of these recommended modes only if reported as a device capability.

The test program first verifies support for these modes by checking the triangle primitives structure initialized by Direct3D function GetCaps. Each reported alpha blending mode reported in the capabilities structure is verified for compliance.

Using the Direct3D HAL, the test program then renders a set of triangles and applies each of the supported source and destination alpha blending modes. Compliance is verified automatically by comparing the resultant pixel values in the primary surface frame buffer with pixel values generated by the Direct3D reference rasterizer. Each possible combination of source and destination mode is also verified.

A 15% error tolerance is allowed between the hardware-generated image and the reference rasterizer image. This error value is calculated as the cumulative pixel value differences between any two scenes.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases, which includes the specific combination of alpha blending modes applied to the scene.


TD-5.30 Z Write Test Description

Overview

The Z Write Test verifies the ZEnable and ZWriteEnable render states by altering the values of these render states, drawing two overlapping triangles, and compares with the reference rasterizer.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases.


TD-5.31 W Buffer Test Description

Overview

The W buffer is tested with two tests. One draws three meshes on top of each other, altering the depth, and comparing with the reference rasterizer. The other test verifies the various modes of W compare by rendering triangles with various RHW values and comparing with the reference rasterizer. The modes of W compare that are tested are:

  • Always
  • Equal
  • Greater
  • GreaterEqual
  • Less
  • LessEqual
  • Never
  • NotEqual

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases.


TD-5.32 Palettized textures – Force Update Test Description

Overview

Test verifies texturing capabilities with 8-bit and 4-bit palettized textures with alpha and non-alpha palettes. During the loop it circles throw following scenarios: (1) create palettized texture tests, (2) load texture tests, (3) palette recreation test, (4) set entries test, (5) wrap addressing mode test, (6) mirror addressing mode test, (7) clamp addressing mode, (8) border addressing mode, (9) color key test, (10) color key blend test.

To verify texturing capabilities the application renders a full window rectangle over colored background and applies texture to it. Verification algorithm is based on image comparison with image generated by reference device.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases.


TD-5.33 Fogging Test Description

Support is required for fog of an arbitrary color, calculated on a per-vertex basis. Using the DirectX HAL device, the test first queries the device capabilities and ensures that per-vertex fog is supported. The test then renders several scenes with various colors of vertex fog activated. A sampling of pixel values in the primary surface buffer is compared to the same scene generated using the DirectX 6 reference rasterizer. A 15% tolerance is allowed to account for precision differences between the hardware-generated image and the reference rasterizer image.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases, which includes the vertex fog color used to generate the image.


TD-5.34 Lighting Test Description

Overview

Click to show or hide information. Bump Env Map

Test verifies compliant support of bump environment map textures (DuDv[Lu]), D3DTOP_BUMPENVMAP and D3DTOP_BUMPENVMAPLUMINANCE. Bump environment map textures are combined in a variety of ways with RGBA textures in single and multiple texture stage scenarios as allowed by the caps exposed through the graphics device. An RGBA texture with the largest G channel is selected. Compliant bump matrix, bump luminance offset, bump luminance scale and texture addressing support is determined by comparison against the reference rasterizer. Test also verifies compliant support of bump environment map textures in conjunction with compliant support of D3DDEVCAPS_TEXTURESYSTEMMEMORY and applies a mixture of valid and invalid scenarios with system and video memory textures. Valid scenarios are determined to be correct as compared to the reference rasterizer. Invalid scenarios are determined to be correct as compared to the sample display driver. The sample display driver returns D3DERR_WRONGTEXTUREFORMAT when system and video memory textures are applied in an inconsistent manner with that supported by the sample display driver hardware.

Click to show or hide information. Luminance

Test verifies compliant support for alpha luminance textures ([A]L). Alpha luminance textures are combined in a variety of ways with RGBA textures in single and multiple texture stage scenarios as allowed by the caps exposed through the graphics device. An RGBA texture with the largest G channel is selected.

Click to show or hide information. Lightmap

Test verifies compliant support of D3DTOP_DOTPRODUCT3 with respect to RGB. All non palettized RGBA textures supported by the graphics device are applied in single and multiple stage scenarios and compared against the reference rasterizer to measure compliant support.

(Alpha) Test verifies compliant support of D3DTOP_DOTPRODUCT3 with respect to alpha. Essentially, this test verifies that the result of the dot product operation is replicated across the RGBA channels correctly as compared to the reference rasterizer.

(Factor) Test verifies compliant support of D3DTOP_DOTPRODUCT3 with respect to D3DTA_TFACTOR. Essentially, this test verifies that the result of the dot product operation is correct as compared to the reference rasterizer when the texture values are retrieved from a texture factor rather than through a texture.

(Mix) Test verifies compliant support of D3DDEVCAPS_TEXTURESYSTEMMEMORY and applies a mixture of valid and invalid scenarios with system and video memory textures. Valid scenarios are determined to be correct as compared to the reference rasterizer. Invalid scenarios are determined to be correct as compared to the sample display driver. The sample display driver returns D3DERR_WRONGTEXTUREFORMAT when system and video memory textures are applied in an inconsistent manner with that supported by the sample display driver hardware. If D3DTOP_DOTPRODUCT3 is supported, this D3DTOP_DOTPRODUCT3 is applied, if not, D3DTOP_MODULATE is applied. Either texture operation provides a solid measure of valid scenarios when compared to the reference rasterizer.

Click to show or hide information. Texture transformation

The test verifies texture transformation capabilities with different types of input vertex data, number and type of out texture coordinates.

The test application renders a sphere in orthogonal and perspective (on hardware that support projected textures) projections with texture that was "projected" from the background image with magnification. During the loop test tries to create from 1 to 3 output texture coordinate sets from one input set. Verification algorithm compares the result image with image rendered by reference device.

Click to show or hide information. Lighting

The test verifies following features of device lighting pipeline: ambient (including per-light ambient), diffuse, specular and emissive lighting with directional, point and spot light types, local and non-local viewer specular highlights and material source settings.

Lighting verification is based on rendering points mesh lit by one or two light sources with different properties, reading results from the back buffer and comparison with results of internal reference calculations. To avoid test fails caused by difference in rasterization rules the test reads back a 3x3 pixels rectangle for comparison.

Click to show or hide information. Multiple lights

The test creates different number of lights in each test case using five different scenarios: (1) disable lights prior to initialization, (2) enable lights in 0 to MAX order, (3) enable lights in MAX to 0 order, (4) enable lights in pseudo random order, (5) enable lights without initialization to test default parameters.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases.


TD-5.35 Compressed Texture Test Description

Overview

The Compressed Texture Test renders a striped various DXT textures, varies alpha values (none, mesh alpha, texture alpha, or both), rotates texture mapping, alters mesh color, tiles texture from one to four, varies Z values of mesh for perspective correction, cycles texture formats used to blt from, and compares with the reference rasterizer. The DXT textures that are rendered and used are:

  • DXT1
  • DXT2
  • DXT3
  • DXT4
  • DXT5

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases.


TD-5.36 Stencil Test Description

Overview

The stencil test verifies compliant stencil functionality when z buffers with stencil planes are exposed. Compliant Direct3D stencil support is based on:

z buffer enumeration
D3DSTENCILCAPS_KEEP*
D3DSTENCILCAPS_ZERO*
D3DSTENCILCAPS_REPLACE*
D3DSTENCILCAPS_INCRSAT*
D3DSTENCILCAPS_DECRSAT*
D3DSTENCILCAPS_INVERT*
D3DSTENCILCAPS_INCR
D3DSTENCILCAPS_DECR

*Required support if z buffers with stencil planes are enumerated.

Command Line Options

General options | Description
-cap | D3DSTENCILCAPS_* validation
-clear | Clear2() validation with respect to stencil planes
-func | D3DRENDERSTATE_STENCILFAIL, ZFAIL, PASS validation
-ignore | verifies stencil operations are not ignored
-op | D3DSTENCILOP_* validation
-scorrupt | stencil plane corruption detection
-zcorrupt | z plane corruption detection
-? | help menu

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases, which includes the specific z buffer format (including z buffer and stencil buffer bit depths) as well as the specific stencil functionality not exhibiting compliant behavior.


TD-5.37 Multi-texturing Tests Description

Overview

This test sets up the color operation and alpha operation of texture stages and then sets textures for the stages if required. It then renders triangles. The test exercises texture stages only up to the max_simultaneous_stages caps reported by device. For every test case the test makes sure ValidateDevice call is handled correctly by the driver for the texturestages.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

The image obtained by HAL is compared against the refrast image to see conformance.

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases.


TD-5.38 Mip-mapped Texture Tests Description

This test is obsolete and has been removed from Kit.

Overview

The Mip-mapped Texture Tests have been removed from the kit.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases.


TD-5.39 Display Simultaneous Features Test Description

Overview

All required RGB rasterization features must be available for activation at the same time. These features include:

  • Bilinear or better texture filtering
  • MIP-mapped textures
  • Alpha blending (8 required Direct3D modes)
  • Flat shading or Gouraud shading
  • Fog of an arbitrary color, calculated on a per-vertex basis
  • Specular highlighting

To validate simultaneous support for these features, the test program uses Direct3D HAL to display a complex animated scene and then sequentially activates each feature. An automated comparison to the Reference rasterizer (baseline) is performed to verify compliance with this requirement. Rasterization features are exaggerated to make comparison with the baseline image as simple as possible. A 15% error tolerance is allowed between the hardware-generated image and the Reference rasterizer image. This error value is calculated as the cumulative pixel value differences between any two scenes.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases, which include the specific combination of rasterization features that failed. All results are recorded in a detailed log file.


TD-5.40 Specular Highlighting Test Description

Overview

Using the DirectX HAL device, the test first queries the device capabilities and ensures that specular highlighting is supported. The test then renders and lights a simple scene that contains a material with specular properties defined. Eight different specular reflection properties are applied at different power levels to the material. A sampling of pixel values in the primary surface buffer is compared to the same scene generated using the DirectX reference rasterizer. A 15% tolerance is allowed to account for precision differences between the hardware-generated image and the reference rasterizer image.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases, which includes the specific combination of specular and power values that were used.


TD-5.41 Clear Offscreen/Texture Surface Test Description

Overview

The following functionality is tested

  • full screen RGB clear
  • full screen z clear
  • full screen stencil clear
  • full screen alpha clear
  • RGB clear / z buffer and stencil buffer independence
  • z clear / stencil buffer independence
  • stencil clear / z buffer independence
  • RGB clear with rectangle list
  • z clear with rectangle list
  • stencil clear with rectangle list

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows 98/ME or Windows 2000 operating system must be installed, as well as DirectX version 7 or higher.

Results Interpretation

Image conformance with the DirectX Reference rasterizer image percentage is displayed and logged by the test program. 100% conformance is mandated for this test.


TD-5.42 Multi-sampling Tests Description

Overview

Antialiasing

An inclined edge is formed between two triangles of two different colors (LeftColor and RightColor). Sets of such edges are drawn with differing inclinations. Let the angle of inclination be 'a'. Then we choose 'a' such that tan(a) is a whole number. What this means is the edge will do one staircase for every tan(a) pixels on the y axis if anti-aliasing were off. Now let us imagine a horizontal scan line of zero thickness and the edge between LeftColor and RightColor of zero thickness. The intersection point of these two lines will either lie inside a pixel or lie in between two pixels. We ignore the second case. If it lies inside a pixel the color of that pixel must be a linear combination of LeftColor and RightColor in the following ratio.

d = x(edge) - x(intersection pixel);

ratio = d + 0.5;

ideal intersection pixel color = (ratio * LeftColor) + ((1 - ratio) * RightColor);

Note this algorithm has the advantage that it does not increase the visual thickness of an edge.

Also sometimes logarithmic blending looks better compared to linear blending. But the conformance percentages are such that it will pass logarithmic blending also.

If antialiasing were not enabled, we know what would be the color of the intersection pixel. It would be LeftColor if d is positive and RightColor if d is negative. It is taken as the "wrong color". Then for each intersection pixel along the edge for one stair case, the deviation from the "ideal color" for that pixel is calculated with the "wrong color" for that pixel as the base. Then the cumulative deviation is found and averaged to find the mean deviation. Permissible mean deviation is set smaller and smaller as number of samples in multi-sampling increases because then the quality of antialiasing is supposed to increase as the number of samples increases.

Note: Refrast image comparison was not used because the best way of doing multisample antialiasing cannot be mandated.

Note: The method explained above is the theoretical basis of the test algorithm. The exact technique may differ.

One test case renders a scene toggling multisample_antialiasing on and off repeatedly. For the primitives in the scene rendered when renderstate multisample_antialiasing was toggled off, antialiasing must NOT be applied on the edges. For the primitives in the scene rendered when renderstate multisample_antialiasing was toggled on, antialiasing must be applied on the edges.

Masking

For Multisample_N mode, N triangles are drawn with the first one just using one sample, the second one using two samples, and so on until N. The first triangle is algorithmically analyzed for intensity 1/N, the second triangle for intensity 2/N, and so on until N. For this analysis, a few pixels from the respective triangle are read and compared with the expected color intensity. A deviation percentage is found based on the fact that deviation must be 100% if the intensity reaches the next lower or higher multisample level. Mean deviation is found by averaging the deviations for the pixels read. Permissible mean deviation is set larger and larger as number of samples in multi-sampling increases because then a small deviation in color is amplified in percentage.

Note: DirectX Reference rasterizer image comparison is not used as an efficient procedural verification can be applied as described above.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows 98/ME Windows 2000 operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

Click to show or hide information. Antialiasing

Conformance percentage is found as (100 – mean deviation) and is displayed and logged by the test program. Pass/Fail is based on conformance percentage meeting the required conformance set for each multi-sampling level.

ReqConf[D3DMULTISAMPLE_NONE] = 0;
ReqConf[D3DMULTISAMPLE_2_SAMPLES] = 10;
ReqConf[D3DMULTISAMPLE_3_SAMPLES] = 12;
ReqConf[D3DMULTISAMPLE_4_SAMPLES] = 35;
ReqConf[D3DMULTISAMPLE_5_SAMPLES] = 36;
ReqConf[D3DMULTISAMPLE_6_SAMPLES] = 37;
ReqConf[D3DMULTISAMPLE_7_SAMPLES] = 38;
ReqConf[D3DMULTISAMPLE_8_SAMPLES] = 39;
ReqConf[D3DMULTISAMPLE_9_SAMPLES] = 40;
ReqConf[D3DMULTISAMPLE_10_SAMPLES] = 42;
ReqConf[D3DMULTISAMPLE_11_SAMPLES] = 43;
ReqConf[D3DMULTISAMPLE_12_SAMPLES] = 45;
ReqConf[D3DMULTISAMPLE_13_SAMPLES] = 46;
ReqConf[D3DMULTISAMPLE_14_SAMPLES] = 48;
ReqConf[D3DMULTISAMPLE_15_SAMPLES] = 49;
ReqConf[D3DMULTISAMPLE_16_SAMPLES] = 51;

Note: The percentages are subject to change.

Click to show or hide information. Masking

Conformance percentage is found as (100 – mean deviation) and is displayed and logged by the test program. Pass/Fail is based on conformance percentage meeting the required conformance set for each multi-sampling level.

ReqConf[D3DMULTISAMPLE_NONE] = 90%
ReqConf[D3DMULTISAMPLE_2_SAMPLES] = 90%
ReqConf[D3DMULTISAMPLE_3_SAMPLES] = 90%
ReqConf[D3DMULTISAMPLE_4_SAMPLES] = 90%
ReqConf[D3DMULTISAMPLE_5_SAMPLES] = 80%
ReqConf[D3DMULTISAMPLE_6_SAMPLES] = 80%
ReqConf[D3DMULTISAMPLE_7_SAMPLES] = 80%
ReqConf[D3DMULTISAMPLE_8_SAMPLES] = 80%
ReqConf[D3DMULTISAMPLE_9_SAMPLES] = 80%
ReqConf[D3DMULTISAMPLE_10_SAMPLES] = 70%
ReqConf[D3DMULTISAMPLE_11_SAMPLES] = 70%
ReqConf[D3DMULTISAMPLE_12_SAMPLES] = 70%
ReqConf[D3DMULTISAMPLE_13_SAMPLES] = 70%
ReqConf[D3DMULTISAMPLE_14_SAMPLES] = 70%
ReqConf[D3DMULTISAMPLE_15_SAMPLES] = 70%
ReqConf[D3DMULTISAMPLE_16_SAMPLES] = 70%


TD-5.43 Present Validation Test Description

Overview

The Present Validation Test will attempt to validate the Preset() method. The main aspects of this test are as follows:

  • To shrink or stretch in height.
  • To shrink or stretch in width.
  • To clip to the source area.
  • To clip to the destination area.
  • To override the destination window.

All of the above aspects of Present are performed individually and in combination, and the resulting output is verified for correctness.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows 98/ME or Windows 2000 operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases, which includes a count of the number of incorrect destination pixels as well as detailed information about the first 15 pixels that did not pass validation.

For each of the first 15 incorrect pixels, there will be one such information line in the log file. The line, from left to right, is generally the destination pixel location and color, the source location, size, and color, and the difference between the corresponding colors. The format of the information is as follows:

dest {(DX,DY) [DR DG DB]} !=
src {(SX,SY)(SWxSH) [SRL-SRH SGL-SGH SBL-SBH]} diff{[LR LG LB]}

With the following symbol definitions:

(DX,DY)

This is the offset location of the destination pixel being validated. DX and DY are the X and Y coordinates, respectively.

[DR DG DB]

This is the color of the destination pixel being validated. DR, DG, and DB are the red, green, and blue color components, respectively.

(SX,SY)

This is the offset location into the source which is the upper left corner of the rectangle of pixels influencing the destination pixel. SX and SY are the X and Y coordinates, respectively.

(SWxSH)

This is the size of the source rectangle of pixels influencing the destination pixel. SW and SH are the width and height, respectively.

[SRL-SRH SGL-SGH SBL-SBH]

This indicates the color range of the rectangle of source pixels influencing the destination pixel. The three ranges define an RGB subcube which must contain the destination color for the pixel to validate correctly. SRL and SRH are the red minimum and maximum values; SGL and SGH are the green minimum and maximum values; SBL and SBH are the blue minimum and maximum values.

[LR LG LB]

This indicates the difference, or error, in the color of the destination pixel being validated. LR, LG, and LB indicate how far out of range the red, green, and blue components are, respectively.


TD-5.44 Matrix Palette Skinning Test Description

Overview

Test goes through several blends (2, 3, and 4) for each of non-indexed and indexed matrix blending. Each group of blends does several blending tests, and results are compared against the reference. There is also a vertex shader test, testing three programmed shaders (2, 3, and 4 blends, similar to the others) for testing argument passing and such.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test will not be run on non-TnL devices, since the primary interest here is whether the hardware blending works. Microsoft Windows 98/ME or Windows 2000 operating system must be installed, as well as DirectX version 8 or higher (since this is mainly a DirectX 8 feature).

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. A failure should indicate errors in the geometry of the blend on the device.


TD-5.45 The Blt Queue Test Description

Overview

Test verifies that drivers do not queue more than 3 presentation blts. A series of presentation blts are sent to the hardware driver, followed by a call to LockRect to flush the blt queue and determine the number of blts that were outstanding.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows 98/ME or Windows 2000 operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases, which includes the number of presentation blts that were calculated to have been queued.


TD-5.46 The Lockable Depth Buffer Test Description

Overview

Test verifies that if a lockable z-buffer format is exposed, its functionality is consistent with expected behavior. This test locks the z-buffer and populates it with data, unlocks and renders primitives, locks the z-buffer again to compare the depth values against the Reference Rasterizer, and then compares final RGB image against the Reference Rasterizer.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows 98/ME or Windows 2000 operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases, which includes the number of pixels which contained a depth buffer value differing significantly from the Reference Rasterizer.


TD-5.47 The Point Sprite Test Description

Overview

The point sprite test runs through a series of standard operation that can be performed using point sprites. For DirectX 6 and 7 drivers the DirectX runtime will simply convert point sprites to quads and allow the driver to process these quads as normal. As of DirectX 8 point sprites can be natively supported by hardware. The test proceeds in the following order

  • Point sprite attenuation/scale with distance from the camera.
  • Point sprite attenuation/scale with distance from the camera (size included in vertex)
  • Point sprites that are defined in world co-ordinates and are lit
  • Point sprites that are defined in world co-ordinates and are lit (size included in vertex)
  • Point sprites that are transformed and lit.
  • Point sprites that are transformed and lit (size included in vertex)
  • A mixture of point sprites and primitives rendered interspersed with each other. (batch)
  • MIP mapped textures on point sprites of the same type as the first test.
  • Cull mode changes while running the batch test in 1 texture format
  • Fill mode changes while running the batch test in 1 texture format
  • User Clipping planes tests that point sprites are clipped correctly to user clip planes.
  • Caps checking is used for caps that must be present but don’t stop the test from running.

The attenuation/scale test are perform with the D3DRS_POINTSCALEENABLE render state set to true all other test set this render state to false. For more information on the equation used for this scaling please refer to the reference documents outlined above. Each test is performed in all the common texture formats supported by the reference rasterizer and the driver being tested. For all, except the point sprite scale sections, point sprites are drawn in several locals to test clipping of point sprites against the view port.

The point sprite batch section renders three point sprites follow by a quad and then a further three point sprites. The final three point sprites contain no texture co-ordinates and hence must be rendered with the default texture co-ordinates, in the case were D3DRS_POINTSPRITEENABLE render state is set to false. (See DirectX 8 DDK documentation on point sprites). The three point sprites start at max point size and go down to a single pixel point. Shade modes, texturing and D3DRS_POINTSPRITEENABLE are also switched on and off during the progression of this stage of the test.

The Mip mapped point sprites component of this test as the name suggest tests that RGB mip mapped textures are rendered correctly on to point sprites. Each LOD is a different color.

The mode test components are to ensure that point sprites are rendered correctly regardless of the cull or fill modes. Here the cull and fill modes are changed while running the batch test in a single texture format.

The user clipping plane test simply check that point sprites are clipped correctly to user defined clipping planes. This component of the test is only run if user defined clipping planes are supported.

If MaxPointSize cap is set to anything other that one it should be set to 16 or greater (preferably >= 64). However MaxPointSize can be set to 1.0f. In this case the driver has indicated that no point sprite support is provided by the hardware/driver.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows 98/ME or Windows 2000 operating system must be installed, as well as DirectX version 8 or higher.

Results

A pass or fail indication of compliance with this requirement is displayed and logged by the test program.


TD-5.53 Set Render Target Test Description

Overview

Set Render Target

Test verifies rendering to a texture for all texture formats that can be specified as a render target. It compares all renders with the reference rasterizer while performing the following render to texture techniques:

  • Renders directly to the texture for all texture formats with each Z buffer formats.
  • Renders directly to the texture for all texture formats with Z buffers disabled.
  • Renders to an offscreen surface and blts to the texture for all texture formats with each Z buffer formats.
  • Renders to an offscreen surface and blts to the texture for all texture formats with Z buffers disabled.

Set Render Target - Invalid

Test verifies that there are no ill effects (system corruption, blue screen, etc) when rendering to a texture that is currently set.

Multiple Swap Chains

The MultiSwapchain test creates 4 swap chains and a 3D model with multi-texturing. It then draws different views of the model for different swap chains and then compares the image in each swap-chain to the corresponding image done by the reference rasterizer. The test then animates the 3D model. Drawing different views to swap chains, image comparison and animation are repeated several times.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows 98/ME or Windows 2000 operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

Image conformance with the DirectX Reference rasterizer image percentage is displayed and logged by the test program. At least 85% conformance for each of the separate views is mandated for this test


TD-5.54 GetRasterStatus Test Description

Overview

The GetRasterStatus Test will validate the GetRasterStatus() method. This test will insure that the scan lines reported via the GetRasterStatus() method are consistent with the display refresh rate returned by GetDisplayMode().

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows 98/ME or Windows 2000 operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases, which includes the refresh rate calculated from GetRasterStatus() and that returned from GetDisplayMode().


TD-5.55 Vertex Buffer and Index Test Description

Overview

The Vertex and Index Buffer Test will attempt to validate the use of a variety of vertex and index buffers. This test is broken into a number of test groups that test vertex and index buffers in different ways. The test groups are as follows:

Click to show or hide information. NormalBuffer

This test group insures that simple objects can be rendered correctly.

Click to show or hide information. LockActive

This test group insures that a selected vertex or index buffer can be rendered from and locked across multiple scenes and in one scene.

Click to show or hide information. Priority

This test group insures that a selected vertex or index buffer can have it’s priority manipulated while rendering a scene.

Click to show or hide information. SwitchRenderState

This test group insures proper operation when switching between hardware and software vertex processing during a scene.

Click to show or hide information. LostOnReset

This test group insures that all buffers are required to be released before a Reset() will succeed.

Click to show or hide information. HugeBuffer

This test group insures that an large object can be rendered correctly.

Click to show or hide information. RelockDynamic

This test group insures that dynamic vertex and index buffers can be reused in a single scene correctly.

Click to show or hide information. LockPointerAlias

This test group insures that, upon a device lost condition, pointers to vertex and index buffers obtained through Lock() do not cause exceptions.

Click to show or hide information. InternalPointerAlias

This test group insures that, upon a device lost condition, internal buffer pointers do not cause exceptions (such as during calls to DrawPrimitive() or DrawIndexedPrimitive() ).

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows 98/ME or Windows 2000 operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases, which depends on the test group, but may include the failing method or all prior methods in the test case.


TD-5.56 Clipping Test Description

Overview

Click to show or hide information. TL Vertex Clip

This test checks that lines are clipped correctly to a view port by examining the render target for pixels drawn outside the view port. These lines are drawn between two transformed and lit vertices that may or may not be inside the view port. In DirectX 6 and 7 it is required that the driver performs this type of clipping correctly. As of DirectX 8 the driver has the option of supporting the functionality by setting the D3DPMISCCAPS_CLIPTLVERTS cap of the Primitive Miscellaneous Capabilities. If the above cap is set then this test is performed as in DirectX 6 and 7. If the cap is not set then this test is an invalid parameter test and the diver must simply remain stable but is not required to produce any sensible output.

Click to show or hide information. Viewport Clipping

The test verifies accuracy of viewport clipping and interpolation of diffuse and specular colors, alpha and vertex fog values and texture coordinates. During the test run it circles throw different primitive types, rendering APIs and few sets of rendering properties in gouraud and flat shading modes.

To perform clipping verification test sets smaller viewport for testing device. Reference device has usual viewport settings and application locks and paints its back buffer after rendering to emulate the results of a smaller viewport settings.

Click to show or hide information. Arbitrary Clipping Planes

The test verifies accuracy of clipping with arbitrary clipping planes and interpolation of diffuse and specular colors, alpha and vertex fog values and texture coordinates. During the test run it circles throw different primitive types, rendering APIs and few sets of rendering properties in gouraud and flat shading modes.

To perform clipping verification test sets from 4 to 6 clipping planes for testing device. On reference device the same picture achieved by locking and painting back buffer after rendering.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results

A pass or fail indication of compliance with this requirement is displayed and logged by the test program. For the invalid parameter version of this test a pass is simply making it to the end of the test cases.


TD-5.57 Multipass Z-Fighting Test Description

Overview

Multipass z-fighting test attempts to determine if multipass rendering exhibits independence with respect to vertex order and primitive types. A transformed and lit (TL) vertex quad is rendered multiple times (4) such that the diffuse color is changed each pass (red -> green -> blue -> white), vertex order is changed each pass (clockwise vertex rotation) and the primitive type is changed each pass (fan -> list -> strip -> fan).

Command line options

Option | Description
-fan | primitive type is fixed (fan)
-list | primitive type is fixed (list)
-strip | primitive type is fixed (strip)
-static | vertex order is fixed
-? | help menu

-static can be combined with -fan, -list or -strip.

-list overrides -fan; -strip overrides -fan and -list.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows 98/Me or Windows 2000 operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-5.58 State Blocks Test Description

Overview

The stateblocks test creates stateblocks through various techniques, applies those blocks and verifies that the proper state gets rendered. The test creates stateblocks records stateblocks through the BeginStateBlock / EndStateBlock method as well as creating stateblocks for each of the predefined stateblock types (SBT_ALL, SBT_VERTEX, SBT_PIXEL) through CreateStateBlock. In the latter case, the state gets recorded through a call to CaptureStateBlock.

Command line options

-testblock:< block # >

Executes only the test block requested.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases, which includes stateblock number and repro scenario (i.e. What was recorded/applied in the stateblock). You can pass the stateblock number to the test through the "-testblock" command line param to test only specific blocks.


TD-5.59 Vertex Buffer Rendering Tests Description

Overview

Test verifies device capabilities to render primitives from different types of vertex buffers (system and driver-allocated memory, vertex type and vertex buffer optimization), different usage pattern (varies number of vertices supplied with one call to a rendering function and different vertex offset) and different lighting or specular parameters.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases.


TD-5.60 Vertex Tweening Tests Description

Overview

This test verifies vertex tweening and vertext shader capabilities of the device by rendering a morphing parametric surface using different code for the vertex pipeline. The test contains two groups:

  • VertexTweenFixedFunction performs vertex tweening using the fixed function pipeline
  • VertexTweenVertexShader test group performs vertex tweening using a custom vertex shader

Each group could be executed separately by specifying dash followed by the test name in the command line (like -VertexTweenFixedFunction or -VertexTweenVertexShader)

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows 98/ME or Windows 2000 operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. The output comparison requires 95% conformance in order for the test to pass. Additional information is generated on some failure cases, which includes API HRESULTS and as much helpful information from the test as possible.


TD-5.61 Vertex Blending Tests Description

Overview

The test verifies vertex blending transformations with different number of transformation matrices (from 2 to 4) by rendering a sphere with non-linear distribution of blending coefficients across its Y-axis. At any given time only 2 matrices are used. Other matrices are set to identity (second matrix in 1, 3 case) or undefined (fours matrix in 1,3 case). During the loop test also goes across three different scenarios: (1) geometry only, (2) texture with texture coordinates, (3) texture with texture generation.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases.


TD-5.62 Texture Coordinate Generation Tests Description

Overview

The test verifies texture coordinate generation capabilities in four different modes: (1) camera space coordinates, (2) camera space normal, (3) camera space reflection vector in non-local viewer mode and (4) camera space reflection vector in local viewer mode. All these modes are tested with different texture transformations settings and regular or vertex blending transformations.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases.


TD-5.63 Pixel Shaders Tests Description

Overview

The test verifies the pixel shader capabilities of the device by rendering a quad using different pixel shader code for each rendering. The shaders are tested for each version smaller than and equal to the version the driver declares it supports in the PixelShaderVersion capability. The test executes through the following groups and in version order i.e. all version 1.0 shaders will be tested before version 1.1 etc. etc:

Touch all Registers | Test that every register and constant that should be available for a given version is present.
Texture address instructions | This group makes sure that all addressing instructions for a particular version are working correctly.
Output Write Masks | Verifies output write masks support matches the version stated.
Arithmetic Instructions & Modifiers | Verifies that Arithmetic instructions and instruction modifiers work correctly.
Argument Modifiers | Tests all the argument modifiers for a given version.
Read Shader | This is an open-ended portion of the test that is used to add shaders that have proven to be problematic in some way for drivers.
Vertex Shader/Pixel Shader combination | This portion of the test uses combinations of software/hardware vertex shaders with pixel shaders.

Each of these groups contains a large number of operations. For more detailed information on how each of the operations works please refer to the Pixel Shader Assemblers Reference in the SDK Documentation.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP, W2K or Win9x operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases.


TD-5.64 Surfaces Tests Description

Overview

This test checks device capacity to create various surfaces. It tries to create different formats and multisampling types of surfaces (including image surface, render target surface and depth stencil surface), and then check to see if the result is consistent with the capacities the device exposes. It also tries other tests, like creating huge surfaces, or a lot of small surfaces to see if the device functions correctly.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-5.65 Texture Update Test Description

Overview

This test verifies device capacities to load textures (mipmap, cubemap) using UpdateTexture function. It first creates a source texture in the system memory, and destination texture in the video memory (source and destination texture could be square or non-square, could have different levels) and populate them with data. Secondly, it does some preparation on the source texture, including (1) make the entire texture dirty. (2) make a portion of the texture dirty. Finally it calls UpdateTexture to load the texture, and check the destination texture to make sure it is loaded correctly.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-5.66 Vertex Shaders Test Description

Overview

This test verifies vertex shader capabilities of the device by rendering a sphere primitive using different code for the vertex pipeline. The test contains two groups:

  • VSOps is the general instructions test group which contains a number of pre-defined simple shaders for each vertex shader instruction
  • VSGen test group combines different transformation and lighting parts to produce more complex vertex shaders

Each group could be executed separately by specifying dash followed by the test name in the command line (like -vsops or -vsgen)

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases.


TD-5.67 Volume Texture Test Description

Overview

Test verifies the proper rendering of volume textures. It does this by comparing all renders to the reference rasterizer while using volume textures in the following ways:

  • Renders all volume texture formats while displaying a variety of depths.
  • Renders all volume texture formats while using five mip levels.
  • Renders volume textures while using all texture generation modes.
  • Renders volume textures while using all volume texture filtering modes.
  • Renders all volume texture formats while using a variety of common texture blending modes.
  • Renders volume textures while using all volume texture addressing modes.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases.


TD-5.68 MipMapping Test Description

Overview

This test verifies device capacities to load textures (mipmap, cubemap) using UpdateTexture function. It first creates a source texture in the system memory, and destination texture in the video memory (source and destination texture could be square or non-square, could have different levels) and populate them with data. Secondly, it does some preparation on the source texture, including (1) make the entire texture dirty. (2) make a portion of the texture dirty. Finally it calls UpdateTexture to load the texture, and check the destination texture to make sure it is loaded correctly.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows 98/ME or Windows 2000 operating system must be installed, as well as DirectX version 6 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-5.69 High Order Surfaces Test Description

Overview

The high order surface test verifies that the hardware device can properly render surfaces of up to quintic order. For RT-Patches, the test generates bezier, b-spline and interp (Catmull-Rom) surfaces of linear, cubic and quintic orders and renders then through calls to DrawRectPatch and DrawTriPatch. The test also tries various tesselation techniques (Discrete & Continuous) and tesselation values for each edge of the tri/rect, and caches the resulting surfaces across several frames (each frame from a different viewing perspective). For N-Patches, the test simply renders several geosets with different levels of tesselation and verifies that the device renders them correctly.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases, which includes surface type, tesselation levels, tesselation technique, cache information, and basis/order information.


TD-5.70 Memory/Texture Management Test Description

Overview

This is actually implemented as series of tests housed in the Memman.exe module. The tests attempt to verify that video memory is accurately reported and managed. They also ensure that the 3D pipeline is properly flushed when an "in-use" managed texture is changed, and that managed memory is properly freed up by the ResourceManagerDiscardBytes() call.

Here is a detailed description of the individual tests:

Memory Management- Consume with VertexBuffers

This test performs some basic checks on the video memory manager. The test fills video memory using CreateVertexBuffer(). VBs are created in a variety sizes and formats. As each VertexBuffer is created it is filled with vertex information that can later be read back to verify the integrity of the memory and to ensure Vertex Buffer allocations do not step on one another. The test further verifies that all reported video memory can be used (allowing for a maximum of 25%% to be inaccessible), and it verifies that memory is used efficiently (The test expects the reported memory usage to vary by no more than 25% of the calculated value). Finally the test expects all video memory to be freed, when the vertex buffers are released.

Memory Management- Consume all video mem with textures

This test performs some basic checks on the video memory manager. The test fills video memory using CreateTexture(). Textures are created in a variety of pixel formats, dimensions, and mip-levels. As each texture is created it is filled with a pixel value that can later be read back to verify the integrity of the memory, and to ensure texture allocations do not step on one another. Because, video memory cannot be directly accessed, the test uses UpdateTexture() to initially fill the surface, and verifies it by copying to system memory using CopyRects(). The test is therefore highly dependent on these functions working properly. Initial testing indicates most problems are in these functions, and not the memory manager.\n");

The test further verifies that all reported video memory can be used (allowing for a maximum of 25% to be inaccessible), and it verifies that memory is used efficiently (The test expects the reported memory usage to vary by no more than 25% of the calculated value). finally the test expects all video memory to be freed, when all textures are released.

Memory Management- Consume random video mem

This test performs some basic checks on the video memory manager. The test randomly creates and releases textures; fragmenting memory, and potentially revealing flaws in the memory manager. Textures are created in a variety of pixel formats, dimensions, and mip-levels. As each texture is created it is filled with a pixel value that can later be read back to verify the integrity of the memory, and to ensure texture allocations do not step on one another. Because, video memory cannot be directly accessed, the test uses UpdateTexture() to initially fill the surface, and verifies it by copying to system memory using CopyRects(). The test is therefore highly dependent on these functions working properly. Initial testing indicates most driver problems are in these functions, and not the memory manager. The test expects all video memory to be freed, when all textures are released.

ResourceManagerDiscardBytes

Verifies basic functionality of ResourceManagerDiscardBytes by using it to free up a 1/4 of managed texture memory.

ResourceManagerDiscardBytes - Zero Case

Verifies functionality of ResourceManagerDiscardBytes when passed zero for the amount of bytes to free (discard). Zero indicates that all managed texture memory should be freed.

ResourceManagerDiscardBytes - Greater than allocated

Verifies functionality of ResourceManagerDiscardBytes when asked to discard more texture memory than was allocated.

PreLoad - Basic Test

This test tries to verify that a managed texture can be preloaded by comparing how long it takes to render a scene with a preloaded texture and one without.

Texture Management - Texture re-use

This test verifies that managed textures can be reused (updated) within a frame. The test accomplishes this by changing the contents of a managed texture 9 times within a single frame. Each texture is rendered in it's original size of 64x64 using the D3DXSprite::Draw function. The test verifies that each image is drawn correctly, by comparing the rendered image against the original 32-bpp GDI DIB. The test allows for a roughly 25% difference in pixel values. (Calculated by converting all pixels to a 32-bit RGB equivalent and summing the differences of each Red, Green, and Blue component.) The test further allows up to 10% of the pixels to mismatch completely.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases.


TD-5.72 Morph – Invalid Params Test Description

Overview

Morph is an invalid parameter test suite targeting display driver robustness on Windows 2000. The test is designed using the IDirect3DDevice::Execute() API and reveals display driver problems in multiple ways:

  • blue screens
  • system hangs
  • system dysfunction including non-responsiveness, etc.

General system dysfunction is clearly the more difficult problem to solve and will require investigation of system resources (memory, handles, etc.) to pinpoint the problem. To recover from system disjunction caused by these tests, reboot the system. All resources should be reset to normal behavior. Valid scenarios (5) have been added for IDirect3DDevice::SwapTextureHandles() to account for test coverage deemed critical by OEMs. Texture swapping scenarios all involve swapping texture handles for RGB textures (of different formats when possible) of similar, dissimilar and non-square sizes based on the D3D devices reported capabilities. Total number of tests has changed from 560 to 570 (5 clipped and 5 unclipped for a total of 10).

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. The test log must indicate 570 variations run, 570 variations passed.


TD-5.73 Volume Texture Update Test Description

Overview

This test verifies device capacities to load volume textures using UpdateTexture function. It first creates a source texture in the system memory, and a destination texture in the video memory (source and destination texture could have different levels). Secondly, it calls UpdateTexture to load the source texture into destination texture (Could load the entire texture, or only part of the texture). Finally, it renders the texture and compares the image with REF to make sure the texture is loaded correctly.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-5.74 Anisotropic Texture Filtering Test Description

Overview

This test verifies proper anisotropic texture filtering of the device by rendering a series of tilted textured square primitives of various sizes. It then uses the resulting primitives to verify the different Min/Mag texture filtering options. The entire series of test cases are repeated for each supported MaxAnisotropy value. The test contains five groups.

Test group … | Uses…
PointAniso | Point as the MinFilter and Anisotropic as the MagFilter
LinearAniso | Linear as the MinFilter and Anisotropic as the MagFilter
AnisoPoint | Anisotropic as the MinFilter and Point as the MagFilter
AnisoLinear | Anisotropic as the MinFilter and Linear as the MagFilter
AnisoAniso | Anisotropic as the MinFilter and Anisotropic as the MagFilter

Each group could be executed separately by specifying dash followed by the test name in the command line (like -pointansio, linearaniso, etc.)

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases.


TD-5.75 Line Style Test Description

Overview

Test ensures consistent driver caps and proper functionality are exposed for line pattern and line pattern repetition. The following caps must be set consistently (both set or both unset):

D3DPRASTERCAPS_PAT (see D3DCAPS8.RasterCaps in the Dx SDK)

D3DPMISCCAPS_LINEPATTERNREP (see D3DCAPS8.PrimitiveMiscCaps in the Dx SDK)

Line pattern, line pattern repetition and styled line clipping scenarios are used to compare source (driver) and reference (Dx8 reference) images.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases.


TD-5.76 Resource Management / Lost Device Test Description

Overview

LostDev.exe is a series of tests that will check if the persistency of resources is kept after and while a "Lost Device" state. The program runs the series of tests on all resources that can be created via the device. Currently, CubeTextures, VolumeTextures, StateBlock and SwapChain are not tested.

Here is a detailed description of the individual tests:

1. Lost Dev While Rendering

This test will verify if the Resource is persistent if the device is lost after or while rendering.

- Create Resource

- lock and fill resource

- Draw Resource (A)

- Lose device

- Reset device

- Draw Resource (B)

Images produced in (A) and (B) are compared and should be identical.

Resource tested:

Textures, Vertex Buffers, Index Buffers are tested on MANAGED and SYSTEMMEM pool. ImageSurface are tested on SYSTEMMEM pool.

2. Creation while Lost

This test will verify if the Resource is persistent if the creation of the resource is after the device is lost and the resource's data filled BEFORE the restoration of the device.

- Lose device

- Create Resource

- lock and fill resource

- Reset device

- Draw Resource

Produced image should reflect data written to resource while lost.

Resource tested:

Textures, Vertex Buffers, Index Buffers are tested on MANAGED and SYSTEMMEM pool. ImageSurface are tested on SYSTEMMEM pool.

3. Creation while Lost Fill AFTER Restore

This test will verify if the Resource is persistent if the creation of the resource is after the device is lost and the resource's data filled AFTER the restoration of the device.

- Lose device

- Create Resource

- Reset device

- lock and fill resource

- Draw Resource

Produced image should reflect data written to resource while lost.

Resource tested:

Textures, Vertex Buffers, Index Buffers are tested on MANAGED and SYSTEMMEM pool. ImageSurface are tested on SYSTEMMEM pool.

4. Lock while Lost

This test will verify that the Resource is persistent if the resource's data is filled BEFORE the restoration of the device and AFTER the device is lost.

- Create Resource

- Lose device

- lock and fill resource

- Reset device

- Draw Resource

Produced image should reflect data written to resource while lost.

Resource tested:

Textures, Vertex Buffers, Index Buffers are tested on MANAGED and SYSTEMMEM pool. ImageSurface are tested on SYSTEMMEM pool.

5. Lost while Locked

This test will verify that the Resource is persistent if resource is locked BEFORE the device is lost and is filled AFTER the device is lost.

- Create Resource

- lock resource

- Lose device

- fill resource

- Reset device

- Draw Resource

Produced image should reflect data written to resource while lost.

Resource tested:

Textures, Vertex Buffers, Index Buffers are tested on MANAGED and SYSTEMMEM pool. ImageSurface are tested on SYSTEMMEM pool.

6. CreateResA, CreateResB, Lose Device, Copy A To B

This test will verify the following: 2 Resources are created and filled before the device is lost and RES A is copied to RES B after the device is lost.

- Create Resource A

- Lock and Fill Res A

- Create Resource B

- Lose device

- Copy Resource A To B

- Reset device

- Draw Resource B

Produced image B should be identical to data from A.

Resource tested:

Textures, Vertex Buffers, Index Buffers are tested on MANAGED and SYSTEMMEM pool. ImageSurface are tested on SYSTEMMEM pool.

7. CreateResA, Lose Device, CreateResB, Copy A To B

This test will verify the following: Resource A is created and filled before the device is lost then the resource B is created and RES A is copied to RES B after the device is lost.

- Create Resource A

- Lock and Fill Res A

- Lose device

- Create Resource B

- Copy Resource A To B

- Reset device

- Draw Resource B

Produced image B should be identical to data from A.

Resource tested:

Textures, Vertex Buffers, Index Buffers are tested on MANAGED and SYSTEMMEM pool. ImageSurface are tested on SYSTEMMEM pool.

8. Lose Device, CreateResA, CreateResB, Copy A To B

This test will verify the following: 2 Resources are created and filled AFTER the device is lost then RES A is copied to RES B after the device is lost.

- Lose device

- Create Resource A

- Lock and Fill Res A

- Create Resource B

- Copy Resource A To B

- Reset device

- Draw Resource B

Produced image B should be identical to data from A.

Resource tested:

Textures, Vertex Buffers, Index Buffers are tested on MANAGED and SYSTEMMEM pool. ImageSurface are tested on SYSTEMMEM pool.

9. Lose, Create, Restore in DEFAULT pool

This test will make sure that the call to create a resource in DEFAULT pool while the device is lost will succeed.

Resource tested:

Textures, Vertex Buffers, Index Buffers, RenderTarget, DepthStencilSurface on DEFAULT pool.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Hardware

No special hardware setup is required for this test.

Required Software

The Windows XP (or later) operating system must be installed, as well as DirectX

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases.


GetInfo() Test Descriptions

The test verifies the EDID structures returned by the monitor and video mini-port are valid.

TD-5.77 IDirect3DDevice7::GetInfo() Test Description

Overview

Data passed to IDirect3DDevice7::GetInfo() and expected return codes:

Id Struct Size HRESULT

X NULL X DDERR_INVALIDOBJECT

X X 0 DDERR_INVALIDOBJECT

I0 DU SU D3D_OK supported/filled

E_FAIL not supported/not filled (expected)

S_FALSE supported/not filled

I1 D1 S1 D3D_OK supported/filled (expected)

E_FAIL not supported/not filled

S_FALSE supported/not filled

I2 D2 S2 D3D_OK supported/filled (expected)

E_FAIL not supported/not filled

S_FALSE supported/not filled

I3 D3 S3 D3D_OK supported/filled (expected)

E_FAIL not supported/not filled

S_FALSE supported/not filled

I4 D4 S4 D3D_OK supported/filled

E_FAIL not supported/not filled (expected)

S_FALSE supported/not filled

IU DU SU D3D_OK supported/filled

E_FAIL not supported/not filled (expected)

S_FALSE supported, not filled

where

I1 = D3DDEVINFOID_TEXTUREMANAGER

I2 = D3DDEVINFOID_D3DTEXTUREMANAGER

I3 = D3DDEVINFOID_TEXTURING

I4 = D3DDEVINFOID_VCACHE

IU = D3DDEVINFOID_UNKNOWN

D1 = D3DDEVINFO_TEXTUREMANAGER

D2 = D3DDEVINFO_D3DTEXTUREMANAGER

D3 = D3DDEVINFO_TEXTURING

D4 = D3DDEVINFO_VCACHE

DU = D3DDEVINFO_UNKNOWN

S1 = sizeof(D3DDEVINFO_TEXTUREMANAGER)

S2 = sizeof(D3DDEVINFO_D3DTEXTUREMANAGER)

S3 = sizeof(D3DDEVINFO_TEXTURING)

S4 = sizeof(D3DDEVINFO_VCACHE)

SU = sizeof(D3DDEVINFO_UNKNOWN)

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows 98/ME, Windows 2000, or Windows XP operating system must be installed, as well as DirectX version 8.1 or higher. If a Direct3D Hal is exposed, IDirect3DDevice7::GetInfo() is required to return compliant information in conjunction with the D3dGetDriverState() driver entry point.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated for failures, which includes any unacceptable returns codes from IDirect3DDevice7::GetInfo().


TD-5.78 IDirect3DDevice8::GetInfo() Test Description

Overview

Data passed to IDirect3DDevice8::GetInfo() and expected return codes:

Id Struct Size HRESULT

X NULL X D3DERR_INVALIDCALL

X X 0 D3DERR_INVALIDCALL

I0 DU SU D3D_OK supported/filled

E_FAIL not supported/not filled (expected)

S_FALSE supported/not filled

I1 D1 S1 D3D_OK supported/filled

E_FAIL not supported/not filled (expected)

S_FALSE supported/not filled

I2 D2 S2 D3D_OK supported/filled

E_FAIL not supported/not filled (expected)

S_FALSE supported/not filled

I3 D3 S3 D3D_OK supported/filled

E_FAIL not supported/not filled (expected)

S_FALSE supported/not filled

I4 D4 S4 D3D_OK supported/filled (preferred)

E_FAIL not supported

S_FALSE supported/not filled (expected)

IU DU SU D3D_OK supported/filled

E_FAIL not supported/not filled (expected)

S_FALSE supported/not filled

where

I1 = D3DDEVINFOID_TEXTUREMANAGER

I2 = D3DDEVINFOID_D3DTEXTUREMANAGER

I3 = D3DDEVINFOID_TEXTURING

I4 = D3DDEVINFOID_VCACHE

IU = D3DDEVINFOID_UNKNOWN

D1 = D3DDEVINFO_TEXTUREMANAGER

D2 = D3DDEVINFO_D3DTEXTUREMANAGER

D3 = D3DDEVINFO_TEXTURING

D4 = D3DDEVINFO_VCACHE

DU = D3DDEVINFO_UNKNOWN

S1 = sizeof(D3DDEVINFO_TEXTUREMANAGER)

S2 = sizeof(D3DDEVINFO_D3DTEXTUREMANAGER)

S3 = sizeof(D3DDEVINFO_TEXTURING)

S4 = sizeof(D3DDEVINFO_VCACHE)

SU = sizeof(D3DDEVINFO_UNKNOWN)

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows 98/ME, Windows 2000, or Windows XP operating system must be installed, as well as DirectX version 8.1 or higher. If a Direct3D Hal is exposed, IDirect3DDevice8::GetInfo() is required to return compliant information in conjunction with the D3dGetDriverState() driver entry point.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated for failures, which includes any unacceptable returns codes from IDirect3DDevice8::GetInfo().


TD-5.79 D3DContextSwitch Test Description

Overview

The test creates two D3D application processes and let them run simultaneously. The two D3D applications uses different RenderStates, TextureStageStates and Textures. When they run the operating system contextswitches between them thus contextswitching on the 3d graphics hardware/driver as well.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

Image conformance with the DirectX Reference rasterizer image percentage is displayed and logged by the test program. 85% conformance is mandated for this test. The image generated by each process is compared against a refrast image in the corresponding process itself. However, the final results logged is a summary of the pass/fail of the two processes combined.


TD-5.80 Vertex Buffer Renaming Test Description

Overview

The Vertex Buffer Renaming Test will attempt to validate Vertex Buffer Renaming is correctly implemented within the driver. Adapters that support dynamic textures are additionally tested while using dynamic textures.

This test creates one dynamic write-only vertex buffer and proceeds to send multiple triangle lists to the adapter. The vertex buffer is written to repeatedly while still in use by the adapter. Should the test receive an invalid pointer from a successive lock on the vertex buffer, the test fails.

Dynamic Textures are tested in the same manner as dynamic vertex buffers.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP, 98/ME, or Windows 2000 operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases, which includes an identification of the object that caused the rendering failure.


TD-5.81 Fill Modes Test Description

This fill mode test runs through all the possible Direct3D fill modes with all the possible primitive types. The way in which primitives are drawn is also cycled (for example, DrawPrimitive, DrawIndexedPrimitive).

Solid – Here the D3DFILL_SOLID render state is set and primitives on each type are rendered.

Wire – Here the D3DFILL_WIREFRAME render state is set and primitives on each type are rendered.

Point – Here the D3DFILL_POINT render state is set and primitives on each type are rendered.

This is a very simple test to check for compliance with all the fill modes in Direct3D

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft® Windows 98/ME, or Windows 2000 operating system must be installed, as well as DirectX® version 6 or higher.

Results

A pass or fail indication of compliance with this requirement is displayed and logged by the test program.


TD-5.82 Invalid Parameter Test

This is preliminary documentation and is subject to change,

Test Kit: HCT 11

Overview

This test verifies driver stability by sending the full range of D3dDrawPrimitives2 (DP2) command tokens to video card drivers. Additionally, this test passes valid and invalid data with the DP2 command tokens it sends. The test attempts to exercise paths of code execution that are not normally covered in a typical Direct3D usage scenario. Unlike other tests, which pay careful attention to the capabilities a device exposes in order to render it with valid data, this test checks driver stability by attempting to tell a device to do things that its capabilities say it cannot do.

Setup

This information is preliminary. For complete procedures for this test in the current DCT, see the DCT Documentation.

Required Hardware

  • A video card with a Direct3D compatible driver.

Required Software

  • Microsoft DirectX 9.0

Results Interpretation

The test writes the test results to a log file (PressureCooker.log) and displays on-screen pass or fail compliance. You can find the log file in the %windir%\dxlogs directory.

The device and driver pass the test if all test cases run to completion without failure or without causing a system stop. Unlike other graphics adapter tests that require that video cards correctly render scenes, this test does not compare the rendered scenes with the reference rasterizer. The only requirement is that the test does not crash the system; therefore, the driver must be able to handle the invalid data. Error codes returned from drivers are currently not tested, although all drivers should return error codes when an error occurs.

If a failure occurs, you can troubleshoot the problem by reviewing the log file and by using the command line options to reproduce specific test cases. To run the test from the command prompt, start the Pressurecooker.exe program. While the test is running, click Help for a complete list of command-line options. Use the options to run the test case where the failure occurred.


TD-5.113 Palettized Textures Test Description

Overview

The palettized textures test (PalAlpha) verifies texturing capabilities with 8-bit and 4-bit palettized textures with alpha and non-alpha palettes. During the loop it circles through following scenarios:

  • Create palettized texture tests
  • Load texture tests
  • Palette recreation test
  • Set entries test
  • Wrap addressing mode test
  • Mirror addressing mode test
  • Clamp addressing mode
  • Border addressing mode
  • Color key test
  • Color key blend test.

To verify texturing capabilities the application renders a full window rectangle over colored background and applies texture to it. The verification algorithm is based on image comparison with image generated by reference device.

Command Line options:

General options | Description
-src:<device> | Choose device to run the test: tnl – to run on hardware T&L device rgb – to run on RGB(MMX) device for PSGP testing ref – to run on Reference device
-ref:<device> | Choose reference device
-palalpha:<n>[-[<n>]] | Run specified range of tests
-debug | Run the test in debug mode

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows XP operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Additional information is generated on failure cases.


TD-5.129 OpenGL Test Description

Overview

The GL Coverage and Utilities Coverage tests are designed to test all API functions within the OpenGL 1.1 library. Specified valid and invalid parameters are passed to these functions to ensure they are handled properly.

The Conformance ECP [x] tests check the functionality of various OpenGL operations to ensure the driver's implementation is valid. This includes Viewport Clamping and Transformations, Matrix Stacks, Vertex Orders, Transforms, Buffer Operations, Color Ramping, Masking, Selection, Feedback, Clipping, Alpha and Stencil Planes, Dithering, Logical Operations, Pixel Operations, Rasterizations, Polygon operations, Lighting, Fog, Texture Mapping, Mipmapping, Display Lists, and Evaluator Vertex Testing.

For more information about each of these features, please check the OpenGL Graphics System: A Specification (Version 1.1). This document can be found on http://www.opengl.org/developers/documentation/specs.html.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

A Test system running Microsoft Windows XP and a display driver with an ICD is required. The graphics adapters must support the following display resolutions: 640x480x16, 640x480x24, and 640x480x32.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Failures may be generated by any of the device setup steps described in the overview section of this test. Any detected failure generates additional information that clearly identifies the non-compliant issue. Each test allows up to 10 failures before a fail is considered.


TD-5.130 Display Windows 9x GDI Test Description

Test Kit: HCT 11, 10

Overview

Display Resolution, Color Depth, and Refresh Rate Test

This test verifies that the graphics adapter hardware supports 800 x 600 pixel resolution, 16 bits per pixel (bpp) color depth, 16-bit Z buffer, double frame buffering, and 75 Hz refresh rate in full-screen 3D graphics mode. Mobile computers are only required to support 640 x 480 pixel resolution.

The test first verifies these requirements in software by querying the DirectDraw capabilities, and then in hardware by selecting the specified settings and displaying a predefined scene as shown in the following steps:

  1. A DirectDraw object is created with the DirectDrawCreate function using the DDCREATE_HARDWAREONLY flag. This action forces a HAL device to be used, instead of a HEL device.
  2. Using the DirectDraw IDirectDraw4: EnumDisplayModes function, the following values in the DDSURFACEDESC2 structure are verified as valid choices:

dwWidth = 800 (dwWidth = 640 for mobile systems)
dwHeight = 600 (dwHeight = 480 for mobile systems)
dwRefreshRate = 75 (or 0 for drivers that do not report this value)

  3. The DDPIXELFORMAT structure verifies that the following are valid choices:

dwRGBBitCount = 16
dwZBufferBitDepth = 16

  4. The SetCooperativeLevel function selects the DDSCL_EXCLUSIVE and DDSCL_FULLSCREEN flags.
  5. SetDisplayMode is called to set the display to 800 x 600 x 16 and 75 Hz refresh rate. If the 75 Hz value fails, a refresh rate value of 0 (default) is used.
  6. CreateSurface is called for the primary surface, the back buffer, and the Z buffer.
  7. The Direct3D CreateDevice function is called using class identifier IID_IDirect3DHALDevice to allow access to the 3D graphics hardware device.
  8. All other 3D graphics tests specified in this chapter employ a double-buffered surface to verify compliance with the double frame buffering requirement.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The SVGA-compatible display monitor attached to the system under test must support the minimum display resolution and refresh rate specified above. Microsoft Windows 98 or Windows 2000 operating system or later must be installed, as well as DirectX version 6 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Failures may be generated by any of the device setup steps described in the overview section of this test. Any detected failure generates additional information that clearly identifies the non-compliant issue.


TD-5.137 Direct Show Test Description

Overview

The Direct Show tests are designed to evaluate the implementation of Direct Show methods critical to video playback. These methods rely heavily on overlay surfaces and the ability to manipulate them. It supports a wide variety of formats, including Advanced Streaming Format (ASF), Motion Picture Experts Group (MPEG), Audio-Video Interleaved (AVI), MPEG Audio Layer-3 (MP3), and WAV files. Direct Show detects and uses hardware video and audio acceleration when available, but runs on systems without this support. This test includes the following cases:

  • Windowless Controls - In windowless mode the VMR creates and configures a DirectDraw clipper object to ensure that the video rectangle is correctly clipped to the application's window and does not appear on any other windows used by other applications. These cases test video sizing, positioning, aspect ratio, video clipping window, repaint, get current image, reflect changes of the display mode, and border coloring. Failures may indicate bad hardware integration
  • Filter Controls - Tests invalidate manipulating with number of streams, rendering preferences (i.e. force off-screen, force overlay, restrict to initial monitor), managing rendering modes (windowed, windowless, or renderless), and installation of application-provided image compositor object
  • Mixer Controls and Mixer Bitmaps - Contains methods that applications use to manipulate the incoming video streams in various ways. It can be used to pass a Windows bitmap or DirectDraw surface that contains a static image that they want to blend with the currently playing video stream. Tests validate alpha blending of video stream and/or video stream and static bitmap including managing alpha-levels for the stream/bitmap, managing Z-order, and rectangles to be mixed. Failures may indicate bad hardware integration and/or bad media format support.
  • Surface Allocations – These cases are designed to validate surface/memory management when a client implements its own Allocator/Presenter object in a renderless mode. Failures may indicate bad memory/resource processing and/or bad media format support.
  • Basic Video Playback – Tests basic playback functions such as average time per frame, bit rate, video size, video palette, getting current image, managing source and destination position/size. Failures may indicate bad hardware integration.
  • Video Windowing – Tests how basic window operations act during playback. This includes window resizing, minimizing, maximizing, owner/child relationships, window message notification, full screen modes, window state, style, playing with cursors etc.
  • Overlay - Intended to provide notification support for any upstream filter that bypasses the renderer's drawing capabilities, but needs notifications of other display properties.
  • Stream Control – Managing streams, i.e. color keys and activation/deactivation.

The mixture of these tests will serve as a stress test for driver functionality.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

A Test system running Microsoft Windows XP as well as DirectX version 8 or higher is required. The graphics adapters must support the minimum display resolution.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Failures may be generated by any of the device setup steps described in the overview section of this test. Any detected failure generates additional information that clearly identifies the non-compliant issue.


TD-5.150 Display Windows 2000 GDI Test Description

Test Kit: HCT 11, HCT 10

Overview

The Display Windows 2000 GDI Test includes the following:

Click to show or hide information. The GDI Alpha Blend Test

The GDI Alpha Blend Stretch Test performs a series of alpha blends on a display surface using both constant alphas of 0, 128, 255 and per-pixel alphas. Since a vendor can perform a stretch independently from another, these blends are compared using an algorithm that will find the associated source pixel for each destination pixel in the image. The blend will be calculated mathematically and will be based on the blend properties of the graphics adapter. For images of the same size, the test will not use the stretching algorithm. It will blend each source pixel with the associated destination pixel. The pixel values will be compared with a tolerance of +/1 on each RGB or ARGB value. The source image will be stretched to the destination image before the blend is performed. The clipping test creates a random clipping region and then performs a blend on that region. This is a test the driver against itself to ensure its regions are exact. This test will run on displays that support 1024x768x16, 24, and 32bpp. The Per Pixel test will only work with 32bpp.

Click to show or hide information. The Check Resolution Test

The Check Resolution test (chndsp) performs two sets of tests to verify the list of supported display modes. These tests are performed once for each display device attached to the system. The first test enumerates all the modes reported by the device driver as being supported. These modes are then switched to in order to verify that they can be successfully selected. The second round of tests exercises the display orientation flags. This test enumerates the modes supported by the display device and filters out modes that only differ in their rotation. For each mode in the list, the test then attempts to switch into the mode using the four possible rotations (0, 90, 180, and 270 degrees). The test compares the success or failure of the mode selection to the initial list of supported modes, and generates failures if there a discrepancy in found between the actual results and the modes that are enumerated.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

A test system with Windows XP or later installed and a graphics card that is capable of displaying/accelerating GDI calls.

Results Interpretation

A pass/fail indication of compliance with the applicable test assertion is displayed and logged by the test program.

For the GDI Alpha Blend Stretch Test, additional information is generated on failure cases, which includes the position of the failed pixel and the display and memory values for that position.

For the Check Resolution Test, additional information is generated on failure cases, which includes mode being selected and the resulting error code. For rotation tests, if a mode selection succeeds but the mode is not listed in the supported modes enumeration, a failure is generated. Similarly, if a supported mode fails to be selected, the test generates a failure.


TD-5.170 Video Rendering Display Test Description

Overview

The DVD Display Tests are designed to evaluate the implementation of DirectDraw methods critical to DVD playback. These methods rely heavily on overlay surfaces and the ability to manipulate them. This includes flipping, shrinking, stretching and reporting the status of these surfaces. The timing of these methods is equally important.

All of these tests are specifically written for Software-based DVD decoders. In the case of a Software based DVD decoder that uses the display card's hardware motion compensation, these tests will not tell us much, if anything, about DVD playback. These tests are specifically for non-hardware motion comp cases. The purpose here is to ensure that there is a method for Software DVD decoding for every graphics card. If the card has a hardware motion comp implementation and it is used in the DVD decoding, then we already know that it works.

It is also important to note that these tests take into consideration a display card that is lacking in Flip capabilities, but it may work fine as a DVD decoder using UpdateOverlay, which is why we have the UpdateOverlayBob Test. Obviously, we would prefer that the display card pass all of the Flip tests, which is the preferable method in Software decoding because it is faster. UpdateOverlay tends to be slow. Some cards can handle both well, but we suggest that the Flip tests are more critical for DVD decoding.

In the case of software bobbing implemented in the DVD decoder, the Flip Bob Interleaved, Flip Bob Non-Interleaved and Switch Flip Bob Weave tests could be disregarded.

If a vendor has a pure software-based DVD decoder solution, then the following tests must pass:

Overlay Scale
Overlay Luminance
Flip Lock Delay
Flip Status
Flip Lock Fill
Flip MultiSurface
Flip

Although these tests were specifically designed for evaluation for the software based DVD decoders, the following tests must pass in case a vendor has a hardware-based DVD implementation:

Flip Bob Non-Interleaved
Flip Bob Interleaved
Switch Flip Bob Weave
Flip Lock Delay
Flip Status
Flip Multi-Surface
Flip
Overlay Scale
Overlay Luminance

Specifically, the Flip and Overlay capabilities are valid concerns for hardware DVD decoders.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

A Video Card must be installed and have a minimum of 4 MB of RAM. The Video Card must also support "YUV Overlays."

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Failures may be generated by any of the device setup steps described in the overview section of this test. Any detected failure generates additional information that clearly identifies the non-compliant issue.

Assertion Table

Assertion

Message

5.170.1

Graphic Adapter drivers must correctly handle overlay horizontal and vertical upscaling and downscaling of YUV surfaces.

5.170.2

Graphic Adapter drivers must present correct luminance on scaled or unscaled overlay surfaces.

5.170.3

Graphic Adapter drivers must correctly implement DirectDraw Flip, Lock and GetFlipStatus functions.

5.170.4

Graphic Adapter drivers must correctly implement Flip, Lock and GetFlipStatus.

5.170.5

Graphic Adapter drivers must be able to correctly flip BOB’d surfaces in random surface order.

5.170.6

Graphic Adapter drivers must perform frame buffer writes with long-term stability

5.170.7

Graphic Adapter drivers must enable Filp-chains to support multiple surfaces

5.170.8

Graphic Adapter drivers must correctly perform interlocking of flipped surfaces.

5.170.9

See 5.170.14

5.170.10

This device does not support DDCAPS2_COPYFOURCC. WMP Video playback relies on the ability of the display driver to perform YUV to YUV Blts. These Blts' must be supported in h/w for all YUV surface types exposed by the driver

AND

The call to blt failed when blitting the FOURCC surface. WMP Video playback relies on the ability of the display driver to perform YUV to YUV Blts. These Blts' must be supported in h/w for all YUV surface types exposed by the driver

5.170.11

Failed: Test did not pass visual verification test

AND

Pointer points to the wrong surface. The pointer returned from CMediaType::GetPoniter was equal to the address of one of the other buffers, indicating flip was not performing as expected

5.170.12

Failed: Failed visual test

AND
Failed: Test must execute in less than 25 milliseconds

5.170.13

Failed: The D3DPTEXTURECAPS_NONPOW2CONDITIONAL flag is set, but the driver created a non-power2 surface

AND

Failed: Failed visual test

5.170.14

Must meet minimum blt performance criteria for YUV surfaces.

Failed unit scale test

AND

Failed downscale-by-2 test

AND

Failed scale-by-2 test

AND

Blt failed

5.171.1

FAILURE: Configuration Failed - This configuration was reported as a failure by the tester. The video and/or subpicture did not display correctly.

AND

FAILURE: No configurations are supported! - None of the minimal required set of configurations is supported by the display driver.

AND

FAILURE: Overall Test Failed! - Either of the above two failures happened during the course of the test run.


TD-5.192 APM/ACPI Display Class Power Test Description

Overview

APMDISP uses the undocumented WM_MONITORPOWER message to initiate User.exe's power management state setting code. This is the same code that is executed when a suspend/resume cycle is initiated. This, in, effect, causes the main VDD to set the display card into D0, D2, or D3. On a transition from any sleep state greater than D0 to D0, the test polls the refresh rate using an IDirectDraw, IDirectDraw4, or IDirectDraw7 interface coupled with GetMonitorFrequency(failing on NT only), GetVerticalBlackStatus, and WaitForVerticalBlanck(). The test then compares its results against each other against a tolerance of 1Hz.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No special hardware setup is required for this test. Microsoft Windows 98/ME or Windows 2000 operating system must be installed, as well as DirectX version 8 or higher.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-5.200 Display PCI D3 Graphics Adapter Functionality, Windows 98 Test Description

Overview

The following PCI-D3 Graphics Adapter Functionality Test Under Windows 98 Second Edition ensures that,

  • Hardware allows the system to successfully go to S3 sleep state.
  • Hardware allows the system to successfully wake from S3 state.
  • Hardware is fully functional on resume from S3 sleep state.

The following tests must be run on a system that correctly supports the S3 sleep state. Windows 98 Second Edition is required to be installed on the system before running these tests. Install the target graphics hardware and associated drivers before starting the following test-sequence.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The following hardware and software setup is required to perform the test.

Required Hardware
  • A desktop platform that supports the ACPI S3-sleep state and passes the WHQL ACPI Compliance tests.
  • A PCI Foxfire II card is required to monitor power-supply status of the PCI bus. When all the LEDs except the 3.3Vaux LED on the card are off, the PCI bus is shown to have lost primary power. In the following test, the LEDs are used to verify that the system goes to a S3 sleep state, which is confirmed by the LEDs being off.
Required Software
  • WHQL Graphics Adapter D3-support test suite.
  • Reference power-managed application (Microsoft Combat Flight Simulator).
  • Microsoft DirectX 6.1.

Results Interpretation

Test Case 1 - System should resume (return to S0 state) and be fully functional.

Test Case 2 - System should resume (return to S0 state) and be fully functional.

Test Case 3 - System should resume (return to S0 state). The application should be fully functional and no video artifacts should be seen.

Test Case 4 - The test should pass.


TD-5.210 Display AGP Interface Test Description

Overview

The purpose of these tests is to assure that AGP hardware can be recognized (enumerated) and configured for optimal performance by the operating system. The AGP interface test ensures that AGP configuration registers, used by the operating system to initialize AGP features, are correctly implemented by both master and target (chipset) device. The test walks the PCI bus starting from the PCI root devnode, looking for an AGP capable chipset. The capabilities for this component are then recorded. The test then walks the devnodes looking for an AGP-capable device. If found, the capabilities of the device and the core chipset are verified.

Setup

Microsoft Windows 98/ME or Windows 2000 operating system must be installed on the test system.

Results Interpretation

A pass/fail indication of compliance with the applicable test assertion is displayed and logged by the test program. Additional information is generated on failure cases, which includes details of all incorrect configuration fields.


TD-5.220 Monitor Tests Description

Test Kit: HCT 11, HCT 10

Note In the HCT kit, this test is called the EDID 1.3 & DDC test.

EDID Version 1 and Version 2

Overview

The test verifies the extended display identification data (EDID) structures returned by the monitor and video mini-port are valid. The EDID data is parsed from the registry, defined into classes, structures, and sub structures, and then member validation functions are called to produce a pass or fail result. A mode list is generated and verified.

EDID Version 1

All fields of the EDID structure should be decodable and usable, according to the respective VESA specification

Auto EDID 1.x Header

Offsets 0x0-0x7h shall equal 0x00FFFFFFFFFFFF00

PASS in log if the correct bytes contain the correct values. If the header bytes do not match this pattern then the EDID structure is passed off to the Version 2 and Version 3 verifiers, respectively. If this fails then the test produces a failure and dump of the EDID data.

Auto EDID 1.x Version Revision

A 1.x capable monitor shall be identified by byte offset 0x12 containing a value of 1. Minor versions are identified by byte 0x13 containing the minor revision. These shall only be valid if the EDID 1.x header is identified.

All version 1 EDIDs are accepted to have a major code of 1, a revision number, and a valid EDID 1 test header. The version byte is found at byte offset 0x12 and the revision # is found at byte offset 0x13.

PASS in log if the correct bytes contain the correct values and an EDID 1.x header was previously identified. Fail if the major value is not equal to 1.

Auto EDID 1.x EDID buffer is at least 128 bytes in length

A 1.x EDID shall be at least 128 bytes in length

PASS in log if the EDID buffer is at least 128 bytes in length. FAIL if the EDID buffer is not at least 128 bytes in length

Auto Version 1 EDID is 1.3 or higher

All version 1 EDID’s shall be 1.3 or higher

PASS in log if the version 1 EDID is at least revision 3. FAIL if the EDID buffer is not at least revision 3.

Auto Version 1 EDID: Vendor/Product Info

Manufacturer ID does not contain any values > 26 except for 31. All version 1 EDIDs shall have compressed ASCII PnP Ids containing the compressed ASCII letters A…Z. This data can be found in byte offsets 0x8 & 0x9.

PASS in log if all values are less than or equal to 26, undecoded. FAIL for each value that is greater than 26.

Manufacturer ID does not contain any zero values. All version 1 EDIDs shall have compressed ASCII PnP Ids containing the compressed ASCII letters A…Z. Since A = 0x1, there can be no zero values. This data can be found in byte offsets 0x8 & 0x9.

PASS in log if all values are not equal to zero, undecoded. FAIL for each value that is zero.

Manufacturer ID Reserved bit is zero. All version 1 EDIDs shall have byte 1 bit 7 (byte offset 0x9) be zero. This is the reserved bit of the Manufacturer ID name.

PASS in log if the bit is zero. FAIL if the bit is one.

Year of Manufacture. All version 1 EDIDs shall specify the year of manufacture using the specified byte coding. The byte offset is 0x11

PASS in log if the decoded value is less than or equal to the current year reported by the OS. Fail if (1) the byte coding is less than 3 or (2) the year is greater than what is reported by the system.

Auto Version 1 EDID: Vendor/Product Info (Optional)

Product code is valid. If a product code is present in the EDID, it contains numbers in hex, LSB first. The product code start at byte offset 0xA.

Pass if the product code is present. Skipped if the product code is not present.

Serial number is valid. The ID Serial number is used to differentiate between individual instances of the same model of monitor. Please see section 3.4, table 3.6 of the E-EDID spec. The byte offset is 0xC.

PASS in log if present. Skipped if not present

Week of Manufacture. All version 1 EDIDs can implement a week of manufacture field in the range of 1-54. If it is not used, it should be set to zero. The byte offset is 0x10

PASS in log if week of manufacture is in the range 0-54. Fail if the week of manufacture is greater than 54. The test is skipped if this value is zero.

Auto Version 1 EDID: Video Input Definition

All version 1 EDIDs should be connected to Analog Inputs. Digital Inputs should be used with EDID 2. It is expected that The byte offset for this is 0x14.

PASS in log if inputs used by monitor are analog. FAIL if the inputs are digital.

Manual Version 1 EDID: Maximum Image Size

All version 1 EDIDs should contain the maximum horizontal and vertical image size unless the display device is a projector. This struct is 2 bytes wide starting at offset 0x15.

PASS in log if these values are zero and the display device is not a projector. FAIL in log if these values are zero and the display device is not a projector.

Auto Version 1 EDID: Display Transfer Characteristic (gamma)

The gamma for the display. If the byte value is 0xFF, then the gamma value is not stored at this location. This byte offset is at location 0x17h.

PASS in log if the decoded gamma transfer is between 1.00 to 3.54. FAIL if the decoded gamma transfer is outside that range. The test is skipped if there is a value of 0xFF at this location.

Auto Version 1 EDID: Common Feature Support: DPMS Support

All displays must be able to be turned on and off through software. The byte offset for this feature is at 0x18h.

PASS in the log if the display device can be switched on and off through software. FAIL in the log if the display device cannot be switched on and off through software.

Auto Version 1.0 – 1.1 EDID: Feature Support: Bits 0 & 2 zero

If the revision of a version 1 EDID is less than 2, bits 0 and 2 must be zero.

PASS in if bits 0 and 2 are zero and the EDID is less than 1.2. FAIL if.bits 0 and 2 are not zero and the EDID is less than 1.2

Auto Version 1 EDID: Color Characteristics (Phosphor or Filter Chromaticity)

If a decoded gamma values Is zero (< .0005), then the EDID writer probably forgot to insert the data. This data comprises the 10 bytes beginning at 0x19 and ending at 0x22.

PASS in log if all values are not zero. FAIL if any value is zero.

Auto Version 1 EDID: Current Mode in either standard, detailed, or established timings.

The current mode should be somewhere in the standard, detailed, or extended timings sections. Each timing section builds up a common timing list. At the end of all this decoding the current mode is searched for in the built-up timing lists. This allows all filtered modes to be validated by using a separate change display settings program. This handles the case of a unused standard timing mode not being set correctly through 0x1, 0x1

PASS in log if the current mode is found somewhere in the general global timing list. FAIL if the current timing mode is not found in the global timing list.

Auto Version 1 EDID: Standard Timing Modes: Horizontal Active Pixel field not zero.

The horizontal active pixel value cannot be zero. This would produce a pixel value of 248, which is less than the minimum of 256.

PASS in the log if the horizontal active pixel value is not zero. Fail if the horizontal active pixel value is zero.

Auto Version 1 EDID: Standard, Detailed, & established timing modes: No duplicate modes (This test is not required but it is recommended)

There can be no duplicate modes from the standard, detailed, or established timing modes. Please see TD-10.19 for how this is accomplished.

PASS in the log if there are no duplicate modes. Fail if there are duplicate modes.

Auto Version 1 EDID: Standard timing modes: All Ids are unique

All standard timing Ids must be unique.

PASS in the log if there are no duplicate Ids. Fail for each duplicate Id.

EDID Version 2

All fields of the EDID structure should be decodable and usable, according to the respective VESA specification

Setup

Performed automatically by test initialization
Required Hardware

EDID capable monitor and video adapter

Required Software

Windows 2000, Windows XP, Windows 98, Windows ME

Results Interpretation

The test validates the EDID structure by breaking down into the structure into Boolean testable units. The test first tells what part of the structure is being verified, tells what the pass and fail criteria are in the log file, and then produces a pass-fail condition. Test assertions are based on characteristics of current monitor technologies.


Chapter 6: Digital and Broadcast Video Test Specification

This chapter specifies testable requirements for PC video capabilities.

Test Coverage

This chapter covers digital video related issues. It is assumed that the reader is somewhat familiar with PC system functional partitioning, common PC graphics capabilities, and consumer electronics video devices such as video recorders, video cameras, and televisions. Familiarity with specific video related PC functionality is helpful but not required.

This document provides definitions of some features, functions, and behaviors specified in Microsoft Windows Logo Program System and Device Requirements. By using these definitions, objective testing methods are defined. Many video-related requirements specified in the design guide are not covered by this document. Compliance with some requirements is extremely difficult to test due to system architecture. Other requirements have a sufficiently high track record of compliance as to make tests for them less important than for items more likely to be a source of problems. Still other requirements are best addressed through statements by vendors when describing system behavior. Many requirements are testable using one or both of the following:

  • A pure software approach in which test software both initiates some system behavior and evaluates the correctness of the behavior.
  • A combination of software and operator evaluation, in which test software initiates some system behavior and the operator provides an indication of correct system behavior.

The first approach is preferred when possible. In the other cases, an effort is made to remove as much of the subjective element from the operator evaluation as possible. Test design plays a crucial role in achieving this portion of our goals.

Test Methodology

The video tests are designed to minimize operator input, remove subjective testing whenever possible and run on standard Windows Logo Program-compliant systems under Windows 98/Me, Windows 2000, or Windows XP.

Operator Input

Several of the tests assume some initial conditions, such as the presence of a particular input signal. These conditions need to be met by the test operator. Other tests have their initial conditions provided entirely by the test installation, such as the presence of a video bitstream. The tests then proceed either with further operator input or without operator input to their conclusion. A typical example of operator input is for the operator to confirm that a particular pattern is present on the system monitor, or a particular audio track is being played by the sound system.

Reduced Subjectivity

In some cases operator interpretation was required in previous tests. For the current tests subjective operator interpretation is not required. For example, assessment of captured and digitized analog video quality is achieved through an algorithmic method and not a subjective quality appraisal method as previously used.

Hardware Requirements

The tests execute on Windows Logo Program-compliant systems. Different tests have different additional hardware requirements such as DVD playback solutions, video capture solutions and so on.

Software Requirements

All video tests can run under Windows XP. Microsoft DirectX extensions are particularly relevant with DirectDraw interface functionality exercised and DirectShow infrastructure used.


Video Test Assertions

This section includes the following groups of assertions derived for Video and Broadcast. Each assertion listed includes an assertion description, a list of reference documents, and references to the "Test Description" section for a description of the corresponding test.

Reference Document Sources for Video Assertions

Functional requirements specified in the following documents:

DVD Specification, V. 1.0

http://www.mpeg.org/MPEG/DVD/

DVD physical format documents

Global Engineering Documents at http://global.ihs.com/

Microsoft Windows Logo Program System and Device Requirements, Version 2.0

http://www.microsoft.com/hwdev/winlogo/
(listed as "WLP#" in these assertions)

Microsoft Windows Driver Development Kit

http://www.microsoft.com/ddk/

PC 2001 System Design Guide and PC 99 System Design Guide

http://www.microsoft.com/hwdev/platform/pcdesign/desguide/pcguides.asp

Microsoft DirectX Software Development Kit

http://www.microsoft.com/windows/directx/


Video Input Format Assertions

Note TD-6.1 Video Input test has been removed from the HCT kit. These assertions are no longer tested.

6.1.1 [DELETED]
6.1.2 [DELETED]
6.1.3 [DELETED]
6.1.4 [DELETED]
6.1.5 [DELETED]


Video Input Data Rate Assertions

Note TD-6.1 Video Input test has been removed from the HCT kit. These assertions are no longer tested.

6.2.1 [DELETED]
6.2.2 [DELETED]
6.2.3 [DELETED]
6.2.4 [DELETED]
6.2.5 [DELETED]
6.2.6 [DELETED]
6.2.7 [DELETED]
6.2.8 [DELETED]


Video Input Disk Data Rate Assertions

Note TD-6.1 Video Input test has been removed from the HCT kit. This assertion is no longer tested.

6.3.1 [DELETED]


Video Input Image Orientation Assertions

Note TD-6.1 Video Input test has been removed from the HCT kit. These assertions are no longer tested.

6.4.1 [DELETED]
6.4.2 [DELETED]
6.4.3 [DELETED]
6.4.4 [DELETED]


Video Input Image Quality Assertions

Note TD-6.1 Video Input test has been removed from the HCT kit. These assertions are no longer tested.

6.5.1 [DELETED]
6.5.2 [DELETED]


Video Copyright Protection Assertions

Note TD-6.6 Video Copyright Protection test has been removed. These assertions are not tested.

6.6.1 [DELETED]
6.6.2 [DELETED]
6.6.3 [DELETED]


Packetized Elementary Stream Routing Assertions

Assertions in this section are tested in TD-6.7 Packetized Elementary Stream (PES) Test.

6.7.1 Ability to route all de-multiplexed MPEG2 stream information using host software.

Reference document: PC 2001 System Design Guide, VID-0217; PC 99 System Design Guide - 15.15.
Test description: TD-6.7 Packetized Elementary Stream (PES) Test


Bus Mastering Assertions

Assertions in this section are tested in TD-6.9 Video Bus Mastering Test.

6.9.1 DVD playback and MPEG 2 decode is DirectShow compliant.

Reference document: WLP# - B11.1.1.3; PC 2001 System Design Guide, VID-0210, VID-0211, VID-0213; PC 99 System Design Guide - 15.27.
Test description: TD-6.9 Video Bus Mastering Test

6.9.2 Use of bus mastering to transfer data stream from DVD.

Reference document: WLP# - B10.1.4.6; PC 2001 System Design Guide, STOR-0341; PC 99 System Design Guide - 15.11.
Test description: TD-6.9 Video Bus Mastering Test

6.9.3 DVD playback does not cause PCI bus contention.

Reference document: WLP# - B4.1.4.11; PC 2001 System Design Guide, VID-0215, PC 99 System Design Guide - 15.12.
Test description: TD-6.9 Video Bus Mastering Test


Video Quality Assertions

Assertions in this section are tested in TD-6.19 Video DVD Playback Tests and TD-6.11 Video DVD Annex Test.

6.10.1 No more than 1 frame is dropped per minute for NTSC and PAL and no more than 1 frame is dropped per minute for progressive video streams.

Reference document: WLP# - B4.1.4.11; PC 2001 System Design Guide, VID-0215.1
Test Description: TD-6.19 Video DVD Playback Tests and TD-6.11 Video DVD Annex Test


CPU Utilization Assertions

Assertions in this section are tested in TD-6.11 Video DVD Annex Test.

6.11.1 MPEG-2 decode of a reference stream may not utilize more than 45% of the CPU.

Complete playback and display, including audio, may not utilize more than 45% of the CPU. Measurements are in addition to observed utilization prior to playback.

Note: This does not apply to mobile systems.

Reference document: WLP# - B4.1.4.11; PC 2001 System Design Guide, VID-0215.6
Test Description: TD-6.11 Video DVD Annex Test


De-interlacing Assertions

Assertions in this section are tested in TD-6.11 Video DVD Annex Test.

6.13.1 Progressive material must be restored by weave de-interlacing without any (de- interlace) artifacts visible.

Reference document: WLP# - B4.1.4.11; PC 2001 System Design Guide, VID-0215.10
Test Description: TD-6.11 Video DVD Annex Test

6.13.2 Interlaced material must be de-interlaced in a manner that is quality equivalent or better than the bob method.

Reference document: WLP# - B4.1.4.11; PC 2001 System Design Guide, VID-0215.12
Test Description: TD-6.11 Video DVD Annex Test


Pull-Down Assertions

Assertions in this section are tested in TD-6.11 Video DVD Annex Test.

6.14.1 MPEG-2 files with progressive 24 fps material are played back as fully restored frames at 24 fps. No frames may be systematically dropped.

Reference document: WLP# - B4.1.4.11; PC 2001 System Design Guide, VID-0215.11
Test Description: TD-6.11 Video DVD Annex Test


Refresh Sync Assertions

Note TD-6.15 Refresh Sync test has been removed. This assertion is not tested.

6.15.1 [DELETED]


Audio/Video Sync Assertions

Note TD-6.16 Audio/Video Sync test has been removed. This assertion is not tested.

6.16.1 [DELETED]


MSWebDVD Test Assertions

Assertions in this section are tested in TD-6.17 Web DVD (MSWebDVD) Test Description.

6.17.1 The standard interface to DVD-style MPEG playback must be used.

Reference document: WLP# - B11.2.5.2
Test Description: TD-6.17 Web DVD (MSWebDVD) Test Description


DirectX VA Decode Assertions

This assertion is tested in TD-6.18 DirectX VA Decode Test.

6.18.1 Decoder must support all of the required minimal DirectX VA configurations.

Reference document: WLP# - B11.1.1.4; PC 2001 System Design Guide, VID-0340
Test Description: TD-6.18 DirectX VA Decode Test Description


Video DVD Annex Assertions

Assertions in this section are tested in TD-6.11 Video DVD Annex Test.

6.19.1 DVD playback and MPEG 2 decode is Mpeg1 Layer2 Audio (AUTO) compliant.

Reference document: WLP# -B11.1.4.2; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.2 DVD playback and MPEG 2 decode is 48kHz PCM Audio (USER) compliant.

Reference document: WLP# -B11.1.4.2; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.3 DVD playback and MPEG 2 decode is 48kHz PCM Audio (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.4 DVD playback and MPEG 2 decode is 96kHz PCM Audio (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.5 DVD playback and MPEG 2 decode is 48kHz PCM Audio (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.6 DVD playback and MPEG 2 decode is AC3 Stereo Audio Track 1 (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.7 DVD playback and MPEG 2 decode is AC3 Stereo Audio Track 1 (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.8 DVD playback and MPEG 2 decode is AC3 Stereo Audio Track 3 (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.9 DVD playback and MPEG 2 decode is AC3 Stereo Audio Track 3 (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.10 DVD playback and MPEG 2 decode is AC3 Stereo Audio Track 5 (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.11 DVD playback and MPEG 2 decode is AC3 Stereo Audio Track 5 (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.12 DVD playback and MPEG 2 decode is AC3 Stereo Audio Track 7 (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.13 DVD playback and MPEG 2 decode is AC3 Stereo Audio Track 7 (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.14 DVD playback and MPEG 2 decode is AC3 Stereo 5.1 Channel (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.15 DVD playback and MPEG 2 decode is AC3 Stereo 5.1 Channel (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.16 DVD playback and MPEG 2 decode is AC3 Stereo DialNorm (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.17 DVD playback and MPEG 2 decode is AC3 Stereo DialNorm (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.18 DVD playback and MPEG 2 decode is DRC Activated Stream (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.19 DVD playback and MPEG 2 decode is DRC Activated Stream (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.20 DVD playback and MPEG 2 decode is DRC Deactivated Stream (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.21 DVD playback and MPEG 2 decode is DRC Deactivated Stream (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.22 DVD playback and MPEG 2 decode is Volume/Audio Control (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.23 DVD playback and MPEG 2 decode is Volume/Audio Control (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.24 DVD playback and MPEG 2 decode is Volume/Audio Control (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.25 DVD playback and MPEG 2 decode is Volume/Audio Control (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.26 DVD playback and MPEG 2 decode is Volume/Audio Control (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.27 DVD playback and MPEG 2 decode is Blue Transparency: 100% (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.28 DVD playback and MPEG 2 decode is Blue Transparency: 100% (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.29 DVD playback and MPEG 2 decode is Blue Transparency: 20% (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.30 DVD playback and MPEG 2 decode is Blue Transparency: 20% (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.31 DVD playback and MPEG 2 decode is Blue Transparency: 40% (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.32 DVD playback and MPEG 2 decode is Blue Transparency: 40% (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.33 DVD playback and MPEG 2 decode is Blue Transparency: 60% (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.34 DVD playback and MPEG 2 decode is Blue Transparency: 60% (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.35 DVD playback and MPEG 2 decode is Blue Transparency: 80% (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.36 DVD playback and MPEG 2 decode is Blue Transparency: 80% (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.37 DVD playback and MPEG 2 decode is Green Transparency: 100% (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.38 DVD playback and MPEG 2 decode is Green Transparency: 100% (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.39 DVD playback and MPEG 2 decode is Green Transparency: 20% (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.40 DVD playback and MPEG 2 decode is Green Transparency: 20% (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.41 DVD playback and MPEG 2 decode is Green Transparency: 40% (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.42 DVD playback and MPEG 2 decode is Green Transparency: 40% (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.43 DVD playback and MPEG 2 decode is Green Transparency: 60% (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.44 DVD playback and MPEG 2 decode is Green Transparency: 60% (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.45 DVD playback and MPEG 2 decode is Green Transparency: 80% (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.46 DVD playback and MPEG 2 decode is Green Transparency: 80% (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.47 DVD playback and MPEG 2 decode is Red Transparency: 100% (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.48 DVD playback and MPEG 2 decode is Red Transparency: 100% (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.49 DVD playback and MPEG 2 decode is Red Transparency: 20% (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.50 DVD playback and MPEG 2 decode is Red Transparency: 20% (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.51 DVD playback and MPEG 2 decode is Red Transparency: 40% (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.52 DVD playback and MPEG 2 decode is Red Transparency: 40% (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.53 DVD playback and MPEG 2 decode is Red Transparency: 60% (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.54 DVD playback and MPEG 2 decode is Red Transparency: 60% (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.55 DVD playback and MPEG 2 decode is Red Transparency: 80% (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.56 DVD playback and MPEG 2 decode is Red Transparency: 80% (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.57 DVD playback and MPEG 2 decode is Index 1 Selection Colors (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.58 DVD playback and MPEG 2 decode is Index 1 Selection Colors (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.59 DVD playback and MPEG 2 decode is Index 1 Action Colors (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.60 DVD playback and MPEG 2 decode is Index 1 Action Colors (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.61 DVD playback and MPEG 2 decode is Index 2 Selection Colors (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.62 DVD playback and MPEG 2 decode is Index 2 Selection Colors (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.63 DVD playback and MPEG 2 decode is Index 2 Action Colors (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.64 DVD playback and MPEG 2 decode is Index 2 Action Colors (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.65 DVD playback and MPEG 2 decode is Index 3 Selection Colors (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.66 DVD playback and MPEG 2 decode is Index 3 Selection Colors (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.67 DVD playback and MPEG 2 decode is Index 3 Action Colors (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.68 DVD playback and MPEG 2 decode is Index 3 Action Colors (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.69 DVD playback and MPEG 2 decode is Custom Index 1 Selection Colors (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.70 DVD playback and MPEG 2 decode is Custom Index 1 Selection Colors (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.71 DVD playback and MPEG 2 decode is Custom Index 1 Action Colors (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.72 DVD playback and MPEG 2 decode is Custom Index 1 Action Colors (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.73 DVD playback and MPEG 2 decode is Custom Index 2 Selection Colors (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.74 DVD playback and MPEG 2 decode is Custom Index 2 Selection Colors (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.75 DVD playback and MPEG 2 decode is Custom Index 2 Action Colors (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.76 DVD playback and MPEG 2 decode is Custom Index 2 Action Colors (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.77 DVD playback and MPEG 2 decode is Custom Index 3 Selection Colors (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.78 DVD playback and MPEG 2 decode is Custom Index 3 Selection Colors (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.79 DVD playback and MPEG 2 decode is Custom Index 3 Action Colors (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.80 DVD playback and MPEG 2 decode is Custom Index 3 Action Colors (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.81 DVD playback and MPEG 2 decode is Seamless Multi-Angle #1 (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.82 DVD playback and MPEG 2 decode is Seamless Multi-Angle #1 (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.83 DVD playback and MPEG 2 decode is Seamless Multi-Angle #2 (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.84 DVD playback and MPEG 2 decode is Seamless Multi-Angle #2 (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.85 DVD playback and MPEG 2 decode is Seamless Multi-Angle #3 (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.86 DVD playback and MPEG 2 decode is Seamless Multi-Angle #3 (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.87 DVD playback and MPEG 2 decode is Seamless Multi-Angle #4 (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.88 DVD playback and MPEG 2 decode is Seamless Multi-Angle #4 (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.89 DVD playback and MPEG 2 decode is Non-Seamless Multi-Angle #1 (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.90 DVD playback and MPEG 2 decode is Non-Seamless Multi-Angle #1 (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.91 DVD playback and MPEG 2 decode is Non-Seamless Multi-Angle #2 (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.92 DVD playback and MPEG 2 decode is Non-Seamless Multi-Angle #2 (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.93 DVD playback and MPEG 2 decode is Non-Seamless Multi-Angle #3 (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.94 DVD playback and MPEG 2 decode is Non-Seamless Multi-Angle #3 (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.95 DVD playback and MPEG 2 decode is Non-Seamless Multi-Angle #4 (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.96 DVD playback and MPEG 2 decode is Non-Seamless Multi-Angle #4 (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.97 DVD playback and MPEG 2 decode is Menu That Ends (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.98 DVD playback and MPEG 2 decode is Menu That Ends (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.99 DVD playback and MPEG 2 decode is Menu That Loops Long (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.100 DVD playback and MPEG 2 decode is Menu That Loops Long (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.101 DVD playback and MPEG 2 decode is Menu That Loops Short (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.102 DVD playback and MPEG 2 decode is Menu That Loops Short (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.103 DVD playback and MPEG 2 decode is Field/Frame Freeze - Bob (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.104 DVD playback and MPEG 2 decode is Field/Frame Freeze - Bob (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.105 DVD playback and MPEG 2 decode is Field/Frame Freeze - Weave (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.106 DVD playback and MPEG 2 decode is Field/Frame Freeze - Weave (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.107 DVD playback and MPEG 2 decode is 16x9 Menu (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.108 DVD playback and MPEG 2 decode is 16x9 Menu (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.113 DVD playback and MPEG 2 decode is Elapsed Time/Chapter - First Play (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.114 DVD playback and MPEG 2 decode is Elapsed Time/Chapter - Chapter Menu (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.116 DVD playback and MPEG 2 decode is Elapsed Time/Chapter - Chapter Menu (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.117 DVD playback and MPEG 2 decode is Elapsed Time/Chapter - Chapter Menu (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.119 DVD playback and MPEG 2 decode is Elapsed Time/Chapter - Resume Play (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.120 DVD playback and MPEG 2 decode is Elapsed Time/Chapter - Resume Play (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.123 DVD playback and MPEG 2 decode is Excessive Cropping: 352x240 (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.124 DVD playback and MPEG 2 decode is Excessive Cropping: 352x240 (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.126 DVD playback and MPEG 2 decode is Excessive Cropping: 720x480 (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.127 DVD playback and MPEG 2 decode is Excessive Cropping: 720x480 (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.129 DVD playback and MPEG 2 decode is Excessive Cropping: 704x480 (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.130 DVD playback and MPEG 2 decode is Excessive Cropping: 704x480 (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.132 DVD playback and MPEG 2 decode is Excessive Cropping: 352x480 (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.133 DVD playback and MPEG 2 decode is Excessive Cropping: 352x480 (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.137 DVD playback and MPEG 2 decode is Forced Letterbox - Window (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.138 DVD playback and MPEG 2 decode is Forced Letterbox - Window (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.143 DVD playback and MPEG 2 decode is Forced Letterbox - Full Screen (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.144 DVD playback and MPEG 2 decode is Forced Letterbox - Full Screen (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.147 DVD playback and MPEG 2 decode is Film - Basic (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.148 DVD playback and MPEG 2 decode is Film - Basic (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.149 DVD playback and MPEG 2 decode is Film - Alternate (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.150 DVD playback and MPEG 2 decode is Film - Alternate (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.151 DVD playback and MPEG 2 decode is Video (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.152 DVD playback and MPEG 2 decode is Video (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.153 DVD playback and MPEG 2 decode is Variations: Speed (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.154 DVD playback and MPEG 2 decode is Variations: Speed (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.155 DVD playback and MPEG 2 decode is Discontinuity: Basic X (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.156 DVD playback and MPEG 2 decode is Discontinuity: Basic X (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.157 DVD playback and MPEG 2 decode is Discontinuity: Alternate Y (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.158 DVD playback and MPEG 2 decode is Discontinuity: Alternate Y (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.159 DVD playback and MPEG 2 decode is Mixed Mode: Basic Y (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.160 DVD playback and MPEG 2 decode is Mixed Mode: Basic Y (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.161 DVD playback and MPEG 2 decode is Mixed Mode: Alternate X (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.162 DVD playback and MPEG 2 decode is Mixed Mode: Alternate X (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.163 DVD playback and MPEG 2 decode is Chapter Break: Alternate 1 (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.164 DVD playback and MPEG 2 decode is Chapter Break: Alternate 1 (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.165 DVD playback and MPEG 2 decode is High Bit Rate: 4mB - 60 Hz Video (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.166 DVD playback and MPEG 2 decode is High Bit Rate: 4mB - 60 Hz Video (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.167 DVD playback and MPEG 2 decode is High Bit Rate: 4mB - X Parade (60) (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.168 DVD playback and MPEG 2 decode is High Bit Rate: 4mB - X Parade (60) (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.169 DVD playback and MPEG 2 decode is High Bit Rate: 6mB - Title Roll (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.170 DVD playback and MPEG 2 decode is High Bit Rate: 6mB - Title Roll (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.171 DVD playback and MPEG 2 decode is High Bit Rate: 6mB - Clock 24 fps (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.172 DVD playback and MPEG 2 decode is High Bit Rate: 6mB - Clock 24 fps (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.173 DVD playback and MPEG 2 decode is High Bit Rate: 7.95mB - Clock - 60Hz (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.174 DVD playback and MPEG 2 decode is High Bit Rate: 7.95mB - Clock - 60Hz (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.175 DVD playback and MPEG 2 decode is High Bit Rate: 7.95mB - 24 fps Film (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.176 DVD playback and MPEG 2 decode is High Bit Rate: 7.95mB - 24 fps Film (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.177 DVD playback and MPEG 2 decode is High Bit Rate: Highest - 60 Hz Video (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.178 DVD playback and MPEG 2 decode is High Bit Rate: Highest - 60 Hz Video (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.179 DVD playback and MPEG 2 decode is High Bit Rate: Highest - 24 fps Film (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.180 DVD playback and MPEG 2 decode is High Bit Rate: Highest - 24 fps Film (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.181 DVD playback and MPEG 2 decode is Low Bit Rate: Clock - 60Hz (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.182 DVD playback and MPEG 2 decode is Low Bit Rate: Clock - 60Hz (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.183 DVD playback and MPEG 2 decode is Low Bit Rate: Jazz Montage (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.184 DVD playback and MPEG 2 decode is Low Bit Rate: Jazz Montage (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.185 DVD playback and MPEG 2 decode is Cycling Bit Rate (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.186 DVD playback and MPEG 2 decode is Cycling Bit Rate (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.187 DVD playback and MPEG 2 decode is V-Bench (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.188 DVD playback and MPEG 2 decode is V-Bench (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.189 DVD playback and MPEG 2 decode is Half-Horizontal: X Parade (60) (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.190 DVD playback and MPEG 2 decode is Half-Horizontal: X Parade (60) (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.191 DVD playback and MPEG 2 decode is Half-Horizontal: 24 fps Film (USER) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test

6.19.192 DVD playback and MPEG 2 decode is Half-Horizontal: 24 fps Film (AUTO) compliant.

Reference document: WLP# -B11.2.2.1; PC 2001 System Design Guide, VID-0219
Test description: TD-6.11 Video DVD Annex Test


Video DVD Playback Assertions

Assertions in this section are tested in TD-6.19 Video DVD Playback Tests.

6.20.193 DVD playback and MPEG 2 decode is Closed Captioning (USER) compliant

Reference document: WLP# - B11.1.4.2; PC 2001 System Design Guide, VID-0219
Test description: TD-6.19 Video DVD Playback Tests

6.20.194 DVD playback and MPEG 2 decode is Closed Captioning (AUTO) compliant

Reference document: WLP# -B11.1.4.2; PC 2001 System Design Guide, VID-0219
Test description: TD-6.19 Video DVD Playback Tests


Video Exclusive Mode Playback Test Assertions

Assertions in this section are tested in TD-6.21 Video Exclusive Mode Playback Test Description.

6.21.1 The standard interface to DVD-style MPEG playback must able to use exclusive full-screen mode.

Reference document: WLP# - B11.2.5.2
Test Description: TD-6.21 Video Exclusive Mode Playback Test Description


DVD Configuration Validation Test Assertions

Assertions in this section are tested in TD-6.22 DVD Configuration Validation Test Description.

6.22.1 The standard interface to DVD-style MPEG playback must able to use DirectDraw, DirectShow, and DirectSound capabilities.

Reference document: WLP# - B11.1.4.1, B11.2.4.3, B11.2.5.2
Test Description: TD-6.22 DVD Configuration Validation Test Description


Audio or Video Capture and Control Assertions

Assertions in this section are tested in TD-6.23 Audio or Video Capture and Control Test.

6.23.1 The device must support basic WDM DirectShow graph building.

Reference document: WLP# - B11.1.1.1; PC 2001 System Design Guide, VID-0210.
Test description: TD-6.23 Audio or Video Capture and Control Test

6.23.2 All filters used must provide the same input and output formats as those provided by the operating system.

Reference document: WLP# - B11.1.1.3; PC 2001 System Design Guide, VID-0213.
Test description: TD-6.23 Audio or Video Capture and Control Test

6.23.3 Audio uses WDM drivers and is compatible with DirectShow.

Reference document: WLP# - B3.1.1.1; B3.1.4.10; PC 2001 System Design Guide, AUD-0326, AUD-0323.
Test description: TD-6.23 Audio or Video Capture and Control Test

6.23.4 Video display quality and frame rate must meet the minimum specifications.

Reference document: WLP# - B11.1.4.4; PC 2001 System Design Guide, VID-0215.
Test description: TD-6.23 Audio or Video Capture and Control Test

6.23.5 Video and TV tuner implementations must be DirectShow compatible.

Reference document: WLP# - B11.1.1.2; PC 2001 System Design Guide, VID-0211.
Test description: TD-6.23 Audio or Video Capture and Control Test

6.23.6 All NTSC/PAL/SECAM capture devices must provide unfiltered VBI data without data loss from video operations.

Reference document: WLP# - B11.4.4.2; PC 2001 System Design Guide, VID-0224.
Test description: TD-6.23 Audio or Video Capture and Control Test

6.23.7 Devices and drivers must function after ACPI power state changes.

Reference document: WLP# - B1.2.2; A1.4.2
Test description: TD-6.23 Audio or Video Capture and Control Test

6.23.8 Devices and drivers must support required ACPI power states.

Reference document: WLP# - B1.4.5; PC 2001 System Design Guide, SYS-0002.
Test description: TD-6.23 Audio or Video Capture and Control Test

6.23.9 Streaming video capture devices that support still image capture must be compatible with Windows Image Acquisition (WIA).

Reference document: WLP# - B9.1.1.1; PC 2001 System Design Guide, IMAG-0318.
Test description: TD-6.23 Audio or Video Capture and Control Test


AV/C Tape Subunit Compliance Assertions

Assertions in this section are tested in TD-6.24 AV/C Tape Subunit Compliance Test.

6.24.1 The IEEE digital media device should enumerate on Windows XP.

Reference document: WLP# - B2.2.1.4; See the IEEE 1394 Technology white paper titled "IEEE 1394 and the Windows Platform" at http://www.microsoft.com/hwdev/bus/1394/1394tech.asp.
Test description: TD-6.24 AV/C Tape Subunit Compliance Test

6.24.2 The digital media device correctly implements IEEE 1394-1995 and 1394a standards.

Reference document: WLP# - B2.2.2.4; PC 2001 System Design Guide, 1394-0094 and 1394-0100.
Test description: TD-6.24 AV/C Tape Subunit Compliance Test

6.24.3 The device must support basic WDM DirectShow graph building.

Reference document: WLP# - B11.1.1.1; PC 2001 System Design Guide, VID-0210.
Test description: TD-6.24 AV/C Tape Subunit Compliance Test

6.24.4 The MPEG decoder must support DirectShow APIs.

Reference document: WLP# - B11.1.1.1; PC 2001 System Design Guide, VID-0210.
Test description: TD-6.24 AV/C Tape Subunit Compliance Test

6.24.5 The driver for any video or tuner/decoder device must use the latest DirectShow API to control audio/video data.

Reference document: WLP# - B11.1.1.1; PC 2001 System Design Guide, VID-0210.
Test description: TD-6.24 AV/C Tape Subunit Compliance Test

6.24.6 All filters used must provide the same input and output formats as those provided by the operating system.

Reference document: WLP# - B11.1.1.3; PC 2001 System Design Guide, VID-0213.
Test description: TD-6.24 AV/C Tape Subunit Compliance Test

6.24.7 The digital video media device must be in VCR mode to run WHQL tests.

Reference document: WLP# - B11.2.3.1.
Test description: TD-6.24 AV/C Tape Subunit Compliance Test

6.24.8 DV camcorders must support the IAMExtDevice DirectShow API to get device capabilities and perform standard functions.

Reference document: WLP# - B11.4.1.2; see the white paper titled "Digital Video Camcorder Support in Windows" at http://www.microsoft.com/hwdev/vidcap/DVCam.htm.
Test description: TD-6.24 AV/C Tape Subunit Compliance Test

6.24.9 DV camcorders must support the IAMExtTransport DirectShow API to get device capabilities and perform standard functions.

Reference document: WLP# - B11.4.1.2; see the white paper titled "Digital Video Camcorder Support in Windows" at http://www.microsoft.com/hwdev/vidcap/DVCam.htm.
Test description: TD-6.24 AV/C Tape Subunit Compliance Test

6.24.10 DV camcorders must support the IAMTimeCodeReader DirectShow API to get device capabilities and perform standard functions.

Reference document: WLP# - B11.4.1.2; see the white paper titled "Digital Video Camcorder Support in Windows" at http://www.microsoft.com/hwdev/vidcap/DVCam.htm.
Test description: TD-6.24 AV/C Tape Subunit Compliance Test

6.24.11 The AV/C VCR Subunit Specification commands must function according to specification.

Reference document: WLP# - B11.4.2.2 ; See the 1394 Trade Association specifications at http://www.1394TA.org.
Test description: TD-6.24 AV/C Tape Subunit Compliance Test

6.24.12 Mandatory VCR subunit commands must be supported.

Reference document: WLP# - B11.4.4.9.
Test description: TD-6.24 AV/C Tape Subunit Compliance Test


DVD ViewGraph Test Assertions

Assertions in this section are tested in TD-6.25 DVD ViewGraph Test.

6.25.1 The DVD playback application must use the DirectShow API.

This is a manual test to verify that installed DVD playback applications use the DirectShow API as required in the reference document.

Reference document: WLP# - B11.1.1.3.
Test description: TD-6.25 DVD ViewGraph Test


Video Test Descriptions

This section describes the Video and Broadcast tests. Test descriptions include a description of each test with set up requirements and results interpretations.

The capture tests provide hardware testing for compliance with PC 2001 System Design Guide, "Baseline Video Driver Support" (VID-0215). These items together define a system capability that supports high (consumer electronics) quality video capture.


TD-6.1 Video Input Test

Note This test has been removed from the HCT kit.


TD-6.6 Video Copyright Protection Test

Note This test has been removed from the HCT kit.


TD-6.7 Packetized Elementary Stream (PES) Test

Test Kit: HCT 11, HCT 10

Overview

The PES Support test verifies that the decoder can handle raw elementary MPEG-2 streams.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires a standard system with a DVD drive installed.

Results Interpretation

The test determines compliance with the assertions. Review test log file, Pestest.log.


TD-6.9 Video Bus Mastering Test

Test Kit: HCT 11, HCT 10

Overview

The purpose of this test is to verify that streaming video for DVD playback does not use the CPU to copy video frames between buffers but uses bus mastering. This test does not apply to DVD playback solutions that do not use PCI bus based decoding hardware.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test must be run in a graphics mode of at least 16 bits/pixel and 800x600 resolution or better.

The test measures the CPU utilization before a MPEG2 stream is played back and during the playback of a MPEG2 stream. The test is passed if the CPU utilization difference is less than or equal to 15%.

The test builds its own playback graph bypassing any player software that may be present on the system. To be able to do this, the system and the decoder must be DirectShow 6.0 compliant.

Results Interpretation

1. DVD playback and MPEG 2 decode is DirectShow compliant.

The test fails immediately if the playback solution is not DirectShow compliant.

2. Use of bus mastering to transfer data stream from DVD.

The test uses CPU utilization measurements during and after DVD playback to assess whether the system uses too much CPU during playback.

The test verifies that DVD playback does not cause PCI bus contention.

3. This portion of the test has not been implemented.

The test proceeds as follows:

  1. Test prompts operator to turn off DVD playback if active.
  2. Test computes the CPU utilization.
  3. Test starts DVD playback.
  4. Test computes CPU utilization difference and terminates.

Note: PC 2001 System Design Guide specifies a minimum number of buffers that a driver and a bus master should utilize. This test does not directly verify this implementation detail. It is unlikely that the test can be passed if the larger number of buffers defined in PC 2001 System Design Guide is not used.


TD-6.11 Video DVD Annex Test

Test Kit: HCT 11, HCT 10

Overview

The purpose of this test is to ensure that any MPEG-2 decoder implementation is efficient enough to allow the system to perform other useful work while a standard video stream is being decoded and played back.

For design requirements originally defined in PC 99, there already exists a similar requirement and test that exempts software solutions but measures the CPU utilization of hardware MPEG-2 decode implementations. That test was not supplied with a reference. This new test uses the same measurement mechanism as the PC 99-related version (a pure software approach) but the test applies to all types of decoder implementations (HW, SW, and hybrid), uses a new pass/fail threshold, and works with a supplied MPEG-2 reference file. As is the case for the PC 99-related test, the analysis takes into consideration CPU utilization before playback as the background load on top of which the playback load is analyzed. A statistical analysis is performed that averages out system load measurements.

The CPU requirement does not apply to mobile systems.

De-interlacing

Both materials that were originally captured in an interlaced manner or in a progressive manner are often decoded as a time/space interlaced stream and must be properly de-interlaced before display. The design guide requires that progressive material be de-interlaced using the weave method which recovers all video information perfectly (assuming the interlacing was done properly) and that interlaced material be de-interlaced using the bob method or a better method. Using bob for progressive material and weave for interlaced material is not permitted.

The test requires a supplied MPEG-2 reference file. The file is played back and the user is asked to compare it to reference images with and without de-interlacing artifacts. Operator feedback indicating that the displayed file looks as good or better than the reference image determines compliance.

Pull-Down

When video streams are originally captured using film at 24 frames per second, the original frame information can in many cases be restored by using a "pull down" algorithm on the video stream presented in an interlaced manner. The pull-down algorithm weave de-interlaces the frames, eliminates repeated frames, and restores the frame rate back to 24 fps.

The test plays back an included MPEG-2 file that contains material that exacerbates incorrectly reconstructed film frames. The operator is queried whether objects moving in the video frame move smoothly. The pass/fail verdict is based on the operator feedback. A test that uses the DVI test device to assess proper pull down is under investigation.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a standard system with at least one DVD drive installed.

Results Interpretation

The Video DVD Annex test provides pass or fail results on the assertions and additional diagnostic information.


TD-6.15 Refresh Sync Test

Note This test has been removed from the HCT kit.


TD-6.16 Audio/Video Sync Test

Note This test has been removed from the HCT kit.


TD-6.17 Web DVD (MSWebDVD) Test Description

Test Kit: HCT 11, HCT 10

Overview

The MSWebDVD test tests the basic DVD playback actions (fast forwarding, rewinding, navigating through menus and chapters, and etc.) It also tests other MSWebDVD specific functionalities (zooming and frame stepping). Currently, this test is hard coded to run on the DVD Test Annex.

First it goes through an audio sequence test section, verifies that a user can hear audio from the disc at different tracks and frequencies. Next it tests sub-picture display, with various transparencies and colors (red/green/blue) and verifies that the user sees what the tools assumes is being shown. It also includes several cropping tests (at different resolutions) and a full screen one. There are also some angle tests, which ensure that the user can see a single view of the playback, from several angles with API calls to MSWebDVD control. MSWebDVD provides the ability to frame step, any given number of frames, and this tool exercises a decoder's ability to allow frame stepping (jump a few frames ahead or backwards) any given number of times in a row.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a supplied MPEG-2 file. The system must have MPEG-2 decoding capabilities in either hardware, software, or as a hybrid. The system must be running Windows XP.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-6.18 DirectX VA Decode Test Description

Test Kit: HCT 11, HCT 10

Overview

The DX VA Decoder test verifies that the target MPEG2 decoder supports DirectX Video Acceleration (DXVA). It verifies that all 7 members of the video minimal configuration set are supported. Each configuration will be visually verified. The test will also verify that each subpicture/alpha blending configuration is also supported. Additionally, other configurations (like off-host variable length decoding) are verified if present.

This test builds a graph including the decoder and the Overlay Mixer or the Video Mixing Renderer. The test driver is configured to accept each configuration, one at a time. It is expected that the decoder will accept each connection attempt and that playback is correct for each configuration.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a supplied MPEG-2 file. The system must have MPEG-2 decoding capabilities in either hardware, software, or as a hybrid.

Results Interpretation

Any required configurations that are rejected are considered failures. Any configurations where playback is not accurate are also failures. Finally, any additional modes which the decoder supports but which do not exhibit accurate playback are considered failures.


TD-6.19 Video DVD Playback Tests

Test Kit: HCT 11, HCT 10

Overview

The DVD Playback Tests includes the following tests:

  • Video DVD Lost In Space
  • Video DVD Janet Jackson: Velvet Rope

The motivation of this portion of the tests is to ensure that systems can process and decode video streams with typical resolutions and frame rates without unnecessary quality degradation. This should hold true for all types of video sources; however, the test focuses on MPEG-2 streams and uses custom MPEG-2 files to make compliance determinations.

The test assesses the following video stream attributes:

  • Frame rate delivery.
  • Dropped frames.
  • Pixel corruption.
  • Image detail.
  • Color accuracy.

Video DVD Lost In Space Test

This test verifies that Closed Captioning is properly displayed.

This test first verifies that playback, menu navigation, and the consequent button selection from that menu succeed, and that it can be visually verified by a tester. Next, comes time play, written to ensure that one can skip around in a title a given number of times without any problems. It also contains fast forwarding, fast rewinding and restart play back tests. It has a couple of audio and subpicture tests. This tool has something the other WHQL tests do not, a Closed Captioning test to ensure support for the Line21 Decoder Interface

Video DVD Janet Jackson: Velvet Rope Test

The purpose of these tests is to verify that basic DVD playback actions like fast forwarding, rewinding, navigating through menus and chapters, and time play for PAL video format.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

These tests require a standard system with a DVD drive installed and the following DVDs.

  • Lost In Space
  • Janet Jackson: Velvet Rope (Region 2, PAL)

Results Interpretation

The test determines compliance with the assertions. Review the log files: Dvdlost.log or Dvdvelvet.log.


TD-6.21 Video Exclusive Mode Playback Test Description

Test Kit: HCT 10

Overview

The Video Exclusive Mode Playback Test contains a testing sequence to determine if a DirectShow graph can be built, and to play back video in DirectDraw exclusive full-screen mode. These capabilities enable game developers and interactive content developers to create content in full-screen mode and still play back video within it; for example, to play a movie in a certain room within a game.

This table contains the list of Exclusive Mode Playback test cases and descriptions. Test cases with files do not use DVD APIs.

Test Cases | Description
DVD playback | Create IDvdGraphBuilder. Build DVD graph. Start playback in exclusive full-screen mode.
Play an .avi file | Create IGraphBuilder. Build DVD graph by calling RenderFile on the .avi file. Start playback in exclusive full-screen mode.
Play an MPEG-1 file | Create IGraphBuilder. Build DVD graph by calling RenderFile on the .MPEG-1 file. Start playback in exclusive full-screen mode.
Play an MPEG-2 file (PES support in exclusive mode) | Create IGraphBuilder. Build DVD graph by calling RenderFile on the .MPEG-2 file. Start playback in exclusive full-screen mode.
Change color key color | Change color key color, and repeat the above three tests.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires a standard system with a DVD drive installed.

Results Interpretation

The test determines compliance with the assertions. Playing MPEG-2 files in exclusive mode will fail if the PES test has failed.


TD-6.22 DVD Configuration Validation Test Description

Test Kit: HCT 11, HCT 10

Overview

The DVD Configuration Validation Test verifies the DirectDraw, DirectShow, and DirectSound capabilities of the system configuration.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires a standard system with a DVD drive installed.

Results Interpretation

The test determines compliance with the assertions. Review test log files.


TD-6.23 Audio or Video Capture and Control Test

Test Kit: HCT 11

Overview

The Audio or Video Capture and Control test verifies that audio or video capture devices (including but not limited to DV camcorders, TV Tuners, and 1394 or USB video conferencing cameras and microphones) support Windows Driver Model (WDM) Stream Class and DirectShow filter graph functionality. Individual test cases verify preview, capture, and playback of audio/video obtained from the capture device. The test also validates correct adherence to power management functionality while the device is streaming, and verifies the ability of the device to function during display resolution changes.

This test uses the Microsoft® DirectShow® application programming interface (API) to manipulate a capture filter in many different ways, verifying return values and settings while applying stress on the system capture architecture. The Audio or Video Capture and Control test reviews the performance of the audio or video capture device during the capture or preview process.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; or Windows .NET Server 2003, Enterprise Edition.

Results Interpretation

The test determines compliance with the assertions. Review the log file Blink.log.


TD-6.24 AV/C Tape Subunit Compliance Test

Test Kit: HCT 11

Overview

The AV/C Tape Subunit Compliance test verifies that an audio/video control (AV/C) tape subunit meets the data transfer specifications established by the 1394 Trade Association in the AV/C Tape Recorder/Player Subunit Specification, and complies with the Microsoft 1394 video capture stack architecture.

The AV/C devices stream isochronous data over the IEEE 1394 bus using the IEC-61883 protocol, a standard communications and control interface used by IEEE 1394 audio/video devices. These devices include digital video (DV) camcorders, MPEG recorders, and D-VHS recorders. An AV/C device can contain multiple subunits, such as tape or storage for still images.

Internally, the AV/C Tape Subunit Compliance test uses Microsoft® DirectShow®. It calls various DirectShow APIs to build and control DirectShow filter graphs, and to control the AV/C subunits.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; or Windows .NET Server 2003, Enterprise Edition.

The AV/C Tape Subunit Compliance test consists of three files. The test program (MSTapeTst.exe) and two test profiles. The file Dvdevice.pro is the test profile for DV camcorders; the file Mpeg2device.pro is the test profile for 1394 MPEG devices. The test may write other files while it is testing your device. You can delete those temporary files after testing is complete.

Results Interpretation

The test determines compliance with the assertions. Review the log file MSTapeTst.log.


TD-6.25 DVD ViewGraph Test

Test Kit: HCT 11

Overview

This test verifies the compatibility of the DVD playback application with the DirectShow API. While the DVD playback application is running, the test examines the running object table and displays the DirectShow filter graph (if any) that the application builds. The test then prompts you to confirm that the DirectShow filters required for DVD playback are present.

Overview of Test Steps

The test examines the running object table (ROT) for a running DirectShow filter graph.

You first start the DVD playback application and begin the DVD playback. The test then examines the running object table (ROT) to find an instance of a DirectShow filter graph. Using the GraphEdit application (a DirectX SDK tool), the test displays the DirectShow filters used for playback. To pass the test, you must confirm that a video renderer, an audio renderer, and a DVD Navigator source filter are present in the filter graph.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; or Windows .NET Server 2003, Enterprise Edition.

Results Interpretation

The test writes the results to a log file (Graphplay.log) and displays on-screen pass or fail status.


Chapter 7: Video Telephony Test Specification

Note: This chapter is obsolete and will not be tested

This chapter describes modem compliance requirements and test tools that validate support for H.324 video telephony. Only new modem device requirements related to video telephony are covered. These requirements are specified in Microsoft Windows Logo Program System and Device Requirements.

This specification also describes the individual tests that verify the requirements for video telephony, under "Video Telephony Test Descriptions" later in this chapter.

Test Coverage

Microsoft Windows Logo Program System and Device Requirements includes many requirements for modem devices. Several of these requirements are specific for supporting H.324 video telephony capabilities. These include:

  • V.250 AT command set support
  • V.80 synchronous access mode
  • V.8 bis (or V.8’) call control signaling

The test assertions detailed in this test specification are based on these video telephony requirements. Supporting information was derived from the Intel Videophone-ready Modem Handbook, Revision 1.1, the TIA-602 specification, and ITU-T Recommendations V.8, V.8 bis, V.80, V.250, and V.251.

Test Methodology

The modem device test described in this document is designed to run on all IA-32 processor based platforms. Two complete systems, each equipped with a modem, are required to execute the test. One system functions as a Server, the other as a Client. The Client modem is considered the Device Under Test (DUT).

A standard GSTN phone line connection or commercially available telephone line simulator (TLS) must be used to connect the two modems. A TLS is preferred over the use of real lines. If real lines are used, they should be of high quality, such as internal PBX lines, and not standard residential (voice-grade) lines with unknown characteristics. The purpose of using high-quality telephone lines is to maximize control over the transmission medium. While real-world line testing is valuable for analyzing modem performance, the purpose of these tests is to verify that a modem contains the required functionality.

Figure 7-1 Hardware Configuration

Figure 7-1. Hardware Configuration

In addition, a "null" modem cable or network connection must exist between the Server and Client systems. The null modem cable must be attached to an external serial communications port on each platform. If a network connection is used, a network hub is required to connect the two systems.

To conduct the tests, a control application is first launched on the Server system. This application monitors the communication ports and provides test sequencing control. The Client test software is then launched which first tests the local capabilities of the modem DUT and then proceeds to the connectivity tests using the Server.


Video Telephony Assertions

The following is a list of modem device assertions to implement H.324 video telephony capability. The video telephony test software tests these assertions. A description of each test is found in the "Test Descriptions" section.

Reference Document Sources for Video Telephony Assertions

Functional requirements specified in the following documents:

Microsoft Windows Logo Program System and Device Requirements, Version 2.0

http://www.microsoft.com/hwdev/winlogo/
(listed as "WLP#" in these assertions)

Microsoft Windows Driver Development Kit

http://www.microsoft.com/ddk/

PC 2001 System Design Guide and PC 99 System Design Guide

http://www.microsoft.com/hwdev/platform/pcdesign/desguide/pcguides.asp

Videophone-Ready Modem Handbook, Section 4

http://developer.intel.com/ial/vidred/index.htm


V.250 AT Command Set Assertions

7.1.1 Modems that support H.324 video telephony capabilities must return the following string when V.250 AT command +GMM is issued.

Reference document: WLP# - B6.1.4.2; PC 2001 System Design Guide - MOD-0368,
PC 99 System Design Guide - 19.3;Videophone-Ready Modem Handbook, Section 4.
Test description: TD-7.1 Video Telephony Local Modem Capability (Test Case #1)

7.1.2 Modem must support V.250 AT commands: +GMI, +GMM, +GMR, +IPR, +IFC, +ILRR, +MS, +MR, +ES, +ER, +DS, and +DR.

Reference document: WLP# - B6.1.4.2; PC 2001 System Design Guide - MOD-0368,
PC 99 System Design Guide - 19.3.
Test description: TD-7.7 Video Telephony V.250 (Test Case #7)

7.1.3 Modem may optionally support V.250 AT commands: +ICF, +MA, +EB, +ESR, +GCI, and +ETBM.

Reference documents: WLP# - B6.1.4.2; PC 2001 System Design Guide - MOD-0368,
PC 99 System Design Guide -19.3.
Test description: TD-7.7 Video Telephony V.250 (Test Case #7)


V.80 Synchronous Access Assertions

7.2.1 Data modem must support V.80 Synchronous Access data protocols.

Reference documents: WLP# - B6.1.4.2; PC 2001 System Design Guide - MOD-0369,
PC 99 System Design Guide - 19.6.
Test descriptions: TD-7.1 Video Telephony Local Modem Capability (Test Case #1) and TD-7.6 Video Telephony V.80 Data Integrity (Test Case #6)


Call Control Signaling Assertions

7.3.1 Modem must support V.8 operation that is controlled by Data Circuit Terminating Equipment (DCE) with Data Terminal Equipment (DTE) notification.

Reference documents: WLP# - B6.1.4.2; PC 2001 System Design Guide - MOD-0370,
PC 99 System Design Guide - 19.7.
Test descriptions: TD-7.2 Video Telephony TVCF/DCF CI Generation (Test Case #2)
TD-7.3 Video Telephony TVCF/DCF CI Detection (Test Case #3),
TD-7.4 Video Telephony VCF CI Origination (Test Case #4), and
TD-7.5 Video Telephony VCF CI Detection (Test Case #5)

7.3.2 Modem must provide a means for turning on the V.8 Calling Indicator (CI) signal for originating calls.

Reference documents: WLP# - B6.1.4.2; PC 2001 System Design Guide - MOD-0370,
PC 99 System Design Guide - 19.7.
Test descriptions: TD-7.2 Video Telephony TVCF/DCF CI Generation (Test Case #2)
TD-7.3 Video Telephony TVCF/DCF CI Detection (Test Case #3),
TD-7.4 Video Telephony VCF CI Origination (Test Case #4), and
TD-7.5 Video Telephony VCF CI Detection (Test Case #5)


Video Telephony Assertions Not Tested

The V.80 Data Integrity Test only verifies basic V.80 functionality (as it applies to data transfer and shielding). Much of the V.80 functionality and V.25ter Annex A command set is not verified.

Note: Assertions defined as "Not Tested" under the provisions of this specification may be subject to testing through alternative test facilities.


Video Telephony Test Descriptions

This section describes the video telephony device tests. The descriptions include an overview of each test, hardware and software setup, test algorithms/steps, and test results interpretation.

The purpose of the following tests is to verify the modem capability for H.324 connectivity.

For H.324 connectivity, the modem requires support for,

  • Standard V.80 interface
  • H.324 Calling Indicator (CI = 21)
  • Standard V.80 encoding and decoding

The standard V.80 interface is a local implementation and is tested by querying the modem with "AT" commands (V.25ter). This is verified by test case #1, Local Modem Capability test.

Once the local capability is tested, the modem is tested for the H.324 Calling Indicator (CI=21). This requires an actual connection to be made by connecting to the server system. The CI is tested in both directions and verified for different call models, such as DCF, TVCF, and VCF. Test cases #2 through #5 are defined for these tests.

The V.80 interface and CI tests qualify a modem for H.324 connection. However, the actual data transmitted after the connection is made must also be tested, since this is when the V.80 encoder and decoder are exercised. This test is conducted by actually making a H.324 connection, described in test case #6.

The V.250 Test verifies that the modem supports and implements the required V.250 AT commands. It also checks the optional V.250 commands. If any of these are supported, they are checked for proper implementation.

Video Telephony Test Flow and DTMF Control

The Local Modem Capability (Test case #1) determines if the modem DUT supports voice capabilities. If so, an additional set of test cases are executed that validate the VCF call model. The following figure illustrates the test execution flow.

Figure 7-2 Test Execution Flowchart

Figure 7-2. Test Execution Flowchart

The H.324 connectivity tests (test cases #2 through #5) require more than one CI generation. This means that the modem must go to the off-hook state after each test. This can be done using the V.80 command <EM><EOT>. However, not all modems respond to this command correctly; some modems may hang up the connection during this command rather than going off-hook. This means that the next test would require another call to the Server.

The problem with another call to the Server is that the Server has to discriminate between the calls to know whether to start from Test Case #2 or from a different test. To solve this problem, DTMF tones are used to control the test. After connecting to the Server, the Client sends a DTMF tone specifying the test to conduct. This way the Server can conduct the test as directed by the Client and the Client can make as many calls as required to complete the test.

The following table shows the DTMF tone and Test Case # relationship.

Table 7-1. DTMF Tones and Corresponding Test Cases

DTMF tone | Test Case | Description
0 | --- | Reserved
1 | --- | Reserved
2 | #2 | TVCF/DCF CI Generation Test
3 | #3 | TVCF/DCF CI Detection Test
4 | #4 | VCF CI Origination Test
5 | #5 | VCF CI Detection Test
6 | #6 | V.80 Data Integrity Test
7 | --- | Reserved
8 | --- | Reserved
9 | N/A | Instruct server app to terminate
* | --- | Reserved
# | --- | Reserved

The following sections describe these test cases in detail.


TD-7.1 Video Telephony Local Modem Capability (Test Case #1)

The test for local capability is to make sure the modem has a V.80 interface. This is tested using the AT commands defined in the V.25ter extension for V.80. The following commands are used to test for V.80 capability.

Table 7-2. Command List For V.80 & CI Modes

No. | AT Command | Purpose
1 | AT+ES=6,,8 | V.80 mode,…..
2 | AT+ESA=,0 | Frame Synchronous submode…..
3 | AT+A8E=6,,21 | CI setting

If there is more than one modem present on the client system, all modems are enumerated and tested for V.80 and CI locally. The list of all modems and their capabilities is returned as a result.

As a part of the local capability test, the modem is tested for dial tone and voice capability. If the dial tone is not available, the user is informed (returned as a part of the result code). No further tests are conducted in this case.

The voice capability information is used in the connectivity tests. If the modem is voice capable, the connectivity tests are also conducted in VCF mode. According to video telephony call models, if the modem is voice capable, the call models are DCF and VCF. In the case of data/fax modems, the call models are DCF and TVCF.

ASSUMPTION: Since the modem behavior of DCF and TVCF are the same, the test treats these two call models in the same way. This assumption is made based on the fact that the sequence of events, in both DCF and TVCF call models, are the same. The following event diagram shows the call sequence in both the cases.

Figure 7-3 DCF/TVCF Call Sequence

Figure 7-3. DCF/TVCF Call Sequence

This assumption cannot be made for the VCF call model because the modem is put in a different state for voice mode operation. For this reason, the connectivity tests for DCF, TVCF, and VCF are divided into two sets of test cases, one for TVCF/DCF and the other for VCF.

Therefore, the test cases for H.324 connectivity are organized as follows:

  • TVCF/DCF

Test case #2: CI generation

Test case #3: CI detection

  • VCF

Test case #4: CI origination

Test case #5: CI detection

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The modem DUT and Client test software, and the Microsoft Windows 98/Me or Windows 2000 operating system must be installed on the Client system.

Results Interpretation

A pass/fail indication of compliance with the applicable test assertion is displayed and logged by the test program. Additional information is generated on failure cases, which includes all AT commands issued to the modem and all response strings returned by the modem.


TD-7.2 Video Telephony TVCF/DCF CI Generation (Test Case #2)

In this test, the Client system makes a call to the server using the TVCF/DCF call model defined earlier and tests CI generation. The Server detects the CI and accepts the data call. The Client modem will be in data mode, whereas the Server modem can be in either voice or data mode. In this test case, the Server modem is placed in voice mode.

The following figure shows the event sequences on Client and Server machines:

** |  | Server
Dial number for server Interactive voice – Data (no data call yet == ATDT<#>;) | < - > | "RING" Accept Incoming Call as a voice call
Send DTMF tone 2 |  | Sets test case #2
Put Modem in V.80 mode Put modem for CI detection CI=21 | - > | Put Modem in V.80 mode Put modem for CI generation CI=21
Switch to H.324 Mode (Sends CI) | - > < - | Detect CI Answer in H.324 Mode (CFO = 21)
Put Modem to Off-hook <EM><EOT> |  | Put Modem back to voice
Return Test Status |  | Return Test Status

Figure 7-4. TVCF/DCF CI Generation Test Event Sequence

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The modem DUT and Client test software must be installed on the Client system. An H.324-compliant modem and Server test software must be installed on the Server system. Microsoft Windows 98/Me or Windows 2000 operating system must be installed on both systems.

Results Interpretation

A pass/fail indication of compliance with the applicable test assertions is displayed and logged by the test program. Additional information is generated on failure cases, which includes all AT commands issued to the modem DUT, all response strings returned by the modem, and all control data sent/received with the Server modem.


TD-7.3 Video Telephony TVCF/DCF CI Detection (Test Case #3)

At the end of test case #2, the client and server attempt to put the modems into an off-hook state by sending the <EM><EOT> command to the modem. A well-behaved modem goes back to the off-hook state, but some may hang up the connection. In this case, the call is reinitiated to continue the tests. After the connection is made, as described in the previous test, the Client sends DTMF tone #3 to indicate test case #3.

In this test, the Client makes a call to the Server using the TVCF/DCF call model defined earlier and tests CI detection. The Server originates the CI. The following figure shows the event sequences on Client and Server machines:

Client |  | Server
Dial number for server Interactive voice – Data (no data call yet == ATDT<#>;) | < - > | "RING" Accept Incoming Call as a voice call
Send DTMF tone 3 | - > | Sets test case #3
Put Modem in V.80 mode Put modem for CI Generation CI=21 |  | Put Modem in V.80 mode Put modem for CI detection CI=21
Detect CI Answer in H.324 Mode (CFO = 21) | - > < - | Switch to H.324 Mode (Sends CI)
Put Modem to Off-hook <EM><EOT> or Keep the modem connected for Test #5 |  | Put Modem back to Voice or Keep the modem connected for Test #5 if no <EOT> is received from client
Return Test Status |  | Return Test Status

Figure 7-5. TVCF/DCF CI Detection Test Event Sequence

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The modem DUT and Client test software must be installed on the Client system. An H.324-compliant modem and Server test software must be installed on the Server system. The Microsoft Windows 98 or Windows 2000 operating system must be installed on both systems.

Results Interpretation

A pass/fail indication of compliance with the applicable test assertions is displayed and logged by the test program. Additional information is generated on failure cases, which includes all AT commands issued to the modem DUT, all response strings returned by the modem, and all control data sent/received with the Server modem.


TD-7.4 Video Telephony VCF CI Origination (Test Case #4)

Once the local modem capabilities are verified by test case #1, the voice capability of the modem is known. If the Client modem is voice capable, the VCF call model is tested. The purpose of test cases # 4 and #5 is to test CI origination and detection for the VCF model. The difference between these and the TVCF/DCF test cases is that the Client modem is put into voice mode, (rather than just off-hook) before starting the H.324 connection.

In test case #4, the Client makes a voice call to the server using the VCF call model and tests CI origination. The Server is configured to detect the CI.

The following figure shows the event sequences on Client and Server machines:

Client |  | Server
Dial number for server Voice call Speakerphone Mode (?) | < - > | "RING" Accept Incoming Call as a voice call
Send DTMF tone 4 | - > | Sets test case #4
Put Modem in V.80 mode Put modem for CI Generation CI=21 |  | Put Modem in V.80 mode Put modem for CI detection CI=21
Switch to H.324 Mode (Sends CI) | - > < - | Detect CI Answer in H.324 Mode (CFO = 21)
Put Modem back to Voice |  | Put Modem back to Voice
Return Test Status |  | Return Test Status

Figure 7-6. VCF CI Origination Test Event Sequence

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The modem DUT and Client test software must be installed on the Client system. An H.324-compliant modem and Server test software must be installed on the Server system. The Microsoft Windows 98/Me or Windows 2000 operating system must be installed on both systems.

Results Interpretation

A pass/fail indication of compliance with the applicable test assertions is displayed and logged by the test program. Additional information is generated on failure cases, which includes all AT commands issued to the modem DUT, all response strings returned by the modem, and all control data sent/received with the Server modem.


TD-7.5 Video Telephony VCF CI Detection (Test Case #5)

As discussed in the case of the DCF/TVCF call models, putting the modem back to the voice call may result in hanging up the call. In this case, another voice call is made to the Server before testing the modem for CI detection.

In test case #5, the Client makes a voice call to the Server using the VCF call model and tests CI detection. The Server originates the CI.

The following figure shows the event sequences on Client and Server machines:

Client |  | Server
Dial number for server Voice call Speakerphone Mode (?) | < - > | "RING" Accept Incoming Call as a voice call
Send DTMF tone 5 | - > | Sets the test state #5
Put Modem in V.80 mode Put modem for CI detection CI=21 |  | Put Modem in V.80 mode Put modem for CI Origination CI=21
Detect CI Answer in H.324 Mode (CFO = 21) | - > < - | Switch to H.324 Mode (Sends CI)
Keep the modem connected for Test #6 |  | Keep the modem connected for Test #6
Return Test Status |  | Return Test Status

Figure 7-7. VCF CI Detection Test Event Sequence

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The modem DUT and Client test software must be installed on the Client system. An H.324-compliant modem and Server test software must be installed on the Server system and the Microsoft Windows 98/Me or Windows 2000 operating system must be installed on both systems.

Results Interpretation

A pass/fail indication of compliance with the applicable test assertions is displayed and logged by the test program. Additional information is generated on failure cases, which includes all AT commands issued to the modem DUT, all response strings returned by the modem, and all control data sent/received with the Server modem.


TD-7.6 Video Telephony V.80 Data Integrity (Test Case #6)

Test cases #1 through #5 are intended to test the modem connectivity. To complete the test, you need to test V.80 data integrity. For this, you need to send and receive data over the V.80 modem driver to exercise V.80 data encoding and decoding. This test is done by actually making a H.324 connection. The H.245 PDUs for Term Caps and the Master-Slave determination are sent across this connection. The Logical channels for Audio and Video are opened, and various data transfers are performed. If the Client modem is capable of making an H.324 connection and transferring the defined data, it is considered capable of H.324 video telephony.

The Call setup and H.324 call connection with channel opening sequence is shown in the following figure:

Figure 7-8 H.324 Call Setup Sequence

Figure 7-8. H.324 Call Setup Sequence

During the H.324 session, data is transferred in full-duplex, V.80 Synchronous Access Mode. Packets of data are transferred using varied packet sizes and packet counts. The following tests are defined:

  • Initiate and receive V.80 calls, which use 128-byte data packets and 22 different data patterns.
  • Initiate V.80 calls, which use 1-byte "control" packets.
  • Initiate V.80 calls, which use 21-byte "audio only" packets.

Data patterns used in each transfer vary from "AA" and "55" to actual V.80 modem command strings. The use of V.80 command strings verifies the modem’s ability to interpret shielded data for transmission and to shield command indicators when receiving data.

When packets are received, the contents are checked for any errors in the transmission. A Pass/Fail criteria is based on the ratio of packet errors to the total number of packets transferred. Passing criteria is defined to be an error ratio less than 0.01 for both the server’s received data and the client’s received data. This value has been determined based on extensive historical validation data. Typically, ratio values of 0.001 or less are expected.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The modem DUT and Client test software must be installed on the Client system. An H.324-compliant modem and Server test software must be installed on the Server system, and the Microsoft Windows 98/Me or Windows 2000 operating system must be installed on both systems.

Results Interpretation

A pass/fail indication of compliance with the applicable test assertions is displayed and logged by the test program. Additional information is generated on failure cases, which includes all AT commands issued to the modem DUT, all response strings returned by the modem, and all control data sent/received with the Server modem.


TD-7.7 Video Telephony V.250 (Test Case #7)

The following table specifies lists the required commands and the validation that is conducted by the test.

V.250 Command | Significance | Test Spec
+GMI | Manufacturer Identification | Output not greater than 2048 characters. It should not contain "0 ?CR?" (3/0, 0/13) or "OK?CR?" (4/15, 4/11, 0/13).
+GMM | Model Identification | Output not greater than 2048 characters. It should not contain "0 ?CR?" (3/0, 0/13) or "OK?CR?" (4/15, 4/11, 0/13).
+GMR | Revision Identification | Output not greater than 2048 characters. It should not contain "0 ?CR?" (3/0, 0/13) or "OK?CR?" (4/15, 4/11, 0/13).
+IPR and +ILRR | Fix DTE Rate | Fix the speed to 57600, do a connect and verify negotiated speed is equal to locked speed Using AT+ILRR=1.
+IFC | Fix Flow Control from DTE to DCE and from DCE to DTE | Send default value of 2,2 and see if the response from the modem is OK.
+MS and +MR=1 | Modulation Setting | Set Modulation to V34 (AT+MS=v34,1,0,0) Set AT+MR=1 and connect. Check if connection was established with V34 modulation setting.
+ES and +ER | Error Control Setting and Error Control Reporting | Set ErrorControl on and check if the connection is made with ErrorControl on. Set ErrorControl off and check if the connection is made with ErrorControl off. In both case set +ER=1.
+DS and +DR | Data Compression and Data Compression Reporting | Set DataCompression on and check if the connection is made with DataCompression on. Set DataCompression off and check if the connection is made with DataCompression off. In both case set +DR=1.

In addition, the following optional commands are validated if the function is controllable in the modem by way of an AT command.

V.250 Command | Significance | Test Spec
+ICF | DTE-DCE character framing | Send +ICF=? and check if response contains range of valid values as defined in the V.250 spec.
+MA | Modulation Automode Control | Send +MA=? and check if the returned response has valid information about carrier protocols. Compare with the known list of protocols.
+EB | Break Handling in Error Control Operation | Send +EB=? and check if response contains range of valid values as defined in the V.250 spec.
+ESR | Selective Repeat | Send +ESR=? and check if response contains range of valid values as defined in the V.250 spec.
+ETBM | Call Termination Buffer Management | Set to default recommended in the V.250 spec and check if there is no ERROR response. Check +ETBM = ? and check if response contains range of valid values as defined in the V.250 spec.
+GCI | Country Information | Output contains valid country code as defined in T.35/Annex A Country Codes.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The modem DUT and test software must be installed on the system along with the Microsoft Windows 98 or Windows 2000 operating system.

Results Interpretation

A pass/fail indication of compliance with the applicable test assertion is displayed and logged by the test program. Additional information is generated on failure cases, which includes all AT commands issued to the modem DUT and all response strings returned by the modem.


Chapter 8: AGP Test Specification

This chapter details compliance requirements and test tools for Accelerated Graphics Port (AGP) implementations in graphics display subsystems. The compliance requirements are defined in Microsoft Windows Logo Program System and Device Requirements.

This test specification also describes individual tests used to verify the requirements for AGP, under "AGP Test Descriptions" found later in this chapter.

Test Coverage

Microsoft Windows Logo Program System and Device Requirements refers to several requirements for AGP implementations defined in the following PC 2001 System Design Guide sections:

  • GRPH-0163 Primary graphics adapter uses AGP or another high-speed connection.

AGP requirements are defined in the Accelerated Graphics Port Interface Specification, Revision 2.0 or later. Specific AGP requirements are as follows:

Discrete graphics solutions require the equivalent of AGP 2X or better.

Integrated graphics solutions require the equivalent of AGP 1X or better.

  • GRPH-0393.2 Mobile PC system uses PCI or better interconnect.

Mobile systems that support 3-D must support Graphics Address Remapping Table (GART) at a minimum.

Supporting information for this specification was derived from the Accelerated Graphics Port Interface Specification, Revision 2.0.

PC 99 System Design Guide describes several requirements for AGP implementations:

  • Chapter 6, "Mobile PC 99," Mobile PC Graphics Requirements.
  • Chapter 14, "Graphics Adapters," PC 99 Design for Graphics Adapters.

The test assertions detailed in this test specification are based on these AGP requirements. Also, supporting information for this specification was derived from the Accelerated Graphics Port Interface Specification, Revision 1.0.

Test Methodology

The purpose of these tests is to assure that AGP hardware can be recognized (enumerated) and configured for optimal performance by the operating system.

  • AGP 2.0 interface test – This test ensures that AGP configuration registers, used by the operating system to initialize AGP features, are correctly implemented by both the master and target (chipset) device. The test walks the PCI bus starting from the PCI root devnode, looking for an AGP capable chipset. The capabilities for this component are then recorded. The test then walks the dev nodes looking for an AGP-capable device. If found, the capabilities of the device and the core chipset are verified.
  • AGP Graphics Address Relocation Table Test – This test verifies that non-local video memory can be allocated and used directly for AGP operations. Support for a GART and Write Combining (WC) Memory (for processors that provide WC) is confirmed. Un-cached memory mapping of the Graphics Aperture is verified for processors which do not support WC. Integrity of the GART allocation/alignment and allocation/free is confirmed.
  • AGP 2.0 transfer mode test – The transfer mode test involves moving a known bit pattern through AGP system memory into local video memory. The test then checks for data corruption by comparing the results of the transfer with the known bit pattern.


AGP Test Assertions

The following is a list of AGP assertions. The AGP test software verifies compliance with these assertions.


Reference Document Sources for AGP Assertions

Hardware and BIOS functional requirements specified in the following documents:

  • Accelerated Graphics Port Interface Specification, Revision 2.0
    http://developer.intel.com
  • PC 2001 System Design Guide and PC 99 System Design Guide,
    http://www.microsoft.com/hwdev/platform/pcdesign/desguide/pcguides.asp
  • PCI Bus Power Management Interface Specification, Revision 1.1 (PCI-PM)
    http://www.pcisig.com/specifications
  • PCI Local Bus Specification, Revision 2.2 (PCI 2.2)
    http://www.pcisig.com/specifications
  • Microsoft Windows Driver Development Kit
    http://www.microsoft.com/ddk/
    See "AGP Support" in the Windows XP DDK
  • Microsoft Windows Logo Program System and Device Requirements, Version 2.0
    http://www.microsoft.com/hwdev/winlogo/
    (listed as "WLP#" in these assertions)


AGP PCI Bus Assertions

The following PCI bus compliance assertions are described in Chapter 4, "PCI Test Specification:
Test Assertions 4.1.1 - 4.5.7
TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)"

8.1.1 AGP implementations must comply with the PCI Bus Power Management Interface Specification, Revision 1.0 or later.

Reference documents: WLP# B4.1.4.9; PC 99 System Design Guide - 14.51; PCI Bus Power Management Interface Specification, Revision 1.0.
Test descriptions: Test assertions 4.1.1 - 4.5.7; TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

8.1.2 AGP implementations must include a PCI 2.1-compliant Subsystem ID and Subsystem Vendor ID.

Reference documents: WLP# B4.1.4.9; PC 99 System Design Guide - 14.51; PCI Local Bus Specification, Revision 2.1.
Test descriptions: Test assertions 4.2.1 - 4.2.4; TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

8.1.3 AGP implementations must comply with the PCI Bus Power Management Interface Specification, Revision 1.1.

Reference documents: PC 2001 System Design Guide - PCI-0130; PCI Bus Power Management Interface Specification, Revision 1.1
Test descriptions: Test assertions 4.1.1 - 4.5.7; TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)

8.1.4 AGP implementations must include a PCI 2.2-compliant Subsystem ID and Subsystem Vendor ID.

Reference documents: PC 2001 System Design Guide - PCI-0126; PCI Local Bus Specification, Revision 2.2.
Test descriptions: Test assertions 4.2.1 - 4.2.4; TD-4.1 PCI Power Management (PM) Register Interface Test (PCICAP)


AGP Interface Assertions

The following AGP interface compliance assertions are tested with TD-8.1 Accelerated Graphics Port (AGP) Interface Test Description.

8.2.1 All AGP implementations must provide a PCI 2.1-compliant capability pointer that contains an offset to a working AGP capability structure.

Reference documents: WLP# - B4.1.4.9; PC 2001 System Design Guide - GRPH-0163; PC 99 System Design Guide - 14.51; Accelerated Graphics Port Interface Specification, Sections 6.1.4 through 6.1.9.
Test description: TD-8.1 Accelerated Graphics Port (AGP) Interface Test Description

8.2.2 All AGP compliant devices must correctly report a revision number of at least 1.0 in the Capability Identifier Register.

Reference documents: WLP# B4.1.4.9; PC 2001 System Design Guide - GRPH-0163; PC 99 System Design Guide - 14.51; Accelerated Graphics Port Interface Specification, Sections 6.1.7.
Test description: TD-8.1 Accelerated Graphics Port (AGP) Interface Test Description

8.2.3 All AGP capability structures must contain a read-only status register and a read/write command register.

All fields of the command register must be read/write.

Reference documents: WLP# - B4.1.4.9; PC 2001 System Design Guide - GRPH-0163; PC 99 System Design Guide - 14.51; Accelerated Graphics Port Interface Specification, Sections 6.1.7 through 6.1.8.
Test description: TD-8.1 Accelerated Graphics Port (AGP) Interface Test Description

8.2.4 All AGP compliant devices must correctly report and be capable of managing a command request queue that contains at least one 32-bit command (Minimum request-queue depth of 1 DWORD).

This means the RQ_DEPTH fields must have a value of zero or greater.

Reference documents: WLP# - B4.1.4.9; PC 2001 System Design Guide - GRPH-0163; PC 99 System Design Guide - 14.51; Accelerated Graphics Port Interface Specification, Section 6.1.8.
Test description: TD-8.1 Accelerated Graphics Port (AGP) Interface Test Description

8.2.5 All AGP compliant devices must support the AGP_ENABLE command bit.

Reference documents: WLP# - B4.1.4.9; PC 2001 System Design Guide - GRPH-0163; PC 99 System Design Guide - 14.51; Accelerated Graphics Port Interface Specification, Section 6.1.9.
Test description: TD-8.1 Accelerated Graphics Port (AGP) Interface Test Description

8.2.6 All AGP compliant devices implemented on desktop PCs must correctly report at least AGP 2X capability.

AGP compliant devices implemented on Mobile PC platforms must correctly report at least AGP 1X capability.

Reference documents: WLP# - B4.1.4.9; PC 2001 System Design Guide - GRPH-0163; PC 99 System Design Guide - 14.51 and 6.23; Accelerated Graphics Port Interface Specification, Section 6.1.8.
Test description: TD-8.1 Accelerated Graphics Port (AGP) Interface Test Description

8.2.7 All AGP compliant systems are required to provide a minimum Graphics Aperture size setting of 64MB (recommended).

Reference documents: WLP# - B4.1.4.9; PC 2001 System Design Guide - GRPH-0163; PC 99 System Design Guide - 14.51.
Test description: TD-8.1 Accelerated Graphics Port (AGP) Interface Test Description

8.2.8 All AGP devices support a valid AGP 2.0 capability structure.

Reference documents: WLP# - B4.1.4.9; PC 2001 System Design Guide - GRPH-0163; AGP Interface Specification, Revision 2.0, Sections 6.1.5 through 6.1.10; PC 2001 System Design Guide - GRPH-0163.
Test description: TD-8.1 Accelerated Graphics Port (AGP) Interface Test Description

8.2.9 All AGP compliant devices implemented on desktop PCs must correctly report a revision number of at least 2.0 in the Capability Identifier Register. AGP compliant devices implemented on Mobile PC platforms must correctly report a revision number of at least 1.0 in the Capability Identifier Register.

Reference documents: WLP# - B4.1.4.9; AGP Interface Specification, Revision 2.0, Section 6.1.8; PC 2001 System Design Guide - GRPH-0163.
Test description: TD-8.1 Accelerated Graphics Port (AGP) Interface Test Description

8.2.10 The AGP command register of the master must match the AGP command register of the target when read.

Reference documents: WLP# - B4.1.4.9; AGP Interface Specification, Revision 2.0, Section 6.1.8; PC 2001 System Design Guide - GRPH-0163.
Test description: TD-8.1 Accelerated Graphics Port (AGP) Interface Test Description

8.2.11 PCI 66MHZ/64 bit qualifies as "another high speed bus" if there are no 33MHZ devices on the same bus.

Reference documents: WLP# - B4.1.4.9; AGP Interface Specification, Revision 2.0, Section 6.1.8; PC 2001 System Design Guide - GRPH-0163.
Test description: TD-8.1 Accelerated Graphics Port (AGP) Interface Test Description


AGP Memory Management Assertions

The following AGP memory management compliance assertions are tested with TD-8.2 AGP Graphics Address Relocation Table (GART) Test Description.

8.3.1 All AGP memory controllers implemented on desktop PCs must support a functional Graphics Address Remapping Table (GART).

Note: The GART is only recommended for AGP controllers implemented on Mobile PC platforms.

Reference document: WLP# - B4.1.4.9; PC 2001 System Design Guide - GRPH-0163; PC 99 System Design Guide - 14.51 and 6.23.
Test description: TD-8.2 AGP Graphics Address Relocation Table (GART) Test Description

8.3.2 AGP implementations on desktop PCs must support non-local video memory (AGP system memory) for storage of graphics data.

Note: Non-local video memory is not required for AGP implementations on Mobile PC platforms.

Reference document: WLP# - B4.1.4.9; PC 2001 System Design Guide - GRPH-0163; PC 99 System Design Guide - 14.51.
Test description: TD-8.2 AGP Graphics Address Relocation Table (GART) Test Description

8.3.3 Write combining (WC) of successive stores to the frame buffer is a requirement for systems with processors that support write combining.

Reference document: WLP# - B4.1.4.9; PC 2001 System Design Guide - GRPH-0163; PC 99 System Design Guide - 14.3.
Test description: TD-8.2 AGP Graphics Address Relocation Table (GART) Test Description

8.3.4 All AGP systems must support mapping of the Graphics Aperture to un-cached physical memory.

Note: AGP was designed to map memory to an un-cached memory region. Systems that do not map the GART/Aperture to uncached physical memory will suffer from poor performance.

Reference document: WLP# - B4.1.4.9; PC 2001 System Design Guide - GRPH-0163; PC 99 System Design Guide - 14.3.
Test description: TD-8.2 AGP Graphics Address Relocation Table (GART) Test Description

8.3.5 All AGP systems must support a working AGP_ENABLE.

Reference document: WLP# - B4.1.4.9; PC 2001 System Design Guide - GRPH-0163,
PC 99 System Design Guide - 14.51; Accelerated Graphics Port Interface Specification, Revision 1.0, Section 6.1.9; Accelerated Graphics Port Interface Specification, Revision 2.0, Section 6.1.10.
Test description: TD-8.2 AGP Graphics Address Relocation Table (GART) Test Description


AGP Transfer Mode Assertion

The following AGP transfer mode compliance assertion is tested with TD-8.3 Accelerated Graphics Port (AGP) Transfer Test Description.

8.4.1 All AGP compliant devices implemented on desktop PCs must be capable of supporting AGP 2X data transfer mode.

AGP compliant devices implemented on Mobile PC platforms must be capable of supporting at least AGP 1X data transfer rate.

Reference documents: WLP# - B4.1.4.9; PC 2001 System Design Guide - GRPH-0163; PC 99 System Design Guide - 14.51 and 6.23; Accelerated Graphics Port Interface Specification 1.0.
Test description: TD-8.3 Accelerated Graphics Port (AGP) Transfer Test Description

8.4.2 Discrete graphics solutions require the equivalent of AGP 2.X or better.

Reference documents: WLP# - B4.1.4.9; AGP Interface Specification, Revision 2.0, Section 6.1.9; PC 2001 System Design Guide - GRPH-0163.
Test description: TD-8.3 Accelerated Graphics Port (AGP) Transfer Test Description

8.4.3 Integrated graphics solutions require the equivalent of AGP 1.X or better.

Reference documents: WLP# - B4.1.4.9; AGP Interface Specification, Revision 2.0, Section 6.1.9; PC 2001 System Design Guide - GRPH-0163.
Test description: TD-8.3 Accelerated Graphics Port (AGP) Transfer Test Description


AGP Test Descriptions

This section describes the AGP tests. The descriptions include an overview of each test, hardware and software setup, test algorithm/steps, and test results interpretation.


TD-8.1 Accelerated Graphics Port (AGP) Interface Test Description

Test Kit: HCT 11, HCT 10

– Updated from AGP 1.0 to AGP 2.0.

This test ensures that the AGP configuration registers used by the operating system to initialize AGP features are correctly implemented by both the AGP master and target (chipset) device. The test walks the PCI bus, looking for AGP capabilities. The capabilities for this component are then recorded. The test then walks the device nodes looking for an AGP-capable device. If found, the capabilities of the device and the core chipset are verified.

This test verifies compliance with the following AGP interface requirements:

  • All AGP implementations must provide a PCI 2.2-compliant capability pointer that contains an offset to a working AGP capability structure.
  • All AGP compliant devices implemented on desktop solutions must correctly report a revision number of at least 2.0 in the Capability Identifier Register. AGP compliant devices implemented on mobile solutions must correctly report a revision number of at least 1.0 in the Capability Identifier Register.
  • All AGP capability structures must contain a read-only status register and a read/write command register. Writes to reserved fields in both registers must produce no effect in the hardware.
  • All AGP compliant devices must correctly report and be capable of managing a command request queue that contains at least one 32-bit command. This means at least an entry of 0 in the RQ_DEPTH field of the masters command register.
  • All AGP compliant devices must support the AGP_ENABLE command bit.
  • All AGP compliant devices implemented on desktop PCs must correctly report support for at least AGP 2X.
  • AGP compliant devices implemented on integrated graphics solutions must report support for at least AGP 1X.

Figure 8-1 illustrates the registers and fields verified by this test.

Figure 8-1 AGP Capability Registers

Figure 8-1. AGP Capability Registers

The test performs the following steps for both master and target AGP devices to verify AGP configuration and capabilities:

  1. Attempts to access the AGP capability structure by scanning the list of enumerated PCI devices. Correctly implemented configuration space for AGP devices set the Capabilities List bit of the PCI Status Register and contain a Capabilities Pointer referencing a list entry with Capability ID (CAP_ID) = 02h, indicating AGP.
  2. The MAJOR and MINOR revision number fields are read and verified to indicate an AGP revision number of at least 2.0 for desktop solutions, and at least 1.0 for mobile solutions. The MAJOR revision number must be at least 2 for desktop solutions and at least 1 for mobile solutions, and the MINOR revision number can be any value.
  3. The AGP_ENABLE bit of the AGP Command Register must be set, indicating that the device is initialized and AGP operations may be executed. It is assumed that the operating system has initialized the device prior to execution of this test.
  4. The RATE field of the AGP Status Register must report a minimum of 2X for desktop systems. Integrated graphics solutions must report a minimum of 1X.
  5. Reserved fields are verified to return zeros when read. Writes to all fields of the AGP Status Register and reserved fields of the AGP Command Register are verified to have no effect.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows 2000 or later
  • AGP Target (chipset)
  • AGP Master (graphics adapter) and supporting drivers

Results Interpretation

The test transcribes all results to a text based log file.

The test fails if:

  • The AGP Capabilities Pointer does not point to a valid AGP 2.0 register set (Capabilities Identifier Register, Command and Status Registers).
  • A desktop solution reports compliance with an AGP revision number less than 2.0.
  • A mobile solution reports compliance with an AGP revision number less than 1.0.
  • A command request queue of at least one 32-bit command is not supported.
  • The AGP_ENABLE command bit is not supported.
  • A discrete graphics solution does not correctly report support for at least AGP 2X.
  • An integrated graphics solution does not correctly report support for at least AGP 1X.
  • A reserved field does not return zeros when read.
  • A write to a field of the AGP Status Register is successful.
  • A write to a reserved field of the AGP Command Register is successful.

The test aborts if:

  • There is no AGP Capabilities Pointer found in the PCI configuration space of the devices on the system – this indicates that AGP is not implemented in this system.

Implementation note: This test will detect the presence of AGP in the system and it will report whether or not the system implements AGP correctly. This test WILL NOT verify compliance with "another high-speed connection", as the PC 2001 System Design Guide does not specify what these others might be.


TD-8.2 AGP Graphics Address Relocation Table (GART) Test Description

Test Kit: HCT 11, HCT 10

Note: In the HCT kit, this test is part of the TD-8.1 Accelerated Graphics Port (AGP) Interface test.

This test verifies compliance with the following AGP memory management requirements:

  • All AGP memory controllers implemented on desktop PCs must support a functional Graphics Address Remapping Table (GART). If an AGP memory controller on a Mobile PC implements a GART, it is compliance tested.
  • All AGP implementations on desktop PCs must support non-local video memory (AGP system memory) for storage of graphic data. Support for non-local video memory is not required for AGP implementations on mobile PC platforms. This means:
  • The AGP miniport must match the hardware in the system and not fail during initialization
  • The AGP miniport must not leak memory
  • The AGP miniport must not try to allocate or free 0 pages of memory
  • The AGP miniport must not free memory that has not been allocated
  • The AGP miniport must not overwrite system data structures or code modules
  • The contents of the system L1 and L2 caches must be able to be flushed to memory for processing by the graphics hardware
  • All virtual address in the GART table should be mappable to physical addresses
  • All physical addresses exposed to graphics hardware must be usable by the graphics hardware
  • Bit errors between the AGP master and target are intolerable
  • All AGP systems containing processors supporting WC must support the use of WC for successive stores to the frame buffer.
  • All AGP systems must support mapping of the Graphics Aperture to un-cached physical memory.

This requires more than one test:

  • The GART needs to be sized so if an allocation is supposed to fail using a divide and conquer algorithm (too big, alignment not possible, page already committed).
  • Allocate WC & UC (processors supporting WC) or uncached (processors not supporting WC) of 1 page on alignment of 0.
  • Run Knuth memory validation algorithm to verify that the GART is being allocated and freed correctly.

All AGP systems must support working AGP_ENABLE. AGP_Enable means that the GART is mapping linear low virtual addresses to linear high virtual addresses. Compare memory blocks with a bit pattern using a standard parity check/checksum algorithm. Continue in powers of two (to turn on one address line at a time) until we’re allocating and deallocating everything on one opp.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows 2000 or later
  • AGP Target (chipset)
  • AGP Master (graphics adapter) and supporting drivers

Results Interpretation

A pass/fail indication of compliance with the applicable test assertion is displayed and logged by the test program.


TD-8.3 Accelerated Graphics Port (AGP) Transfer Test Description

Test Kit: HCT 11, HCT 10

This test first ensures that the AGP configuration registers used by the operating system to initialize AGP features are correctly implemented by both the AGP master and target (chipset) device. The test walks the PCI bus, looking for AGP capabilities. The capabilities for this component are then recorded. The test then walks the device nodes looking for an AGP-capable device. If found, the following capability of the device and the core chipset is verified.

This test verifies compliance with the following AGP interface requirements:

  • All AGP compliant devices implemented on discrete graphics solutions must correctly report support for at least AGP 2X.
  • AGP compliant devices implemented on integrated graphics solutions must report support for at least AGP 1X.

This test then verifies that AGP devices are capable of reliably transferring data when configured to run at the required transfer mode. A known bit pattern is transferred between AGP system memory and local video memory (video memory residing on the graphics adapter). The bit pattern is then compared with the result of the transfer (as it resides in local video memory) and any differences are interpreted to mean data corruption. The size of the bit pattern is determined by querying the adapter for its maximum supported surface size. The texture characteristics of the adapter are queried, and a source surface in AGP memory, and a target surface in video memory are created using a Log(n) algorithm.

The pattern used for this texture is as follows:

10101010 01010101 0000000000000000

11111111 11111111 1111111111111111

10101010 10101010 0101010101010101

00000000 00000000 0000000000000000

10101010 10101010 1010101010101010

01010101 01010101 0101010101010101

10101010 10101010 1010101010101010

10101010 10101010 1010101010101010

01010101 01010101 0101010101010101

01010101 01010101 0101010101010101

This bit pattern represents four test cases: 8bits, 16bits, 32bits, and 64bits, respectively. By reversing the bit order on these boundaries, errors between transfers are more likely to be detected. If the pattern cannot be repeated in its entirety, as much of the pattern is repeated as possible Since write combining delivers information out-of-order, reordering errors is more easily detected.

The texture is the largest possible texture that has the same size in AGP and video memory. So if a card has 16MB of AGP memory available, but only 8MB of video memory available and no restrictions on texture sizes, then an 8MB AGP texture and an 8MB video memory texture would be created.

The created textures are then verified to be in AGP and video memory.

Next, the destination texture is filled with its offset in ULONG_PTRs from the beginning of the texture. So addresses 16, 32, & 64, for example, would contain the values 4, 8, & 16 on a 32-bit machine. On a 64-bit machine these addresses would contain 2, 4 & 8. This is to help determine if any data actually arrived in the target texture.

The pattern is then transferred between system memory to AGP memory, and AGP memory back to system memory. The patterns are then compared, and any differences are interpreted to mean data corruption.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows 2000 or later as well as DirectX 5 or later.
  • AGP Target (chipset)
  • AGP Master (graphics adapter) and supporting drivers

Results Interpretation

The test transcribes all results to a text based log file.

The test fails if:

  • The AGP device (master or target) reports less than 2X transfer mode support for discrete graphics solutions.
  • The AGP device (master or target) reports less than 1X transfer mode support for integrated graphics solutions.
  • The bit pattern transferred between AGP system memory and local video memory becomes corrupt during transfer.
  • At least one of the three methods used to transfer data to the AGP card result in a bytes/second value of < 133MB/s.

The test aborts if:

  • There is no AGP Capabilities Pointer found in the PCI configuration space of the devices on the system – this indicates that AGP is not implemented in this system.
  • The test is unable to create a surface to move the bit pattern through – these would be DirectX surface creation errors. (Both textured and non-textured creates failed).

Implementation note: This test will detect the presence of AGP in the system and it will report whether or not the system implements AGP correctly. This test WILL NOT verify compliance with "another high-speed connection", as the PC 2001 System Design Guide does not specify what these others might be.


Chapter 9: USB Host Controller, Hub and Peripheral Device Test Specification

Universal Serial Bus (USB) has been designed to enhance the PC end user experience in the following ways:

  • Enable low-cost, high-volume applications
  • Simple user "plug and play" paradigm
  • Port consolidation (mouse, keyboard, game port, serial and parallel)

This document specifies tests that determine hardware compliance with the key USB requirements in Microsoft Windows Logo Program System and Device Requirements. Test algorithms detailing how an individual hardware implementation will be tested for conformance with relevant specifications are fully described. The hardware tested includes: USB host controllers and root hubs, external hubs and peripheral devices.

Test Coverage

This chapter covers USB host controller, hub, and peripheral requirements. This document attempts to provide unambiguous definitions of the relevant features, functions, and behaviors specified in Microsoft Windows Logo Program System and Device Requirements. Some USB related requirements are not covered by this document. Some of the requirements have a high track record of compliance as to make tests for them less important than for items more likely to be a source of problems. Many requirements are testable using one or both of the following methods:

  • A purely software approach in which test software both initiates some system behavior and evaluates the correctness of the behavior.
  • A combination of software and operator evaluation, in which test software initiates some system behavior and the operator by interaction with the test software, provides an indication of correct system behavior.
  • Pure operator observation or evaluation of some aspect of the system.

The pure software fully automated approach is preferred when possible. In the other cases, an effort is made to remove as much of the subjective element from the operator evaluation as possible. This document describes the functional structure of the tests required to verify the USB requirements. In depth discussion of detailed test implementation is beyond the scope of this document.

Test Methodology

USB hubs and peripherals are implemented via a complex set of protocols. The correct operation of these protocols requires a software implementation that controls and coordinates the interaction of the hardware controller and peripherals. This test specification and associated tests use existing OS USB device drivers and device class drivers whenever possible to access and control the hardware being tested. These existing drivers offer the stability required to test the correct functioning of the hardware without masking the actual operation of that hardware. This approach minimizes the possibility that incorrect software implementation is uncovered by the tests.

Operator Input

Several of the tests require that some initial conditions such as the presence of a set of specified hubs and/or peripherals be set. Other tests have initial conditions provided by the test installation. Whenever possible, operator input requirements are minimized and the initial conditions are explicitly provided to the operator via on screen prompting. In the cases where such input is required, the margin for error is minimized through thorough descriptions of the needed input.


USB Test Assertions

Reference Document Sources for USB Assertions

Functional requirements specified in the following documents:

Enhanced Host Controller Interface Specification for Universal Serial Bus 2.0

To be published on http://www.usb.org/ when available

Microsoft Windows Logo Program System and Device Requirements, Version 2.0

http://www.microsoft.com/hwdev/winlogo/
(listed as "WLP#" in these assertions)

Microsoft Windows Driver Development Kit

http://www.microsoft.com/ddk/

OpenHCI: Open Host Controller Interface Specification for USB, Release 1.0a

http://www.microsoft.com/hwdev/respec/busspecs.htm
Or Universal HCI specification

PC 2001 System Design Guide and PC 99 System Design Guide

http://www.microsoft.com/hwdev/platform/pcdesign/desguide/pcguides.asp

Universal Host Controller Interface (UHCI) Design Guide, Revision 1.1

http://developer.intel.com/design/USB/UHCI11D.htm

USB class specifications

http://www.usb.org/developers/devclass.html

Universal Serial Bus (USB) 1.1 Specification (or later)

http://www.usb.org/developers/docs.html


USB Basic Test Assertions

The test assertions in the next two sections are derived from basic or general USB system requirements in Microsoft Windows Logo Program System and Device Requirements. Several of the assertions reference compatibility with comprehensive specifications that in turn have many correctness assertions. In these cases, the detailed breakout of compatibility requirements is provided in the test descriptions.

9.1.1 System includes USB with two USB ports, minimum.

Reference documents: PC 2001 System Design Guide, Sections, BIOS–0005.2; PC 99 System Design Guide - 7.1.
Test description: TD-9.10 USB System Port Presence Test

9.1.2 Systems include BIOS support for USB keyboards behind up to one level of external hub.

Reference documents: PC 2001 System Design Guide, Sections, BIOS–0005.2 & SYS–0021; PC 99 System Design Guide - 7.2.
Test description: TD-9.17 USB BIOS Support Test

9.1.3 All USB hardware complies with USB 1.0 specification.

Reference documents: WLP# - B2.6.2.3; PC 99 System Design Guide - 7.3.
Test description: TD-9.11 USB Specification Compliance Test

9.1.4 Connections use USB icon.

Reference document: WLP# - B2.6.4.2; PC 99 System Design Guide - 7.4.
Test description: Test Not Specified

9.1.A1 The system supports at least two ports capable of hosting removable devices, in addition to any ports used by the keyboard and pointing devices.

Mobile systems must support at least one port in addition to any ports used by keyboard and pointing devices.

Reference documents: WLP# - A2.4.1; A3.4.4; PC 2001 System Design Guide - SYS–0021, MOBL-0063; Universal Serial Bus Specification, Revision 1.1.
Test Description: TD-9.10 USB System Port Presence Test

9.1.A2 Systems include BIOS support for USB keyboards and pointing devices behind up to two levels of hubs external to the system.

Reference documents: WLP# - A1.1.4; PC 2001 System Design Guide - BIOS–0005.2
Test Description: TD-9.17 USB BIOS Support Test

9.1.A3 Systems include BIOS support for USB descriptors up to 64 kilobytes in length.

Reference document: WLP# - A1.1.4; PC 2001 System Design Guide - BIOS-0005.3.
Test description: Test Not Specified


USB Host Controller Assertions

The assertions contained in this section apply to the host controller. Additional information regarding the derivation of these assertions is also provided.

9.1.5 USB host controller can wake the system from S1 or S2.

Reference documents: WLP# -B2.6.4.3; PC 2001 System Design Guide - USB-0085; PC 99 System Design Guide - 7.7.
Test description: TD-9.13 USB System Wake Capabilities Test

9.1.6 Systems and devices must comply with USB power management requirements in the USB Specification, Version 1.0.

Reference documents: WLP# - B2.6.2.3; PC 99 System Design Guide - 7.10.
Test description: TD-9.6 USB Hub Power Management Test

9.1.7 USB host controller meets either OpenHCI or UHCI specification.

Reference documents: WLP# - B2.6.2; PC 99 System Design Guide - 7.6.
Test description: TD-9.12 USB Host Controller Version Compliance Test

9.1.B1 USB host controllers must meet the OpenHCI Specification, or the UHCI Specification, or the EHCI Specification.

Reference documents: WLP# - B2.6.2; PC 2001 System Design Guide - USB-0081, PC 99 System Design Guide - 7.6. OpenHCI Specification for USB, Revision 1.0a. UHCI Specification, Revision 1.1. Enhanced Host Controller Interface Specification, Revision .95.
Test description: TD-9.12 USB Host Controller Version Compliance Test

9.1.B2 EHCI USB host controllers must meet version .95 of the EHCI specification.

Reference documents: WLP# - B2.6.2; PC 2001 System Design Guide - USB-0081. Enhanced Host Controller Interface Specification, Revision .95.
Test description: TD-9.12 USB Host Controller Version Compliance Test

9.1.B3

Note This assertion is undefined.

9.1.B4 UHCI USB host controllers must meet version 1.1 of the UHCI specification.

Reference documents: WLP# - B2.6.2; PC 2001 System Design Guide - USB-0081, PC 99 System Design Guide - 7.6. Universal Host Controller Interface Specification, Revision 1.1.
Test Description: TD-9.12 USB Host Controller Version Compliance Test

9.1.B5 The USB host controller must support wake-up capabilities from S1, S2, and S3 system sleep states.

Reference documents: WLP# - B2.6.4.3; PC 2001 System Design Guide - USB–0085; USB Specification, Revision 1.1.
Test Description: TD-9.13 USB System Wake Capabilities Test


USB Hub Assertions

9.1.8 USB hubs comply with the USB 1.1 specification.

Reference documents: WLP# - B2.6.2.3; PC 99 System Design Guide - 7.8
Test description: TD-9.11 USB Specification Compliance Test
(Recommended only)

9.1.9 Bus-Powered USB hubs provide ports that can be individually power switched.

Reference documents: WLP# - B2.6.4.8; PC 2001 System Design Guide - USB-0086,
PC 99 System Design Guide - 7.9.
Test description: TD-9.5 USB Port Power Switching Test
(Recommended only)

9.1.10 Systems and devices comply with USB power management requirements.

Reference documents: WLP# - B2.6.2; PC 99 System Design Guide - 7.10.
Test description: TD-9.6 USB Hub Power Management Test

9.1.C1 USB field of each hub’s Device Descriptor reports revision 1.1 or 2.0.

Reference documents: WLP# - B2.6.2; PC 2001 System Design Guide - USB–0081; USB Specification, Revisions 1.1, and 2.0.
Test Description: TD-9.11 USB Specification Compliance Test

9.1.C2 An external hub must operate in a self-powered configuration unless it is integrated into a USB keyboard or integrated into a mobile system.

Reference document: WLP# - B2.6.4.8; PC 2001 System Design Guide - USB–0086; USB Specification, Revision 1.1.
Test Description: TD-9.14 USB Self Powered Hub Test

9.1.C3 A hub which reports USB version 1.1 must fully comply with the USB 1.1 Specification.

Reference documents: WLP# - B2.6.2; PC 2001 System Design Guide - USB–0081; USB Specification, Revision 1.1.
Test Description: TD-9.11 USB Specification Compliance Test

9.1.C3.1 A hub which reports USB version 1.1 must set all bits to one in the PortPwrCtrlMask in the hub descriptor.

Reference documents: WLP# - B2.6.2; PC 2001 System Design Guide - USB–0081; USB Specification, Revision 1.1, Section 11.15.2.1.
Test Description: TD-9.11 USB Specification Compliance Test

9.1.C3.2 A hub which reports USB version 1.1, must report Ganged or Individual port power switching in the wHubCharacteristics field of the hub descriptor.

Reference documents: WLP# - B2.6.2; PC 2001 System Design Guide - USB–0081; USB Specification, Revision 1.1, Section 11.15.2.1.
Test Description: TD-9.11 USB Specification Compliance Test

9.1.C4 Bus-Powered USB hubs provide ports that can be individually power switched.

Reference documents: WLP# - B2.6.4.8’ PC 2001 System Design Guide - USB-0086, PC 99 System Design Guide - 7.9.
Test description: TD-9.5 USB Port Power Switching Test


USB Peripheral Assertions

9.1.11 Devices and drivers support maximum flexibility of hardware interface options.

Reference documents: WLP# - B2.6.4.4; PC 2001 System Design Guide - USB–0084; PC 99 System Design Guide - 7.5.
Test description: TD-9.7 USB Isochronous Alternate Interface Presence Test

9.1.12 Devices and drivers must provide multiple alternate settings for interfaces with endpoints that consume isochronous bandwidth.

Reference documents: WLP# - B2.6.4.4; PC 2001 System Design Guide - USB-0084.1,
PC 99 System Design Guide - 7.5.1.
Test description: TD-9.7 USB Isochronous Alternate Interface Presence Test

9.1.13 Devices and drivers must not use isochronous bandwidth in alternate setting 0 of interfaces that use isochronous bandwidth.

Reference documents: WLP# - B2.6.4.4; PC 2001 System Design Guide - USB-0084.2,
PC 99 System Design Guide - 7.5.2.
Test description: TD-9.7 USB Isochronous Alternate Interface Presence Test

9.1.14 Systems and devices must comply with USB power management requirements in the USB Specification, Version 1.0.

Devices must comply with the Interface Power Management feature in the USB Common Device Class Specification, Revision 1.0.

Reference documents: WLP# - B2.6; PC 99 System Design Guide - 7.10; USB Common Device Class Specification, Revision 1.0; USB 1.0.
Test description: TD-9.8 USB Peripheral Power Management Test

9.1.15 USB devices meet requirements in related USB devices class specifications.

Reference documents: WLP# - B2.6.2.2; PC 2001 System Design Guide - USB-0088,
PC 99 System Design Guide - 7.11.
Test description: TD-9.9 USB Device Class Compliance Test

9.1.16 USB field of each peripheral’s Device Descriptor reports revision 1.1 or 2.0.

Reference documents: WLP# - B2.6.2; PC 2001 System Design Guide - USB–0081; USB Specification, Revisions 1.1, and 2.0.
Test Description: TD-9.11 USB Specification Compliance Test

9.1.17 Bus powered devices draw maximum of 500mA during normal operation.

Reference document: WLP# - B2.6.4.1; PC 2001 System Design Guide - USB–0087; USB Specification, Revision 1.1, Section 7.2.1.
Test Description: TD-9.15 USB Device and Hub Power Usage Test

9.1.18 Self-powered devices draw maximum of 100mA from the USB during normal operation.

Reference document: WLP# - B2.6.4.1; PC 2001 System Design Guide - USB–0087; USB Specification, Revision 1.1, Section 7.2.1.
Test Description: TD-9.15 USB Device and Hub Power Usage Test

9.1.19 A device cannot require any of its software to be pre-loaded before the device is connected to the system.

Reference documents: WLP# - B2.6.4.7; PC 2001 System Design Guide - USB–0089; USB Specification, Revision 1.1.
Test Description: TD-9.16 USB Device Installation Test

9.1.20 Any software required by the device must be installed when the device is connected.

The device and software must be fully functional after the installation. The installation should not require a reboot.

Reference document: WLP# - B2.6.4.7; PC 2001 System Design Guide - USB–0089; System Design Guide - SYS-0029.1;USB Specification, Revision 1.1.
Test Description: TD-9.16 USB Device Installation Test

9.1.21 Systems and devices must comply with USB power management requirements in the USB Specification, Version 1.1.

Devices must comply with the Interface Power Management feature in the USB Common Class Specification, Revision 1.1.

Reference documents: WLP# - B2.6.4.1; PC 2001 System Design Guide - USB-0087,
PC 99 System Design Guide - 7.10.
Test description: TD-9.8 USB Peripheral Power Management Test

9.1.22 USB devices and USB client software and drivers must not fail over system suspend and resume cycles to the S3 system state.

Reference documents: WLP#- B2.6.4.3; PC 2001 System Design Guide - USB-0085.
Test description: Test Not Specified

9.1.23 A USB device that reports USB version 1.1 must fully comply with the USB 1.1 Specification.

Reference documents: WLP# - B2.6.2; PC 2001 System Design Guide - USB–0081; USB Specification, Revision 1.1.
Test Description: TD-9.11 USB Specification Compliance Test

9.1.24 A USB device that reports USB version 1.1, must set bit D7 to one (Bus Powered) in the bmAttributes field of its configuration descriptors.

Reference documents: WLP# - B2.6.2; PC 2001 System Design Guide - USB–0081; USB Specification, Revision 1.1, Section 9.6.2.
Test Description: TD-9.11 USB Specification Compliance Test


USB Manual Interoperability Test Assertions

9.18.1 Installing and loading the driver does not reduce or eliminate the functionality of other devices installed on the system.

Reference documents: WLP# - B1.4.3
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.2 All USB devices and controllers function properly during simultaneous transfers to multiple devices on the bus.

Reference documents: WLP# - B2.6.3.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.3 Devices / Hubs function at any hub depth supported by the USB specification.

Reference documents: WLP# - B2.6.3.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.4 USB Controllers support any hub depth / device combinations supported by the USB specification.

Reference documents: WLP# - B2.6.3.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.5 Device drivers comply with DDK requirements for its operating system.

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.6 USB Verifier – URBs sent only to started devices

This assertion is tested for every URB submitted by the client driver to the USB stack. This assertion verifies that the client driver is submitting URBs only after the device has been started after processing the IRP_MN_START_DEVICE PnP IRP. If this assertion fails, it indicates that the client driver has attempted to submit an IRP when the device is not in the started state. (AssertURBToStartedDevice)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.7 USB Verifier – URBs sent only to powered devices

This assertion is tested for every URB submitted by the client driver to the USB stack. This assertion verifies that the client driver is submitting URBs only when the device is in the fully powered state, or PowerDeviceD0. If this assertion fails, it indicates that the client driver has attempted to submit an IRP when the device is some power state other than D0. (AssertURBToPoweredDevice)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.8 USB Verifier – URB length field is the expected size

For all URBs submitted to the USB stack, the USB Verifier checks that the Length field of the URB is correct for type of URB being submitted. If this assertion fails, it indicates that URB Length field is different than the size that the USB Verifier has calculated to be correct. A message will be displayed indicating the expected URB length. One common scenario in which this assertion fails is when the client driver fails to fill in the Length field. (AssertURBExpectedLength)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.9 USB Verifier – Interface pipe count is greater than zero

The client driver has issued a SELECT_INTERFACE URB to select an alternate setting for one of its interfaces. This assertion verifies that the NumberOfPipes field specified in the USBD_INTERFACE_INFORMATION structure is greater than zero. In most cases, all SELECT_INTERFACE requests should specify an interface with at least one pipe. However, this assertion will also fail for streaming devices that are selecting their zero bandwidth alternate setting. If this is the case, then this assertion failure is OK. A further version of USB Verifier will attempt to eliminate this false positive. (AssertInterfacePipeCount)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.10 USB Verifier – Interface length in a SELECT_INTERFACE URB is the correct size

The client driver has issued a SELECT_INTERFACE URB to select an alternate setting for one of its interfaces. USB Verifier calculates the minimum length of the URB for this request. The minimum length is defined as the size of the USBD_INTERFACE_INFORMATION structure plus the size of the USBD_PIPE_INFORMATION structure for all of the pipes specified in the USBD_INTERFACE_INFORMATION NumberOfPipes field. The client driver must pass down an URB that contains the correct amount of information. This assertion checks that the specified size is at least that size although future versions may tighten this restriction to verify that the URB is of the exact correct size. (AssertInterfaceLength)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.11 USB Verifier – URBs are not sent to invalid functions

The client driver has issued an URB with an invalid Function field in the URB. (AssertInvalidClientRequest)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.12 USB Verifier – Isochronous transfer request contains at least one packet

The client driver has issued an ISOCH_TRANSFER URB. This assertion validates that the NumberOfPackets field of the URB is greater than zero. All isochronous transfer requests must contain at least one data packet to transfer. (AssertIsochPacketCount)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.13 USB Verifier – Client drivers do not use the same URB multiple times incorrectly

The client driver has submitted an URB to the USB stack when there already exists a pending URB that shares the same URB structure. This assertion will only fail when the VERIFY_TRACK_URBS flag is set. When this flag is set, USB Verifier maintains a list of the pending URBs and the interrupt request packets (IRPs) they are carried on. Many times a client will allocate an URB and reuse that URB for multiple requests. This practice is acceptable if the client driver waits for completion of the URB before reusing the structure. If this assertion fails, it indicates the client has reissued the URB before waiting for previous submission of that URB to complete. This condition commonly occurs during a race condition between client submission code and URB cancellation code. (AssertClientMultipleURBUse)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.14 USB Verifier – Client drivers do not use the same IRP multiple times incorrectly.

The client driver has submitted an IRP to the USB stack when there already exists a pending IRP that shares the same IRP structure. This assertion will only fail when the VERIFY_TRACK_URBS flag is set. When this flag is set, USB Verifier maintains a list of pending URBs and the IRPs they are carried on. Many times a client will allocate an IRP and reuse that IRP for multiple requests. This practice is acceptable if the client driver waits for completion of the IRP before reusing the structure. If this assertion fails, it indicates the client has reissued the IRP before waiting for previous submission of that IRP to complete. This condition commonly occurs during a race condition between client submission code and IRP cancellation code. (AssertClientMultipleIRPUse)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.15 USB Verifier – The pending URB list count cannot be negative

This assertion occurs in the URB completion routine that is called once the USB stack has completed processing the URB. USB Verifier maintains a count of all pending URBs that have been sent to the USB stack. This count is incremented for every URB passed along to the USB stack and decremented once again during completion. This count should never be less than 0. If this assertion fails, it likely indicates that an URB that was submitted once has been completed twice. (AssertURBListCountNegative)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.16 USB Verifier – The low memory pending URB list count cannot be negative

This assertion occurs in the URB completion routine that is called once the USB stack has completed processing the URB. If the VERIFY_TRACK_URBS flag is set, USB Verifier maintains a list of all pending URBs. If this flag has been set but a memory allocation for failed for the list entry, USB Verifier will maintain a increment a low memory count and pass the URB to the USB stack. On completion, if the flag is set but the URB was not found in the list, it is assumed that a low memory condition occurred on submission. Therefore, the low memory count is decremented. This low memory count should never be zero. If this assertion fails, it may indicate that an URB that was submitted was completed twice. (AssertURBListLMCountNegative)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.17 USB Verifier – URB buffers cannot be modified while pending

This assertion occurs in the URB completion routine that is called once the USB stack has completed processing the URB. If the VERIFY_REPLACE_URBS flag is set, USB Verifier will create an alternate URB that contains the data of the submitted URB request and submit this new URB to the USB stack in place of the original URB. It then writes garbage data on the original URB to catch any client drivers that might change the data in a URB while it is pending in the USB stack. An assertion failure indicates that the client driver attempted to change some URB data while the URB was pending in the USB stack. (AssertURBBufferVerifyUntouched)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.18 USB Verifier – Low Memory completed URB list count cannot be negative

This assertion occurs in the URB completion routine that is called once the USB stack has completed processing the URB. If the VERIFY_REPLACE_URBS flag is set, USB Verifier will create an alternate URB that contains the data of the submitted URB request and submit this new URB to the USB stack in place of the original URB. If this new URB memory allocation fails, USB verifier will submit the original URB to the USB stack and increment a low memory count for replaced URBs On completion, USB Verifier will attempt to replace the original URB with the data in the alternate URB that it allocated. If this assertion fails, it indicates that a low memory condition occurred when the URB was submitted and the count is being decremented on completion and that this count is less than zero. This low memory count should never be negative. (AssertReplaceURBsLMCountNegative)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.19 USB Verifier – Drivers must cancel all pending I/O before a remove

This assertion verifies that the client driver has cancelled all pending URBs before passing the IRP_MN_REMOVE_DEVICE IRP to the USB stack. Client drivers must cancel all pending I/O when processing this PnP IRP. An assertion failure indicates the client driver did not do so. (AssertPendingRequestsAfterRemove)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.20 USB Verifier – Pending Low Memory Requests After Remove

This assertion verifies that the client driver has cancelled all pending URBs before passing the IRP_MN_REMOVE_DEVICE IRP to the USB stack. This low memory count indicates that there are outstanding URB requests for URBs that could not be traced due to low memory conditions. (AssertPendingLMRequestsAfterRemove)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.21 USB Verifier – Pending requests must be complete before issuing a remove

This assertion verifies that the client driver has cancelled all pending URBs before passing the IRP_MN_REMOVE_DEVICE IRP to the USB stack. This assertion checks the pending URB list that is maintained when the VERIFY_TRACK_URBS flag is set for requests that have not yet completed. A client driver must insure that all pending requests have been completed before passing the IRP_MN_REMOVE_DEVICE IRP to the USB stack. (AssertStaleURB)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.22 USB Verifier – Pending requests must be complete before issuing a remove

If the VERIFY_REPLACE_URBS flag is set, USB Verifier will create an alternate URB that contains the data of the submitted URB request and submit this new URB to the USB stack in place of the original URB. If this new URB memory allocation fails, USB verifier will submit the original URB to the USB stack and increment a low memory count for replaced URBs. This assertion verifies that the low memory count for replaced URBs is zero upon processing the IRP_MN_REMOVE_DEVICE. If this assertion fails, it indicates that there is an URB still pending in the USB stack. A client driver must insure that all pending requests have been completed before passing the IRP_MN_REMOVE_DEVICE IRP to the USB stack. (AssertCheckReplacedURBs)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.23 USB Verifier – URBs must be completed on the expected IRP

This assertion occurs in the URB completion routine that is called once the USB stack has completed processing the URB. If the VERIFY_TRACK_URBS flag is set, USB Verifier maintains a list of all pending URBs. On completion, USB Verifier searches its internal list of pending URBs for the URB that is being completed. When the URB is found in the list, USB Verifier checks that the IRP field of the list entry for this URB corresponds to the IRP that is being completed. These two IRP values should match. If this assertion fails, it indicates that an URB is being completed on IRP other than the one expected. An assertion failure would likely indicate that the client used the URB on multiple IRPs submitted simultaneously. If this is the case, AssertMultipleURBUse should have failed on URB submission. (AssertURBToIRPMismatch)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.24 USB Verifier – Client drivers must release frame length control before issuing a remove.

The client driver has forwarded the IRP_MN_REMOVE_DEVICE PnP IRP to the USB stack. During its normal operation, the client driver requested and received frame control for the USB system via the TAKE_FRAME_LENGTH_CONTROL URB. This assertion checks that such a client driver has released frame length control with the RELEASE_FRAME_LENGTH_CONTROL URB before passing on the IRP_MN_REMOVE_DEVICE IRP. (AssertRemoveWithFrameLengthControl)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.25 USB Verifier – When switching to a new configuration, the new configuration must contain an interface.

The client driver has issued a SELECT_CONFIGURATION URB but has specified a configuration with a configuration descriptor that does not have any interfaces. The interface count must be greater than zero to be a valid configuration. (AssertInitInterfaceCountPositive)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.26 USB Verifier – When switching to a new configuration, the old configuration must contain an interface.

The client driver has issued a SELECT_CONFIGURATION URB to select a new configuration with a configuration already set. This assertion validates that the old configuration had a least one interface. (AssertOldInterfaceListSizePositive)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.27 USB Verifier – Interface count is valid and matches descriptors

This assertion checks that there are enough entries in the interface list for the new interface that is being added. On receiving a SELECT_CONFIGURATION URB, USB Verifier allocates space for an interface list based on the number of interfaces reported in the configuration descriptor. After allocating this list, the verifier creates an entry for each of the interfaces. If this assertion fails, it means that there are more interfaces being added than were indicated in the configuration descriptor. A failure probably indicates an internal USB Verifier error. (AssertInterfaceAddListCountValid)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.28 USB Verifier – Select Configuration URB must reference a valid interface

The USB Verifier is attempting to insert a new interface into its internal interface list upon receiving a SELECT_CONFIGURATION URB. This assertion verifies that the slot in list that the interface will be inserted into does not contain previous interface information. An assertion failure probably indicates an internal USB Verifier error. (AssertInterfaceAddListEntryFound)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.29 USB Verifier – Select Interface request must contain a valid configuration handle

The client driver has issued a SELECT_INTERFACE URB. This assertion validates that the ConfigurationHandle field in the Select Interface URB corresponds to the current configuration handle stored by the USB Verifier. A failure indicates that the client driver has passed an invalid configuration handle. (AssertSelectInterfaceValidConfiguration)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.30 USB Verifier – Client drivers cannot set the frame length incorrectly

The client driver has issued a SET_FRAME_LENGTH URB. The USB Verifier checks that the client driver has previously requested and received the ability to set the frame length with the TAKE_FRAME_LENGTH_CONTROL URB. If this assertion fails, it indicates that the client driver does not currently have the ability to set the frame length. (AssertFrameLengthControlSet)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.31 USB Verifier – Control Transfers must use a valid pipe

The client driver has issued a CONTROL_TRANSFER URB. The USB Verifier maintains an internal list of valid pipes that are currently open. This assertion verifies the PipeHandle field of the submitted URB is a valid open pipe handle. A failure indicates that the client has passed in an invalid pipe handle. (AssertControlXferValidPipe)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.32 USB Verifier – Control transfers must be sent to a control pipe

The client driver has issued a CONTROL_TRANSFER URB. The USB Verifier maintains an internal list of valid pipes that are currently open. This assertion indicates that the pipe handle passed in the URB is a valid pipe handle but does not reference a control pipe. (AssertControlXferPipeType)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.33 USB Verifier – Bulk or Interrupt transfers must use a valid pipe

The client driver has issued a BULK_OR_INTERRUPT_TRANSFER URB. The USB Verifier maintains an internal list of valid pipes that are currently open. This assertion verifies the PipeHandle field of the submitted URB is a valid open pipe handle. A failure indicates that the client has passed in an invalid pipe handle. (AssertBulkIntXferValidPipe)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.34 USB Verifier – Bulk or Interrupt Transfer URBs must be sent to a Bulk/Interrupt pipe

The client driver has issued a BULK_OR_INTERRUPT_TRANSFER URB. The USB Verifier maintains an internal list of valid pipes that are currently open. This assertion indicates that the pipe handle passed in the URB is a valid pipe handle but does not reference a bulk or interrupt pipe. (AssertBulkIntXferPipeType)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.35 USB Verifier – Isochronous transfers must use a valid pipe

The client driver has issued an ISOCH_TRANSFER URB. The USB Verifier maintains an internal list of valid pipes that are currently open. This assertion verifies the PipeHandle field of the submitted URB is a valid open pipe handle. A failure indicates that the client has passed in an invalid pipe handle. (AssertIsochXferValidPipe)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.36 USB Verifier – Isochronous transfer requests must be sent to an isochronous pipe

The client driver has issued an ISOCH_TRANSFER URB. The USB Verifier maintains an internal list of valid pipes that are currently open. This assertion indicates that the pipe handle passed in the URB is a valid pipe handle but does not reference an isochronous pipe. (AssertIsochXferPipeType)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.37 USB Verifier – Reset cannot be sent with pending Isochronous transfers

The client driver has issued a RESET_PIPE URB for an isochronous pipe. This assertion verifies that the client driver does not have any pending isochronous requests to this pipe at the time the RESET_PIPE is received. Client drivers should issue an ABORT_PIPE URB to cancel all pending transfers before issuing a RESET_PIPE. (AssertResetWithPendingIsochXfers)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.38 USB Verifier – Reset cannot be sent with pending Bulk or Interrupt transfers

The client driver has issued a RESET_PIPE URB for a bulk or interrupt pipe. This assertion verifies that the client driver does not have any pending requests to this pipe at the time the RESET_PIPE is received. Client drivers should issue an ABORT_PIPE URB to cancel all pending transfers before issuing a RESET_PIPE. (AssertResetWithPendingBulkIntXfers)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.39 USB Verifier – Reset cannot be sent with pending control transfers

The client driver has issued a RESET_PIPE URB for a control pipe. This assertion verifies that the client driver does not have any pending control requests to this pipe at the time the RESET_PIPE is received. Client drivers should issue an ABORT_PIPE URB to cancel all pending transfers before issuing a RESET_PIPE. (AssertResetWithPendingControlXfers)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.40 USB Verifier – Reset or Abort must be issued on a valid pipe

The client driver has issued a ABORT_PIPE or RESET_PIPE URB. The USB Verifier maintains an internal list of valid pipes that are currently open. This assertion verifies the PipeHandle field of the submitted URB is a valid open pipe handle. A failure indicates that the client has passed in an invalid pipe handle. (AssertResetAbortOnInvalidPipe)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.41 USB Verifier – Reset or Abort cannot be sent until previous URB is complete

The client driver has issued an ABORT_PIPE or RESET_PIPE URB. The USB Verifier tracks whether a similar request has been already received for the specified pipe and is still pending. If this assertion fails, it indicates the client has issued a second URB of the same type before the previous URB has been completed. Client drivers should only have one ABORT_PIPE or RESET_PIPE pending for a given pipe at one time. (AssertResetOrAbortPending)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.42 USB Verifier – Reset/Abort must complete with a valid pipe handle

The client driver has issued an ABORT_PIPE or RESET_PIPE URB and the USB stack has completed the URB and the completion routines for the carrying IRP are being called. Once this completion returns to the USB Verifier, it checks that the pipe handle specified in the URB is a valid pipe handle. If this assertion fails and AssertResetAbortOnInvalidPipe did not fail, it indicates that PipeHandle field of the URB was changed after USB Verifier submitted the URB to the USB stack. If the VERIFY_REPLACE_URBS flag is set for this device, it indicates that the USB stack changed the pipe handle in the URB. If the flag is not set, it could indicate that either the client driver or the USB stack changed this field. If AssertResetAbortOnInvalidPipe failed previously, this assertion should also fail since it performs a similar check. (AssertResetAbortCompleteValidPipe)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.43 USB Verifier – Reset / Abort pipe flag must be set

The client driver has issued an ABORT_PIPE or RESET_PIPE URB and the USB stack has completed the URB and the completion routines for the carrying IRP are being called. Once this completion returns to the USB Verifier, it checks that an internal flag for tracking whether an ABORT or RESET is currently pending is set. If this assertion fails, it indicates that the flag for this pipe was not set when it should be and indicates an internal USB Verifier error. (AssertResetAbortPipeFlagSet)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test

9.18.44 USB Verifier – The URBLink field must be NULL

The client driver has issued an URB request that contains an UrbLink field. The original intent of this field was to allow multiple URB to be submitted on one IRP. However, this feature was never fully implemented within the core USB stack and the use of this field could cause unintended behavior. The driver should always set this field to NULL and submit each URB on its own IRP. (AssertUrbLinkNotNull)

Reference documents: WLP# - B1.1.1
Test Description: TD-9.18 USB Manual Interoperability Test


USB Port Reporting Test Assertions

9.19.1 All reported USB ports are accessible by an internal/external USB device.

Reference documents: WLP# - B2.6.3.1
Test Description: TD-9.19 USB Port Reporting Test

9.19.2 Compound devices correctly implement the DeviceRemovable field in the hub descriptor for any non-removable USB devices.

Reference documents: WLP# - B2.6.3.1
Test Description: TD-9.19 USB Port Reporting Test


Selective Suspend Test Assertions

The assertions in this sections are tested in TD-9.20 USB Selective Suspend Test Description.

9.20.1 When suspended, the USB device maintains any internal status including its address and configuration.

Reference documents: WLP# - B2.6.2; USB Specification section 9.1.1.6
Test Description: TD-9.20 USB Selective Suspend Test Description

9.20.2 Attached devices must be prepared to be suspended at any time they are powered, whether they have been assigned a non-default address or are configured.

Reference documents: WLP# - B2.6.2; USB Specification section 9.1.1.6
Test Description: TD-9.20 USB Selective Suspend Test Description

9.20.3 A USB device exits suspend mode when there is bus activity.

Reference documents: WLP# - B2.6.2; USB Specification section 9.1.1.6
Test Description: TD-9.20 USB Selective Suspend Test Description

9.20.4 After a port is resumed, a device attached to that port must respond to data transfers within 10ms of the resume signaling.

Reference documents: WLP# - B2.6.2; USB Specification section 9.2.6.2
Test Description: TD-9.20 USB Selective Suspend Test Description)


Device Enumeration Stress Test Assertions

The assertions in this sections are tested in TD-9.21 USB Enumeration Stress Test Description and in TD-9.24 USB Descriptor Test Description

9.21.1 After a USB device has been powered, it must not respond to any bus transactions until it has received a reset from the bus.

Reference documents: WLP# - B2.6.2; USB Specification section 9.1.1.3
Test Description: TD-9.21 USB Enumeration Stress Test Description

9.21.2 A device capable of high-speed operation must reset successfully at full-speed when in an electrical environment that is operating at full speed.

Reference documents: WLP# - B2.6.2; USB Specification section 9.1.1.3
Test Description: TD-9.21 USB Enumeration Stress Test Description; TD-9.24 USB Descriptor Test Description

9.21.3 After a device is successfully reset, the device must also respond successfully to device and configuration requests and return appropriate information.

Reference documents: WLP# - B2.6.2; USB Specification section 9.1.1.3
Test Description: TD-9.21 USB Enumeration Stress Test Description; TD-9.24 USB Descriptor Test Description

9.21.4 All USB devices use the default address when initially powered or after the device has been reset.

Reference documents: WLP# - B2.6.2; USB Specification section 9.1.1.4
Test Description: TD-9.21 USB Enumeration Stress Test Description

9.21.5 When suspended, the USB device maintains any internal status including its address and configuration.

Reference documents: WLP# - B2.6.2; USB Specification section 9.1.1.6
Test Description: TD-9.21 USB Enumeration Stress Test Description

9.21.6 After the reset/resume recovery interval, if a device receives a SetAddress request, the device must be able to complete processing of the request and be able to successfully complete the status stage of the request within 50ms.

Reference documents: WLP# - B2.6.2; USB Specification section 9.2.6.3
Test Description: TD-9.21 USB Enumeration Stress Test Description

9.21.7 For standard device requests that require no data stage, a device must be able to complete the request and be able to successfully complete the status stage of the request within 50 ms of receipt of the request for requests directed to the device, interface or endpoint.

Reference documents: WLP# - B2.6.2; USB Specification section 9.2.6.4
Test Description: TD-9.21 USB Enumeration Stress Test Description

9.21.8 The device must then be able to successfully complete the status stage within 50 ms after returning the last data packet.

For standard device requests that require data stage transfer, a device must be able to return the first data packet to the host within 500 ms of receipt of the request. For subsequent data packets, if any, the device must be able to return them within 500 ms of successful completion of the transmission of the previous packet.

Reference documents: WLP# - B2.6.2; USB Specification section 9.2.6.4
Test Description: TD-9.21 USB Enumeration Stress Test Description

9.21.9 For standard device requests that require a data stage transfer to the device, the device must be capable of accepting all data packets from the host and successfully completing the status stage if the host provides the data at the maximum rate at which the device can accept it.

Reference documents: WLP# - B2.6.2; USB Specification section 9.2.6.4
Test Description: TD-9.21 USB Enumeration Stress Test Description

9.21.10 USB devices must respond to standard device requests, even if the device has not yet been assigned an address or has not been configured.

Reference documents: WLP# - B2.6.2; USB Specification section 9.4
Test Description: TD-9.21 USB Enumeration Stress Test Description


Address Test Assertions

Assumptions in this section are tested in TD-9.22 USB Address Description Test Description.

9.22.1 After a device is successfully reset, the device must also respond successfully to device and configuration requests and return appropriate information.

Reference documents: WLP# - B2.6.2; USB Specification section 9.1.1.3
Test Description: TD-9.22 USB Address Description Test Description

9.22.2 All USB devices use the default address when initially powered or after the device has been reset.

Reference documents: WLP# - B2.6.2; USB Specification section 9.1.1.4
Test Description: TD-9.22 USB Address Description Test Description

9.22.3 After the reset/resume recovery interval, if a device receives a SetAddress request, the device must be able to complete processing of the request and be able to successfully complete the status stage of the request within 50ms.

Reference documents: WLP# - B2.6.2; USB Specification section 9.2.6.3
Test Description: TD-9.22 USB Address Description Test Description

9.22.4 USB devices must respond to standard device requests, even if the device has not yet been assigned an address or has not been configured.

Reference documents: WLP# - B2.6.2; USB Specification section 9.4
Test Description: TD-9.22 USB Address Description Test Description


Device Control Requests Test Assertions

The assertions in this section are tested in TD-9.23 USB Device Control Requests Test Description

9.23.1 After a USB device has been powered, it must not respond to any bus transactions until it has received a reset from the bus.

Reference documents: WLP# - B2.6.2; USB Specification section 9.1.1.3
Test Description: TD-9.23 USB Device Control Requests Test Description

9.23.2 A device capable of high-speed operation must reset successfully at full-speed when in an electrical environment that is operating at full speed.

Reference documents: WLP# - B2.6.2; USB Specification section 9.1.1.3
Test Description: TD-9.23 USB Device Control Requests Test Description

9.23.3 After a device is successfully reset, the device must also respond successfully to device and configuration requests and return appropriate information.

Reference documents: WLP# - B2.6.2; USB Specification section 9.1.1.3
Test Description: TD-9.23 USB Device Control Requests Test Description

9.23.4 All USB devices use the default address when initially powered or after the device has been reset.

Reference documents: WLP# - B2.6.2; USB Specification section 9.1.1.4
Test Description: TD-9.23 USB Device Control Requests Test Description

9.23.5 After the reset/resume recovery interval, if a device receives a SetAddress request, the device must be able to complete processing of the request and be able to successfully complete the status stage of the request within 50ms.

Reference documents: WLP# - B2.6.2; USB Specification section 9.2.6.3
Test Description: TD-9.23 USB Device Control Requests Test Description

9.23.6 For standard device requests that require no data stage, a device must be able to complete the request and be able to successfully complete the status stage of the request within 50 ms of receipt of the request for requests directed to the device, interface or endpoint.

Reference documents: WLP# - B2.6.2; USB Specification section 9.2.6.4
Test Description: TD-9.23 USB Device Control Requests Test Description

9.23.7 For standard device requests that require data stage transfer, a device must be able to return the first data packet to the host within 500 ms of receipt of the request.

For standard device requests that require data stage transfer, a device must be able to return the first data packet to the host within 500 ms of receipt of the request. For subsequent data packets, if any, the device must be able to return them within 500 ms of successful completion of the transmission of the previous packet. The device must then be able to successfully complete the status stage within 50 ms after returning the last data packet.

Reference documents: WLP# - B2.6.2; USB Specification section 9.2.6.4
Test Description: TD-9.23 USB Device Control Requests Test Description

9.23.8 For standard device requests that require a data stage transfer to the device, the device must be capable of accepting all data packets from the host and successfully completing the status stage if the host provides the data at the maximum rate at which the device can accept it.

Reference documents: WLP# - B2.6.2; USB Specification section 9.2.6.4
Test Description: TD-9.23 USB Device Control Requests Test Description

9.23.9 USB devices must respond to standard device requests, even if the device has not yet been assigned an address or has not been configured.

Reference documents: WLP# - B2.6.2; USB Specification section 9.4
Test Description: TD-9.23 USB Device Control Requests Test Description


USB Device Framework (CV) Test Assertions

These test assertions are tested in the TD-9.25 USB Device Framework Test. Note that the test assertion numbers that appear in the test logs are in the form x.x.x and that they do not have the 9.25 prefix as shown in this document. The WHQL Test Specification uses the form 9.25.x.x.x for classification purposes.

General Chapter 9 Command Assertions

9.25.1.1.1 Devices must have a corresponding configuration value for a valid configuration index.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.4.2
Test description: TD-9.25.1.1, TD-9.25.1.2, TD-9.25.1.3, TD-9.25.1.4, TD-9.25.1.5, TD-9.25.1.6, TD-9.25.1.10.

9.25.1.1.2 Devices must support being set to Addressed/Configured state.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.1.1
Test description: TD-9.25.1.1, TD-9.25.1.2, TD-9.25.1.3, TD-9.25.1.4, TD-9.25.1.5, TD-9.25.1.6, TD-9.25.1.10.

9.25.1.1.3 Devices must support a valid GetDescriptor(Device) request.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.4.3
Test description: TD-9.25.1.1 Device Descriptor Test

9.25.1.1.4 Devices must support a valid GetDescriptor(String) request.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.4.3, 9.6.7
Test description: Not available (TD-9.25.1.7)

9.25.1.1.5 Devices must support a valid GetDescriptor(Configuration) request.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.4.3
Test description: TD-9.25.1.3 Configuration Descriptor Test

9.25.1.1.6 High Speed Capable devices must support a valid GetDescriptor(OtherSpeedConfiguration) request.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.4.3
Test description: TD-9.25.1.3 Configuration Descriptor Test

9.25.1.1.7 Devices must support a valid SetConfiguration request

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.4.7
Test description: TD-9.25.1.11 Set Configuration Test

9.25.1.1.8 Device must support a valid GetDescriptor(DeviceQualifier) request.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.4.7
Test description: TD-9.25.1.2 Device Qualifier Test

HID Command Assertions

9.25.1.1.9 HID devices must support a GetDescriptor(HIDDescriptor) request.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 6.2, 7.1.1
Test description: TD-9.25.3.1 HID Descriptor Test

9.25.1.1.10 HID devices must support a valid SetProtocol(Report) request.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 1.1, Section 7.2.6
Test description: TD-9.25.3.3 HID Descriptor Test

9.25.1.1.11 HID devices must support a valid GetProtocol request.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 1.1, Section 7.2.5
Test description: TD-9.25.3.3 HID Descriptor Test

9.25.1.1.12 HID devices must support a valid SetProtocol(Boot) request.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 1.1, Section 7.2.6
Test description: TD-9.25.3.3 HID Descriptor Test

9.25.1.1.13 HID devices must support a valid GetDescriptor(Report) request.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 1.1, Section 6.2, 7.1.1
Test description: TD-9.25.3.4 HID Report Descriptor Test

9.25.1.1.14 HID devices that do not support a SetIdle request must respond with a request error.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 1.1, Section 7.2, 7.2.3
Test description: TD-9.25.3.2 HID Get/Set Idle Test

9.25.1.1.15 HID devices that do not support a GetIdle request must respond with a request error.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 1.1, Section 7.2, 7.2.3
Test description: TD-9.25.3.2 HID Get/Set Idle Test

General Device Assertions

9.25.1.1.20 Devices must respond with a Request Error to GetDescriptor requests that specify an invalid descriptor type.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.2.7 and 9.4.3.
Test description: Not available. (TD-9.25.1.8 Bad Descriptor Test)

9.25.1.1.21 Devices must respond with a Request Error to SetFeature requests that specify an invalid feature selector.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.2.7 and 9.4.9.
Test description: Not available. (TD-9.25.1.9 Bad Feature Test)

9.25.1.1.22 Devices must respond with a Request Error to ClearFeature requests that specify an invalid feature selector.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.2.7 and 9.4.1.
Test description: Not available. (TD-9.25.1.9 Bad Feature Test)

9.25.1.1.22 Devices must respond with a Request Error to ClearFeature requests that specify an invalid feature selector.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.2.7 and 9.4.1.
Test description: Not available. (TD-9.25.1.9 Bad Feature Test)

9.25.1.1.30 A suspended device must resume normal operation when resume signaling is seen on its upstream port.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 7.1.7.7.
Test description: Not available. (TD-9.25.1.13 Suspend/Resume Test)

9.25.1.1.100 Devices must support a GetStatus Standard Request.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.
Test description: (TD-9.25.1.3 Configuration Descriptor Test, TD-9.25.1.5 Endpoint Descriptor Test)

Device Descriptor Assertions

9.25.1.2.1 The descriptor returned in response to a GetDescriptor(Device) request must have a length of 0x12 (or appropriate length if less bytes are requested).

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.1.
Test description: TD-9.25.1.1 Device Descriptor Test

9.25.1.2.2 The descriptor returned in response to a GetDescriptor(Device) request must the have value of 0x01 in the Type field.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.1.
Test description: TD-9.25.1.1 Device Descriptor Test

9.25.1.2.3 The descriptor returned in response to a GetDescriptor(Device) request must have the value of 0x01/0x02 in the high byte of the bcdUSB field.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.1.
Test description: TD-9.25.1.1 Device Descriptor Test

9.25.1.2.4 The descriptor returned in response to a GetDescriptor(Device) request must have the value of 0x00/0x01/0x10 in the low byte of the bcdUSB field.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.1.
Test description: TD-9.25.1.1 Device Descriptor Test

9.25.1.2.5 The descriptor returned in response to a GetDescriptor(Device) request must have a value of 0x00 in the device subclass field when the device.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.1.
Test description: TD-9.25.1.1 Device Descriptor Test

9.25.1.2.6 The MaxPacketSize of a control endpoint must be 0x40 for a USB device operating at High speed.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.1.
Test description: TD-9.25.1.1 Device Descriptor Test

9.25.1.2.7 The MaxPacketSize of a control endpoint must be 0x08 for a usb device operating at Low speed.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.1.
Test description: TD-9.25.1.1 Device Descriptor Test

9.25.1.2.8 The MaxPacketSize of a control endpoint must be one of 0x08/0x10/0x20/0x40 for a USB device operating at full speed.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.1.
Test description: TD-9.25.1.1 Device Descriptor Test

9.25.1.2.9 A device must have at least one configuration.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.3.
Test description: TD-9.25.1.1 Device Descriptor Test

9.25.1.2.20 The descriptor returned in response to a GetDescriptor([OtherSpeed]Configuration) request cannot contain multiple descriptors of type configuration.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.3.
Test description: TD-9.25.1.3 Configuration Descriptor Test

9.25.1.2.21 The descriptor returned in response to a GetDescriptor([OtherSpeed]Configuration) request cannot contain a descriptor of type device.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.3.
Test description: TD-9.25.1.3 Configuration Descriptor Test

9.25.1.2.22 The descriptor returned in response to a GetDescriptor([OtherSpeed]Configuration) request cannot contain a descriptor of type device qualifier.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.3.
Test description: TD-9.25.1.3 Configuration Descriptor Test

9.25.1.2.23 The descriptor returned in response to a GetDescriptor([OtherSpeed]Configuration) request cannot contain a descriptor of type other speed configuration.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.3.
Test description: TD-9.25.1.3 Configuration Descriptor Test

9.25.1.2.24 The descriptor returned in response to a GetDescriptor([OtherSpeed]Configuration) request must contain the number of interfaces descriptors reported in the configuration descriptor.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.3.
Test description: TD-9.25.1.3 Configuration Descriptor Test

9.25.1.2.25 The descriptor returned in response to a GetDescriptor([OtherSpeed]Configuration) request must contain the number of endpoint descriptors reported in the contained interface descriptors.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.5.
Test description: TD-9.25.1.3 Configuration Descriptor Test

9.25.1.2.26 The configuration descriptor returned in response to a GetDescriptor([OtherSpeed]Configuration) request must have a length of 0x09.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Sections 9.6.3, 9.6.4.
Test description: TD-9.25.1.3 Configuration Descriptor Test

9.25.1.2.27 The descriptor returned in response to a GetDescriptor(Configuration) request must the value of 0x02 in the Type field.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.3.
Test description: TD-9.25.1.3 Configuration Descriptor Test

9.25.1.2.28 The descriptor returned in response to a GetDescriptor(OtherSpeedConfiguration) request must the value of 0x07 in the Type field.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.4.
Test description: TD-9.25.1.3 Configuration Descriptor Test

9.25.1.2.29 The number of interfaces cannot be a zero in a [OtherSpeed]Configuration descriptor.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Sections 9.6.4, 9.6.5
Test description: TD-9.25.1.3 Configuration Descriptor Test

9.25.1.2.30 Bits 0 through 4 must be set to zero in the bmAttributes field.of a [OtherSpeed]Configuration descriptor.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Sections 9.6.4, 9.6.4
Test description: TD-9.25.1.3 Configuration Descriptor Test

9.25.1.2.31 Bit 7 must be set to one in the bmAttributes field of a [OtherSpeed]Configuration descriptor.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Sections 9.6.3, 9.6.4
Test description: TD-9.25.1.3 Configuration Descriptor Test

9.25.1.2.32 A BUS-POWERED device cannot draw zero power.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.3.
Test description: TD-9.25.1.3 Configuration Descriptor Test

9.25.1.2.33 A SELF-POWERED device cannot draw more than 100ma from the USB bus.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 7.2.1.5.
Test description: TD-9.25.1.3 Configuration Descriptor Test

9.25.1.2.34 A BUS-POWERED device cannot draw more than 500ma.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 7.2.1.4.
Test description: TD-9.25.1.3 Configuration Descriptor Test

Interface Descriptor

9.25.1.2.40 An Isochronous endpoint present in alternate interface 0x00 must have a MaxPacketSize of 0x00

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 5.6.3.
Test description: TD-9.25.1.4 Interface Descriptor Test

9.25.1.2.41 The first interface must have an interface number of 0x0 and an alternate setting of 0x0.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.5.
Test description: TD-9.25.1.4 Interface Descriptor Test

9.25.1.2.42 The interface number cannot be greater than the number of interfaces reported in the configuration descriptor.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.5.
Test description: TD-9.25.1.4 Interface Descriptor Test

9.25.1.2.43 An Interface must have at least one setting with an Alternate Setting set to zero.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.5.
Test description: TD-9.25.1.4 Interface Descriptor Test

9.25.1.2.44 A device must support the SetInterface request if it has alternate settings for that interface.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.4.10.
Test description: TD-9.25.1.4 Interface Descriptor Test

9.25.1.2.45 Alternate settings for a given interface must be in sequential order.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.5.
Test description: TD-9.25.1.4 Interface Descriptor Test

9.25.1.2.46 Interface numbers must be in sequential order.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.5.
Test description: TD-9.25.1.4 Interface Descriptor Test

9.25.1.2.47 An interface descriptor must have a length of 0x09.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.5.
Test description: TD-9.25.1.4 Interface Descriptor Test

9.25.1.2.48 An interface descriptor must have a value of 0x04 in the Type field.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.5.
Test description: TD-9.25.1.4 Interface Descriptor Test

9.25.1.2.49 An interface descriptor must have a value of 0x00 in the interface subclass field when the interface class is 0x00.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.5.
Test description: TD-9.25.1.4 Interface Descriptor Test

9.25.1.2.50 A device must support the GetInterface request if it has alternate settings for that interface.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.4.4.
Test description: TD-9.25.1.4 Interface Descriptor Test

9.25.1.2.51 A successful GetInterface request must return the alternate setting set by a prior call to SetInterface.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.4.4.
Test description: TD-9.25.1.4 Interface Descriptor Test

Endpoint Descriptor

9.25.1.2.60 An endpoint descriptor must have a length of 0x07.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.6.
Test description: TD-9.25.1.5 Endpoint Descriptor Test

9.25.1.2.61 An endpoint descriptor must have a value of 0x05 in the Type field.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.6.
Test description: TD-9.25.1.5 Endpoint Descriptor Test

9.25.1.2.62 Only the default control endpoint can have an address of 0x00.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.6.
Test description: TD-9.25.1.5 Endpoint Descriptor Test

9.25.1.2.63 Bits 6 and 7 must be set to zero in the bmAttributes field.of an Endpoint descriptor.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 5.3.1.1.
Test description: TD-9.25.1.5 Endpoint Descriptor Test

9.25.1.2.64 Bits 4 and 5 cannot BOTH be set in the bmAttributes field.of an Isochronous Endpoint descriptor.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.6.
Test description: TD-9.25.1.5 Endpoint Descriptor Test

9.25.1.2.65 Bits 2 through 5 must be set to zero in the bmAttributes field.of a non Isochronous Endpoint descriptor.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.6.
Test description: TD-9.25.1.5 Endpoint Descriptor Test

9.25.1.2.66 Bits 13 through 15 must be set to zero in the wMaxPacketSize field.of an Endpoint descriptor.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.6.
Test description: TD-9.25.1.5 Endpoint Descriptor Test

9.25.1.2.67 Legal mult values are 0x00/0x01/0x02 for a High speed Isochronous/Interrupt Endpoint descriptor.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.6.
Test description: TD-9.25.1.5 Endpoint Descriptor Test

9.25.1.2.68 Bits 11 and 12 must be set to zero in the wMaxPacketSize field.of a Control/Bulk Endpoint descriptor.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.6.
Test description: TD-9.25.1.5 Endpoint Descriptor Test

9.25.1.2.69 Bits 11 and 12 must be set to zero in the wMaxPacketSize field.of a non high-speed Endpoint descriptor.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.6.
Test description: TD-9.25.1.5 Endpoint Descriptor Test

9.25.1.2.70 USB 1.x compliant devices must have a value of 0x01 in the bInterval field of an Isochronous Endpoint descriptor.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.6.
Test description: TD-9.25.1.5 Endpoint Descriptor Test

9.25.1.2.71 USB 2.x compliant devices must have a value between 0x01 and 0x10 in the bInterval field of an Isochronous Endpoint descriptor.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.6.
Test description: TD-9.25.1.5 Endpoint Descriptor Test

9.25.1.2.72 USB 2.x compliant devices must have a value between 0x01 and 0x10 in the bInterval field of a High speed Interrupt Endpoint descriptor.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.6.
Test description: TD-9.25.1.5 Endpoint Descriptor Test

9.25.1.2.73 A device cannot have a value of 0x00 in the bInterval field of a Full/Low speed Interrupt Endpoint descriptor.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.6.
Test description: TD-9.25.1.5 Endpoint Descriptor Test

9.25.1.2.74 A device operating at Low speed cannot have Isochronous endpoints.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 5.6.4.
Test description: TD-9.25.1.5 Endpoint Descriptor Test

9.25.1.2.75 A Full speed Isochronous endpoint must have a MaxPacketSize between 0 and 1023.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 5.6.3.
Test description: TD-9.25.1.5 Endpoint Descriptor Test

9.25.1.2.76 A High speed Interrupt/Isochronous endpoint must have a MaxPacketSize between 0 and 1024 when the Mult value is zero.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 5.6.3.
Test description: TD-9.25.1.5 Endpoint Descriptor Test

9.25.1.2.77 A High speed Interrupt/Isochronous endpoint must have a MaxPacketSize between 513 and 1024 and bInterval value of 1 when the Mult value is one.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.6.
Test description: TD-9.25.1.5 Endpoint Descriptor Test

9.25.1.2.78 A High speed Interrupt/Isochronous endpoint must have a MaxPacketSize between 683 and 1024 and bInterval value of 1 when the Mult value is two.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.6.
Test description: TD-9.25.1.5 Endpoint Descriptor Test

9.25.1.2.79 A device operating at Low speed cannot have Bulk endpoints.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 5.8.3.
Test description: TD-9.25.1.5 Endpoint Descriptor Test

9.25.1.2.80 A Full speed Bulk endpoint must have a MaxPacketSize of 0x08/0x10/0x20/0x40.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 5.8.3.
Test description: TD-9.25.1.5 Endpoint Descriptor Test

9.25.1.2.81 A High speed Bulk endpoint must have a MaxPacketSize of 0x200.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 5.8.3.
Test description: TD-9.25.1.5 Endpoint Descriptor Test

9.25.1.2.82 A Low speed Interrupt endpoint must have a MaxPacketSize less than or equal to 0x08.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 5.7.3.
Test description: TD-9.25.1.5 Endpoint Descriptor Test

9.25.1.2.83 A Full speed Interrupt endpoint must have a MaxPacketSize less than or equal to 0x40.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.5.
Test description: TD-9.25.1.5 Endpoint Descriptor Test

9.25.1.2.90 The number of endpoint descriptors in an interface must match the number reported in the interface descriptor.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.5.
Test description: TD-9.25.1.5 Endpoint Descriptor Test

9.25.1.2.91 A device that has Bulk/Interrupt endpoints must support the Halt Endpoint request on those endpoints.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.4.
Test description: TD-9.25.1.6 Halt Endpoint Test

Interface Descriptor

9.25.1.2.100 A device that supports remote wakeup in a specific configuration must not fail a valid SetFeature(DEVICE_REMOTE_WAKEUP) command.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.4.9.
Test description: TD-9.25.1.10 Remote Wakeup Test

9.25.1.2.101 A device that supports remote wakeup in a specific configuration must not fail a valid ClearFeature(DEVICE_REMOTE_WAKEUP) command.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.4.1.
Test description: TD-9.25.1.10 Remote Wakeup Test

9.25.1.2.102 After a successful ClearFeature(DEVICE_REMOTE_WAKEUP) Bit 1 of status word returned in response to a GetStatus request must be set to a zero.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.4.5.
Test description: Not available. (TD-9.25.1.9 Bad Feature Test)

9.25.1.2.103 After a successful SetFeature(DEVICE_REMOTE_WAKEUP) Bit 1 of status word returned in response to a GetStatus request must be set to a one.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.4.5.
Test description: Not available. (TD-9.25.1.9 Bad Feature Test)

9.25.1.2.104 After a successful SetFeature(SUSPEND), a hub/host port's status must show 'suspended'.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.13.
Test description: Not available.

9.25.1.2.105 A device with remote wakeup disabled must not initiate a remote wakeup.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.4.1.
Test description: Not available. (TD-9.25.1.9 Bad Feature Test)

9.25.1.2.106 A device with remote wakeup enabled must be able to initiate a remote wakeup on its suspended parent port.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.4.9.
Test description: Not available. (TD-9.25.1.9 Bad Feature Test)

Device Qualifier Assertions

9.25.1.2.120 The descriptor returned in response to a GetDescriptor(DeviceQualifier) request cannot have a value of 0x00/0x01 in the high byte of the bcdUSB field.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.2.
Test description: TD-9.25.1.2 Device Qualifier Test

9.25.1.2.121 The descriptor returned in response to a GetDescriptor(DeviceQualifier) request must have a length of 0x0a.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.2.
Test description: TD-9.25.1.2 Device Qualifier Test

9.25.1.2.122 The descriptor returned in response to a GetDescriptor(DeviceQualifier) request must the value of 0x06 in the Type field.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.2.
Test description: TD-9.25.1.2 Device Qualifier Test

9.25.1.2.123 The descriptor returned in response to a GetDescriptor(DeviceQualifier) request must have a value of 0x00 in the device subclass field when the device class is 0x00.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.2.
Test description: TD-9.25.1.2 Device Qualifier Test

9.25.1.2.123 The descriptor returned in response to a GetDescriptor(DeviceQualifier) request must have a value of 0x00 in the device subclass field when the device class is 0x00.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.2.
Test description: TD-9.25.1.2 Device Qualifier Test

9.25.1.2.124 The descriptor returned in response to a GetDescriptor(DeviceQualifier) request must have a value of 0x00 in the reserved field.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.6.2.
Test description: TD-9.25.1.2 Device Qualifier Test


USB Hub Compliance (CV) Test Assertions

These test assertions are tested in the TD-9.26 USB Hub Compliance (CV) Test. Note that the test assertion numbers that appear in the test logs have the form x.x.x and do not have the 9.26 prefix shown in this document. The WHQL Test Specification uses the form 9.26.x.x.x for classification purposes.

Hub General Command Assertions

9.26.2.1.1 Hubs must support Get_Port_Status requests on all ports.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.
Test description: TD-9.26.2.1, TD-9.26.2.2, TD-9.26.2.3, TD-9.26.2.x

9.26.2.1.2 Hubs must support Clear_Port_Feature(PortPower) requests on all ports.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.2.
Test description: TD-9.26.2.5 Power Off Suspended Port Test, TD-9.26.2.6 Power Off and On Port Test

9.26.2.1.3 Hubs must support Set_Port_Feature(PortPower) requests on all ports.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.13.
Test description: TD-9.26.2.6 Power Off and On Port Test

9.26.2.1.4 Hubs must support Set_Port_Feature(Suspend) requests on all ports.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.13.
Test description: TD-9.26.2.2 Detach Device From Suspended Port, TD-9.26.2.5 Power Off Suspended Port Test, TD-9.26.2.10 Reset Suspended Port Test, TD-9.26.2.12 Suspend Port Test

9.26.2.1.5 Hubs must support Clear_Port_Feature(Enabled) requests on all ports.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.2.
Test description: TD-9.26.2.3 Disable The Enabled Port Test, TD-9.26.2.9 Reset Disabled Port With Device Connected Port Test

9.26.2.1.6 Hubs must support Set_Feature(RemoteWakeup) requests.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.13.
Test description: TD-9.26.2.15 Suspend and Disconnect Device, TD-9.26.2.16 Suspend and Connect Device, TD-9.26.2.17 Suspend and Remote Wakeup

9.26.2.1.7 Hubs must support Clear_Feature(RemoteWakeup) requests.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.2.
Test description: TD-9.26.2.13 Suspend and Ignore Connect, TD-9.26.2.14 Suspend and Ignore Disconnect

9.26.2.1.8 Hubs must support Set_Port_Feature(Reset&Enable) requests on all ports.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.13.
Test description: TD-9.26.2.8 Reset Enabled Port With Device Connected Port Test, TD-9.26.2.9 Reset Disabled Port With Device Connected Port Test, TD-9.26.2.10 Reset Suspended Port Test

9.26.2.1.9 Hubs must support Clear_Port_Feature(C_PORT_RESET) requests on all ports.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.2.
Test description: TD-9.26.2.8 Reset Enabled Port With Device Connected Port Test, TD-9.26.2.9 Reset Disabled Port With Device Connected Port Test, TD-9.26.2.10 Reset Suspended Port Test

9.26.2.1.10 Hubs must support Clear_Port_Feature(Suspend) requests on all ports.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.2.
Test description: TD-9.26.2.11 Resume Port Test

9.26.2.1.11 Hubs must support a GetDescriptor(HUB_Descriptor) request.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.5.
Test description: TD-9.26.2.18 Hub Descriptor Test

Hub Port Status Change Assertions

9.26.2.2.1 The state of Hub ports that are suspended, disconnected or enabled must not change when an event (connect, disconnect, suspend, resume, or remote wakeup) happens on another port.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.
Test description: TD-9.26.2.13 Suspend and Ignore Connect, TD-9.26.2.14 Suspend and Ignore Disconnect, TD-9.26.2.15 Suspend and Disconnect Device, TD-9.26.2.16 Suspend and Connect Device, TD-9.26.2.17 Suspend and Remote Wakeup

9.26.2.2.2 After receiving a Clear_Port_Feature(PortPower), a hub port's status must show "not powered."

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.
Test description: TD-9.26.2.5 Power Off Suspended Port Test, TD-9.26.2.6 Power Off and On Port Test

9.26.2.2.3 After receiving a Set_Port_Feature(PortPower), a hub port's status must show "powered."

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.
Test description: TD-9.26.2.6 Power Off and On Port Test

9.26.2.2.4 After receiving a Set_Port_Feature(Suspend), a hub port's status must show "suspended."

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.
Test description: TD-9.26.2.2 Detach Device From Suspended Port, TD-9.26.2.5 Power Off Suspended Port Test, TD-9.26.2.10 Reset Suspended Port Test, TD-9.26.2.12 Suspend Port Test

9.26.2.2.5 After receiving a Clear_Port_Feature(Enable), a hub port's status must show "not enabled."

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.
Test description: TD-9.26.2.3 Disable The Enabled Port Test, TD-9.26.2.9 Reset Disabled Port With Device Connected Port Test

9.26.2.2.6 After notification that a Reset&Enable request is complete, a hub port's status must show "enabled."

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.
Test description: TD-9.26.2.8 Reset Enabled Port With Device Connected Port Test, TD-9.26.2.10 Reset Suspended Port Test

9.26.2.2.7 After notification that a Host-Initiated Resume request is complete, a hub port's status must show "enabled."

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.
Test description: TD-9.26.2.11 Resume Port Test

9.26.2.2.20 After a Disconnect Event on an enabled port, the hub port status must indicate Not Connected, Not Enabled, Not Suspended, Not OverCurrent, Not Reset, and Powered and the port change status must indicate Connect change, No Suspend change, No Overcurrent change, and No Reset change.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.
Test description: TD-9.26.2.1 Detach Device From Enabled Port Test

9.26.2.2.21 After a Disconnect Event on a suspended port, the hub port status must indicate Not Connected, Not Enabled, Not Suspended, Not OverCurrent, Not Reset, and Powered and the port change status must indicate Connect change, No Suspend change, No Overcurrent change, and No Reset change.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.
Test description: TD-9.26.2.2 Detach Device From Suspended Port

9.26.2.2.22 After a Connect Event on a port, the hub port status must indicate. Connected, Not Enabled, Not Suspended, Not OverCurrent, Not Reset, and Powered and the port change status must indicate Connect change, No Enable/Disable change, No Suspend change, No Overcurrent change, and No Reset change.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.
Test description: TD-9.26.2.4 Hot Plug Device Port Test

9.26.2.2.23 After a Remote Wakeup Event on a suspended port, the hub port status must indicate Connected, Enabled, Not Suspended, Not OverCurrent, Not Reset, and Powered and the port change status must indicate No Connect change, No Enable/Disable change, Suspend change, No Overcurrent change, and No Reset change.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.
Test description: TD-9.26.2.7 Remote Wakeup Port Test

9.26.2.2.40 Hub port events that cause a hub port change bit to transition from a zero to a one (connect, disconnect, reset complete, resume complete) must cause the appropriate notification data to be sent to the host at the next poll of the hub's change notification pipe.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.4.
Test description: TD-9.26.2.1, TD-9.26.2.2, TD-9.26.2.3, (all TD-9.26.2.x)

9.26.2.2.41 Data returned from a hub's change notification pipe must indicate which ports had a change in status.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.4.
Test description: TD-9.26.2.1, TD-9.26.2.2, TD-9.26.2.3, (all TD-9.26.2.x)

9.26.2.2.60 A suspended hub that is not enabled for remote wakeup must not signal remote wakeup when a connect or disconnect happens on one of its ports.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.4.1.
Test description: TD-9.26.2.13 Suspend and Ignore Connect

9.26.2.2.61 A suspended hub that is enabled for remote wakeup must signal remote wakeup when a connect or disconnect happens on one of its ports.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Chapter 11.
Test description: TD-9.26.2.14 Suspend and Ignore Disconnect

Hub Descriptor Assertions

9.26.2.3.1 The descriptor returned in response to a GetDescriptor(Hub_Descriptor) request must have the value of 0x29 in the bDescriptorType field.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.23.2.1.
Test description: TD-9.26.2.18 Hub Descriptor Test

9.26.2.3.2 The descriptor returned in response to a GetDescriptor(Hub_Descriptor) request must have a value of 0x0 or 0x1 in the Logical Power Switching Mode subfield of the wHubCharacteristics field.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.23.2.1.
Test description: TD-9.26.2.18 Hub Descriptor Test

9.26.2.3.3 Self-powered Hubs MUST provide Over-Current Protection.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.23.2.1.
Test description: TD-9.26.2.18 Hub Descriptor Test

9.26.2.3.4 Reserved bits in the Hub Descriptor must read as zeros.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.23.2.1.
Test description: TD-9.26.2.18 Hub Descriptor Test

9.26.2.3.5 Bit 0 of the Device Removable bitmask is reserved and must read as a zero.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.23.2.1.
Test description: TD-9.26.2.18 Hub Descriptor Test

9.26.2.3.6 All bits in the Hub Descriptors' PortPwrCtrlMask field must be 1's.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.23.2.1.
Test description: TD-9.26.2.18 Hub Descriptor Test


USB HIDView (CV) Test Assertions

These test assertions are tested in the TD-9.27 USB HIDView (CV) Test. Note that the test assertion numbers that appear in the test logs have the form x.x.x and do not have the 9.27 prefix shown in this document. The WHQL Test Specification uses the form 9.27.x.x.x for classification purposes.

General HID Assertions

9.27.3.2.1 A HID class compliant Interface must have one HID descriptor associated with it.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.1, Section 7.1.
Test description: TD-9.27.3.1 HID Descriptor Test

9.27.3.2.2 A HID class compliant Interface must have one Endpoint descriptor associated with it.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.1, Section 7.1.
Test description: TD-9.27.3.1 HID Descriptor Test

HID Descriptor Assertions

9.27.3.2.20 A HID class compliant Interface must have a value of 0x00/0x01 in the bInterfaceSubClass field.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.1, Appendix E.3.
Test description: TD-9.27.3.1 HID Descriptor Test

9.27.3.2.21 A HID class compliant Interface must have a value of 0x00/0x01/0x02 in the bInterfaceProtocol field.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.1, Appendix E.3.
Test description: TD-9.27.3.1 HID Descriptor Test

9.27.3.2.22 A HID class compliant Interface must have a valid HID descriptor associated with it.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.1, Section 7.1.
Test description: TD-9.27.3.1 HID Descriptor Test

9.27.3.2.23 The HID descriptors obtained from the configuration descriptor and one obtained by performing a GetDescriptor request for the same interface must match.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.1, Section 7.1.
Test description: TD-9.27.3.1 HID Descriptor Test

9.27.3.2.24 The descriptor returned in response to a GetDescriptor(HIDDescriptor) request must have a length of at least 0x09 and in increments of 3 if more than 9.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.1, Section 6.2.1.
Test description: TD-9.27.3.1 HID Descriptor Test

9.27.3.2.25 The descriptor returned in response to a GetDescriptor(HIDDescriptor) request must have a bNumDescriptors value that correlates with the length value.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.1, Section 6.2.1.
Test description: TD-9.27.3.1 HID Descriptor Test

9.27.3.2.26 The descriptor returned in response to a GetDescriptor(HIDDescriptor) request must the value of 0x21 in the Type field.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.1, Section 6.2.1.
Test description: TD-9.27.3.1 HID Descriptor Test

9.27.3.2.27 The descriptor returned in response to a GetDescriptor(HIDDescriptor) request must the value greater than 0x01 in the high byte of the bcdHID field.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.1, Section 6.2.1.
Test description: TD-9.27.3.1 HID Descriptor Test

9.27.3.2.28 The descriptor returned in response to a GetDescriptor(HIDDescriptor) request must contain at least one entry containing of type report descriptor.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.1, Section 6.2.1.
Test description: TD-9.27.3.1 HID Descriptor Test

HID Command Assertions

9.27.3.2.40 The protocol returned in response to a GetProtocol request must match the protocol set by a successful previous call to SetProtocol.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.1, Section 7.2.5.
Test description: TD-9.27.3.3 HID Get/Set Protocol Test

9.27.3.2.60 The number of items in a report descriptor must be greater than 0x0.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.1, Section 6.2.2.
Test description: TD-9.27.3.4 HID Report Descriptor Test

9.27.3.2.61 The report descriptor returned in response to a GetDescriptor(Report) must be compliant with the HID specification.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.1, Section 6.2.2.
Test description: TD-9.27.3.4 HID Report Descriptor Test

9.27.3.2.80 The idle rate returned in response to a GetIdle request must match the idle rate set by a successful previous call to SetIdle.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.1, Section 7.2.3.
Test description: TD-9.27.3.2 HID Get/Set Idle Test


USB High Speed Hub Test Assertions

These assertions are tested in TD-9.28 USB High Speed Hub Basic Test, the TD-9.29 USB High Speed Hub Basic Transfer Test, and in TD-9.30 USB 2.0 High-Speed Hub Advanced Transfer Test. These tests are based upon the USBHTT compliance test tool developed by the USB-IF and available at http://www.usb.org. Note that the test assertion numbers that appear in the test logs are in the form x.x.x and that they do not have the 9.28 prefix as shown in this document. The WHQL Test Specification uses the form 9.28.x.x.x for classification purposes.

Each test assertion lists the specific sub-tests where the assertion is tested. You can use the test description number to locate information about the test. In some cases, where there is currently no test for an assertion, the test description is listed as not available. However, for compliance with the USB 2.0 high-speed hub specification and the Microsoft Windows Logo Program System and Device Requirements, these assertions must still be met.

USB high-speed hub test assertions are listed in the following section:

Device Enumeration and Port Routing

Port Indicators

Number of Transaction Translators

Descriptors and Commands

Miscellaneous

General Transaction Translator (HUB) Data Integrity

Transaction Translator Full/Low Speed Transaction Scheduling

Multiple Stream Interoperability


Device Enumeration and Port Routing

Hub Connected Upstream to High Speed Capable Port

9.28.1.1.1 When a hub’s upstream port is connected to a high speed capable port, control of a full speed device connected to a downstream port must be routed to the transaction translator by the hub port routing logic.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.
Test description: TD-9.28.1.2 Device Enumeration In High Speed Environment Test

9.28.1.1.2 When a hub’s upstream port is connected to a high speed capable port, control of a low speed device must be routed to the transaction translator by the hub port routing logic.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.
Test description: TD-9.28.1.2 Device Enumeration In High Speed Environment Test

9.28.1.1.3 When a hub’s upstream port is connected to a high speed capable port, a USB-IF compliant full speed device must enumerate properly when connected to a downstream port.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.
Test description: TD-9.28.1.2 Device Enumeration in High Speed Environment Test

9.28.1.1.4 When a hub’s upstream port is connected to a high speed capable port, a USB-IF compliant low speed device must enumerate properly when connected to a downstream port.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.
Test description: TD-9.28.1.2 Device Enumeration in High Speed Environment Test

9.28.1.1.5 When a hub’s upstream port is connected to a high speed capable port, a USB-IF compliant high speed device must enumerate properly when connected to a downstream port.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.
Test description: TD-9.28.1.2 Device Enumeration in High Speed Environment Test

Hub Connected Upstream to Full/Low Speed Only Capable Port

9.28.1.2.1 When a hub’s upstream port is connected to a full/low speed only capable port, a USB-IF compliant high speed device must enumerate properly when connected to a downstream port (as a full speed device).

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.
Test description: TD-9.28.1.1 Device Enumeration in Full Speed Environment Test

9.28.1.2.2 When a hub’s upstream port is connected to a full/low speed only capable port, a USB-IF compliant full speed device must enumerate properly when connected to a downstream port.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.
Test description: TD-9.28.1.1 Device Enumeration in Full Speed Environment Test

9.28.1.2.3 When a hub’s upstream port is connected to a full/low speed-only capable port, a USB-IF compliant low speed device must enumerate properly when connected to a downstream port.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.
Test description: TD-9.28.1.1 Device Enumeration in Full Speed Environment Test

9.28.1.2.4 When a hub’s upstream port is connected to a full/low speed-only capable port, the transaction translator must be disabled and must not be used. The hub repeater must operate as a full/low speed repeater.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.1.1.
Test description: Not available.

General Device Detection

9.28.1.3.1 Bit 9 of the Port Status Bits should be set to one If and only if a low speed device is attached to the downstream port of a hub.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.
Test description: TD-9.28.1.2 Device Enumeration in High Speed Environment Test

9.28.1.3.2 Bit 10 of the Port Status Bits should be set to one if, and only if, a high speed device is attached to the downstream port of a hub that is operating in a high speed environment.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.
Test description: TD-9.28.1.2 Device Enumeration in High Speed Environment Test


Port Indicators

The Port Indicators test assertions are optional for USB 2.0 hubs. However, if they are implemented all of the following assertions must be met.

9.28.1.4.1 A hub must accurately indicate whether it supports port indicators through bit D7 of the wHubCharacteristics field of the hub class descriptor.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Sections 11.5.3, 11.23.2.1.
Test description: TD-9.28.1.3 Port Indicator Manual Mode Test; TD-9.28.1.4 Port Indicator Automatic Mode Test

9.28.1.4.2 If a high speed capable hub implements port indicators they must be as specified in the Universal Serial Bus Specification, Revision 2.0. Custom port indicators are not allowed.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0.
Test description: TD-9.28.1.3 Port Indicator Manual Mode Test; TD-9.28.1.4 Port Indicator Automatic Mode Test

9.28.1.4.3 When a hub is suspended or not configured all of its port indicators must be off.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Sections 11.5.3, 11.23.2.1.
Test description: TD-9.28.1.3 Port Indicator Manual Mode Test; TD-9.28.1.4 Port Indicator Automatic Mode Test

9.28.1.4.4 When a hub makes the transition out of a not configured state, its port indicators must be in Automatic control mode (as defined in section 11.5.3 of the Universal Serial Bus Specification, Revision 2.0) by default.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.5.3
Test description: TD-9.28.1.4 Port Indicator Automatic Mode Test

9.28.1.4.5 A hub port indictor must be off when it is under automatic control and the port is in the Suspended, Resuming, SendEOR, Restart_E, or Restart_S state.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.5.3.
Test description: TD-9.28.1.4 Port Indicator Automatic Mode Test

9.28.1.4.6 A hub port indictor must be Green when it is under automatic control and the port is in the Enabled, Transmit, or TransmitR state.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.5.3.
Test description: TD-9.28.1.4 Port Indicator Automatic Mode Test

9.28.1.4.7 A hub port indictor for a hub with Port Power Switching must be off when it is under automatic control and the port is in the Disconnected, Disabled, Not Configured, Resetting, or Testing state.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.5.3.
Test description: Not available.

9.28.1.4.8 The following rule applies to a hub port indictor for a hub without Port Power Switching. It must be off or amber if there is an over-current condition when it is under automatic control and the port is in the Disconnected, Disabled, Not Configured, Resetting, or Testing state.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.5.3.
Test description: Not available.

9.28.1.4.9 A hub port indictor for a hub with Port Power Switching must be off or amber if there is an over-current condition. This rule applies when it is under automatic control and the port is in the powered-off state.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.5.3.
Test description: Not available.

9.28.1.4.10 A hub port indictor for a hub without Port Power Switching must be off when it is under automatic control and the port is in the powered-off state.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.5.3.
Test description: Not available.

9.28.1.4.11 Bit 12 of a hub’s Port Status bits must accurately indicate whether the port indicator is currently under Automatic or Software control.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.7.1.
Test description: TD-9.28.1.3 Port Indicator Manual Mode Test; TD-9.28.1.4 Port Indicator Automatic Mode Test

9.28.1.4.12 A port indicator must make the transition to manual mode and display amber in response to a Set Port Feature command with feature selector PORT_INDICATOR and Port Indicator Selector 1.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.13.
Test description: TD-9.28.1.3 Port Indicator Manual Mode Test

9.28.1.4.13 A port indicator must make the transition to manual mode and display green in response to a Set Port Feature command with feature selector PORT_INDICATOR and Port Indicator Selector 2.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.13.
Test description: TD-9.28.1.3 Port Indicator Manual Mode Test

9.28.1.4.14 A port indicator must make the transition to manual mode and display off in response to a Set Port Feature command with feature selector PORT_INDICATOR and Port Indicator Selector 3.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.13.
Test description: TD-9.28.1.3 Port Indicator Manual Mode Test

9.28.1.4.15 A port indicator must make the transition to automatic mode in response to a Set Port Feature command with feature selector PORT_INDICATOR and Port Indicator Selector 0.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.13.
Test description: TD-9.28.1.3 Port Indicator Manual Mode Test

9.28.1.4.16 A hub must respond to a Clear Port Feature command with feature selector PORT_INDICATOR by transitioning the port indicator for that port to Automatic Mode.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, 12/07/00 Errata.
Test description: TD-9.28.1.3 Port Indicator Manual Mode Test


Number of Transaction Translators

Reporting of Number of Transaction Translator in Implementation

9.28.1.5.1 A hub must implement either one transaction translator or one transaction translator per downstream port.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, 11.14.1.3.
Test description: TD-9.28.1.5 Number of Transaction Translators Test

9.28.1.5.2 A hub operating at full/low speed must set the bDeviceProtocol field of its Device_Qualifer Descriptor to 1 if its implements a single transaction translator or 2 if it implements one transaction translator per port.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.
Test description: TD-9.28.1.5 Number of Transaction Translators Test

9.28.1.5.3 A hub operating at high speed must set the bInterfaceProtocol field of its Interface Descriptor to 0 if its implements a single transaction translator or 1 if it implements one transaction translator per port.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.
Test description: TD-9.28.1.5 Number of Transaction Translators Test

9.28.1.5.4 A hub operating at high speed that implements one transaction translator per port must provide an alternate setting for its interface with all fields identical to those for the default interface except for bInterfaceProtocol which must be set to 2.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.
Test description: TD-9.28.1.5 Number of Transaction Translators Test

9.28.1.5.5 By default a hub with multiple transaction translators (1 per port) must only use one transaction translator (single TT mode by default).

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.
Test description: TD-9.28.1.5 Number of Transaction Translators Test

9.28.1.5.6 A multiple transaction translator capable port (1 per port) must only use more than one transaction translator if its alternate interface setting is set through a SET_INTERFACE request. A hub with multiple transaction translators must support SET_INTERFACE when operating in a high-speed capable environment.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.
Test description: TD-9.28.1.5 Number of Transaction Translators Test

9.28.1.5.7 A hub with multiple transaction translators (1 per port) must support GET_INTERFACE when operating in a high speed environment.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.
Test description: TD-9.28.1.5 Number of Transaction Translators Test


Descriptors and Commands

Transaction Translator Commands and Transaction Translator Think Time

9.28.1.6.1 A hub must implement its Device, Device Qualifier, Configuration, Interface, Other Speed Configuration, and Endpoint descriptors when connected in a full speed electrical environment as specified in the Universal Serial Bus Specification, Revision 2.0.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.
Test description: TD-9.28.1.6 Full Speed Descriptor Test

9.28.1.6.2 A hub must implement its Device, Device Qualifier, Configuration, Interface, Other Speed Configuration and Endpoint descriptors when connected in a high speed electrical environment as specified in the Universal Serial Bus Specification, Revision 2.0.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.23.1.
Test description: TD-9.28.1.7 High Speed Descriptor Test

9.28.1.6.3 A hub must respond to a valid Get_TT_State request with bits 0 to 15 of the TT_Return_Flags field set to zero.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.8.
Test description: TD-9.28.1.10 Get TT State Test

9.28.1.6.4 A transaction translator must return to its initial state after configuration in response to the Reset_TT request.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.9.
Test description: TD-9.28.1.13 Reset TT Test

9.28.1.6.5 A transaction translator must halt operation in response to a valid Stop_TT request.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.11.
Test description: TD-9.28.1.12 Stop TT Test

9.28.1.6.6 A transaction translator that has been stopped via a Stop_TT request must only resume operation after being reset through a Reset_TT request or an overall reset of the hub.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.11.
Test description: TD-9.28.1.12 Stop TT Test

9.28.1.6.7 A transaction translator must clear an asynchronous (non-periodic) buffer associated with the given endpoint in response to a valid Clear TT Buffer request.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.11.
Test description: TD-9.28.1.11 Clear TT Buffer Test

9.28.1.6.8 A transaction translator must treat an otherwise correct Clear_TT_Buffer response that specifies a non-existent transaction as a functional no-op.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.11.
Test description: TD-9.28.1.11 Clear TT Buffer Test

9.28.1.6.9 A transaction translator must accurately indicate its worst case Think Time to advance to the next full/low speed transaction.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.11.
Test description: TD-9.28.1.14 Clear TT Buffer Test.

9.28.1.6.10 A multi-TT hub must respond with a Request Error to a Clear TT Buffer, Stop TT, Reset TT, or Get TT State request with an invalid port number. A single TT hub must respond with a Request Error to a Clear TT Buffer or Get TT State request with an invalid port number. A single TT hub may ignore the port number in Stop TT and Reset TT requests.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.
Test description: TD-9.28.1.10 Get TT State Test; TD-9.28.1.11 Clear TT Buffer Test; TD-9.28.1.12 Stop TT Test; TD-9.28.1.13 Reset TT Test.

9.28.1.6.11 A hub must respond with a Request Error to a Clear TT Buffer, Stop TT, Reset TT, or request with an incorrect wLength field.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.
Test description: TD-9.25.10 Get TT State Test; TD-9.25.11 Clear TT Buffer Test; TD-9.25.12 Stop TT Test; TD-9.25.13 Reset TT Test.

9.28.1.6.12 A hub must support the PING protocol on its control endpoint. This includes the possibility of a host that PINGs before attempting an OUT transaction.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 8.5.1.1.
Test description: Not available.

9.28.1.6.13 The bHubContrCurrent field in the hub descriptor must indicate the current draw of the hub circuitry from VBUS. It must not include the current draw of any embedded downstream devices.

Reference document: WLP# B.2.6.4.6. Note: This is currently a proposed erratum to the Universal Serial Bus Specification, Revision 2.0. The current (as of 3/29/02) specification does not clearly define the meaning of this field.
Test description: Not available.

9.28.1.6.14 A TT that has been stopped with a Stop TT command must continue to generate SOFs to enabled downstream ports under its control.

Reference document: WLP# B.2.6.4.6. Note: This is currently a proposed erratum to the Universal Serial Bus Specification, Revision 2.0. The current (as of 3/29/02) specification does not clearly define the meaning of this field.
Test description: TD-9.29.1.12 Stop TT Test

USB 2.0 Test Modes Assertions

9.28.1.7.1 A hub must place its upstream port in test mode TEST_J in response to a valid SET_FEATURE command with feature selector TEST_MODE and test selector Test_J.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.4.9.
Test description: TD-9.28.1.8 Upstream Port Test Mode Test

9.28.1.7.2 A hub must place its upstream port in test mode TEST_K in response to a valid SET_FEATURE command with feature selector TEST_MODE and test selector Test_K.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.4.9.
Test description: TD-9.28.1.8 Upstream Port Test Mode Test

9.28.1.7.3 A hub must place its upstream port in test mode TEST_SEO_NAK in response to a valid SET_FEATURE command with feature selector TEST_MODE and test selector Test_SEO_NAK.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.4.9.
Test description: TD-9.28.1.8 Upstream Port Test Mode Test

9.28.1.7.4 A hub must place its upstream port in test mode TEST_PACKET in response to a valid SET_FEATURE command with feature selector TEST_MODE and test selector Test_Packet.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.4.9.
Test description: TD-9.28.1.8 Upstream Port Test Mode Test

9.28.1.7.5 A hub must respond with a request error to a valid SET_FEATURE command with feature selector TEST_MODE and test selector Test_Force_Enable.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.4.9, 7.1.20.
Test description: TD-9.28.1.8 Upstream Port Test Mode Test

9.28.1.7.6 Once a hub has its upstream port in a test mode it must only exit the test mode if the power is cycled for the hub.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 7.1.20.
Test description: TD-9.28.1.8 Upstream Port Test Mode Test

9.28.1.7.7 A hub must transition a downstream port out of test mode in response to a reset.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.12.
Test description: TD-9.28.1.9 Downstream Port Test Mode Test

9.28.1.7.8 A hub with a downstream port in a test mode must still report port disconnects or port resume status changes for all other downstream ports.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.12.
Test description: TD-9.28.1.9 Downstream Port Test Mode Test

9.28.1.7.9 A downstream facing port that has been placed in a test mode may only exit the mode when the hub is reset.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 7.1.20.
Test description: TD-9.28.1.9 Downstream Port Test Mode Test

9.28.1.7.10 A hub must place the designated downstream facing port in test mode TEST_J in response to a valid SET_PORT_FEATURE command with feature selector PORT_TEST and test selector Test_J.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.12.
Test description: TD-9.28.1.9 Downstream Port Test Mode Test

9.28.1.7.11 A hub must place the designated downstream facing port in test mode TEST_K in response to a valid SET_PORT_FEATURE command with feature selector PORT_TEST and test selector Test_K.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.12.
Test description: TD-9.28.1.9 Downstream Port Test Mode Test

9.28.1.7.12 A hub must place the designated downstream facing port in test mode TEST_SEO_NAK in response to a valid SET_PORT_FEATURE command with feature selector PORT_TEST and test selector Test_SE0_NAK.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.12.
Test description: TD-9.28.1.9 Downstream Port Test Mode Test

9.28.1.7.13 A hub must place the designated downstream facing port in test mode TEST_PACKET in response to a valid SET_PORT_FEATURE command with feature selector PORT_TEST and test selector Test_Packet.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.12.
Test description: TD-9.28.1.9 Downstream Port Test Mode Test

9.28.1.7.14 A hub must place the designated downstream facing port in test mode TEST_Force_Enable in response to a valid SET_PORT_FEATURE command with feature selector PORT_TEST and test selector Test_Force_Enable.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.12.
Test description: TD-9.28.1.9 Downstream Port Test Mode Test

9.28.1.7.15 A downstream port in test mode Test_Force_Enable must still indicate disconnect events.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 7.1.20.
Test description: Not available.

9.28.1.7.16 A hub must respond with a request error (STALL) to a CLEAR_FEATURE command with feature selector TEST_MODE.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 9.4.1.
Test description: Not available.

9.28.1.7.17 A hub must respond with a request error (STALL) to a CLEAR_PORT_FEATURE command with feature selector PORT_TEST.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.24.2.2.
Test description: Not available.


Miscellaneous

Hub and Transaction Translator Requirements

9.28.1.8.1 If a transaction translator is receiving a packet at EOF2 of the downstream facing bus it must disable the downstream facing port that is currently transmitting.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.22.
Test description: Not available.

9.28.1.8.2 If the transaction translator is transmitting a packet near EOF1 of the downstream facing bus it must force and abnormal termination sequence as defined in Section 11.3.3 of the Universal Serial Bus Specification, Revision 2.0 and stop transmitting.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.22.
Test description: Not available.

9.28.1.8.3 A port with a high-speed device connected must still indicate high-speed operation through descriptors when it is suspended and the device reverts to full speed terminations.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.5.1.9.
Test description: TD-9.28.1.15 High Speed Device Connection During Suspend Test

9.28.1.8.4 If a hub misses Start-of-Frame (SOF) packets for three consecutive microframes when operating in a high speed environment it also loses synchronization for its full speed timers. Any transaction translators in operation must stop generating full speed SOF packets until synchronization is regained.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.
Test description: Not available.

9.28.1.8.5 Frame timers used by transaction translator units in hubs must maintain synchronization unless the hub microframe timer loses synchronization.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.
Test description: Not available.

9.28.1.8.6 If a hub misses Start-of-Frame (SOF) packets for three consecutive microframes when operating in a high speed environment it loses synchronization for its microframe timer and all related frame timers used by transaction translators.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.
Test description: Not available.

9.28.1.8.7 If a hub loses microframe synchronization its transaction translators must respond to periodic complete splits with results buffered in the periodic complete split pipeline.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.
Test description: Not available.

9.28.1.8.8 If a hub loses microframe synchronization its transaction translators must abort any buffered periodic start-split transactions in the periodic start split pipeline.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.
Test description: Not available.

9.28.1.8.9 If a hub loses microframe synchronization its high speed handler must ignore any high-speed periodic start splits.
9.28.1.8.10 If a hub loses microframe synchronization its transaction translators must stop issuing low speed keep alive on any low speed enabled ports.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.
Test description: Not available.

9.28.1.8.11 If a hub loses microframe synchronization, its transaction translators must stop issuing full speed SOFs on any full speed enabled downstream ports.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.
Test description: Not available.

9.28.1.8.12 If a hub loses microframe synchronization, its transaction translators must not start issuing any subsequent periodic full/low speed transactions.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.
Test description: Not available.

9.28.1.8.13 If a hub loses microframe synchronization, its high-speed handler must respond to any high speed start splits for bulk/control transactions normally. (NAK if buffers full – place transactions in available non-periodic buffers as it normally would.)

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.
Test description: Not available.

9.28.1.8.14 If a hub loses microframe synchronization it must respond normally to any complete splits for bulk/control transactions.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.
Test description: Not available.

9.28.1.8.15 If a hub loses microframe synchronization it must not issue any pending bulk/control transactions on the full/low speed bus. It must preserve the buffers for these transactions until synchronization is regained.
9.28.1.8.16 A hub must repeat all high speed traffic, including start and complete splits, to all high speed enabled downstream ports. In particular, a hub may not prevent split traffic from reaching a hub further downstream with a full or low speed device connected.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.22.2.
Test description: TD-9.25.16 Multiple Hub Tier Split Traffic Test

Bulk and Control (Non-Periodic) Transfers

The following assertions use the notation described in the Universal Serial Bus Specification, Revision 2.0 to describe the possible states of a buffer for a bulk or control transfer being executed through a transaction translator.

General

9.28.2.1.1 A transaction translator must have at least two bulk/control transaction buffers. Each one must be capable of holding the Start Split and related data for an OUT or data from the full/low speed bus for an IN.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.
Test description: TD-9.29.1.17 Number of Non-Periodic Buffers Test.

9.28.2.1.2 If the transaction translator has an available Non-Periodic buffer (not in the Ready/X or Pending state) the high speed handler must accept the Start Split for a bulk or control transaction.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.
Test description: TD-9.29.1.17 Number of Non-Periodic Buffers Test.

9.28.2.1.3 If the transaction translator does not have an available Non-Periodic buffer (not in the Ready/X or Pending state) the high speed handler must NAK the start split for a bulk or control transfer.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.
Test description: TD-9.29.1.17 Number of Non-Periodic Buffers Test.

9.28.2.1.4 If the high speed handler for a transaction translator times out or receives a CRC error anywhere in the <Start Split – Token – Data> sequence for a bulk or control transfer it must timeout and not buffer the transaction in one of its non-periodic buffers.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.
Test description: TD-9.29.1.17 Number of Non-Periodic Buffers Test.

9.28.2.1.5 If the high speed handler for a transaction translator times out or receives a bad CRC anywhere in the <Complete Split – Token> sequence it must time out and not respond.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: Not available.

9.28.2.1.6 If a full or low speed non-periodic transaction results in a NAK, STALL, or ACK response the transaction translator must update the transaction buffer to the corresponding status and must not retry the transaction.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: TD-9.29.1.20 Control Transaction Protocol Test; TD-9.25.21 Bulk Transaction Protocol Test.

9.28.2.1.7 A full or low speed non periodic transaction that produces a timeout or transaction error must be retried locally by the transaction translator.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: TD-9.29.1.26 Number of Local Retries Test.

9.28.2.1.8 A full or low speed non-periodic transaction must not be tried more than three times locally by the transaction translator.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: TD-9.29.1.26 Number of Local Retries Test.

9.28.2.1.9 A full or low speed non periodic transaction that has been tried three times locally by the transaction translator without success must be resolved to a STALL response.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: TD-9.29.1.26 Number of Local Retries Test.

9.28.2.1.10 The integrity of all data associated with non periodic transactions must be preserved as it is transferred into and out of any of the non-periodic buffer space used by the transaction translator.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: TD-9.29.1.22 Control Transaction Loopback Test; TD-9.25.23 Bulk Transaction Loopback Test.

Control Transactions

9.28.2.2.1 The high-speed handler for a transaction translator receives a Start Split for a control transfer to an endpoint. There is already a control transaction for that endpoint whose non-periodic buffer is in the pending or ready/x state. In this case, the transaction translator must respond with an ACK but disregard the information.*

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: TD-9.29.1.18 Control Transaction Retry Handling Test.

9.28.2.2.2 If the high speed handler for a transaction translator receives a Start Split for a control transfer and already has a non-periodic buffer in the old/x state for the same endpoint it must re-use the same buffer for the new transaction.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: Not available.

9.28.2.2.3 If the high speed handler for a transaction translator receives a Complete Split for a control transfer and has a non-periodic buffer for the same endpoint in the pending state it must respond with a NYET handshake.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: TD-9.29.1.22 Control Transaction Loopback Test

9.28.2.2.4 If the high speed handler for a transaction translator receives a complete split for a control transfer and does not have a non-periodic buffer for that endpoint it must respond with a STALL.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: TD-9.29.1.24 Control Transaction Unpaired Complete Split Test

9.28.2.2.5 The high-speed handler for a transaction translator receives a complete split for a control transfer. If it has a non-periodic buffer for the same endpoint in the ready/STALL state, it must return STALL and transition the buffer to the old/STALL state.*

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: TD-9.29.1.20 Control Transaction Protocol Test

9.28.2.2.6 If the high speed handler for a transaction translator receives a complete split for a control transfer and has a non periodic buffer for the same endpoint in the old/STALL state it must return STALL.*

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: TD-9.29.1.20 Control Transaction Protocol Test

9.28.2.2.7 The high speed handler for a transaction translator receives a complete split for a control OUT transfer. If it has a non-periodic buffer for the same endpoint in the ready/ACK state it must return ACK and transition the buffer to the old/ACK state.*

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: TD-9.29.1.22 Control Transaction Loopback Test

9.28.2.2.8 If the high speed handler for a transaction translator receives a complete split for a control OUT transfer and has a non-periodic buffer for the same endpoint in the old/ACK state it must return ACK.*

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: TD-9.29.1.22 Control Transaction Loopback Test

9.28.2.2.9 The high speed handler for a transaction translator receives a complete split for a control IN transfer. If it has a non-periodic buffer for the same endpoint in the ready/DataX state it must return DataX and transition the buffer to the old/DataX state.*

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: TD-9.29.1.22 Control Transaction Loopback Test

9.28.2.2.10 If the high speed handler for a transaction translator receives a complete split for a control IN transfer and has a non periodic buffer for the same endpoint in the old/Data state it must return Data.*

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: TD-9.29.1.22 Control Transaction Loopback Test

9.28.2.2.11 The high speed handler for a transaction translator receives a complete split for a control transfer. If it has a non-periodic buffer for the same endpoint in the ready/NAK state it must return NAK and transition the buffer to the old/NAK state.*

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: TD-9.29.1.20 Control Transaction Protocol Test

9.28.2.2.12 If the high-speed handler for a transaction translator receives a complete split for a control transfer and has a non periodic buffer for the same endpoint in the old/NAK state, it must return NAK.*

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: TD-9.29.1.20 Control Transaction Protocol Test

9.28.2.2.13 A transaction translator must correctly handle full speed control transfers in both directions of up to 64 bytes.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: TD-9.29.1.22 Control Transaction Loopback Test

9.28.2.2.14 A transaction translator must correctly handle low speed control transfers in both directions of up to 8 bytes.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: TD-9.29.1.22 Control Transaction Loopback Test

* Note The USB core specification stipulates that direction should not be checked as part of buffer matching for control endpoints. Some vendors have implemented checking that does not match for Setup/In, Setup/Out, Out/In mismatches. These implementations are also acceptable.

Bulk Transactions

9.28.2.3.1 The high speed handler for a transaction translator receives a Start Split for a bulk transfer. If there is already a buffer for that endpoint and direction already in the pending or ready/x state it must respond with an ACK but disregard the information.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: TD-9.29.1.19 Bulk Transaction Retry Handling Test

9.28.2.3.2 The high speed handler for a transaction translator receives a Start Split for a bulk transfer. If it already has a non-periodic buffer for that endpoint and direction in the old/x state it must re-use the same buffer for the new transaction.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: Not available

9.28.2.3.3 The high speed handler for a transaction translator receives a Complete Split for a bulk transfer. If it already has a non-periodic buffer for the same endpoint and direction that is in the pending state it must respond with a NYET handshake.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: TD-9.29.1.23 Bulk Transaction Loopback Test

9.28.2.3.4 The high speed handler for a transaction translator receives a complete split for a bulk transfer. If it does not have a non-periodic buffer for that endpoint and direction it must respond with a STALL.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: TD-9.29.1.25 Bulk Transaction Unpaired Complete Split Test

9.28.2.3.5 The high speed handler for a transaction translator receives a complete split for a bulk transfer. If it has a non-periodic buffer for the same endpoint and direction in the ready/STALL state it must return STALL and transition the buffer to the old/STALL state.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: TD-9.29.1.21 Bulk Transaction Protocol Test

9.28.2.3.6 If the high speed handler for a transaction translator receives a complete split for a bulk transfer and has a non periodic buffer for the same endpoint and direction in the old/STALL state it must return STALL.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: TD-9.29.1.21 Bulk Transaction Protocol Test

9.28.2.3.7 The high speed handler for a transaction translator receives a complete split for a bulk out transfer. If it has a non-periodic buffer for the same endpoint and direction in the ready/ACK state it must return ACK and transition the buffer to the old/ACK state.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: TD-9.29.1.23 Bulk Transaction Loopback Test

9.28.2.3.8 If the high speed handler for a transaction translator receives a complete split for a bulk out transfer and has a non periodic buffer for the same endpoint and direction in the old/ACK state it must return ACK.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: TD-9.29.1.23 Bulk Transaction Loopback Test

9.28.2.3.9 I The high speed handler for a transaction translator receives a complete split for a bulk in transfer. If it has a non-periodic buffer for the same endpoint and direction in the ready/Data state it must return Data and transition the buffer to the old/Data state.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: TD-9.29.1.23 Bulk Transaction Loopback Test

9.28.2.3.10 If the high speed handler for a transaction translator receives a complete split for a bulk in transfer and has a non periodic buffer for the same endpoint and direction in the old/DataX state it must return DataX.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: TD-9.29.1.23 Bulk Transaction Loopback Test

9.28.2.3.11 The high speed handler for a transaction translator receives a complete split for a bulk transfer. If it has a non-periodic buffer for the same endpoint and direction in the ready/NAK state it must return NAK and transition the buffer to the old/NAK state.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: TD-9.29.1.21 Bulk Transaction Protocol Test

9.28.2.3.12 If the high speed handler for a transaction translator receives a complete split for a bulk transfer and has a non periodic buffer for the same endpoint and direction in the old/NAK state it must return NAK.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.17.1.
Test description: TD-9.29.1.21 Bulk Transaction Protocol Test

9.28.2.3.13 A transaction translator must correctly handle full speed bulk transfers in both directions of up to 64 bytes.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Chapter 5, 11.
Test description: TD-9.29.1.23 Bulk Transaction Loopback Test

Isochronous and Interrupt (Periodic) Transfers

In the following assertions, the high-speed bus microframes are referenced as follows:

| Y0 | Y1 | Y2 | Y3 | Y4 | Y5 | Y6 | Y7 |

Frame X-1 Frame X

9.28.3.1.1 A transaction translator must be able to receive and correctly buffer up to 16 start splits for periodic transfers in a single microframe.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.18.4.
Test description: TD-9.29.1.27 Start Split Pipeline Size Test

9.28.3.1.2 When the high speed handler of a transaction translator receives a valid Start Split for a periodic transaction, it must place the start split into the start split pipeline.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.18.4.
Test description: TD-9.29.1.27 Start Split Pipeline Size Test, TD-9.29.1.28 Interrupt Transaction Protocol Test, TD-9.29.1.29 Isochronous Transaction Protocol Test, TD-9.29.1.30 Interrupt Transaction Loopback Test

9.28.3.1.3 The high speed handler must accept and handle all valid Start Splits for periodic transfers received in any microframe except during microframe Y6.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.18.5.
Test description: TD-9.30.1.32 Interrupt IN Microframe Boundary Test, TD-9.30.1.33 Isochronous IN Microframe Boundary Test

9.28.3.1.4 The transaction translator must not start any periodic transaction on the full/low speed bus during the same microframe the Start Split for that transaction arrived.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.18.5.
Test description: TD-9.29.1.28 Interrupt Transaction Protocol Test, TD-9.29.1.29 Isochronous Transaction Protocol Test

9.28.3.1.5 The transaction translator (high speed handler) must never send any response packet to a periodic start split.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.18.5.
Test description: Not available

9.28.3.1.6 The transaction translator (high speed handler) must place periodic start splits in the start split pipeline in the order in which they are received.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.20.3.
Test description: TD-9.29.1.27 Start Split Pipeline Size Test

9.28.3.1.7 The transaction translator (high speed handler) must execute periodic transactions on the full/low speed bus in the same order as the start splits in the microframe pipeline.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.20.3.
Test description: TD-9.29.1.27 Start Split Pipeline Size Test

Abort Rules – Section 11.18.6.1

9.28.3.2.1 If a full or low speed periodic transaction is in progress when EOF occurs, it must be aborted by the transaction translator.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.1.
Test description: 9.30.1.34 Periodic Abort Rules Test

9.28.3.2.2 If an interrupt transaction is in progress and the microframe timer indicates microframe X+4, where X is the microframe in which the start split for the transaction arrived, it must be aborted.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.1.
Test description: 9.30.1.34 Periodic Abort Rules Test

9.28.3.2.3 If a periodic transaction is aborted it must not have a complete split response in the complete split stage pipeline. This means that the transaction translator will respond with a NYET to any Complete Splits for the transaction.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.1.
Test description: 9.30.1.34 Periodic Abort Rules Test

9.28.3.2.4 When a transaction translator aborts a periodic IN transaction, it must not issue the handshake packet for the transaction on the full/low speed bus.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.1.
Test description: Not available

9.28.3.2.5 When a transaction translator aborts an OUT transaction and is in the middle of a DATA packet, it must stop issuing data bytes and force a bit stuffing error on the downstream facing bus.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.1.
Test description: Not available

Free Rules – Section 11.18.6.2

9.28.3.3.1 If a periodic start split received in microframe X has still not been executed when the microframe timer indicates the X+4 microframe it must be removed from the start split pipeline.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.2.
Test description: TD-9.30.1.35 Periodic Free Rules Test

9.28.3.3.2 All start splits in the start split pipeline for unexecuted transfers, except those received in microframe Y7 must be removed from the start split pipeline at the beginning of a new full speed frame.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.2.
Test description: TD-9.30.1.35 Periodic Free Rules Test

9.28.3.3.3 The entry for a transaction in the periodic Complete Split pipeline must only live for one microframe after the transaction is executed on the full/low speed bus. At the beginning of the second microframe after the execution the buffer space in the complete split transaction pipeline must be freed for re-use.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.18.7.
Test description: TD-9.30.1.36 Complete Split Pipeline Free Test

Complete-Split Pipeline Search Rules – Section 11.18.8

9.28.3.4.1 If the high speed handler for a transaction translator receives a periodic complete split that matches the first entry of the complete split pipeline the handler must respond with the indicated data and/or status.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.18.8.
Test description: TD- 9.29.1.30 Interrupt Transaction Loopback Test, TD-9.29.1.31 Isochronous Transaction LoopBack Test

9.28.3.4.2 The high speed handler for a transaction translator receives a periodic complete split that matches the first entry in the complete split pipeline multiple times. In this case it must continue to respond with the indicated data and/or status until it receives a periodic complete split for a different transaction.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.18.8.
Test description: Not available

9.28.3.4.3 If the high speed handler receives a complete split for a periodic transaction that does not match the first entry in the complete split pipeline it must search all other entries in the complete split pipeline.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.18.8.
Test description: TD-9.30.1.37 Out Of Order Complete Split Test

9.28.3.4.4 The high speed handler receives a complete split for a periodic transaction that does not match the first entry in the complete split pipeline and does not find a match in the pipeline. In this case it must return the pipeline to its state at the start of the search and return NYET.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.18.8.
Test description: TD-9.30.1.37 Out Of Order Complete Split Test

9.28.3.4.5 If the high speed handler receives a complete split for a periodic transaction that does not match the first entry in the complete split pipeline it must search all other entries. If it finds a match it must advance the pipeline to the matching transaction and free all entries it passes in the advance. It must return the status and/or data for the matching entry.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.18.8.
Test description: TD-9.30.1.37 Out Of Order Complete Split Test

9.28.3.4.6 If the high-speed handler receives a first periodic complete split for a transaction and has not finished searching the periodic complete split pipeline for a match, it must not respond to the complete split and continue to search for the match. It must respond correctly to the next complete split for the transaction.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.18.8.
Test description: TD-9.30.1.37 Out Of Order Complete Split Test

9.28.3.4.7 The transaction translator must not start a periodic transaction until it has space available in the complete split pipeline stage to hold the results of the transaction.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.18.6.3.
Test description: Not available

Interrupt Transactions – Sections 11.20.x

9.28.3.5.1 A transaction translator must never locally retry an interrupt transfer on the full/low speed bus.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.20.
Test description: TD-9.29.1.27 Start Split Pipeline Size Test

9.28.3.5.2 If the high speed handler for a transaction translator receives a complete split for an interrupt transfer and has a periodic complete split pipeline entry for the same endpoint and direction in the old/NAK state it must return NAK.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.
Test description: TD-9.29.1.28 Interrupt Transaction Protocol Test

9.28.3.5.3 If the high speed handler for a transaction translator receives a complete split for an interrupt transfer and has a periodic complete split pipeline entry for the same endpoint and direction in the old/STALL state it must return STALL.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.
Test description: TD-9.29.1.28 Interrupt Transaction Protocol Test

9.28.3.5.4 The high speed handler for a transaction translator receives a complete split for an interrupt transfer. If it has a periodic complete split pipeline entry for the same endpoint and direction in the old/trans_err state it must return ERR.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.
Test description: TD-9.29.1.28 Interrupt Transaction Protocol Test

9.28.3.5.5 If the high speed handler for a transaction translator receives a complete split for an interrupt OUT transfer and has a periodic complete split pipeline entry for the same endpoint and direction in the old/ACK state it must return ACK.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.
Test description: TD-9.29.1.30 Interrupt Transaction Loopback Test

9.28.3.5.6 The high speed handler for a transaction translator receives a complete split for an interrupt IN transfer. If it has a periodic complete split pipeline entry for the same endpoint and direction in the old/DATAX state it must return DATAX.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.
Test description: TD-9.29.1.30 Interrupt Transaction Loopback Test

9.28.3.5.7 The high speed handler for a transaction translator receives a complete split for an interrupt IN transfer. If it has a periodic complete split pipeline entry for the same endpoint and direction in the old/MDATA state it must return MDATA.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.
Test description: TD-9.30.1.32 Interrupt IN Microframe Boundary Test

9.28.3.5.8 If the full/low speed CRC check fails, an ERR handshake must be returned to the host for the transaction by the transaction translator. No data can be returned for the current microframe.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.
Test description: TD-9.29.1.28 Interrupt Transaction Protocol Test

9.28.3.5.9 The full/low speed CRC must not be returned in response to a complete split for an interrupt IN transaction.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.
Test description: TD-9.29.1.30 Interrupt Transaction Loopback Test, TD-9.30.1.32 Interrupt IN Microframe Boundary Test

9.28.3.5.10 The full/low speed interrupt IN transaction is still in progress at a microframe boundary and at least 3 data bytes have been received. In this case, the transaction translator must update the appropriate complete split pipeline entry with the current data except the latest two bytes and place the entry in the old/MDATA state. It must not perform a full/low speed CRC check. The transaction translator is allowed to carry forward up to the last 6 bytes in the microframe (2 bytes for the potential CRC plus up to an additional 4 bytes).

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.20.4. (Currently pending in proposed errata as of 6/26/2001.)
Test description: TD-9.30.1.32 Interrupt IN Microframe Boundary Test

9.28.3.5.11 The full/low speed interrupt IN transaction is still in progress at a microframe boundary and less than 3 data bytes have been received. In this case the transaction translator must return NYET to the corresponding complete split. The transaction translator may return NYET and carry forward up to the first 6 data bytes.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.20.4. (Currently pending in proposed errata as of 6/26/2001.)
Test description: Not available

9.28.3.5.12 A transaction translator returns MDATA for the complete split for an Interrupt IN. It must return the remaining data with the appropriate DATA0/1 PID or ERR if the CRC check fails in response to the next complete split for that endpoint and direction.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.20.4.
Test description: Not available

9.28.3.5.13 The transaction translator high speed handler receives a CRC error, bit stuffing error, or timeout in the Start Split – IN sequence for an interrupt IN transaction. In this case it must disregard the start split and not place it into the Start Split microframe pipeline.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.21.1.
Test description: Not available

9.28.3.5.14 The transaction translator high speed handler receives a CRC error, bit stuffing error, or timeout in the Start Split – OUT – DATA/X sequence for an interrupt OUT transaction. In this case it must disregard the start split and not place it into the Start Split microframe pipeline.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.21.1.
Test description: Not available

9.28.3.5.15 If the full/low speed transaction completes before the end of a microframe (no matter how close to the end) the transaction translator must return all data in response to the complete split in the next microframe.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.21.1.
Test description: Not available

Isochronous Transactions – Sections 11.21.x

9.28.3.6.1 A transaction translator must never locally retry an isochronous transfer on the full/low speed bus.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.21.1.
Test description: TD-9.29.1.27 Start Split Pipeline Size Test

9.28.3.6.2 The high speed handler for a transaction translator receives a timeout, bit stuffing error, or CRC error in the Start Split-all – OUT – DATA sequence for an isochronous OUT. In this case it must disregard the start split and not attempt the transaction on the full/low speed bus.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.21.1.
Test description: Not available

9.28.3.6.3 If the high speed handler for a transaction translator receives a timeout, bit stuffing, or CRC error anywhere in the Start Split-begin – OUT – DATA sequence for an isochronous OUT it must disregard the Start Split and not attempt the transaction on the full/low speed bus.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.
Test description: Not available

9.28.3.6.4 The high speed handler receives an error or times out in the Start Split-begin – OUT – DATA sequence. In this case it must disregard any subsequent Start Split-middles or Start Split-ends for the same endpoint until it receives a Start Split-begin or any Start Split for a different endpoint.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.
Test description: Not available

9.28.3.6.5 The transaction translator must generate the full/low speed CRC for all Isochronous OUT transactions that it generates.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.
Test description: TD-9.29.1.30 Interrupt Transaction Loopback Test

9.28.3.6.6 If the transaction translator receives a Start Split-begin for an Isochronous OUT transaction it must start the transaction on the full/low speed bus and continue to look for isochronous OUT start splits to the same endpoint in each subsequent microframe.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.
Test description: TD-9.29.1.30 Interrupt Transaction Loopback Test

9.28.3.6.7 The transaction translator does not receive a Start Split-middle or Start Split-end in a successive microframe after receiving a Start Split-begin for an isochronous OUT endpoint. In this case, it must force a bit stuff error in full/low speed transaction.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.
Test description: TD-9.30.1.38 Out Of Order Start Split Test

9.28.3.6.8 The high speed handler does not receive a Start Split-middle or Start Split-end in an expected microframe. In this case it must disregard any subsequent Start Split-middles or Start Split-ends for the same endpoint until it receives a Start Split-begin or any Start Split for a different endpoint.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.
Test description: TD-9.30.1.38 Out Of Order Start Split Test

9.28.3.6.9 The transaction translator receives a Start Split-middle or Start Split-end with a bad CRC in a successive microframe after receiving a Start Split-begin for an isochronous OUT endpoint. In this case it must force a bit stuffing error on the full/low speed transaction.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.
Test description: Not available

9.28.3.6.10 If the high speed handler receives a Start Split-middle or Start Split-end with an error it must disregard any subsequent Start Split-middles or Start Split-ends for the same endpoint until it receives a Start Split-begin or any Start Split for a different endpoint.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.
Test description: Not available

9.28.3.6.11 The high speed handler receives a Start Split-middle or Start Split-end for an Isochronous OUT transaction and does not already have a full/low speed transaction pending for that endpoint. In this case, it must disregard that Start Split and any subsequent Start-Split middles or Start Split-ends for the same endpoint until it receives a Start Split-begin or any Start Split for a different endpoint.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.21.3.
Test description: TD-9.30.1.38 Out Of Order Start Split Test

9.28.3.6.12 The transaction translator high speed handler receives a CRC error, bit stuffing error, or timeout anywhere in the Start Split – IN sequence for an isochronous IN transaction it must disregard the start split and not place it into the Start Split microframe pipeline.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.21.1.
Test description: Not available

9.28.3.6.13 The transaction translator must never return the full/low speed CRC as part of the data for an isochronous IN transaction.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.21.4.
Test description: TD-9.29.1.31 Isochronous Transaction Loopback Test

9.28.3.6.14 The high speed handler for a transaction translator receives a complete split for an isochronous IN transfer. If it has a periodic complete split pipeline entry for the same endpoint and direction in the old/DATAX state it must return DATAX.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.
Test description: TD-9.29.1.31 Isochronous Transaction Loopback Test

9.28.3.6.15 The high speed handler for a transaction translator receives a complete split for an isochronous IN transfer and has a periodic complete split pipeline entry for the same endpoint and direction in the old/Trans_err state. It must return ERR.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.20.1.
Test description: TD-9.29.1.29 Isochronous Transaction Protocol Test

9.28.3.6.17 A full speed isochronous IN transaction is still in progress at a microframe boundary and at least three data bytes have been received. In this case, the transaction translator must update the appropriate complete split pipeline entry with the current data except the latest two bytes and place the entry in the old/MDATA state. It must not perform a full speed CRC check. The transaction translator is allowed to carry forward up to the last 6 bytes in the microframe (2 bytes for the potential CRC plus up to an additional 4 bytes).

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.20.4. (Currently pending in proposed errata as of 6/26/2001.)
Test description: TD-9.30.1.33 Isochronous IN Microframe Boundary Test

9.28.3.6.18 New v0.9] A full speed isochronous IN transaction is still in progress at a microframe boundary and less than 3 data bytes have been received. The transaction translator must return NYET to the corresponding complete split. The transaction translator may return NYET and carry forward up to the first 6 data bytes.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.20.4. (Currently pending in proposed errata as of 6/26/2001.)
Test description: Not available

9.28.3.6.19 If the full/low speed transaction completes before the end of a microframe (no matter how close to the end) the transaction translator must return all data in response to the complete split in the next microframe.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.21.1.
Test description: Not available

9.28.3.6.20 The TT high-speed handler must return isochronous data with the same data toggle used by the device. Alternately, the TT high speed handler may always use DATA0.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, proposed errata as of 3/29/02.
Test description: Not available


General Transaction Translator (HUB) Data Integrity

General Host Controller Interaction Assertions

9.28.3.7.1 A USB 2.0 hub must not corrupt data moving from a host system to any USB device.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Chapter 11.
Test description: TD-9.29.1.22 Control Transaction Loopback Test, TD-9.29.1.23 Bulk Transaction Loopback Test, TD-9.29.1.30 Interrupt Transaction Loopback Test, TD-9.29.1.31 Isochronous Transaction Loopback Test

9.28.3.7.2 A USB 2.0 hub must not corrupt data moving from any USB device into the host.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Chapter 11.
Test description: TD-9.29.1.22 Control Transaction Loopback Test, TD-9.29.1.23 Bulk Transaction Loopback Test, TD-9.29.1.30 Interrupt Transaction Loopback Test, TD-9.29.1.31 Isochronous Transaction Loopback Test


Transaction Translator Full/Low Speed Transaction Scheduling

Transaction Scheduling Assertions

9.28.3.8.1 The transaction translator full/low speed handler must start executing the next periodic full/low speed transaction for the current microframe whenever it is idle.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.14.2.3.
Test description: TD-9.29.1.30 Interrupt Transaction Loopback Test, TD-9.29.1.31 Isochronous Transaction Loopback Test

9.28.3.8.2 Whenever the transaction translator full/low speed handler is idle, and there are no periodic transactions available, it must execute an available non-periodic transaction selected in round robin fashion. It must only execute a non-periodic transaction if it can be finished before the end of the current full speed frame. For IN transactions this calculation must be made using the maximum transaction size.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Section 11.14.2.3.
Test description: TD-9.30.1.39 Non-Periodic Bandwidth Reclamation Test


Multiple Stream Interoperability

Transaction Scheduling Assertions

9.28.3.9.1 The transaction translator must correctly process all valid combinations of periodic and non-periodic transactions running in unison.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Chapter 11.
Test description: TD-9.30.1.40 Mixed Stream Interoperability Test

9.28.3.9.2 The transaction translator must correctly process all valid combinations of non-periodic transactions running in unison.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Chapter 11.
Test description: TD-9.30.1.40 Mixed Stream Interoperability Test

9.28.3.9.3 The transaction translator must correctly process all valid combinations of periodic transactions running in unison.

Reference document: WLP# B.2.6.4.6; Universal Serial Bus Specification, Revision 2.0, Chapter 11.
Test description: TD-9.30.1.40 Mixed Stream Interoperability Test


USB Test Descriptions

This section includes an overview of each test, hardware and software setup, test execution instructions, and test results interpretation.


TD-9.1 USB System Hub and Port Presence Test Description

Assertion 9.1 superseded by assertion 9.1.A1

See test description, TD-9.10 USB System Port Presence Test


TD-9.2 USB BIOS USB Keyboard Support Test

Assertion 9.1.2 superseded by assertion 9.1.A2

See test description, TD-9.17 USB BIOS Support Test.


TD-9.3 USB System Wake Capability Test

Assertion 9.1.5 superseded by assertion 9.1.B5.

See test description, TD-9.13 USB System Wake Capabilities Test.


TD-9.4 USB Hub Specification 1.0/1.1 Compliance Test

Assertion 9.1.8 superseded by assertion 9.1.C1.

See test description, TD-9.11 USB Specification Compliance Test.


TD-9.5 USB Port Power Switching Test Description

Overview

This test insures hubs that are BUS powered provide ports that are individually power switched. This information is determined by examining all of the hubs attached to the system and then checking their descriptors to see if they are bus powered and if so, validating that the ports are capable of supporting individual power switching.

Note: In PC 2001 System Design Guide, bus powered hubs are only allowed if they are integrated into USB keyboards or mobile systems.

Overview of Test Steps

Following a clean installation of the operating system, the system is booted. Clean means there has been no manipulation of the operating system USB drivers. A test peripheral device is attached to each hub port. The test device must be bus powered and provide an LED or some other visible signal that indicates when it is receiving power. A root hub that is compliant with PC 2001 requirements is enumerated and registered by the operating system. The test program queries the USB hub through the USB software stack to determine whether it is bus or self-powered. The test software issues a Configuration GetDescriptor to get the configured capabilities of the hub. The following fields are returned and examined:

Offset | Field | Description
8 | MaxPower | Maximum power consumption of the device from USB hub
7 | bMAttributes | D6: Self-powered

The test software also issues a GetStatus command to the hub. Bit zero of the returned status word is the self –powered bit of the device status. Taken together these three pieces of information have the following interpretation:

Case | Max Power | Self Powered | Hub Device Status (D0) | Explanation
1 | 0 | 0 | 0 or 1 | N/A. This is an illegal set of information
2 | 0 | 1 | 0 | N/A. A device that is only self-powered, but does not have local power cannot connect to the Bus and communicate.
3 | 0 | 1 | 1 | Self-powered only hub and local power supply is good.
4 | >0 | 0 | 0 or 1 | Bus-powered only hub.
5 | >0 | 1 | 0 | Hub capable of both self- and bus-powered operating modes. It is currently only available as a bus-powered hub.
6 | >0 | 1 | 1 | Hub capable of both self- and bus-powered operating modes. It is currently available as a self-powered hub.

If the hub is a bus powered only or a dual power mode hub operating as bus-powered, then the port power switching capability is examined for compliance. If the hub is self-powered, then the device is not tested with regard to its port power switching capabilities.

The device descriptor for any bus-powered hub is returned by issuing a Device GET_DESCRIPTOR command. The following fields are examined by the test software:

Offset | Field | Description
1 | bDescriptorType | 29h Indicates a hub descriptor
2 | bNumberPorts | Number of downstream ports that this hub supports
7 | wHubCharactaristics | D1:D0 – 01 indicates individual port power switching

The descriptor must be 29h indicating that the device is a hub. The D1:D0 fields must be set to indicate that the hub supports individual port power switching.

After determining that bus powered hubs properly provide individual port power switching, the test software drive the ports through their individual power states. The port is moved to the powered off state if it is not in that state by issuing a ClearPortFeature command with the PORT_POWER feature selected. This causes the port to be placed in the powered off state and should result in power being removed from the port. The test software then requests that a device be attached to each of the ports in sequence so that all ports individually run through the following procedure:

  1. Attach USB bus powered device to port.
  2. Test administrator observes that the USB device attached to the port does not have power applied to it as indicated by the LED on the test peripheral device.
  3. Power turned on to port through the issuance of a Set Port Feature command with the PORT_POWER feature selected.
  4. Test administrator observes that the USB device attached to the port does have power applied to it and that the non-selected ports do not have power applied to them.
  5. Power turned off to port through the issuance of a ClearPortFeature command with the PORT_POWER feature selected.
  6. Test administrator observes that the USB device attached to the port does not have power applied to it.

The hub topology of the system is hierarchically traversed, and each hub attached to the system is tested in the same manner.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The system must be configured with a USB host controller and at least two ports. There should be no devices attached to any of the hubs in the system to be tested. The test operator will be instructed to attach USB powered devices to the ports on the hubs as the test progresses.

The test requires the following hardware and software:

  • Windows Millennium Edition, Windows 2000, or later versions of a Windows based OPERATING SYSTEMS
  • PC 2001 System Design Guide compliant USB host controller and supporting drivers

Results Interpretation

Individual pass/fail indication is provided for each test category of hub and port capabilities.

The following condition causes test failures:

  • Hub is USB bus powered but does not indicate port power switching capability.
  • Devices attached to hubs receive power in the port power off state.

The following advisory information is provided as applicable.

  • Content of hub descriptor.
  • Content of each port descriptor.


TD-9.6 USB Hub Power Management Test Description

Overview

This test insures that USB hub devices properly implement the power management functionality as described in the Universal Serial Bus Specification 1.1. This specification requires that USB hub devices support the same power management operations and states as any other type of USB peripheral device. The hub is driven through these states and its power management functionality is checked for correctness. USB hubs are also required to implement proper port and device power management functions specific to hubs, which include transitioning out of suspend states in response to remote wakeup, connect and disconnect events. A USB topology may have many hubs attached and each hub’s operation is verified by the described sequence of tests. The particular hub that is currently being exercised by the test is called the target hub.

Overview of Test Steps

Following a clean installation of the operating system, the system is booted. Clean in this case means that there has been no manipulation or use of the USB subsystem prior to the running of the USB tests.

A root hub device that is compliant with the current Windows Logo Program requirements is enumerated and registered by the operating system load. The test software applies the described test procedure to this hub and to any other hubs found by descending the USB topology tree.

Hub Suspend and Resume

The test software prompts the test operator to attach a USB peripheral device to one of the target hub’s ports and then enables and places that port into Suspended state. All other ports on the target hub are placed in the Powered On state. The test software issues a USB suspend command to the HCI which places the host controller into the USBSuspend state and quiesces the entire USB resulting in the hub entering suspend state.

The test software then resumes the hub by issuing a USB resume command to the HCI, which places the USB into USBOperational state. A Device GetHubStatus command is then issued to the hub to verify that it is been enabled. The status of the ports on the target hub are examined by issuing a Device GetPortStatus command and the resulting status is compared with the pre-suspend states to check that they match.

Hub Suspend and Respond to Device Connection

The test software determines whether the target hub supports remote wakeup by issuing a Device GET_CONFIGURATION command and examining the D5 bit in the bmAttributes field. If remote wakeup is supported, the test software enables remote wakeup on the target hub by issuing a Device SetFeature with the DEVICE_REMOTE_WAKEUP flag set. The test software issues a USB suspend command to the HCI resulting in a transition to USBSuspend.

The test software then prompts the test operator to connect a USB peripheral device into a port on the target hub. Following the device connection, the test software verifies that the USB status is USBOperational indicating that resume processing has succeeded.

A Device GetHubStatus command is then issued to the hub to verify that it is been enabled. The status of the port that received the connect event is examined by issuing a GetPortStatus command for the designated port. The port should show the following bits in the status field:

Field | Value
PORT_CONNECTION | Connected
PORT_ENABLE | Enabled
PORT_SUSPEND | Not Suspended
PORT_OVER_CURRENT | No Overcurrent
PORT_RESET | No Reset
PORT_POWER | Powered On
PORT_LOW_SPEED | Device Dependent

The port should show the following bits in the status change field:

Field | Value
C_PORT_CONNECTION | Changed
C_PORT_ENABLE | Not Changed
C_PORT_SUSPEND | Not Changed
C_PORT_OVER_CURRENT | Not Changed
C_PORT_RESET | Not Changed

The status of the remaining ports on the target hub are examined by issuing a Device GetPortStatus command and the resulting status is compared with the pre-suspend states to check that they match.

Hub Suspend and Respond to Device Disconnect

The test software determines whether the target hub supports remote wakeup by issuing a Device GetConfiguration command and examining the D5 bit in the bmAttributes field. If remote wakeup is supported, the test software enables remote wakeup on the target hub by issuing a Device SetFeature with the DEVICE_REMOTE_WAKEUP flag set.

The test operator is prompted to connect a USB peripheral device to a port on the target hub. The port is placed in the Enabled state. All other ports on the target hub are placed in the Powered On state.

The test software issues a USB suspend command to the HCI resulting in a global transition to USBSuspend.

The test software then prompts the user to disconnect a USB peripheral device from the target hub. The test software verifies that that the USB status is USBOperational indicating that resume processing has succeeded.

A Device GetHubStatus command is then issued to the hub to verify that it has been enabled. The status of the port that received the disconnect event is examined by issuing a GetPortStatus command for the designated port. The port should show the following bits in the status field:

Field | Value
PORT_CONNECTION | Not Connected
PORT_ENABLE | Not Enabled
PORT_SUSPEND | Not Suspended
PORT_OVER_CURRENT | No Overcurrent
PORT_RESET | No Reset
PORT_POWER | Powered On
PORT_LOW_SPEED | N/A

The port should show the following bits in the status change field:

Field | Value
C_PORT_CONNECTION | Changed
C_PORT_ENABLE | Not Changed
C_PORT_SUSPEND | Not Changed
C_PORT_OVER_CURRENT | Not Changed
C_PORT_RESET | Not Changed

The status of the remaining ports on the target hub are examined by issuing a Device GetPortStatus command and the resulting status is compared with the pre-suspend states to check that they match.

Hub Suspend and Remote Wakeup Processing

The test software determines whether the hub supports remote wakeup by issuing a Device GET_CONFIGURATION command and examining the D5 bit in the bmAttributes field. If remote wakeup is supported, the test software continues with the following procedure. The test software prompts the test operator to connect a USB peripheral device that supports remote wakeup into a port on the target hub. The USB peripheral device and the target hub are both enabled for remote wakeup support by issuing a Device SetFeatures command with the DEVICE_REMOTE_WAKEUP flag set. All other ports on the target hub are placed in the Powered On state.

The test software issues a USB suspend command to the HCI resulting in a global transition to USBSuspend.

The type and invocation of external stimulus that awakens the USB peripheral device and causes it to force its port circuitry through resume signaling is device dependent. The test software asks the test operator to provide such stimulus and indicate that such stimulus has been provided. In response to such stimulus, the port that the USB peripheral device has been attached to should be taken out of the suspend mode and the test software verifies that the USB status is USBOperational. A Device GetHubStatus command is then issued to the hub to verify that it has been enabled. The status of port that received the remote wakeup event is examined by issuing a GetPortStatus command for the designated port. The port should show the following bits in the status field:

Field | Value
PORT_CONNECTION | Connected
PORT_ENABLE | Enabled
PORT_SUSPEND | Not Suspended
PORT_OVER_CURRENT | No Overcurrent
PORT_RESET | No Reset
PORT_POWER | Powered On
PORT_LOW_SPEED | Device Dependent

The port should show the following bits in the status change field:

Field | Value
C_PORT_CONNECTION | Not Changed
C_PORT_ENABLE | Not Changed
C_PORT_SUSPEND | Not Changed
C_PORT_OVER_CURRENT | Not Changed
C_PORT_RESET | Not Changed

The status of the remaining ports on the target hub are examined by issuing a Device GetPortStatus command and the resulting status is compared with the pre-suspend states to check that they match.

Hub Suspend and Ignore Device Connection

The test software determines whether the target hub supports remote wakeup by issuing a Device GET_CONFIGURATION command and examining the D5 bit in the bmAttributes field. If remote wakeup is supported, the test software disables remote wakeup on the target hub by issuing a Device ClearFeature with the DEVICE_REMOTE_WAKEUP flag set. The test software issues a USB suspend command to the HCI resulting in a transition to USBSuspend.

The test software then prompts the test operator to connect a USB peripheral device into a port on the target hub. Following the device connection, the test software verifies that the USB status is USBSuspend indicating that resume processing has not occurred.

Hub Suspend and Ignore Device Disconnect

The test software determines whether the target hub supports remote wakeup by issuing a Device GetConfiguration command and examining the D5 bit in the bmAttributes field. If remote wakeup is supported, the test software disables remote wakeup on the target hub by issuing a Device ClearFeature with the DEVICE_REMOTE_WAKEUP flag set.

The test operator is prompted to connect a USB peripheral device to a port on the target hub. The port is placed in the Enabled state. All other ports on the target hub are placed in the Powered On state.

The test software issues a USB suspend command to the HCI resulting in a global transition to USBSuspend.

The test software then prompts the user to disconnect a USB peripheral device from the target hub. The test software verifies that that the USB status is USBSuspend indicating that resume processing has not occurred.

Port Suspend and Resume

The test software prompts the test operator to attach USB peripheral devices to all ports on the target hub. All ports on the target hub are first placed into the Enable state and then moved to the Suspended state with the use of the SetPortFeature command.

The test software then resumes the port by issuing a ClearPortFeature with the PORT_SUSPEND flag set. The port should show the following bits in the status field:

Field | Value
PORT_CONNECTION | Connected
PORT_ENABLE | Enabled
PORT_SUSPEND | Not Suspended
PORT_OVER_CURRENT | No Overcurrent
PORT_RESET | No Reset
PORT_POWER | Powered On
PORT_LOW_SPEED | Device Dependent

The port should show the following bits in the status change field:

Field | Value
C_PORT_CONNECTION | Not Changed
C_PORT_ENABLE | Not Changed
C_PORT_SUSPEND | Changed
C_PORT_OVER_CURRENT | Not Changed
C_PORT_RESET | Not Changed

The status of the remaining ports on the target hub are examined by issuing a Device GetPortStatus command and the resulting status is compared with the following values to verify that they match:

Field | Value
PORT_CONNECTION | Connected
PORT_ENABLE | Enabled
PORT_SUSPEND | Suspended
PORT_OVER_CURRENT | No Overcurrent
PORT_RESET | No Reset
PORT_POWER | Powered On
PORT_LOW_SPEED | Device Dependent

The port should show the following bits in the status change field:

Field | Value
C_PORT_CONNECTION | Not Changed
C_PORT_ENABLE | Not Changed
C_PORT_SUSPEND | Not Changed
C_PORT_OVER_CURRENT | Not Changed
C_PORT_RESET | Not Changed

Port Suspend and Respond to Device Disconnect

The test software prompts the test operator to attach USB peripheral devices to all ports on the target hub. All ports on the target hub are first placed into the Enable state and then moved to the Suspended state with the use of the SetPortFeature command.

The test software then prompts the user to disconnect a USB peripheral device from a specified port on the target hub. The port the USB peripheral device has been attached to should be taken out of the Suspended state. The status of the port that received the remote wakeup event is examined by issuing a GetPortStatus command for the designated port. The port should show the following bits in the status field:

Field | Value
PORT_CONNECTION | Not Connected
PORT_ENABLE | Not Enabled
PORT_SUSPEND | Not Suspended
PORT_OVER_CURRENT | No Overcurrent
PORT_RESET | No Reset
PORT_POWER | Powered On
PORT_LOW_SPEED | Device Dependent

The port should show the following bits in the status change field:

Field | Value
C_PORT_CONNECTION | Changed
C_PORT_ENABLE | Changed
C_PORT_SUSPEND | Changed
C_PORT_OVER_CURRENT | Not Changed
C_PORT_RESET | Not Changed

The status of the remaining ports on the target hub are examined by issuing a Device GetPortStatus command and the resulting status is compared with the following values to verify that they match:

Field | Value
PORT_CONNECTION | Connected
PORT_ENABLE | Enabled
PORT_SUSPEND | Suspended
PORT_OVER_CURRENT | No Overcurrent
PORT_RESET | No Reset
PORT_POWER | Powered On
PORT_LOW_SPEED | Device Dependent

The port should show the following bits in the status change field:

Field | Value
C_PORT_CONNECTION | Not Changed
C_PORT_ENABLE | Not Changed
C_PORT_SUSPEND | Not Changed
C_PORT_OVER_CURRENT | Not Changed
C_PORT_RESET | Not Changed

Port Suspend and Remote Wakeup Processing

The test software prompts the test operator to connect a USB peripheral device that supports remote wakeup into each port on the target hub. The USB peripheral devices are then enabled for remote wakeup support by issuing a Device SetFeatures command with the DEVICE_REMOTE_WAKEUP flag set. All ports on the target hub are first placed into the Enable state and then moved to the Suspended state with the use of the SetPortFeature command.

The type and invocation of external stimulus that awakens the USB peripheral device and causes it to force its port circuitry through resume signaling is device dependent. The test software asks the test operator to provide such stimulus to a device attached to a particular port and indicate that such stimulus has been provided. In response to such stimulus, the port the USB peripheral device has been attached to should be taken out of the Suspended state. The status of the port that received the remote wakeup event is examined by issuing a GetPortStatus command for the designated port. The port should show the following bits in the status field:

Field | Value
PORT_CONNECTION | Connected
PORT_ENABLE | Enabled
PORT_SUSPEND | Not Suspended
PORT_OVER_CURRENT | No Overcurrent
PORT_RESET | No Reset
PORT_POWER | Powered On
PORT_LOW_SPEED | Device Dependent

The port should show the following bits in the status change field:

Field | Value
C_PORT_CONNECTION | Not Changed
C_PORT_ENABLE | Not Changed
C_PORT_SUSPEND | Changed
C_PORT_OVER_CURRENT | Not Changed
C_PORT_RESET | Not Changed

The status of the remaining ports on the target hub are examined by issuing a Device GetPortStatus command and the resulting status is compared with the following values to verify that they match:

Field | Value
PORT_CONNECTION | Connected
PORT_ENABLE | Enabled
PORT_SUSPEND | Suspended
PORT_OVER_CURRENT | No Overcurrent
PORT_RESET | No Reset
PORT_POWER | Powered On
PORT_LOW_SPEED | Device Dependent

The port should show the following bits in the status change field:

Field | Value
C_PORT_CONNECTION | Not Changed
C_PORT_ENABLE | Not Changed
C_PORT_SUSPEND | Not Changed
C_PORT_OVER_CURRENT | Not Changed
C_PORT_RESET | Not Changed

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The system must be configured with a USB host controller that is compliant with Universal Serial Bus Specification 1.1. There should be no devices attached to the system. The test operator is instructed to attach the peripheral devices as the test progresses.

The test requires the following hardware and software:

  • Windows Millennium Edition, Windows 2000, or later versions of a Windows based OPERATING SYSTEMS
  • Windows Logo Program compliant USB host controller and supporting drivers

Results Interpretation

Individual pass/fail indication is provided for each test category of USB peripheral device support for the power management requirements.

The following conditions cause test failures:

  • Root hub information does not appear correctly in the registry
  • Hub port cannot be placed in the proper states
  • The USB hub device does not manage its state changes properly in response to the suspend processing
  • The USB hub device indicates support for remote wakeup but cannot be configured for remote wakeup activity
  • The USB peripheral hub does not remotely wake the system following the it being placed in the suspend state when USB is resumed or a device is connected, disconnected or issues a remote wakeup event

The following advisory information is provided as applicable:

  • Content of hub descriptor
  • Content of each port descriptor
  • Content of USB peripheral device descriptors following each device state change


TD-9.7 USB Isochronous Alternate Interface Presence Test Description

Test Kit: HCT 11, HCT 10

Overview

This test verifies that when any device has an interface that consumes isochronous bandwidth, that device supports multiple alternate settings for that interface and that alternate setting 0 does not consume isochronous bandwidth. The requirement for alternate setting zero can be provided by an interface that has no endpoints, an interface with isochronous endpoints that don’t carry a payload or an alternate interface that has non-isochronous endpoints. The test software probes for these capabilities by recursively examining the configurations, interfaces, and endpoints that a device supports.

Overview of Test Steps

The test software places the ports on the root hub in the Powered On state. The test operator is prompted to attach the target USB peripheral device to a port on the root hub. The test software then places the port in the enabled state and communication with the target device is initiated. A Device GetDescriptor command is issued to the target device. The number of configurations supported by the device is returned in the field bNumConfigurations. The number of configurations is stored by the test software to be used to drive an iterative examination of all configurations. For each device configuration, a Device GetConfiguration command is issued to the target device. The number of interfaces supported by the configuration is returned in the field bNumInterfaces. The descriptor for the interfaces and endpoints for those interfaces are returned in the body of the configuration descriptor.

The interface descriptors for a configuration are parsed using the bInterfaceNumber and bAlternateSetting fields as keys. Groups of alternative interfaces share the same bInterfaceNumber field with incrementing bAlternateSetting fields. For each Interface with the bAlternateSetting field equal to 0 and the bNumEndpoints field greater than 0, the endpoint descriptors are parsed. The bmAttributes of the endpoint descriptor are examined to determine whether the endpoint is using an Isochronous transfer type. If the transfer type is Isochronous, then the wMaxPacketSize is examined. If the wMaxPacketSize is greater than zero, the device is consuming isochronous bandwidth inappropriately and is does not meet the Windows Logo Program requirements related to PC 2001 item USB-0084.2 and the interface is appropriately flagged as out of compliance. If the transfer type is isochronous with a wMaxPacketSize of 0 or is not isochronous, then the interface is in compliance.

If an isochronous interface has a descriptor with bAlternateSetting 1 or greater then the interface provides multiple alternate settings and is in compliance with System Design Guide Requirements.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The system must be configured with a USB host controller that is compliant with Universal Serial Bus Specification 1.1 and Windows Logo Program requirements. There should be no devices attached to the system. The test operator is instructed to attach the peripheral devices as the test progresses.

The test requires the following hardware and software:

  • Windows Millennium Edition, Windows 2000, or later versions of a Windows based OPERATING SYSTEMS
  • Windows Logo Program compliant USB host controller and supporting drivers

Results Interpretation

Individual pass/fail indication is provided for each test category of USB peripheral device support for the power management requirements.

The following conditions cause test failures:

  • Alternate Interface 0 consumes isochronous bandwidth
  • An interface supported by the device consumes isochronous bandwidth and does not provide more than one alternate setting.

The following advisory information is provided as applicable:

  • Content of USB peripheral device Device descriptor
  • Content of USB peripheral device Configuration descriptors
  • Content of USB peripheral device Interface descriptors
  • Content of USB peripheral device Endpoint descriptors


TD-9.8 USB Peripheral Power Management Test

Overview

This test insures that USB peripheral devices properly implement the power management functionality as described in the Universal Serial Bus Specification 1.1[1]. This document requires that USB peripheral devices support power draws in the powered, configured and active states. The peripheral is driven through these states and its power management functionality is checked for correctness. Bus powered devices are allowed to draw up to 500mA of current during normal operation. Self-powered devices are allowed to draw one unit of current (100mA) from the USB and are required to reduce this to 500(A during suspend state. Self-powered devices may also choose to draw no power from the USB and do not have to implement a suspend state. In this case they must still respond correctly to the suspend state of their connected hub port. The device that is currently being tested is called the target device.

Overview of Test Steps

The test software places the port that the peripheral is attached to in the powered off state. The test operator is then instructed to attach the USB peripheral device to the designated port. The test software then places the port in the PORT_POWER state using a SetPortFeature command. The USB system software then configures the device and brings it into operation.

Device Suspend and Resume

The status of the port is examined by issuing a GetPortStatus command for the designated port. The port should show the following bits in the status field:

Field | Value
PORT_CONNECTION | Connected
PORT_ENABLE | Enabled
PORT_SUSPEND | Not Suspended
PORT_OVER_CURRENT | No Overcurrent
PORT_RESET | No Reset
PORT_POWER | Powered On
PORT_LOW_SPEED | Device Dependent

The test software selectively places the target USB peripheral device into the SUSPENDED state by placing the port that it is connected to into the disabled state through the use of the SetPortFeature with the PORT_SUSPEND flag set. The USB peripheral device should recognize the idle interval of greater than 3ms and go into suspended mode independently. After delaying for 3ms the test software queries the port status and the port should have the following configuration:

Field | Value
PORT_CONNECTION | Connected
PORT_ENABLE | Enabled
PORT_SUSPEND | Suspended
PORT_OVER_CURRENT | No Overcurrent
PORT_RESET | No Reset
PORT_POWER | Powered On
PORT_LOW_SPEED | Device Dependent

The test software then resumes the device by issuing ClearPortFeature with the PORT_SUSPEND flag set. The USB peripheral device should then return to the active state and the port should show the following configuration:

Field | Value
PORT_CONNECTION | Connected
PORT_ENABLE | Enabled
PORT_SUSPEND | Not Suspended
PORT_OVER_CURRENT | No Overcurrent
PORT_RESET | No Reset
PORT_POWER | Powered On
PORT_LOW_SPEED | Device Dependent

The port should show the following bits in the status change field:

Field | Value
C_PORT_CONNECTION | Not Changed
C_PORT_ENABLE | Not Changed
C_PORT_SUSPEND | Changed
C_PORT_OVER_CURRENT | Not Changed
C_PORT_RESET | Not Changed

The USB peripheral device then queries using a Device GetStatus command to verify that it is communicating with the USB System Software.

Device Suspend and Remote Wakeup

A Device GetConfiguration command is issued to the USB peripheral device to determine whether it is capable of remotely waking up the system. This capability is indicated with the D5 bit in the bmAttributes field of the configuration descriptor. If the target USB peripheral device supports remote wakeup, then the USB peripheral Device GetStatus command should indicate that the Remote Wakeup capability is disabled as it is required to be until set. The remote wakeup capability is then enabled for the device by the issuance of a SetFeature with the DEVICE_REMOTE_WAKEUP flag set. The test software selectively places the USB peripheral device into Suspended state by placing the port that it is connected to into the disabled state through the use of the SetPortFeature with the PORT_SUSPEND flag set. A USB peripheral Device GetStatus command is issued and should indicate that the Remote Wakeup capability is now enabled. The USB peripheral device should recognize the idle interval of greater than 3ms and go into suspended mode independently. After delaying for 3ms the test software queries the port status and the port should have the following configuration:

Field | Value
PORT_CONNECTION | Connected
PORT_ENABLE | Enabled
PORT_SUSPEND | Suspended
PORT_OVER_CURRENT | No Overcurrent
PORT_RESET | No Reset
PORT_POWER | Powered On
PORT_LOW_SPEED | Device Dependent

The type and invocation of external stimulus that awakens the USB peripheral device and causes it to force its port circuitry through resume signaling is device dependent. The test software asks the test operator to provide such stimulus and indicate that such stimulus has been provided. In response to such stimulus, the port that the USB peripheral device is attached to should be taken out of the suspend mode. To verify this, the port status is queried and the following status should be indicated:

Field | Value
PORT_CONNECTION | Connected
PORT_ENABLE | Enabled
PORT_SUSPEND | Not Suspended
PORT_OVER_CURRENT | No Overcurrent
PORT_RESET | No Reset
PORT_POWER | Powered On
PORT_LOW_SPEED | Device Dependent

The port should show the following bits in the status change field:

Field | Value
C_PORT_CONNECTION | Not Changed
C_PORT_ENABLE | Not Changed
C_PORT_SUSPEND | Changed
C_PORT_OVER_CURRENT | Not Changed
C_PORT_RESET | Not Changed

The port is then disabled and powered down by the test software and the test operator is prompted to remove the device from the port.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The system must be configured with a USB host controller that is compliant with Universal Serial Bus Specification 1.1. There should be no devices attached to the system. The test operator is instructed to attach the peripheral devices as the test progresses.

The test requires the following hardware and software:

  • Windows Millennium Edition, Windows 2000, or later versions of a Windows based OPERATING SYSTEMS
  • Logo-compliant USB host controller and supporting drivers

Results Interpretation

Individual pass/fail indication is provided for each test category of USB peripheral device support for the power management requirements.

The following conditions cause test failures:

  • Hub port cannot be placed in the proper states
  • The target USB peripheral device does not manage its state changes properly in response to the hub port suspend processing
  • The target USB peripheral device indicates support for remote wakeup but cannot be configured for remote wakeup activity
  • The target USB peripheral device does not remotely wake the system following it being placed in the suspend state

The following advisory information is provided as applicable

  • Content of hub descriptor
  • Content of each port descriptor
  • Content of USB peripheral device descriptors following each device state change


TD-9.9 USB Device Class Compliance Test Description

Overview

A USB Class describes a group of devices or interfaces with similar attributes or services. A Class Specification defines the requirements for such a related group. The device class compliance is measured by a set of tests that interrogate peripheral devices that are members of the following device classes for basic descriptor and interface compliance:

  • Communication devices
  • HID devices
  • Audio devices
  • HID Point of Sale devices
  • Mass Storage devices
  • Monitor devices
  • Power devices
  • Printer devices

The only devices that are subject to this test requirement are devices that fit into the above classes. All other USB peripheral types are not subject to this test.

Overview of Test Steps

The devices are attached to a running system at the root hub and the software queries the device for its class, descriptor and interface information. The retrieved information is compared to the required information and functionality for that class for conformance.

Each of the device types is queried using the following commands for the information to validate that the devices meet requirements in related USB devices class specification:

Get Device Descriptor

This tests the Get Device Descriptor command. The descriptor returned is checked for errors. The class information in the device descriptor is as follows:

Offset | Field | Description
4 | Device Class | Class code (assigned by the USB). If this field is reset to zero, each interface within a configuration specifies its own class information and the various interfaces operate independently. If this field is set to a value between 1 and FEH, the device supports different class specifications on different interfaces and the interfaces may not operate independently. This value identifies the class definition used for the aggregate interfaces. If this field is set to FFH, the device class is vendor-specific.
5 | Device Sub Class | Subclass code (assigned by the USB). These codes are qualified by the value of the bDeviceClass field. If the bDeviceClass field is reset to zero, this field must also be reset to zero. If the bDeviceClass field is not set to FFH, all values are reserved for assignment by the USB.

Get Class Descriptor

This tests the Get Class Descriptor command. The descriptor returned is checked for correspondence with the class information and other errors.

Offset | Field | Description
5 | Interface Class | Class code (assigned by the USB). A value of zero is reserved for future standardization. If this field is set to FFH, the interface class is vendor-specific.
6 | Interface Subclass | Class code (assigned by the USB). A value of zero is reserved for future standardization. If this field is set to FFH, the interface class is vendor-specific.
7 | Interface Protocol | Class code (assigned by the USB). A value of zero is reserved for future standardization. If this field is set to FFH, the interface class is vendor-specific.

Check Spec Draft 4 Compliance

If the device is part of the HID class, this test determines whether the device is compliant with the HID 1.0 Draft 4 or later. This is determined by the placement of the HID descriptor within the configuration descriptor.

Each device that is a member of one of the specified classes is required to conform to the descriptor format and content and expose the specified class interfaces.


Mass Storage CBI Devices

The mass storage CBI devices are given their class designation at the interface level. In this case the class and subclass fields of the device descriptor are 00h.

The interface descriptors are used to determine compliance with the class specification.

Interface Classes

Class Code | Device Type | Description
01h | Reduced Block Commands (RBC) | Typically, a Flash device uses RBC command blocks. However, any Mass Storage device can use RBC command blocks.
02h | SFF8020I | Typically, a CD-ROM device uses SFF8020i command blocks for its Mass Storage interface. However, a CD-ROM device can be in another subclass (for example, RBC) and other types of storage devices can belong to the SFF8020I subclass.
03h | QIC-157 | Typically, a tape device uses QIC-157 command blocks.
04h | UFI | Typically a floppy disk drive (FDD) device
05h | SFF8070I | Typically, a floppy disk drive (FDD) device uses SFF8070i command blocks. However, an FDD device can be in another subclass (for example, RBC) and other types of storage devices can belong to the SFF8070i subclass.
06h | SCSI transparent command set |

The interface descriptors must have one of the above codes to be valid.

Protocol Subclasses

Protocol Code | Protocol Type | Description
00h | Control/Bulk/ Interrupt protocol with command completion interrupt | USB Mass Storage Class Control/Bulk/Interrupt (CBI) Transport.
01h | Control/Bulk/ Interrupt protocol with no command completion interrupt | USB Mass Storage Class Control/Bulk/Interrupt (CBI) Transport.

The protocol classes must have one of the above protocol codes to be valid.


Audio Devices

The audio devices are given their class designation at the interface level. In this case the class and subclass fields of the device descriptor are 00h. The interface descriptors are used to determine compliance with the class specification.

Interface Classes

Class Code | Device Type | Description
00h | Subclass Undefined | Undefined audio functions
01h | Audio Control | Control channel for all audio functions
02h | Audio Streaming | Streaming audio functions
03h | MIDI Streaming | Streaming MIDI functions

The interface descriptors must have one of the above codes to be valid.


Printer Devices

The printer devices are given their class designation at the interface level. In this case the class and subclass fields of the device descriptor are 00h. The interface descriptors are used to determine compliance with the class specification.

Interface Class

Class Code | Device Type | Description
07h | Printer | Device class for printers

The interface descriptors must have one of the above class codes to be valid.

Interface Subclass

Subclass Code | Device Type | Description
01h | Printer | Device subclass for printers

The interface descriptors must have one of the above subclass codes to be valid.

Interface Protocol Classes

Protocol Code | Protocol Type
01h | Unidirectional interface
02h | Bidirectional interface

The protocol classes must have one of the above protocol codes to be valid.


Communication Devices

The communication devices are given their class designation at the device and interface levels.

Device Class

Class Code | Device Type | Description
02h | Communication | Device class for communication

Interface Class

Class Code | Device Type | Description
02h | Communication | Device class for communication

The interface descriptors must have one of the above class codes to be valid.

Interface Subclass

Subclass Code | Device Type
01h | Direct line control model
02h | Abstract control model
03h | Telephone control model
04h | Multi-channel control model
05h | CAPI control model
06h | Ethernet networking control model
07h | ATM networking control model

The interface descriptors must have one of the above subclass codes to be valid.

Interface Protocol Classes

Class Code | Device Type | Description
01h | V.25ter | Common AT command set

The protocol class must have one of the above protocol codes to be valid.


HID Devices

The HID devices are given their class designation at the device and interface levels.

Device Class

Class Code | Device Type | Description
03h | HID | Generic HID device

Interface Class

Class Code | Device Type | Description
03h | HID | Generic HID interface

The interface descriptors must have one of the above class codes to be valid.

Interface Subclass

Class Code | Device Type | Description
00h | No subclass | Does not support boot interface
01h | Boot Interface subclass | Supports boot interface

The interface descriptors must have one of the above subclass codes to be valid.

Interface Protocol Class

Class Code | Device Type | Description
00h | None | Does not support boot interface
01h | Keyboard | Keyboard HID device
02h | Mouse | Mouse device

The protocol class must have one of the above protocol codes to be valid.

HID Descriptor

Every HID device must have a HID descriptor of the following form:

Offset | Field | Description
5 | Number of Descriptors | Numeric expression specifying the number of class descriptors.
6 | Descriptor Type | Constant name identifying the type of class descriptor.

The Number of Descriptors field must always be greater than or equal to one as a HID device must support the Report descriptor.

The following descriptor types must be present in the HID descriptor:

Descriptor Type | Device Type | Description
21h | HID Device | Generic HID device
22h | Report descriptor | Supports the report interface

Report Descriptor

The report descriptor provides a description of the data provided by each control in a device. Usages are part of the report descriptor and supply the information about the device and its control methods


Monitor Devices

The Monitor devices are HID devices and thus have HID class designations at the device and interface levels.

Device Class

Class Code | Device Type | Description
03h | HID | Generic HID device

Interface Class

Class Code | Device Type | Description
03h | HID | Generic HID interface

The interface descriptors must have one of the above class codes to be valid.

Interface Subclass

Class Code | Device Type | Description
00h | No subclass | Does not support boot interface

The interface descriptors must have one of the above subclass codes to be valid.

lnterface Protocol Classes

Class Code | Device Type | Description
00h | None | Does not support boot interface

The protocol class must have the above protocol codes to be valid.

HID Descriptor

The Number of Descriptors field must always be greater than or equal to one as a HID device must support the Report descriptor.

Descriptor Type | Device Type | Description
21h | HID Device | Generic HID device
22h | Report descriptor | Supports the report interface

Report Descriptor

The monitor class is identified by the following values in Usage Page field of the report descriptor:

Value | Description
80h | Monitor
81h | USB enumerated values
82h | VESA Virtual controls
05h 80h | Monitor Control

The Usage page field must have one of the above values for each usage page found in the report descriptor.

The Usage fields of the report descriptors must have one of the following values:

Type | Value | Description
Usage Page | 01h | USB Monitor Control HID device
EDID Info | 02h |
VDIF Info | 03h |
VESA Version | 04h | The version of the VESA Monitor Command Set specification used by this device. If this field is set to zero (0), the monitor uses the virtual control usage values defined in this document. If this field is non-zero, it is a Binary-Coded Decimal (BCD) value representing the version number of the VESA Monitor Command Set specification used to define the monitor’ s virtual control and command usage values.


POS Devices

The POS devices are HID devices and thus have HID class designations at the device and interface levels.

Device Class

Class Code | Device Type | Description
03h | HID | Generic HID device

Interface Class

Class Code | Device Type | Description
03h | HID | Generic HID interface

The interface descriptors must have one of the above class codes to be valid.

Interface Subclass

Class Code | Device Type | Description
00h | No subclass | Does not support boot interface

The interface descriptors must have one of the above subclass codes to be valid.

Interface Protocol Classes

Class Code | Device Type | Description
00h | None | Does not support boot interface

The protocol class must have the above protocol codes to be valid.

HID Descriptor

The Number of Descriptors field must always be greater than or equal to one as a HID device must support the Report descriptor.

Descriptor Type | Device Type | Description
21h | HID Device | Generic HID device
22h | Report descriptor | Supports the report interface

Report Descriptor

Type | Value | Description
Usage Page | 8C | Bar code scanner

The above information is required in the POS report descriptor.


Power Devices

The power devices are HID devices and thus have HID class designations at the device and interface levels.

Device Class

Class Code | Device Type | Description
03h | HID | Generic HID device

Interface Class

Class Code | Device Type | Description
03h | HID | Generic HID interface

The interface descriptors must have one of the above class codes to be valid.

Interface Subclass

Class Code | Device Type | Description
00h | No subclass | Does not support boot interface

The interface descriptors must have one of the above subclass codes to be valid.

Interface Protocol Classes

Class Code | Device Type | Description
00h | None | Does not support boot interface

The protocol class must have the above protocol codes to be valid.

HID Descriptor

The Number of Descriptors field must always be greater than or equal to one as a HID device must support the Report descriptor.

Descriptor Type | Device Type | Description
21h | HID Device | Generic HID device
22h | Report descriptor | Supports the report interface

Report Descriptor

Type | Value | Description
Usage Page | 84 | Power device

The above information is required in the power device report descriptor.


TD-9.10 USB System Port Presence Test Description

Test Kit: HCT 11, HCT 10

Overview

This test determines whether a system contains one or more USB root hubs or standard hubs. The system must contain at least one USB root hub and a total of two USB ports besides those used for a USB pointing device and/or USB keyboard. The test queries the system for USB root hubs through the USB software stack. The query determines whether there are at least two ports in the system besides the keyboard and/or pointing device ports and that they conform to the Windows Logo Program basic requirements. For mobile systems, one port is required.

Overview of Test Steps

Following a clean installation of the operating system, the system is booted. Clean means there has been no manipulation of the operating system USB drivers. Additional and/or updated peripheral drivers can be installed. If a USB keyboard and/or pointing device are part of the system they should be connected. No other USB devices should be connected to the system unless they are internal devices.

Note: An internal device is defined as a device that is connected to a USB port that is not exposed by the system. For example, this could include an internal USB mass storage device or an internal USB multi-port hub.

If the system comes with an external hub it should also be connected. The test program then queries each of the USB hubs through the USB software stack to determine how many ports are present in the system. The test software issues a Device GetDescriptor to get the device capabilities of the hub(s). The following fields are returned and examined:

Offset | Field | Description
1 | bDescriptorType | 29h Indicates a hub descriptor
2 | bNbrPorts | Number of downstream ports that this hub supports
7 | DeviceRemovable | Indicates if a port has a removable device attached

The descriptor value must be 29h (or 09h) indicating that the device is a hub. The port number and the DeviceRemovable bitmap vector for each hub are used to calculate the total number of removable ports in the system. There must be at least two ports in the system that supports removable devices. For mobile, there must be at least one port that supports removable devices.

The test software then issues a GetPortStatus for each port that supports removable devices on the hubs in the system. The port should show the following bits in the status field:

Field | Value
PORT_CONNECTION | Not Connected
PORT_ENABLE | Not Enabled
PORT_SUSPEND | Not Suspended
PORT_OVER_CURRENT | No Overcurrent
PORT_RESET | No Reset
PORT_POWER | Powered On
PORT_LOW_SPEED | N/A

This is the normal state for the hub and port to accept new device connections. Every removable port that does meet these requirements is not available and does not count towards the port requirement (2 ports for desktop and 1 for mobile).

Once this process is complete the user is asked to connect a device to each port that indicates it is available. If the user is unable to connect a device to any of these ports it does not count towards the port requirement (2 ports for desktop and 1 for mobile).

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment must include the following:

  • Windows Millennium Edition, Windows 2000, or later versions of a Windows based OPERATING SYSTEMS
  • Windows Logo Program compliant USB host controller and supporting drivers

The system should be set up with a USB keyboard and / or USB pointing device only if they are part of the standard system configuration. All Internal USB devices and external USB hubs and devices should also be attached if they are part of the system configuration. An additional USB device is needed to verify that the proper number of system ports is accessible by a user.

Results Interpretation

The test transcribes all results to a text based log file.

The test fails if:

  • USB System Software does not load correctly and enable the host controller(s).
  • System does not support at least two (one on mobile) available downstream ports besides those used by USB keyboards and pointing devices. The following advisory information is provided as applicable.
  • Content of each hub descriptor.
  • Content of each port status descriptor.


TD-9.11 USB Specification Compliance Test Description

Test Kit: HCT 11, HCT 10

Overview

This test verifies that the descriptors on all Universal Serial Bus (USB) devices and hubs attached to a system comply with the either the Universal Serial Bus Specification 1.1 or the Universal Serial Bus Specification 2.0.

The test enumerates the USB bus through the USB software stack. The target device or hub is queried to determine which level of the USB specification is supported.

For devices and hubs that support USB Specification version 1.1, some differences between the 1.1 and 1.0 descriptors are checked.

Overview of Test Steps

First a clean installation of the operating system the system is booted. Clean means there has been no manipulation of the operating system USB software. All USB hubs and devices that are part of the system should be connected. The test software enumerates the USB bus through the USB software stack. The test software issues a Device GetDescriptor for each device and hub present and interprets the bcdUSB field as follows:

BcdUSB | Explanation
0x0100 | Compliant with version 1.0 of the specification
0x0110 | Compliant with version 1.1 of the specification
0x0200 | Compliant with version 2.0 of the specification

If any device or hub is not compliant with version 1.1 or 2.0 of the USB specification the test fails.

USB 1.1 Specification Descriptor Checks

For each device or hub that indicates Universal Serial Bus 1.1 Specification Compliance the following descriptor checks are made.

Note: This is not in intended to be a full 1.1 Specification Compliance Test. It only checks a few descriptor differences between the 1.1 and 1.0 Specifications that can be checked readily through software.

For each device or hub that reports 1.1 Specification compliance, the software enumerates through all of the configuration descriptors. If bit D7 in the bmAttributes field is not set to one as required by the USB 1.1 Specification, the test fails.

For each hub that reports an implementation of the USB 1.1 Specification the test queries the hub for its hub descriptor. The following fields in the hub descriptor are examined by the test software:

wHubCharacteristics: Bits D0 and D1 must indicate that the hub supports ganged or individual port power switching. If bits D0 and D1 are 1X, the test fails.

PortPwrCtrlMask: All bits in this field must be set to one to maintain compatibility with software written for USB 1.0 devices. If any of these bits are set to zero, the test fails.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires the following hardware and software:

  • Windows Millennium Edition, Windows 2000, or later.
  • Windows Logo Program compliant compliant USB host controller and supporting drivers

The test requires that the following hardware and software be installed, if they are part of the system undergoing the test.

  • Windows Logo Program compliant USB hub(s) and supporting drivers
  • Windows Logo Program compliant USB cables
  • Windows Logo Program compliant USB devices and supporting drivers

Results Interpretation

The test transcribes all results to a text based log file (Usb1_1ct.log).

The test fails if:

  • The device descriptor indicates that the device does not support Universal Serial Bus Specification, Revision 1.1 or 2.0.
  • The device descriptor indicates that the device supports USB Specification, Version 1.1 but the D7 bit in the bmAttributes field of a configuration descriptor is not set to one.
  • The hub indicates that it supports the USB Specification, Version 1.1 but its Logical Power Switching Mode in wHubCharacteristics is not set to Ganged or Individual port power switching.
  • The hub indicates that it supports the USB Specification, Version 1.1 but not all bits in its PortPwrCtrlMask are set to 1.


TD-9.12 USB Host Controller Version Compliance Test Description

Test Kit: HCT 11, HCT 10

Overview

This test checks for one or more valid UHCI, OpenHCI, or EHCI host controllers in the system. It performs basic register checks on the host controllers to determine the versions of the associated host controller specifications with which the host controllers are compliant.

Overview of Test Steps

First a clean installation of the operating system is booted. Clean means there has been no manipulation of the operating system USB drivers. Additional and/or updated peripheral drivers can be installed. Any USB devices that are part of the system such as keyboards or pointing devices should be connected prior to running the test.

PCI Bus Enumeration

The PCI bus is also enumerated to search for the USB OpenHCI/UHCI/EHCI host controllers. The test scans a list of PCI devices and looks at the class code PCI configuration register of each to determine if it is an OpenHCI/UHCI/EHCI USB controller. The PCI Class Code register has the values shown below for USB controllers:

Field | Bits | Read/Write | Description
PI | 7-0 | R | PROGRAMMING INTERFACE A constant value of ‘20h’ Identifies the device being an EnhancedHCI Host Controller A constant value of ‘10h’ Identifies the device being an OpenHCI Host Controller A constant value of ‘00h’ Identifies the device as having no specific register level programming interface defined (UHCI)
SC | 15-8 | R | SUB CLASS A constant value of ‘03h’ Identifies the device being of Universal Serial Bus
BC | 23-16 | R | BASE CLASS A constant value of ‘0Ch’ Identifies the device being a Serial Bus Controller

If the base class is 0Ch and the sub class is 03h the PCI device is a Universal Serial Bus Controller. In this case the programming interface is examined to determine the type of Universal Serial Bus Controller.

Minimum OpenHCI/UHCI/EHCI Version Compliance

Each OpenHCI/UHCI/EHCI controller must meet a minimum version of the corresponding host controller specification. The version of the specification that each host controller supports is determined as follows:

EHCI – The HCIVERSION register at Offset 0x02 of the EHCI capability registers is read. This register contains a 16 bit BCD encoded version of the EHCI specification to which the host controller conforms. It must be at least 0x0095 or the test fails.

OpenHCI – The test should check the HcRevision value in the operational registers on OCHI controllers for compliance with Open Host Controller Interface Specification v1.0a.

UHCI – The UHCI specification does not define a version register for the version of the UHCI specification that the host controller implements. Instead the PCI Serial Bus Release Number register at offset 0x60 in configuration space is read. This 8-bit register must be version 1.1 or the test fails (0x10 indicates version 1.1 of the UHCI specification).

If any of the UHCI, OHCI, or EHCI controllers in the system do not meet the versions documented above the host controller compliance test fails.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following software:

  • Windows Millennium Edition, Windows 2000, or later versions of a Windows based OPERATING SYSTEMS
  • Windows Logo Program compliant USB host controller with root hub and supporting drivers

Results Interpretation

The test transcribes all results to a text based log file.

The test fails if:

  • The number of UHCI, OHCI, and EHCI USB host controllers found by enumerating the PCI bus does not match the operating system information.
  • An EHCI host controller does not meet at least version .95 of the EHCI specification.
  • An UHCI host controller does not meet at least version 1.10 of the UHCI specification.


TD-9.13 USB System Wake Capabilities Test Description

Overview

This test ensures that the USB host controller can wake the system out of power management states S1, S2 and S3. If more than one USB host controller is present in the system, this requirement applies only to additional integrated controllers (not add in cards). The USB host controller must be able to wake the system from any of these three states. It must be able to wake mobile systems from S1 and S2. The host controller is required to request system wakeup when it or one of its downstream devices process and propagate a remote wakeup event. The user is required to use a USB device to wake the system. The test enables the device to be used for remote wake and then programmatically suspends the system to S3. The user operates the device to generate the wake event and the test verifies that the system wakes up. If the system does not wake up or the system is not woken up by a USB wake event from the target device, the test fails.

Overview of Test Steps

First a clean installation of the operating system is booted. Clean means there has been no manipulation of the standard operating system USB drivers. Additional and/or updated peripheral drivers can be installed. Any USB devices that are part of the system such as keyboards or pointing devices should be connected prior to running the test. When the test software runs it prompts the user to connect the USB device that will be used to generate the wake event (a USB keyboard or pointing device is recommended).

The test software enumerates the USB bus through the USB software stack and identifies the target device. The test software enables the target device for remote wakeup. The method for enabling the target device for remote wakeup events depends on the operating system. The methods used for current operating systems are documented below:

Windows 2000

Under Windows 2000 remote wakeup capability must be individually enabled through the operating system device manager for each USB device that is capable of waking the system, perform the following steps:

  1. Open Windows 2000 Device Manager. To do this select Start >> Settings>>Control Panel and then chose the System icon. Select the hardware tab and then chose device manager.
  2. Right click and target device and select properties.
  3. From the Power Management tab check the box allowing the device to wake the system from standby.

Windows Millennium Edition

Under Windows Millennium Edition (Windows Me) running on a desktop, USB devices are automatically enabled to wake the system. No action needs to be taken by the test software or user.

The test software verifies that the target device has been successfully enabled for wake events. Once this is verified the test software prompts the user to use the target device to wake the system and the programmatically suspends the system to the S3 state. If the target device cannot wake the system, the test fails.

If the system supports the S2 and/or S1 states, the test software repeats the same test for each of these power states. If the target device cannot wake the system from S2 or S1, the test fails.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows Millennium Edition, Windows 2000, or later versions of a Windows based OPERATING SYSTEMS
  • Windows Logo Program compliant USB host controller and supporting drivers
  • Windows Logo Program compliant USB cables

For the initial setup any USB devices that are a standard part of the system can be connected. When the test runs, all devices except one Windows Logo Program compliant USB device (pointing device or keyboard is recommended) with supporting drivers will need to be removed from the system.

Results Interpretation

The test transcribes all results to a text based log file.

The test fails if:

  • The USB hub and peripheral devices indicate support for remote wakeup but cannot be configured for remote wakeup activity.
  • The USB hub and peripheral devices do not remotely wake the system out of S1, S2 or S3 into the S0 state following the wake event.


TD-9.14 USB Self Powered Hub Test Description

Test Kit: HCT 11, HCT 10

Overview

The test queries all non-root USB hubs in the system to determine whether they are bus or self powered. This includes both USB hubs that are used internally in the system and USB hubs that are supplied externally as part of the system. Every hub in the system that is not part of an integrated keyboard device or integrated into a mobile system is required to be self-powered. The test enumerates the USB bus through the USB software stack. Each hub in the system is queried to determine whether it is bus or self powered. If a bus-powered hub is found that is not part of an integrated keyboard device or integrated into a mobile system, the test fails.

Overview of Test Steps

First a clean installation of the operating system is booted. Clean means there has been no manipulation of the operating system USB drivers. Additional and/or updated peripheral drivers can be installed. The test enumerates the USB bus through the USB software stack to find all of the non root USB hubs in the system. To locate the hubs, the test software issues a Device GET_DESCRIPTOR command to each device in the system. The following field is examined to determine if the device is a hub:

Offset | Field | Description
1 | BDescriptorType | 29h indicates a hub descriptor

The test queries the USB hubs through the USB software stack to determine whether they are bus or self-powered. The test software issues a Configuration GetDescriptor to get the configured capabilities of the hubs. The following fields are returned and examined:

Offset | Field | Description
8 | MaxPower | Maximum power consumption of the device from USB hub
7 | BMAttributes | D6: Self-powered

The test software also issues a GetStatus command to the hub. Bit zero of the returned status word is the self –powered bit of the device status. Taken together these three pieces of information have the following interpretation:

Case | Max Power | Self Powered | Hub Device Status (D0) | Explanation
1 | 0 | 0 | 0 or 1 | N/A. This is an illegal set of information
2 | 0 | 1 | 0 | N/A. A device that is only self-powered, but does not have local power cannot connect to the Bus and communicate.
3 | 0 | 1 | 1 | Self-powered only hub and local power supply is good.
4 | >0 | 0 | 0 or 1 | Bus-powered only hub.
5 | >0 | 1 | 0 | Hub capable of both self- and bus-powered operating modes. It is currently only available as a bus-powered hub.
6 | >0 | 1 | 1 | Hub capable of both self- and bus-powered operating modes. It is currently available as a self-powered hub.

Note: Some hubs are self-powered for the power they supply to their ports but take their own operating power from the USB bus. These hubs are allowed.

If case 1 or 2 is discovered, the hub is reporting an illegal configuration and the test fails. If case 3 or 6 is discovered, the hub is operating as a self-powered hub and test requirements are met.

In case 4 or 5 the hub is operating in bus powered mode. This is only allowed if the hub is part of an integrated keyboard. To determine if this is the case, the test software issues a Hub GetDescriptor to get the capabilities of the hub. The following field is returned and examined:

Offset | Field | Description
3 | wHubCharacteristics | D2: Identifies a compound device 0: Hub is not part of a compound device 1: Hub is part of a compound device

If a hub operating in bus-powered mode is not part of a compound device, the test fails.

Each bus powered hub in the system must have a keyboard connected to one of its downstream ports. The USB keyboard is a HID device that must conform to Device Class Specification for Human Interface Devices. To find the keyboards in the system, the test queries all devices and their interfaces. The following values indicate a keyboard device:

Interface Class

Class Code | Device Type | Description
03h | HID | Generic HID interface

Interface Protocol Class

Class Code | Device Type | Description
01h | Keyboard | Keyboard HID device

If a bus-powered hub does not have a keyboard as a downstream child, the test fails.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows Millennium Edition, Windows 2000, or later versions of Windows based OPERATING SYSTEMS
  • Windows Logo Program compliant USB host controller and supporting drivers
  • Windows Logo Program compliant USB hub(s) and/or compound devices and supporting drivers
  • Windows Logo Program compliant USB cables

The system should be set up with a USB keyboard and / or USB pointing device only if they are part of the standard system configuration. All Internal USB hubs and devices and external USB hubs and devices should also be attached if they are part of the system configuration. All devices and hubs with their own power supplies should have them connected.

Results Interpretation

The test transcribes all results to a text based log file.

The test fails if:

  • A hub is located which is not self-powered and is not part of a keyboard device or integrated into a mobile system.
  • A hub with an illegal set of power attributes is discovered.


TD-9.15 USB Device and Hub Power Usage Test Description

Overview

The test queries all devices and non-root USB hubs in the system to determine their power usage characteristics. This includes USB hubs and devices that are used internally in the system and USB hubs and devices that are supplied externally as part of the system. Self-powered devices/hubs must draw no more than 100mA of current from the USB bus during normal operation. Bus-powered devices/hubs must draw no more than 500mA of current during normal operation. The test enumerates the USB bus through the USB software stack. Each configuration for each hub/device in the system is queried to determine whether it is bus or self powered and how much power it consumes. If a hub/device consumes too much power, the test fails.

Overview of Test Steps

First a clean installation of the operating system is booted. Clean means there has been no manipulation of the operating system USB drivers. Additional and/or updated peripheral drivers can be installed. The test program queries each USB hub/device through the USB software stack to determine the number of configurations it supports. It does this by issuing the Get Device Descriptor command for each USB hub/device and examining the field described below:

Offset | Field | Description
17 | bNumConfigurations | Number of possible device configurations.

If the bNumConfigurations field is not 1 or more the test fails. The test software issues a Configuration GetDescriptor to get the power capabilities of each configuration for the hub/device. The following fields are returned and examined:

Offset | Field | Description
7 | BMAttributes | D6: 0: Bus-powered. 1: Self-powered.
8 | MaxPower | Maximum power consumption of the device from the USB hub.

The MaxPower field multiplied by 2 gives the reported power consumption in mA. For any bus-powered device/hub configuration, the test fails, if this value is greater than 500 mA. For any self-powered device/hub configuration, the test fails, if this value is greater than 100 mA.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows Millennium Edition, Windows 2000, or later versions of Windows based OPERATING SYSTEMS
  • Windows Logo Program compliant USB host controller and supporting drivers
  • Windows Logo Program compliant USB hub(s) and supporting drivers
  • Windows Logo Program compliant USB cables
  • Windows Logo Program compliant USB devices and supporting drivers

The system should be set up with a USB keyboard and /or USB pointing device only if they are part of the standard system configuration. All Internal USB hubs and devices and external USB hubs and devices should also be attached if they are part of the system configuration. All devices and hubs with there own power supplies should have them connected.

Results Interpretation

The test transcribes all results to a text based log file.

The test fails if:

  • A hub/device has a self-powered configuration that consumes more than 100mA of current.
  • A hub/device has a bus-powered configuration that consumes more than 500mA of current.


TD-9.16 USB Device Installation Test Description

Test Kit: HCT 10

Overview

This test verifies the proper installation of USB devices into the system. When a USB device is first inserted into the system it must automatically prompt for and allow the installation of any software it needs that is not provided by the operating system. It is recommended that the device does not require a reboot after installation. The test fails if any device that is part of the system does not prompt for and install its software correctly when the device is first inserted into a clean system.

Overview of Test Steps

First a clean installation of the operating system is booted. Clean means there has been no manipulation of the operating system USB software and that no additional USB peripheral device related software has been installed. The following procedure must be followed individually for each USB device that is part of the system.

The system must be clean of any supporting software, device driver or user-mode applications necessary for the proper functioning of the USB device. The test software enumerates the USB bus through the USB software stack. The test software then prompts the user to plug in a device to be tested. The operating system recognizes the device and begins the installation prompting the user for supporting media if necessary. The test software observes what programs run as part of the installation. On completion of the installation process, the user should not be requested to reboot the system in order for the device to function properly. If the test software receives notification of a reboot, the test fails.

After the completion of the installation process, the test issues the device/hub Get Device Descriptor and Get Configuration Descriptor commands. The results are checked to verify the device has been properly configured. The test verifies that the device and its software are functional. If the device and/or any of its installed software is not fully functional the test fails.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows Millennium Edition, Windows 2000, or later versions of Windows based OPERATING SYSTEMS
  • Windows Logo Program compliant USB host controller and supporting drivers
  • Windows Logo Program compliant USB hub(s) and supporting drivers
  • Windows Logo Program compliant USB cables
  • Windows Logo Program compliant USB devices and supporting drivers

The system should be set up with a clean install of the OS. Clean means that the operating system USB software has not been modified in any way and no additional USB related software installed. The system should be set up with a USB keyboard and/or USB pointing device only if they are part of the standard system configuration. All other external USB hubs and devices should not be attached to the system. They are connected one by one to the clean system as the test runs.

Results Interpretation

The test transcribes all results to a text based log file.

The test fails if:

  • Installation of software for a USB device that is connected to the system is not done through an INF file.
  • Connecting the device to the system does not install all necessary software for the device to be fully functional.
  • The installation of software for the device when it is connected to the system requires a reboot.


TD-9.17 USB BIOS Support Test Description

Overview

This test verifies that the system BIOS supports USB keyboards and pointing devices behind at least 2 external (to the system) USB hubs. When the user enters the BIOS setup a USB keyboard should be useable as long as more than two hubs do not separate it from the system port. The test analyzes the USB bus in the system and prompts the user to connect two USB hubs and/or a keyboard to one or more system ports and then enter the BIOS setup. If the keyboard is not useable in the BIOS for each possible configuration, the test fails.

Overview of Test Steps

First a clean installation of the operating system is booted. Clean means there has been no manipulation of the operating system USB drivers. Additional and/or updated peripheral drivers can be installed. No devices should be connected to the exposed system USB ports except for a USB keyboard and/or pointing device. Two Windows Logo Program compliant USB hubs are required to complete the test.

Upon running the test software, the user is prompted to disconnect all devices except a USB pointing device. The test software enumerates the USB bus through the USB software stack. To locate hubs the test software issues a Device GET_DESCRIPTOR command to each device in the system. The following field is examined to determine if the device is a hub:

Offset | Field | Description
1 | BdescriptorType | 29h indicates a hub descriptor

Only Root Hubs in System

If no non-root hubs are detected in the system, the user is prompted to connect 2 USB hubs to an exposed system port. The test software also prompts the user to connect the USB keyboard and USB pointing device to the last of the hubs. The USB test then enumerates the USB bus through the USB software stack to ensure that USB hubs have been connected to the system as instructed and that a USB keyboard and USB pointing device are connected beyond at least 2 levels of non-root USB hubs.

The USB keyboard must meet the USB Device Class Definition for Human Interface Devices, Version 1.1. The test software checks the following fields of device class, interface, and HID descriptors to verify that the keyboard should be supported by a BIOS that is Windows Logo Program compliance.

Interface Class

The following interface class code is valid:

Class Code | Device Type | Description
03h | HID | Generic HID interface
Interface Subclass

The following interface class code is required as the keyboard must support the boot protocol:

Class Code | Device Type | Description
01h | Boot Interface subclass | Supports boot interface

Interface Protocol Class

The following protocol code is required for the keyboard HID device:

Class Code | Device Type | Description
01h | Keyboard | Keyboard HID device

HID Descriptor

Every HID device must have a HID descriptor. The HID descriptor takes the following form:

Offset | Field | Description
5 | Number of Descriptors | Numberic expression specifying the number of class descriptors
6 | Descriptor Type | Constant name identifying the type of class descriptor

The Number of Descriptors field must always be greater than or equal to one as a HID device must support the report descriptor.

The following descriptor types must be present in the HID descriptor.

Descriptor Type | Device Type | Description
21h | HID Device | Generic HID device
22h | Report Descriptor | Supports the report interface

Once a valid keyboard is identified the test software prompts to the user to reboot and enter the BIOS setup utility to verify that the keyboard is functional.

Once the user exits the BIOS and reloads the operating system, the test software records if using the keyboard in the BIOS was successful.. If the keyboard fails to function in the BIOS setup when attached to the hubs, the test fails.

Internal Hubs in System

If the system contains internal hub(s) in addition to the root hub(s) all of the exposed system ports may already be behind one or more levels of a non root hub. The user is still prompted to connect 2 USB hubs to an exposed system port. The test software also prompts the user to connect the USB keyboard and USB pointing device to the last of the hubs. The user must connect to the system port that is already behind the greatest number of hubs. If the test operator is unsure of the system configuration they should test all ports. The test software prompts the user to connect a keyboard to an exposed system port. The test software enumerates the USB bus through the USB software stack and verifies the keyboard is at least two levels of hub beyond the root-hub. If this is not the case, the test software prompts the user to remove the keyboard and connect an additional hub to the same port with the keyboard connected to that hub. The test software then verifies that the keyboard meets the HID requirements as described in the preceding section.

Once a valid keyboard is identified the test software prompts the user to reboot and enter the BIOS setup utility to verify that the keyboard is functional.

Once the user exits the BIOS and reboots the operating system, the test software records if using the keyboard in the BIOS was successful. If the keyboard fails to function in the BIOS setup, the test fails.

USB Keyboard and PS/2 Pointing Device

If the system supports a PS/2 pointing device the test software prompts the user to disconnect the USB pointing device and connect a PS/2 pointing device. The test software prompts the user to reboot and enter the BIOS setup utility to verify that the keyboard is still functional.

Once the user exits the BIOS and reboots the operating system, the test software records if using the keyboard in the BIOS was successful. If the keyboard fails to function in the BIOS setup, the test fails.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows Millennium Edition, Windows 2000, Windows XP, or later
  • Windows Logo Program compliant USB host controller and supporting drivers
  • Windows Logo Program compliant USB hub(s) and supporting drivers
  • Windows Logo Program compliant USB cables
  • Windows Logo Program compliant USB keyboard

The system should be set up with a clean install of the OS. Clean means that the operating system USB software has not been modified in any way and no additional USB related software has been installed. The system should be set up with a USB keyboard and /or USB pointing device only if they are part of the standard system configuration. Nothing else should be connected to the exposed system ports.

Results Interpretation

The test transcribes all results to a text based log file.

The test fails if:

  • The BIOS does not support a USB keyboard that meets the HID specification.
  • The BIOS does not support a USB keyboard behind 2 external USB hubs.
  • The BIOS does not support a USB keyboard when a PS/2 pointing device is attached.


TD-9.18 USB Manual Interoperability Test Description

Test Kit: HCT 11, HCT 10

Overview

This test verifies that the USB device, or the system, operates properly with a series of USB devices attached. A specified device tree is created on the test system, and the devices are used while the test tool validates the device driver behavior and data sent to each device on the system to ensure that data transfers can be performed without error. The goal is to ensure that the system or device does not negatively impact the standard operation of USB. The test fails if any of the devices on the system fail to operate properly during normal device operation.

USB Verifier handles the validation of the device driver behavior and is a valuable tool designed to help USB client driver writers develop more robust code. The core USB driver stack relies on the integrity of client drivers and performs minimal error checking on requests received from those drivers. Therefore, many client driver bugs first appear as assertion failures, invalid device operations or bug checks. The goal of USB Verifier to catch client errors before the USB stack has a chance to process them.

USB Verifier installs itself as a filter driver between the client driver and the core USB driver stack. It intercepts client requests and performs additional processing before forwarding the requests to the core stack. If it finds an error condition during this additional processing, it causes an assertion failure to occur in the debugger. This failure provides more meaningful information to the client driver writer.

Overview of Test Steps

The test requires the construction of a USB device tree. For complete procedures for this test in the current HCT kit, see the HCT Documentation.

Once the required device tree is created, USB Verifier is installed on the device nodes, and the test begins to track the data and driver behavior. Depending on the device being tested, you are required to exercise the USB device tree in the following manner:

System or Host Controller Test Procedure

The device tree is sequentially constructed on an available USB port on the system or host controller. Once attached to a port, all of the devices on the tree must be manually exercised to validate data transfers can still occur. This procedure is repeated for every available port on the system or host controller.

Hub Test Procedure

Three test passes are performed for validation of the hub. A test pass occurs with the USB hub used in place of each of the USB hubs in the required device tree. Once the hub is installed, functionality of all of the devices on the tree is confirmed.

Device Test Procedure

The test device is sequentially attached to a root system port and all of the USB hubs in the required device tree. At each location, the functionality of the device, as well as all of the other devices on the system, is verified.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following software:

  • Windows XP Operating System

Results Interpretation

The test fails if:

  • The required USB device tree is not created or is not functional.
  • Any of the USB devices stop functioning during testing.
  • Any of the USB devices fail enumeration after a PnP event.
  • Data is not transferred to all of the required devices.
  • All of the ports on the system/controller are not tested.
  • A USB Verifier assertion occurs.


TD-9.19 USB Port Reporting Test Description

Test Kit: HCT 11, HCT 10

Overview

This test verifies that the system or hub under test reports the correct number of USB ports. The number of ports in the USB hub descriptor must correspond to the number of port physically available to either an internal/compound device, or accessible for a user’s device. For compound devices, the test also verifies that the DeviceRemovable field in the USB hub description correctly marks the embedded devices as non-removable.

Overview of Test Steps

The test procedure varies depending on the unit under test:

Systems

All external hubs must be removed from the system. Any USB hubs found after this step are considered to be motherboard components and treated as non-removable. USB devices must next be attached to all available ports on the system. If any port is not occupied, or not functional, the test issues a failure.

Devices

The device under test is added to the system. If it contains a USB hub, the DeviceRemovable field is examined to ensure that any ports used by the compound device are marked appropriately. USB devices must next be attached to all available ports on the system. If any port is not occupied, or not functional, the test issues a failure.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Operating System.
  • Device or system under test

Results Interpretation

The test fails if:

  • The number of accessible USB ports is incorrect.
  • Any of the accessible ports do not function correctly.

The test warns if:

  • The DeviceRemovable field is incorrect.


TD-9.20 USB Selective Suspend Test Description

Test Kit: HCT 11, HCT 10

Overview

Windows XP now supports the selective suspend abilities of the USB. This feature allows a devices port to be suspended when the device is not in use in order to conserve power. To properly support this new feature, a device must maintain its internal state when its upstream port has been suspended and be able to function correctly when its upstream port is resumed. This test will insure that devices respond appropriately on its control pipe at its currently assigned device address following the suspend/resume cycle of a port. Depending on the class of the device, additional steps may be performed to insure that the device responds correctly on other endpoints. This test runs only on devices and hubs.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Operating System
  • System with at least one available root hub port
  • USB Hub that properly supports the suspension of a port.
  • Device/Hub under test

Results Interpretation

The test fails if:

  • A device fails to respond correctly on its control pipe following the suspend/resume cycle
  • A device fails to respond correctly on any other endpoints in its current configuration following the suspend/resume cycle.


TD-9.21 USB Enumeration Stress Test Description

Test Kit: HCT 11, HCT 10

Overview

The USBENUM test verifies the proper functionality of a USB device when initially attached to a USB port. To properly enumerate in the Windows environment, a device must consistently provide valid information on its control pipe and properly respond to all standard device requests. This test repeats the Windows XP enumeration process to ensure that devices will enumerate reliably in real-world scenarios. This test covers only USB peripheral devices and hubs.

Initialization

  • Select device to test (must be plugged into root hub)
  • Open handle to host controller
  • Gather initial information
  • Device Descriptor
  • Config Descriptor
  • String Descriptors (if supported by device and test)

Enumeration test (repeat n times) with no string descriptor support

  • Reset Device Port
  • Get Device Descriptor (first MPS with wLength value of FF)
  • Reset Device Port
  • Get Device Descriptor (full descriptor)
  • Set Address (address not in use)
  • Get Config. Descriptor
  • Compare device and configuration descriptors to initial ones
  • Set configuration to configuration 0

Enumeration test (repeat n times) with string descriptor support

  • Reset Device Port
  • Get Device Descriptor (first MPS with wLength value of FF)
  • Reset Device Port
  • Get Device Descriptor (full descriptor)
  • Set Address (address not in use)
  • Get Config. Descriptor
  • Compare device and configuration descriptors to initial ones
  • Set configuration to configuration 0

Result

Success indicated by device and configuration descriptor comparisons passing for n iterations. Any descriptor comparison failure

Overview of Test Steps

The system used for this test must have an available root hub port. If the test is to be run on a system where the keyboard and mouse are attached via USB and the system supports more than one root hub, these devices should be connected on one of the other root hubs. If the system has only one root hub, all other devices must be attached downstream of a secondary root hub port.

The device under test must be attached directly to the open root hub port. The user must then select the device that needs to be tested. Once selected, the test will run without user intervention. While the test runs, any devices connected to other ports on the same root hub may become unusable for a period of time.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Operating System
  • System with at least one available root hub port
  • Device/Hub under test

Results Interpretation

The test fails if:

  • Any standard device request is not properly handled by the device under test
  • Any standard device request does not meet the response time requirements as defined in the USB specification.


TD-9.22 USB Address Description Test Description

Test Kit: HCT 11, HCT 10

Overview

A USB device must respond correctly to all possible USB device addresses, addresses 0 through 127. This test verifies that devices can respond correctly at their assigned address and that they do not respond and any other address.

The test will perform the following steps:

  1. Initialization
  • Select device to test (must be plugged into root hub)
  • Open handle to host controller
  • Gather initial information

- Device descriptor

- Configuration descriptor

- String descriptors (if supported by device and test)

  2. Address test #1 (repeat for all addresses)
  • Reset device port
  • Get descriptors (device, comfit, string) from address 0
  • Set device address (next address value not in use)
  • Get descriptors using address 0 (device should not respond)
  • Get descriptors using new address (device should respond)
  • Compare descriptors to initial information
  3. Address test #2 (repeat for all addresses)
  • Reset device port (first time only)
  • Set address (next address value not in use)
  • Get descriptors from previous address (device should not respond)
  • Get descriptors from new address (device should respond)
  • Compare descriptors to initial information
  4. Result

For success, a device must always respond with valid device, configuration and string descriptors while not responding at its previous device address. Any failure indicates a test failure.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Operating System
  • System with at least one available root hub port
  • Device/Hub under test

Results Interpretation

The test fails if:

  • Any standard device request is not properly handled by the device under test
  • Any standard device request does not meet the response time requirements as defined in the USB specification.
  • A device fails to respond to a request at its currently assigned address
  • A device responds at a address other than its currently assigned address


TD-9.23 USB Device Control Requests Test Description

Test Kit: HCT 11, HCT 10

Overview

All USB devices must respond correctly to all USB control requests after they have been reset in the USB environment. The control requests that must be supported are detailed in chapter nine of the USB Specification. This test will validate that devices respond to those requests in the appropriate fashion at different addresses and at different times following a port reset. This test covers only USB peripheral devices and hubs.

Overview of Test Steps

The system used for this test must have an available root hub port. If the test is to be run on a system where the keyboard and mouse are attached via USB and the system supports more than one root hub, these devices should be connected on one of the other root hubs. If the system has only one root hub, all other devices must be attached downstream of a secondary root hub port.

The device under test must be attached directly to the open root hub port. The user must then select the device that needs to be tested. Once selected, the test will run without user intervention. While the test runs, any devices connected to other ports on the same root hub may become unusable for a period of time.

Initialization

  • Select device to test (must be plugged into root hub)
  • Open handle to host controller
  • Gather initial information
  • Device Descriptor
  • Config. Descriptor
  • String Descriptors (if supported by device and test)

Enumeration test (repeat n times) with no string descriptor support

  • Reset Device Port
  • Get Device Descriptor (first MPS with wLength value of FF)
  • Reset Device Port
  • Get Device Descriptor (full descriptor)
  • Set Address (address not in use)
  • Get Config. Descriptor
  • Compare device and configuration descriptors to initial ones
  • Set configuration to configuration 0

Enumeration test (repeat n times) with string descriptor support

  • Reset Device Port
  • Get Device Descriptor (first MPS with wLength value of FF)
  • Reset Device Port
  • Get Device Descriptor (full descriptor)
  • Set Address (address not in use)
  • Get Config. Descriptor
  • Compare device and configuration descriptors to initial ones
  • Set configuration to configuration 0

Result

Success indicated by device and configuration descriptor comparisons passing for n iterations. Any descriptor comparison failure

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Operating System
  • System with at least one available root hub port
  • Device/Hub under test

Results Interpretation

The test fails if:

  • Any standard device request is not properly handled by the device under test
  • Any standard device request does not meet the response time requirements as defined in the USB specification.


TD-9.24 USB Descriptor Test

Test Kit: HCT 11

Overview

The USB Descriptor test is required only for Universal Serial Bus (USB) peripheral devices and hubs. It verifies the proper response of a USB device to standard descriptor requests.

The USB Descriptor test requests both the device's device descriptor and configuration descriptor with varying lengths. The test calculates the upper limit to be at least two maximum packet sizes larger than the actual size of the descriptor. If this calculated upper limit is less than 255 bytes, the test increases the upper limit to 255 bytes. The USB test device is expected to return valid descriptor information; however, the amount of information returned must be no larger than the length requested by the test. If the length requested is greater than the size of the descriptor, the device must return the whole descriptor with no additional data.

Initialization

  • Select device to test (must be plugged into root hub)
  • Open handle to host controller
  • Gather initial information
  • Device Descriptor
  • Config Descriptor
  • String Descriptors (if supported by device and test)
  • Device Qualifier Descriptor (if USB 2.0 high-speed capable device)

Descriptor test

  • Reset Device Port
  • Repeat Get Device Descriptor with lengths of one to calculated upper bound in one byte increments
  • Repeat Get Configuration Descriptor with lengths of one to calculated upper bound in one byte increments
  • Set Address to 2
  • Repeat Get Device Descriptor with lengths of one to calculated upper bound in one byte increments
  • Repeat Get Configuration Descriptor with lengths of one to calculated upper bound in one byte increments

Result

Success indicated by device and configuration descriptor comparisons passing for all iterations.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows® XP Operating System
  • System with at least one available root hub port
  • Device/Hub

Results Interpretation

The test fails if:

  • Any standard descriptor request is not properly handled by the test device
  • Any standard descriptor request does not meet the response time requirements as defined in the USB specification.


TD-9.25 USB Device Framework (CV)

Test Kit: HCT 11

This test verifies that the test device provides support for the commands set forth in Chapter 9, "USB Device Framework" of the Universal Serial Bus (USB) Specification Revision 2.0.

More specifically, the test verifies that the test device responds correctly to device, configuration, and interface descriptor requests.

Overview

The Device Framework test runs a number of individual tests that verify various attributes and operations used by the function-specific portions of the test device. The tests also verify communications from the device through the bus interface to the host. The Device Framework test is based upon the USBCV compliance test tool provided by the USB-IF.

Click to show or hide information. Device States

For these tests, three different device states are used. Many of the tests run with the test device in more than one state. This section describes the three states and the procedures used to put the device into each of the states. The device state information may help with debugging in cases where the test device is not reaching the required starting state for the test. The individual test descriptions mention which device states they are run on, but do not repeat the setup procedure. The device states are as follows:

Default State:

In the default state, the test device is attached to the USB and is powered. The device has been reset, but has not been assigned a unique address. The device responds at the default address.

To put the device in the configured state, the following procedure is used:

  1. Issue a valid Set Configuration command to the device with configuration value zero.
  2. Issue a valid Get Configuration command and verify that the device responds with zero.
  3. Issue a valid Set Address command to the device with address zero.

Address State:

In the Address State, the device is attached to the USB and is receiving power. The device has been reset, and a unique device address has been assigned. The device is not configured.

To put the device in the Address State, the following procedure is used.

  1. Issue a valid Set Configuration command to the device with configuration value zero.
  2. Issue a valid Get Configuration command to the device and verify that device responds with zero.

Configured State:

In the Configured State, the device is attached to the USB and is receiving power. The device has been reset, and has a unique device address. The device is configured. The host can now use the function provided by the device.

Click to show or hide information. Device enumeration routine

The device is enumerated using the following routine:

  1. Get device descriptor using a maximum packet size of 64. (This will cause a short packet for devices with a bMaxPacketSize0 field < 64)
  2. Issue a Set Address command with the next available USB address.
  3. Get the device descriptor again with the right maximum packet size.
  4. Get configuration descriptor asking for a number of bytes equal to configuration descriptor size only.
  5. Issue a Set Configuration command for the first configuration supported by the device.
  6. Get the configuration descriptor again asking for a number of bytes equal to the configuration descriptor size.
  7. Get the configuration descriptor using the total length of the entire descriptor.

If the descriptors indicate the device is a hub, continue with the steps below:

  1. Get the hub class descriptor.
  2. Issue a Set Port Feature command with power selector PORT_POWER for each port on the hub.
  3. Sleep for 1 second.
  4. Issue Get Port Status commands for each port.
  5. If the connect bit is set in the port status issue a port reset and proceed to step 13. Otherwise stop.
  6. Sleep for 50 milliseconds.
  7. Check the port status to ensure the enable bit has been set. Then proceed to the enumerate device routine.

Click to show or hide information. Test cases

The USB Device Framework (CV) test runs the following test cases:

TD-9.25.1.1 Device Descriptor Test

TD-9.25.1.2 Device Qualifier Test

TD-9.25.1.3 Configuration Descriptor Test

TD-9.25.1.4 Interface Descriptor Test

TD-9.25.1.5 Endpoint Descriptor Test

TD-9.25.1.6 Halt Endpoint Test

TD-9.25.1.10 Remote Wakeup Test

TD-9.25.1.11 Set Configuration Test

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • USB device.

Results Interpretation

The test generates a detailed log file of test results and displays on-screen pass or fail status. The name of the log file is Usbcv_chap9.log.


TD-9.25.1.1 Device Descriptor Test

This test verifies that the test device responds to valid GetDescriptor requests and returns a descriptor in compliance with the specification.

Device States For Test

This test runs with the device in the default, address, and configured states.

Overview

The test performs the following steps.

  1. The test places the device in the starting state (Default, Address, or Configured).
  2. The test issues a valid Get_Descriptor request for the device with a requested length of 18 bytes.
  3. The test performs the following checks on the returned device descriptor value:

bLength == 18

bDescriptorType == DEVICE descriptor type

bcdUSB.hibyte == (01 or 02)

if (Device Speed == High) then bcdUSB.hibyte == 02

(if bcdUSB.hibyte == 01) then bcdUSB.lowbyte == (01 or 10 or 00)

if (bDeviceClass == 0) then bDeviceSubClass == 0.

if (Device Speed == Low) then bMaxPacketSize0 == 8.

If (Device Speed == Full) then bMaxPacketSize0 == (8 or 16 or 32 or 64)

If (Device Speed == High) then bMaxPacketSize0 == 64

Check that idVendor is in the list of valid entries maintained by the USB-IF.

bNumConfigurations != 0

  4. The test repeats steps 1, 2, and 3 with device in the other states (Default, Address, or Configured).
  5. If the device supports multiple configurations, the test is repeated for each possible configuration.
  6. If the device is a high-speed capable device, the test must be run with the device in both high-speed and full-speed operation.

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_chap9.log).

The test fails if:

  • Device enumeration fails following the method described in this specification.
  • Valid get descriptor commands fail for any reason.
  • Valid set address commands fail for any reason.
  • Valid set configuration commands fail for any reason.
  • Valid get configuration commands fail for any reason.
  • Any of the device descriptor content checks fail.


TD-9.25.1.2 Device Qualifier Test

This test verifies that the test device responds to valid GetDescriptor request for a device_qualifier and returns a descriptor in compliance with the USB specification.

Device States For Test

This test runs with the device in the Default, Address, and Configured states.

Overview

The test performs the following steps.

  1. The test places the device in the starting state (Default, Address, or Configured).
  2. The test issues a valid get device qualifier descriptor command with a requested length of 9 bytes.
  3. The test checks the following on the device_qualifier descriptor value:

bcdUSB.hibyte == 02

bLength == 10

bDescriptorType == DEVICE_QUALIFER descriptor type

if (bDeviceClass == 0) then bDeviceSubClass == 0.

If (Device Speed == High) then bMaxPacketSize0 == (8 or 16 or 32 or 64)

If (Device Speed == Full) then bMaxPacketSize0 == 64

BNumConfiguration != 0

bReserved != 0

  4. The test repeats steps 1, 2, and 3 with device in the other states (Default, Address, or Configured).
  5. If the device supports multiple configurations, the test is repeated for the configured state for each possible configuration.
  6. If the device is a high-speed capable device, the complete test must be run with the device in both full-speed and high-speed operation.

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_chap9.log).

The test fails if:

  • Device enumeration fails following the method described in this specification.
  • Valid get descriptor commands fail for any reason.
  • Valid set address commands fail for any reason.
  • Valid set configuration commands fail for any reason.
  • Valid get configuration commands fail for any reason.
  • Any of the device descriptor content checks fail.


TD-9.25.1.3 Configuration Descriptor Test

This test verifies that the test device responds to valid Get Configuration Descriptor commands and returns a descriptor in compliance with the USB specification.

Device States For Test

This test runs with the device in the Default, Address, and Configured states.

Overview

The test performs the following steps.

  1. The test places the device in the starting state (Default, Address, or Configured).
  2. The test issues a valid get configuration descriptor command with a requested length of 9 bytes.
  3. The test checks the configuration descriptor value:

BLength == 9

bDescriptorType == CONFIGURATION descriptor type (or OTHER_SPEED_CONFIGURATION type)

  4. The test issues a valid get configuration descriptor command with a requested length of wTotalLength from the configuration descriptor
  5. The test parses the data returned with the following information and checks:

The first descriptor must be a configuration descriptor as checked in step 3.

All other descriptors must be endpoint, interface, or class descriptors.

Counts the number of endpoint descriptors.

Counts the number of interface descriptors (alternate setting == 0)

Sums the bNumEndPoint values from all interface descriptors.

  6. Checks that the number of interface descriptors found equals the bNumInterfaces value in the configuration descriptor.
  7. Checks that the total number of endpoint descriptors found match the sum of the bNumEndPoint values from each of the interface descriptors.
  8. Issues a valid get configuration descriptor command with a requested length of 9 bytes.
  9. Performs each of the following checks on the configuration descriptor value:

bLength == 9

bDescriptorType == Configuration descriptor type

bNumInterface != 0

bmAttributes bits D0 to D4 == 0.

bmAttributes bit D7 == 1

if (bMaxPower == 0) bmAttributes D6 == 1

  10. If this is not an other_speed configuration test, the test issues a Get Status request for the device.

If the status request indicates the device is operating bus-powered bMaxPower must be less than 500 mA.

If the status request indicates the device is operating self-powered bMaxPower must be less than 100 mA.

  11. If the test supports multiple configurations repeat test for each configuration descriptor.
  12. If the device is a high-speed capable device, the test must be run with the device in both high-speed and full-speed operation and is also run for the other_speed_configuration descriptor.

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_chap9.log).

The test fails if:

  • Device enumeration fails following the method described in this specification.
  • Valid get descriptor commands fail for any reason.
  • Valid set address commands fail for any reason.
  • Valid set configuration commands fail for any reason.
  • Valid get configuration commands fail for any reason.
  • Any of the device descriptor content checks fail.


TD-9.25.1.4 Interface Descriptor Test

This test verifies that the test device reports interface descriptors in compliance with the specification.

Device States For Test

This test runs with the device in the Default, Address, and Configured states.

Overview

The test performs the following steps.

  1. The test places the device in the starting state (Default, Address, or Configured).
  2. The test sends a valid get configuration descriptor command with a requested length of 9 bytes.
  3. The test performs the following checks on the configuration descriptor value:

bLength == 9

bDescriptorType == CONFIGURATION descriptor type (or OTHER_SPEED_CONFIGURATION type)

  4. The test issues a valid get configuration descriptor command with a requested length of wTotalLength from the configuration descriptor.
  5. If this is not an other_speed_configuration test, the test sends a set configuration request to set the configuration of the device to the one being tested. The test then issues a get configuration command to make sure the correct configuration is indicated.
  6. Perform the following bandwidth check for all interface and endpoint descriptors returned by the device:

If a default interface (alternate setting zero) contains an isochronous endpoint with a maximum packet size greater than 0 the test fails.

If a default interface (alternate setting zero) contains an interrupt endpoint with a maximum packet size greater than 64 the test fails.

  7. Check that there is at least one interface descriptor in the data returned.
  8. Check that the first interface descriptor returned has bInterfaceNumber and bAlternateSetting values of zero.
  9. For each interface descriptor returned, the test performs the following checks:

If this is not the first interface descriptor (see check 8)

If (current interface number == previous interface number)

Then current alternate setting must be one greater

Else

Current interface number must be 1 greater than previous

Current alternate setting must be zero

Current interface number must be < total number interfaces

bLength > 8

bDescriptorType == INTERFACE descriptor type

if (bInterfaceClass == 0) then check that bInterfaceSubClass == 0

  10. If this is not an other_speed interface, the test performs the following additional checks.

Call set interface for the current bInterfaceNumber and bAlternateSetting values.

If the current interface has no alternate settings the device may STALL the request, otherwise it must succeed.

Call get interface for the current bInterfaceNumber and verify that the correct alternate setting value is returned.

  11. If the test supports multiple configurations repeat test for each configuration descriptor.
  12. If the device is a high-speed capable device the test must be run with the device in both high-speed and full-speed operation and is also run for the other_speed_configuration descriptor.

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_chap9.log).

The test fails if:

  • Device enumeration fails following the method described in this specification.
  • Valid get descriptor commands fail for any reason.
  • Valid set address commands fail for any reason.
  • Valid set configuration commands fail for any reason.
  • Valid get configuration commands fail for any reason.
  • Valid set interface requests fail for any reason.
  • Valid get interface requests fail for any reason.
  • Any of the device descriptor content checks fail.


TD-9.25.1.5 Endpoint Descriptor Test

This test verifies that the device under test reports endpoint descriptors in compliance with the specification.

Device States For Test

This test is run with the device in the Default, Address, and Configured states.

Overview

The test performs the following steps.

  1. The test places the device in the starting state (Default, Address, or Configured).
  2. Issue a valid get configuration descriptor command with a requested length of 9 bytes.
  3. Perform the following checks on the configuration descriptor value:

bLength == 9

bDescriptorType == CONFIGURATION descriptor type (or OTHER_SPEED_CONFIGURATION type)

  4. Issue a valid get configuration descriptor command with a requested length of wTotalLength from the configuration descriptor
  5. If this is not an other speed configuration test issue a Set configuration command to set the configuration of the device to the one being tested. Then issue a Get configuration command to make sure the correct configuration is indicated.
  6. Issue a valid get device descriptor command to store the bcdUSB value.
  7. For each endpoint descriptor found in the data returned from the get configuration descriptor request perform the following checks:

bLength > 6

bDescriptorType == ENDPOINT descriptor type

bEndPointAddress != (0x00 or 0x80)

bmAttributes D6-D7 must be zero.

BmAttributes D2-D5 must be zero unless the endpoint is isochronous and

bcdUSB is 0200 or greater.

Note There is an exception made if bcdUSB is 0x0101 or 0x0110 and the endpoint is part of an audio interface.

wMaxPacketSize bit D13 to D15 must be zero.

  8. The endpoint being tested is categorized according to the following logic:

Current Device Speed | Other Speed Descriptor | Category
Low | NA | CV_LOW
FULL | YES | CV_HIGH
FULL | NO | CV_FULL_2X (bcdUSB)
 |  | CV_FULL_1X
HIGH | NO | CV_HIGH
HIGH | YES | CV_FULL_2X

  9. For each endpoint descriptor the following endpoint type and speed dependent checks are performed:

If wMaxPacketSize bits D11 to D12 are non-zero the endpoint must be type CV_HIGH with transfer type INTERRUPT or ISOCHRONOUS.

  10. For Control endpoints the following checks are performed.

CV_LOW wMaxPacketSize == 8

CV_FULL (1x or 2x) wMaxPacketSize == (8 or 16 or 32 or 64)

CV_HIGH wMaxPacketSize == 64

  11. For Bulk endpoints the following checks are performed.

CV_LOW FAIL - ILLEGAL

CV_FULL (1x or 2x) wMaxPacketSize == (8 or 16 or 32 or 64)

CV_HIGH wMaxPacketSize == 512

  12. For Interrupt endpoints the following checks are performed.

CV_LOW bInterval >9

wMaxPacketSize < 9

CV_FULL_1X bInterval != 0

wMaxPacketSize < 65

CV_FULL_2X bInterval != 0

wMaxPacketSize < 65

CV_HIGH bInterval > 0 and bInterval < 16

MULT 0 wMaxPacketSize < 1025

MULT 1 wMaxPacketSize > 512 and wMaxSize < 1025

MULT 2 wMaxPacketSize > 682 and wMaxSize < 1025

  13. For Isochronous endpoints the following checks are performed.

CV_LOW FAIL - ILLEGAL

CV_FULL_1X bInterval == 1

wMaxPacketSize < 1024

CV_FULL_2X bInterval > 0 and bInterval < 17

wMaxPacketSize < 1024

CV_HIGH bInterval > 0 and bInterval < 17

MULT 0 wMaxPacketSize < 1025

MULT 1 wMaxPacketSize > 512 and wMaxSize < 1025

MULT 2 wMaxPacketSize > 682 and wMaxSize < 1025

  14. If the test supports multiple configurations, the test is repeated for each configuration descriptor.
  15. If the device is a high-speed capable device, the test must be run with the device in both high-speed and full-speed operation and is also run for the other_speed_configuration descriptor.

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_chap9.log).

The test fails if:

  • Device enumeration fails following the method described in this specification.
  • Valid get descriptor commands fail for any reason.
  • Valid set address commands fail for any reason.
  • Valid set configuration commands fail for any reason.
  • Valid get configuration commands fail for any reason.
  • Any of the device descriptor content checks fail.


TD-9.25.1.6 Halt Endpoint Test

This test is similar to the interface descriptor test except that it also checks that all bulk and interrupt endpoints can be programmatically halted.

Device States For Test

This test is run with the device in the Configured state.

Overview

The test performs the following steps.

  1. The test places the device in the Configured state.
  2. The test issues a valid get configuration descriptor command with a requested length of 9 bytes.
  3. Performs the following checks on the configuration descriptor value:

bLength == 9

bDescriptorType == CONFIGURATION descriptor type (or

OTHER_SPEED_CONFIGURATION type)

  4. The test issues a valid get configuration descriptor command with a requested length of wTotalLength from the configuration descriptor.
  5. If this is not an other_speed_configuration test, the test issues a set configuration command to set the configuration of the device to the one being tested. The test then issues a get configuration command to make sure the correct configuration is indicated.
  6. Performs the following bandwidth check for all interface and endpoint descriptors returned by the device:

If a default interface (alternate setting zero) contains an isochronous endpoint with a maximum packet size greater than 0 the test fails.

If a default interface (alternate setting zero) contains an interrupt endpoint with a maximum packet size greater than 64 the test fails.

  7. Check that there is at least one interface descriptor in the data returned.
  8. Check that the first interface descriptor returned has bInterfaceNumber and bAlternateSetting values of zero.
  9. For each interface descriptor returned perform the following checks:

If this is not the first interface descriptor (see check 8)

If (current interface number == previous interface number)

Then current alternate setting must be one greater

Else

Current interface number must be 1 greater than previous

Current alternate setting must be zero

Current interface number must be < total number interfaces

bLength > 8

bDescriptorType == INTERFACE descriptor type

if (bInterfaceClass == 0) then check that bInterfaceSubClass == 0

  10. If this is not an other_speed interface, the test makes the following additional checks.

Call set interface for the current bInterfaceNumber and bAlternateSetting values.

If the current interface has no alternate settings the device may STALL the request, otherwise it must succeed.

Call get interface for the current bInterfaceNumber and verify that the correct alternate setting value is returned.

  11. For each endpoint associated with interface descriptor in step 10, the test performs the following checks if the endpoint is bulk or interrupt:

Issue a valid Get Status request for the endpoint.

If the endpoint is halted, issue a valid Clear Feature request with feature selector ENDPOINT_HALT. Then issue a valid Get Status request for the endpoint and verify that the endpoint no longer reports halt.

Issue a valid Set Feature request with feature selector ENDPOINT_HALT.

Issue a valid Get Status request for the endpoint.

Verify that ENDPOINT_HALT is reported in the status.

Issue a valid Clear Feature request with feature selector ENDPOINT_HALT

Issue a valid Get Status request for the endpoint.

Verify that ENDPOINT_HALT is not reported in the status.

  12. If the test supports multiple configurations, the test is repeated for each configuration descriptor.

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_chap9.log).

The test fails if:

  • Device enumeration fails following the method described in this specification.
  • Valid get descriptor commands fail for any reason.
  • Valid set address commands fail for any reason.
  • Valid set configuration commands fail for any reason.
  • Valid get configuration commands fail for any reason.
  • Valid set interface requests fail for any reason.
  • Valid get interface requests fail for any reason.
  • Valid get status requests fail for any reason.
  • Valid set feature (ENDPOINT_HALT) requests fail for any reason.
  • Valid clear feature (ENDPOINT_HALT) requests fail for any reason.
  • Any of the device descriptor content checks fail.


TD-9.25.1.10 Remote Wakeup Test

This test checks each device configuration supporting remotewakeup to ensure that the device properly supports the Set and Clear feature commands with feature selector DEVICE_REMOTE_WAKEUP.

Device States For Test

This test is run with the device in the Configured state. For each remote wakeup capable configuration the test is run with remote wakeup enabled (must work) and disabled (must not work).

Overview

The test performs the following steps.

  1. The test places the device in the Address state.
  2. The test issues a valid get configuration descriptor command with a requested length of 9 bytes.
  3. The test performs the following checks on the configuration descriptor value:

bLength == 9

bDescriptorType == CONFIGURATION descriptor type

bmAttributes bit D5 == 1 (Remote Wakeup)

  4. Repeat steps 2 and 3 for each configuration.
  5. If bit D5 is never set there is nothing to test.
  6. If bit D5 is set for some configurations, the test issues a valid get configuration for the configuration that was set in Step 1. If bit D5 is set, proceed with the Remote Wakeup Test; otherwise, there is nothing to test for this configuration.

Remote Wakeup Test

  1. The test issues a valid Set Configuration command to set the device into the remote wakeup capable configuration being tested (enabled or disabled).
  2. The test issues a valid Get Configuration command and verifies that the device reports the configuration that was set in step 1.
  3. The test issues a valid Set Feature command with feature selector DEVICE_REMOTE_WAKEUP.
  4. The test issues a valid Get Status command and verifies that Remote Wakeup is reported.
  5. If this is a remote wakeup disabled test, the test issues a valid Clear Feature command with feature selector DEVICE_REMOTE_WAKEUP. The test then issues a valid Get Status command and verifies that Remote Wakeup is not reported.
  6. The test suspends the parent port of the device under test.
  7. The test sleeps for 1 second.
  8. The test checks the parent port status to verify that it has suspended.
  9. The test prompts you to generate a remote wakeup event on the test device.
  10. Polls the parent port for up to 15 seconds, sending valid Get Port Status commands, and checks to see when (if) the PORT_SUSPEND bit is cleared.
  11. If the test supports multiple configurations, the test is repeated for each configuration descriptor. If the device is high-speed capable, the test repeats with the device operating at high-speed and full-speed.

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_chap9.log).

The test fails if:

  • Device enumeration fails following the method described in this specification.
  • Valid get descriptor commands fail for any reason.
  • Valid set address commands fail for any reason.
  • Valid set configuration commands fail for any reason.
  • Valid get configuration commands fail for any reason.
  • Valid get status requests fail for any reason.
  • Valid set feature (DEVICE_REMOTE_WAKEUP) requests fail for any reason.
  • Valid clear feature (DEVICE_REMOTE_WAKEUP) requests fail for any reason.
  • Device status does not properly indicate the whether remote wakeup is enabled.
  • The device produces a remote wakeup event when remote wakeup is disabled.
  • The device does not produce a remote wakeup event when remote wakeup is enabled.
  • The device prevents its parent port from entering the suspend state.


TD-9.25.1.11 Set Configuration Test

This test checks each device configuration that can be set using Set Configuration command and that the device properly reports its current configuration in response to the Get Configuration command.

Device States For Test

This test is run with the device starting in the Address state.

Overview

The test performs the following steps.

  1. The test places the device in the address state.
  2. The test issues a valid get configuration descriptor command with a requested length of 9 bytes for configuration index zero.
  3. The test issues a valid set configuration request using the bConfigurationValue obtained in step two.
  4. The test issues a valid get configuration request and verifies the configuration set in step 3 is reported.
  5. The test issues a valid get configuration descriptor command with a requested length of 9 bytes for the configuration to be tested.
  6. The test issues a valid set configuration request using the bConfigurationValue obtained in step 5.
  7. The test issues a valid get configuration request and verifies that the configuration set in step 6 is reported.
  8. The test issues a valid set configuration request using configuration value zero.
  9. The test issues a valid get Configuration command and verifies that the device reports the configuration that was set in step 7.
  10. The test issues a valid set configuration request using the bConfigurationValue obtained in step five.
  11. The test issues a valid get configuration request and verifies the configuration set in step 10 is reported.
  12. If the test supports multiple configurations, the test is repeated for each configuration descriptor. If the device is high-speed capable, the test repeats operating at high speed and full speed.

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_chap9.log).

The test fails if:

  • Device enumeration fails following the method described in this specification.
  • Valid get descriptor commands fail for any reason.
  • Valid set address commands fail for any reason.
  • Valid set configuration commands fail for any reason.
  • Valid get configuration commands fail for any reason.
  • Valid get status requests fail for any reason.
  • Valid set feature (DEVICE_REMOTE_WAKEUP) requests fail for any reason.
  • Valid clear feature (DEVICE_REMOTE_WAKEUP) requests fail for any reason.
  • Device status does not properly indicate the whether remote wakeup is enabled.
  • The device produces a remote wakeup event when remote wakeup is disabled.
  • The device does not produce a remote wakeup event when remote wakeup is enabled.
  • The device prevents its parent port from entering the suspend state.


TD-9.26 USB Hub Compliance (CV)

Test Kit: HCT 11

This test verifies that the Universal Serial Bus (USB) hub complies with Chapter 11 of the Universal Serial Bus Specification Revision 2.0.

Overview

The USB Hub Compliance test verifies that the hub responds correctly to hub descriptor and remote wake requests. This test is based upon the USBCV compliance test tool provided by the USB-IF.

The USB hub provides additional connectivity for USB peripherals. The hub also provides power to attached peripherals, and recognizes dynamic attachment and removal of peripheral devices.

Click to show or hide information. Test cases

The USB Hub Compliance test runs the following test cases:

TD-9.26.2.1 Detach Device From Enabled Port Test

TD-9.26.2.2 Detach Device From Suspended Port

TD-9.26.2.3 Disable The Enabled Port Test

TD-9.26.2.4 Hot Plug Device Port Test

TD-9.26.2.5 Power Off Suspended Port Test

TD-9.26.2.6 Power Off and On Port Test

TD-9.26.2.7 Remote Wakeup Port Test

TD-9.26.2.8 Reset Enabled Port With Device Connected Port Test

TD-9.26.2.9 Reset Disabled Port With Device Connected Port Test

TD-9.26.2.10 Reset Suspended Port Test

TD-9.26.2.11 Resume Port Test

TD-9.26.2.12 Suspend Port Test

TD-9.26.2.13 Suspend and Ignore Connect

TD-9.26.2.14 Suspend and Ignore Disconnect

TD-9.26.2.15 Suspend and Disconnect Device

TD-9.26.2.16 Suspend and Connect Device

TD-9.26.2.17 Suspend and Remote Wakeup

TD-9.26.2.18 Hub Descriptor Test

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • USB Hub.

Results Interpretation

The test generates a detailed log file of test results and displays on-screen pass or fail status. The name of the log file is Usbcv_chap11.log.


Status Change Endpoint Test

The host system receives port and hub status change notifications through the Status Change endpoint. The USB Hub Compliance tests create events that set the port change bits of the hub. The USB Hub Compliance tests use the following procedure to check the Status Change endpoint. This procedure is shown here for reference.

To check the Status Change Endpoint

  1. The test performs the following steps for up to 15 seconds.
  2. The test sends interrupt IN commands with a requested length of 8 bytes and a timeout of 50 milliseconds to the Status Change endpoint of the hub.
  3. The test repeats step 2 until the 15-second timeout is exceeded or until the interrupt IN command returns data (doesn’t time out).
  4. If the 15-second timeout is reached, the test times out and fails.
  5. If data is received from the Status Change endpoint it must meet the following conditions:

a. The change bit for the port under test must be set.

b. No other change bits for any other ports can be set.

c. Bit Zero (Hub Change) must not be set.

Note Not all the USB Hub Compliance tests involve events that will product a status change. The tests that do, list the Status Change Endpoint Test as one of the steps.


TD-9.26.2.1 Detach Device From Enabled Port Test

This test verifies that if a device is detached from an enabled hub port, the port status correctly shows a connect change and that port power is still set.

Starting Configuration

Test Port: Any Device Port Enabled

Other Ports: No Device Port Enabled

Overview

The test performs the following steps.

  1. Enumerates the USB bus.
  2. Checks to verify that the ports are in the proper starting configuration using Get Port Status.
  3. Clears all port change bits using the Clear Port Feature command.
  4. Calls Get Port Status on each port and stores the initial port status values.
  5. The test prompts you to disconnect the device from the test port.
  6. The test checks the port status by running the Status Change Endpoint test.
  7. Issues a get port status command on the test port.
  8. Checks that the port state is as follows:

PORT_CONNECTION MUST BE ZERO

PORT_ENABLE MUST BE ZERO

PORT_SUSPEND MUST BE ZERO

PORT_OVER_CURRENT MUST BE ZERO

PORT_RESET MUST BE ZERO

PORT_POWER MUST BE SET

PORT_LOW_SPEED IGNORE

PORT_HIGH_SPEED IGNORE

PORT_TEST MUST BE ZERO

PORT_INDICATOR MUST BE ZERO

C_PORT_CONNECTION MUST BE SET

C_PORT_ENABLE MUST BE ZERO

C_PORT_SUSPEND MUST BE ZERO

C_PORT_OVER_CURRENT MUST BE ZERO

C_PORT_RESET MUST BE ZERO

  9. Calls Get Port Status on all non-test ports.
  10. Verifies that there were no changes in the port status on any of the non-test ports.
  11. Repeats steps 1 to 10 with the remaining ports that have not been tested.

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_chap11.log).

The test fails if:

  • Valid Get Port Status commands fail for any reason.
  • Valid Clear Port Feature commands fail for any reason.
  • A known good device fails to enumerate for any reason.
  • Any port status bits change on the non-test ports during the course of the test.
  • The port status for the port under test does not change as described.


TD-9.26.2.2 Detach Device From Suspended Port

This test verifies that if a device is detached from a suspended hub port, the port status correctly shows a connect change and that port power is still set.

Starting Configuration

Test Port: Any Device Port Enabled

Other Ports: No Device Port Enabled

Overview

The test performs the following steps.

  1. Enumerates the USB bus.
  2. Checks to verify that the ports are in the proper starting configuration using Get Port Status.
  3. Clears all port change bits using the Clear Port Feature command.
  4. Calls Get Port Status on each port and stores the initial port status values.
  5. Calls Set Port Feature to suspend the port.
  6. The test issues a get port status command to the port under test to verify it is suspended and continues making calls until suspend is indicated or one second elapses.
  7. The test prompts you to disconnect the device from the test port.
  8. The test checks the port status by running the Status Change Endpoint test.
  9. Issues a get port status command on the test port.
  10. Checks that the test port state is as follows:

PORT_CONNECTION MUST BE ZERO

PORT_ENABLE MUST BE ZERO

PORT_SUSPEND MUST BE ZERO

PORT_OVER_CURRENT MUST BE ZERO

PORT_RESET MUST BE ZERO

PORT_POWER MUST BE SET

PORT_LOW_SPEED IGNORE

PORT_HIGH_SPEED IGNORE

PORT_TEST MUST BE ZERO

PORT_INDICATOR MUST BE ZERO

C_PORT_CONNECTION MUST BE SET

C_PORT_ENABLE MUST BE ZERO

C_PORT_SUSPEND MUST BE ZERO

C_PORT_OVER_CURRENT MUST BE ZERO

C_PORT_RESET MUST BE ZERO

  11. Call Get Port Status on all non-test ports.
  12. Verifies that there were no changes in the port status on any of the non-test ports.
  13. Repeats steps 1 to 12 with each of the remaining ports.

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_chap11.log).

The test fails if:

  • Valid Get Port Status commands fail for any reason.
  • Valid Clear Port Feature commands fail for any reason.
  • A known good device fails to enumerate for any reason.
  • Any port status bits change on the non-test ports during the course of the test.
  • The port status for the port under test does not change as described.
  • A valid Set Port Feature command does not suspend the test port.


TD-9.26.2.3 Disable the Enabled Port Test

This test verifies that if an enabled port is programmatically disabled no port change bits are set. The test also verifies that the connect and power status bits remain set.

Starting Configuration

Test Port: Any Device Port Enabled

Other Ports: No Device Port Enabled

Overview

  1. The test performs the following steps.
  2. Enumerates the USB bus.
  3. Checks to verify that the ports are in the proper starting configuration using Get Port Status.
  4. Clears all port change bits using the Clear Port Feature command.
  5. Calls Get Port Status on each port and stores the initial port status values.
  6. Issues a Clear Port Feature command with feature selector PORT_ENALBE to disable the port under test.
  7. Issues a get port status command on the test port.
  8. Checks that the port under test state is as follows:

PORT_CONNECTION MUST BE SET

PORT_ENABLE MUST BE ZERO

PORT_SUSPEND MUST BE ZERO

PORT_OVER_CURRENT MUST BE ZERO

PORT_RESET MUST BE ZERO

PORT_POWER MUST BE SET

PORT_LOW_SPEED MUST NOT CHANGE

PORT_HIGH_SPEED MUST NOT CHANGE

PORT_TEST MUST BE ZERO

PORT_INDICATOR MUST BE ZERO

C_PORT_CONNECTION MUST BE ZERO

C_PORT_ENABLE MUST BE ZERO

C_PORT_SUSPEND MUST BE ZERO

C_PORT_OVER_CURRENT MUST BE ZERO

C_PORT_RESET MUST BE ZERO

  9. Calls the Get Port Status requests on all non-test ports.
  10. Verifies that there were no changes in the port status on any of the non-test ports.
  11. Repeats steps 1 to 9 with each of the remaining ports.

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_chap11.log).

The test fails if:

  • Valid Get Port Status commands fail for any reason.
  • Valid Clear Port Feature commands fail for any reason.
  • A known good device fails to enumerate for any reason.
  • Any port status bits change on the non-test ports during the course of the test.
  • The port status for the port under test does not change as described.


TD-9.26.2.4 Hot Plug Device Port Test

This test verifies that when you connect a device to a port of the test hub, the status bits in the port are updated appropriately.

Starting Configuration

Test Port: No Device Port Enabled

Other Ports: No Device Port Enabled

Overview

The test performs the following steps.

  1. The test enumerates the USB bus.
  2. The test verifies that the ports are in the proper starting configuration using Get Port Status.
  3. The test clears all port change bits using the Clear Port Feature command.
  4. The test calls Get Port Status on each port and stores the initial port status values.
  5. The test prompts you to connect a device to the test port.
  6. The test checks the port status by running the Status Change Endpoint test.
  7. Issues a get port status command on the port under test.
  8. The test checks that the test port is configured as follows:

PORT_CONNECTION MUST BE SET

PORT_ENABLE MUST BE ZERO

PORT_SUSPEND MUST BE ZERO

PORT_OVER_CURRENT MUST BE ZERO

PORT_RESET MUST BE ZERO

PORT_POWER MUST BE SET

PORT_LOW_SPEED IGNORE

PORT_HIGH_SPEED IGNORE

PORT_TEST MUST BE ZERO

PORT_INDICATOR MUST BE ZERO

C_PORT_CONNECTION MUST BE SET

C_PORT_ENABLE MUST BE ZERO

C_PORT_SUSPEND MUST BE ZERO

C_PORT_OVER_CURRENT MUST BE ZERO

C_PORT_RESET MUST BE ZERO

  9. The test calls Get Port Status on all non-test ports.
  10. Verifies that there were no changes in the port status on any of the non-test ports.
  11. Repeats steps 1 to 10 with each of the remaining ports.

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_chap11.log).

The test fails if:

  • Valid Get Port Status commands fail for any reason.
  • Valid Clear Port Feature commands fail for any reason.
  • A known good device fails to enumerate for any reason.
  • Any port status bits change on the non-test ports during the course of the test.
  • The port status for the port under test does not change as described.


TD-9.26.2.5 Power Off Suspended Port Test

This test verifies that if a suspended port is powered off the port correctly indicates all zeros for the port status.

Starting Configuration

Test Port: Any Device Port Enabled

Other Ports: No Device Port Enabled

Overview

The test performs the following steps.

  1. The test enumerates the USB bus.
  2. The test verifies that the ports are in the proper starting configuration using Get Port Status.
  3. The test clears all port change bits using the Clear Port Feature command.
  4. Calls Get Port Status on each port and stores the initial port status values.
  5. Issues a Set Port Feature command with feature selector PORT_SUSPEND.
  6. Issues a Get Port Status command on the port under test. Continues making calls until suspend is indicated or 1 second has elapsed.
  7. Check that the port status for the port under test is as follows:

PORT_CONNECTION MUST BE SET

PORT_ENABLE IGNORE

PORT_SUSPEND MUST BE SET

PORT_OVER_CURRENT MUST BE ZERO

PORT_RESET MUST BE ZERO

PORT_POWER MUST BE SET

PORT_LOW_SPEED IGNORE

PORT_HIGH_SPEED IGNORE

PORT_TEST MUST BE ZERO

PORT_INDICATOR MUST BE ZERO

C_PORT_CONNECTION MUST BE ZERO

C_PORT_ENABLE MUST BE ZERO

C_PORT_SUSPEND MUST BE ZERO

C_PORT_OVER_CURRENT MUST BE ZERO

C_PORT_RESET MUST BE ZERO

  8. Issues a Clear Port Feature command with feature selector PORT_POWER.
  9. Issues a get port status command on the test port.
  10. Checks that the state of the test port is as follows:

PORT_CONNECTION IGNORE

PORT_ENABLE IGNORE

PORT_SUSPEND IGNORE

PORT_OVER_CURRENT IGNORE

PORT_RESET IGNORE

PORT_POWER MUST BE ZERO

PORT_LOW_SPEED IGNORE

PORT_HIGH_SPEED IGNORE

PORT_TEST IGNORE

PORT_INDICATOR IGNORE

C_PORT_CONNECTION IGNORE

C_PORT_ENABLE IGNORE

C_PORT_SUSPEND IGNORE

C_PORT_OVER_CURRENT IGNORE

C_PORT_RESET IGNORE

  11. Calls Get Port Status on all non-test ports.
  12. Verifies that there were no changes in the port status on any of the non-test ports.
  13. Repeats steps 1 to 12 with each of the remaining ports.

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_chap11.log).

The test fails if:

  • Valid Get Port Status commands fail for any reason.
  • Valid Clear Port Feature commands fail for any reason.
  • A known good device fails to enumerate for any reason.
  • Any port status bits change on the non-test ports during the course of the test.
  • The port status for the port under test does not change as described.


TD-9.26.2.6 Power Off and On Port Test

This test verifies that a hub reports the port status correctly when the power to the port is turned on and off with and without devices connected.

Starting Configuration

Test Port: Any Device/No Device Port Enabled

Other Ports: No Device Port Enabled

Overview

The test performs the following steps.

  1. The test enumerates the USB bus.
  2. The test verifies that the ports are in the proper starting configuration using Get Port Status.
  3. The test clears all port change bits using the Clear Port Feature command.
  4. Calls Get Port Status on each port and stores the initial port status values.
  5. Issues a Clear Port Feature command with feature selector PORT_POWER.
  6. Issues a Get Port Status command to the test port.
  7. Checks that the port status for the test port is configured as follows:

PORT_CONNECTION IGNORE

PORT_ENABLE IGNORE

PORT_SUSPEND IGNORE

PORT_OVER_CURRENT IGNORE

PORT_RESET IGNORE

PORT_POWER MUST BE ZERO

PORT_LOW_SPEED IGNORE

PORT_HIGH_SPEED IGNORE

PORT_TEST IGNORE

PORT_INDICATOR IGNORE

C_PORT_CONNECTION IGNORE

C_PORT_ENABLE IGNORE

C_PORT_SUSPEND IGNORE

C_PORT_OVER_CURRENT IGNORE

C_PORT_RESET IGNORE

  8. The test issues a Set Port Feature Command with feature selector PORT_POWER.
  9. The test checks the port status by running the Status Change Endpoint test.
  10. The test issues a Get Port Status command for the test port.
  11. The test checks that the state of the test port is as follows:

PORT_CONNECTION SET (if device on test port)

PORT_ENABLE MUST BE ZERO

PORT_SUSPEND MUST BE ZERO

PORT_OVER_CURRENT MUST BE ZERO

PORT_RESET MUST BE ZERO

PORT_POWER MUST BE SET

PORT_LOW_SPEED MUST NOT CHANGE (Step 2)

PORT_HIGH_SPEED MUST NOT CHANGE (Step 2)

PORT_TEST MUST BE ZERO

PORT_INDICATOR MUST BE ZERO

C_PORT_CONNECTION MUST BE SET (if device)

C_PORT_ENABLE MUST BE ZERO

C_PORT_SUSPEND MUST BE ZERO

C_PORT_OVER_CURRENT MUST BE ZERO

C_PORT_RESET MUST BE ZERO

  12. The test sends a Get Port Status to all non-test ports.
  13. The test verifies that there were no changes in the port status on any of the non-test ports.
  14. Repeats steps 1 to 13 with each of the remaining ports, with and without a device on the test port.

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_chap11.log).

The test fails if:

  • Valid Get Port Status commands fail for any reason.
  • Valid Clear Port Feature commands fail for any reason.
  • A known good device fails to enumerate for any reason.
  • Any port status bits change on the non-test ports during the course of the test.
  • The port status for the test port does not change as described.


TD-9.26.2.7 Remote Wakeup Port Test

This test verifies that if a device connected to a port of the test hub issues a remote wakeup, the port status is updated appropriately.

Starting Configuration

Test Port: Remote Wakeup Capable Device Port Enabled

Other Ports: No Device Port Enabled

Overview

The test performs the following steps.

  1. The test enumerates the USB bus.
  2. The test verifies that the ports are in the proper starting configuration using Get Port Status.
  3. The test clears all port change bits using the Clear Port Feature command.
  4. The test calls Get Port Status on each port and stores the initial port status values.
  5. The test issues a Set Port Feature command with feature selector PORT_SUSPEND to suspend the test port.
  6. The test sends a Get Port Status command to the test port, and continues issuing calls until suspend is indicated or until one second has elapsed.
  7. The test checks the test port state as follows:

PORT_CONNECTION MUST BE SET

PORT_ENABLE IGNORE

PORT_SUSPEND MUST BE SET

PORT_OVER_CURRENT MUST BE ZERO

PORT_RESET MUST BE ZERO

PORT_POWER MUST BE SET

PORT_LOW_SPEED IGNORE

PORT_HIGH_SPEED IGNORE

PORT_TEST MUST BE ZERO

PORT_INDICATOR MUST BE ZERO

C_PORT_CONNECTION MUST BE ZERO

C_PORT_ENABLE MUST BE ZERO

C_PORT_SUSPEND MUST BE ZERO

C_PORT_OVER_CURRENT MUST BE ZERO

C_PORT_RESET MUST BE ZERO

  8. The test prompts you to issue a remote wakeup on the device attached to the test port.
  9. The test checks the port status by running the Status Change Endpoint test.
  10. The test issues a get port status command on the test port.
  11. The test checks the state of the test port as follows:

PORT_CONNECTION MUST BE SET

PORT_ENABLE MUST BE SET

PORT_SUSPEND MUST BE ZERO

PORT_OVER_CURRENT MUST BE ZERO

PORT_RESET MUST BE ZERO

PORT_POWER MUST BE SET

PORT_LOW_SPEED MUST NOT CHANGE

PORT_HIGH_SPEED MUST NOT CHANGE

PORT_TEST MUST BE ZERO

PORT_INDICATOR MUST BE ZERO

C_PORT_CONNECTION MUST BE ZERO

C_PORT_ENABLE MUST BE ZERO

C_PORT_SUSPEND MUST BE SET

C_PORT_OVER_CURRENT MUST BE ZERO

C_PORT_RESET MUST BE ZERO

  12. The test verifies that there were no changes in the port status on any of the non-test ports.
  13. The test repeats steps 1 to 12 with each of the remaining ports.

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_chap11.log).

The test fails if:

  • Valid Get Port Status commands fail for any reason.
  • Valid Clear Port Feature commands fail for any reason.
  • A known good device fails to enumerate for any reason.
  • Any port status bits change on the non-test ports during the course of the test.
  • The port status for the port under test does not change as described.


TD-9.26.2.8 Reset Enabled Port With Device Connected Port Test

This test verifies that if a device is connected to a port of the hub under test that status bits in the port are updated appropriately when a port reset is performed.

Starting Configuration

Test Port: Any Device Port Enabled

Other Ports: No Device Port Enabled

Overview

The test performs the following steps.

  1. The test enumerates the USB bus.
  2. The test verifies that the ports are in the proper starting configuration using Get Port Status.
  3. The test clears all port change bits using the Clear Port Feature command.
  4. The test calls Get Port Status on each port and stores the initial port status values.
  5. The test issues a Set Port Feature command with feature selector PORT_RESET for the test port.
  6. The test checks the port status by running the Status Change Endpoint test.
  7. The test issues a Get Port Status command to the test port.
  8. The test checks that the port under test state is as follows:

PORT_CONNECTION MUST BE SET

PORT_ENABLE MUST BE SET

PORT_SUSPEND MUST BE ZERO

PORT_OVER_CURRENT MUST BE ZERO

PORT_RESET MUST BE ZERO

PORT_POWER MUST BE SET

PORT_LOW_SPEED MUST NOT CHANGE

PORT_HIGH_SPEED MUST NOT CHANGE

PORT_TEST MUST BE ZERO

PORT_INDICATOR MUST BE ZERO

C_PORT_CONNECTION MUST BE ZERO

C_PORT_ENABLE MUST BE ZERO

C_PORT_SUSPEND MUST BE ZERO

C_PORT_OVER_CURRENT MUST BE ZERO

C_PORT_RESET MUST BE SET

9. The test calls Get Port Status for all non-test ports.

10. Verifies that there were no changes in the port status on any of the non-test ports.

11. Repeats steps 1 to 10 with each of the remaining ports.

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_chap11.log).

The test fails if:

  • Valid Get Port Status commands fail for any reason.
  • Valid Clear Port Feature commands fail for any reason.
  • A known good device fails to enumerate for any reason.
  • Any port status bits change on the non-test ports during the course of the test.
  • The port status for the port under test does not change as described.


TD-9.26.2.9 Reset Disabled Port With Device Connected Port Test

This test verifies that if a device is connected to a disabled port of the hub under test that status bits in the port are updated appropriately when a port reset is performed.

Starting Configuration

Test Port: Any Device Port Enabled

Other Ports: No Device Port Enabled

Overview

The test software performs the following steps.

The test performs the following steps.

  1. The test enumerates the USB bus.
  2. The test verifies that the ports are in the proper starting configuration using Get Port Status.
  3. The test clears all port change bits using the Clear Port Feature command.
  4. The test calls Get Port Status on each port and stores the initial port status values.
  5. The test issues a Clear Port Feature command with feature selector PORT_ENABLE for the test port.
  6. The test issues a Get Port Status command on the test port.
  7. The test checks the state of the port as follows:

PORT_CONNECTION MUST BE SET

PORT_ENABLE MUST BE ZERO

PORT_SUSPEND MUST BE ZERO

PORT_OVER_CURRENT MUST BE ZERO

PORT_RESET MUST BE ZERO

PORT_POWER MUST BE SET

PORT_LOW_SPEED MUST NOT CHANGE

PORT_HIGH_SPEED MUST NOT CHANGE

PORT_TEST MUST BE ZERO

PORT_INDICATOR MUST BE ZERO

C_PORT_CONNECTION MUST BE ZERO

C_PORT_ENABLE MUST BE ZERO

C_PORT_SUSPEND MUST BE ZERO

C_PORT_OVER_CURRENT MUST BE ZERO

C_PORT_RESET MUST BE ZERO

  8. The test issues a Set Port Feature command with feature selector PORT_RESET for the test port.
  9. The test checks the port status by running the Status Change Endpoint test.
  10. The test issues a Get Port Status command on the test port.
  11. Check that the port under test state is as follows:

PORT_CONNECTION MUST BE SET

PORT_ENABLE MUST BE SET

PORT_SUSPEND MUST BE ZERO

PORT_OVER_CURRENT MUST BE ZERO

PORT_RESET MUST BE ZERO

PORT_POWER MUST BE SET

PORT_LOW_SPEED MUST NOT CHANGE

PORT_HIGH_SPEED MUST NOT CHANGE

PORT_TEST MUST BE ZERO

PORT_INDICATOR MUST BE ZERO

C_PORT_CONNECTION MUST BE ZERO

C_PORT_ENABLE MUST BE ZERO

C_PORT_SUSPEND MUST BE ZERO

C_PORT_OVER_CURRENT MUST BE ZERO

C_PORT_RESET MUST BE SET

  12. The test calls Get Port Status on all non-test ports.
  13. The test verifies that there were no changes in the port status on any of the non-test ports.
  14. The test repeats steps 1 to 13 with each of the remaining ports.

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_chap11.log).

The test fails if:

  • Valid Get Port Status commands fail for any reason.
  • Valid Clear Port Feature commands fail for any reason.
  • A known good device fails to enumerate for any reason.
  • Any port status bits change on the non-test ports during the course of the test.
  • The port status for the test port does not change as described.


TD-9.26.2.10 Reset Suspended Port Test

This test verifies that if a device is connected to a suspended port of the test hub, the status bits in the port are updated appropriately when a port reset is performed.

Starting Configuration

Test Port: Any Device Port Enabled

Other Ports: No Device Port Enabled

Overview

The test software performs the following steps.

The test performs the following steps.

  1. The test enumerates the USB bus.
  2. The test verifies that the ports are in the proper starting configuration using Get Port Status.
  3. The test clears all port change bits using the Clear Port Feature command.
  4. The test calls Get Port Status on each port and stores the initial port status values.
  5. The test issues a Set Port Feature command with feature selector PORT_SUSPEND for the test port.
  6. The test issues a Get Port Status command on the test port. The test continues to send Get Port Status commands until suspend is indicated or until one second has elapsed.
  7. The test verifies that the port state is as follows:

PORT_CONNECTION MUST BE SET

PORT_ENABLE IGNORE

PORT_SUSPEND MUST BE SET

PORT_OVER_CURRENT MUST BE ZERO

PORT_RESET MUST BE ZERO

PORT_POWER MUST BE SET

PORT_LOW_SPEED MUST NOT CHANGE

PORT_HIGH_SPEED MUST NOT CHANGE

PORT_TEST MUST BE ZERO

PORT_INDICATOR MUST BE ZERO

C_PORT_CONNECTION MUST BE ZERO

C_PORT_ENABLE MUST BE ZERO

C_PORT_SUSPEND MUST BE ZERO

C_PORT_OVER_CURRENT MUST BE ZERO

C_PORT_RESET MUST BE ZERO

  8. The test issues a Set Port Feature command with feature selector PORT_RESET for the test port.
  9. The test checks the port status by running the Status Change Endpoint test.
  10. The test issues a Get Port Status command on the test port.
  11. The test checks that the port state is as follows:

PORT_CONNECTION MUST BE SET

PORT_ENABLE MUST BE SET

PORT_SUSPEND MUST BE ZERO

PORT_OVER_CURRENT MUST BE ZERO

PORT_RESET MUST BE ZERO

PORT_POWER MUST BE SET

PORT_LOW_SPEED MUST NOT CHANGE

PORT_HIGH_SPEED MUST NOT CHANGE

PORT_TEST MUST BE ZERO

PORT_INDICATOR MUST BE ZERO

C_PORT_CONNECTION MUST BE ZERO

C_PORT_ENABLE MUST BE ZERO

C_PORT_SUSPEND MUST BE ZERO

C_PORT_OVER_CURRENT MUST BE ZERO

C_PORT_RESET MUST BE SET

  12. The test calls Get Port Status on all non-test ports.
  13. The test verifies that there were no changes in the port status on any of the non-test ports.
  14. The test repeats steps 1 to 13 with each of the remaining ports.

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_chap11.log).

The test fails if:

  • Valid Get Port Status commands fail for any reason.
  • Valid Clear Port Feature commands fail for any reason.
  • A known good device fails to enumerate for any reason.
  • Any port status bits change on the non-test ports during the course of the test.
  • The port status for the port under test does not change as described.


TD-9.26.2.11 Resume Port Test

This test verifies that if a device is connected to a suspended port of the hub, the status bits in the port are updated appropriately when a port resume is performed.

Starting Configuration

Test Port: Any Device Port Enabled

Other Ports: No Device Port Enabled

Overview

The test software performs the following steps.

The test performs the following steps.

  1. The test enumerates the USB bus.
  2. The test verifies that the ports are in the proper starting configuration using Get Port Status.
  3. The test clears all port change bits using the Clear Port Feature command.
  4. The test calls Get Port Status on each port and stores the initial port status values.
  5. The test issues a Set Port Feature command with feature selector PORT_SUSPEND for the test port.
  6. The test issues a Get Port Status command on the test port, and then continues to send Get Port Status commands until suspend is indicated or one second has elapsed.
  7. Checks that the port state is as follows:

PORT_CONNECTION MUST BE SET

PORT_ENABLE IGNORE

PORT_SUSPEND MUST BE SET

PORT_OVER_CURRENT MUST BE ZERO

PORT_RESET MUST BE ZERO

PORT_POWER MUST BE SET

PORT_LOW_SPEED MUST NOT CHANGE

PORT_HIGH_SPEED MUST NOT CHANGE

PORT_TEST MUST BE ZERO

PORT_INDICATOR MUST BE ZERO

C_PORT_CONNECTION MUST BE ZERO

C_PORT_ENABLE MUST BE ZERO

C_PORT_SUSPEND MUST BE ZERO

C_PORT_OVER_CURRENT MUST BE ZERO

C_PORT_RESET MUST BE ZERO

  8. The test delays for one second to ensure the suspend operation has completed.
  9. The test issues a Clear Port Feature command with feature selector PORT_SUSPEND for the test port.
  10. The test checks the port status by running the Status Change Endpoint test.
  11. The test issues a Get Port Status command on the test port, and then continues to send Get Port Status commands until suspend is cleared or one second has passed.
  12. Checks that the port state is as follows:

PORT_CONNECTION MUST BE SET

PORT_ENABLE MUST BE SET

PORT_SUSPEND MUST BE ZERO

PORT_OVER_CURRENT MUST BE ZERO

PORT_RESET MUST BE ZERO

PORT_POWER MUST BE SET

PORT_LOW_SPEED MUST NOT CHANGE

PORT_HIGH_SPEED MUST NOT CHANGE

PORT_TEST MUST BE ZERO

PORT_INDICATOR MUST BE ZERO

C_PORT_CONNECTION MUST BE ZERO

C_PORT_ENABLE MUST BE ZERO

C_PORT_SUSPEND MUST BE SET

C_PORT_OVER_CURRENT MUST BE ZERO

C_PORT_RESET MUST BE ZERO

  13. The test calls Get Port Status on all non-test ports.
  14. The test verifies that there were no changes in the port status on any of the non-test ports.
  15. The test repeats steps 1 to 14 with each of the remaining ports.

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_chap11.log).

The test fails if:

  • Valid Get Port Status commands fail for any reason.
  • Valid Clear Port Feature commands fail for any reason.
  • A known good device fails to enumerate for any reason.
  • Any port status bits change on the non-test ports during the course of the test.
  • The port status for the test port does not change as described.


TD-9.26.2.12 Suspend Port Test

This test verifies that a hub correctly responds to a Suspend port command.

Starting Configuration

Test Port: Any Device Port Enabled

Other Ports: No Device Port Enabled

Overview

The test software performs the following steps.

The test performs the following steps.

  1. The test enumerates the USB bus.
  2. The test verifies that the ports are in the proper starting configuration using Get Port Status.
  3. The test clears all port change bits using the Clear Port Feature command.
  4. The test calls Get Port Status on each port and stores the initial port status values.
  5. The test issues a Set Port Feature command with feature selector PORT_SUSPEND for the test port.
  6. The test issues a Get Port Status command on the test port, and then continues to send Get Port Status commands until suspend is indicated or one second has elapsed.
  7. The test checks that the port state is as follows:

PORT_CONNECTION MUST BE SET

PORT_ENABLE IGNORE

PORT_SUSPEND MUST BE SET

PORT_OVER_CURRENT MUST BE ZERO

PORT_RESET MUST BE ZERO

PORT_POWER MUST BE SET

PORT_LOW_SPEED MUST NOT CHANGE

PORT_HIGH_SPEED MUST NOT CHANGE

PORT_TEST MUST BE ZERO

PORT_INDICATOR MUST BE ZERO

C_PORT_CONNECTION MUST BE ZERO

C_PORT_ENABLE MUST BE ZERO

C_PORT_SUSPEND MUST BE ZERO

C_PORT_OVER_CURRENT MUST BE ZERO

C_PORT_RESET MUST BE ZERO

  8. The test calls Get Port Status on all non-test ports.
  9. The test verifies that there were no changes in the port status on any of the non-test ports.
  10. The test repeats steps 1 to 9 with each of the remaining ports.

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_chap11.log).

The test fails if:

  • Valid Get Port Status commands fail for any reason.
  • Valid Clear Port Feature commands fail for any reason.
  • A known good device fails to enumerate for any reason.
  • Any port status bits change on the non-test ports during the course of the test.
  • The port status for the test port does not change as described.


TD-9.26.2.13 Suspend and Ignore Connect

This test disables remote wakeup for the hub and verifies that the hub correctly ignores connect events when it is suspended.

Starting Configuration

Test Port: No Device Port Enabled

Other Ports: No Device Port Enabled

Overview

The test performs the following steps.

  1. The test enumerates the USB bus.
  2. The test verifies that the ports are in the proper starting configuration using Get Port Status.
  3. The test clears all port change bits using the Clear Port Feature command.
  4. The test calls Get Port Status on each port and stores the initial port status values.
  5. The test issues the Clear Feature command with feature selector DEVICE_REMOTE_WAKEUP to disable remote wakeup for the test hub.
  6. The test suspends the parent port for the test hub.
  7. The test gets the port status of the parent port of the hub to verify that the suspended state has occurred. The test continues to send Get Port Status commands to the parent port until suspend is indicated or one second has elapsed.
  8. The test prompts you to connect a device to the test port.
  9. The test verifies the parent port of the hub is still suspended.
  10. The test issues a Clear Port Feature command with feature selector PORT_SUSPEND to the parent port of the hub.
  11. The test reads the status change endpoint of the test hub.
  12. The test verifies that the hub reports a status change only on the test port.
  13. The test issues a Get Port Status command for the test port.
  14. The test checks that the port state is as follows:

PORT_CONNECTION MUST BE SET

PORT_ENABLE MUST BE ZERO

PORT_SUSPEND MUST BE ZERO

PORT_OVER_CURRENT MUST BE ZERO

PORT_RESET MUST BE ZERO

PORT_POWER MUST BE SET

PORT_LOW_SPEED IGNORE

PORT_HIGH_SPEED IGNORE

PORT_TEST MUST BE ZERO

PORT_INDICATOR MUST BE ZERO

C_PORT_CONNECTION MUST BE SET

C_PORT_ENABLE MUST BE ZERO

C_PORT_SUSPEND MUST BE ZERO

C_PORT_OVER_CURRENT MUST BE ZERO

C_PORT_RESET MUST BE ZERO

15. The test calls Get Port Status on all non-test ports.

16. The test verifies that there were no changes in the port status on any of the non-test ports.

17. The test repeats steps 1 to 16 with each of the remaining ports. The test is also repeated with the non-test ports initially having a device connected (GROUP).

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_chap11.log).

The test fails if:

  • Valid Get Port Status commands fail for any reason.
  • Valid Clear Port Feature commands fail for any reason.
  • A known good device fails to enumerate for any reason.
  • Any port status bits change on the non-test ports during the course of the test.
  • The port status for the test port does not change as described.
  • A valid Clear Feature command is not accepted.


TD-9.26.2.14 Suspend and Ignore Disconnect

This test disables remote wakeup for the hub under test and verifies that the hub correctly ignores disconnect events when it is suspended.

Starting Configuration

Test Port: Any Device Port Enabled

Other Ports: No Device Port Enabled

Overview

The test performs the following steps.

  1. The test enumerates the USB bus.
  2. The test verifies that the ports are in the proper starting configuration using Get Port Status.
  3. The test clears all port change bits using the Clear Port Feature command.
  4. The test calls Get Port Status on each port and stores the initial port status values.
  5. The test issues the Clear Feature command with feature selector DEVICE_REMOTE_WAKEUP to disable remote wakeup for the test hub.
  6. The test suspends the parent port for the test hub.
  7. The test issues a Get Port Status command for the parent port to verify the suspended state occurred. The test continues to send Get Port Status commands to the parent port of the hub until suspend is indicated or one second has elapsed.
  8. The test prompts you to disconnect the device from the test port.
  9. The test checks the parent port of the hub to make sure it is still suspended.
  10. The test issues a Clear Port Feature with feature selector PORT_SUSPEND to the parent port of the hub.
  11. The test read the status change endpoint of the hub.
  12. The test verifies that the hub reports a status change only on the test port.
  13. The test issues a Get Port Status command for the test port.
  14. The test checks that the port state is as follows:

PORT_CONNECTION MUST BE ZERO

PORT_ENABLE MUST BE ZERO

PORT_SUSPEND MUST BE ZERO

PORT_OVER_CURRENT MUST BE ZERO

PORT_RESET MUST BE ZERO

PORT_POWER MUST BE SET

PORT_LOW_SPEED IGNORE

PORT_HIGH_SPEED IGNORE

PORT_TEST MUST BE ZERO

PORT_INDICATOR MUST BE ZERO

C_PORT_CONNECTION MUST BE SET

C_PORT_ENABLE MUST BE ZERO

C_PORT_SUSPEND MUST BE ZERO

C_PORT_OVER_CURRENT MUST BE ZERO

C_PORT_RESET MUST BE ZERO

15. The test calls Get Port Status on all non-test ports.

16. The test verifies that there were no changes in the port status on any of the non-test ports.

17. The test repeats steps 1 to 16 with each of the remaining ports. The test is also repeated with the non-test ports initially having a device connected (GROUP).

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_chap11.log).

The test fails if:

  • Valid Get Port Status commands fail for any reason.
  • Valid Clear Port Feature commands fail for any reason.
  • A known good device fails to enumerate for any reason.
  • Any port status bits change on the non-test ports during the course of the test.
  • The port status for the port under test does not change as described.
  • A valid Clear Feature command is not accepted.


TD-9.26.2.15 Suspend and Disconnect Device

This test suspends the hub under test and verifies that a remote wakeup occurs when a device is disconnected from the hub under test.

Starting Configuration

Test Port: Any Device Port Enabled

Other Ports: No Device Port Enabled

Overview

The test performs the following steps.

  1. The test enumerates the USB bus.
  2. The test verifies that the ports are in the proper starting configuration using Get Port Status.
  3. The test clears all port change bits using the Clear Port Feature command.
  4. The test calls Get Port Status on each port and stores the initial port status values.
  5. The test issues the Set Feature command with feature selector DEVICE_REMOTE_WAKEUP to enable remote wakeup for the test hub.
  6. The test suspends the parent port for the test hub.
  7. The test issues a Get Port Status command for the parent port to verify the suspended state occurred. The test continues to send Get Port Status commands to the parent port of the hub until suspend is indicated or one second has elapsed.
  8. The test prompts you to disconnect the device from the test port.
  9. The test polls the status of the parent port of the hub until it is no longer suspended.
  10. The test checks the port status by running the Status Change Endpoint test.
  11. The test issues a Get Port Status command for the test port.
  12. The test checks that the port state is as follows:

PORT_CONNECTION MUST BE ZERO

PORT_ENABLE MUST BE ZERO

PORT_SUSPEND MUST BE ZERO

PORT_OVER_CURRENT MUST BE ZERO

PORT_RESET MUST BE ZERO

PORT_POWER MUST BE SET

PORT_LOW_SPEED IGNORE

PORT_HIGH_SPEED IGNORE

PORT_TEST MUST BE ZERO

PORT_INDICATOR MUST BE ZERO

C_PORT_CONNECTION MUST BE SET

C_PORT_ENABLE MUST BE ZERO

C_PORT_SUSPEND MUST BE ZERO

C_PORT_OVER_CURRENT MUST BE ZERO

C_PORT_RESET MUST BE ZERO

  13. The test calls Get Port Status on all non-test ports.
  14. The test verifies that there were no changes in the port status on any of the non-test ports.
  15. The test repeats steps 1 to 14 with each port of the remaining ports. The test is also repeated with the non-test ports initially having a device connected (GROUP).

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_chap11.log).

The test fails if:

  • Valid Get Port Status commands fail for any reason.
  • Valid Clear Port Feature commands fail for any reason.
  • A known good device fails to enumerate for any reason.
  • Any port status bits change on the non-test ports during the course of the test.
  • The port status for the test port does not change as described.
  • A valid Clear Feature command is not accepted.


TD-9.26.2.16 Suspend and Connect Device

This test suspends the hub and verifies that a remote wakeup occurs when a device is connected to the hub.

Starting Configuration

Test Port: Any Device Port Enabled

Other Ports: No Device Port Enabled

Overview

The test performs the following steps.

  1. The test enumerates the USB bus.
  2. The test verifies that the ports are in the proper starting configuration using Get Port Status.
  3. The test clears all port change bits using the Clear Port Feature command.
  4. The test calls Get Port Status on each port and stores the initial port status values.
  5. The test issues the Set Feature command with feature selector DEVICE_REMOTE_WAKEUP to enable remote wakeup for the test hub.
  6. The test suspends the parent port for the test hub.
  7. The test issues a Get Port Status command for the parent port to verify the suspended state occurred. The test continues to send Get Port Status commands to the parent port of the hub until suspend is indicated or one second has elapsed.
  8. The test prompts you to connect the device to the test port.
  9. The test polls the status of the parent port of the hub until it is no longer suspended.
  10. The test checks the port status by running the Status Change Endpoint test.
  11. The test verifies that the hub reports a status change only on the test port.
  12. The test issues a Get Port Status command for the port.
  13. The test verifies that the port state is as follows:

PORT_CONNECTION MUST BE SET

PORT_ENABLE MUST BE ZERO

PORT_SUSPEND MUST BE ZEO

PORT_OVER_CURRENT MUST BE ZERO

PORT_RESET MUST BE ZERO

PORT_POWER MUST BE SET

PORT_LOW_SPEED IGNORE

PORT_HIGH_SPEED IGNORE

PORT_TEST MUST BE ZERO

PORT_INDICATOR MUST BE ZERO

C_PORT_CONNECTION MUST BE SET

C_PORT_ENABLE MUST BE ZERO

C_PORT_SUSPEND MUST BE ZERO

C_PORT_OVER_CURRENT MUST BE ZERO

C_PORT_RESET MUST BE ZERO

  14. The test calls Get Port Status on all non-test ports.
  15. The test verifies that there were no changes in the port status on any of the non-test ports.
  16. The test repeats steps 1 to 15 with each port of the remaining ports. The test is also repeated with the non-test ports initially having a device connected (GROUP).

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_chap11.log).

The test fails if:

  • Valid Get Port Status commands fail for any reason.
  • Valid Clear Port Feature commands fail for any reason.
  • A known good device fails to enumerate for any reason.
  • Any port status bits change on the non-test ports during the course of the test.
  • The port status for the test port does not change as described.
  • A valid Clear Feature command is not accepted.
  • A remote wakeup is not produced by the hub under test in response to a connect event.


TD-9.26.2.17 Suspend and Remote Wakeup

This test suspends the hub under test and verifies that a remote wakeup occurs when a remote wakeup is initiated from a downstream device connected to the hub.

Starting Configuration

Test Port: Remote Wakeup Capable Device Port Enabled

Other Ports: No Device Port Enabled

Overview

The test performs the following steps.

  1. The test enumerates the USB bus.
  2. The test verifies that the ports are in the proper starting configuration using Get Port Status.
  3. The test clears all port change bits using the Clear Port Feature command.
  4. The test calls Get Port Status on each port and stores the initial port status values.
  5. The test issues the Set Feature command with feature selector DEVICE_REMOTE_WAKEUP to enable remote wakeup for the test hub.
  6. The test suspends the parent port for the test hub.
  7. The test issues a Get Port Status command for the parent port to verify the suspended state occurred. The test continues to send Get Port Status commands to the parent port of the hub until suspend is indicated or one second has elapsed.
  8. The test prompts you to initiate a remote wakeup from the device on the port.
  9. The test polls the status of the parent port of the hub until it is no longer suspended.
  10. The test checks the port status by running the Status Change Endpoint test.
  11. The test issues a Get Port Status command for the port.
  12. The test verifies that the port state is as follows:

PORT_CONNECTION MUST BE SET

PORT_ENABLE MUST BE SET

PORT_SUSPEND MUST BE ZERO

PORT_OVER_CURRENT MUST BE ZERO

PORT_RESET MUST BE ZERO

PORT_POWER MUST BE SET

PORT_LOW_SPEED MUST NOT CHANGE

PORT_HIGH_SPEED MUST NOT CHANGE

PORT_TEST MUST BE ZERO

PORT_INDICATOR MUST BE ZERO

C_PORT_CONNECTION MUST BE ZERO

C_PORT_ENABLE MUST BE ZERO

C_PORT_SUSPEND MUST BE SET

C_PORT_OVER_CURRENT MUST BE ZERO

C_PORT_RESET MUST BE ZERO

  13. The test calls Get Port Status on all non-test ports.
  14. The test verifies that there were no changes in the port status on any of the non-test ports.
  15. The test repeats steps 1 to 14 with each port of the remaining ports. The test is also repeated with the non-test ports initially having a device connected (GROUP).

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_chap11.log).

The test fails if:

  • Valid Get Port Status commands fail for any reason.
  • Valid Clear Port Feature commands fail for any reason.
  • A known good device fails to enumerate for any reason.
  • Any port status bits change on the non-test ports during the course of the test.
  • The port status for the port under test does not change as described.
  • A valid Clear Feature command is not accepted.
  • A remote wakeup is not produced by the hub under test in response to a connect event.


TD-9.26.2.18 Hub Descriptor Test

This test verifies that the test device responds to valid Get Hub Descriptor command and returns a descriptor in compliance with the specification.

Device States For Test

This test is run with the device in the Configured state.

Overview

The test performs the following steps.

  1. The test issues a valid Get Configuration descriptor command with a requested length of 9 bytes.
  2. The test issues a valid Set Configuration command with the bConfiguration value from the configuration descriptor.
  3. The test issues a valid Get Hub Descriptor command with a requested length of 9 bytes.
  4. The test performs the following checks on the device descriptor value:

bLength == 9 (Note: if the bNbrPorts field is > 7 the length must be longer)

if bLength > 9 the Get Hub Descriptor is issued again with the indicated length.

bDescriptorType == HUB descriptor type

if wHubCharacteristics D2 == 1 then the Device Removable bitmask must have at least one bit set.

wHubCharacterstics D0 to D1 == (00 or 01)

wHubCharacteristics D3 to D4 == (00 or 01)

If wHubCharacteristics D3 to D4 != (00 or 01) issue a Get Status command to the hub. The status must indicate bus powered.

If bcdUSB.hibyte < 2 then wHubCharateristics D5 to D7 == 0

wHubCharacteristics D8 t o D15 == 0

Bit zero in the DeivceRemovableBitMask must be zero. The remaining bits are checked against the user-supplied information on non-accessible ports.

All bits in the PortPwrCtrlMask must be one.

The bHubContrCurrent must be <= 100 mA.

  5. If the hub supports multiple configurations, repeat the test for each possible configuration.
  6. If the hub is a high-speed capable device, the test must be run with the hub in both high-speed and full-speed operation.

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_chap11.log).

The test fails if:

  • Device enumeration fails following the method described in this specification.
  • Valid get descriptor commands fail for any reason.
  • Valid set address commands fail for any reason.
  • Valid set configuration commands fail for any reason.
  • Valid get configuration commands fail for any reason.
  • Any of the hub descriptor content checks fail.


TD-9.27 USB HIDView (CV)

Test Kit: HCT 11

This test validates that USB Human Input Devices (HID) comply with the functional and operational specifications for HID class USB devices. The test specifically validates the HID class-specific Report descriptor. To run this test, you must attach a physical device to the system.

Note This test is required for USB-capable HID class devices.

Overview

The primary use of a HID class device is to control the operation of the system. Examples of HID class devices include keyboards, pointing devices (mouse devices, trackballs, joysticks), control devices (steering wheels, throttles, rudder pedals, data gloves), and other devices that perform a similar function, such as bar code readers.

The USB HIDView (CV) test is based upon the USBCV compliance test tool provided by the USB-IF. For information about the USB HID class, see the Universal Serial Bus Device Class Definition for Human Interface Devices, Revision 1.11 available from the USB-IF at http://www.usb.org.

Click to show or hide information. HID class algorithm

The USB HIDView (CV) test uses the following algorithm to verify that the test device is a HID class device.

  1. The test sends a valid Get Descriptor request to the device.
  2. For each configuration that the device supports, the test sends a valid GetDescriptor(Configuration) request with a bLength of 9 bytes. The test then sends a valid Get Configuration request with a blength equal to the wTotalLength field of the configuration descriptor.
  3. For each configuration descriptor obtained in step 2, the test parses the descriptor finding all interface descriptors. If any of the interface descriptors has a bDeviceClass value of 0x03 (HID_CLASS), the device is a HID device. The device is then tested.

Click to show or hide information. Test cases

The USB HIDView (CV) test runs a series of tests that verify the test device complies with the specifications for HID class devices.

TD-9.27.3.1 HID Descriptor Test

TD-9.27.3.2 HID Get/Set Idle Test

TD-9.27.3.3 HID Get/Set Protocol Test

TD-9.27.3.4 HID Report Descriptor Test

TD-9.27.3.5 HID Specification Version Test

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • USB HID device.

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_hid.log).


TD-9.27.3.1 HID Descriptor Test

This test verifies that the device under test responds to valid Get HID Descriptor command and returns a descriptor in compliance with the HID specification. It also verifies that the HID descriptor(s) in the configuration descriptor and the descriptor(s) returned explicitly in response to the Get HID Descriptor command are identical.

Device States For Test

This test is run with the device in the Configured state.

Overview

The test performs the following steps.

  1. The test issues a valid Set Configuration command for the configuration (unless it is an other_speed_configuration descriptor).
  2. The test issues a valid Get Configuration command and verifies that the configuration has been set. (if we are not testing an other_speed_configuration descriptor)
  3. The test issues a valid Get Configuration Descriptor with a requested length of 9 bytes.
  4. The test issues a valid Get Configuration Descriptor with a requested length of the wTotalLength field from the descriptor obtained in step 3.
  5. For the configuration descriptor obtained in step 4, the test parses the descriptor to locate all interface descriptors.
  6. For each interface descriptor, the test checks to see if bInterfaceClass == 0x03 (HID_CLASS).
  7. The test perform each of the following checks on the HID class interfaces:

bInterfaceSubClass < 2 //Undefined SubClass

bInterfaceProtocol < 3 //Undefined

  8. For each HID interface found in step 6, the test locates the HID descriptor as follows:

Issue a valid Get Configuration Descriptor call requesting 9 bytes.

Issue a valid Get Configuration Descriptor call requesting the full length.

Look at each interface descriptor in order until the interface and alternate setting numbers match the interface found in step 6.

Check that bInterfaceClass == 0x03.

Search forward in the configuration descriptor from this interface descriptor until a HID class descriptor is found (If none are found the test fails).

  9. If the HID class descriptor found in step 8 is for an interface with alternate setting zero and the configuration descriptor being tested is not an other_speed_descriptor, a valid Get HID Descriptor is issued for the interface in question.
  10. The Hid Class descriptor(s) obtained in step 8 and step 9 are compared to ensure that they are identical (the test fails if they different).
  11. For each HID class descriptor obtained in step 9 (and 10), the test performs the following checks:

bLength > 8.

bLength must be a multiple of 3.

bLength == (9 + (bNumDescriptors –1)*3)

bDescriptorType == HID descriptor type (0x21)

bcdHID >= 0x100

Each Additional bDescriptorType field must not be in the reserved range from 0x24 to 0x2F.

  12. The test is repeated for each possible device configuration. For a high-speed capable device the test is run with the device operating at both full speed and high speed. The test is also performed on the other_speed_configuration descriptor as described above.

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_hid.log).

The test fails if

  • Device enumeration fails following the method described in this specification.
  • Valid get descriptor commands fail for any reason.
  • Valid set address commands fail for any reason.
  • Valid set configuration commands fail for any reason.
  • Valid get configuration commands fail for any reason.
  • Any of the HID descriptor content checks fail.
  • Valid get HID descriptor commands fail for any reason.


TD-9.27.3.2 HID Get/Set Idle Test

This test verifies that the device under test correctly supports the Get Idle command if it supports the Set Idle command.

Device States For Test

This test is run with the device in the Configured state.

Overview

The test performs the following steps.

  1. The test issues a valid Set Configuration command for the configuration (unless it is an other_speed_configuration descriptor).
  2. The test issues a valid Get Configuration command and verifies that the configuration has been set. (if we are not testing an other_speed_configuration descriptor)
  3. The test issues a valid Get Configuration Descriptor with a requested length of 9 bytes.
  4. The test issues a valid Get Configuration Descriptor with a requested length of the wTotalLength field from the descriptor obtained in step 3.
  5. For the configuration descriptor obtained in step 4, the test parses the descriptor to locate all interface descriptors.
  6. For each interface descriptor, the test checks to see if bInterfaceClass == 0x03 (HID_CLASS).
  7. For each interface found in Step 6 the following descriptor parsing is performed:

REPORT DESCRIPTOR PARSING

  8. The test issues a valid Get HID descriptor for the interface being tested.
  9. The test parses the HID descriptor to find the length of the report descriptor for this interface.
  10. The test issues a valid Get Report Descriptor request with a requested length from step 9.
  11. The test counts the number of item tags in the Report Descriptor. It must be at least 1.
  12. The test counts the number of input tags in the Report Descriptor.
  13. The test counts the number of report Ids in the Report Descriptor.
  14. If there are no report IDs the GET/SET Idle test is run with value 0x7F

If there are report IDs, the Get/Set Idle test is run with values 0x00, 0x7F, and 0xFF for each report ID for an INPUT.

GET/SET IDLE TEST

  15. The test issues a valid Set Idle request for the Report ID and duration being tested.
  16. The test issues a valid Get Idle request for the Report ID being tested.
  17. If both requests complete successfully, the test checks that Get Idle request returns the correct value that was set.
  18. The test is repeated for each possible device configuration. For high-speed capable device it is run with the device operating at both full speed and high speed.

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_hid.log).

The test fails if

  • Device enumeration fails following the method described in this specification.
  • Valid get descriptor commands fail for any reason.
  • Valid set address commands fail for any reason.
  • Valid set configuration commands fail for any reason.
  • Valid get configuration commands fail for any reason.
  • Valid get HID descriptor commands fail for any reason.
  • Valid get HID report descriptor commands fail for any reason.
  • Set IDLE values do not match those returned by Get IDLE.


TD-9.27.3.3 HID Get/Set Protocol Test

This test verifies that a boot class HID interface correctly supports the Get and Set Protocol HID Requests.

Device States For Test

This test is run with the device in the Configured state.

Overview

The test performs the following steps.

  1. The test issues a valid Set Configuration command for the configuration (unless it is an other_speed_configuration descriptor).
  2. The test issues a valid Get Configuration command and verifies that the configuration has been set. (if we are not testing an other_speed_configuration descriptor)
  3. The test issues a valid Get Configuration Descriptor with a requested length of 9 bytes.
  4. The test issues a valid Get Configuration Descriptor with a requested length of the wTotalLength field from the descriptor obtained in step 3.
  5. For the configuration descriptor obtained in step 4, the test parses the descriptor to locate all interface descriptors.
  6. For each interface descriptor, the test checks to see if bInterfaceClass == 0x03 (HID_CLASS).
  7. For each interface descriptor that is HID check the bInterfaceSubClass. If the bInterfaceSubClass == 0x01 and bAlternateSetting == 0 perform the following test:

GET/SET PROTOCOL:

  8. The test issues a valid Set Protocol request for the Report Protocol.
  9. The test issues a valid Get Protocol request.
  10. The test checks that the Get Protocol request returns Report Protocol.
  11. The test issues a valid Set Protocol Request for the Boot Protocol.
  12. The test issues a valid Get Protocol Request for the Boot Protocol.
  13. The test checks that the Get Protocol request returns Boot Protocol.
  14. The test is repeated for each possible device configuration. For a high-speed capable device, the test is run with the device operating at both full speed and high speed.

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_hid.log).

The test fails if

  • Device enumeration fails following the method described in this specification.
  • Valid get descriptor commands fail for any reason.
  • Valid set address commands fail for any reason.
  • Valid set configuration commands fail for any reason.
  • Valid get configuration commands fail for any reason.
  • Valid get HID descriptor commands fail for any reason.
  • Valid get HID report descriptor commands fail for any reason.
  • Set Protocol values do not match those returned by Get Protocol.
  • Valid Get or Set Protocol commands to a boot interface fail for any reason.


TD-9.27.3.4 HID Report Descriptor Test

This test verifies that the device under test provides a Report Descriptor that meets the HID specification for each of its HID interfaces.

Device States For Test

This test is run with the device in the Configured state.

Overview

The test performs the following steps.

  1. The test issues a valid Set Configuration command for the configuration (unless it is an other_speed_configuration descriptor).
  2. The test issues a valid Get Configuration command and verifies that the configuration has been set. (if we are not testing an other_speed_configuration descriptor)
  3. The test issues a valid Get Configuration Descriptor with a requested length of 9 bytes.
  4. The test issues a valid Get Configuration Descriptor with a requested length of the wTotalLength field from the descriptor obtained in step 3.
  5. For the configuration descriptor obtained in step 4, the test parses the descriptor to locate all interface descriptors.
  6. For each interface descriptor, the test checks to see if bInterfaceClass == 0x03 (HID_CLASS).
  7. For each interface found in Step 6, the following descriptor parsing is performed:

REPORT DESCRIPTOR PARSING

  8. The test issues a valid Get HID descriptor for the interface being tested.
  9. The test parses the HID descriptor to find the length of the report descriptor for this interface.
  10. The test issues a valid Get Report Descriptor request with a requested length from step 9.
  11. The test counts the number of item tags in the Report Descriptor. It must be at least 1.
  12. The test parses the report descriptor according to section 6.2.2 of the HID specification.
  13. The test is repeated for each possible device configuration. For a high-speed capable device the test is run with the device operating at both full speed and high speed.

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_hid.log).

The test fails if

  • Device enumeration fails following the method described in this specification.
  • Valid get descriptor commands fail for any reason.
  • Valid set address commands fail for any reason.
  • Valid set configuration commands fail for any reason.
  • Valid get configuration commands fail for any reason.
  • Valid get HID descriptor commands fail for any reason.
  • Valid get HID report descriptor commands fail for any reason.
  • A report descriptor does not comply with section 6.2.2 of the HID specification.


TD-9.27.3.5 HID Specification Version Test

This test checks to see with which version of the HID specification the device is in compliance.

Device States For Test

This test is run with the device in the Configured state.

Overview

The test performs the following steps.

  1. The test issues a valid Set Configuration command for the configuration (unless it is an other_speed_configuration descriptor).
  2. The test issues a valid Get Configuration command and verifies that the configuration has been set. (if we are not testing an other_speed_configuration descriptor)
  3. The test issues a valid Get Configuration Descriptor with a requested length of 9 bytes.
  4. The test issues a valid Get Configuration Descriptor with a requested length of the wTotalLength field from the descriptor obtained in step 3.
  5. For the configuration descriptor obtained in step 4, the test parses the descriptor to locate all interface descriptors.
  6. For each interface descriptor, the test checks to see if bInterfaceClass == 0x03 (HID_CLASS).
  7. For each interface found in Step 6, the following descriptor parsing is performed:

HID SPEC VERSION PARSING

  8. Starting at the HID descriptor found in step 6 parse forward in the configuration descriptor to locate each of the following items:

a. First HID descriptor after the HID interface.

b. Second HID descriptor after the HID interface

c. First EndPoint Descriptor after HID interface.

d. First interface descriptor (any kind) after the HID interface.

  9. If the location of A is greater than the location of D, the test fails.
  10. If the location of B is less than the location of D, the test fails.
  11. If the location of C is greater than the location of D, the test fails.
  12. If the location of A is less than C, the interface is HID spec 4 compliant. Otherwise, it is HID spec 3 compliant.
  13. The test is repeated for each possible device configuration. For a high-speed capable device the test is run with the device operating at both full speed and high speed.

Results Interpretation

The test writes the pass/fail results to a log file (Usbcv_hid.log).

The test fails if

  • Device enumeration fails following the method described in this specification.
  • Valid get descriptor commands fail for any reason.
  • Valid set address commands fail for any reason.
  • Valid set configuration commands fail for any reason.
  • Valid get configuration commands fail for any reason.
  • A HID interface does not have at least one endpoint.
  • Two HID descriptors describe a single HID interface.
  • A HID interface does not have a following HID descriptor before the next interface.


TD-9.28 USB High Speed Hub Basic Test

Test Kit: HCT 11

The USB High Speed Hub Basic Test is required only for Universal Serial Bus (USB) revision 2.0 high-speed hubs. The test verifies the proper response of a USB 2.0 hub to transactions with high-speed, full-speed, and low-speed peripheral devices.

The USB High Speed Hub Basic test verifies that the hub correctly enumerates the attached devices, implements the port indicators, and correctly reports the device, configuration, device qualifier, other speed configuration, interface, and endpoint descriptors. The test also verifies that hubs with multiple transaction translators pass the tests for both high-speed and full-speed operation.

Overview

A hub is a USB device that connects to a host system and provides additional USB attachment points. The USB hub contains three principal components: the hub repeater, the hub controller, and the transaction translator. This test focuses on the transaction translator and verifies compliance with the Universal Serial Bus Specification Revision 2.0 requirements and the Microsoft Windows Logo Program System and Device Requirements. A USB 2.0 hub provides support for high-speed, full-speed and low-speed USB peripherals.

The USB High Speed Basic test comprises a number of individual tests based upon the USB 2.0 Transaction Translator and Hub Compliance Test Specification developed by the USB-IF. These tests are described in the following sections.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • USB device.

Results Interpretation

The test generates a detailed log file of test results and displays on-screen pass or fail status. The name of the log file is BasicHubsTests.log.


TD-9.28.1.1 Device Enumeration in Full Speed Environment Test

This test verifies that low, full- and high-speed capable devices enumerate correctly on each downstream port of the test hub when the hub is connected to a host controller that is not high-speed capable.

Overview

The test hub connects to a Universal Host Controller Interface (UHCI) or an Open Host Controller Interface (OHCI) host controller (full-speed only capable port).

Initially, no downstream device should be connected to the test hub unless it is a non-removable part of a compound device.

The test software prompts you to connect and then disconnect a low-speed test device, a full-speed test device, and a high-speed test device to each of the available ports on the hub.

For each device, this test verifies that the device has been successfully enumerated by sending a GetDescriptor request to get the configuration descriptor for the device.

When each device is connected, the test executes a GetPortStatus request and examines bit 9 and 10 of the port status bits. These bits must accurately indicate whether a low-speed or high-speed device is connected to the port. In a full speed environment, this means that bit 9 should be set if a low-speed device is connected, and bit 10 should never be set.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • Microsoft USB 2.0 enabled driver stack.
  • OHCI or UHCI full/low speed only capable root port.
  • Full Speed Test Device
  • Low Speed Test Device
  • High Speed Capable Test Device

Results Interpretation

The test writes all results to a file (BasicHubsTests.log).

The test fails if:

  • Any of the test devices fail to enumerate properly and/or doesn’t respond successfully to a get descriptor request on any of the hub ports.
  • Bits 9 or 10 of the Port Status bits do not correctly indicate the presence or absence of the low-speed or high-speed test devices.


TD-9.28.1.2 Device Enumeration in High Speed Environment Test

This test verifies that low, full and high-speed capable devices enumerate correctly on each downstream port of the hub under test when it is connected to a high-speed capable host controller.

Overview

The test hub connects to an Enhanced Host Controller Interface (EHCI) host controller (high-speed capable port).

Initially, no downstream device should be connected to the hub unless it is a non-removable part of a compound device.

The test prompts you to connect and then disconnect a low-speed test device, a full-speed test device, and a high-speed test device to each of the available ports on the hub.

For each device, the test software verifies that the device has been successfully enumerated by performing a get descriptor command to get the configuration descriptor for the test device.

When each device is connected the test software executes a GetPortStatus request and examines bit 9 and 10 of the port status bits. They must accurately indicate whether a low-speed or high-speed device is connected to the port.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • Full-speed compliance device
  • Low-speed compliance device
  • High-speed capable compliance device

Results Interpretation

The test writes all results to a file (BasicHubsTests.log).

The test fails if:

  • Any of the test devices fail to enumerate properly and/or does not respond successfully to a get descriptor request on any of the hub ports.
  • The high-speed test device enumerates as full speed device on any of the hub ports.
  • Bits 9 or 10 of the Port Status bits do not correctly indicate the presence or absence of the low-speed or high-speed test devices.


TD-9.28.1.3 Port Indicator Manual Mode Test

This test verifies that if the high-speed capable hub implements port indicators, the hub does so in compliance with the Universal Serial Bus Specification, Revision 2.0. This test verifies that the port indicators presence is correctly reported in the hub descriptor and that the indicators can be controlled through the manual control mode specified in the USB specification.

Overview

The test hub connects to an Enhanced Host Controller Interface (EHCI) host controller (high-speed capable port).

Initially, no downstream device should be connected to the hub unless it is a non-removable part of a compound device.

The test issues a get descriptor request for the hub descriptor and then checks bit D7 of the wHubCharacteristics field. If the value is zero and the hub does not have indicators present, the hub passes and the test is finished. If the value of the bit is one, the test proceeds to exercise the manual mode of the port indicators.

For each port the test software executes a GetPortStatus request and verifies that Bit 12 is zero indicating it is under automatic control. This is the required default behavior.

Next, the test repeats the following series of steps to test the indicator for each port:

  1. The test issues a SetPortFeature request with the PORT_INDICATOR feature selector and a selector value of one (amber).
  2. The test prompts you to verify that the port indicator displays amber.
  3. The test issues a GetPortStatus request for the port.
  4. Verifies that the port status now indicates manual port indicator control.
  5. Repeat steps 1-4 for green and off manual settings.
  6. Returns the port indicator to automatic mode using the SetPortFeature request.
  7. Verifies the Port Status indicates automatic mode.
  8. Repeats step 1 for off and green manual modes.
  9. Repeats steps 6-7 using ClearPortFeature instead of the SetPortFeature request to restore the port indicator to automatic mode.

Note When the hub is suspended, all port indicators should be off.

  10. Repeats steps 1-8 performing a Suspend/Resume in step 6. Verifies that all port indicators are off in the suspended state. Verifies that the tested port indicator returns to its previous mode when the hub resumes from the suspended state.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.

Results Interpretation

The test writes all results to a file (BasicHubsTests.log).

The test fails if:

  • The hub fails to indicate accurately whether it has port indicators in its hub descriptor.
  • The hub port indicators do not default to automatic control.
  • The port status incorrectly indicates whether its indicator is under manual or automatic control at any point.
  • The port indicator for any port does not correctly respond to a SetPortFeature request for a manual indicator mode.
  • The port indicator for any port does not correctly respond to a ClearPortFeature or SetPortFeature request to place the port indicators back into automatic mode.
  • Port indicators are not off while the hub is suspended.
  • Port indicators do not maintain the operating mode/state through a hub suspend/resume cycle.


TD-9.28.1.4 Port Indicator Automatic Mode Test

This test verifies that if the high-speed capable hub implements port indicators, the hub does so in compliance with the Universal Serial Bus Specification, Revision 2.0. This test verifies that the presence of the port indicators is correctly reported in the hub descriptor and that the hub supports automatic port indicator setting as described in the USB 2.0 specification.

Overview

The test hub connects to an Enhanced Host Controller Interface (EHCI) host controller (high-speed capable port).

Initially, no downstream device should be connected to the hub unless it is a non-removable part of a compound device.

The test issues a get descriptor request for the hub descriptor and then checks bit D7 of the wHubCharacteristics field. If the value is zero and the hub does not have indicators present, the hub passes and the test is finished. If the value of the bit is one, the test proceeds to exercise the manual mode of the port indicators.

For each port the test software executes a GetPortStatus request and verifies that Bit 12 is zero indicating it is under automatic control. This is the required default behavior.

Next, the test repeats the following series of steps to test the indicator for each port:

  1. The test suspends and resumes the hub.
  2. The test prompts you to verify that all port indicators remain off during the suspended state.
  3. The test issues a GetPortStatus request for the port.
  4. The test verifies the port status still indicates automatic port indicator control.
  5. Connect a device to each port.
  6. The test generates traffic through standard USB requests (GetDescriptor)
  7. The test prompts you to verify that the port indicator remains green after the device is connected.
  8. The test creates an over-current condition on the port.
  9. The test prompts you to verify that the port indicator shows amber.
  10. The test is repeated with hub operating at full speed.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • Hub

Results Interpretation

The test writes all results to a file (BasicHubsTests.log).

The test fails if:

  • The hub fails to indicate accurately whether it has port indicators in its hub descriptor.
  • The hub port indicators do not default to automatic control.
  • The port status incorrectly indicates whether its indicator is under manual or automatic control at any point.
  • The port indicator does not stay off during suspend.
  • The port indicator does not signal green during enabled/transmit/transmitR states.
  • The port indicator does not signal amber during an over-current condition.


TD-9.28.1.5 Number of Transaction Translators Test

This test obtains the device, device qualifier, and configuration descriptors for the hub when the hub is connected to a full-speed electrical environment and a high-speed electrical environment. The device protocol values are examined in both sets of descriptors to verify that the hub’s self-reported transaction translator implementation is consistent. You must verify the reported implementation is actually the one used by the hub.

Overview

Hubs can either implement one transaction translator that handles all downstream ports or implement one transaction translator per downstream port. The default mode of operation for both types of hubs is to have a single transaction translator handle all downstream full- and low-speed traffic. Hubs that support multiple transactions translators must be explicitly told to use more than one translator by having their default interface changed through a SetInterface request. Hubs that implement multiple transaction translators must pass all transaction translator tests for both modes of operation.

Initially, no downstream device should be connected to the hub unless it is a non-removable part of a compound device.

The hub must be connected to a full-speed operating environment. The test issues a GetDescriptor request to obtain the device_qualifier descriptor. The test examines the bDeviceProtocol field in the descriptor. The field must be either one (1), indicating the hub has only one transaction translator (TT), or two (2), indicating the hub has one TT per port.

Next, the hub must be connected to a high-speed capable port. The test issues a GetDescriptor request to get the device descriptor. The test examines the bDeviceProtocol field to see if it reports one (Single TT) or 2 (One TT per port).

The test examines the hub’s interface descriptors. If the hub implements a single TT, it must have a single interface with a bInterfaceProtocol value of zero.

If the hub implements multiple TTs (one per port), the test carries out the following sequence:

  1. The test makes a SetInterface request to set the alternate interface setting.
  2. The test issues GetInterface request to verify the current setting is accurately reported.
  3. The test issues SetInterface request to return to the default interface.
  4. The test issues a GetInterface request to verify the current setting is accurately reported.
  5. Check the bInterfaceProtocol value in the interface descriptors to make sure they are set correctly for a multiple TT implementation.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • USB-IF certified high-speed hub.
  • USB-IF certified full-speed hub.

Results Interpretation

The test writes all results to a file (BasicHubsTests.log).

The test fails if:

  • The hub does not indicate the same TT implementation when connected to full-speed and high-speed electrical environments.
  • The hub indicates the wrong TT implementation through its descriptors.
  • The hub implements multiple TTs but does not correctly support GetInterface or SetInterface requests when the hub has a high-speed connection on the upstream port.
  • The hub incorrectly sets the protocol value in any of its descriptors for its TT implementation.


TD-9.28.1.6 Full Speed Descriptor Test

This test verifies that the hub implements its device, configuration, device qualifier, other speed configuration, interface, and endpoint descriptors as specified in the Universal Serial Bus Specification, Revision 2.0. The parameters are fixed except for variations due to the transaction translator implementation the hub uses. This information is obtained from TD-9.28.1.5 Number of Transaction Translators Test.

Overview

The hub connects to a full-speed operating environment. Initially, no downstream device must be connected to the hub unless it is a non-removable part of a compound device.

The test issues GetDescriptor requests for the hub’s device, configuration, interface, endpoint, device qualifier, and other speed configuration descriptors. Every parameter in each of the descriptors is examined and must be in accordance with the USB Specification, Revision 2.0 and all current errata. Note that there have been published errata affecting the hub descriptor information. At this time, the latest was dated 12/07/2000.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • USB-IF certified high-speed hub.
  • USB-IF certified full-speed hub.

Results Interpretation

The test writes all results to a file (BasicHubsTests.log).

The test fails if:

  • Any of the descriptors cannot be read from the hub.
  • Any of the parameters in any of the descriptors differ from the descriptors for USB 2.0 hubs in the USB 2.0 Specification


TD-9.28.1.7 High Speed Descriptor Test

This test verifies that the hub implements its device, configuration, device qualifier, other speed configuration, interface, and endpoint descriptors as specified in the Universal Serial Bus Specification, Revision 2.0. The parameters are fixed except for variations due to the transaction translator implementation the hub uses. This information is obtained from TD-9.28.1.5 Number of Transaction Translators Test.

Overview

The hub connects to an Enhanced Host Controller Interface (EHCI) host controller (high-speed capable port). Initially, no downstream device must be connected to the hub unless it is a non-removable part of a compound device.

The test issues GetDescriptor requests for the hub’s device, configuration, interface, endpoint, device qualifier, and other speed configuration descriptors. Every parameter in each of the descriptors is examined and must be in accordance with the USB Specification, Revision 2.0 and all current errata. Note that there are published errata affecting the hub descriptor information. At this time, the latest was dated 12/07/2000.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.

Results Interpretation

The test writes all results to a file (BasicHubsTests.log).

The test fails if:

  • Any of the descriptors cannot be read from the hub.
  • Any of the parameters in any of the descriptors differ from the descriptors for USB 2.0 hubs in the USB 2.0 Specification


TD-9.28.1.10 Get TT State Test

This test verifies that the hub responds correctly to the Get_TT_State request.

Overview

The test hub connects to an Enhanced Host Controller Interface (EHCI) host controller (high-speed capable port).

Initially, no downstream device should be connected to the hub unless it is a non-removable part of a compound device.

The test issues the Stop_TT request followed by the Get_TT_State request for each of the hub’s TT units. The TT State response is examined for each TT to ensure that all reserved bits are set to zero. Finally, a Reset_TT request is issued for each TT to return the hub to normal operation.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.

Results Interpretation

The test writes all results to a file (BasicHubsTests.log).

The test fails if:

  • The hub does not respond to the Get_TT_State request when the TT is stopped.
  • The hub responds and bits 0-15 of the TT_Return_Flags response are not all zero.


TD-9.28.1.15 High Speed Device Connection During Suspend Test

This test verifies that the hub continues to accurately report the presence of a high-speed device while it is in the suspended state when the device reverts to full-speed terminations.

Overview

The hub connects to an Enhanced Host Controller Interface (EHCI) host controller (high-speed capable port).

A high-speed device must be connected to the first available downstream port of the hub.

The test issues a GetPortStatus request for each available downstream port of the hub. The test checks to see that only the port with the connected high-speed test device has bit 10 in the port status register set, indicating the presence of a high-speed device.

Next, the port with the device attached is suspended by sending a SetPortFeature command, with feature selector PORT_SUSPEND, to the port with the high-speed device attached. The test again issues the GetPortStatus command for the suspended port and verifies that the high-speed device is still reported. The port suspend is cleared by issuing the ClearPortFeature command with the PORT_SUSPEND feature selector. The test again issues the GetPortStatus command and verifies the high-speed device is still reported.

The process is repeated with a low-speed and full-speed device to check bit 9 of the port status register and all possible state combinations.

This process is repeated for each available downstream port on the hub.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.

Results Interpretation

The test writes all results to a file (BasicHubsTests.log).

The test fails if:

  • The hub does not correctly indicate the presence of a high-speed device through its port status register before, during, or after the port to which the device is attached is suspended and resumed.
  • The hub does not correctly indicate the presence of a full-speed device through its port status register before, during, or after the port to which the device is attached is suspended and resumed.
  • The hub does not correctly indicate the presence of a low-speed device through its port status register, before, during, or after the port to which the device is attached is suspended and resumed.


TD-9.29 USB High Speed Hub Basic Transfer Test

Test Kit: HCT 11

The USB High Speed Hub Basic Transfer Test is required only for Universal Serial Bus (USB) revision 2.0 high-speed hubs. The test verifies that the hub responds correctly to various transaction translator requests, and that the hub correctly handles a variety of transactions with high-speed, full-speed, and low-speed peripheral devices.

Overview

A hub is a USB device that connects to a host system and provides additional USB attachment points. The USB hub contains three principal components: the hub repeater, the hub controller, and the transaction translator. This test focuses on the transaction translator and verifies compliance with the Universal Serial Bus Specification Revision 2.0 requirements and the Microsoft Windows Logo Program System and Device Requirements. A USB 2.0 hub provides support for high-speed, full-speed and low-speed USB peripherals.

The USB High Speed Basic Transfer test comprises a number of individual tests based upon the USB 2.0 Transaction Translator and Hub Compliance Test Specification developed by the USB-IF. These tests are described in the following sections.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • EHCI high-speed capable devices.
  • Full-speed compliance devices.
  • Low-speed compliance devices.

Results Interpretation

The test generates a detailed log file of test results and displays on-screen pass or fail status. The name of the log file is BasicTransferTests.log.


TD-9.29.1.11 Clear TT Buffer Test

This test verifies that the hub responds correctly to the Clear_TT_Buffer request to clear the state of a non-periodic buffer associated with a given endpoint.

Overview

The hub connects to an EHCI host controller (high-speed capable port).

A full-speed compliance device is connected to an available downstream port of the test hub. The test configures the full-speed test device to have as many Bulk OUT endpoints as the test device will support.

The test issues a Bulk OUT transaction and sends an arbitrary packet to the test device for each of the endpoints in sequence. Software manipulation through a custom EHCI driver stack is used to prevent complete splits from being issued for any of these transactions. This is done by having a separate queue head for each transaction with a final dummy queue head that loops back on itself. While the non-periodic list spins on the dummy queue head the other transaction states can be monitored. Once all of the non-periodic buffers for the transaction translator are full, the OUT transactions will not be able to advance to the complete split stage.

At this point, the test sends a Clear_TT_Buffer request to one of the endpoints that has a pending transaction. After this request is issued the test sends another OUT transaction to this endpoint. The transaction must be completed successfully.

The same test process is repeated using control endpoints instead of bulk endpoints.

If the hub implements multiple transaction translators, the test device must be moved and the test repeated for each of the hubs available downstream ports.

The test is repeated for IN transactions.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • Full-speed compliance device.

Results Interpretation

The test writes all results to a file (BasicTransferTests.log).

The test fails if the Clear_TT_Buffer request does not enable a transaction to be sent to the cleared endpoint when all the non-periodic buffers are in the pending state.


TD-9.29.1.12 Stop TT Test

This test verifies that the hub responds correctly to the Stop_TT request.

Overview

For this test, you connect the hub an EHCI host controller (high-speed capable port) and connect a full-speed test device to one of the available downstream ports of the hub.

The test issues a Stop TT request to the hub. The test then attempts to run loopback tests of each transfer type to verify that the TT is stopped. Next, the test software issues a Reset TT request. The test then verifies that the loopback tests will run successfully.

The test is repeated for each downstream port on the hub if the hub implements one TT per port.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • Full-speed compliance device.

Results Interpretation

The test writes all results to a file (BasicTransferTests.log).

The test fails if:

  • A transaction translator continues to generate downstream non-periodic traffic after receiving a Stop_TT request.
  • A transaction translator continues to generate downstream periodic traffic after receiving a Stop_TT request.
  • Communication to the downstream device fails after a Reset_TT request.


TD-9.29.1.13 Reset TT Test

This test verifies that the hub responds correctly to the Reset TT request.

Overview

For this test, you connect the hub an EHCI host controller (high-speed capable port) and connect a full-speed test device to one of the available downstream ports of the hub.

The test configures the test device to support either as many bulk loopback endpoint pairs as the device is capable of supporting, or as many non-periodic buffers as the transaction translator supports (whichever is smaller). The maximum packet size for each endpoint is configured to be 64 bytes. Each endpoint is configured to count the number of transactions that are sent to it.

The test issues a series of Bulk OUT transactions for each of the OUT endpoints in the loopback pairs. Through software manipulation, the test prevents the host controller from issuing complete-splits for any of these transactions. The test then issues a valid Reset TT request. The complete splits for each of the Bulk OUT transactions are then allowed to complete. Each of these transactions must result in a STALL.

Next, the test repeats the same process for IN transactions to each of the IN endpoints in the loopback pairs.

In addition, this entire test is repeated on each port if the hub uses a multiple TT implementation.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high speed capable root port.
  • Full speed compliance device.

Results Interpretation

The test writes all results to a file (BasicTransferTests.log).

The test fails if:

  • A transaction translator continues to generate downstream non-periodic traffic after receiving a Reset_TT request.
  • A transaction translator continues to generate downstream periodic traffic after receiving a Reset_TT request.
  • The Reset_TT command does not clear all TT data/transaction buffers.
  • Communication to the downstream test device fails to work after the Reset_TT command is used.


TD-9.29.1.14 TT Think Time Test

This test verifies that the hub correctly reports its worst-case think time to advance to the next transaction in the periodic pipeline.

Overview

For this test, you connect the hub an EHCI host controller (high-speed capable port) and connect a full-speed test device to one of the available downstream ports of the hub.

This test configures the test device to support the maximum number of isochronous OUT endpoints the test device will support.

The test sends the GetDescriptor request to the hub to obtain the hub descriptor. The test examines bits D6…D5 of the wHubCharacteristics field to verify the reported worst case TT Think Time of the hub. This is interpreted as follows:

00: TT requires at most 8 FS bit times of inter-transaction gap.

01: TT requires at most 16 FS bit times of inter-transaction gap.

10: TT requires at most 24 FS bit times of inter-transaction gap.

11: TT requires at most 32 FS bit times of inter-transaction gap.

The test device is configured to measure the time between transactions to any of its isochronous OUT endpoints.

The test sets up a periodic schedule to send the hub isochronous transactions. The device tracks the time between each transaction as they execute.

The test queries the device to determine the largest delay in FS bit times between the end of one isochronous OUT transaction and the start of the next.

The procedure is repeated for isochronous IN, interrupt IN, and interrupt OUT transactions (limited to the number of non-periodic buffers in the TT) and for combinations of periodic and non-periodic transactions and full- and low-speed transactions.

If the hub implements more than one transaction translator per port, this test is repeated for each of the available downstream ports on the hub.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • Full-speed compliance device.
  • Low-speed compliance device.

Results Interpretation

The test writes all results to a file (BasicTransferTests.log).

The test fails if:

  • The hub does not respond to the GetDescriptor request for the hub descriptor.
  • There is a longer delay between transactions to the full-speed test device than the hub reports as its worst case TT think time.


TD-9.29.1.16 Multiple Hub Tier Split Traffic Test

This test verifies that the hub correctly repeats all high-speed traffic received at its upstream port to all of its high speed enabled downstream ports. In particular, the hub must repeat all high-speed split traffic to ensure that it reaches the appropriate hub with the full/low speed target device attached.

Overview

For this test, you connect the hub to an EHCI host controller (high-speed capable port). Four additional hubs are then connected in series behind the first hub. You connect a full-speed test device to the last hub in the chain.

The test configures the full speed test device to support a loopback pair of bulk endpoints and a loopback pair of interrupt endpoints. A loopback pair of endpoints is an IN endpoint and an OUT endpoint. Data that is written to the OUT endpoint may be immediately read back from the IN endpoint. The maximum packet size for both the bulk and interrupt endpoints is set to 64 bytes.

Next, the test continuously issues a series of bulk OUT and bulk IN and interrupt OUT and interrupt IN transactions to the endpoints. The transfer sizes and data patterns are varied. In every case, the data read back from the device is compared with the data sent.

The process is repeated with a low-speed test device for each TT in the hub. The process is also repeated with a high-speed test device and high-speed loopback traffic.

The process is also repeated for isochronous and control loopback.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • Five hubs.
  • EHCI high-speed capable root port.
  • High-, full-, and low-speed compliance devices.

Results Interpretation

The test writes all results to a file (BasicTransferTests.log).

The test fails if:

  • A test device cannot be configured behind a chain of five hubs.
  • Any full-, low-, or high-speed transactions are unsuccessful behind a chain of five hubs.


TD-9.29.1.17 Number of Non-Periodic Buffers Test

This test verifies that the transaction translator implements at least two non-periodic transaction buffers.

Overview

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.

The test configures the full-speed test device to support as many bulk OUT/IN loopback endpoint pairs as the test device supports. The maximum packet size for the endpoints is set to 64 bytes.

Next, the test sets up a series of bulk OUT transactions to each of the endpoints. Using software manipulation through a custom EHCI test stack, the test allows the transactions to issue start splits but not to issue complete splits. This is done by using a separate queue head for each transaction and a dummy queue head and the end of the list, which loops back on itself. This keeps the non-periodic buffers in the pending state. Once a transaction is not able to advance to the do-complete-split stage, the non-periodic transaction buffers of the TT have been filled and the number of non-periodic buffers can be calculated. The transactions are then allowed to complete normally. Bulk IN transactions are performed for each of the bulk OUT loopback pairs that were completed. The data sent must match the data received.

This procedure is repeated for each downstream port on the hub if the hub uses a multiple TT implementation. The procedure is also repeated using bulk IN transactions instead of bulk OUT transactions.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.

Results Interpretation

The test writes all results to a file (BasicTransferTests.log).

The test fails if:

  • A transaction translator does not have at least two non-periodic buffers.
  • A transaction translator does not correctly NAK non-periodic start splits when its non-periodic buffers are filled with pending transactions. A NAK is a handshake packet that indicates a negative acknowledgement.
  • Data read back from a bulk IN loopback endpoint does not match the data sent to the bulk OUT endpoint.


TD-9.29.1.18 Control Transaction Retry Handling Test

This test verifies that the transaction translator correctly handles a start split for a control transaction when it has a non-periodic buffer in the pending state with a transaction to the same endpoint. This condition can easily result when the host loses the ACK for a start split. An ACK is a handshake packet that indicates a positive acknowledgement.

Overview

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.

The test configures the full-speed test device to support a control endpoint with a maximum packet size of 64 bytes. The device is first queried to obtain the current transaction count for the endpoint.

Next, the test sets up a pair of control OUT transactions to the same endpoint. Using software manipulation through a custom EHCI test stack, the test allows the transactions to issue start splits but not to issue complete splits. This keeps the non-periodic buffer used for the first transaction in the pending state. The transaction translator should treat the second transaction as a retry of the first and respond with an ACK but not buffer the transaction. The transactions are then allowed to complete normally.

The test again queries the device for the transaction count on the control endpoint. If more than one new transaction (or zero) has been attempted on the endpoint, the test fails.

If the test device does not support transaction counting the test may be performed by issuing two small control OUT transactions with different data patterns to the endpoint. If the data read back from the endpoint through a control IN contains both pieces of data, the test fails.

The test is repeated using control IN transfers. If the hub supports a multiple TT organization, the test is repeated on each port.

The retry testing is carried out for each stage of the control transaction.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • Full Speed Compliance Device

Results Interpretation

The test writes all results to a file (BasicTransferTests.log).

The test fails if a transaction translator does not correctly treat control transfers as retries when it already has a transfer pending for the same endpoint.


TD-9.29.1.19 Bulk Transaction Retry Handling Test

This test verifies that the transaction translator correctly handles a start split for a bulk transaction when it has a non-periodic buffer in the pending or ready/x state with a transaction to the same endpoint and direction. This condition can easily result when the host loses the ACK for a start split.

Overview

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.

The test configures the full-speed test device to support a pair of bulk endpoints that support loopback transfers. The maximum packet size for each endpoint is set to 64 bytes. The test first queries the device to obtain the current transaction count for the Bulk OUT endpoint.

Next, the test sets up a pair of bulk OUT transactions to the endpoint. Using software manipulation through a custom EHCI test stack, the test allows the transactions to issue start splits but not complete splits. This keeps the non-periodic buffer used for the first transaction in the pending or ready/x state. The transaction translator should treat the second transaction as a retry of the first and respond with an ACK but not buffer the transaction. The transactions are then allowed to complete normally.

The test again queries the device for the transaction count on the bulk OUT endpoint. If more than one new transaction (or zero) has been attempted on the endpoint, the test fails.

If the test device does not support transaction counting, the test may be performed by issuing two small bulk OUT transactions with different data patterns to the endpoint. If the data read back from the endpoint through a bulk IN transaction contains both pieces of data, the test fails.

The test is repeated using bulk IN transfers. If the hub supports a multiple TT organization, the test is repeated on each port.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • Full Speed Compliance Device

Results Interpretation

The test writes all results to a file (BasicTransferTests.log).

The test fails if a transaction translator does not correctly treat bulk transfers as retries when it already has a transfer pending for the same endpoint.


TD-9.29.1.20 Control Transaction Protocol Test

This test verifies that the transaction translator correctly handles various device protocol response cases for control transactions.

Overview

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.

The test configures the full-speed test device to support four additional control endpoints. The maximum packet size for the endpoints is set to 64 bytes.

The test software configures one of the endpoints to respond with a STALL, one of the endpoints to respond with a NAK, and one of the endpoints to timeout (not respond). If the test device supports it, the remaining control endpoint is also configured to generate CRC errors.

Next, the test sends a series of control transactions to each of the endpoints. The result of the transaction must resolve to STALL for the STALL, timeout, and CRC error endpoints. The test aborts the transaction to the NAK endpoint after 1 second. The test software reads the transaction count from the NAK endpoint before and after this transaction attempt. If the count has not increased in a manner that indicates repeated transaction attempts, the test fails.

The test is repeated for transactions in both directions and all valid transfer sizes.

If the hub implements multiple TT units, the test must be repeated on each port of the hub.

The entire test procedure is repeated using a low-speed compliance device for all valid transfer sizes.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • Full-speed compliance device.
  • Low-speed compliance device.

Results Interpretation

The test writes all results to a file (BasicTransferTests.log).

  • The test fails if:
  • A transaction does not correctly report a STALL for an endpoint programmed to STALL, timeout, or produce CRC errors.
  • A transaction for an endpoint programmed to respond with a NAK responds with a state other than NAK.
  • A transaction is not repeatedly retried for an endpoint programmed to NAK due to an error in hub behavior.


TD-9.29.1.21 Bulk Transaction Protocol Test

This test verifies that the transaction translator correctly handles various protocol response cases for bulk transactions.

Overview

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.

The test configures the full-speed test device to support four bulk OUT endpoints. The maximum packet size for the endpoints is set to 64 bytes.

The test configures one of the endpoints to respond with STALL, one of the endpoints to respond with NAK, and one of the endpoints to timeout (not respond). If the test device supports it, the remaining endpoint is configured to generate CRC errors.

Next, the test sets up a series of bulk transactions to each of the endpoints. The result of the transaction must resolve to STALL for the STALL, timeout, and CRC error endpoints. The test aborts the transaction to the NAK endpoint after 1 second. The test reads the transaction count from the NAK endpoint before and after this transaction attempt. If the count has not increased in a manner that indicates repeated transaction attempts, the test fails.

The test is repeated for all valid transfer sizes.

If the hub implements multiple TT units, the test must be repeated on each port of the hub.

The four endpoints are reconfigured as bulk IN endpoints and the same procedure is repeated.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • Full-speed compliance device.
  • Low-speed compliance device.

Results Interpretation

The test writes all results to a file (BasicTransferTests.log).

The test fails if:

  • A transaction does not correctly report a STALL for an endpoint programmed to STALL, timeout, or produce CRC errors.
  • A transaction attempt for an endpoint programmed to NAK responds with a state other than NAK.
  • A transaction is not repeatedly retried for an endpoint programmed to NAK due to an error in hub behavior.


TD-9.29.1.22 Control Transaction Loopback Test

This test performs functional testing of control transfers by exercising concurrent streams of OUT and IN transfer pairs to control endpoints. The test sets up the compliance device to support as many control endpoints as possible. Transaction streams are initiated for each endpoint that sends data through control OUT transactions and then reads it back with control IN transactions. Transfer streams are run for all possible transfer sizes and all possible data patterns.

Overview

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.

The test configures the full-speed test device to support as many control endpoints as the test device will support. The maximum packet size for the endpoints is set to 64 bytes.

Next, the test sets up a transfer stream for each control endpoint. Each stream repeatedly executes control OUT and control IN transfers. The test compares the data received (IN) with the data sent (OUT) to make sure they are identical.

The test is repeated for all valid transfer sizes for every possible data pattern.

The same procedure is repeated with a low speed compliance device. This procedure is repeated for each downstream port on the hub if it uses a multiple TT implementation.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • Full-speed compliance device.
  • Low-speed compliance device.

Results Interpretation

The test writes all results to a file (BasicTransferTests.log).

The test fails if:

  • The data returned by any control IN transfer is not identical to the data that was sent with a control OUT transfer.
  • A control transfer cannot be successfully completed to the test device.


TD-9.29.1.23 Bulk Transaction Loopback Test

This test performs functional testing of bulk transfers by exercising concurrent streams of OUT and IN transfer pairs to bulk endpoints. The test sets up the compliance device to support as many bulk endpoints as possible. Transaction streams are initiated for each endpoint that sends data through bulk OUT transactions and then reads it back with bulk IN transactions. Transfer streams are run for all possible transfer sizes and all possible data patterns.

Overview

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.

The test configures the full-speed test device to support as many bulk endpoint pairs as the test device will support. The maximum packet size for the endpoints is set to 64 bytes.

Next, the test sets up a transfer stream for each bulk endpoint pair. Each stream repeatedly executes bulk OUT and bulk IN transfers. The test compares the data received (IN) with the data sent (OUT) to make sure they are identical.

The test is repeated for all valid transfer sizes for every possible data pattern.

This procedure is repeated for each downstream port on the hub if the hub uses a multiple TT implementation.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • Full-speed compliance device.
  • Low-speed compliance device.

Results Interpretation

The test writes all results to a file (BasicTransferTests.log).

The test fails if:

  • The data returned by any bulk IN transfer is not identical to the data that was sent with a bulk OUT transfer.
  • A bulk transfer cannot be successfully completed to the test device.


TD-9.29.1.24 Control Transaction Unpaired Complete Split Test

This test verifies that the transaction translator correctly handles the case where a complete split for a control transaction is received for an endpoint that does not currently have a non-periodic buffer assigned to it.

Overview

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub. The test device is configured to have only a default control endpoint.

Next, the test sets up a control OUT transaction to the control endpoint of the test device. Using software manipulation through a custom EHCI test stack, the test allows the transaction to issue a start split but not a complete split. The test software then issues a Clear_TT_Buffer request for the control endpoint of the test device. Once this request is completed, the transaction that has been in the ready/x state without issuing a complete split is allowed to complete. This transaction should result in a STALL on the control OUT endpoint for the test device.

The test is repeated for a control IN transfer.

If the hub implements multiple TT units, the test must run on each port of the hub.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • Full-speed compliance device.

Results Interpretation

The test writes all results to a file (BasicTransferTests.log).

The test fails if a transaction translator does not return a STALL when it receives a control transaction for an endpoint and a direction that is not currently assigned to one of the non-periodic buffers.


TD-9.29.1.25 Bulk Transaction Unpaired Complete Split Test

This test verifies that the transaction translator correctly handles the case where a complete split for a bulk transaction is received for an endpoint and direction that does not currently have a non-periodic buffer assigned to it.

Overview

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub. The test device is configured to have a pair of loopback bulk endpoints.

The test sets up a bulk OUT transaction to the bulk OUT endpoint of the test device. Using software manipulation through a custom EHCI test stack, the test allows the transaction to issue a start split but not allowed to issue a complete split. The test then issues a Clear_TT_Buffer request for the bulk OUT endpoint of the test device. Once this request is complete, the transaction that was in the ready/x state without issuing a complete split is allowed to complete. This transaction should result in a STALL.

The test is repeated for a bulk IN transfer.

If the hub implements multiple TT units the test must be repeated on each port of the hub.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • Full-speed compliance device.

Results Interpretation

The test writes all results to a file (BasicTransferTests.log).

The test fails if a transaction translator does not return a STALL when it receives a bulk transaction for an endpoint and a direction that is not currently assigned to one of the non-periodic buffers.


TD-9.29.1.26 Number of Local Retries Test

This test verifies that the transaction translator performs local retries of non-periodic transactions if the transactions produce timeouts or CRC errors on the full/low speed bus. The test verifies the transactions are tried exactly three times.

Overview

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub. The test configures the full-speed test device to support two bulk OUT endpoints. The maximum packet size for the endpoints is set to 64 bytes. One endpoint is configured to timeout and the other to respond with CRC errors (if the device supports this mode). Both endpoints are configured to track and return a transaction count on command. The test obtains the current transaction count for both endpoints.

Next, the test sets up two bulk OUT transactions to each of the endpoints. The transactions must produce a STALL response for the test to pass. Once the transactions are complete, the test reads the transaction count for both of the bulk endpoints. If either transaction count has not increased by three, the test fails.

This procedure is repeated for each downstream port on the hub if the hub uses a multiple TT implementation.

The procedure is repeated for endpoints that NAK and STALL. In this case, there must only be one local attempt per transfers.

The same tests are repeated for control endpoints.

The test is repeated for an isochronous endpoint for timeout mode only.

The test is repeated for interrupt endpoints. These cases are the same as bulk/control endpoints except for the timeout case, which must produce an ERR response. There must only be one local attempt per transfer for the periodic endpoints.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • Full-speed compliance device.

Results Interpretation

The test writes all results to a file (BasicTransferTests.log).

The test fails if:

  • A transaction translator does not attempt local retries of a non-periodic transaction that resulted in a timeout or CRC error.
  • A transaction translator attempts a non-periodic transaction less than or more than three times when it consistently results in a timeout or CRC error.
  • The correct transfer status is not returned for any transfer.
  • The correct number of local transfers is not attempted for transfer to a fixed response endpoint.


TD-9.29.1.27 Start Split Pipeline Size Test

This test verifies that the transaction translator can successfully accept as many as 16 start-splits in a single microframe.

Overview

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.

The test configures the full speed test device to support 16 isochronous OUT endpoints (or as many as the test device supports). The maximum packet size for the endpoints is set to 1024 bytes. Each endpoint is configured to keep a transaction count. The test sets up a series of small isochronous OUT transactions to each of the endpoints. The test uses a custom EHCI test stack to allow complete control of transaction scheduling.

All the transactions are scheduled for execution in the same microframe and then periodic transactions are enabled for the host controller. After a sufficient delay, the periodic list is disabled to prevent the host controller from attempting any of the transactions that were not able to execute in the specified microframe. The transaction descriptors are examined to see how many of the transactions were executed (the host sends a start-split transaction).

Next, the test queries the device to obtain the transaction count for each of the endpoints on the test device. If any endpoint has received more than one transaction or the total number of transactions received by the endpoints does not match the number of start-splits sent by the host controller, the test fails.

This procedure is repeated with the start-split transactions sent in each possible microframe (all except microframe 6).

If supported by the test device, the procedure is also repeated with one-byte isochronous OUT transfers. Each endpoint is sent a different byte. The device is required to assemble the bytes in the order that they were received. At the end of the test, the data is read back from the bytes. If all the bytes are not present and in the order they were sent, the test fails.

This procedure is repeated for each downstream port on the hub if the hub uses a multiple TT implementation.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • Full-speed compliance device.

Results Interpretation

The test writes all results to a file (BasicTransferTests.log).

The test fails if:

  • A transaction translator does not issue full/low-speed periodic transactions in the order start-splits were received.
  • A transaction translator does not handle receiving up to 16 start-splits in a single microframe.


TD-9.29.1.28 Interrupt Transaction Protocol Test

This test verifies that the transaction translator correctly handles various device protocol response cases for interrupt transactions.

Overview

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.

The test configures the full-speed test device to support four interrupt OUT endpoints. The maximum packet size for the endpoints is set to 64 bytes. The endpoints are also configured to keep a transaction count. The current count for each endpoint is read.

The test software configures one of the endpoints to respond with STALL, one of the endpoints to respond with NAK, and one of the endpoints to timeout (not respond). If the test device supports CRC checks, the remaining interrupt endpoint is configured to generate CRC errors.

Next, the test sets up a series of interrupt OUT transactions to each of the endpoints. The test uses a custom EHCI test stack to allow complete control of the periodic schedule. In turn, the test sets up and runs periodic schedules that attempt 100 transactions to the current endpoint being tested. After the transaction attempts are made, the transaction count for each endpoint is read and must have increased by 100.

The result of the each transaction must resolve to STALL for the STALL endpoint. The transaction attempt to the NAK endpoint should eventually time out. The CRC and timeout endpoints should result in ERR responses.

The test is repeated for transactions in both directions and for all valid transfer sizes. If the hub implements multiple TT units, the test must be repeated on each port of the hub.

The entire test procedure is repeated using a low-speed compliance device for all valid transfer sizes.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • Full-speed compliance device.
  • Low-speed compliance device.

Results Interpretation

The test writes all results to a file (BasicTransferTests.log).

The test fails if:

  • A transaction translator attempts local retries of an interrupt transaction.
  • A transaction attempt completes for an endpoint programmed to NAK.
  • A transaction attempt to an endpoint programmed to respond with CRC errors or to timeout does not result in an ERR response.


TD-9.29.1.29 Isochronous Transaction Protocol Test

This test verifies that the transaction translator correctly handles various device protocol response cases for isochronous IN transactions.

Overview

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.

The test configures the full-speed test device to support two isochronous IN endpoints. The maximum packet size for the endpoints is set to 1024 bytes. The endpoints are also configured to keep a transaction count. The current count for each endpoint is read.

The test configures one of the endpoints to not respond (timeout). If the test device supports it the remaining isochronous endpoint is configured to generate CRC errors.

Next, the test sets up a series of isochronous IN transactions to each of the endpoints. The test uses a custom EHCI test stack to allow complete control of the periodic schedule. In turn, the test sets up and runs periodic schedules that attempt 100 transactions to the current endpoint being tested. After the transaction attempts are made, the transaction count for each endpoint is read and must have increased by 100. Each transaction should result in an ERR response.

The test is repeated for transactions in both directions and for all valid transfer sizes.

If the hub implements multiple TT units, the test must be repeated on each port of the hub.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • Full-speed compliance device.

Results Interpretation

The test writes all results to a file (BasicTransferTests.log).

The test fails if:

  • A transaction translator attempts local retries of an isochronous transaction.
  • A transaction attempt to an endpoint programmed to respond with CRC errors or to timeout does not result in an ERR response.


TD-9.29.1.30 Interrupt Transaction Loopback Test

This test performs functional testing of interrupt transfers by exercising concurrent streams of OUT and IN transfer pairs to pairs of interrupt endpoints. The test sets up the compliance device to support as many pairs of interrupt loopback endpoints as possible. Transaction streams are initiated for each endpoint that send data through interrupt OUT transactions and then read it back with interrupt IN transactions. Transfer streams are run for a variety of transfer sizes and with all possible data patterns for those sizes.

Overview

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.

The test configures the full-speed test device to support as many interrupt loopback pairs of endpoints as the test device will support. The maximum packet size for the endpoints is set to 64 bytes. The bInterval value for each endpoint is set to the minimum allowable time.

Next, the test sets up a transfer stream for each pair of interrupt endpoints. Each stream repeatedly executes interrupt OUT and interrupt IN transactions. The test compares the data received from the IN transaction with the data sent with the OUT transaction to make sure the data is identical.

The test is repeated for all possible transfer sizes for every possible data pattern.

The data read by an interrupt IN transaction should always match the data sent by an interrupt OUT transaction.

The same procedure is repeated with a low speed compliance device.

This procedure is repeated for each downstream port on the hub if the hub uses a multiple TT implementation.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • Full-speed compliance device.
  • Low-speed compliance device.

Results Interpretation

The test writes all results to a file (BasicTransferTests.log).

The test fails if:

  • The data returned by any interrupt IN transfer is not identical to the data that was sent with an interrupt OUT transfer.
  • An interrupt transfer cannot be successfully completed to the test device.


TD-9.29.1.31 Isochronous Transaction Loopback Test

This test performs functional testing of isochronous transfers by exercising concurrent streams of OUT and IN transfer pairs to isochronous loopback endpoint pairs. The test sets up the compliance device to support as many pairs of isochronous loopback endpoints as possible. Transaction streams are initiated for each endpoint pair that sends data through isochronous OUT transactions and then reads it back with isochronous IN transactions. Transfer streams are run for a variety of transfer sizes and with all possible data patterns for those sizes.

Overview

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.

The test configures the full-speed test device to support as many isochronous loopback pairs of endpoints as the test device supports. The maximum packet size for the endpoints is set to 1024 bytes (or the maximum supported by the test device). The bInterval value for each endpoint is set to the minimum allowable time.

Next, the test sets up a transfer stream for each pair of isochronous endpoints. Each stream repeatedly executes isochronous OUT and isochronous IN transactions. The test compares the data received from the IN transaction to the data sent with each OUT transaction to make sure the data is identical.

The test is repeated for all valid transfer sizes for every possible data pattern.

The data read by an isochronous IN transaction should always match the data sent by an isochronous OUT transaction.

This procedure is repeated for each downstream port on the hub if the hub uses a multiple TT implementation.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • Full-speed compliance device.

Results Interpretation

The test writes all results to a file (BasicTransferTests.log).

The test fails if:

  • The data returned by any isochronous IN transfer is not identical to the data that was sent with an isochronous OUT transfer.
  • An isochronous transfer cannot be successfully completed to the test device.


TD-9.30 USB High-Speed Hub Advanced Transfer Test

Test Kit: HCT 11

The USB High Speed Hub Advanced Transfer Test is required only for Universal Serial Bus (USB) revision 2.0 high-speed hubs. The test verifies that the hub correctly handles a variety of transactions types, including interrupt and isochronous IN transactions that occur at microframe boundaries, periodic transactions, and out-of-order complete-split and start-split transactions.

Overview

A hub is a USB device that connects to a host system and provides additional USB attachment points. The USB hub contains three principal components: the hub repeater, the hub controller, and the transaction translator. This test focuses on the transaction translator and verifies compliance with the Universal Serial Bus Specification Revision 2.0 requirements and the Microsoft Windows Logo Program System and Device Requirements. A USB 2.0 hub provides support for high-speed, full-speed and low-speed USB peripherals.

The USB High Speed Advance Transfer test comprises a number of individual tests based upon the USB 2.0 Transaction Translator and Hub Compliance Test Specification developed by the USB-IF. These tests are described in the following sections.

Click to show or hide information. A note about Schmoo pipes

Interrupt IN and Isochronous IN transactions that run behind a transaction translator have special handling rules when the transactions are still in progress at a microframe boundary. The tests, TD-9.30.1.32 and TD-9.30.1.33, use a dummy transaction to shift the location of IN transactions throughout a microframe and across microframe boundaries. This dummy transaction is an isochronous OUT to a non-existent endpoint that is slowly increased one bit at a time by varying the size and number of bitstuffs produced by the data pattern. This dummy transaction pipe will be referred to as a schmoo pipe following the nomenclature used in the Enhanced Host Controller Interface Specification for Universal Serial Bus Host Controller document available at http://developer.intel.com/technology/usb/ehcispec.htm.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • EHCI high-speed capable devices.
  • Full-speed compliance devices.
  • Low-speed compliance devices.

Results Interpretation

The test generates a detailed log file of test results and displays on-screen pass or fail status. The name of the log file is AdvTransferTest.log.


TD-9.30.1.32 Interrupt IN Microframe Boundary Test

The Interrupt IN Microframe Boundary test checks to ensure that the transaction translator correctly handles the case where interrupt IN transactions are still in progress at a microframe boundary. This is accomplished using a schmoo pipe to generate transactions that precede the interrupt IN transaction in the microframe.

For information on schmoo pipes, see TD-9.30 USB High Speed Hub Advanced Transfer Test.

Overview

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.

The test configures the full-speed test device to support an isochronous OUT endpoint and a loopback pair of interrupt endpoints. The maximum packet size for the interrupt endpoints is set to 64 bytes. The maximum packet size of the isochronous OUT endpoint is set to 1024 bytes.

Using a custom EHCI test stack, the test sets up a schedule to execute a series of three transactions within a microframe. The transaction order is:

  1. Interrupt OUT
  2. Schmoo OUT
  3. Interrupt IN

For each fixed Interrupt transaction size and data pattern the schmoo OUT is varied from 1 to 188 – N bytes, one bit at a time, where N is the current size of the Interrupt transaction. In each case, the data read from the interrupt IN transaction is compared to ensure it is the same as the data written with the interrupt OUT transaction. The transaction descriptor for each completing Interrupt IN transaction is examined to see if it required one or two complete splits to finish. When the transaction first requires two complete splits, the end of the microframe boundary has just been crossed.

The test is repeated for all valid sized interrupt transfers for every possible data pattern.

The procedure is repeated for all possible microframes (that is, when start-splits arrive in microframe 1, 2, 3, etc.).

This procedure is repeated for each downstream port on the hub if the hub uses a multiple TT implementation.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • Full-speed compliance device.

Results Interpretation

The test writes all results to a file (AdvTransferTest.log).

The test fails if the data returned by any interrupt IN transfer is not identical to the data that was sent with an interrupt OUT transfer.


TD-9.30.1.33 Isochronous IN Microframe Boundary Test

This test explicitly checks to ensure that the transaction translator correctly handles the case where isochronous IN transactions are still in progress at a microframe boundary. This is accomplished using a schmoo pipe to generate transactions that precede the isochronous IN transaction in the microframe. This is also implicitly tested to some extent in the TD-9.29.1.31 Isochronous Transaction Loopback Test with large data sizes. Therefore, this test examines only small transfers.

For information on schmoo pipes, see TD-9.30 USB High Speed Hub Advanced Transfer Test.

Overview

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.

The test configures the full speed test device to support an isochronous OUT endpoint and a loopback pair of isochronous endpoints. The maximum packet size for the isochronous loopback endpoints is set to 128 bytes. The maximum packet size of the isochronous OUT endpoint is set to 1024 bytes.

The test uses a custom EHCI test stack to set up a schedule to execute a series of three transactions within a microframe. The transaction order is:

  1. Isochronous OUT (loopback endpoint)
  2. Schmoo OUT
  3. Isochronous IN (loopback endpoint)

For each fixed isochronous transaction size and data pattern, the schmoo OUT is varied from 1 to 188 – N bytes, one bit at a time, where N is the current size of the isochronous loopback transaction. In each case the data read from the isochronous IN loopback transaction is compared to ensure it is the same as the data written with the isochronous loopback OUT transaction. The transaction descriptor for each completing isochronous IN transaction is examined to see if it required one or two complete splits to finish. When the transaction first requires two complete splits, the end of the microframe boundary has just been crossed.

The test is repeated for all valid sized isochronous transfers for every possible data pattern.

This procedure is repeated for each downstream port on the hub if the hub uses a multiple TT implementation.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • Full-speed compliance device.

Results Interpretation

The test writes all results to a file (AdvTransferTest.log).

The test fails if the data returned by any isochronous IN transfer is not identical to the data that was sent with an isochronous OUT transfer.


TD-9.30.1.34 Periodic Abort Rules Test

This test verifies that the transaction translator will abort periodic transactions that are still in progress at the end of a classic frame. It also verifies that interrupt transactions that are still in progress at the beginning of the fourth microframeafter the start-split for the transaction arrivedwill be aborted.

Overview

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub.

The test configures the full-speed test device to support an isochronous IN data source endpoint. The maximum packet size for the endpoint is set to 1024 bytes. The isochronous IN source is programmed to respond with 490 bytes of transaction length including bitstuffs, interpacket delay, etc.

The test device is also configured to support an additional pair of isochronous loopback endpoints and a pair of interrupt loopback endpoints with maximum packet sizes of 1024 and 64 respectively.

The test sets up start-splits for an isochronous IN transaction (490) bytes and an interrupt OUT transaction with the start splits sent in the same microframe. Later, an interrupt IN transaction is performed to read back the data sent with the interrupt OUT. The data must match. The order is:

  1. Isochronous IN
  2. Interrupt OUT
  3. Delay
  4. Interrupt IN

This process is repeated with the size of the data returned by the isochronous IN source being increased by one bit each iteration (using bitstuffs). At around a size of 500 bytes, the interrupt IN should no longer return data because the interrupt OUT transaction will be running at the beginning of microframe X+4 after the start-split arrival and must be aborted.

The process is repeated using the isochronous loopback endpoints to make sure that the isochronous transactions are NOT aborted.

This process is repeated is with the start splits for the initial isochronous IN and interrupt OUT transactions being sent in microframes Y0-Y4.

The process is repeated will all valid transfer sizes for the transfer being pushed across the abort boundary.

To explicitly exercise the End of Frame abort rule instead of the X+4 abort rule, another run of the test is repeated. In this case, start-splits are sent in microframe Y5. The starting size for the isochronous IN data source is only 300 in this case. It is tested using interrupt and loopback endpoints pairs. The hub must shut down the port when the EOF abort occurs.

This procedure is repeated for each downstream port on the hub if the hub uses a multiple TT implementation.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • Full-speed compliance device.

Results Interpretation

The test writes all results to a file (AdvTransferTest.log).

The test fails if:

  • The data read from an isochronous or interrupt loopback endpoint does not match the data written.
  • An interrupt transaction that is in progress at the beginning of the fourth microframe after the start split arrival is not aborted.
  • An isochronous transaction that is in progress at the end of the frame is not aborted.
  • The hub does not shut down (disable) the port in an EOF abort case.


TD-9.30.1.35 Periodic Free Rules Test

This test verifies that the transaction translator will free start-splits for periodic transactions that have not been started at the end of a classic frame. It also verifies that periodic transactions that are not in progress at the beginning of the fourth microframeafter the start-split for the transaction arrivedwill be freed from the start split pipeline.

Overview

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub. The test configures the full speed test device to support an isochronous IN data source endpoint. The maximum packet size for the endpoint is set to 1024 bytes. The isochronous IN source is programmed to respond with 564 bytes of transaction length including bitstuffs, interpacket delay, etc. The test device is also configured to support an additional pair of isochronous loopback endpoints and a pair of interrupt loopback endpoints with maximum packet sizes of 1024 and 64 respectively.

The test sets up start splits for an isochronous IN transaction (564) bytes and an interrupt OUT transaction with the start splits sent in the same microframe. Later an interrupt IN transaction is performed to read back the data sent with the interrupt OUT. The interrupt IN must not return any data. The transaction order is:

  1. Isochronous OUT
  2. Interrupt OUT
  3. Delay
  4. Interrupt IN

This process is repeated for 100 iterations with the size of the data returned by the isochronous IN source being increased by one bit each iteration. The interrupt IN should never run because of the X+4 microframe free rule. This process is repeated with the start-splits for the initial isochronous IN and interrupt OUT transactions being sent in microframes Y0-Y4.The process is repeated using the isochronous loopback endpoints.

To explicitly exercise the End-of-Frame free rule, instead of the X+4 free rule, the test is repeated. In this case, start-splits are sent in microframe Y5. The starting size for the isochronous IN data source is only 376 in this case. It is tested using interrupt and loopback endpoints pairs. In this case, both types of IN should not return data as the interrupt OUT and isochronous OUT to loopback endpoints should be freed.

The process is repeated for all valid transfer sizes for the transfer that should be freed.

This procedure is repeated for each downstream port on the hub if it uses a multiple TT implementation.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • Full-speed compliance device.

Results Interpretation

The test writes all results to a file (AdvTransferTest.log).

The test fails if:

  • Any data is read from an isochronous or interrupt loopback endpoint in a free case.
  • An isochronous or interrupt start-split is not freed from the pipeline at the beginning of the fourth microframe after its arrival.


TD-9.30.1.36 Complete Split Pipeline Free Test

This test verifies that complete-split information for periodic transactions is freed from the complete-split pipeline if they are still present at the beginning of the second microframe after the associated transactions completed on the full/low speed bus.

Overview

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub. The test configures the full-speed test device to support a pair of isochronous and a pair of interrupt loopback endpoints. The maximum packet size for the isochronous endpoint loopback pair is set to 128 bytes. The maximum packet size of the interrupt endpoint loopback pair is set to 64 bytes. Each endpoint is configured to keep a transaction count.

The test sets up a series of interrupt OUT and IN transaction pairs. The test uses a custom EHCI test stack to allow complete control over the transaction scheduling. The interrupt OUT is scheduled under normal scheduling rules. The interrupt IN is scheduled such that a complete-split is not scheduled for the first microframe it would normally be scheduled in.

This transaction series is set up and run. The complete-splits for the interrupt IN should never complete (NYET). The host should resolve the transaction to an error (the TT will not receive a complete-split in the microframe where the data is really available, causing the TT to free the complete-split at the beginning of the next microframe).

This procedure is repeated for all valid transfer sizes.

The procedure is also repeated for isochronous transactions for all valid transfer sizes.

This procedure is repeated for each downstream port on the hub if it uses a multiple TT implementation.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • Full-speed compliance device.

Results Interpretation

The test writes all results to a file (AdvTransferTest.log).

The test fails if an interrupt or isochronous loopback IN still completes despite the first complete split not being issued.


TD-9.30.1.37 Out Of Order Complete Split Test

This test verifies that a TT correctly searches the pipeline for an out of order complete-split and advances the pipeline to the matching entry in the case a match is found. The test also ensures that the TT does not lose information in the complete-split pipelines when it must search for a non-existent entry.

Overview

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub. The test configures the full-speed test device to support as many pairs of interrupt endpoints as possible. A custom EHCI test stack is used to allow complete control over the transaction scheduling.

Transfers are sent to each of the endpoints with the start-splits and complete-splits scheduled in the same microframes. For one endpoint (the bad index/transfer), the start-split is scheduled one microframe earlier. This means that its complete split will not be matched. All transfers except the "bad" transfer must complete successfully. The bad transfer must fail.

Next, the process is repeated with interrupt IN transfers. All must complete successfully except the "bad" transfer. The data received must match the data sent with each of the OUT transfers.

This transaction series is set up and run as a one shot run. The periodic list is disabled. The complete transaction sequence is set up. The list is enabled and then immediately disabled once the transactions are run. This procedure is repeated for all valid transaction sizes and a variety of different data patterns. For each test iteration, the data pattern is different for each loopback pair of endpoints.

This procedure is repeated for each downstream port on the hub if the hub uses a multiple TT implementation.

The test is also repeated using isochronous transfers. The "bad" isochronous OUT transfer is created by using the wrong begin/middle/all label on the OUT.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • Full-speed compliance device.

Results Interpretation

The test writes all results to a file (AdvTransferTest.log).

The test fails if:

  • Out of order complete-splits are not completed by the TT.
  • Other transactions that should not be affected by an out of order complete-split are affected.
  • Any IN transactions do not product the data written to the OUT endpoint in the loopback pair for a good endpoint.


TD-9.30.1.38 Out Of Order Start Split Test

This test verifies that isochronous OUT transactions requiring multiple start-splits are correctly aborted in cases where start-splits are received out of order, or not received at all by the transaction translator.

Overview

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub. The test configures the full speed test device to support a pair of isochronous loopback endpoints and a pair of interrupt loopback endpoints. The maximum packet size for the isochronous endpoint loopback pair is set to 1024 bytes.

The test sets up a series of isochronous OUT and isochronous IN transaction pairs. A custom EHCI test stack is used to allow complete control over the transaction scheduling. The isochronous OUT is scheduled in the following fashion:

SS – Begin, SS – Middle1, SS – Middle 2, . . ., SS – Middle 3 (Correct)

SS – Middle 1, SS – Middle 2, …. (No SS Begin)

SS – Begin, Empty Microframe, SS – Middle 1, … (Empty Microframe1)

SS – Begin, Empty Microframe, SS – End (Empty Microframe2)

SS – Begin, SS – Middle1, SS-Middle 2/INT OUT, … (INT OUT In Middle)

SS – End (END Only)

SS- Begin, SS – Middle1, . .. (NO SS – END) (Missing END)

The isochronous IN and a pair of interrupt OUT/IN transactions are always scheduled later in the correct fashion (except for the INT OUT in Middle case above).

This transaction series is set up and run. The ISO data pattern should only be read back correctly in the case labeled (Correct) above. The interrupt data pattern should always be read back correctly.

This procedure is repeated for a variety of transfer sizes. A variety of data patterns are used.

This procedure is repeated for each downstream port on the hub if the hub uses a multiple TT implementation.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • Full-speed compliance device.

Results Interpretation

The test writes all results to a file (AdvTransferTest.log).

The test fails if:

  • A long Isochronous OUT that skips a microframe or is intermingled with another transaction is not aborted.
  • An aborted Isochronous OUT affects an unrelated Interrupt transaction.
  • The data read back from the interrupt loopback endpoint is not the same as the data written.


TD-9.30.1.39 Non-Periodic Bandwidth Reclamation Test

This test verifies that the transaction translator will execute a non-periodic transaction when the periodic pipeline becomes empty. This execution must take place if a non-periodic transaction is available and can be run before the current (if any) periodic transactions can be executed.

Overview

For this test, you connect the hub to an EHCI host controller (high-speed capable port) and connect a full-speed test device to an available downstream port of the hub. The test configures the full-speed test device to support a pair of isochronous endpoints and a pair of bulk endpoints. Each endpoint is configured for loopback transfers. A series of several frames of transactions are run as part of the test. The transfers occur as follows:

  1. Isochronous OUT to out endpoint of loopback pair.
  2. Stop Periodic List.
  3. Queue isochronous OUT endpoint to dummy endpoint (no real endpoint).
  4. Queue isochronous IN from IN endpoint of loopback pair.
  5. Attempt bulk IN transfer as soon as isochronous transfers start.

This process is repeated with the size of the isochronous OUT transfer (and thus the isochronous IN) increased by one byte each time. This continues until the Bulk transfer no longer executes. If the transfer stops executing before the total size of the isochronous OUT and isochronous IN transfers (streaming) are less than 1370 bytes the test fails.

The test is repeated for Bulk IN transfers.

The procedure is also repeated for BULK transactions of all possible sizes.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • Full-speed compliance device.

Results Interpretation

The test writes all results to a file (AdvTransferTest.log).

The test fails if:

  • A non-periodic transaction does not occur when the periodic pipeline is empty and there is more than enough time before the end of the frame.
  • The TT stops executing bulk transfers when it still has more than enough time left in the frame to execute them.


TD-9.30.1.40 Mixed Stream Interoperability Test

This test creates multiple loopback streams of various mixed transfer types. The algorithms for the loopback tests are described in TD-9.29.1.22, TD-9.29.1.23, TD-9.29.1.30, and TD-9.29.1.31.

Overview

For this test, you connect the high-speed hub to an EHCI host controller (high-speed capable port). Full-speed and low-speed test devices are connected to a USB 1.1 hub, which is connected to an available downstream port of the high-speed test hub. The test configures the full- and low-speed test devices to support pairs of loopback endpoints for each transaction type. The loopback tests described in the loopback tests for each individual transfer type are run simultaneously. They are run first for the full-speed device only, and then for both devices together. In each case, the period of the periodic loopback streams is varied for each stream at a different rate.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • EHCI high-speed capable root port.
  • Full-speed compliance device.
  • Low-speed compliance device.

Results Interpretation

The test writes all results to a file (AdvTransferTest.log).

The test fails if the data read on an IN transfer does not match the data written on an OUT transfer.


Chapter 10: ATA/ATAPI Peripheral and Controller Test Specification

This document describes tests that determine hardware compliance with requirements described in Microsoft Windows Logo Program System and Device Requirements. This document describes ATA (AT Attachment) / ATAPI (ATA Packet Interface) platform hardware (controller) and ATA/ATAPI device (hard disk, CD and DVD) tests for key requirements in Microsoft Windows Logo Program System and Device Requirements.

Test Coverage

This document covers ATA and ATAPI storage controller and peripheral requirements. The peripherals covered are hard disk, CD and DVD drives. Other ATA/ATAPI devices such as writeable CDs and rewriteable optical media are not covered by this test specification.

Test Methodology

The ATA/ATAPI controllers and peripherals are implemented via a complex set of protocols. The correct operation of these protocols requires a software implementation that controls and coordinates the interaction of the hardware controller and peripherals. This test specification and associated tests use existing Windows ATA/ATAPI device drivers to access and control the hardware being tested.

These existing drivers offer the stability and functionality required to test the correct functioning of the hardware without masking the actual operation of that hardware. Where possible, the hardware is accessed as close to the bottom of the operating system software stack as possible using such technologies as ASPI or the SCSI pass through commands present in the Windows operating systems. This approach minimizes the possibility that incorrect software implementation is the source of any errors uncovered by the tests.

Problems in the implementation of the ATA/ATAPI controllers and peripherals, whether from correctness or performance issues, are most likely to be found through complex and/or concurrent command sequences. There are complex test scenarios that can only be implemented by utilizing all layers of the software stack. These layers include the following areas: application, file system, cache system, device driver and HAL. The tests attempt to separate software from hardware related problems and provide specific interpretable diagnostic output.

The ATA/ATAPI tests are designed to minimize operator input, remove subjective testing whenever possible and run on standard Windows Logo Program-compliant systems under Windows 2000. The complex interaction of system, controller and peripherals dictates that correct operation of each of the components be tested, at least in part, by a system configuration containing each of these elements. The result is that in many cases, both controller and peripherals are tested together.

Hardware Requirements

It is required that the tests be executed on a Windows Logo Program-compliant system that includes the following types of hardware: hard disks, CD and DVD drives, and ATA/ATAPI compliant controllers. Correct operation of the system and device hardware can only be determined by attaching devices to the system with specified capabilities. For example, the system might have ATA devices that support various rates of DMA and/or PIO with devices that support asynchronous and overlapped command modes

Software Requirements

The ATA tests execute directly under Microsoft Windows 2000 applications. All software must comply with software-related requirements defined for the Windows Logo Program for hardware.


ATA/ATAPI Test Assertions

All ATA/ATAPI test assertions can be classified into three categories:

  • ATA/ATAPI Controller assertions
  • ATA/ATAPI Peripheral general assertions
  • Power management for ATA/ATAPI controller and peripheral devices assertions

The controller/peripheral nature of the ATA/ATAPI subsystem requires that many of the capabilities be tested in tandem. Where a test validates capabilities of both controllers and peripherals, the actual test description appears in the section that has the most relevance to the test.

The power management assertion category includes tests to:

  • Verify the correct implementation of all power management states and transitions for controllers and devices
  • Verify the retention of required operational states across all power management state transitions
  • Validate that the peripherals can be independently managed through their power state transitions and commands


Reference Document Sources for ATA/ATAPI Assertions

Functional requirements specified in the following documents:

ATA/ATAPI-5

ATA standards: Global Engineering Documents at http://global.ihs.com/

ATAPI Removable Media Device BIOS Specification (ARMD), V. 1.0

http://www.phoenix.com/products/specs.html

Compaq-Intel-Phoenix BIOS Boot Specification, V.1.01; El Torito—Bootable CD-ROM Format Specification, V.1.0

http://www.ptltd.com/techs/specs.html

Media Status Notification Support Specification, V. 1.03

http://www.microsoft.com/hwdev/resources/specs/storspec.asp

Microsoft Windows Logo Program System and Device Requirements, Version 2.0

http://www.microsoft.com/hwdev/winlogo/
(listed as "WLP#" in these assertions)

Microsoft Windows Driver Development Kit

http://www.microsoft.com/ddk/

MMC-2 - Multi-Media Command Set-2

Global Engineering Documents at http://global.ihs.com/
(incorporates information defined in Enhanced Music CD Specification)

NCITS Serial Bus Protocol-2 (SBP-2) transport protocols (ANSI NCITS 3.25-1998)

Global Engineering Documents at http://global.ihs.com/

PC 2001 System Design Guide and PC 99 System Design Guide

http://www.microsoft.com/hwdev/platform/pcdesign/desguide/pcguides.asp

Reduced Block Commands (RBC; NCITS.330-2000)

Global Engineering Documents at http://global.ihs.com/

SCSI Parallel Interface (SPI-3) [ANSI/NCITS T10-1302D] standard

Global Engineering Documents at http://global.ihs.com/

Small Computer Interface (SCSI-2)

[X3.131:1994] standard
Global Engineering Documents at http://global.ihs.com/

Universal Serial Bus Mass Storage Class Specification Overview, Revision 1.0

http://www.usb.org/developers


ATA/ATAPI Controller Assertions

The test assertions derived for ATA/ATAPI controllers are covered in this section. Assertions that are tested, as well as those that are not, are listed as appropriate. Several requirements reference compatibility with comprehensive specifications that have many correctness assertions contained within them. In these cases, the detailed breakout of the specific compatibility requirements contained within the referenced specification that are to be verified is provided in the applicable sections of this document.

10.1.1 Controller and peripherals comply with ATA-2, ATA-3 or ATA/ATAPI4.

Reference documents: WLP# - B10.2.2.1; PC 2001 System Design Guide - ATA-0115, STOR-0347; PC 99 System Design Guide - 10.1.
Test descriptions: TD-10.4 ATA/ATAPI Command Processing Capability Test and TD-10.5 ATA/ATAPI Mode Selection Capability Test

10.1.2 Dual ATA adapters use a single FIFO with asynchronous access or dual FIFOs and channels.

Reference Documents: WLP# - ; PC 2001 System Design Guide - ATA-0118; PC 99 System Design Guide - 10.4.
Test Description: TD-10.1 ATA/ATAPI-4 Bus Master/Asynchronous/Dual FIFO Capability Test

10.1.3 Controller and peripherals support Ultra DMA.

Reference Documents: WLP# - B10.2.4.4; PC 2001 System Design Guide - ATA-0119, STOR-0350; PC 99 System Design Guide - 10.7, 18.6.
Test Descriptions: TD-10.2 Ultra DMA Capability Test and TD-10.3 ATA/ATAPI Ultra DMA Performance Test

10.1.4 Storage components and optical devices support bus master capabilities.

Reference Documents: WLP# - B10.1.4.6; PC 2001 System Design Guide - STOR-0341; PC 99 System Design Guide - 18.1.
Test Descriptions: TD-10.1 ATA/ATAPI-4 Bus Master/Asynchronous/Dual FIFO Capability Test

10.1.5 ATA/ATAPI controllers comply with ATA/ATAPI-5 standards.

Reference Documents: WLP# - 10.2.2.1; PC 2001 System Design Guide - ATA-0115; AT Attachment With Packet Interface Extension -5 (ATA/ATAPI5).
Test Descriptions: TD-10.13 ATAPI-5 Capability Test and TD-10.17 ATAPI-5 Compliance Test

10.1.6 Controller supports Ultra DMA (ATA/33).

Reference Documents: WLP# - B10.2.4.4; PC 2001 System Design Guide - ATA-0119; AT Attachment With Packet Interface Extension -5 (ATA/ATAPI5).
Test Description: TD-10.2 Ultra DMA Capability Test and TD-10.3 ATA/ATAPI Ultra DMA Performance Test


ATA/ATAPI Controller Assertions Not Tested

The following ATA/ATAPI controller assertions are not tested.

Note: Assertions defined as "Not Tested" under the provisions of this specification may be subject to testing through alternative test facilities.

10.2.1 Bootable ATA controller supports El Torito No Emulation Mode.

Reference Documents: WLP# - B10.1.4.2; PC 2001 System Design Guide - ATA-0116; PC 99 System Design Guide - 10.2.
Test Description: Not Tested

10.2.2 Option ROMs support Int 13h extensions.

Reference Documents: WLP# -A1.1.4; PC 2001 System Design Guide - ATA-0117; PC 99 System Design Guide - 10.3.
Test Description: Not Tested

10.2.3 System BIOS and devices support LBA.

Reference Documents: WLP# - A1.1.4; PC 2001 System Design Guide - ATA-0117; PC 99 System Design Guide - 10.5.
Test Description: Not Tested

10.2.4 System BIOS supports ARMD.

Reference Documents: WLP# - A1.1.4; PC 2001 System Design Guide - BIOS-0018; PC 99 System Design Guide - 10.6.
Test Description: Not Tested

10.2.5 Controller and peripheral connections include Pin 1 cable designation with keyed and shrouded connectors.

Reference Documents: WLP# - B10.2.4.6; PC 2001 System Design Guide - ATA-0120; PC 99 System Design Guide - 10.8.
Test Description: Not Tested

10.2.6 Each device has a Plug and Play device ID.

Reference Documents: WLP# - A1.1.3; PC 2001 System Design Guide - SYS-0026; PC 99 System Design Guide - 10.13.
Test Description: Not Tested

10.2.7 Dynamic resource configuration is supported for all devices.

Reference Documents: WLP# - A1.1.3; PC 2001 System Design Guide - SYS-0026; PC 99 System Design Guide - 10.14.
Test Description: Not Tested

10.2.8 Resource configuration meets bus requirements.

Reference Documents: WLP# - A1.1.3; PC 2001 System Design Guide - SYS-0026; PC 99 System Design Guide - 10.15.
Test Description: Not Tested

10.2.9 ISA address ranges 3F7h and 377h are not claimed by ATA controllers.

Reference Documents: WLP# - B10.2.4.4; PC 2001 System Design Guide -ATA-0119; PC 99 System Design Guide - 10.16.
Test Description: Not Tested

10.2.10 PC ATA/ATAPI controller complies with PCI Bus Power Management Interface specification.

Reference Documents: WLP# - B2.5.4.1; PC 99 System Design Guide - 10.17.
Test Description: Not Tested

10.2.11 Discrete PCI ATA controllers in mobile docking stations implement in PCI Native-Mode ATA.

Reference Documents: WLP# - A3.4.7; PC 2001 System Design Guide - ATA-0122.
Test Description: Not Tested


ATA Hard Disk Drive Test Assertions

The controller/peripheral nature of the ATA implementation results in some of the tests contained in this specification covering both controller and peripherals. The test assertions contained in this section are most relevant to hard disk drive requirements. Additional information regarding the derivation of these assertions is also provided.

10.3.1 Controller and peripherals comply with ATA-2, ATA-3 or ATA/ATAPI-4 protocols.

Reference Documents: WLP# - B10.2; PC 99 System Design Guide - 10.1.
Test Description: TD-10.4 ATA/ATAPI Command Processing Capability Test

10.3.2 Controller and peripherals support Ultra DMA.

Reference Documents: WLP# - B10.2.4.4; PC 2001 System Design Guide - ATA-0119, STOR-0350; PC 99 System Design Guide - 10.7, 18.6.
Test Description: TD-10.2 Ultra DMA Capability Test and TD-10.3 ATA/ATAPI Ultra DMA Performance Test

10.3.3 Peripherals comply with ATA/ATAPI-4 or SFF8020I v.2.5.

Reference Documents: WLP# - B10.2; PC 99 System Design Guide - 10.9.
Test Description: TD-10.4 ATA/ATAPI Command Processing Capability Test

10.3.4 Bus and device meet PC 99 power management requirements.

Reference Documents: WLP# - B10.2; PC 99 System Design Guide - 10.17.
Test Description: TD-10.6 ATA/ATAPI Hard Disk Drive Power Management Capability Test

10.3.5 ATA device supports ATA STANDBY command.

Reference Documents: WLP# - B10.2.4.9; PC 2001 System Design Guide - STOR-0349, PC 99 System Design Guide - 10.18.
Test Description: TD-10.6 ATA/ATAPI Hard Disk Drive Power Management Capability Test

10.3.6 Operating system recognizes the boot drive in a multiple-drive system.

Reference Documents: WLP# - A1.1.4; PC 2001 System Design Guide - BIOS-0005.4,
PC 99 System Design Guide - 18.14.
Test Description: TD-10.4 ATA/ATAPI Command Processing Capability Test

10.3.7 Device and controller comply with device class power management reference specification.

Reference Documents: WLP# - B1.4.5; PC 2001 System Design Guide - STOR-0364,
PC 99 System Design Guide - 18.37.
Test Description: TD-10.6 ATA/ATAPI Hard Disk Drive Power Management Capability Test

10.3.8 Peripherals comply with ATA/ATAPI-5.

Reference Documents: WLP# - B10.1.2.2; PC 2001 System Design Guide - STOR-0347, AT Attachment With Packet Interface Extension -5 (ATA/ATAPI-5).
Test Description: TD-10.13 ATAPI-5 Capability Test and TD-10.17 ATAPI-5 Compliance Test

10.3.9 ATA devices support Ultra DMA.

Reference Documents: WLP# - B10.2.4.4; PC 2001 System Design Guide - STOR-0350, AT Attachment with Packet Interface Extension -5 (ATA/ATAPI-5).
Test Description: TD-10.2 Ultra DMA Capability Test and TD-10.3 ATA/ATAPI Ultra DMA Performance Test


ATA Hard Disk Drive Test Assertion Not Tested

The following ATA Hard Drive test assertion is not tested.

Note: Assertions defined as "Not Tested" under the provisions of this specification may be subject to testing through alternative test facilities.

10.4.1 Hard drive is SMART-compliant and uses SMART IOCTL API

Reference document: WLP# - B10.2; PC 99 System Design Guide - 18.15.
Test Description: Not Tested


ATA/ATAPI-5 CD Drive Assertions

The test assertions contained in this section are most relevant to CD drive requirements. Additional information regarding the derivation of these assertions is also provided.

10.5.1 Controller and peripherals comply with: ATA-2, ATA-3 or ATA/ATAPI-4 protocols.

Reference Documents: WLP# - B10.2; PC 99 System Design Guide - 10.1.
Test Descriptions: TD-10.4 ATA/ATAPI Command Processing Capability Test

10.5.2 Removable media devices support media status notification.

Reference Documents: WLP# - B10.1.4.3; PC 2001 System Design Guide - STOR-0342, SYS-0030.3; PC 99 System Design Guide - 10.10, 18.2.
Test Description: TD-10.7 ATA/ATAPI CD Drive Media Status Notification Capability Test

10.5.3 ATAPI devices support DEVICE RESET command.

Reference Documents: WLP# - B10.2.4.8; PC 2001 System Design Guide - STOR-0348; PC 99 System Design Guide - 10.12.
Test Description: TD-10.8 ATA/ATAPI CD Drive Power Management Capability Test

10.5.4 Bus and device meet PC 99 power management requirements.

Reference Documents: PC 99 System Design Guide - 10.17.
Test Description: TD-10.8 ATA/ATAPI CD Drive Power Management Capability Test

10.5.5 ATA device supports ATA STANDBY command.

Reference Documents: WLP# - B10.2.4.9; PC 2001 System Design Guide - STOR-0349; PC 99 System Design Guide - 10.18.
Test Description: TD-10.8 ATA/ATAPI CD Drive Power Management Capability Test

10.5.6 Operating system recognizes the boot drive in a multiple-drive system.

Reference Documents: WLP# - A1.1.4; PC 2001 System Design Guide - BIOS-0005.4; PC 99 System Design Guide - 18.14.
Test Description: TD-10.4 ATA/ATAPI Command Processing Capability Test

10.5.7 ATA/ATAPI CD drive complies with SFF 8020i v.2.6.

Reference Documents: WLP# - B10.2; PC 99 System Design Guide - 18.19.
Test Description: TD-10.4 ATA/ATAPI Command Processing Capability Test

10.5.8 Device and controller comply with Storage Device Class Power Management Reference Specification.

Reference Documents: WLP# - B1.4.5; PC 2001 System Design Guide - STOR-0364; PC 99 System Design Guide - 18.37.
Test Description: TD-10.8 ATA/ATAPI CD Drive Power Management Capability Test

10.5.9 Peripherals comply with ATA/ATAPI-5.

Reference Documents: WLP# - B10.1.2.2; PC 2001 System Design Guide - STOR-0347; AT Attachment With Packet Interface Extension -5 (ATA/ATAPI-5).
Test Description: TD-10.13 ATAPI-5 Capability Test and TD-10.17 ATAPI-5 Compliance Test

10.5.10 ATA/ATAPI CD or DVD drive complies with MMC-2.

Reference Documents: WLP# - B10.5.2.1; PC 2001 System Design Guide - STOR-0354, NCITS 333 T10/1228-D SCSI Multi-Media Command Set -2 (MMC-2); NCITS Project T10/1236-D SCSI Primary Commands-2 (SPC-2).
Test Description: TD-10.14 MMC-2 Capability Test and TD-10.18 MMC-2 Compliance Test

10.5.11 Support for the READ CD-DA command as defined in the MMC-2 standard is required.

Reference Documents: WLP# - B10.5.2.1; PC 2001 System Design Guide - STOR-0354, NCITS 333 T10/1228-D SCSI Multi-Media Command Set -2 (MMC-2); NCITS Project T10/1236-D SCSI Primary Commands-2 (SPC-2).
Test Description: TD-10.14 MMC-2 Capability Test and TD-10.18 MMC-2 Compliance Test

10.5.12 CD and DVD devices use push-to-close design.

Reference Documents: WLP# - B10.2; PC 99 System Design Guide - 18.23.
Test Description: [NOT TESTED]


ATA/ATAPI-5 CD Drive Assertions Not Tested

The following ATA/ATAPI-5 CD Drive assertions are not tested.

Note: Assertions defined as "Not Tested" under the provisions of this specification may be subject to testing through alternative test facilities.

10.6.1 CD device provides 8x minimum transfer rate or better performance.

Reference Documents: WLP# - B10.5.4.2; PC 2001 System Design Guide - STOR-0362; PC 99 System Design Guide - 18.16.
Test Descriptions: Not Tested

10.6.2 CD Drive is CD-enhanced compatible.

Reference Documents: WLP# - B10.5.4.2; PC 2001 System Design Guide - STOR-0352; PC 99 System Design Guide - 18.17.
Test Descriptions: Not Tested

10.6.3 CD drive supports specified logical and physical CD formats.

Reference Documents: WLP# - B10.5.4.2; PC 2001 System Design Guide - STOR-0353; PC 99 System Design Guide - 18.18.
Test Descriptions: Not Tested

10.6.4 CD drive supports multisession and compatibility forms of the READ_TOC command.

Reference Documents: WLP# - B10.5.2.2; PC 2001 System Design Guide - STOR-0355; PC 99 System Design Guide - 18.20.
Test Descriptions: Not Tested

10.6.5 CD device supports digital audio detection.

Reference Documents: WLP# - B10.5.4.2; PC 2001 System Design Guide - STOR-0357; PC 99 System Design Guide - 18.22.
Test Descriptions: Not Tested

10.6.6 OS enumeration of all ATAPI devices complies with ATA/ATAPI-4 or SFF 8020I v.2.5.

Reference Documents: WLP# - B10.2; PC 99 System Design Guide - 10.11.
Test Descriptions: Not Tested

10.6.7 ATA/ATAPI CD or DVD changer complies with MMC-2.

Reference Documents: WLP# - B10.8.4.1; PC 2001 System Design Guide - STOR-0356; PC 99 System Design Guide - 18.21.
Test Descriptions: Not Tested


ATA/ATAPI-5 DVD Assertions

The following ATA/ATAPI-5 DVD assertions are tested.

10.7.1 Controller and peripherals comply with: ATA-2, ATA-3 or ATA/ATAPI-4 protocols.

Reference Documents: WLP# - B10.2; PC 99 System Design Guide - 10.1.
Test Description: TD-10.4 ATA/ATAPI Command Processing Capability Test

10.7.2 Removable media devices support media status notification.

Reference Documents: WLP# - B10.1.4.3; PC 2001 System Design Guide - STOR-0342, SYS-0030.3; PC 99 System Design Guide - 10.10, 18.2.
Test Description: TD-10.9 ATA/ATAPI DVD Media Status Notification Capability Test

10.7.3 ATAPI devices support DEVICE RESET command.

Reference Documents: WLP# - B10.2.4.8; PC 2001 System Design Guide - STOR-0348; PC 99 System Design Guide - 10.12.
Test Description: TD-10.10 DVD Drive Power Management Capability Test

10.7.4 Bus and device meet PC 99 power management requirements.

Reference Documents: WLP# - B10.2; PC 99 System Design Guide - 10.17.
Test Description: TD-10.10 DVD Drive Power Management Capability Test

10.7.5 ATA device supports ATA STANDBY command.

Reference Documents: WLP# - B10.2.4.8; PC 2001 System Design Guide - STOR-0349; PC 99 System Design Guide - 10.18.
Test Description: TD-10.10 DVD Drive Power Management Capability Test

10.7.6 DVD device complies with MMC-2 standard.

Reference Documents: WLP# - B10.5.2.1; PC 2001 System Design Guide - STOR-0354,
PC 99 System Design Guide - 18.28.
Test Descriptions: TD-10.9 ATA/ATAPI DVD Media Status Notification Capability Test and TD-10.10 DVD Drive Power Management Capability Test

10.7.7 DVD drive and controller support bus master DMA transfers.

Reference Documents: WLP# - B10.5.4.1; PC 2001 System Design Guide - STOR-0341; PC 99 System Design Guide - 18.26.
Test Description: TD-10.11 ATA/ATAPI DVD Bus Master DMA Capability Test

10.7.8 Device and controller comply with Storage Device Class Power Management Reference Specification.

Reference Documents: WLP# - B1.4.5; PC 2001 System Design Guide - STOR-0364; PC 99 System Design Guide - 18.37.
Test Description: TD-10.10 DVD Drive Power Management Capability Test

10.7.9 Peripherals comply with ATA/ATAPI-5.

Reference Documents: WLP# -B10.1.2.2 ; PC 2001 System Design Guide - STOR-0347; AT Attachment With Packet Interface Extension -5 (ATA/ATAPI-5).
Test Description: TD-10.13 ATAPI-5 Capability Test and TD-10.17 ATAPI-5 Compliance Test

10.7.10 ATA/ATAPI CD or DVD drive complies with MMC-2.

Reference Documents: WLP# - B10.5.4.3; PC 2001 System Design Guide - STOR-0354, NCITS 333 T10/1228-D SCSI Multi-Media Command Set -2 (MMC-2), AT Attachment With Packet Interface Extension-5 (ATA/ATAPI-5); NCITS Project T10/1236-D SCSI Primary Commands-2 (SPC-2).
Test Description: TD-10.14 MMC-2 Capability Test; TD-10.18 MMC-2 Compliance Test

10.7.11 CD and DVD devices use push-to-close design.

Reference Documents: WLP# - B10.2; PC 99 System Design Guide - 18.23.
Test Description: Not Tested


ATA/ATAPI-5 DVD Assertions Not Tested

The following ATA/ATAPI-5 DVD assertions are not tested.

Note: Assertions defined as "Not Tested" under the provisions of this specification may be subject to testing through alternative test facilities.

10.8.1 DVD device provides 2 MB per second minimum transfer rate or better performance anywhere on the disc.

Reference Documents: WLP# - B10.5.4.3; PC 2001 System Design Guide - STOR-0360; PC 99 System Design Guide - 18.25.
Test Descriptions: Not Tested

10.8.2 DVD drive meets minimum compatibility requirements.

Reference Documents: WLP# - B10.2; PC 99 System Design Guide - 18.27.
Test Descriptions: Not Tested

10.8.3 DVD device supports defect management.

Reference Documents: WLP# - B10.5.4.3; PC 2001 System Design Guide - STOR-0361; PC 99 System Design Guide - 18.30.
Test Descriptions: Not Tested

10.8.4 DVD device supports copyright protection.

This is not a Windows Logo Program requirement.

Reference document: PC 99 System Design Guide - 18.31.
Test Descriptions: Not Tested

10.8.5 ATA/ATAPI CD or DVD changer complies with MMC-2.

Reference Documents: WLP# -B10.8.4.1; PC 2001 System Design Guide - STOR-0356; PC 99 System Design Guide - 18.21.
Test Descriptions: Not Tested


ATA/ATAPI Test Descriptions

This section describes the ATA/ATAPI peripheral and controller tests. Test descriptions include: a detailed specification of each test, set up requirements and results interpretations with any associated issues and problems discussed to remove ambiguity.


TD-10.1 ATA/ATAPI-4 Bus Master/Asynchronous/Dual FIFO Capability Test

Overview

This test determines whether a system supports bus master data transfers by the ATA controller(s). Bus mastering allows the ATA controller to efficiently transfer data over the system bus without using processor bandwidth. The FIFO(s) is used in the transfer of data to or from the system under direction of the controller and the FIFO(s) must not be a single point of resource contention within the system. In a dual FIFO configuration, each FIFO should be accessed independently so that transfers on each bus may happen independently of the other. If a single FIFO is used for a dual adapter configuration, then each controller should be able to access the FIFO independently while issuing an operation.

A controller compliant with ATA/ATAPI-4 supports the following status bit in the Class Code:

Bit | Description
7:0 | Programming Interface (PI). 80h=Capable of IDE bus master operation

A controller compliant with ATA/ATAPI-4 supports the following status bits in the Bus Master Status register:

Bit | Description
7 | Simplex only. This read-only bit indicates whether or not both bus master channels (primary and secondary) can be operated at the same time. If the bit is set to ‘0’ then the channels operate independently and can be used at the same time. If the bit is set to ‘1’ then only one channel may be used at a time.
6 | Drive 1 DMA Capable: This read/write bit is set by device dependent code (BIOS or device driver) to indicate that drive 1 for this channel is capable of DMA transfers and that the controller has been initialized for optimum performance.
5 | Drive 0 DMA Capable: This read/write bit is set by device dependent code (BIOS or device driver) to indicate that drive 1 for this channel is capable of DMA transfers and that the controller has been initialized for optimum performance.

After the system is booted to Windows 2000 the test program interrogates the status of the ATA controller by using a query interface to the disk device driver.

Overview of Test Steps

The test program queries the disk device driver that is responsible for the operation of the ATA controllers. At the time of the invocation of the test program, the device driver will have fully initialized the ATA controller and is fully capable of access to both disk drives. The test program passes a request to the device driver to return the status of the two sets of bits as described above. The test then interprets these bits to determine whether bus master and independent channel operations are supported capabilities and that the device driver has successfully enabled both devices for simultaneous bus master DMA transfers.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The system must be configured with ATA/ATAPI-4 compliant controllers and devices. The controllers and devices must be capable of supporting bus mastering and ATA/33, which is also known as Ultra DMA mode 2.

For software setup, the system requires Microsoft Windows 2000 (or later) be installed.

Results Interpretation

Individual pass/fail indication is provided for each test category of controller independent access provided and device DMA mode successfully enabled.

The following conditions cause test failures:

  • ATA controller does not support bus mastering as reflected in the class code register.
  • ATA controller supports simplex mode only as reflected in the corresponding bus master status register.
  • ATA device is not successfully configured for DMA transfers.

The following advisory information is provided as applicable:

  • Content of bits [7:0] in class code register.
  • Content of status bit 7 in bus master status register.
  • Content of status bit 6 in bus master status register.
  • Content of status bit 5 in bus master status register.

It is possible for the ATA devices or the software stack to be the cause of a failure to enable DMA on an ATA channel. Bits 5 and 6 of the bus master status register are under control of the device driver and reflect the result of the driver’s efforts to enable DMA on each of the channels. If the bits are not set, this test is not capable of determining whether the device or controller is at fault. It is assumed that the devices attached to the system have been verified to operate correctly in DMA mode and that failure to enable DMA mode is indicative of a problem within the controller.


TD-10.2 Ultra DMA Capability Test

Overview

The ATA bus (also called the IDE bus) is a storage interface originally designed for the ISA Bus of the IBM PC/AT. With the advent of faster host systems and devices, the definition of the bus has been expanded to include new operating modes. Each of the PIO modes, numbered zero through four, is faster than the one before (higher numbers translate to faster transfer rates). PIO modes 0, 1, and 2 correspond to transfer rates for the interface as were originally defined with maximum transfer rates of 3.3, 5.2, and 8.3 megabytes per second (MB/s), respectively. PIO mode 3 defines a maximum transfer rate of 11.1 MB/s, and PIO mode 4 defines a maximum rate of 16.7 MB/s. Additionally, Multiword DMA and Ultra DMA modes have been defined. Multiword DMA mode 0, 1, and 2 have maximum transfer rates of 4.2, 13.3, and 16.7 MB/s, respectively. Ultra DMA modes 0, 1, 2, 3 and 4 have maximum transfer rates of 16.7, 25, 33.3, 44.4, and 66.6 MB/s, respectively.

The Ultra DMA Capability Test determines whether ATA controllers and devices support Ultra DMA mode 2. Ultra DMA mode 2 is a protocol that supports DMA transfers of 33.3 MB/s between peripherals and main memory without processor intervention. Correct support is either Ultra DMA mode 2, 3 or 4, which are the modes that support at least 33.3 MB/s transfer rates.

Overview of Test Steps

The test program interrogates the status of the ATA controller by using the query interface to the disk device driver to examine the running state of the device driver and controller. The test determines the Ultra DMA transfer modes supported by the device by issuing an IDENTIFY DEVICE. Each device reports its transfer mode configuration in the response packet. The transfer mode configuration is assessed by examining the following field:

Word | Bits | Description
88 | 2 | UltraDMA mode 2 and below are supported

Bit 2 of word 88 must be set to indicate that Ultra DMA mode 2 is supported.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The system must be configured with ATA/ATAPI-5 compliant controllers and devices. These controllers and devices must be capable of supporting Ultra DMA mode 2.

For software setup, the system requires that Windows 2000 (or later) is installed.

Results Interpretation

Individual pass/fail indication is provided for each test category of controller and individual device Ultra DMA mode successfully supported. The test transcribes all results to a text based log file.

The test fails if:

  • An ATA controller does not support Ultra DMA mode 2.
  • An ATA device does not support Ultra DMA mode 2.

The test aborts if:

  • No ATA controller or device is present in this system.
  • An ATA controller, device or the software stack fails to query an ATA device.

The following advisory information is provided as applicable:

  • ATA controller Ultra DMA support and selected state.
  • ATA device Ultra DMA support and selected state.


TD-10.3 ATA/ATAPI Ultra DMA Performance Test

Overview

The ATA bus (also called the IDE bus) is a storage interface originally designed for the ISA Bus of the IBM PC/AT. With the advent of faster host systems and devices, the definition of the bus has been expanded to include new operating modes. Each of the PIO modes numbered zero through four is faster than the one before (higher numbers translate to faster transfer rates). PIO modes 0, 1, and 2 correspond to transfer rates for the interface as were originally defined with maximum transfer rates of 3.3, 5.2, and 8.3 megabytes per second (MB/s), respectively. PIO mode 3 defines a maximum transfer rate of 11.1 MB/s, and PIO mode 4 defines a maximum rate of 16.7 MB/s. Additionally, Multiword DMA and Ultra DMA modes have been defined. Multiword DMA mode 0, 1, and 2 have maximum transfer rates of 4.2, 13.3, and 16.7 MB/s, respectively. Ultra DMA modes 0, 1, 2, 3 and 4 have maximum transfer rates of 16.7, 25, 33.3, 44.4, and 66.6 MB/s, respectively.

The Ultra DMA Performance Test determines whether ATA controllers and hard drive peripherals support 33 MB per second or higher transfer rates. Ultra DMA mode 2 is a protocol that supports DMA transfers of 33 MB per second between devices and main memory without processor intervention.

Overview of Test Steps

This test reads large amounts of data from a hard disk device attached to an ATA controller, using the READ DMA or READ DMA QUEUED command. Measuring the data throughput determines if Ultra DMA mode 2 transfers are taking place. There is overhead on each transfer request that is issued to an ATA device. The overhead includes application, operating system, device driver, controller and peripheral processing times. This test attempts to minimize the overhead by using strictly large reads to maximize the percentage of time spent processing data.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The system must be configured with an ATA/ATAPI-5 compliant controller and hard drive. The drive must be capable of supporting bus mastering and Ultra DMA mode 2.

For software setup, the system requires that Windows 2000 (or later) is installed.

Results Interpretation

Individual pass/fail indication is provided for each test category of controller Ultra DMA enabled and individual device Ultra DMA mode successfully enabled. The test transcribes all results to a text based log file.

The test fails if:

  • The read transfers from the hard disk are below 50% of 33 MB per second.

The test aborts if:

  • No ATA controller or device is present in this system.
  • An ATA controller, device or the software stack fails to query an ATA device.

The following advisory information is provided as applicable:

  • The average read data transfer rate from the ATA hard disk.


TD-10.4 ATA/ATAPI Command Processing Capability Test

Overview

The purpose of this test is to insure that ATA controllers and peripherals support the key operation aspects of the ATA-2, ATA-3 or ATA/ATAPI-4 protocols that are necessary to run the Windows family of operating systems. There are a large number of commands and possible permutations of command issuance allowed by these specifications. The resulting state space is extremely large and cannot be exhaustively tested. The non-exhaustive verification performed in this test is done by the general process of formatting drives, installing an operating system, checking the integrity of drives and running a stress test to exercise all key commands and protocols. This test sequence is designed to cover the key aspects of the protocol that is exercised in the actual running of the system under the operating system.

Overview of Test Steps

The Microsoft Windows 2000 operating system setup boot disk is inserted into a floppy drive and the installation procedure starts. The Windows 2000 installation CD is then inserted in the CD (or DVD) drive and the install procedure continues. During installation a partition is created on the hard drive created with the FAT32 file system.

Once Windows 2000 has been installed, the test operator is prompted to create three additional partitions using the Disk Administrator on the remaining drive space. The three partitions should be named: FAT, FAT32 and NTFS.

A WIN32 application level disk stress test is then run which spawns multiple threads and reads/writes to all the disks in random order with known data patterns. These data patterns are designed to detect common disk transfer and storage errors. This stress test is a Windows 32 application and as such exercises all reasonable paths through the controller and device hardware.

Following the completion of the stress test, disk check utilities are run so that the fundamental disk structures of each disk are verified. If all of these steps are successful, then the controller and drives have an acceptable level of compliance with the basic ATA-2, ATA-3 or ATA/ATAPI-4 specifications.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The system must be configured with ATA/ATAPI-4 compliant controllers and devices. These controllers and devices must be capable of supporting bus mastering and ATA/33, which is also known as Ultra DMA mode 2.

The system requires formatted blank hard drives and this test installs Microsoft Windows 2000 as described in the narrative of the test.

Results Interpretation

Test results provide pass/fail indication. The following conditions cause test failures:

  • Failure of the Windows 2000 operating system to be installed correctly.
  • Failure of the Disk Administrator to successfully create the additional file system partitions.
  • Failure of the disk stress test application to successfully complete and verify the resultant data stored on the disk.
  • Failure of the disk checking utilities to validate the on disk structures for all four of the file system partitions.

Diagnostic output is provided by the Windows 2000 operating system for installation, file system creation and file system partition data structure verification. The stress test application provides diagnostic output on any read or write errors and details of the location and nature of any data discrepancy.


TD-10.5 ATA/ATAPI Mode Selection Capability Test

Assertion 10.1.1 is superseded by assertions 10.1.5 and 10.3.8.

Overview

A key element of compliance with the ATA/ATAPI-4 specification is the ability to support a variety of configurations of peripheral devices. This support must include supporting a variety of transfer modes and speeds. This test verifies that the ATA controller can support the setting of fast timing modes (PIO, BM and UDMA) in mixed combinations for a variety of peripherals. These peripheral configurations also include permutations of primary and secondary channel configurations.

Overview of Test Steps

The system is configured with various drives that support PIO and Ultra DMA transfer modes. The test program then uses the following device driver parameters to force the use of a variety of fast timing modes for each of the peripherals.

The following parameters are tested:

  • 'Use Multi Block': disables Multi Block PIO transfers on a drive. When enabled for a given drive, the drive is accessed in a single sector mode for PIO transfers.
  • ‘Primary Master Mode’ (PMM): override for Primary Master drive that allows the default timing mode of a drive to be changed: either DMA speed X only or PIO speed Y only.
  • ‘Primary Slave Mode’ (PSM): override for Primary Slave drive that allows the default timing mode of a drive to be changed: either DMA speed X only or PIO speed Y only.
  • 'Secondary Master Mode' (SMM): override for Secondary Master drive that allows the default timing mode of a drive to be changed: either DMA speed X only or PIO speed Y only.
  • ‘Secondary Slave Mode’ (SSM): override for Secondary Slave drive that allows the default timing mode of a drive to be changed: either DMA speed X only or PIO speed Y only.

The device transfer modes can only be changed at system boot time so the system is rebooted after each mode change and the device driver is queried to insure that the requested mode matches the mode that the drive has been placed into by the device driver.

The possible modes that can be enabled for a device are:

  • PIO Mode 'P' is applied to the drive ONLY, DMA disabled
  • PIO0/Compatible
  • PIO2
  • PIO3 w/ IORDY flow control
  • PIO4 w/ IORDY flow control
  • DMA Mode 'D' is applied to the drive ONLY, fast PIO disabled (PIO0 is used for any PIO).
  • Single Word DMA 2
  • Multi Word DMA 1
  • Multi Word DMA 2
  • UDMA Mode 'U' is applied to the drive ONLY, fast PIO disabled (PIO0 is used for any PIO).
  • UDMA mode 0
  • UDMA mode 1
  • UDMA mode 2

Peripheral Mode Configuration

Primary Master | Primary Slave | Second Master | Second Slave | PM Mode | PM BMIDE | PS Mode | PS BMIDE | SM Mode | SM BMIDE | SS Mode | SS BMIDE
MW2/PIO4 HDD |  | MW2/PIO4 HDD |  | 4 | Y |  |  | 4 | Y |  |
MW2/PIO4 HDD |  | SW2/PIO3 CD-ROM |  | 4 | y |  |  | 2 | y |  |
MW2/PIO4 HDD | MW1/PIO3 HDD |  |  | 4 | y | 3 | y |  |  |  |
MW2/PIO4 HDD | MW1/PIO3 CD-ROM |  |  | 4 | y | 3 | y |  |  |  |
MW1/PIO3 HDD |  | MW1/PIO3 CD-ROM |  | 3 | y |  |  | 3 | y |  |
UDMA2/ MW2/PIO4 HDD |  | UDMA2/ MW2/PIO4 HDD |  | 4/ U2 | y |  |  | 4 | y |  |
UDMA2/ MW2/PIO4 HDD |  | MW2/PIO4 HDD |  | 4/ U2 | y |  |  | 4 | y |  |
UDMA2/ MW2/PIO4 HDD |  | SW2/PIO2 HDD |  | 4/ U2 | y |  |  | 2 | y |  |
UDMA2/ MW2/ PIO4 HDD |  | SW2/PIO3 CD-ROM |  | 4/ U2 | y |  |  | 2 | y |  |
UDMA2/ MW2/PIO4 HDD |  | UDMA2/ MW2/PIO4 CD-ROM |  | 4/ U2 | y |  |  | 4/ U2 | y |  |
UDMA2/ MW2/PIO4 HDD |  | UDMA2/ MW2/PIO4 DVD |  | 4/ U2 | y |  |  | 4/ U2 | y |  |
UDMA2/ MW2/PIO4 HDD | UDMA2/ MW2/PIO4 HDD |  |  | 4/ U2 | y | 4/ U2 | y |  |  |  |
UDMA2/ MW2/PIO4 HDD | MW2/PIO4 HDD |  |  | 4/ U2 | y | 4 | y |  |  |  |
UDMA2/ MW2/PIO4 HDD | SW2/PIO3 CD-ROM |  |  | 4/ U2 | y | 2 | y |  |  |  |
UDMA2/ MW2/PIO4 HDD | UDMA2/ MW2/PIO4 CD-ROM |  |  | 4/ U2 | y | 4/ U2 | y |  |  |  |
UDMA2/ MW2/PIO4 HDD | UDMA2/ MW2/PIO4 DVD |  |  | 4/ U2 | y | 4/ U2 | y |  |  |  |
 |  | UDMA2/ MW2/PIO4 HDD | UDMA2/ MW2/PIO4 HDD |  |  |  |  | 4/ U2 | y | 4/ U2 | y
 |  | UDMA2/ MW2/PIO4 HDD | MW2/PIO4 HDD |  |  |  |  | 4/ U2 | y | 4 | y
 |  | UDMA2/ MW2/PIO4 HDD | MW1/PIO3 CD-ROM |  |  |  |  | 4/ U2 | y | 3 | y
 |  | UDMA2/ MW2/PIO4 HDD | SW2/PIO3 CD-ROM |  |  |  |  | 4/ U2 | y | 2 | y

After each reboot that has changed the transfer mode operating condition, the device status is queried through the device driver to check that the drive is operating in the transfer mode that was specified by the test. Once the device transfer mode has been verified, the test executes a stress test program that reads and writes known data to the disks in a random fashion with multiple threads. This stress program then verifies that the data on the disks is consistent with the known pattern.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

For hardware setup, the system must be configured with two ATA/ATAPI-4 compliant hard disk drives. These drives must be capable of supporting bus mastering and ATA33 which is also known as Ultra DMA mode 2. CD and DVD drives attached to the system must be capable of Ultra DMA mode 2. Each drive is configured as defined in the above table.

For software setup, the system requires Microsoft Windows NT be installed as described in the software requirements section of this chapter.

Results Interpretation

Individual pass/fail indication is provided for each test category of controller support for the configured modes, and for incorrect completion of random read/write stress tests.

The following conditions cause test failures:

  • If the register(s) and/or the bus master status do not match the table, then this is considered a failed configuration.
  • Stress test for a given configuration did not successfully complete.

The following advisory information is provided as applicable

  • ATA controller and device operational modes.
  • Amount of concurrency used in the stress tests.
  • Amount of data successfully transferred in the stress tests.

It is possible for the ATA devices or the software stack to be the cause of a failure to enable the correct operational mode on one or both of the ATA devices.


TD-10.6 ATA/ATAPI Hard Disk Drive Power Management Capability Test

Overview

This test insures that hard disk drives properly implement the power management functionality as described in the Storage Device Class Power Management Reference Specification, Version 1.0 or later. This document requires that hard disk drives support power states D0, D1 and D3. The D0 power state corresponds to the Active state, the D1 power state to the Standby state and the D3 power state to the Sleep state. The transitions to and between reduced function/consumption power states are controlled in ATA drives by the ATA SLEEP, STANDBY and STANDBY IMMEDIATE commands. In addition, transitions from D0 to D1, D1 to D3 and the correct reactivation of these devices to D0 from D3 through a software bus reset are required. Correct reactivation includes returning to the previous operational DMA state.

Overview of Test Steps

The test determines support for the power management feature set by issuing an IDENTIFY DEVICE command to the device driver. Each device reports its capability to support the power management commands. The power management capabilities are assessed by examining the following fields:

Word | Bits | Description
82 | 3 | Power Management Feature Set supported
85 | 3 | Power Management Feature Set supported

After verifying capability and enabled status, the test program places the master hard drive on the primary channel from the D0 power management mode into the D1 power management mode that is implemented by the Standby state. This state transfer is initiated by issuing the STANDBY IMMEDIATE command. In the Standby state the device’s interface is functional and can respond to commands but the disk media may be spun down. The CHECK POWER MODE command is then issued to the master device on the primary channel to verify that it has gone into the Standby state. The Sector Count field of the command result should be 00h indicating that the device is in Standby.

The test program transitions the master hard disk on the primary ATA channel from the D1 power management mode into the D3 power management mode, which is implemented by the Sleep state. This state transfer is initiated by issuing the SLEEP command. In the Sleep state the device’s interface is not functional and cannot respond to commands and the disk media is spun down.

The test program returns the master hard disk drive on the primary ATA channel to the D0/Active mode or the D1/Standby mode, either of which is supported by the specification by instructing the device driver to issue a software reset on the primary ATA channel. The test program checks to see that the master hard disk drive has returned to Active or Standby mode by issuing a CHECK POWER MODE command. The command should return FFh or 00h in the sector count result value. If the drive has transitioned to the Standby mode, the test program returns the master hard disk drive on the primary ATA channel to the D0 or Active mode issuing a read request to it on the primary ATA channel. The test program then verifies that the Ultra DMA mode has been restored correctly by issuing an IDENTIFY DEVICE command to the master drive and verifying that DMA mode 2 is active.

The test program then transitions the master hard disk on the primary ATA channel from the D0 mode directly into the D3 power management mode, which is implemented by the Sleep state. This state transfer is initiated by issuing the SLEEP command. The test program returns the master hard disk drive on the primary ATA channel to the D0/Active mode or the D1/Standby mode, either of which is supported by the spec by instructing the device driver to issue a software reset on the primary ATA channel. The test program checks to see that the master hard disk drive has returned to Active or Standby mode by issuing a CHECK POWER MODE command. The command should return FFh or 00h in the sector count result value. If the drive has transitioned to the Standby mode, the test program returns the master hard disk drive on the primary ATA channel to the D0 or Active mode issuing a read request to it on the primary ATA channel. The test program then verifies that the Ultra DMA mode has been restored correctly by issuing an IDENTIFY DEVICE command to the master drive and verifying that DMA mode 2 is active.

The test program then places the master hard drive on the primary channel from the D0 power management mode into the D1 power management mode that is implemented by the Standby state. This state transfer is initiated by issuing the STANDBY IMMEDIATE command. In the Standby state the device’s interface is functional and can respond to commands but the disk media may be spun down. The CHECK POWER MODE command is then issued to the master device on the primary channel to verify that it has gone into the Standby state. The Sector Count field of the command result should be 00h indicating that the device is in a Standby state.

The test program returns the master hard disk drive on the primary ATA channel to the D0 or Active mode issuing a read request to it on the primary ATA channel. The test program checks to see that the master hard disk drive has returned to Active mode by issuing a CHECK POWER MODE command. The command should return FFh in the sector count result value. The test program then verifies that the Ultra DMA mode has been restored correctly by issuing an IDENTIFY DEVICE command to the master drive and verifying that DMA mode 2 is active.

The test program issues a STANDBY command with a timeout value of 04h in the sector count register instructing the drive to enter the Standby state in 20 seconds. The test program checks to see that the master hard disk drive is still in the Active mode by issuing a CHECK POWER MODE command. The command should return FFh in the sector count result value. The command must be issued and returned before the 20 second timeout interval has expired. After 30 seconds, allowing the 20 second timer value to expire, the test program issues a CHECK POWER MODE command. The command should return 00h in the Sector Count field of the command indicating that the device is in Standby mode. The test program then returns the master hard disk drive on the primary ATA channel to the D0 or Active mode issuing a read request to it on the primary ATA channel. The test program checks to see that the master hard disk drive has returned to Active mode by issuing a CHECK POWER MODE command. The command should return FFh in the sector count result value. The above procedure is performed 5 times in succession to validate the correct operation of the Standby Timer functionality.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

For hardware setup, the system must be configured with ATA/ATAPI-4 compliant controllers and devices. These controllers and devices must be capable of supporting bus mastering, ATA/33 and the Overlapped command set. It is permissible to have a CD or DVD drive configured on an ATA channel during the running of this test.

For software setup, the system requires that Windows 2000 (or later) is installed.

Results Interpretation

Individual pass/fail indication is provided for each test category of hard disk drive support for the power management command set.

The following conditions cause test failures:

  • The IDENTIFY DEVICE command indicates that the device does not implement the power management feature set.
  • The CHECK POWER MODE does not indicate that the target device has entered Standby mode.
  • The read access does not return successfully when the drive is in Standby mode.
  • The devices do not return to Active or Standby mode following the software ATA bus reset.
  • The DMA modes are not maintained across power management state transitions.

It is possible for the ATA devices or the software stack to cause a failure to enable the correct operational mode on one or both of the ATA devices.


TD-10.7 ATA/ATAPI CD Drive Media Status Notification Capability Test

Test Kit: HCT 11, HCT 10

Overview

This test insures that ATAPI CD drives properly implement the Media Status Notification functionality as described in ANSI NCITS T10 Multi-Media Command Set-2. The Media Status Notification feature set allows the operating system and application software to control the insertion and ejection of media and be notified of a variety of media state changes. This test moves the CD device through the media status states and verifies that the media can be controlled and status can be obtained on the various supported media events.

Overview of Test Steps

Microsoft Windows Logo Program System and Device Requirements requires that ATAPI CD drives support the GET CONFIGURATION command defined in SFF 8090 or the MMC-2 Specification. CD drives that do not support the GET CONFIGURATION command have their support for the Media Status Notification feature set determined empirically by attempting to use the MESN related commands. The test attempts to determine support for the MMC-2 Media Status Notification feature set by issuing a GET CONFIGURATION command to the device driver. If the CD device supports the GET CONFIGURATION command, it reports this capability in response to the command. Support for Media Status Notification requires that the following capabilities are supported by the CD device:

Feature Number | Feature Name | Description
0002h | Morphing | Ability to notify host about operational changes and accept host requests to prevent operational changes
0003h | Removable Medium | The medium may be removed from the device

The test program uses the polling method of determining media status change. This requires that the test program issue the GET EVENT STATUS NOTIFICATION commands to the device driver on a regular basis. The test program issues the GET EVENT STATUS NOTIFICATION commands at one-second intervals. The polling is done with bits 2 and 4 of the Notification Class Field of the Event Status Header set to 1. This polls for power and media status change events.

The GET EVENT STATUS NOTIFICATION command has the following structure:

Byte | Description
04h | Notification Class Request

The Notification Class Request/Response field has the following structure:

Bit | Description
1000b | Media Class Events

The Media Event Class Returned Data has the following structure:

Byte | Bits | Description
0 | 0:3 | Media Event
0 | 4:7 | Reserved
1 | 0:7 | Media Status
2 | 0:7 | Start Slot
3 | 0:7 | End Slot

The Media Event Format has the following structure:

Code | Event | Description
0h | NoEvent | Media Event
1h | EjectRequest | The logical unit has received a request from the user to eject the specified slot or media
2h | NewMedia | The specified slot has received new media and is ready to access it
3h | MediaRemoval | The media has been removed from the specified slot and the logical unit is unable to access the media without user intervention
4h-Fh | Reserved |

The Media Status Byte has the following structure:

Bit | Description
0h | Door or tray open
1h | Media present
2:7 | Reserved

This test manually transitions the CD drive through the Prevent/Allow states to allow for media insertion and ejection.

The test program instructs the user to insert a CD media into the logical unit and close the door manually. Once this is done, the test program detects that the media has been inserted through a GET EVENT STATUS NOTIFICATION. The return packet should indicate that a media status change has occurred, and that NewMedia has been inserted and there is media present in the logical unit and the door is closed.

Notification Event/Response | Media Event | Media Status Byte
1000b | 02h | 10b

The test program enables media ejection control by issuing a PREVENT MEDIUM REMOVAL command to the device driver with Prevent bit set to 1 to lock the media in the CD drive. This command requests that the CD Logical Unit disable the removal of the medium in the logical unit. The prevention of media removal is accomplished through the use of a Locking Mechanism provided by the CD device and any hardware ejection initiation mechanisms is disabled. The Prevent is used in conjunction with the Get Event Status Notification command, to prevent media from being ejected without control by, or notification to the host software. The test program then issues a media READ command to insure that the media is mounted and accessible to operating system or application programs.

The test program issues a START/STOP UNIT command with the loEj bit set to 1 and Start bit set to 0 requesting that the media be ejected. The command should return with an error of 02 Not Ready, 53 Media Removal Prevented. The test operator then is instructed to press the eject button on the CD drive which signals the drive that a media eject is requested.

The test program, still polling for state changes through GET EVENT STATUS NOTIFICATION should detect the EjectRequest. The return packet should indicate that a media status change has occurred, an EjectRequest has been detected and there is media present in the logical unit and the door is closed.

Notification Event/Response | Media Event | Media Status Byte
1000b | 02h | 10b

At this point, the user is asked to verify that the media eject request has not been serviced (that is,. the door to the CD drive is still closed with the media inside). The test program enables media ejection control by issuing a PREVENT MEDIUM REMOVAL command to the device driver with Prevent bit set to 0 to unlock the media in the CD drive. The user presses a key that signals the test program a START/STOP UNIT command with the loEj bit set to 1 and Start bit set to 0 requesting that the media be ejected. The test program should detect that the media has been ejected through a GET EVENT STATUS NOTIFICATION command. The return packet should indicate that a media status change has occurred, a MediaRemoval has been detected and there is no media present in the logical unit and the door is open.

Notification Event/Response | Media Event | Media Status Byte
1000b | 03h | 01b

The test program forces the loading of the CD media into the logical unit by issuing a START/STOP UNIT command with the loEj bit set to 1 and Start bit set to 1. The test program should detect that the media has been inserted through a GET EVENT STATUS NOTIFICATION command. The return packet should indicate that a media status change has occurred, a NewMedia has been detected and there is media present in the logical unit and the door is closed.

Notification Event/Response | Media Event | Media Status Byte
1000b | 02h | 10b

The test program enables media ejection control by issuing a PREVENT MEDIUM REMOVAL command to the device driver with Prevent bit set to 1 to lock the media in the CD drive. The test program issues a media READ command to insure that the media is mounted and accessible to operating system or application programs. The test program enables media ejection control by issuing a PREVENT MEDIUM REMOVAL command to the device driver with Prevent bit set to 0 to unlock the media in the CD drive. The test program issues a START/STOP UNIT command with the loEj bit set to 1 and Start bit set to 0. The test program should detect that the media has been ejected through a GET EVENT STATUS NOTIFICATION command. The return packet should indicate that a media status change has occurred, a MediaRemoval has been detected and there is no media present in the logical unit and the door is open.

Notification Event/Response | Media Event | Media Status Byte
1000b | 03h | 01b

The test operator is instructed to remove the media from the CD device platter and manually close the CD device door. The test program should not detect any media change through a GET EVENT STATUS NOTIFICATION command. The return packet should indicate that the door is closed and there is no media in the device.

Notification Event/Response | Media Event | Media Status Byte
1000b | 00h | 00b

The MMC-2 specification requires that a device in Standby state provide the proper GET EVENT STATUS notification. The test program places the CD drive on the primary channel from the D0 power management mode into the D1 power management mode that is implemented by the Standby state. This state transfer is initiated by issuing the STANDBY IMMEDIATE command. The test program prompts the test operator to place a CD media into the drive and manually close the door. Once this is done, the test program detects that the media has been inserted through a GET EVENT STATUS NOTIFICATION. The return packet should indicate that a media status change has occurred, NewMedia has been inserted and there is media present in the logical unit and the door is closed.

Notification Event/Response | Media Event | Media Status Byte
1000b | 02h | 10b

The CHECK POWER MODE command is then issued to the CD device on the primary channel to verify that it has stayed in the Standby state. The Sector Count field of the command result should be 00h indicating that the device is in Standby state.

The drive is required to report a NewMedia event on returning from reset processing. The test program prompts the test operator to insert a CD media and manually close the door. The test program transitions the CD drive to the D3 or Sleep state through the issuance of a START/STOP Unit command with the Power Condition bit set to 5h. The test program then transitions the drive into the Standby state by issuing a DEVICE RESET command. The device should detect the media in the drive and notify the host via a GET EVENT STATUS NOTIFICATION command. The return packet should indicate that a media status change has occurred, NewMedia has been inserted and there is media present in the logical unit and the door is closed.

Notification Event/Response | Media Event | Media Status Byte
1000b | 02h | 10b

The test program then issues a media access command to insure that the media is mounted and accessible to operating system or application programs.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

For hardware setup, the system must be configured with ATA/ATAPI-4 compliant controllers and devices and one ATAPI CD or DVD drive. These controllers and devices must be capable of supporting bus mastering and ATA/33. The CD or DVD drive attached to the system must be capable of supporting Ultra DMA mode 2 when configured.

For software setup, the system requires that Windows 2000 (or later) is installed.

Results Interpretation

Individual pass/fail indication is provided for each test category of hard disk drive support for the power management command set.

The following conditions cause test failures:

  • The GET CONFIGURATION command if supported indicates that the CD drive does not implement the MORPHING or REMOVABLE MEDIA feature sets.
  • The PREVENT MEDIUM REMOVAL command completes with a failure code.
  • The GET EVENT STATUS NOTIFICATION command is not supported by the CD drive as evidenced by a failure return code in response to issuance of the command.
  • The GET EVENT STATUS NOTIFICATION command doesn’t indicate that the media has been inserted into the CD device.
  • The device cannot be read from when the media is indicated to have been inserted.
  • The GET EVENT STATUS NOTIFICATION command doesn’t indicate that the media eject button has been pressed.
  • The GET EVENT STATUS NOTIFICATION command doesn’t indicate that the media ejection button has occurred and that there is no media in the CD device.
  • The media does not get loaded into the CD device following the issuance of the START/STOP UNIT command.
  • The device does not indicate NewMedia condition when returning from reset.


TD-10.8 ATA/ATAPI CD Drive Power Management Capability Test

Overview

This test insures that ATAPI CD drives properly implement the power management functionality as described in the Storage Device Class Power Management Reference Specification, Version 1.0 or later. This document requires CD drives to support power states D0, D1 and D3. The D0 power state corresponds to the Active state, the D1 power state corresponds to the Standby state and the D3 power state corresponds to the Sleep state. Management of reduced function/consumption power states is implemented in ATAPI CD drives by the ATA CHECK POWER MANAGEMENT, STANDBY IMMEDIATE and SLEEP commands. The specification does not require that the IDLE state and corresponding commands be implemented so they are not tested. In addition, transitions from D0 to D1, D1 to D3 and the correct reactivation of these devices to D0 from D3 through a DEVICE RESET command is required. Correct reactivation includes returning to the configured operational DMA state, if applicable and other operational modes should remain unchanged from the values set during the previous Active state.

Overview of Test Steps

The test determines support for the power management feature set by issuing an IDENTIFY PACKET DEVICE command to the device driver. The CD device reports its capability to support the power management commands. The power management capabilities are indicated by the following fields:

Word | Bits | Description
82 | 3 | Power Management Feature Set supported
85 | 3 | Power Management Feature Set supported
85 | 9 | DEVICE RESET command supported

After verifying capability and enabled state, the test program disables the reverting to power on defaults during software reset by issuing the appropriate SET FEATURES command. The first run of the test is performed with no media in the drive.

The test program verifies the support for the CHECK POWER MODE command by issuing that command to the drive. The values in the sector count field have the following values:

Value | Description
00h | The device is in Standby mode
80h | The device is in the idle mode
FFh | Device is in active mode

The test program then transitions the CD drive on the primary channel from the D0 power management mode into the D1 power management mode, which is implemented by the Standby state. This state transfer is initiated by issuing the STANDBY IMMEDIATE command. When in the Standby state the device’s interface is functional and can respond to commands but the disk media may be spun down. The CHECK POWER MODE command is then issued to the CD device on the primary channel to verify that it has gone into the Standby state. The Sector Count field of the command result should be 00h indicating that the device is in Standby state.

The test program then transitions the CD on the primary ATA channel from the D1 power management mode into the D3 power management mode, which is implemented by the SLEEP state. This state transfer is initiated by issuing the SLEEP command. In the Sleep state the CD device can only respond to a DEVICE RESET command or hardware reset and the disk media is spun down.

The test program returns the CD drive on the primary ATA channel to the D0 or Active mode by instructing the device driver to issue a DEVICE RESET command to the CD. The test program checks to see that the CD drive has returned to Active mode by issuing a CHECK POWER MODE command. The command should return FFh in the sector count result value. The test program then verifies that the selectable modes have been restored correctly by issuing an IDENTIFY PACKET DEVICE command to the master drive and verifying that the following parameters match those when the device was initially in the Active state:

Word | Bits | Description
63 | 8 9 10 | Multiword DMA mode 0 is selected Multiword DMA mode 1 is selected Multiword DMA mode 2 is selected
88 | 10 9 8 | Ultra DMA mode 2 is selected Ultra DMA mode 1 is selected Ultra DMA mode 0 is selected

The test program then transitions the CD drive on the primary ATA channel from the D0 mode directly into the D3 power management mode, which is implemented by the Sleep state. This state transfer is initiated by issuing the SLEEP command. The test program prompts the test operator to press the eject button on the CD drive. The drive should not respond to this request in the Sleep state. The test program returns the CD drive on the primary ATA channel to the D0 or Active mode by instructing the device driver to issue a DEVICE RESET to the CD device. The test program checks to see that the CD drive has returned to Active mode by issuing a CHECK POWER MODE command. The command should return FFh in the sector count result value. The test program then verifies that the selectable modes have been restored correctly by issuing an IDENTIFY PACKET DEVICE command to the master drive and verifying that the parameters match those when the device was initially in the Active state.

The test program then places the CD drive on the primary channel from the D0 power management mode into the D1 power management mode that is implemented by the Standby state. This state transfer is initiated by issuing the STANDBY IMMEDIATE command. The CHECK POWER MODE command is then issued to the master device on the primary channel to verify that it has gone into the Standby state. The Sector Count field of the command result should be 00h indicating that the device is in Standby mode.

The test program returns the CD drive on the primary ATA channel to the D0 or Active mode by issuing a READ request to it on the primary ATA channel. The test program checks to see that the CD drive has returned to Active mode by the successful return of the READ command followed by issuing a CHECK POWER MODE command. The CHECK POWER MODE command should return FFh in the sector count result value. The test program then verifies that the selectable modes have been restored correctly by issuing an IDENTIFY PACKET DEVICE command to the master drive and verifying that the parameters match those when the device was initially in the Active state.

The Media Event Status Notification of the MMC-2 specification requires that the ATAPI CD drive transition remain in the Standby state when a media has been inserted. The test program transitions the CD drive on the primary ATA channel from the D0 mode directly into the D1 power management mode, which is implemented by the Standby state. This state transfer is initiated by issuing the STANDBY IMMEDIATE command. The test program prompts the test operator to insert a CD media into the drive and manually close the door. A media change should be detected and the drive should stay in the Standby state. The CHECK POWER MODE command is issued to the master device on the primary channel to verify that it has stayed in the Standby state. The Sector Count field of the command result should be 00h indicating that the device is in Standby mode.

The test program issues a STANDBY command with a timeout value of 04h in the sector count register instructing the drive to enter the Standby state in 20 seconds. The test program will check to see that the master hard disk drive is still in the Active mode by issuing a CHECK POWER MODE command. The command should return FFh in the sector count result value. The command must be issued and returned before the 20 second timeout interval has expired. After 30 seconds, allowing the 20 second timer value to expire, the test program issues a CHECK POWER MODE command. The command should return 00h in the Sector Count field of the command indicating that the device is in Standby mode. The test program then returns the CD drive on the primary ATA channel to the D0 or Active mode issuing a read request to it on the primary ATA channel. The test program checks to see that the master hard disk drive has returned to Active mode by issuing a CHECK POWER MODE command. The command should return FFh in the sector count result value. The above procedure is performed 5 times in succession to validate the correct operation of the Standby Timer functionality.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

For hardware setup, the system must be configured with ATA/ATAPI-4 compliant controllers and devices and one CD or DVD drive. The hard disk drives must be capable of supporting bus mastering and Ultra DMA/33. The CD or DVD drive attached to the system must be capable of tolerating Ultra DMA mode 2 when configured.

For software setup, the system requires that Windows 2000 (or later) is installed.

Results Interpretation

Individual pass/fail indication is provided for each test category of hard disk drive support for the power management command set.

The following conditions cause test failures:

  • The IDENTIFY DEVICE command indicates that the CD does not implement the power management feature set
  • CHECK POWER MODE does not indicate that the CD has entered Standby mode
  • The read access does not return successfully when the CD is in Standby mode
  • The CD does not return to Active mode following the software ATA bus reset
  • CHECK POWER MODE does not indicate that the CD has entered Sleep mode
  • The CD does not return to Active mode following the DEVICE RESET command
  • The mode parameters are not maintained across any power management state transitions
  • The CD does not remain in the Standby state upon media insertion

It is possible for the ATA devices or the software stack to be the cause of a failure to enable the correct operational mode on one or both of the ATA devices.


TD-10.9 ATA/ATAPI DVD Media Status Notification Capability Test

Test Kit: HCT 11, HCT 10

Overview

This test insures that DVD drives properly implement the Media Status Notification functionality as described in ANSI NCITS T10 Multi-Media Command Set-2. The Media Status Notification feature set allows the operating system and application software to control the insertion and ejection of media and be notified of a variety of media state changes. This test moves the DVD device through the media status states and verifies that the media can be controlled and status can be obtained on the various supported media events.

Overview of Test Steps

The test determines support for the MMC-2 Media Status Notification feature set by issuing a GET CONFIGURATION command to the device driver. The DVD device reports its capability to support the Media Status Notification commands. Support for Media Status Notification requires that the following capabilities be supported by the DVD device:

Feature Number | Feature Name | Description
0002h | Morphing | Ability to notify host about operational changes and accept host requests to prevent operational changes.
0003h | Removable Medium | The medium may be removed from the device

The test program uses the polling method of determining media status change. This requires that the test program issue GET EVENT STATUS NOTIFICATION commands to the device driver on a regular basis. The test program issues GET EVENT STATUS NOTIFICATION commands every 1 second. The polling is done with bits 2 and 4 of the Notification Class Field of the Event Status Header set to 1. This poll for power and media status change events.

The GET EVENT STATUS NOTIFICATION command has the following structure:

Byte | Description
04h | Notification Class Request

The Notification Class Request/Response field has the following structure:

Bit | Description
0100b | Power Management Class Events
1000b | Media Class Events

The Media Event Class Returned Data has the following structure:

Byte | Bits | Description
0 | 0:3 | Media Event
0 | 4:7 | Reserved
1 | 0:7 | Media Status
2 | 0:7 | Start Slot
3 | 0:7 | End Slot

The Media Event Format has the following structure:

Code | Event | Description
0h | NoEvent | Media Event
1h | EjectRequest | The logical unit has received a request from the user to eject the specified slot or media
2h | NewMedia | The specified slot has received new media and is ready to access it
3h | MediaRemoval | The media has been removed from the specified slot and the logical unit is unable to access the media without user intervention
4h-Fh | Reserved |

The Media Status Byte has the following structure:

Bit | Description
0h | Door or tray open
1h | Media present
2:7 | Reserved

The test program enables media control by issuing a PREVENT MEDIUM REMOVAL command to the device driver with Prevent bit set to 1 and Persistent bit set to 1. This command requests that the DVD Logical Unit disable the removal of the medium in the logical unit. The prevention of media removal shall be accomplished through the use of a Locking Mechanism provided by the DVD device and any hardware ejection initiation mechanisms is disabled. The PREVENT operation issued is persistent and the prevent condition will not reset when media is removed or inserted. This allows new media to become captive without host interaction. The persistent prevent status allows eject requests from the host to succeed. The Persistent Prevent is used in conjunction with the Get Event Status Notification command to prevent media from being ejected without control by or notification to the host software.

The test program instructs the user to insert a DVD media into the logical unit and close the door manually. Once this is done, the test program detects that the media has been inserted through a GET EVENT STATUS NOTIFICATION. The return packet should indicate that a media status change has occurred; NewMedia has been inserted and there is media present in the logical unit and the door is closed.

Notification Event/Response | Media Event | Media Status Byte
1000b | 02h | 10b

The test program then issues a media access command to insure that the media is mounted and accessible to operating system or application programs.

The test operator is then instructed to press the eject button on the DVD drive. The test program is still polling for state changes through GET EVENT STATUS NOTIFICATION. The return packet should indicate that a media status change has occurred; an EjectRequest has been detected and there is media present in the logical unit and the door is closed.

Notification Event/Response | Media Event | Media Status Byte
1000b | 02h | 10b

At this point, the user is asked to verify that the media eject request has not been serviced (that is the door to the DVD drive is still closed with the media inside). The media eject should not occur until the test program issues a command to cause the unload. The user presses a key that signals the test program to issue a START/STOP UNIT command with the LoEj bit set to 1 and the Start bit set to 0 which requests the drive to eject the media.

The test program should detect that the media has been ejected through a GET EVENT STATUS NOTIFICATION. The return packet should indicate that a media status change has occurred, a MediaRemoval has been detected and there is no media present in the logical unit and the door is open.

Notification Event/Response | Media Event | Media Status Byte
1000b | 03h | 01b

The test program forces the loading of the DVD media into the logical unit by a START/STOP UNIT command with the LoEj bit set to 1 and the Start bit set to 1 which requests the drive to load the media. The test program should detect that the media has been inserted through a GET EVENT STATUS NOTIFICATION. The return packet should indicate that a media status change has occurred; a NewMedia has been detected and there is media present in the logical unit and the door is closed.

Notification Event/Response | Media Event | Media Status Byte
1000b | 02h | 10b

The test program issues a media access command to insure that the media is mounted and accessible to operating system or application programs.

The test program forces the unloading of the DVD media from the logical unit by a START/STOP UNIT command with the LoEj bit set to 1 and the Start bit set to 0 which will request the drive to eject the media. The test program should detect that the media has been ejected through a GET EVENT STATUS NOTIFICATION. The return packet should indicate that a media status change has occurred; a MediaRemoval has been detected and there is no media present in the logical unit and the door is open.

Notification Event/Response | Media Event | Media Status Byte
1000b | 03h | 01b

The test operator is instructed to remove the media from the DVD device platter and manually close the DVD device door. The test program should not detect any media change through a GET EVENT STATUS NOTIFICATION. The return packet should indicate that the door is closed and there is no media in the device.

Notification Event/Response | Media Event | Media Status Byte
1000b | 00h | 00b

The drive is required to report a NewMedia event on returning from reset. The test program prompts the test operator to insert a DVD media and manually close the door. The test program transitions the DVD drive to the D3 or Sleep state through the issuance of a START/STOP Unit command with the Power Condition bit set to 5h. The test program transitions the drive into the Standby state by issuing a DEVICE RESET command. The device should detect the media in the drive and notify the host via a GET EVENT STATUS NOTIFICATION. The return packet should indicate that a media status change has occurred; NewMedia has been inserted and there is media present in the logical unit and the door is closed.

Notification Event/Response | Media Event | Media Status Byte
1000b | 02h | 10b

The test program issues a media access command to insure that the media is mounted and accessible to operating system or application programs.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

For hardware setup, the system must be configured with ATA/ATAPI-4 compliant controllers and devices and one ATAPI DVD drive. The hard disk drive must be capable of supporting bus mastering and ATA/33.

For software setup, the system requires that Windows 2000 (or later) is installed.

Results Interpretation

Individual pass/fail indication is provided for each test category of hard disk drive support for the power management command set.

The following conditions cause test failures:

  • The GET CONFIGURATION command indicates that the DVD drive does not implement the MORPHING or REMOVABLE MEDIA feature sets.
  • The PREVENT MEDIUM REMOVAL command completes with a failure code.
  • The GET EVENT STATUS NOTIFICATION doesn’t indicate that the media has been inserted into the DVD device.
  • The device cannot be read from when the media is indicated to have been inserted.
  • The GET EVENT STATUS NOTIFICATION doesn’t indicate that the media eject button has been pressed.
  • The GET EVENT STATUS NOTIFICATION doesn’t indicate that the media ejection button has occurred and that there is no media in the DVD device.
  • The media is not loaded into the DVD device following the issuance of the START/STOP UNIT command.
  • The DVD device does not indicate NewMedia condition on returning from DEVICE RESET.


TD-10.10 ATA/ATAPI DVD Drive Power Management Capability Test

Overview

This test insures that DVD drives properly implement the power management functionality as described in the Storage Device Class Power Management Reference Specification, Version 1.0 or later. This document requires that ATAPI DVD drives support power states D0, D1 and D3. The reduced function/consumption power states are implemented in DVD drives by the Active, Standby and Sleep states. The START/STOP Unit ATAPI command is used to control transitions between the power management states. In addition, transitions from D0 to D1, D1 to D3 and the correct reactivation of these devices to D0 from D3 through a DEVICE RESET command is required. Correct reactivation includes returning to the previous operational DMA state and other operational modes should remain unchanged from the values set during the previous Active state.

Overview of Test Steps

The test determines support for the power management feature set by issuing a GET CONFIGURATION command to the device driver. The DVD device reports its capability to support the power management commands. The DVD device is required to support the power management states. The power management capabilities are assessed by examining the following fields returned in the Power Management field (word 100h) in the response data:

Byte | Description
0-1 | 0100h
2:0 | Current: must be 1
2:1 | Persistent: must be 1
3:0-5 | Additional length: must be 0

The test program uses the polling method of determining media status change. This requires that the test program issue GET EVENT STATUS NOTIFICATION commands to the device driver on a regular basis. The test program issues GET EVENT STATUS NOTIFICATION commands every 1 second. The polling is done with bits 2 and 4 of the Notification Class Field of the Event Status Header set to 1. This polls for power and media status change events.

The GET EVENT STATUS NOTIFICATION command has the following structure:

Byte | Description
04h | Notification Class Request

The Notification Class Request/Response field has the following structure:

Bit | Description
0100b | Power Management Class Events
1000b | Media Class Events

The Power Management Class Returned Data has the following structure:

Byte | Bits | Description
0 | 0:3 | Power Event
0 | 4:7 | Reserved
1 | 0:7 | Power Status

The Power Event Format has the following structure:

Code | Event | Description
0h | NoChange | No changes in power state or in power state transition
1h | PowerChangeSuccessful | The logical unit successfully changed to the specified power state
2h | PowerChangeFailed | The logical unit failed to enter the last requested state and is still operating at the power state specified in the power status field
3h-Fh | Reserved |

The Power Status Byte has the following structure:

Bit | Description
0h | Reserved
1h | The logical unit is in the active state
2h | The logical unit is in the Idle state
3h | The logical unit is in the Standby state
4h:Fh | Reserved

After verifying the correctness of the capability bits, the test program disables the Idle state timer and enables the Standby mode timer to 10 seconds through the issuance of a MODE SELECT command. The MODE SELECT command alters the power condition page to have the Idle field set to 0, the Standby field set to 1 and the Standby Timer field set to 50. A START/STOP UNIT command with the Power Condition field set to 3h is issued to place the drive into the Standby state. The test program should detect that the power state has been changed through a GET EVENT STATUS NOTIFICATION. The return packet should indicate that a power status change has occurred and the current power state is Standby.

Notification Event/Response | Power Event | Power Status Byte
1000b | 01h | 3h

The test program then transitions the DVD drive on the primary channel from the D1 power management mode into the D3 power management mode, which is implemented by the Sleep state. This state transfer is initiated by issuing Power Condition field set to 5h. In the Sleep state, the device’s interface is not functional and can only be reactivated by a DEVICE RESET or bus reset command. The program will not receive a power status change notification on this state transition since the DVD command interface is not functional.

The test program returns the DVD drive on the primary ATA channel to the D1 or Standby mode by instructing the device driver to issue a DEVICE RESET command to the DVD. Once the command returns, the test program should detect that the device has transitioned to the Standby state through a GET EVENT STATUS NOTIFICATION. The return packet should indicate that the power management state has successfully changed to the Standby state.

Notification Event/Response | Power Event | Power Status Byte
0100b | 01h | 3h

The test program then verifies that the selectable modes have been restored correctly by issuing an ATAPI IDENTIFY DEVICE command to the master drive and verifying that the parameters match those when the device was initially in the Active state. The previously active DMA state must also be restored.

The test program then transitions the DVD drive on the primary ATA channel from the D0 mode directly into the D3 power management mode, which is implemented by the SLEEP state. This state transfer is initiated by issuing Power Condition field set to 5h. The test program returns the DVD drive on the primary ATA channel to the D0 or Active mode by instructing the device driver to issue a DEVICE RESET to the DVD device. Once the command returns, the test program should detect that the device has transitioned to the Standby state through a GET EVENT STATUS NOTIFICATION. The return packet should indicate that the power management state has successfully changed to the Standby state.

Notification Event/Response | Power Event | Power Status Byte
0100b | 01h | 3h

The test program then verifies that the selectable modes have been restored correctly by issuing an ATAPI IDENTIFY DEVICE command to the master drive and verifying that the parameters match those when the device was initially in the Active state.

The test program returns the CD drive on the primary ATA channel to the D0 or Active mode by issuing a READ request to it on the primary ATA channel. The test program checks to see that the CD drive has returned to Active mode through a GET EVENT STATUS NOTIFICATION. The return packet should indicate that a power status change has occurred and the current power state is Active.

Notification Event/Response | Power Event | Power Status Byte
1000b | 01h | 1h

The test program issues a START/STOP UNIT command with the Power Condition field set to 3h to place the drive into the Standby state. The test program should detect that the power state has been changed through a GET EVENT STATUS NOTIFICATION. The return packet should indicate that a power status change has occurred and the current power state is Standby.

Notification Event/Response | Power Event | Power Status Byte
1000b | 01h | 3h

The test program prompts the test operator to insert a DVD media into the drive. This results in a media event indicating the presence of a NewMedia, but there should be no power status notification and the drive should remain in Standby state as indicated by the power status field.

Notification Event/Response | Power Event | Power Status Byte
1000b | 01h | 3h

The test program accesses the DVD media with a READ command, which should result in the drive transitioning to the Active state. A GET EVENT STATUS NOTIFICATION return packet should indicate that a power status change has occurred and the current power state is Active.

Notification Event/Response | Power Event | Power Status Byte
1000b | 01h | 1h

The test program issues no commands to the DVD drive except for the GET EVENT STATUS NOTIFICATION commands that continues to be issued at 1 second intervals. Within 10 seconds of ceasing drive access commands, the test program should detect a power state transition into the Standby mode via the GET EVENT STATUS NOTIFICATION command. The timeout interval for Standby state was set earlier by the test program to 5 seconds.

Notification Event/Response | Power Event | Power Status Byte
1000b | 01h | 3h

The test program returns the CD drive on the primary ATA channel to the D0 or Active mode by issuing a READ request to it on the primary ATA channel. The test program checks to see that the CD drive has returned to Active mode through a GET EVENT STATUS NOTIFICATION. The return packet should indicate that a power status change has occurred and the current power state is Active.

Notification Event/Response | Power Event | Power Status Byte
1000b | 01h | 1h

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

For hardware setup, the system must be configured with ATA/ATAPI-4 compliant controllers and devices and one DVD drive.

For software setup, the system requires that Windows 2000 (or later) is installed.

Results Interpretation

Individual pass/fail indication is provided for each test category of hard disk drive support for the power management command set.

The following conditions cause test failures:

  • The IDENTIFY DEVICE command indicates that the DVD does not implement the power management feature set
  • CHECK POWER MODE does not indicate that the DVD has entered STANDBY mode
  • The read access does not return successfully when the DVD is in STANDBY mode
  • The DVD does not return to ACTIVE mode following the software ATA bus reset
  • The DVD does not return to ACTIVE mode following the DEVICE RESET command
  • The mode parameters are not maintained across any power management state transitions
  • The DMA state is not maintained across any power management state transitions

It is possible for the ATA devices or the software stack to be the cause of a failure to enable the correct operational mode on one or both of the ATA devices.


TD-10.11 ATA/ATAPI DVD Bus Master DMA Capability Test

Overview

This test determines whether a DVD device supports bus master DMA data transfers. Bus mastering allows the DVD device to efficiently transfer data over the system bus without using processor bandwidth.

A controller compliant with ATA/ATAPI-4 supports the following status bit in the Class Code:

Bit | Description
7:0 | Programming Interface (PI). 80h=Capable of IDE bus master operation

A controller compliant with ATA/ATAPI-4 supports the following status bits in the Bus Master Status register:

Bit | Description
6 | Drive 1 DMA Capable: This read/write bit is set by device dependent code (BIOS or device driver) to indicate that drive 1 for this channel is capable of DMA transfers and that the controller has been initialized for optimum performance.
5 | Drive 0 DMA Capable: This read/write bit is set by device dependent code (BIOS or device driver) to indicate that drive 1 for this channel is capable of DMA transfers and that the controller has been initialized for optimum performance.

After the system is booted to Windows 2000 the test program interrogates the status of the ATA controller by using a query interface to the disk device driver to determine whether DMA transfers are enabled. The DVD device is then queried to determine whether it is currently configured to utilize DMA transfers.

Overview of Test Steps

The test program queries the disk device driver that is responsible for the operation of the ATA controllers to determine controller and device capabilities and configuration. At the time of the invocation of the test program, the device driver has fully initialized the ATA controller and is fully capable of access to both disk drives. The test program passes a request to the device driver to return the status of the two sets of bits as described above. The test then interprets the bits to determine whether bus master operations are supported and that the device driver has successfully enabled the DVD device for bus master DMA transfers.

The test determines the currently configured transfer mode for DVD device by issuing an IDENTIFY PACKET DEVICE command to the device driver. Each device reports its transfer mode configuration in the response packet. The transfer mode configuration is assessed by examining the following fields:

Word | Bits | Description
49 | 8 | DMA supported
63 | 0 | Multiword DMA mode 0 is supported
63 | 1 | Multiword DMA mode 1 and below is supported
63 | 2 | Multiword DMA mode 2 and below is supported
63 | 8 | Multiword DMA mode 0 is selected
63 | 9 | Multiword DMA mode 1 is selected
63 | 10 | Multiword DMA mode 2 is selected

The test program verifies that the controller and the DVD device are capable and configured for DMA operation. This is done by examining word 49 bit 8 and verifying that the DVD device supports and is configured to use one of the DMA modes.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The system must be configured with ATA/ATAPI-4 compliant controllers and devices. Any drives must be capable of supporting bus mastering and ATA/33 which is also known as Ultra DMA mode 2.

For software setup, the system requires that Windows 2000 (or later) is installed.

Results Interpretation

Individual pass/fail indication is provided for each test category of controller independent access provided and device DMA mode successfully enabled.

The following conditions cause test failures:

  • ATA controller does not support bus mastering as reflected in the class code register.
  • ATA hard disk drive is not successfully configured for DMA transfers.
  • ATAPI DVD device is not successfully configured for DMA transfers.

The following advisory information is provided as applicable:

  • Content of bits [7:0] in class code register.
  • Content of status bit 7 in bus master status register.
  • Content of status bit 6 in bus master status register.
  • Content of status bit 5 in bus master status register.
  • Content of word 49 in Identify Packet Device results.
  • Content of word 63 in Identify Packet Device results.

It is possible for the ATA devices or the software stack to be the cause of a failure to enable DMA on an ATA channel. Bits 5 and 6 of the bus master status register are under control of the device driver and reflect the result of the driver’s efforts to enable DMA on each of the channels. If the bits are not set, this test is not capable of determining whether the device or controller is at fault. It is assumed that the devices attached to the system have been verified to operate correctly in DMA mode and that failure to enable DMA mode is indicative of a problem within the controller.


TD-10.12 Ultra DMA Capability Test

Merged into 10.2.


TD-10.13 ATAPI-5 Capability Test

Overview

The AT Attachment with Packet Interface Extension -5 standard (ATA/ATAPI-5) specifies the AT Attachment Interface between host systems and storage devices. It provides a common attachment interface for systems manufacturers, system integrators, software suppliers, and suppliers of intelligent storage devices. It includes the Packet Command feature set implemented by devices commonly known as ATAPI devices.

The ATAPI-5 Capability Test verifies that ATA controllers and devices are compliant with the ATA/ATAPI-5 standard. The test program interrogates the status of the ATA controller by using the query interface to the disk device driver to examine the running state of the device driver and controller. The test program then queries the status of the devices to verify that they are compliant with ATA/ATAPI-5. The test determines the major version number supported by the device by issuing an IDENTIFY DEVICE. Each device reports its major version number in the response packet. The major version number is assessed by examining the following field:

Word | Value | Description
80 | 0000h | Device does not report version number
80 | FFFFh | Device does not report version number
80 | Bit 5 = 1 | Supports ATA/ATAPI-5

The data structure returned by the device includes in it a field that reports the device’s ATA/ATAPI-5 standard revision level supported by the device. This bit field is encoded in word 80 of the returned data structure, if the field is reported (not 0x0000 or 0xFFFF). If reported, bit 5 must be set to indicate compliance with the ATA/ATAPI-5 standard.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The system must be configured with ATA/ATAPI-5 compliant controllers and peripherals.

For software setup, the system requires that Windows 2000 (or later) is installed.

Results Interpretation

Individual pass/fail indication is provided for each test category of controller and device. The test transcribes all results to a text based log file.

The test fails if:

  • An ATA controller reports a supported version, but not ATA/ATAPI-5.
  • An ATA device reports a supported version, but not ATA/ATAPI-5.

The test aborts if:

  • No ATA controller or device is present in this system.
  • An ATA controller, device or the software stack fails to query an ATA device.

The following advisory information is provided as applicable:

  • ATA controller supported standard.
  • ATA device supported standard.


TD-10.14 MMC-2 Capability Test

Overview

The SCSI Multimedia Commands - 2 standard (MMC-2) defines the SCSI command set extensions to access multimedia features for all classes of SCSI devices. The applicable clauses of the standard when used in conjunction with the SCSI Primary Commands specification, SCSI Block Commands, and other applicable command set documents, define the full standard set of commands available for that device in the SCSI environment.

The MMC-2 Capability Test verifies that CD and DVD drives are compliant with the MMC-2 standard. The test program interrogates the status of the ATA devices by using the query interface to the CD or DVD device driver to examine the running state of the device driver and the device. The test program then queries the status of the devices to verify that they are compliant with MMC-2. The test determines the version descriptors supported by the device by issuing an INQUIRY command, as outlined in the SCSI Primary Commands - 2 standard (SPC-2). Each device reports up to eight standards to which the device claims conformance, starting at byte 58 through byte 72. One of the relevant standards the device reports it complies with must correspond to the appropriate MMC-2 version descriptor. The version descriptor is tested by looking for either of the documented version descriptor values:

Value | Standard
0240h | MMC-2 (no version claimed)
0255h | MMC-2 T10/1228 revision 11

In addition, support for the READ CD-DA command as defined in the MMC-2 standard is required. The CD Capabilities and Mechanical Status Page contains the "CD-DA Commands Supported" bit and the "CD-DA Stream is Accurate" bit. Both values are tested by examining the following two bits:

Byte | Bit | Description
5 | 0 | CD-DA Commands Supported
5 | 1 | CD-DA Stream is Accurate

Both bits must be set and their functionality must be implemented.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The system must have one or more CD or DVD drives installed. These drives must comply with MMC-2.

For software setup, the system requires that Windows 2000 (or later) is installed.

Results Interpretation

Individual pass/fail indication is provided for each CD or DVD drive. The test transcribes all results to a text based log file.

The test fails if:

  • A CD or DVD drive does not support MMC-2.
  • A CD or DVD drive does not support the "CD-DA Commands Supported" bit.
  • A CD or DVD drive does not support the "CD-DA Stream is Accurate" bit.

The test aborts if:

  • No ATA controller or device is present in this system.
  • An ATA controller, device or the software stack fails to query an ATA device.

The following advisory information is provided as applicable:

  • CD or DVD drive displays the "CD-DA Commands Supported" and the "CD-DA Stream is Accurate" bits.


TD-10.15 Push-To-Close Test

[NOT TESTED]


TD-10.16 Ultra DMA Performance Test

Merged into 10.3.


TD-10.17 ATAPI-5 Compliance Test

Overview

The AT Attachment with Packet Interface Extension -5 standard (ATA/ATAPI-5) specifies the AT Attachment Interface between host systems and storage devices. It provides a common attachment interface for systems manufacturers, system integrators, software suppliers, and suppliers of intelligent storage devices. It includes the Packet Command feature set implemented by devices commonly known as ATAPI devices.

This Windows Logo Program requirement is not easily testable since it would essentially require testing the device for compliance against a specification of several hundred pages. Initial compliance of devices for ATA/ATAPI-5 can be measured by testing a specific subset of commands for all devices implementing the PACKET command feature set:

Code | Command
08h | DEVICE RESET
E2h | STANDBY
90h | EXECUTE DEVICE DIAGNOSTIC
E7h | FLUSH CACHE
ECh | IDENTIFY DEVICE
A1h | IDENTIFY PACKET DEVICE
00h | NOP
A0h | PACKET
20h | READ SECTOR(S)
EFh | SET FEATURES

The ATAPI-5 Compliance Test verifies that devices are compliant with the ATA/ATAPI 5 standard. Each command is executed and compared to a known expected result.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The system must be configured with ATA/ATAPI-5 compliant controllers and peripherals.

For software setup, the system requires that Windows 2000 (or later) is installed.

Results Interpretation

Individual pass/fail indication is provided for each test category of controller and device. The test transcribes all results to a text based log file.

The test fails if:

  • A device does not support an ATA/ATAPI-5 command.

The test aborts if:

  • No ATA controller or device is present in this system.
  • An ATA controller, device or the software stack fails to query an ATA device.

The following advisory information is provided as applicable:

  • CD or DVD drive displays the actual and expected behavior for the ATA/ATAPI-5 command.


TD-10.18 MMC-2 Compliance Test

Overview

The SCSI Multimedia Commands - 2 standard (MMC-2) defines the SCSI command set extensions to access multimedia features for all classes of SCSI devices. The applicable clauses of the standard when used in conjunction with the SCSI Primary Commands specification, SCSI Block Commands, and other applicable command set documents, define the full standard set of commands available for that device in the SCSI environment.

This Windows Logo Program requirement is not easily testable since it would essentially require testing the CD or DVD drives for compliance against a specification of several hundred pages. Initial compliance of devices for MMC-2 can be measured by testing a specific subset of commands:

Code | Command
BEh | Read CD
B9h | Read CD MSF
43h | Read TOC
4Bh | Pause / Resume
E5h | Check power mode
90h | Execute device diagnostic
E1h | Idle immediately
00h | NOP
08h | Device reset
A0h | Packet
A1h | Identify packet device
EFh | Set features
E6h | Sleep
E0h | Standby immediate

The MMC-2 Compliance Test verifies that CD and DVD drives are compliant with the MMC-2 standard. Each command is executed and compared to a known expected result.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The system must have one or more CD or DVD drives installed. These drives must comply with MMC-2.

For software setup, the system requires that Windows 2000 (or later) is installed.

Results Interpretation

Individual pass/fail indication is provided for each CD or DVD drive. The test transcribes all results to a text based log file.

The test fails if:

  • A CD or DVD drive does not support an MMC-2 command.

The test aborts if:

  • No ATA controller or device is present in this system.
  • An ATA controller, device or the software stack fails to query an ATA device.

The following advisory information is provided as applicable:

  • CD or DVD drive displays the actual and expected behavior for the MMC-2 command.


Chapter 11: Speech Input “Application Readiness” Test Specification

WHQL Test Specification

Previous Next

Chapter 11: Speech Input "Application Readiness" Test Specification

This test specification focuses on the subset of platform hardware requirements and recommendations defined within Microsoft Windows Logo Program System and Device Requirements that relate specifically to speech input "Application Readiness."

In general, requirements on either the system or peripheral side that are either verifiable by visual inspection or are fully characterized by the system manufacturer’s subsystem providers are implemented as checklists.

Also, all speech input related recommended features are implemented as checklists. A recommended feature is not required, but can be used by a system manufacturer to promote a product value-add differentiation for their customers.

Test Coverage

The test assertions detailed in this test specification are based on these Audio requirements. Also, supporting information for this specification was derived from Personal Computer Audio Quality Measurements, Dr. Steven Harris and Cliff Sanchez, Crystal Semiconductor and Audio Codec 97 (AC ’97) Specification, Revision 2.1, Intel Corporation.

Test Methodology

All speech input tests are designed to run on all IA-32 processor-based platforms. No dependencies on core logic chipset implementation are presently known.

The test methodology and description for each testable assertion can be found in the Audio Test Specification, Chapter 11. The test assertions listed here index the appropriate sections in the Audio Test chapter.

Test Assertions

For a summary of current speech input requirements, see Table 11.1.

Speech Input assertions that address the requirements are classified into the following categories:

Audio Subsystem Host Interface

  • The audio subsystem host interface category includes assertions to verify:
  • ISA bus is not used for the host interface.
  • No Sound Blaster legacy hardware is used when running Microsoft Windows.
  • Host supports 16 bit stereo PCM sample resolution at required sample rates of 48Kss and 44.1Kss.
  • Host supports Full Duplex operation with simultaneous independent record and play sample rates.

Microphone Input Electrical / Mechanical Attributes

  • The microphone input electrical/mechanical attributes category includes assertions to verify:
  • A compatible mechanical input jack is used.
  • The AC impedance of the jack is matched to microphone peripheral.
  • A programmable microphone boost amplifier is supported.
  • The microphone input circuit can operate with electret microphone peripherals.

Voice Codec Input Performance

  • The voice codec input performance category includes assertions to verify that the audio performance meets the minimum requirements for
  • Frequency Response
  • Dynamic Range
  • Total Harmonic Distortion
  • Sample capture accuracy

Microphone Peripheral Electrical / Mechanical Attributes

  • The microphone peripheral electrical/mechanical attributes category includes assertions to verify:
  • Microphone peripheral electrically and mechanically mates to the system correctly.
  • Microphone peripheral is designed for positioning with respect to the speaker for optimum results.

Table 11a. Speech Input "Application Readiness" Requirements

WLP# | Requirement Description | Test / Checklist
 | Host System Interface |
A1.4.3 | No ISA Bus host interface | Checklist
11.1.2 | No SoundBlaster Legacy Hardware under Windows OS | Checklist
11.1.3 | Full Duplex Codec Operation. | Test
11.1.4 | Support for 48 Kss sample capture rate | Test
11.1.5 | Support for 44.1 Kss sample capture rate | Test
11.1.6 | Simultaneous independent Capture/Playback sample rates | Test
 | Audio Codec ADC (capture) Performance |
11.2.1 | Full Scale Input Voltage test to ensure that full scale digital value is not reached until Vin ( 100 mV (VRMS) | Test
11.2.2 | Mic ADC Frequency Response | Test
11.2.3 | Mic ADC Dynamic Range | Test
11.2.4 | Mic ADC Total Harmonic plus Noise. | Test
11.2.5 | Mic ADC Sample Capture Accuracy. | Test
 | System Microphone Input |
11.3.1 | 3 conductor 3.5 mm mini-jack | Checklist
11.3.2 | Tip/Ring/Sleeve mechanical configuration | Checklist
11.3.3 | Voice input on Tip | Checklist
11.3.4 | Electret bias on Ring | Checklist
11.3.5 | Sleeve connected to ground | Checklist
11.3.6 | 4K( min. impedance (Tip to ground) | Checklist
11.3.7 | Programmable pre-amp microphone boost | Checklist
11.3.8 | 2 K( min. impedance (Vbias source to ring) | Checklist
11.3.9 | AC coupled Tip | Checklist

Table 11b lists the current Speech Input Recommendations.

Table 11b. Speech Input "Application Readiness" Recommendations

# | Speech Input Requirement Description | Test / Checklist
 | Host System Interface |
1 | Support for 32 Kss sample capture rate | Test
2 | Support for 32 Kss sample capture rate | Test
3 | Support for 22.05 Kss sample capture rate | Test
4 | Support for 16 Kss sample capture rate | Test
5 | Support for 11.025 Kss sample capture rate | Test
6 | Support for 8 Kss sample capture rate | Test
 | Microphone Peripheral Electrical / Mechanical |
7 | Physical positioning of microphone within 1.5" of corner of speaker’s mouth, for close-speaking headset designs | Checklist
8 | 3 conductor 3.5mm mini-plug | Checklist
9 | Tip/Ring/Sleeve mechanical configuration | Checklist
10 | Audio output on Tip | Checklist
11 | Vbias input on Ring of 2-5V DC for electret microphones | Checklist
12 | Sleeve connects to Ground | Checklist

The assertions listed in this section are referenced to the document from which they were derived.

The tests for the functional requirements are described in the "Test Descriptions" section. The descriptions include an overview of each test, instructions for hardware and software setup, test execution, and test results.


Speech Input Test Assertions

Reference Document Sources for Speech Input Assertions

Functional requirements specified in the following documents:

Audio Codec ’97, Revision 2.1

http://developer.intel.com/ial/scalableplatforms/audio/index.htm

Microsoft Windows Logo Program System and Device Requirements, Version 2.0

http://www.microsoft.com/hwdev/winlogo/
(listed as "WLP#" in these assertions)

Microsoft Windows Driver Development Kit

http://www.microsoft.com/ddk/

PC 2001 System Design Guide and PC 99 System Design Guide

http://www.microsoft.com/hwdev/platform/pcdesign/desguide/pcguides.asp

Personal Computer Audio Quality Measurements

http://www.cirrus.com/design/products/pubs/


Speech Input Audio Subsystem Host Interface Assertions

The following audio subsystem host interface assertions are tested with TD-11.1 Host System Audio Control Interface Test (Checklist), TD-16.6 Audio Full Duplex Test (FDuplex), and TD-16.8 Audio PC 99 Audio Device Test (PC99Aud).

11.1.1 No ISA Bus host interface.

The audio subsystem must not be attached to the system via an ISA Bus interface. PCI and USB are acceptable bus attachments for PC 99 audio.
Reference document: WLP# - A1.4.3; PC 2001 System Design Guide - SYS-0041,
PC 99 System Design Guide - 17.2.
Test description: TD-11.1 Host System Audio Control Interface Test (Checklist)

11.1.2 No Sound Blaster legacy hardware under Windows operating system.

This requirement precludes the use of 8237 DMA channels, ISA IRQ, FM synthesis circuitry, and SB control registers. It is acceptable to include Sound Blaster legacy hardware for applications running under real mode DOS, however this hardware must not present problems when running Sound Blaster emulation under the Windows operating system.
Reference documents: WLP# - B3.1.4.1; PC 2001 System Design Guide - AUD-0322,
PC 99 System Design Guide - 17.3.
Test description: TD-11.1 Host System Audio Control Interface Test (Checklist)

11.1.3 Full Duplex Codec Operation.

The audio subsystem must be capable of simultaneously playing and recording audio.
Reference documents: WLP# - B3.1.4.2; PC 2001 System Design Guide - AUD-0325,
PC 99 System Design Guide - 17.5 and WLP# - ; PC 2001 Test Specification, Test Assertions 16.15.x.
Test description: TD-16.6 Audio Full Duplex Test (FDuplex)

11.1.4 Audio hardware must provide support for the 48 Kss sample capture rate.

Reference document: WLP# - B3.1.4.2; PC 2001 System Design Guide - AUD-0324; PC 99 System Design Guide - 17.5.2, Test Assertion 16.31.9.
Test description: TD-16.8 Audio PC 99 Audio Device Test (PC99Aud)

11.1.5 Audio hardware must provide support for the 44.1 Kss sample capture rate.

Reference document: WLP# - B3.1.4.2; PC 2001 System Design Guide - AUD-0324; PC 99 System Design Guide - 17.5.2; Test Assertion 16.31.8.
Test description: TD-16.8 Audio PC 99 Audio Device Test (PC99Aud)

11.1.6 Simultaneous independent Capture/Playback sample rates.

The audio subsystem must be capable of simultaneous playback and record at any combination of supported sample rates.
Reference documents: WLP# - B3.1.4.2; PC 2001 System Design Guide - AUD-0325,
PC 99 System Design Guide - 17.6; Test Assertions 16.31.14 and 16.31.15.
Test description: TD-16.8 Audio PC 99 Audio Device Test (PC99Aud)

11.1.7 Support for the 32 Kss sample capture rate.

(This is a hardware recommendation only.)
Reference documents: PC 99 System Design Guide - 17.5.2
Test description: TD-16.8 Audio PC 99 Audio Device Test (PC99Aud)

11.1.8 Support for 22.05 Kss sample capture rate.

(This is a hardware recommendation only.)
Reference documents: PC 99 System Design Guide - 17.5.2
Test description: TD-16.8 Audio PC 99 Audio Device Test (PC99Aud)

11.1.9 Support for 16 Kss sample capture rate.

(This is a hardware recommendation only.)
Reference documents: PC 99 System Design Guide - 17.5.2
Test description: TD-16.8 Audio PC 99 Audio Device Test (PC99Aud)

11.1.10 Support for 11.025 Kss sample capture rate.

(This is a hardware recommendation only.)
Reference documents: PC 99 System Design Guide - 17.5.2
Test description: TD-16.8 Audio PC 99 Audio Device Test (PC99Aud)

11.1.11 Support for 8 Kss sample capture rate.

(This is a hardware recommendation only.)
Reference document: PC 99 System Design Guide - 17.5.2
Test description: TD-16.8 Audio PC 99 Audio Device Test (PC99Aud)


Speech Input Audio Codec ADC Capture Performance Assertions

The following audio codec ADC capture performance assertions are tested as described in TD-16.7 Audio Quality Test (AUDQLTY).

11.2.1 Full Scale Input Voltage test to ensure that full scale digital value is not reached until Vin ( 100 mV (VRMS).

Reference documents: WLP# - B3.1.4.4; PC 2001 System Design Guide - AUD-0329; PC 99 System Design Guide - 17.4.
Test description: TD-16.7 Audio Quality Test (AUDQLTY)

11.2.2 Microphone ADC Frequency Response (-3 dB) at 22.05 kHz must be between 100 Hz and 8.8 kHz, inclusive.

Reference documents: WLP# - B3.1.4.4; PC 2001 System Design Guide - AUD-0329; PC 99 System Design Guide - 17.4; Test Assertion 16.30.13.
Test description: TD-16.7 Audio Quality Test (AUDQLTY)

11.2.3 Microphone ADC Dynamic Range must be greater than or equal to 70 dB FS A-weighted.

For mobile systems, the microphone ADC Dynamic Range must be greater than or equal to 60 dB FS A-weighted.
Reference documents: WLP# - B3.1.4.4; PC 2001 System Design Guide - AUD-0329; PC 99 System Design Guide - 17.4; Test Assertion 16.30.14.
Test description: TD-16.7 Audio Quality Test (AUDQLTY)

11.2.4 Microphone ADC Total Harmonic Distortion plus Noise (-3 dB) must be less than or equal to –60 dB FS (input-referenced).

For mobile systems, the microphone ADC THD+N must be less than or equal to –50 dB FS.
Reference documents: WLP# - B3.1.4.4; PC 2001 System Design Guide - AUD-0329; PC 99 System Design Guide - 17.4; Test Assertion 16.30.15.
Test description: TD-16.7 Audio Quality Test (AUDQLTY)

11.2.5 Microphone ADC Sample Capture Accuracy must be 0.1% or less.

Reference documents: WLP# - B3.1.4.4; PC 2001 System Design Guide - AUD-0329; PC 99 System Design Guide - 17.4.
Test description: TD-16.7 Audio Quality Test (AUDQLTY)


Speech Input System Microphone Input Assertions

The following system microphone input assertions are tested with TD-11.2 Microphone Input Electro-Mechanical Test (Checklist).

11.3.1 Three-conductor 3.5 mm mini-jacks.

Reference documents: WLP# - B3.1.4.6; PC 2001 System Design Guide - AUD-0331; PC 99 System Design Guide - 17.7.
Test description: TD-11.2 Microphone Input Electro-Mechanical Test (Checklist)

11.3.2 Tip/Ring/Sleeve mechanical configuration.

Reference documents: WLP# - B3.1.4.6; PC 2001 System Design Guide - AUD-0331; PC 99 System Design Guide - 17.7.
Test description: TD-11.2 Microphone Input Electro-Mechanical Test (Checklist)

11.3.3 Voice input on tip.

Reference documents: WLP# - B3.1.4.6; PC 2001 System Design Guide - AUD-0331; PC 99 System Design Guide - 17.7.
Test description: TD-11.2 Microphone Input Electro-Mechanical Test (Checklist)

11.3.4 Electret bias on ring.

Reference documents: WLP# - ; PC 2001 System Design Guide - AUD-0331; PC 99 System Design Guide - 17.7.
Test description: TD-11.2 Microphone Input Electro-Mechanical Test (Checklist)

11.3.5 Sleeve connected to ground.

Reference documents: WLP# - B3.1.4.6; PC 2001 System Design Guide - AUD-0331; PC 99 System Design Guide - 17.7.
Test description: TD-11.2 Microphone Input Electro-Mechanical Test (Checklist)

11.3.6 4K( minimum impedance from tip to ground.

Reference documents: WLP# - B3.1.4.6; PC 2001 System Design Guide - AUD-0331; PC 99 System Design Guide - 17.7.
Test description: TD-11.2 Microphone Input Electro-Mechanical Test (Checklist)

11.3.7 Programmable pre-amp microphone boost.

Reference documents: WLP# - B3.1.4.6; PC 2001 System Design Guide - AUD-0331; PC 99 System Design Guide - 17.7.
Test description: TD-11.2 Microphone Input Electro-Mechanical Test (Checklist)

11.3.8 2 K( minimum impedance from Vbias source to ring.

Reference documents: WLP# - B3.1.4.6; PC 2001 System Design Guide - AUD-0331; PC 99 System Design Guide - 17.7.
Test description: TD-11.2 Microphone Input Electro-Mechanical Test (Checklist)

11.3.9 AC coupled tip.

Reference documents: WLP# - B3.1.4.6; PC 2001 System Design Guide - AUD-0331; PC 99 System Design Guide - 17.7.
Test description: TD-11.2 Microphone Input Electro-Mechanical Test (Checklist)


Speech Input Microphone Peripheral Electrical / Mechanical Assertions

The following microphone peripheral electrical / mechanical assertions are tested with TD-11.3 Microphone Peripheral Electrical / Mechanical Test (Checklist).

11.4.1 Physical positioning of microphone within 1.5" of corner of speaker’s mouth, for close-speaking headset designs.

Reference documents: WLP# - B3.1.4.13; PC 2001 System Design Guide - AUD-0332; PC 99 System Design Guide - 7.11.
Test description: TD-11.3 Microphone Peripheral Electrical / Mechanical Test (Checklist)

11.4.2 Three-conductor 3.5mm mini-plug.

Reference documents: WLP# - B3.1.4.6, B3.1.4.13; PC 2001 System Design Guide - AUD-0331 and AUD-0332; PC 99 System Design Guide - 7.11.
Test description: TD-11.3 Microphone Peripheral Electrical / Mechanical Test (Checklist)

11.4.3 Tip/Ring/Sleeve mechanical configuration.

Reference documents: WLP# - B3.1.4.6, B3.1.4.13; PC 2001 System Design Guide - AUD-0331 and AUD-0332; PC 99 System Design Guide - 7.11.
Test description: TD-11.3 Microphone Peripheral Electrical / Mechanical Test (Checklist)

11.4.4 Audio output on tip.

Reference documents: WLP# - B3.1.4.6, B3.1.4.13; PC 2001 System Design Guide - AUD-0331 and AUD-0332; PC 99 System Design Guide - 7.11.
Test description: TD-11.3 Microphone Peripheral Electrical / Mechanical Test (Checklist)

11.4.5 Vbias input on ring of 2-5V DC for electret microphones.

Reference documents: WLP# - B3.1.4.6, B3.1.4.13; PC 2001 System Design Guide - AUD-0332; PC 99 System Design Guide - 7.11.
Test description: TD-11.3 Microphone Peripheral Electrical / Mechanical Test (Checklist)

11.4.6 Sleeve connects to ground.

Reference documents: WLP# - B3.1.4.6, B3.1.4.13; PC 2001 System Design Guide - AUD-0331 and AUD-0332; PC 99 System Design Guide - 7.11.
Test description: TD-11.3 Microphone Peripheral Electrical / Mechanical Test (Checklist)


Speech Input Test Descriptions

TD-11.1 Host System Audio Control Interface Test (Checklist)

This section groups all features relating to the interface between the host system and the audio subsystem.

Systems manufacturers declare product adherence to these requirements and recommendations in this area of product design by completing the following checklist. Any failed result is a failed test.

Answer each line item in the following checklist.

Table 11-1. Host System Audio Control Interface Assertions Checklist

Assertion | Description | Confirm
11.1.1 | Host I/O Bus Interface is PCI or USB, not ISA |
11.1.2 | A system that has SB Legacy HW accessible under Windows. |


TD-11.2 Microphone Input Electro-Mechanical Test (Checklist)

This section details the interface between a microphone output plug and the system’s voice capture electronics.

Systems manufacturers declare product adherence to these requirements and recommendations in this area of product design by completing the following checklist. Any Failed result is a failed test.

Table 11-2. Microphone Input Electro-Mechanical Assertions Checklist

Assertion | Description | Confirm
11.3.1 | Three-conductor 3.5mm mini-jack. |
11.3.2 | Mini-jack has tip/ring/sleeve configuration. |
11.3.3 | Voice audio is connected to the tip. |
11.3.4 | Electret microphone bias voltage connected to ring. |
11.3.5 | Sleeve connected to ground. |
11.3.6 | Tip to ground impedance ( 4 K(. |
11.3.7 | On/off programmable microphone input pre-amp |
11.3.8 | Vbias ring to ground impedance ( 2 K( |
11.3.9 | AC coupled Tip |


TD-11.3 Microphone Peripheral Electrical / Mechanical Test (Checklist)

This section groups those attributes that collectively determine a given microphone’s suitability for speech applications from a physical perspective. All of these attributes are recommendations only, and pertain only to a close speaking configuration.

Even though the assertions are not required, system manufacturers are still encouraged to have their bundled microphones meet these recommended assertions and to differentiate themselves with respect to their products’ speech "readiness" in this regard.

Complete the following checklist.

Table 11-3. Peripheral Microphone Electro-Mechanical Assertions Checklist

Assertion | Description | Confirm
11.4.1 | Microphone element positions within 1.5" of the corner of the speaker’s mouth, for close-speaking headsets. |
11.4.2 | Three-conductor 3.5mm mini-jack. |
11.4.3 | Mini-jack has tip/ring/sleeve configuration. |
11.4.4 | Voice audio is connected to the tip. |
11.4.5 | Electret Microphone bias operating voltage 2-5V DC. |
11.4.6 | Electret Mic bias voltage connected to ring. |


Chapter 12: Remote Boot Test Specification

This chapter describes remote boot requirements and test tools that validate support for remote boot using the protocol specified for API support provided by the remote boot agent, and for associated BIOS support of the remote boot capability.

This test specification also describes the individual tests that verify the requirements for remote boot in the "Remote Boot Test Descriptions" section.

Test Coverage

These tests cover requirements defined for the following requirements defined in Microsoft Windows Logo Program System and Device Requirements:

BIOS supports Pre-Boot Execution Environment (PXE)

BIOS supports booting the system from the network and using F12 to force a system boot

The system universal unique ID (UUID) is provided.

BIOS supports Boot Integrity Services (Not implemented)

System BIOS provides remote lockout capability

Test Methodology

Two types of tests are performed. The first type of test is comprised of checks for specific BIOS capabilities. These are determined through simple operator tests and are verified by observation of results (that is, the tests are not programmatic).

The second type of test verifies the remote boot capability, Remote Lockout capability and, Boot Integrity Service capability (Not implemented). This includes operational and functional test elements. Specifically, the system under test (SUT) uses the core remote boot capability to remote boot test software (the operational part of the test). The test software in turn functionally tests some of the finer points of the remote boot and DHCP protocols and some specific capabilities (for example, APIs) provided by the PXE boot ROM.

The remote boot tests and BIOS requirements described in this document are designed to run on all IA-32 processor based platforms.

The remote boot test environment requires two servers (2 Windows XP or 1 Windows 2000 and 1 Windows XP) in addition to the PC system under test (SUT), and network equipment as needed to connect the servers and SUT on a single segment (see Figure 12-1). The two servers each provide a specific service essential to the remote boot tests.

The following software is needed to configure the two test servers:

  • A Windows 2000 Server CD
  • The Remote Boot Test Kit software

Figure 12-1. Remote Boot Test Setup

Figure 12-1. Remote Boot Test Setup

In addition to the SUT, the BIOS test environment requires a Network Interface Card with a PXE 2.0 boot ROM installed, and the boot ROM boot mode set to "BBS" (as opposed to either "Int 18" or "Int 19").


Reference Documents for Remote Boot Test Assertions

Functional requirements specified in the following documents:

Boot Integrity Services Application Programming Interface, Version 1.0

http://developer.intel.com/ial/wfm/wfmspecs.htm

Compaq-Intel-Phoenix BIOS Boot Specification, v. 1.01 El Torito—Bootable CD-ROM Format Specification, v. 1.0

http://www.ptltd.com/techs/specs.html

Microsoft Windows Logo Program System and Device Requirements, Version 2.0

http://www.microsoft.com/hwdev/winlogo/
(listed as "WLP#" in these assertions)

Microsoft Windows Driver Development Kit

http://www.microsoft.com/ddk/

PC 2001 System Design Guide and PC 99 System Design Guide

http://www.microsoft.com/hwdev/platform/pcdesign/desguide/pcguides.asp

System Management BIOS Reference Specification, Version 2.3

http://www.phoenix.com/techs/specs.html


Remote Boot Test Assertions

This section includes the assertions derived for remote boot. Each assertion listed includes an assertion description, a list of reference documents, and references to the "Test Description" section for a description of the test.

12.1.1 BIOS supports booting system from the network.
– BIOS includes capability specified in CIP BIOS Boot Specification 1.01
– BIOS must provide a configuration interface to set order of boot devices.

Reference document: WLP# - A1.1.4; PC 2001 System Design Guide - BIOS-0014.2.1; Compaq, Intel, Phoenix BIOS Boot Specification, Version 1.01.
Test description: TD-12.1 BIOS Supports Booting System from the Network Test

12.1.2 F12 key must force a system boot initiated from the network adapter.

Test is not currently implemented.

Reference document: WLP# - A1.1.4; PC 2001 System Design Guide - BIOS-0014.2.3; Compaq, Intel, Phoenix BIOS Boot Specification, Version 1.01,
Appendix C
Test description: TD-12.2 BIOS Supports Forcing a Network Boot Test

12.1.3 System UUID is provided.

Test is not currently implemented.

Reference document: WLP# - A1.1.4; PC 2001 System Design Guide - BIOS-0014.3
Test description: TD-12.3 UUID Present Test

12.1.4 System supports Remote Boot.

Reference document: WLP# - B7.1.4.5; PC 2001 System Design Guide - NET-0256, BIOS-0014.1
Test descriptions: TD-12.4 Remote Boot Supported Test and
TD-12.5 Remote Boot Windows 2000 Remote Install Test

12.1.5 System BIOS provides Remote Lockout Capability (When Implemented).

Reference document: WLP# - A1.1.4; PC 2001 System Design Guide - BIOS-0014.5.
Test description: TD-12.6 BIOS Supports Remote Lockout Test

12.1.6 BIOS supports Boot Integrity Services (BIS), if system includes BIS support

Test is not currently implemented

Reference document: WLP# - A1.1.4; PC 2001 System Design Guide - BIOS-0014.4, Boot Integrity Services (BIS), Version 1.0; System Management BIOS Reference Specification, Version 2.3.
Test description: TD-12.7 BIOS Supports Boot Integrity Service Test


Remote Boot Test Descriptions

This section describes the remote boot device tests. The descriptions include an overview of each test, hardware and software setup, test execution instructions, test algorithms/steps, and test results interpretation.

General Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

  1. Install Windows 2000 Server.

a. Insert CD or boot floppies in server.

b. Install Windows 2000 Server to one of your partitions. You must have at least one additional partition on your system that is not your system or boot partition, and this partition must have a minimum of 800MB of free space. (Example if your test server only has one drive, create a 2.0 GB partition to install the operation system on and leave the remaining space free.)

c. During the GUI mode portion of setup select the defaults or normal settings except for the following cases (in order of appearance):

(a.) Windows 2000 Components page: select "Remote Installation Services" and "Networking Services/Domain Name System"

(b.) Network Settings page:

(i.) Select "Custom settings", Next>

(ii.) Highlight "Internet Protocol (TCP/IP)", properties

(iii.) Set an IP address and subnet mask that is correct for you network

(iv.) Set the DNS server address to the static address you gave in the previous step. Click OK.

(v.) Click Next>.

  2. Promote the server to a Domain Controller

a. Start->Run-> "dcpromo.exe"

b. Click Next>

c. Select "Domain controller for a new domain", Next>

d. Select "Create a new domain tree", Next>

e. Select "Create a new forest of domain trees", Next>

f. Enter a DNS name for the domain. Ex: ris.com, Next>

g. Accept the default NetBIOS name, Next>

h. Accept the default locations for the database and log, Next>

i. Accept the default location for the sysvol, Next>

j. Select "Yes, install and configure DNS on this computer", Next>

k. Select "Permissions compatible with pre-Windows 2000 servers", Next>

l. Enter the password to set on the domain admin account, Next>

m. Click Next> to start the promotion operation.

n. Click Finish

o. Allow system to restart.

  3. Configure DNS

a. Start->Run->dnsmgmt.msc

b. Highlight the forward lookup zone for your domain (ex:ris.com), properties

c. Set Allow dynamic updates to Yes, OK

  4. If needed, format the free space on your disk to create a partition that has a minimum of 800MB of free space and the volume must be formatted as NTFS. (This partition must not be your boot or system volume)
  5. Configure Remote Installation Services (RIS)

a. Start->Run->risetup.exe

b. Click Next>

c. Enter a drive/directory on your disk with 800MB of free space. (The default should be your largest NTFS volume that is not boot or system.) Click Next>.

d. Select "Respond to client computers requesting service", Next>

e. Enter path to CD-ROM drive that has your Windows 2000 Profession CD inserted, Next>

f. Click Next>

g. Click Next>

h. Click Finish

i. Click Done

  6. Authorize RIS server

a. Start->Run->adminpak.msi

b. Click Next>

c. Select "Install all of the Administrative Tools", Next>

d. Click Finish

e. Start->Run->dhcpmgmt.msc

f. Right Click on DHCP, Select "Add Server…"

g. Enter the IP address of this system, OK

h. Close the dhcpmgmt mmc snap-in.

  7. Modify Answer File to Not Do a Full Installation

a. Browse to \\<server>\REMINST\Setup\English\Images\win2000.pro\i386\templates directory.

b. Open the file ristndrd.sif with the Notepad

c. Find the line "Repartition = Yes".

d. Change this line to "Repartition = No".

e. Save the updated version of ristndrd.sif

Adding Additional NIC Drivers to a RIS Image
  1. Browse to \\<server>\REMINST\Setup\English\Images\win2000.pro\i386 directory.
  2. Copy the contents of the NIC driver disk to the directory listed above.
  3. Start->Run->"net stop binlsvc"
  4. Start->Run->"net start binlsvc"


TD-12.1 BIOS Supports Booting System from the Network Test

Overview

For any system that includes a network adapter, the system BIOS must comply with the requirements defined in Sections 3 and 4 as applied to Plug and Play devices defined in Compaq, Intel, Phoenix BIOS Boot Specification, Version 1.01. This specification describes the requirements for Initial Program Load (IPL) devices.

The system must also allow all boot devices to be configured as to the order of precedence for boot. This mechanism must clearly show how the system orders boot devices when end users are making configuration choices. For example, in a system that permits booting from floppy drive, hard drive, CD or DVD drive, and network adapter, it must be clear to the end user how to set a boot order that favors a specific device such as the network adapter.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

  1. Install the PXE 2.0 enabled NIC into the SUT.
  2. Turn on the SUT’s power.
  3. Using the SUT manufacturer’s instructions, enter the BIOS setup interface during POST.
  4. Find the boot device boot order setup interface.
  5. Determine that the PXE 2.0 enabled NIC appears in the list of boot devices.
  6. Move the PXE 2.0 enabled NIC to be first in the boot order list of boot devices.
  7. Save the BIOS setup and reboot the SUT.
  8. Using the PXE 2.0 enabled NIC manufacturer’s instructions, set the boot mode of the NIC to "BBS" (normally a key combination used to bring up a configuration menu executed during the initial stage of the remote boot).
  9. Turn off the SUT.

Test Execution Instructions

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

  1. Turn on the SUT’s power.
  2. Using the SUT manufacturer’s instructions, enter the BIOS setup interface during POST.
  3. Find the boot device boot order setup interface.
  4. Determine that the PXE 2.0 enabled NIC appears first in the list of boot devices.

Results Interpretation

If the test result indicates the presence of the PXE 2.0 enabled NIC in the list of boot devices (e.g. "Network" is defined as one of the boot devices), then the BIOS supports BBS as specified and the SUT has passed the test.

If the PXE 2.0-enabled NIC does not appear in the boot list, then either BBS is not supported or has been incorrectly implemented and the SUT has failed the test.


TD-12.2 BIOS Supports Forcing a Network Boot Test

Note This test is not implemented.

Overview

For any system that includes a network interface, the <F12> key must force a system boot from the network. This must be enabled by default. Configuration of this feature can be provided through a CMOS configuration setting. When this feature is enabled, the boot display must indicate the <F12> key forces a system boot from the network. This display must appear for a duration sufficient to be read by users, but must not lengthen the overall time needed to boot the machine.

Systems that do not have an F12 key, or already use the F12 key for another OEM-defined BIOS function, may use an alternate key for network boot.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The System Under Test must have a hard drive with a bootable operating system installed.

  1. Turn on the SUT’s power.
  2. Using the SUT manufacturer’s instructions, enter the BIOS setup interface during POST.
  3. Find the boot device boot order setup interface.
  4. Move the hard drive to be the first in the boot order list of boot devices.
  5. Move the network interface after the hard drive in the boot order list of boot devices.
  6. Save the BIOS setup and reboot the SUT.

Test Execution Instructions

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

  1. Turn on the SUT’s power.
  2. Using the key indicated on the boot screen, force the network boot.
  3. Observe that the SUT attempts to boot from the network rather than from the hard drive.

Results Interpretation

If the boot screen does not display that by pressing the indicated key, this forces a system boot from the network, the SUT fails the test.

If the boot screen displays that pressing the indicated key will force a system boot from the network, and the user presses it at the appropriate time but the SUT does not attempt a system boot from the network, the SUT fails the test.


TD-12.3 UUID Present Test

Note This test is not implemented.


TD-12.4 Remote Boot Supported Test

Test Kit: HCT 11, HCT 10

Note This test includes the Remote Boot test and PXE Server Installation test.

Overview

This test checks four things:

  1. Basic Remote Boot capability
  2. Remote Boot protocol Packet Analysis

Packet analysis consists of determining if the DHCP and PXE packets correctly contain the following options:

Description | Option Number
SUT machine identifier (UUID) | 97
SUT system architecture option | 93
SUT network interface identifier | 94
Correct DHCP Msg type | 53
Class Identifier set to "PXEClient" | 60

If any of these options are missing or contain incorrect values, the SUT is considered to fail the compliance test.

In addition, a basic field check of the DHCP packet is performed. Compliance requires correct use of the DHCP protocol.

  3. PXE API function

This test attempts to verify that all PXE API calls exist. It also verifies the contents of all the registers modified by the call and prints the results to a log file. It tests the APIs in the following sequence: BINL_INFO, UDP, TFTP and UNDI.

  4. UNDI API function

Different sizes of files are copied from the SUT’s mapped drive to the SUT’s RAMDisk, to stress test the UNDI API. The original files and the copied files are then compared.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The System Under Test must have an operating system installed with a FAT partition as the first partition on the system. This partition must have enough free space to allow the writing of the log file.

Set up the Server(s)

The PXE test environment includes two Microsoft Windows 2000 servers. One server runs Microsoft DHCP and one runs the PXE and MTFTPD services provided in the Remote Boot Test Kit. For both servers in your test environment, do the following:

  1. Install Microsoft Windows 2000 Server
  2. Install TCP/IP.
  3. Assign a static IP address to the server.
  4. Ensure the "GUEST" account is enabled.
Install DHCP

One of the servers in the test setup must provide the DHCP service. To set up this service:

  1. During the Microsoft Windows 2000 installation, install the Microsoft DHCP Server.
  2. Create a valid scope on the DHCP server.
Install the PXE Services

The other server in your test setup must provide the PXE service. To set up this service:

  1. Copy the executable PC01RBTK.EXE to a temporary directory of your choice ("<temp>" in the following listing) on the NT test server.
  2. Run <temp>\PC01RBTK.exe.

The install program installs services and sets up associated registry keys.

When the install program completes, choose to reboot the system so the new services start correctly.

After installing RBTK, the following directories and files exist in the installation directory:

<install directory> | RBTK installation directory
SYSTEM | Directory holding executables and bootfiles
| |---ApiTestOpts.dll |
| |---BStrapOpts.dll |
| |---PxeClientTester.dll |
| |---DosUndiOpts.dll |
| |---PXEServerParser.dll |
| |---mkimage.exe | Utility for creating bootfile file from floppy
| |---PxeConfig.exe | Utility for configuring PXE settings
| |---PxeMsg.dll |
| |---PxeService.exe | Bootserver and ProxyDHCP Service
| |---PxeMTFTP.exe | MTFTP Service
| |---RegRite.exe | Utility for writing the Client boot menu to the registry
| |---PxeParser.dll |
| \---IMAGES |
| \---X86PC | Directory for X86PC specific bootfiles
| \---UNDI | Directory for UNDI specific bootfiles
| +---APITEST | Directory for APITest Service bootfiles
| | |--apitest.0 | Layer 0 bootfile for APITest
| | |--mktest.bat | Batch file for creating APITest.1 bootfile
| | \---MKIMAGE | Source files for APITest.1
| | |--autoexec.bat | Source files for APITest.1
| | |--autoexec.tst | Source files for APITest.1
| | |--config.sys | Source files for APITest.1
| | |--copylogs.bat | Source files for APITest.1
| | |--csagent2.exe | Source files for APITest.1
| | |--ndistest.bat | Source files for APITest.1
| | |--newtest.exe | Source files for APITest.1
| | |--pxeapi.ini | Source files for APITest.1
| | |--ramd.exe | Source files for APITest.1
| | |--reboot.com | Source files for APITest.1
| | \---NET | Source files for APITest.1
| | |--lmhosts | Source files for APITest.1
| | |--ndis.dos | Source files for APITest.1
| | |--netstart.bat | Source files for APITest.1
| | |--protocol.ini | Source files for APITest.1
| | |--system.ini | Source files for APITest.1
| \---Bstrap |
| |--Bstrap.0 | Bootstrap for pre 2.0 PXE boot roms
\---TESTLOG | Directory for test logs
|--testfile.exe | Executable to create test files FILE111

The installation adds a share to the "Testlog" directory. Please ensure that the GUEST account has access rights to the "Testlog" directory and has permissions to connect to "Testlog" share.

Enabling Network Boot on the System Under Test

Using the platform BIOS setup interface, make the network interface the first boot device.

The ability to make the NIC the first boot device depends on underlying BIOS support. Compliance requires BIOS Boot Spec (BBS) support. If this is present, setting the boot order should not be a problem. To set the boot order in a SUT for most BBS compliant systems:

  1. Enter BIOS setup during POST
  2. Locate the boot order setting
  3. Make the NIC the first boot device

Test Execution Instructions

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Re-boot the SUT. When prompted, press <F8> to view menu. Select "Remote Boot Test" from the menu. The SUT performs a remote boot. The remote boot downloads and executes the test program.

Results Interpretation

A RAM drive is created on the SUT during the API test. All SUT API test output files are created on this virtual A drive.

The Log file is written to C:\RMTBOOT.LOG. In addition, the SUT maps a drive to the <install directory>\TestLOG share of the Bootserver and the API test log files are also copied to the SUT’s sub-directory on this share.

The test application on the test server places the log file results of the Packet Analysis test in SUT’s sub-directory.

The test logs are cumulative. Therefore the SUT’s subdirectory should be deleted before performing a new test boot.

In summary, the test logs are located in the sub-directory: <install directory>\Testlog, and for a particular SUT, in the sub-directory named with the last 8 characters of the SUT's MAC address.

This sub-directory contains the files:

File | Description
TESTSUM.TXT | Contains a summary of the results of the PXE API test and the Packet Analysis tests. The packet analysis summary is first, followed by the summary results of the PXE API test.
Cpkt1.TXT | The SUT’s DHCPDISCOVER packet.
Cpkt2.TXT | The DHCP server’s DHCPACK packet.
Cpkt3.TXT | The Boot Server’s Discover Reply packet, which contains Option #60 set to "PXEClient", a valid bootfile name, and may contain MTFTP options.
Rmtboot.log | Log file containing Pass/Fail results based on test assertions.
Analysis.txt | File containing Pass/Fail text displayed on SUT’s screen at completion of test.
NDISTEST.TXT | Contains the detailed output from performing a series of file transfers to stress test the NDIS interface.
DHCPPKT.TXT | Contains a hex dump of the DHCP_Discover or BINL_Request packet and a detailed analysis of the PXE options found or missing. DHCPPKT.TXT may contain multiple packet analysis depending on how many DHCP transactions were performed.

The following TESTSUM.TXT file illustrates the results of a SUT that sends a DHCP Discover when it first boots and then follows with a BINL Request. This SUT has failed the compatibility test because it does not include a UUID in the DHCP or BINL packet. The third packet in the analysis occurred after the SUT booted and is from the DOS TCP/IP stack that is loaded during the API test.

The text after the packet analysis indicates the SUT passed all of the API tests.

==============================================================

12/19/97 13:06:20 : Results of Packet Analysis For Client:C90C945A

==============================================================

Invalid or missing Client Machine Identifier(UUID) (97,0x61)

FAILED: Packet does not comply with PXE protocol due to the errors listed above.

--------------------------------------------------------------

END OF ANALYSIS

--------------------------------------------------------------

**************************************************************

==============================================================

12/19/97 13:06:20 : Results of Packet Analysis For Client:C90C945A

==============================================================

Invalid or missing Client Machine Identifier(UUID) (97,0x61)

FAILED: Packet does not comply with PXE protocol due to the errors listed above.

--------------------------------------------------------------

END OF ANALYSIS

------------------------------------------------------------------------------

******************************************************************************

Note: The following section shows DHCP Discover from DOS TCP/IP during APITest. Note that this is not a packet generated by PXE, but rather one that occurred after booting.

==============================================================================

12/19/97 13:07:01 : Results of Packet Analysis For Client:C90C945A

==============================================================

Invalid or missing Vendor Class Identifier (60,0x3C)

Invalid or missing Client System Architecture (93,0x5C)

Invalid or missing Client Network Interface Identifier (94,0x5D)

Invalid or missing Client Machine Identifier(UUID) (97,0x61)

FAILED: Packet does not comply with PXE due to the errors listed above.

--------------------------------------------------------------

END OF ANALYSIS

--------------------------------------------------------------

**************************************************************

API Test Results

GET_DHCP_DISCOVER: Passed..

GET_DHCP_ACK: Passed..

GET_BINL_REPLY: Passed..

UDP_OPEN: Passed..

UDP_WRITE: Passed..

UDP_READ: Passed..

UDP_CLOSE: Passed..

TFTP_GET_FILE_SIZE: Passed..

TFTP_OPEN: Passed..

TFTP_READ: Passed..

TFTP_CLOSE: Passed..

TFTP_READ_FILE: Passed..

UNDI_SHUTDOWN: Passed..

UNDI_INITIATE_DIAGS: Call is present but not supported.

This is an optional call.

UNDI_INIT: Passed..

UNDI_GET_STAT: Passed..

UNDI_CLEAR_STAT: Passed..

UNDI_OPEN: Passed..

UNDI_GET_INFO: Passed..

UNDI_GET_NIC_TYPE: Passed..

UNDI_GET_IFACE_INFO: Passed..

UNDI_SET_STATION_ADDR: Passed..

UNDI_GET_MCAST_ADDR: Passed..

UNDI_SET_MCAST_ADDR: Passed..

UNDI_SET_PACKET_FILTER: Passed..

UNDI_TRANSMIT: Passed..

UNDI_FORCE_INTERRUPT: Passed..

UNDI_RESET_NIC: Passed..

UNDI_CLOSE: Passed..

UNDI_SHUTDOWN: Passed..


TD-12.5 Remote Boot Windows 2000 Remote Install Test

Note This test is not implemented.

Overview

This test is designed to verify that the system under test (SUT) successfully installs Windows 2000 Professional using Remote Installation Services.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Set up the Windows 2000 Server
  1. Disconnect the Remote Boot Protocol and API Test Server from the test network.
  2. Insert the Microsoft Windows 2000 Server CD in the system.
  3. Follow the setup instructions listed in Setup Windows 2000 Server for Remote Boot Test.
  4. If the SUT requires a Network Interface Card (NIC) driver that is not shipped with Windows 2000, then follow the instructions in Adding Additional NIC Drivers to a RIS Image.
Enabling Network Boot on the System Under Test

Using the platform BIOS setup interface, make the network interface the first boot device.

The ability to make the NIC the first boot device depends on underlying BIOS support. Windows Logo Program compliance requires BIOS Boot Spec (BBS) support. If this is present, setting the boot order should not be a problem. To set the boot order in a SUT for most BBS compliant systems:

  1. Enter BIOS setup during POST
  2. Locate the boot order setting
  3. Make the NIC the first boot device

Test Execution Instructions

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

  1. Re-boot the SUT. The SUT performs a remote boot.
  2. When prompted press F12 to select a Network Service Boot
  3. The Client Installation Wizard (CIW) is downloaded to the SUT.
  4. Select Enter on the Welcome page of CIW to continue.
  5. Enter administrator in the username field of the logon page.
  6. Select Enter on the Caution page to continue.
  7. Select Enter on the Installation Information page to start the installation.

Results Interpretation

The SUT should start an installation of Windows 2000 Professional. The test is considered passed if the system makes it to the screen to select the installation partition.


TD-12.6 BIOS Supports Remote Lockout Test

Overview

The System Under Test must have an operating system installed with a FAT partition as the first partition on the system. This partition must have enough free space to allow the writing of the log file.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The Network Interface must be the first boot device.

Test Execution Instructions

Re-boot the SUT. When prompted press <F8> to view menu. Select "Remote Lockout Test" from the menu. The SUT performs a remote boot. The remote boot downloads and executes the test program. The Log file will be written to C:\RLOCKOUT.LOG.

Results Interpretation

If the Remote Lockout Capability is not available the system fails the test.


TD-12.7 BIOS Supports Boot Integrity Service Test

Note This test is not implemented.

Overview

The System Under Test must have an operating system installed with a FAT partition as the first partition on the system. This partition must have enough free space to allow the writing of the log file.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

If not already done, disconnect the Windows 2000 RIS Server from the network and reconnect the PXE Remote Boot Protocol and APITest Server to the network. Make the Network Interface the first boot device.

Test Execution Instructions

Re-boot the SUT. When prompted press <F8> to view menu. Select "Boot Integrity Services Test" from the menu. The SUT performs a remote boot. The remote boot downloads and executes the test program. The Log file will be written to C:\RLOCKOUT.LOG.

Results Interpretation

A pass or fail message is written to the screen and the log file contains all of the pertinent information based on test assertions.


TD-12.8 Setup Windows 2000 Server for Remote Boot Test

Note This test is not implemented.


Chapter 13: Digital Still Imaging and WIA Test Specification

This specification consists of two main parts:

  • Digital Still Imaging Test Specification, for still imaging hardware and for drivers based on STI solutions.
  • WIA (Windows Image Acquisition) Mini-driver Test Specification, for driver solutions based on the WIA model supported in Windows Millennium Edition, Windows XP, and later versions of the operating system.

For systems shipping before July 2000 running Windows 2000 or Windows 98 Second Edition, the Windows Logo Program 1.1 defines these required hardware and system behaviors. Microsoft Windows Logo Program System and Device Requirements (2.0) defines requirements for still imaging devices on systems that run Windows Millennium Edition and Windows XP.

This chapter applies to the following digital still imaging devices:

  • Digital cameras
  • Flatbed scanners
  • Photo scanners (single page feed)
  • Film scanners

Other devices may be capable of acting like a still imaging device, such as a tethered video camera with still image capture support. These devices should be capable of passing the set of tests described in this document. In general, a still imaging device must be able to capture an image optically. Thus, a digital camera flash memory device removed from the camera and inserted into a flash reader or a PhotoCD ROM in a CD ROM player are not considered digital still imaging devices.

The purpose of this document is to describe test procedures for digital still imaging devices with sufficient detail so that a test implementation can be derived.


Digital Still Imaging Test Specification

Test Coverage

The Digital Still Imaging tests exercise the still imaging hardware and driver to test compliance with Windows Logo Program 1.1 requirements. All tests are based on the Microsoft Windows 98 operating system; as other operating systems are not as commonly supported by still imaging hardware.

Table 13-1 lists the requirements for still imaging devices under the Windows Logo Program 1.1.

Table 13-1. Windows Logo Program 1.1 Still Imaging Device Requirements and Test Coverage

Capability | Compliance | Test Coverage
Port connection | All | No - self-certify
Port icons | All | No - self-certify
ICC color management | All | Yes
IR requirements | All IR devices | No - but IR tests may apply
Fast IR transfer | All IR devices | Yes, for IR devices
Secondary interface | All IR devices | No - self-certify
SCSI compliance | All SCSI devices | No - but SCSI tests may apply
SCSI compatibility | All SCSI devices | No - but SCSI tests may apply
USB compliance | All USB devices | No - but USB tests may apply
USB string descriptor | All USB devices | No - but USB tests may apply
USB alt. interface = 0 bps | USB devices that use iso | No - but USB tests may apply
USB doesn’t saturate bus | USB devices that use iso | No - but USB tests may apply
USB performance | All USB devices | No - but USB tests may apply
PC-compatible file system | All if removable memory | Yes - by procedure
Use JPEG or FlashPix | Recommended | No - not required
1394 compliance | All 1394 devices | No - but 1394 tests may apply
Serial device is P&P | All COM devices | No - but COM tests may apply
All interfaces are P&P | All | No - covered by bus test
Device has P&P ID | All | No - covered by bus test
Daisy-chain 1284 devices | All parallel port devices | No - but 1284 tests may apply
Bus power management | All | No - covered by bust test
Driver installation | All | No - self-certify
STI based | All except IR | Yes, except IR
Apps. meet Win32 spec. | All | No - application requirement
TWAIN 1.7 or later | All that support TWAIN | Yes, if TWAIN supported
Socket interface for IR | All IR devices | No - but IR tests may apply
1394 device uses SBP2 | Recommended | No - not required

Table 13-2 lists Windows Logo Program 2.0 requirements for still imaging devices.

Table 13-2. Windows Logo Program 2.0 Still Imaging Device Requirements and Test Coverage

Capability | Compliance | Test Coverage
USB or 1394 port connection | Digital Still Cameras All | No - self-certify
ICC color management | All except devices supporting sRGB output | Yes
USB imaging device class specification | All USB devices | No - but USB tests may apply
Minimum Throughput | All devices | Yes
PC-compatible file system | All if removable memory | Yes - by procedure
Use JPEG | Required | No
Accurate image information | All | No
Support for PIMA 15740 protocol | USB cameras | No
WIA driver | All except IR | Yes, except IR
WDM Stream class driver | Cameras capable of streaming video | No - WDM driver test may apply
TWAIN 1.7 or later | All that support TWAIN | Yes, if TWAIN supported
1394 device uses SBP2 | Required | No

Test Methodology

These tests run on systems that are Windows Logo Program compliant, running either Windows 98/Me or Windows 2000, or Windows XP. The imaging device drivers and applications must be installed as per instructed in the device’s user manual. For IrDA tests, the IrDA port must be enabled and correctly configured as per instructed in the OS manual or the device’s user manual.


WIA Minidriver Test Specification

Overview

The Windows Image Acquisition (WIA) Minidriver Test checks the properties and transfer mechanisms of a still image device driver.

See Reference Documents for Still Imaging Test Assertions.

Test Methodology

Testing Variations

There are two variations of testing that the WIA minidriver shall pass:

1. Conformance Testing - Tests that the minidriver meets the rules and specifications for WIA. It must:

  • Provide a COM interface
  • Provide an IStiUSD interface
  • Initialize itself correctly
  • Build a device item tree
  • Initialize item properties
  • Read, validate, and write item properties
  • Correctly delete items from a device tree when requested
  • Transfer data
  • Provide event notification
  • Issue commands to a device
  • Enumerate device formats and capabilities
  • Report device errors
  • Provide color management
  • Correctly implement Automatic Document Feeder properties, if the device has an ADF

2. Load/Stress Testing - Verifies that the device behaves correctly when accessed simultaneously from 2 or more applications at the same time.

Test Types

Tests will be classified in two general types:

  • Required Tests - Mandatory for passing the test.
  • Recommended Tests - Tests properties or functionality that is recommended or optional in the WIA documentation. If a minidriver implements an optional property, it must implement it correctly.

Test Classes

There are four test classes:

1. WIA Driver Methods Tests

2. WIA Driver Properties Tests

  • Property Attributes
  • Common Device Properties
  • Camera Device Properties
  • Scanner Device Properties
  • Common Item Properties
  • Camera Item Properties
  • Scanner Item Properties
  • Interdependency Properties tests

3. Error Condition Tests (WIA Mini-driver behavior is checked under erroneous input)

  • Driver Property Error Tests
  • Execution Sequence tests

4. Load/Stress Tests

  • Interaction with more than one Imaging Application
  • Low System Resource Tests (Insufficient free RAM or HDD space)

Each class may contain both required and recommended tests.

Test Results

At the end of each test execution, a result will be logged. Possible test result values are shown in the following table.

Test Result | Description
PASSED | The WIA minidriver behavior was correct
FAILED | The WIA minidriver behavior was incorrect
ABORTED | The user interrupted the test execution

A test is considered PASSED if:

  • The return codes are correct
  • The reported values for properties are correct
  • The minidriver correctly executes requested commands

For each function call the result analyzer compares the expected function return code with the actual return code. If the values are different, the test is considered failed and the current test execution stops. The test result will be flagged as FAILED.

If the return codes are correct, the tests will check if the WIA minidriver operates according to the specification. If a property value has been changed and the driver accepts it, the test will query the mini-driver for the property value. If the reported value is incorrect, the test will be flagged as FAILED.

If everything works as expected the test result will be PASSED.


Digital Still Imaging Test Assertions


Reference Documents for Still Imaging Test Assertions

Functional requirements specified in the following documents:

ICC Profile Format Specification, Spec ICC.1:1988-09 and Addendum 2, ICC.1A:1999-04

http://www.color.org/info_profiles2.html

Microsoft Windows Logo Program System and Device Requirements, Version 2.0

http://www.microsoft.com/hwdev/winlogo/
(listed as "WLP#" in these assertions)

Microsoft Platform Software Development Kit

"Windows Image Acquisition" in "Graphics and Multimedia Services"
(Referred to as "WIA SDK" in this test specification)
http://msdn.microsoft.com/library/default.asp

Microsoft Windows Driver Development Kit

"Still Image Drivers" in the Windows XP DDK (WIA DDK)
"Kernel-mode Drivers for Still Image Devices" in Windows 2000 DDK
http://www.microsoft.com/ddk/

PC 2001 System Design Guide and PC 99 System Design Guide

http://www.microsoft.com/hwdev/platform/pcdesign/desguide/pcguides.asp


Image Color Management Profile Test Assertions

The Image Color Management (ICM) profile tests assertions are tested in:
TD-13.1 Image Color Management Profile Test

The ICM system supports profiles that conform to the International Color Consortium (ICC) profile specification. The profiles ensure that colors are represented accurately, regardless of the device being used. The devices include scanners, monitors, digital cameras, and printers.

13.1.1 Imaging device ships with ICC profile.

Reference document: WLP# - B9.1.4.2; ICC.1:1998-09, File Formats for Color Profiles.
Test description: TD-13.1 Image Color Management Profile Test

13.1.2 ICC profile header can be retrieved.

Reference document: WLP# - B9.1.4.2; ICC.1:1998-09, File Formats for Color Profiles.
Test description: TD-13.1 Image Color Management Profile Test

13.1.3 ICC profile size field in the profile header should be larger than the size of the profile header.

Reference document: WLP# - B9.1.4.2; ICC.1:1998-09, File Formats for Color Profiles.
Test description: TD-13.1 Image Color Management Profile Test

13.1.4 ICC profile file size should be larger than the profile header size.

Reference document: WLP# - B9.1.4.2; ICC.1:1998-09, File Formats for Color Profiles.
Test description: TD-13.1 Image Color Management Profile Test

13.1.5 ICC profile size field in the profile header should not be larger than the file size.

Reference document: WLP# - B9.1.4.2; ICC.1:1998-09, File Formats for Color Profiles.
Test description: TD-13.1 Image Color Management Profile Test

13.1.6 ICC profile version field in the header must be a version supported by Windows default CMM.

Reference document: WLP# - B9.1.4.2; ICC.1:1998-09, File Formats for Color Profiles.
Test description: TD-13.1 Image Color Management Profile Test

13.1.7 ICC profile class field in the header must be a valid class type and must match with the class of the imaging device.

Reference document: WLP# - B9.1.4.2; ICC.1:1998-09, File Formats for Color Profiles.
Test description: TD-13.1 Image Color Management Profile Test

13.1.8 ICC profile data color space field in the header must be a valid color space type.

Reference document: WLP# - B9.1.4.2; ICC.1:1998-09, File Formats for Color Profiles.
Test description: TD-13.1 Image Color Management Profile Test

13.1.9 ICC profile connection color space in the header must be a valid connection color space.

Reference document: WLP# - B9.1.4.2; ICC.1:1998-09, File Formats for Color Profiles.
Test description: TD-13.1 Image Color Management Profile Test

13.1.10 ICC profile signature in the header must be a valid signature.

Reference document: WLP# - B9.1.4.2; ICC.1:1998-09, File Formats for Color Profiles.
Test description: TD-13.1 Image Color Management Profile Test

13.1.11 ICC profile primary platform field in the header must be a valid platform type.

Reference document: WLP# - B9.1.4.2; ICC.1:1998-09, File Formats for Color Profiles.
Test description: TD-13.1 Image Color Management Profile Test

13.1.12 ICC profile reserved bytes in the header must be zero.

Reference document: WLP# - B9.1.4.2; ICC.1:1998-09, File Formats for Color Profiles.
Test description: TD-13.1 Image Color Management Profile Test

13.1.13 ICC profile contains the required tags for the type of ICC profile.

Reference document: WLP# - B9.1.4.2; ICC.1:1998-09, File Formats for Color Profiles.
Test description: TD-13.1 Image Color Management Profile Test

13.1.14 ICC profile tags present in the profile must be valid.

Reference document: WLP# - B9.1.4.2; ICC.1:1998-09, File Formats for Color Profiles.
Test description: TD-13.1 Image Color Management Profile Test

13.1.15 ICC profile is valid.

Reference document: WLP# - B9.1.4.2; ICC.1:1998-09, File Formats for Color Profiles.
Test description: TD-13.1 Image Color Management Profile Test

13.1.16 A transform can be created using the ICC profile.

Reference document: WLP# - B9.1.4.2; ICC.1:1998-09, File Formats for Color Profiles.
Test description: TD-13.1 Image Color Management Profile Test

13.1.17 A translation can be done using a transform that uses the ICC profile.

Reference document: WLP# - B9.1.4.2; ICC.1:1998-09, File Formats for Color Profiles.
Test description: TD-13.1 Image Color Management Profile Test


Image Download Test Assertions

The assertions in this section are tested in:
TD-13.2 Image Download Test

13.2.1 Image can be downloaded to system.

Reference document: WLP# - B9.1.4.3; PC 2001 System Design Guide - IMAG-0312; PC 99 System Design Guide, Chapter 22.
Test description: TD-13.2 Image Download Test

13.2.2 IR image download takes place at 80 Kpixels/s or faster for download of stored image and at 40 Kpixels/s or faster for download of newly acquired image.

Reference document: WLP# - B9.1.4.3; PC 2001 System Design Guide - IMAG-0312;PC 99 System Design Guide - 22.5.
Test description: TD-13.2 Image Download Test

13.2.3 Serial image download takes place at 2 Kpixels/s or faster for download of stored image and at 1 Kpixels/s or faster for download of newly acquired image.

Reference document: PC 99 System Design Guide - 22.5.
Test description: TD-13.2 Image Download Test

13.2.4 Parallel port image download takes place at 20 Kpixels/s or faster for download of stored image and at 10 Kpixels/s or faster for download of newly acquired image.

Reference document: PC 99 System Design Guide - 22.5.
Test description: TD-13.2 Image Download Test

13.2.5 USB image download takes place at 120 Kpixels/s or faster for download of stored image and at 40 Kpixels/s or faster for download of newly acquired image.

Reference document: WLP# - B9.1.4.3; PC 2001 System Design Guide - IMAG-0312;PC 99 System Design Guide - 22.5.
Test description: TD-13.2 Image Download Test

13.2.6 1394 image download takes place at 200 Kpixel/s or faster for download of stored image and at 40 Kpixels/s or faster for download of newly acquired image.

Reference document: WLP# - B9.1.4.3; PC 2001 System Design Guide - IMAG-0312;PC 99 System Design Guide - 22.5.
Test description: TD-13.2 Image Download Test

13.2.7 SCSI image download takes place at 200 Kpixels/s or faster for download of stored image and at 40 Kpixels/s or faster for download of newly acquired image.

Reference document: PC 99 System Design Guide - 22.5
Test description: TD-13.2 Image Download Test


PC-Compliant File System Test Assertions

The assertions in this section are tested in:
TD-13.3 PC-Compliant Files System Test

13.3.1 E-film media can be read via file system operation.

Reference document: WLP# - B9.1.4.6; PC 2001 System Design Guide - IMAG-0313; PC 99 System Design Guide - 22.14
Test description: TD-13.3 PC-Compatible Files System Test

13.3.2 E-film media can be erased via file system operation

Reference document: WLP# - B9.1.4.6; PC 2001 System Design Guide - IMAG-0313; PC 99 System Design Guide - 22.14
Test description: TD-13.3 PC-Compatible Files System Test

13.3.3 E-film media can be written via file system operation.

Reference document: WLP# - B9.1.4.6; PC 2001 System Design Guide - IMAG-0313; PC 99 System Design Guide - 22.14
Test description: TD-13.3 PC-Compatible Files System Test

13.3.4 E-film media "space available" can be determined via file system operation.

Reference document: WLP# - B9.1.4.6; PC 2001 System Design Guide - IMAG-0313; PC 99 System Design Guide - 22.14
Test description: TD-13.3 PC-Compatible Files System Test


WIA Properties Test Assertions

WIA Common Device Properties Test Assertions

13.4.1.1 WIA_DPA_FIRMWARE_VERSION

WIA_DPA_FIRMWARE_VERSION common device property shall exist for a device’s root item for all device types. The property shall have the WIA_PROP_NONE type, the VT_BSTR subtype and the WIA_PROP_READ access. This string value shall have a length greater than zero.

Reference document: WIA SDK - Common Device Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317

Test Description: TD-13.4.1.1 WIA_DPA_FIRMWARE_VERSION Test Description

13.4.1.2 WIA_DPA_CONNECT_STATUS

WIA_DPA_CONNECT_STATUS common device property is optional. If this property exists, it shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access. Possible values for this property are: WIA_DEVICE_CONNECTED, WIA_DEVICE_NOT_CONNECTED.

Reference document: WIA SDK - Common Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.1.2 WIA_DPA_CONNECT_STATUS Test Description

13.4.1.3 WIA_DPA_DEVICE_TIME

WIA_DPA_DEVICE_TIME common device property is optional. If this property exists, it shall have the WIA_PROP_NONE type, WIA_PROP_READ or WIA_PROP_RW access and shall contain a valid date stored in the format defined by the SYSTEMTIME structure. If the property has WIA_PROP_RW access, setting the property will update the time stored on the device.

Reference document: WIA SDK - Common Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.1.3 WIA_DPA_DEVICE_TIME Test Description


WIA Camera Device Properties Test Assertions

The assertions in this section are tested in:

13.4.2.1 WIA_DPC_PICTURES_TAKEN

WIA_DPC_PICTURES_TAKEN camera device property shall exist for a camera’s root item. The property shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.1 WIA_DPC_PICTURES_TAKEN Test Description

13.4.2.2 WIA_DPC_PICTURES_REMAINING

WIA_DPC_PICTURES_REMAINING camera device property shall exist for a camera’s root item. The property shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.2 WIA_DPC_PICTURES_REMAINING TEST DESCRIPTION

13.4.2.3 WIA_DPC_EXPOSURE_MODE

WIA_DPC_EXPOSURE_MODE camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.3 WIA_DPC_EXPOSURE_MODE Test Description

13.4.2.4 WIA_DPC_EXPOSURE_COMP

WIA_DPC_EXPOSURE_COMP camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access. Legal values are from -200 to 200 in increments of 50.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.4 WIA_DPC_EXPOSURE_COMP Test Description

13.4.2.5 WIA_DPC_EXPOSURE_TIME

WIA_DPC_EXPOSURE_TIME camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.5 WIA_DPC_EXPOSURE_TIME Test Description

13.4.2.6 WIA_DPC_FNUMBER

WIA_DPC_FNUMBER camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.6 WIA_DPC_FNUMBER Test Description

13.4.2.7 WIA_DPC_FLASH_MODE

WIA_DPC_FLASH_MODE camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_LIST type, the VT_I4 subtype and the WIA_PROP_RW access. Legal values are WIA_FLASH_MODE_AUTO, WIA_FLASH_MODE_FILL, WIA_FLASH_MODE_OFF and WIA_FLASH_MODE_REDEYE.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.7 WIA_DPC_FLASH_MODE Test Description

13.4.2.8 WIA_DPC_FOCUS_MODE

WIA_DPC_FOCUS_MODE camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.8 WIA_DPC_FOCUS_MODE Test Description

13.4.2.9 WIA_DPC_ZOOM_POSITION

WIA_DPC_ZOOM_POSITION camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.9 WIA_DPC_ZOOM_POSITION Test Description

13.4.2.10 WIA_DPC_PAN_POSITION

WIA_DPC_PAN_POSITION camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.10 WIA_DPC_PAN_POSITION Test Description

13.4.2.11 WIA_DPC_TILT_POSITION

WIA_DPC_TILT_POSITION camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.11 WIA_DPC_TILT_POSITION Test Description

13.4.2.12 WIA_DPC_TIMER_MODE

WIA_DPC_TIMER_MODE camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_LIST type, the VT_I4 subtype and the WIA_PROP_RW access. Legal values are: WIA_TIMER_MODE_OFF and WIA_TIMER_MODE_ON.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.12 WIA_DPC_TIMER_MODE Test Description

13.4.2.13 WIA_DPC_TIMER_VALUE

WIA_DPC_TIMER_VALUE camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.13 WIA_DPC_TIMER_VALUE Test Description

13.4.2.14 WIA_DPC_POWER_MODE

WIA_DPC_POWER_MODE camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access. Possible values are: WIA_POWER_MODE_LINE and WIA_POWER_MODE_BATTERY.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.14 WIA_DPC_POWER_MODE Test Description

13.4.2.15 WIA_DPC_BATTERY_STATUS

WIA_DPC_BATTERY_STATUS camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access. Possible values are between 0 and 100.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.15 WIA_DPC_BATTERY_STATUS Test Description

13.4.2.16 WIA_DPC_FOCUS_MANUAL_DIST

WIA_DPC_FOCUS_MANUAL_DIST camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.16 WIA_DPC_FOCUS_MANUAL_DIST Test Description

13.4.2.17 WIA_DPC_PICT_WIDTH

WIA_DPC_PICT_WIDTH camera device property is optional for a camera's root item. If this property exists, it shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access, or it may have the WIA_PROP_LIST type, VT_I4 subtype, and WIA_PROP_RW access. The number of legal values shall be the same as those of WIA_DPC_PICT_HEIGHT.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.17 WIA_DPC_PICT_WIDTH Test Description

13.4.2.18 WIA_DPC_PICT_HEIGHT

WIA_DPC_PICT_HEIGHT camera device property is optional for a camera's root item. If this property exists, it shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access, or it may have the WIA_PROP_LIST type, VT_I4 subtype, and WIA_PROP_RW access. The number of legal values shall be the same as those of WIA_DPC_PICT_WIDTH.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.18 WIA_DPC_PICT_HEIGHT Test Description

13.4.2.19 WIA_DPC_THUMB_WIDTH

WIA_DPC_THUMB_WIDTH camera device property is optional for a camera's root item. If this property exists, it shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access, or it may have the WIA_PROP_LIST type, VT_I4 subtype, and WIA_PROP_RW access. The number of legal values shall be the same as those of WIA_DPC_THUMB_HEIGHT.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.19 WIA_DPC_THUMB_WIDTH Test Description

13.4.2.20 WIA_DPC_THUMB_HEIGHT

WIA_DPC_THUMB_HEIGHT camera device property is optional for a camera's root item. If this property exists, it shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access, or it may have the WIA_PROP_LIST type, VT_I4 subtype, and WIA_PROP_RW access. The number of legal values shall be the same as those of WIA_DPC_THUMB_WIDTH.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.20 WIA_DPC_THUMB_HEIGHT Test Description

13.4.2.21 WIA_DPC_COMPRESSION_SETTING

WIA_DPC_COMPRESSION_SETTING camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access. Otherwise it has WIA_PROP_READ, the VT_I4 subtype and the WIA_PROP_NONE.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.21 WIA_DPC_COMPRESSION_SETTING Test Description

13.4.2.22 WIA_DPC_TIMELAPSE_INTERVAL

WIA_DPC_TIMELAPSE_INTERVAL camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access. Otherwise it has WIA_PROP_READ, the VT_I4 subtype and the WIA_PROP_NONE.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.22 WIA_DPC_TIMELAPSE_INTERVAL Test Description

13.4.2.23 WIA_DPC_TIMELAPSE_NUMBER

WIA_DPC_TIMELAPSE_NUMBER camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access. Otherwise it has WIA_PROP_READ, the VT_I4 subtype and the WIA_PROP_NONE.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.23 WIA_DPC_TIMELAPSE_NUMBER Test Description

13.4.2.24 WIA_DPC_BURST_INTERVAL

WIA_DPC_BURST_INTERVAL camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access. Otherwise it has WIA_PROP_READ, the VT_I4 subtype and the WIA_PROP_NONE.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.24 WIA_DPC_BURST_INTERVAL Test Description

13.4.2.25 WIA_DPC_BURST_NUMBER

WIA_DPC_BURST_NUMBER camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access. Otherwise it has WIA_PROP_READ, the VT_I4 subtype and the WIA_PROP_NONE.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.25 WIA_DPC_BURST_NUMBER Test Description

13.4.2.26 WIA_DPC_EFFECT_MODE

WIA_DPC_EFFECT_MODE camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access. Otherwise it has WIA_PROP_READ, the VT_I4 subtype and the WIA_PROP_NONE.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.26 WIA_DPC_EFFECT_MODE Test Description

13.4.2.27 WIA_DPC_DIGITAL_ZOOM

WIA_DPC_DIGITAL_ZOOM camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access. Otherwise it has WIA_PROP_READ, the VT_I4 subtype and the WIA_PROP_NONE.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.27 WIA_DPC_DIGITAL_ZOOM Test Description

13.4.2.28 WIA_DPC_SHARPNESS

WIA_DPC_SHARPNESS camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access. Otherwise it has WIA_PROP_READ, the VT_I4 subtype and the WIA_PROP_NONE.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.28 WIA_DPC_SHARPNESS Test Description

13.4.2.29 WIA_DPC_CONTRAST

WIA_DPC_CONTRAST camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access. Otherwise it has WIA_PROP_READ, the VT_I4 subtype and the WIA_PROP_NONE.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.29 WIA_DPC_CONTRAST Test Description

13.4.2.30 WIA_DPC_CAPTURE_MODE

WIA_DPC_CAPTURE_MODE camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access. Otherwise it has WIA_PROP_READ, the VT_I4 subtype and the WIA_PROP_NONE.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.30 WIA_DPC_CAPTURE_MODE Test Description

13.4.2.31 WIA_DPC_CAPTURE_DELAY

WIA_DPC_CAPTURE_DELAY camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access. Otherwise it has WIA_PROP_READ, the VT_I4 subtype and the WIA_PROP_NONE.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.31 WIA_DPC_CAPTURE_DELAY Test Description

13.4.2.32 WIA_DPC_EXPOSURE_INDEX

WIA_DPC_EXPOSURE_INDEX camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access. Otherwise it has WIA_PROP_READ, the VT_I4 subtype and the WIA_PROP_NONE.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.32 WIA_DPC_EXPOSURE_INDEX Test Description

13.4.2.33 WIA_DPC_EXPOSURE_METERING_MODE

WIA_DPC_EXPOSURE_METERING_MODE camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access. Otherwise it has WIA_PROP_READ, the VT_I4 subtype and the WIA_PROP_NONE.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2..33 WIA_DPC_EXPOSURE_METERING_MODE Test Description

13.4.2.34 WIA_DPC_FOCUS_METERING_MODE

WIA_DPC_FOCUS_METERING_MODE camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access. Otherwise it has WIA_PROP_READ, the VT_I4 subtype and the WIA_PROP_NONE.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.34 WIA_DPC_FOCUS_METERING_MODE Test Description

13.4.2.35 WIA_DPC_FOCUS_DISTANCE

WIA_DPC_FOCUS_DISTANCE camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access. Otherwise it has WIA_PROP_READ, the VT_I4 subtype and the WIA_PROP_NONE.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.35 WIA_DPC_FOCUS_DISTANCE Test Description

13.4.2.36 WIA_DPC_FOCAL_LENGTH

WIA_DPC_FOCAL_LENGTH camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access. Otherwise it has WIA_PROP_READ, the VT_I4 subtype and the WIA_PROP_NONE.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.36 WIA_DPC_FOCAL_LENGTH Test Description

13.4.2.37 WIA_DPC_RGB_GAIN

WIA_DPC_RGB_GAIN camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access. Otherwise it has WIA_PROP_READ, the VT_I4 subtype and the WIA_PROP_NONE.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.37 WIA_DPC_RGB_GAIN Test Description

13.4.2.38 WIA_DPC_WHITE_BALANCE

WIA_DPC_WHITE_BALANCE camera device property is optional for a camera’s root item. If this property exists, it shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access. Otherwise it has WIA_PROP_READ, the VT_I4 subtype and the WIA_PROP_NONE.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.38 WIA_DPC_WHITE_BALANCE Test Description

13.4.2.39 WIA_DPC_UPLOAD_URL

WIA_DPC_UPLOAD_URL camera device property is optional for a camera's root item. If this property exists, it shall have the WIA_PROP_NONE type, the VT_BSTR subtype and the WIA_PROP_RW access.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.39 WIA_DPC_UPLOAD_URL Test Description

13.4.2.40 WIA_DPC_ARTIST

WIA_DPC_ARTIST camera device property is optional for a camera's root item. If this property exists, it shall have the WIA_PROP_NONE type, the VT_BSTR subtype and the WIA_PROP_RW access.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.40 WIA_DPC_ARTIST Test Description

13.4.2.41 WIA_DPC_COPYRIGHT_INFO

WIA_DPC_COPYRIGHT_INFO camera device property is optional for a camera's root item. If this property exists, it shall have the WIA_PROP_NONE type, the VT_BSTR subtype and the WIA_PROP_RW access.

Reference document: WIA SDK - Camera Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.2.41 WIA_DPC_COPYRIGHT_INFO Test Description


WIA Scanner Device Properties Test Assertions

13.4.3.1 WIA_DPS_HORIZONTAL_BED_SIZE

WIA_DPS_HORIZONTAL_BED_SIZE scanner device property shall exist for a flatbed scanner root item. The property shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Scanner Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.3.1 WIA_DPS_HORIZONTAL_BED_SIZE Test Description

13.4.3.2 WIA_DPS_VERTICAL_BED_SIZE

WIA_DPS_VERTICAL_BED_SIZE scanner device property shall exist for a flatbed scanner root item. The property shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Scanner Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.3.2 WIA_DPS_VERTICAL_BED_SIZE Test Description

13.4.3.3 WIA_DPS_HORIZONTAL_SHEET_FEED_SIZE

WIA_DPS_HORIZONTAL_SHEET_FEED_SIZE scanner device property shall exist for a sheet-fed or hand-held scanner root item. The property shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Scanner Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.3.3 WIA_DPS_HORIZONTAL_SHEET_FEED_SIZE Test Description

13.4.3.4 WIA_DPS_VERTICAL_SHEET_FEED_SIZE

WIA_DPS_VERTICAL_SHEET_FEED_SIZE scanner device property shall exist for a sheet-fed or a hand-held scanner root item. The property shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Scanner Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.3.4 WIA_DPS_VERTICAL_SHEET_FEED_SIZE Test Description

13.4.3.5 WIA_DPS_SHEET_FEEDER_REGISTRATION

WIA_DPS_SHEET_FEEDER_REGISTRATION scanner device property is optional for a sheet-fed or a hand-held scanner root item. If the property exists, it shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Scanner Device Property Constants; WLP# - B9.1.1.1;PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.3.5 WIA_DPS_SHEET_FEEDER_REGISTRATION Test Description

13.4.3.6 WIA_DPS_HORIZONTAL_BED_REGISTRATION

WIA_DPS_HORIZONTAL_BED_REGISTRATION scanner device property is optional for a flatbed scanner root item. If the property exists, it shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Scanner Device Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.3.5 WIA_DPS_SHEET_FEEDER_REGISTRATION Test Description

13.4.3.7 WIA_DPS_VERTICAL_BED_REGISTRATION

WIA_DPS_VERTICAL_BED_REGISTRATION scanner device property is optional for a flatbed scanner root item. If the property exists, it shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Scanner Device Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD 13.4.3.7 WIA_DPS_VERTICAL_BED_REGISTRATION Test Description

13.4.3.8 WIA_DPS_PAD_COLOR

WIA_DPS_PAD_COLOR scanner device property is optional for a scanner root item. If the property exists, it shall have the WIA_PROP_NONE type, the RGBQUAD. NOTE: If the device allows the pad color to be set, this property should have an access of read/write. For all others it shall be read-only.

Reference document: WIA SDK - Scanner Device Property Constants; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.3.8 WIA_DPS_PAD_COLOR Test Description

13.4.3.9 WIA_DPS_DOCUMENT_HANDLING_CAPABILITIES

WIA_DPS_DOCUMENT_HANDLING_CAPABILITIES scanner device property shall exist for a scanner root item. The property shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Scanner Device Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.3.9 WIA_DPS_DOCUMENT_HANDLING_CAPABILITIES Test Description

13.4.3.10 WIA_DPS_DOCUMENT_HANDLING_STATUS

WIA_DPS_DOCUMENT_HANDLING_STATUS scanner device property is optional for a scanner root item. If this property exists, it shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Scanner Device Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.3.10 WIA_DPS_DOCUMENT_HANDLING_STATUS Test Description

13.4.3.11 WIA_DPS_DOCUMENT_HANDLING_SELECT

WIA_DPS_DOCUMENT_HANDLING_SELECT scanner device property is optional for a scanner root item. If this property exists, it shall have the WIA_PROP_FLAG type, the VT_I4 subtype and the WIA_PROP_RW access. Legal flags are: FEEDER, FLATBED, DUPLEX, FRONT_FIRST, BACK_FIRST, FRONT_ONLY, BACK_ONLY, NEXT_PAGE, PREFEED, and AUTO_ADVANCE. Expected property values are valid combinations of the above flags

Reference document: WIA SDK - Scanner Device Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.3.11 WIA_DPS_DOCUMENT_HANDLING_SELECT Test Description

13.4.3.12 WIA_DPS_DOCUMENT_HANDLING_CAPACITY

WIA_DPS_DOCUMENT_HANDLING_CAPACITY scanner device property shall exist for a scanner root item. The property shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Scanner Device Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.3.12 WIA_DPS_DOCUMENT_HANDLING_CAPACITY Test Description

13.4.3.13 WIA_DPS_OPTICAL_XRES

WIA_DPS_OPTICAL_XRES scanner device property shall exist for a scanner root item. The property shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access. The property shall have a value greater than zero and less than 100,000.

Reference document: WIA SDK - Scanner Device Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.3.13 WIA_DPS_OPTICAL_XRES Test Description

13.4.3.14 WIA_DPS_OPTICAL_YRES

WIA_DPS_OPTICAL_YRES scanner device property shall exist for a scanner root item. The property shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access. The property shall have a value greater than zero and less than 100,000.

Reference document: WIA SDK - Scanner Device Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.3.14 WIA_DPS_OPTICAL_YRES Test Description

13.4.3.15 WIA_DPS_PLATEN_COLOR

WIA_DPS_PLATEN_COLOR scanner device property is optional for a scanner root item. If this property exists, it shall have the WIA_PROP_NONE type, the RGBQUAD subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Scanner Device Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.3.15 WIA_DPS_PLATEN_COLOR Test Description

13.4.3.16 WIA_DPS_ENDORSER_CHARACTERS

WIA_DPS_ENDORSER_CHARACTERS scanner device property is optional for a scanner root item. If this property exists, it shall have the WIA_PROP_NONE type, the VT_BSTR subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Scanner Device Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.3.16 WIA_DPS_ENDORSER_CHARACTERS Test Description

13.4.3.17 WIA_DPS_ENDORSER_STRING

WIA_DPS_ENDORSER_STRING scanner device property is optional for a scanner root item. If this property exists, it shall have the WIA_PROP_NONE type, the VT_BSTR subtype and the WIA_PROP_RW access.

Reference document: WIA SDK - Scanner Device Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.3.17 WIA_DPS_ENDORSER_STRING Test Description

13.4.3.18 WIA_DPS_SCAN_AHEAD_PAGES

WIA_DPS_SCAN_AHEAD_PAGES scanner device property is optional for a scanner root item. If this property exists, it shall have the WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access.

Reference document: WIA SDK - Scanner Device Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.3.18 WIA_DPS_SCAN_AHEAD_PAGES Test Description

13.4.3.19 WIA_DPS_MAX_SCAN_TIME

WIA_DPS_MAX_SCAN_TIME scanner device property shall exists for a scanner root item. The property shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Scanner Device Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.3.19 WIA_DPS_MAX_SCAN_TIME Test Description

13.4.3.20 WIA_DPS_PAGES

WIA_DPS_PAGES scanner device property is optional for a scanner root item. If this property exists, it shall have the WIA_PROP_LIST type, the VT_I4 subtype and the WIA_PROP_RW access.

Reference document: WIA SDK - Scanner Device Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.3.20 WIA_DPS_PAGES Test Description

13.4.3.21 WIA_DPS_PAGE_SIZE

WIA_DPS_PAGE_SIZE scanner device property is optional for a scanner root item. If this property exists, it shall have the WIA_PROP_LIST type, the VT_I4 subtype and the WIA_PROP_RW access.

Reference document: WIA SDK - Scanner Device Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD- 13.4.3.21 WIA_DPS_PAGE_SIZE Test Description

13.4.3.22 WIA_DPS_TRANSPARENCY

WIA_DPS_TRANSPARENCY scanner device property is optional for a scanner root item. If this property exists, it shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Scanner Device Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.3.22 WIA_DPS_TRANSPARENCY Test Description

13.4.3.23 WIA_DPS_TRANSPARENCY_SELECT

WIA_DPS_TRANSPARENCY_SELECT scanner device property is optional for a scanner root item. If this property exists, it shall have the WIA_PROP_FLAG type, the VT_I4 subtype and the WIA_PROP_RW access.

Reference document: WIA SDK - Scanner Device Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.3.23 WIA_DPS_TRANSPARENCY_SELECT Test Description

13.4.3.24 WIA_DPS_PAGE_WIDTH

WIA_DPS_PAGE_WIDTH scanner device property is optional for a scanner root item. If this property exists, it shall have the WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access.

Reference document: WIA SDK - Scanner Device Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.3.24 WIA_DPS_PAGE_WIDTH Test Description

13.4.3.25 WIA_DPS_PAGE_HEIGHT

WIA_DPS_PAGE_HEIGHT scanner device property is optional for a scanner root item. If this property exists, it shall have the WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access.

Reference document: WIA SDK - Scanner Device Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.3.25 WIA_DPS_PAGE_HEIGHT Test Description

13.4.3.26 WIA_DPS_PREVIEW

WIA_DPS_PREVIEW scanner device property is optional for a scanner root item. If this property exists, it shall have the WIA_PROP_LIST type, the VT_I4 subtype and the WIA_PROP_RW access.

Reference document: WIA SDK - Scanner Device Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.3.26 WIA_DPS_PREVIEW Test Description

13.4.3.27 WIA_DPS_MIN_HORIZONTAL_SHEET_FEED_SIZE

WIA_DPS_MIN_HORIZONTAL_SHEET_FEED_SIZE scanner device property shall exist for a sheet-fed or hand-held scanner root item. The property shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Scanner Device Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.3.27 WIA_DPS_MIN_HORIZONTAL_SHEET_FEED_SIZE Test Description

13.4.3.28 WIA_DPS_MIN_VERTICAL_SHEET_FEED_SIZE

WIA_DPS_MIN_VERTICAL_SHEET_FEED_SIZE scanner device property is optional for a sheet-fed or a hand-held scanner root item. The property shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Scanner Device Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.3.28 WIA_DPS_MIN_VERTICAL_SHEET_FEED_SIZE Test Description

13.4.3.29 WIA_DPS_SHOW_PREVIEW_CONTROL

WIA_DPS_SHOW_PREVIEW_CONTROL scanner device property is optional for a scanner root item. The property shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Scanner Device Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.3.29 WIA_DPS_SHOW_PREVIEW_CONTROL Test Description


WIA Common Item Properties Test Assertions

13.4.4.1 WIA_IPA_ITEM_NAME

WIA_IPA_ITEM_NAME common item property shall exist for all items. The property shall have the WIA_PROP_NONE type, the VT_BSTR subtype and the WIA_PROP_READ access. For the root item, the value of this property shall be "Root".

Reference document: WIA SDK - Common WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.4.1 WIA_IPA_ITEM_NAME Test Description

13.4.4.2 WIA_IPA_FULL_ITEM_NAME

WIA_IPA_FULL_ITEM_NAME common item property shall exist for all items. The property shall have the WIA_PROP_NONE type, the VT_BSTR subtype and the WIA_PROP_READ access. For the root item, the value of this property shall be "\0001\Root", where 0001 is the same number as the number in the WIA_DIP_DEV_ID.

Reference document: WIA SDK - Common WIA Item Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.4.2 WIA_IPA_FULL_ITEM_NAME Test Description

13.4.4.3 WIA_IPA_ITEM_FLAGS

WIA_IPA_ITEM_FLAGS common item property shall exist for all items. The property shall have the WIA_PROP_FLAG type, the VT_I4 subtype and the WIA_PROP_READ access. The root item shall have only the flags WiaItemTypeDevice, WiaItemTypeRoot and WiaItemTypeFolder set.

Reference document: WIA SDK - Common WIA Item Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.4.3 WIA_IPA_ITEM_FLAGS Test Description

13.4.4.4 WIA_IPA_ITEM_TIME

WIA_IPA_ITEM_TIME common item property shall exist for all items. The property shall have the WIA_PROP_NONE type, the VT_I4 | VT_VECTOR subtype and the WIA_PROP_READ access. Time is reported in the SYSTEMTIME format.

Reference document: WIA SDK - Common WIA Item Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.4.4 WIA_IPA_ITEM_TIME Test Description

13.4.4.5 WIA_IPA_ACCESS_RIGHTS

WIA_IPA_ACCESS_RIGHTS common item property shall exist for all items. The property shall have the WIA_PROP_NONE type, the VT_I4 subtype, the WIA_PROP_READ access for scanners and the WIA_PROP_FLAG type, the VT_I4 subtype, the WIA_PROP_RW access for cameras. Legal values for this property are: WIA_ITEM_READ, WIA_ITEM_WRITE, WIA_ITEM_RD, WIA_ITEM_RWD or WIA_ITEM_CAN_BE_DELETED.

Reference document: WIA SDK - Common WIA Item Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.4.5 WIA_IPA_ACCESS_RIGHTS Test Description

13.4.4.6 WIA_IPA_DATATYPE

WIA_IPA_DATATYPE common item property shall exist for all items. The property shall have the WIA_PROP_NONE type, the VT_I4 subtype, the WIA_PROP_READ access for cameras and the WIA_PROP_LIST type, the VT_I4 subtype, the WIA_PROP_RW access for scanners. Legal values for this property are: WIA_DATA_THRESHOLD, WIA_DATA_DITHER, WIA_DATA_GRAYSCALE, WIA_DATA_COLOR, WIA_DATA_COLOR_THRESHOLD and WIA_DATA_COLOR_DITHER.

Reference document: WIA SDK - Common WIA Item Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.4.6 WIA_IPA_DATATYPE Test Description

13.4.4.7 WIA_IPA_DEPTH

WIA_IPA_DEPTH common item property shall exist for all items. The property shall have the VT_I4 subtype. On devices that allow only a single color-space resolution per data type the property has READ access and WIA_PROP_NONE type; otherwise it has RW access and WIA_PROP_LIST type. For cameras, this property has always READ access and WIA_PROP_NONE type.

Reference document: WIA SDK - Common WIA Item Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.4.7 WIA_IPA_DEPTH Test Description

13.4.4.8 WIA_IPA_PREFERRED_FORMAT

WIA_IPA_PREFERRED_FORMAT common item property shall exist for all items. The property shall have the WIA_PROP_NONE type, the VT_CLSID subtype and the WIA_PROP_READ access. Legal values for this property are: IMGFMT_MEMORYBMP, IMGFMT_BMP, IMGFMT_EMF, IMGFMT_WMF, IMGFMT_JPEG, IMGFMT_PNG, IMGFMT_GIF, IMGFMT_TIFF, IMGFMT_EXIF, IMGFMT_PHOTOCD, IMGFMT_FLASHPIX, IMGFMT_ICO.

Reference document: WIA SDK - Common WIA Item Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.4.8 WIA_IPA_PREFERRED_FORMAT Test Description

13.4.4.9 WIA_IPA_FORMAT

WIA_IPA_FORMAT common item property shall exist for all items. The property shall have the WIA_PROP_LIST type, the VT_CLSID subtype and the WIA_PROP_READ access for cameras and RW for scanners. Possible values for this property are: IMGFMT_MEMORYBMP, IMGFMT_BMP, IMGFMT_EMF, IMGFMT_WMF, IMGFMT_JPEG, IMGFMT_PNG, IMGFMT_GIF, IMGFMT_TIFF, IMGFMT_EXIF, IMGFMT_PHOTOCD, IMGFMT_FLASHPIX, IMGFMT_ICO. When WIA_IPA_TYMED is set to TYMED_CALLBACK, the valid values for this property include at least IMGFMT_MEMORYBMP. When WIA_IPA_TYMED is set to TYMED_FILE, the valid values for this property include at least IMGFMT_BMP

Reference documents: WIA SDK - Common WIA Item Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.4.9 WIA_IPA_FORMAT Test Description

13.4.4.10 WIA_IPA_COMPRESSION

WIA_IPA_COMPRESSION common item property shall exist for all items. If the device supports more than one compression type, the property shall have the WIA_PROP_LIST type, the VT_I4 subtype and the WIA_PROP_RW access. Otherwise, the property shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Legal values for this property are: WIA_COMPRESSION_NONE, WIA_COMPRESSION_BI_RLE4, WIA_COMPRESSION_BI_RLE8 and WIA_COMPRESSION_G3.

Reference document: WIA SDK - Common WIA Item Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.4.10 WIA_IPA_COMPRESSION Test Description

13.4.4.11 WIA_IPA_TYMED

WIA_IPA_TYMED common item property shall exist for all items. The property shall have the WIA_PROP_LIST type, the VT_I4 subtype and the WIA_PROP_RW access. The valid values for this property shall include TYMED_CALLBACK and TYMED_FILE.

Reference document: WIA SDK - Common WIA Item Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.4.11 WIA_IPA_TYMED Test Description

13.4.4.12 WIA_IPA_CHANNELS_PER_PIXEL

WIA_IPA_CHANNELS_PER_PIXEL common item property shall exist for all items. The property shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Common WIA Item Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.4.12 WIA_IPA_CHANNELS_PER_PIXEL Test Description

13.4.4.13 WIA_IPA_BITS_PER_CHANNEL

WIA_IPA_BITS_PER_CHANNEL common item property shall exist for all items. If the device supports the setting of the number of bits per channel, the property shall have the WIA_PROP_LIST type, the VT_I4 subtype and the WIA_PROP_RW access. Otherwise, the property shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Common WIA Item Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.4.13 WIA_IPA_BITS_PER_CHANNELTest Description

13.4.4.14 WIA_IPA_PLANAR

WIA_IPA_PLANAR common item property shall exist for all items. The property shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access. Possible values for this property are: WIA_PACKED_PIXEL and WIA_PLANAR.

Reference document: WIA SDK - Common WIA Item Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.4.14 WIA_IPA_PLANAR Test Description

13.4.4.15 WIA_IPA_PIXELS_PER_LINE

WIA_IPA_PIXELS_PER_LINE common item property shall exist for all items. The property shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Common WIA Item Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.4.15 WIA_IPA_PIXELS_PER_LINE Test Description

13.4.4.16 WIA_IPA_BYTES_PER_LINE

WIA_IPA_BYTES_PER_LINE common item property shall exist for all items. The property shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Common WIA Item Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.4.16 WIA_IPA_BYTES_PER_LINE Test Description

13.4.4.17 WIA_IPA_NUMBER_OF_LINES

WIA_IPA_NUMBER_OF_LINES common item property shall exist for all items. The property shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Common WIA Item Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.4.17 WIA_IPA_NUMBER_OF_LINES Test Description

13.4.4.18 WIA_IPA_GAMMA_CURVES

WIA_IPA_GAMMA_CURVES common item property is optional. If the property exists, it shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access.

Reference document: WIA SDK - Common WIA Item Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.4.18 WIA_IPA_GAMMA_CURVES Test Description

13.4.4.19 WIA_IPA_ITEM_SIZE

WIA_IPA_ITEM_SIZE common item property shall exist for all items. The property shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Common WIA Item Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.4.19 WIA_IPA_ITEM_SIZE Test Description

13.4.4.20 WIA_IPA_MIN_BUFFER_SIZE

WIA_IPA_MIN_BUFFER_SIZE common item property shall exist for all items. The property shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Common WIA Item Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.4.20 WIA_IPA_MIN_BUFFER_SIZE Test Description

13.4.4.21 WIA_IPA_REGION_TYPE

WIA_IPA_REGION_TYPE common item property is optional. If the property exists, it shall have the WIA_PROP_NONE type, the VT_BSTR subtype and the WIA_PROP_READ access. Possible values for this property are: WIA_TEXT_ITEM, WIA_PHOTO_ITEM, WIA_DRAWING_ITEM, WIA_LOGO_ITEM, WIA_HANDWRITING_ITEM, WIA_CHART_ITEM, WIA_TABLE_ITEM.

Reference document: WIA SDK - Common WIA Item Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.4.21 WIA_IPA_REGION_TYPE Test Description

13.4.4.22 WIA_IPA_ICM_PROFILE_NAME

WIA_IPA_ICM_PROFILE_NAME common item property shall exist for all items. The property shall have the WIA_PROP_LIST type, the VT_BSTR subtype and the WIA_PROP_RW access.

Reference document: WIA SDK - Common WIA Item Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.4.22 WIA_IPA_ICM_PROFILE_NAME Test Description

13.4.4.23 WIA_IPA_APP_COLOR_MAPPING

WIA_IPA_APP_COLOR_MAPPING common item property is optional. If the property exists, it shall have the WIA_PROP_LIST type, the VT_I4 subtype and the WIA_PROP_RW access.

Reference document: WIA SDK - Common WIA Item Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.4.23 WIA_IPA_APP_COLOR_MAPPING Test Description

13.4.4.24 WIA_IPA_PROP_STREAM_COMPAT_ID

WIA_IPA_PROP_STREAM_COMPAT_ID common item property is optional. If the property exists, it shall have the WIA_PROP_LIST type, the VT_CLSID subtype and the WIA_PROP_RW access.

Reference document: WIA SDK - Common WIA Item Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.4.24 WIA_IPA_PROP_STREAM_COMPAT_ID Test Description

13.4.4.25 WIA_IPA_FILENAME_EXTENSION

WIA_IPA_FILENAME_EXTENSION common item property is optional. If the property exists, it shall have the WIA_PROP_NONE type, the VT_BSTR subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Common WIA Item Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.4.25 WIA_IPA_FILENAME_EXTENSION Test Description

13.4.4.26 WIA_IPA_SUPPRESS_PROPERTY_PAGE

WIA_IPA_SUPPRESS_PROPERTY_PAGE common item property is optional. If the property exists, it shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Common WIA Item Property Constants; WLP# - B9.1.1.1; PC 2001 System Design Guide -IMAG-0317.

Test Description: TD-13.4.4.26 WIA_IPA_SUPPRESS_PROPERTY_PAGE Test Description


WIA Camera Item Properties Test Assertions

13.4.5.1 WIA_IPC_THUMBNAIL

WIA_IPC_THUMBNAIL camera item property shall exist for all image-type items on a camera device. The property shall have the WIA_PROP_NONE type, the VT_UI1 | VT_VECTOR subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Camera WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.5.1 WIA_IPC_THUMBNAIL Test Description

13.4.5.2 WIA_IPC_THUMB_WIDTH

WIA_IPC_THUMB_WIDTH camera item property shall exist for all image-type items on a camera device. The property shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Camera WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.5.2 WIA_IPC_THUMB_WIDTH Test Description

13.4.5.3 WIA_IPC_THUMB_HEIGHT

WIA_IPC_THUMB_HEIGHT camera item property shall exist for all image-type items on a camera device. The property shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Camera WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.5.3 WIA_IPC_THUMB_HEIGHT Test Description

13.4.5.4 WIA_IPC_AUDIO_AVAILABLE

WIA_IPC_AUDIO_AVAILABLE camera item property is optional for all image-type items on a camera device. If the property exists, it shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Camera WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.5.4 WIA_IPC_AUDIO_AVAILABLETest Description

13.4.5.5 WIA_IPC_AUDIO_DATA_FORMAT

WIA_IPC_AUDIO_DATA_FORMAT common item property is optional for all image-type items on a camera device. If the property exists, it shall have the WIA_PROP_NONE type, the VT_CLSID subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Camera WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.5.5 WIA_IPC_AUDIO_DATA_FORMAT Test Description

13.4.5.6 WIA_IPC_AUDIO_DATA

WIA_IPC_AUDIO_DATA common item property is optional for all image-type items on a camera device. This property shall exist for each item in the tree that has the WIA_IPC_AUDIO_AVAILABLE property set. If the property exists, it shall have the WIA_PROP_NONE type, the VT_UI1 | VT_VECTOR subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Camera WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.5.6 WIA_IPC_AUDIO_DATA Test Description

13.4.5.7 WIA_IPC_SEQUENCE

WIA_IPC_SEQUENCE camera item property is optional for all image-type items on a camera device. If the property exists, it shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Common WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.5.7 WIA_IPC_SEQUENCE Test Description

13.4.5.8 WIA_IPC_TIMEDELAY

WIA_IPC_TIMEDELAY camera item property is optional for all image-type items on a camera device. If the property exists, it shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Common WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.5.8 WIA_IPC_TIMEDELAY Test Description

13.4.5.9 WIA_IPC_NUM_PICT_PER_ROW

WIA_IPC_NUM_PICT_PER_ROW camera item property is optional for all folder-type items on a camera device. If the property exists, it shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Common WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.5.9 WIA_IPC_NUM_PICT_PER_ROW Test Description


WIA Scanner Item Properties Test Assertions

13.4.6.1 WIA_IPS_CUR_INTENT

WIA_IPS_CUR_INTENT scanner item property shall exist for all image-type items on a scanner device. The property shall have the WIA_PROP_FLAG type, the VT_I4 subtype and the WIA_PROP_RW access. Valid flags for this property are: WIA_INTENT_NONE, WIA_INTENT_IMAGE_TYPE_COLOR, WIA_INTENT_IMAGE_TYPE_GRAYSCALE, WIA_INTENT_IMAGE_TYPE_TEXT (image type flags); WIA_INTENT_MINIMIZE_SIZE, WIA_INTENT_MAXIMIZE_QUALITY (size/quality flags). The current property value should be an image type flag, possibly OR’ed with a size/quality flag.

Reference document: WIA SDK - Scanner WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.6.1 WIA_IPS_CUR_INTENT Test Description

13.4.6.2 WIA_IPS_XRES

WIA_IPS_XRES scanner item property shall exist for all image-type items on a scanner device. The property shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access.

Reference document: WIA SDK - Scanner WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.6.2 WIA_IPS_XRES Test Description

13.4.6.3 WIA_IPS_YRES

WIA_IPS_YRES scanner item property shall exist for all image-type items on a scanner device. If the device supports the independent setting of horizontal and vertical resolutions, the property shall have the WIA_PROP_LIST or the WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access. Otherwise, the property shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Scanner WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.6.3 WIA_IPS_YRES Test Description

13.4.6.4 WIA_IPS_XPOS

WIA_IPS_XPOS scanner item property shall exist for all image-type items on a scanner device. The property shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access.

Reference document: WIA SDK - Scanner WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.6.4 WIA_IPS_XPOS Test Description

13.4.6.5 WIA_IPS_YPOS

WIA_IPS_YPOS scanner item property shall exist for all image-type items on a scanner device. The property shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access.

Reference document: WIA SDK - Scanner WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.6.5 WIA_IPS_YPOS Test Description

13.4.6.6 WIA_IPS_XEXTENT

WIA_IPS_XEXTENT scanner item property shall exist for all image-type items on a scanner device. The property shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access.

Reference document: WIA SDK - Scanner WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.6.6 WIA_IPS_XEXTENT Test Description

13.4.6.7 WIA_IPS_YEXTENT

WIA_IPS_YEXTENT scanner item property shall exist for all image-type items on a scanner device. The property shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access.

Reference document: WIA SDK - Scanner WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.6.7 WIA_IPS_YEXTENT Test Description

13.4.6.8 WIA_IPS_PHOTOMETRIC_INTERP

WIA_IPS_PHOTOMETRIC_INTERP scanner item property shall exist for all image-type items on a scanner device. If the device supports selectable photometric interpretation, the property shall have the WIA_PROP_LIST type, the VT_I4 subtype and the WIA_PROP_RW access. Otherwise the property shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access. Valid values for this property are: WIA_PHOTO_WHITE_1 and WIA_PHOTO_WHITE_0.

Reference document: WIA SDK - Scanner WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.6.8 WIA_IPS_PHOTOMETRIC_INTERP Test Description

13.4.6.9 WIA_IPS_BRIGHTNESS

WIA_IPS_BRIGHTNESS scanner item property shall exist for all image-type items on a scanner device. The property shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access. Legal values for this property are: WIA_BRIGHTNESS_AUTO, WIA_BRIGHTNESS_LIGHT, WIA_BRIGHTNESS_NORM, WIA_BRIGHTNESS_DARK or a value between -1000 and 1000.

Reference document: WIA SDK - Scanner WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.6.9 WIA_IPS_BRIGHTNESS Test Description

13.4.6.10 WIA_IPS_CONTRAST

WIA_IPS_CONTRAST scanner item property shall exist for all image-type items on a scanner device. The property shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access. Legal values for this property are: WIA_CONTRAST_AUTO or a value between -1000 and 1000.

Reference document: WIA SDK - Scanner WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.6.10 WIA_IPS_CONTRAST Test Description

13.4.6.11 WIA_IPS_ORIENTATION

WIA_IPS_ORIENTATION scanner item property is optional. This property applies to all image-type items on a scanner device. If a scanner can support the detection of document orientation, this property will be implemented. If the property exists, it shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access. Valid values for this property are: WIA_PORTRAIT, WIA_LANDSCAPE, WIA_ROT180 and WIA_ROT270.

Reference document: WIA SDK - Scanner WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.6.11 WIA_IPS_ORIENTATION Test Description

13.4.6.12 WIA_IPS_ROTATION

WIA_IPS_ROTATION scanner item property is optional. This property applies to all image-type items on a scanner device. If a scanner supports internal rotation during scanning, this property will be implemented. If the property exists, it shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_RW access. Legal values for this property are: WIA_PORTRAIT, WIA_LANDSCAPE, WIA_ROT180 and WIA_ROT270.

Reference document: WIA SDK - Scanner WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.6.12 WIA_IPS_ROTATION Test Description

13.4.6.13 WIA_IPS_MIRROR

WIA_IPS_MIRROR scanner item property is optional. This property applies to all image-type items on a scanner device. If a scanner can support the detection of document mirroring, this property is implemented with WIA_PROP_READ access. If a scanner supports mirroring during scanning, this property is implemented with WIA_PROP_RW access. If the property exists, it shall have the VT_I4 subtype; the WIA_PROP_NONE type if the property is read only or WIA_PROP_LIST if the property is r/w. Legal values for this property are: WIA_MIRRORED.

Reference document: WIA SDK - Scanner WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.6.13 WIA_IPS_MIRROR Test Description

13.4.6.14 WIA_IPS_THRESHOLD

WIA_IPS_THRESHOLD scanner item property shall exist for all image-type items on a scanner device. The property shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access.

Reference document: WIA SDK - Scanner WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.6.14 WIA_IPS_THRESHOLD Test Description

13.4.6.15 WIA_IPS_PREVIEW

WIA_IPS_PREVIEW scanner item property is optional. This property applies to all image-type items on a scanner device. If the property exists, it shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access.

Reference document: WIA SDK - Scanner WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.6.15 WIA_IPS_PREVIEW Test Description

13.4.6.16 WIA_IPS_INVERT

WIA_IPS_INVERT scanner item property is optional. This property applies to all image-type items on a scanner device. If the property exists, it shall have the WIA_PROP_LIST or WIA_PROP_RANGE type, the VT_I4 subtype and the WIA_PROP_RW access.

Reference document: WIA SDK - Scanner WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.6.16 WIA_IPS_INVERT Test Description

13.4.6.17 WIA_IPS_WARM_UP_TIME

WIA_IPS_WARM_UP_TIME scanner item property is optional. This property applies to all image-type items on a scanner device. If the property exists, it shall have the WIA_PROP_NONE type, the VT_I4 subtype and the WIA_PROP_READ access.

Reference document: WIA SDK - Scanner WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.6.17 WIA_IPS_WARM_UP_TIME Test Description


WIA Interdependencies Tests Test Assertions

13.4.7.1 WIA_IPA_TYMED

(WIA_IPA_TYMED) If the device is a scanner, changing the current value of this property shall cause the current and valid values of the WIA_IPA_FORMAT and WIA_IPA_PREFERRED_FORMAT properties to change to formats listed by the structure returned from drvGetWiaFormatInfo.

Reference document: WIA SDK - Common WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

WIA DDK - IWiaMiniDrv::drvGetWiaFormatInfo.

Test Description: TD-13.4.7.1 WIA_IPA_TYMED Test Description

13.4.7.2 WIA_IPS_INTENT

(WIA_IPS_INTENT) If the device is a scanner, when changing the current value of this property to a value of IMAGE_TYPE_COLOR, IMAGE_TYPE_GRAYSCALE, or IMAGE_TYPE_TEXT (and that value is in the set of valid values), the WIA_IPA_DATATYPE property must be set appropriately

Reference document: WIA SDK - Scanner WIA Item Property Constants, Common WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.7.2 WIA_IPS_INTENT Test Description

13.4.7.3 WIA_IPA_DATATYPE

(WIA_IPA_DATATYPE) If the device is a scanner, when the current value of this property is changed, the current values of the following properties shall be updated correctly: WIA_IPA_CHANNELS_PER_PIXEL, WIA_IPA_BITS_PER_CHANNEL, WIA_IPA_PLANAR, WIA_IPA_DEPTH, WIA_IPA_ITEM_SIZE

Reference document: WIA SDK - Scanner WIA Item Property Constants, Common WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.7.3 WIA_IPA_DATATYPE Test Description

13.4.7.4 WIA_IPS_XRES

(WIA_IPS_XRES) If the device is a scanner, when the current value of this property is changed, the current and valid values of the following properties shall be proportionally changed: WIA_IPS_XPOS, WIA_IPS_XEXTENT, WIA_IPA_PIXELS_PER_LINE, WIA_IPA_BYTES_PER_LINE, WIA_IPA_ITEM_SIZE. If the WIA_IPS_YRES property is read-only, the current and valid values of the following properties shall also be proportionally changed: WIA_IPS_YPOS, WIA_IPS_YEXTENT, WIA_IPA_NUMBER_OF_LINES.

Reference document: WIA SDK - Scanner WIA Item Property Constants, Common WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.7.4 WIA_IPS_XRES Test Description

13.4.7.5 WIA_IPS_YRES

(WIA_IPS_YRES) If the device is a scanner, when the current value of this property is changed, the current and valid values of the following properties shall be proportionally changed: WIA_IPS_YPOS, WIA_IPS_YEXTENT, WIA_IPA_NUMBER_OF_LINES, WIA_IPA_ITEM_SIZE.

Reference document: WIA SDK - Scanner WIA Item Property Constants, Common WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.7.5 WIA_IPS_YRES Test Description

13.4.7.6 WIA_IPS_XPOS

(WIA_IPS_XPOS) If the device is a scanner, a change in the current value of this property shall affect the valid values for the WIA_IPS_XEXTENT property. The current value for WIA_IPS_XEXTENT shall be clipped to the new valid values.

Reference document: WIA SDK - Scanner WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.7.6 WIA_IPS_XPOS Test Description

13.4.7.7 WIA_IPS_YPOS

(WIA_IPS_YPOS) If the device is a scanner, a change in the current value of this property shall affect the valid values for the WIA_IPS_YEXTENT property. The current value for WIA_IPS_YEXTENT shall be clipped to the new valid values.

Reference document: WIA SDK - Scanner WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.7.7 WIA_IPS_YPOS Test Description

13.4.7.8 WIA_IPS_XEXTENT

(WIA_IPS_XEXTENT) If the device is a scanner, when the current value of this property is changed, the current values of the following properties shall be proportionally changed: WIA_IPA_PIXELS_PER_LINE, WIA_IPA_BYTES_PER_LINE, WIA_IPA_ITEM_SIZE.

Reference document: WIA SDK - Scanner WIA Item Property Constants, Common WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.7.8 WIA_IPS_XEXTENT Test Description

13.4.7.9 WIA_IPS_YEXTENT

(WIA_IPS_YEXTENT) If the device is a scanner, when the current value of this property is changed, the current values of the following properties shall be proportionally changed: WIA_IPS_NUMBER_OF_LINES, WIA_IPA_ITEM_SIZE.

Reference document: WIA SDK - Scanner WIA Item Property Constants, Common WIA Item Property Constants; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.7.9 WIA_IPS_YEXTENT Test Description


WIA Methods Tests Test Assertions

13.4.8.1 drvDeviceCommand

(drvDeviceCommand) No commands are mandatory for scanners. Only one command is mandatory for cameras: WIA_CMD_SYNCHRONIZE. All other commands are optional. If a non-implemented command is passed to this method, the return value shall be E_NOT_IMPL.

Reference documents: WIA SDK - WIA Device Commands. WIA DDK - Issuing Device Commands; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.8.1 drvDeviceCommand Test Description

13.4.8.2 drvDeleteItem

(drvDeleteItem) If an item has the WIA_ITEM_CAN_BE_DELETED flag set in the WIA_IPA_ACCESS_RIGHTS property, this method shall delete the item.

Reference document: WIA DDK - IWiaMiniDrv::drvDeleteItem; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.8.2 drvDeleteItem Test Description

13.4.8.3 drvAnalyzeItem

(drvAnalyzeItem) This method should return S_OK, even if the analyze doesn’t detect any data type.

Reference document: WIA DDK - IWiaMiniDrv::drvAnalyzeItem; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.8.3 drvAnalyzeItem Test Description

13.4.8.4 drvGetWiaFormatInfo

(drvGetWiaFormatInfo) This method shall return the format pairs supported by the device. The following two pairs shall be supported at a minimum: (TYMED_CALLBACK, IMGFMT_MEMORYBMP) and (TYMED_FILE, IMGFMT_BMP).

Reference document: WIA DDK - IWiaMiniDrv::drvGetWiaFormatInfo; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.8.4 drvGetWiaFormatInfo Test Description

13.4.8.5 drvGetCapabilities

(drvGetCapabilities) When WIA_DEVICE_COMMANDS is passed to this method, it shall return the commands supported by the drvDeviceCommand method. When WIA_DEVICE_EVENTS is passed to this method, it shall return the list of events this mini-driver can generate.

Reference document: WIA DDK - IWiaMiniDrv::drvGetCapabilities; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.8.5 drvGetCapabilities Test Description

13.4.8.6 drvAcquireItemData

(drvAcquireItemData) This method shall acquire data from the device using the current property settings. If the item’ s WIA_IPA_TYMED property value is TYMED_CALLBACK the transfer shall be transferred as a memory callback. If the item’ s WIA_IPA_TYMED property value is TYMED_FILE the transfer shall be a file buffered transfer.

Reference document: WIA DDK - IWiaMiniDrv::drvAcquireItemData; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.4.8.6 drvAcquireItemData Test Description


WIA Micro-Driver Test Assertions

Test Kit: HCT 10

WIA Micro-Driver Required Functions Test Assertions

13.5.1.1 TestLibrary

This test case tests IHV-provided DLL library for its micro-driver. The DLL must provide the following functions: MicroEntry(...), Scan(...), and SetPixelWindow(...).

Reference document: WIA DDK - WIA Microdriver Functions; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.5.1.1 TestLibrary Test Description

13.5.1.2 TestSetPixelWindow

This test case tests required function SetPixelWindow(...).This function sets the image area to be scanned.

Reference document: WIA DDK - WIA Microdriver Functions; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.5.1.2 TestSetPixelWindow Test Description

13.5.1.3 TestScan

This test case tests required function Scan(...).This function reads data from the device and returns the data to the WIA Flatbed driver.

Reference document: WIA DDK - WIA Microdriver Functions; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.5.1.3 TestScan Test Description


WIA Micro-Driver Required Commands Test Assertions

13.5.2.1 TestCmdInitialize

This test case tests required command CMD_INITIALIZE in MicroEntry(...). This command is called by the WIA Flatbed Driver to initialize the microdriver and set device IO handles to valid values.

Reference document: WIA DDK - WIA Microdriver Commands: Required Commands; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.5.2.1 TestCmdInitialize Test Description

13.5.2.2 TestCmdStiDeviceReset

This test case tests required command CMD_STI_DEVICERESET in MicroEntry(...). This command is called by the WIA Flatbed Driver to reset the device in response to a Still Image (STI) request.

Reference document: WIA DDK - WIA Microdriver Commands: Required Commands; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.5.2.2 TestCmdStiDeviceReset Test Description

13.5.2.3 TestCmdStiDiagnostic

This test case tests required command CMD_STI_DIAGNOSTIC in MicroEntry(...). This command is called by the WIA Flatbed Driver when the user requests to test the device.

Reference document: WIA DDK - WIA Microdriver Commands: Required Commands; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.5.2.3 TestCmdStiDiagnostic Test Description

13.5.2.4 TestCmdResetScanner

This test case tests required command CMD_RESETSCANNER in MicroEntry(...). This command is called by the WIA Flatbed Driver to reset the device in response to a WIA service request. The microdriver should set the device to its power-on state.

Reference document: WIA DDK - WIA Microdriver Commands: Required Commands; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.5.2.4 TestCmdResetScanner Test Description

13.5.2.5 TestCmdSetXResolution

This test case tests required command CMD_SETXRESOLUTION in MicroEntry(...). This command is called by the WIA Flatbed Driver to set the horizontal scan resolution.

Reference document: WIA DDK - WIA Microdriver Commands: Required Commands; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.5.2.5 TestCmdSetXResolution Test Description

13.5.2.6 TestCmdSetYResolution

This test case tests required command CMD_SETYRESOLUTION in MicroEntry(...). This command is called by the WIA Flatbed Driver to set the vertical scan resolution.

Reference document: WIA DDK - WIA Microdriver Commands: Required Commands; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.5.2.6 TestCmdSetYResolution Test Description

13.5.2.7 TestCmdSetDataType

This test case tests required command CMD_SETDATATYPE in MicroEntry(...). This command is called by the WIA Flatbed Driver to set the data type for the scan. Allowed datatypes are WIA_DATA_THRESHOLD, WIA_DATA_GRAYSCALE, WIA_DATA_COLOR.

Reference document: WIA DDK - WIA Microdriver Commands: Required Commands; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.5.2.7 TestCmdSetDataType Test Description

13.5.2.8 TestCmdSetIntensity

This test case tests required command CMD_SETINTENSITY in MicroEntry(...). This command is called by the WIA Flatbed Driver to set the intensity or brightness value for the scan. -1000 should be interpreted as the lowest brightness value, 0 nominal, and 1000 the device's maximum brightness.

Reference document: WIA DDK - WIA Microdriver Commands: Required Commands; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.5.2.8 TestCmdSetIntensity Test Description

13.5.2.9 TestCmdSetContrast

This test case tests required command CMD_SETCONTRAST in MicroEntry(...). This command is called by the WIA Flatbed Driver to set the contrast value for the scan. -1000 should be interpreted as the lowest contrast value, 0 nominal, and 1000 the device's maximum contrast.

Reference document: WIA DDK - WIA Microdriver Commands: Required Commands; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.5.2.9 TestCmdSetContrast Test Description

13.5.2.10 TestCmdGetCapabilities

This test case tests required command CMD_GETCAPABILITIES in MicroEntry(...). This command is called by the WIA Flatbed Driver to get button event information.

Reference document: WIA DDK - WIA Microdriver Commands: Required Commands; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.5.2.10 TestCmdGetCapabilities Test Description

13.5.2.11 TestCmdUninitialize

This test case tests required command CMD_UNINITIALIZE in MicroEntry(...). This command is called by the WIA Flatbed Driver to uninitialize the microdriver and close Device IO handles.

Reference document: WIA DDK - WIA Microdriver Commands: Required Commands; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.5.2.11 TestCmdUninitialize Test Description


WIA Micro-Driver Event Commands Test Assertions

13.5.3.1 TestCmdStiGetStatus

This test case tests required command CMD_STI_GETSTATUS in MicroEntry(...). This command is called by the WIA Flatbed Driver to get the on-line status of the device and if the device has push buttons, to get the button status.

Reference document: WIA DDK - WIA Microdriver Commands: Event Commands; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.5.3.1 TestCmdStiGetStatus Test Description

13.5.3.2 TestCmdGetInterruptEvent

This test case tests required command CMD_STI_GETSTATUS in MicroEntry(...). This command is called by the WIA Flatbed Driver in a separate thread to monitor the status of button events that use interrupts from the device (i.e. for USB devices which report events via the interrupt pipe). If your device only supports polling, this command does not need to be implemented, return E_NOTIMPL.

Reference document: WIA DDK - WIA Microdriver Commands: Event Commands; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.5.3.2 TestCmdGetInterruptEvent Test Description


WIA Micro-Driver ADF Commands Test Assertions

13.5.4.1 TestCmdLoadADF

This test case tests required command CMD_LOAD_ADF in MicroEntry(...). This command is called by the WIA Flatbed Driver to load a page into the ADF. If this command does not apply to the device, return E_NOTIMPL.

Reference document: WIA DDK - WIA Microdriver Commands: Automatic Document Feeder Commands; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.5.4.1 TestCmdLoadADF Test Description

13.5.4.2 TestCmdUnloadADF

This test case tests required command CMD_UNLOAD_ADF in MicroEntry(...). This command is called by the WIA Flatbed Driver to unload a page from the ADF. If this command does not apply to the device, return E_NOTIMPL.

Reference document: WIA DDK - WIA Microdriver Commands: Automatic Document Feeder Commands; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.5.4.2 TestCmdUnloadADF Test Description

13.5.4.3 TestCmdGetADFAvailable

This test case tests required command CMD_GETADFAVAILABLE in MicroEntry(...). This command is called by the WIA Flatbed Driver to check the availability of ADF. If this command does not apply to the device, return E_NOTIMPL.

Reference document: WIA DDK - WIA Microdriver Commands: Automatic Document Feeder Commands; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.5.4.3 TestCmdGetADFAvailable Test Description

13.5.4.4 TestCmdGetADFHasPaper

This test case tests required command CMD_GETADFHASPAPER in MicroEntry(...). This command is called by the WIA Flatbed Driver to get the paper status of the device’s ADF. If this command does not apply to the device, return E_NOTIMPL.

Reference document: WIA DDK - WIA Microdriver Commands: Automatic Document Feeder Commands; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.5.4.4 TestCmdGetADFHasPaper Test Description

13.5.4.5 TestCmdGetADFStatus

This test case tests required command CMD_GETADFSTATUS in MicroEntry(...). This command is called by the WIA Flatbed Driver to get the status of the ADF attached to the device. Possible status values are MCRO_ERROR_GENERAL_ERROR, MCRO_ERROR_OFFLINE, MCRO_ERROR_PAPER_EMPTY, MCRO_ERROR_PAPER_JAM, MCRO_ERROR_PAPER_PROBLEM, MCRO_ERROR_USER_INTERVENTION, and MCRO_STATUS_OK. If this command does not apply to the device, return E_NOTIMPL.

Reference document: WIA DDK - WIA Microdriver Commands: Automatic Document Feeder Commands; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.5.4.5 TestCmdGetADFStatus


WIA Micro-Driver Optional Commands Test Assertions

13.5.5.1 TestCmdGetSupportedFileFormats

This test case tests optional command CMD_ GETSUPPORTEDFILEFORMATS in MicroEntry(...). This command is called by the WIA Flatbed Driver to get the number of additional file formats (except BMP and MEMORYBMP). If this command does not apply to the device, return E_NOTIMPL.

Reference document: WIA DDK - WIA Microdriver Commands: Optional Commands; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.5.5.1 TestCmdGetSupportedFileFormats Test Description

13.5.5.2 TestCmdGetSupportedMemoryFormats

This test case tests optional command CMD_GETSUPPORTEDMEMORYFORMATS in MicroEntry(...). This command is called by the WIA Flatbed Driver to get the number of additional memory formats (except BMP and MEMORYBMP). If this command does not apply to the device, return E_NOTIMPL.

Reference document: WIA DDK - WIA Microdriver Commands: Optional Commands; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.5.5.2 TestCmdGetSupportedMemoryFormats Test Description

13.5.5.3 TestCmdSetScanMode

This test case tests optional command CMD_SETSCANMODE in MicroEntry(...). This command is called by the WIA Flatbed Driver to set the scan mode of the microdriver's device (SCANMODE_PREVIEWSCAN or SCANMODE_FINALSCAN). If this command does not apply to the device, return E_NOTIMPL.

Reference document: WIA DDK - WIA Microdriver Commands: Optional Commands; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.5.5.3 TestCmdSetScanMode Test Description

13.5.5.4 TestCmdSetStiDeviceHKey

This test case tests optional command CMD_SETSTIDEVICEHKEY in MicroEntry(...). This command is called by the WIA Flatbed Driver to allow the microdriver to read registry entries in the installed registry section. If this command does not apply to the device, return E_NOTIMPL.

Reference document: WIA DDK - WIA Microdriver Commands: Optional Commands; PC 2001 System Design Guide -IMAG-0317; WLP# - B9.1.1.1.

Test Description: TD-13.5.5.4 TestCmdSetStiDeviceHKey Test Description


WIA Driver Test Assertion

13.6.1 Driver support implements the WIA driver architecture.

Still image devices must provide drivers based on WIA that expose camera properties and enable camera functionality. The services provided by WIA provide hardware abstraction, installation wizards, and event polling.

Reference document: WLP# - B9.1.1.1; PC 2001 System Design Guide, IMAG-0317

Test Description: TD-13.5 WIA Micro-Driver Test Description


Digital Still Imaging Test Descriptions

This section describes the Digital Still Imaging tests. The descriptions include hardware and software setup, test execution instructions and test results interpretation.


TD-13.1 Image Color Management Profile Test

Test Kit: HCT 11, HCT 10

Overview

The Image Color Management (ICM) profile test enumerates all available imaging devices. If there is more than one device connected, the operator selects the device under examination.

The ICM system supports profiles that conform to the International Color Consortium (ICC) profile specification. The profiles ensure that colors are represented accurately, regardless of the device being used. The devices include scanners, monitors, digital cameras, and printers.

TD-13.1.1 Imaging device ships with ICC profile.

The test verifies the presence of an ICC color profile for the device by opening the profile for reading with OpenColorProfile() with share read file access. Assertion 13.1.1 is passed if OpenColorProfile() returns a non-NULL HPROFILE.

TD-13.1.2 ICC profile header can be retrieved.

The test attempts to retrieve the profile header with GetColorProfileHeader() API. Assertion 13.1.2 is passed if GetColorProfileHeader() successfully retrieves the profile header.

TD-13.1.3 ICC profile size field in the profile header should be larger than the size of the profile header.

The test verifies that the size field in the profile header is larger than the size of the profile header.

TD-13.1.4 ICC profile file size should be larger than the profile header size.

The test verifies that the file size, which is returned from GetFileSize(), is larger than the profile header size.

TD-13.1.5 ICC profile size field in the profile header should not be larger than the file size.

The test verifies that the profile size in the profile header isn’t larger than the file size returned by GetFileSize().

TD-13.1.6 ICC profile version field in the header must be a version supported by Windows default CMM.

The test verifies that the version in the profile header is a version that is supported by Windows default color management module (CMM). The current profile versions are known to be supported: 2.0, 2.1, and 2.2. Assertion 13.1.6 is passed in the version is 2.0, 2.1, or 2.2.

TD-13.1.7 ICC profile class field in the header must be a valid class type and must match with the class of the imaging device.

The test verifies that the class in the profile header is a valid class. The class must be one of the classes specified in the ICC specification ICC.1:1998-09, Section 6.1.4. Valid classes signatures for still imaging devices are ‘scnr’, ‘mntr’, and ‘spac’. The test then verifies that the class matches with that of the still imaging device selected for the test.

TD-13.1.8 ICC profile data color space field in the header must be a valid color space type.

The test then verifies that the data color space field is a valid data color space signature as specified in the ICC specification ICC.1:1998-09, Section 6.1.5.

TD-13.1.9 ICC profile connection color space in the header must be a valid connection color space.

The test then verifies that the connection color space in the header is a valid connection space as defined in ICC specification ICC.1:1998-09, Section 6.1.6.

TD-13.1.10 ICC profile signature in the header must be a valid signature.

The test then verifies that the profile file signature in the profile header is ‘acsp’.

TD-13.1.11 ICC profile primary platform field in the header must be a valid platform type.

The test then verifies that the primary platform is valid according to ICC specification ICC.1:1998-09, Section 6.1.7.

TD-13.1.12 ICC profile reserved bytes in the header must be zero.

The test then verifies that the reserved bytes in the profile header contain zeroes. Assertion 13.1.12 is passed if the reserved bytes in the profile header are zero.

TD-13.1.13 ICC profile contains the required tags for the type of ICC profile.

The test verifies that the profile contains the required tags (description tag, copyright tag, media white point tag etc.) for the type of profile as described in ICC specification ICC.1:1998-09, Section 6.3. Assertion 13.1.13 is passed if the required tags are present.

TD-13.1.14 ICC profile tags present in the profile must be valid.

The test verifies that the tag data in the profile is valid.

TD-13.1.15 ICC profile is valid.

The test verifies that the profile is valid by calling the default CMM’s API IsColorProfileValid(). Assertion 13.1.15 is passed if the default CMM’s IsColorProfileValid() indicates that the profile is valid.

TD-13.1.16 A transform can be created using the ICC profile.

The test verifies that a transform can be created with the profile by calling either CreateColorTransfrom() or CreateMultipleProfileColorTransform(). Assertion 13.1.16 is passed if a transform can be created using the profile.

TD-13.1.17 A translation can be done using a transform that uses the ICC profile.

The test verifies that a translation can be done using a transform that uses the profile. TranslateBitmapBits() is that translation call used with some arbitrary color bits. Assertion 13.1.17 is passed if a translation can be done using a transform that uses the profile.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

If there is more than one device connected, the operator selects the device under examination.

Results Interpretation

All assertions exercised by the ICC Profile test must pass for the test to pass. The log file indicates the profile interpretation, lists all header values in hexadecimal form, and indicates the appropriate meaning of the value.


TD-13.2 Image Download Test

Overview

The objective of this test is to ascertain that the image transfer meets the minimum required throughput. For image transfers, the test measures the effective transfer rate from the device to the test application (which uses the TWAIN interface). This means that the device to application throughput potentially incorporates image decompression time. A device that uses fast IR mode can still fail this test if slow decompression renders the use of the fast IR mode academic. However, the image compression ratio is not considered by the test.

The image download test operates as a TWAIN application. The test queries the user for the type of connection used and supported. It requests a single image in RGB24 mode at default resolutions from the device. The test device must transfer the image in TWAIN User Interface disabled mode. A second image download is also requested. Download time for each image includes enabling the device (TWAIN terminology), image data transfer time and if needed decompression of the image data (for example, digital cameras). The test measures the download timings per image and then calculates the average throughput of the five images. Successful image download of the first image identifies the PASS/FAIL for assertion (13.2.1). To determine the overall throughput:

Case 1: If the second image download is successful:

Total Download Time For 5 Images =

Enabling the device for Image One + 4 x Enabling the device for Image Two +

5 x (Data transfer time for Image One + Decompression time for Image One).

Overall Throughput =(Total Download Time For 5 Images)/ 5x (Size of Image One).

Case 2: If only the first image download is successful:

Total Download Time For Image One =

Enabling the device for Image One + Data transfer time for Image One +

If needed, decompression time for Image One.

Overall Throughput =(Total Download Time For Image One)/(Size of Image One).

If an imaging device supports multiple interfaces to transfer image data, to pass the Image Download test, the device must pass the test for all the interfaces it supports.

The following are minimum required throughput values:

  • Fast IR - 80 Kpixels/sec throughput
  • USB - 120 Kpixels/sec throughput
  • 1394 - 200 Kpixels/sec throughput

The minimum required throughput values are also based on whether download image was stored on the e-film media before the test (image stored on the e-film media of digital camera) or the image was acquired during the test (image from a scanner). Since the download of the newly acquired image involves the processing of the image and then download, the minimum required throughput values for this category are lower than that of download of a stored image.

TD-13.2.1 Image can be downloaded to system.

A prerequisite of the test is the ability to download a single image from the imaging device using TWAIN. If the device is capable of storing images (camera) then only one image, of default resolution and quality, should be stored in the device during the test. This assertion passes if the image transfer is successful.

TD-13.2.2 IR image download takes place at 80 Kpixels/s or faster for download of stored image and at 40 Kpixels/s or faster for download of newly acquired image.

If the user indicates that IR device to computer communications are utilized then to pass this assertion, the image transfer must take place at a rate of 80 Kpixels/s or faster for download of stored image and at a rate of 40 Kpixels/s or faster for download of newly acquired image. This measurement includes all communication overhead and decompression times if applicable.

TD-13.2.3 Serial image download takes place at 2 Kpixels/s or faster for download of stored image and at 1 Kpixels/s or faster for download of newly acquired image.

If the user indicates that serial port device to computer communications are utilized then to pass this assertion, the image transfer must take place at a rate of 2 Kpixels/s or faster for download of stored image and at a rate of 40 Kpixels/s or faster for download of newly acquired image. This measurement includes all communication overhead and decompression times if applicable.

TD-13.2.4 Parallel port image download takes place at 20 Kpixels/s or faster for download of stored image and at 10 Kpixels/s or faster for download of newly acquired image.

If the user indicates that the parallel port device to computer communications are utilized then to pass this assertion, the image transfer must take place at a rate of 20 Kpixels/s or faster for download of stored image and at a rate of 40 Kpixels/s or faster for download of newly acquired image. This measurement includes all communication overhead and decompression times if applicable.

TD-13.2.5 USB image download takes place at 120 Kpixels/s or faster for download of stored image and at 40 Kpixels/s or faster for download of newly acquired image.

If the user indicates that the USB port device to computer communications are utilized then to pass this assertion, the image transfer must take place at a rate of 120 Kpixels/s or faster for download of stored image and at a rate of 40 Kpixels/s or faster for download of newly acquired image. This measurement includes all communication overhead and decompression times if applicable.

TD-13.2.6 1394 image download takes place at 200 Kpixel/s or faster for download of stored image and at 40 Kpixels/s or faster for download of newly acquired image.

If the user indicates that the 1394 port device to computer communications are utilized then to pass this assertion, the image transfer must take place at a rate of 200 Kpixels/s or faster for download of stored image and at a rate of 40 Kpixels/s or faster for download of newly acquired image. This measurement includes all communication overhead and decompression times if applicable.

TD-13.2.7 SCSI image download takes place at 200 Kpixels/s or faster for download of stored image and at 40 Kpixels/s or faster for download of newly acquired image.

If the user indicates that the SCSI bus device to computer communications are utilized then the image transfer must take place at a rate of 200 Kpixels/s or faster for download of stored image and at a rate of 40 Kpixels/s or faster for download of newly acquired image. This measurement includes all communication overhead and decompression times if applicable.

Setup

The hardware setup requires a Windows Logo Program compliant system with an imaging device driver configured for TWAIN support. An imaging device must contain at least one stored image for testing if applicable (camera), or must set up to capture an image dynamically if applicable (scanner). The device should be set up for the highest supported resolution at normal quality or at default settings.

Device driver and associated applications are installed as per device driver manual instructions. Proper setup is verified by capturing images with bundled application or other compatible application.

Results Interpretation

A pass/fail condition is based on average image throughput for five transfers. Test log lists the achieved value, the threshold value and the individual transfer results.


TD-13.3 PC-Compliant File System Test

Test Kit: HCT 11, HCT 10

Overview

If still imaging devices contain removable media, such as CompactFlash cards, then the media card when inserted into a reader should be treated as a file system by the operating system. The test verifies that a card written by the device is accessible by the operating system. The operator is queried for a drive letter that represents the media drive. The test then copies files, deletes files and attempts to write files back to the media drive. Specifically, the test ascertains the following:

TD-13.3.1 E-film media can be read via file system operation.

The test verifies that a file can read from the e-film device using file system operations. The integrity of the file is not verified.

TD-13.3.2 E-film media can be erased via file system operation

The test verifies that a file on the e-film device can be erased using file system operations.

TD-13.3.3 E-film media can be written via file system operation.

The test verifies that a file can be written to the e-film device using file system operations.

TD-13.3.4 E-film media "space available" can be determined via file system operation.

The test obtains the available space value of the e-film device using file system operations. The test then writes files to the device until the device is full. The previous space available amount is compared to the number of files written and a pass/fail evaluation is based on a 90% correlation.

The test tracks errors that occur during the operations and supports a verbose mode that allows the operator to monitor progress.

Setup

The hardware setup requires a Windows Logo Program compliant system with a media reading device such as a PC Card reader properly installed. Additionally, the device to be tested must have been used to format a media device and then store at least one image on the device. The operator should verify before the test that the images are viewable and that the media device functions properly in the device under investigation.

Results Interpretation

The automatic portion of the test is passed if the directory listing, read and delete operations proceed without error and yield their intended results. The media device may be write-protected in which case the write test portion of the test defaults to a pass. If the media device is not write-protected, a sequence of file writes until the device is full must succeed without error for the test to pass.


WIA Minidriver Test Descriptions

Test Kit: HCT 11, HCT 10

Overview

The Windows Image Acquisition (WIA) Minidriver tests are based on the new Digital Still Image device driver requirements in the PC2001 System Design Guide.

WIA device drivers will be compliant with STI’s User Mode Driver (USD) model, allowing backward compatibility with Windows 98 and Windows 2000 operating systems.

Test Case Structure

A typical test case has the following structure:

StartWIA
<test case body >
StopWIA

Where:

  • StartWIA: Retrieves the information needed to access the WIA mini-driver under test
  • <test case body>: Implements the test
  • StopWIA: Release the resources allocated during test execution leaving the system and the mini-driver in a known state.

Tests will be built using the following set of test functions. These functions are defined only to allow the user to easily create tests. The functions are based on the WIA API methods. This set of functions is sufficient to allow the implementation of all tests in this specification.

StartWIA

Retrieves the information needed to access the WIA mini-driver under test.

The function obtains a pointer to the WIA Device Manager interface and creates a WIA Device using the Target device ID (device under test). Finally, it retrieves the WIA Root Item.

The function returns a HRESULT value.

StopWIA

Releases the WIA Root Item and the WIA Device Manager.

The function returns a HRESULT value.

GetDeviceType

Retrieves the type of the WIA Device under test.

The device under test could be Scanner or Camera WIA Device.

If possible, the function will return more information (if the device is a handheld scanner, if an ADF is attached to the device and others).

GetProperty

Retrieves the specified property data (access, type, subtype, value, legal values) for a specific WIA item.

The function accepts as parameters the property ID, the target WIA item and a placeholder for the property data. The function returns a HRESULT value.

SetProperty

Changes the specified property value for a specific WIA item.

The functions accepts as parameters the property ID, the target WIA item and the new value. The function returns a HRESULT value.

GetItemsCount

Traverses a tree given its root item and returns the number of items including the root. The function returns a HRESULT value.

DeviceCommand

Sends a specified command to the WIA Device under test.

The function returns a HRESULT value.

CheckSuppValues

Issues a SetProperty and then a GetProperty for every reported supported value. The SetProperty function should return S_OK and the GetProperty function should return the same value for the property as the one that was just set. Otherwise, the function return S_FALSE.

GetImageFile

Transfers the image data from a WIA Item using a file buffered transfer. The function returns a HRESULT value.

GetImageMemory

Transfers the image data from a WIA Item using a memory callback transfer. The function returns a HRESULT value.

GetFormatInfo

Retrieves the supported formats and media types of incoming data. The function returns a HRESULT value.

GetDeviceCaps

Retrieves the supported device capabilities. The function returns a HRESULT value.

DeviceCommand

Issues a specified command to the WIA Device. The function returns a HRESULT value.

AnalyzeItem

Acquires and tries to detect what data types are present on a WIA Item.

The function returns a HRESULT value.

DeleteItem

Deletes the specified WIA Item. The function returns a HRESULT value.

Setup

The test environment must include the following:

  • Windows Me or a later version of Windows that supports WIA.
  • A WIA capable device (scanner or digital camera).

Test Cases

Properties Tests

These tests are grouped in the following categories:

  • Property Attributes
  • Common Device Properties
  • Camera Device Properties
  • Scanner Device Properties
  • Common Item Properties
  • Camera Item Properties
  • Scanner Item Properties
  • Interdependency Properties tests

The Properties Tests check if the WIA mini-driver correctly implements the device tree item properties. These tests will access the tree items and will verify each of the followings attributes for each property:

  • Access
  • Type
  • Subtype
  • Value

The property tests will also verifies that the WIA minidriver does not accept an illegal value for a property, and that dependent property values are correctly updated when a property value is changed.

Methods Tests

The Methods Tests check if the WIA mini-driver correctly responds when the Imaging Application calls the device tree item methods. The correct functionality is also tested, when possible.

Load/Stress Tests

There are no special tests defined in this section. In order to test the minidriver under load conditions, the Test Application will run two different tests in separate threads.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-13.4.1.1 WIA_DPA_FIRMWARE_VERSION Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPA_FIRMWARE_VERSION Target: root item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_BSTR Expected property value length: > 0
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
3 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPA_FIRMWARE_VERSION Value: <any value> Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
4 - StopWIA |


TD-13.4.1.2 WIA_DPA_CONNECT_STATUS Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPA_CONNECT_STATUS Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_I4 Expected property value: WIA_DEVICE_CONNECTED or WIA_DEVICE_NOT_CONNECTED
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
3 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPA_CONNECT_STATUS Value: <any value> Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
4 - StopWIA |


TD-13.4.1.3 WIA_DPA_DEVICE_TIME Test Description

# - Test Function | DESCRIPTION
1 - StartWIA |
2 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPA_DEVICE_TIME Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_READ or WIA_PROP_RW Expected property type: WIA_PROP_NONE Expected property subtype: SYSTEMTIME Expected property value: A valid date formatted as a SYSTEMTIME structure.
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary.
3 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPA_DEVICE_TIME Value: current system time (or other valid SYSTEMTIME value). Target: root item
PASS/FAIL Criteria: | If property access is WIA_PROP_RW ( Expected result: S_OK If property access is WIA_PROP_READ ( Expected result: S_FALSE
Comments: | Let a_date be the value sent as a parameter.
If property access is WIA_PROP_READ go to step 5 and return PASSED.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPA_DEVICE_TIME Target: root item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: a_date.
Comments: | FAILED if one of the expected values doesn’t match the reported one. PASSED otherwise.
5 - StopWIA |


TD-13.4.2.1 WIA_DPC_PICTURES_TAKEN Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_PICTURES_TAKEN Target: root item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_I4
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_PICTURES_TAKEN Value: <any value> Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.2.2 WIA_DPC_PICTURES_REMAINING TEST DESCRIPTION

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_PICTURES_REMAINING Target: root item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_I4
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_PICTURES_REMAINING Value: <any value> Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.2.3 WIA_DPC_EXPOSURE_MODE Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_EXPOSURE_MODE Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_RW Expected property type: WIA_PROP_LIST or WIA_PROP_RANGE Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_EXPOSURE_MODE Value: Illegal Value Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.2.4 WIA_DPC_EXPOSURE_COMP Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_EXPOSURE_COMP Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_RW Expected property type: WIA_PROP_RANGE Expected property subtype: VT_I4 Expected property value: -200 or -150 or -100 or -50 or 0 or 50 or 100 or 150 or 200
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_EXPOSURE_COMP Value: Illegal Value Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.2.5 WIA_DPC_EXPOSURE_TIME Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_EXPOSURE_TIME Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_RW Expected property type: WIA_PROP_RANGE Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_EXPOSURE_TIME Value: Illegal Value Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.2.6 WIA_DPC_FNUMBER Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_FNUMBER Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_RW Expected property type WIA_PROP_LIST or WIA_PROP_RANGE Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_FNUMBER Value: Illegal Value Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.2.7 WIA_DPC_FLASH_MODE Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_FLASH_MODE Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_RW Expected property type WIA_PROP_LIST Expected property subtype: VT_I4 Expected property value: WIA_FLASH_MODE_AUTO or WIA_FLASH_MODE_FILL or WIA_FLASH_MODE_OFF or WIA_FLASH_MODE_REDEYE
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - CheckSuppValues | Verify if all the reported values are really supported by the property.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_FLASH_MODE Value: Illegal Value Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
6 - StopWIA |


TD-13.4.2.8 WIA_DPC_FOCUS_MODE Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_FOCUS_MODE Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_RW Expected property type WIA_PROP_LIST or WIA_PROP_RANGE Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_FOCUS_MODE Value: Illegal Value Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.2.9 WIA_DPC_ZOOM_POSITION Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_ZOOM_POSITION Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_RW Expected property type WIA_PROP_LIST or WIA_PROP_RANGE Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_ZOOM_POSITION Value: Illegal Value Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.2.10 WIA_DPC_PAN_POSITION Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_PAN_POSITION Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_RW Expected property type WIA_PROP _RANGE Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_PAN_POSITION Value: Illegal Value Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.2.11 WIA_DPC_TILT_POSITION Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_TILT_POSITION Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_RW Expected property type WIA_PROP _RANGE Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_TILT_POSITION Value: Illegal Value Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.2.12 WIA_DPC_TIMER_MODE Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_TIMER_MODE Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_RW Expected property type WIA_PROP _LIST Expected property subtype: VT_I4 Expected property value: WIA_TIMER_MODE_OFF or WIA_TIMER_MODE_ON
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - CheckSuppValues | Verify if all the reported values are really supported by the property.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_TIMER_MODE Value: Illegal Value Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
6 - StopWIA |


TD-13.4.2.13 WIA_DPC_TIMER_VALUE Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_TIMER_VALUE Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_RW Expected property type WIA_PROP _RANGE Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_TIMER_VALUE Value: Illegal Value Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.2.14 WIA_DPC_POWER_MODE Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_POWER_MODE Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_READ Expected property type WIA_PROP_NONE Expected property subtype: VT_I4 Expected property value: WIA_POWER_MODE_LINE or WIA_POWER_MODE_BATTERY
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_POWER_MODE Value: WIA_POWER_MODE_LINE Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.2.15 WIA_DPC_BATTERY_STATUS Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_BATTERY_STATUS Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_READ Expected property type WIA_PROP _NONE Expected property subtype: VT_I4 Expected property value: In the range 0 to 100.
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_BATTERY_STATUS Value: 0 Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.2.16 WIA_DPC_FOCUS_MANUAL_DIST Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_FOCUS_MANUAL_DIST Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_READ Expected property type WIA_PROP _NONE Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_FOCUS_MANUAL_DIST Value: <any value> Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.2.17 WIA_DPC_PICT_WIDTH Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_PICT_WIDTH Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_READ or WIA_PROP_RW Expected property type: WIA_PROP_NONE for read only or WIA_PROP_LIST for read/write access Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - CheckSuppValues | Verify if all the reported values are really supported by the property. If the property has read-only access, skip this test.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
5 - GetRangeMin | Verify if the number of elements in the supported value list is equal to that for property WIA_DPC_PICT_HEIGHT.
Parameters: | Property: WIA_DPC_PICT_WIDTH Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if the number is not the same as that for property WIA_DPC_PICT_HEIGHT Continue testing otherwise.
6 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_PICT_WIDTH Value: <any value> Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
7 - StopWIA |


TD-13.4.2.18 WIA_DPC_PICT_HEIGHT Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_PICT_HEIGHT Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_READ or WIA_PROP_RW Expected property type: WIA_PROP_NONE for read only or WIA_PROP_LIST for read/write access Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - CheckSuppValues | Verify if all the reported values are really supported by the property. If the property has read-only access, skip this test.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
5 - GetRangeMin | Verify if the number of elements in the supported value list is equal to that for property WIA_DPC_PICT_WIDTH.
Parameters: | Property: WIA_DPC_PICT_HEIGHT Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | AILED if the number is not the same as that for property WIA_DPC_PICT_WIDTH Continue testing otherwise.
6 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_PICT_HEIGHT Value: <any value> Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
7 - StopWIA |


TD-13.4.2.19 WIA_DPC_THUMB_WIDTH Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_THUMB_WIDTH Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_READ or WIA_PROP_RW Expected property type: WIA_PROP_NONE for read only or WIA_PROP_LIST for read/write access Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn't exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
4 - CheckSuppValues | Verify if all the reported values are really supported by the property. If the property has read-only access, skip this test.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
5 - GetRangeMin | Verify if the number of elements in the supported value list is equal to that for property WIA_DPC_THUMB_HEIGHT.
Parameters: | Property: WIA_DPC_THUMB_WIDTH Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if the number is not the same as that for property WIA_DPC_THUMB_HEIGHT Continue testing otherwise.
6 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_THUMB_WIDTH Value: <any value> Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
7 - StopWIA |


TD-13.4.2.20 WIA_DPC_THUMB_HEIGHT Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_THUMB_HEIGHT Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_READ or WIA_PROP_RW Expected property type: WIA_PROP_NONE for read only or WIA_PROP_LIST for read/write access Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn't exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
4 - CheckSuppValues | Verify if all the reported values are really supported by the property. If the property has read-only access, skip this test.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
5 - GetRangeMin | Verify if the number of elements in the supported value list is equal to that for property WIA_DPC_THUMB_WIDTH
Parameters: | Property: WIA_DPC_THUMB_HEIGHT Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if the number is not the same as that for property WIA_DPC_THUMB_WIDTH Continue testing otherwise.
6 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_THUMB_HEIGHT Value: <any value> Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
7 - StopWIA |


TD-13.4.2.21 WIA_DPC_COMPRESSION_SETTING Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_COMPRESSION_SETTING Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_READ or WIA_PROP_RW Expected property type WIA_PROP_LIST (or RANGE or NONE) Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn't exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
If the property has WIA_PROP_RW access, do step 4. Else do step 5
4 - CheckSuppValues | Verify if all the reported values are really supported by the property. If the property has read-only access, skip this test.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_COMPRESSION_SETTING Value: Any Value since this property is Read-only Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
6 - StopWIA |


TD-13.4.2.22 WIA_DPC_TIMELAPSE_INTERVAL Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_TIMELAPSE_INTERVAL Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_READ or WIA_PROP_RW Expected property type WIA_PROP_LIST (or RANGE or NONE) Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn't exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
If the property has WIA_PROP_RW access, do step 4. Else do step 5
4 - CheckSuppValues | Verify if all the reported values are really supported by the property. If the property has read-only access, skip this test.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_TIMELAPSE_INTERVAL Value: Any Value since this property is Read-only Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
6 - StopWIA |


TD-13.4.2.23 WIA_DPC_TIMELAPSE_NUMBER Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_TIMELAPSE_NUMBER Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_READ or WIA_PROP_RW Expected property type WIA_PROP_LIST (or RANGE or NONE) Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn't exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
If the property has WIA_PROP_RW access, do step 4. Else do step 5
4 - CheckSuppValues | Verify if all the reported values are really supported by the property. If the property has read-only access, skip this test.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_TIMELAPSE_NUMBER Value: Any Value since this property is Read-only Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
6 - StopWIA |


TD-13.4.2.24 WIA_DPC_BURST_INTERVAL Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_BURST_INTERVAL Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_READ or WIA_PROP_RW Expected property type WIA_PROP_LIST (or RANGE or NONE) Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn't exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
If the property has WIA_PROP_RW access, do step 4. Else do step 5
4 - CheckSuppValues | Verify if all the reported values are really supported by the property. If the property has read-only access, skip this test.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_BURST_INTERVAL Value: Any Value since this property is Read-only Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
6 - StopWIA |


TD-13.4.2.25 WIA_DPC_BURST_NUMBER Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_BURST_NUMBER Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_READ or WIA_PROP_RW Expected property type WIA_PROP_LIST (or RANGE or NONE) Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn't exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
If the property has WIA_PROP_RW access, do step 4. Else do step 5
4 - CheckSuppValues | Verify if all the reported values are really supported by the property. If the property has read-only access, skip this test.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_BURST_NUMBER Value: Any Value since this property is Read-only Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
6 - StopWIA |


TD-13.4.2.26 WIA_DPC_EFFECT_MODE Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_EFFECT_MODE Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_READ or WIA_PROP_RW Expected property type WIA_PROP_LIST (or RANGE or NONE) Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn't exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
If the property has WIA_PROP_RW access, do step 4. Else do step 5
4 - CheckSuppValues | Verify if all the reported values are really supported by the property. If the property has read-only access, skip this test.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_EFFECT_MODE Value: Any Value since this property is Read-only Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
6 - StopWIA |


TD-13.4.2.27 WIA_DPC_DIGITAL_ZOOM Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_DIGITAL_ZOOM Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_READ or WIA_PROP_RW Expected property type WIA_PROP_LIST (or RANGE or NONE) Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn't exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
If the property has WIA_PROP_RW access, do step 4. Else do step 5
4 - CheckSuppValues | Verify if all the reported values are really supported by the property. If the property has read-only access, skip this test.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_DIGITAL_ZOOM Value: Any Value since this property is Read-only Target: root item`
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
6 - StopWIA |


TD-13.4.2.28 WIA_DPC_SHARPNESS Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_SHARPNESS Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_READ or WIA_PROP_RW Expected property type WIA_PROP_LIST (or RANGE or NONE) Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn't exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
If the property has WIA_PROP_RW access, do step 4. Else do step 5
4 - CheckSuppValues | Verify if all the reported values are really supported by the property. If the property has read-only access, skip this test.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_SHARPNESS Value: Any Value since this property is Read-only Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
6 - StopWIA |


TD-13.4.2.29 WIA_DPC_CONTRAST Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_CONTRAST Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_READ or WIA_PROP_RW Expected property type WIA_PROP_LIST (or RANGE or NONE) Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn't exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
If the property has WIA_PROP_RW access, do step 4. Else do step 5
4 - CheckSuppValues | Verify if all the reported values are really supported by the property. If the property has read-only access, skip this test.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_CONTRAST Value: Any Value since this property is Read-only Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
6 - StopWIA |


TD-13.4.2.30 WIA_DPC_CAPTURE_MODE Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_CAPTURE_MODE Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_READ or WIA_PROP_RW Expected property type WIA_PROP_LIST (or RANGE or NONE) Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn't exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
If the property has WIA_PROP_RW access, do step 4. Else do step 5
4 - CheckSuppValues | Verify if all the reported values are really supported by the property. If the property has read-only access, skip this test.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_CAPTURE_MODE Value: Any Value since this property is Read-only Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
6 - StopWIA |


TD-13.4.2.31 WIA_DPC_CAPTURE_DELAY Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_CAPTURE_DELAY Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_READ or WIA_PROP_RW Expected property type WIA_PROP_LIST (or RANGE or NONE) Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn't exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
If the property has WIA_PROP_RW access, do step 4. Else do step 5
4 - CheckSuppValues | Verify if all the reported values are really supported by the property. If the property has read-only access, skip this test.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_CAPTURE_DELAY Value: Any Value since this property is Read-only Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
6 - StopWIA |


TD-13.4.2.32 WIA_DPC_EXPOSURE_INDEX Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_EXPOSURE_INDEX Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_READ or WIA_PROP_RW Expected property type WIA_PROP_LIST (or RANGE or NONE) Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn't exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
If the property has WIA_PROP_RW access, do step 4. Else do step 5
4 - CheckSuppValues | Verify if all the reported values are really supported by the property. If the property has read-only access, skip this test.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_EXPOSURE_INDEX Value: Any Value since this property is Read-only Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
6 - StopWIA |


TD-13.4.2.33 WIA_DPC_EXPOSURE_METERING_MODE Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_EXPOSURE_METERING_MODE Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_READ or WIA_PROP_RW Expected property type WIA_PROP_LIST (or RANGE or NONE) Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn't exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
If the property has WIA_PROP_RW access, do step 4. Else do step 5
4 - CheckSuppValues | Verify if all the reported values are really supported by the property. If the property has read-only access, skip this test.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_EXPOSURE_METERING_MODE Value: Any Value since this property is Read-only Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
6 - StopWIA |


TD-13.4.2.34 WIA_DPC_FOCUS_METERING_MODE Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_FOCUS_METERING_MODE Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_READ or WIA_PROP_RW Expected property type WIA_PROP_LIST (or RANGE or NONE) Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn't exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
If the property has WIA_PROP_RW access, do step 4. Else do step 5
4 - CheckSuppValues | Verify if all the reported values are really supported by the property. If the property has read-only access, skip this test.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_FOCUS_METERING_MODE Value: Any Value since this property is Read-only Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
6 - StopWIA |


TD-13.4.2.35 WIA_DPC_FOCUS_DISTANCE Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_FOCUS_DISTANCE Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_READ or WIA_PROP_RW Expected property type WIA_PROP_LIST (or RANGE or NONE) Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn't exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
If the property has WIA_PROP_RW access, do step 4. Else do step 5
4 - CheckSuppValues | Verify if all the reported values are really supported by the property. If the property has read-only access, skip this test.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_FOCUS_DISTANCE Value: Any Value since this property is Read-only Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
6 - StopWIA |


TD-13.4.2.36 WIA_DPC_FOCAL_LENGTH Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_FOCAL_LENGTH Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_READ or WIA_PROP_RW Expected property type WIA_PROP_LIST (or RANGE or NONE) Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn't exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
If the property has WIA_PROP_RW access, do step 4. Else do step 5
4 - CheckSuppValues | Verify if all the reported values are really supported by the property. If the property has read-only access, skip this test.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_FOCAL_LENGTH Value: Any Value since this property is Read-only Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
6 - StopWIA |


TD-13.4.2.37 WIA_DPC_RGB_GAIN Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_RGB_GAIN Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_READ or WIA_PROP_RW Expected property type WIA_PROP_LIST (or RANGE or NONE) Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn't exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
If the property has WIA_PROP_RW access, do step 4. Else do step 5
4 - CheckSuppValues | Verify if all the reported values are really supported by the property. If the property has read-only access, skip this test.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_RGB_GAIN Value: Any Value since this property is Read-only Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
6 - StopWIA |


TD-13.4.2.38 WIA_DPC_WHITE_BALANCE Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_WHITE_BALANCE Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FLASE Expected property access: WIA_PROP_READ or WIA_PROP_RW Expected property type WIA_PROP_LIST (or RANGE or NONE) Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn't exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
If the property has WIA_PROP_RW access, do step 4. Else do step 5
4 - CheckSuppValues | Verify if all the reported values are really supported by the property. If the property has read-only access, skip this test.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_WHITE_BALANCE Value: Any Value since this property is Read-only Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
6 - StopWIA |


TD-13.4.2.39 WIA_DPC_UPLOAD_URL Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_UPLOAD_URL Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_RW Expected property type WIA_PROP _NONE Expected property subtype: VT_BSTR
Comments: | If the returned result is S_FALSE (the property doesn't exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_UPLOAD_URL Value: "TEST STRING" Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if the expected result is not S_OK. Continue testing otherwise
5 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_UPLOAD_URL Target: root item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: "TEST STRING"
Comments: | FAILED if one of the expected values doesn't match the reported one. PASSED otherwise.
6 - StopWIA |


TD-13.4.2.40 WIA_DPC_ARTIST Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_ARTIST Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_RW Expected property type WIA_PROP _NONE Expected property subtype: VT_BSTR
Comments: | If the returned result is S_FALSE (the property doesn't exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_ARTIST Value: "TEST STRING" Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if the expected result is not S_OK. Continue testing otherwise
5 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_ARTIST Target: root item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: "TEST STRING"
Comments: | FAILED if one of the expected values doesn't match the reported one. PASSED otherwise.
6 - StopWIA |


TD-13.4.2.41 WIA_DPC_COPYRIGHT_INFO Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_COPYRIGHT_INFO Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_RW Expected property type WIA_PROP _NONE Expected property subtype: VT_BSTR
Comments: | If the returned result is S_FALSE (the property doesn't exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_COPYRIGHT_INFO Value: "TEST STRING" Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if the expected result is not S_OK. Continue testing otherwise
5 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPC_COPYRIGHT_INFO Target: root item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: "TEST STRING"
Comments: | FAILED if one of the expected values doesn't match the reported one. PASSED otherwise.
6 - StopWIA |


TD-13.4.3 Scanner Device Properties

TD-13.4.3.1 WIA_DPS_HORIZONTAL_BED_SIZE Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue testing if the device is a flatbed scanner. Otherwise the test is PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPS_HORIZONTAL_BED_SIZE Target: root item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type WIA_PROP _NONE Expected property subtype: VT_I4
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPS_HORIZONTAL_BED_SIZE Value: <any value> Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.3.2 WIA_DPS_VERTICAL_BED_SIZE Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue testing if the device is a flatbed scanner. Otherwise the test is PASSED.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPS_VERTICAL_BED_SIZE Target: root item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type WIA_PROP _NONE Expected property subtype: VT_I4
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPS_VERTICAL_BED_SIZE Value: <any value> Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.3.3 WIA_DPS_HORIZONTAL_SHEET_FEED_SIZE Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue testing if the device is a sheet-fed and handheld or it is a scanner with sheet-fed ADF. PASSED if the device is a photo, slide, film, flatbed scanner or camera.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPS_HORIZONTAL_SHEET_FEED_SIZE Target: root item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type WIA_PROP _NONE Expected property subtype: VT_I4
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPS_HORIZONTAL_SHEET_FEED_SIZE Value: <any value> Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.3.4 WIA_DPS_VERTICAL_SHEET_FEED_SIZE Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue testing if the device type is a sheet-fed and handheld or it is a scanner with sheet-fed ADF. PASSED if the device type is a photo, slide, film, flatbed scanner or camera.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPS_VERTICAL_SHEET_FEED_SIZE Target: root item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type WIA_PROP _NONE Expected property subtype: VT_I4
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPS_VERTICAL_SHEET_FEED_SIZE Value: <any value> Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.3.5 WIA_DPS_SHEET_FEEDER_REGISTRATION Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue testing if the device is a sheet-fed or a hand-held scanner. PASSED if the device is a camera.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPS_SHEET_FEEDER_REGISTRATION Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_READ Expected property type WIA_PROP _NONE Expected property subtype: VT_I4 Expected property value: LEFT_JUSTIFIED or CENTERED or RIGHT_JUSTIFIED
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPS_SHEET_FEEDER_REGISTRATION Value: <any value> Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.3.6 WIA_DPS_HORIZONTAL_BED_REGISTRATION Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue testing if the device is a flatbed scanner. PASSED if the device is a camera.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPS_HORIZONTAL_BED_REGISTRATION Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_READ Expected property type WIA_PROP _NONE Expected property subtype: VT_I4 Expected property value: LEFT_JUSTIFIED or CENTERED or RIGHT_JUSTIFIED
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPS_HORIZONTAL_BED_REGISTRATION Value: <any value> Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.3.7 WIA_DPS_VERTICAL_BED_REGISTRATION Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue testing if the device is a scanner. PASSED if the device is a camera.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPS_VERTICAL_BED_REGISTRATION Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_READ Expected property type WIA_PROP _NONE Expected property subtype: VT_I4 Expected property value: TOP_JUSTIFIED or CENTERED or BOTTOM_JUSTIFIED
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPS_VERTICAL_BED_REGISTRATION Value: <any value> Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.3.8 WIA_DPS_PAD_COLOR Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue testing if the device is a scanner. PASSED if the device is a camera.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPS_PAD_COLOR Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_READ or WIA_PROP_RW Expected property type WIA_PROP _NONE Expected property subtype: RGBQUAD
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - StopWIA |


TD-13.4.3.9 WIA_DPS_DOCUMENT_HANDLING_CAPABILITIES Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue testing if the device type is a feed-to-platen or sheet-fed ADF is present. PASSED otherwise.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPS_DOCUMENT_HANDLING_CAPABILITIES Target: root item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type WIA_PROP _NONE Expected property subtype: VT_I4 Expected property value:
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPS_DOCUMENT_HANDLING_CAPABILITIES Value: <any value> Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.3.10 WIA_DPS_DOCUMENT_HANDLING_STATUS Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue testing if the device is a scanner. PASSED if the device is a camera.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPS_DOCUMENT_HANDLING_STATUS Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_READ Expected property type WIA_PROP _NONE Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPS_DOCUMENT_HANDLING_STATUS Value: <any value> Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.3.11 WIA_DPS_DOCUMENT_HANDLING_SELECT Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue testing if the device is a scanner. PASSED if the device is a camera.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPS_DOCUMENT_HANDLING_SELECT Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_RW Expected property type WIA_PROP _FLAG Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPS_DOCUMENT_HANDLING_SELECT Value: <any value> Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.3.12 WIA_DPS_DOCUMENT_HANDLING_CAPACITY Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue testing if the device type is a feed-to-platen or sheet-fed ADF is present. PASSED otherwise.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPS_DOCUMENT_HANDLING_CAPACITY Target: root item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type WIA_PROP _NONE Expected property subtype: VT_I4
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPS_DOCUMENT_HANDLING_CAPACITY Value: <any value> Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.3.13 WIA_DPS_OPTICAL_XRES Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue testing if the device is a scanner. PASSED if the device is a camera.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPS_OPTICAL_XRES Target: root item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type WIA_PROP _NONE Expected property subtype: VT_I4
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPS_OPTICAL_XRES Value: <any value> Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.3.14 WIA_DPS_OPTICAL_YRES Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue testing if the device is a scanner. PASSED if the device is a camera.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPS_OPTICAL_YRES Target: root item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type WIA_PROP _NONE Expected property subtype: VT_I4 Expected property value: > 0 and < 100,000
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPS_OPTICAL_YRES Value: <any value> Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.3.15 WIA_DPS_PLATEN_COLOR Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue testing if the device is a scanner. PASSED if the device is a camera.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPS_PLATEN_COLOR Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_READ Expected property type WIA_PROP _NONE Expected property subtype: RGBQUAD
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPS_PLAYEN_COLOR Value: <any value> Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.3.16 WIA_DPS_ENDORSER_CHARACTERS Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue testing if the device is a scanner. PASSED if the device is a camera.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPS_ENDORSER_CHARACTERS Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_READ Expected property type WIA_PROP _NONE Expected property subtype: VT_BSTR
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPS_ENDORSER_CHARACTERS Value: <any value> Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.3.17 WIA_DPS_ENDORSER_STRING Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue testing if the device is a scanner. PASSED if the device is a camera.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPS_ENDORSER_STRING Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_RW Expected property type WIA_PROP _NONE Expected property subtype: VT_BSTR
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPS_ENDORSER_STRING Value: "TEST STRING" Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if the expected result is not S_OK. Continue testing otherwise.
5 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPS_ENDORSER_STRING Target: root item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: "TEST STRING"
Comments: | FAILED if one of the expected values doesn’t match the reported one. PASSED otherwise.
6 - StopWIA |


TD-13.4.3.18 WIA_DPS_SCAN_AHEAD_PAGES Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue testing if the device is a scanner. PASSED if the device is a camera.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPS_SCAN_AHEAD_PAGES Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_RW Expected property type WIA_PROP_RANGE Expected property subtype: VT_I4 Expected property value: WIA_SCAN_AHEAD_ALL or a value greater or equal to 0
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPS_SCAN_AHEAD_PAGES Value: 0 Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | NOTE: A value of zero disables scan ahead. FAILED if the expected result is not S_OK. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPS_SCAN_AHEAD_PAGES Value: Illegal Value Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
6 - StopWIA |


TD-13.4.3.19 WIA_DPS_MAX_SCAN_TIME Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue testing if the device is a scanner. PASSED if the device is a camera.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPS_MAX_SCAN_TIME Target: root item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type WIA_PROP _NONE Expected property subtype: VT_I4 Expected property value: > 0
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPC_MAX_SCAN_TIME Value: <any value> Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.3.20 WIA_DPS_PAGES Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue testing if the device is a scanner. PASSED if the device is a camera.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPS_PAGES Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_RW Expected property type WIA_PROP _LIST Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPS_PAGES Value: 1 Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | NOTE: Applications that do not support multi-page scans should set this value to one, if it is present. FAILED if the expected result is not S_OK. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPS_PAGES Value: Illegal Value Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
6 - StopWIA |


TD-13.4.3.21 WIA_DPS_PAGE_SIZE Test Description

Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue testing if the device is a scanner. PASSED if the device is a camera.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPS_PAGE_SIZE Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_RW Expected property type WIA_PROP_LIST Expected property subtype: VT_I4 Expected property value: WIA_PAGE_LETTER or WIA_PAGE_LEGAL or WIA_PAGE_A4
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - CheckSuppValues | Verify if all the reported values are really supported by the property.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPS_PAGE_SIZE Value: Illegal Value Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
6 - StopWIA |


TD-13.4.3.22 WIA_DPS_TRANSPARENCY Test Description

Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue testing if the device is a scanner. PASSED if the device is a camera.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPS_TRANSPARENCY Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_I4 Expected property value: A combination of the following flags LIGHT_SOURCE_PRESENT_DETECT, LIGHT_SOURCE_PRESENT, LIGHT_SOURCE_DETECT_READY and LIGHT_SOURCE_READY
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPS_TRANSPARENCY Value: <any value> Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.3.23 WIA_DPS_TRANSPARENCY_SELECT Test Description

Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue testing if the device is a scanner. PASSED if the device is a camera.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPS_TRANSPARENCY_SELECT Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_RW Expected property type: WIA_PROP_FLAG Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - CheckSuppValues | Verify if all the reported values are really supported by the property.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPS_TRANSPARENCY_SELECT Value: Illegal Value Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
6 - StopWIA |


TD-13.4.3.24 WIA_DPS_PAGE_WIDTH Test Description

Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue testing if the device is a scanner. PASSED if the device is a camera.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPS_PAGE_WIDTH Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_RW Expected property type: WIA_PROP_RANGE Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPS_PAGE_WIDTH Value: Illegal Value Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.3.25 WIA_DPS_PAGE_HEIGHT Test Description

Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue testing if the device is a scanner. PASSED if the device is a camera.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPS_PAGE_HEIGHT Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_RW Expected property type: WIA_PROP_RANGE Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPS_PAGE_HEIGHT Value: Illegal Value Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.3.26 WIA_DPS_PREVIEW Test Description

Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue testing if the device is a scanner. PASSED if the device is a camera.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPS_PREVIEW Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_RW Expected property type: WIA_PROP_LIST Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - CheckSuppValues | Verify if all the reported values are really supported by the property.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: root item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPS_PREVIEW Value: Illegal Value Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
6 - StopWIA |


TD-13.4.3.27 WIA_DPS_MIN_HORIZONTAL_SHEET_FEED_SIZE Test Description

Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue testing if the device is a sheet-fed and handheld or it is a scanner with sheet-fed ADF. PASSED if the device is a photo, slide, film, flatbed scanner or camera.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPS_MIN_HORIZONTAL_SHEET_FEED_SIZE Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_READ Expected property type WIA_PROP _NONE Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn't exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPS_MIN_HORIZONTAL_SHEET_FEED_SIZE Value: <any value> Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
56 - StopWIA |


TD-13.4.3.28 WIA_DPS_MIN_VERTICAL_SHEET_FEED_SIZE Test Description

Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue testing if the device is a sheet-fed and handheld or it is a scanner with sheet-fed ADF. PASSED if the device is a photo, slide, film, flatbed scanner or camera.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPS_VERTICAL_SHEET_FEED_SIZE Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_READ Expected property type WIA_PROP _NONE Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn't exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPS_VERTICAL_SHEET_FEED_SIZE Value: <any value> Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
56 - StopWIA |


TD-13.4.3.29 WIA_DPS_SHOW_PREVIEW_CONTROL Test Description

Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: DUT
PASS/FAIL Criteria: |
Comments: | Continue testing if the device is a sheet-fed and handheld or it is a scanner with sheet-fed ADF. PASSED if the device is a photo, slide, film, flatbed scanner or camera.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DPS_SHOW_PREVIEW_CONTROL Target: root item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_READ Expected property type WIA_PROP _NONE Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE (the property doesn't exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_DPS_SHOW_PREVIEW_CONTROL Value: <any value> Target: root item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
56 - StopWIA |


TD-13.4.4.1 WIA_IPA_ITEM_NAME Test Description

Test Function | Description
1 - StartWIA |
For every item in the device’s tree repeat step 2 and 3
2 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_NAME Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_BSTR Expected property value: current_value
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise
If current_item is the root item and If current_value != "Root" the test is FAILED.
3 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_NAME Value: <any value> Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
4 - StopWIA |


TD-13.4.4.2 WIA_IPA_FULL_ITEM_NAME Test Description

# - Test Function | Description
1 - StartWIA |
For every item in the device’s tree repeat steps 2 and 4
2 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_FULL_ITEM_NAME Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_BSTR Expected property value: current_value
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise
If current_item is the root item execute step 3
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_DIP_DEV_ID Let deviceId be the returned property value.
If current_value != "\"+deviceId+"\Root" the test is FAILED.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_FULL_ITEM_NAME Value: <any value> Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
5 - StopWIA |


TD-13.4.4.3 WIA_IPA_ITEM_FLAGS Test Description

Test Function | Description
1 - StartWIA |
For every item in the device’s tree repeat step 2 and 3
2 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_ FLAGS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_FLAG Expected property subtype: VT_I4 Expected property value: current_value
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise
If current_item is the root item and If current_value != (WiaItemTypeDevice | WiaItemTypeRoot | WiaItemTypeFolder) the test is FAILED
3 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_ FLAGS Value: <any value> Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
4 - StopWIA |


TD-13.4.4.4 WIA_IPA_ITEM_TIME Test Description

Test Function | Description
1 - StartWIA |
For every item in the device’s tree repeat steps 2..3
2 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_TIME Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_I4 | VT_VECTOR Expected property value: A valid SYSTEMTIME value.
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise
3 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_TIME Value: <any value> Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
4 - StopWIA |


TD-13.4.4.5 WIA_IPA_ACCESS_RIGHTS Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the property data for the target item.
Parameters: | Target: Device under test
PASS/FAIL Criteria: | Expected result: deviceType
Comments: |
For every item in the device’s tree,If (deviceType =Scanner) repeat steps 3, 4. Else repeat steps 5, 6
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ACCESS_RIGHTS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_I4 Expected property value: WIA_ITEM_READ, WIA_ITEM_WRITE, WIA_ITEM_RD, WIA_ITEM_RWD or WIA_ITEM_CAN_BE_DELETED
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_ACCESS_RIGHTS Value: <any value> Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
5 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ACCESS_RIGHTS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_RW Expected property type: WIA_PROP_FLAG Expected property subtype: VT_I4 Expected property value: WIA_ITEM_READ, WIA_ITEM_WRITE, WIA_ITEM_RD, WIA_ITEM_RWD or WIA_ITEM_CAN_BE_DELETED
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise
6 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_ACCESS_RIGHTS Value: Illegal Value Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise
7 - StopWIA |


TD-13.4.4.6 WIA_IPA_DATATYPE Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the property data for the target item.
Parameters: | Target: Device under test
PASS/FAIL Criteria: | Expected result: deviceType
Comments: |
For every item in the device’s tree, If (deviceType =Camera) repeat steps 3, 4. Else repeat steps 5..7
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_DATATYPE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_I4 Expected property value: WIA_DATA_THRESHOLD or WIA_DATA_DITHER or WIA_DATA_GRAYSCALE or WIA_DATA_COLOR or WIA_DATA_COLOR_THRESHOLD or WIA_DATA_COLOR_DITHER.
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_DATATYPE Value: <any value> Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
5 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_DATATYPE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_RW Expected property type: WIA_PROP_LIST Expected property subtype: VT_I4 Expected property value: WIA_DATA_THRESHOLD or WIA_DATA_DITHER or WIA_DATA_GRAYSCALE or WIA_DATA_COLOR or WIA_DATA_COLOR_THRESHOLD or WIA_DATA_COLOR_DITHER.
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise
6 - CheckSuppValues | Verify if all the reported values are really supported by the property.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Issues a SetProperty and then a GetProperty for every reported supported value. The SetProperty function should return S_OK and the GetProperty function should return the same value for the property as the one that was just set. Otherwise the test is FAILED. FAILED if one of the supported values cannot be set or the property value after the SetProperty operation doesn’t match the one just set. Continue testing otherwise
7 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_DATATYPE Value: Illegal Value Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
8 - StopWIA |


TD-13.4.4.7 WIA_IPA_DEPTH Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the property data for the target item.
Parameters: | Target: Device under test
PASS/FAIL Criteria: | Expected result: deviceType
Comments: |
For every item in the device’s tree, If ((deviceType = Scanner) and [device allows the depth to be set] ) repeat steps 3 and 4. Else repeat steps 5 and 6.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_DEPTH Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_I4
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_DEPTH Value: <any value> Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
5 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_DEPTH Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_RW Expected property type: WIA_PROP_LIST Expected property subtype: VT_I4
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise
6 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_DEPTH Value: Illegal Value Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
7 - StopWIA |


TD-13.4.4.8 WIA_IPA_PREFERRED_FORMAT Test Description

# - Test Function | Description
1 - StartWIA |
For every item in the device’s tree repeat steps 2..3
2 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_PREFERRED_FORMAT Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_CLSID Expected property value: IMGFMT_MEMORYBMP or IMGFMT_BMP or IMGFMT_EMF or IMGFMT_WMF or IMGFMT_JPEG or IMGFMT_PNG or IMGFMT_GIF or IMGFMT_TIFF or IMGFMT_EXIF or IMGFMT_PHOTOCD or IMGFMT_FLASHPIX or IMGFMT_ICO
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise
3 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_PREFERRED_FORMAT Value: <any value> Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
4 - StopWIA |


TD-13.4.4.9 WIA_IPA_FORMAT Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the property data for the target item.
Parameters: | Target: Device under test
PASS/FAIL Criteria: | Expected result: deviceType
Comments: |
For every item in the device’s tree execute steps 3 and 4
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ FORMAT Target: current_item Let ipaTymed be the returned property value
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ FORMAT Target: current_item Let ipaFormatList the returned list of values.
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ if (deviceType = camera); WIA_PROP_RW otherwise. Expected property type: WIA_PROP_LIST Expected property subtype: VT_CLSID Expected property value: IMGFMT_MEMORYBMP or IMGFMT_BMP or IMGFMT_EMF or IMGFMT_WMF or IMGFMT_JPEG or IMGFMT_PNG or IMGFMT_GIF or IMGFMT_TIFF or IMGFMT_EXIF or IMGFMT_PHOTOCD or IMGFMT_FLASHPIX or IMGFMT_ICO.
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
If ( (ipaTymed = TYMED_CALLBACK) and [ipaFormatList include IMGFMT_MEMORYBMP]) the test is PASSED. Otherwise the test is FAILED If ( (ipaTymed = TYMED_FILE) and [ipaFormatList include IMGFMT_BMP]) the test is PASSED. Otherwise the test is FAILED
5 - StopWIA |


TD-13.4.4.10 WIA_IPA_COMPRESSION Test Description

# - Test Function | Description
1 - StartWIA |
For every item in the device’s tree repeat steps 2..5
2 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_COMPRESSION Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_RW or WIA_PROP_READ Expected property type: WIA_PROP_LIST if the access is WIA_PROP_RW; WIA_PROP_NONE if the access is WIA_PROP_READ. Expected property subtype: VT_I4 Expected property value: WIA_COMPRESSION_NONE or WIA_COMPRESSION_BI_RLE4 or WIA_COMPRESSION_BI_RLE8 or WIA_COMPRESSION_G3
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise
If the property has WIA_PROP_RW access execute steps 3 and 4. Otherwise execute step 5.
3 - CheckSuppValues | Verify if all the reported values are really supported by the property.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_COMPRESSION Value: Illegal Value Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_COMPRESSION Value: <any value> Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
6 - StopWIA |


TD-13.4.4.11 WIA_IPA_TYMED Test Description

# - Test Function | Description
1 - StartWIA |
For every item in the device’s tree repeat step 2..4
2 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_TYMED Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_RW Expected property type: WIA_PROP_LIST Expected property subtype: VT_I4 Expected property value: TYMED_CALLBACK or TYMED_FILE
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise
3 - CheckSuppValues | Verify if all the reported values are really supported by the property.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_TYMED Value: Illegal Value Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
5 - StopWIA |


TD-13.4.4.12 WIA_IPA_CHANNELS_PER_PIXEL Test Description

Test Function | Description
1 - StartWIA |
For every item in the device’s tree repeat step 2..4
2 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_CHANNELS_PER_PIXEL Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_I4
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise
3 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_CHANNELS_PER_PIXEL Value: <any value> Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
4 - StopWIA |


TD-13.4.4.13 WIA_IPA_BITS_PER_CHANNELTest Description

# - Test Function | Description
1 - StartWIA |
For every item in the device’s tree repeat steps 2..5.
2 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_BITS_PER_CHANNEL Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_RW or WIA_PROP_READ Expected property type: WIA_PROP_LIST if the access is WIA_PROP_RW; WIA_PROP_NONE if the access is WIA_PROP_READ Expected property subtype: VT_I4 Expected property value: 1 or 4 or 8
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise
If the property access is WIA_PROP_READ execute steps 3, 4. Otherwise execute step 5.
3 - CheckSuppValues | Verify if all the reported values are really supported by the property.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_BITS_PER_CHANNEL Value: Illegal Value Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_BITS_PER_CHANNEL Value: <any value> Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
6 - StopWIA |


TD-13.4.4.14 WIA_IPA_PLANAR Test Description

# - Test Function | Description
1 - StartWIA |
For every item in the device’s tree repeat steps 2..4
2 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_PLANAR Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_I4 Expected property value: WIA_PACKED_PIXEL or WIA_PLANAR
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise
3 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_PLANAR Value: <any value> Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
4 - StopWIA |


TD-13.4.4.15 WIA_IPA_PIXELS_PER_LINE Test Description

# - Test Function | Description
1 - StartWIA |
For every item in the device’s tree repeat step 2..3
2 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_PIXELS_PER_LINE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_I4
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise
3 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_PIXELS_PER_LINE Value: <any value> Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
4 - StopWIA |


TD-13.4.4.16 WIA_IPA_BYTES_PER_LINE Test Description

# - Test Function | Description
1 - StartWIA |
For every item in the device’s tree repeat steps 2..3
2 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ BYTES _PER_LINE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_I4
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise
3 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_ BYTES _PER_LINE Value: <any value> Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
4 - StopWIA |


TD-13.4.4.17 WIA_IPA_NUMBER_OF_LINES Test Description

# - Test Function | Description
1 - StartWIA |
For every item in the device’s tree repeat steps 2..3
2 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_NUMBER_OF_LINES Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_I4
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise
3 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_NUMBER_OF_LINES Value: <any value> Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
4 - StopWIA |


TD-13.4.4.18 WIA_IPA_GAMMA_CURVES Test Description

# - Test Function | Description
1 - StartWIA |
For every item in the device’s tree repeat steps 2..3
2 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_GAMMA_CURVES Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_RW Expected property type: WIA_PROP_LIST or WIA_PROP_RANGE Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE continue testing with other tree item, since the property is optional. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise
3 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_GAMMA_CURVES Value: Illegal Value Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
4 - StopWIA |


TD-13.4.4.19 WIA_IPA_ITEM_SIZE Test Description

# - Test Function | Description
1 - StartWIA |
For every item in the device’s tree repeat steps 2..3
2 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_SIZE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_I4
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise
3 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_SIZE Value: <any value> Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
4 - StopWIA |


TD-13.4.4.20 WIA_IPA_MIN_BUFFER_SIZE Test Description

# - Test Function | Description
1 - StartWIA |
For every item in the device’s tree repeat steps 2..3
2 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_MIN_BUFFER_SIZE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_I4
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
3 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_MIN_BUFFER_SIZE Value: <any value> Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
4 - StopWIA |


TD-13.4.4.21 WIA_IPA_REGION_TYPE Test Description

# - Test Function | Description
1 - StartWIA |
For every item in the device’s tree repeat steps 2..3
2 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_REGION_TYPE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_BSTR Expected property value: WIA_TEXT_ITEM or WIA_PHOTO_ITEM or WIA_DRAWING_ITEM or WIA_LOGO_ITEM or WIA_HANDWRITING_ITEM or WIA_CHART_ITEM or WIA_TABLE_ITEM
Comments: | If the returned result is S_FALSE continue testing with other tree item, since the property is optional.
3 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_REGION_TYPE Value: <any value> Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
4 - StopWIA |


TD-13.4.4.22 WIA_IPA_ICM_PROFILE_NAME Test Description

# - Test Function | Description
1 - StartWIA |
For every item in the device’s tree repeat steps 2..3
2 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ICM_PROFILE_NAME Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_RW Expected property type: WIA_PROP_LIST Expected property subtype: VT_BSTR
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
3 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_ICM_PROFILE_NAME Value: <any value> Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
4 - StopWIA |


TD-13.4.4.23 WIA_IPA_APP_COLOR_MAPPING Test Description

Test Function | Description
1 - StartWIA |
For every item in the device’s tree repeat steps 2..4
2 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_APP_COLOR_MAPPING Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_RW Expected property type: WIA_PROP_LIST Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE continue testing with other tree item, since the property is optional.
3 - CheckSuppValues | Verify if all the reported values are really supported by the property.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_APP_COLOR_MAPPING Value: Illegal Value Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. PASSED otherwise.
5 - StopWIA |


TD-13.4.4.24 WIA_IPA_PROP_STREAM_COMPAT_ID Test Description

Test Function | Description
1 - StartWIA |
For every item in the device’s tree repeat steps 2..3
2 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_PROP_STREAM_COMPAT_ID Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_RW Expected property type: WIA_PROP_LIST Expected property subtype: Expected property value:
Comments: | If the returned result is S_FALSE continue testing with other tree item, since the property is optional.
3 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_PROP_STREAM_COMPAT_ID Value: Illegal Value Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
4 - StopWIA |


TD-13.4.4.25 WIA_IPA_FILENAME_EXTENSION Test Description

Test Function | Description
1 - StartWIA |
For every item in the device’s tree repeat steps 2..3
2 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_FILENAME_EXTENSION Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_BSTR Expected property value:
Comments: | If the returned result is S_FALSE continue testing with other tree item, since the property is optional.
3 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_FILENAME_EXTENSION Value: <any value> Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
4 - StopWIA |


TD-13.4.4.26 WIA_IPA_SUPPRESS_PROPERTY_PAGE Test Description

Test Function | Description
1 - StartWIA |
For every item in the device’s tree repeat steps 2..3
2 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_SUPPRESS_PROPERTY_PAGE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_I4 Expected property value:
Comments: | If the returned result is S_FALSE continue testing with other tree item, since the property is optional.
3 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_SUPPRESS_PROPERTY_PAGE Value: <any value> Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
4 - StopWIA |


TD-13.4.5.1 WIA_IPC_THUMBNAIL Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType |
Parameters: | Target: Device under test.
PASS/FAIL Criteria: | none
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
For every item in the device’s tree repeat steps 3, 4.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property:WIA_IPA_ITEM_FLAGS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | If the returned property has the flag WiaItemTypeImage cleared continue with the next tree item, since this is not an image-type item.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPC_THUMBNAIL Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_UI1 | VT_VECTOR
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
5 - StopWIA |


TD-13.4.5.2 WIA_IPC_THUMB_WIDTH Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType |
Parameters: | Target: Device under test.
PASS/FAIL Criteria: | none
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
For every item in the device’s tree repeat steps 3..5.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property:WIA_IPA_ITEM_FLAGS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | If the returned property has the flag WiaItemTypeImage cleared continue with the next tree item, since this is not an image-type item.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPC_THUMB_WIDTH Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_I4
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPC_THUMB_WIDTH Value: <any value> Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
6 - StopWIA |


TD-13.4.5.3 WIA_IPC_THUMB_HEIGHT Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType |
Parameters: | Target: Device under test.
PASS/FAIL Criteria: | None
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
For every item in the device’s tree repeat steps 3..5
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property:WIA_IPA_ITEM_FLAGS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | If the returned property has the flag WiaItemTypeImage cleared continue with the next tree item, since this is not an image-type item.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPC_THUMB_HEIGHT Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_I4
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPC_THUMB_WIDTH Value: <any value> Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
6 - StopWIA |


TD-13.4.5.4 WIA_IPC_AUDIO_AVAILABLE Test Description

Test Function | Description
1 - StartWIA |
2 - GetDeviceType |
Parameters: | Target: Device under test.
PASS/FAIL Criteria: | None
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
For every item in the device’s tree repeat steps 3..5
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property:WIA_IPA_ITEM_FLAGS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | If the returned property has the flag WiaItemTypeImage cleared continue with the next tree item, since this is not an image-type item.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPC_AUDIO_AVAILABLE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE continue testing with other tree item, since the property is optional. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPC_AUDIO_AVAILABLE Value: <any value> Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
6 - StopWIA |


TD-13.4.5.5 WIA_IPC_AUDIO_DATA_FORMAT Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType |
Parameters: | Target: Device under test.
PASS/FAIL Criteria: | None
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
For every item in the device’s tree repeat steps 3..5
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property:WIA_IPA_ITEM_FLAGS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | If the returned property has the flag WiaItemTypeImage cleared continue with the next tree item, since this is not an image-type item.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPC_AUDIO_DATA_FORMAT Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_CLSID
Comments: | If the returned result is S_FALSE continue testing with other tree item, since the property is optional.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPC_AUDIO_DATA_FORMAT Value: <any value> Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
6 - StopWIA |


TD-13.4.5.6 WIA_IPC_AUDIO_DATA Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType |
Parameters: | Target: Device under test.
PASS/FAIL Criteria: | None
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
For every item in the device’s tree repeat steps 3..5
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property:WIA_IPA_ITEM_FLAGS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | If the returned property has the flag WiaItemTypeImage cleared continue with the next tree item, since this is not an image-type item.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPC_AUDIO_DATA Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_UI1 | VT_VECTOR
Comments: | If the returned result is S_FALSE continue testing with other tree item, since the property is optional.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPC_AUDIO_DATA Value: <any value> Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
6 - StopWIA |


TD-13.4.5.7 WIA_IPC_SEQUENCE Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType |
Parameters: | Target: Device under test.
PASS/FAIL Criteria: | None
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
For every item in the device’s tree repeat steps 3..5
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property:WIA_IPA_ITEM_FLAGS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | If the returned property has the flag WiaItemTypeImage cleared continue with the next tree item, since this is not an image-type item.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPC_SEQUENCE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE continue testing with other tree item, since the property is optional. FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPC_SEQUENCE Value: <any value> Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
6 - StopWIA |


TD-13.4.5.8 WIA_IPC_TIMEDELAY Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType |
Parameters: | Target: Device under test.
PASS/FAIL Criteria: | None
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
For every item in the device’s tree repeat steps 3..5
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property:WIA_IPA_ITEM_FLAGS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | If the returned property has the flag WiaItemTypeImage cleared continue with the next tree item, since this is not an image-type item.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPC_TIMEDELAY Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE continue testing with other tree item, since the property is optional. FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPC_TIMEDELAY Value: <any value> Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
6 - StopWIA |


TD-13.4.5.9 WIA_IPC_NUM_PICT_PER_ROW Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType |
Parameters: | Target: Device under test.
PASS/FAIL Criteria: | None
Comments: | Continue if the device type is a camera. Otherwise return PASSED.
For every item in the device’s tree repeat steps 3..5
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property:WIA_IPA_ITEM_FLAGS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | If the returned property has the flag WiaItemTypeImage cleared continue with the next tree item, since this is not an image-type item.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPC_NUM_PICT_PER_ROW Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_I4
Comments: | If the returned result is S_FALSE continue testing with other tree item, since the property is optional. FAILED if one of the expected values doesn't match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPC_NUM_PICT_PER_ROW Value: <any value> Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
6 - StopWIA |


TD-13.4.6 Scanner Item Properties

TD-13.4.6.1 WIA_IPS_CUR_INTENT Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType |
Parameters: | Target: Device under test.
PASS/FAIL Criteria: | None
Comments: | Continue if the device type is a scanner. Otherwise return PASSED.
For every item in the device’s tree repeat steps 3..6
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property:WIA_IPA_ITEM_FLAGS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | If the returned property has the flag WiaItemTypeImage cleared continue with the next tree item, since this is not an image-type item.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_CUR_INTENT Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_RW Expected property type: WIA_PROP_FLAG Expected property subtype: VT_I4 Expected property value: One of the following flags WIA_INTENT_NONE, WIA_INTENT_IMAGE_TYPE_COLOR, WIA_INTENT_IMAGE_TYPE_GRAYSCALE, WIA_INTENT_IMAGE_TYPE_TEXT possibly OR’ed with one of the following flags: WIA_INTENT_MINIMIZE_SIZE, WIA_INTENT_MAXIMIZE_QUALITY.
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
5 - CheckSuppValues | Verify if all the reported values are really supported by the property.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
6 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPS_CUR_INTENT Value: Illegal Value Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
7 - StopWIA |


TD-13.4.6.2 WIA_IPS_XRES Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType |
Parameters: | Target: Device under test.
PASS/FAIL Criteria: | None
Comments: | Continue if the device type is a scanner. Otherwise return PASSED.
For every item in the device’s tree repeat steps 3..6.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property:WIA_IPA_ITEM_FLAGS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | If the returned property has the flag WiaItemTypeImage cleared continue with the next tree item, since this is not an image-type item.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_XRES Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_RW Expected property type: WIA_PROP_LIST or WIA_PROP_RANGE Expected property subtype: VT_I4
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
5 - CheckSuppValues | Verify if all the reported values are really supported by the property.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
6 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPS_XRES Value: Illegal Value Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
7 - StopWIA |


TD-13.4.6.3 WIA_IPS_YRES Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType |
Parameters: | Target: Device under test.
PASS/FAIL Criteria: | None
Comments: | Continue if the device type is a scanner. Otherwise return PASSED.
For every item in the device’s tree repeat steps 3, 4.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property:WIA_IPA_ITEM_FLAGS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | If the returned property has the flag WiaItemTypeImage cleared continue with the next tree item, since this is not an image-type item.
If [the device supports the independent setting of horizontal and vertical resolutions] go to step 4. Else go to step 5.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_YRES Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_RW Expected property type: WIA_PROP_LIST or WIA_PROP_RANGE Expected property subtype: VT_I4
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
5 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_YRES Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_LIST or WIA_PROP_RANGE Expected property subtype: VT_I4
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
6 - StopWIA |


TD-13.4.6.4 WIA_IPS_XPOS Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType |
Parameters: | Target: Device under test.
PASS/FAIL Criteria: | None
Comments: | Continue if the device type is a scanner. Otherwise return PASSED.
For every item in the device’s tree repeat steps 3..6
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_FLAGS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | If the returned property has the flag WiaItemTypeImage cleared continue with the next tree item, since this is not an image-type item.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_XPOS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_RW Expected property type: WIA_PROP_LIST or WIA_PROP_RANGE Expected property subtype: VT_I4
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
5 - CheckSuppValues | Verify if all the reported values are really supported by the property.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
6 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPS_XPOS Value: Illegal Value Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
7 - StopWIA |


TD-13.4.6.5 WIA_IPS_YPOS Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType |
Parameters: | Target: Device under test.
PASS/FAIL Criteria: | None
Comments: | Continue if the device type is a scanner. Otherwise return PASSED.
For every item in the device’s tree repeat steps 3..6
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_FLAGS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | If the returned property has the flag WiaItemTypeImage cleared continue with the next tree item, since this is not an image-type item.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_YPOS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_RW Expected property type: WIA_PROP_LIST or WIA_PROP_RANGE Expected property subtype: VT_I4
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
5 - CheckSuppValues | Verify if all the reported values are really supported by the property.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
6 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPS_YPOS Value: Illegal Value Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
7 - StopWIA |


TD-13.4.6.6 WIA_IPS_XEXTENT Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType |
Parameters: | Target: Device under test.
PASS/FAIL Criteria: | None
Comments: | Continue if the device type is a scanner. Otherwise return PASSED.
For every item in the device’s tree repeat steps 3..6
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_FLAGS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | If the returned property has the flag WiaItemTypeImage cleared continue with the next tree item, since this is not an image-type item.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_XEXTENT Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_RW Expected property type: WIA_PROP_LIST or WIA_PROP_RANGE Expected property subtype: VT_I4
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
5 - CheckSuppValues | Verify if all the reported values are really supported by the property.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
6 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPS_XEXTENT Value: Illegal Value Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
7 - StopWIA |


TD-13.4.6.7 WIA_IPS_YEXTENT Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType |
Parameters: | Target: Device under test.
PASS/FAIL Criteria: | None
Comments: | Continue if the device type is a scanner. Otherwise return PASSED.
For every item in the device’s tree repeat steps 3..6
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_FLAGS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | If the returned property has the flag WiaItemTypeImage cleared continue with the next tree item, since this is not an image-type item.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_YEXTENT Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_RW Expected property type: WIA_PROP_LIST or WIA_PROP_RANGE Expected property subtype: VT_I4
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
5 - CheckSuppValues | Verify if all the reported values are really supported by the property.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
6 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPS_YEXTENT Value: Illegal Value Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
7 - StopWIA |


TD-13.4.6.8 WIA_IPS_PHOTOMETRIC_INTERP Test Description

Test Function | Description
1 - StartWIA |
2 - GetDeviceType |
Parameters: | Target: Device under test.
PASS/FAIL Criteria: | None
Comments: | Continue if the device type is a scanner. Otherwise return PASSED.
For every item in the device’s tree repeat steps 3, 4.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property:WIA_IPA_ITEM_FLAGS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | If the returned property has the flag WiaItemTypeImage cleared continue with the next tree item, since this is not an image-type item.
If [the device supports selectable photometric interpretation] go to step 4. Else go to step 5.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_PHOTOMETRIC_INTERP Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_RW Expected property type: WIA_PROP_LIST Expected property subtype: VT_I4 Expected property value: WIA_PHOTO_WHITE_1 or WIA_PHOTO_WHITE_0
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
5 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_PHOTOMETRIC_INTERP Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_I4 Expected property value: WIA_PHOTO_WHITE_1 or WIA_PHOTO_WHITE_0
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
6 - StopWIA |


TD-13.4.6.9 WIA_IPS_BRIGHTNESS Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType |
Parameters: | Target: Device under test.
PASS/FAIL Criteria: | None
Comments: | Continue if the device type is a scanner. Otherwise return PASSED.
For every item in the device’s tree repeat steps 3..6
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_FLAGS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | If the returned property has the flag WiaItemTypeImage cleared continue with the next tree item, since this is not an image-type item.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_BRIGHTNESS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_RW Expected property type: WIA_PROP_LIST or WIA_PROP_RANGE Expected property subtype: VT_I4 Expected property value: WIA_BRIGHTNESS_AUTO or WIA_BRIGHTNESS_LIGHT or WIA_BRIGHTNESS_NORM or WIA_BRIGHTNESS_DARK or a value between -1000 and 1000.
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
5 - CheckSuppValues | Verify if all the reported values are really supported by the property.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
6 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPS_BRIGHTNESS Value: Illegal Value Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
7 - StopWIA |


TD-13.4.6.10 WIA_IPS_CONTRAST Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType |
Parameters: | Target: Device under test.
PASS/FAIL Criteria: | None
Comments: | Continue if the device type is a scanner. Otherwise return PASSED.
For every item in the device’s tree repeat steps 3..6
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_FLAGS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | If the returned property has the flag WiaItemTypeImage cleared continue with the next tree item, since this is not an image-type item.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_CONTRAST Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_RW Expected property type: WIA_PROP_LIST or WIA_PROP_RANGE Expected property subtype: VT_I4 Expected property value: WIA_CONTRAST_AUTO or a value between -1000 and 1000.
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
5 - CheckSuppValues | Verify if all the reported values are really supported by the property.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
6 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPS_CONTRAST Value: Illegal Value Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
7 - StopWIA |


TD-13.4.6.11 WIA_IPS_ORIENTATION Test Description

Test Function | Description
1 - StartWIA |
2 - GetDeviceType |
Parameters: | Target: Device under test.
PASS/FAIL Criteria: | None
Comments: | Continue if the device type is a scanner. Otherwise return PASSED.
For every item in the device’s tree repeat steps 3, 4.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_FLAGS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | If the returned property has the flag WiaItemTypeImage cleared continue with the next tree item, since this is not an image-type item.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_ORIENTATION Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_NONE Expected property subtype: VT_I4 Expected property value: WIA_PORTRAIT, WIA_LANDSCAPE, WIA_ROT180 and WIA_ROT270.
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise
5 - StopWIA |


TD-13.4.6.12 WIA_IPS_ROTATION Test Description

Test Function | Description
1 - StartWIA |
2 - GetDeviceType |
Parameters: | Target: Device under test.
PASS/FAIL Criteria: | None
Comments: | Continue if the device type is a scanner. Otherwise return PASSED.
For every item in the device’s tree repeat steps 3..5
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_FLAGS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | If the returned property has the flag WiaItemTypeImage cleared continue with the next tree item, since this is not an image-type item.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_ROTATION Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_READ Expected property type: WIA_PROP_LIST Expected property subtype: VT_I4 Expected property value: WIA_PORTRAIT or WIA_LANDSCAPE or WIA_ROT180 or WIA_ROT270.
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPS_ROTATION Value: <any value> Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
6 - StopWIA |


TD-13.4.6.13 WIA_IPS_MIRROR Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType |
Parameters: | Target: Device under test.
PASS/FAIL Criteria: | None
Comments: | Continue if the device type is a scanner. Otherwise return PASSED.
For every item in the device’s tree repeat steps 3, 4.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_FLAGS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | If the returned property has the flag WiaItemTypeImage cleared continue with the next tree item, since this is not an image-type item.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_MIRROR Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK or S_FALSE Expected property access: WIA_PROP_RW or WIA_PROP_READ Expected property type: WIA_PROP_LIST if access is WIA_PROP_RW. WIA_PROP_NONE otherwise. Expected property subtype: VT_I4 Expected property value: WIA_MIRRORED
Comments: | If the returned result is S_FALSE (the property doesn’t exist) return result PASSED since the property is optional. No further testing is necessary. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
5 - StopWIA |


TD-13.4.6.14 WIA_IPS_THRESHOLD Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType |
Parameters: | Target: Device under test.
PASS/FAIL Criteria: | None
Comments: | Continue if the device type is a scanner. Otherwise return PASSED.
For every item in the device’s tree repeat steps 3, 4.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_FLAGS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | If the returned property has the flag WiaItemTypeImage cleared continue with the next tree item, since this is not an image-type item.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_THRESHOLD Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_RW Expected property type: WIA_PROP_LIST or WIA_PROP_RANGE. Expected property subtype: VT_I4
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPS_THRESHOLD Value: Illegal Value Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
6 - StopWIA |


TD-13.4.6.15 WIA_IPS_PREVIEW Test Description

Test Function | Description
1 - StartWIA |
2 - GetDeviceType |
Parameters: | Target: Device under test.
PASS/FAIL Criteria: | None
Comments: | Continue if the device type is a scanner. Otherwise return PASSED.
For every item in the device’s tree repeat steps 3..6
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_FLAGS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | If the returned property has the flag WiaItemTypeImage cleared continue with the next tree item, since this is not an image-type item.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_PREVIEW Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_RW Expected property type: WIA_PROP_LIST or WIA_PROP_RANGE. Expected property subtype: VT_I4
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
5 - CheckSuppValues | Verify if all the reported values are really supported by the property.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
6 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPS_PREVIEW Value: Illegal Value Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
7 - StopWIA |


TD-13.4.6.16 WIA_IPS_INVERT Test Description

Test Function | Description
1 - StartWIA |
2 - GetDeviceType |
Parameters: | Target: Device under test.
PASS/FAIL Criteria: | None
Comments: | Continue if the device type is a scanner. Otherwise return PASSED.
For every item in the device’s tree repeat steps 3..6
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_FLAGS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | If the returned property has the flag WiaItemTypeImage cleared continue with the next tree item, since this is not an image-type item.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_INVERT Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_RW Expected property type: WIA_PROP_LIST or WIA_PROP_RANGE. Expected property subtype: VT_I4
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
5 - CheckSuppValues | Verify if all the reported values are really supported by the property.
Parameters: | Values list: property supported values list returned from the previous GetProperty operation Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
6 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPS_INVERT Value: Illegal Value Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
7 - StopWIA |


TD-13.4.6.17 WIA_IPS_WARM_UP_TIME Test Description

Test Function | Description
1 - StartWIA |
2 - GetDeviceType |
Parameters: | Target: Device under test.
PASS/FAIL Criteria: | None
Comments: | Continue if the device type is a scanner. Otherwise return PASSED.
For every item in the device’s tree repeat steps 3, 4.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_FLAGS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | If the returned property has the flag WiaItemTypeImage cleared continue with the next tree item, since this is not an image-type item.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_WARM_UP_TIME Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_RW Expected property type: WIA_PROP_NONE. Expected property subtype: VT_I4
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPS_WARM_UP_TIME Value: <any value> Target: current_item
PASS/FAIL Criteria: | Expected result: S_FALSE
Comments: | FAILED if the expected result is not S_FALSE. Continue testing otherwise.
6 - StopWIA |


TD-13.4.7.1 WIA_IPA_TYMED Test Description

Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: Device under test.
PASS/FAIL Criteria: |
Comments: | If the device is a camera test is PASSED. Otherwise continue testing.
3 - GetFormatInfo | Determine the formats and media types of incoming data supported.
Parameters: | Target: Device under test.
PASS/FAIL Criteria: | Expected result: S_OK Expected values: A set of (formatID, mediaType) pairs. Let formatSet be the returned set.
Comments: |
For every item (current_item) in the WIA tree repeat steps 4, 5, 6.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property:WIA_IPA_FORMAT Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let oldFormat be the returned property value.
5 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_PREFERRED_FORMAT Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let oldPrefFormat be the returned property value.
For every pair (formatID, mediaType) in formatSet repeat steps 6, 7 & 8.
6 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_TYMED Value: mediaType Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: |
7 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property:WIA_IPA_FORMAT Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: formatID
Comments: |
8 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_PREFERRED_FORMAT Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: formatID
Comments: |
9 - StopWIA |


TD-13.4.7.2 WIA_IPS_INTENT Test Description

Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: Device under test.
PASS/FAIL Criteria: |
Comments: | If the device is a camera test is PASSED. Otherwise continue testing.
For every item (current_item) in the WIA tree repeat steps 3, 4.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_INTENT Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let intentSet be the returned property legal value list.
If IMAGE_TYPE_COLOR is in intentSet execute steps 4, 5.
4 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPS_INTENT Value: IMAGE_TYPE_COLOR Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: |
5 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_DATATYPE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: WIA_DATA_COLOR or WIA_DATA_COLOR_THRESHOLD or WIA_DATA_COLOR_DITHER
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
If IMAGE_TYPE_GRAYSCALE is in intentSet execute steps 6, 7.
6 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPS_INTENT Value: IMAGE_TYPE_GRAYSCALE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: |
7 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_DATATYPE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: WIA_DATA_GRAYSCALE
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
If IMAGE_TYPE_TEXT is in intentSet execute steps 8, 9.
8 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPS_INTENT Value: IMAGE_TYPE_TEXT Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: |
9 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_DATATYPE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: WIA_DATA_THRESHOLD
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
10 - StopWIA |


TD-13.4.7.3 WIA_IPA_DATATYPE Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: Device under test.
PASS/FAIL Criteria: |
Comments: | If the device is a camera test is PASSED. Otherwise continue testing.
For every item (current_item) in the WIA tree repeat steps 3-32. WIA_DATA_THRESHOLD
3 - SetProperty | Sets the property data for the target item.
Parameters: | Property WIA_IPA_DATATYPE Value: WIA_DATA_THRESHOLD Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: |
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_CHANNELS_PER_PIXEL Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: 1
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
5 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_BITS_PER_CHANNEL Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: 1
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
6 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_PLANAR Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected result:
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
7 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_DEPTH Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: 1
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
8 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_SIZE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value:
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
WIA_DATA_DITHER
9 - SetProperty | Sets the property data for the target item.
Parameters: | Property WIA_IPA_DATATYPE Value: WIA_DATA_DITHER Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: |
10 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_CHANNELS_PER_PIXEL Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: 1
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
11 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_BITS_PER_CHANNEL Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value:
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
12 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_PLANAR Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected result:
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
13 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_DEPTH Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value:
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
14 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_SIZE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value:
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
WIA_DATA_GRAYSCALE
9 - SetProperty | Sets the property data for the target item.
Parameters: | Property WIA_IPA_DATATYPE Value: WIA_DATA_GRAYSCALE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: |
10 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_CHANNELS_PER_PIXEL Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: 1
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
11 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_BITS_PER_CHANNEL Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: 8
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
12 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_PLANAR Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected result:
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
13 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_DEPTH Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: 8
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
14 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_SIZE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value:
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
WIA_DATA_COLOR
15 - SetProperty | Sets the property data for the target item.
Parameters: | Property WIA_IPA_DATATYPE Value: WIA_DATA_COLOR Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: |
16 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_CHANNELS_PER_PIXEL Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: 3
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
17 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_BITS_PER_CHANNEL Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: 8
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
18 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_PLANAR Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected result:
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
19 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_DEPTH Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: 24
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
20 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_SIZE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value:
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
WIA_DATA_COLOR_THRESHOLD
21 - SetProperty | Sets the property data for the target item.
Parameters: | Property WIA_IPA_DATATYPE Value: WIA_DATA_COLOR_THRESHOLD Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: |
22 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_CHANNELS_PER_PIXEL Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: 3
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
23 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_BITS_PER_CHANNEL Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: 8
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
24 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_PLANAR Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected result:
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
25 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_DEPTH Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: 24
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
26 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_SIZE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value:
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
WIA_DATA_COLOR_DITHER
27 - SetProperty | Sets the property data for the target item.
Parameters: | Property WIA_IPA_DATATYPE Value: WIA_DATA_COLOR_DITHER Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: |
28 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_CHANNELS_PER_PIXEL Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: 3
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
29 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_BITS_PER_CHANNEL Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: 8
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
30 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_PLANAR Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected result:
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
31 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_DEPTH Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: 24
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
32 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_SIZE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value:
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
33 - StopWIA |


TD-13.4.7.4 WIA_IPS_XRES Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: Device under test.
PASS/FAIL Criteria: |
Comments: | If the device is a camera test is PASSED. Otherwise continue testing.
For every item (current_item) in the WIA tree repeat steps 3 - 9.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_XPOS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let oldXPos be the returned property value.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_XEXTENT Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let oldXExtent be the returned property value.
5 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_PIXELS_PER_LINE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let oldPixelsPerLine be the returned property value.
6 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_BYTES_PER_LINE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let oldBytesPerLine be the returned property value.
7 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_SIZE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let oldItemSize be the returned property value.
8 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_YRES Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ or WIA_PROP_RW
Comments: | Let oldYRes be the returned property value.
If the returned property access is WIA_PROP_READ then go to step 9. Else go to step 11.
9 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_YPOS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let oldYPos be the returned property value.
10 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_YEXTENT Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let oldYExtent be the returned property value.
11 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_NUMBER_OF_LINES Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let oldNumberOfLines be the returned property value.
12 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_XRES Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let oldXRes be the returned property value.
For the minimum and maximum valid value (newXRes) of this WIA_IPS_XRES property repeat steps 13 - 19.
13 - SetProperty | Sets the property data for the target item.
Parameters: | Property WIA_IPS_XRES Value: newXRes Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let be ddd = newXRes / oldXRes.
14 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_XPOS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: ddd * oldXPos
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
15 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_XEXTENT Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: ddd * oldXExtent
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
16 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_PIXELS_PER_LINE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: ddd * oldPixelsPerLine
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
17 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_BYTES_PER_LINE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: ddd * oldBytesPerLine
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
18 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_SIZE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: ddd * oldItemSize
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
If the WIA_IPA_YRES is has WIA_PROP_READ access (see above) execute steps 19 - 22.
19 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_YRES Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: ddd * oldYRes
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
20 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_YPOS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: ddd * oldYPos
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
21 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_YEXTENT Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: ddd * oldYExtent
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
22 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_NUMBER_OF_LINES Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: ddd * oldNumberOfLines
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
23 - StopWIA |


TD-13.4.7.5 WIA_IPS_YRES Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: Device under test.
PASS/FAIL Criteria: |
Comments: | If the device is a camera test is PASSED. Otherwise continue testing.
For every item (current_item) in the WIA tree repeat steps 3 - 8.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_YRES Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property access: WIA_PROP_READ or WIA_PROP_RW
Comments: | Let oldYRes be the returned property value. If the returned property access is WIA_PROP_READ the test is PASSED. Otherwise continue testing.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_YPOS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let oldYPos be the returned property value.
5 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_YEXTENT Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let oldYExtent be the returned property value.
6 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_NUMBER_OF_LINES Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let oldNumberOfLines be the returned property value.
7 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_SIZE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let oldItemSize be the returned property value.
For the minimum and maximum valid value (newYRes) of this WIA_IPS_YRES property repeat steps 8 - 12
8 - SetProperty | Sets the property data for the target item.
Parameters: | Property WIA_IPS_YRES Value: newYRes Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let be ddd = newYRes / oldYRes.
9 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_YPOS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: ddd * oldYPos
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
10 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_YEXTENT Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: ddd * oldYExtent
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
11 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_NUMBER_OF_LINES Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: ddd * oldNumberOfLines
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
12 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_SIZE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: ddd * oldItemSize
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
13 - StopWIA |


TD-13.4.7.6 WIA_IPS_XPOS Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: Device under test.
PASS/FAIL Criteria: |
Comments: | If the device is a camera test is PASSED. Otherwise continue testing.
For every item (current_item) in the WIA tree repeat steps 3 - 5.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_XPOS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let oldXPos be the returned property value.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_XEXTENT Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let oldXExtent be the returned property value. Let [oldXExtentMin, oldXExtentMax] the range of legal values.
For the minimum and maximum valid value (newXPos) of this WIA_IPS_XPOS property repeat steps 5 - 7
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property WIA_IPS_XPOS Value: newXPos Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let be ddd = newXPos / oldXPos.
6 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_XEXTENT Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: ddd * oldXExtent Expected property legal values range: [ddd * oldXExtentMin, ddd * oldXExtentMax]
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
7 - StopWIA |


TD-13.4.7.7 WIA_IPS_YPOS Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: Device under test.
PASS/FAIL Criteria: |
Comments: | If the device is a camera test is PASSED. Otherwise continue testing.
For every item (current_item) in the WIA tree repeat steps 3 - 5.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_YPOS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let oldYPos be the returned property value.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_YEXTENT Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let oldYExtent be the returned property value. Let [oldYExtentMin, oldYExtentMax] the range of legal values.
For the minimum and maximum valid value (newYPos) of this WIA_IPS_YPOS property repeat steps 5 - 6.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property WIA_IPS_YPOS Value: newYPos Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let be ddd = newYPos / oldYPos.
6 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_YEXTENT Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: ddd * oldYExtent Expected property legal values range: [ddd * oldYExtentMin, ddd * oldYExtentMax]
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
7 - StopWIA |


TD-13.4.7.8 WIA_IPS_XEXTENT Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: Device under test.
PASS/FAIL Criteria: |
Comments: | If the device is a camera test is PASSED. Otherwise continue testing.
For every item (current_item) in the WIA tree repeat steps 3 - 7.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_XEXTENT Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let oldXExtent be the returned property value.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_PIXELS_PER_LINE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let oldPixelsPerLine be the returned property value.
5 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_BYTES_PER_LINE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let oldBytesPerLine be the returned property value.
6 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_SIZE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let oldItemSize be the returned property value.
For the minimum and maximum valid value (newXExtent) of this WIA_IPS_XEXTENT property repeat steps 7 - 10.
7 - SetProperty | Sets the property data for the target item.
Parameters: | Property WIA_IPS_XEXTENT Value: newXExtent Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let be ddd = newXExtent / oldXExtent.
8 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_PIXELS_PER_LINE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: ddd * oldPixelsPerLine
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
9 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_BYTES_PER_LINE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: ddd * oldBytesPerLine
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
10 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_SIZE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: ddd * oldItemSize
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
11 - StopWIA |


TD-13.4.7.9 WIA_IPS_YEXTENT Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: Device under test.
PASS/FAIL Criteria: |
Comments: | If the device is a camera test is PASSED. Otherwise continue testing.
For every item (current_item) in the WIA tree repeat steps 3 - 6.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_XEXTENT Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let oldXExtent be the returned property value.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_NUMBER_OF_LINES Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let oldNumberOfLines be the returned property value.
5 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_SIZE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let oldItemSize be the returned property value.
For the minimum and maximum valid value (newYExtent) of this WIA_IPS_YEXTENT property repeat steps 6 - 8.
6 - SetProperty | Sets the property data for the target item.
Parameters: | Property WIA_IPS_YEXTENT Value: newYExtent Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | Let be ddd = newXExtent / oldXExtent.
8 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPS_NUMBER_OF_LINES Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: ddd * oldNumberOfLines
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
9 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property: WIA_IPA_ITEM_SIZE Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK Expected property value: ddd * oldItemSize
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
10 - StopWIA |


TD-13.4.8.1 drvDeviceCommand Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: Device under test.
PASS/FAIL Criteria: |
Comments: |
3 - GetDeviceCaps | Retrieves the device capabilities for the target WIA device.
Parameters: | Target: Device under test. Flag: WIA_DEVICE_COMMANDS
PASS/FAIL Criteria: | Expected result: S_OK Expected value: A set of WIA_DEV_CAP values (named setDevCap) that identifies the supported device commands.
Comments: | From the WIA_DEV_CAPS structures only the guid field will be used.
If (device is a scanner) and (WIA_CMD_SYNCHRONIZE is not setDevCap) the test is FAILED. For every command supp_cmd in the setDevCap set execute step 4.
4 - DeviceCommand | Issues a command to a WIA device.
Parameters: | Target: Device under test Command: supp_cmd
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
For every valid command notsupp_cmd that is not in the setDevCap set execute step 5.
5 - DeviceCommand | Issues a command to a WIA device.
Parameters: | Target: Device under test Command: notsupp_cmd
PASS/FAIL Criteria: | Expected result: E_NOT_IMPL
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
6 - StopWIA |


TD-13.4.8.2 drvDeleteItem Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: Device under test.
PASS/FAIL Criteria: |
Comments: |
For every item (current_item) in the WIA tree repeat step 3.
3 - GetProperty | Retrieves the property data for the target item.
Parameters: | Target: current_item Property: WIA_IPA_ACCESS_RIGHTS
PASS/FAIL Criteria: | Expected result: S_OK Expected value: a combination of flags.
Comments: |
If (the returned property value has the WIA_ITEM_CAN_BE_DELETED flag set) execute steps 4 & 5.
4 - DeleteItem | Deletes a WIA item.
Parameters: | Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: |
5 - GetProperty | Retrieves the property data for the target item.
Parameters: | Target: current_item Property: WIA_IPA_ITEM_FLAGS
PASS/FAIL Criteria: | Expected result: S_OK or WIA_ERROR_ITEM_DELETED. Expected value: the value shall have the WiaItemTypeDeleted flag set.
Comments: | If returned result is WIA_ERROR_ITEM_DELETED continue without verifying the property value.
6 - StopWIA |


TD-13.4.8.3 drvAnalyzeItem Test Description

# - Test Function | Description
1 - StartWIA |
For every item (current_item) in the WIA tree repeat step 2.
2 - AnalyzeItem | Acquire and try to detect what data types are present on page.
Parameters: | Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
3 - StopWIA |


TD-13.4.8.4 drvGetWiaFormatInfo Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetFormatInfo | Determine the formats and media types of incoming data supported.
Parameters: | Target: Device under test.
PASS/FAIL Criteria: | Expected result: S_OK Expected values: A set of (formatID, mediaType) pairs.
Comments: | If the returned set doesn’t include the pairs (TYMED_CALLBACK, IMGFMT_MEMORYBMP) and (TYMED_FILE, IMGFMT_BMP), the test is FAILED. Otherwise the test is PASSED.
3 - StopWIA |


TD-13.4.8.5 drvGetCapabilities Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetDeviceCaps | Retrieves the device capabilities for the target WIA device.
Parameters: | Target: Device under test. Flag: WIA_DEVICE_COMMANDS
PASS/FAIL Criteria: | Expected result: S_OK Expected value: A set of WIA_DEV_CAP values (named setDevCap) that identifies the supported device commands.
Comments: | From the WIA_DEV_CAPS structures only the guid field will be used.
For every command supp_cmd in the setDevCap set execute step 3.
3 - DeviceCommand | Issues a command to a WIA device.
Parameters: | Target: Device under test Command: supp_cmd
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
For every valid command notsupp_cmd that is not in the setDevCap set execute step 4.
4 - DeviceCommand | Issues a command to a WIA device.
Parameters: | Target: Device under test Command: notsupp_cmd
PASS/FAIL Criteria: | Expected result: E_NOT_IMPL
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
5 - GetDeviceCaps | Retrieves the device capabilities for the target WIA device.
Parameters: | Target: Device under test. Flag: WIA_DEVICE_EVENTS
PASS/FAIL Criteria: | Expected result: S_OK Expected value: A set of WIA_DEV_CAP values (named setDevCap) that identifies the supported WIA events.
Comments: | From the WIA_DEV_CAPS structures only the guid field will be used. FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
6 - StopWIA |


TD-13.4.8.6 drvAcquireItemData Test Description

# - Test Function | Description
1 - StartWIA |
2 - GetFormatInfo | Determine the formats and media types of incoming data supported.
Parameters: | Target: Device under test.
PASS/FAIL Criteria: | Expected result: S_OK Expected values: A set of (formatID, mediaType) pairs. Let formatSet be the returned set.
Comments: |
3 - GetDeviceType | Retrieves the DUT type.
Parameters: | Target: Device under test
PASS/FAIL Criteria: |
Comments: |
For every item (current_item) in the WIA tree repeat step 4.
4 - GetProperty | Retrieves the property data for the target item.
Parameters: | Property:WIA_IPA_ITEM_FLAGS Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | If the returned property has the flag WiaItemTypeImage cleared continue with the next tree item, since this is not an image-type item.
If the device is a camera, repeat step 6 for every pair (formatID, mediaType) in formatSet. Otherwise, repeat steps 5 & 6 for every pair (formatID, mediaType) in formatSet.
5 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_FORMAT Value: formatID Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: |
6 - SetProperty | Sets the property data for the target item.
Parameters: | Property: WIA_IPA_TYMED Value: mediaType Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: |
If the mediaType is TYMED_FILE go to step 7. Otherwise go to step 8.
7 - GetImageFile | Transfer an image from the WIA item using a file buffered transfer.
Parameters: | Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
8 - GetImageMemory | Transfer an image from the WIA item using a memory callback.
Parameters: | Target: current_item
PASS/FAIL Criteria: | Expected result: S_OK
Comments: | FAILED if one of the expected values doesn’t match the reported one. Continue testing otherwise.
9 - StopWIA |


TD-13.5 WIA Micro-Driver Test Description

Test Kit: HCT 10

Overview

The Windows Image Acquisition (WIA) Microdriver test (MicroDrvTest.exe) examines the microdriver dynamic link library (DLL) directly, and verifies that all of the functions and commands meet the requirements defined in the Still Image Drivers section of the Windows 2000 Driver Development Kit (DDK).

The micro-driver is a DLL, which implements any needed device-specific behavior. Microsoft provides a common WIA Flatbed Driver, called WiaFBDrv.dll, which sits on top of the micro-driver. The WIA Flatbed Driver receives requests from the WIA service and routes the requests to the microdriver through the microdriver functions. The WIA Flatbed Driver then receives responses to the requests from the microdriver and sends these responses back to the WIA service. This architecture is functionally reduced from the WIA Minidriver architecture. The common WIA Flatbed Driver combined with the microdriver can be used as a WIA mini-driver for the flatbed scanner.

This test examines the micro-driver DLL directly. It checks all the required functions and commands, defined in WIA DDK. The test result is summarized and rated in the test log. The micro-driver should pass the testing without any failure.

TD-13.5.1.1 TestLibrary Test Description

This test case tests IHV-provided DLL library for its micro-driver. The DLL must provide the following functions: MicroEntry(...), Scan(...), and SetPixelWindow(...).

TD-13.5.1.2 TestSetPixelWindow Test Description

This test case tests required function SetPixelWindow(...).This function sets the image area to be scanned.

TD-13.5.1.3 TestScan Test Description

This test case tests required function Scan(...).This function reads data from the device and returns the data to the WIA Flatbed driver.

TD-13.5.2.1 TestCmdInitialize Test Description

This test case tests required command CMD_INITIALIZE in MicroEntry(...). This command is called by the WIA Flatbed Driver to initialize the microdriver and set device IO handles to valid values.

TD-13.5.2.2 TestCmdStiDeviceReset Test Description

This test case tests required command CMD_STI_DEVICERESET in MicroEntry(...). This command is called by the WIA Flatbed Driver to reset the device in response to a Still Image (STI) request.

TD-13.5.2.3 TestCmdStiDiagnostic Test Description

This test case tests required command CMD_STI_DIAGNOSTIC in MicroEntry(...). This command is called by the WIA Flatbed Driver when the user requests to test the device.

TD-13.5.2.4 TestCmdResetScanner Test Description

This test case tests required command CMD_RESETSCANNER in MicroEntry(...). This command is called by the WIA Flatbed Driver to reset the device in response to a WIA service request. The microdriver should set the device to its power-on state.

TD-13.5.2.5 TestCmdSetXResolution Test Description

This test case tests required command CMD_SETXRESOLUTION in MicroEntry(...). This command is called by the WIA Flatbed Driver to set the horizontal scan resolution.

TD-13.5.2.6 TestCmdSetYResolution Test Description

This test case tests required command CMD_SETYRESOLUTION in MicroEntry(...). This command is called by the WIA Flatbed Driver to set the vertical scan resolution.

TD-13.5.2.7 TestCmdSetDataType Test Description

This test case tests required command CMD_SETDATATYPE in MicroEntry(...). This command is called by the WIA Flatbed Driver to set the data type for the scan. Allowed datatypes are WIA_DATA_THRESHOLD, WIA_DATA_GRAYSCALE, WIA_DATA_COLOR.

TD-13.5.2.8 TestCmdSetIntensity Test Description

This test case tests required command CMD_SETINTENSITY in MicroEntry(...). This command is called by the WIA Flatbed Driver to set the intensity or brightness value for the scan. -1000 should be interpreted as the lowest brightness value, 0 nominal, and 1000 the device's maximum brightness.

TD-13.5.2.9 TestCmdSetContrast Test Description

This test case tests required command CMD_SETCONTRAST in MicroEntry(...). This command is called by the WIA Flatbed Driver to set the contrast value for the scan. -1000 should be interpreted as the lowest contrast value, 0 nominal, and 1000 the device's maximum contrast.

TD-13.5.2.10 TestCmdGetCapabilities Test Description

This test case tests required command CMD_GETCAPABILITIES in MicroEntry(...). This command is called by the WIA Flatbed Driver to get button event information.

TD-13.5.2.11 TestCmdUninitialize Test Description

This test case tests required command CMD_UNINITIALIZE in MicroEntry(...). This command is called by the WIA Flatbed Driver to uninitialize the microdriver and close Device IO handles.

TD-13.5.3.1 TestCmdStiGetStatus Test Description

This test case tests required command CMD_STI_GETSTATUS in MicroEntry(...). This command is called by the WIA Flatbed Driver to get the on-line status of the device and if the device has push buttons, to get the button status.

TD-13.5.3.2 TestCmdGetInterruptEvent Test Description

This test case tests required command CMD_STI_GETSTATUS in MicroEntry(...). This command is called by the WIA Flatbed Driver in a separate thread to monitor the status of button events that use interrupts from the device (i.e. for USB devices which report events via the interrupt pipe). If your device only supports polling, this command does not need to be implemented, return E_NOTIMPL

TD-13.5.4.1 TestCmdLoadADF Test Description

This test case tests required command CMD_LOAD_ADF in MicroEntry(...). This command is called by the WIA Flatbed Driver to load a page into the ADF. If this command does not apply to the device, return E_NOTIMPL.

TD-13.5.4.2 TestCmdUnloadADF Test Description

This test case tests required command CMD_UNLOAD_ADF in MicroEntry(...). This command is called by the WIA Flatbed Driver to unload a page from the ADF. If this command does not apply to the device, return E_NOTIMPL.

TD-13.5.4.3 TestCmdGetADFAvailable Test Description

This test case tests required command CMD_GETADFAVAILABLE in MicroEntry(...). This command is called by the WIA Flatbed Driver to check the availability of ADF. If this command does not apply to the device, return E_NOTIMPL.

TD-13.5.4.4 TestCmdGetADFHasPaper Test Description

This test case tests required command CMD_GETADFHASPAPER in MicroEntry(...). This command is called by the WIA Flatbed Driver to get the paper status of the device’s ADF. If this command does not apply to the device, return E_NOTIMPL.

TD-13.5.4.5 TestCmdGetADFStatus Test Description

This test case tests required command CMD_GETADFSTATUS in MicroEntry(...). This command is called by the WIA Flatbed Driver to get the status of the ADF attached to the device. Possible status values are MCRO_ERROR_GENERAL_ERROR, MCRO_ERROR_OFFLINE, MCRO_ERROR_PAPER_EMPTY, MCRO_ERROR_PAPER_JAM, MCRO_ERROR_PAPER_PROBLEM, MCRO_ERROR_USER_INTERVENTION, and MCRO_STATUS_OK. If this command does not apply to the device, return E_NOTIMPL.

Setup

To run this test follow these steps:

  1. Have a Windows version that supports WIA and the flatbed scanner connected to the test machine.
  2. Turn power on.
  3. Run MicroDrvTest.exe.
  4. Choose "Test"-"Start" to launch the test. To select no debug-level test log (default), set the log-level by choosing "Test"-"Log Level".
  5. If more than one scanner is attached, select the device to test.
Required Hardware

Flatbed Scanner

Results Interpretation

The test log is automatically saved in "MicroDrvTst.log". To save the log to any other file choose "File"-"Save" or "Save As...".

To navigate through the test failures press the tool bar button "->" to go to next failure, or "<-" to last failure.


Chapter 14: PC Card Test Specification

This chapter describes PC card test assertions and test tools that validate support for PC Card socket controllers, 16-bit PC Cards, CardBus cards, and PC Card power management.

In the context of this specification, PC Card refers to 16-bit cards (previously referred to as PCMCIA cards), 32-bit CardBus cards, and PC Card Socket Controllers. Only requirements related to PC Cards are covered.

This specification also describes the individual tests that verify the requirements for PC cards in the "PC Card Test Description" section.

Test Coverage

Microsoft Windows Logo Program System and Device Requirements refers to several requirements in Design Guidelines for PC Card and CardBus for PC cards. These requirements can be broadly classified into the following functional categories:

  • PC Socket controllers
  • 16-bit PC Cards
  • CardBus cards
  • PC Card power management

The test assertions detailed in this test specification are based on these PC Card requirements. Supporting information was derived from the February 1995 and March 1997 PC Card Standards, including PC Card Standard Guidelines, PCI to PCMCIA CardBus Bridge Register Description (Yenta specification), and the PCI Bus Power Management Interface Specification, Revision 1.0 and Revision 1.1.

Although this test specification lists test assertions and provides test descriptions to verify the CardBus socket interface functionality and CardBus power management aspects, two specific tests, CardBus Interface Test (TD-14.10) and CardBus Card Wake-Up Test (TD-14.11), will not be implemented as there is no special CardBus test hardware available to validate this functionality.

Test Methodology

The PC card tests described in this document are designed to run on all IA-32 processor based systems.

Two PC card tests described in this test specification require a special CardBus tester card to verify the CardBus interface functionality with CardBus controllers and PC cards power management features. The key requirements for the CardBus tester card are listed below:

  • The CardBus tester card must be designed as an I/O card.
  • The CardBus tester card must be 100% compatible with the functional, AC electrical, and DC electrical requirements of the PC Card Standard.
  • The CardBus tester card must implement a single function with full PCI-like configuration space including all bytes of the device dependent space. The tester card must include a minimum set of configuration registers and configuration tuples so that the Microsoft Windows operating system can properly recognize and configure this card, just like any other CardBus cards.
  • The CardBus tester card function must implement the following event registers: Function Event, Function Event Mask, Function Present State, and Force Event Capability.
  • The CardBus tester card must support memory and I/O window types.
  • The CardBus tester must implement the power management register block in a manner consistent with the following sections of Revision 7.0 of the PC Card Standard:

PC Card Host System Specification, Section 3, (all sub-sections), "PCI Bus Power Management Interface Specifications for PCI-to-CardBus Bridges."

PC Card Host System Specification, Section 4.5.3 (all sub-sections), "Socket Status & Control Registers."

PC Card Host System Specification, Section 4.7.3, "Wakeup."

Guidelines, Section 3, "Physical Guidelines."

Socket Services Specification, Section 4.5, "Windows Supported."

Socket Services Specification, Section 4.7, "Power Management and Indicators."

Card Services Specification, Section 3.5.17, "PM_RESUME."

Card Services Specification, Section 3.5.18, "PM_SUSPEND."

Metaformat Specification, Section 2.3.7, "CardBus PC Card Metaformat."

Metaformat Specification, Section 2.3.9, "CardBus PC Card Tuple Chain Processing."

Metaformat Specification, Section 3.3.1, "CardBus PC Card Base Address Register Tuple."

Metaformat Specification, Section 3.3.3, "CardBus PC Card Configuration Table Entry Tuple."

Metaformat Specification, Section 3.3.5, "CardBus PC Card Configuration Tuple."

Physical Specification (all sub-sections).

Electrical Specification, Section 2, "Common Pin Description."

Electrical Specification, Section 3, "Card Type Detection Mechanism."

Electrical Specification, Section 5 (all sub-sections), "CardBus PC Card Electrical Interface."

Electrical Specification, Section 6 (all sub-sections), "PCI Bus Power Management for CardBus Cards."

  • The CardBus tester card must support D0, D1, D2, D3 Hot, and D3 Cold device power states.
  • The CardBus tester card must be capable of generating a power management event by asserting its CSTSCHG signal from D0, D1, D2, D3 Hot, and D3 Cold states.
  • The CardBus tester card must not consume more than 200mA during its operation.
  • The assertion of CSTSCHG signal from any device power state is required to be handled via software control without user intervention.
  • The CardBus tester card must provide a mechanism to measure the CardBus 3.3V Vcc within a specified tolerance level.


PC Card Test Assertions

The following PC Card assertions are used to verify CardBus socket controller implementation of industry-standard ExCA register set definition for CardBus bridges and check implementation of I/O tuples for 16-bit cards and CardBus cards. In addition, these assertions verify power management aspects for CardBus controllers and PC Cards.


Reference Documents for PC Card Assertions

Default Device Class Power Management Reference Specification, Version 1.0 or later

http://www.microsoft.com/hwdev/specs/PMref/

Design Guidelines for PC Card and CardBus

http://www.microsoft.com/hwdev/platform/pcdesign/desguide/pcguides.asp

(see PC 2001 System Design Guide)

Microsoft Windows Driver Development Kit

http://www.microsoft.com/ddk/
See "Supporting Multifunction PCI Devices" and "System-Supplied Setup Classes" in the Windows DDK

Microsoft Windows Logo Program System and Device Requirements, Version 2.0

http://www.microsoft.com/hwdev/winlogo/
(listed as "WLP#" in these assertions)

PC 2001 System Design Guide and PC 99 System Design Guide

http://www.microsoft.com/hwdev/platform/pcdesign/desguide/pcguides.asp

PC Card Controller Device Class Power Management Reference Specification, V. 2.0

http://www.microsoft.com/HWDev/specs/PMref/PMcard.htm

PCI Bus Power Management Interface Specification, Revision 1.1 (PCI-PM)

http://www.pcisig.com/specifications

PCI Bus Power Management Interface Specification for PCI-to-CardBus Bridges

Provided in Volume 11, PC Card Standard, Release 7, http://www.pcmcia.org/bookstore.htm

PC Card Standard Guidelines

http://www.pcmcia.org/bookstore.htm

PCI to PCMCIA CardBus Bridge Register Description

http://www.pcmcia.org/bookstore.htm

PCI Local Bus Specification, Revision 2.2 (PCI 2.2)

http://www.pcisig.com/specifications


PC Card ExCA Compatibility Assertions

The following PC card socket controller ExCA assertions are tested in TD-14.1 ExCA Compatibility Test (EXCA)

14.1.1 PC card socket controller supports industry-standard ExCA register set.

Reference document: WLP#- B2.1.4.1; Design Guidelines for PC Card and CardBus, 12.3.
Test description: TD-14.1 ExCA Compatibility Test (EXCA)

14.1.2 CardBus bridges must implement ExCA Base Address register (offset 10h).

Reference document: WLP# - B2.5.2; Design Guidelines for PC Card and CardBus, 12.3.
Test description: TD-14.1 ExCA Compatibility Test (EXCA)

14.1.3 Each CardBus controller socket must include a minimum of four memory windows.

Reference documents: WLP#- B2.1.4.1; Exchangeable Card Architecture Specification, Section 3.1 and Design Guidelines for PC Card and CardBus, 12.3.
Test description: TD-14.1 ExCA Compatibility Test (EXCA)

14.1.4 Each CardBus socket memory window must support system address capabilities for both real and protected mode operations.

Reference documents: WLP#- B2.1.4.1; Exchangeable Card Architecture Specification, Section 3.1 and Design Guidelines for PC Card and CardBus, 12.3.
Test description: TD-14.1 ExCA Compatibility Test (EXCA)

14.1.5 Each CardBus socket memory window must be configurable from a 4K byte minimum window size to an 8M byte maximum window size in protected mode.

Reference documents: WLP#- B2.1.4.1; Exchangeable Card Architecture Specification, Section 3.1 and Design Guidelines for PC Card and CardBus, 12.3.
Test description: TD-14.1 ExCA Compatibility Test (EXCA)

14.1.6 Each CardBus socket memory window must be configurable from a 4K-byte minimum window size to a 256K-byte maximum window size in real mode.

Reference documents: WLP#- B2.1.4.1; Exchangeable Card Architecture Specification, Section 3.1 and Design Guidelines for PC Card and CardBus, 12.3.
Test description: TD-14.1 ExCA Compatibility Test (EXCA)

14.1.7 CardBus socket memory windows are Mapbase anywhere between 256K bytes and 16M bytes in available system address space.

Reference documents: WLP#- B2.1.4.1; Exchangeable Card Architecture Specification, Section 3.1 and Design Guidelines for PC Card and CardBus, 12.3.
Test description: TD-14.1 ExCA Compatibility Test (EXCA)

14.1.8 CardBus socket memory size can be any 4K increment or it can be power of 2 size.

Reference documents: WLP#- B2.1.4.1; Exchangeable Card Architecture Specification, Section 3.1 and Design Guidelines for PC Card and CardBus, 12.3.
Test description: TD-14.1 ExCA Compatibility Test (EXCA)

14.1.9 Each CardBus controller socket must include a minimum of two I/O windows.

Reference documents: WLP#- B2.1.4.1; Exchangeable Card Architecture Specification, Section 3.2 and Design Guidelines for PC Card and CardBus, 12.3.
Test description: TD-14.1 ExCA Compatibility Test (EXCA)

14.1.10 Each CardBus socket I/O window must be configurable from a 1-byte minimum window size to a 256 bytes maximum window size.

Reference document: WLP#- B2.1.4.1; Exchangeable Card Architecture Specification, Section 3.2 and Design Guidelines for PC Card and CardBus, 12.3.
Test description: TD-14.1 ExCA Compatibility Test (EXCA)

14.1.11 CardBus socket I/O size must be a power of 2 size.

Reference document: WLP#- B2.1.4.1; Exchangeable Card Architecture Specification, Section 3.2 and Design Guidelines for PC Card and CardBus, 12.3.
Test description: TD-14.1 ExCA Compatibility Test (EXCA)


CardBus Bridge Register Assertions

The following PC card socket controller assertions are tested in the TD-14.2 CardBus Bridge Register Test (CBBRIDGE).

14.2.1 System supports industry-standard definition in PCI to PCPMCIA CardBus Bridge Register Description (Yenta Specification) for CardBus Bridges.

Reference document: WLP#- B2.1.4.1; Design Guidelines for PC Card and CardBus, 12.7.
Test description: TD-14.2 CardBus Bridge Register Test (CBBRIDGE)

14.2.2 CardBus bridges must implement configuration header type 2.

Reference document: WLP#- B2.1.4.1; Design Guidelines for PC Card and CardBus, 12.7.
Test description: TD-14.2 CardBus Bridge Register Test (CBBRIDGE)

14.2.3 If a CardBus bridge implements multiple sockets, each of its sockets must be implemented as a separate function within the bridge.

Reference document: WLP#- B2.1.4.1; Design Guidelines for PC Card and CardBus, 12.7.
Test description: TD-14.2 CardBus Bridge Register Test (CBBRIDGE)

14.2.4 Each function (such as the socket interface) within a CardBus bridge must have its own set of configuration registers, adhering to the CardBus bridge header format.

Reference document: WLP#- B2.1.4.1; Design Guidelines for PC Card and CardBus, 12.7.
Test description: TD-14.2 CardBus Bridge Register Test (CBBRIDGE)

14.2.5 Device identification registers in the configuration space (such as Vendor ID, Device ID, Revision ID, and Class Code) must comply with the functionality defined in the PCI Local Bus Specification 2.1.

Reference documents: WLP#- B2.1.4.1; PC Card Standard February 1999 (Release 7.0), Volume 11, PC Card Host System Specification, Section 4.5.2 and Design Guidelines for PC Card and CardBus, 12.7.
Test description: TD-14.2 CardBus Bridge Register Test (CBBRIDGE)

14.2.6 CardBus bridge Subsystem ID and Subsystem Vendor ID registers (offsets 42h and 40h in the configuration space) comply with the PCI Local Bus Specification 2.1.

Reference document: WLP#- B2.1.4.1; PC Card Standard February 1999 (Release 7.0), Volume 11; PC Card Host System Specification, Section 4.5.2 and Design Guidelines for PC Card and CardBus, 12.7.
Test description: TD-14.2 CardBus Bridge Register Test (CBBRIDGE)

14.2.7 CardBus bridge Subsystem ID and Subsystem Vendor ID registers must be populated with nonzero values.

Reference documents: WLP#- B2.1.4.1; PC Card Standard February 1999 (Release 7.0), Volume 11; PC Card Host System Specification, Section 4.5.2 and Design Guidelines for PC Card and CardBus, 12.7.
Test description: TD-14.2 CardBus Bridge Register Test (CBBRIDGE)

14.2.8 Bus number registers in the configuration space (such as Primary Bus Number, Secondary Bus Number and Sub-ordinate Bus Number) must comply with the functionality defined in the PCI Local Bus Specification 2.1.

Reference documents: WLP#- B2.1.4.1; PC Card Standard February 1999 (Release 7.0), Volume 11; PC Card Host System Specification, Section 4.5.2 and Design Guidelines for PC Card and CardBus, 12.7.
Test description: TD-14.2 CardBus Bridge Register Test (CBBRIDGE)

14.2.9 CardBus bridges must implement command registers (such as Command and Bridge Control) and these registers must comply with the functionality defined in the PCI Local Bus Specification 2.1.

Reference documents: WLP#- B2.1.4.1; PC Card Standard February 1999 (Release 7.0), Volume 11; PC Card Host System Specification, Section 4.5.2 and Design Guidelines for PC Card and CardBus, 12.7.
Test description: TD-14.2 CardBus Bridge Register Test (CBBRIDGE)

14.2.10 CardBus bridges must implement status registers (such as Status and Secondary Status) and these registers must comply with the functionality defined in the PCI Local Bus Specification 2.1.

Reference documents: WLP#- B2.1.4.1; PC Card Standard February 1999 (Release 7.0), Volume 11; PC Card Host System Specification, Section 4.5.2 and Design Guidelines for PC Card and CardBus, 12.7.
Test description: TD-14.2 CardBus Bridge Register Test (CBBRIDGE)

14.2.11 CardBus bridges must implement memory filter registers (such as Memory Base Address and Memory Limit) and these registers must comply with the functionality defined in the PCI Local Bus Specification 2.1.

Reference documents: WLP#- B2.1.4.1; PC Card Standard February 1999 (Release 7.0), Volume 11; PC Card Host System Specification, Section 4.5.2 and Design Guidelines for PC Card and CardBus, 12.7.
Test description: TD-14.2 CardBus Bridge Register Test (CBBRIDGE)

14.2.12 CardBus bridges must implement I/O filter registers (such as I/O Base Address and I/O Limit) and these registers must comply with the functionality defined in the PCI Local Bus Specification 2.1.

Reference documents: WLP#- B2.1.4.1; PC Card Standard February 1999 (Release 7.0), Volume 11; PC Card Host System Specification, Section 4.5.2 and Design Guidelines for PC Card and CardBus, 12.7.
Test description: TD-14.2 CardBus Bridge Register Test (CBBRIDGE)

14.2.13 CardBus bridges must implement latency timer registers (such as Latency Timer and Secondary Latency Timer) and these registers must comply with the functionality defined in the PCI Local Bus Specification 2.1.

Reference documents: WLP#- B2.1.4.1; PC Card Standard February 1999 (Release 7.0), Volume 11; PC Card Host System Specification, Section 4.5.2 and Design Guidelines for PC Card and CardBus, 12.7.
Test description: TD-14.2 CardBus Bridge Register Test (CBBRIDGE)

14.2.14 CardBus bridges must implement interrupt-related registers (such as the Interrupt Pin and Interrupt Line) and these registers must comply with the functionality defined in the PCI Local Bus Specification 2.1.

Reference documents: WLP#- B2.1.4.1; PC Card Standard February 1999 (Release 7.0), Volume 11; PC Card Host System Specification, Section 4.5.2 and Design Guidelines for PC Card and CardBus, 12.7.
Test description: TD-14.2 CardBus Bridge Register Test (CBBRIDGE)

14.2.15 CardBus bridges must implement Cache Line Size register and the register must comply with the functionality defined in the PCI Local Bus Specification 2.1.

Reference documents: WLP#- B2.1.4.1; PC Card Standard February 1999 (Release 7.0), Volume 11; PC Card Host System Specification, Section 4.5.2 and Design Guidelines for PC Card and CardBus, 12.7.
Test description: TD-14.2 CardBus Bridge Register Test (CBBRIDGE)

14.2.16 CardBus bridges must implement Cap_Ptr register (offset 14h).

Reference documents: WLP#- B2.1.4.1; PC Card Standard February 1999 (Release 7.0), Volume 11; PC Card Host System Specification, Section 4.5.2 and Design Guidelines for PC Card and CardBus, 12.7 and 12.19.
Test description: TD-14.2 CardBus Bridge Register Test (CBBRIDGE)

14.2.17 CardBus Bridge Cap_Ptr offset must be DWORD aligned.

Reference documents: WLP#- B2.1.4.1; PC Card Standard February 1999 (Release 7.0), Volume 1, PC Card Host System Specification, Section 4.5.2 and Design Guidelines for PC Card and CardBus, 12.7 and 12.19.
Test description: TD-14.2 CardBus Bridge Register Test (CBBRIDGE)

14.2.18 CardBus bridge Cap_Ptr value must have a minimum value of 80h and a maximum value of F8h.

Reference documents: WLP#- B2.1.4.1; PC Card Standard February 1999 (Release 7.0), Volume 11; PC Card Host System Specification, Section 4.5.2 and Design Guidelines for PC Card and CardBus, 12.7 and 12.19.
Test description: TD-14.2 CardBus Bridge Register Test (CBBRIDGE)

14.2.19 CardBus bridges must implement PC Card Socket Status and Control Registers Base Address Register.

Reference documents: WLP#- B2.1.4.1; PC Card Standard February 1999 (Release 7.0), Volume 11; PC Card Host System Specification, Section 4.5.2 and Design Guidelines for PC Card and CardBus, 12.7.
Test description: TD-14.2 CardBus Bridge Register Test (CBBRIDGE)

14.2.20 CardBus bridges must provide Event, Mask, Present State, Force, and Control registers for each socket it supports.

Reference documents: WLP#- B2.1.4.1; PC Card Standard February 1999 (Release 7.0), Volume 2, Electrical Specification, Section 5.5.4.4 and Design Guidelines for PC Card and CardBus, 12.7.
Test description: TD-14.2 CardBus Bridge Register Test (CBBRIDGE)

14.2.21 All reserved fields in the CardBus bridge configuration space must always return value of 0 when they are read.

Write operations on these fields must have no effect.

Reference documents: WLP#- B2.1.4.1; PC Card Standard February 1999 (Release 7.0), Volume 11 and PC Card Host System Specification.
Test description: TD-14.2 CardBus Bridge Register Test (CBBRIDGE)


CardBus Socket Controller BIOS Assertions

The following PC card socket controller assertions are tested in TD-14.3 CardBus Socket Controller BIOS Test (CBBIOS).

14.3.1 BIOS initializes CardBus controller in 82365-compatible mode and support backward compatibility.

Reference document: WLP#- B2.1.4.1; Design Guidelines for PC Card and CardBus, 12.8.
Test description: TD-14.3 CardBus Socket Controller BIOS Test (CBBIOS)

14.3.2 BIOS must initialize the CardBus controller in Intel® 82365-compatible mode and report it as device "PNP0E03, Intel 82365-Compatible CardBus Controller"

Reference document: WLP#- B2.1.4.1; Design Guidelines for PC Card and CardBus, 12.8.
Test description: TD-14.3 CardBus Socket Controller BIOS Test (CBBIOS)

14.3.3 BIOS must set CardBus controller Command register to 0x07 during POST.

Reference document: WLP#- B2.1.4.1; Design Guidelines for PC Card and CardBus, 12.8.
Test description: TD-14.3 CardBus Socket Controller BIOS Test (CBBIOS)

14.3.4 BIOS must set CardBus controller’s all memory and I/O windows (such as offset 1Ch-38h) to 0 during POST.

Reference document: WLP#- B2.1.4.1; Design Guidelines for PC Card and CardBus, 12.8.
Test description: TD-14.3 CardBus Socket Controller BIOS Test (CBBIOS)

14.3.5 BIOS must set CardBus controller’s PC Card Socket Status and Control Registers Base Address (offset 10h) to 0 during POST.

Note: If support for other environments (e.g., Windows 3.1 and MS-DOS) is needed, some other value can be set.

Reference document: WLP#- B2.1.4.1; Design Guidelines for PC Card and CardBus, 12.8.
Test description: TD-14.3 CardBus Socket Controller BIOS Test (CBBIOS)

14.3.6 BIOS must set CardBus controller’s Interrupt Line register (offset 3Ch) to 0xFF during POST.

Note: If support for other environments (e.g., Windows 3.1 and MS-DOS) is needed, some other value can be set.

Reference document: WLP#- B2.1.4.1; Design Guidelines for PC Card and CardBus, 12.8.
Test description: TD-14.3 CardBus Socket Controller BIOS Test (CBBIOS)

14.3.7 BIOS must be at least PCI 2.1 compliant and must support the $PIR Interrupt Routing Table.

Reference document: WLP#- B2.1.4.1; Design Guidelines for PC Card and CardBus, 12.8.
Test description: TD-14.3 CardBus Socket Controller BIOS Test (CBBIOS)


16-Bit PC Card Tuple Assertions

The following 16-bit PC card tuple assertions are tested in the TD-14.4 16-Bit PC Card Tuple Test (16BTUPLE).

14.4.1 16-Bit PC cards support required I/O card tuples.

Reference document: WLP#- B2.1.4.3; Design Guidelines for PC Card and CardBus, 12.11.
Test description: TD-14.4 16-Bit PC Card Tuple Test (16BTUPLE)

14.4.2 No 16-bit card tuple can be longer than 257 bytes.

Reference document: WLP#- B2.1.4.3; PC Card Standard February 1999 (Release 7.0), Volume 4, Metaformat Specification, Section 2.3.1.
Test description: TD-14.4 16-Bit PC Card Tuple Test (16BTUPLE)

14.4.3 16-Bit PC cards must implement CISTPL_DEVICE (tuple code 01H).

Reference documents: WLP#- B2.1.4.3; PC Card Standard February 1999 (Release 7.0), Volume 4, Metaformat Specification, Section 3.2.2 and Design Guidelines for PC Card and CardBus, 12.11.
Test description: TD-14.4 16-Bit PC Card Tuple Test (16BTUPLE)

14.4.4 Device information tuple, CISTPL_DEVICE (tuple code 01H), must be present for 16-bit PC cards, but the device type must be null.

Reference document: WLP#- B2.1.4.3; Design Guidelines for PC Card and CardBus, 12.11.
Test description: TD-14.4 16-Bit PC Card Tuple Test (16BTUPLE)

14.4.5 16-Bit PC cards must implement CISTPL_VERS_1 (tuple code 15H).

Reference documents: WLP#- B2.1.4.3; PC Card Standard February 1999 (Release 7.0), Volume 4, Metaformat Specification, Section 3.2.10 and Design Guidelines for PC Card and CardBus, 12.11.
Test description: TD-14.4 16-Bit PC Card Tuple Test (16BTUPLE)

14.4.6 16-Bit PC cards must implement CISTPL_CONF (tuple code 1AH).

Reference documents: WLP#- B2.1.4.3; PC Card Standard February 1999 (Release 7.0), Volume 4, Metaformat Specification, Section 3.3.4 and Design Guidelines for PC Card and CardBus, 12.11.
Test description: TD-14.4 16-Bit PC Card Tuple Test (16BTUPLE)

14.4.7 16-Bit PC cards must implement CISTPL_CFTABLE_ENTRY (tuple code 1BH).

Reference documents: WLP#- B2.1.4.3; PC Card Standard February 1999 (Release 7.0), Volume 4, Metaformat Specification, Section 3.3.2 and Design Guidelines for PC Card and CardBus, 12.11.
Test description: TD-14.4 16-Bit PC Card Tuple Test (16BTUPLE)

14.4.8 16-Bit PC cards must implement CISTPL_MANFID (tuple code 20H).

Reference documents: WLP#- B2.1.4.3; PC Card Standard February 1999 (Release 7.0), Volume 4, Metaformat Specification, Section 3.2.9 and Design Guidelines for PC Card and CardBus, 12.11.
Test description: TD-14.4 16-Bit PC Card Tuple Test (16BTUPLE)

14.4.9 16-Bit PC cards must implement CISTPL_FUNCID (tuple code 21H).

Reference documents: WLP#- B2.1.4.3; PC Card Standard February 1999 (Release 7.0), Volume 4, Metaformat Specification, Section 3.2.7 and Design Guidelines for PC Card and CardBus, 12.11.
Test description: TD-14.4 16-Bit PC Card Tuple Test (16BTUPLE)

14.4.10 Configuration table entry tuples listed in priority order.

Reference document: WLP#- B2.1.4.3; Design Guidelines for PC Card and CardBus, 12.12.
Test description: TD-14.4 16-Bit PC Card Tuple Test (16BTUPLE)

14.4.11 16-Bit cards specify maximum configuration options.

Reference document: WLP#- B2.1.4.3; Design Guidelines for PC Card and CardBus, 12.13.
Test description: TD-14.4 16-Bit PC Card Tuple Test (16BTUPLE)


CardBus Card Tuple Assertions

The following CardBus card tuple assertions are tested in the TD-14.5 CardBus Card Tuple Test (CBTUPLE).

14.5.1 No CardBus card tuple can be longer than 256 bytes.

Reference documents: WLP#- B2.1.4.2; PC Card Standard February 1999 (Release 7.0), Volume 4, Metaformat Specification, Section 2.3.1.
Test description: TD-14.5 CardBus Card Tuple Test (CBTUPLE)

14.5.2 CardBus card tuple chain must be located in configuration space, memory space, or expansion ROM space of the card.

Reference documents: WLP#- B2.1.4.2; PC Card Standard February 1999 (Release 7.0), Volume 4, Metaformat Specification, Section 2.3.7.
Test description: TD-14.5 CardBus Card Tuple Test (CBTUPLE)

14.5.3 All CardBus card tuple chains must start with a CISTPL_LINKTARGET (tuple code 13H) tuple aligned on a four-word boundary.

Reference documents: WLP#- B2.1.4.2; PC Card Standard February 1999 (Release 7.0), Volume 4, Metaformat Specification, Section 2.3.7.
Test description: TD-14.5 CardBus Card Tuple Test (CBTUPLE)

14.5.4 CardBus card tuple chain in device-dependent configuration space must start after 40h offset and must be contiguous until a CISTPL_END is reached.

Reference documents: WLP#- B2.1.4.2; PC Card Standard March 1997, Volume 2, Electrical Specification, Section 5.4.2.1.11.
Test description: TD-14.5 CardBus Card Tuple Test (CBTUPLE)

14.5.5 CardBus card implement required tuples.

Reference documents: WLP#- B2.1.4.2; Design Guidelines for PC Card and CardBus, 12.16.
Test description: TD-14.5 CardBus Card Tuple Test (CBTUPLE)

14.5.6 CardBus cards must implement CISTPL_CONFIG_CB (tuple code 04H).

Reference documents: WLP#- B2.1.4.2; PC Card Standard February 1999 (Release 7.0), Volume 4, Metaformat Specification, Section 3.3.5.
Test description: TD-14.5 CardBus Card Tuple Test (CBTUPLE)

14.5.7 CardBus cards must implement CISTPL_CFTABLE_ENTRY_CB (tuple code 05H).

Reference documents: WLP#- B2.1.4.2; PC Card Standard February 1999 (Release 7.0), Volume 4, Metaformat Specification, Section 3.3.3.
Test description: TD-14.5 CardBus Card Tuple Test (CBTUPLE)

14.5.8 CardBus cards must implement CISTPL_LINKTARGET (tuple code 13H).

Reference documents: WLP#- B2.1.4.2; PC Card Standard February 1999 (Release 7.0), Volume 4, Metaformat Specification, Section 3.1.4.
Test description: TD-14.5 CardBus Card Tuple Test (CBTUPLE)

14.5.9 CardBus cards must implement CISTPL_VERS_1 (tuple code 15H).

Reference documents: WLP#- B2.1.4.2; PC Card Standard February 1999 (Release 7.0), Volume 4, Metaformat Specification, Section 3.2.10.
Test description: TD-14.5 CardBus Card Tuple Test (CBTUPLE)

14.5.10 CardBus cards must implement CISTPL_MANFID (tuple code 20H).

Reference documents: WLP#- B2.1.4.2; PC Card Standard February 1999 (Release 7.0), Volume 4, Metaformat Specification, Section 3.2.9.
Test description: TD-14.5 CardBus Card Tuple Test (CBTUPLE)

14.5.11 CardBus cards must implement CISTPL_END (tuple code FFH).

Reference documents: WLP#- B2.1.4.2; PC Card Standard February 1999 (Release 7.0), Volume 4, Metaformat Specification, Section 3.1.2.
Test description: TD-14.5 CardBus Card Tuple Test (CBTUPLE)

14.5.12 CardBus cards must implement CISTPL_FUNCID (tuple code 21H).

Reference documents: WLP#- B2.1.4.2; PC Card Standard February 1999 (Release 7.0), Volume 4, Metaformat Specification, Section 3.2.7.
Test description: TD-14.5 CardBus Card Tuple Test (CBTUPLE)


CardBus Card Configuration Space Register Assertions

The following CardBus card configuration space register assertions are tested in TD-14.6 CardBus Card Configuration Space Register Test (CBCREG).

14.6.1 All devices comply with the PC Card Standards.

Reference document: WLP#- B2.1.4.2; Design Guidelines for PC Card and CardBus, 12.1.
Test description: TD-14.6 CardBus Card Configuration Space Register Test (CBCREG)

14.6.2 CardBus cards must have a separate configuration space for each implemented function.

Reference documents: WLP#- B2.1.4.2; PC Card Standard March 1997, Volume 2, Electrical Specification, Section 5.4.2.
Test description: TD-14.6 CardBus Card Configuration Space Register Test (CBCREG)

14.6.3 All unimplemented registers in CardBus card configuration space must return all 0’s when read.

Reference documents: WLP#- B2.1.4.2; PC Card Standard March 1997, Volume 2, Electrical Specification, Section 5.4.2.1.
Test description: TD-14.6 CardBus Card Configuration Space Register Test (CBCREG)

14.6.4 CIS register in CardBus card configuration space is a read-only register.

Reference documents: WLP#- B2.1.4.2; PC Card Standard March 1997, Volume 2, Electrical Specification, Section 5.4.2.1.8.
Test description: TD-14.6 CardBus Card Configuration Space Register Test (CBCREG)

14.6.5 Each configuration space of a multi-function CardBus card must have its own CIS, pointed to by the CIS pointer in its configuration space.

Reference documents: WLP#- B2.1.4.2; PC Card Standard March 1997, Volume 2, Electrical Specification, Section 5.4.2.1.8.
Test description: TD-14.6 CardBus Card Configuration Space Register Test (CBCREG)

14.6.6 If a CardBus card’s CIS begins in device-dependent configuration space, the Address Space Offset field value in the CIS register must be in the range 40h to F8h, both inclusive.

Reference documents: WLP#- B2.1.4.2; PC Card Standard March 1997, Volume 2, Electrical Specification, Section 5.4.2.1.8.
Test description: TD-14.6 CardBus Card Configuration Space Register Test (CBCREG)

14.6.7 If a CardBus card's CIS begins in the memory address space governed by one of the six Base Address Registers, the Address Space Offset field value in the CIS register plus the base address value in the Base Address Register must be in the range 0 to FFFFFFF8h, both inclusive.

Reference documents: WLP#- B2.1.4.2; PC Card Standard March 1997, Volume 2, Electrical Specification, Section 5.4.2.1.8.
Test description: TD-14.6 CardBus Card Configuration Space Register Test (CBCREG)

14.6.8 If a CardBus card’s CIS begins in the expansion ROM space governed by the Expansion ROM Base Register, the Address Space Offset field (bits 3-23) value in the CIS register must be in the range 0 to 0FFFFFF8h, both inclusive.

Reference documents: WLP#- B2.1.4.2; PC Card Standard March 1997, Volume 2, Electrical Specification, Section 5.4.2.1.8.
Test description: TD-14.6 CardBus Card Configuration Space Register Test (CBCREG)

14.6.9 If a CardBus card’s CIS begins in the expansion ROM space governed by the Expansion ROM Base Register, the Address Space Offset field (bits 24-27) value in the CIS register must be in the range 0 to Fh, both inclusive.

Reference documents: WLP#- B2.1.4.2; PC Card Standard March 1997, Volume 2, Electrical Specification, Section 5.4.2.1.8.
Test description: TD-14.6 CardBus Card Configuration Space Register Test (CBCREG)


CardBus Card Common Silicon Guidelines Assertions

The following CardBus Card Common Silicon Guidelines assertions are tested in TD-14.7 CardBus Card Common Silicon Guidelines Test (CBCOMSIG).

14.7.1 CardBus card configuration space meets Common Silicon Guidelines.

Reference document: WLP#- B2.1.4.2; Design Guidelines for PC Card and CardBus, 12.14.
Test description: TD-14.7 CardBus Card Common Silicon Guidelines Test (CBCOMSIG)

14.7.2 CardBus card common silicon must implement read-only Vendor ID field in the 16-double word PCI-like configuration header space.

Reference documents: WLP#- B2.1.4.2; PC Card Standard February 1999 (Release 7.0), Volume 10, Guidelines, Section 2.1.3.4 and Design Guidelines for PC Card and CardBus, 12.14.
Test description: TD-14.7 CardBus Card Common Silicon Guidelines Test (CBCOMSIG)

14.7.3 CardBus card common silicon must implement read-only Device ID field in the 16-double word PCI-like configuration header space.

Reference documents: WLP#- B2.1.4.2; PC Card Standard February 1999 (Release 7.0), Volume 10, Guidelines, Section 2.1.3.4 and Design Guidelines for PC Card and CardBus, 12.14.
Test description: TD-14.7 CardBus Card Common Silicon Guidelines Test (CBCOMSIG)

14.7.4 CardBus card common silicon must implement read-only Revision ID field in the 16-double word PCI-like configuration header space.

Reference documents: WLP#- B2.1.4.2; PC Card Standard February 1999 (Release 7.0), Volume 10, Guidelines, Section 2.1.3.4 and Design Guidelines for PC Card and CardBus, 12.14.
Test description: TD-14.7 CardBus Card Common Silicon Guidelines Test (CBCOMSIG)

14.7.5 CardBus card common silicon must implement read-only Class Code field in the 16-double word PCI-like configuration header space.

Reference documents: WLP#- B2.1.4.2; PC Card Standard February 1999 (Release 7.0), Volume 10, Guidelines, Section 2.1.3.4 and Design Guidelines for PC Card and CardBus, 12.14.
Test description: TD-14.7 CardBus Card Common Silicon Guidelines Test (CBCOMSIG)

14.7.6 CardBus card common silicon must implement PCI’s read-only Max_Lat field in the 16-double word PCI-like configuration header space.

Reference documents: WLP#- B2.1.4.2; PC Card Standard February 1999 (Release 7.0), Volume 10, Guidelines, Section 2.1.3.4 and Design Guidelines for PC Card and CardBus, 12.14.
Test description: TD-14.7 CardBus Card Common Silicon Guidelines Test (CBCOMSIG)

14.7.7 CardBus card common silicon must implement PCI’s read-only Min_Gnt field in the 16-double word PCI-like configuration header space.

Reference documents: WLP#- B2.1.4.2; PC Card Standard February 1999 (Release 7.0), Volume 10, Guidelines, Section 2.1.3.4 and Design Guidelines for PC Card and CardBus, 12.14.
Test description: TD-14.7 CardBus Card Common Silicon Guidelines Test (CBCOMSIG)

14.7.8 CardBus card common silicon must implement PCI’s read-write Interrupt Line register in the 16-double word PCI-like configuration header space.

Reference documents: WLP#- B2.1.4.2; PC Card Standard February 1999 (Release 7.0), Volume 10, Guidelines, Section 2.1.3.4 and Design Guidelines for PC Card and CardBus, 12.14.
Test description: TD-14.7 CardBus Card Common Silicon Guidelines Test (CBCOMSIG)


CardBus Card Subsystem ID and Subsystem Vendor ID Assertions

The following CardBus Subsystem ID and Subsystem Vendor ID assertions are tested in TD-14.8 CardBus Subsystem ID and Subsystem Vendor ID Test (CBSID).

14.8.1 CardBus card reserved fields (offset 2Ch in the configuration space) comply with PCI 2.1.

Reference document: WLP#- B2.1.4.2; Design Guidelines for PC Card and CardBus, 12.15.
Test description: TD-14.8 CardBus Subsystem ID and Subsystem Vendor ID Test (CBSID)

14.8.2 CardBus cards Subsystem ID and Subsystem Vendor ID must be populated with nonzero values.

Reference document: WLP#- B2.1.4.2; Design Guidelines for PC Card and CardBus, 12.15.
Test description: TD-14.8 CardBus Subsystem ID and Subsystem Vendor ID Test (CBSID)


CardBus Bridge Power Management Register Assertions

The following CardBus Bridge Power Management Register assertions are tested in the CardBus Bridge Power Management Register Test (CBPMREG). These assertions cover the Status and CapPtr registers located in the CardBus Bridge/Card configuration header and PMC, PMCSR, BSE, and Data register located in the Power Management Register Interface blocks. These assertions are tested in TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG) .

14.9.1 CardBus controllers and cards implement PCI power management specification.

Reference document: WLP# - B.1.4.5, B2.1.2.1; Design Guidelines for PC Card and CardBus, 12.19.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.2 The Capabilities bit (bit 4) in the PCI Status Register determines whether or not the function implements new capabilities.

When this bit is set to a value other than 0b, it indicates that the function implements capabilities. If the value is set at 0b, the function does not implement new capabilities.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.1.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.3 The Capabilities bit is read-only and its reset value is 1b.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.1.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.4 The Cap_Ptr register is located in PCI configuration space at offset 34h for header-type 0 devices.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.1.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.5 The Cap_Ptr register is located in PCI configuration space at offset 14h for header-type 2 devices (PCI-to-CardBus bridges).

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.1.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.6 The values of 00h-3Fh are not valid for the Cap_Ptr register for CardBus cards For PCI-to-CardBus bridges, the values of 00h-7Fh are not valid for the Cap_Ptr register.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.1.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.7 The Cap_Ptr register offset is double word aligned so that the two least-significant bits are always assigned 0 values.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.1.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.8 The power management registers can be accessed as bytes, 16-bit words, or 32-bit double words.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.1.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.9 The Capability ID register is read-only.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.1.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.10 The NextItemPtr field (bits 8-15) must point to the next item in the capabilities list.

This address must be double word-aligned. If this capability entry is the last, it must have a value of 00h.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.1.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.11 The NextItemPtr field (bits 8-15) is read-only.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.1.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.12 Each function of a PCI device has only one item in its capability list with Cap_ID register value set to a value of 01b.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.1.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.13 The PMC Register is a 16-bit read-only register.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.3.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.14 For CardBus cards, the Version field (bits 0-2) must have a value of 010b to indicate that this function complies with Revision 1.1 of the PCI Power Management Interface Specification for CardBus cards.

For PCI-to-CardBus bridges, the Version field (bits 0-2) can have a value of 001b as specified in Revision 1.0 of the PCI Power Management Interface Specification or 010b to indicate that the function complies with Revision 1.1 of the PCI PM Interface Specification.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.3.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.15 The PME_Clock (bit 3) must have a value of 0b for functions that do not support PME# generation in any state.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.3.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.16 The reset value for the PME_Clock bit is 0b.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management 1.1 Specification, Section 3.2.3.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.17 If the function relies on the presence of the PCI clock for the PME# operation, the PME_Clock bit must be set to a value of 1b; otherwise, it must be set to a value of 0b.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management 1.1 Specification, Section 3.2.3.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.18 The DSI bit (bit 5) indicates whether special initialization of this function is required.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management 1.1 Specification, Section 3.2.3.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.19 The D1_Support bit (bit 9) must be set to a value of 1b for any function that supports the D1 power management state.

If the function does not support D1, it must always return a value of 0b for this bit.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management 1.1 Specification, Section 3.2.3.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.20 The D1_Support bit is read-only.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management 1.1 Specification, Section 3.2.3.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.21 The D2_Support bit (bit 10) must be set to a value of 1b for any function that supports the D2 power management state.

If the function does not support D2, it must always return a value of 0b for this bit.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management 1.1 Specification, Section 3.2.3.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.22 The D2_Support bit is read-only.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management 1.1 Specification, Section 3.2.3.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.23 The PME_Support bits 15 indicates the power states in which the function may assert the PME# signal.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management 1.1 Specification, Section 3.2.3.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.24 The PME_Support bits 11-14 are read-only.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PC Card Standard March 1997, Volume 11, PC Card Host System.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.25 All reserved bits in the PMC Register (bit 6-8) must always return a value of 0b when they are read.

Write operations on these bits have no effect. This is applicable only for CardBus bridges which comply with PCI PM spec Rev 1.0.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management 1.1 Specification, Section 3.2.3.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.26 For CardBus bridges auxiliary Power Source (bit 4) must have a value of 1b to indicate that support for PME# in D3COLD requires auxiliary power supplied by the system by way of a proprietary delivery vehicle.

If the function supplies its own auxiliary power, this bit must have a value of 0b. This bit is read-only. This is applicable for CardBus bridges which comply with version 1.0 of PCI PM Spec. For CardBus cards that comply with PCI PM Spec Rev 1.1 the bit 4 is reserved and should read 0. This bit is read-only.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PC Card Standard March 1997, Volume 11, PC Card Host System.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.27 The PowerState field (bits 0-1) in the PMCSR Register is used both to determine the current power state of a PCI function and to set the function into a new power state.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management 1.1 Specification, Section 3.2.4.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.28 The PowerState field is read/write.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management 1.1 Specification, Section 3.2.4.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.29 The reset value for the PowerState field is 00b.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management 1.1 Specification, Section 3.2.4.
Test description: 14.10 CardBus/Card Power Management Register Test (CBPMREG)

14.9.30 If system software attempts to write an unsupported optional state to the PowerState field, the write operation must complete normally on the bus.

The data is then discarded and no state change occurs.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management 1.1 Specification, Section 3.2.4.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.31 The PME_En bit (bit 8) is read/write.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management 1.1 Specification, Section 3.2.4.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.32 If the function does not support PME# generation from the D3 Cold state, the PME_En bit must default to a value of 0b.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management 1.1 Specification, Section 3.2.4.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.33 The PCI functions that do not support PME# generation from any Dx state may treat the PME_En bit as read-only.

When system software reads the bit, the bit must always return a value of 0b.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management 1.1 Specification, Section 3.2.4.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.34 If the PCI function supports the PME# signal generation from the D3 Cold state, the PME_En bit is sticky, and the operating system must explicitly clear it upon each initial loading.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.35 The PME_Status (bit 15) supports read/write/clear.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.36 Writing a value of 1b to the PME_Status bit clears it and causes the function to stop asserting a PME#, if enabled.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.37 Writing a value of 0b to the PME_Status bit has no effect.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.38 If the PCI function does not support PME# generation from the D3 Cold state, the PME_Status bit defaults to a value of 0b.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.39 The Data_Select field (bits 9-12) is required for any function that implements the Data Register.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.40 The Data_Select field is read/write.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.41 The reset value of the Data_Select field is 0000b.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.42 The Data_Scale field (bits 13-14) is required for any function that implements the Data Register.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.43 The Data_Scale field is read-only.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.44 All reserved fields in the PMCSR Register (bits 2-7) must always return a value of 0 when they are read.

Write operations on these fields have no effect.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.4.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.45 The Data Register is an optional, 8-bit read-only register.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.6.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.46 If the Data Register is implemented, the Data_Select and Data_Scale fields must also be implemented.

If the Data Register is not implemented, it must always return a value of 0b. The Data_Select and Data_Scale fields must also return a value of 0b.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management Interface Specification, Revision 1.1, Section 3.2.6.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.47 The default value of the Data Register is 00h.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management 1.1 Specification, Section 3.2.6.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.48 If the Data Register is implemented, writing an appropriate value to the Data_Select field in the PMCSR Register and reading both the Data_Scale field and Data Register causes the binary value read from the Data Register to be multiplied by the Data_Scale field’s scaling factor to calculate the value for the desired measurement.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management 1.1 Specification, Section 3.2.6.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.49 Only values ranging from 0 through 8 are valid for the Data_Select field.

Values ranging from 9 through 15 are reserved.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management 1.1 Specification, Section 3.2.6.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.50 Multifunction devices that implement power reporting must report the power that each function consumes in each corresponding function’s configuration space.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management 1.1 Specification, Section 3.2.6.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.51 If the Data_Select field of the function 0’s PMCSR Register has been programmed to a value of 1000b, the Data Register must be used to report the common logic power consumption via function 0’s configuration space in a multifunction device.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management 1.1 Specification, Section 3.2.6.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.52 The B2_B3# bit (bit 6) determines the action to result from programming the function to the D3 Hot state.

A value of 1b indicates that when the bridge function is programmed to this state, its secondary bus PCI clock is stopped (B2). A value of 0b indicates that its secondary bus has its power removed (B3).

Note: This assertion is not applicable for CardBus cards.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management 1.1 Specification, Section 3.2.5.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.53 The B2_B3# bit is read-only.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management 1.1 Specification, Section 3.2.5.

Note: This assertion is not applicable for CardBus cards.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.54 If the BPCC_En bit (bit 7) is set to a value of 1b, only the B2_B3# bit becomes significant.

Note: This assertion is not applicable for CardBus cards.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management 1.1 Specification, Section 3.2.5.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.55 The BPCC_En bit (bit 7) indicates the presence of the bus power and clock control mechanism.

A value of 1b indicates that the bus power/clock control mechanism is enabled. A value of 0b indicates that the bus power and clock control policies have been disabled. Note: This assertion is not applicable for CardBus cards.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management 1.1 Specification, Section 3.2.5.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.56 When the bus power and clock control mechanism is disabled, the system software cannot use the bridge’s PMCSR Register PowerState field to control the power or clock of the bridge’s secondary bus.

Note: This assertion is not applicable for CardBus cards.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management 1.1 Specification, Section 3.2.5.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

14.9.57 All reserved fields in the PMCSR_BSE Register (bits 0-5) must always return a value of 0b when they are read.

Write operations on these fields have no effect. Note: This assertion is not applicable for CardBus cards.

Reference document: WLP# - B.1.4.5, B2.1.2.1; PCI Bus Power Management 1.1 Specification, Section 3.2.5.
Test description: TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)


CardBus Card Wake-Up Assertions

The following CardBus card wake-up assertions are tested in TD-14.11 CardBus Card Wake-Up Test (CBWAKE).

Some CardBus Card Wake-Up assertions will not be able to be fully tested under Windows 2000 RTM due to limitations in the implementation of polling mode in the PCMCIA driver and unimplemented code in the ACPI driver for Wake-up via PCMCIA. These assertions must be evaluated on an individual basis and reviewed further by the respective component developers.

14.10.1 CardBus cards must use the CSTSCHG pin to signal wake-up events.

Reference document: WLP# - B.1.4.5, B2.1.4.6; Design Guidelines for PC Card and CardBus, 12.19.
Test description: TD-14.11 CardBus Card Wake-Up Test (CBWAKE)

14.10.2 Setting the PME_En bit in the CardBus card’s configuration space must provide the same behavior as setting both the GWAK and WKUP bits in the card’s Function Event Mask register.

Reference document: WLP# - B.1.4.5, B2.1.4.6; Design Guidelines for PC Card and CardBus, 12.19.
Test description: TD-14.11 CardBus Card Wake-Up Test (CBWAKE)

14.10.3 CardBus device’s PME_En bit must be enabled by system software before asserting PME# signal.

Reference documents: WLP# - B.1.4.5, B2.1.4.6; PC Card Standard February 1999 (Release 7.0), Volume 2, Electrical Specification, Section 6.7 and Design Guidelines for PC Card and CardBus, 12.19.
Test description: TD-14.11 CardBus Card Wake-Up Test (CBWAKE)

14.10.4 Once PME# signal is asserted, the CardBus device must continue to drive the signal low until system software explicitly clears PME_Status and PME_En bit in the PMCSR register of the function.

Reference documents: WLP# - B.1.4.5, B2.1.4.6; PC Card Standard February 1999 (Release 7.0), Volume 2, Electrical Specification, Section 6.7 and Design Guidelines for PC Card and CardBus, 12.19.
Test description: TD-14.11 CardBus Card Wake-Up Test (CBWAKE)

14.10.5 Auxiliary power supplied for the controller must be at least 200mA provided via the Vcc pins.

Reference documents: WLP# - B.1.4.5, B2.1.4.6; PC Card Standard February 1999 (Release 7.0), Volume 2, Electrical Specification, Section 6.7.1 and Design Guidelines for PC Card and CardBus, 12.19.
Test description: TD-14.11 CardBus Card Wake-Up Test (CBWAKE)

14.10.6 CardBus card must not consume more than 200mA when the CardBus card is programmed to the D3 state.

Reference documents: WLP# - B.1.4.5, B2.1.4.6; PC Card Standard February 1999 (Release 7.0), Volume 2, Electrical Specification, Section 6.7.1 and Design Guidelines for PC Card and CardBus, 12.19.
Test description: TD-14.11 CardBus Card Wake-Up Test (CBWAKE)

14.10.7 CardBus card must not consume more than 200mA when the CardBus PME_Support bit 15 (D3Cold) is set.

Reference documents: WLP# - B.1.4.5, B2.1.4.6; PC Card Standard February 1999 (Release 7.0), Volume 2, Electrical Specification, Section 6.7.1 and Design Guidelines for PC Card and CardBus, 12.19.
Test description: TD-14.11 CardBus Card Wake-Up Test (CBWAKE)

14.10.8 PME# signal assertion must generate some form of System Control Interrupt (SCI).

Reference documents: WLP# - B.1.4.5, B2.1.4.6; PC Card Standard February 1999 (Release 7.0), Volume 2, Electrical Specification, Section 6.8.4.1 and Design Guidelines for PC Card and CardBus, 12.19.
Test description: TD-14.11 CardBus Card Wake-Up Test (CBWAKE)

14.10.9 Setting PME_En bit must set the GWAKE (bit 4) and WKUP (bit 14) fields in the CardBus Function Event register.

Reference documents: WLP# - B.1.4.5, B2.1.4.6; PC Card Standard February 1999 (Release 7.0), Volume 2, Electrical Specification, Section 6.6.2 and Design Guidelines for PC Card and CardBus, 12.19.
Test description: TD-14.11 CardBus Card Wake-Up Test (CBWAKE)

14.10.10 Clearing PME_En bit must clear the GWAKE (bit 4) and WKUP (bit 14) fields in the CardBus Function Event register.

Reference documents: WLP# - B.1.4.5, B2.1.4.6; PC Card Standard February 1999 (Release 7.0), Volume 2, Electrical Specification, Section 6.6.2 and PC 99 System Design Guide, Section 12.19.
Test description: TD-14.11 CardBus Card Wake-Up Test (CBWAKE)

14.10.11 Clearing the GWAKE and/or WKUP mask bits must not clear the PME_En bit in the PMCSR register.

Reference documents: WLP# - B.1.4.5, B2.1.4.6; PC Card Standard February 1999 (Release 7.0), Volume 2, Electrical Specification, Section 6.6.2 and Design Guidelines for PC Card and CardBus, 12.19.
Test description: TD-14.11 CardBus Card Wake-Up Test (CBWAKE)

14.10.12 When PME_En bit is set to 1, CSTSCHG event must be latched into the PME_Status.

Reference documents: WLP# - B.1.4.5, B2.1.4.6; PC Card Standard February 1999 (Release 7.0), Volume 2, Electrical Specification, Section 6.6.2 and Design Guidelines for PC Card and CardBus, 12.19.
Test description: TD-14.11 CardBus Card Wake-Up Test (CBWAKE)

14.10.13 If CSTSCHG is asserted, setting PME_En bit to 0 must prevent the CSTSCHG pin from being asserted and clear the GWAKE and WKUP bits in the Function Event Mask register.

Reference documents: WLP# - B.1.4.5, B2.1.4.6; PC Card Standard February 1999 (Release 7.0), Volume 2, Electrical Specification, Section 6.6.2 and Design Guidelines for PC Card and CardBus, 12.19.
Test description: TD-14.11 CardBus Card Wake-Up Test (CBWAKE)

14.10.14 Writing 1 to the PME_Status must clear the GWAKE bit.

Reference documents: WLP# - B.1.4.5, B2.1.4.6; PC Card Standard February 1999 (Release 7.0), Volume 2, Electrical Specification, Section 6.6.2 and Design Guidelines for PC Card and CardBus, 12.19.
Test description: TD-14.11 CardBus Card Wake-Up Test (CBWAKE)

14.10.15 Clearing the GWAKE bit in the Function Event register must clear the PME_Status bit in the PMCSR register.

Reference documents: WLP# - B.1.4.5, B2.1.4.6; PC Card Standard February 1999 (Release 7.0), Volume 2, Electrical Specification, Section 6.6.2 and Design Guidelines for PC Card and CardBus, 12.19.
Test description: TD-14.11 CardBus Card Wake-Up Test (CBWAKE)

14.10.16 If PME_En bit is set to 0, changes in the CardBus card Function Event registers must have no affect on PME_En and PME_Status bits.

Reference documents: WLP# - B.1.4.5, B2.1.4.6; PC Card Standard February 1999 (Release 7.0), Volume 2, Electrical Specification, Section 6.6.2 and Design Guidelines for PC Card and CardBus, 12.19.
Test description: TD-14.11 CardBus Card Wake-Up Test (CBWAKE)


CardBus Interface Assertions

The following CardBus interface assertions are tested in the TD-14.10 CardBus Interface Test (CBIF).

14.11.1 CardBus PC Card adapters must provide support for 16-bit PC cards.

Reference document: WLP# - B2.1.4.1; PC Card Standard March 1997, Volume 2, Electrical Specification, Section 5.5.4.1.
Test description: TD-14.10 CardBus Interface Test (CBIF)

14.11.2 CardBus PC Card adapter must generate the Status Changed interrupt when a PC card is inserted into its socket.

Reference document: WLP# - B2.1.4.1; PC Card Standard March 1997, Volume 2, Electrical Specification, Section 5.5.4.3.2.
Test description: TD-14.10 CardBus Interface Test (CBIF)

14.11.3 CardBus PC Card adapter must generate the Status Changed interrupt when a PC card is removed from its socket.

Reference document: WLP# - B2.1.4.1; PC Card Standard March 1997, Volume 2, Electrical Specification, Section 5.5.4.3.2.
Test description: TD-14.10 CardBus Interface Test (CBIF)

14.11.4 CardBus PC Card adapter must generate the Status Changed interrupt when CSTSCHG is asserted by the PC card.

Reference document: WLP# - B2.1.4.1; PC Card Standard March 1997, Volume 2, Electrical Specification, Section 5.5.4.3.2.
Test description: TD-14.10 CardBus Interface Test (CBIF)

14.11.5 CardBus PC Card adapter must generate the Status Changed interrupt when a PC card power-up is completed.

Reference document: WLP# - B2.1.4.1; PC Card Standard March 1997, Volume 2, Electrical Specification, Section 5.5.4.3.2.
Test description: TD-14.10 CardBus Interface Test (CBIF)

14.11.6 CardBus PC Card adapters must provide Socket Event, Mask, Present State, Force Event, and Control registers for each socket it supports.

Reference document: WLP# - B2.1.4.1; PC Card Standard March 1997, Volume 2, Electrical Specification, Section 5.5.4.4.
Test description: TD-14.10 CardBus Interface Test (CBIF)

14.11.7 CardBus PC Card adapters must provide the ability to simulate events by forcing values in the socket’s Event and Preset State registers.

Reference document: WLP# - B2.1.4.1; PC Card Standard March 1997, Volume 2, Electrical Specification, Section 5.5.4.4.4.
Test description: TD-14.10 CardBus Interface Test (CBIF)

14.11.8 CardBus PC Card adapters must not ignore the CSTSCHG signal during the power-up and power-down procedures.

Reference document: WLP# - B2.1.4.1; PC Card Standard March 1997, Volume 2, Electrical Specification, Section 5.5.4.7.2.
Test description: TD-14.10 CardBus Interface Test (CBIF)

14.11.9 CardBus 3.3V Vcc must be within the voltage regulation band, 3.0V to 3.6V.

Reference document: WLP# - B2.1.4.1; PC Card Standard March 1997, Volume 2, Electrical Specification, Section 5.3.2.1.1.
Test description: TD-14.10 CardBus Interface Test (CBIF)


PC Card Test Descriptions

This section describes the PC Card tests. The descriptions include an overview of each test, hardware and software setup, test execution instructions, test algorithms/steps, and test results interpretation.


TD-14.1 PC Card ExCA Compatibility Test (EXCA)

Overview

The EXCA test determines whether the PC card socket controllers support the industry-standard ExCA register set. The built-in software supporting 16-bit PCMCIA cards in Windows includes drivers for the ExCA-compatible socket controllers. To be compatible with these drivers, socket-controller implementations must support the industry-standard ExCA base register set.

The test verifies whether the following ExCA registers are implemented by the PC card socket controllers: Identification and Revision, Interface Status, Power Control, Interrupt and General Control, Card Status Change, Card Status Change and Interrupt Configuration, Address Window Enable, I/O Window Control, I/O Window registers, Memory Window registers. For each of these registers, this test checks read-only bits/fields and reserved bits/fields to ensure that they are implemented correctly.

The ExCA registers implemented by the PC card socket controllers must be register compatible with the Intel 82365 controller for backward compatibility. The ExCA registers can be accessed in two ways through two registers in the CardBus Bridge configuration space:

  • 16-Bit Legacy Mode Base Address register (Offset 0x44).
  • CardBus Socket/ExCA Base Address register (Offset 0x10).

The ExCA registers are accessed through the 16-Bit Legacy Mode Base Address by writing the register offset value into the index register (I/O base) and reading or writing the data register (I/O base +1). The I/O base address used in the index/data scheme is programmed in the 16-Bit Legacy Mode Base Address register, which can be shared by multiple card sockets.

The PC card socket controller must also provide a memory mapped alias of the ExCA registers by directly mapping them into PCI memory space. They are located through the CardBus Socket/ExCA Base Address register at memory offset 0x800. Each socket has a separate base address programmable by function. Memory offsets are 0x800-0x844 for both functions 0 and 1.

Overview of Test Steps

The test program scans the target system to build a linked list of all CardBus Bridge devices and gathers available information about the configuration header. At the time that this test program is able to run, the CardBus Bridge has been enumerated and initialized by the PCI bus driver. For each PCI function within the CardBus Bridge (that is each socket implemented by the CardBus Bridge), the test program accesses the ExCA registers through I/O (that is via 16-Bit Legacy Mode Base Address register) and checks for the Intel 32365-compatible ExCA registers. The test program repeats this test by accessing the ExCA register through memory (that is via CardBus Socket/ExCA Base Address register).

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires the target system to implement one or more PCI-CardBus Bridges. For software setup, the target system requires Windows installed correctly.

Results Interpretation

Individual pass/fail indication is provided for failures associated with each ExCA register. All failure messages are annotated with appropriate test assertion(s).

The following conditions cause test failures:

  • CardBus Bridge does not implement ExCA registers.
  • Read-only bits/fields of certain ExCA register are not implemented correctly.
  • Reserved bits/fields return non-zero values when read.
  • PC card socket controller does not support the required minimum number of memory and/or I/O windows.
  • ExCA registers cannot be accessed via the 16-Bit Legacy Mode Base Address register and/or the CardBus Socket/ExCA Base Address register.


TD-14.2 CardBus Bridge Register Test (CBBRIDGE)

Test Kit: HCT 11, HCT 10

Overview

The CBBRIDGE test determines whether the CardBus bridges support all registers specified in PCI to PCMCIA CardBus Bridge Register Description standard (Yenta Specification). This test verifies all reserved fields in the CardBus bridge configuration space register return value of 0 when they are read. Write operations on these fields must have no effect. This also checks whether read-only bits/fields in the CardBus bridge registers are only readable.

The test program verifies whether the following classes of configuration space registers are implemented: device identification registers (that is Vendor ID, Device ID, Revision ID, and Class Code), subsystem and subsystem vendor id registers, bus number registers (Primary Bus Number, Secondary Bus Number, and Sub-ordinate Bus Number), Command and Status registers, memory filter registers (Memory Base Address and Memory Limit), I/O filter registers (I/O Base Address and I/O Limit), latency timer registers (Latency Timer and Secondary Latency Timer), interrupt-related registers (Interrupt Pin and Interrupt Line), new capability register (Cap_Ptr), and socket registers (Event, Mask, Present State, Force, and Control).

After the system is booted to Windows, the test program accesses the CardBus bridge configuration space registers to verify the support for the above registers. The test accesses CardBus Bridge PCI configuration space via the Windows PCI driver interface.

Overview of Test Steps

The test program scans the target system to build a linked list of all CardBus Bridge devices and gathers available information about the configuration header. At the time that this test program is able to run, the CardBus Bridge has been enumerated and initialized by the PCI bus driver. For each PCI function within the CardBus Bridge (that is each socket implemented by the CardBus Bridge), the test program checks the following for each function configuration header space registers:

  • Implementation of the configuration header registers.
  • Read-only bits/fields within the register are not writeable.
  • Reserved bits/fields within the register always return 0s when read.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires the target system to implement one or more PCI-CardBus Bridges. For software setup, the target system requires Windows installed correctly.

Results Interpretation

Individual pass/fail indication is provided for failures associated with each CardBus configuration space register. All failure messages are annotated with appropriate test assertion(s).

The following conditions cause test failures:

  • CardBus Bridge does not implement certain required configuration space register.
  • Read-only bits/fields of certain CardBus bridge register are not implemented correctly.
  • Reserved bits/fields return non-zero values when read.


TD-14.3 CardBus Socket Controller BIOS Test (CBBIOS)

Overview

The CBBIOS test determines whether the system BIOS initializes the CardBus controller in the Intel 82365-compatible mode for backward compatibility. CardBus controllers are enumerated and configured in the same way as other PCI bus bridges. The system BIOS must initialize the CardBus controller to put the controller in legacy mode so that Windows socket services driver can access it as an Intel PC Card I/O card-compatible (PCIC-compatible) controller at an I/O address.

The test program verifies whether the system BIOS initializes the CardBus controller in the Intel 82365-compatible mode and reports it as device "pnp0e03, Intel 82365-compatible CardBus controller". Specifically, the test program verifies the following register contents during CardBus controller configuration space initialization: Command, 16-Bit Legacy Mode Base Address, CardBus Socket Register/ExCA Base Address Register, Interrupt Line, and all memory and I/O window related registers.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a target system with a PCI-CardBus Bridge supporting one or more socket interfaces. This test runs under the DOS environment.

Results Interpretation

Individual pass/fail indication is provided for failures associated with CardBus controller register contents. All failure messages are annotated with appropriate test assertion(s).

The following conditions cause test failures:

  • The system BIOS does not initialize the CardBus controller in Intel 82365-compatible mode.
  • The system BIOS does not initialize the CardBus controller registers (such as Command, 16-Bit Legacy Mode Base Address, CardBus Socket Register/ExCA Base Address Register, Interrupt Line, and all memory and I/O window related registers) with correct values.


TD-14.4 16-Bit PC Card Tuple Test (16BTUPLE)

Overview

The 16BTUPLE test determines whether the 16-bit PC Card (that is PCMCIA) cards support I/O card tuples required for the correct configuration of the card by the operating system. The Windows operating system determines what type of card is plugged into the PC card socket by examining the tuples on the card. For Plug and Play functionality, 16-bit PC card I/O cards must support a set of required information and configuration tuples. The PCMCIA bus enumerator uses these tuples to identify the card, load the correct device driver, and indicate all possible configurations to the Plug and Play configuration manager. The operating system then dynamically assigns a valid configuration based on this information.

The test program verifies whether the 16-bit PC card implements the following tuples:

  • Device information tuple (CISTPL_DEVICE for cards capable of 5V operation and CISTPL_DEVICE for cards capable of 3.3V operation)
  • Level 1 version/product information tuple (CISTPL_VERS_1)
  • Configuration tuple (CISTPL_CONF)
  • Configuration table entry tuple (CISTPL_CFTABLE_ENTRY)
  • Manufacturer ID tuple (CISTPL_MANCID)
  • Function ID tuple (CISTPL_FUNCID)

After the system is booted to Windows, the test program processes the 16-bit PC card CIS structure to verify the support for the above tuples. The test accesses 16-bit PC card tuple via the Windows Card Services/Socket Services interface. Specifically, the following Card Services API are called by this test to process the tuples: GetFirstTuple, GetNextTuple, and GetTupleData.

Overview of Test Steps

The test program scans the target system to build a linked list of all 16-bit PC card devices and gathers available information about the configuration header. At the time that this test program is able to run the CardBus bridges and 16-bit PC cards have been enumerated and initialized by the PCI bus and CardBus card and socket drivers. For each PCI function within the 16-bit PC card, the test program determines whether it implements the required tuples.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a target system with a PCI-CardBus Bridge supporting one or more socket interfaces. The device under test must be any 16-bit I/O PC card. For software setup, the target system requires Windows installed correctly. As part of this installation, Card Services and Socket Services drivers must be loaded. This test also requires a special card services client driver to access the card’s tuple information.

Results Interpretation

Individual pass/fail indication is provided for failures associated with each 16-bit PC card tuple. All failure messages are annotated with appropriate test assertion(s).

The following condition causes test failures:

  • 16-bit PC card under test does not implement the required tuple.


TD-14.5 CardBus Card Tuple Test (CBTUPLE)

Overview

The CBTUPLE test determines whether the CardBus cards support I/O card tuples required for the correct configuration of the card by the operating system. This test is similar to that of 16-bit card tuple test described in the previous section except that it verifies the required tuples for CardBus cards.

The test program verifies whether the CardBus cards implements the following tuples:

  • Link target control tuple (CISTPL_CISTPL_LINKTARGET)
  • End of chain tuple (CISTPL_CISTPL_END)
  • Base address register definition tuple (CISTPL_ BAR)
  • Configuration tuple (CISTPL_ CONFIG_CB)
  • Configuration table entry tuple (CISTPL_CFTABLE_ENTRY_CB)
  • Level 1 version/product information tuple (CISTPL_VERS_1)
  • Manufacturer identification string tuple (CISTPL_MANFID)
  • Function class identification tuple (CISTPL_FUNCID)

After the system is booted to Windows, the test program processes the CardBus card CIS structure to verify the support for the above tuples. The test accesses CardBus card tuple via the Windows Card Services/Socket Services interface. Specifically, the following Card Services API are called by the test to process the tuples: GetFirstTuple, GetNextTuple, and GetTupleData.

Overview of Test Steps

The test program scans the target system to build a linked list of all CardBus card devices and gathers available information about the configuration header. At the time that this test program is able to run the CardBus bridges and CardBus cards have been enumerated and initialized by the PCI bus and CardBus card and socket drivers. For each PCI function within the CardBus card, the test program determines whether the underlying CardBus card function implements the required tuples.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a target system with a PCI-to-CardBus Bridge supporting one or more socket interfaces. The device under test must be any CardBus I/O PC card. For software setup, the target system requires Windows installed correctly. As part of the installation, Card Services and Socket Services drivers must be loaded. This test also requires a special card services client driver to access the card’s tuple information.

Results Interpretation

Individual pass/fail indication is provided for failures associated with CardBus card tuples. All failure messages are annotated with appropriate test assertion(s).

The following condition causes test failures:

  • CardBus card under test does not implement the required tuple.


TD-14.6 CardBus Card Configuration Space Register Test (CBCREG)

Test Kit: HCT 11, HCT 10

Overview

The CBCREG test determines whether the CardBus card’s configuration space support registers are implemented correctly. Specifically, this test program validates the CardBus CIS Pointer register. CardBus cards must include a separate CIS for each function within the card. Each CIS provides a method for function-specific software such as the client drivers to determine the type of function and configuration options for a given function.

The test program verifies the CardBus card’s CIS Pointer register field functionality. In addition, the program verifies whether all unimplemented registers in CardBus card configuration space returns all 0s when read.

After the system is booted to Windows, the test program accesses the CardBus card’s configuration space to verify the support for the CIS register fields. The test accesses CardBus card’s configuration space via the PCI driver interface.

Overview of Test Steps

The test program scans the target system to build a linked list of all CardBus card devices and gathers available information about the configuration header. At the time that this test program runs the CardBus bridges, the CardBus cards have been enumerated and initialized by the PCI bus and the CardBus card and socket drivers. For each PCI function within the CardBus card, the test program determines whether the underlying CardBus card function implements CIS Pointer register.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a target system with a PCI-CardBus Bridge supporting one or more socket interfaces. The device under test must be any CardBus I/O PC card. For software setup, the target system requires Windows installed correctly.

Results Interpretation

Individual pass/fail indication is provided for failures associated with the CardBus card’s CIS Pointer register fields. All failure messages are annotated with the appropriate test assertion(s).

The following condition causes test failures:

  • CardBus card under test does not implement the CIS Pointer register field correctly.


TD-14.7 CardBus Card Common Silicon Guidelines Test (CBCOMSIG)

Test Kit: HCT 11, HCT 10

Overview

The CBCOMSIG test determines whether the CardBus card’s configuration space supports Common Silicon Guidelines as described in PC Card Standard Guidelines, Volume 10. The standard for CardBus defines a PCI-like configuration space that is not fully compliant with the PCI specification. Specifically, under the CardBus standard, card vendors do not have to implement certain critical fields in the configuration space, described in the PC Card standard as allocated. However, to maintain compatibility with existing PCI system software drivers, it is required that CardBus cards meet the Common Silicon Guidelines. Without the allocated fields, CardBus cards cannot be fully treated as PCI devices and configured by the PCI software.

The test program verifies whether the CardBus cards implement the following allocated fields in the configuration space:

  • PCI SIG assigned vendor ID (Vendor ID)
  • Vendor assigned device ID (Device ID)
  • Vendor assigned revision ID (Revision ID)
  • CardBus card device class (Class Code)
  • Latency timer setting (Max_Lat)
  • Time-slice request setting (Min_Gnt)
  • Current IRQ routing for the CardBus card device (Interrupt Line)

After the system is booted to Windows, the test program accesses the CardBus card’s configuration space to verify the support for the above fields. The test accesses CardBus card’s configuration space via the PCI driver interface.

Overview of Test Steps

The test program scans the target system to build a linked list of all CardBus card devices and gathers available information about the configuration header. At the time that this test program is able to run, the CardBus bridges and CardBus cards have been enumerated and initialized by the PCI bus and CardBus card and socket drivers. For each PCI function within the CardBus card, the test program determines whether the underlying CardBus card function implements all allocated fields per the Common Silicon Guideline standards.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a target system with a PCI-CardBus Bridge supporting one or more socket interfaces. The device under test must be any CardBus I/O PC card. For software setup, the target system requires Windows installed correctly.

Results Interpretation

Individual pass/fail indication is provided for failures associated with CardBus card’s allocated fields in its configuration space. All failure messages are annotated with appropriate test assertion(s).

The following condition causes test failures:

  • CardBus card under test does not implement the required allocated field.


TD-14.8 CardBus Subsystem ID and Subsystem Vendor ID Test (CBSID)

Overview

The purpose of the CBSID test is to verify whether CardBus cards implement subsystem ID and subsystem vendor ID registers in their configuration space. The subsystem ID and subsystem vendor ID registers are required on CardBus cards for Windows compatibility.

After the system is booted to Windows, the test program accesses the CardBus card’s configuration space registers to verify the support for the subsystem ID registers. The test accesses CardBus card’s PCI configuration space via the Windows PCI driver interface.

Overview of Test Steps

The test program scans the target system to build a linked list of all CardBus card devices and gathers available information about the configuration header. At the time that this test program is able to run, the CardBus bridges and CardBus cards have been enumerated and initialized by the PCI bus, and CardBus card and socket drivers. For each PCI function within the CardBus card, the test program determines whether the underlying CardBus card function supports PCI subsystem ID and subsystem vendor ID registers. If these registers are implemented, the program then checks whether they have nonzero values. The program also verifies if these two registers are not writable.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a target system with a PCI-CardBus Bridge supporting one or more socket interfaces. All peripheral devices under test must be CardBus card devices such as a CardBus modem card and a CardBus network card.

For software setup, the target system requires Windows installed correctly.

Results Interpretation

Individual pass/fail indication is provided for failures associated CardBus card functions. All failure messages are annotated with appropriate test assertion(s).

The following conditions cause test failures:

  • Device under test does not implement subsystem ID and subsystem vendor ID registers as required by PCI 2.1 specification.
  • Subsystem ID and/or subsystem vendor ID registers of the CardBus card functions are writable.


TD-14.9 CardBus Bridge Power Management Register Test (CBPMREG)

Test Kit: HCT 11, HCT 10

Overview

The purpose of the CBPMREG test is to probe CardBus Bridge configuration space for each of the CardBus device functions and verify that the power management registers have been implemented correctly.

The CBPMREG test accesses CardBus Bridge PCI configuration space via the Windows PCI driver interface.

Overview of Test Steps

The test program scans the target system to build a linked list of all CardBus Bridge and card devices and gathers available information about the configuration header. At the time the test program is able to run, the CardBus Bridge have been enumerated and initialized by the PCI bus and PC card drivers. For each PCI function within the CardBus Bridge (that is each socket implemented by the CardBus Bridge) and CardBus card, the test program first determines whether the underlying function supports PCI new capabilities structure. If power management new capability is supported the function, the program then verifies that the function has correctly implemented its power management interface register block.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a target system with a PCI-CardBus Bridge supporting one or more socket interfaces. The CardBus Bridge must support PCI power management register interface. Other peripheral device under test (for example, CardBus modem card) must also support power management register interface.

For software setup, the target system requires Windows installed correctly.

Results Interpretation

Individual pass/fail indication is provided for failures associated with power management register implementation. All failure messages are annotated with appropriate test assertion(s).

The following conditions cause test failures:

  • Device under test does not support PCI power management register block.
  • CardBus bridge/card functions do not implement certain power management registers correctly (for example, reading reserved bits/fields results in non-zero values, CardBus bridge is not compliant with PCI power management specification 1.1).


TD-14.10 CardBus Interface Test (CBIF)

Overview

The purpose of this test is to verify the CardBus socket interface functionality. This test determines whether the CardBus bridge socket interface registers are implemented correctly for the proper power management operations of CardBus cards.

After the system is booted to Windows, the test program accesses the PCI-to-CardBus bridge’s configuration space via the Windows PCI driver interface. At the time that the program is able to run, the PCI-to-CardBus bridge is enumerated and initialized by the PCI bus driver.

Overview of Test Steps

  1. Scan the target system to build a linked list of all PCI-to-CardBus bridge sockets and gather available information about the configuration space and the new capability list for the CardBus bridge sockets. If the PCI-to-CardBus bridge does not support PCI power management register interface, report an error and abort the test.
  2. Verify that the PCI-to-CardBus bridge implements socket Event, Mask, Present State, Force Event, and Control registers for the socket it supports.
  3. Verify that all reserved fields in the socket interface registers always return values of 0s when they are read. Ensure write operations on these fields have no effect.
  4. Write to the Force Event register bits (for example., CSTSCHG, 16Card, CBcard, 3Vcard, and 5Vcard) to cause bits in the Socket Present State register and/or Socket Event registers to be set. If appropriate Socket Present State and Event register bits are not set, report an error message.
  5. Verify that writing zeroes to the Socket Force Event register has no effect.
  6. Instruct the user to insert the CardBus tester into the socket.
  7. Check whether the CardBus tester card is configured correctly by the Windows operating system.
  8. Determine whether the PCI-to-CardBus bridge sets the following bits:
  • CCD#1 and CCD#2 bits in Socket Present State register.
  • CCD#1 and CCD#2 bits in Socket Event register.
  • CSTSCHG bit Socket Present State register.
  • CSTSCHG bit Socket Event register.
  • PowerCycle bit Socket Present State register.
  • PowerCycle bit Socket Event register.
  • Other bits in Socket Present State register (for example, CBcard, 3Vcard, and so on.)
  9. Instruct the user to remove the CardBus tester from the socket.
  10. Determine whether the PCI-to-CardBus bridge sets appropriate bits in Socket Present State and Event registers.
  11. Repeat steps 6 through 10 by inserting the CardBus tester into each of the CardBus bridge sockets.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a target system with a PCI-to-CardBus bridge supporting one or more socket interfaces. In addition, the test requires a special CardBus tester card, which is capable of asserting its CTSTCHG signal.

For software setup, the target system requires Windows installed correctly. As part of the installation, Card Services and Socket Services drivers must be loaded.

Results Interpretation

Individual pass/fail indication is provided for failures associated with CardBus interface functionality. All failures are annotated with appropriate test assertion(s).

The following conditions cause test failures:

  • PCI-to-CardBus bridge does not support power management capability structure in its PCI configuration space.
  • PCI-to-CardBus bridge’s power management interface registers are not implemented according to the PCI Power Management Interface Spec for CardBus bridges.
  • PCI-to-CardBus bridge does not implement Socket Event, Mask, Present State, and Control registers for each socket it supports.
  • CardBus tester is not configured correctly by the Windows operating system.
  • PCI-to-CardBus bridge does not generate the Status Changed interrupt when the CardBus tester asserts the CSTSCHG signal.
  • PCI-to-CardBus bridge does not generate the Status Changed interrupt when the CardBus tester is inserted into its socket.
  • PCI-to-CardBus bridge does not generate the Status Changed interrupt when the CardBus tester is removed from its socket.
  • PCI-to-CardBus bridge does not generate the Status Changed interrupt when the CardBus tester’s power-up is completed.


TD-14.11 CardBus Card Wake-Up Test (CBWAKE)

Overview

The purpose of this test is to verify that the ACPI compliant mobile platform correctly sequences between the S1/S2/S3 system sleep states and its working state in response to the PME# signal assertion from the PCI-to-CardBus bridge as a result of CSTSCHG assertion by the CardBus tester.

After the system is booted to Windows, the test program accesses the PCI-to-CardBus bridge’s configuration space via the Windows PCI driver interface. The test program accesses CardBus tester’s tuples via Windows Card Services/Socket Services interface. Specifically, the following Card Services APIs are called by the test to process its tuples: GetFirstTuple, GetNextTuple, and GetTupleData.

At the time that this program is able to run, the PCI-to-CardBus bridge is enumerated and initialized by the PCI bus driver.

Overview of Test Steps

  1. Scan the target system to build a linked list of all PCI-to-CardBus bridge sockets and gather available information about the configuration space and the new capability list for the CardBus bridge sockets. If the PCI-to-CardBus bridge does not support the PCI power management register interface, report an error message and abort the test.
  2. Instruct the user to insert the CardBus tester into the socket.
  3. Check whether the CardBus tester card is configured correctly by the Windows operating system.
  4. Check if the target system supports ACPI. Report an error and abort the test for non-ACPI systems.
  5. Perform the following steps for each supported sleep state of the target system: S1, S2, and S3.

Perform the following steps for each supported sleep state of the CardBus tester: D0, D1, D2, D3 Hot, and D3 Cold.

(a.) Place the CardBus tester into an appropriate device state by writing its PMCSR.PowerState field in the power management register block.

(b.) Transition the target system into an appropriate system sleep state.

(c.) Verify that the system is in S3 sleep state.

(d.) Measure CardBus tester’s Vaux when the target system is in S3.

(e.) Wake-up the system by asserting CardBus tester’s CSTSCHG signal.

(f.) Check if the CardBus tester’s power management register bits are set to reflect the current device power state (for example, PME_Status, PME_En, PowerState).

(g.) Verify that the CardBus tester is fully functional after the target system goes to Sx sleep state and back.

(h.) Measure CardBus tester’s 3.3V Vcc when the system wakes up from its sleep state. If the 3.3V Vcc is out of the voltage regulation band (such as 3.3V Vcc < 3.0V or 3.3V Vcc > 3.6V), report an error message and continue testing.

  6. Repeat steps 2 through 5 by inserting the CardBus tester into each of the CardBus bridge sockets.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires an ACPI compliant target system with a PCI-to-CardBus bridge supporting one or more socket interfaces. In addition, the test requires a special CardBus tester card, which is capable of waking up the system from its sleep states.

For software setup, the target system requires Windows installed correctly. As part of the installation, Card Services and Socket Service drivers must be loaded. The test also requires a special card services client driver to access the CardBus tester’s tuple information.

Results Interpretation

Individual pass/fail indication is provided for failures associated with CardBus power management functionality. All failures are annotated with appropriate test assertion(s).

The following conditions cause test failures:

  • PCI-to-CardBus bridge does not support power management capability structure in its PCI configuration space.
  • PCI-to-CardBus bridge’s power management interface registers are not implemented according the PCI Power Management Interface Spec. for CardBus bridges.
  • The target mobile platform does not support ACPI.
  • Assertion of CSTSCHG from the CardBus tester’s D1 device state does not wake-up the target system from its S0/S1 power states.
  • Assertion of CSTSCHG from the CardBus tester’s D2 device state does not wake-up the target system from its S0/S1/S2 power states.
  • Assertion of CSTSCHG from the CardBus tester’s D3 Hot device state does not wake-up the target system from its S0/S1/S2 power states.
  • Assertion of CSTSCHG from the CardBus tester’s D3 Cold device state does not wake-up the target system from its S0/S1/S2/S3 power states.
  • CardBus Vcc is out of range in S0, S1, or S2 sleep state.
  • CardBus Vaux is out of range in S3 system sleep state.


Chapter 15: Television Output Hardware Test Specification

This document provides a specification of metrics used in assessing the function of hardware supporting a generation of base-band analog video signals conforming to ITU region M signaling standards. This specification makes use of previously defined metrics for related video capabilities.

In the context of this document, television output is the hardware implementing a capability of producing an SDTV signal from a digital representation of the base-band video. A digital representation may provide less than, the same as, or more than the required resolution for production of an SDTV signal. All hardware that is involved in processing of the digital representation after presentation to the display subsystem is included in the tested hardware. The television output hardware is typically closely associated with the hardware implementing the display capability, although this is not required.

Test Coverage

This specification addresses television output requirements that partially verify compliance with Microsoft Windows Logo Program System and Device Requirements. These chapters specify several requirements that are applicable to television output devices. Standard definition television (SDTV) signals that have been generated by such devices have special considerations that must be addressed in testing. Television Output Hardware is not required in the system. If present, that hardware must meet the functionality requirements described within this specification.

These tests provide coverage of hardware implementing the encoding of base-band video SDTV signals. This capability complements the PC’s capability of playing entertainment type content, allowing connectivity with a wide range of Consumer Electronics (CE) devices, some of which may need to have video signals sent to them by the PC. These tests do not specifically provide coverage of any RF modulated output capability of such hardware. In the interests of maintaining signal integrity in transmission to the connected device, all signals should be transferred using Y/C (S-Video) interconnects. A solution that does not provide an S-Video connection may use a composite (SMPTE-170M) interconnect.

A composite interconnect, due to the way in which the signal is encoded, may produce a lower quality signal than a Y/C interconnect, all else being equal. A solution that provides both Y/C and composite connections may pass the test based on the results using either the Y/C or composite connection. It does not need to pass the test using both of the connections, rather only one needs to pass.

The US uses NTSC chrominance encoding, while many other countries use PAL chrominance encoding. Nearly all of the Americas use ITU Region-M signaling standard. Other regions of the world may employ signaling standards that do not adhere to ITU Region-M standards. These tests are not defined for such regions. These tests are defined for ITU Region-M standards with NTSC chrominance in an NTSC-M environment, and with PAL chrominance in a PAL-M environment.

The assessment of the hardware capability is conducted by automatic inspection of the data generated by a video encoding solution, using known test patterns. The known test patterns are various representations of content specifically designed to determine whether the television output hardware is functioning correctly. The inspection is accomplished by connection of the television output to the input of a system that passes the Video Input Test Suite using 720 pixels per line.

The automated portions of the test suite are started on each machine, and require little operator intervention if the hardware is minimally functional. Detailed test logs are generated on the device under test and analysis machines, providing pass and fail indications for individual test assertions. No subjective operator input is required. Certain portions of the test suite assess hardware capabilities for which it is difficult or impossible to provide automated testing. In these few cases, the test suite requests operator input. In all of these cases, the operator input is restricted to yes or no questions pertaining to objective fact.

In no case is a subjective evaluation requested. An example of such interaction would be the request for an operator to confirm the base-band video cable is attached to the TV Output hardware. Another example is the request that the operator verify that the device under test had this connection present when it was powered on. Each portion of the test suite may provide information in addition to assertion status as an aid in diagnosing difficulties.

This test suite requires a single S-Video or composite video cable, the PC containing the television output hardware, and a PC supporting Windows Logo Program-compliant video input at 720 pixels per line in YUY2 mode.

Note: Descriptions of known system configurations that provide this video input capability are available at the System Test Implementers Forum web site.

Test Methodology

The Television Output Hardware tests require certain equipment, materials, configuration and interconnect of the equipment, verification of the configuration, and finally the actual testing. The following sections cover each of these areas

Test Materials

The tests require the following test equipment and materials.

  • One PC system configured with Y/C and composite base-band video input, which can pass the Video Input Test Suite. This system is called the Test Signal Analyzer (TSA). Refer to the Video Input Test Suite descriptions in Chapter 6 for configuration information.
  • One PC system configured with television output. This system is called the Device Under Test (DUT). The DUT must provide Y/C S-Video or SMPTE-170M composite output.
  • One S-Video or composite video cable used to connect the TV Output of the DUT to the base-band video input of the TSA.
  • The test implementation including portions that execute on the DUT and on the TSA.

Test Configuration

The DUT is connected to the TSA. The connection is made using either the Y/C or composite output of the DUT to the corresponding input of the TSA using the appropriate cable.

Test Configuration Schema

Test Configuration Schema

The verification of the correct configuration of the DUT may be aided by the use of a standard television set.

Verification of Configuration

Once the required connections have been made, verify the correct system configuration by viewing the DUT output on the TSA. Start a video input application on the TSA and determine whether the desktop from the DUT is visible in the preview video. A method of doing this, without a video input application, is to use the DirectX Media SDK’s graph editor as follows. From the TSA, launch the application ‘graphedt.exe’ from the DirectX Media SDK. Insert the video capture source filter corresponding to your video input solution into the empty, unnamed filter graph. Configure the source filter for a YUY2 input format at 720 x 480 resolution. Render the capture pin by right clicking on the pin and selecting render from the drop down menu.

The filter graph should change, with a connection from the capture pin to at least one other filter. See below if this does not happen. Press the play or run button on the button bar and you should see the video coming from the DUT in a window on your screen. The video should consist of the desktop of the DUT. If not, there is a problem with your configuration. Be sure to check that the TV Output Hardware on the DUT is enabled, and that the system was started with a device attached to the TV Output Hardware (the TSA for instance). If you see the desktop from the DUT, proceed with the final step in verification. On the DUT, move the cursor and verify that the changed desktop (new cursor location) is shown properly in the window on the TSA.

In case of trouble rendering the capture pin, that is, if there is nothing connected to the capture pin after selecting render from the menu or if the capture pin is connected back to the crossbar, check your TSA system configuration for rendering support for the YUY2 format. Some video codecs available freely on the web are able to display this format. One such video codec is Indeo Video 4 codec, available at http://www.ligos.com/indeo/downloads/download.shtm . When you have succeeded in rendering the capture pin in the chosen format, you should be able to see the video coming from the DUT in a window on your screen when you press the play button in the graph editor on the TSA.

Test Operation

The TVOUTCFG test is invoked on the DUT and runs to completion. This generates a log of assertions with pass or fail status. The TVOUTFN1 and TVOUTFN2 tests are invoked on the DUT and TSA respectively. These tests should be started at the same time. Each of these tests generates a log of assertions with pass or fail status. The TVOUTIMG test is then invoked on the TSA. The TVOUTFN1 test continues on the DUT, providing test images used by TVOUTIMG. The TVOUTIMG test generates a log of assertions with pass or fail status.

In cases where two tests are launched simultaneously on the DUT and TSA, launching an executable on each machine starts the tests. The tests then perform an automated synchronization and run to completion. The DUT portion runs N times, generates its log and terminates. The TSA portion captures one of the N runs, generates its log and terminates. The tests run for approximately one minute. During this time, it is only necessary for the operator to insure that the test configuration is not disturbed, and to respond to various prompts. No other operator intervention is required. Passing the test requires a pass for each assertion. If the test detects some problem with the configuration that was not uncovered by the above configuration verification procedure, it alerts the operator to the problem and requests that it be corrected.


TV Output Hardware Test Assertions

The TV Output Hardware Test Suite is composed of four tests providing coverage for 27 assertions. Each assertion listed below contains a pointer to a detailed test description. The detailed test description provides in depth information about how the assertions are tested, how each test is run, and how the results of the test should be interpreted.


Reference Documents for TV Output Assertions

Microsoft Windows Driver Development Kit

http://www.microsoft.com/ddk/

Microsoft Windows Logo Program System and Device Requirements, Version 2.0

http://www.microsoft.com/hwdev/winlogo/
(listed as "WLP#" in these assertions)

PC 2001 System Design Guide and PC 99 System Design Guide

http://www.microsoft.com/hwdev/platform/pcdesign/desguide/pcguides.asp


TV Output Hardware Configuration Assertions

The following hardware configuration assertions are tested in TD-15.1 TV Output Hardware Configuration Test (TVOUTCFG).

15.1.1 Hardware indicates support for television base-band video output.

Reference documents: WLP# - B11.1.4.4, B4.1.2.3; PC 2001 System Design Guide - VID-0215, GRPH-0169; PC 99 System Design Guide - 14.6.
Test description: TD-15.1 TV Output Hardware Configuration Test (TVOUTCFG)

15.1.2 Hardware indicates support for a Y/C (S-Video) or Composite TV output.

Reference documents: WLP# - B11.1.4.4, B4.1.2.3; System Design Guide - GRPH-0193; PC 99 System Design Guide - 14.6.2.
Test description: TD-15.1 TV Output Hardware Configuration Test (TVOUTCFG)

15.1.3 Hardware indicates support for ITU Region-M output.

Reference documents: WLP# - B11.1.4.4, B4.1.2.3; PC 2001 System Design Guide - VID-0215, GRPH-0169; PC 99 System Design Guide - 14.6.1.
Test description: TD-15.1 TV Output Hardware Configuration Test (TVOUTCFG)

15.1.4 Hardware indicates support for multiple source resolutions.

Reference documents: WLP# - B4.1.4.10; PC 2001 System Design Guide - GRPH-0207; PC 99 System Design Guide - 14.14.
Test description: TD-15.1 TV Output Hardware Configuration Test (TVOUTCFG)

15.1.5 Hardware indicates support for a controllable, effective flicker filter.

Reference documents: WLP# - B4.1.4.10; PC 2001 System Design Guide - GRPH-0163; PC 99 System Design Guide - 14.1 and 14.3.
Test description: TD-15.1 TV Output Hardware Configuration Test (TVOUTCFG)

15.1.6 Hardware indicates support for YUY2 source image format.

Reference documents: WLP# - B4.1.4.11; PC 2001 System Design Guide - GRPH-0207.3; PC 99 System Design Guide - 14.14.3.
Test description: TD-15.1 TV Output Hardware Configuration Test (TVOUTCFG)


TV Output Hardware Function #1 Assertions

The following hardware function assertions are tested in TD-15.2 TV Output Hardware Function #1 Test (TVOUTFNC1).

15.2.1 Hardware supports adequate bus speed for TV output.

Reference documents: WLP# - B4.1.4.9; PC 2001 System Design Guide - GRPH-0163; PC 99 System Design Guide - 14.1 and 14.3.
Test description: TD-15.2 TV Output Hardware Function #1 Test (TVOUTFNC1)

15.2.2 Hardware supports adequate buffer speed for TV Output.

Reference documents: WLP# - B4.1.4.9; PC 2001 System Design Guide - GRPH-0163; PC 99 System Design Guide - 14.1and 14.3.
Test description: TD-15.2 TV Output Hardware Function #1 Test (TVOUTFNC1)

15.2.3 Hardware supports full frame rate display for TV output.

Reference documents: WLP# - B11.1.4.4; PC 2001 System Design Guide - VID-0215; PC99 System Design Guide - 15.35.1.
Test description: TD-15.2 TV Output Hardware Function #1 Test (TVOUTFNC1)


TV Output Hardware Function #2 Assertions

The following TV output hardware function assertions are tested in TD-15.3 TV Output Hardware Function #2 Test (TVOUTFNC2).

15.3.1 Hardware provides base-band ITU Region-M video output.

Reference documents: WLP# - B11.1.4.4; PC 2001 System Design Guide - VID-0215, GRPH-0169; PC 99 System Design Guide - 14.6.
Test description: TD-15.3 TV Output Hardware Function #2 Test (TVOUTFNC2)

15.3.2 Hardware provides support for multiple YUY2 source image resolutions.

Reference documents: WLP# - B11.1.4.4; PC 2001 System Design Guide - GRPH-0207;
PC99 System Design Guide - 14.14.
Test description: TD-15.3 TV Output Hardware Function #2 Test (TVOUTFNC2)

15.3.3 Hardware provides support for a controllable, effective flicker filter.

Reference documents: WLP# - B11.1.4.4, B4.1.4.10; PC 2001 System Design Guide - GRPH-0163;
PC 99 System Design Guide - 14.1 and 14.3.
Test description: TD-15.3 TV Output Hardware Function #2 Test (TVOUTFNC2)

15.3.4 The frame rate is within 0.4% of expected during the period of the test.

Reference documents: WLP# - B11.1.4.4, B4.1.4.10; PC 2001 System Design Guide - VID-0215; PC 99 System Design Guide - 15.35.1.
Test description: TD-15.3 TV Output Hardware Function #2 Test (TVOUTFNC2)

15.3.5 Hardware provides the correct field presentation rate.

Reference documents: WLP# - B11.1.4.4, B4.1.4.10; PC 2001 System Design Guide - VID-0215;
PC99 System Design Guide - 15.35.1.
Test description: TD-15.3 TV Output Hardware Function #2 Test (TVOUTFNC2)


TV Output Hardware Quality Assertions

The following TV output hardware quality assertions are tested in TD-15.4 TV Output Hardware Quality Test (TVOUTIMG).

15.4.1 Image is presented in top down order.

Reference documents: WLP# - B11.1.4.4, B4.1.4.10; PC 2001 System Design Guide - VID-0215; PC99 System Design Guide - 15.34 and 15.35
Test description: TD-15.4 TV Output Hardware Quality Test (TVOUTIMG)

15.4.2 Image is presented without field inversion.

Reference documents: WLP# - B11.1.4.4, B4.1.4.10; PC 2001 System Design Guide - VID-0215; PC99 System Design Guide - 15.34 and 15.35.
Test description: TD-15.4 TV Output Hardware Quality Test (TVOUTIMG)

15.4.3 Image is presented without mirror inversion.

Reference documents: WLP# - B11.1.4.4, B4.1.4.10; PC 2001 System Design Guide - VID-0215; PC99 System Design Guide - 15.34 and 15.35.
Test description: TD-15.4 TV Output Hardware Quality Test (TVOUTIMG)

15.4.4 Image generated from a full resolution source has correct luminance detail.

Reference documents: WLP# - B11.1.4.4, B4.1.4.10; PC 2001 System Design Guide - VID-0215; PC99 System Design Guide - 15.35.
Test description: TD-15.4 TV Output Hardware Quality Test (TVOUTIMG)

15.4.5 Image generated from a full resolution source has correct chrominance detail.

Reference documents: WLP# - B11.1.4.4, B4.1.4.10; PC 2001 System Design Guide - VID-0215; PC99 System Design Guide - 15.35.
Test description: TD-15.4 TV Output Hardware Quality Test (TVOUTIMG)

15.4.6 Image generated from a non-full resolution source has correct luminance detail.

Reference documents WLP# - B11.1.4.4, B4.1.4.10; PC 2001 System Design Guide - VID-0215; PC 99 System Design Guide - 15.35.
Test description: TD-15.4 TV Output Hardware Quality Test (TVOUTIMG)

15.4.7 Image generated from a non-full resolution source has correct chrominance detail.

Reference documents: WLP# - B11.1.4.4, B4.1.4.10; PC 2001 System Design Guide - VID-0215; PC99 System Design Guide - 15.35.
Test description: TD-15.4 TV Output Hardware Quality Test (TVOUTIMG)

15.4.8 Image generated from a full resolution source has correct luminance levels.

Reference document: WLP# - B11.1.4.4, B4.1.4.10; PC 2001 System Design Guide - VID-0215; PC 99 System Design Guide - 15.35.
Test description: TD-15.4 TV Output Hardware Quality Test (TVOUTIMG)

15.4.9 Image generated from a full resolution source has correct chrominance levels.

Reference documents: WLP# - B11.1.4.4, B4.1.4.10; PC 2001 System Design Guide - VID-0215; PC 99 System Design Guide - 15.35.
Test description: TD-15.4 TV Output Hardware Quality Test (TVOUTIMG)

15.4.10 Image generated from a non-full resolution source has correct luminance levels.

Reference documents: WLP# - B11.1.4.4, B4.1.4.10; PC 2001 System Design Guide - VID-0215; PC 99 System Design Guide - 15.35.
Test description: TD-15.4 TV Output Hardware Quality Test (TVOUTIMG)

15.4.11 Image generated from a non-full resolution source has correct chrominance levels.

Reference document: WLP# - B11.1.4.4, B4.1.4.10; PC 2001 System Design Guide - VID-0215; PC 99 System Design Guide - 15.35.
Test description: TD-15.4 TV Output Hardware Quality Test (TVOUTIMG)

15.4.12 Image generated from a full resolution source has correct image dimensions.

Reference documents: WLP# - B11.1.4.4, B4.1.4.10; PC 2001 System Design Guide - VID-0215; PC 99 System Design Guide - 15.35.
Test description: TD-15.4 TV Output Hardware Quality Test (TVOUTIMG)

15.4.13 Image generated from a non-full resolution source has correct image dimensions.

Reference documents: WLP# - B11.1.4.4, B4.1.4.10; PC 2001 System Design Guide - VID-0215; PC 99 System Design Guide - 15.35.
Test description: TD-15.4 TV Output Hardware Quality Test (TVOUTIMG)


Desktop TVOUT Assertions

The following Desktop TVOUT assertions are tested in TD-15.5 TV Image Positioning Test and TD-15.6 1024x768 Resolution TV-Out Conversion Test

15.5.1 Software must be able to program the television output hardware to position the television image +/- 40 pixels horizontally and +/- 20 scan lines vertically. The pixel increment for image translation must be 4 pixels or less.

Reference document: WLP# - B11.1.4.4, B4.1.4.10; PC 2001 System Design Guide - GRPH-0191.
Test description: TD-15.5 TV Image Positioning Test

15.5.2 TV-out hardware must be able to accept desktop resolutions up to 1024x768 progressive and convert it to an interlaced TV resolution output signal.

Reference document: WLP# - B11.1.4.4, B4.1.4.10; PC 2001 System Design Guide - GRPH-0191.
Test description: TD-15.6 1024x768 Resolution TV-Out Conversion Test


TV Output Test Descriptions

This section provides a detailed description of the goals and operation of each of the tests. Each test includes an overview, a description of each assertion with testing methodology, testing criteria for obtaining a "PASS" for the assertion, instructions for setup and running the test, and guidelines for interpreting the results of the test.

The DirectX Media infrastructure (DirectShow) provides an appropriate level of abstraction from implementation details and is required to run the tests. Test software will report if the DirectX Media infrastructure (DirectShow) is not present in the system, and then terminates.


TD-15.1 TV Output Hardware Configuration Test (TVOUTCFG)

Overview

The TV Output Hardware Configuration Test assesses the presence and configuration of the television standard output capability. A pass for each assertion is required to obtain a pass for the test.

This test accesses the TV Output capability through the DirectX Media interfaces provided for using and configuring video outputs and ancillary devices

Each assertion is described in the numbered paragraphs below. The method used to test the assertion and the criteria for passing the assertion is described.

1. The hardware indicates support for television base-band video output.

For this assertion, the test determines whether the hardware indicates support for a television standard output. If such support is indicated, the assertion test passes, otherwise, it fails. There is not, at this time, a standard method for determining the presence of this support in software. The test asks the operator to confirm that the capability is enabled in order to assess this assertion. If the operator indicates that the capability is enabled, this assertion test passes, otherwise it fails. An informative message is provided in the test log to indicate that the capability should be enabled and the test rerun.

2. The hardware indicates support for a Y/C (S-Video) or composite TV output.

For this assertion, the test determines whether the hardware indicates support for an S-Video or composite connector. The test passes if such support is indicated and fails otherwise. As in assertion one above, and for the same reason, the test relies on operator input to assess this assertion. The operator is asked to specify the type of interconnect being used for the test. The operator response is recorded in the test output to enable tracking of results based on connection type.

3. The hardware indicates support for ITU Region-M output.

For this assertion, the test determines whether the hardware indicates the ability to provide a Region-M compatible signal. If so, the test passes, otherwise it fails. As in assertion one above, and for the same reason, the test relies on operator input to assess this assertion.

4. The hardware indicates support for multiple source resolutions.

For this assertion, the test determines whether the hardware indicates the ability to produce a TV output from multiple different source resolutions. The test attempts to configure the hardware to provide TV output from a full resolution source image description, from a half horizontal resolution source image description, and from a quarter (half vertical, half horizontal) source image resolution. If the hardware indicates support for each of these, and the support appears functional, the test passes. If any of these configurations results in an error condition, or the support appears to not function, the test fails. The test does not require operator input. As an informational message, the test logs any resolutions that result in errors.

5. The hardware indicates support for a controllable, effective flicker filter.

For this assertion, the test determines whether the hardware indicates support for a flicker filter. If it does not, the test fails. If it does, the test continues. The test determines whether the hardware indicates support for turning the flicker filter on and off. If it does not the test fails, otherwise it passes. As in assertion one above, and for the same reason, the test relies on operator input to assess this assertion.

6. The hardware indicates support for YUY2 source image format.

For this assertion, the test determines whether the hardware indicates support for use of YUY2 format source images. In actuality you will run the test twice. The test assesses this for the same set of resolutions used in the previous assertion step 4. If the hardware indicates support for YUY2 format in each resolution the test passes, otherwise it fails. As an informational message, the test displays any resolutions, which resulted in errors.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test configuration setup is described in the Test Methodology section. The test requires approximately thirty seconds to complete.

Results Interpretation

Each pass or fail condition is described in the test description under each test assertion. In addition to passing and failing, the test may provide advisory information under the heading of ‘warning’ or ‘info’. This status does not affect the pass or fail result. In cases where the test is able to determine that a simple configuration error has occurred, an informative message indicating how to correct the error is provided. An overall test pass requires a pass for each assertion. An assertion failure is flagged in the log, and includes the assertion number and the text of the assertion. It is possible to pass assertion four, and fail assertion six if a solution provides support for a common YVU format, but not for YUY2. It is possible to fail assertions four and six if a solution’s surface memory is not accessible between a lock()/unlock() pair. If an access of the surface memory results in an error, the test traps the error and provides log information indicating that there is a problem accessing the surface. Several of the assertions must be verified by use of operator input due to a lack of a standard interface by which the hardware capabilities are exposed. It is envisioned that over time, such standard interfaces become available. A future revision of this test specification may be produced that incorporates use of such interfaces.


TD-15.2 TV Output Hardware Function #1 Test (TVOUTFNC1)

Overview

The TV Output Hardware Function #1 test assesses the ability of the hardware, as viewed from the source, to provide basic functionality in support of the TV Output capability. These metrics relate to the ability to provide source imagery to the subsystem in a timely manner so other devices in the system are not unduly impacted.

The test may not complete successfully if the TVOUTCFG test does not pass. The test can in some cases execute and produce useful information, even if the TVOUTCFG test does not pass.

This test accesses the TV output capability through the DirectX Media interfaces provided for using and configuring filters and associated devices.

Each assertion is described in the numbered paragraphs below. The method used to test the assertion and the criteria for passing the assertion is described.

1. The hardware supports adequate bus speed for TV output.

For this assertion, the test assesses the ability of the used bus to access the TV output hardware for transferring source imagery in a timely manner. The test performs this measurement by transferring a small (2048 byte) buffer of data from the system to the subsystem. If this transfer occurs at one hundred megabytes per second or more, the test passes, otherwise it fails. The speed of the transfer is measured by first starting the clock, beginning the transfer, waiting for the transfer to complete, and then stopping the clock. The elapsed time is computed with the following formula (elapsed = stop – start). The rate of bus speed is computed using the following formula (rate = size / elapsed). Additional details may include the actual measured speed of the transfer.

2. The hardware supports adequate buffer speed for TV output.

For this assertion, the test assesses the ability of the TV output hardware to accept source imagery in a timely manner. The test performs this measurement by transferring approximately 600Kbytes from the system to the subsystem. If this transfer occurs at one hundred megabytes per second or more the test passes, otherwise it fails. The speed of the transfer is measured in the same way as the previous assertion. Additional details may include the actual measured speed of the transfer.

3. The hardware supports full frame rate display for TV output.

For this assertion, the test assesses the ability of the hardware to support display of full frame rate source imagery. The test determines, for a sequence of frames at Region-M rates, whether the dispatch of any source image in the sequence completes after the time that the next source image is to be displayed, as measured by frame number and Region-M rates. If the completion of each frame dispatch is prior to the desired dispatch time of the subsequent frame the test passes, otherwise it fails. Additional details may include the minimum and maximum time remaining from the end of the dispatch to the next frame dispatch time.

In all cases, dispatch times are considered integer multiples of Region-M signaling rates, where the multiple corresponds to the number of the frame in the sequence. This is not to be confused with presentation time, a mainly software construct.

This portion of the test suite continues to run providing test images used by the TSA in performing the TVOUTFN2 and TVOUTIMG tests described here. The test requests the operator to confirm that they have launched the TVOUTFN2 test on the TSA. It then displays the first portion of the test images used in the TVOUTFN2 testing. These test images are displayed multiple times to insure that the TSA has an opportunity to analyze each.

When this is complete, the test pauses to request the operator to confirm that the DUT flicker filter is set to its ON position. The operator should at this point enable the flicker filter. When the operator confirms this, the test displays the first set of flicker filter test imagery. The TSA acquires this imagery and analyzes it. The test then pauses to request the operator to confirm that the DUT flicker filter is set to its OFF position. The operator should at this point disable the flicker filter. When the operator confirms this, the test displays the second set of flicker filter test imagery. The TSA again acquires the imagery and analyzes it. The DUT then generates the field rate test imagery, completing the set of images used by the TSA in running the TVOUTFN2 test. The TVOUTFN2 test terminates on the TSA, and the test then asks the operator on the DUT to confirm that the TSA is running the TVOUTIMG test. When the operator confirms this, the test displays the test images used in the TVOUTIMG testing. These test images are displayed multiple times to insure that the TSA has an opportunity to analyze each. After this, the test exit’s and TVOUT hardware testing is complete.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test configuration setup is described in the Test Methodology section. The test requires approximately three minutes to complete.

Results Interpretation

Each pass or fail condition is described in the test description under each test assertion. In addition to passing and failing, the test may provide advisory information under the heading of ‘warning’ or ‘info’. This status does not affect the pass or fail result. In cases where the test is able to determine that a simple configuration error has occurred, an informative message indicating how to correct the error is shown. In the case of the bus and buffer speed testing, high detail logging level selection causes the measured speed to be recorded in the log. When the bus or buffer speed approaches twice the required speed, the accuracy of the measurement is limited by the granularity of timing available. In this case, the measurement may be +/- 10% of the actual speed. Higher precision time base usage would require using different methods on different families of processors.


TD-15.3 TV Output Hardware Function #2 Test (TVOUTFNC2)

Overview

The TV Output Hardware Function #2 test assesses the ability of the hardware, as viewed from the destination, to provide basic functionality in support of the capability. These metrics relate to the ability to produce images in a timely manner, adhering correctly to the signaling standard, so that the hardware is capable of inter-operating with other devices adhering to the same standards.

A pass for each assertion is required to pass the test. The test may not complete successfully if the TVOUTCFG test is not passed. The test can in some cases execute even if the TVOUTCFG test is not passed and can produce useful information.

Each assertion is described in the numbered paragraphs below. The method used to test the assertion and the criteria for passing the assertion test is described.

1. The hardware provides base-band ITU Region-M video output.

The test configures the TSA input, and attempts to acquire the signal from the DUT. If the test is able to configure the input and acquire the signal from the DUT, the test passes, otherwise it fails. The test first attempts to use the Y/C input if present. It will use the composite input if it is unable to acquire the signal from the DUT on the YC input, or there is no Y/C input. The test attempts to use NTSC color decoding for each input to acquire the signal from the DUT. It will use PAL color decoding if it is unable to acquire the signal from the DUT using NTSC. The test terminates on a failure.

2. The hardware provides support for multiple YUY2 source image resolutions.

For this assertion, the test assesses basic characteristics of images produced by the DUT using multiple different source image resolutions. If the resulting images produced are not grossly in error the test passes, otherwise it fails. The source resolutions assessed are widths of 720, 704, 360, and 352 with height of 480, and widths of 360 and 352 with height of 240. This test assesses the effect of using the support indicated to be present in TVOUTCFG assertion six. Examples of gross errors that cause this test to fail are a solution that produces a half screen of output given a half resolution input; solution which produces a border around the image whether black in color or otherwise, a solution which exhibits an incorrect magnification ratio placing image features in incorrect locations, and a solution that provides an image with the U and V components swapped. In cases where the cause of a failure can be determined by the test, the test provides informational messages describing the cause. Detailed consideration of test images is handled by the TD-15.4 TV Output Hardware Quality Test (TVOUTIMG).

3. The hardware provides support for a controllable effective flicker filter.

For this assertion, the test assesses the ability of the hardware to provide flicker filtration and to control its application. The DUT produces a series of test images. The first set of images requires the flicker filter to be engaged. The second set of images requires the flicker filter to be disengaged. The imagery is single horizontal line features for the former. For the latter, several image sets are used including, a cut from a first field with red chrominance to a second field with blue chrominance and a pair of fields that contain luminance features which appear in only one of the fields. The TSA determines whether the images requiring the flicker filter are being displayed correctly with the flicker filter engaged and whether the images not requiring the flicker filter are being displayed correctly with the flicker filter disengaged. If both of these conditions are true, the test passes, otherwise it fails. An example of a situation that fails would be a solution that produced purple images from the red and blue cut.

4. Frame rate is within 0.4% of expected during the period of test.

For this assertion, the test assesses the average frame rate observed at the TSA. The average frame rate during the period of the test must be not vary from the expected frame rate by more than 0.4%. If the frame rate varies from the expected by less than or equal to 0.4% the test will pass, otherwise it will fail. This frame rate tolerance is derived from the use of a TSA, which passes the Video Input Test Suite and uses a tolerance of 0.2%. We would like to specify that the TV Output frame encoding rate is within 0.2% of nominal. Since the direction of the errors could be opposite, the test tolerance is set at 0.4%.

5. The hardware provides correct field presentation rate.

For this assertion, the test assesses the ability of the hardware to provide all fields of the source imagery without dropping or repeating fields. The DUT provides a coded field sequence providing the TSA the ability to assess missing or duplicated fields. If the hardware is able to provide all of the source imagery fields in the correct order the test passes, otherwise it fails.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test configuration setup is described in the Test Methodology section. The test requires approximately a minute to complete.

Results Interpretation

Each pass or fail condition is described in the test description under each test assertion. In addition to passing and failing, the test may provide advisory information under the heading of ‘warning’ or ‘info’. This status does not affect the pass or fail result. In cases where the test is able to determine that a simple configuration error has occurred, an informative message indicating how to correct the error is shown. It is possible for a solution to provide a flicker filter that cannot be controlled. Such a filter could be stuck in the on position. In this case, the TV Output would be unable to correctly reproduce shot on video content. It would also reduce the vertical resolution of progressive content. The test therefore requires that the filter be able to be turned off. Again, a flicker filter implementation could be stuck at off, or equivalently, be ineffective. This would cause annoying flicker to be present when graphics are overlaid on the video without regard to blending. The test therefore requires that the flicker filter be effective.

It is possible for a solution to pass the TVOUTFN2 test without any indication of a picture geometry problem. The detailed consideration of over-can, under-can, and other aspects of picture geometry are made in the TVOUTIMG test.


TD-15.4 TV Output Hardware Quality Test (TVOUTIMG)

Overview

The TV Output Hardware Quality test assesses the ability of the hardware, as viewed from the destination, to provide quality images from quality source image data. This test runs on the TSA. This test focuses on assuring interoperability as it relates to intra-image quality, while TVOUTFNC (#1 and #2) focus on interoperability mainly from an inter-image timing perspective. The test implements operational definitions of Video SNR, Chroma Phase, Luma Bandwidth, Chroma Bandwidth, Luma Linearity, Chroma Linearity, Luma Gain, and Chroma Gain video signal integrity measurements. The test does not implement a differential gain test, as that is inferable from passing of the tests of independent gain. Testing is provided for each of several resolution source images in order to insure that the hardware provides support for multiple images resolutions. Each of the video quality metrics is applied to each of the source resolutions. Each source resolution is coded in the test imagery, and is detected by the TSA.

A pass for each assertion is required to obtain a pass for the test. The test may not complete successfully if the TVOUTCFG test is not passed. The test can in some cases execute and produce useful information even if the TVOUTCFG test is not passed.

The test uses ITU-R BT.601 (Rec. 601) level video, with values identical to SDI (8 bits) in providing source imagery to the TV Output solution. Of potential interest to hardware designers, the values used for each of the devices in the SMPTE bars pattern are provided here. These are considered normative values, which encoding hardware is expected to use in producing the canonical analog waveforms. Metrics are provided here in IRE units for correlation between the correct encoding and the encoding by the device under test. These metrics compute the MLD between a portion of the DUT signal and the reference.

It is expected that the hardware is properly localized as to setup and other analog issues, and no attempt is made by the test software to specifically assess these items. The edge rates of the devices within the SMPTE bars pattern are reduced by convolution with a five tap Hamming window kernel. The values used in the convolution are approximations of 0.08/0.54/1.0/0.54/0.08 which are chosen to facilitate processing.

This convolution is performed across the entire image, although it is of no effect other than at edges, since the images are synthetic and noise free. The initial position of the kernel is chosen with the center at the left most active pixel with the left two taps set to 7.5 IRE to simulate rise from blanking. The final position of the kernel performs the same ‘zero’ fill operation on the right edge, simulating return to blanking. The reference digitization of the SMPTE bars pattern is that obtained by digitizing the output of a traceably calibrated Tektronix TSG-95. Each different source resolution of the SMPTE bars pattern is produced synthetically without use of a resizing operation. No resizing operation is performed by the TSA software. The TSA always uses full resolution data. The locale for the non-full resolution devices are computed from the local for the full resolution devices, rounded to the nearest pixel. As in the other cases, the images are synthesized at full edge rates, and convolved to reduce the edge rates.

The SMPTE bars pattern is used for portions of the luma and chroma level assertion tests. Other simpler test patterns are used for these and for simpler assertion tests.

The horizontal resolution specification is in TV lines. The test images for this use the same Hamming filter as above to reduce edge rates. This constrains the source resolution from the 540 (pixels in raster height), which may appear to be available absent edge rate constraints to somewhat greater than 360 TV lines. This is well in excess of the spec requirements, and is not a practical limitation in the test.

Table 15-1. Normative Y’ Cb Cr Values for SMPTE Bars

 | Y’ | Cb | Cr
Grey | 176 | 128 | 128
Yellow | 162 | 44 | 141
Cyan | 131 | 156 | 44
Green | 112 | 72 | 58
Magenta | 84 | 184 | 198
Red | 65 | 100 | 212
Blue | 35 | 212 | 114
-I | 16 | 158 | 95
Y | 235 | 128 | 128
Q | 16 | 175 | 149
Blk | 16 | 128 | 128
BTB | 8 | 128 | 128
AB | 24 | 128 | 128

Each assertion is described in the numbered paragraphs below. The method used to test the assertion and the criteria for passing the assertion test is described.

1. The image is presented in a top down order.

For this assertion, the test assesses whether the image produced by the hardware is presented right side up, or without up-down inversion. If the image is presented upside down the test fails, otherwise it passes. If the test fails, the test terminates.

2. The image is presented without field inversion.

For this assertion, the test assesses whether the image produced by the hardware is presented with the first field first, and second field second, within any two field window starting with a top field. If the image is presented with the fields in the correct order the test passes, otherwise it fails. If the test fails, the test terminates.

3. The image is presented without mirror inversion.

For this assertion, the test assesses whether the image produced by the hardware is presented with mirror, or left/right inversion. If the image is presented without mirror image inversion, the test passes, otherwise it fails. If the test fails, the test terminates.

4. The image generated from full resolution source has correct luminance detail.

For this assertion, the test assesses characteristics of the image related to luminance frequency response and fidelity. Various sized and oriented features are used. If the hardware exhibits insufficient frequency response or fidelity the test fails, otherwise it passes. The frequency response required to pass the test is 300 TV lines.

5. The image generated from the full resolution source has correct chrominance detail.

For this assertion, the test assesses the characteristics of the image related to chrominance frequency response. If the hardware exhibits insufficient frequency response the test fails, otherwise it passes. The frequency response required to pass the test is 150 TV lines.

6. The image generated from the non-full resolution source has correct luminance detail.

For this assertion, the test assesses characteristics of the image related to luminance frequency response and fidelity. Various sized and oriented features are used. If the hardware exhibits insufficient frequency response or fidelity the test fails, otherwise it passes. The frequency response required to pass the test is 100 TV lines.

7. The image generated from the non-full resolution source has correct chrominance detail.

For this assertion, the test assesses the characteristics of the image related to chrominance frequency response. If the hardware exhibits insufficient frequency response the test fails, otherwise it passes. The frequency response required to pass the test is 50 TV lines.

8. The image generated from the full resolution source has correct luma levels.

For this assertion, the test assesses the ability of the hardware to produce images with correct luma levels. The test assesses the luma noise level, luma gain, and linearity. The test uses various test patterns to assess this. If the hardware is able to represent the luma levels correctly the test passes, otherwise the test fails. Large area average level measurements are used. The minimum area subject to this test is a 64 pixel 8x8 area. The measurement must match the reference levels within +/-3 IRE for all SMPTE bars devices except –I, and Q for the test to pass. The –I and Q devices must be reproduced within +/-6 IRE.

9. The image generated from the full resolution source has correct chrominance levels.

For this assertion, the test assesses the fidelity of the color encoding, the chrominance noise level, and the presence or absence of false chrominance sometimes produced by high luminance detail. If the hardware provides correct colors and no color in the absence of color in the source image, the test passes, otherwise it fails. The test indicates in the case of a failure which of the possible defects are present. Large area average level measurements are used. The minimum area subject to this test is a 64 pixel 8x8 area. The measurement must match the reference levels within +/-3 IRE for all SMPTE bars devices.

10. The image generated from the non-full resolution source has correct luminance levels.

For this assertion, the test assesses the ability of the hardware to produce images with correct luma levels. The test assesses the luma noise level, luma gain, and linearity. The test uses various test patterns to assess this. If the hardware is able to represent the luma levels correctly the test passes, otherwise the test fails. Large area average level measurements are used. The minimum area subject to this test is a 64 pixel 8x8 area. The measurement must match the reference levels within +/-3 IRE for all SMPTE bars devices except –I, and Q for the test to pass. The –I and Q devices must be reproduced within +/- 6 IRE.

11. The image generated from the non-full resolution source has correct chrominance levels.

For this assertion, the test assesses the fidelity of the color encoding, the chrominance noise level, and the presence or absence of false chrominance sometimes produced by high luminance detail. If the hardware provides correct colors and no color in the absence of color in the source image the test passes, otherwise it fails.

The test indicates in the case of a failure, which of the possible defects are present. Large area average level measurements are used. The minimum area subject to this test is a 64 pixel 8x8 area. The measurement must match the reference levels within +/- 3 IRE for all SMPTE bars devices.

12. The image generated from full resolution source has correct image dimensions.

For this assertion, the test determines the ability of the hardware to produce images that have no removed or added image information at the edges, and does not have distorted intra-image dimensions. If the image dimensions are found to be correct the test passes, otherwise it fails. A solution that produces images with offsets of more than two pixels from the expected locations fail.

13. The image generated from the non-full resolution source has correct image dimensions.

For this assertion, the test determines the ability of the hardware to produce images that have no removed or added image information at the edges, and does not have distorted intra-image dimensions. If the image dimensions are found to be correct the test passes, otherwise it fails.

A solution that produces images with offsets of more than ten pixels from the expected locations fail. This test provides a very wide margin of error due to the uncertainty introduced by scaling of the image, both at the source and at the destination.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test configuration setup is described in the Test Methodology section. The test requires approximately a minute to complete.

Results Interpretation

Each pass or fail condition is described in the test description under each test assertion. In addition to passing and failing, the test may provide advisory information under the heading of ‘warning’ or ‘info’. This status does not affect the pass or fail result. In cases where the test is able to determine that a simple configuration error has occurred, an informative message indicating how to correct the error is shown. The test may fail due to problems associated only with non-full resolution source imagery. Such a problem could be due to scaling hardware. The test allows for some uncertainty, both in the filter outputs precision, and in the location of the output samples due to scaling. The test provides indication of the source resolutions that do not meet the criteria for passing the test.


TD-15.5 TV Image Positioning Test

Overview

This test is a manual test and requires user interaction. The intent of the test is to ensure that an image within a TV signal can be moved horizontally and vertically into NTSC safe region area. Figure 15.1 explains how the 720x480 resolution of a TV is partitioned into safe and overscan regions.

Figure 15.1 Consumer televisions display the content within the NTSC safe region

Content within the overscan area is often distorted in its shape and appearance and thus not suitable for viewing. As a safeguard, television source images often occupy an area larger than 640x440. An important note is that the top-left corner of the windows desktop will often map to the top left corner of the NTSC of the 720x480 area, which is outside of the NTSC safe region.

This test works by placing image content in the areas that would map to areas in the overscan area. This can be done by initializing the desktop to a resolution of 800x600 and putting image content at pixel columns 0 and 720 and then verifying that the positioning solution can make that content visible on the television. To test vertical positioning, initializing the desktop to a resolution of 640x480 and ensuring that image content at pixel rows 0 and 480 can be seen by using the positioning software.

In either case, a solution that applies a translation-transformation to the desktop such that image content actually moves on the monitor is unacceptable. Positioning the TV-out image should not cause any shift in the position of the desktop displayed on the monitor.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The software solution provided with the TV-out capable hardware can implement their software solution in any number of ways. One possible method is to integrate the image translation controls into the display properties in the control panel. The other scheme is to create a separate applet or utility that is accessible through the tray in the windows taskbar or as an application available from the start menu.

Results Interpretation

The test is operator dependent. If the operator can use the provided software so that content that would normally appear in the overscan areas can be displayed in NTSC safe areas by positioning, then the test passes. The one thing that the solution cannot do is translate the actual desktop displayed on the monitor.


TD-15.6 1024x768 Resolution TV-Out Conversion Test

Overview

This test is an operator dependent test.

Setup

The operator must first initialize the desktop to 1024x768. The operator can then connect a television to the TV-out port using an industry standard cable.

Results Interpretation

If the desktop properly appears, then the test passes.


Chapter 16: Audio Test Specification

The audio test specification defines attributes of audio hardware and drivers that are key to providing a rich audio experience on the PC. Modern applications of audio technology on the PC, such as teleconferencing, gaming, media streaming and music production require that the audio subsystem, including audio hardware and drivers, possess the following qualities:

  • Low system overhead – This requires that data copying and user-to-kernel mode transitions be minimized, and that the hardware is implemented on a high bandwidth (non-ISA) data bus.
  • Low latency – This requires that the driver stack services requests and transitions between states in a timely manner.
  • Full-duplex operation – This requires that the hardware and drivers impose no constraints on the available rendering and capturing formats at any time.
  • Hi-fidelity audio reproduction – This requires proper hardware design and glitch-free driver operation.
  • Robustness – This requires that the hardware and driver be fault-tolerant, and handle responses correctly to power management and Plug and Play events.

These tests qualify underlying hardware and driver support of requirements specified in chapter 17 of the PC 99 System Design Guide.

Test Coverage

The audio tests qualify support of requirements by testing the following:

  • Microsoft DirectSound drivers.
  • Mixer, Wave, and MIDI drivers.
  • Basic data rates and full-duplex operation at independent sampling rates.
  • Support for WDM Driver model, including support for kernel streaming and topology.
  • Audio quality – such as frequency response, dynamic range, THD+N, and cross-talk.

Test Methodology

The audio device tests are designed to run on all x86 processor based platforms. The tests require a PC or laptop with audio hardware that includes speakers and a microphone. The tests also require the Microsoft Windows 98/Me, Windows 2000, or Windows XP operating system and the WDM audio driver be installed.

For audio quality testing, two systems connected to a network are required. The AudioLab COM Component should be installed on both machines. This component supplies different services like sound analyzing and playing or setting the mixer. The user who executes the tests, should be logged on and have administrative access to the remote machine, in order to instantiate the COM Components.

AudioLab.DLL is an InProcess COM component that can also be used as a DCOM object on the remote machine (via DLLHOST.EXE).

The different test applications like LULLABYST.EXE or PCAUDREQST.EXE use the AudioLab COM component locally or remotely depending on the test cases selected.

The remote machine is configured using the SelfTest Wizard (STWIZARD.EXE) application. The SelfTest Wizard checks if the remote machine is accessible and asks about the audio configuration on the computer under test. These settings are saved in the registry, and are used by the test applications to connect to the services on the remote machine. The Selftest Wizard can also be launched within the test applications under the Options.Selftest Wizard menu item.

Before running each test case the correct audio cable configuration is checked. If the cable check fails, the user is notified. An example cable warning message is "Local Machine LineIn – Remote Machine LineOut". Having seen this message, you should check the cable connection.

Below are some useful hints about mixerline settings.

  • AudioLab changes volume levels.
  • AudioLab mutes all the lines except the one under test.
  • AudioLab selects the input line depending on your sound card jack settings that are set manually by the SelfTest Wizard at the beginning of the test. LineIn is the first selection. If it does not exist, Microphone is used for cable connection.


Audio Test Assertions

This section includes the following assertions derived for audio devices and drivers. Each assertion listed includes an assertion description, a list of reference documents, and a reference to the "Test Description" section that explains the test suite.

Table 16-1 lists all audio test assertion numbers, corresponding requirements, and the tests that provide coverage.

Note: The following highlighted text indicates a new test.

Table 16-1. Audio Test Assertions

Assertion Numbers | Requirements | Test Coverage Section and Test Name
16.1.1 – 16.1.2 |  | 16.9 Digital Rights management Test (DrmTest)
16.1.3 | N/A | N/A
16.1.4 – 16.1.6 |  | 16.9 Digital Rights management Test (DrmTest)
16.1.7 – 16.1.19 | N/A | N/A
16.1.20 – 16.1.32 |  | 16.9 Digital Rights management Test (DrmTest)
16.1.33 – 16.1.49 | N/A | N/A
16.1.50 – 16.1.53 |  | 16.9 Digital Rights management Test (DrmTest)
16.1.54 – 16.1.59 | N/A | N/A
16.1.60 – 16.1.61 |  | 16.9 Digital Rights management Test (DrmTest)
16.2.0 – 16.3.x | N/A | N/A
16.4.1 – 16.4.4 | AUD-0337, AUD-0327; PC 99 - 17.31, 17.32 | 16.1 DirectSound Driver Test (DsDrvTst)
16.4.5 | AUD-0324, AUD-0337, AUD-0327; PC 99 - 17.5, 17.31, 17.32 | 16.1 DirectSound Driver Test (DsDrvTst)
16.4.6 | AUD-0337, AUD-0327; PC 99 - 17.31, 17.32 | 16.1 DirectSound Driver Test (DsDrvTst)
16.4.7 | AUD-0326, AUD-0337, AUD-0327; PC 99 - 17.8, 17.31, 17.32 | 16.1 DirectSound Driver Test (DsDrvTst)
16.4.8 – 16.4.29 | AUD-0337, AUD-0327; PC 99 - 17.31, 17.32 | 16.1 DirectSound Driver Test (DsDrvTst)
16.4.30 – 16.4.32 | N/A | N/A
16.4.33 – 16.4.40 | AUD-0337, 17.31, 17.32 | 16.1 DirectSound Driver Test (DsDrvTst)
16.5.x – 16.7.1 | N/A | N/A
16.7.1 – 16.7.2 | SYS-0003.4, AUD-0336; PC 99 -17.28, 17.29 | 16.2 Audio Power Management Test (Lullaby)
16.7.3 | N/A | N/A
16.7.4 – 16.7.8 | SYS-0003.4, AUD-0336; PC 99 -17.28, 17.29 | 16.2 Audio Power Management Test (Lullaby)
16.7.9 | N/A | N/A
16.7.10 – 16.7.12 | SYS-0003.4, AUD-0336, 17.28, 17.29 | 16.2 Audio Power Management Test (Lullaby)
16.7.13 – 16.7.39 | N/A | N/A
16.7.40 – 16.7.51 | SYS-0003.4, AUD-0336, 17.28, 17.29 | 16.2 Audio Power Management Test (Lullaby)
16.8.1 – 16.8.3 | AUD-0337, 17.31, 17.32 | 16.3 Mixer Driver Test (MixDrv32)
16.8.4 | N/A | N/A
16.8.5 – 16.8.22 | AUD-0337, 17.31, 17.32 | 16.3 Mixer Driver Test (MixDrv32)
16.8.23 – 16.8.24 | N/A | N/A
16.8.25 – 16.8.30 | AUD-0337, 17.31, 17.32 | 16.3 Mixer Driver Test (MixDrv32)
16.8.31 – 16.8.32 | N/A | N/A
16.8.33 – 16.8.48 | AUD-0337, 17.31, 17.32 | 16.3 Mixer Driver Test (MixDrv32)
16.9.1 – 16.9.2 | AUD-0337, AUD-0324; 17.5.2, 17.31, 17.32 | 16.4 Wave Driver Test (WavDrv32)
16.9.3 – 16.9.34 | AUD-0337, 17.31, 17.32 | 16.4 Wave Driver Test (WavDrv32)
16.9.35 – 16.9.36 | AUD-0326, AUD-0337, 17.8, 17.31, 17.32 | 16.4 Wave Driver Test (WavDrv32)
16.9.37 – 16.9.38 | AUD-0337, 17.31, 17.32 | 16.4 Wave Driver Test (WavDrv32)
16.9.39 – 16.9.40 | AUD-0326, AUD-0337, 17.8, 17.31, 17.32 | 16.4 Wave Driver Test (WavDrv32)
16.9.41 – 16.9.42 | AUD-0337, 17.31, 17.32 | 16.4 Wave Driver Test (WavDrv32)
16.10.1 – 16.10.37 | AUD-0337, 17.31, 17.32 | 16.5 MIDI Driver Test (MidDrv32)
16.10.38 – 16.10.46 | N/A | N/A
16.10.47 | AUD-0337, 17.31, 17.32 | 16.5 MIDI Driver Test (MidDrv32)
16.11.x – 16.14.x | N/A | N/A
16.15.1 – 16.15.800 | N/A | N/A
16.15.801 – 16.15.804 | AUD-0324, AUD-0337, 17.5, 17.31, 17.32 | 16.6 Full Duplex Test (FDuplex)
16.15.806 – 16.15.808 | N/A | N/A
16.15.809 | AUD-0324, AUD-0337, 17.5, 17.31, 17.32 | 16.6 Full Duplex Test (FDuplex)
16.15.810 | N/A | N/A
16.15.811 – 16.15.814 | AUD-0324, AUD-0337, 17.5, 17.31, 17.3217.5, 17.31, 17.32 | 16.6 Full Duplex Test (FDuplex)
16.15.815 – 16.15.818 | N/A | N/A
16.15.819 | AUD-0324, AUD-0337, 17.5, 17.31, 17.32 | 16.6 Full Duplex Test (FDuplex)
16.15.820 – 16.15.822 | N/A | N/A
16.15.823 | AUD-0324, AUD-0337, 17.5, 17.31, 17.32 | 16.6 Full Duplex Test (FDuplex)
16.15.824 – 16.15.828 | N/A | N/A
16.15.829 | AUD-0324, AUD-0337, 17.5, 17.31, 17.32 | 16.6 Full Duplex Test (FDuplex)
16.15.830 – 16.15.832 | N/A | N/A
16.15.833 | AUD-0324, AUD-0337, 17.5, 17.31, 17.32 | 16.6 Full Duplex Test (FDuplex)
16.15.834 – 16.15.838 | N/A | N/A
16.15.839 | AUD-0324, AUD-0337, 17.5, 17.31, 17.32 | 16.6 Full Duplex Test (FDuplex)
16.15.840 – 16.15.842 | N/A | N/A
16.15.843 – 16.15.845 | AUD-0324, AUD-0337, 17.5, 17.31, 17.32 | 16.6 Full Duplex Test (FDuplex)
16.15.846 – 16.15.852 | N/A | N/A
16.15.853 – 16.15.855 | AUD-0324, AUD-0337, 17.5, 17.31, 17.32 | 16.6 Full Duplex Test (FDuplex)
16.15.856 – 16.15.860 | N/A | N/A
16.15.861 – 16.15.864 | AUD-0324, AUD-0337, 17.5, 17.31, 17.32 | 16.6 Full Duplex Test (FDuplex)
16.15.865 – 16.15.870 | N/A | N/A
16.15.871 – 16.15.874 | AUD-0324, AUD-0337, 17.5, 17.31, 17.32 | 16.6 Full Duplex Test (FDuplex)
16.16.x – 16.29.x | N/A | N/A
16.30.1 – 16.30.17 | AUD-0329, 17.4 | 16.7 Audio Quality Test (AudQlty)
16.31.1 | AUD-0337, 17.2, 17.31 | 16.8 Audio Device Test (PC99Aud)
16.31.2 | 17.20 | 16.8 Audio Device Test (PC99Aud)
16.31.3 – 16.31.5 | N/A | N/A
16.31.6 – 16.31.7 | 17.5.1 | 16.8 Audio Device Test (PC99Aud)
16.31.8 – 16.31.9 | 17.5.2 | 16.8 Audio Device Test (PC99Aud)
16.31.10 – 16.31.13 | AUD-0324, 17.5, 17.32 | 16.8 Audio Device Test (PC99Aud)
16.31.14 – 16.31.15 | AUD-0324, AUD-0325, 17.5, 17.6 | 16.8 Audio Device Test (PC99Aud)
16.31.16 – 16.31.28 | N/A | N/A
16.31.29 – 16.31.30 | AUD-0324, 17.5, 17.32 | 16.8 Audio Device Test (PC99Aud)
16.32.1 – 16.32.8 |  | 16.10 KS Audio Position Accuracy Test (KsPosTst)
16.33.1 – 16.33.26 |  | 16.11 KS DirectMusic Filter Test (KSDMTst.exe)
16.34.1 – 16.34. |  | 16.12 DirectMusic Driver Test (DMDrv.exe)
16.35.1 – 16.35. |  | 16.13 AC-3 Driver Test (AC3Test.exe)


Reference Document Sources for Audio Assertions

Hardware and BIOS functional requirements specified in the following documents:

  • PC 2001 System Design Guide and PC 99 System Design Guide,
    http://www.microsoft.com/hwdev/platform/pcdesign/desguide/pcguides.asp
  • Microsoft Windows Driver Development Kit
    http://www.microsoft.com/ddk/
    See "WDM Audio Driver Design Guide," "Audio Miniport Drivers," and "DirectMusic Synths and Synth Sinks" in the Windows XP DDK
  • Microsoft Windows Logo Program System and Device Requirements, Version 2.0
    http://www.microsoft.com/hwdev/winlogo/
    (listed as "WLP#" in these assertions)


Audio Digital Rights Management Test Assertions

The Digital Rights Management Test (DrmTest) tests if the audio driver protects content as described in DRM Design Guide.

Digital Rights Assertions

These assertions are tested in TD-16.9 Audio Digital Rights Managements Test (DrmTest).

16.1.1 Audio miniport must implement IDrmAudioStream interface in its stream objects.

Reference document: WLP# B.1.4.11; "Digital Rights Management Reference" in the Windows DDK
Test description: TD-16.9 Audio Digital Rights Managements Test (DrmTest)

16.1.2 Audio miniport stream object must return IDrmAudioStream interface if queried for IID_IDrmAudioStream.

Reference document: WLP# B.1.4.11; "Digital Rights Management Reference" in the Windows DDK
Test description: TD-16.9 Audio Digital Rights Managements Test (DrmTest)

16.1.3 This test assertion is undefined.
16.1.4 The audio driver must never attach a non-DRM certified driver to its stack.

Reference document: WLP# B.1.4.11; "Digital Rights Management Reference" in the Windows DDK
Test description: TD-16.9 Audio Digital Rights Managements Test (DrmTest)

16.1.5 The audio driver must be signed with DRM-compliant signature.

Note that this test case will fail, unless the driver is signed.

Reference document: WLP# B.1.4.11; "Digital Rights Management Reference" in the Windows DDK
Test description: TD-16.9 Audio Digital Rights Managements Test (DrmTest)

16.1.6 The audio driver must be signed with DRM compliant signature and the MinDrmLevel bit in the catalog file should be set properly.

Note that this test case will fail, unless the driver is signed.

Reference document: WLP# B.1.4.11; "Digital Rights Management Reference" in the Windows DDK
Test description: TD-16.9 Audio Digital Rights Managements Test (DrmTest)

16.1.20 Waveout capture should be muted if DRMRIGHTS.CopyProtect=TRUE.

Reference document: WLP# B.1.4.11; "Digital Rights Management Reference" in the Windows DDK
Test description: TD-16.9 Audio Digital Rights Managements Test (DrmTest)

16.1.21 Waveout Capture must not be muted if DRMRIGHTS.CopyProtect=FALSE.

Reference document: WLP# B.1.4.11; "Digital Rights Management Reference" in the Windows DDK
Test description: TD-16.9 Audio Digital Rights Managements Test (DrmTest)

16.1.22 Waveout Capture must be enabled after the DRM buffer is destroyed.

Reference document: WLP# B.1.4.11; "Digital Rights Management Reference" in the Windows DDK
Test description: TD-16.9 Audio Digital Rights Managements Test (DrmTest)

16.1.23 Waveout Capture must remain muted, even if the mixer settings are changed.

Reference document: WLP# B.1.4.11; "Digital Rights Management Reference" in the Windows DDK
Test description: TD-16.9 Audio Digital Rights Managements Test (DrmTest)

16.1.24 When playing two streams with PCM and DRM formats, if PCM stream is created first, waveout capture must be muted if DRMRIGHTS.CopyProtect=TRUE. (PCM, DRM, DRM, PCM)

Reference document: WLP# B.1.4.11; "Digital Rights Management Reference" in the Windows DDK
Test description: TD-16.9 Audio Digital Rights Managements Test (DrmTest)

16.1.25 When playing two streams with PCM and DRM formats, if PCM stream is created first, waveout capture must be muted if DRMRIGHTS.CopyProtect=TRUE. (PCM, DRM, PCM, DRM)

Reference document: WLP# B.1.4.11; "Digital Rights Management Reference" in the Windows DDK
Test description: TD-16.9 Audio Digital Rights Managements Test (DrmTest)

16.1.26 When playing two streams with PCM and DRM formats, if DRM stream is created first, waveout capture must be muted if DRMRIGHTS.CopyProtect=TRUE. (DRM, PCM, DRM, PCM)

Reference document: WLP# B.1.4.11; "Digital Rights Management Reference" in the Windows DDK
Test description: TD-16.9 Audio Digital Rights Managements Test (DrmTest)

16.1.27 When playing two streams with PCM and DRM formats, if DRM stream is created first, waveout capture must be muted if DRMRIGHTS.CopyProtect=TRUE. (DRM, PCM, PCM, DRM)

Reference document: WLP# B.1.4.11; "Digital Rights Management Reference" in the Windows DDK
Test description: TD-16.9 Audio Digital Rights Managements Test (DrmTest)

16.1.28 When playing two streams with DRM and DRM formats, waveout capture must be muted if at least one of the DRMRIGHTS.CopyProtect is set to TRUE. (DRMT, DRM, DRM, DRMT)

Reference document: WLP# B.1.4.11; "Digital Rights Management Reference" in the Windows DDK
Test description: TD-16.9 Audio Digital Rights Managements Test (DrmTest)

16.1.29 When playing two streams with DRM and DRM formats, waveout capture must be muted if at least one of the DRMRIGHTS.CopyProtect is set to TRUE. (DRMT, DRM, DRMT, DRM)

Reference document: WLP# B.1.4.11; "Digital Rights Management Reference" in the Windows DDK
Test description: TD-16.9 Audio Digital Rights Managements Test (DrmTest)

16.1.30 When playing two streams with DRM and DRM formats, waveout capture must be muted if at least one of the DRMRIGHTS.CopyProtect is set to TRUE. (DRM, DRMT, DRMT, DRM)

Reference document: WLP# B.1.4.11; "Digital Rights Management Reference" in the Windows DDK
Test description: TD-16.9 Audio Digital Rights Managements Test (DrmTest)

16.1.31 When playing two streams with DRM and DRM formats, waveout capture must be muted if at least one of the DRMRIGHTS.CopyProtect is set to TRUE. (DRM, DRMT, DRM, DRMT)

Reference document: WLP# B.1.4.11; "Digital Rights Management Reference" in the Windows DDK
Test description: TD-16.9 Audio Digital Rights Managements Test (DrmTest)

16.1.32 WaveOut must remain muted if capture is restarted.

Reference document: WLP# B.1.4.11; "Digital Rights Management Reference" in the Windows DDK
Test description: TD-16.9 Audio Digital Rights Managements Test (DrmTest)

16.1.50 S/PDIF output must be muted if DRMRIGHTS.DigitalOutputDisable=TRUE.

Reference document: WLP# B.1.4.11; "Digital Rights Management Reference" in the Windows DDK
Test description: TD-16.9 Audio Digital Rights Managements Test (DrmTest)

16.1.51 S/PDIF output must not be muted if DRMRIGHTS.DigitalOutputDisable=FALSE.

Reference document: WLP# B.1.4.11; "Digital Rights Management Reference" in the Windows DDK
Test description: TD-16.9 Audio Digital Rights Managements Test (DrmTest)

16.1.52 S/PDIF output must be enabled after the DRM buffer is destroyed.

Reference document: WLP# B.1.4.11; "Digital Rights Management Reference" in the Windows DDK
Test description: TD-16.9 Audio Digital Rights Managements Test (DrmTest)

16.1.53 S/PDIF output must remain muted, even if the mixer settings are changed.

Reference document: WLP# B.1.4.11; "Digital Rights Management Reference" in the Windows DDK
Test description: TD-16.9 Audio Digital Rights Managements Test (DrmTest)

16.1.60 S/PDIF output must be muted if DRMRIGHTS.DigitalOutputDisable=TRUE.

Reference document: WLP# B.1.4.11; "Digital Rights Management Reference" in the Windows DDK
Test description: TD-16.9 Audio Digital Rights Managements Test (DrmTest)

16.1.61 S/PDIF output must be muted if DRMRIGHTS.DigitalOutputDisable=FALSE.

Reference document: WLP# B.1.4.11; "Digital Rights Management Reference" in the Windows DDK
Test description: TD-16.9 Audio Digital Rights Managements Test (DrmTest)


Audio DirectSound Test Assertions

The DirectSound test assertions are tested in the DirectSound Driver test.

Note: Test Assertions 16.2.x through 16.3.x are undefined.

The assertions in this section are tested in TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.1 If the driver is signed, this test case would pass, otherwise, it would fail.

On Windows Millennium Edition (Windows Me), all drivers will pass this test.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.2 Driver must be able to mix multiple buffers which have same wave data(22k16bmo) and are created from one single dsound object.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.3 Driver must be able to mix multiple buffers which have same wave data(22k16bmo).

Each of these buffers is created from a different dsound object.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.4 Driver must be able to play a buffer multiple times and stop a buffer multiple times in a roll.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.5 Driver must be able to mix multiple buffers which have same wave data(random wave format) and are created from one single dsound object.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.6 Driver must be able to mix multiple buffers which have same wave data(random wave format).

Each of these buffers is created from a different dsound object.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.7 Driver must be able to mix multiple buffers which have different wave data(random wave format) and are created from one single dsound object.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.8 Driver must be able to mix multiple buffers which have different wave data(random wave format).

Each of these buffers is created from a different dsound object.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.9 Driver must support IDirectSoundBuffer::Stop/SetCurrentPosition/GetStatus/Play APIs.

User should be able to Stop() when playing, SetCurrentPosition() to a random position in the buffer, play from that point, check playing status by calling GetStatus no matter whether the buffer is playing or not. This test is testing 22k16bmo wave data.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.10 The DirectSound device must support the IDirectSoundBuffer::Play API.

The driver must be able to change state from PAUSE to RUN and succeed a writestream request. Play call must succeed whether the buffer is playing or not, no matter whether the buffer is looping or not. If Play is called on a playing buffer, nothing additional needs to be performed. Otherwise, driver needs to receive data and play it on the audio device. This test is testing 22k16bmo wave data.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.11 The DirectSound device must support the IDirectSoundBuffer::Play API on a primary buffer.

DirectSound device should accurately report play cursor positions, app should be able to streaming data based on this information. Lock/Unlock() should succeed on a primary buffer no matter it is playing or not. This test is testing 22k16bmo wave data.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.12 The DirectSound device must support the IDirectSoundBuffer::Play API on a secondary buffer.

DirectSound device should accurately report play cursor positions, app should be able to streaming data based on this information. Lock/Unlock() should succeed on a secondary buffer no matter it is playing or not. This test is testing 22k16bmo wave data.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.13 Release a dsound buffer while it is playing should succeed.

This test is testing 22k16bmo wave data.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.14 Release a dsound object while there is buffer playing should succeed.

This test is testing 22k16bmo wave data.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.15
16.4.15.1 All combinations of wave formats for secondary buffer and primary buffer should succeed.

The test would cycle through all regular wave formats for secondary buffer and for each secondary buffer, when it is playing, test would cycle primary buffer wave formats through all regular wave formats. Test tries` 3D control and different 3D algorithm too.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.15.2 Playing all regular wave formats which driver reported for secondary buffer should succeed.

It is expected that the buffer should naturally stop playing after two seconds given the buffer is a one second buffer.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.16 Same as 16.4.9 except that this test is testing random format wave data.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.17 Same as 16.4.10 except that this test is testing random format wave data.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.18 Same as 16.4.11 except that this test is testing random format wave data.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.19 Same as 16.4.12 except that this test is testing random format wave data.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.20
16.4.20.1 Same as 16.4.13 except that this test is testing random format wave data.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.20.2 Same as 16.4.14 except that this test is testing random format wave data.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.21
16.4.21.1 The DirectSound device must support the IDirectSoundBuffer::SetVolume API.

The volume parameter of this call can be anything in the range of DSBVOLUME_MIN and DSBVOLUME_MAX. Subsequent GetVolume calls must return the same volume as previously set. SetVolume must succeed whether the buffer is playing or not, and whether the buffer is set to loop or not.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.21.2 The DirectSound device must support the IDirectSoundBuffer::SetPan API.

The pan parameter of this call can be anything in the range of DSBPAN_LEFT and DSBPAN_RIGHT. Subsequent GetPan calls must return the same pan value as previously set. SetPan must succeed whether the buffer is playing or not, and whether the buffer is set to loop or not.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.21.3 The DirectSound device must support the IDirectSoundBuffer::SetFrequency API.

The frequency parameter of this call can be anything in the range of driver’s reported capabilities. Subsequent GetFrequency calls must return the frequency value that was previously set. SetFrequency must succeed whether the buffer is playing or not, and whether the buffer is set to loop or not.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.22 – 16.4.34 The DirectSound device must support the IDirectSound::DuplicateSoundBuffer API.

If the DirectSound device supports hardware acceleration, the device must support the corresponding create hardware pin request. Duplicated buffer should be independent from the original copy, i.e. original buffer release etc. should not affect duplicated copies. All regular buffer controls are expected to succeed on duplicated buffers too.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.34.0 – 16.4.34.4 The DirectSound device must support the IDirectSound::GetCaps API.

If the device supports hardware acceleration, the device must accurately report the following capabilities: MaximumChannels, MinimumBitsPerSample, MaximumBitsPerSample, MinimumSampleFrequency, and MaximumSampleFrequency.

For SampleFrequency, it must support all common frequency rates (8k, 11.025k, 22.05k, 44.1k, 16k, 32k, 48k) that falls into MinimumSampleFrequency and MaximumSampleFrequency.

If hardware acceleration is supported, the device must accurately report possible pin instances and export node properties as appropriate. If the driver supports on board memory, it must accurately report FreeHwMemBytes.

If dwFreeHw3D(static|streaming)Buffers are non-zero, it is expected that any format of {x | 8k, 11025, 22050, 44100, 16k, 32k, 48k, MinimumSampleFrequency <= x <= MaximumSampleFrequency } 3-D buffer can be successfully created.

If dwFreeHwMixing(Static|Streaming)Buffers-and dwFreeHw3D(static|streaming)Buffers are non-zero, it is expected that any format of {x | 8k, 11025, 22050, 44100, 16k, 32k, 48k, MinimumSampleFrequency <= x <= MaximumSampleFrequency } 2-D buffer can be successfully created.

The driver must accurately report a free pin number according to their current state—that is, after apps creates several sound buffers, it is expected that dwFreeHwXXX members will decrease.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.35
16.4.35.1 The DirectSound device must support the IDirectSoundBuffer::SetCurrentPosition API.

The position parameter of this call can be anything block-aligned from 0 to buffersize-1. If hardware acceleration is supported, driver must set hardware buffer position as specified and subsequent GetCurrentPosition calls must return the new start position. SetCurrentPosition must succeed whether the buffer is playing or not, and whether the buffer is set to loop or not.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.35.2 – 16.4.35.3 The DirectSound device must support IDirectSoundBuffer::GetCurrentPosition API.

If the device supports hardware acceleration, it must report sample positions within 1 ms of the current position of the buffer being rendered. When the buffer is playing a consistently increasing play position sequence and write position sequence are expected. The test fails if two sequential GetCurrentPosition calls return a decreasing cursor position. Also, it is expected that after Play() is called, the first play cursor moves within 100ms.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.35.4 The DirectSound device must support IDirectSoundBuffer::Stop API.

When Stop is called on a primary buffer with DSSCL_WRITEPRIMARY cooperative level, driver must reset cursor position to 0.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.36.1 – 16.4.36.2 The DirectSound device must support the IDirectSoundBuffer::SetFormat API.

The format parameter of this call can be anything in the range of driver’s reported capabilities. If this is on a DSSCL_WRITEPRIMARY primary buffer, subsequent GetFormat calls must return the same format. SetFormat must succeed whether buffer is playing or not, and whether the buffer is set to loop or not.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.36.3 – 16.4.36.4 The DirectSound device must support controls on a primary buffer.

SetPan/GetPan, SetVolume/GetVolume should work the same way as on secondary buffers.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.35 Multiple primary buffers should be supported.

Test would create multiple primary buffers, play all of them and change controls.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.38.1 – 16.4.38.5 The DirectSound device must support IDirectSound3DListener::SetXXX and GetXXX API’s.

The SetXXX/GetXXX calls must succeed whether the buffer is playing or not, for both hardware and software implementations. Given a valid parameter, subsequent GetXXX calls of SetXXX calls must return previously set values.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.42 – 16.4.46 The DirectSound device must support IDirectSound3DBuffer::SetXXX and GetXXX API’s.

The SetXXX/GetXXX calls must succeed whether the buffer is playing or not, for both hardware and software implementations. Given a valid parameter, subsequent GetXXX calls of SetXXX calls must return previously set values.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.50.1 – 16.4.50.6 The DirectSound device must support DirectSound’s voice management.

Driver should not do their own voice management, i.e. when it reports that it can still handle hardware buffers, it should actually be able to do it. Another requirement for driver here is that it should be able to quickly release and instantiate pins.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.80.1 – 16.4.80.5 The DirectSound device must support IDirectSoundNotify::SetNotificationPositions API on playback buffer.

SetNotificationPositions must succeed on multiple notifications, single notifications, stop notifications and so on. Notification events must be issued at the correct time. Driver must be prepared to handle zero notification set.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.90.1 The DirectSound device must give equivalent output power level to software and hardware DirectSound 2-D buffers.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.90.2 The DirectSound device must give equivalent output power level to software and hardware DirectSound 3-D buffers.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.200 The DirectSound device must support DirectSoundCaptureEnumerate API, which queries SysAudio device info.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.201 – 16.4.201.1 The DirectSound device must support IdirectSoundCapture::GetCaps API.

If the device supports hardware acceleration, the device must accurately report its capabilities.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.202 The DirectSound device must support IDirectSoundCapture::CreateCaptureBuffer API.

If the device supports a hardware capture pin, it must succeed the corresponding create hardware pin request (as long as the format is one of the device’s reported capabilities). If WAVEMAP flag is used, ACM supported wave format capture buffer creation should succeed.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.203 The DirectSound device must support IDirectSoundCaptureBuffer::GetCaps API.

It should return accurate buffer length and capture buffer flags.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.204 The DirectSound device must support IDirectSoundCaptureBuffer::GetFormat API.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.205 The DirectSound device must support IDirectSoundCaptureBuffer::GetStatus API.

GetStatus() call should succeed no matter buffer is capturing or not.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.206 The DirectSound device must support IDirectSoundCaptureBuffer::Lock/UnLock API.

Calls to lock entire buffer, non-overlapped buffer area must succeed.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.207 The DirectSound device must support IDirectSoundCaptureBuffer::Start/Stop API.

Driver must be able to change state from PAUSE to RUN and succeed readstream request. Start call must succeed whether the buffer is capturing or not. If Start is called on a capturing buffer and loop state is not changed, nothing additional is needed. Otherwise, the driver needs to receive a readstream request.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.210.1 – 16.4.210.5 The DirectSound device must support IDirectSoundNotify::SetNotificationPositions API on capture buffer.

SetNotificationPositions must succeed on multiple notifications, single notifications, stop notifications and so on. Notification events must be issued at the correct time. Driver must be prepared to handle zero notification set.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)

16.4.220.1 The DirectSound device must support IDirectSoundCaptureBuffer::GetCurrentPosition API.

GetCurrentPosition may be called whether the buffer is capturing or idle. When buffer is capturing, a consistently increasing capture position sequence and read position sequence are expected. The test fails if two sequential GetCurrentPosition calls return a decreasing cursor position. Also, it is expected that after Start() is called, the first capture cursor moves within 100ms.

Reference document: WLP# - B3.1.1; PC 2001 System Design Guide- AUD-0326-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.1 DirectSound Driver Test (DsDrvTst)


Audio Power Management Test Assertions

The Audio Power test assertions are tested in TD-16.2 Audio Power Management Test (Lullaby).

16.7.1 The audio device on the system must be able to play wave audio via the sndPlaySound API, both before and after an S1 suspend / resume cycle.

Reference document: WLP# - B3.1.1, B3.1.2.2; PC 2001 System Design Guide- AUD-0336; PC 99 System Design Guide - 17.28 and 17.29.
Test description: TD-16.2 Audio Power Management Test (Lullaby)

16.7.2 The audio device on the system must be able to play wave audio via the waveOutWrite API, both before and after an S1 suspend / resume cycle.

Reference document: WLP# - B3.1.1, B3.1.2.2; PC 2001 System Design Guide- AUD-0336; PC 99 System Design Guide - 17.28 and 17.29.
Test description: TD-16.2 Audio Power Management Test (Lullaby)

16.7.3 Note: This test assertion is undefined.
16.7.4 The audio device on the system must be able to play audio via the IDirectSoundBuffer::Play API, both before and after an S1 suspend / resume cycle.

Reference document: WLP# - B3.1.1, B3.1.2.2; PC 2001 System Design Guide- AUD-0336; PC 99 System Design Guide - 17.28 and 17.29.
Test description: TD-16.2 Audio Power Management Test (Lullaby)

16.7.5 The audio device on the system must be able to record audio via the IDirectSoundCaptureBuffer::Start API, both before and after an S1 suspend / resume cycle.

Reference document: WLP# - B3.1.1, B3.1.2.2; PC 2001 System Design Guide- AUD-0336; PC 99 System Design Guide - 17.28 and 17.29.
Test description: TD-16.2 Audio Power Management Test (Lullaby)

16.7.6 The audio device on the system must be able to play midi audio via the midiStreamOut API, both before and after an S1 suspend / resume cycle.

Reference document: WLP# - B3.1.1, B3.1.2.2; PC 2001 System Design Guide- AUD-0336; PC 99 System Design Guide - 17.28 and 17.29.
Test description: TD-16.2 Audio Power Management Test (Lullaby)

16.7.7 If an audio device is playing wave audio via the sndPlaySound API, the device must be silent while the machine is suspended to S1 state, and the state of the device must be restored to its pre-suspend state on a resume from S1.

Reference document: WLP# - B3.1.1, B3.1.2.2; PC 2001 System Design Guide- AUD-0336; PC 99 System Design Guide - 17.28 and 17.29.
Test description: TD-16.2 Audio Power Management Test (Lullaby)

16.7.8 If an audio device is playing wave audio via the waveOutWrite API, the device must be silent while the machine is suspended to S1 state, and the state of the device must be restored to its pre-suspend state on a resume from S1.

Reference document: WLP# - B3.1.1, B3.1.2.2; PC 2001 System Design Guide- AUD-0336; PC 99 System Design Guide - 17.28 and 17.29.
Test description: TD-16.2 Audio Power Management Test (Lullaby)

16.7.10 If an audio device is playing wave audio via the IDirectSoundBuffer::Play API, the device must be silent while the machine is suspended to S1 state, and the state of the device must be restored to its pre-suspend state on a resume from S1.

Reference document: WLP# - B3.1.1, B3.1.2.2; PC 2001 System Design Guide- AUD-0336; PC 99 System Design Guide - 17.28 and 17.29.
Test description: TD-16.2 Audio Power Management Test (Lullaby)

16.7.11 If an audio device is recording wave audio via the IDirectSoundCaptureBuffer::Start API, the state of the device must be restored to its pre-suspend state on a resume from S1.

Reference document: WLP# - B3.1.1, B3.1.2.2; PC 2001 System Design Guide- AUD-0336; PC 99 System Design Guide - 17.28 and 17.29.
Test description: TD-16.2 Audio Power Management Test (Lullaby)

16.7.12 If an audio device is playing MIDI data via the midiStreamOut API, the device must be silent while the machine is suspended to S1 state, and the state of the device must be restored to its pre-suspend state on a resume from S1.

Reference document: WLP# - B3.1.1, B3.1.2.2; PC 2001 System Design Guide- AUD-0336; PC 99 System Design Guide - 17.28 and 17.29.
Test description: TD-16.2 Audio Power Management Test (Lullaby)

16.7.13 – 16.7.39 Note: These test assertions are undefined.
16.7.40 An audio device on the system must be able to play wave audio via the sndPlaySound API, both before and after an S4 suspend / resume cycle.

Reference document: WLP# - B3.1.1, B3.1.2.2; PC 2001 System Design Guide- AUD-0336; PC 99 System Design Guide - 17.28 and 17.29.
Test description: TD-16.2 Audio Power Management Test (Lullaby)

16.7.41 An audio device on the system must be able to play wave audio via the waveOutWrite API, both before and after an S4 suspend / resume cycle.

Reference document: WLP# - B3.1.1, B3.1.2.2; PC 2001 System Design Guide- AUD-0336; PC 99 System Design Guide - 17.28 and 17.29.
Test description: TD-16.2 Audio Power Management Test (Lullaby)

16.7.43 An audio device on the system must be able to play audio via the IDirectSoundBuffer::Play API, both before and after an S4 suspend / resume cycle.

Reference document: WLP# - B3.1.1, B3.1.2.2; PC 2001 System Design Guide- AUD-0336; PC 99 System Design Guide - 17.28 and 17.29.
Test description: TD-16.2 Audio Power Management Test (Lullaby)

16.7.44 An audio device on the system must be able to record audio via the IDirectSoundCaptureBuffer::Start API, both before and after an S4 suspend / resume cycle.

Reference document: WLP# - B3.1.1, B3.1.2.2; PC 2001 System Design Guide- AUD-0336; PC 99 System Design Guide - 17.28 and 17.29.
Test description: TD-16.2 Audio Power Management Test (Lullaby)

16.7.45 An audio device on the system must be able to play midi audio via the midiStreamOut API, both before and after an S4 suspend / resume cycle.

Reference document: WLP# - B3.1.1, B3.1.2.2; PC 2001 System Design Guide- AUD-0336; PC 99 System Design Guide - 17.28 and 17.29.
Test description: TD-16.2 Audio Power Management Test (Lullaby)

16.7.46 If an audio device is playing wave audio via the sndPlaySound API, the device must be silent while the machine is suspended to S4 state, and the state of the device must be restored to its pre-suspend state on a resume from S4.

Reference document: WLP# - B3.1.1, B3.1.2.2; PC 2001 System Design Guide- AUD-0336; PC 99 System Design Guide - 17.28 and 17.29.
Test description: TD-16.2 Audio Power Management Test (Lullaby)

16.7.47 If an audio device is playing wave audio via the waveOutWrite API, the device must be silent while the machine is suspended to S4 state, and the state of the device must be restored to its pre-suspend state on a resume from S4.

Reference document: WLP# - B3.1.1, B3.1.2.2; PC 2001 System Design Guide- AUD-0336; PC 99 System Design Guide - 17.28 and 17.29.
Test description: TD-16.2 Audio Power Management Test (Lullaby)

16.7.49 If an audio device is playing wave audio via the IDirectSoundBuffer::Play API, the device must be silent while the machine is suspended to S4 state, and the state of the device must be restored to its pre-suspend state on a resume from S4.

Reference document: WLP# - B3.1.1, B3.1.2.2; PC 2001 System Design Guide- AUD-0336; PC 99 System Design Guide - 17.28 and 17.29.
Test description: TD-16.2 Audio Power Management Test (Lullaby)

16.7.50 If an audio device is recording wave audio via the IDirectSoundCaptureBuffer::Start API, the state of the device must be restored to its pre-suspend state on a resume from S4.

Reference document: WLP# - B3.1.1, B3.1.2.2; PC 2001 System Design Guide- AUD-0336; PC 99 System Design Guide - 17.28 and 17.29.
Test description: TD-16.2 Audio Power Management Test (Lullaby)

16.7.51 If an audio device is playing MIDI data via the midiStreamOut API, the device must be silent while the machine is suspended to S4 state, and the state of the device must be restored to its pre-suspend state on a resume from S4.

Reference document: WLP# - B3.1.1, B3.1.2.2; PC 2001 System Design Guide- AUD-0336; PC 99 System Design Guide - 17.28 and 17.29.
Test description: TD-16.2 Audio Power Management Test (Lullaby)


Audio Mixer Driver Test Assertions

The Mixer Driver test assertions are tested in TD-16.3 Mixer Driver Test (MIXDRV32).

16.8.1 The Mixer device must support the mixerGetNumDevs API.

The API gets the number of devices in the system and logs them.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.2 The Mixer device must support the mixerGetDevCaps API.

The API logs capabilities returned from the driver.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.3 The mixerGetDevCaps must not write more than cbmxcaps bytes into the pmxcaps buffer.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.4 The mixerGetDevCaps must not crash if cbmxcaps bytes passed in less than the size of (MIXERCAPS).

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.5 mixerOpen must work with the CALLBACK_WINDOW flag specified.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.6 The mixer device sends a MM_MIXM_CONTROL_CHANGE message in response to a control change (as effected by mixerSetControlDetails).

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.7 mixerOpen must work with the MIXER_OBJECTF_MIXER flag specified.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.8 Mixer APIs called on a closed mixer handle (via mixerClose) will fail.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.9 mixerGetLineInfo must produce a unique mixer ID for each DST line.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.10 mixerGetLineInfo must produce a unique mixer ID for each SRC line.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.11 mixerGetLineInfo must return information about each mixer line.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.12 mixerGetLineInfo must return correct information about each component type.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.13 mixerGetLineInfo must return correct information about each available target type.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.14 mixerGetLineControls must return unique control id for each control.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.15 mixerGetLineControls must return consistent control information if called with MIXER_GETLINECONTROLSF_ONEBYID flag.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.16 mixerGetLineControls must return consistent control information if called with MIXER_GETLINECONTROLSF_ONEBYTYPE flag.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.17 mixerGetLineControls must return error, if called with an invalid dwLineId using MIXER_GETLINECONTROLSF_ONEBYTYPE or MIXER_GETLINECONTROLSF_ALL flag.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.18 mixerGetLineControls must return error, if called with an invalid dwControlId using MIXER_GETLINECONTROLSF_ONEBYID flag.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.19 mixerGetLineControls must return error, if called with an invalid dwControlType using MIXER_GETLINECONTROLSF_ONEBYTYPE flag.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.20 mixerGetLineControls must return error, if called with (dwControlId = -1) using MIXER_GETLINECONTROLSF_ALL or MIXER_GETLINECONTROLSF_ONEBYID flag.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.21 mixerSetControlDetails and mixerGetControlDetails must work for all mixer control details properly. (VALUE)

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.22 mixerSetControlDetails and mixerGetControlDetails must work for all mixer control detail properly. (LISTTEXT)

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.23 Verify that the mixer device will coalesce the channel values on a multiple channel control if info is asked for in a uniform manner.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.24 This test verifies that a mixer driver will set all channel values to the specified value passed in by mixerSetControlDetails if the MIXERCONTROLDETAILS.cChannels value is set to 1.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.25 mixerGetControlDetails must return MIXERR_INVALCONTROL if invalid dwControlId is passed.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.26 mixerGetControlDetails must return error if invalid cChannel is passed.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.27 mixerGetControlDetails must return error if invalid cMultipleItems is passed.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.28 mixerSetControlDetails must return MIXERR_INVALCONTROL if invalid dwControlId is passed.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.29 mixerSetControlDetails must return error if invalid cChannel is passed.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.30 mixerSetControlDetails must return error if invalid cMultipleItems is passed.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.31 Verifies that mixerSetControlDetails works for all controls in a uniform manner.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.32 This is the same as 8.31, except that it passes a MIXERCONTROLDETAILS-sized buffer to the API.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.33 Changing master volume must affect wave playback volume.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.34 Changing master volume must affect MIDI playback volume.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.35 Changing master volume must affect CD playback volume.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.36 Changing master volume must affect Line-In playback volume.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.37 Changing master volume balance must affect wave playback balance.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.38 Changing master volume balance must affect MIDI playback balance.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.39 Changing master volume balance must affect CD playback balance.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.40 Changing master volume balance must affect Line-In playback balance.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.41 Changing wave volume must affect wave playback volume.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.42 Changing MIDI volume must affect MIDI playback volume.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.43 Changing CD volume must affect CD playback volume.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.44 Changing Line-In volume must affect Line-In playback volume.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.45 Changing wave volume balance must affect wave playback volume.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.46 Changing MIDI volume balance must affect MIDI playback balance.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.47 Changing CD volume balance must affect CD playback balance.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)

16.8.48 Changing Line-In volume balance must affect Line-In playback balance.

Reference document: WLP# - B3.1.1.1; PC 2001 System Design Guide - AUD-0337; PC 99 System Design Guide - 17.31 and 17.32.
Test description: TD-16.3 Mixer Driver Test (MIXDRV32)


Audio Wave Driver Test Assertions

The Wave Driver test assertions are tested in TD-16.4 Audio Wave Driver Test (WAVDRV32).

16.9.1 waveInGetDevCaps –

waveInOpen must succeed with the following wave formats

  • nChannels ( { 1, 2}
  • nSamplesPerSec ({8k, 11025, 16k, 22050, 32k, 44100, 48k }
  • wBitsPerSample ({ 8, 16 }

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.2 waveOutGetDevCaps –

waveOutOpen must succeed with the following wave formats

  • nChannels ( { 1, 2 }
  • nSamplesPerSec ( { 8k, 11025, 16k, 22050, 32k, 44100, 48k }
  • wBitsPerSample ( { 8, 16 }

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.3 waveInOpen –
  • The driver supports a waveIn device.
  • For each format, if waveInOpen with WAVE_FORMAT_QUERY specified succeeds, then it must also succeed without that flag.
  • For each format, if waveInOpen with WAVE_FORMAT_QUERY specified fails, then it must also fail without that flag.
  • The driver must support an unlimited number of open waveIn devices.
  • The driver must post a WIM_OPEN message with the correct parameters in response to waveInOpen.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.4 waveInClose –
  • waveInClose must succeed on an open waveIn device before and after recording.
  • The device must post a WIM_CLOSE message with the correct parameters in response to waveInClose.
  • The device must fail calls to waveInClose if the device is recording.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.5 waveOutOpen –
  • The driver supports a waveOut device.
  • For each format, if waveOutOpen with WAVE_FORMAT_QUERY specified succeeds, then it must also succeed without that flag.
  • For each format, if waveOutOpen with WAVE_FORMAT_QUERY specified fails, then it must also fail without that flag.
  • The driver must support an unlimited number of open waveOut devices.
  • The driver must post a WOM_OPEN message with the correct parameters in response to waveOutOpen.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.6 waveOutClose –
  • waveOutClose must succeed on an open waveOut device before and after recording.
  • The device must post a WOM_CLOSE message with the correct parameters in response to waveOutClose.
  • The device must fail calls to waveOutClose if the device is recording, or in a paused state.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.7 waveOutGetPosition –
  • waveOutGetPosition must report a position of 0 on a newly opened device.
  • For a device that is playing, the position reported must be non-zero, and always incremented (never moving backwards).
  • The position must eventually reach the end of the specified buffer.
  • The position reported must be 0 after calling waveOutReset.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.8 waveOutPrepareHeader –
  • After calling waveOutPrepareHeader, the WHDR_PREPARED bit must be set.
  • The device must succeed two consecutive calls to waveOutPrepareHeader.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.9 waveOutUnprepareHeader –
  • The device must succeed calls to waveOutUnprepare header for prepared headers before and after playing.
  • Calling waveOutUnprepareHeader must clear the WHDR_PREPARED bit on a prepared header.
  • The device must succeed two consecutive calls to waveOutUnprepareHeader.
  • The device must fail a call to waveOutUnprepareHeader on a queued header.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.10 waveOutBreakLoop –
  • Setting the dwLoops member of a wave header causes a header to loop dwLoops times.
  • Calling waveoutBreakLoop while a header is playing causes the current header to complete the current loop and then terminate.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.11 waveOutPause –
  • The device is in the paused state when it is opened.
  • Pausing a header works at any time that the header is prepared, whether the header is playing or not.
  • Calling waveOutWrite on a paused header leaves the header paused.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.12 waveOutRestart –
  • waveOutRestart has no effect on a header that is not paused.
  • waveOutRestart restarts a header immediately.
  • After calling waveOutRestart on a paused header, the position returned by waveOutGetPosition must be the first sample after the position that was reported in the paused state.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.13 waveOutReset –
  • waveOutReset works immediately after a device is opened.
  • waveOutReset works on a paused header.
  • A header can be restarted after calling waveOutReset.
  • waveOutReset works on a buffer that has been restarted.
  • The position reported by waveOutGetPosition is 0 after calling waveOutReset.
  • The device sends a WHDR_DONE message in response to waveOutReset for looped and non-looped headers.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.14 waveInGetPosition –
  • waveInGetPosition must report a position of 0 on a newly opened device.
  • For a device that is recording, the position reported must be non-zero, and always incremented (never moving backwards).
  • The position must eventually reach the end of the specified buffer.
  • The position reported by must be 0 after calling waveInReset.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.15 waveInPrepareHeader –
  • After calling waveInPrepareHeader, the WHDR_PREPARED bit must be set.
  • The device must succeed two consecutive calls to waveInPrepareHeader.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.16 waveInUnprepareHeader –
  • The device must succeed calls to waveInUnprepare header for prepared headers before and after recording.
  • Calling waveInUnprepareHeader must clear the WHDR_PREPARED bit on a prepared header.
  • The device must succeed two consecutive calls to waveInUnprepareHeader.
  • The device must fail a call to waveInUnprepareHeader on a queued header.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.17 waveInStart –
  • A device must be in a stopped state when first opened.
  • A device must not be in a stopped state while recording.
  • waveInStart works before and after calling waveInPrepareHeader.
  • waveInStart works before calling waveInAddBuffer.
  • waveInStart works after calling waveInStop.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.18 waveInStop –
  • waveInStop works before and after calling waveInPrepareHeader.
  • waveInStop works before calling waveInAddBuffer.
  • Device is in stopped state after calling waveInReset.
  • waveInStop works on a recording header.
  • The WHDR_DONE bit is set on dwFlags after calling waveInStop.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.19 waveInReset –
  • waveInReset works immediately after opening device.
  • waveInReset works if device is recording.
  • Device is in stopped state after calling waveInReset.
  • waveInReset works if a device is stopped.
  • The position reported by waveInGetPosition is 0 after calling waveInReset.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.20 waveOutGetPitch –
  • If WAVECAPS_PITCH is not set, then waveOutGetPitch will fail.
  • If WAVECAPS_PITCH is set, then waveOutGetPitch will succeed.
  • Pitch is 1.00 immediately after opening device.
  • waveOutGetPitch works when device is stopped, paused, or playing.
  • waveOutGetPitch returns the value passed to waveOutSetPitch.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.21 waveOutSetPitch –
  • If WAVECAPS_PITCH is not set, then waveOutSetPitch fails.
  • If WAVECAPS_PITCH is set, then waveOutSetPitch succeeds.
  • waveOutSetPitch works when the device is stopped, paused, or playing.
  • waveOutSetPitch returns the value passed to waveOutSetPitch.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.22 waveOutGetPlaybackRate –
  • If WAVECAPS_PLAYBACKRATE is not set, then waveOutGetPlaybackRate fails.
  • If WAVECAPS_PLAYBACKRATE is set, then waveOutGetPlaybackRate succeeds.
  • Rate is 1.00 immediately after opening device.
  • waveOutGetPlaybackRate works when device is stopped, paused, or playing.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.23 waveOutSetPlaybackRate –
  • If WAVECAPS_PLAYBACKRATE is not set, then waveOutSetPlaybackRate fails.
  • If WAVECAPS_PLAYBACKRATE is set, then waveOutSetPlaybackRate succeeds.
  • Rate reported by waveOutGetPlaybackRate matches rate set by waveOutSetPlaybackRate.
  • waveOutSetPlaybackRate works when device is stopped, paused, or playing.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.24 waveOutGetVolume –
  • If WAVECAPS_LRVOLUME is set, then so is WAVECAPS_VOLUME.
  • If WAVECAPS_VOLUME is not set, then waveOutGetVolume fails.
  • If WAVECAPS_VOLUME is set, then waveOutGetVolume succeeds.
  • waveOutGetVolume works if device is stopped or paused.
  • waveOutGetVolume works while device is playing if device is asynchronous.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.25 waveOutSetVolume –
  • If WAVECAPS_LRVOLUME is set, then so is WAVECAPS_VOLUME.
  • If WAVECAPS_VOLUME is not set, then waveOutSetVolume fails.
  • If WAVECAPS_VOLUME is set, then waveOutSetVolume succeeds.
  • waveOutSetVolume works if device is stopped or paused.
  • waveOutSetVolume works while device is playing if device is asynchronous.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.26 waveOutWrite –
  • waveOutWrite works if buffer is paged out.
  • WHDR_DONE bit is clear before calling waveOutWrite and set after calling waveOutWrite.
  • WHDR_INQUEUE bit is set for queued headers (before callback).
  • Driver posts WOM_DONE message with correct parameters in response to waveOutWrite.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.27 waveOutWrite small buffers – Device can play buffers of different sizes.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.28 waveOutWrite medium buffers – Device can play buffers of different sizes.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.29 waveOutWrite large buffers – Device can play buffers of different sizes.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.30 waveOutWrite unaligned data – Device can play buffers that do not start on DWORD- or QWORD-aligned addresses.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.31 waveInAddBuffer –
  • waveInAddBuffer works if buffer is paged out.
  • WHDR_DONE bit is clear before calling waveInAddBuffer and set after calling waveInAddBuffer.
  • WHDR_INQUEUE bit is set for queued headers (before callback).
  • Driver posts WIM_DONE message with correct parameters in response to waveInAddBuffer.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.32 waveInAddBuffer small buffers – Device can record into varied sizes of buffers.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.33 waveInAddBuffer medium buffers – Device can record into varied sizes of buffers.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.34 waveInAddBuffer large buffers – Device can record into varied sizes of buffers.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.34.1 waveInAddBuffer unaligned data – Device can record into buffer whose address is not DWORD- or QWORD-aligned.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.35 waveOut Sampling Rate Accuracy – The output rate of a wave device is within ± 1% of the nSamplesPerSecond.
16.9.35.1 waveOut Startup Latency – The time between a call to waveOutRestart and when a device plays its first sample does not exceed 10ms.
16.9.35.2 waveOut Sampling Rate drift – The difference between the actual time a sample has been playing, and the time reported by waveOutGetPosition does not exceed 1ms.
16.9.35.3 waveOut Time to WHDR_DONE – The driver sets the WHDR_DONE bit within 100ms of completion of the last playing buffer (using CALLBACK_NULL).

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.36 waveIn Sampling Rate accuracy – The input rate of a wave device is within ± 1% of the nSamplesPerSecond.
16.9.36.1 waveIn Startup Latency – The time between a call to waveOutRestart and when a device plays its first sample does not exceed 10ms.
16.9.36.2 waveIn Sampling Rate drift– The difference between the actual time a sample has been recording, and the time reported by waveInGetPosition does not exceed 1ms.
16.9.36.3 waveIn Time to WHDR_DONE– The driver sets the WHDR_DONE bit within 100ms of completion of the last recording buffer (using CALLBACK_NULL).

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.37 waveOutWrite actual play time – The time from when the driver reports its first non-zero position to when it sets the WHDR_DONE bit is the time expected for the buffer to play.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.38 waveInAddBuffer actual record time – The time from when the driver reports its first non-zero position to when it sets the WHDR_DONE bit is the time expected for the buffer to be recorded.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.39 waveOutGetPosition performance – The driver call handles multiple calls to waveOutGetPosition within 1ms.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.40 waveInGetPosition performance – The driver call handles multiple calls to waveInGetPosition within 1ms.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.41 waveIn Callback Event – A waveIn device opened with the CALLBACK_EVENT flag sets the specified event to signal in response to waveInStart.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)

16.9.42 waveOut Callback Event – A waveOut device opened with the CALLBACK_EVENT flag, sets the specified event to signal in response to waveOutWrite.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0324, AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.4 Audio Wave Driver Test (WAVDRV32)


Audio MIDI Driver Test Assertions

The MIDI Driver test assertions are tested in TD-16.5 Audio MIDI Driver Test (MIDDRV32).

16.10.1 MIDI Get Device Capabilities – The device must correctly populate the MIDIINCAPS structure on a call to midiInGetDevCaps.
  • The dwSupport field must be 0.
  • The szPname field must be null-terminated.
  • The wMid (Manufacturer ID) field and wPid (Product ID) field must both be registered with Microsoft.
  • The vDriverVersion field must not equal 0.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.2 MIDM_GETDEVCAPS with various sizes of MIDIINCAPS –

On a call to midiInGetDevCaps, the device must populate the memory pointed to by the lpMidiInCaps parameter with no more than the number of bytes specified by the cbMidiInCaps parameter. cbMidiInCaps could even be 0. The device must not cause midiInGetDevCaps to return anything other than MSYSERR_NOERROR in this scenario.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.3 MODM Get Device Capabilities – The device must correctly populate the MIDIOUTCAPS structure on a call to midiOutGetDevCaps.
  • The szPname field must be null-terminated.
  • The wMid (Manufacturer ID) field and wPid (Product ID) field must both be registered with Microsoft.
  • The vDriverVersion field must not equal 0.
  • If the device reports that it is external (wTechnology field equals MOD_MIDIPORT) then the wVoices field must equal 0, the wNotes field must equal 0, the wChannelMask field must equal 0xFFFF, the dwSupport field must not have the MIDICAPS_VOLUME, MIDICAPS_LRVOLUME, nor the MIDICAPS_CACHE flags set.
  • If the device reports that it is internal (wTechnology field equals MOD_SYNTH) then the wVoices field must be greater than 0, the wNotes field must be greater than 0, and the wChannelMask field must not equal 0.
  • If the device has set the MIDICAPS_CACHE flag in the dwSupport field then it must force neither midiOutCachePatches nor midiOutCacheDrumPatches to return MMSYSERR_NOTSUPPORTED.
  • If the MIDICAPS_CACHE flag was not set then the device must force neither midiOutCachePatches nor midiOutCacheDrumPatches to return MMSYSERR_NOERROR.
  • If the device has set the MIDICAPS_VOLUME flag or the MIDICAPS_LRVOLUME flag in the dwSupport field, then it must force neither midiOutGetVolume nor midiOutSetVolume to return MMSYSERR_NOTSUPPORTED.
  • If neither the MIDICAPS_VOLUME flag nor the MIDICAPS_LRVOLUME flags were set then the device must force neither midiOutGetVolume nor midiOutSetVolume to return MMSYSERR_NOERROR.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.4 MODM Get Device Capabilities with various sized MIDIOUTCAPS –

On a call to midiOutGetDevCaps, the device must populate the memory pointed to by the lpMidiOutCaps parameter with no more than the number of bytes specified by the cbMidiOutCaps parameter. cbMidiOutCaps could even be 0. The device must not cause midiOutGetDevCaps to return anything other than MMSYSERR_NOERROR in this scenario.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.5 MIDM_OPEN and MIDM_CLOSE with function callback –

When opening an input device with a MidiInProc callback function specified in the dwCallback parameter and the CALLBACK_FUNCTION flag set in the dwFlags parameter of the midiInOpen call, the MIM_OPEN and MIM_CLOSE messages must be passed in the wMsg parameter of the specified callback function when calling midiInOpen and midiInClose respectively. The hMidiIn parameter of the callback function must be the same as the MIDI input device handle obtained from the call to midiInOpen. The dwInstance parameter of the callback function must be the same as the dwInstance parameter passed to midiInOpen.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.6 MIDM_OPEN and MIDM_CLOSE with window callback –

When opening an input device with a window callback function specified in the dwCallback parameter and the CALLBACK_WINDOW flag set in the dwFlags parameter of the midiInOpen call, the MM_MIM_OPEN and MM_MIM_CLOSE messages must be passed in the Msg.message parameter of the specified window callback function when calling midiInOpen and midiInClose respectively. The Msg.wParam parameter of the window callback function must be the same as the MIDI input device handle obtained from the call to midiInOpen.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.7 MIDM_OPEN and MIDM_CLOSE with event callback –

When opening an input device with an event handle specified in the dwCallback parameter and the CALLBACK_EVENT flag set in the dwFlags parameter of the midiInOpen call, the event must be signaled every time either midiInOpen or midiInClose is called.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.8 MIDM_CLOSE while buffers are in the queue –

Calling midiInClose on an opened input device containing incomplete buffers added through midiInAddBuffer must return MIDIERR_STILLPLAYING and must not perform a MIM_CLOSE callback.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.9 MODM_OPEN and MODM_CLOSE with function callback –

When opening an output device with a MidiOutProc callback function specified in the dwCallback parameter and the CALLBACK_FUNCTION flag set in the dwFlags parameter of the midiOutOpen call, the MOM_OPEN and MOM_CLOSE messages must be passed in the wMsg parameter of the specified callback function when calling midiOutOpen and midiOutClose respectively. The hMidiOut parameter of the callback function must be the same as the MIDI output device handle obtained from the call to midiOutOpen. The dwInstance parameter of the callback function must be the same as the dwInstance parameter passed to midiOutOpen.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.10 MODM_OPEN and MODM_CLOSE with window callback –

When opening an output device with a window callback function specified in the dwCallback parameter and the CALLBACK_WINDOW flag set in the dwFlags parameter of the midiOutOpen call, the MM_MOM_OPEN and MM_MOM_CLOSE messages must be passed in the Msg.message parameter of the specified window callback function when calling midiOutOpen and midiOutClose respectively. The Msg.wParam parameter of the window callback function must be the same as the MIDI output device handle obtained from the call to midiOutOpen.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.11 MODM_OPEN and MODM_CLOSE with event callback –

When opening an output device with an event handle specified in the dwCallback parameter and the CALLBACK_EVENT flag set in the dwFlags parameter of the midiOutOpen call, the event must be signaled every time either midiOutOpen or midiOutClose is called.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.12 MIDM_PREPARE and MIDM_UNPREPARE with various buffer sizes –

The MHDR_PREPARED flag must be set in the dwFlags field of the lpMidiInHdr parameter after a call to midiInPrepareHeader. The MHDR_PREPARED flag must be cleared from the dwFlags field of the lpMidiInHdr parameter after a call to midiInUnprepareHeader. The dwUser field of the lpMidiInHdr parameter must be changed by neither midiInPrepareHeader nor midiInUnprepareHeader.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.13 MODM_PREPARE and MODM_UNPREPARE with various buffer sizes –

The MHDR_PREPARED flag must be set in the dwFlags field of the lpMidiOutHdr parameter after a call to midiOutPrepareHeader. The MHDR_PREPARED flag must be cleared from the dwFlags field of the lpMidiOutHdr parameter after a call to midiOutUnprepareHeader. The dwUser field of the lpMidiOutHdr parameter must be changed by neither midiOutPrepareHeader nor midiOutUnprepareHeader.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.14 MIDI Start while already recording short message –

Requirements of assertion 16.10.5 and the MIM_DATA message must be received for each MIDI message recorded. The correct MIDI messages must be received by the callback function in the same order they were sent to/recorded by the device. Subsequent messages must have increasing timestamps. The first message must not be stamped with a time prior to which it was sent. A second call to midiInStart must not reset the timestamp timer back to 0.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.15 MIDI Start while already recording SysEx message –

Requirements of assertion 16.10.5 and the MIM_LONGDATA message must be received for each SysEx message recorded. The SysEx message received must be identical to the one sent. The dwBytesRecorded field of the lpMidiInHdr parameter passed to the input device by midiInAddBuffer must equal the dwBytesRecorded field of the lpMidiOutHdr parameter of midiOutLongMsg. The SysEx messages must be received by the callback function in the same order they were sent to/recorded by the device. Subsequent messages must have increasing timestamps. The first message must not be stamped with a time prior to which it was sent. A second call to midiInStart must not reset the timestamp timer back to 0.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.16 MIDI Start after recording is stopped –

Requirements of assertions 16.10.14 and 16.10.15, except when midiInStop is called after the first call to midiInStart but before the second call, the second call to midiInStart must reset the timestamp timer back to 0.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.17 MIDI Start after recording is reset –

Requirements of assertions 16.10.14 and 16.10.15, except that instead of calling midiInStart a second time, midiInReset is called in its place. This must have the effect of resetting the timestamp timer back to 0.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.18 MIDI Start with no buffers to record SysEx message –

Requirements of assertion 16.10.5 and since no buffers have been added to the input device through midiInAddBuffer, no callbacks must be received for any sent SysEx messages. The input device must ignore any received SysEx messages. MIDI messages, on the other hand must still be received correctly and generate the proper MIM_DATA callbacks.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.19 MIDI Stop while recording SysEx message –

If midiInStop is called when the input device still has an incomplete SysEx buffer, a MIM_LONGERROR callback must be received for that buffer. The dwBytesRecorded field of the lpMidiInHdr parameter passed to the input device by midiInAddBuffer must equal the number of bytes received before midiInStop was called. The data pointed to by the lpData field of the lpMidiInHdr parameter must be identical to the data received prior to the midiInStop call. The MHDR_INQUEUE flag must be clear and the MHDR_DONE flag must be set in the dwFlags field of the lpMidiInHdr parameter. Any empty buffers in the input queue must not have been returned to the callback. The MHDR_INQUEUE flag must be set and the MHDR_DONE flag must be clear in the dwFlags field of the lpMidiInHdr parameter for all empty buffers.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.20 MIDI Stop after recording is reset –

A call to midiInStop immediately after a call to midiInReset must return MMSYSERR_NOERROR. Any MIDI messages received prior to the call to midiInReset must generate the appropriate MIM_DATA callbacks.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.21 MIDI Stop, verify recording stops –

Any MIDI messages sent after a call to midiInStop must not be recorded and must not generate any callbacks.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.22 MIDI Reset while recording SysEx messages –

If midiInReset is called when the input device still has an incomplete SysEx buffer, a MIM_LONGERROR callback must be received for that buffer. The dwBytesRecorded field of the lpMidiInHdr parameter passed to the input device by midiInAddBuffer must equal the number of bytes received before midiInReset was called. The data pointed to by the lpData field of the lpMidiInHdr parameter must be identical to the data received prior to the midiInReset call. Any empty buffers in the input queue must be returned via MIM_LONGDATA callbacks after midiInReset is called. The MHDR_INQUEUE flag must be clear and the MHDR_DONE flag must be set in the dwFlags field of the lpMidiInHdr parameter for all returned buffers, incomplete or complete. The incomplete buffer’s timestamp must be based off of the call to midiInStart and not based off of the reset timer due to midiInReset.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.23 MIDI Reset after recording is stopped –

Requirements of assertion 16.10.22 and a second call to midiInReset must return MMSYSERR_NOERROR.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.24 MIDI Reset while recording short messages only—

Any MIDI messages sent after a call to midiInReset must not be recorded and must not generate any callbacks.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.25 MIM DATA function callback verification –

Requirements of assertion 16.10.5 and the MIM_DATA message must be received for each MIDI message recorded. The correct MIDI messages must be received by the callback function in the same order they were sent to/recorded by the device. Subsequent messages must have increasing timestamps. The first message must not be stamped with a time prior to which it was sent.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.26 MIM LONGDATA function callback verification –

Requirements of assertion 16.10.5 and the MIM_LONGDATA message must be received for each SysEx message recorded. The SysEx message received must be identical to the one sent. The dwBytesRecorded field of the lpMidiInHdr parameter passed to the input device by midiInAddBuffer must equal the dwBytesRecorded field of the lpMidiOutHdr parameter of midiOutLongMsg. The SysEx messages must be received by the callback function in the same order they were sent to/recorded by the device. Subsequent messages must have increasing timestamps. The first message must not be stamped with a time prior to when it was sent.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.27 MIM LONGERROR function callback verification –

If an incomplete SysEx message is received, a MIM_LONGERROR callback must be received for that buffer. The dwBytesRecorded field of the lpMidiInHdr parameter passed to the input device by midiInAddBuffer must equal the number of bytes received before midiInStop was called. The data pointed to by the lpData field of the lpMidiInHdr parameter must be identical to the data received prior to the midiInStop call. The MHDR_INQUEUE flag must be clear and the MHDR_DONE flag must be set in the dwFlags field of the lpMidiInHdr parameter.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.28 MIM LONGDATA without callbacks –

When midiInOpen is called with dwCallback equal to NULL and dwFlags equal to CALLBACK_NULL, the driver must still call DriverCallback. This is verified by ensuring that the MHDR_DONE flag is set in the dwFlags field of the lpMidiInHdr parameter to midiInAddBuffer after a SysEx message is received. The SysEx message received must be identical to the one sent.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.29 MODM LONGDATA without callbacks—

When midiOutOpen is called with dwCallback equal to NULL and dwFlags equal to CALLBACK_NULL, the driver must still call DriverCallback. This is verified by ensuring that the MHDR_DONE flag is set in the dwFlags field of the lpMidiOutHdr parameter to midiOutLongMsg after a SysEx message is sent.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.30 MIDM Add Buffer before recording is started –

Calling midiInAddBuffer before recording is started must clear the MHDR_DONE flag and set the MHDR_INQUEUE flag in the dwFlags parameter of lpMidiInHdr.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.31 MIDM Add Buffer after recording is started –

Requirements of assertion 16.10.37 and calling midiInAddBuffer after recording has been started must clear the MHDR_DONE flag and set the MHDR_INQUEUE flag in the dwFlags parameter of lpMidiInHdr.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.32 MIDM Add Buffer with five buffers of various sizes –

Requirements of assertion 16.10.32 must be met for buffers of various sizes.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.33 SysEx message recording with buffers same size as SysEx messages –

Requirements of assertion 16.10.5 and the SysEx messages received must be identical to the ones sent. The dwBytesRecorded field of the lpMidiInHdr parameter passed to the input device by midiInAddBuffer must equal the dwBytesRecorded field of the lpMidiOutHdr parameter of midiOutLongMsg. The SysEx messages must be received by the callback function in the same order they were sent to/recorded by the device.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.34 SysEx message recording with buffers smaller than the SysEx message –

Requirements of assertion 16.10.34, except that a SysEx message can span more than one buffer. The dwBytesRecorded field of the first buffer must be its size and the dwBytesRecorded field of the remaining buffers must be either their size (if they’re full) or the remainder of the sent SysEx message’s size. When appended to each other, the buffers must make up the original SysEx message. Each received buffer must generate a MIM_LONGDATA callback with the proper information. The MHDR_INQUEUE flag must be clear and the MHDR_DONE flag must be set in the dwFlags field of the lpMidiInHdr parameter.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.35 SysEx message recording with buffers larger than the SysEx message

16.10.34 and when a complete SysEx message is received, even if the buffer is not full, it must be returned through a MIM_LONGDATA callback. It’s data must be correct just as specified in 16.10.34.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.36 SysEx msg recording and running status –

SysEx messages must not use running status. Any SysEx message that fails to start with the SysEx status byte must not be recorded and must not generate a MIM_LONGDATA callback.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.37 Short msg recording with running status – ‘

When messages sent using a running status byte are received, a MIM_DATA callback must be generated and the dwParam1 parameter must be expanded to include the running status byte. Real-time messages must not interfere with a running status and a running status must end when a new status byte is received.

Reference document: PC 99 System Design Guide, Sections 17.31 and 17.32.
Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

Note: Test assertions 16.10.38 through 16.10.46 are undefined.

16.10.47 MIDI Volume Control message verification –

If the wTechnology field in the lpMidiOutCaps parameter equals MOD_MIDIPORT after a call to midiOutGetCaps, the device must support the midiOutGetVolume and midiOutSetVolume calls. If the dwSupport field has the MIDICAPS_CACHE flag set, the device must support a call to midiOutCachePatches.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

16.10.48 Basic midiOutGetVolume/midiOutSetVolume test –

If the device supports volume controlling, it must successfully respond to midiOutGetVolume and midiOutSetVolume calls. This is verified by setting the volume and getting it to make sure it returns what it was set to.

Reference document: WLP# B3.1.1; PC 2001 System Design Guide - AUD-0337, AUD-0327; PC 99 System Design Guide - 17.5.2, 17.31, 17.32.
Test description: TD-16.5 Audio MIDI Driver Test (MIDDRV32)

Note: Test assertions 16.11.x through 16.14.x are undefined.


Audio Full Duplex Test Assertions

The Full Duplex test assertions are tested in TD-16.6 Full Duplex Test (FDuplex).

16.15.1 – 16.15.800 Note: These test assertions are undefined.
16.15.801 Audio subsystem must support 8kHz full-duplex operation using DirectSound / DirectSoundCapture, if capture buffer is created first.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0329, AUD-0324; PC 99 System Design Guide - 17.5, 17.31, 17.32.
Test description: TD-16.6 Full Duplex Test (FDuplex)

16.15.802 Audio subsystem must support 11.025 kHz full-duplex operation using DirectSound / DirectSoundCapture, if capture buffer is created first.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0329, AUD-0324; PC 99 System Design Guide - 17.5, 17.31, 17.32.
Test description: TD-16.6 Full Duplex Test (FDuplex)

16.15.803 Audio subsystem must support 22.05 kHz full-duplex operation using DirectSound / DirectSoundCapture, if capture buffer is created first.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0329, AUD-0324; PC 99 System Design Guide - 17.5, 17.31, 17.32.
Test description: TD-16.6 Full Duplex Test (FDuplex)

16.15.804 Audio subsystem must support 44.1kHz full-duplex operation using DirectSound / DirectSoundCapture if capture buffer is created first.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0329, AUD-0324; PC 99 System Design Guide - 17.5, 17.31, 17.32.
Test description: TD-16.6 Full Duplex Test (FDuplex)

16.15.804.3 Audio subsystem must support 48.0kHz full-duplex operation using DirectSound / DirectSoundCapture, if capture buffer is created first.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0329, AUD-0324; PC 99 System Design Guide - 17.5, 17.31, 17.32.
Test description: TD-16.6 Full Duplex Test (FDuplex)

16.15.805 – 16.15.808 Note: These test assertions are undefined.
16.15.809 Audio subsystem must support full-duplex operation using DirectSound Hardware Buffers/ DirectSoundCapture, if capture buffer is created first.

These test cases are only valid for systems supporting playback on DirectSound Hardware Buffers.

16.15.809.1 Note: This test assertion is undefined.
16.15.809.2 Audio subsystem must support 8 kHz full-duplex operation using DirectSound Hardware Buffers/ DirectSoundCapture, if capture buffer is created first.

The test case is only valid for systems supporting 8 kHz playback on DirectSound Hardware Buffers.

16.15.809.3 Audio subsystem must support 11.025 kHz full-duplex operation using DirectSound Hardware Buffers/ DirectSoundCapture, if capture buffer is created first.

The test case is only valid for systems supporting 11.025 kHz playback on DirectSound Hardware Buffers.

16.15.809.4 Audio subsystem must support 22.05 kHz full-duplex operation using DirectSound Hardware Buffers/ DirectSoundCapture, if capture buffer is created first.

The test case is only valid for systems supporting 22.05 kHz playback on DirectSound Hardware Buffers.

16.15.809.5 Audio subsystem must support 44.1kHz full-duplex operation using DirectSound Hardware Buffers/ DirectSoundCapture, if capture buffer is created first.

The test case is only valid for systems supporting 44.1 kHz playback on DirectSound Hardware Buffers.

16.15.809.6 – 16.15.809.7 Note: These assertions are undefined.
16.15.809.8 Audio subsystem must support 48.0kHz full-duplex operation using DirectSound Hardware Buffers/ DirectSoundCapture if capture buffer is created first.

The test case is only valid for systems supporting 48.0 kHz playback on DirectSound Hardware Buffers.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0329, AUD-0324; PC 99 System Design Guide - 17.5, 17.31, 17.32.
Test description: TD-16.6 Full Duplex Test (FDuplex)

16.15.810 Note: This test assertion is undefined.
16.15.811 Audio subsystem must support 8kHz full-duplex operation using DirectSound / DirectSoundCapture if playback buffer is created first.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0329, AUD-0324; PC 99 System Design Guide - 17.5, 17.31, 17.32.
Test description: TD-16.6 Full Duplex Test (FDuplex)

16.15.812 Audio subsystem must support 11.025 kHz full-duplex operation using DirectSound / DirectSoundCapture, if playback buffer is created first.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0329, AUD-0324; PC 99 System Design Guide - 17.5, 17.31, 17.32.
Test description: TD-16.6 Full Duplex Test (FDuplex)

16.15.813 Audio subsystem must support 22.05 kHz full-duplex operation using DirectSound / DirectSoundCapture, if playback buffer is created first.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0329, AUD-0324; PC 99 System Design Guide - 17.5, 17.31, 17.32.
Test description: TD-16.6 Full Duplex Test (FDuplex)

16.15.814 Audio subsystem must support 44.1 kHz full-duplex operation using DirectSound / DirectSoundCapture, if playback buffer is created first.
16.15.814.1 – 16.15.814.2 Note: These test assertions are undefined.
16.15.814.3 Audio subsystem must support 48 kHz full-duplex operation using DirectSound / DirectSoundCapture, if playback buffer is created first.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0329, AUD-0324; PC 99 System Design Guide - 17.5, 17.31, 17.32.
Test description: TD-16.6 Full Duplex Test (FDuplex)

16.15.815 – 16.15.818 Note: These test assertions are undefined.
16.15.819 Audio subsystem must support full-duplex operation using DirectSound Hardware Buffers/ DirectSoundCapture, if playback buffer is created first.

The test case is only valid for systems supporting playback on DirectSound Hardware Buffers.

16.15.819.1 Note: This test assertion is undefined.
16.15.819.2 Audio subsystem must support 8.0 kHz full-duplex operation using DirectSound Hardware Buffers/ DirectSoundCapture, if playback buffer is created first.

The test case is only valid for systems supporting 8.0 kHz playback on DirectSound Hardware Buffers.

16.15.819.3 Audio subsystem must support 11.025 kHz full-duplex operation using DirectSound Hardware Buffers/ DirectSoundCapture, if playback buffer is created first.

The test case is only valid for systems supporting 11.025 kHz playback on DirectSound Hardware Buffers.

16.15.819.4 Audio subsystem must support 22.05 kHz full-duplex operation using DirectSound Hardware Buffers/ DirectSoundCapture, if playback buffer is created first.

The test case is only valid for systems supporting 22.05 kHz playback on DirectSound Hardware Buffers.

16.15.819.5 Audio subsystem must support 44.0 kHz full-duplex operation using DirectSound Hardware Buffers/ DirectSoundCapture, if playback buffer is created first.

The test case is only valid for systems supporting 44.0 kHz playback on DirectSound Hardware Buffers.

16.15.819.6 – 16.15.819.7 Note: These test assertions are undefined.
16.15.819.8 Audio subsystem must support 48.0 kHz full-duplex operation using DirectSound Hardware Buffers/ DirectSoundCapture, if playback buffer is created first.

The test case is only valid for systems supporting 48.0 kHz playback on DirectSound Hardware Buffers.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0329, AUD-0324; PC 99 System Design Guide - 17.5, 17.31, 17.32.
Test description: TD-16.6 Full Duplex Test (FDuplex)

16.15.820 – 16.15.822 Note: These test assertions are undefined.
16.15.823 Audio subsystem must support 8 kHz full-duplex operation using DirectSound / WaveIn, if capture buffer is created first.
16.15.823.1 Audio subsystem must support 11.025 kHz full-duplex operation using DirectSound / WaveIn, if capture buffer is created first.
16.15.823.2 Audio subsystem must support 22.05 kHz full-duplex operation using DirectSound / WaveIn, if capture buffer is created first.
16.15.823.3 Audio subsystem must support 44.1 kHz full-duplex operation using DirectSound / WaveIn, if capture buffer is created first.
16.15.823.6 Audio subsystem must support 48.0 kHz full-duplex operation using DirectSound / WaveIn, if capture buffer is created first.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0329, AUD-0324; PC 99 System Design Guide - 17.5, 17.31, 17.32.
Test description: TD-16.6 Full Duplex Test (FDuplex)

16.15.824 – 16.15.828 Note: These test assertions are undefined.
16.15.829 Audio subsystem must support full-duplex operation using DirectSound Hardware Buffers/ WaveIn, if capture buffer is created first.

The test case is only valid for systems supporting playback on DirectSound Hardware Buffers.

16.15.829.1 Note: This test assertion is undefined.
16.15.829.2 Audio subsystem must support 8 kHz full-duplex operation using DirectSound Hardware Buffers/ WaveIn, if capture buffer is created first.

The test case is only valid for systems supporting 8.0 kHz playback on DirectSound Hardware Buffers.

16.15.829.3 Audio subsystem must support 11.025 kHz full-duplex operation using DirectSound Hardware Buffers/ WaveIn, if capture buffer is created first.

The test case is only valid for systems supporting 11.025 kHz playback on DirectSound Hardware Buffers.

16.15.829.4 Audio subsystem must support 22.05 kHz full-duplex operation using DirectSound Hardware Buffers/ WaveIn, if capture buffer is created first.

The test case is only valid for systems supporting 22.05 kHz playback on DirectSound Hardware Buffers.

16.15.829.5 Audio subsystem must support 44.1 kHz full-duplex operation using DirectSound Hardware Buffers/ WaveIn, if capture buffer is created first.

The test case is only valid for systems supporting 44.1 kHz playback on DirectSound Hardware Buffers.

16.15.829.6 – 16.15.829.7 Note: These test assertions are undefined.
16.15.829.8 Audio subsystem must support 48.0 kHz full-duplex operation using DirectSound Hardware Buffers/ WaveIn, if capture buffer is created first.

The test case is only valid for systems supporting 48.0 kHz playback on DirectSound Hardware Buffers,

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0329, AUD-0324; PC 99 System Design Guide - 17.5, 17.31, 17.32.
Test description: TD-16.6 Full Duplex Test (FDuplex)

16.15.830 - 16.15.832 Note: These test assertions are undefined.
16.15.833 Audio subsystem must support 8 kHz full-duplex operation using DirectSound / WaveIn, if playback buffer is created first.
16.15.833.1 Audio subsystem must support 11.025 kHz full-duplex operation using DirectSound / WaveIn if playback buffer is created first.
16.15.833.2 Audio subsystem must support 22.05 kHz full-duplex operation using DirectSound / WaveIn if playback buffer is created first.
16.15.833.3 Audio subsystem must support 44.1 kHz full-duplex operation using DirectSound / WaveIn, if playback buffer is created first.
16.15.33.4 – 16.15.833.5 Note: These test assertions are undefined.
16.15.833.6 Audio subsystem must support 48.0 kHz full-duplex operation using DirectSound / WaveIn, if playback buffer is created first

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0329, AUD-0324; PC 99 System Design Guide - 17.5, 17.31, 17.32.
Test description: TD-16.6 Full Duplex Test (FDuplex)

16.15.834 – 16.15.838 Note: These test assertions are undefined.
16.15.839 Audio subsystem must support full-duplex operation using DirectSound Hardware Buffers/ WaveIn, if playback buffer is created first.

The test case is only valid for systems supporting playback on DirectSound Hardware Buffers.

16.15.839.1 Note: This test assertion is undefined.
16.15.839.2 Audio subsystem must support 8 kHz full-duplex operation using DirectSound Hardware Buffers/ WaveIn, if playback buffer is created first.

The test case is only valid for systems supporting 8.0 kHz playback on DirectSound Hardware Buffers.

16.15.839.3 Audio subsystem must support 11.025 kHz full-duplex operation using DirectSound Hardware Buffers/ WaveIn if playback buffer is created first.

The test case is only valid for systems supporting 11.025 kHz playback on DirectSound Hardware Buffers.

16.15.839.4 Audio subsystem must support 22.05 kHz full-duplex operation using DirectSound Hardware Buffers/ WaveIn if playback buffer is created first.

The test case is only valid for systems supporting 22.05 kHz playback on DirectSound Hardware Buffers.

16.15.839.5 Audio subsystem must support 44.1 kHz full-duplex operation using DirectSound Hardware Buffers/ WaveIn if playback buffer is created first.

The test case is only valid for systems supporting 44.1 kHz playback on DirectSound Hardware Buffers.

16.15.839.6 – 16.15.839.7 Note: These test assertions are undefined.
16.15.839.8 Audio subsystem must support 48.0 kHz full-duplex operation using DirectSound Hardware Buffers/ WaveIn if playback buffer is created first.

The test case is only valid for systems supporting 48.0 kHz playback on DirectSound Hardware Buffers.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0329, AUD-0324; PC 99 System Design Guide - 17.5, 17.31, 17.32.
Test description: TD-16.6 Full Duplex Test (FDuplex)

16.15.840 – 16.15.842 Note: These test assertions are undefined.
16.15.843 Audio subsystem must support 8 kHz full-duplex operation using WaveOut / WaveIn, if capture buffer is created first.

(WaveIn is created with NULL callback).

16.15.843.1 Audio subsystem must support 11.025 kHz full-duplex operation using WaveOut / WaveIn, if capture buffer is created first.

(WaveIn is created with NULL callback).

16.15.843.2 Audio subsystem must support 22.05 kHz full-duplex operation using WaveOut / WaveIn if capture buffer is created first.

(WaveIn is created with NULL callback).

16.15.843.3 Audio subsystem must support 44.1 kHz full-duplex operation using WaveOut / WaveIn if capture buffer is created first.

(WaveIn is created with NULL callback).

16.15.843.4 – 16.15.843.5 Note: These test assertions are undefined.
16.15.843.6 Audio subsystem must support 48.0 kHz full-duplex operation using WaveOut / WaveIn, if capture buffer is created first.

(WaveIn is created with NULL callback).

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0329, AUD-0324; PC 99 System Design Guide - 17.5, 17.31, 17.32.
Test description: TD-16.6 Full Duplex Test (FDuplex)

16.15.844 Audio subsystem must support 8 kHz full-duplex operation using WaveOut / WaveIn if capture buffer is created first.
16.15.844.1 Audio subsystem must support 11.025 kHz full-duplex operation using WaveOut / WaveIn if capture buffer is created first.
16.15.844.2 Audio subsystem must support 22.05 kHz full-duplex operation using WaveOut / WaveIn, if capture buffer is created first.
16..15.844.3 Audio subsystem must support 44.1 kHz full-duplex operation using WaveOut / WaveIn, if capture buffer is created first.
16.15.844.4 – 16.15.844.5 Note: These test assertions are undefined.
16.15.844.6 Audio subsystem must support 48.0 kHz full-duplex operation using WaveOut / WaveIn, if capture buffer is created first.

(WaveIn is created with FUNCTION callback).

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0329, AUD-0324; PC 99 System Design Guide - 17.5, 17.31, 17.32.
Test description: TD-16.6 Full Duplex Test (FDuplex)

16.15.845 Audio subsystem must support 8 kHz full-duplex operation using WaveOut / WaveIn, if capture buffer is created first.

(WaveIn is created with EVENT callback).

16.15.845.1 Audio subsystem must support 11.025 kHz full-duplex operation using WaveOut / WaveIn if capture buffer is created first.

(WaveIn is created with EVENT callback).

16.15.845.2 Audio subsystem must support 22.05 kHz full-duplex operation using WaveOut / WaveIn, if capture buffer is created first.

(WaveIn is created with EVENT callback).

16.15.845.3 Audio subsystem must support 44.1 kHz full-duplex operation using WaveOut / WaveIn, if capture buffer is created first.

(WaveIn is created with EVENT callback).

16.15.845.4 – 16.15.845.5 Note: These test assertions are undefined.
16.15.845.6 Audio subsystem must support 48.0 kHz full-duplex operation using WaveOut / WaveIn, if capture buffer is created first.

(WaveIn is created with EVENT callback).

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0329, AUD-0324; PC 99 System Design Guide - 17.5, 17.31, 17.32.
Test description: TD-16.6 Full Duplex Test (FDuplex)

16.15.846 – 16.15.852 Note: These test assertions are undefined.
16.15.853 Audio subsystem must support 8 kHz full-duplex operation using WaveOut / WaveIn, if playback buffer is created first.

(WaveIn is created with NULL callback).

16.15.853.1 Audio subsystem must support 11.025 kHz full-duplex operation using WaveOut / WaveIn, if playback buffer is created first.

(WaveIn is created with NULL callback).

16.15.853.2 Audio subsystem must support 22.05 kHz full-duplex operation using WaveOut / WaveIn, if playback buffer is created first.

(WaveIn is created with NULL callback).

16.15.853.3 Audio subsystem must support 44.1 kHz full-duplex operation using WaveOut / WaveIn, if playback buffer is created first.

(WaveIn is created with NULL callback).

16.15.853.4 – 16.15.853.5 Note: These test assertions are undefined.
16.15.853.6 Audio subsystem must support 48.0 kHz full-duplex operation using WaveOut / WaveIn, if playback buffer is created first.

(WaveIn is created with NULL callback).

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0329, AUD-0324; PC 99 System Design Guide - 17.5, 17.31, 17.32.
Test description: TD-16.6 Full Duplex Test (FDuplex)

16.15.854 Audio subsystem must support 8 kHz full-duplex operation using WaveOut / WaveIn, if playback buffer is created first.

(WaveIn is created with FUNCTION callback).

16.15.854.1 Audio subsystem must support 11.025kHz full-duplex operation using WaveOut / WaveIn, if playback buffer is created first.

(WaveIn is created with FUNCTION callback).

16.15.854.2 Audio subsystem must support 22.05 kHz full-duplex operation using WaveOut / WaveIn, if playback buffer is created first.

(WaveIn is created with FUNCTION callback).

16.15.854.3 Audio subsystem must support 44.1 kHz full-duplex operation using WaveOut / WaveIn, if playback buffer is created first.

(WaveIn is created with FUNCTION callback).

16.15.854.4 – 16.15.854.5 Note: These test assertions are undefined.
16.15.854.6 Audio subsystem must support 48.0 kHz full-duplex operation using WaveOut / WaveIn, if playback buffer is created first.

(WaveIn is created with FUNCTION callback).

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0329, AUD-0324; PC 99 System Design Guide - 17.5, 17.31, 17.32.
Test description: TD-16.6 Full Duplex Test (FDuplex)

16.15.855 Audio subsystem must support 8kHz full-duplex operation using WaveOut / WaveIn if playback buffer is created first.

(WaveIn is created with EVENT callback).

16.15.855.1 Audio subsystem must support 11.025 kHz full-duplex operation using WaveOut / WaveIn if playback buffer is created first.

(WaveIn is created with EVENT callback).

16.15.855.2 Audio subsystem must support 22.05 kHz full-duplex operation using WaveOut / WaveIn, if playback buffer is created first.

(WaveIn is created with EVENT callback).

16.15.855.3 Audio subsystem must support 44.1 kHz full-duplex operation using WaveOut / WaveIn, if playback buffer is created first.

(WaveIn is created with EVENT callback).

16.15.855.4 – 16.15.855.5 Note: These test assertions are undefined.
16.15.855.6 Audio subsystem must support 48.0 kHz full-duplex operation using WaveOut / WaveIn, if playback buffer is created first.

(WaveIn is created with EVENT callback).

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0329, AUD-0324; PC 99 System Design Guide - 17.5, 17.31, 17.32.
Test description: TD-16.6 Full Duplex Test (FDuplex)

16.15.856 – 16.15.860 Note: These test assertions are undefined.
16.15.861 Audio subsystem must support 8 kHz full-duplex operation using WaveOut / DirectSoundCapture, if capture buffer is created first.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0329, AUD-0324; PC 99 System Design Guide - 17.5, 17.31, 17.32.
Test description: TD-16.6 Full Duplex Test (FDuplex)

16.15.862 Audio subsystem must support 11.025 kHz full-duplex operation using WaveOut / DirectSoundCapture, if capture buffer is created first.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0329, AUD-0324; PC 99 System Design Guide - 17.5, 17.31, 17.32.
Test description: TD-16.6 Full Duplex Test (FDuplex)

16.15.863 Audio subsystem must support 22.05 kHz full-duplex operation using WaveOut / DirectSoundCapture, if capture buffer is created first.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0329, AUD-0324; PC 99 System Design Guide - 17.5, 17.31, 17.32.
Test description: TD-16.6 Full Duplex Test (FDuplex)

16.15.864 Audio subsystem must support 44.1kHz full-duplex operation using WaveOut / DirectSoundCapture if capture buffer is created first.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0329, AUD-0324; PC 99 System Design Guide - 17.5, 17.31, 17.32.
Test description: TD-16.6 Full Duplex Test (FDuplex)

16.15.864.1 – 16.15.864.2 Note: These test assertions are undefined.
16.15.864.3 Audio subsystem must support 48.0kHz full-duplex operation using WaveOut / DirectSoundCapture, if capture buffer is created first.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0329, AUD-0324; PC 99 System Design Guide - 17.5, 17.31, 17.32.
Test description: TD-16.6 Full Duplex Test (FDuplex)

16.15.865 – 16.15.870 Note: These test assertions are undefined.
16.15.871 Audio subsystem must support 8 kHz full-duplex operation using WaveOut / DirectSoundCapture, if playback buffer is created first.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0329, AUD-0324; PC 99 System Design Guide - 17.5, 17.31, 17.32.
Test description: TD-16.6 Full Duplex Test (FDuplex)

16.15.872 Audio subsystem must support 11.025 kHz full-duplex operation using WaveOut / DirectSoundCapture, if playback buffer is created first.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0329, AUD-0324; PC 99 System Design Guide - 17.5, 17.31, 17.32.
Test description: TD-16.6 Full Duplex Test (FDuplex)

16.15.873 Audio subsystem must support 22.05kHz full-duplex operation using WaveOut / DirectSoundCapture if playback buffer is created first.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0329, AUD-0324; PC 99 System Design Guide - 17.5, 17.31, 17.32.
Test description: TD-16.6 Full Duplex Test (FDuplex)

16.15.874 Audio subsystem must support 44.1 kHz full-duplex operation using WaveOut / DirectSoundCapture, if playback buffer is created first.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0329, AUD-0324; PC 99 System Design Guide - 17.5, 17.31, 17.32.
Test description: TD-16.6 Full Duplex Test (FDuplex)

16.15.874.1 – 16.15.874.2 Note: These test assertions are undefined.
16.15.874.3 Audio subsystem must support 48.0 kHz full-duplex operation using WaveOut / DirectSoundCapture, if playback buffer is created first.

Reference document: WLP# B3.1.4; PC 2001 System Design Guide - AUD-0329, AUD-0324; PC 99 System Design Guide - 17.5, 17.31, 17.32.
Test description: TD-16.6 Full Duplex Test (FDuplex)

Note: Test assertions 16.16.x through 16.29.x are undefined.


Audio Quality Test Assertions

These assertions are no longer tested as the TD-16.7 Audio Quality Test is obsolete.

The Audio Quality test assertions are tested in TD-16.7 Audio Quality Test (AUDQLTY).

16.30.1 Analog-to-Analog pass-through (A-A) at –3dB LineIn-LineOut Frequency Response must be between 20Hz-20Khz, inclusive.

Mobile PCs must have Frequency Response between 20Hz-15Khz, inclusive.

Reference document: WLP# B3.1.4.4; PC 2001 System Design Guide - AUD-0329; PC 99 System Design Guide - 17.4.
Test description: TD-16.7 Audio Quality Test (AUDQLTY)

16.30.2 Analog-to-Analog pass-through (A-A) LineIn-LineOut Dynamic Range must be greater than or equal to 80dB FS A-weighted.

Mobile PCs must have Dynamic Range greater than or equal to 70dB FS A.

Reference document: WLP# B3.1.4.4; PC 2001 System Design Guide - AUD-0329; PC 99 System Design Guide - 17.4.
Test description: TD-16.7 Audio Quality Test (AUDQLTY)

16.30.3 Analog-to-Analog pass-through (A-A) LineIn-LineOut THD+N must be less than or equal to –65dB FS.

Mobile PCs must have THD+N less than or equal to -55dB FS.

Reference document: WLP# B3.1.4.4; PC 2001 System Design Guide - AUD-0329; PC 99 System Design Guide - 17.4.
Test description: TD-16.7 Audio Quality Test (AUDQLTY)

16.30.4 Analog-to-Analog pass-through (A-A) MicIn-LineOut at –3dB Frequency Response must be between 100Hz-12kHz, inclusive.

Reference document: WLP# B3.1.4.4; PC 2001 System Design Guide - AUD-0329; PC 99 System Design Guide - 17.4.
Test description: TD-16.7 Audio Quality Test (AUDQLTY)

16.30.5 Analog-to-Analog pass-through (A-A) MicIn-LineOut Dynamic Range must be greater than or equal to 70dB FS A-weighted.

Mobile PCs must have Dynamic Range greater than or equal to 60dB FS A.

Reference document: WLP# B3.1.4.4; PC 2001 System Design Guide - AUD-0329; PC 99 System Design Guide - 17.4.
Test description: TD-16.7 Audio Quality Test (AUDQLTY)

16.30.6 Analog-to-Analog pass-through (A-A) MicIn-LineOut THD+N must be less than or equal to –60dB FS.

Mobile PCs must have THD+N less than or equal to –50dB FS.

Reference document: WLP# B3.1.4.4; PC 2001 System Design Guide - AUD-0329; PC 99 System Design Guide - 17.4.
Test description: TD-16.7 Audio Quality Test (AUDQLTY)

16.30.7 Digital-to-Analog (PC-D-A) LineOut at –3dB Frequency Response must be between 20Hz-17.6kHz, inclusive.

Mobile PCs must have Frequency Response between 20Hz-15kHz, inclusive.

Reference document: WLP# B3.1.4.4; PC 2001 System Design Guide - AUD-0329; PC 99 System Design Guide - 17.4.
Test description: TD-16.7 Audio Quality Test (AUDQLTY)

16.30.8 Digital-to-Analog (PC-D-A) LineOut Dynamic Range must be greater than or equal to 80dB FS A-weighted.

Mobile PCs must have Dynamic Range greater than or equal to 70dB FS A.

Reference document: WLP# B3.1.4.4; PC 2001 System Design Guide - AUD-0329; PC 99 System Design Guide - 17.4.
Test description: TD-16.7 Audio Quality Test (AUDQLTY)

16.30.9 Digital-to-Analog (PC-D-A) LineOut THD+N must be less than or equal to -65dB FS.

Mobile PCs must have THD+N less than or equal to –55dB FS.

Reference document: WLP# B3.1.4.4; PC 2001 System Design Guide - AUD-0329; PC 99 System Design Guide - 17.4.
Test description: TD-16.7 Audio Quality Test (AUDQLTY)

16.30.10 Analog-to-Digital (A-D-PC) LineIn at –3dB Frequency Response must be between 20Hz-17.6kHz, inclusive.

Mobile PCs must have Frequency Response between 20Hz-15kHz, inclusive.

Reference document: WLP# B3.1.4.4; PC 2001 System Design Guide - AUD-0329; PC 99 System Design Guide - 17.4.
Test description: TD-16.7 Audio Quality Test (AUDQLTY)

16.30.11 Analog-to-Digital (A-D-PC) LineIn Dynamic Range must be greater than or equal to 70dB FS A-weighted.

Mobile PCs must have Dynamic Range greater than or equal to 60dB FS A.

Reference document: WLP# B3.1.4.4; PC 2001 System Design Guide - AUD-0329; PC 99 System Design Guide - 17.4.
Test description: TD-16.7 Audio Quality Test (AUDQLTY)

16.30.12 Analog-to-Digital (A-D-PC) LineIn THD+N must be less than or equal to -60dB FS.

Mobile PCs must have THD+N less than or equal to –50dB FS.

Reference document: WLP# B3.1.4.4; PC 2001 System Design Guide - AUD-0329; PC 99 System Design Guide - 17.4.
Test description: TD-16.7 Audio Quality Test (AUDQLTY)

16.30.13 Analog-to-Digital (A-D-PC) MicIn at –3dB Frequency Response must be between 100Hz-8.8kHz, inclusive.

Reference document: WLP# B3.1.4.4; PC 2001 System Design Guide - AUD-0329; PC 99 System Design Guide - 17.4.
Test description: TD-16.7 Audio Quality Test (AUDQLTY)

16.30.14 Analog-to-Digital (A-D-PC) MicIn Dynamic Range must be greater than 70dB FS A-weighted.

Mobile PCs must have Dynamic Range greater than or equal to 60dB FS A.

Reference document: WLP# B3.1.4.4; PC 2001 System Design Guide - AUD-0329; PC 99 System Design Guide - 17.4.
Test description: TD-16.7 Audio Quality Test (AUDQLTY)

16.30.15 Analog-to-Digital (A-D-PC) MicIn THD+N must be less than or equal to –60dB FS.

Mobile PCs must have THD+N less than or equal to –50dB FS.

Reference document: WLP# B3.1.4.4; PC 2001 System Design Guide - AUD-0329; PC 99 System Design Guide - 17.4.
Test description: TD-16.7 Audio Quality Test (AUDQLTY)

16.30.16 Analog-to-Analog (A-A) LineIn-LineOut Cross-talk (left/right channel separation measured at 10 kHz) must be greater than or equal to 60dB.

Mobile PCs must be greater than or equal to 50dB.

Reference document: WLP# B3.1.4.4; PC 2001 System Design Guide - AUD-0329; PC 99 System Design Guide - 17.4.
Test description: TD-16.7 Audio Quality Test (AUDQLTY)

16.30.17 Analog-to-Analog (A-A) MicIn-LineOut Cross-talk (left/right channel separation measured at 10 kHz) must be greater than or equal to 60dB.

Mobile PCs must be greater than or equal to 50dB.

Reference document: WLP# B3.1.4.4; PC 2001 System Design Guide - AUD-0329; PC 99 System Design Guide - 17.4.
Test description: TD-16.7 Audio Quality Test (AUDQLTY)


PC 99 Audio Device Test Assertions

The PC 99 Audio Device test assertions are tested in TD-16.8 Audio PC 99 Audio Device Test (PC99Aud).

16.31.1 Audio driver must contain either WaveCyclic or WavePCI miniport.

Reference document: WLP# - B3.1; PC 99 System Design Guide, Sections 17.2 and 17.31.
Test description: TD-16.8 Audio PC 99 Audio Device Test (PC99Aud)

16.31.2 If the audio device is connected to the PCI bus, the audio driver must be enumerated by the PCI bus.

Reference document: WLP# - B3.1; PC 99 System Design Guide, Section 17.20.
Test description: TD-16.8 Audio PC 99 Audio Device Test (PC99Aud)

16.31.3 – 16.31.5 Note: These test assertions are undefined.
16.31.6 Audio subsystem must support 44.1 kHz playback.

Reference document: WLP# - B3.1; PC 99 System Design Guide, Section 17.5.1.
Test description: TD-16.8 Audio PC 99 Audio Device Test (PC99Aud)

16.31.7 Audio subsystem must support 48 kHz playback.

Reference document: WLP# - B3.1; PC 99 System Design Guide, Section 17.5.1.
Test description: TD-16.8 Audio PC 99 Audio Device Test (PC99Aud)

16.31.8 Audio subsystem must support 44.1 kHz capture.

Reference document: WLP# - B3.1; PC 99 System Design Guide, Section 17.5.2.
Test description: TD-16.8 Audio PC 99 Audio Device Test (PC99Aud)

16.31.9 Audio subsystem must support 48 kHz capture.

Reference document: WLP# - B3.1; PC 99 System Design Guide, Section 17.5.2.
Test description: TD-16.8 Audio PC 99 Audio Device Test (PC99Aud)

16.31.10 Audio subsystem must support 44.1 kHz full-duplex operation, if playback buffer is created first.

Reference document: WLP# - B3.1; PC 99 System Design Guide, Sections 17.5 and 17.32.
Test description: TD-16.8 Audio PC 99 Audio Device Test (PC99Aud)

16.31.11 Audio subsystem must support 44.1 kHz full-duplex operation, if capture buffer is created first.

Reference document: WLP# - B3.1; PC 99 System Design Guide, Sections 17.5 and 17.32.
Test description: TD-16.8 Audio PC 99 Audio Device Test (PC99Aud)

16.31.12 Audio subsystem must support 48 kHz full-duplex operation, if playback buffer is created first.

Reference document: WLP# - B3.1; PC 99 System Design Guide, Sections 17.5 and 17.32.
Test description: TD-16.8 Audio PC 99 Audio Device Test (PC99Aud)

16.31.13 Audio subsystem must support 48 kHz full-duplex operation, if capture buffer is created first.

Reference document: WLP# - B3.1; PC 99 System Design Guide, Sections 17.5 and 17.32.
Test description: TD-16.8 Audio PC 99 Audio Device Test (PC99Aud)

16.31.14 Audio subsystem must support 44.1 kHz- and 48 kHz full-duplex operation at independent sample rates, if playback buffer is created first.

Reference document: WLP# - B3.1; PC 99 System Design Guide, Sections 17.5 and 17.6.
Test description: TD-16.8 Audio PC 99 Audio Device Test (PC99Aud)

16.31.15 Audio subsystem must support 44.1 kHz and 48 KHz full-duplex operation at independent sample rates, if capture buffer is created first.

Reference document: WLP# - B3.1; PC 99 System Design Guide, Sections 17.5 and 17.6.
Test description: TD-16.8 Audio PC 99 Audio Device Test (PC99Aud)

16.31.16 – 16.31.28 Note: These test assertions are undefined.
16.31.29 Audio subsystem must support playback at all supported formats.

Reference document: WLP# - B3.1; PC 99 System Design Guide, Sections 17.5.1 and 17.32.
Test description: TD-16.8 Audio PC 99 Audio Device Test (PC99Aud)

16.31.30 Audio subsystem must support capture at all supported formats.

Reference document: WLP# - B3.1; PC 99 System Design Guide, Sections 17.5.2 and 17.32.
Test description: TD-16.8 Audio PC 99 Audio Device Test (PC99Aud)


Audio KsPosTst Test Assertions

The KsPosTst test assertions are tested in TD-16.10 KS Audio Position Accuracy Test (KsPosTst).

16.32.1 The audio rendering device must be able to start playing audio data within 15 ms from when the render pin is set to the run state.

This is determined by the time delta from when the pin is set to the run state, and when the value of the reported audio position becomes non-zero. The first non-zero value is converted to time, based on the wave format, and subtracted from the delta.

Reference document: WLP# B3.1.4.7; PC 2001 System Design Guide - AUD-0326, AUD-0334
Test description: TD-16.10 KS Audio Position Accuracy Test (KsPosTst)

16.32.2 The audio rendering device must stream the correct number of bytes of data over the correct time interval, within a 1% tolerance.

The duration is measured from the time that the pin is to the run state to when the stream IRP is completed. The byte length is determined by getting the position of the stream after the IRP is completed.

Reference document: WLP# B3.1.4.7; PC 2001 System Design Guide - AUD-0326, AUD-0334
Test description: TD-16.10 KS Audio Position Accuracy Test (KsPosTst)

16.32.3 While rendering data, the stream position reported must increase monotonically, i.e. the stream position must never go backwards.

Also, the write cursor must always be ahead of the play cursor.

Reference document: WLP# B3.1.4.7; PC 2001 System Design Guide - AUD-0326, AUD-0334
Test description: TD-16.10 KS Audio Position Accuracy Test (KsPosTst)

16.32.4 A histogram of position vs. time while rendering a stream must progress linearly.

The sample rate calculated from this histogram (the slope of a least-squares best fit) must be within 1% of the specified sample rate. Deviations from linearity must be within the following tolerances: max < 4 ms, standard deviation < 1 ms.

Reference document: WLP# B3.1.4.7; PC 2001 System Design Guide - AUD-0326, AUD-0334
Test description: TD-16.10 KS Audio Position Accuracy Test (KsPosTst)

16.32.5 The audio capturing device must be able to start recording audio data within 15 ms from when the capture pin is set to the run state.

This is determined by the time delta from when the pin is set to the run state, and when the value of the reported audio position becomes non-zero. The first non-zero value is converted to time, based on the wave format, and subtracted from the delta.

Reference document: WLP# B3.1.4.7; PC 2001 System Design Guide - AUD-0326, AUD-0334
Test description: TD-16.10 KS Audio Position Accuracy Test (KsPosTst)

16.32.6 The audio capturing device must capture the correct number of bytes of data over the correct time interval, within a 1% tolerance.

The duration is measured from the time that the pin is to the run state to when the stream IRP is completed. The byte length is determined by getting the position of the stream after the IRP is completed.

Reference document: WLP# B3.1.4.7; PC 2001 System Design Guide - AUD-0326, AUD-0334
Test description: TD-16.10 KS Audio Position Accuracy Test (KsPosTst)

16.32.7 While capturing data, the stream position reported must increase monotonically, i.e. the stream position must never go backwards.

Reference document: WLP# B3.1.4.7; PC 2001 System Design Guide - AUD-0326, AUD-0334
Test description: TD-16.10 KS Audio Position Accuracy Test (KsPosTst)

16.32.8 A histogram of position vs. time while capturing a stream must progress linearly.

The sample rate calculated from this histogram (the slope of a least-squares best fit) must be within 1% of the specified sample rate. Deviations from linearity must be within the following tolerances: max < 4 ms, standard deviation < 1 ms.

Reference document: WLP# B3.1.4.7; PC 2001 System Design Guide - AUD-0326, AUD-0334
Test description: TD-16.10 KS Audio Position Accuracy Test (KsPosTst)


KSDMTst Test Assertions

The KSDMTst test assertions are tested in TD-16.11 KS DirectMusic Filter Test (KSDMTst.exe) Description.

16.33.1 Verifies that a DirectMusicFilter, which claims support for KSPROPSETID_Synth\KSPROPERTY_SYNTH_VOLUME, supports BasicSupport, Get, and Set operations correctly

Reference document: WLP# B3.1.1
Test description: TD-16.11 KS DirectMusic Filter Test (KSDMTst.exe) Description

16.33.2 Verifies that a DirectMusicFilter, which claims support for KSPROPSETID_Synth\KSPROPERTY_SYNTH_VOLUMEBOOST, supports BasicSupport, Get, and Set operations correctly.

Reference document: WLP# B3.1.1
Test description: TD-16.11 KS DirectMusic Filter Test (KSDMTst.exe) Description

16.33.3 Verifies that a DirectMusicFilter, which claims support for KSPROPSETID_Synth\KSPROPERTY_SYNTH_CAPS, supports BasicSupport, Get, and Set operations correctly.

Reference document: WLP# B3.1.1
Test description: TD-16.11 KS DirectMusic Filter Test (KSDMTst.exe) Description

16.33.4 Verifies that a DirectMusicFilter, which claims support for KSPROPSETID_Synth\KSPROPERTY_SYNTH_PORTPARAMETERS, supports BasicSupport, Get, and Set operations correctly.

Reference document: WLP# B3.1.1
Test description: TD-16.11 KS DirectMusic Filter Test (KSDMTst.exe) Description

16.33.5 Verifies that a DirectMusicFilter, which claims support for KSPROPSETID_Synth\KSPROPERTY_SYNTH_CHANNELGROUPS, supports BasicSupport, Get, and Set operations correctly.

Reference document: WLP# B3.1.1
Test description: TD-16.11 KS DirectMusic Filter Test (KSDMTst.exe) Description

16.33.6 Verifies that a DirectMusicFilter, which claims support for KSPROPSETID_Synth\KSPROPERTY_SYNTH_VOICEPRIORITY, supports BasicSupport, Get, and Set operations correctly.

Reference document: WLP# B3.1.1
Test description: TD-16.11 KS DirectMusic Filter Test (KSDMTst.exe) Description

16.33.7 Verifies that a DirectMusicFilter, which claims support for KSPROPSETID_Synth\KSPROPERTY_SYNTH_LATENCYCLOCK, supports BasicSupport, Get, and Set operations correctly.

Reference document: WLP# B3.1.1
Test description: TD-16.11 KS DirectMusic Filter Test (KSDMTst.exe) Description

16.33.8 Verifies that a DirectMusicFilter, which claims support for KSPROPSETID_Synth\KSPROPERTY_SYNTH_RUNNINGSTATS, supports BasicSupport, Get, and Set operations correctly.

Reference document: WLP# B3.1.1
Test description: TD-16.11 KS DirectMusic Filter Test (KSDMTst.exe) Description

16.33.9 Verifies that a DirectMusicFilter, which claims support for KSPROPSETID_Synth\KSPROPERTY_SYNTH_RUNNINGSTATS, supports BasicSupport, Get, and Set operations correctly.

Reference document: WLP# B3.1.1
Test description: TD-16.11 KS DirectMusic Filter Test (KSDMTst.exe) Description

16.33.10 Verifies that a DirectMusicFilter, which claims support for KSPROPSETID_Synth_Dls\KSPROPERTY_SYNTH_DOWNLOAD and KSPROPERTY_SYNTH_UNLOAD, supports BasicSupport, Get, and Set operations correctly.

Reference document: WLP# B3.1.1
Test description: TD-16.11 KS DirectMusic Filter Test (KSDMTst.exe) Description

16.33.11 Verifies that a DirectMusicFilter, which claims support for KSPROPSETID_Synth_Dls\KSPROPERTY_SYNTH_COMPACT , supports BasicSupport, Get, and Set operations correctly.

Reference document: WLP# B3.1.1
Test description: TD-16.11 KS DirectMusic Filter Test (KSDMTst.exe) Description

16.33.12 Verifies that a DirectMusicFilter, which claims support for KSPROPSETID_Synth_Dls\KSPROPERTY_SYNTH_APPEND, supports BasicSupport, Get, and Set operations correctly.

Reference document: WLP# B3.1.1
Test description: TD-16.11 KS DirectMusic Filter Test (KSDMTst.exe) Description

16.33.13 Verifies that a DirectMusicFilter, which claims support for KSPROPSETID_Synth_Dls\KSPROPERTY_WAVEFORMAT, supports BasicSupport, Get, and Set operations correctly.

Reference document: WLP# B3.1.1
Test description: TD-16.11 KS DirectMusic Filter Test (KSDMTst.exe) Description

16.33.14 Verifies that a DirectMusicFilter, which claims support for GUID_DMUS_PROP_GM_Hardware\0, supports BasicSupport, Get, and Set operations correctly.

Reference document: WLP# B3.1.1
Test description: TD-16.11 KS DirectMusic Filter Test (KSDMTst.exe) Description

16.33.15 Verifies that a DirectMusicFilter, which claims support for GUID_DMUS_PROP_GS_Hardware\0, supports BasicSupport, Get, and Set operations correctly.

Reference document: WLP# B3.1.1
Test description: TD-16.11 KS DirectMusic Filter Test (KSDMTst.exe) Description

16.33.16 Verifies that a DirectMusicFilter, which claims support for GUID_DMUS_PROP_XG_Hardware\0, supports BasicSupport, Get, and Set operations correctly.

Reference document: WLP# B3.1.1
Test description: TD-16.11 KS DirectMusic Filter Test (KSDMTst.exe) Description

16.33.17 Verifies that a DirectMusicFilter, which claims support for GUID_DMUS_PROP_XG_Capable\0, supports BasicSupport, Get, and Set operations correctly.

Reference document: WLP# B3.1.1
Test description: TD-16.11 KS DirectMusic Filter Test (KSDMTst.exe) Description

16.33.18 Verifies that a DirectMusicFilter, which claims support for GUID_DMUS_PROP_GS_Capable\0, supports BasicSupport, Get, and Set operations correctly.

Reference document: WLP# B3.1.1
Test description: TD-16.11 KS DirectMusic Filter Test (KSDMTst.exe) Description

16.33.19 Verifies that a DirectMusicFilter, which claims support for GUID_DMUS_PROP_DLS1\0, supports BasicSupport, Get, and Set operations correctly.

Reference document: WLP# B3.1.1
Test description: TD-16.11 KS DirectMusic Filter Test (KSDMTst.exe) Description

16.33.20 Verifies that a DirectMusicFilter, which claims support for GUID_DMUS_PROP_DLS2\0, supports BasicSupport, Get, and Set operations correctly.

Reference document: WLP# B3.1.1
Test description: TD-16.11 KS DirectMusic Filter Test (KSDMTst.exe) Description

16.33.21 Verifies that a DirectMusicFilter, which claims support for GUID_DMUS_PROP_INSTRUMENT2\0, supports BasicSupport, Get, and Set operations correctly.

Reference document: WLP# B3.1.1
Test description: TD-16.11 KS DirectMusic Filter Test (KSDMTst.exe) Description

16.33.22 Verifies that a DirectMusicFilter, which claims support for GUID_DMUS_PROP_Effects\0, supports BasicSupport, Get, and Set operations correctly.

Reference document: WLP# B3.1.1
Test description: TD-16.11 KS DirectMusic Filter Test (KSDMTst.exe) Description

16.33.23 DirectMusic filter must be capable of rendering and capturing MIDI data as appropriate.

Reference document: WLP# B3.1.1
Test description: TD-16.11 KS DirectMusic Filter Test (KSDMTst.exe) Description

16.33.24 DirectMusicfilter must be capable of gracefully handling invalid MIDI and DLS data.

Reference document: WLP# B3.1.1
Test description: TD-16.11 KS DirectMusic Filter Test (KSDMTst.exe) Description

16.33.25 DirectMusic filter must be capable of handling properties sent with bad buffers, incorrectly sized buffers, and invalid data.

Reference document: WLP# B3.1.1
Test description: TD-16.11 KS DirectMusic Filter Test (KSDMTst.exe) Description

16.33.26 DirectMusic filter must be capable of handling rapid changes of pin state, DLS downloading and unloading, rendering and capturing of MIDI data.

Reference document: WLP# B3.1.1
Test description: TD-16.11 KS DirectMusic Filter Test (KSDMTst.exe) Description


DMDrv Test Assertions

The DMDrv test assertions are tested in TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description.

16.34.1 Verifies that a synth can play a MIDI file.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.2 Verifies that a synth can play a MIDI file with reverb enabled, if supported.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.3 Verifies that a synth can play a MIDI file after the Band is unloaded.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.4 Downloads and Unloads instruments and then plays a MIDI file.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.5 Verifies that a synth can download/unload DLS data.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.6 Verifies that a synth can handle KSPROPERTY_SYNTH_DLS_COMPACT properly, if supported.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.7 Verifies that a synth can handle DLS download and unloading while it’s playing MIDI data.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.8 Verifies that a synth can handle GM voice and custom voice overlapping.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.9 Verifies that a synth can handle download of DLS data containing instrument copyrights.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.10 Verifies that a synth can handle download of DLS data containing wave copyrights.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.11 Verifies that a synth can handle a download of DLS data containing both instrument and wave copyrights.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.12 Verifies that a port can support multiple output instances, if it supports output.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.13 Verifies that a port can support multiple input instances, if it supports input.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.14 Verifies that a port does not introduce an excessive amount of latency ~100ms, when playing data.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.15 Verifies that a port can return its output capabilities, if it’s capable of output.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.16 Verifies that a port can return its input capabilities, it it’s capable of input.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.17 Verifies that a port can return its maximum Voices capability.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.18 Verifies that a port can return its maximum ChannelGroup capability.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.19 Verifies that a port can return its maximum audio channels capability.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.20 Verifies that a port can return its effect support for reverb.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.21 Verifies that a port can return its effect support for chorus.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.22 Verifies that a port can support 11.025kHz, mono.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.23 Verifies that a synth can support 11.025kHz, stereo.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.24 Verifies that a synth can support 22.050kHz, mono.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.25 Verifies that a synth can support 22.050kHz, stereo.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.26 Verifies that a synth can support 44.100kHz, mono.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.27 Verifies that a synth can support 44.100kHz, stereo.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.28 Verifies that a synth can toggle reverb on/off while playing, if reverb is supported.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.29 Verifies that a synth can toggle chorus on/off while playing, if chorus is supported.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.75 Verifies that we can get, increase, and decrease volume via GUID_DMUS_PROP_Volume, if it claims to be supported.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.76 See 16.34.75
16.34.77 See 16.34.75
16.34.78 Verifies that we can get and set GUID_DMUS_PROP_WriteLatency, if it claims to be supported.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.79 See 16.34.78
16.34.80 Verifies that we can get and set GUID_DMUS_PROP_WritePeriod, if it claims to be supported.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.81 See 16.34.80
16.34.82 Verifies that we can get, increase, and decrease volume via KSPROPERTY_SYNTH_VOLUME, if it claims to be supported.

Reference document: WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.83 See 16.34.82
16.34.84 See 16.34.82


AC3Test Test Assertions

The AC3Test test assertions are tested in TD-16.13 AC-3 Driver (AC3Test.exe)Test Description.

16.35.1 Pins that report support for AC-3 must have a KSDATARANGE_AUDIO that indicates support for 48KHz, 16-bit, stereo, WAVE_FORMAT_DOLBY_AC3_SPDIF (0x92).

Reference document: WLP# B3.1.1
Test description: TD-16.13 AC-3 Driver (AC3Test.exe)Test Description

16.35.2 Pins that report support for AC-3 must have dataranges for both KSDATAFORMAT_SPECIFIER_WAVEFORMATEX and KSDATAFORMAT_SPECIFIER_DSOUND. The pin must be instantiable using either of these format specifiers.

Reference document: WLP# B3.1.1
Test description: TD-16.13 AC-3 Driver (AC3Test.exe)Test Description

16.35.3 The number of times that a pin may be instantiated must agree with the value returned by KSPROPERTY_PIN_CINSTANCES.

Reference document: WLP# B3.1.1
Test description: TD-16.13 AC-3 Driver (AC3Test.exe)Test Description

16.35.4 AC-3 pins must be able to successfully accept and render AC-3 data

Reference document: WLP# B3.1.1
Test description: TD-16.13 AC-3 Driver (AC3Test.exe)Test Description

16.35.5 AC-3 pins must be able to successfully transition between KSSTATE_RUN and KSSTATE_PAUSE repeatedly.

Reference document: WLP# B3.1.1
Test description: TD-16.13 AC-3 Driver (AC3Test.exe)Test Description

16.35.6 AC-3 pins must support "GET" calls to KSPROPERTY_AUDIO_POSITION while the pin is in the "RUN" state. Furthermore, the position reported by this property handler must increase with each successive call until the stream is stopped.

Reference document:
Test description: TD-16.13 AC-3 Driver (AC3Test.exe)Test Description

16.35.7 AC-3 pins must support "SET" calls to KSPROPERTY_AUDIO_POSITION while the pin is in the "RUN" state. The pin must be able to handle many calls to this property handler made in rapid succession. Furthermore, the value returned by a "GET" call must agree with the value passed to a "SET" call which immediately precedes it.

Reference document: WLP# B3.1.1
Test description: TD-16.13 AC-3 Driver (AC3Test.exe)Test Description

16.35.8 An AC-3 pin must be exposable through the waveOut API. waveOutOpen must succeed on the corresponding wave device using a format of 48KHz, 16-bit, stereo, WAVE_FORMAT_DOLBY_AC3_SPDIF (0x92).

Reference document: WLP# B3.1.1
Test description: TD-16.13 AC-3 Driver (AC3Test.exe)Test Description

16.35.9 The number of times that the waveOut device may be opened must agree with the value returned by the corresponding AC-3 pin for KSPROPERTY_PIN_CINSTANCES.

Reference document: WLP# B3.1.1
Test description: TD-16.13 AC-3 Driver (AC3Test.exe)Test Description

16.35.10 The waveOut device must accept AC-3 data (48KHz, 16-bit, stereo, WAVE_FORMAT_DOLBY_AC3_SPDIF (0x92)).

Reference document: WLP# B3.1.1
Test description: TD-16.13 AC-3 Driver (AC3Test.exe)Test Description

16.35.11 The waveOut device must behave correctly under multiple calls to waveOutPause and waveOutRestart made in rapid succession.

Reference document: WLP# B3.1.1
Test description: TD-16.13 AC-3 Driver (AC3Test.exe)Test Description

16.35.12 The position reported by the AC-3 device must be 0 after calling waveOutReset.

Reference document: WLP# B3.1.1
Test description: TD-16.13 AC-3 Driver (AC3Test.exe)Test Description

16.35.13 The driver must do nothing to prevent the successful operation of waveOutGetPosition. Specifically, successive calls to waveOutGetPosition must return successively increasing values.

Reference document: WLP# B3.1.1
Test description: TD-16.13 AC-3 Driver (AC3Test.exe)Test Description

16.35.14 The AC-3 pin must be exposable through the DirectSound API. IDirectSound::CreateSoundBuffer must succeed using a format of 48KHz, 16-bit, stereo, WAVE_FORMAT_DOLBY_AC3_SPDIF (0x92)

Reference document: WLP# B3.1.1
Test description: TD-16.13 AC-3 Driver (AC3Test.exe)Test Description

16.35.15 The number of times that the DirectSoundBuffer object may be duplicated must agree with the value returned by the corresponding AC-3 pin for KSPROPERTY_PIN_CINSTANCES.

Reference document: WLP# B3.1.1
Test description: TD-16.13 AC-3 Driver (AC3Test.exe)Test Description

16.35.16 IDirectSoundBuffer::Play must succeed on a DirectSoundBuffer object corresponding to the AC-3 pin.

Reference document: WLP# B3.1.1
Test description: TD-16.13 AC-3 Driver (AC3Test.exe)Test Description

16.35.17 IDirectSoundBuffer::Stop must succeed for a running stream on a DirectSoundBuffer object corresponding to the AC-3 pin.

Reference document: WLP# B3.1.1
Test description: TD-16.13 AC-3 Driver (AC3Test.exe)Test Description

16.35.18 GetCurrentPosition and SetCurrentPosition methods must succeed on a IDirectSoundBuffer interface corresponding to a running AC-3 pin.

Reference document: WLP# B3.1.1
Test description: TD-16.13 AC-3 Driver (AC3Test.exe)Test Description

16.35.19 GetPan and SetPan methods must succeed on a IDirectSoundBuffer interface if the corresponding AC-3 filter has the appropriate KSNODETYPE_VOLUME nodes in its topology. If the appropriate nodes are not present, then these methods must fail.

Reference document: WLP# B3.1.1
Test description: TD-16.13 AC-3 Driver (AC3Test.exe)Test Description

16.35.20 GetVolume and SetVolume methods must succeed on a IDirectSoundBuffer interface if the corresponding AC-3 filter has the appropriate KSNODETYPE_VOLUME nodes in its topology. If the appropriate nodes are not present, then these methods must fail.

Reference document: WLP# B3.1.1
Test description: TD-16.13 AC-3 Driver (AC3Test.exe)Test Description

16.35.21 IDirectSoundBuffer::GetStatus must succeed for a running stream on a DirectSoundBuffer object corresponding to the AC-3 pin. Furthermore, the status reported must indicate DSBSTATUS_LOCHARDWARE.

Reference document: WLP# B3.1.1
Test description: TD-16.13 AC-3 Driver (AC3Test.exe)Test Description


GFX Test Assertions

16.36.1 Must be able to open and insert the GFX into the graph.

Reference document: WLP# B3.1.1
Test description: TD-16.35 GFX (gfxtest.exe) Test Description

16.36.2 Must be able to play audio through the GFX, while exercising KS properties, events, and methods.

Reference document: WLP# B3.1.1
Test description: TD-16.35 GFX (gfxtest.exe) Test Description

16.36.3 Must be DRM-compliant.

Reference document: WLP# B3.1.1
Test description: TD-16.35 GFX (gfxtest.exe) Test Description

16.36.4 Must support the required KS dataranges.

Reference document: WLP# B3.1.1
Test description: TD-16.35 GFX (gfxtest.exe) Test Description

16.36.100 addplayremoveplay_defaultzone.

Reference document: WLP# B3.1.1
Test description: TD-16.35 GFX (gfxtest.exe) Test Description

16.36.101 A GFX must not cause a fault/hang when playing data through the default audio device.

Reference document: WLP# B3.1.1
Test description: TD-16.35 GFX (gfxtest.exe) Test Description

16.36.102 A GFX must not cause a fault/hang when added to the graph while data is playing through the default audio device.

Reference document: WLP# B3.1.1
Test description: TD-16.35 GFX (gfxtest.exe) Test Description

16.36.103 A GFX must not cause a fault/hang when removed from the graph while data is playing through the default audio device.

Reference document: WLP# B3.1.1
Test description: TD-16.35 GFX (gfxtest.exe) Test Description

16.36.104 A GFX must not cause a fault/hang when added to and removed from the graph while data is playing through the default audio device.

Reference document: WLP# B3.1.1
Test description: TD-16.35 GFX (gfxtest.exe) Test Description

16.36.105 A GFX must not cause a fault/hang when playing data through it.

Reference document: WLP# B3.1.1
Test description: TD-16.35 GFX (gfxtest.exe) Test Description

16.36.106 A GFX must not cause a fault/hang when added to the graph while data is playing through that graph.

Reference document: WLP# B3.1.1
Test description: TD-16.35 GFX (gfxtest.exe) Test Description

16.36.107 A GFX must not cause a fault/hang when removed from the graph while data is playing through that graph.

Reference document: WLP# B3.1.1
Test description: TD-16.35 GFX (gfxtest.exe) Test Description

16.36.108 A GFX must not cause a fault/hang when added to and removed from the graph while data is playing through that graph.

Reference document: WLP# B3.1.1
Test description: TD-16.35 GFX (gfxtest.exe) Test Description


Audio Test Descriptions

This section describes the audio device and driver tests. Test descriptions include a description of each test, set up requirements, and results interpretations. Each named test is referenced by various assertions at the beginning of this chapter.


TD-16.1 DirectSound Driver Test (DsDrvTst)

Test Kit: HCT 11, HCT 10

Overview

The DsDrvTst test ensures that the driver complies with the DirectSound API/DDI as defined in the DirectX SDK.

For testing equivalent output power levels between software and hardware DirectSound 2-D buffers, a full-scale 1kHz tone is played through both a DirectSound secondary software buffer and a DirectSound secondary hardware buffer at 0 attenuation, center pan. The amplitude of the output of each of the outputs is measured and compared. The measured output levels should be within 5% or the test fails. This process is repeated 3 times with a random pan setting and attenuation setting.

For testing equivalent output power levels between software and hardware DirectSound 3-D buffers, a full-scale pink noise file is played through a DirectSound3D secondary software buffer using the NO_VIRTUALIZATION algorithm, at 0 attenuation. The RMS power output of each of the outputs is measured and compared. The measured output levels of the hardware buffer should be within 10% of the software buffer or the test case fails. This process is repeated with predefined coordinates {(0,1,0), (1,1,1), (5,5,5), (10,10,10), (-1,1,1), (-5,5,5), (-10,10,10), (1,1,-1), (5,5,-5), (10,10,-10)} and three random coordinates.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires an audio device and DirectSound-compliant driver installed in a test system. Windows 98 Second Edition, Windows 2000, or Windows XP must also be installed.

Results Interpretation

All test cases return PASS, FAIL or PENDING. Review the test results in the generated log file for specific details regarding failures. A test case returns PENDING when it perceives that the environment is not set up properly for it to perform its test, or the test case is not appropriate for the hardware being tested. For example, a test case that tests 3D hardware buffers on a device that does not support 3D buffers would return PENDING.


TD-16.2 Audio Power Management Test (Lullaby)

Test Kit: HCT 11, HCT 10

Overview

Lullaby tests the behavior of the audio subsystem before, during and after S1 suspend cycles. There are two types of test cases.

Synchronous test cases follow these steps:

  1. Play a MIDI/audio file.
  2. Stop playing.
  3. Put the machine to sleep mode. (Machine will wake up by default within 5 seconds)
  4. Play a MIDI/audio file.
  5. Stop playing.

Asynchronous test cases follow these steps:

  1. Play a MIDI/audio file.
  2. Put the machine to sleep mode while playing.
  3. Stop playing.
  4. Play a MIDI/audio file.
  5. Stop playing.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires an audio device installed in an ACPI-enabled system with S1 and S3/S4 sleep state capabilities. If the system supports RTC wake from these states, then the test cases will be fully automatic. Otherwise, some manual intervention is required to wake the machine.

This test case requires the SndAnlyz software.

Results Interpretation

All test cases return PASS or FAIL. Review the test results in the generated log file for specific details regarding failures.


TD-16.3 Mixer Driver Test (MIXDRV32)

Test Kit: HCT 11, HCT 10

Overview

The MixDrv32 test assures that an audio device and driver are compliant with the Multimedia SDK documentation with respect to the "mixer" family of Multimedia APIs.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires an audio device and driver installed in a test system. Windows 98 Second Edition, Windows 2000, or Windows XP must also be installed.

Results Interpretation

All test cases return PASS or FAIL. Review the test results in the generated log file for specific details regarding failures.


TD-16.4 Audio Wave Driver Test (WAVDRV32)

Test Kit: HCT 11, HCT 10

Overview

The WavDrv32 test assures that an audio device is compliant with the Multimedia SDK documentation with regard to the "wave" family of Multimedia APIs.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires an audio device and driver installed in a test system. Windows 98 Second Edition, Windows 2000, or Windows XP must also be installed.

Results Interpretation

All test cases return PASS or FAIL. Review the test results in the generated log file for specific details regarding failures.


TD-16.5 Audio MIDI Driver Test (MIDDRV32)

Test Kit: HCT 11, HCT 10

Overview

The MIDDRV32 test assures that an audio device is compliant with the Multimedia SDK documentation with regard to the "MIDI" family of Multimedia APIs.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires an audio device and driver installed in a test system. A MIDI loopback cable must be attached to the device under test. Windows 98 Second Edition, Windows 2000, or Windows XP must also be installed.

Results Interpretation

All test cases return PASS, FAIL or PENDING. Review the test results in the generated log file for specific details regarding failures. A test case returns PENDING when it perceives that the environment is not set up properly for it to perform its test. An example of this scenario would be if the test is run with no output port selected and a given test case needs to use an output port.


TD-16.6 Full Duplex Test (FDuplex)

Test Kit: HCT 11, HCT 10

Overview

The FDuplex test assures that the audio device complies with the full duplex requirements of Windows Logo Program.

The FDuplex test verifies that the HW/driver pair can perform various full-duplex operations with different combinations of APIs, namely:

  • DirectSound / DirectSoundCapture
  • DirectSound / WaveIn
  • WaveIn / WaveOut (NULL notification)
  • WaveIn / WaveOut (Event notification)
  • WaveIn / WaveOut (Callback function notification)
  • WaveOut / DirectSoundCapture

For each method 8, 11, 22 and 44 kHz formats are used.

FDuplex uses an automated approach to determine whether the full-duplex operation is successfully completed or failed.

FDuplex performs the following steps.

  1. Create recording buffer. (order may change depending on the case)
  2. Start playback.
  3. Start recording.
  4. Wait for recording and playback to finish (waiting method depends on test case)
  5. Analyze the recorded data and verify that the playback and recording are the same.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires an audio device and driver installed in a test system with Windows 98 Second Edition, Windows 2000, or Windows XP. FDuplex requires an audio cable and correct playback settings. Connect an audio cable from LineIn/Microphone to LineOut/Speaker, whichever is available and make sure that the correct mixer line is selected for recording. Set mixer volume control so that there is no clipping (over-saturation) of the signal.

Mixer settings are stored at the beginning of the test and are included in the log file.

Results Interpretation

All test cases return PASS or FAIL. Review the test results in the generated log file for specific details regarding failures.

Each test case consists of sub-cases. Each sub-case tries a different format combination for the current format. The log contains detailed information about the API calls and their return values. At the end of each sub-case, the result of the sub-test is displayed.

Here is a list of common failures:

Call to an API function fails: The test does not display any specific error message at the end of sub-case for this type of failure. You should track the log file to find which API call has failed.
This type of failure is most probably caused by the driver.

Test case times out: This type of failure occurs in step 4 (see above). The test polls position to determine if the operation has finished. If position does not get to the end of the buffer, the log will contain the following message "FAIL: Timeout after the specified time".
This type of failure is most probably caused by the driver. It is reporting a wrong position.

The recorded data is not as expected: This type of failure occurs in step 5 (see above). The test analyzes recorded data and tries to find the test signal. If it finds unexpected results (no data, distorted data, noise) it will display the following message "FAIL : Expected : %4d Hz Recorded : %4d Hz". This displays the expected frequency of the test signal and the recorded frequency.
This type of failure is most probably caused by incorrect mixer settings, a bad audio cable, or the driver.


TD-16.7 Audio Quality Test (AUDQLTY)

This test is obsolete and was removed from Kit.

Overview

The AUDQLTY test assures that the audio device complies with Windows Logo Program.

Testing methodology is based on the Personal Computer Audio Quality Measurement (PCAQM) document.

For Frequency Response measurements the following steps are performed:

  1. Set mixer lines on both machines appropriate for testing path.
  2. Set player to 1kHz –3dB FS.
  3. Analyze and set measured value to 0dB.
  4. Sweep signal frequency from 20Hz to 20kHz (-20dB FS).
  5. Analyze each signal and compare to 0dB.

For Dynamic Range measurements the following steps are performed:

  1. Set mixer lines on both machines appropriate for testing path.
  2. Set player to 1kHz –60dB FS.
  3. Analyze the signal.
  4. Notch out the fundamental frequency and measure residual energy.

For THD+N measurements the following steps are performed:

  1. Set mixer lines on both machines appropriate for testing path.
  2. Set player to 1kHz –3dB FS.
  3. Analyze the signal.
  4. Notch out the fundamental frequency and measure residual energy.

For Crosstalk measurements, the following steps are performed:

  1. Set mixer lines on both machines appropriate for testing path.
  2. Set player to 1kHz –3dB FS mono.
  3. Analyze the signal.
  4. Calculate the ratio of channels.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires two systems, both with an audio device and driver installed and Windows 98 Second Edition, Windows 2000, or Windows XP.

Sound Analyzer test application (SAServer) must be installed. SAServer requires that both machines be connected to a network.

SAServer installation is different for Windows 98 Second Edition, Windows 2000, and Windows XP because of networking differences in the operating systems.

Windows 98 Second Edition

After running the Audio Test Setup, follow these steps on both the local and remote machines:

  1. Run ComSetup. If everything is setup correctly for DCOM remote connection, ComSetup exits immediately.

Otherwise, click the Preferred button on ComSetup dialog, which checks the system registry and makes the changes for you.

ComSetup cannot change Network Properties. If they need to be changed, you are directed to configure Network Properties.

This step may require a few reboots. After each reboot, run ComSetup.

  2. Run Register.bat. This registers COM components.
  3. Run SAServer.

Windows 2000

After running ACT99 Setup follow these steps on local and remote machines.

  1. Run Register.bat. This registers COM components.
  2. Run SAServer (This is optional. Windows 2000/XP Remote Process Invoking feature runs SAServer whenever it is needed)

Windows 98 Second Edition, Windows 2000, and Windows XP

After setup is done, SAServer is running on both local and remote machine. It is ready to supply services required by ModMgr.

If you select a test that requires SAServer from Tshell, you must perform the following steps:

  1. First dialog asks for your remote machine name. Enter the machine name. ModMgr establishes the connection and collects information about local and remote machines. It compares operating system versions, media devices (except game ports) and drivers on both systems. Any differences invalidate the test run.
  2. Second dialog asks for the slot configuration on the sound card. Select all the inputs and outputs that are in your sound card. These are used for selecting appropriate mixer lines for different tests.
  3. Third dialog asks you to set all mixer lines to 0 dB level (no gain, no attenuation) for both playback and recording. This step is only required for the local machine. After everything is set, click the Finish button. ModMgr collects mixer levels and propagates the values to the remote machine.

Results Interpretation

All test cases return PASS or FAIL. Review the test results in the generated log file for specific details regarding failures.


TD-16.8 Audio PC Audio Requirement Test (PCAudreqst)

Test Kit: HCT 11, HCT 10

Overview

The PC99Aud test assures that the audio device complies with Windows Logo Program.

The PC 99 Audio Device Test verifies various properties of the driver. The test cases access the pins of the driver directly. Hence, it verifies the actual capabilities of the driver.

The playback and capture test cases follow these steps:

  1. Find the first wave filter.
  2. Find the output (input sink) or input (output sink) pins.
  3. For 8, 11, 16, 22, 32, 44 and 48kHz formats:
    Find out if the format is supported using datarange and datarange intersection properties of the pin. If the format is supported, create a playback or capture pin with the supported format.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires two systems, both with an audio device and driver installed and Windows 98 Second Edition, Windows 2000, or Windows XP.

This test case requires the SndAnlyz software. Refer to TD-16.7 Audio Quality Test (AUDQLTY) setup for details.

Results Interpretation

All test cases return PASS or FAIL. Review the test results in the generated log file for specific details regarding failures.


TD-16.9 Audio Digital Rights Management Test (DrmTest)

Test Kit: HCT 11, HCT 10

Overview

The Digital Rights Management test assures that the audio device complies with portions of Windows Millennium Edition DRM Supplement to the Windows DDK.

There are four set of tests in DrmTest.

1. Test if the driver adds Drm-interfaces properly. (1-6)

The KSCATEGORY_AUDIO and KSCATEGORY_RENDER pins will be enumerated. Each pin will be instantiated with a 44kHz 16 bit stereo format. KSPROPSETID_DrmAudioStream, KSPROPERTY_DRMAUDIOSTREAM_CONTENTID property will be sent to the pin handle using DeviceIoControl. The data will only contain a ULONG (StreamId) as defined in DDK headers. The StreamId will be set to 0.

2. Test if the driver can handle DRMRIGHTS.CopyProtect properly. (20-31)

The basic steps for these tests are as follows.

If no waveout capture is found, the test will run just once without analyzing the results.

If waveout capture is found, the test will be repeated for each waveout capture line.
WAVE_FORMAT_DRM DirectSoundBuffer will be created first. The DRMRIGHTS.CopyProtect=TRUE structure will be propagated down to the miniport.
The analyzer expects to have silence.

The test cases also use DRMRIGHTS.CopyProtect=FALSE to test if the waveout capture is enabled.

DRM and PCM streams are created and played concurrently.

Two DRM streams with different rights are created and played concurrently.

3. Test if the driver can handle DRMRIGHTS.DigitalOutputDisable properly.

The basic steps for these tests are as follows. This test case is manual and should only be considered if the S/PDIF output is enabled with WDM driver.

Unmute the S/PDIF output mixer line using SndVol32.

Connect the S/PDIF output to a receiver or a speaker. WAVE_FORMAT_DRM DirectSoundBuffer will be created first.

The DRMRIGHTS.DigitalOutputDisable=TRUE structure will be propagated down to the miniport. The output must be muted.

4. Test if the DRM system with the new driver can handle all sample rates properly.

The basic steps for these tests are as follows.

If no waveout capture is found, the test will run just once without analyzing the results.

If waveout capture is found, the test will be repeated for each waveout capture line.

WAVE_FORMAT_DRM DirectSoundBuffer will be created with different sample rates. The DRMRIGHTS. CopyProtect =FALSE structure will be propagated down to the miniport.

The analyzer expects to have test signal.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

System must have a sound card. The operating system must be Windows Millennium Edition.

If the sound card has S/PDIF output, a receiver with S/PDIF input or a speaker with S/PDIF input is required.

All audio loopback cables and microphones should be disconnected, before running the test.

The test will first find out if there is a waveout capture path.

  1. All mixer line volume controls for playback and recording are set to MAX.
  2. All source lines connected to MIXERLINE_COMPONENTTYPE_DST_SPEAKERS (playback) are unmuted.
  3. If the MIXERLINE_COMPONENTTYPE_DST_WAVEIN mixer destination line does not have a MUX control, all source lines connected to MIXERLINE_COMPONENTTYPE_DST_WAVEIN are unmuted.
  4. If the MIXERLINE_COMPONENTTYPE_DST_WAVEIN mixer destination line has a MUX control, the next step 5-7 will be repeated for each mixer line selection.
  5. WAVE_FORMAT_PCM DirectSoundBuffer will be created.
  6. WaveIn capture will be created.
  7. When the capture and playback finishes, the capture buffer will be analyzed. If the test signal is found, then the mixer line is marked as waveout capture. All the marked lines will be expected to be muted if DRMRIGHTS.CopyProtect=TRUE.
  8. After all mixer lines are processed, mixer settings are restored to original.
  9. The same mixer method will be used for all waveout capture test cases.

Results Interpretation

All test cases return PASS or FAIL. Review the test results in the generated log file for specific details regarding failures.


TD-16.10 KS Audio Position Accuracy Test (KsPosTst)

Test Kit: HCT 11, HCT 10

Overview

KsPosTst is provided as a replacement for the "performance" related test cases in WavDrv32. KsPosTst bypasses all audio APIs and KS filters such as KMixer, for the most accurate and direct testing of the audio device possible. Positional information is determined using the KSPROPSETID_Audio.KSPROPERTY_AUDIO_POSITION property.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires an audio device that uses a WDM audio driver (i.e. it will not test VxD or Windows NT 4.0 drivers). Windows 98 Second Edition, Windows 2000, or Windows XP must also be installed.

Results Interpretation

All test cases return PASS, FAIL or PENDING. Review the test results in the generated log file for specific details regarding failures. A test case returns PENDING if it cannot find an appropriate KS pin. For example, a capture test case will return PENDING if there are no capture devices found.


TD-16.11 KS DirectMusic Filter Test (KSDMTst.exe) Description

Test Kit: HCT 11, HCT 10

Overview

KSDMTst assures that each enumerated KSCATEGORY_AUDIO, KSCATEGORY_SYNTH filter that exposes DirectMusic format pins is compliant with the DirectX SDK and Windows DDK documentation with regard to DirectMusic Kernel Streaming Interfaces.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires an audio device and driver installed in a test system running Windows Me or Windows XP.

Results Interpretation

A test case can pass, fail, abort, or return pending.


TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

Test Kit: HCT 11, HCT 10

Overview

DMDrv assures that each enumerated DirectMusic synthesizer (Kernel Mode or User Mode) compliant with the DirectX SDK with regard to DirectMusic API.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires an audio device and driver installed in a test system running Windows Me or Windows XP.

Results Interpretation

A test case can pass, fail, abort, or return pending. The first two are self-explanatory. An abort takes place when the test app perceives some internal error in a test case and cannot complete the test case reliably. A test case returns pending when it perceives that the environment is not set up properly for it to perform its test. An example of this scenario is if the test case requires certain capabilities that the synth under test does not possess.


TD-16.13 AC-3 Driver (AC3Test.exe) Test Description

Test Kit: HCT 11, HCT 10

Overview

AC3Test assures that each enumerated KSCATEGORY_AUDIO, KSCATEGORY_RENDER filter that exposes AC-3 format pins is compliant with the Windows DDK documentation with regard to implementation of AC-3 format pins. Also, this test assures that the filter does nothing to preclude support for AC-3 streaming through the wave and DirectSound APIs.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires an audio device and driver installed in a test system running Windows Me or Windows XP. If the audio device has a digital output (such as a S/PDIF out) through which the AC-3 stream passes, the tester should attach an AC-3 decoding device (such as a home theatre receiver) to the device under test so that the output of the card can be monitored audibly.

Results Interpretation

A test case can pass or fail.


TD-16.15 Software Synthesizer Test Description

Overview

The Software Synthesizer test specification defines attributes of a Software Synthesizer (SWSynth) that are required for proper operation on the PC. This specification covers both legacy (WinMM-exposed) SWSynths and DirectMusic SWSynths. A SWSynth will need to pass all of the Software Synthesizer tests on a USB audio device using the OS class driver, an integrated AC’97 controller, and an audio device that supports hardware mixing. The audio drivers used for testing need to be signed. The SWSynth must also pass the core PNP driver tests. If the SWSynth passes the Software Synthesizer test kit on these 3 signed device combinations, it will receive a logo that is not tied to a specific piece of hardware.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires an audio device and driver installed in a test system running Windows Me or Windows XP.

Then install the Software Synth under test.

Results Interpretation

A test case can pass, fail, or abort.


TD-16.35 GFX (gfxtest.exe) Test Description

Test Kit: HCT 11, HCT 10

Overview

Gfxtest assures that a GFX is installed correctly, works correctly with the GFX architecture, is a healthy AVStream filter, and does not compromise the Windows audio system.

The GFX test specification defines attributes of a Global Effects (GFX) filter that are required for proper operation of the audio stack in Windows XP. A global effect is an audio signal transform applied to the final audio mix rendered by an audio device or applied to the audio signal coming in from an audio capture device. Currently, GFXs are only supported on USB devices. A non-HW-Specific GFX will need to pass all of the GFX tests on a USB audio device using the OS class driver. A HW-Specific GFX will need to pass all of the GFX tests on the corresponding USB audio device, which must either be using the OS class driver or have its own signed driver. The GFX will also have to pass all of the core PNP driver tests.

Since DRM content may pass through a GFX, the GFX AVStream filter must implement a property handler for KSPROPERTY_DRMAUDIOSTREAM_CONTENTID. This handler calls DrmForwardContentToDeviceObject to advise the DRM system of the connect downstream pin that received the content. The GFX AVStream filter calls KsPinGetConnectedPinFileObject and KsPinGetConnectedPinDeviceObject to retrieve the FILE_OBJECT and DEVICE_OBJECT parameters to pass to DrmForwardConectToDeviceObject. NOTE: We are investigating the possibility of having KS handle the DRM property on behalf of an AVStream filter if the AVStream filter does not provide such a handler itself. The GFX vendor will also need to sign a DRM agreement.

Setup

This test requires a USB audio device to be installed on a test system running Windows XP. It also requires the GFX being tested to be installed on the test system.

Results Interpretation

A test case can pass, fail, abort, or return pending.


Chapter 17: TV Standard Input Capability Test Specification

Note: This chapter is not currently implemented.

This document provides a specification of metrics used in assessing the function of hardware supporting decode of radio frequency (RF) modulated video signals. This specification makes use of previously defined metrics for related video capabilities.

In the context of this document, television standard input is the hardware implementing a capability of demodulating an RF modulated SDTV signal, digitizing the base-band video and placing a representation of the video into system main memory. Demodulation is typically provided in a modular television tuner unit. A separate video input device typically provides digitization of demodulated base-band video. The video input module is usually capable of directly accepting other base-band video signals.

The RF modulated aspect of these signals introduces unique characteristics, differentiating these signals from those that are only subject to base band analog processing. The primary differences relate to video noise levels in luminance and chrominance, group delay causing skew between chrominance and luminance features, and overall frequency response or bandwidth of chrominance and luminance.

Test Coverage

This specification addresses television standard input requirements that partially verify compliance with Microsoft Windows Logo Program System and Device Requirements. Standard definition television (SDTV) signals that have been RF modulated have special considerations that must be addressed in video testing.

These tests provide coverage of hardware implementing the decoding of RF modulated video signals. This capability complements the capability of decoding of base band video signals, allowing connectivity with a wide range of devices, some of which may only be conveniently connected using RF interconnects. These tests provide coverage of the video quality of the tuner hardware subsystem for video input solutions with TV tuners. These tests do not provide coverage of tuner function, such as channel selection, as these functions are mainly software features.

All RF interconnects are made using a television standard frequency that is commonly implemented for this purpose on Consumer Electronics (CE) devices. In the US, VHF TV channel three is used.

The US uses NTSC chrominance encoding and ITU Region-M signaling standard. Other regions of the world may employ signaling standards that do not adhere to ITU Region-M standards. These tests are not defined for such regions. These tests are defined for ITU Region-M standards with PAL chrominance in a PAL-M environment.

The assessment of the hardware capability is conducted by inspection of the data generated by a video decoding solution, given known input. The known input is DVD content played on a CE DVD player.

The DVD player can be the same as players used for other hardware testing. A CE VCR, also used for related testing, is used for these tests if a DVD player does not have a RF output. Various cables are used in making the interconnections.

Test Methodology

The Television Standard Input Capability tests require certain materials, configuration and interconnect of the materials, verification of the configuration, and finally the actual testing. The following sections cover each of these areas. Detailed test descriptions are provided in the "Test Descriptions" section.

Test Equipment

The tests require the following test equipment and materials:

  • A PC system configured with RF modulated TV standard video input and base band video input. This system is called the Device Under Test (DUT). The DUT must have Microsoft Windows 98/Me or Windows 2000 operating system loaded with DirectDraw and DirectShow runtime version 6.0 or higher and DirectX Media SDK 6.0 or higher. In all cases, release software is assumed.
  • A CE DVD player suitable for home entertainment use. This system is called the Test Signal Generator (TSG). The TSG may generate PAL-M or NTSC-M output as appropriate to the intended market of the DUT.
  • A CE VCR with base band input and RF output, if the DVD player does not have RF output. This system is called the RF Modulator (RFMOD). The RFMOD should be selected to be compatible with the PAL or NTSC color encoding as appropriate.
  • An S-Video or Composite Video cable, if the DVD player does not have RF output.
  • A RF standard cable (75 ohm), as used for cable television distribution.
  • Joe Kane’s, Video Essentials DVD, (UPC 47715-0711-2). This DVD is called the media (MEDIA). This media is available as 525 line 60 field (region M) only.
Test Configuration

The test system is connected in the following way. The TSG is connected to the DUT. The connection may be made through the RFMOD if the TSG lacks a RF modulated video output. If the connection is made through the RFMOD, the connection should be made using the base band cable from the TSG to the RFMOD and the RF standard cable from the RFMOD to the DUT.

Test Setup Schematic

Test Setup Schematic

The MEDIA is placed in the TSG. The TSG will display circa Title 15 Chapter 11 Second 36 of the MEDIA as a still frame. The precise frame is ‘stepped’ to. Some DVD players display the correct frame as second 37 frame 2. The first occurrence of the frame is shown in Figure 17-1 and is the desired test input.

Figure 17-1 Desired Test Output

Figure 17-1. Desired Test Output

If a DVD player displays an image where the interlace is incorrect as shown in
Figure 17-1, use the TSG’s step feature to advance the DVD player until the image appears as shown in Figure 17-1. To confirm that the correct pattern has been found, look at the device in the lower right (radial wedge), the area just to the left of center near the top (diagonal lines below text "300"), and the device at the upper left (thin white line on black rectangle). Each area can clearly show the differences between the desired input and other input.

A typical characteristic appearance of each device in the presence of incorrect interlace is as follows. The radial wedge has the points of the wedges diverging from the center. The diagonal line pattern appears as cross hatches. The thin white line on black rectangle appears as a stair step with reverse direction aliasing.

Figure 17-2 Incorrect Interlace Example

Figure 17-2. Incorrect Interlace Example

The selection of the correct frame for the test input can be aided by the use of a standard television set.

Verification of Configuration

Once the required connections have been made, verify the correct system configuration by viewing the TSG output on the DUT. Launch the application ‘graphedt.exe’ from the DirectX Media SDK. Insert the video capture source filter corresponding to your video input solution into the empty, unnamed filter graph. Configure the source filter for a YUY2 input format at one of these horizontal resolutions {352, 360, 480, 512, 640, 704, and 720} and 480 vertical resolution. Render the capture pin by right clicking on the pin and selecting render from the drop down menu. The filter graph should change, with a connection from the capture pin to at least one other filter.

Read below if this does not happen. Press the play or run button on the button bar and you should see the video coming from the TSG in a window on your screen. Verify that the video is working by turning on and off the TSG menus. You should see the menu screens appear and then disappear from the window on your screen.

In case you have trouble rendering the capture pin, that is, if there is nothing connected to the capture pin after selecting render from the menu, your system configuration should be enhanced to include rendering support for your chosen data format. If you are using YUY2 input formats, some video codecs available freely on the web are able to display this format. One such video codec is the Indeo Video 4 codec, contained in the distribution available at http://www.ligos.com/indeo/downloads/download.shtm.

When you have succeeded in rendering the capture pin in the chosen format, you should be able to see the video coming from the TSG in a window on your screen when you press the play button.

Test Operation

The tests run for a period of three minutes. During this time, it is only necessary for the operator to insure that the test configuration is not disturbed. No other operator intervention is required. The test provides a pass or fail indication for each assertion. Passing the test requires a pass for each assertion. If the test detects some problem with the configuration, which was not uncovered by the above verification, the operator is alerted to the problem and is requested to correct it. The tests implement a set of metrics similar to the PC99 Video Input Test Suite, tailored to the special considerations of RF modulated video.


TV Input Test Assertions

The TV Standard Input Test Suite is composed of three tests providing coverage for the following twenty assertions. Each assertion contains a pointer to a detailed test description. The detailed test description provides in-depth information about how the assertions are tested, how each test is run, and how the results of the test should be interpreted.


Reference Documents for TV Input Assertions

Microsoft Windows Driver Development Kit

http://www.microsoft.com/ddk/

Microsoft Windows Logo Program System and Device Requirements, Version 2.0

http://www.microsoft.com/hwdev/winlogo/
(listed as "WLP#" in these assertions)

PC 2001 System Design Guide and PC 99 System Design Guide

http://www.microsoft.com/hwdev/platform/pcdesign/desguide/pcguides.asp


TV Input Hardware Configuration Assertions

The following system configuration assertions are tested in TD-17.1 TV Input Hardware Configuration Test (TVIN_CFG).

17.1.1 System includes analog video input.

Reference document: WLP# - B11.3; B11.1.4.4; PC 2001 System Design Guide, VID-0215, GRPH-0169; PC 99 System Design Guide - 15.3.
Test description: TD-17.1 TV Input Hardware Configuration Test (TVIN_CFG)

17.1.2 System includes an analog TV tuner.

Reference document: WLP# - B11.3; B11.1.4.4; PC 2001 System Design Guide, VID-0215, GRPH-0169; PC 99 System Design Guide - 15.4.
Test description: TD-17.1 TV Input Hardware Configuration Test (TVIN_CFG)

17.1.3 [Replaced with assertion 17.1.8. v.0.5]
The system provides YUY2 or UYVY 4:2:2 format data

Reference document: WLP# - B11.3; B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.30 and 15.35.
Test description: TD-17.1 TV Input Hardware Configuration Test (TVIN_CFG)

17.1.4 Vertical resolution is the ITU region M 480 line standard.

Reference document: WLP# - B11.3; B11.1.4.4; PC 2001 System Design Guide, VID-0215, GRPH-0169; PC 99 System Design Guide - 15.4.
Test description: TD-17.1 TV Input Hardware Configuration Test (TVIN_CFG)

17.1.5 Horizontal resolution is 720, 704, 640, 512, 480, 360, or 352 pixels.

Reference document: WLP# - B11.3; B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.30 and 15.35.1.
Test description: TD-17.1 TV Input Hardware Configuration Test (TVIN_CFG)

17.1.6 Input frame rate is described as ITU region M 29.97-fps standard.

Reference document: WLP# - B11.3; B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.4, 15.30 and 15.35.1.
Test description: TD-17.1 TV Input Hardware Configuration Test (TVIN_CFG)

17.1.7 The TV Input solution initializes within 5 seconds.

Reference document: WLP# - B11.3; B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.35.
Test description: TD-17.1 TV Input Hardware Configuration Test (TVIN_CFG)

17.1.8 The system provides YUY2 format data.

Reference document: WLP# - B11.3; B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.30 and 15.35.
Test description: TD-17.1 TV Input Hardware Configuration Test (TVIN_CFG)


TV Input Hardware Function Assertions

The following hardware quality assertions are tested in TD-17.2 TV Input Hardware Function Test (TVIN_FNC).

17.2.1 Frame rate is within 20% of expected during first ten seconds.

Reference document: WLP# - B11.3; B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.35.1.
Test description: TD-17.2 TV Input Hardware Function Test (TVIN_FNC)

17.2.2 Frame rate is within 0.2% of expected during full three minutes of test.

Reference document: WLP# - B11.3; B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.35.1.
Test description: TD-17.2 TV Input Hardware Function Test (TVIN_FNC)

17.2.3 Delivered frames have no pixel drops greater than 16 pixels in size.

Reference document: WLP# - B11.3; B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.35.1.
Test description: TD-17.2 TV Input Hardware Function Test (TVIN_FNC)

17.2.4 Delivered frames have fewer than one hundred pixels dropped.

Reference document: WLP# - B11.3; B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC99 System Design Guide - 15.35.1.
Test description: TD-17.2 TV Input Hardware Function Test (TVIN_FNC)

17.2.5 No more than 2 frames are dropped in each 1/2 second of input.

Reference document: WLP# - B11.3; B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.35.1.
Test description: TD-17.2 TV Input Hardware Function Test (TVIN_FNC)

17.2.6 No more than 3 frames are dropped in each minute of input.

Reference document: WLP# - B11.3; B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.35.1.
Test description: TD-17.2 TV Input Hardware Function Test (TVIN_FNC)

17.2.7 No more than 6 frames are dropped during the test period.

Reference document: WLP# - B11.3; B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.35.1.
Test description: TD-17.2 TV Input Hardware Function Test (TVIN_FNC)

17.2.8 No more than 0.1% of all input pixels are in error.

Reference document: WLP# - B11.3; B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.35.1.
Test description: TD-17.2 TV Input Hardware Function Test (TVIN_FNC)

17.2.9 Disk accepts 3.7MB/s write traffic while viewing TV Input.

Reference document: WLP# - B11.3; B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.35.1.
Test description: TD-17.2 TV Input Hardware Function Test (TVIN_FNC)


TV Input Image Quality Assertions

The following image quality assertions are tested in TD-17.3 TV Input Hardware Image Quality Test (TVIN_IMG).

17.3.1 Input VIDEOINFO’s BITMAPINFOHEADER "biHeight" is 480.

Reference document: WLP# - B11.3; B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.34 and 15.35.
Test description: TD-17.3 TV Input Hardware Image Quality Test (TVIN_IMG)

17.3.2 Input image is presented in top down order.

Reference document: WLP# - B11.3; B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.34 and 15.35.
Test description: TD-17.3 TV Input Hardware Image Quality Test (TVIN_IMG)

17.3.3 Input image is presented without field inversion.

Reference document: WLP# - B11.3; B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.34 and 15.35.
Test description: TD-17.3 TV Input Hardware Image Quality Test (TVIN_IMG)

17.3.4 Input image is presented without mirror inversion.

Reference document: WLP# - B11.3; B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.34 and 15.35.
Test description: TD-17.3 TV Input Hardware Image Quality Test (TVIN_IMG)

17.3.5 Input image has correct image detail.

Reference document: WLP# - B11.3; B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.35.
Test description: TD-17.3 TV Input Hardware Image Quality Test (TVIN_IMG)

17.3.6 Input image has correct image levels.

Reference document: WLP# - B11.3; B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.35.
Test description: TD-17.3 TV Input Hardware Image Quality Test (TVIN_IMG)

17.3.7 Input image has correct image dimensions.

Reference document: WLP# - B11.3; B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.35.
Test description: TD-17.3 TV Input Hardware Image Quality Test (TVIN_IMG)


TV Input Test Descriptions

This section provides a detailed description of the goals and operation of each test. Each test includes an overview, a description of each assertion with testing methodology, testing criteria for obtaining a "PASS" for the assertion, instructions for setup and running the test, and guidelines for interpreting the results of the test.

The DirectX Media infrastructure (Direct Show) provides an appropriate level of abstraction from implementation details and is required to run the tests. Test software will report if the DirectX Media infrastructure (Direct Show) is not present in the system.


TD-17.1 TV Input Hardware Configuration Test (TVIN_CFG)

Overview

The TV Input Hardware Configuration Test assesses the presence and configuration of the television standard input capability. A pass for each assertion is required to obtain a pass for the test. In some cases, the test continues to execute past one or more error conditions to provide as much information as possible.

The test accesses the TV Input capability through the DirectX Media interfaces provided for using and configuring video input source filters and ancillary devices. The test confirms:

  • Presence of a video input (streaming) source filter
  • Presence of a crossbar switch controlling the routing of input signals
  • Presence of a TV tuner input to the crossbar switch
  • Ability to route the TV tuner input to the video source filter
  • Presence of a TV tuner filter providing control of the configuration of the TV tuner
  • Ability to configure the TV tuner device for US VHF TV channel 3
  • Ability to configure the source filter for decode to at least one of two 4:2:2 packed pixel data formats
  • Ability to configure the source filter for decode of ITU region M signals to 480 active video lines
  • Ability to configure the source filter for ITU-R-BT.601 rate video or resampling of same in width
  • Indications from the source filter that periodicity of sample presentation matches ITU region M standard. The input must be in ‘pseudo’ frame format at one half of the field rate

Each assertion is described in the numbered paragraphs below. The method used to test the assertion and the criteria for passing the assertion test is described.

  1. The system includes analog video input. For this assertion, the test discovers an analog video input solution by exercising the DirectX Media IFilterGraph and IGraphBuilder interfaces to find and instantiate the source filter within a filter graph. For systems with more than one analog video input solution, the test configuration indicates which solution is to be used for the test. Each video input solution present in the system must pass the test. The video input solution selected for this assertion is used for all other assertions within the test. A solution that does not indicate an error when enumerating and instantiating the source filter passes the test. If a solution indicates an error, the test fails, displays an error message, and terminates.
  2. The system includes an analog TV tuner. For this assertion, the test discovers a streaming Crossbar switch filter and a streaming TV Tuner filter. It instantiates them within a filter graph and configures the TV tuner hardware for US VHF channel 3. The test then connects the Analog Video output pin of the TV Tuner filter to the Video Tuner In pin of the Crossbar switch. The test then connects the Video Decoder Out pin of the Crossbar switch to the Analog Video In pin of the capture source filter. The test passes if no error is indicated during the operations. If the operations result in an error, the test fails, displays an error message, and terminates.
  3. [Windows Logo Program 1.1] The system provides YUY2 or UYVY 4:2:2 format data.
    [Windows Logo Program 2.0] The system provides YUY2 format data.
    For this assertion, the test attempts to configure the capture output of the source filter for YUY2 format data. If either format results in an error, the test fails, displays an error message, and terminates. The test passes if it is able to select both of these formats without an error being generated by the solution.
  4. Vertical resolution is ITU region M 480 line standard. The ITU designates the SDTV signaling systems by a letter code. The area in which each system is used is called a ‘region’. Region ‘M’ refers to all places in which system ‘M’ is used. This covers nearly all of the Americas. System ‘M’ is a 525 line (active plus non-active) standard. The tests are only defined for region M. The test configures the source filter for this signaling system. Specifically, the test configures the source filter for NTSC-M video with 480 lines of (active) video data. The test passes if no error is indicated when configuring the source filter. The test fails and the test terminates if an error occurs.
  5. Horizontal resolution is 720, 704, 640, 512, 480, 360, or 352 pixels. For this assertion, the test operates in one of two modes. In the first mode, the test configures the source filter for 720 pixel wide video. If this fails, the test configures the source filter for each of the other widths in order. If all of these fail, then the test fails and terminates.

In the second mode, the test configuration indicates the desired width, and the test configures the source filter for that width. If this fails, the test fails and terminates. The test passes if the test is able to configure one width without error.

  6. Input frame rate is described as ITU region M 29.97-fps standard. For this assertion the test determines whether the indicated input frame rate is 29.97 frames per second, corresponding to one half of the region M field rate. The test fails if the indicated frame rate is not 29.97 frames per second. In case of failure, the test configures the source filter for 29.97 frames per second. If this succeeds, the test continues past this assertion failure. If the test is unable to configure the source filter for 29.97 frames per second, the test terminates.

The metric used for the test is an indication of 33 milliseconds as the average. This measure is generated by integer division of the AvgTimePerFrame, obtained from the Format() method (ns per frame), by ten thousand. A value of other than 33ms per frame causes the test to fail.

  7. The TV input solution initializes within five seconds. For this assertion, the test determines whether the time required to perform initialization of the hardware preparatory to use of the capability is in excess of five seconds. The definition of ‘initialization’ is that all filter discovery, insertion, configuration, and interconnection has been completed. The test fails if the initialization requires more than five seconds. If the initialization completes without error, the test continues to execute past the failure. If the initialization completes in five or less seconds, the test passes. The time required for initialization is measured in integral seconds. A solution requiring 5.9 seconds to initialize passes, while a solution requiring six seconds fails.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test configuration setup is described in the Test Methodology section. The test requires approximately five seconds to complete.

Results Interpretation

Each pass or fail condition is described in the test under each test assertion. In addition to passing and failing, the test may provide advisory information under the heading of ‘warning’ or ‘info’. This status does not affect the ‘pass’ or ‘fail’ result. In cases where the test is able to determine that a simple configuration error has occurred, an informative message indicating how to correct the error is shown. For example, the first assertion of this test, (test configuration referencing a TV Input solution which is not present in the machine), would flag this under a warning in addition to the failure message.

A solution must pass each assertion in order to pass the test. No assertion generates an ambiguous result (for example, "Pass with Warning").


TD-17.2 TV Input Hardware Function Test (TVIN_FNC)

Overview

The TV Input Hardware Function test assesses the ability of the hardware to provide correct data in a timely manner and display the data without degrading overall system response. This test accesses the TV Input capability through the DirectX Media interfaces provided for using and configuring video input source filters and ancillary devices. The test confirms:

  • Start of streaming of input video data from the source filter
  • Appropriate sustained rate of presentation of data from source filter
  • Lack of large objectionable spatially correlated errors in the data
  • Lack of high rate of occurrence of non-correlated errors in the data
  • Lack of temporal correlation among errors in the data
  • Ability of the remainder of system hardware to function while viewing TV

The metrics attempt to approximate the real non-zero error rates, which occur in CE devices and their corresponding error distributions. A random error distribution makes the error visibility low for a given rate of errors. The tests favor solutions, which, for the same overall error rate provide the lowest expected observability of the errors. For the overall error rate, a metric of a tolerance of two tenths of a percent of nominal frame rate was chosen. Each error metric is an approximation of this value. As an example, a solution that provides slightly fewer than the expected number of frames, but provides frames without corrupt data can fare as well as a solution that provides the expected number of frames, some that contain significant corrupt data.

Each assertion is described in the numbered paragraphs below. The method used to test the assertion and the criteria for passing the assertion test is described.

  1. Frame rate is within 20% of expected during first ten seconds. For this assertion, the test assesses the average frame rate during the first ten seconds of the three minute test period. The test uses the metric (delivered frames) divided by (elapsed time of test). If the resulting frame rate, which includes all frames delivered with or without pixels in error, differs from the expected frame rate by more than twenty percent, the test fails. If the resulting frame rate differs from the expected by twenty or less percent, the test passes. The test terminates on a failure. This allows early termination of the testing in cases of system configuration difficulties, as for instance a situation where the source filter never begins streaming video.
  2. Frame rate is within 0.2% of expected during a full three minutes of test. For this assertion, the test assesses the average frame rate over the three minute test period. The test uses the metric (delivered frames – dropped frames) divided by (elapsed time of test). If the resulting frame rate differs from the expected frame rate by more than 0.2%, the test fails. If the frame rate differs from the expected by 0.2% or less, the test passes.
  3. Delivered frames have no pixel drops greater than 16 pixels in size. For this assertion, the test assesses the degree of spatial correlation of pixels in error in each frame received. If a frame has pixels in error, which are contiguous and greater than sixteen pixels in size, the frame is considered dropped. Since this drop is accumulated toward frame rate and total drops, the test passes. If at least one frame is received with more than sixteen contiguous pixels in error, the test generates a pass with a warning. If all frames received have sixteen or fewer contiguous pixels in error, the test passes.
  4. Delivered frames have fewer than one hundred pixels dropped. For this assertion, the test assesses the number of pixels dropped within each frame received. If a frame has 100 or more pixels dropped, the frame is considered dropped. Since this drop is accumulated toward the frame rate and total drops, the test passes. If at least one frame is received with 100 or more pixels in error, the test generates a pass with a warning. If all frames received have fewer than 100 pixels in error, the test passes.
  5. No more than 2 frames are dropped in each 1/2 second of input. For this assertion, the test assesses the closeness in time of frames considered dropped for all reasons. For each non-rolling half second period of the three minute test, if more than two frames are dropped, the test fails. If all half second periods have two or less frames dropped, the test passes.
  6. No more than 3 frames are dropped in each minute of input. For this assertion, the test assesses the total number of frames considered dropped for all reasons in each of the three minutes of the test period. If during any one minute of the test period, more than three frames are dropped, the test fails. If three or less frames are dropped in each minute of the test period, the test passes.
  7. No more than 6 frames are dropped during the test period. For this assertion, the test assesses the total number of frames considered dropped for all reasons during the full three minute test period. If the number of frames dropped is in excess of six during the three minute test period, the test fails. If the number of frames dropped is six or less, the test passes.
  8. No more than 0.1% of all input pixels are in error. For this assertion, the test assesses the number of pixels found to be in error, regardless of spatial or temporal correlation. If the total number of pixels in error is greater than 0.1% of the total number of input pixels (defined as total frames * horizontal resolution * vertical resolution), the test fails. If the number of pixels in error is less than or equal to 0.1%, the test passes.
  9. Disk accepts 3.7MB/s write traffic while viewing TV Input. For this assertion, the test determines whether with the TV data being viewed, the system hardware is able to sustain 3.7MB/s average write traffic to the disk. A solution that cannot sustain this disk traffic while viewing is in progress fails. A solution that can sustain this disk traffic while viewing is in progress passes.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test configuration setup is described in the Test Methodology section. The test requires approximately 3 minutes to complete.

Results Interpretation

Each pass or fail condition is described in the test under each test assertion. Tests can also produce a ‘pass with warning’ status, which is interpreted as ‘This assertion was violated at least once. The test can still pass if there are not associated or repeated errors.’ The status is intended to provide additional information for debugging failures, should they occur. For example, assertion 17.2.3 requires that any pixel drops not be larger than 16 pixels in size. If a frame arrives with a larger pixel drop, this assertion test would produce a ‘pass with warning’ status. This assertion test would not produce a ‘fail’ status, since dropping of several frames is in fact permissible (see assertions from steps 1, 2, and 7 within the test descriptions). If there were many frames presented with pixel drops larger than 16 pixels in size, then the test could produce a ‘fail’ status, but does not need to, since the overall frame rate and total drop related assertions will fail as necessary.


TD-17.3 TV Input Hardware Image Quality Test (TVIN_IMG)

Overview

The TV Input Hardware Image Quality test assesses the quality of the image provided by the hardware. For the purpose of this test, image quality is defined as a complex of interoperable image descriptions, decoder correctness, bandwidth, and noise metrics. The test verifies:

  • Images are provided without overload of the sign bit of the image height
  • Images are provided in top down order, upper left corner at lowest addressed memory location proceeding right and down to higher memory addresses
  • Images are presented in pseudo-frame format with correctly interleaved fields
  • Images are presented in the correct left / right orientation, not as a mirror image of the correct image
  • Images are presented with adequate levels of detail to provide for high quality uses such as large screen monitors or post processing
  • Images are presented with correctly decoded colors and gray levels and with low noise
  • Images are presented with correct dimensions, without significant increase or reduction at the left, right, top, and bottom edges

This test accesses the TV Input capability through the DirectX Media interfaces provided for using and configuring video input source filters and ancillary devices.

  1. Input VIDEOINFO’s BITMAPINFOHEADER "biHeight" is 480. For this assertion, the test assesses whether the indicated height of the input image using the biHeight member of the BITMAPINFO structure is 480. This insures that the sign bit of this structure member is not overloaded to indicate image order. If the height is indicated to be 480, the test passes. If the indicated height is not 480, the test fails.
  2. Input image is presented in top down order. For this assertion, the test assesses whether the input image is presented with the pels for the pixels in the upper left of the image area at the lowest addressed memory locations, proceeding first to the right and then down the image area to higher addressed memory locations. This insures that for the common YVU formats in question, the expected image order is adhered to allowing for interoperable usage of the data. If the image is not presented in top down order, the test fails. If the image is presented in top down order, the test passes.
  3. Input image is presented without field inversion. For this assertion, the test assesses the interleaving of the 2:1 interlaced input data. The sequence of ‘top field’, ‘bottom field’ should be interleaved with the top field providing the top and thence every other line, and the bottom field providing the second and thence every other line. Failure to do this correctly results in various artifacts that make the data unsuitable for subsequent high quality use. The test passes if the data is interleaved correctly, and fails if the data is not.
  4. Input image is presented without mirror inversion. For this assertion, the test assesses whether the input image is presented with left - right (mirror image) inversion or with correct (observer’s view) orientation. This defect creates a sometimes subtle artifact that renders the data unsuitable for subsequent use. The test fails if the data is presented with left/right inversion and passes if the data is presented with correct left/right orientation.
  5. Input image has correct image detail. For this assertion, the test assesses the degree of difference between the image detail provided by the hardware and known characteristics of the test pattern displayed by the TSG from the MEDIA. The metrics used focus on correctness of decode of high detail areas of the image. This assesses luminance and chrominance bandwidth. In order to provide a cross-check, the test assesses the noise in low detail areas of the image. If the first set of metrics indicates low bandwidth or the second set indicates high noise (potentially invalidating the bandwidth measure), the test fails. If the first set of metrics indicates adequate bandwidth and the second set of metrics indicates low noise, the test passes.
  6. Input image has correct image levels. For this assertion, the test assesses the degree of difference between the image as decoded by the hardware and known characteristics of the test pattern displayed by the TSG from the MEDIA. The metrics focus on correctness of decode of image levels, disregarding to the extent possible image detail considerations. The test determines whether color and gray level decode is correct. A wide range of colors and gray levels is used to assess the correctness. The test passes if, for each color and gray level considered, the input image closely approximates the correct value. This test fails if any color or gray level does not closely approximate the correct value. If the test fails, it optionally provides indication of whether the gray levels and or color decoding is the source of the failure. This should be useful in determining whether or which adjustments to the hardware are needed to attain a correct decode.
  7. Input image has correct image dimensions. For this assertion, the test assesses the actual decoded image width, height, and feature placement. Errors in the time that hardware begins and ends digitization result in one or more of image translation, incorrect borders of arbitrary colors, image magnification, or image reduction. Correct dimensions mean a substantial lack of any of these artifacts.

For clarification, a pass scenario and two fail scenarios are described. Hardware that is capable of placing pixels within two pixels of the correct location results in a pass. Hardware capable of producing video with a ten pixel wide black strip at the left edge (early start of digitization) will fail. Hardware that significantly crops the actual image will fail (late start, early finish). The test passes if the input images substantially lack these artifacts. The test fails if any of these artifacts are present to a significant degree.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test configuration setup is described in the Test Methodology section. The test requires approximately 30 seconds to complete.

Results Interpretation

Each pass or fail condition is described in the test under each test assertion. Tests can produce a ‘pass with warning’ status. This is to be interpreted as ‘This assertion was not violated. A small increase in the degree of the defect addressed in this assertion would cause this assertion to be violated.’ This is an advisory message only.


Chapter 18: Legacy Reduced and Free Test Specification

The purpose of this test specification is to provide test coverage for Legacy Free requirements.

Test Coverage

Microsoft Windows Logo Program System and Device Requirements describes several requirements for Legacy Free test coverage.


Legacy Reduced and Free Test Assertions

The Legacy free test assertions are divided into these major groups: legacy-reduced platform, legacy-free hardware, legacy-free BIOS, and general system. The legacy test software verifies compliance with these assertions. The legacy reduced platform assertions are prerequisites for a Legacy Free system.


Reference Document Sources for Legacy Free Assertions

Hardware and firmware functional requirements specified in the following documents:

  • Debug Port Specification
    http://www.microsoft.com/hwdev/platform/PCdesign/LR/debugspec.asp
  • Legacy-Free Design Requirements
    http://www.microsoft.com/hwdev/platform/PCdesign/LR/Lf.asp
  • PC 2001 System Design Guide and PC 99 System Design Guide,
    http://www.microsoft.com/hwdev/platform/pcdesign/desguide/pcguides.asp
  • Microsoft Windows Driver Development Kit
    http://www.microsoft.com/ddk/
  • Microsoft Windows Logo Program System and Device Requirements, Version 2.0
    http://www.microsoft.com/hwdev/winlogo/
    (listed as "WLP#" in these assertions)
  • USB Mass Storage Class Specification Overview, Revision 1.0
    http://www.usb.org/developers/devclass_docs.html


Legacy-Reduced Platform Assertions

The assertions in this section are tested in TD-18.1 Legacy Free Test (LegFree)

18.1.1 System does not include ISA expansion devices or slots.

Reference documents: WLP# - A4.4.9; PC 2001 System Design Guide - SYS-0041.
Test description: TD-18.1 Legacy Free Test (LegFree)

18.1.2 Preinstalled components and upgrades do not require MS-DOS or legacy interfaces.

Peripherals included with the system must offer a non-legacy interface such as PCI, USB, USB 2.0, SCSI, IEEE 1394 or Card Bus.

Reference documents: WLP# - A4.4.8; PC 2001 System Design Guide - SYS-0042.
Test description: TD-18.1 Legacy Free Test (LegFree)

18.1.3 DELETED
18.1.4 Only Win32-based software and utilities ship with system.

This restriction does not apply to OEM diagnostic utilities or the emergency recovery software provided with the system.

Reference documents: WLP# - 5.
Test description: TD-18.1 Legacy Free Test (LegFree)


Legacy-Free Hardware Assertions

Minimum Hardware Assertions

The following assertions must be met in order to satisfy the requirements of the legacy-free platform.

These assertions are tested in TD-18.1 Legacy Free Test (LegFree)

18.2.1 If implemented, floppy disk capabilities do not use legacy FDC.

Reference documents: WLP# - A4.1.3, A4.4.4; PC 2001 System Design Guide - SYS-0067.
Test description: TD-18.1 Legacy Free Test (LegFree)

18.2.2 No legacy ports detected.

The following ports are considered legacy ports and must be replaced by USB or other non-legacy equivalents: FDC, Serial, Parallel, PS/2-compatible ports, ISA-based game ports and MPU 401 (MIDI) ports. Systems can provide Super I/O-based IrDA support through June 2001. Systems can use the 8042 controller internally, but must not include external PS/2 connectors.

Reference documents: WLP# - A4.1.3, A4.4.1; PC 2001 System Design Guide - SYS-0067.
Test description: TD-18.1 Legacy Free Test (LegFree)

18.2.3 A20M# is always de-asserted pulled high by the hardware at the processor or removed, and there is no way to mask the A20 address line.

Reference documents: WLP# - A4.1.6; PC 2001 System Design Guide - SYS-0047.
Test description: TD-18.1 Legacy Free Test (LegFree)

18.2.4 System supports legacy-free debug capabilities (An internal debug header must be provided).

Reference documents: WLP# - A4.1.5; PC 2001 System Design Guide - BIOS-0046.
Test description: TD-18.1 Legacy Free Test (LegFree)

18.2.5 Operating system detection software does not report the presence of Super I/O-dependent components with exceptions for the 8042 controller and legacy IRDA using COM2 on mobile systems.

Reference documents: WLP# - A4.1.3, A4.4.1; PC 2001 System Design Guide - BIOS-0045.
Test description: TD-18.1 Legacy Free Test (LegFree)

18.2.6 No use of restricted port addresses.

Hardware, whether on the system board or bundled with the system, must not use any of the port addresses historically used by legacy devices. If hardware is present and disabled, ACPI declaration must claim resources that cannot be freed with exceptions for the 8042 controller and legacy IRDA using COM2 on mobile systems.

Reference documents: WLP# - A4.1.3; PC 2001 System Design Guide - BIOS-0045.
Test description: TD-18.1 Legacy Free Test (LegFree)

Minimum Pre-installation Assertions

The following assertions must be met in order to satisfy the requirements of the legacy-free platform.

18.3.1 System includes USB with two user-accessible USB ports, minimum in addition to any used by the keyboard or pointing device.

Mobile PCs must include at least one user-accessible USB port, minimum in addition to any used by the keyboard or pointing device. The USB port on mobile systems may be on the system itself or a port replicator that is included with the system.

Reference documents: WLP# - A4.4.2
Test description: TD-18.1 Legacy Free Test (LegFree)

18.3.2 All external input devices included with the system must be USB Device Class Definition for Human Interface Devices, Version 1.1 (HID 1.1), compliant.

Reference documents: WLP# - A4.4.7; PC 2001 System Design Guide - INPT-0133.
Test description: TD-18.1 Legacy Free Test (LegFree)

18.3.3 DELETED
18.3.4 Peripherals included with the system must offer a non-legacy interface such as PCI, USB, USB 2.0, SCSI, IEEE 1394 or Card Bus.

Reference documents: WLP# - A4.4.6; PC 2001 System Design Guide - SYS-0042.
Test description: TD-18.1 Legacy Free Test (LegFree)

Minimum BIOS Assertions

The following assertions must be met by the BIOS in order to satisfy the requirements of the legacy-free platform.

18.4.1 The BIOS does not include boot dependencies on ISA.

Reference documents: WLP# - A4.4.9; PC 2001 System Design Guide - BIOS-0013.
Test description: TD-18.1 Legacy Free Test (LegFree)

18.4.2 No ISA-related components appear on BIOS setup screen.

Reference documents: WLP# - A4.4.9; PC 2001 System Design Guide - BIOS-0013.
Test description: TD-18.1 Legacy Free Test (LegFree)

18.4.3 BIOS provides boot support for USB keyboards, mice and hubs.

Reference documents: WLP# - A4.4.10; PC 2001 System Design Guide - BIOS-0005.2.
Test description: TD-18.1 Legacy Free Test (LegFree)

18.4.4 BIOS does not include hardware emulation of the 8042 controller if the 8042 controller is not present.

Reference documents: WLP# - A4.4.10; PC 2001 System Design Guide - BIOS-0005.2.
Test description: TD-18.1 Legacy Free Test (LegFree)

18.4.5 ROM BIOS interrupt handlers preserve values in all registers, including the high 16-bits of the 32-bit register.

Any ROM BIOS API that is documented to modify only the low 16-bits of a 32-bit register must preserve the high 16-bits of that 32-bit register when the bits are preserved there are less likely to be compatibility problems for applications that use that API.

If a ROM BIOS API is documented to modify the flags, for example, it is documented to return with the CARRY flag set or cleared--this restriction does not apply to individual arithmetic bits in the flags register. Any ROM BIOS API that is documented to modify the flags is assumed to modify all of the "arithmetic" flag bits: CARRY, AUX-CARRY, PARITY, ZEROSIGN, and OVERFLOW. The values of the other bits in the flags register must be preserved unless the API is documented to modify them.

Reference documents: WLP# - A4.4.10; PC 2001 System Design Guide - BIOS-0012.
Test description: TD-18.1 Legacy Free Test (LegFree)

18.4.6 DELETED
18.4.7 The LEGACY_DEVICES flag is set to 0 in the ACPI Fixed ACPI Description Table (FADT).

Reference documents: WLP# - A4.1.1; PC 2001 System Design Guide - BIOS-0015.
Test description: TD-18.1 Legacy Free Test (LegFree)

18.4.8 BIOS supports ACPI legacy-free reporting mechanism. The ACPI reset mechanism must be supported.

Reference documents: WLP# - A4.1.1; PC 2001 System Design Guide - BIOS-0015.
Test description: TD-18.1 Legacy Free Test (LegFree)

18.4.9 BIOS supports ACPI legacy-free reporting mechanism. LEGACY_DEVICES and 8042 flags set as defined in ACPI section 5.2.1.

Reference documents: WLP# - A4.1.1; PC 2001 System Design Guide - BIOS-0015.
Test description: TD-18.1 Legacy Free Test (LegFree)

18.4.10 BIOS supports required interrupts (8, 10, 11, 13, 15, 16, 19, 1A, 1B and 23.)

This assertion is not tested because the test cannot reliably test BIOS interrupts from within protected mode Windows.

Reference documents: WLP# - A4.1.4; PC 2001 System Design Guide - BIOS-0043.
Test description: TD-18.1 Legacy Free Test (LegFree)

18.4.11 BIOS handles long descriptors read from USB device attached at boot time.

Reference documents: WLP# - A2.4.8; PC 2001 System Design Guide - BIOS-0005.3.
Test description: TD-18.1 Legacy Free Test (LegFree)

General Requirement Assertions

The following assertions must be met by the general requirements for the Windows Logo Program in order to satisfy the requirements of the legacy-free platform.

18.5.1 BIOS supports booting from CD or DVD drive based on El Torito-Bootable CD-ROM Format Specification, v. 1.0.

Reference documents: WLP# - B10.1.5.6, ; PC 2001 System Design Guide - BIOS-0005.
Test description: TD-18.1 Legacy Free Test (LegFree)

18.5.2 Any USB storage components included with the system complies with USB Mass Storage Bulk-Only Specification, Revision 1.0 or later.

Reference documents: WLP# - A1.1.4, B10.1.2.10; PC 2001 System Design Guide - STOR-0343; USB Mass Storage Class Specification Overview, Revision 1.0.
Test description: TD-18.1 Legacy Free Test (LegFree)

18.5.3 Advanced Programmable Interrupt Controller (APIC), if present, properly connected so the system can be configured either in APIC mode or in the standard PIC ("virtual wire") mode.

Reference documents: WLP# - A1.4.12; PC 2001 System Design Guide - SYS-0001.3.
Test description: TD-18.1 Legacy Free Test (LegFree)

18.5.4 If IEEE 1394 is implemented, the host controller must comply with IEEE 1394a and 1394 OHCI 1.0.

Reference documents: WLP# - B2.2.2.1; PC 2001 System Design Guide - 1394-0091. See also Chapter 19, "IEEE 1394 Test Specification"
Test description: TD-18.1 Legacy Free Test (LegFree)

18.5.5 If CardBus is implemented, it must meet the requirements defined in Design Guidelines for PC Card and CardBus

Reference documents: WLP#B2.1.1.3; Design Guidelines for PC Card and CardBus, an addendum to PC 2001 System Design Guide, Version 1.0; See also Chapter 14, PC Card Test Specification"
Test description: TD-18.1 Legacy Free Test (LegFree)

18.5.6 If PCI components are implemented in the system, they must comply with PCI Local Bus Specification, Revision 2.2 and PCI Bus Power Management Interface Specification, Revision 1.1.

Reference documents: WLP#2.5.1; PCI Local Bus Specifications, Revision 2.2 and PCI Bus Power Management Interface Specification, Revision 1.1; see also Chapter 4, PCI Test Specification"
Test description: TD-18.1 Legacy Free Test (LegFree)

18.5.7 If Device Bay is implemented, it must comply with Device Bay Interface Specification, Version 1.0 and USB Device Bay Specification 1.0.

Reference documents: Device Bay Interface Specification, Version 1.0 and USB Device Bay Specification 1.0
Test description: TD-18.1 Legacy Free Test (LegFree)

18.5.8 DELETED
18.5.9 DELETED
18.5.10 DELETED


Legacy Reduced and Legacy Free Test Description

This section describes the Legacy test. The descriptions include an overview of the test, hardware and software setup, test algorithm/steps, and test results interpretation.


TD-18.1 Legacy Free Test (LegFree)

Test Kit: HCT 11, HCT 10

Overview

This test verifies a target system that claims to be Legacy Free via the ACPI tables. The test checks legacy I/O addresses, memory locations, and PnP devnodes for the existence of legacy devices. This test also verifies that A20M#, if it exists, can’t be asserted and that the BIOS preserves the general-purpose registers when its INT handlers are called.

Test Methodology

The general methodology of this test is to enumerate the system and check for any existing legacy devices. The test verifies that A20M# can’t be asserted or does not exist, reset the system via the ACPI reset mechanism and verify the system works in both PIC and APIC mode. The Legacy Free test performs the following steps:

If platform claims being Legacy Free (LEGACY_DEVICES flag = 0)

  1. Enumerate devices.
  2. Perform exhaustive search for legacy devices at their known I/O and memory locations as well as PNP devnodes.
  3. Compare results of search with 8042 and LEGACY_DEVICES flags in ACPI tables.
  4. Test for presence of A20M#

a. If 8042 present,

If Port 92h is present and not allocated to something else, clear bit 1 of Port 92h to give KBC control of line.

b. Issue the known command to de-assert A20M# from KBC.

c. Write value above 1Mb.

d. Verify no wrap around.

e. Issue command(s) to assert A20M# from KBC.

f. Write new value in low memory, check for wrap around.

g. If wrap around occurred, fail the platform.

h. Restore A20M# to de-asserted state.

i. If Port 92h present and not allocated to something else

(a) Clear bit 1 of Port 92h.

(b) Write value above 1Mb.

(c) Verify no wrap around.

(d) Set bit 1 of Port 92h

(e) Write new value in low memory, check for wrap around.

(f) If wrap around occurred, the platform fails.

  5. Prompt user to ensure USB keyboard and mouse are plugged in
  6. Execute BIOS INTs and check that all registers are preserved
  7. Program FoxFire card into Dx state via PMCSR
  8. Execute ACPI reset command
  9. On system reset, FoxFire card’s PMCSR register should be default value. This is to ensure that system reset also resets PCI bus.
  10. Hook/Filter Timer 0 interrupt before OS enables it, ensure Timer 0 is firing IRQ at system bootup.
  11. Disable all interrupts except for USB keyboard.
  12. Switch system between APIC and PIC mode.
  13. Ensure user input is coming from USB keyboard in both APIC and PIC mode.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The target system must support the 1999 changes to the ACPI Specification v1.0b, Section 5.2.1. A FoxFire II card needs to be present in the system to verify the ACPI reset mechanism and a USB keyboard and mouse are needed.

Results Interpretation

This test creates a detailed log file of test results and displays pass or fail status on the screen.


Chapter 19: IEEE 1394 Test Specification

The purpose of this test specification is to provide test coverage for Institute of Electrical and Electronics Engineers, Inc (IEEE) 1394 requirements. The IEEE 1394 is a high-speed serial bus that provides enhanced PC connectivity for a wide range of devices, including consumer electronics audio/video (A/V) appliances, storage peripherals, other PCs, and portable devices. IEEE 1394 has been adopted by the consumer electronics industry and is expected to provide a volume, Plug and Play-compatible expansion interface for the PC. The 100-MB/sec, 200-MB/sec, and 400-MB/sec transfer rates currently specified in IEEE P1394.a and the proposed enhancements in IEEE P1394.b are well suited to multi-streaming I/O requirements.

Test Coverage

Microsoft Windows Logo Program System and Device Requirements describes several requirements for IEEE 1394.


IEEE 1394 Test Assertions

The IEEE 1394 assertions are divided into these major groups: Data Transfer, Fast Bus Reset, Data Transfer Completion, Suspend and Resume Device Support, HostController Power Management, Device Power Identification, Multiport Device Repeater, Port Current, Alternate Power Provider Capabilities, Power Consumer Post-Reset, Power Consumer Configuration ROM, Device Port Suspend and Resume, Port Disable and Resume, Device Power Config ROM, POWER_CHANGE Config ROM, Device Disable/Enable on Extended Bus, IEEE 1394 Configuration ROM, and IEEE 1394 Interoperability. The IEEE 1394 software verifies compliance with these assertions.

Reference Document Sources for IEEE 1394 Assertions

Functional requirements specified in the following documents:

1394 Open Host Controller Interface Specification, Revision 1.0

ftp://ftp.austin.ibm.com/pub/chrptech/1394ohci/ohcir100.pd

1394 Trade Association Power Specification, Part 1: Cable Power Distribution; 1394 Trade Association Power Specification, Part 3: Power State Management

ftp://ftp.p1394pm.org/pub/p1394pm/

AV/C Digital Interface Command Set VCR Subunit Specification, V. 2.0.1

http://www.1394TA.org

IEC 61883 Digital Interface for Consumer Electronic Audio/Video Equipment

http://www.iec.ch/webstore/

IEEE 1394-1995 or later standards, and IEEE 1394a
IEEE 1212-1991 and function discovery in IEEE 1212r

Global Engineering Documents at http://global.ihs.com/

NCITS Serial Bus Protocol (SBP-2) transport protocols [ANSI NCITS 3.25-1998 (SBP-2)]
NCITS T10, Reduced Block Commands (RBC)
NCITS T10 Multimedia Command Set 2 (MMC-2)

Global Engineering Documents at http://global.ihs.com/

Microsoft Windows Logo Program System and Device Requirements, Version 2.0

http://www.microsoft.com/hwdev/winlogo/
(listed as "WLP#" in these assertions)

Microsoft Windows Driver Development Kit

http://www.microsoft.com/ddk/

PC 2001 System Design Guide and PC 99 System Design Guide

http://www.microsoft.com/hwdev/platform/pcdesign/desguide/pcguides.asp

SBP-2 Support and Windows 2000

http://www.microsoft.com/hwdev/tech/print/sbp2_w2000.asp


1394 Asychronous and Isochronous Loopback Test Assertions

WHQL Test Specification

Previous Next

1394 Asynchronous and Isochronous Loopback Test Assertions

19.1.1 Asynchronous and isochronous loop back tests will be performed on all accessible internal ports at speeds of S100, S200 and S400 Mbps. The ports are connected to another PC that supports the equivalent speeds.

Reference document: WLP#-B2.2.1.3; PC 2001 System Design Guide - 1394-0096.
Test Description: TD-19.1 1394 Asynchronous and Isochronous Loopback Test Description


Fast Bus Reset Test Assertions

19.2.1 All ports and devices support fast bus resets with the worst case being 100 (sec and the average case being 5 (sec.

Reference document: WLP#-B2.2.4.1; PC 2001 System Design Guide - 1394-0092.
Test Description: TD-19.2 Fast Bus Reset Test Description


Data Transfer Completion Test Assertions

19.3.1 Devices (peripheral device or host controller) under test must be able to complete asynchronous and isochronous (if device supports isochronous transfer) data transfer tests while another device generates bus resets.

Reference document: WLP#-B2.2.4.6; PC 2001 System Design Guide - 1394-0103.
Test Description: TD-19.3 Data Transfer Completion Test Description


Suspend and Resume Device Support Test Assertions

19.4.1 Devices (peripheral device or host controller) under test must support suspend and resume states.

Reference document: WLP#-B2.2.4.1; PC 2001 System Design Guide - 1394-0092; IEEE 1394a.
Test Description: TD-19.4 Suspend and Resume Device Support Test Description


HostController Power Management Test Assertions

19.5.1 Host controllers must support PCI 1.1 Power Management states D0, D1, D2, and D3.

Reference document: WLP#-B2.2.5.2; PC 2001 System Design Guide - 1394-0091; IEEE 1394a.
Test Description: TD-19.5 HostController Power Management Test Description


Device Power Identification Test Assertions

19.6.1 Every device must correctly identify itself as a Power Producer, Alternate Power Producer, Power Consumer, or Self-Powered device through the "Prw" field of its Self-ID packet.

Reference document: WLP#-B2.2.4.6; PC 2001 System Design Guide - 1394-103; IEEE 1394a.
Test Description: TD-19.6 Device Power Identification Test Description


Multiport Device Repeater Test Assertions

19.7.1 Devices with multiple ports must be able to function as repeaters when local power is shut off.

Reference document: WLP#-B2.2.4.6; PC 2001 System Design Guide - 1394-103; 1394 Trade Association Power Specification Part 1.
Test Description: TD-19.7 Multiport Device Repeater Test Description


Port Current Test Assertions

19.8.1 Current drawn through a single port of any device shall not exceed 1.5 A

Reference document: WLP#-B2.2.4.6; PC 2001 System Design Guide - 1394-103; 1394 Trade Association Power Specification Part 1.
Test Description: TD-19.8 Port Current Test Description


Alternate Power Provider Capabilities Test Assertions

19.9.1 For Alternate Power Provider devices, the Cable_Power_Supply_Level entry of the Configuration ROM must correctly indicate the power delivery capabilities.

Reference document: WLP#-B2.2.4.6; PC 2001 System Design Guide - 1394-103; 1394 Trade Association Power Specification Part 1.
Test Description: TD-19.9 Alternate Power Provider Capabilities Test Description


Power Consumer Post-Reset Test Assertions

19.10.1 After reset, Power Consumers do not consume more than 3 Watts of power until they receive a link-on packet from the Power Manager.

Reference document: WLP#-B2.2.4.6; PC 2001 System Design Guide - 1394-103; 1394 Trade Association Power Specification Part 1.
Test Description: TD-19.10 Power Consumer Post-Reset Test Description


Power Consumer Configuration ROM Test Assertions

19.11.1 If a Power Consumer requires more power than can be indicated in its self-ID packet, the Configuration ROM entries which describe the power requirements of the device are required.

Reference document: WLP#-B2.2.4.6; PC 2001 System Design Guide - 1394-103; 1394 Trade Association Power Specification Part 1.
Test Description: TD-19.11 Power Consumer Configuration ROM Test Description


Device Port Suspend and Resume Test Assertions

19.12.1 Devices are able to enter into suspend states and resume appropriately.

Reference document: WLP#-B2.2.4.6; PC 2001 System Design Guide - 1394-103; 1394 Trade Association Power Specification Part 2.
Test Description: TD-19.12 Device Port Suspend and Resume Test Description


Port Disable and Resume Test Assertions

19.13.1 Devices must be able to disable and then resume their ports.

Reference document: WLP#-B2.2.4.6; PC 2001 System Design Guide - 1394-103; 1394 Trade Association Power Specification Part 3.
Test Description: TD-19.13 Port Disable and Resume Test Description


Device Power Config ROM Test Assertions

19.14.1 All devices must have valid NODE_POWER_STATE, NODE_POWER_CONTROL, UNIT_POWER_STATE, and UNIT_POWER_CONTROL entries in their Configuration ROM.

Reference document: WLP#-B2.2.4.6; PC 2001 System Design Guide - 1394-103; 1394 Trade Association Power Specification Part 3.
Test Description: TD-19.14 Device Power Config ROM Test Description


POWER_CHANGE Config ROM Test Assertions

19.15.1 Power Manager capable devices have a valid POWER_CHANGE Configuration ROM entry.

Reference document: WLP#-B2.2.4.6; PC 2001 System Design Guide - 1394-0103; 1394 Trade Association Power Specification Part 3.
Test Description: TD-19.15 POWER_CHANGE Config ROM Test Description


Device Disable/Enable on Extended Bus Test Assertions

19.16.1 All peripheral devices must pass 500 cycles of disable and enable in both a minimal and extended bus configuration.

Reference document: WLP#-B2.2.1.3; PC 2001 System Design Guide - 1394-0096.
Test Description: TD-19.16 Device Disable/Enable on Extended Bus Test Description


1394 Configuration ROM Test Assertions

19.18.1 All devices must support the IEEE 1212-2000 General ROM format. This includes having Header information, and bus information block and root directory entries.

Reference document: WLP#-B2.2.4.2; PC 2001 System Design Guide - 1394-0099; IEEE 1212-2000.
Test Description: TD-19.17 1394 Configuration ROM Test Description

19.18.2 Devices must supply textual descriptors for the Vendor_ID and Model_ID entries of the Configuration ROM.

Reference document: WLP#-B2.2.4.12; PC 2001 System Design Guide - 1394-0099; IEEE 1212-2000.
Test Description: TD-19.17 1394 Configuration ROM Test Description


1394 Interoperability Test Assertions

19.19.1 All 1394 devices must have the ability to interoperate with a variety of different device classes on the same 1394 bus at the same time.

Reference document: WLP#-B2.2.1.3; PC 2001 System Design Guide - 1394-0096.
Test description: TD-19.18 1394 Interoperability Test Description


IEEE 1394 Test Descriptions

TD-19.1 1394 Asynchronous and Isochronous Loopback Test Description

Test Kit: HCT 11, HCT 10

Overview

Asynchronous and isochronous loopback tests will be performed on all accessible internal ports at speeds of S100, S200 and S400 Mbps. The ports are connected to another PC that supports the equivalent speeds.

The 1394 loopback test assures that a given host controller is able to successfully send and receive all permutation of asynchronous and isochronous data. The test requires One PC to have two separate 1394 host controllers installed. The 1394 host controllers must be connected together via a 1394 cable.

The asynchronous test will force allocation of asynchronous address space on one host controller hand have the other host controller issue asynchronous reads, writes and locks repeatedly, verifying the contents of the data region each time. The test will issue transactions to both Quadlet aligned and Byte aligned 1394 addresses. Also, both Quadlet requests and Block requests will be utilized. Furthermore, the test will operate both above and below the FFFF:00000000 asynchronous address space region.

The isochronous test will have one host controller issue isochronous talks, while the other issues isoch listens and verifies the incoming data. The test will ensure that the host controllers can receive and send data on all channels. The test will specify different values for the Sy and Tag fields and ensure the data stream can be synchronized to those values. The test will send variable length data, while ensuring there is no data lost by the listening node. The talking node will also use Header Scatter Gather features to send data, again ensuring that the listening node correctly receives all sent data.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires a PC with at least two IEEE-1394 host controller installed, connected via 1394 cables. In addition a 1394 HDD and 1394 Conferencing Camera, plus whatever device is being tested.

Results Interpretation

If any iterations of the loopback tests fail at either S100, S200 or S400 Mbps, then the system has failed the test.


TD-19.2 Fast Bus Reset Test Description

Overview

An Isochronous stream will be started between two devices. A third device will be plugged and unplugged, causing bus resets. These bus resets must not interfere with the isochronous stream.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires a PC with at least two IEEE-1394 host controller installed, connected via 1394 cables. In addition a 1394 HDD and 1394 Conferencing Camera, plus whatever device is being tested.

Results Interpretation

If the isochronous stream does not complete successfully, the device has failed the test.


TD-19.3 Data Transfer Completion Test Description

Overview

The device will undergo asynchronous and isochronous (if supported) data transfers while another device on the bus generates bus resets.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires a PC with at least two IEEE-1394 host controller installed, connected via 1394 cables. In addition a 1394 HDD and 1394 Conferencing Camera, plus whatever device is being tested.

Results Interpretation

If the data transfer tests fail, the device has failed the test.


TD-19.4 Suspend and Resume Device Support Test Description

Overview

The test repeats an automated suspend and resume of the system. After each repetition, the functionality of each connected 1394 device is tested.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires a PC with at least two IEEE-1394 host controller installed, connected via 1394 cables. In addition a 1394 HDD and 1394 Conferencing Camera, plus whatever device is being tested.

Results Interpretation

If the system is unable to enter suspend states, or the devices do not function correctly once resumed, then the system has failed the test.


TD-19.5 Host Controller Power Management Test Description

Overview

The system repeats an automated suspend and resume into and out of states D0, D1, D2 and D3. After each cycle, the functionality of all devices is verified.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires a PC with at least two IEEE-1394 host controller installed, connected via 1394 cables. In addition a 1394 HDD and 1394 Conferencing Camera, plus whatever device is being tested.

Results Interpretation

If the system is unable to enter all the suspend states, or the devices do not function correctly after resuming, then the device has failed the test.


TD-19.6 Device Power Identification Test Description

Overview

The Self-ID packet is checked against its known power type to ensure that the device reports itself correctly.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires a PC with at least two IEEE-1394 host controller installed, connected via 1394 cables. In addition a 1394 HDD and 1394 Conferencing Camera, plus whatever device is being tested.

Results Interpretation

If the power type identified in the Self-ID packet does not match the power type of the device, then the device has failed the test.


TD-19.7 Multiport Device Repeater Test Description

Overview

The device is connected to two other devices through different ports. Then, the device is turned off. The two powered devices must be able to communicate, using the device without power as a repeater. All serial bus traffic must be passed across the device that has been turned off.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires a PC with at least two IEEE-1394 host controller installed, connected via 1394 cables. In addition a 1394 HDD and 1394 Conferencing Camera, plus whatever device is being tested.

Results Interpretation

If the two powered devices are unable to communicate across the serial bus, the device has failed the test.


TD-19.8 Port Current Test Description

Overview

The current drawn through every port shall be tested to ensure it is less than 1.5 A.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires a PC with at least two IEEE-1394 host controller installed, connected via 1394 cables. In addition a 1394 HDD and 1394 Conferencing Camera, plus whatever device is being tested.

Results Interpretation

If more than 1.5 A are drawn through any port, then the device has failed the test.


TD-19.9 Alternate Power Provider Capabilities Test Description

Overview

The Cable_Power_Supply_Level field of the Configuration ROM is inspected to ensure a valid value is provided.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires a PC with at least two IEEE-1394 host controller installed, connected via 1394 cables. In addition a 1394 HDD and 1394 Conferencing Camera, plus whatever device is being tested.

Results Interpretation

If a valid value is not present, then the test has failed the test.


TD-19.10 Power Consumer Post-Reset Test Description

Overview

All Power Consumer devices are inspected to ensure they do not begin sinking more than 3 Watts of power until they receive a link-on packet from the Power Manager.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires a PC with at least two IEEE-1394 host controller installed, connected via 1394 cables. In addition a 1394 HDD and 1394 Conferencing Camera, plus whatever device is being tested.

Results Interpretation

If a device consumes more than 3 Watts before receiving a link-on packet, the device has failed the test.


TD-19.11 Power Consumer Configuration ROM Test Description

Overview

If a device requires more power than can be represented in the Self-ID packet, then the Configuration ROM is inspected for additional information regarding the power consumption requirements.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires a PC with at least two IEEE-1394 host controller installed, connected via 1394 cables. In addition a 1394 HDD and 1394 Conferencing Camera, plus whatever device is being tested.

Results Interpretation

If the Configuration ROM does not describe the power consumption requirements, then the device has failed the test.


TD-19.12 Device Port Suspend and Resume Test Description

Overview

A device port must be able to suspend when any of the events occur: the port is sent a Suspend Command Packet, it detects an RX_SUSPEND, it is in the same PHY as another port which has detected an RX_SUSPEND, it detects an RX_DISABLE_NOTIFY, or it no longer detects a BIAS. Once the device receives the Suspend Command Packet it should suspend and then enter a low power state. The device must also signal all of its other active ports to suspend by using TX_SUSPEND. The device must resume itself when receiving either a Resume Packet or a Resume Port Command Packet.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires a PC with at least two IEEE-1394 host controller installed, connected via 1394 cables. In addition a 1394 HDD and 1394 Conferencing Camera, plus whatever device is being tested.

Results Interpretation

If the device does not suspend and cause its other active ports to suspend, and then later resume on the appropriate events, then the device has failed the test.


TD-19.13 Port Disable and Resume Test Description

Overview

A device is able to disable its ports by receiving either a Port Disable Command or by having the link write directly to the port register and setting the disable bit. Once disabled, a device must be able to be resumed by a Port Enable Command.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires a PC with at least two IEEE-1394 host controller installed, connected via 1394 cables. In addition a 1394 HDD and 1394 Conferencing Camera, plus whatever device is being tested.

Results Interpretation

If the device does not suspend and cause its other active ports to suspend, and then later resume on the appropriate events, then the device has failed the test.


TD-19.14 Device Power Config ROM Test Description

Overview

The Configuration ROM of the device is inspected and checked for valid values of NODE_POWER_STATE, NODE_POWER_CONTROL, UNIT_POWER_STATE, and UNIT_POWER_CONTROL.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires a PC with at least two IEEE-1394 host controller installed, connected via 1394 cables. In addition a 1394 HDD and 1394 Conferencing Camera, plus whatever device is being tested.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-19.15 POWER_CHANGE Config ROM Test Description

Overview

The Configuration ROM of the device is inspected and checked for a valid value of POWER_CHANGE.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires a PC with at least two IEEE-1394 host controller installed, connected via 1394 cables. In addition a 1394 HDD and 1394 Conferencing Camera, plus whatever device is being tested.

Results Interpretation

If a valid value does not exist for the Configuration ROM entry, then the device has failed this test.


TD-19.16 Device Disable/Enable on Extended Bus Test Description

Overview

Peripheral devices undergo 500 cycles of disable and enable. This is done in a minimal bus configuration (the device and a PC) and an extended bus configuration (the device, a PC and at least two other devices).

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires a PC with at least two IEEE-1394 host controller installed, connected via 1394 cables. In addition a 1394 HDD and 1394 Conferencing Camera, plus whatever device is being tested.

Results Interpretation

After every cycle of disable and enable, the functionality of all devices is verified. If any of the devices on the bus are not functional, the device has failed this test.


TD-19.17 1394 Configuration ROM Test Description

Test Kit: HCT 11, HCT 10

Overview

The 1394 Configuration Rom test examines the Configuration ROM of every device attached to the PCs initial 1394 bus, as well as that off the 1394 Host Controller itself. The test ensures that all of the Configuration ROMs adhere to the IEEE-1212r-2000 and IEEE-1394 standards.

In order to successfully pass the test, all devices must correctly implement General ROM format specified by IEEE-1212r-2000. The rom_crc_value specified throughout the Configuration ROM must correctly match the data it protects. The bus_name entry in the Bus_Info_Block section must contain the following values: 0x31, 0x33, 0x39 and 0x34 ("1394"). The max_rec value must correspond to the maximum allowable values, determined by the speed of the node, as indicated in the IEEE-1394a specifications. A valid eui64 must also be provided in the Bus_Info_Block. All Unit Directories must be pointed to from the Root Directory and contain Textual Descriptors for the Vendor_ID and Model_ID values.

The Configuration ROM of the device is inspected to ensure that it contains Header information, bus information block, and root directory entries.

The Configuration ROM of the device is inspected and checked for valid textual descriptors in the Vendor_ID and Model_ID fields.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires a PC with at least two IEEE-1394 host controller installed, connected via 1394 cables. In addition a 1394 HDD and 1394 Conferencing Camera, plus whatever device is being tested.

Results Interpretation

If any of the information is not in the Configuration ROM, the device has failed the test.


TD-19.18 1394 Interoperability Test (1394hct.exe –I) Description

WHQL Test Specification

Previous Next

TD-19.18 1394 Interoperability Test Description

Test Kit: HCT 11, HCT 10

Overview

This test is designed to ensure that typical 1394 devices present on a system will work correctly in given configurations. This test will initially scan all the devices present on the system, and ensure there are a SBP-2 Hard drive and a 1394 Conferencing camera present on the system. Once this has been verified, the test will begin creating and destroying files and directories on the HDD, and previewing video from the Conferencing camera. Both devices must function successfully for the test to pass.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires a PC with at least two IEEE-1394 host controller installed, connected via 1394 cables. In addition a 1394 HDD and 1394 Conferencing Camera, plus whatever device is being tested.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


Chapter 20: Modem Test Specification

This document describes assertions and tests for Modems. This document also provides test coverage information to facilitate initial development and review cycle processes focusing on Modem test coverage.

This document describes basic functionality tests for modems so that each step maps to basic AT Commands/Responses. This document also describes the assertions for which a given test can be failed. These tests specifications are independent of the operating system or the intermediate telephony layer support in operating system.

The test specifications are independent of bus types (PCI, USB, CardBus, etc.) unless specifically stated.


Modem Test Assertions

The Modem assertions are divided into these major groups: Send File, Compression, Error Control, Forced Error Control, Speed, Speed Adjust, Inactivity Timeout, Hardware FlowControl, Software FlowControl, Call Setup Timeout, Blind Dial, Speaker Volume, Speaker Mode, Caller ID, Generate Digits, Monitor Digits, Handset Hookswitch, Speaker Phone Hookswitch, Speaker Phone Volume/Gain, Handset Audio, and Line Audio. The Modem software verifies compliance with these assertions.

Reference Documents for Modem Assertions

Bellcore Technical References

http://www.telcordia.com/index.html

Communications Device Class Power Management Reference Specification, V. 2.0

[MOD-0381, 0382]
http://www.microsoft.com/hwdev/resources/specs/pmref/PMcom.asp

EIA Standard #ANSI/EIA-516-88

Joint EIA/CVCC Recommended Practice for Teletext: North American Basic Teletext Specification (NABTS) - http://www.tiaonline.org/

ETSI (European Telecommunication Standards Institute)

http://www.etsi.org/

ITU (International Telecommunication Union) communications standards

http://www.itu.int/publications/index.html

Microsoft Windows Driver Development Kit

http://www.microsoft.com/ddk/

Microsoft Windows Logo Program System and Device Requirements, Version 2.0

http://www.microsoft.com/hwdev/winlogo/
(listed as "WLP#" in these assertions)

USB Class Definitions for Communications Devices

Version 1.1 for External Devices
http://www.usb.org/developers/docs.html

PC 2001 System Design Guide and PC 99 System Design Guide

http://www.microsoft.com/hwdev/platform/pcdesign/desguide/pcguides.asp

PHS Internet Access Forum Standard (PIAFS)

http://www.arib.or.jp/piaf/piaf_E_index.htm


Send File - Modem Assertions

Assertions in this section are tested in TD-20.1 Send File Test (SENDFILE).

20.1.1 Connection is established.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.1 Send File Test (SENDFILE)

20.1.2 CRC is valid for Data Transferred.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.1 Send File Test (SENDFILE)


Compression - Modem Assertions

Assertions in this section are tested in TD-20.2 Compression Test (COMPRESSION).

20.2.1 Compression Bit is SET.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.2 Compression Test (COMPRESSION)

20.2.2 Compression Bit is not SET.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.2 Compression Test (COMPRESSION)


Error Control - Modem Assertions

Assertions in this section are tested in TD-20.3 Error Control Test (ERRCTRL).

20.3.1 Error Control Bit is SET.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.3 Error Control Test (ERRCTRL)

20.3.2 Error Control Bit is not SET.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.3 Error Control Test (ERRCTRL)


Forced Error Control - Modem Assertions

20.4.1 Connection is NOT Established.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.4 Forced Error Control Test (FERRCTRL)


Speed - Modem Assertions

20.5.1 Connection Speed is 28.8 Kbps or higher.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.5 Speed Test (SPEED)


Speed Adjust - Modem Assertions

Assertions in this section are tested in TD-20.6 Speed Adjust Test (SPEEDADJUST).

20.6.1 Connection Speed is 19200 bps.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.6 Speed Adjust Test (SPEEDADJUST)


Inactivity Timeout - Modem Assertions

Assertions in this section are tested in TD-20.7 Inactivity Timeout Test (INACTIVITY).

20.7.1 Modem NOT disconnected within fixed time interval.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.7 Inactivity Timeout Test (INACTIVITY)

20.7.2 Modem NOT disconnected before a fixed time setting.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.7 Inactivity Timeout Test (INACTIVITY)


Hardware FlowControl - Modem Assertions

Assertions in this section are tested in TD-20.8 Hardware FlowControl Test (FLOWCTRLHARD).

20.8.1 Hardware FlowControl Bit is Set.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.8 Hardware FlowControl Test (FLOWCTRLHARD)

20.8.2 No TAPI Failures when resetting Hardware FlowControl Bit.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.8 Hardware FlowControl Test (FLOWCTRLHARD)


Software FlowControl - Modem Assertions

Assertions in this section are tested in TD-20.9 Software FlowControl Test (FLOWCTRLSOFT).

20.9.1 Software FlowControl Bit is Set.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.9 Software FlowControl Test (FLOWCTRLSOFT)

20.9.2 No TAPI Failures when resetting Hardware FlowControl Bit.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.9 Software FlowControl Test (FLOWCTRLSOFT)


Call Setup Timeout - Modem Assertions

20.10.1 Time taken to disconnect is less than 18 seconds.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.10 CallSetup Timeout Test (CALLSETUP)


Blind Dial - Modem Assertions

20.11.1 Modem can dial when phone line is unplugged.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.11 Blind Dial Test (BLINDDIAL)


Speaker Volume - Modem Assertions

Assertions in this section are tested in TD-20.12 Speaker Volume Test (SPEAKERVOL).

20.12.1 If Modem supports HIGH speaker volume setting, set speaker volume to high.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.12 Speaker Volume Test (SPEAKERVOL)

20.12.2 If Modem supports MEDIUM speaker volume setting, set speaker volume to medium.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.12 Speaker Volume Test (SPEAKERVOL)

20.12.3 If Modem supports LOW speaker volume setting, set speaker volume to low.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.12 Speaker Volume Test (SPEAKERVOL)


Speaker Mode - Modem Assertions

Assertions in this section are tested in TD-20.13 Speaker Mode Test (SPEAKERMODE).

20.13.1 If Modem supports ON speaker mode setting, set speaker mode to ON.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.13 Speaker Mode Test (SPEAKERMODE)

20.13.2 If Modem supports SETUP speaker mode setting, set speaker mode to SETUP.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.13 Speaker Mode Test (SPEAKERMODE)

20.13.3 If Modem supports OFF speaker mode setting, set speaker mode to OFF.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.13 Speaker Mode Test (SPEAKERMODE)

20.13.4 If Modem supports DIAL speaker mode setting, set speaker mode to DIAL.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.13 Speaker Mode Test (SPEAKERMODE)


Caller ID - Modem Assertions

20.14.1 If modem supports Caller ID, either Number or Name is displayed as Caller ID Information.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.14 CallerID Test (CALLERID)


Generate Digits - Modem Assertions

20.15.1 If voice modem supports capability to generate digits, it can generate 0-9,# and * digits.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.15 Generate Digits Test (GENDIGITS)


Monitor Digits - Modem Assertions

20.16.1 If modem supports capability to monitor digits, it can detect the digit pressed by user on remote handset.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.16 Monitor Digits Test (MONDIGITS)


Handset Hookswitch - Modem Assertions

Assertions in this section are tested in TD-20.17 Handset HookSwitch Test (HSHOOKSWITCH).

20.17.1 If modem supports capability to detect handset hookswitch, it can detect when the handset connected to modem goes OFF hook.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.17 Handset HookSwitch Test (HSHOOKSWITCH)

20.17.2 If modem supports capability to detect handset hookswitch, it can detect when the handset connected to modem goes ON hook.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.17 Handset HookSwitch Test (HSHOOKSWITCH)


Speaker Phone Hookswitch - Modem Assertions

Assertions in this section are tested in TD-20.18 SpeakerPhone HookSwitch Test (SPHOOKSWITCH).

20.18.1 If modem supports capability to detect speaker phone hookswitch, it can detect when the speakerphone connected to modem goes OFF hook using TAPI call phoneGetHookSwitch.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.18 SpeakerPhone HookSwitch Test (SPHOOKSWITCH)

20.18.2 If modem supports capability to detect speaker phone hookswitch, it can detect when the speakerphone connected to modem goes ON hook using TAPI call phoneGetHookSwitch.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.18 SpeakerPhone HookSwitch Test (SPHOOKSWITCH)

20.18.3 If modem supports capability to detect speaker phone hookswitch, it can detect when the microphone connected to modem is mute using TAPI call phoneGetStatus.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.18 SpeakerPhone HookSwitch Test (SPHOOKSWITCH)

20.18.4 If modem supports capability to detect speaker phone hookswitch, it can detect when the speakerphone connected to modem goes OFF hook using TAPI call phoneGetStatus.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.18 SpeakerPhone HookSwitch Test (SPHOOKSWITCH)

20.18.5 If modem supports capability to detect speaker phone hookswitch, it can detect when the speakerphone connected to modem goes ON hook using TAPI call phoneGetStatus.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.18 SpeakerPhone HookSwitch Test (SPHOOKSWITCH)

20.18.6 User selected fail when speakerphone connected to modem is set to OFF hook.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.18 SpeakerPhone HookSwitch Test (SPHOOKSWITCH)

20.18.7 User selected fail when microphone connected to modem is set to MUTE.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.18 SpeakerPhone HookSwitch Test (SPHOOKSWITCH)

20.18.8 User selected fail when speakerphone connected to modem is set to ON hook.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.18 SpeakerPhone HookSwitch Test (SPHOOKSWITCH)


Speaker Phone Volume/Gain - Modem Assertions

Assertions 20.18.1, 20.18.4 and 20.18.6 are tested in TD-20.19 SpeakerPhone Volume/Gain Test (SPVOLGAIN).

20.19.1 If modem supports capability to set speaker phone volume, it can set speaker phone volume to HIGH.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.19 SpeakerPhone Volume/Gain Test (SPVOLGAIN)

20.19.2 If modem supports capability to set speaker phone volume, it can set speaker phone volume to LOW.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.19 SpeakerPhone Volume/Gain Test (SPVOLGAIN)

20.19.3 If modem supports capability to set microphone gain, it can set microphone gain to HIGH.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.19 SpeakerPhone Volume/Gain Test (SPVOLGAIN)

20.19.4 If modem supports capability to set microphone gain, it can set microphone gain to LOW.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.19 SpeakerPhone Volume/Gain Test (SPVOLGAIN)


Handset Audio - Modem Assertions

20.20.1 If modem supports handset audio capability, it can record using the handset connected to the modem.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.20 Handset Audio Test (HSAUDIO)


Line Audio - Modem Assertions

20.21.1 If modem supports line audio capability, it can record using the remote handset.

Reference documents: WLP# - B6.1; AT Command set doc, Revision 1.0(a); PC 2001 System Design Guide, Chapter 13, Modem Requirements.
Test descriptions: TD-20.21 Line Audio Test (LINEAUDIO)


AT+GCI - Modem Assertions

Assertions in this section are tested in TD-20.22 AT +GCI Test (ATGCI).

20.22.1 If the modem supports the AT+GCI=? command, it displays the list of countries/regions in format described in V.250 specification.

Reference documents: WLP# - B6.1; PC 2001 System Design Guide, Chapter 13, Modem Requirements; V.250 ITU-T Specification; T.35 Annex A Country Codes.
Test descriptions: TD-20.22 AT +GCI Test (ATGCI)

20.22.2 If the modem supports the AT+GCI=? command, the list of countries/regions contain valid country codes as defined in T.35 Annex A.

Reference documents: WLP# - B6.1; PC 2001 System Design Guide, Chapter 13, Modem Requirements; V.250 ITU-T Specification; T.35 Annex A Country Codes.
Test descriptions: TD-20.22 AT +GCI Test (ATGCI)

20.22.3 If the modem supports the AT+GCI? command, the country code returned by this command is present in the list of countries/regions mentioned in 20.22.1 and 20.22.2

Reference documents: WLP# - B6.1; PC 2001 System Design Guide, Chapter 13, Modem Requirements; V.250 ITU-T Specification; T.35 Annex A Country Codes.
Test descriptions: TD-20.22 AT +GCI Test (ATGCI)


MCT Core Test Descriptions

This section describes the tests to verify the basic functionality for any modem device

TD-20.1 Send File Test (SENDFILE)

The Send File Test verifies that the test modem can make a connection with a reference modem in dial or answer mode. It also verifies that fixed amount of ASCII data can be sent after a connection is made.

SENDFILE will perform the following steps:

  1. Static and Dynamic Initialization of Test and Reference Modem
  2. Test Modem setting up call using ATDT and getting Connection Response.(Dial Mode)
  3. ASSERT (20.1.1) : Test Fail if Connection is not established
  4. Send ASCII data from Test Modem and Receive same ASCII data on Reference Modem.
  5. ASSERT (20.1.2) : Test Fail if CRC value for the ASCII data does not match.
  6. Hang up Call for Test and Reference Modem
  7. Test Modem setting up call using ATA and getting Connection Response.(Answer Mode)
  8. ASSERT (20.1.1): Test Fail if Connection is not established
  9. Send ASCII data from Test Modem and Receive same ASCII data on Reference Modem.
  10. ASSERT (20.1.2): Test Fail if CRC value for the ASCII data does not match.
  11. Hang up Call for Test and Reference Modem

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a target system with a modem installed (internal or external). For software setup, the target system requires Windows XP installed correctly.

Results Interpretation

Failures in SENDFILE3 and SENDFILE8 can be caused due to wrong setting of phone numbers, line failures, interoperability problems between test and reference modem or device problems. Failures in SENDFILE5 and SENDFILE10 can be caused due to device problems or line conditions.


TD-20.2 Compression Test (COMPRESSION)

The Compression Test verifies that the test modem can set Compression ON or OFF when it dials/answers a call. It also verifies that fixed amount of ASCII data can be sent after a connection is made.

COMPRESSION will perform the following steps:

  1. Static Initialization of Test and Reference Modem
  2. Dynamic Initialization with AT Command to set compression ON for Test and Reference Modem
  3. Test Modem setting up call using ATDT and getting Connection Response.(Dial Mode)
  4. ASSERT (20.2.1): Check Connection Response to verify if Compression Bit is ON
  5. ASSERT (20.1.1): Test Fail if Connection is not established
  6. Send ASCII data from Test Modem and Receive same ASCII data on Reference Modem
  7. ASSERT (20.1.2): Test Fail if CRC value for the ASCII data does not match.
  8. Hang up Call for Test and Reference Modem
  9. Dynamic Initialization with AT Command to set compression OFF for Test and Reference Modem
  10. Test Modem setting up call using ATDT and getting Connection Response.(Dial Mode)
  11. ASSERT (20.2.2.): Check Connection Response to verify if Compression Bit is OFF
  12. ASSERT (20.1.1): Test Fail if Connection is not established
  13. Send ASCII data from Test Modem and Receive same ASCII data on Reference Modem.
  14. ASSERT (20.1.2): Test Fail if CRC value for the ASCII data does not match.
  15. Hang up Call for Test and Reference Modem
  16. Dynamic Initialization with AT Command to set compression ON for Test and Reference Modem
  17. Test Modem setting up call using ATA and getting Connection Response.(Answer Mode)
  18. ASSERT (20.2.1): Check Connection Response to verify if Compression Bit is ON
  19. ASSERT (20.1.1): Test Fail if Connection is not established
  20. Send ASCII data from Test Modem and Receive same ASCII data on Reference Modem
  21. ASSERT (20.1.2): Test Fail if CRC value for the ASCII data does not match.
  22. Hang up Call for Test and Reference Modem
  23. Dynamic Initialization with AT Command to set compression OFF for Test and Reference Modem
  24. Test Modem setting up call using ATA and getting Connection Response.(Answer Mode)
  25. ASSERT (20.2.2): Check Connection Response to verify if Compression Bit is OFF
  26. ASSERT (20.1.1): Test Fail if Connection is not established
  27. Send ASCII data from Test Modem and Receive same ASCII data on Reference Modem.
  28. ASSERT (20.1.2): Test Fail if CRC value for the ASCII data does not match.
  29. Hang up Call for Test and Reference Modem

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a target system with a modem installed (internal or external). For software setup, the target system requires Windows XP installed correctly.

Results Interpretation

Failures in Compression Test are caused if the test modem does not respond with Correct Response when a connection is established.


TD-20.3 Error Control Test (ERRCTRL)

The ErrorControl Test verifies that the test modem can set ErrorControl ON or OFF when it dials/answers a call. It also verifies that fixed amount of ASCII data can be sent after a connection is made.

ERRCTRL will perform the following steps:

  1. Static Initialization of Test and Reference Modem
  2. Dynamic Initialization with AT Command to set ErrorControl ON for Test and Reference Modem
  3. Test Modem setting up call using ATDT and getting Connection Response.(Dial Mode)
  4. ASSERT (20.3.1): Check Connection Response to verify if ErrorControl Bit is ON
  5. ASSERT (20.1.1): Test Fail if Connection is not established
  6. Send ASCII data from Test Modem and Receive same ASCII data on Reference Modem
  7. ASSERT (20.1.2): Test Fail if CRC value for the ASCII data does not match.
  8. Hang up Call for Test and Reference Modem
  9. Dynamic Initialization with AT Command to set ErrorControl OFF for Test and Reference Modem
  10. Test Modem setting up call using ATDT and getting Connection Response. (Dial Mode)
  11. ASSERT (20.3.2): Check Connection Response to verify if ErrorControl Bit is OFF
  12. ASSERT (20.1.1): Test Fail if Connection is not established
  13. Send ASCII data from Test Modem and Receive same ASCII data on Reference Modem.
  14. Hang up Call for Test and Reference Modem
  15. Dynamic Initialization with AT Command to set ErrorControl ON for Test and Reference Modem
  16. Test Modem setting up call using ATA and getting Connection Response. (Answer Mode)
  17. ASSERT (20.3.1): Check Connection Response to verify if ErrorControl Bit is ON
  18. ASSERT (20.1.1): Test Fail if Connection is not established
  19. Send ASCII data from Test Modem and Receive same ASCII data on Reference Modem
  20. ASSERT (20.1.2): Test Fail if CRC value for the ASCII data does not match.
  21. Hang up Call for Test and Reference Modem
  22. Dynamic Initialization with AT Command to set ErrorControl OFF for Test and Reference Modem
  23. Test Modem setting up call using ATA and getting Connection Response. (Answer Mode)
  24. ASSERT (20.3.2): Check Connection Response to verify if ErrorControl Bit is OFF
  25. ASSERT (20.1.1): Test Fail if Connection is not established
  26. Send ASCII data from Test Modem and Receive same ASCII data on Reference Modem.
  27. Hang up Call for Test and Reference Modem

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a target system with a modem installed (internal or external). For software setup, the target system requires Windows XP installed correctly.

Results Interpretation

Failures in ErrorControl Test are caused if the test modem does not respond with Correct Response when a connection is established.


TD-20.4 Forced Error Control Test (FERRCTRL)

The Forced Error Test verifies that the test modem can make a connection with a reference modem in dial or answer mode. It also verifies that fixed amount of ASCII data can be sent after a connection is made.

FERRCTRL will perform the following steps:

  1. Static Initialization of Test and Reference Modem
  2. Dynamic Initialization with AT Command to set ForcedErrorControl ON for Test Modem
  3. Dynamic Initialization with AT Command to set ErrorControl ON for Reference Modem
  4. Test Modem setting up call using ATDT and getting Connection Response. (Dial Mode)
  5. ASSERT (20.3.1): Check Connection Response to verify if ErrorControl Bit is ON
  6. ASSERT (20.1.1): Test Fail if Connection is not established
  7. Send ASCII data from Test Modem and Receive same ASCII data on Reference Modem
  8. ASSERT (20.1.2): Test Fail if CRC value for the ASCII data does not match.
  9. Hang up Call for Test and Reference Modem
  10. Dynamic Initialization with AT Command to set ForcedErrorControl ON for Test Modem
  11. Dynamic Initialization with AT Command to set ErrorControl OFF for Reference Modem
  12. Test Modem setting up call using ATDT and getting Connection Response. (Dial Mode)
  13. ASSERT (20.4.1): Test Fail if Connection IS established
  14. Hang up Call for Test and Reference Modem

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a target system with a modem installed (internal or external). For software setup, the target system requires Windows XP installed correctly.

Results Interpretation

Failures in Forced ErrorControl Test can be caused if the test modem does not respond with Correct Response for FERRCTRL5. If Forced Error Control is not implemented properly, FERRCTRL13 will assert as modem will try to connect with ErrorConrol setting OFF.


TD-20.5 Speed Test (SPEED)

The Speed Test verifies that the test modem can make a connection at a speed greater than or equal to 28.8 kbps with a reference modem in dial or answer mode.

SPEED will perform following steps:

  1. Static and Dynamic Initialization of Test and Reference Modem
  2. Test Modem setting up call using ATDT and getting Connection Response. (Dial Mode)
  3. ASSERT (20.1.1): Test Fail if Connection is not established
  4. ASSERT (20.5.1): Test Fail if Negotiated DCE Rate is less than 28800 bits per second
  5. Hang up Call for Test and Reference Modem
  6. Test Modem setting up call using ATA and getting Connection Response. (Answer Mode)
  7. ASSERT (20.1.1): Test Fail if Connection is not established
  8. ASSERT (20.5.1): Test Fail if Negotiated DCE Rate is less than 28800 bits per second
  9. Hang up Call for Test and Reference Modem

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a target system with a modem installed (internal or external). For software setup, the target system requires Windows XP installed correctly.

Results Interpretation

Failures in SPEED3 and SPEED6 can be caused due to wrong setting of phone numbers, line failures, interoperability problems between test and reference modem or device problems. Failures in SPEED4 and SPEED8 can be caused if modem does not support V.34 or higher modulation protocols.


MCT Options Test Descriptions

This section describes the tests to verify if a specific option is supported for a modem device and if it is supported to check if it is supported correctly.

TD-20.6 Speed Adjust Test (SPEEDADJUST)

The Speed Adjust Test verifies that the test modem can make a connection with a reference modem at a specific speed when speed adjust is ON for Test and Reference Modem. It also verifies that it fails to make a connection if the speed adjust is OFF for Test and Reference Modem.

SPEEDADJUST will perform the following steps:

  1. Static Initialization of Test and Reference Modem
  2. CHECK : If Test Modem Supports SpeedAdjust, Goto Step3 else End Test with Fail Status
  3. Set SpeedAdjust ON for Test and Reference Modem
  4. Set BaudRate for Reference Modem to 19200. Dynamic Initialization of Test and Reference Modem
  5. Test Modem setting up call using ATA and getting Connection Response.(Answer Mode)
  6. ASSERT (20.1.1): Test Fail if Connection is not established
  7. ASSERT (20.6.1): Test Fail if Test Modem NOT connected at 19200 bps.
  8. Hang up Call for Test and Reference Modem
  9. Set SpeedAdjust OFF for Test and Reference Modem
  10. Set BaudRate for Reference Modem to 28800. Dynamic Initialization of Test and Reference Modem
  11. Test Modem setting up call using ATA and getting Connection Response. (Answer Mode)
  12. ASSERT (20.4.1): Test Fail if Connection is established
  13. Hang up Call for Test and Reference Modem

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a target system with a modem installed (internal or external). For software setup, the target system requires Windows XP installed correctly.

Results Interpretation

Failures in SPEEDADJUST7 and SPEEDADJUST12 can be caused if device is unable to set/reset its SpeedAdjust Settings. Failures in SPEEDADJUST6 can be caused due to wrong setting of phone numbers, line failures, interoperability problems between test and reference modem or device problems.


TD-20.7 Inactivity Timeout Test (INACTIVITY)

The Inactivity Timeout Test verifies that the Test modem can disconnect within a set time interval after connecting to Reference Modem. The test also verifies if the Inactivity Timeout can be set to OFF or if it can be set to more than the maximum allowed value.

INACTIVITY will perform the following steps:

  1. Static Initialization of Test and Reference Modem
  2. CHECK : If Test Modem Supports InactivityTimeout, Goto Step3 else End Test with Pass Status
  3. If Inactivityscale is less than 60 set Inactivity Timeout 10 else set Inactivity Timeout to 60
  4. Test Modem setting up call using ATDT and getting Connection Response. (Dial Mode)
  5. ASSERT (20.1.1): Test Fail if Connection is not established
  6. Wait for Test Modem to Disconnect
  7. ASSERT (20.7.1): Test Fail if Test Modem NOT disconnected within fixed time interval of <someval1,someval2>. If InactivityTimeout setting in Step 3 was 60 <someval1,someval2> = <50,70> else if it was less than 60 <someval1,someval2> = <5,15>.
  8. Hang up Call for Test and Reference Modem
  9. Set InactivityTimeout OFF for Test and Reference Modem
  10. Test Modem setting up call using ATDT and getting Connection Response. (Dial Mode)
  11. ASSERT (20.1.1): Test Fail if Connection is not established
  12. Wait for Test Modem to Disconnect
  13. ASSERT (20.7.2): Test Fail if Test Modem disconnected before fixed time setting of <someval>. If InactivityTimeout setting in Step 3 was 60 <someval> = 70 else if it was less than 60 <someval> = 15.
  14. Hang up Call for Test and Reference Modem.
  15. Set InactivityTimeout to MAX1 value for Test Modem
  16. Test Modem setting up call using ATDT and getting Connection Response. (Dial Mode)
  17. ASSERT (20.1.1): Test Fail if Connection is not established
  18. Wait for Test Modem to Disconnect
  19. ASSERT (20.7.2): Test Fail if Test Modem disconnected before fixed time setting of MAX Inactivity Timeout.
  20. Hang up Call for Test and Reference Modem.
  21. Set Inactivity Timeout to greater than MAX1 value for Test Modem
  22. Test Modem setting up call using ATDT and getting Connection Response. (Dial Mode)
  23. ASSERT (20.4.1): Test Warned if Connection is established and Passed if Connection is not established. If the connection is not established the Test modem detected that InactivityTimeout value is set to something greater than maximum allowed.
  24. Hang up Call for Test and Reference Modem.

1 MAX value is derived by multiplying Registry setting for InactivityTimeout with InactivityScale.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a target system with a modem installed (internal or external). For software setup, the target system requires Windows XP installed correctly.

Results Interpretation

Failures in INACTIVITY7, INACTIVITY13 and INACTIVITY19 can be caused if device is unable to set/reset its Inactivity Timeout Settings. Failures in INACTIVITY5, INACTIVITY11 and INACTIVITY17 can be caused due to wrong setting of phone numbers, line failures, interoperability problems between test and reference modem or device problems.


TD-20.8 Hardware FlowControl Test (FLOWCTRLHARD)

The Hardware FlowControl Test verifies that the test modem can make a connection with Hardware Flow Control set to ON and transfer a file. It also verifies that the test modem can reset Hardware Flow Control setting to OFF.

FLOWCTRLHARD will perform the following steps:

  1. Static Initialization of Test and Reference Modem
  2. CHECK : If Test Modem Supports Hardware Flow Control, Goto Step3 else End Test with Fail Status
  3. Dynamic Initialization with AT Command to Hardware FlowControl ON for Test and Reference Modem
  4. Test Modem setting up call using ATDT and getting Connection Response. (Dial Mode)
  5. ASSERT (20.8.1): Check Connection Response to verify if Hardware FlowControl Bit is ON
  6. ASSERT (20.1.1): Test Fail if Connection is not established
  7. Send ASCII data from Test Modem and Receive same ASCII data on Reference Modem
  8. ASSERT (20.1.2): Test Fail if CRC value for the ASCII data does not match.
  9. Hang up Call for Test and Reference Modem
  10. Dynamic Initialization with AT Command to set Hardware Flow Control OFF for Test and Reference Modem
  11. ASSERT (20.8.2): Fail if any TAPI error flagged when Hardware Flow Control set to OFF.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a target system with a modem installed (internal or external). For software setup, the target system requires Windows XP installed correctly.

Results Interpretation

Failures in FLOWCTRLHARD4 and FLOWCTRLHARD10 can be caused if device is unable to set/reset its Hardware Flow Control Settings. Failures in FLOWCTRLHARD5 can be caused due to wrong setting of phone numbers, line failures, interoperability problems between test and reference modem or device problems.


TD-20.9 Software FlowControl Test (FLOWCTRLSOFT)

The Software FlowControl Test verifies that the test modem can make a connection with Software Flow Control set to ON and transfer a file. It also verifies that the test modem can reset Software Flow Control setting to OFF.

FLOWCTRLSOFT will perform the following steps:

  1. Static Initialization of Test and Reference Modem
  2. CHECK : If Test Modem Supports Software Flow Control, Goto Step3 else End Test with Fail Status
  3. Dynamic Initialization with AT Command to Software FlowControl ON for Test and Reference Modem
  4. Test Modem setting up call using ATDT and getting Connection Response. (Dial Mode)
  5. ASSERT (20.9.1): Check Connection Response to verify if Software FlowControl Bit is ON
  6. ASSERT (20.1.1): Test Fail if Connection is not established
  7. Send ASCII data from Test Modem and Receive same ASCII data on Reference Modem
  8. ASSERT (20.1.2): Test Fail if CRC value for the ASCII data does not match.
  9. Hang up Call for Test and Reference Modem
  10. Dynamic Initialization with AT Command to set Software Flow Control OFF for Test and Reference Modem
  11. ASSERT (20.9.2): Fail if any TAPI error flagged when Software Flow Control set to OFF.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a target system with a modem installed (internal or external). For software setup, the target system requires Windows XP installed correctly.

Results Interpretation

Failures in FLOWCTRLSOFT4 and FLOWCTRLSOFT10 can be caused if device is unable to set/reset its Software Flow Control Settings. Failures in FLOWCTRLSOFT5 can be caused due to wrong setting of phone numbers, line failures, interoperability problems between test and reference modem or device problems.


TD-20.10 CallSetup Timeout Test (CALLSETUP)

The CallSetup Timeout Test verifies that the test modem can set CallSetup Timeout to off and to maximum allowed value. The test also sets the value of CallSetup Timeout to a fixed value and tries to make a connection.

CALLSETUP will perform the following steps:

  1. Static Initialization of Test and Reference Modem
  2. Set Callsetup Timeout value to 1 second
  3. Test Modem setting up call using ATDT and getting Connection Response. (Dial Mode)
  4. ASSERT (20.4.1): Test Fail if Connection IS established
  5. Hang up Call for Test and Reference Modem
  6. Set Callsetup Timeout value to maximum value.
  7. Test Modem setting up call using ATDT and getting Connection Response. (Dial Mode)
  8. ASSERT (20.1.1): Test Fail if Connection is NOT established
  9. Hang up Call for Test and Reference Modem
  10. Set Callsetup Timeout value to 10 second
  11. Test Modem setting up BLINDDIAL call
  12. ASSERT (20.4.1): Test Fail if Connection IS established
  13. Wait for Call to Disconnect
  14. ASSERT (20.10.1): Test Fail if time taken for call to disconnect is greater than 18 seconds.
  15. Hang up Call for Test and Reference Modem

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a target system with a modem installed (internal or external). For software setup, the target system requires Windows XP installed correctly.

Results Interpretation

Failures in CALLSETUP4, CALLSETUP8 and CALLSETUP14 can be caused if device is unable to set/reset its Callsetup Timeout Settings.


MCT Interactive Tests

This section describes the tests that require user input to validate if the modem is functioning correctly.

TD-20.11 BlindDial Test (BLINDDIAL)

The BlindDial Test verifies that the test modem can dial out when the modem is not connected to a phone line. In this test, you must unplug/plug the phone line and verify when the test modem is able to dial.

BLINDDIAL will perform the following steps:

  1. Static and Dynamic Initialization of Test and Reference Modem
  2. CHECK : Ask USER if it is PCMCIA modem then skip test
  3. Ask USER to unplug the phone line from the Test Modem
  4. Set SpeakerMode to SpeakerMode DIAL to hear modem during the call connection.
  5. Set SpeakerVolume to SpeakerVolume HIGH to hear modem during the call connection.
  6. Test Modem setting up BlindDial Call
  7. ASSERT (20.11.1): Ask USER if the modem dialed without the phone line plugged in. Fail if user chose no.
  8. Hang up Call for Test and Reference Modem

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a target system with a modem installed (internal or external). For software setup, the target system requires Windows XP installed correctly.

Results Interpretation

Failures in BLINDIAL7 are based on user’s evaluation of the modem’s dialing the call. The test is skipped for PC Card/ PCMCIA modem because most PC Card modems implement an optical DAA in which line current must be present for the modem to function. The modem can function without dial tone being present but the line current must be present.


TD-20.12 Speaker Volume Test (SPEAKERVOL)

The Speaker Volume Test verifies that the test modem can make a connection with a reference modem at different volume settings supported by the Test modem. The user needs to verify the volume when modem is dialing, ringing and negotiating a connection with reference modem.

SPEAKERVOL will perform the following steps:

  1. Static and Dynamic Initialization of Test and Reference Modem
  2. Get the SpeakerVolume Settings supported by test modem. Usually support one or more of (Low, Medium, High) Settings
  3. Set SpeakerMode to SpeakerModeDial to hear modem during the call connection.
  4. CHECK : If modem supports LOW SpeakerVolume, set Speaker Volume to Low else goto 8
  5. Test Modem setting up call using ATDT and getting Connection Response (Dial Mode)
  6. ASSERT (20.12.3): Ask USER if the speakervolume was Low. Fail if user chose no.
  7. Hang up Call for Test and Reference Modem
  8. CHECK : If modem supports MEDIUM SpeakerVolume, set Speaker Volume to Medium else goto 12
  9. Test Modem setting up call using ATDT and getting Connection Response (Dial Mode)
  10. ASSERT (20.12.2): Ask USER if the speakervolume was Medium. Fail if user chose no.
  11. Hang up Call for Test and Reference Modem
  12. CHECK : If modem supports HIGH SpeakerVolume, set Speaker Volume to High else END Test
  13. Test Modem setting up call using ATDT and getting Connection Response (Dial Mode)
  14. ASSERT (20.12.1): Ask USER if the speakervolume was High. Fail if user chose no.
  15. Hang up Call for Test and Reference Modem

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a target system with a modem installed (internal or external). For software setup, the target system requires Windows XP installed correctly.

Results Interpretation

Failures in SPEAKERVOL6, SPEAKERVOL10 and SPEAKERVOL14 are based on user’s evaluation of the modem’s setting of SpeakerVolume.


TD-20.13 Speaker Mode Test (SPEAKERMODE)

The Speaker Mode Test verifies that the test modem can make a connection with a reference modem at different speaker mode settings supported by the Test modem. The user needs to verify the speaker mode when modem is dialing, ringing and negotiating a connection with reference modem.

SPEAKERMODE will perform the following steps:

  1. Static and Dynamic Initialization of Test and Reference Modem
  2. Get the SpeakerMode Settings supported by test modem. Usually support one or more of (Off, Dial, On, Setup) Settings
  3. Set SpeakerVolume to SpeakerVolumeHigh to hear modem during the call connection.
  4. CHECK : If modem supports SpeakerMode OFF, set SpeakerMode to OFF else goto 8
  5. Test Modem setting up call using ATDT and getting Connection Response. (Dial Mode)
  6. ASSERT (20.13.3): Ask USER if anything was heard when connection was being made. If user chose yes, fail the test.
  7. Hang up Call for Test and Reference Modem
  8. CHECK: If modem supports SpeakerMode SETUP, set SpeakerMode to SETUP else goto 12
  9. Test Modem setting up call using ATDT and getting Connection Response. (Dial Mode)
  10. ASSERT (20.13.2): Ask USER if modem was heard only during ringing and negotiating connection. Fail if user chose no.
  11. Hang up Call for Test and Reference Modem
  12. CHECK: If modem supports SpeakerMode ON, set SpeakerMode to ON else goto 16
  13. Test Modem setting up call using ATDT and getting Connection Response. (Dial Mode)
  14. ASSERT (20.13.1): Ask USER if modem was heard only during dialing, ringing and negotiating connection. Fail if user chose no.
  15. Hang up Call for Test and Reference Modem
  16. CHECK: If modem supports SpeakerMode DIAL, set SpeakerMode to DIAL else END TEST
  17. Test Modem setting up call using ATDT and getting Connection Response. (Dial Mode)
  18. ASSERT (20.13.4): Ask USER if modem was heard only during dialing and negotiating connection. Fail if user chose no.
  19. Hang up Call for Test and Reference Modem

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a target system with a modem installed (internal or external). For software setup, the target system requires Windows XP installed correctly.

Results Interpretation

Failures in SPEAKERMODE6, SPEAKERMODE10, SPEAKERMODE14 and SPEAKERVOL18 are based on user’s evaluation of the modem’s setting of SpeakerVolume.


TD-20.14 CallerID Test (CALLERID)

The CallerID Test verifies that the test modem can receive Caller Identification information with an incoming call. A Dialog pops up with callerid information and user needs to validate the information.

CALLERID will perform the following steps:

  1. Static and Dynamic Initialization of Test and Reference Modem
  2. Test Modem setting up call using ATA and getting Connection Response. (Answer Mode)
  3. Store Caller ID Information
  4. ASSERT (20.14.1): Ask USER if there was either CallerID number or CallerID Name displayed as callerid information.
  5. Hang up Call for Test and Reference Modem

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a target system with a modem installed (internal or external). For software setup, the target system requires Windows XP installed correctly.

Results Interpretation

Failure in CALLERID4 is caused if the modem does not support the caller identification functionality correctly.


MCT Voice Tests

This section describes the tests that verify the Voice functionality of the Modem. Most of the tests are manual and require user intervention.

TD-20.15 Generate Digits Test (GENDIGITS)

The Generate Digits Test verifies that the test modem can generate digits 0-9,# and * so that user can hear these digits on the remote phone.

GENDIGITS will perform the following steps:

  1. Static and Dynamic Initialization of Test Modem
  2. CHECK: If the test modem supports Generate Digits functionality, goto step 3 else END TEST
  3. Initialization of Test Modem in Voice Mode
  4. Make Voice Call from Test Modem to Remote HandSet connected to a phone line.
  5. Ask User to pick up the remote phone
  6. Ask User to listen for digits on remote phone
  7. Generate Digits 0123456789*#
  8. ASSERT (20.15.1): Ask USER if DTMFs 0-9, * and # were heard on the remote phone. Fail if user chose no.
  9. Ask User to hang up remote phone
  10. Hang up Call for Test Modem

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a target system with a modem installed (internal or external). For software setup, the target system requires Windows XP installed correctly.

Results Interpretation

Failure in GENDIGITS8 is caused if the modem does not support the generate digits functionality correctly.


TD-20.16 Monitor Digits Test (MONDIGITS)

The Monitor Digits Test verifies that the test modem can monitor digits 0-9,# and * when user presses them on the remote handset.

MONDIGITS will perform the following steps:

  1. Static and Dynamic Initialization of Test Modem
  2. CHECK: If the test modem supports Monitor Digits functionality, goto step 3 else END TEST
  3. Initialization of Test Modem in Voice Mode
  4. Make Voice Call from Test Modem to Remote HandSet connected to a phone line.
  5. Ask User to pick up the remote phone
  6. Ask User to press digits on remote phone
  7. ASSERT (20.16.1): Ask USER if correct digit is shown when a digit is pressed on remote phone. Fail if user chose no.
  8. Ask User to hang up remote phone
  9. Hang up Call for Test Modem

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a target system with a modem installed (internal or external). For software setup, the target system requires Windows XP installed correctly.

Results Interpretation

Failure in MONDIGITS7 is caused if the modem does not support the monitor digits functionality correctly.


TD-20.17 Handset HookSwitch Test (HSHOOKSWITCH)

The Handset HookSwitch Test verifies that the test modem can detect if the handset connected to modem is offhook when user picks it up and it is onhook when user hangs up the local handset.

HSHOOKSWITCH will perform the following steps:

  1. Static and Dynamic Initialization of Test Modem
  2. CHECK: If the test modem supports Handset Hookswitch functionality, goto step 3 else END TEST
  3. Initialization of Test Modem in Voice Mode and Initialization of Phone Device
  4. Make Voice Call from Test Modem to Remote HandSet connected to a phone line.
  5. Ask User to pick up the remote phone
  6. Ask User to pick up the local phone connected to the Test Modem
  7. ASSERT (20.17.1): Fail if the Modem did not detect the local phone to be off hook
  8. Ask User to hang up the local phone connected to the Test Modem
  9. ASSERT (20.17.2): Fail if the Modem did not detect the local phone to be on hook
  10. Ask User to hang up remote phone
  11. Hang up Call for Test Modem

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a target system with a modem installed (internal or external). For software setup, the target system requires Windows XP installed correctly.

Results Interpretation

Failure in HSHOOKSWITCH7 and HSHOOKSWITCH9 is caused if the modem does not support the handset hookswitch functionality correctly.


TD-20.18 SpeakerPhone HookSwitch Test (SPHOOKSWITCH)

The SpeakerPhone HookSwitch Test verifies that the test modem can detect if the speaker and microphone connected to the modem work when connected to remote phone.

SPHOOKSWITCH will perform the following steps:

  1. Static and Dynamic Initialization of Test Modem
  2. CHECK : If the test modem supports SpeakerPhone Hookswitch functionality, goto step 3 else END TEST
  3. Initialization of Test Modem in Voice Mode and Initialization of Phone Device
  4. Make Voice Call from Test Modem to Remote HandSet connected to a phone line.
  5. Ask User to pick up the remote phone
  6. Set Test Modem to state where speakerphone is off hook
  7. Ask User to talk through microphone and remote phone.
  8. ASSERT (20.18.6): Fail if the User did not hear anything through speaker or remote phone.
  9. ASSERT (20.18.1): Fail if the Modem did not detect the speakerphone to be off hook (using phoneGetHookSwitch)
  10. ASSERT (20.18.4): Fail if the Modem did not detect the speakerphone to be off hook (using phoneGetStatus)
  11. Set Test Modem to state where speaker is off hook and microphone is mute.
  12. Ask User to talk through microphone and check if microphone is mute.
  13. ASSERT (20.18.7): Fail if the User did hear anything through remote phone.
  14. ASSERT (20.18.1): Fail if the Modem did not detect the speakerphone to be off hook (using phoneGetHookSwitch)
  15. ASSERT (20.18.3): Fail if the Modem did not detect the microphone to be mute (using phoneGetStatus)
  16. Set Test Modem to state where speakerphone is on hook.
  17. Ask User to talk through microphone and remote phone.
  18. ASSERT (20.18.8): Fail if the User DID hear anything through speaker or remote phone.
  19. ASSERT (20.18.2): Fail if the Modem did not detect the speakerphone to be on hook (using phoneGetHookSwitch)
  20. ASSERT (20.18.5): Fail if the Modem did not detect the speakerphone to be on hook (using phoneGetStatus)
  21. Ask User to hang up remote phone
  22. Hang up Call for Test Modem

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a target system with a modem installed (internal or external). For software setup, the target system requires Windows XP installed correctly.

Results Interpretation

Failure in SPHOOKSWITCH8, SPHOOKSWITCH13 and SPHOOKSWITCH18 is caused if user thinks that the modem did not work with speaker and microphone. Failure in SPHOOKSWITCH9, SPHOOKSWITCH10, SPHOOKSWITCH114, SPHOOKSWITCH15, SPHOOKSWITCH19 and SPHOOKSWITCH20 is caused if the modem does not support the speakerphone hookswitch functionality correctly.


TD-20.19 SpeakerPhone Volume/Gain Test (SPVOLGAIN)

The SpeakerPhone Volume/Gain Test verifies that the speaker connected to voice modem can work at different volume levels and the microphone connected to voice modem works for different gain levels.

SPVOLGAIN will perform the following steps:

  1. Static and Dynamic Initialization of Test Modem
  2. CHECK: If the test modem supports SpeakerPhoneVolume and SpeakerPhoneGain functionality, goto step 3 else END TEST
  3. Initialization of Test Modem in Voice Mode and Initialization of Phone Device
  4. Make Voice Call from Test Modem to Remote HandSet connected to a phone line.
  5. Ask User to pick up the remote phone
  6. Set Test Modem to state where speakerphone is off hook
  7. Ask User to talk through microphone and remote phone.
  8. ASSERT (20.18.6): Fail if the User did not hear anything through speaker or remote phone.
  9. ASSERT (20.18.1): Fail if the Modem did not detect the speakerphone to be off hook (using phoneGetHookSwitch)
  10. ASSERT (20.18.4): Fail if the Modem did not detect the speakerphone to be off hook (using phoneGetStatus)
  11. Set Speaker Volume to High
  12. Ask User to talk through remote phone and check if the volume of speaker is HIGH.
  13. ASSERT (20.19.1): Fail if the User felt that volume of speaker is not HIGH.
  14. Set Speaker Volume to Low
  15. Ask User to talk through remote phone and check if the volume of speaker is LOW.
  16. ASSERT (20.19.2): Fail if the User felt that volume of speaker is not LOW.
  17. Set Microphone Gain to High
  18. Ask User to talk through microphone and check on remote phone if the gain of microphone is HIGH.
  19. ASSERT (20.19.3): Fail if the User felt that gain of microphone is not HIGH.
  20. Set Microphone Gain to Low
  21. Ask User to talk through microphone and check on remote phone if the gain of microphone is LOW.
  22. ASSERT (20.19.4): Fail if the User felt that gain of microphone is not LOW
  23. Ask User to hang up remote phone
  24. Hang up Call for Test Modem

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a target system with a modem with SpeakerPhone is installed (internal or external). For software setup, the target system requires Windows XP installed correctly.

Results Interpretation

Failure in SPVOLGAIN8, SPVOLGAIN13, SPVOLGAIN16, SPVOLGAIN19 and SPVOLGAIN22 is caused if user thinks that the modem did not set volume of speaker and gain of microphone correctly. SPVOLGAIN9 and SPVOLGAIN10 is caused if the modem does not support the speakerphone hookswitch functionality correctly.


TD-20.20 Handset Audio Test (HSAUDIO)

The Handset Audio Test verifies that the test modem can record audio message through local handset and then play the recorded message.

HSAUDIO will perform the following steps:

  1. Static and Dynamic Initialization of Test Modem
  2. CHECK : If the test modem supports Handset Audio functionality, goto step 3 else END TEST
  3. Initialization of Test Modem in Voice Mode, Initialization of Phone Device and Initialization of wave device
  4. Ask User to pick up the local phone connected to the Test Modem
  5. Ask User to talk through local phone when ready to record.
  6. Set modem to record the voice data
  7. Ask User to hang up the local phone connected to the Test Modem
  8. Ask User to pick up the local phone connected to the Test Modem
  9. Play voice data recorded in step 6
  10. ASSERT (20.20.1): Fail if the user did not hear what was recorded in step 6
  11. Ask User to hang up the local phone connected to the Test Modem
  12. Close Wave Device

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a target system with a modem installed (internal or external). For software setup, the target system requires Windows XP installed correctly.

Results Interpretation

Failure in HSAUDIO10 is caused if the modem does not support the handset audio recording functionality correctly.


TD-20.21 Line Audio Test (LINEAUDIO)

The Line Audio Test verifies that the test modem can record audio message through remote phone and then play the recorded message.

LINEAUDIO will perform the following steps:

  1. Static and Dynamic Initialization of Test Modem
  2. CHECK : If the test modem supports Line Audio functionality, goto step 3 else END TEST
  3. Initialization of Test Modem in Voice Mode and Initialization of wave device
  4. Make Voice Call from Test Modem to Remote HandSet connected to a phone line.
  5. Ask User to pick up the remote phone
  6. Ask User to talk through remote phone when ready to record.
  7. Set Modem to record voice data
  8. Ask User to listen to the remote phone
  9. Play voice data recorded in step 7
  10. ASSERT (20.21.1): Fail if the user did not hear what was recorded in step 7.
  11. Ask User to hang up remote phone
  12. Hang up the call for Test Modem
  13. Close Wave Devices

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a target system with a modem installed (internal or external). For software setup, the target system requires Windows XP installed correctly.

Results Interpretation

Failure in LINEAUDIO10 is caused if the modem does not support the line audio recording functionality correctly.


MCT V.250 Tests

This section describes the tests that use AT Commands from V.250 ITU-T Specification.

TD-20.22 AT +GCI Test (ATGCI)

The AT +GCI Test verifies that modem supports "AT+GCI=?" and "AT+GCI?" commands.

ATGCI will perform the following steps:

  1. Static and Dynamic Initialization of Test and Reference Modem.
  2. Send AT+GCI=? Command to the Test Modem.
  3. CHECK: If Modem returns Error, Log Failure and End Test.
  4. ASSERT (20.22.1): Check if the list of countries/regions returned is in the format specified in V.250 Spec.
  5. ASSERT (20.22.2): For each country code in the list, check if it is a valid country code defined in T.35 Annex A.
  6. Send AT+GCI? Command to the Test Modem.
  7. CHECK: If Modem returns Error, Log Failure and End Test.
  8. ASSERT (20.22.3): For country code returned, check if it is present in the list got in Step 4.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires a target system with a modem installed (internal or external). For software setup, the target system requires Windows XP installed correctly.

Results Interpretation

Failures in ATGCI4, ATGCI5 and ATGCI8 are due to modem’s failure to comply by V.250 Specifications and return valid response.


Chapter 21: Anti-virus File System Filter Test Specification

Expand all contracted text Show All

WHQL Test Specification

Previous Next

Chapter 21: Anti-Virus/File System Filter Driver Test Specification

This chapter describes the Anti-Virus and File System Filter Driver tests and test assertions. These tests verify compliance with Microsoft Windows Logo Program System and Device Requirements.

File system drivers include drivers for the system-supplied NTFS and file allocation table (FAT) file systems. On the Windows NT-based operating system, file system drivers are kernel-mode drivers. File system filter drivers provide additional capabilities above a standard file system driver, typically by implementing such value-added services as virus screening.


References for Anti-Virus File System Test Assertions

Application Specification for Microsoft Windows for Desktop Applications

http://msdn.microsoft.com/winlogo/

Windows Installable File System (IFS) Kit

http://msdn.microsoft.com/winlogo/


Anti-virus File System Test Assertions

WHQL Test Specification

Previous Next

Anti-Virus/File System Filter Driver Test Assertions

This section provides descriptions of the test assertions.

File System API Test (IFSTEST) Assertions

The following assertions test the File system API semantics and transparency during normal mode of operation. The AV application must preserve File System API semantics and behave as a transparent file system filter for non-infected files under normal conditions. These assertions are tested by the Installable File System test (IFSTEST). Also, see "Anti-virus File System Filter Assertions Not Tested" for a list of the assertions required for compliance, but that are not specifically tested.


Anti-virus Scenario Test (IFSTEST-Virus) Assertions

The following assertions test the File system API semantics and transparency during virus-infected mode of operation. The AV application must preserve File System API semantics and behave as a transparent file system filter under virus infected conditions. These assertions are tested by the Installable File System test (IFSTEST-Virus).


Driver Quality Assertions

These assertions are tested in TD-21.1 Installable File Systems Test Suite.

21.1.1 The AV application must pass stringent IRP processing checked by the Windows 2000 Driver Verifier Manager tool (verifier.exe located in the \system32 directory).

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.1 Installable File Systems Test Suite

21.1.2 The AV application must support Plug and Play drives such as removable USB/1394 drives.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.1 Installable File Systems Test Suite

21.1.3 The AV application must intelligently support OnNow/ACPI requirements as specified in the Application Specification for Windows 2000 and the filter driver should not register for power IRPs.

Reference documents: Application Specification for Windows 2000
Test descriptions: TD-21.1 Installable File Systems Test Suite

21.1.4 The AV application must support both fixed and removable media unless the product is designed not to work on either of these and clearly indicates the nature of the limitation. In particular, AV applications that scan floppy drives must pass the floppy I/O test while actively scanning the floppy drive.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.1 Installable File Systems Test Suite

21.1.5 The AV application must be able to handle out-of-band IOCTL/FSCTL control codes without crashing the system.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.1 Installable File Systems Test Suite


Anti-virus File System Filter Assertions Not Tested

21.1.6 The virus signature update policy (auto update) on AV applications must indicate if any kernel mode components have changed.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: Not tested

21.1.7 If a kernel mode component change is required the auto-update policy must display a pop up for user to accept or reject update.

This is because acceptance of any kernel mode driver update will invalidate the logo (as well as the digital signature resulting in the kernel mode drivers being unsigned).

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: Not tested

21.1.8 All kernel mode drivers must only use ntddk.h or ntifs.h.

This implies that they must not touch any data structures that have not been exported such as ETHREAD and KTHREAD structures. In general, all kernel mode drivers must not modify operating system functions, operating system dispatch tables, or private operating system data structures.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: Not tested

21.1.9 All file system filters must propagate fast IO callbacks.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: Not tested

21.1.10 File system filters must be able to handle dynamic volumes that can appear or disappear.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: Not tested

21.1.11 File system filters must be responsive to HSM.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: Not tested

21.1.12 File sytem filters can call IODetachDevice() only in the FastIODetachDevice routine. They must not call autodetach (from Installshield) under any circumstances.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: Not tested

21.1.13 The AV application must comply with the Application Specification for Windows 2000 Install/Uninstall requirements.

In addition, the preferred method of installing kernel mode drivers is by Windows Installer service. As a Windows XP requirement, all kernel mode drivers must be right-click installable by an INF file.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: Not tested

21.1.14 Anti-virus file system filters must be able to cope with NTFS read-only volumes. This is a requirement for Windows XP

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: Not tested


OpenCreateGeneral File System Test Assertions

Assertions in this section are tested in TD-21.2 OpenCreateGeneral File System Test Group.

21.2.1 The File System must accurately create a paging file.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.2 OpenCreateGeneral File System Test Group – CreatePagingFileTest

21.2.2 The File System must accurately form filenames up to the maximum filename length the file system will support.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.2 OpenCreateGeneral File System Test Group – FileNameLengthTest

21.2.3 The File System must accurately parse the double backslash when used as a prefix for a filename or directory name.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.2 OpenCreateGeneral File System Test Group – HFHTest

21.2.4 The File System must accurately use filenames contain Unicode characters if the Unicode on disk volume attribute flag is set.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.2 OpenCreateGeneral File System Test Group – UnicodeOnDiskTest

21.2.5 The File System must accurately differentiate between filenames that differ only in case if the case sensitive search volume attribute flag is set.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.2 OpenCreateGeneral File System Test Group – CaseSensitiveTest

21.2.6 The File System must accurately preserve the case of different filenames if the case preserved names volume attribute flag is set.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.2 OpenCreateGeneral File System Test Group – PreserveCaseTest

21.2.7 The File System must accurately create an 8.3 representation for the long filenames if the file system supports long names.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.2 OpenCreateGeneral File System Test Group – ShortFileNameTest

21.2.8 The File System must accurately use share access for files and directories.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.2 OpenCreateGeneral File System Test Group – ShareAccessTest

21.2.9 The File System must accurately supports alternate data streams for files access if using NTFS file system.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.2 OpenCreateGeneral File System Test Group – AlternateStreamTest

21.2.10 The File System must accurately support share access of alternate data streams.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.2 OpenCreateGeneral File System Test Group – StreamShareTest

21.2.11 The File System must accurately create a Device Object in the root directory.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.2 OpenCreateGeneral File System Test Group – FileSystemDeviceOpenTest

21.2.12 The File System must accurately create a file using the full path.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.2 OpenCreateGeneral File System Test Group – FileFullPathCreationTest

21.2.13 The File System must accurately create a directory using the full path including the system root, volume root, and directory path.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.2 OpenCreateGeneral File System Test Group – DirectoryFullPathCreationTest

21.2.14 The File System must accurately create and access files by going through the handle of an open directory.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.2 OpenCreateGeneral File System Test Group – FileRelativePathCreationTest

21.2.15 The File System must accurately create and access directories by going through the handle of an open directory.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.2 OpenCreateGeneral File System Test Group – DirectoryRelativePathCreationTest

21.2.16 The File System must accurately open files using the unique and persistent identifier for the file.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.2 OpenCreateGeneral File System Test Group – FileOpenByIDTest

21.2.17 The File System must accurately use the non-directory file option flag by being able to open a file but not being able to open a directory if set.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.2 OpenCreateGeneral File System Test Group – NonDirectoryFileOpenTest

21.2.18 The File System must accurately use the directory file flag by being able to open a file but not being able to open a directory if set.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.2 OpenCreateGeneral File System Test Group – NonDirectoryFileOpenTest

21.2.19 The File System must accurately support volume or DASD opening of volumes.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.2 OpenCreateGeneral File System Test Group – OpenVolumeTest


OpenCreateParameters File System Test Assertions

Assertions in this section are tested in TD-21.3 OpenCreateParameters File System Test Group.

21.3.1 The File System must accurately use the file overwrite disposition with the file create function, existing file is truncated and attributes are ORed.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.3 OpenCreateParameters File System Test Group – OverwriteFileTest

21.3.2 The File System must accurately requires an existing file when using the file overwrite disposition with the file create function.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.3 OpenCreateParameters File System Test Group – OverwriteFileAllocTest

21.3.3 The File System must accurately use System and Hidden attributes when using the file overwrite disposition with the file create function.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.3 OpenCreateParameters File System Test Group – OverwriteFileAttrTest

21.3.4 The File System must accurately use the file overwrite disposition with file supersede disposition, existing file is truncated and attributes are replaced with the new attributes.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.3 OpenCreateParameters File System Test Group – SupersedeFileTest

21.3.5 The File System must accurately requires an existing file when using the file overwrite disposition with file supersede disposition.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.3 OpenCreateParameters File System Test Group – SupersedeFileAllocTest

21.3.6 The File System must accurately use System and Hidden attributes when using the file overwrite disposition with file supersede disposition.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.3 OpenCreateParameters File System Test Group – SupersedeFileAttrTest

21.3.7 The File System must accurately allow files to be opened for reading but not for writing when the read only attribute is set.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.3 OpenCreateParameters File System Test Group – ReadOnlyAttributeTest

21.3.8 The File System must accurately create files with the system attribute set.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.3 OpenCreateParameters File System Test Group – SystemAttributeTest

21.3.9 The File System must accurately open existing files but not be able to open files that do not exist.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.3 OpenCreateParameters File System Test Group – OpenFileTest

21.3.10 The File System must accurately open existing directories but not be able to open directories that do not exist.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.3 OpenCreateParameters File System Test Group – OpenFileDirTest

21.3.11 The File System must accurately create files unless the file already exists.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.3 OpenCreateParameters File System Test Group – CreateFileTest

21.3.12 The File System must accurately open an existing files.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.3 OpenCreateParameters File System Test Group – OpenAlwaysFileTest

21.3.13 The File System must accurately create a file when opening a nonexistent file.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.3 OpenCreateParameters File System Test Group – OpenAlwaysFileTest

21.3.14 The File System must accurately create a directory when opening a nonexistent directory.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.3 OpenCreateParameters File System Test Group – OpenAlwaysFileDirTest

21.3.15 The File System must accurately use the file overwrite if disposition.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.3 OpenCreateParameters File System Test Group – OverwriteAlwaysFileTest

21.3.16 The File System must accurately use the file overwrite if disposition with both an existing and non-existing files.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.3 OpenCreateParameters File System Test Group – OverwriteAlwaysAllocTest

21.3.17 The File System must accurately use the file overwrite if disposition on hidden system files

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.3 OpenCreateParameters File System Test Group – OverwriteAlwaysAttrTest

21.3.18 The File System must be able accurately set allocation sizes of files at creation time.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.3 OpenCreateParameters File System Test Group – FileAllocationSizeTest

21.3.19 The File System must accurately use the file execute disposition to cause the updating of the last accessed time on a handle close.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.3 OpenCreateParameters File System Test Group – ExecuteAccessTest

21.3.20 The File System must be able accurately set the hidden attribute of files at creation time.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.3 OpenCreateParameters File System Test Group – HiddenAttributeTest

21.3.21 The File System must be able accurately set the normal attribute set (NOT read only, hidden, system, directory or archive) of files at creation time.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.3 OpenCreateParameters File System Test Group – NormalAttributeTest

21.3.22 The File System must be able accurately set the directory attribute of files at creation time to create a directory.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.3 OpenCreateParameters File System Test Group – DirectoryAttributeTest

21.3.23 The File System must accurately use the file create disposition to create directories.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.3 OpenCreateParameters File System Test Group – CreateFileDirTest

21.3.24 The File System must accurately set the archive attribute of files at creation time.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.3 OpenCreateParameters File System Test Group – ArchiveAttributeTest


CloseCleanupDelete File System Test Assertions

Assertions in this section are tested in TD-21.4 CloseCleanupDelete File System Test Group.

21.4.1 The File System must accurately open a volume for DASD access.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.4 CloseCleanupDelete File System Test Group – VolumeUnlockOnCloseTest

21.4.2 The File System must accurately record the failed attempt to open a file on a locked volume.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.4 CloseCleanupDelete File System Test Group – VolumeUnlockOnCloseTest

21.4.3 The File System must be able to accurately create and delete files in a selected directory.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.4 CloseCleanupDelete File System Test Group – UpdateOnCloseTest

21.4.4 The File System must be able to accurately find a files contained a directory using a Directory Handle and obtain the File Times (creation, accessed, change, and last write times) , Attributes, End of File Pointer, and Allocation size; and that these are within appropriate ranges.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.4 CloseCleanupDelete File System Test Group – UpdateOnCloseTest

21.4.5 The File System must be able to accurately create and delete a sub-directory in a selected directory.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.4 CloseCleanupDelete File System Test Group – UpdateOnCloseDirTest

21.4.6 The File System must be able to accurately use a Directory Handle to find a sub-directory contained in that directory, and obtain the File Times, Attributes, End of File Pointer, and Allocation size; and that these are within appropriate ranges.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.4 CloseCleanupDelete File System Test Group – UpdateOnCloseDirTest

21.4.7 The File System must be able to accurately reduce the allocation size of a file (rounded up to the nearest minimum allocation unit) when the allocation size is larger than the file size.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.4 CloseCleanupDelete File System Test Group – TruncateOnCloseTest

21.4.8 The File System must be able to accurately query a directory for files using both long and short filenames.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.4 CloseCleanupDelete File System Test Group – TunnelingTest

21.4.9 The File System must be able accurately delete and recreate a files using their short file name will recreate their long file name.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.4 CloseCleanupDelete File System Test Group – TunnelingTest

21.4.10 The File System must be able to accurately delete files mark for delete on close via the open/create option.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.4 CloseCleanupDelete File System Test Group – DeleteOnLastCloseTest

21.4.11 The File System must be able to accurately delete files marked for delete on close, via the file information.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.4 CloseCleanupDelete File System Test Group – DeleteOnLastCloseTest

21.4.12 The File System must be able to accurately delete a file when the final handle to a "delete on close file" is closed.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.4 CloseCleanupDelete File System Test Group – DeleteOnLastCloseTest


VolumeInformation File System Test Assertions

Assertions in this section are tested in TD-21.5 VolumeInformation File System Test Group.

21.5.1 The operating system must be able to accurately query and set volume labels.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.5 VolumeInformation File System Test Group – VolumeLabelTest

21.5.2 The operating system must be able to accurately query the volume for creation time, serial number, label length, support objects, and volume label.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.5 VolumeInformation File System Test Group – VolumeInformationTest

21.5.3 The operating system must be able to accurately query the volume size information (total allocation units, available allocation units, sectors per allocation unit and bytes per sector).

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.5 VolumeInformation File System Test Group – SizeInformationTest

21.5.4 The operating system must be able to accurately query the volume device information (device type and characteristics).

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.5 VolumeInformation File System Test Group – DeviceInformationTest

21.5.5 The operating system must be able to accurately query for volume attribute information (file system attributes, maximum component name length, file system name length and file system name) using volume, directory and file handles.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.5 VolumeInformation File System Test Group – AttributeInformationTest


FileInformation File System Test Assertions

Assertions in this section are tested in TD-21.6 FileInformation File System Test Group.

21.6.1 The file information must be accurately read all (basic information, standard information, internal information, EA information, position information and name information) at the same time.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.6 FileInformation File System Test Group – AllInformationTest

21.6.2 The file information must be accurately truncate or extend the file depending on allocation size.

The file size is different from the allocation size. The allocation size must fall on an allocation unit boundary while the file size can be any value at or before the currently allocated size.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.6 FileInformation File System Test Group – AllocationInformationTest

21.6.3 The file information must accurately update allocation size for a file but must wait to update the directory file until after the handle to the directory file is closed.

The file size starts with an allocation size of zero.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.6 FileInformation File System Test Group – ZeroAllocationInformationTest

21.6.4 The file information must accurately return information on the compression used if the file is compressed.

A query is performed on two files (one that is compressed and one that is not) and a check is performed to make sure that the uncompressed file size is greater than the compressed file size.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.6 FileInformation File System Test Group – CompressionInformationTest

21.6.5 The file information must accurately set the Delete Pending flag and delete these flagged files on close.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.6 FileInformation File System Test Group – DispositionInformationTest

21.6.6 The file information must accurately set the end of file position and it must be less than or equal to the allocation size.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.6 FileInformation File System Test Group – EndOfFileInformationTest

21.6.7 The file information must be able to accurately create hard links to a file.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.6 FileInformation File System Test Group – LinkInformationTest

21.6.8 The file information must be able to accurately open a file using hard links.

The data and attributes in the file opened using the link is read and compared against the original file’s data and attributes. They must be the same.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.6 FileInformation File System Test Group – LinkInformationTest

21.6.9 The file information must be able to accurately rename files/directories (except the root directory) within a volume.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.6 FileInformation File System Test Group – SimpleRenameInformationTest

21.6.10 The file information system must not allow the renaming of a filename to an existing filename unless the attribute, Replace If Exists, is set.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.6 FileInformation File System Test Group – ConflictingRenameInformationTest

21.6.11 The file information must be able to accurately use long names to obtain their short names (8.3 format).

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.6 FileInformation File System Test Group – AlternateNameInformationTest

21.6.12 The file information must be accurately read all Network open information (creation time, last access time, last write time, change time, allocation size and end of file).

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.6 FileInformation File System Test Group – FileNetworkOpenInformationTest

21.6.13 The file information must be accurately contain stream name, size in bytes, and allocated size in bytes for both primary data stream and alternate data streams.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.6 FileInformation File System Test Group – StreamInformationTest

21.6.14 The file information must accurately set number of links and delete pending flag the same for all streams in the file.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.6 FileInformation File System Test Group – StreamStandardInformationTest

21.6.15 The file information must be able to be queried and accurately set basic information (creation time, last access time, last write time, and change time) and all except creation time must change when the file is changed.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.6 FileInformation File System Test Group – BasicInformationTest

21.6.16 The file information must be able to be queried and accurately contain standard information (allocation size, end of file pointer, number of links, delete pending flag, and directory value).

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.6 FileInformation File System Test Group – StandardInformationTest

21.6.17 The file information accurately contain a unique index value of file that does not change when the file changes.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.6 FileInformation File System Test Group – InternalInformationTest

21.6.18 The file information must contain an index value that can be used to open up the file (may not be supported by all file systems).

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.6 FileInformation File System Test Group – InternalInformationTest

21.6.19 The file information must be able to be queried and accurately contain extended attribute size of a file.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.6 FileInformation File System Test Group – EaInformationTest

21.6.20 The file information must be able to be queried and accurately contain the long filename and the length of the filename.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.6 FileInformation File System Test Group – NameInformationTest


EaInformation File System Test Assertions

Assertions in this section are tested in TD-21.7 EaInformation File System Test Group.

21.7.1 The Extended Attribute information must be accurately read all three at once, both data and labels

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.7 EaInformation File System Test Group – FullEaInformationTest

21.7.2 The Extended Attribute information must be accurately read using a list of Extended Attribute names

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.7 EaInformation File System Test Group – ListEaInformationTest

21.7.3 The Extended Attribute information must be accurately read using an index value

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.7 EaInformation File System Test Group – IndexEaInformationTest

21.7.4 The Extended Attribute information must be accurately specified at file creation time

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.7 EaInformation File System Test Group – CreateEaInformationTest

21.7.5 The Extended Attribute information must also be accurately set at times other then file creation time

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.7 EaInformation File System Test Group – SetEaInformationTest

21.7.6 The Extended Attribute information can be accurately read back one entry at a time

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.7 EaInformation File System Test Group – SingleEaEntryTest


DirectoryInformation File System Test Assertions

Assertions in this section are tested in TD-21.8 DirectoryInformation File System Test Group.

21.8.1 The directory information must accurately record directory for access times, end of file pointers, extended attribute sizes and allocation sizes for queried files.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.8 DirectoryInformation File System Test Group – FullDirectoryInformationTest

21.8.2 The directory information, file names and file name lengths, must match file parameters.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.8 DirectoryInformation File System Test Group – FileNameDirectoryInformationTest

21.8.3 The directory information must insure that file directory information last access time, last write time, and change time are updated when data is written to the file.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.8 DirectoryInformation File System Test Group – FileDirectoryInformationTest

21.8.4 The directory information must insure that file directory information (two directories) last access time, last write time, and change time are updated when data is written to the file.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.8 DirectoryInformation File System Test Group – BothDirectoryInformationTest


FileLocking File System Test Assertions

Assertions in this section are tested in TD-21.9 FileLocking File System Test Group.

21.9.1 The file locking system must accurately obtain an exclusive lock on a file and a second process must fail at obtaining any lock on the file.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.9 FileLocking File System Test Group – LockSharedExTest

21.9.2 The file locking system must accurately obtain a shared lock on a file and a second process must fail at obtaining an exclusive lock on the file.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.9 FileLocking File System Test Group – LockSharedExTest

21.9.3 The file locking system must accurately unlock exclusive and shared byte range locks.

The process that did not lock the file must fail at attempts to unlock the locked file.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.9 FileLocking File System Test Group – UnlockRangeTest

21.9.4 The file locking system must accurately fail the overlapping exclusive locks attempts on locked exclusive regions.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.9 FileLocking File System Test Group – LockOverlapTest

21.9.5 The file locking system must accurately allow the overlapping of shared locks on shared locked regions.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.9 FileLocking File System Test Group – LockOverlapTest

21.9.6 The file locking system must be able to accurately lock an area, both exclusive and shared, and only allow proper access.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.9 FileLocking File System Test Group – LockRangeTest

21.9.7 The file locking system must be able to accurately set the file locking API to fail immediate, if a lock is currently held on the region of the file.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.9 FileLocking File System Test Group – LockFailImmediateTest

21.9.8 The file locking system must be able to accurately use event handles for synchronization of multiple locking processes.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.9 FileLocking File System Test Group – LockOverlappedTest

21.9.9 The file locking system must be able to accurately use file handles for locking and only allow proper access.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.9 FileLocking File System Test Group – UnlockAllTest

21.9.10 The file locking system must be able to accurately use threads to close handles for unlocking files.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.9 FileLocking File System Test Group – UnlockRangeOnCloseTest

21.9.11 The file locking system must be able to accurately use keys access to both shared and exclusive locked files.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.9 FileLocking File System Test Group – LockKeyTest


OpLocks File System Test Assertions

Assertions in this section are tested in TD-21.10 OpLocks File System Test Group.

21.10.1 The operating system must accurately set the batch operational lock but will release it if the file system wants it closed.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.10 OpLocks File System Test Group – BatchOplocksTest

21.10.2 The operating system must accurately notify of the completion a break I/O request packet (IRP) when other IRPs are queued.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.10 OpLocks File System Test Group – BreakNotifyTest

21.10.3 The operating system must accurately notify of an operational lock break being initiated when the file option is set.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.10 OpLocks File System Test Group – CompleteImmediatelyTest

21.10.4 The operating system must accurately break an operational lock when a write I/O request packet is received.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.10 OpLocks File System Test Group – OplockReadBreakItoIITest

21.10.5 The operating system must be able to accurately request and receive Level I operational locks which are exclusive.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.10 OpLocks File System Test Group – OplockLevel1Test

21.10.6 The operating system must be able to accurately break of a Level I or Level II operational lock to none with a set information I/O request packet.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.10 OpLocks File System Test Group – OplockSetInfoBreakTest

21.10.7 The operating system must break operational lock held against an open file objects before byte range file locking can be completed.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.10 OpLocks File System Test Group – LockOplockBreakTest

21.10.8 The operating system must be able accurately break a level I operational lock to level II when a file is opened a second time for reading or writing.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.10 OpLocks File System Test Group – OplockBreakItoIITest

21.10.9 The operating system must be able accurately break a level II operational lock when the file is opened for read and write access.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.10 OpLocks File System Test Group – OplockIIWriteBreakingTest

21.10.10 The operating system must be able accurately break a level II operational lock when the file is written to.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.10 OpLocks File System Test Group – OplockBreakIItoNoneTest

21.10.11 The operating system must be able accurately break Level I or Level II operational locks when the file is closed.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.10 OpLocks File System Test Group – OplockBreakIandIIOnCloseTest

21.10.12 The operating system must allow multiple files to maintain a level II operational locks on a file.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.10 OpLocks File System Test Group – OplockRequestIITest

21.10.13 The operating system must accurately break a level II operational locks on a file with a subsequent open.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.10 OpLocks File System Test Group – OplockIIOpenBreakingTest


ChangeNotification File System Test Assertions

Assertions in this section are tested in TD-21.11 ChangeNotification File System Test Group.

21.11.1 The change notification must accurately cleanup attributes in 4 seconds.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.11 ChangeNotification File System Test Group

21.11.2 The change notification must accurately report cleanup file size in 4 seconds.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.11 ChangeNotification File System Test Group

21.11.3 The change notification must accurately record the events of closing a file within 4 seconds.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.11 ChangeNotification File System Test Group

21.11.4 The change notification must accurately record the events of deleting a file within 4 seconds.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.11 ChangeNotification File System Test Group

21.11.5 The change notification must accurately record the events of changing a filename (rename, create, and delete) within 4 seconds.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.11 ChangeNotification File System Test Group

21.11.6 The change notification must accurately record the events of a flush write within 4 seconds.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.11 ChangeNotification File System Test Group

21.11.7 The change notification must accurately record the events of attempts to open a file and directory.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.11 ChangeNotification File System Test Group

21.11.8 The change notification must accurately record the events of any changes in the security descriptors of a file within 4 seconds.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.11 ChangeNotification File System Test Group

21.11.9 The change notification must support the Windows NT Security Model.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.11 ChangeNotification File System Test Group


DeviceControl File System Test Assertions

Assertions in this section are tested in TD-21.12 DeviceControl File System Test.

21.12.1 The device control system must be able to accurately open a file system related device object such as a partition or floppy device.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.12 DeviceControl File System Test – DeviceIOControlTest

21.12.2 The device control system must be able to accurately get the drive geometry, using an event and asynchronous procedure call, prior to timeout.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.12 DeviceControl File System Test – DeviceIOControlTest


FileSystemControlVolume File System Test Assertions

Assertions in this section are tested in TD-21.13 FileSystemControlVolume File System Test Group.

21.13.1 The file system control must accurately dismounting a volume (volume must be locked) by disconnecting a volume object from its associated file system driver.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.13 FileSystemControlVolume File System Test Group – ControlDismountVolumeTest

21.13.2 The file system control must accurately use the I/O Control interface to lock a non-system volume with no open handles.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.13 FileSystemControlVolume File System Test Group – ControlLockVolumeTest

21.13.3 The file system control must accurately use the I/O Control interface to unlock a volume.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.13 FileSystemControlVolume File System Test Group – ControlUnlockVolumeTest

21.13.4 The file system control must accurately check to see if a volume is mounted.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.13 FileSystemControlVolume File System Test Group – VolumeMountedTest

21.13.5 The file system control must accurately marks a volume as permanently dirty when a corruption is detected in the meta data.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.13 FileSystemControlVolume File System Test Group – MountedDirtyTest

21.13.6 The file system control must accurately search for all the volumes mounted on the same real device, and marks them all bad.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.13 FileSystemControlVolume File System Test Group – InvalidateVolumesTest

21.13.7 The file system control must accurately recognize when removable media is replaced with new media or changed media.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.13 FileSystemControlVolume File System Test Group – MountVerifyVolumesTest


FileSystemControlGeneral File System Test Assertions

Assertions in this section are tested in TD-21.14 FileSystemControlGeneral File System Test Group.

21.14.1 The file system control must accurately use retrieval pointers for use later in when writing the crash dump paging file.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.14 FileSystemControlGeneral File System Test Group – QueryRetrievalPointersTest

21.14.2 The file system control must accurately update retrieval pointers when file size changes.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.14 FileSystemControlGeneral File System Test Group – GetRetrievalPointersTest

21.14.3 The file system control must accurately compress individual files.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.14 FileSystemControlGeneral File System Test Group – SetCompressionTest

21.14.4 The file system control must accurately retrieve volume statistics, filesystem performance counters.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.14 FileSystemControlGeneral File System Test Group – GetStatisticsTest

21.14.5 The file system control (Fat Compatible Volumes only) must accurately check a pathname for valid characters, leading backslashes, and for wildcards.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.14 FileSystemControlGeneral File System Test Group – PathNameValidTest

21.14.6 The file system control must accurately exercise the FSCT, ensure volume bitmap is accurately mapping used and unused clusters.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.14 FileSystemControlGeneral File System Test Group – GetVolumeBitmapTest

21.14.7 The file system control must accurately move the logical clusters used by a file to new logical clusters on the volume.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.14 FileSystemControlGeneral File System Test Group – MoveFileTest

21.14.8 The file system control must not allow a DASD handle to be used to read/write beyond the end of the volume.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.14 FileSystemControlGeneral File System Test Group – AllowExtendedDASDTest


ReadWrite File System Test Assertions

Assertions in this section are tested in TD-21.15 ReadWrite File System Test Group.

21.15.1 The file system must be able to accurately read from and write to files.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.15 ReadWrite File System Test Group – ReadWriteTest

21.15.2 The file system must be able to accurately maintain cache coherency for open files.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.15 ReadWrite File System Test Group – ReadWriteCoherencyTest

21.15.3 The file system must be able to accurately open files with write through caching.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.15 ReadWrite File System Test Group – WriteThroughTest

21.15.4 The file system must be able to accurately open files with write through caching using both synchronous and asynchronous file handles.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.15 ReadWrite File System Test Group – WriteThroughSyncTest

21.15.5 The file system must be able to accurately append data to an open file that was opened with the append data access flag set.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.15 ReadWrite File System Test Group – AppendDataTest

21.15.6 The file system must be able to accurately specify the byte offset into the file and verified using the read function.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.15 ReadWrite File System Test Group – AtomicSeekReadTest

21.15.7 The file system should not update the file offset when using a zero byte length IO operation.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.15 ReadWrite File System Test Group – ZeroLengthIOTest

21.15.8 The file system must be able to accurately use the Read and Write functions that specify byte offsets and a byte lengths.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.15 ReadWrite File System Test Group – ReadWriteRangeTest

21.15.9 The file system must be able to accurately perform asynchronous IO with the Read and Write functions.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.15 ReadWrite File System Test Group – EventAsyncIOTest

21.15.10 The file system must be able to accurately perform asynchronous IO using APC with the Read and Write functions.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.15 ReadWrite File System Test Group – APCSynchRWTest

21.15.11 The file system must be able to accurately zero the contents of files, for security purposes when the file is extended either by setting the end of file pointer through the NT set function or by writing beyond the end of the file.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.15 ReadWrite File System Test Group – ZeroOnExtendTest


SectionCaching File System Test Assertions

Assertions in this section are tested in TD-21.16 SectionCaching File System Test Group.

21.16.1 The file system must be able to accurately extend files when a user mapping exists with a Set Information File and the new extended region should be initialized with 0's.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.16 SectionCaching File System Test Group – ExtendingWithUserMappingTest

21.16.2 The file system must be able to accurately flush file buffers for files with the FILE_ATTRIBUTE_TEMPORARY flag set.

The number of bytes written to the block device, the end of file pointer, and the last write time should be updated from the flush.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.16 SectionCaching File System Test Group – FlushBuffersTest

21.16.3 The file system must be able to accurately flush buffers of the root directory and obtain statistics

This requires Windows 2000. The statistics are the number of bytes written to the block device, the end of file pointer, the last write time for all files.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.16 SectionCaching File System Test Group – FlushBuffersRootTest

21.16.4 The file system must be able to accurately flush buffers on the volume handle and obtain statistics.

The volume statistics are the number of bytes written to the block device, the end of file pointer, and last write time.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.16 SectionCaching File System Test Group – FlushBuffersVolumeTest

21.16.5 The file system must be able to accurately create a user mapped section with an open file handle and still be maintained after the handle is closed.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.16 SectionCaching File System Test Group – MaintainSectionMappingTest

21.16.6 The file system must be able to accurately maintain coherency between the image section and the data section.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.16 SectionCaching File System Test Group – DataImageCoherencyTest

21.16.7 The file system will not supersede or overwrite files when a view on a user mapping exists.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.16 SectionCaching File System Test Group – ExistingUserMappingTest

21.16.8 The file system will not truncate files when user mapping exists.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.16 SectionCaching File System Test Group – TruncateWithUserMappingTest


Security File System Test Assertions

Assertions in this section are tested in TD-21.17 Security File System Test Group.

21.17.1 The NTFS file system must be able to accurately set ownership of files.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.17 Security File System Test Group – SetOwnerSecurityTest

21.17.2 The NTFS file system must be able to accurately set the security DACL to only allow read operations by the Administrator.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.17 Security File System Test Group – SetDaclSecurityTest

21.17.3 The NTFS file system must be able to accurately set a file’s the Group SID Security Group SID files and directories.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.17 Security File System Test Group – SetGroupSecurityTest

21.17.4 The NTFS file system must be able to accurately set the SACL list to allow audit operations to be performed on files.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.17 Security File System Test Group – SetSaclSecurityTest

21.17.5 The NTFS file system must be able to accurately audit the deletion of the file when set in the SACL.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.17 Security File System Test Group – AuditDelSecurityTest

21.17.6 The NTFS file system must be able to accurately audit the change of security permissions (the DACL) when set in the SACL.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.17 Security File System Test Group – AuditPermSecurityTest

21.17.7 The NTFS file system must be able to accurately audit the change of the owner of files when set in the SACL.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.17 Security File System Test Group – AuditOwnerSecurityTest

21.17.8 The NTFS file system must be able to accurately Bypass Traverse Checking for all users on the system.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.17 Security File System Test Group – DirectoryTraverseTest


ObjectID File System Test Assertions

These assertions only apply to file systems that support Object IDs.
Assertions in this section are tested in TD-21.18 ObjectID File System Test Group.

21.18.1 The Object IDs must be able to be used to accurately retrieve volume's Object ID.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.18 ObjectID File System Test Group – GetObjectIDVolumeTest

21.18.2 The Object IDs must be able to be used to accurately retrieve the full path of a file or directory.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.18 ObjectID File System Test Group – NameInformationExTest

21.18.3 The Object IDs must be able to be used to accurately open a file or directory.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.18 ObjectID File System Test Group – ObjectOpenByIDTest

21.18.4 The Object IDs must be able to be accurately added to and removed from object index.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.18 ObjectID File System Test Group – NotificationObjectIDRemovedTest

21.18.5 The Object IDs must be able to be accurately set (extended information portion) for a file or directory.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.18 ObjectID File System Test Group – SetExtendedObjectIDTest

21.18.6 The Object IDs must be able to accurately be set on files and directories provided that BACKUP/RESTORE privileges are enabled.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.18 ObjectID File System Test Group – SetObjectIDTest

21.18.7 The Object IDs must be able to accurately be set on a volume provided that a file or directory does not already have the same Object ID.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.18 ObjectID File System Test Group – SetObjectIDVolumeTest

21.18.8 The Object IDs must be able to accurately be tunneled for a file or directory.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.18 ObjectID File System Test Group – TunnelObjectIDTest

21.18.9 The Object IDs must be able to accurately report on the tunneling process (object ID added, removed, and restored).

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.18 ObjectID File System Test Group – NotificationObjectIDNotTunnelledTest

21.18.10 The Object IDs must be unique for each file and directory on the volume and cannot be reset.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.18 ObjectID File System Test Group – SetUniqueObjectIDNameCollisionTest

21.18.11 The Object IDs must be unique for each file and directory (duplicate ID’s are not allowed).

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.18 ObjectID File System Test Group – SetUniqueObjectIDDuplicateNameTest

21.18.12 The Object IDs must be able to accurately report on the adding of to an object index.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.18 ObjectID File System Test Group – NotificationObjectIDAddedTest

21.18.13 The Object IDs must be able to accurately be retrieved when existing or be generated new for a file or directory.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.18 ObjectID File System Test Group – CreateOrGetObjectIDTest

21.18.14 The Object IDs must be able to accurately report on the inability to be restored from the tunnel cache for duplicate object IDs or if the destination file already has an object ID.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.18 ObjectID File System Test Group – NotificationObjectIDTunnelledCollisionTest

21.18.15 The Object IDs must be able to accurately be removed from a file or directory, provided the handle is opened with RESTORE intent and WRITE access.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.18 ObjectID File System Test Group – DeleteObjectIDTest

21.18.16 The Object IDs must be able to accurately report on being removed from an object index.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.18 ObjectID File System Test Group – NotificationObjectIDDeletedTest

21.18.17 The Object IDs must be able to accurately be queried for volume structure.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.18 ObjectID File System Test Group – EnumObjectIDTest

21.18.18 The Object IDs must be able to accurately retrieved for files and directories.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.18 ObjectID File System Test Group – GetObjectIDTest


MountPoints File System Test Assertions

Assertions in this section are tested in TD-21.19 MountPoints File System Test Group.

21.19.1 The File System must be able to accurately copy a directory that contains a name graft.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.19 MountPoints File System Test Group – CreateDirectoryExDirectoryTest

21.19.2 The File System must be able to accurately create a volume mount point and then copy the directory containing the point.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.19 MountPoints File System Test Group – CreateDirectoryExVolumeTest

21.19.3 The File System must be able to accurately link a lower child directory to its immediate parent and then traverse the self-referencing directory tree up to 16 times before an error status is returned

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.19 MountPoints File System Test Group – DirectoryCycleOnReparseTest

21.19.4 The File System must be able to accurately reparse a name on a directory and then provide access through the reparse point.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.19 MountPoints File System Test Group – DirectoryGraftTest

21.19.5 The File System must be able to accurately reparse a name on a directory and show that name grafting requires an empty directory.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.19 MountPoints File System Test Group – DirectoryGraftEmptyFileTest

21.19.6 The File System must not be able to perform name grafting on a directory that contains a subdirectory.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.19 MountPoints File System Test Group – DirectoryGraftEmptyTest

21.19.7 The File System must not be able to perform name grafting on a directory using a handle to a named data stream on a directory.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.19 MountPoints File System Test Group – DirectoryGraftEmptyStreamTest

21.19.8 The File System must not be able to perform name grafting on a file.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.19 MountPoints File System Test Group – FileGraftTest

21.19.9 The File System must not be able to perform name grafting on a named data stream of a file.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.19 MountPoints File System Test Group – FileGraftStreamTest

21.19.10 The File System must be able to accurately create a volume mount point and then exercise it.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.19 MountPoints File System Test Group – LocalMountPointTest


ReparsePoints File System Test Assertions

Assertions in this section are tested in TD-21.20 ReparsePoints File System Test Group.

21.20.1 The File System must be able to only set a reparse point on an empty directory.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.20 ReparsePoints File System Test Group – SetPointDirectoryNotEmptyTest

21.20.2 The File System must be able to accurately retrieve the reparse tag for a given file or directory with a reparse point.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.20 ReparsePoints File System Test Group – EnumReparsePointsTest

21.20.3 The File System must be able to accurately obtain BASIC INFORMATION from a file or directory with a reparse point.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.20 ReparsePoints File System Test Group – FileAttributeReparsePointTest

21.20.4 The File System must be able to accurately get a reparse point set on files and directories while using an output buffer length argument.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.20 ReparsePoints File System Test Group – GetPointBufferSmallTest

21.20.5 The File System must be able to accurately get a reparse point set on files and directories only if a prior reparse point was set.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.20 ReparsePoints File System Test Group – GetPointNotReparseTest

21.20.6 The File System must be able to accurately get a reparse point set on files and directories only if the reparse buffer argument is not null.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.20 ReparsePoints File System Test Group – GetPointInvalidUserBufferTest

21.20.7 The File System must be able to accurately get a reparse point set on files and directories using only valid buffer arguments.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.20 ReparsePoints File System Test Group – GetPointInvalidParamTest

21.20.8 The File System must accurately report on an invalid buffer size when using a NULL reparse buffer argument.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.20 ReparsePoints File System Test Group – SetPointInvalidBufferSizeTest

21.20.9 The File System must accurately report on an invalid parameter when attempting to set a reparse point on a volume or by using an output buffer argument.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.20 ReparsePoints File System Test Group – SetPointInvalidParamTest

21.20.10 The File System must accurately report on an invalid IO reparse data when the input buffer length argument is greater than the max buffer size, the input buffer length argument different than the reparse data buffer length, or the GUID is equal to NULL (if ISV reparse tag).

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.20 ReparsePoints File System Test Group – SetPointIoReparseDataInvalidTest

21.20.11 The File System must accurately use volume index to wait for reparse point additions, when supported.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.20 ReparsePoints File System Test Group – ChangeNotificationReparseTest

21.20.12 The File System must accurately open files and directories with reparse points, which inhibits reparse behavior of the file or directory.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.20 ReparsePoints File System Test Group – OpenReparsePointTest

21.20.13 The File System must accurately query files and directories, with reparse points, for full attributes.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.20 ReparsePoints File System Test Group – QueryFullAttributesReparseTest

21.20.14 The File System must accurately query files and directories, with reparse points, for attributes tag information.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.20 ReparsePoints File System Test Group – QueryFileAttributeTagInfoTest

21.20.15 The File System must accurately set a reparse point on files and directories and check for valid behavior.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.20 ReparsePoints File System Test Group – SetPointIoReparseTagInvalidTest

21.20.16 The File System must not overwrite file and directory reparse tags with different reparse tags.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.20 ReparsePoints File System Test Group – SetPointIoReparseTagMismatchTest

21.20.17 The File System must not delete files and directories with a reparse point using normal deletion semantics.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.20 ReparsePoints File System Test Group – DeleteFileDirReparsePointTest

21.20.18 The File System must not be able to delete reparse points from files and directories without write access.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.20 ReparsePoints File System Test Group – DelPointAccessDeniedTest

21.20.19 The File System must be able to accurately delete reparse points from files and directories using Globally unique identifiers.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.20 ReparsePoints File System Test Group – DelPointAttributeConflictTest

21.20.20 The File System must not be able to delete reparse points from files and directories with NULL reparse buffers.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.20 ReparsePoints File System Test Group – DelPointInvalidBufferSizeTest

21.20.21 The File System must not be able to delete reparse points from files and directories with an input buffer length argument greater than reparse data buffer header size, an input buffer data length argument different than zero, or a buffer size argument different than the GUID header size (if ISV reparse tag).

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.20 ReparsePoints File System Test Group – DelPointIoReparseDataInvalidTest

21.20.22 The File System must not be able to delete reparse points from files and directories by using a reparse point on a volume or by using an output buffer argument.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.20 ReparsePoints File System Test Group – DelPointInvalidParmTest

21.20.23 The File System must not be able to delete reparse points from files and directories by using a reparse tag equal to IO reparse tag reserved-one or IO reparse tag reserved-zero.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.20 ReparsePoints File System Test Group – DelPointIoReparseTagInvalidTest

21.20.24 The File System must not be able to delete reparse points from files and directories by using a different reparse tag.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.20 ReparsePoints File System Test Group – DelPointIoReparseTagMismatchTest

21.20.25 The File System must not be able to delete reparse points from files and directories which do not have prior reparse points set.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.20 ReparsePoints File System Test Group – DelPointNotReparseTest

21.20.26 The File System must not be able to delete reparse points from files and directories which have extended attributes.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.20 ReparsePoints File System Test Group – SetPointEASNotSupportedTest

21.20.27 The File System must not be able to set reparse points on files and directories with no WRITE access.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.20 ReparsePoints File System Test Group – SetPointAccessDeniedTest

21.20.28 The File System must not be able to set reparse points from files and directories with mismatched GUID.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.20 ReparsePoints File System Test Group – SetPointAttributeConflictTest


SparseFiles File System Test Assertions

Assertions in this section are tested in TD-21.21 SparseFiles File System Test Group.

21.21.1 The file system must be able to accurately move sparse files to sparse regions over an already committed LCN range.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.21 SparseFiles File System Test Group – SparseMoveFileTest

21.21.2 The file system must be able to accurately have sparse and nonsparse data streams on files.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.21 SparseFiles File System Test Group – SparseNonSparseStreamTest

21.21.3 The file system must be able to accurately set a range of non-sparse files to zero.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.21 SparseFiles File System Test Group – NonSparseZeroDataTest

21.21.4 The file system must accurately change a sparse file to a non-sparse file when it is a overwritten.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.21 SparseFiles File System Test Group – ResetSparseAttrOverwriteTest

21.21.5 The file system must accurately use FSCTL_SET_ZERO_DATA to reduce the allocation size of sparse files.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.21 SparseFiles File System Test Group – SparseZeroDataAllocTest

21.21.6 The file system must be able to accurately set zero data to a range in sparse files.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.21 SparseFiles File System Test Group – SparseZeroDataTest

21.21.7 The file system must be able to accurately change allocation size of sparse files by writing data to the data stream.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.21 SparseFiles File System Test Group – SparseStreamTest

21.21.8 The file system must be able to accurately change allocation size of sparse directories by writing data to the data stream.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.21 SparseFiles File System Test Group – SparseStreamDirTest

21.21.9 The file system must accurately change a sparse file to a non-sparse file when the file is superseded.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.21 SparseFiles File System Test Group – ResetSparseAttrSupersedeTest

21.21.10 The file system must accurately reduce the allocation size of the sparse file by setting the data to zero.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.21 SparseFiles File System Test Group – SparseAllocatedRangesTest

21.21.11 The file system must be able to accurately set the sparse attribute flag depending on a stream by stream basis.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.21 SparseFiles File System Test Group – FileInformationSparseAttrTest

21.21.12 The file system must be able to accurately compress sparse files.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.21 SparseFiles File System Test Group – SparseCompressedStreamTest

21.21.13 The file system must be able to accurately create a user mapped section and view on sparse files.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.21 SparseFiles File System Test Group – SparseUserMappedSectionTest

21.21.14 The file system must accurately report if there is a user mapped section and view on sparse files.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.21 SparseFiles File System Test Group – SparseUserMapZeroTest


Extended Security File System Test Assertions

Assertions in this section are tested in TD-21.22 ExtendedSecurity File System Test.

21.22.1 The extended security system must be able to accurately scan the file records and find entries owned by a specified owner's SID.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.22 ExtendedSecurity File System Test – FindFilesBySidTest

21.22.2 The extended security system must be able to accurately scan the file records and find entries owned by a specified Administrator account SID.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.22 ExtendedSecurity File System Test – FindFilesBySidTest


ForcedDismount File System Test Assertions

21.23.1 The file system must be able to accurately dismount on an active volume, i.e., with opened file handles, unless the volume is the system drive or it is exclusive-locked.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.23 ForcedDismount File System Test


Encryption File System Test Assertions

Assertions in this section are tested in TD-21.24 Encryption File System Test Group.

21.24.1 The encryption driver must be able to accurately encrypt a file using the NtCreateFile API with the FILE_ATTRIBUTE_ENCRYPTED flag specified.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.24 Encryption File System Test Group – SuperOverEncryptedTest

21.24.2 The encryption driver must not allow an encrypt a file to be read without the correct security token and will warn user that access is denied.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.24 Encryption File System Test Group – SuperOverEncryptedTest

21.24.3 The encryption driver must be able to accurately read and write raw encrypted data.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.24 Encryption File System Test Group – ReadWriteRawEncryptedTest

21.24.4 The encryption driver must be able to accurately remove a specified user from a list of users that are permitted to access a specified encrypted file unless it is the last user.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.24 Encryption File System Test Group – RemoveUsersEncryptionTest

21.24.5 The encryption driver must be able to accurately retrieve a list of users that are permitted to access a specified encrypted file.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.24 Encryption File System Test Group – QueryUsersEncryptionTest

21.24.6 The encryption driver must be able to accurately retrieve a list of users that are permitted to recover a specified encrypted file.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.24 Encryption File System Test Group – QueryRecoveryAgentsTest

21.24.7 The encryption driver must be able to accurately recover a file using a recovery agent that is not the file owner.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.24 Encryption File System Test Group – QueryRecoveryAgentsTest

21.24.8 The encryption driver must be able to accurately encrypt and then decrypt a file.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.24 Encryption File System Test Group – EncryptDecryptFileTest

21.24.9 The encryption driver must be able to accurately encrypt and then decrypt a directory.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.24 Encryption File System Test Group – EncryptDecryptDirTest

21.24.10 The encryption driver must be able to accurately check the encryption status attributes of files and directories.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.24 Encryption File System Test Group – EncryptionStatusTest

21.24.11 The encryption driver must be able to accurately uncompress a compressed and encrypted file when a call to the file is made and the attributes on the file should then show encryption only.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.24 Encryption File System Test Group – EncryptionDecompressionTest

21.24.12 The encryption driver must be able to accurately encrypt a compressed file by decompressing the file, applying the encryption and then recompressing the file.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.24 Encryption File System Test Group – EncryptionCompressionTest

21.24.13 The encryption driver must be able to accurately get the encryption status of a file or directory.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.24 Encryption File System Test Group – EncryptionAttributeTest

21.24.14 The encryption driver must be able to accurately encrypt a non-empty directory and all the files in it.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.24 Encryption File System Test Group – DirectoryEncryptedSuperOverTest

21.24.15 The encryption driver must be able to accurately encrypt files created in an encrypted directory.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.24 Encryption File System Test Group – DirectoryEncryptedNewFileTest

21.24.16 The encryption driver must be able to accurately encrypt directories created in an encrypted directory.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.24 Encryption File System Test Group – DirectoryEncryptedNewDirTest

21.24.17 The encryption driver must be able to accurately encrypt files that have the FILE_ATTRIBUTE_ENCRYPTED flag set.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.24 Encryption File System Test Group – CreateEncryptedFileTest

21.24.18 The encryption driver must be able to accurately encrypt directories that have the FILE_ATTRIBUTE_ENCRYPTED flag set.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.24 Encryption File System Test Group – CreateEncryptedDirTest

21.24.19 The encryption driver must be able to accurately add a user to the list of users that are permitted to access a specified encrypted file

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.24 Encryption File System Test Group – CreateEncryptedDirTest


Quotas File System Test Assertions

Assertions in this section are tested in TD-21.25 Quotas File System Test Group.

21.25.1 The file system must accurately track quota usage and quota enforcement.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.25 Quotas File System Test Group – VolumeQuotaEnforceTest

21.25.2 The file system must be able to accurately use the FILE_VC_QUOTA_NONE flag to disable quota usage tracking.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.25 Quotas File System Test Group – VolumeQuotaNoneTest

21.25.3 The file system must be able to accurately query quota settings and set to the volume quota index.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.25 Quotas File System Test Group – QuerySetQueryQuotaTest

21.25.4 The file system must be able to accurately enable disk Quota tracking, whereby quota usage changes are tracked, but no quota enforcement is done.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.25 Quotas File System Test Group – VolumeQuotaTrackTest

21.25.5 The file system must accurately generate the correct event when the user quota exceeds the limit.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.25 Quotas File System Test Group – VolumeQuotaUserLimitTest

21.25.6 The file system must accurately ignore quota events when the FILE_VC_LOG_VOLUME_THRESHOLD flag is set.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.25 Quotas File System Test Group – VolumeQuotaLimitTest

21.25.7 The file system must accurately ignore quota events when the FILE_VC_LOG_VOLUME_THRESHOLD flag is set.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.25 Quotas File System Test Group – VolumeQuotaThresholdTest


LinkTracking File System Test Assertions

Assertions in this section are tested in TD-21.26 LinkTracking File System Test Group.

21.26.1 The IShellLink interface must accurately create and resolve the object of a link that has moved on the same volume.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.26 LinkTracking File System Test Group – IshellLinkResolveTest

21.26.2 The IShellLink interface must accurately create and resolve the object of a link that has moved on a different volume (on the same system).

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.26 LinkTracking File System Test Group – IShellLinkResolveVolumeTest


ChangeJournal File System Test Assertions

Assertions in this section are tested in TD-21.27 ChangeJournal File System Test Group.

21.27.1 The change journal must accurately record the event due to creating a new file and the create USN event must exist in the change log.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.27 ChangeJournal File System Test Group – ChangeJournalTest"

21.27.2 The change journal must accurately record the event due to writing new data at end of file and the write should complete successfully.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.27 ChangeJournal File System Test Group – ChangeJournalTest"

21.27.3 The change journal must accurately record the event due to setting end of file information and the truncate operation should complete successfully.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.27 ChangeJournal File System Test Group – ChangeJournalTest"

21.27.4 The change journal must accurately record the event due to changing extended attributes.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.27 ChangeJournal File System Test Group

21.27.5 The change journal must accurately record the event due to setting reparse point on a file.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.27 ChangeJournal File System Test Group – ChangeJournalTest"

21.27.6 The change journal must be able to creating a USN event in the change log, and increase size its size.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.27 ChangeJournal File System Test Group

21.27.7 The change journal must be able to reset all USN values to zero, and remove journal file from disk.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.27 ChangeJournal File System Test Group

21.27.8 The change journal must accurately create an enumeration that lists the change journal entries between two specified boundaries.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.27 ChangeJournal File System Test Group

21.27.9 The change journal be able to locate the create USN event in the change log.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.27 ChangeJournal File System Test Group

21.27.10 The change journal must accurately return information about the selected item in the USN journal.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.27 ChangeJournal File System Test Group

21.27.11 The change journal be able to locate the selected USN records in the change log.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.27 ChangeJournal File System Test Group

21.27.12 The change journal must accurately read and return the last file or directory USN event location in the change log.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.27 ChangeJournal File System Test Group

21.27.13 The change journal must accurately change the size of a USN journal.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.27 ChangeJournal File System Test Group

21.27.14 The change journal must accurately report the allocation size.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.27 ChangeJournal File System Test Group

21.27.15 The change journal must accurately write a close USN record for the current file, and return its USN.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.27 ChangeJournal File System Test Group


StreamEnhancements File Test Assertions

Assertions in this section are tested in TD-21.28 StreamEnhancements File System Test Group.

21.28.1 The named streams in a file must be able to be accurately created and queried.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.28 StreamEnhancements File System Test Group – StreamQueryNamesTest

21.28.2 The named streams in a file must be able to be accurately opened and renamed.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.28 StreamEnhancements File System Test Group – StreamRenameTest

21.28.3 The named streams in a file must be able to accurately notify of a file size change.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.28 StreamEnhancements File System Test Group – StreamNotifySizeTest

21.28.4 The named streams in a file must be able to accurately notify of a data change.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.28 StreamEnhancements File System Test Group – StreamNotifyWriteTest

21.28.5 The named streams in a file must be able to accurately notify of a change to names on a file or directory.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.28 StreamEnhancements File System Test Group – StreamNotifyNameTest

21.28.6 The named streams in a file must be able to be accurately opened and marked for deletion (and deleted on cleanup).

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.28 StreamEnhancements File System Test Group – StreamDeleteTest


DefragEnhancements File System Test Assertions

Assertions in this section are tested in TD-21.29 DefragEnhancements File System Test Group.

21.29.1 The Defrag Enhancement system must be able to accurately move directories, a cluster at a time, using directory handles, retrieval pointers, and volume handles.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.29 DefragEnhancements File System Test Group – MoveDirTest

21.29.2 The Defrag Enhancement system must be able to accurately record move system view (security, quota, reparse, object ID) directories, a cluster at a time, using directory handles, retrieval pointers, and volume handles.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.29 DefragEnhancements File System Test Group – MoveViewTest


System Cache Assertions

21.30.1 The target of the stress tests must not bug check or break as a result of resource timeout or critical section timeout.

Reference documents: Windows Logo Program System and Device Requirements WL-4
Test descriptions: TD-21.30 System Cache Test Description


DCDP 14-Day Stress (Anti-Virus) Test Assertions

This is preliminary documentation and subject to change.

21.32.1 [NEW v0.3] The driver must run under test for 14 days without failure.

Reference documents: WLP# - WL-4; See the "The Datacenter Driver Program" white paper at http://www.microsoft.com/hwdev/platform/server/datacenter/default.asp
Test descriptions: TD-21.31 DCDP 14 Day Stress (Anti-Virus) Test


Anti-virus File System Filter Test Descriptions

This section describes the anti-virus file system filter tests. Test descriptions include a description of each test, set up requirements, and results interpretations. Each named test is referenced by various assertions at the beginning of this chapter.

TD-21.1 Installable File Systems Test Suite

Test Kit: HCT 11, HCT 10

The Installable File System Test, IFS Test, was designed to test the compliance of installable file systems in the Microsoft Windows NT 4.0 and Windows 2000 Operating Systems. Its intended audience includes file system developers who want to verify that their drivers comply with a standard set of expected functionality. The IFS Test is run from the command line with several options specified. Each test that is run will return a test status block whether the test has passed or failed, or the test results can be viewed in NTlog.

The IFS Test was written with the following design goals in mind:

Click to show or hide information. Subsystem Independence

The software layer where the tests take place is at the NT Native Call API. (user mode ntdll.dll) This provides the important advantage of Subsystem Independence. The WIN32 API is a Microsoft supplied, publicly available interface. This interface creates the WIN32 subsystem, which depends heavily upon the private Microsoft native call interface. The NT Native Call API interface sits below all subsystems in the OS. By rigorously verifying the correct operation of the file system at this level, the correct operation for other subsystems can be reasonably assumed.

Click to show or hide information. Synthetic Operation Distinction

There are several WIN32 File System Operations that rely on the execution of a sequence of NT Native Call APIs. These are identified to be the first type of Synthetic File System Operations. The testing philosophy presented is to observe the use and expectations of the NT Native Call API by the Type I Synthetic Operations, track these usages and expectations, and verify that an existing Test (or combination there-of) exercises these operations. Some examples of this include the WIN32 Backup APIs (BackupRead, BackupWrite, BackupSeek), CopyFile and MoveFile.

The second type of Synthetic Operation is a File System related operation at the WIN32 level or NT Native Call API level which are satisfied by either the WIN32 or Kernel code. A good example is the NtSetInformationFile() call with the FilePositionInformation class specified. The file pointer is updated in the file object by the I/O Manager and the call is completed.

There are several reasons not to include Synthetic Operation testing directly in the Compliance test. Firstly, much of what would be tested would be in the WIN32 user mode code, kernel mode I/O Manager or Object Manager code. These are key system paths which are well tested and do not need to be re-tested by the File System Developer. Second, if a Synthetic Operation fails because of a File System problem, there would not be an easily descriptive failure analysis available to the developer without describing WIN32 or NT internal calls. In addition, if unexpected results do occur in the core Operating System components, these would not be easily traceable for the file system developer.

Click to show or hide information. Separate Test Groups

A file system driver is usually written by modifying an existing file system or IFS Kit skeleton. The IFS Test can be used by developers to test portions of their driver before the entire FSD is complete. This is accomplished by separating the IFS Test into groups, each comprised of the relevant set of individual tests. This independence permits testing of specific portions of the new FSD without the interaction from other untested or unimplemented functions.

Click to show or hide information. Asynchronous / Synchronous Testing

Most of the I/O operations can be performed both asynchronously and synchronously. The calling user mode thread may block in kernel mode when waiting for a Synchronous operation to complete. The same user mode thread may be able to continue execution while an asynchronous operation is completed by a system/worker thread in kernel mode. It is the job of the FSD developer to implement this functionality within the file system driver. The IFS tests are generally designed to be run in both modes of operation. Special tests are created where applicable to test certain cases where only asynchronous or synchronous operations are allowed.

Click to show or hide information. Fault Identification

The fault identification capability of the IFS Test allows a FSD developer to test different aspects of a file system and determine which operation causes a failure. The developer can better identify and isolate the problem if the exact point of failure is readily discernable. This capability is created by the separate IFS Test groups and independent tests within those groups. Each test will return a test status block indicating whether the test has passed or failed.

Click to show or hide information. Coverage

The goal for the IFS test is to compare all functional aspects of a new FSD with other completed file systems. By comparing the untested driver against a group of comprehensive tests that are known to work on time tested file systems (e.g. FASTFAT or NTFS), a new driver could be considered compliant from a functional point of view. This is a black box approach to the problem. Given the same input, any file system put in the box should behave in the same way. This approach, in conjunction with a stress test, will result in a robust test of the new FSD.

The native calls interact directly with the I/O manager and sometimes make direct calls into the FSD through these two interfaces. The level of control in the native calls allows for specific operations to be tested on the file system; enabling fault identification. The native calls also make the test extensible since new calls can replace outdated calls, and additional calls can be added to support new IRPs or Fast I/O paths.

There is a relationship between the native calls and the IRPs and Fast I/O paths. Not all native calls are considered in the IFS Test, but all IRPs and Fast I/O paths must be addressed for complete coverage. Note that all native calls that use the file system interface were considered.

Click to show or hide information. Extensible

The IFS Test can be added to when new capabilities are added to the file system model. The grouping of tests lends itself to this capability. Individual tests can be added and removed from the groups without affecting surrounding tests.

Backward compatibility can be checked by applying a selection of tests that were verified on previous versions of the Operating System and FSD.

Click to show or hide information. Development Guideline

Many questions on file system development are what is the minimum set of requirements for a compliant FSD. There are few complete file systems available for NT (NTFS being the most advanced). This lends to the confusion. The IFS Test helps establish a minimum set of capabilities that a file system driver should support. The tests can be used as a designer’s guide by demonstrating the expected capabilities of their system. Notes in the documentation of the test will help describe what is expected and what capabilities the FSD must have to be compliant.

Click to show or hide information. Filter Testing

The IFS Test can be used to diagnose filter problems. Appendix A in this on-line help file describes two properties of filters, transparency and co-existence. It details how the IFS Test can be used to verify these properties and determine if a filter is impacting an NT system in an undesirable way.


TD-21.2 OpenCreateGeneral File System Test Group

The tests in this group include:

Click to show or hide information. CreatePagingFileTest

The create paging file function can be used to create a paging file. Paging file creation is tested using a combination of file opens on the paging file and registry queries. The create paging file function is used to create a new paging file and verified to return a success. The create file function is called with the file open disposition on the paging file. All share access rights and a desired access of just synchronize are used in the open. This should fail since the file open for paging does not allow even a minimal amount of access.

Click to show or hide information. FileNameLengthTest

Each file system supports different length filenames. This is file system dependent and determined by internal representations. The maximum component name length obtained from attribute information test is used to determine the maximum filename length the file system will support. This value is used to form filenames less than, equal, and greater than the maximum. The create file function is used to test the different filenames. When the filenames specified go beyond the maximum length, an error should be returned by the create file function, object name invalid. The created files are verified by calling the create file function. A successful open verifies the creation and reference of the file by names of proper length. The test is repeated for directory names. The directory file option flag is specified to the create file function.

Click to show or hide information. HFHTest

This tests the parsing of the double backslash when used as a prefix for a filename or directory name. The backslash is converted to a single backslash in this case. A file is created in the root directory of the volume under test. The file is opened with a call to the create file function. The double backslash is used for the open access. The open should succeed on the file.

A directory is created in the root directory of the volume under test. The directory is opened with a call to the create file function. The double backslash is used for the open access. The open should succeed on the directory.

Click to show or hide information. UnicodeOnDiskTest

The Unicode on disk volume attribute flag can be obtained using the query volume information function. This flag indicates that the file system will store the Unicode representation of the filename on the disk. Several files are created using the create file function call. These filenames contain Unicode characters. Several valid and invalid Unicode characters are used in the filename. The directory is then queried. The long names are checked to see if the Unicode representation has been preserved. The code page is then changed. The returned filenames are checked to see if the Unicode representation has been stored. All invalid Unicode characters in the code page should be returned as a ‘?’.

Click to show or hide information. CaseSensitiveTest

The case sensitive search volume attribute flag can be obtained using the query volume information function. This flag indicates that the file system will differentiate between file names that differ only in case. That is, when two file names are identical except for case, they are considered different files. This is verified by using the create file function with several file names that differ only in case. Each file is filled with different data. The files are then opened with the filenames and the unique data they contain is verified with by reading the files. The files are then queried for the unique IDs. These IDs are verified to be different for the cases where the filenames differ only by case.

Click to show or hide information. PreserveCaseTest

The case preserved names volume attribute flag can be obtained using the query volume information function. This flag indicates that the file system will preserve the case of different file names. That is, when a file is created with a mixed-case file name, the directory contents when queried return file names that reflect the original mixed case. This is verified by using the create file function call with several file names that have mixed case. The directory is then queried. The returned file names are checked to see if the case has been preserved from create time.

Click to show or hide information. ShortFileNameTest

This test is performed if the file system supports long names. Short names are the MSDOS compatible 8.3 format. Long names are defined as any file names that do not fit in the 8.3 format but are otherwise legal names in the file system. The file system should always create an 8.3 representation for the long filename. The 8.3 representation may be created when extended characters are used in the file name. This short name representation can be used to access the file just as with the long filename. This capability is verified by using the create file function with several long file names and several filenames that use extended characters. The directory is then queried. The returned short and long file names are checked to see if the short names have been properly created for the files. The file is then accessed using the short name. This should be successful.

Click to show or hide information. ShareAccessTest

The share access of a handle can be specified at create file time. This access determines if subsequent opens on the same file are allowed to succeed. A file is first created with read attributes desired access and no share parameters set. This will only allow query type operations.

The file is created with the create file function. Four subsequent opens are attempted on the file. The create file function is used to open the file with the following desired access parameters: read data, write data. The two calls are made separately. These should both fail since sharing is not allowed for these options. A third call specifies zero for the access parameters, but specifies delete on close create option, this too should fail with access denied error. The last call is made with a zero for the access parameters and read attributes for the create options. This should succeed as queries are allowed. This test is verified by specifying the share parameters separately. The pass/fail result of the create file function verifies the correct operation of the share control. These tests are repeated for directories and DASD handles, the same results apply.

Click to show or hide information. AlternateStreamTest

NTFS supports alternate data streams. By specifying the filename as in the normal open/create tests but following the name with a colon ‘:’ and the name of the alternate stream, the alternate streams can be opened/created. A test file is created using the create file function and data is written to the file. The test filename is appended with the string ":stream1 and the alternate data stream is opened using the create file function. Data is written to the alternate data stream. Two more streams are opened and written to with different data. All open file handles are closed. The alternate data streams and primary data stream is open for reading. The data is verified. An attempt is then made to open data streams, which do not exist in the file. The proper status should be returned from the call to the create file function.

Click to show or hide information. StreamShareTest

Share access of a handle of an alternate data stream should follow the same rules as the opening of another handle on the same file. A single stream in a file containing multiple streams is first opened with the read attributes desired access and no share parameters set. This will only allow query type operations.

The stream is opened with the create file function. Four subsequent opens are attempted on the handle. The create file function is used to open a different stream with the following desired access parameters: read data, write data. The two calls are made separately. These should both fail since sharing is not allowed. A third call specifies zero for the access parameters, but specifies delete on close create option. This should also fail. The last call is made with a zero for the access parameters and read attributes for the create options. This should succeed as queries are allowed. This test is verified by specifying the share parameters separately. The pass/fail result of the create file function verifies the correct operation of the share control.

Click to show or hide information. FileSystemDeviceOpenTest

The FSD should create a Device Object in the root directory of the Windows NT object namespace (e.g. \Fat, \Ntfs). This tests the opening (and thereby verification of existence) of this Device Object. The user supplies an Object Namespace path as input. The file open disposition is used with the desired access of ReadAttributes. The successful return on the operation is required to pass the test.

Click to show or hide information. FileFullPathCreationTest

A fully qualified filename is one that consists of the full path to a file in the Windows NT object namespace. For this test, the system path to the volume is used as a prefix to the filename. The filename that is appended to this path is formed within the upper bound of the maximum component name length. The non-existence of the file is verified by a call to the create file function with the file open disposition. This should fail with an object name not found error. The file is then created with a call to the create file function with the file create disposition. ReadOnly volumes should return a write protection error at this point. The file handle is closed. The existence of the file is verified with a call to the create file function with the file open disposition. This should succeed.

Click to show or hide information. DirectoryFullPathCreationTest

A fully qualified directory-name is one in which a full path including the system root, volume root, and directory path is supplied as a prefix to the directory name. The TESTVOL and TESTROOT strings are used as prefixes to the directory name in this test. The directory name is appended to the path and formed within the upper bound of the maximum component name length.

The failure of the create when the temporary attribute is specified is tested. The creation of a directory in a path that exists and does not exist is tested. The nonexistence of the directory is verified by a call to the create file function with the file open disposition and the file directory option flag. This option flag instructs the file system to open a directory rather than a file. This should fail.

The directory is then created with a call to the create file function using the file create disposition with the directory file option flag. This is also tested with the temporary attribute set in the call to the create file function. This should fail with an access denied error. The directory handle is then closed.

The existence of the directory is verified by another call to the create file function with the file open disposition and the directory file option flag set. This operation should succeed. The handle to the directory is then closed. A file is then created inside of the newly created directory using the create file function and the fully qualified path and filename. The call to the create file function should have the file create disposition. The handle is then closed.

A subsequent open on the fully qualified directory path and filename using the create file function and the file open disposition will verify the file is created in the directory path. The handle is then closed. The above directory creation is tested with a path specified with TESTVOL\TESTROOT\faketestdir\testdir. This should fail since faketestdir does not exist. The above directory creation is tested with a path that does exists (realtestdir instead of faketestdir). This should succeed.

Click to show or hide information. FileRelativePathCreationTest

Files can be accessed by going through the handle of an open directory. This is considered a relative path access since the file is created relative to a specific open directory. The handle to the test directory is used in the object attributes parameter to the create file function. The file name is created within the upper bound of the maximum component length. Only the file name is passed into the create file function since no qualifying path is necessary.

A handle to a test directory is opened. The non-existence of the file is verified by a call to the create file function with the file open disposition; this should fail with an object name not found error. The existence of the file is verified by another call to the create file function with the file open disposition. This operation should succeed. The file handle and test directory handles are then closed. The above test file creation attempt is repeated, but the file name specified is modified to have a leading backslash. This operation should fail with an object name invalid error.

Click to show or hide information. DirectoryRelativePathCreationTest

Directories can also be opened or created relative to an open directory. This is considered a relative access. The handle to a test directory, is used in the object attributes parameter to the create file function. The directory name is created within the upper bound of the maximum component name length. There is also a test for failure on leading backslash.

A handle to the test directory is opened. The nonexistence of the directory is verified by a call to the create file function with the file open disposition and the directory file option flag set. This create option instructs the file system to create a directory not a file. This should fail since the operation is attempting to open a directory that does not exist. The directory is then created with a call to the create file function using the file create disposition and the directory file create option. This should succeed. The directory handle is then closed. The existence of the directory is verified by another call to the create file function with the file open disposition and with the directory file option flag. This operation should succeed.

A file is then created inside of the newly created directory using the create file function with the file create disposition. The handle to the recently created directory should be passed in as an object attribute for the relative path information. The handle is then closed. A subsequent open using the create file function call with the file open disposition on the created directory handle verifies the file is created in the new directory. The handles to the file, directory and test directory are closed. The above test directory creation attempt is repeated, but the directory name specified is modified to have a leading backslash, this should fail with object name invalid error.

Click to show or hide information. FileOpenByIDTest

The unique and persistent identifier for a file can be queried. This identifier can be used to open the file on supported file systems. A test file is created in the TESTVOL\TESTROOT path. The query information file function is called to obtain the unique index value. The 8 bytes are passed into a call to the create file function in place of the filename. A handle to the test root path is passed into the call through the object attributes root directory parameter. The file open disposition is used. The contents and attributes of the opened file are compared against the test file.

Click to show or hide information. NonDirectoryFileOpenTest

The non-directory file option flag can be specified in a call to the create file function. The operation should fail if the object being opened is a directory and the flag is set. The directory file option flag can be specified in a call to the create file function. This operation should fail if the object being opened is a file and the flag is set.

A test directory is created in the TESTVOL\TESTROOT path. An open is attempted on the directory with the non-directory file. This operation should fail with the not a directory error. An open is attempted on the directory without the non-directory file disposition being set. This operation should succeed. The same operation should be performed with the directory file flag set. This should succeed in the same way the first attempt succeeded.

A test file is created in the TESTVOL\TESTROOT path. An open is attempted on the file with the directory file flag set. This operation should fail with object name invalid error. An open is attempted on the file without the directory file being set. This operation should succeed. The same operation should be performed with the non-directory file flag set. This should succeed in the same way the first attempt succeeded.

Click to show or hide information. OpenVolumeTest

The file system driver should support volume or DASD opening. This allows for an opening of the "\DosDevices\?: volume device; where ?: is the name of the drive letter mapped to the volume under test. Once the volume device is opened, it can be written in a direct byte access method as opposed to a file and directory hierarchy. Automatic volume locking is also tested.

First we create a new file on the volume. We are not concerned over the desired access. This will be to maintain an open handle. Next an attempt is made to open the volume. Since the share access is 0, there can be no open handles on the volume. We check to see that the sharing violation error came back. Next we try to open the volume for reading. Even though we only have one handle open and that is a read only handle, we should fail with a sharing violation error. Next we try to open the volume with the file share read disposition on the share access. Since there is only one handle open and this is a read only handle, we should have a success. Next, two DASD opens are attempted, the first should succeed and the second should fail with an access denied error.


TD-21.3 OpenCreateParameters File System Test Group

The tests in this group include:

Click to show or hide information. OverwriteFileTest

When the file create function is used with the file overwrite disposition, an existing file is required. The existing file is truncated so the end of file pointer is set to the beginning of the file. The System and Hidden attributes specified in the call to the file create function must match the attributes currently set on the existing file. New attributes are ORed into the existing attributes, that is existing attributes cannot be cleared, but additional attributes can be specified.

The file create function is used with the file overwrite function on a filename that does not exist, this operation should succeed. Next the file create function is used with the file overwrite function on a filename that does exist, this operation should return a file overwritten status. The file is then read, and should now be empty.

Click to show or hide information. OverwriteFileAllocTest

When the file create function is used with the file overwrite disposition, an existing file is required. The existing file is truncated so the end of file pointer is set to the beginning of the file.

The test is performed with an allocation size specified to the file create function. The allocation size is queried and is verified to be a multiple of the minimum allocation size.

Click to show or hide information. OverwriteFileAttrTest

When the file create function is used with the file overwrite disposition, an existing file is required. The System and Hidden attributes specified in the call to the file create function must match the attributes currently set on the existing file. New attributes are ORed into the existing attributes; that is, existing attributes cannot be cleared, but additional attributes can be specified.

The file create function is used with the file overwrite function on a filename that does not exist; this operation should succeed. Next the file create function is used with the file overwrite function on a filename that does exist; this operation should return a file overwritten status. The file is then read, and should now be empty.

The test is repeated again on a hidden system test file. This time when the file create function is called the status returned is a media write protected error. The test is repeated again on a read-only file; now when the file create function is called, the test should fail with an access denied error.

Click to show or hide information. SupersedeFileTest

When the file create function is specified with the file supersede disposition, an existing file is required. The existing file is truncated so the end of file pointer is set to the beginning of the file. The system and hidden attributes specified in the call to the file create function must match the attributes currently set on the existing file. New attributes become the attributes of the file; that is existing attributes are replaced with the new attributes.

The file create function is called with the file supersede disposition and a filename that does not exist; this should succeed. Next the file create function is called with the file supersede disposition on a filename that does exist; this should return a file supersede status.

Click to show or hide information. SupersedeFileAllocTest

When the file create function is specified with the file supersede disposition, an existing file is required. The existing file is truncated so the end of file pointer is set to the beginning of the file.

The test is performed with an allocation size specified to the file create function, the allocation size is then queried and it is verified to be a multiple of the minimum allocation size.

Click to show or hide information. SupersedeFileAttrTest

When the file create function is specified with the file supersede disposition, an existing file is required. The system and hidden attributes specified in the call to the file create function must match the attributes currently set on the existing file. New attributes become the attributes of the file; that is existing attributes are replaced with the new attributes.

The test is performed on a hidden system file, when the file create function is called with the file supersede disposition, the media write protected error is returned. The test is repeated on a file that is read only; the call to the file create function with the file supersede disposition should fail with an access denied error.

Click to show or hide information. ReadOnlyAttributeTest

The attributes of a file can be set at file creation time. If the read only attribute is set on a file, the file can be opened for reading but not writing. The file cannot subsequently be opened with the delete on close option set. The delete on close option and read only attribute are mutually exclusive. A test file with the read only attribute is opened and a write is attempted. This should fail with an invalid user buffer error. Next a read is attempted on the test file; this should pass without any errors. The file handle is then closed. The file create function with the delete on close option set, is used to open a test file; this attempt should fail with an access denied error. Next this test is performed on a test file with the delete on close and read only option set at creation time; this should fail with an access denied error.

Click to show or hide information. SystemAttributeTest

The attributes of a file can be set at file creation time. If the system attribute is set on a file, the file will reflect this attribute information with the query directory file function. A file is created with the system attribute set. The query directory file function is then called to verify the existence of the flag in the returned information on the file.

Click to show or hide information. OpenFileTest

An attempt is made to open a file that does not exist; this attempt should return an object not found error. Next, an attempt is made to open a file that does exist; this operation should succeed.

Click to show or hide information. OpenFileDirTest

An attempt is made to open a directory that does not exist; this attempt should return an object not found error. Next an attempt is made to open a directory that does exist; this operation should succeed.

Click to show or hide information. CreateFileTest

The file create disposition does not allow an open on an existing file. This disposition will create a new file if the file does not exist, and returns an error if the file already exists.

The file create disposition is used to create a file that does not exist; this operation should succeed. Next the file create disposition is used to create a file that does exist; this operation should fail with an access denied error.

Click to show or hide information. OpenAlwaysFileTest

The file open if disposition allows the opening of an existing or nonexistent file. If the file does not exist, the file is created. The create file function is used with the file open if disposition for a filename that does not exist; this operation should return a created status. Next the create file function is used with the file open if disposition for a file name that does exist; this operation should return an open status.

Click to show or hide information. OpenAlwaysFileDirTest

The file open if disposition allows the opening of an existing or nonexistent directory. If the directory does not exist, the directory is created. The create file function is used with the file open if disposition for a directory name that does not exist; this operation should return a created status. Next the create file function is used with the file open if disposition for a directory name that does exist; this operation should return an open status.

Click to show or hide information. OverwriteAlwaysFileTest

The file overwrite if disposition does not require an existing file. If the file is created, the end of file pointer is already at the beginning of the file so no overwriting is done. If the file already exists, the file is truncated. The end of file pointer is set to the beginning of the file. The system and hidden attributes specified in the call to the file create function must match the attributes currently set on the existing file. New attributes are ORed into the existing attributes; that is, existing attributes cannot be cleared, but additional attributes can be specified.

The file create function is used with the file overwrite if disposition on a filename that does not exist. The status returned should be a file created success. Next the file create function is used with the file overwrite if disposition on a filename that exists and contains data, this should return a success message, and a file overwritten status. A read is done on the file and there should be no data in it.

Click to show or hide information. OverwriteAlwaysAllocTest

The file overwrite if disposition does not require an existing file. The file create function is used with the file overwrite if disposition on a filename that does not exist. The status returned should be a file created success. Next the file create function is used with the file overwrite if disposition on a filename that exists and contains data, this should return a success message, and a file overwritten status. A read is done on the file and there should be no data in it.

The test is repeated with an allocation size specified in the file create function; the allocation size is then queried and it is verified to be a multiple of the minimum allocation size.

The test is repeated on a hidden system file, when the file create function is called with the overwrite if disposition, the media write protected error is returned. The test is repeated, this time on a file that is read only; the call to the file create function with the overwrite if disposition should fail with an access denied error.

Click to show or hide information. OverwriteAlwaysAttrTest

The file overwrite if disposition does not require an existing file. The file create function is used with the file overwrite if disposition on a filename that does not exist. The status returned should be a file created success. Next the file create function is used with the file overwrite if disposition on a filename that exists and contains data; this should return a success message, and a file overwritten status. A read is done on the file and there should be no data in it.

The test is repeated on a hidden system file, when the file create function is called with the overwrite if disposition, the media write protected error is returned. The test is repeated, this time on a file that is read only; the call to the file create function with the overwrite if disposition should fail with an access denied error.

Click to show or hide information. FileAllocationSizeTest

The allocation size of the file can be specified at creation time. This is the amount of space the file takes up on the storage device. The actual size of the file is marked by the end-of-file pointer. The minimum allocation size varies on a file system, and volume basis. The file create function is used with a specified allocation size to reserve the storage for several files. Each file requests a different allocation size. Each file is then queried and verified for its allocation size. The size should be consistent with the specified allocation size, rounded up to the minimum allocation size allowable for the volume. Then a file is created with no allocation size specified; the default allocation size should be zero and this is verified.

Click to show or hide information. ExecuteAccessTest

The file execute disposition causes the file system driver to update the last accessed time on a handle close. The last access time is read from the file and recorded. The file create function is used to open a sample executable with the file execute disposition. The handle is then closed. The last access time is then checked and verified to be updated.

Click to show or hide information. HiddenAttributeTest

The attributes of a file can be set at file creation time. If the hidden attribute is set on a file, the file will reflect this attribute information with the query directory file function. A test file is created with the hidden attribute set. The query directory file is used to verify the existence of the flag in the returned information on the file.

Click to show or hide information. NormalAttributeTest

The attributes of a file can be set at file creation time. If the normal attribute is set on a file, the file will reflect this attribute information with the query directory file. Normal file attributes are NOT read only, hidden, system, directory or archive. A file is created with the normal attribute set. The file is then closed. The query directory file is then called to verify the absence of the following attributes: read only, hidden, system, directory or archive.

Click to show or hide information. DirectoryAttributeTest

The directory attribute designates a file as a directory. The attribute should be set by the file system when a new directory is created. If the directory attribute is set on a file, the file will reflect this attribute information with the query directory file. A test directory is created and the query directory function is called on the directory containing this test directory, to verify the existence of the flag in the returned information on the directory. A new file is then created and the query directory file function is called to verify the cleared directory attribute flag in the returned information on the file.

Click to show or hide information. CreateFileDirTest

The file create disposition does not allow an open on an existing directory. This disposition will create a new directory if the directory does not exist, and returns an error if the directory is already existing.

The file create disposition is used to create a directory that does not exist, this operation should succeed. Next the file create disposition is used to create a directory that does exist; this operation should fail with an access denied error.

Click to show or hide information. ArchiveAttributeTest

The attributes of a file can be set at file creation time. If the archive attribute is set on a file, the file will reflect this attribute information with the query directory file. The archive attribute should be set anytime a file is created or modified without the archive attribute specified in the call to the file create file function. A file is created with the archive attribute set. The query directory file is used to verify the existence of the flag in the returned information on the file. The test is repeated on a file without the archive attribute set, the attribute should be set after the handle to the file is closed. The test is repeated with four permutations of cached/no buffering and synchronous/asynchronous. The test file is again opened and the archive bit is cleared. The handle to the file is then closed. The file is then queried and it is verified that the archive bit is not set. The file is again opened and a few bytes are written to the file. The handle to the file is then closed. The query directory file is then called again to verify the archive bit is set.


TD-21.4 CloseCleanupDelete File System Test Group

The tests in this group include:

Click to show or hide information. VolumeUnlockOnCloseTest

The volume can be opened directly for DASD access. I/O buffers must be subsequently sector aligned direct or buffered. The volume is auto-locked as a result of a DASD open. The semantics for the DASD open are tested in OpenVolumeTest. No additional files can be opened on the locked volume (even with minimal or no desired access).

The test opens the volume with auto-lock and attempts to perform a file open. The operation’s failure (due to the locked volume) is verified. The handle to the open volume is then closed. When the DASD handle is closed, the volume should release the volume lock. This is tested by again attempting a file open. This time the file open should succeed.

Click to show or hide information. UpdateOnCloseTest

A Directory Handle can be used to find a file contained in that directory, and obtain the File Times, Attributes, End of File Pointer, and Allocation size. If there are open handles on the file, there may be a difference between changes that have been made to the file, with regards to the above file information, and the information that is read back by way of the open directory handle. The information is updated when the last open handle to the File Object is closed. This sends out an IRP_MJ_CLEANUP.

This test first creates a number of files, verifies the file information by way of a directory handle and queries. The files are then opened, written to, and read from. The file information is again queried and checked to see that it has not updated. The file handles are then closed. The file information is again queried and the updated information is verified.

The test is repeated, but then the updated (but not committed) information is changed using an IRP_MJ_SET_INFORMATION. The information that was updated by way of the set information IRP is verified when the file handles are closed. The test verified the set information overwrites any other updated information when the IRP_MJ_CLEANUP causes the file system driver to reconcile the information.

Click to show or hide information. UpdateOnCloseDirTest

A Directory Handle can be used to find a sub-directory contained in that directory, and obtain the File Times, Attributes, End of File Pointer, and Allocation size of the sub-directory. The End of File Pointer and Allocation size should be returned as 0. If there are open handles on the sub-directory, there may be a difference between changes that have been made to the sub-directory, with regards to the above information, and the information that is read back by way of the open directory handle (of the directory that contains the sub-directories). The information is updated when the last open handle to the File Object (for the sub-directory) is closed. This sends out an IRP_MJ_CLEANUP.

This test first creates a number of sub-directories, verifies the file information by way of a container directory handle and queries. The sub-directories are then opened, access by listing, and modified by creating file inside of those test sub-directories. The file information is again queried and checked to see that it has not updated. The sub-directory handles are then closed. The file information is again queried and the updated information is verified.

Click to show or hide information. TruncateOnCloseTest

If the allocation size is larger than the file size, the file system should reduce the allocation size to the smallest possible size rounded up to the nearest minimum allocation unit. This reduction is performed when IRP_MJ_CLEANUP is sent to the file system. This corresponds to close of the last open handle to a file object.

This is tested with a file where the allocation size is set at creation time. The file is then written with a much smaller amount of data then the allocation size. The handle is then closed. The file is again opened (allocation size not set on open) and the allocation size is checked to see that it has been reduced.

Click to show or hide information. TunnelingTest

The short naming convention is in the DOS 8.3 format. Both FAT and NTFS file systems have 2 namespaces. These namespaces should map to the same files. When a file is created with a name that is not in the 8.3 format and ASCII code page, a short name representation can also be created. The short name can be used to access the file by an MS-DOS or Windows operating system. The short name can also be used by Windows NT to access the file. A problem arises when legacy applications delete files by their Short Names, and then try to re-create these files. Namely, the long names would be lost. The Tunneling Cache in the FAT and NTFS file systems takes care of this. The Cache is Process and Directory specific. When a file is deleted, and created again using it’s short name ONLY, the long name will be re-applied to the file.

This test first opens a test directory. The directory handle is then used to create several long named files in that directory. The different directory handle is then used to query for long and short name information. The handles to the files are closed. The files are then deleted.

Files are created using the directory handle and the previously queried short names. A different directory handle is then used to query the directory for file name information. The long file names are thereby verified.

Click to show or hide information. DeleteOnLastCloseTest

Files are deleted on the final handle IRP_MJ_CLEANUP that have previously been marked for deletion. There are two mechanisms for marking a file for delete. The first is from open/create with the option to delete on close. The second is to set the file information to mark the file for delete on close. These two mechanisms have different semantics.

The following rules should clarify the purpose of this test:

  • When a handle is opened for delete on close, that handle is now a "delete on close handle.
  • When a "delete on close handle is closed (in the IRP_MJ_CLEANUP path), the file is then (and only then) marked for deletion and becomes a "delete on close file.
  • When the file is deleted through a set information call, the file is marked for deletion and becomes a "delete on close file.
  • No additional handles can be opened on a delete on close file (i.e. a file that has been marked for deletion). Such attempts will fail with STATUS_DELETE_PENDING.
  • A query for deletion pending to a file that is a "delete on close file will return TRUE.
  • When the file information is set not to delete the file on close, the file is unmarked for deletion and is no longer a "delete on close file. The handle that received the set information call may still be a "delete on close handle, in which case the file will again become a "delete on close file when the handle is closed.
  • When the final handle to a "delete on close file is closed, the file is deleted.


TD-21.5 VolumeInformation File System Test Group

The tests in this group include:

Click to show or hide information. VolumeLabelTest

Each volume maintains a label that can be queried and set. This test opens up a handle to a volume and queries the volume information. The volume handle is then closed and two handles, a directory handle and file handle are then opened. A volume information query is done on both handles and verification is done to make sure the volume information matches that which was queried with the volume handle. Next the volume label is changed and a query is done to make sure that the label did get changed. If the label did get changed then the original volume label is restored and the test has complete. The test is run 3 more times to test certain error conditions. The first error condition to test is trying to change the volume label with a directory or file handle, this attempt should return an access denied error. The second error condition to test is trying to set the volume label to a string over 32 UNICODE characters long; this should return a invalid volume label error. The third error condition to test is trying to query the volume information with a small buffer; this should return a buffer overflow error.

Click to show or hide information. VolumeInformationTest

The creation time, serial number, and volume label are applied to the volume at format time. The operating system can query the volume for this information. This test is run 3 times, opening up a volume handle, directory handle and a file handle. Each handle is then queried for volume information and the following fields are all verified: volume creation time, volume serial number, volume label length, support objects, and volume label are all checked.

Click to show or hide information. SizeInformationTest

The size information that can be queried gives information about the allocation units on the volume. The allocation unit is the smallest unit of space that can be allocated on a volume. For example, a file that stores 1 byte will allocate the allocation unit size on the volume. This information is verified here and is used in other tests. This test is run 3 times, opening up a volume handle, directory handle and a file handle. Each handle is then queried for volume size information and the following fields are all verified: total allocation units, available allocation units, sectors per allocation unit and bytes per sector.

Click to show or hide information. DeviceInformationTest

The characteristics of a volume device can be queried along with the device type. This test is run 3 times, opening up a volume handle, directory handle and a file handle. Each handle is then queried for volume device information and the following fields are all verified: device type and characteristics.

Click to show or hide information. AttributeInformationTest

The attributes are initially set during volume formatting. The attributes contain important information about the capabilities of the file system with the volume. This test is run 3 times, opening up a volume handle, directory handle and a file handle. Each handle is then queried for volume attribute information and the following fields are all verified: file system attributes, maximum component name length, file system name length and file system name.


TD-21.6 FileInformation File System Test Group

The tests in this group include:

Click to show or hide information. AllInformationTest

The basic information, standard information, internal information, EA information, position information and name information can all be queried on a file at the same time. A file handle or directory handle is opened and the file is queried for all the information: creation time, last access time, last write time, change time, file attributes, allocation size, end of file pointer, number of links, delete pending flag, directory flag, index number, EA size, long filename, long filename length and current byte offset. All these values are compared to the known values obtained at creation time of the file or directory. If all match then the test has passed.

Click to show or hide information. AllocationInformationTest

The allocation size of a file can be set to truncate or extend the file. The allocation size is the amount of space the file system reserves for use by the file. This allocation size can be initialized at create time and later changed. It is changed automatically by writing beyond the end of file. The file size is different from the allocation size. The allocation size must fall on an allocation unit boundary while the file size can be any value at or before the currently allocated size. A test file is opened with a non zero allocation size. A query is performed to make sure that the allocation size is equal to what was set at create time of the file. Then the allocation size is reduced, this should truncate the file. A query is performed to make sure the allocation size did reduce. If this passes then the allocation size is even further reduced and query is performed again to make sure the size did decrease. A separate query is performed specifically on directory files to verify the change in allocation size. Next the allocation size is increased on the file and a query is performed to verify this increase. If all these changes in allocation size are verified the test has passed.

Click to show or hide information. ZeroAllocationInformationTest

A test file that has an allocation size of zero is opened. This file is then written to with 1000 bytes of data. A query is then performed to obtain the allocation size, it is expected to be a multiple of 512. If this passes, then a second query is done on the file as a directory file. This type of query should return a zero for the allocation size because the allocation size will not be updated on the directory file until the handle to the directory file is closed. If this passes the file handle is closed and a second query on the directory file is done to make sure the allocation size is a multiple of 512.

Click to show or hide information. CompressionInformationTest

The compression information for the file can be queried if the file system supports file compression. This returns information on the compression used if the file is compressed. Two test files are opened (one that is compressed and one that is not). A query is performed on both files and a check is performed to make sure that the uncompressed file size is greater than the compressed file size.

Click to show or hide information. DispositionInformationTest

Files are deleted on close. This deletion takes place when a flag is set in the file object. The file can also be flagged to be deleted at create time. A file handle is opened on a test file and the deletion flag is then set on the file. A query is performed to make sure the Delete Pending flag is set, then the file handle is closed. Next an attempt is made to open the deleted file; the failure of this open will verify that the file was deleted.

Click to show or hide information. EndOfFileInformationTest

The end of file position can be changed. This marks the actual end of file for data reading and writing purposes. The end of file position is less than or equal to the allocation size since the granularity of allocation on the file system is usually a power of 2 sectors. First the original size on file create is checked and then the end is moved towards the beginning of the file. The allocation size is checked to make sure it reduced to the nearest possible size. Next the end of file pointer is moved toward the end of the file. The allocation size is checked to see if it is enlarged.

Click to show or hide information. LinkInformationTest

Hard links can be created to an open file. This functionality is tested here. When the file is opened with the linked filename, the file should look identical to the original file with respect to data and queried information. A file with test data is opened and a link to the file is created. The file is then closed. The file is opened again, this time using the link. The data in the file is read and compared against the original data in the file, which should be the same. Next all the attributes are compared against the original attributes of the file to see if they are the same. The following data is checked: File Attributes, Creation Time, Last Access Time, Last Write Time, Change Time, Allocation Size, End Of File pointer, Number of Links, Delete Pending flag, Directory flag, Index number, EA size and Current Byte offset.

Click to show or hide information. SimpleRenameInformationTest

A file/directory can be renamed only within a volume. The root directory cannot be renamed. The rename target may specify either a file or a directory. A handle to a file is opened and it is renamed to a non-existing filename. The same is done with a directory. Next a rename is attempted on a root directory; this operation should fail with an invalid parameter error. Next a rename is attempted on a file between two volumes; this should also fail with an invalid parameter error.

Click to show or hide information. ConflictingRenameInformationTest

A test file is opened and an attempt is made to rename the file name to an existing file name. If the file attribute, Replace If Exists, is set, then a file can be renamed to an existing filename, otherwise an error will be recorded. When the test file or directory is renamed to an existing file name (Replace If Exists not set) an invalid parameter error occurs. This rename is attempted again but with the Replace If Exists flag set, this operation should succeed. Next, a second test file is opened twice (two handles are opened to the same file). A file rename is attempted on both handles, and both attempts should return an access denied error.

Click to show or hide information. AlternateNameInformationTest

The long name can be used to obtain the 8.3 representation with a query call. A file with a filename length of over 15 characters is opened and data is written to the file. A query is performed on the file to obtain its 8.3 representation. The handle to the file is then closed. The file is reopened using the 8.3 alternate name from the query; the data from the file is read and verified to insure that it is correct.

Click to show or hide information. FileNetworkOpenInformationTest

Network open information is another file information class that can be queried. This information includes creation time, last access time, last write time, change time, allocation size and end of file. A test file is opened and the following information is queried and verified: creation time, last access time, last write time, change time, allocation size and end of file.

Click to show or hide information. StreamInformationTest

A file can be queried for the file information. This information includes the stream name, size in bytes, and allocated size in bytes. A primary data stream is written with data. Alternate data streams are created with unique and varying amounts of data. The stream names are verified to be of the format ".%stream name%:DATA$. The stream sizes and allocation sizes are verified. The allocation size should have a granularity of 8 bytes.

Click to show or hide information. StreamStandardInformationTest

The standard information, allocation size and end of file pointer should be unique for each stream. The number of links and delete pending information should be common for all streams in the file. A test file that contains multiple streams is opened and the following information is queried and verified: allocation size, end of file, number of links, delete pending flag and directory flag value. A single file handle is used to mark the file for deletion. A different file handle is queried and the Delete Pending flag is verified to be set. A link is made to an open stream handle, and all the open handles queried to check the Number of Links value.

Click to show or hide information. BasicInformationTest

Basic information can be queried or set. This information includes the file attributes, which are initialized at create time. It also includes all the timestamps on the file including creation and various access times. This test involves opening up a file or directory handle and querying the creation time, last access time, last write time, change time and file attributes. These values are compared to the known values that were obtained at creation time. If all values are correct, then these values are changed. The file is queried again to make sure that the changes have been made.

Click to show or hide information. StandardInformationTest

Standard information on a file can be queried. The allocation size is the amount of space allocated for the file. The end of file pointer points to the end of the file and must be contained in the current allocation size. This marks the actual end of the file. The number of links indicates the number of hard links on the file. The delete pending flag indicates the file is marked for deletion and the deletion occurs when all handles to the file are closed. The directory value indicates if it is a directory. This test opens up a file or directory handle and queries the standard information on the file: Allocation Size, End Of File pointer, Number of Links, Delete Pending and the Directory value. All of these values are then compared to the known values.

Click to show or hide information. InternalInformationTest

The index of the file is a unique and persistent 64-bit integer. The index value of the file can be used to open up a file (may not be supported by all file systems). A file handle or directory handle is opened and the Internal information of the file is queried (the query returns the Index Number of the file). The file handle is then closed. The file is again opened and the Index Number is queried. Verification is done to make sure that the two Index Numbers match. If they match, the test is passed.

Click to show or hide information. EaInformationTest

The extended attribute size on the file can be queried. This is the size of the extended attribute information stored along with the file. A file handle is opened and the EA information is then queried. The EA size is compared to the known EA size; if they match then the test is passed.

Click to show or hide information. NameInformationTest

The name of the file can be queried. This is the long filename and the length of the filename. A file handle or directory handle is opened and a query is performed to obtain the long filename and the filename length. The long filename is compared to the filename that was used to open the handle; if they match the test is passed. The test is repeated with a small buffer to query the filename data; this is done to see if a buffer overflow error is returned by the query.


TD-21.7 EaInformation File System Test Group

The tests in this group include:

Click to show or hide information. FullEaInformationTest

All of the Extended Attribute information for a file can be accessed at once. The test file used for this test has three Extended Attributes each with 4 bytes of data. This file is opened with access privilege that permits its EA data to be read. A query is performed to read out all the EA entries associated with this file at once. The data and labels that are returned are verified.

Click to show or hide information. ListEaInformationTest

The Extended Attribute information can be selectively queried based on a list of Extended Attribute names. The test file used for this test has three Extended Attributes each with 4 bytes of data. This file is opened with access privilege that permits its EA data to be read. A query list with a label to just the second entry is created and a query is performed on just the second EA entry. The data associated with the second EA entry is verified. Then the query list with a label to just the third entry is created and a query is performed on just the third EA entry. The data associated with the third EA entry is verified. The same is done for the first entry.

Click to show or hide information. IndexEaInformationTest

The Extended Attribute information can be selectively queried based on an index value. The test file used for this test has three Extended Attributes each with 4 bytes of data. The file is opened with access privilege that permits its EA data to be read. A query is performed specifically indexing just the second EA entry. The data and label associated with the second entry is verified. Then a query is performed specifically indexing the third EA entry. The data and label for the third entry is verified. The same is performed to query the first EA entry.

Click to show or hide information. CreateEaInformationTest

The Extended Attribute information for a file can be specified at creation time. The test file used for this test has one Extended Attribute with 4 bytes of data associated with it. This file is opened with access privilege that permits its EA data to be read. The file is then queried for its EA data. If the query is successful then the file has EA data associated with it and the CreateEaInformationTest has passed.

Click to show or hide information. SetEaInformationTest

The Extended Attribute information for a file can be set after creation time. The first part of the test uses a file that has no Extended Attribute associated with it. This file is opened with access privilege that permits its EA data to be written and read. First the file is queried to check the size of the EA, since this file has no EA data the EA size is expected to be zero. Next there are two Extended Attributes each with 4 bytes of data set for the file. The file is queried one entry at a time, to verify the Extended Attributes that were just set (EA name and EA data). The first test file is then closed. The second part of the test uses a file that has one Extended Attribute with 4 bytes of data associated with it. The file is opened with access privilege that permits its EA data to be written and read. The second file is queried to check the EA size matches the size of one Extended Attribute with 4 bytes of data. Next the existing Extended Attribute is replaced with new data values but the label will still be the same. The file again is queried to check if the label matches that which is expected and to verify the data value change. Last the file is queried again to check that the EA size is that of an Extended Attribute with 4 bytes of data associated with it.

Click to show or hide information. SingleEaEntryTest

The Extended Attribute information for a file can be read back one entry at a time. The test file used for this test has three Extended Attributes each with 4 bytes of data associated with it. This file is opened with access privilege that permits its EA data to be read. A query is performed from the start of the EA entries block to return just the first entry. The data and label associated with this entry are then verified. This is done two more times to verify the second and third EA entries, but this time the scan is not done from the start of the EA entries block, it is done from after the last EA entry that was queried.


TD-21.8 DirectoryInformation File System Test Group

The tests in this group include:

Click to show or hide information. FullDirectoryInformationTest

The access times, end of file pointer, Ea size and allocation size for the files in a directory can be queried. This test is run four times on a directory with four files that have different allocation sizes. The file is opened and then some data is written to the file, this write should update the last access time, last write time and change time of the file after a close. The file is then reopened and queried for the times, allocation size, ea size and end of file pointer; these values are then checked.

Click to show or hide information. FileNameDirectoryInformationTest

The file names and file name length parameters can be queried of a specific directory. Four different files are opened and the filenames and filename lengths are checked for each of these files. If the file names and file name lengths match then the test has passed.

Click to show or hide information. FileDirectoryInformationTest

The access times, end of file pointer and allocation size for the files in a directory can be queried. This test is run four times on a directory with four files that have different allocation sizes. The file is opened and then data is written that should update the last access time, last write time and change time of the file after a close. The file is then reopened and queried for the times, allocation size and end of file pointer to confirm that the values have changed.

Click to show or hide information. BothDirectoryInformationTest

The access times, end of file pointer and allocation size for the files in a directory can be queried. This test is run four times on a directory with four files that have different allocation sizes. The file is opened and then data is written that should update the last access time, last write time and change time of the file after a close. The file is then reopened and queried for the times, allocation size and end of file pointer to confirm that the values have changed.


TD-21.9 FileLocking File System Test Group

Click to show or hide information. LockSharedExTest

This tests the use of exclusive and shared byte range locking in multiple processes. Process A obtains some exclusive and shared locks on a file. The correct read and write accesses are tested in these locked regions. Process B then attempts to obtain locks on these same regions. These operations are checked for failure. Process B then attempts to access the areas locked by Process A. Correct access is verified.

Click to show or hide information. UnlockRangeTest

Process A is used to obtain some exclusive and shared byte range locks on a file. Process A then verifies proper access to the locked regions. Some of these locked regions are then unlocked. Process B attempts access to the still locked and recently unlocked regions. Correct access is verified. Process B then attempts locks on the areas previously locked by Process A. These operations are checked for success.

Click to show or hide information. LockOverlapTest

Several exclusive and shared locked ranges are obtained on a file. Overlapping exclusive locks are attempts on locked exclusive regions. Failure is verified for these locking attempts. Shared locks are then attempted on the exclusive and shared locked regions. Success is verified for these attempts.

Click to show or hide information. LockRangeTest

Process A locks a whole file with exclusive and shared locks. Proper access is verified when the entire file is locked. Process A then locks a range larger than the current file. Process B attempts access to the area beyond this locked region. This should succeed. Process B then attempts access to the area locked by Process A when the file was smaller than that area. The byte range lock held by A should be verified on this range in terms of obtaining a lock on the same region.

Click to show or hide information. LockFailImmediateTest

The file locking API can be set to fail immediate if a lock is currently held on the region of the file. This is tested with a synchronous file handle. The blocking of the thread by the alternate process is tested until the lock is release. The fail immediately will not block with a synchronous handle.

Click to show or hide information. LockOverlappedTest

The file locking API can be used with events for synchronization. The APIs are used between two processes. Process A obtains a lock on a byte range. Process B then attempts to obtain a lock and waits on the event handle. This wait should not timeout, but the event should become signaled when the lock is released by Process A.

Click to show or hide information. UnlockAllTest

Several locks are obtained on a file handle. This handle is then closed. The same locks are attempted with another file handle that is obtained before the first file handle is closed. The locks are again attempted and should be granted since they were all unlocked with the handle close.

Click to show or hide information. UnlockRangeOnCloseTest

  • Start Process A.
  • First get 2 handles.
  • Obtain some locks on handle 1.
  • Try and fail to obtain same locks on handle 2.
  • Obtain some other locks on handle 2.
  • Start of thread
  • Thread will close handle 1 at t=1 seconds.
  • Thread will close handle 2 at t=2 seconds.
  • Start Process B.
  • Try and fail to obtain all locks on handle 1 and 2.
  • Wait till t=1 second and obtain locks that were on handle 1 only.
  • Wait till t=2 second and obtain locks that were on handle 2.

Click to show or hide information. LockKeyTest

  • Process A gets some shared and exclusive locks.
  • Process A attempts to access this data without key and fails.
  • Process A attempts to access WITH key and succeeds.
  • Process B attempts to access this data without key and fails.
  • Process B attempts to access WITH key and succeeds.


TD-21.10 OpLocks File System Test Group

The tests in this group include:

Click to show or hide information. BatchOplocksTest

The batch oplock is operationally equivalent to a level 1 oplock (i.e. it is exclusive). The difference is that while a Level I oplock is always backed by a real user handle, a batch oplock may be held by a proxy agent (such as Srv.sys) to indicate that it is keeping a file open in the hope that a client will need it again; but should the file system like it closed, it will close the file.

  1. C opens a test file for reading.
  2. C requests a Batch Oplock on the file using the FSCTL_REQUEST_BATCH_OPLOCK file control.
  3. The file should be read by C, this should succeed.
  4. D opens the test file for reading and writing, this should block since there will be a break pending.
  5. The IRP from step 2 should complete indicating that the Batch Oplock has been broken. The Information should be FILE_OPLOCK_BROKEN_TO_LEVEL_2.
  6. C sends the FSCTL_OPLOCK_BREAK_ACKNOWLEDGE control to the file system to acknowledge the break.

Click to show or hide information. BreakNotifyTest

Additional IRPs can be queued to wait for a break to complete. These IRPs will wait for the full break to occur. That involves the completion of the original break IRP and the acknowledge cycle.

  1. C opens a test file for reading and writing.
  2. C requests a Level I oplock on the file using the FSCTL_REQUEST_OPLOCK_LEVEL_I file control.
  3. The file should be written to and read from by C, this should succeed
  4. D opens the test file for reading and writing, this should block. This is because the client holding a Level I oplock must be notified of break and the client's buffers flushed.
  5. The IRP from step 2 should complete.
  6. The FSCTL_OPLOCK_BREAK_NOTIFY control should be sent. This IRP should be queued since there is a break in progress.
  7. C issues the FSCTL_OPLOCK_BREAK_ACKNOWLEDGE control. This will acknowledge the break to a level II lock.
  8. The IRP from step 6 should now complete indicating that there is now no break in progress.
  9. C and D close the file.

Click to show or hide information. FilterOplockTest

There is currently no description for this test.

Click to show or hide information. CompleteImmediatelyTest

Normally an open to an oplocked file will block until the file's oplock is broken. There is a file option that can be specified at open time called FILE_COMPLETE_IF_OPLOCKED that changes the blocking behavior (this was added to solve several deadlock conditions within the Srv.sys). If this option is specified and the open is otherwise successful, the final status will be STATUS_OPLOCK_BREAK_IN_PROGRESS, which is an NTSUCCESS code. If the open fails for any reason, the final status will be the error code. In either case, the Information value will be FILE_OPLOCK_BREAK_UNDERWAY, which tells the caller that an oplock break has been initiated.

  1. A opens a file and requests a Level I oplock.
  2. B opens the same file with the FILE_COMPLETE_IF_OPLOCKED option set.
  3. The call should complete normally with FILE_OPLOCK_BREAK_UNDERWAY in the Information field regardless of the final Status of the create operation.
  4. The Oplock IRP from Step 1 should complete.
  5. The same open should be attempted without the option.
  6. The call should then block until the oplock break on the file is acknowledged.

Click to show or hide information. OplockReadBreakItoIITest

This should be called OplockWriteBreakIItoNone Test. The only major IRP type that will cause a break is IRP_MJ_WRITE. That is why this test was modified to test the breaking through the "data access FSCTL.

  1. C opens a test file for reading and writing.
  2. D opens the same test file for reading and writing.
  3. C requests a Level II oplock on the file with the FSCTL_REQUEST_OPLOCK_LEVEL_II file control.
  4. The file should be read by C, this should succeed.
  5. D attempts to write to the file issuing the IRP_MJ_WRITE request. This will be blocked because the client holding a Level II oplock must be notified of break to None and the client's buffers flushed.
  6. The IRP from step 3 should complete.

Click to show or hide information. OplockLevel1Test

This tests that Level I oplocks are exclusive.

  1. C opens a test file for reading and writing.
  2. D opens the same test file for reading and writing.
  3. C requests and receives a Level I oplock on the file with the FSCTL_REQUEST_OPLOCK_LEVEL_I file control. This should fail with STATUS_OPLOCK_NOT_GRANTED since there is another handle outstanding.
  4. C and D close the file.

Click to show or hide information. OplockSetInfoBreakTest

The IRP_MJ_SET_INFORMATION request will cause a break of a Level I or Level II lock to none. This is because when issued by a client, there are changes to critical information that logically invalidate the oplock. These include the following types of Set Information:

FileEndOfFileInformation
FileAllocationInformation
FileRenameInformation
FileLinkInformation

The first two classes above will break any oplock to none, while the latter two will only break batch oplock to none. Note that the following test is for a single set operation. The following steps should take place 3 times, each time with a different information item being changed:

  1. C opens a test file for reading and writing.
  2. D opens the same test file for reading and writing.
  3. C requests a Level II oplock on the file with the FSCTL_REQUEST_OPLOCK_LEVEL2 file control.
  4. The file should be read from by C, this should succeed.
  5. D uses the NtSetInformationFile()to set the information file. This will be blocked because the client holding a Level II oplock must be notified of break to none.
  6. The IRP from step 3 should complete.
  7. The set information operation from step 5 should now become unblocked and complete successfully.
  8. C and D close their handles.

Click to show or hide information. LockOplockBreakTest

Oplocks held against an open file object must be broken before the byte range file locking can be completed. The file system performs this break synchronously (thread requesting lock is blocked until oplock notification cycle has been completed). This ability is tested with the following steps:

  1. Process C requests a Level II oplock on the file and receives back STATUS_PENDING indicating that the oplock has been granted.
  2. The file should read from by C, this should succeed.
  3. Process D attempts to lock a range of the file using NtLockFile(). This thread (of Process D) should block.
  4. The IRP obtained in step 1 should complete with FILE_OPLOCK_BROKEN_TO_NONE.
  5. The NtLockFile() call from step 3 should now complete.
  6. Process C should attempt writing to the locked range of bytes. This operation should fail since Process D now holds a byte range lock on the file.

Click to show or hide information. OplockBreakItoIITest

Only a single level I oplock can be held on a file. When the file is opened a second time for reading or writing, the level I oplock will be broken to a level II. The original owner of the file will be able to keep the level II lock until the file is written to. The file can be read from with cached reads.

  1. C opens a synchronous handle to the test file for reading and writing.
  2. C requests a Level I oplock on the file. This should return with STATUS_OPLOCK_NOT_GRANTED.
  3. C opens an asynchronous handle to the test file for reading and writing.
  4. C requests a Level I oplock on the file and receives back STATUS_PENDING indicating that the oplock has been granted. An event handle is used to signal an oplock break.
  5. The file should be written to and read from by C, this should succeed. The oplock should not break.
  6. D opens the test file for reading and writing, this should block. This is because the client holding a Level I oplock must be notified of break and the client’s buffers flushed.
  7. The IRP from step 4 should complete and the event signaled in process C.
  8. C issues the FSCTL_OPLOCK_BREAK_ACKNOWLEDGE control. This will acknowledge the break to a level II lock. This FSCTL returns STATUS_PENDING.
  9. The blocked open from step 6 should now become unblocked.
  10. C should be able to read from the test file without the level II oplock breaking.
  11. D should also be able to read from the file without the level II oplock breaking.
  12. C and D close the file.

Click to show or hide information. OplockIIWriteBreakingTest

If a level II oplock is held by a file, and the file is written to, the oplock will be broken. This can only occur by a file that has opened the file for read and write access and originally obtained a level II oplock on the file. It could not occur with any but the first since subsequent opens with the write ability will cause the oplock to break on open. We just test that a write in another process will break the level II oplock, and a subsequent write operation is successful.

  1. C opens a test file for reading.
  2. C requests a Level II oplock on the file.
  3. The file should be read from by C, this should succeed.
  4. D opens the test file for reading and writing. This breaks the level II oplock.
  5. D then attempts to write to the file. This should be successful.
  6. Both files handles are closed.

Click to show or hide information. OplockBreakIItoNoneTest

If a file is written to when a level II oplock is maintained on the file, the level II oplock is broken to none. The write IRP is queued until the lock is completely broken through the notify-response protocol.

  1. C opens an asynchronous handle to a test file for reading and writing.
  2. C requests a Level I oplock on the file and receives STATUS_PENDING
  3. The file should be written to and read from by C, this should succeed.
  4. D opens the test file for reading only, this should block. This is because the client holding a Level I oplock must be notified of break and the client's buffers flushed.
  5. The IRP from step 2 should complete with FILE_OPLOCK_BROKEN_TO_LEVEL_2.
  6. C issues the FSCTL_OPLOCK_BREAK_ACKNOWLEDGE control. This will acknowledge the break to a level II lock.
  7. The blocked open from step 4 should now become unblocked.
  8. D should also be able to read from the file without the level II oplock breaking. These will not be cached reads since D does not hold an Oplock.
  9. C should be able to read from the test file without the level II oplock breaking.
  10. D shoud try to write to the file. This should break the level II oplock held on the file by C with FILE_OPLOCK_BROKEN_TO_NONE.
  11. The IRP from step 6 should complete.
  12. C and D close the file.

Click to show or hide information. OplockBreakIandIIOnCloseTest

When a file is closed Level I or Level II oplocks are broken. This is tested by opening a file with a level I and then level II oplock and closing the file. The breaking of the locks is verified and the correct protocol state is verified by attempting subsequent access. Normally, the break would require a response before the subsequent access would be allowed.

  1. C opens a test file for reading and writing.
  2. C requests a Level I oplock on the file.
  3. The file should be written to and read from by C, this should succeed.
  4. C closes the file.
  5. The IRP from step 2 should complete indicating the Level I oplock is broken. The Information will show FILE_OPLOCK_BROKEN_TO_NONE.
  6. D opens the same test file for reading and writing. This should not block since the oplock has been deleted from the system.
  7. D requests and receives a Level II oplock on the file.
  8. The file should be read from by D. This should succeed.
  9. D closes the file.
  10. The IRP from step 7 should complete indicating the Level II oplock is broken. The Information will show FILE_OPLOCK_BROKEN_TO_NONE.

Click to show or hide information. OplockRequestIITest

Multiple files can maintain level II oplocks on a file. This allows efficient, cached access by multiple readers.

  1. C opens a test file for reading and writing.
  2. C requests a Level II oplock on the file using the FSCTL_REQUEST_OPLOCK_LEVEL_II control operation.
  3. The file should be read from by C, this should succeed.
  4. D opens a test file for reading and writing.
  5. D requests a Level II oplock on the file using the FSCTL_REQUEST_OPLOCK_LEVEL_II control operation.
  6. C should be able to do cached reads from the file.
  7. D should be able to do cached reads from the file.
  8. C and D close the file.

Click to show or hide information. OplockIIOpenBreakingTest

A level II oplock can be broken with a subsequent open. If the open is for read and write access, the level II oplock will be broken to none.

  1. C opens a test file for reading and writing.
  2. C requests a Level II oplock on the file.
  3. The file should be read from by C, this should succeed.
  4. D opens the test file for reading and writing, this should block since the file has an open oplock.
  5. The level II oplock obtained in step 2 will be broken.
  6. The blocked open from step 4 should now become unblocked.
  7. C and D close the file.


TD-21.11 ChangeNotification File System Test Group

There are many combinations of FILTERS, CAUSES, and ACTIONS. The notification events table is used for a coverage test of all expected notification behavior. A file handle is opened in the test directory and a thread is created that will write to the file. Meanwhile in the main thread the write is waited upon for 4 seconds, if the write does not occur a timeout will happen. When the write does occur the event is triggered and the test will make sure the correct ACTION was reported. The following tests make up this group:

Click to show or hide information. NotificationCleanupAttribTest

This tests the original DACL is reset to allow the test file to be deleted during cleanup. All notification events should complete.

Click to show or hide information. NotificationCleanupFileSizeTest

This tests the original DACL is reset to allow the test file to be file size returned during cleanup. All notification events should complete.

Click to show or hide information. NotificationCloseTest

When an open file handle is closed, all pending notifications should be completed. A file handle is opened in the test directory and a thread is created that will close the file handle. Meanwhile in the main thread the close of the file handle is waited upon for 4 seconds, if the file handle is not closed in the time allotted a timeout will happen. All notification events should complete.

Click to show or hide information. NotificationDeleteTest

When a directory is actually deleted, or marked for deletion, all pending notifications on changes in that directory must be completed. A file handle is opened in the test directory and a thread is created that will mark the file for deletion and then close the file handle (this close should then delete the file). Meanwhile in the main thread the delete of the file is waited upon for 4 seconds, if the delete does not occur a timeout will happen. When the delete does occur the event is triggered and the test will make sure the correct ACTION was reported. This test is then repeated, but instead of deleting the file in a separate thread, it is done in the main thread. When the notification is waited upon a STATUS DELETE PENDING should come back.

Click to show or hide information. NotificationFilenameTest

Any changes in the filenames in a directory or subtree can be used to trigger a notification event. This includes renames, creations and deletions. First a file handle is opened in the test directory and a thread is created that will rename the file. Meanwhile in the main thread, the renaming of the file is waited upon for 4 seconds, if the notification doesn’t happen an error has occurred. When the rename does occur the event is triggered and the test will make sure the correct ACTION was reported. This test is repeated two more times, once with a file that is created in a separate thread; and then with a file that is deleted in a separate thread.

Click to show or hide information. NotificationFlushWriteTest

This tests the flushing of the cache before the volume is locked.

Click to show or hide information. NotificationNonDirectoryTest

The only way a notification can occur is if a directory handle is supplied to the notification change function. A call made with any other function should return an invalid parameter error. First a file handle is opened in the test directory and a thread is created that will write to the file. Meanwhile in the main thread the write of the file is waited upon for 4 seconds, if the notification doesn’t happen an error has occurred. This test is repeated but this time a file handle is supplied to the notification function, this should return back with an invalid parameter error.

Click to show or hide information. NotificationSecurityTest

Any changes in the security descriptors of a file in a directory or subtree can be used to trigger a notification event. A file handle is opened in the test directory and a thread is created that will change the security descriptors of the file. Meanwhile in the main thread, the changing of the security descriptors of the file is waited upon for 4 seconds, if the notification doesn’t happen an error has occurred. When the security descriptor change does occur the event is triggered and the test will make sure the correct ACTION was reported.


TD-21.12 DeviceControl File System Test

DeviceIOControlTest

The create file function is used to open a file system related device object such as a partition or floppy device. Device I/O commands are passed through the file system to the device driver directly. The "\DosDevices\?: device is opened where ?: is a DOS drive letter for the volume under test. This test will issue a Device I/O Control command. A successful completion of the command and inspection of the returned information for accuracy will verify the path through the file system driver to the underlying device driver. This test is repeated using APC completion to help detect file system bugs in request completion.


TD-21.13 FileSystemControlVolume File System Test Group

The tests in this group include:

Click to show or hide information. ControlDismountVolumeTest

Dismounting a volume disconnects a volume object from its associated file system driver. This can be used when converting volumes, as in the FAT to NTFS converter. The volume starts out as FAT, is dismounted, formatted for NTFS, and then remounted. When it is remounted it will attach to the NTFS driver. The test for dismounting involves being able to see a mount request to the volume. That is necessary because the first reference to the volume after it is dismounted will usually mount the volume back up. The mounting can be observed by the File System Control. Note that the volume can only be dismounted if it is locked. A test volume handle is opened and a dismount is issued to it. Next a file open operation is attempted on a file on the test volume. This should fail with an access denied error, but this open attempt will remount the volume. So next a dismount is issued again to the test volume and this should succeed.

Click to show or hide information. ControlLockVolumeTest

The File System I/O Control interface can be used to lock the volume. The control file function call gets a handle to an opened volume as a parameter. There are two things that need to be tested. First, a volume can only be locked if there are no other open handles on the volume. This test will have to be performed on a non-system containing volume. First a volume is locked then unlocked using the control file function.

Next the open volume handle is closed and a file handle is opened for a file on the test volume. An open is attempted on the test volume, but this should fail because there is an open file handle, if this succeeds the volume handle and file handles are closed.

Next the volume handle is opened again and a lock is issued to the volume.

Next files and directory opens are attempted on the locked volume. These attempts should fail with access denied errors. Next files and directories are opened as a relative handle, these attempts should also fail with access denied errors. The next thing that is test is the flushing of the cache before the volume is locked.

This is done by getting the volume statistics (specifically the read/write counters). Then opening up a couple of files on the test volume and doing read and write operations on those files. After the read/write operations are performed the volume statistics are again checked to see if they were updated. In the next part of the test a lock is issued to an already locked volume; this attempt should fail with an access denied error.

The volume is issued an unlock now and then the lock is issued again. This should return a success.

Click to show or hide information. ControlUnlockVolumeTest

The File System Control checks that the open volume handle is closed and a file handle is opened for a file on the test volume. An open is attempted on the test volume, but this should fail because there is an open file handle, if this succeeds the volume handle and file handles are closed. See steps in ControlLockVolumeTest

Click to show or hide information. VolumeMountedTest

The File System Control checks to see if a volume is mounted. This can be used in conjunction with the dismount control. First the test volume handle is opened and a dismount is issued to it. Next the File System Control to check if the volume is mounted is issued, for NTFS this should come back with a success; but on FAT volumes this will return the wrong volume error.

Click to show or hide information. MountedDirtyTest

This File System Control permanently marks a volume as permanently dirty. This is done when there has been a corruption detected in the meta data. First the test volume is opened and the File System Control is issued that will mark the volume dirty. This test is not complete until a reboot is performed and the Chkdsk program gets initiated.

Click to show or hide information. InvalidateVolumesTest

The File System control that invalidates volumes will search for all the volumes mounted on the same real device and marks them all bad. This prevents their further use in the system, as the only operations that can be done on such handles is cleanup and close. First two test files are opened on the test volume. Next the test volume itself is opened and an invalidate volumes control is issued to it. A read is performed on both test files and these attempts should return with the error invalid handle. Next the file handles are closed and then reopened again. The reads are attempted and this time they should succeed.

Click to show or hide information. MountVerifyVolumesTest

Mounting is tested implicitly by many of the tests and the test groups. In this test multiple files are opened on a removable media volume. The removable media is replaced with new media. The error wrong volume will be returned when the handles to the opened files are used to access the files. The original removable media has some files modified with new file sizes. A success will be returned when the handles to the opened files are used to access untouched files. The error file invalid will be returned when the handles to the files, which had modified file sizes, are used to access the files.

Click to show or hide information. ControlLockVolumeFlushTest

Tests the flushing of the cache before the volume is locked. Data is written to the file. Statistics on the volume are obtained. The number of bytes written to the block device, the end of file pointer, and the last write time should be updated from the flush.


TD-21.14 FileSystemControlGeneral File System Test Group

The tests in this group include:

Click to show or hide information. QueryRetrievalPointersTest

This is only used when a new page file is created. The retrieval pointers are queried from the file system for the file so that they can be used later in writing the crash dump to the paging file. This test has not been implemented.

Click to show or hide information. GetRetrievalPointersTest

The retrieval pointers consist of a list of extents. An extent is a VCN to LCN mapping. This test first creates a file and writes data to the file. Next the retrieval pointers are obtained by using FSCTL_GET_RETRIEVAL_POINTERS. Additional data is appended to the end of the file. The retrieval pointers are again obtained using the FSCTL. The additional VCN to LCN mapping (for the added clusters) is then observed.

Click to show or hide information. SetCompressionTest

The File System Control can be used to compress an individual file on the volume if the File System supports this feature. First a query is performed on the file system to see if it supports file compression. If the file system supports compression, a test file is opened and a checksum is performed on an uncompressed file. Next a File System Control is issued to the uncompressed file handle to compress it. The file size is checked to make sure it is less than the file size of the uncompressed file. Next the file handle is closed then reopened again. Now the File System Control to compress is issued again, this should uncompress the file. The file size is checked to make sure that it is the same as it was prior to the compression. The checksum is performed and the result is compared to the checksum of the file prior to compression, these values should be equal.

Click to show or hide information. GetStatisticsTest

The File System Control can be used to return the file system performance counters for the volume referred to. This test is performed by opening up a volume handle then issuing the file system control that will get the volume statistics. The volume handle is then closed and two test files are opened on the volume. After a few read and write operations are performed on these test files, the file handles are then closed. The volume is then opened again and the statistics are retrieved. The read and write counters are then checked to see that each counter incremented by known increments.

Click to show or hide information. PathNameValidTest

Note that this test is only supported on Fat Compatible Volumes. This File System Control checks a pathname for valid characters, leading backslashes, and for wildcards. It passes the string to the file system to check. This is entirely dependent on the syntax of the file system path names. A volume handle is opened and two test pathnames are checked. The first pathname is a valid pathname and the second pathname checked is an invalid pathname.

Click to show or hide information. GetVolumeBitmapTest

The volume bitmap is a sequence of bytes that indicate a mapping of used and unused clusters. Each cluster is mapped to a single bit in this bitmap. This test exercises the FSCTL and does a simple test of the bitmap. The volume is opened and the bitmap is obtained. The number of allocated and unallocated clusters is counted. Next a file is opened on the volume and a significant amount of data (1Mbyte) is written to the file. The bitmap is again obtained. The allocated clusters count should increase by the amount necessary for the new file.

Click to show or hide information. MoveFileTest

The File System Control move file information class will move the logical clusters used by a file to new logical clusters on the volume. A file is created and written with a known data pattern. The initial retrieval pointers are queried using FSCTL_GET_RETRIEVAL_POINTERS. Next, the file’s clusters are moved using FSCTL_MOVE_FILE. The new retrieval pointers are queried. The expected change in the retrieval pointers is verified. The data is read from the file and checked for consistency.

Click to show or hide information. AllowExtendedDASDTest

The File System Control, allow extended DASD I/O, specifies whether a DASD handle can be used to read/write beyond the end of the volume. A test volume is opened and a read is performed starting the very end of the volume. This read is expected to return back an end-of-file error. Next a file system control, allow extended DASD I/O is issued to the volume. A second read is performed and this time reading at the very end of the volume should return back with a success.


TD-21.15 ReadWrite File System Test Group

Test Kit: HCT 11, HCT 10

Note In the HCT kit, this test is called the SysCache test.

The tests in this group include:

Click to show or hide information. ReadWriteTest

This will test the reading from and writing to files managed by the file system. First a synchronous file handle is opened to the test file and a buffer full of known data is written to the test file. Next the data is read from the file and compared to the known data to see if it matches. If the data matches, the file pointer is reset to the beginning of the test file and the data is read again, this time the parameter FILE_USE_FILE_POINTER_POSITION is specified as an offset to the read function. The handle is then closed. The test file is once again opened with a synchronous file handle and the data is read and checked once again. The file handle is then closed. A synchronous file handle is once again opened to the test file. A buffer full of known data is written to the test file, with the FILE_WRITE_TO_END_OF_FILE offset being specified to the write function. This should append the data to the end of the test file. The file is read from and the data is checked. The file handle is then closed. Lastly, an asynchronous file handle is opened to the test file and data is read from the file. A query is performed to make sure that the file pointer position did not change. The test is complete.

Click to show or hide information. ReadWriteCoherencyTest

The system maintains cache coherency for open files. Two handles are opened for the test file used in this test, the first handle opens the file with caching disabled and the second handle opens the file with caching enabled. First some data is written out to the file using the non-caching handle, this data is read back and checked using the caching handle. Second some data is written out to the file using the caching handle, this data is read back and checked using the non-caching handle. The data checked for both should be consistent. This test is repeated for an asynchronous handle.

Click to show or hide information. WriteThroughTest

A file can be opened with write through caching. Read operations are cached as normal, but write operations will update the cache and write the changed data out to the storage device before they complete. First a test file is opened with write through caching enabled. A region of the file is read from to ensure that data is cached. The same region is written to and the volume read/write stats are checked to make sure they are updated. The region is read from again and the data is verified to make sure it has been updated. The test is repeated for an asynchronous handle.

Click to show or hide information. WriteThroughSyncTest

A file can be opened with write through caching. Read operations are cached as normal, but write operations will update the cache and write the changed data out to the storage device before they complete. First a test file is opened with write through caching enabled. A region of the file is read from to ensure that data is cached. The same region is written to and the volume read/write stats are checked to make sure they are updated. The region is read from again and the data is verified to make sure it has been updated.

Click to show or hide information. AppendDataTest

This tests the appending of data to an open file that is opened with the append data access flag set. A file is opened with the append data access flag set. Data is then appended to the file and the new end of file information and allocation size are checked to verify it has been updated in accordance with the append data. A read is performed on the file to check that the original data as well as the appended data is correct.

Click to show or hide information. AtomicSeekReadTest

The byte offset into the file can be specified to the read function. This byte offset performs the equivalent to a seek before the read. To test this a known data pattern is written to the test file. The data is then verified by reading the file at several different points by specifying the byte offset to the read function.

Click to show or hide information. ZeroLengthIOTest

If an IO operation is specified with a zero byte length, the file offset should not be updated. In addition zero length extending or beyond EOF should be success no-ops. A test file is opened and the current file offset is recorded. The read and write operations are performed with a new offset and a non-zero byte length. The new current file offset is recorded and checked to make sure it changed with respect to the read and write calls. The read and write operations are performed again with a new offset, but a 0 byte length. The new current file offset is recorded and made sure it didn’t change. This test is repeated with a file offset that is beyond the end of the test file.

Click to show or hide information. ReadWriteRangeTest

If a read operation is specified at an offset that is beyond the end of the file, the end of file error is returned. If the IO operation starts at a valid offset within the file, but the range causes a read/write off the end of the file, a success is returned along with the number of bytes transferred. Write operations will extend the file. A test file is opened and a read is performed at an offset that is beyond the current end of file. The end of file error is expected. Next a read is performed again but with a byte offset near the end of the file and a byte length for reading that extends off the end of the file. A success is expected and the actual number of bytes read is verified. This test is repeated for the write operation. When writing with an offset near the end of file and specifying a byte length that extends off the end of file, the end of file pointer will increase.

Click to show or hide information. EventAsyncIOTest

The read and write functions can perform asynchronous IO. If an operation cannot proceed immediately, the calls may return a status pending. A test file is opened with an asynchronous file handle. A read and write operation are performed on the test file and a status pending is expected to be returned. Both the read and write operations are waited upon for completion.

Click to show or hide information. APCSynchRWTest

The read and write functions can perform asynchronous IO using APC. If an operation cannot proceed immediately, for example a file object cannot be locked for exclusive access because another thread has the lock, the calls will return a status pending. If an APC is specified, that call will be made when the IO completes. A test file is opened with an asynchronous file handle. A write operation is performed on the test file, with an APC routine being specified for the write. The APC will set the event when the write completes. This completion is waited upon in the main thread. This test is repeated for the read operation.

Click to show or hide information. ZeroOnExtendTest

If a file is extended either by setting the end of file pointer through the NT set function or by writing beyond the end of the file, the contents of the file is zeroed for security purposes.

First a test file is opened with caching enabled. The NT set function is used to set the End of File pointer to a value larger than the current file. The data from the file is read back and verified, the data from the beginning of the file to the old end of file pointer should be original data, and the data from the old end of file pointer to the new end of file pointer should all be zero.

Next the write function is used to write data at an offset beyond the end of the file. The data is read back and verified, the data from the beginning to the old end of file pointer is all original data, the data from the old end of file pointer to the start of write offset should all be zero, and the data from the start of the write offset to the end of the file should all be the new data just written. This test is repeated for non-cached IO.


TD-21.16 SectionCaching File System Test Group

The tests in this group include:

Click to show or hide information. ExtendingWithUserMappingTest

A file can be extended when a user mapping exists. The new extended region should be initialized with 0's.

  1. A test file is opened, a user mapped section is created, and a view created.
  2. The file handle is closed.
  3. The test file is again opened with a call to NtCreateFile() with the FILE_WRITE_DATA and FILE_READ_DATA desired access specified.
  4. The file is extended with a Set Information File -> FileEndOfFileInformation call. The End Of File is specified to be some value larger than the current end of file.
  5. The Set Information File call should succeed.
  6. Another view is created on the extended region.
  7. The file contents are read. The extended region’s view should contain all 0s. The original region should have valid data.

Click to show or hide information. FlushBuffersTest

This tests involves the IRP_MJ_FLUSH_BUFFERS, IRP on a file object. A file is first created with the FILE_ATTRIBUTE_TEMPORARY flag set. Data is written to the file. Statistics on the volume are obtained. The open file handle is passed in a call to NtFlushBuffersFile. The statistics are again obtained. The number of bytes written to the block device, the end of file pointer, the last write time should be updated from the flush.

Click to show or hide information. FlushBuffersRootTest

This test involves the IRP_MJ_FLUSH_BUFFERS, IRP on a root directory object. Several files, in several subdirectories, are created with the FILE_ATTRIBUTE_TEMPORARY flag set. Data is written to the files. The root directory of the volume is opened. Statistics on the volume are obtained. The open root directory handle is passed in a call to NtFlushBuffersFile. The statistics are again obtained. The number of bytes written to the block device, the end of file pointer, the last write time should be updated on all files, from the flush.

Click to show or hide information. FlushBuffersVolumeTest

This test involves the IRP_MJ_FLUSH_BUFFERS, IRP on a volume object. Several files, in several subdirectories, are created with the FILE_ATTRIBUTE_TEMPORARY flag set. Data is written to the files. The volume is then directly opened. Statistics on the volume are obtained. The open volume handle is passed in a call to NtFlushBuffersFile. The statistics are again obtained. The number of bytes written to the block device, the end of file pointer, and last write time should be updated from the flush on all volumes.

Click to show or hide information. MaintainSectionMappingTest

A user mapped section is created with an open file handle. The file handle can be closed and the user mapped section maintained.

  1. A test file is opened.
  2. A user mapped section/mapped view are created with the open handle.
  3. The handle is closed.
  4. A view on the section is used to verify the file contents are still accessible.
  5. Another attempt is made at opening the test file with 0 share access (nothing is shared).
  6. Write some data to the opened test file.
  7. Verify the written data is present in the mapped section.
  8. The file is closed.

Click to show or hide information. DataImageCoherencyTest

The image section must be kept consistent with the data section. This test first creates a file containing an executable file. The file is then run, causing the executable image to be mapped into an image section. The cached data section should be flushed to disk before the image is faulted in.

  1. A known working executable is opened for reading.
  2. A new file is created with write access (filename = temp.exe).
  3. The contents of the first file are copied into the new file with NtReadFile() and NtWriteFile().
  4. The handles to the files are closed.
  5. The temp.exe executable file is run as in the WIN32 CreateProcess call.
  6. Proper execution of the file is verified, as well as the flush of dirty data to the disk.

Click to show or hide information. ExistingUserMappingTest

A file cannot be superseded or overwritten when a view on a user mapping exists.

  1. A test file is opened, a user mapped section is created, and a view mapped.
  2. The handle to the test file is closed.
  3. The test file is again opened with a call to NtCreateFile(). The FILE_OVERWRITE disposition is specified.
  4. The open should fail with STATUS_USER_MAPPED_FILE.
  5. The test file is again opened with a call to NtCreateFile(). The FILE_SUPERSEDE disposition is specified.
  6. The open should also fail with STATUS_USER_MAPPED_FILE.

Click to show or hide information. TruncateWithUserMappingTest

A file cannot be truncated when a user mapping exists.

  1. A test file is opened; a user mapped section is created, and a view is created.
  2. The handle to the test file is closed.
  3. The test file is again opened with a call to NtCreateFile() with the FILE_WRITE_DATA access right specified.
  4. The file is truncated with a Set Information File -> FileEndOfFileInformation call. The EndOfFile is specified to be some value smaller than the current end of file.
  5. The Set Information File call should return the error STATUS_USER_MAPPED_FILE.
  6. The test is repeated with Set Information File -> AllocationInformation. By reducing the allocation size on the file below the current end of file, the file is truncated.


TD-21.17 Security File System Test Group

The tests in this group include:

Click to show or hide information. SetOwnerSecurityTest

This test requires that the file system being tested is NTFS; and that a test user is created with Users rights. This test user is specified at the command line when running with the /u option. The password for this user must be the same as the user name (e.g. Username: JuiceGuy Password: JuiceGuy). The first thing that is done in this test is to start another process, as the test user. This process will create the test file used in this test and ownership will belong to the test user. Next the test file is opened by the current user (the user running the test). The user SID is changed so that the current user will take ownership of the file. The file is then queried for its Owner SID to verify that the current owner did take ownership of the file.

Click to show or hide information. SetDaclSecurityTest

If the file system supports security on a file and directory basis, the Object Manager will use the set security function to set the security descriptor on the file or directory. A test file is first opened and the security DACL is changed for the file to only allow read operations for the Administrator. The file is then queried for its Security DACL information; the results from this query are compared to what was set on the file. If both Security DACLs match, the original DACL is reset to allow the test file to be deleted during cleanup.

Click to show or hide information. SetGroupSecurityTest

This test requires that the file system being tested is NTFS; and that a test user is created with Users rights. The test file is first opened and the Security Group SID is changed so that the Administrators group has control of this file. The file is then queried for its Security Group SID and this is compared to the Group SID that it was set to.

Click to show or hide information. SetSaclSecurityTest

This test requires the file system being tested is NTFS. First the Security Privilege is enabled in order to access the SACL. A SACL list allows you to audit operations performed on a file. The test file is opened and the SACL list is set to audit all Read operations performed on the test file. Next the file is opened again and queried for its SACL information. This is compared to what the SACL was set to earlier (audit all Read operations). If both lists match the test is passed.

Click to show or hide information. AuditDelSecurityTest

This test requires the file system being tested is NTFS. First the Security Privilege is enabled in order to access the SACL. The test file is then opened and the SACL is set to audit the deletion of the file; the file is closed and the security changes are now enabled. The file is then opened and marked for deletion upon close. Once the file is closed the Event Log should log the deletion of the file. The file is closed and the Event Log is opened and a search is done through the Event Log for the deletion of the test file. If this event has taken place the test has passed.

Click to show or hide information. AuditPermSecurityTest

This test requires that the file system being tested is NTFS. First the Security Privilege is enabled in order to access the SACL. The test file is then opened and the SACL is set to audit the change of security permissions (the DACL), the file is closed and the security changes now are enabled. The file is then reopened and the DACL is changed; this change should cause the event to be logged in the Event Log. The Event Log is searched for this event, if it is there the test is passed and the original DACL information is reset.

Click to show or hide information. AuditOwnerSecurityTest

This test requires that the file system being tested is NTFS; and that a test user is created with Users rights. This test user is specified at the command line with the /u option. The password for this user must be the same as the user name (e.g. UserName: JuiceGuy Password: JuiceGuy). The first thing that is done in this test is to start another process, as the test user. This process will create the test file used in this test and ownership will belong to the test user. Next the Security Privilege is enabled in order to access the SACL. The test file is then opened and the SACL is set to audit the change of the owner of the test file; the file is then closed and the security changes are now enabled. The file is opened and the current user takes ownership of the file. This should set an even in the Event Log. The Event Log is searched for this event, and if present, the test is passed.

Click to show or hide information. DirectoryTraverseTest

The default installation of NT 4.0 enables Bypass Traverse Checking for all users on the system. This allows a user to access a directory (which maintains a legal ACL for the user) that is a subdirectory under a path that contains directories that do not maintain a legal ACL for the user. This test requires that the file system being tested is NTFS; and that a test user is created with Users rights. There are 3 directories in this test (the 2nd directory is a subdirectory of the first and the 3rd directory is a subdirectory of the 2nd). The 1st directory is opened and the DACL is changed so that only administrators can perform operation on it; the same is done with the 2nd. Next a second thread is initiated that will log in the test user and try to create a file in the 1st directory; this attempt should fail. The same is repeated with the 2nd directory. This is repeated on the 3rd directory as well, but this time a success is expected as a return if the Bypass Traverse Checking is enabled; access denied is expected if this user privilege is not enabled.


TD-21.18 ObjectID File System Test Group

Object IDs are used to uniquely identify files and directories on a volume. This feature allows files or directories to be referenced by a unique ID, which is preserved even if the file or directory is renamed. The file or directory may be opened by its Object ID, and its path name queried.

The following tests are part of this Group:

Click to show or hide information. GetObjectIDVolumeTest

The NtQueryVolumeInformationFile API with FileFsObjectInformation class can be used to retrieve a volume's Object ID. If the volume does not have an Object ID, the operation fails with STATUS_OBJECT_NAME_NOT_FOUND. Otherwise, the existing Object ID is retrieved and the operation succeeds.

Click to show or hide information. NameInformationExTest

The NtQueryInformationFile with the FileNameInformation class can be used to retrieve the full path of a file or directory through Object IDs. This is verified by opening a file or directory by its Object ID, and querying its file name. Note that directory traverse privilege is required.

Click to show or hide information. ObjectOpenByIDTest

The NtCreateFile with FILE_OPEN_BY_FILE_ID can be used to open a file or directory by Object ID. Similar to the semi-unique 64Bit file index, the Object ID is used as the file name of length sizeof(OBJECTID).

Click to show or hide information. NotificationObjectIDRemovedTest

Changes to the (\$Extend\$ObjId:$O:$INDEX_ALLOCATION) object index can be observed using NtNotifyChangeDirectoryFile(). The FILE_OBJECTID_INFORMATION structure is returned. The following notifications are possible:

FILE_ACTION_ADDED

An object ID has been added to the index

FILE_ACTION_REMOVED

An object ID has been removed from the index via FSCTL_DELETE_OBJECT_ID

FILE_ACTION_REMOVED_BY_DELETE

An object ID has been removed from the index because the file with which it was associated was deleted

FILE_ACTION_ID_NOT_TUNNELLED

An object ID could not be restored from the tunnel cache because the ID was in use by another file on the volume

FILE_ACTION_TUNNELLED_ID_COLLISION

An object ID could not be restored from the tunnel cache because the destination file already had an object ID

This test verifies the FILE_ACTION_REMOVED notification.

Click to show or hide information. SetExtendedObjectIDTest

The FSCTL_SET_OBJECT_ID_EXTENDED is used to set the extended information portion of a file or directory's Object ID. This is verified by using the FSCTL_GET_OBJECT_ID to retrieve this extended information.

Click to show or hide information. SetObjectIDTest

An object ID can be set on a file or directory with the FSCTL_SET_OBJECT_ID control code and the FILE_OBJECTID_BUFFER, provided the user attempting the operation has BACKUP/RESTORE privileges on the system. This means that SE_RESTORE_NAME privilege must be enabled on the user process and the file or directory handle must be opened with BACKUP/RESTORE intent. Otherwise, STATUS_ACCESS_DENIED is returned.

This is verified by opening a file or directory without the FILE_OPEN_FOR_BACKUP_INTENT create flag and attempting the FSCTL_SET_OBJECT_ID operation. The operation should fail with STATUS_ACCESS_DENIED.

Click to show or hide information. SetObjectIDVolumeTest

The NtSetVolumeInformationFile API with FileFsObjectInformation class can be used to set an Object ID on a volume. If the volume does not have an Object ID, the new Object ID is set and the operation succeeds. If the volume already has an Object ID, the old Object ID is replaced with the new Object ID and the operation succeeds. However, if a file or directory already has the same Object ID, the operation fails with STATUS_DUPLICATE_NAME.

Click to show or hide information. TunnelObjectIDTest

The Tunneling of Object IDs is the process of caching the Object ID of a file or directory. If a file or directory that has an object ID is deleted, and if another file or directory that does not have an object ID is renamed to the file or directory just deleted, the renamed file will have an object ID. It is said that the object ID has been tunnelled (from the deleted file to the renamed file).

Click to show or hide information. NotificationObjectIDNotTunnelledTest

Changes to the (\$Extend\$ObjId:$O:$INDEX_ALLOCATION) object index can be observed using NtNotifyChangeDirectoryFile(). The FILE_OBJECTID_INFORMATION structure is returned. The following notifications are possible:

FILE_ACTION_ADDED

An object ID has been added to the index

FILE_ACTION_REMOVED

An object ID has been removed from the index via FSCTL_DELETE_OBJECT_ID

FILE_ACTION_REMOVED_BY_DELETE

An object ID has been removed from the index because the file with which it was associated was deleted

FILE_ACTION_ID_NOT_TUNNELLED

An object ID could not be restored from the tunnel cache because the ID was in use by another file on the volume

FILE_ACTION_TUNNELLED_ID_COLLISION

An object ID could not be restored from the tunnel cache because the destination file already had an objectid

This test verifies the FILE_ACTION_ID_NOT_TUNNELLED notification.

Click to show or hide information. SetUniqueObjectIDNameCollisionTest

The Object IDs should be unique for each file and directory on the volume. This is verified by using FSCTL_SET_OBJECT_ID to try setting an object ID on a file or directory that already has an object ID. The operation should fail with STATUS_OBJECT_NAME_COLLISION.

Click to show or hide information. SetUniqueObjectIDDuplicateNameTest

The Object IDs should be unique for each file and directory on the volume. This is verified by using FSCTL_SET_OBJECT_ID to try setting an object ID that is known to already exist on the volume. The operation should fail with STATUS_DUPLICATE_NAME if the file or directory on which the operation is attempted does not have an object ID.

Click to show or hide information. NotificationObjectIDAddedTest

Changes to the (\$Extend\$ObjId:$O:$INDEX_ALLOCATION) object index can be observed using NtNotifyChangeDirectoryFile(). The FILE_OBJECTID_INFORMATION structure is returned. The following notifications are possible:

FILE_ACTION_ADDED

An object ID has been added to the index

FILE_ACTION_REMOVED

An object ID has been removed from the index via FSCTL_DELETE_OBJECT_ID

FILE_ACTION_REMOVED_BY_DELETE

An object ID has been removed from the index because the file with which it was associated was deleted

FILE_ACTION_ID_NOT_TUNNELLED

An object ID could not be restored from the tunnel cache because the ID was in use by another file on the volume

FILE_ACTION_TUNNELLED_ID_COLLISION

An object ID could not be restored from the tunnel cache because the destination file already had an object ID

This test verifies the FILE_ACTION_ADDED notification.

Click to show or hide information. CreateOrGetObjectIDTest

The FSCTL_CREATE_OR_GET_OBJECT_ID can be used to return the existing ObjectID or generate a new object ID for the file or directory. This is verified by attempting the FSCTL_CREATE_OR_GET_OBJECT_ID operation on a file or directory that has a known Object ID. The operation should succeed and the known Object ID should be returned in a FILE_OBJECTID_BUFFER structure. Then, the Object ID is deleted from the file with FSCTL_DELETE_OBJECT_ID. Finally, the FSCTL_CREATE_OR_GET_OBJECT_ID attempt is made on the same file. The operation should succeed and return a newly created Object ID in the FILE_OBJECTID_BUFFER.

Click to show or hide information. NotificationObjectIDTunnelledCollisionTest

Changes to the (\$Extend\$ObjId:$O:$INDEX_ALLOCATION) object index can be observed using NtNotifyChangeDirectoryFile(). The FILE_OBJECTID_INFORMATION structure is returned. The following notifications are possible:

FILE_ACTION_ADDED

An object ID has been added to the index

FILE_ACTION_REMOVED

An object ID has been removed from the index via FSCTL_DELETE_OBJECT_ID

FILE_ACTION_REMOVED_BY_DELETE

An object ID has been removed from the index because the file with which it was associated was deleted

FILE_ACTION_ID_NOT_TUNNELLED

An object ID could not be restored from the tunnel cache because the ID was in use by another file on the volume

FILE_ACTION_TUNNELLED_ID_COLLISION

An object ID could not be restored from the tunnel cache because the destination file already had an object ID

This test verifies the FILE_ACTION_TUNNELLED_ID_COLLISION notification.

Click to show or hide information. DeleteObjectIDTest

An existing Object ID can be removed from a file or directory using FSCTL_DELETE_OBJECT_ID, provided the handle is opened with RESTORE intent and WRITE access. This is verified by attempting to delete the Object ID of a file or directory with the handle opened without the FILE_OPEN_FOR_BACKUP_INTENT option flag nor WRITE access. The operation should fail with STATUS_ACCESS_DENIED. Then, the operation is repeated with a handle opened with the FILE_OPEN_FOR_BACKUP_INTENT option flag and WRITE access. The operation should succeed.

Click to show or hide information. NotificationObjectIDDeletedTest

Changes to the (\$Extend\$ObjId:$O:$INDEX_ALLOCATION) object index can be observed using NtNotifyChangeDirectoryFile(). The FILE_OBJECTID_INFORMATION structure is returned. The following notifications are possible:

FILE_ACTION_ADDED

An object ID has been added to the index

FILE_ACTION_REMOVED

An object ID has been removed from the index via FSCTL_DELETE_OBJECT_ID

FILE_ACTION_REMOVED_BY_DELETE

An object ID has been removed from the index because the file with which it was associated was deleted

FILE_ACTION_ID_NOT_TUNNELLED

An object ID could not be restored from the tunnel cache because the ID was in use by another file on the volume

FILE_ACTION_TUNNELLED_ID_COLLISION

An object ID could not be restored from the tunnel cache because the destination file already had an object ID

This test verifies the FILE_ACTION_REMOVED_BY_DELETE notification.

Click to show or hide information. EnumObjectIDTest

The Object IDs on a volume can be queried with the NtQueryDirectoryFile() and FileObjectIdInformation class. A FILE_OBJECTID_INFORMATION structure is returned for each object. The name of the pseudo-directory to open is (\$Extend\$ObjId:$O:$INDEX_ALLOCATION).

Click to show or hide information. GetObjectIDTest

The FSCTL_GET_OBJECT_ID and FILE_OBJECTID_BUFFER can be used to retrieve a file or directory's object ID. This is verified by setting the object ID on a file or directory, and retrieving the Object ID with the FSCTL_GET_OBJECT_ID operation. The same ID that was set should be returned.


TD-21.19 MountPoints File System Test Group

The tests in this group include:

Click to show or hide information. CreateDirectoryExDirectoryTest

The purpose of this test is to copy a directory that contains a name graft. The reparse information should be copied with the special WIN32 CreateDirectoryEx call. The target directory contains a subdirectory and a file. Access to these through the copied reparse point is verified.

Click to show or hide information. CreateDirectoryExVolumeTest

The purpose of this test is to create a volume mount point and then copy the directory containing the point. A special WIN32 API call CreateDirectoryEx should also copy the reparse information. A file and directory are known to exist on an alternate volume. The file and directory are opened through the copied volume mount point.

Click to show or hide information. DirectoryCycleOnReparseTest

The purpose of this test is to attempt the legal operation of linking a lower child directory to its immediate parent and then traversing the self-referencing directory tree up to 16 times before an error status is returned. This limit is imposed by the I/O manager.

Click to show or hide information. DirectoryGraftTest

The purpose of this test is to attempt name grafting on a directory. The target directory contains a subdirectory and a file. Access to these through the reparse point is verified.

Click to show or hide information. DirectoryGraftEmptyFileTest

The purpose of this test is to attempt name grafting on a directory that contains a file. Name grafting requires an empty directory. The STATUS_DIRECTORY_NOT_EMPTY status return is verified.

Click to show or hide information. DirectoryGraftEmptyTest

The purpose of this test is to attempt name grafting on a directory that contains a subdirectory. The STATUS_DIRECTORY_NOT_EMPTY status return is verified.

Click to show or hide information. DirectoryGraftEmptyStreamTest

The purpose of this test is to attempt name grafting on a directory using a handle to a named data stream on a directory. Even though a named data stream on the directory was opened, this attempt returns STATUS_NOT_A_DIRECTORY.

Click to show or hide information. FileGraftTest

The purpose of this test is to attempt name grafting on a file. A file is opened, and an attempt is made to set the IO_REPARSE_TAG_MOUNT_POINT reparse point with the file handle. On Windows 2000 NTFS volumes, this returns STATUS_NOT_A_DIRECTORY.

Click to show or hide information. FileGraftStreamTest

The purpose of this test is to attempt name grafting on a named data stream of a file. A named data stream of file is opened, and an attempt is made to set the IO_REPARSE_TAG_MOUNT_POINT reparse point with the file handle. On Windows 2000 ntfs volumes, this returns STATUS_NOT_A_DIRECTORY.

Click to show or hide information. LocalMountPointTest

The purpose of this test is to create a volume mount point and then exercise it. A file and directory are known to exist on an alternate volume. The file and directory are opened through the volume mount point.


TD-21.20 ReparsePoints File System Test Group

The tests in this group include:

Click to show or hide information. SetPointDirectoryNotEmptyTest

This test validates the behavior of FSCTL_SET_REPARSE_POINT on a non-empty directory.

The code path that returns STATUS_DIRECTORY_NOT_EMPTY is exercised by attempting to set a reparse point on a non-empty directory. This operation is expected to fail with STATUS_DIRECTORY_NOT_EMPTY on NTFS5-compatible file systems.

Click to show or hide information. EnumReparsePointsTest

This test verifies that the index (\$EXTEND\$Reparse:$R:$INDEX_ALLOCATION) can be used with NtQueryDirectoryFile() and that the FileReparsePointInformation class retrieves the reparse tag for a given file or directory with a reparse point. First, a reparse point is set on a file and directory. Then, the index is queried. The reparse tag information for the file and directory with a reparse point retrieved. This operation is expected to succeed on NTFS5-compatible file systems.

Click to show or hide information. FileAttributeReparsePointTest

This test verifies that BASIC INFORMATION can be obtained from a file or directory with a reparse point. First, a reparse point is set on a file and directory. Then, the file or directory is queried for BASIC INFORMATION. The attribute field of the FILE_ATTRIBUTE_BASIC_INFORMATION structure is checked for FILE_ATTRIBUTE_REPARSE_POINT.

This operation is expected to succeed on NTFS5-compatible file systems.

Click to show or hide information. GetPointBufferSmallTest

This test validates the behavior of the FSCTL_GET_REPARSE_POINT, which is used to get a reparse point set on a file or directory.

The code path that returns STATUS_BUFFER_TOO_SMALL is exercised by attempting to get a reparse point from a file or directory while using an output buffer length argument less than REPARSE_DATA_BUFFER_HEADER_SIZE. This operation is expected to fail with STATUS_BUFFER_TOO_SMALL on supported file systems.

Click to show or hide information. GetPointNotReparseTest

This test validates the behavior of the FSCTL_GET_REPARSE_POINT, which is used to get a reparse point set on a file or directory.

The code path that returns STATUS_NOT_A_REPARSE_POINT is exercised by attempting to get a reparse point from a file or directory which has noprior reparse point set. This operation is expected to fail with STATUS_NOT_A_REPARSE_POINT on NTFS5-compatible file systems.

Click to show or hide information. GetPointInvalidUserBufferTest

This test validates the behavior of the FSCTL_GET_REPARSE_POINT, which is used to get a reparse point set on a file or directory.

The code path that returns STATUS_INVALID_USER_BUFFER is exercised by attempting to get a reparse point from a file or directory while using NULL as a reparse buffer argument to the NtFsControlFile() API. This operation is expected to fail with STATUS_INVALID_USER_BUFFER on NTFS5-compatible file systems.

Click to show or hide information. GetPointInvalidParamTest

This test validates the behavior of the FSCTL_GET_REPARSE_POINT, which is used to get a reparse point set on a file or directory.

The code path that returns STATUS_INVALID_PARAMETER is exercised by attempting to get a reparse point on a volume or by using an output buffer argument with the NtFsControlFile() API. The operation is expected to fail with STATUS_INVALID_PARAMETER n NTFS5-compatible file systems.

Click to show or hide information. SetPointInvalidBufferSizeTest

This test validates the behavior of the FSCTL_SET_REPARSE_POINT, which is used to set a reparse point on a file or directory.

The code path that returns STATUS_INVALID_BUFFER_SIZE is exercised by attempting to set a reparse point on a file and directory while passing NULL as a reparse buffer argument to the NtFsControlFile() API. The operation is expected to fail with STATUS_INVALID_BUFFER_SIZE on NTFS5-compatible file systems.

Click to show or hide information. SetPointInvalidParamTest

This test validates the behavior of the FSCTL_SET_REPARSE_POINT, which is used to set a reparse point on a file or directory.

The code path that returns STATUS_INVALID_PARAMETER is exercised by attempting to set a reparse point on a volume or by using an output buffer argument. The operation is expected to fail in both cases with STATUS_INVALID_PARAMETER on supported file systems.

Click to show or hide information. SetPointIoReparseDataInvalidTest

This test validates the behavior of the FSCTL_SET_REPARSE_POINT, which is used to set a reparse point on a file or directory.

The code path that returns STATUS_IO_REPARSE_DATA_INVALID is exercised by using an input buffer length argument less than REPARSE_DATA_BUFFER_HEADER_SIZE, an input buffer length argument greater than MAX_REPARSE_DATA_BUFFER_SIZE, an input buffer length argument different than the reparse data buffer length, or a GUID equal to NULL (if ISV reparse tag). The operation is expected to fail in all of these cases with STATUS_IO_REPARSE_DATA_INVALID on NTFS5-compatible file systems.

Click to show or hide information. ChangeNotificationReparseTest

This test verifies that the index (\$EXTEND\$Reparse:$R:$INDEX_ALLOCATION) can be used to wait for reparse point additions. First, a change notification is set on a volume index. Then, an event is created to wait for the addition of reparse points.

Next, a different thread sets a reparse point on a file to trigger the event. Meanwhile, the main thread waits for the event to occur. This operation is expected to fail with IFSTEST_TEST_PENDING_IO_TIMEOUT on NTFS5-compatible file systems because it is not yet supported.

Click to show or hide information. OpenReparsePointTest

This test verifies that a file or directory with a reparse point can be opened with the FILE_OPEN_REPARSE_POINT, which inhibits reparse behavior of the file or directory.

First, a reparse point is set on a file and directory. Then, an attempt is made to open the file and directory without using FILE_OPEN_REPARSE_POINT. The operation is expected to fail with STATUS_IO_REPARSE_TAG_NOT_HANDLED on NTFS5-compatible file systems.

Next, an attempt is made to open the file and directory while using FILE_OPEN_REPARSE_POINT. The operation is expected to succeed on NTFS5-compatible file systems.

Click to show or hide information. QueryFullAttributesReparseTest

This test verifies that a file or directory with a reparse point can be queried using NtQueryFullAttributesFile() API, which returns a FILE_NETWORK_OPEN_INFORMATION structure. This operation is expected to succeed on NTFS5-compatible file systems, with the FILE_ATTRIBUTE_REPARSE_POINT attribute set in the attribute field of the returned structure.

Click to show or hide information. QueryFileAttributeTagInfoTest

This test verifies that a file or directory with a reparse point can be queried for FileAttributeTagInformation. First, a reparse point is set on a file or directory. Then, the NtQueryInformationFile() API is used with theFileAttributeTagInformation class. This operation is expected to succeed on NTFS5-compatible file systems.

Click to show or hide information. SetPointIoReparseTagInvalidTest

This test validates the behavior of the FSCTL_SET_REPARSE_POINT, which is used to set a reparse point on a file or directory.

The code path that returns STATUS_IO_REPARSE_TAG_INVALID is exercised by attempting to set a reparse point on a file or directory while using a reparse tag equal to IO_REPARSE_TAG_NSS, IO_REPARSE_TAG_RESERVED_ONE, IO_REPARSE_TAG_RESERVED_ZERO, or ~IO_REPARSE_TAG_VALID_VALUES. The operation is expected to fail in all of these cases with STATUS_IO_REPARSE_TAG_INVALID on NTFS5-compatible file systems.

Click to show or hide information. SetPointIoReparseTagMismatchTest

The code path that returns STATUS_IO_REPARSE_TAG_MISMATCH is exercised by attempting to set a reparse point file or directory with a different reparse tag.

First, a reparse point is set on a file and directory with one reparse tag. Then, an attempt is made to overwrite the same file and directory while using a different reparse tag as argument.

The operation is expected to fail with STATUS_IO_REPARSE_TAG_MISMATCH on NTFS5-compatible File systems.

Click to show or hide information. DeleteFileDirReparsePointTest

This test verifies that a file or directory with a reparse point CANNOT be deleted with normal deletion semantics. First, a reparse point is set on a file and directory. Then, an attempt is made to delete the file and directory with NtDeleteFile() API. The file-delete operation should fail with STATUS_IO_REPARSE_TAG_NOT_HANDLED status on NTFS5-compatible file systems.

Click to show or hide information. DelPointAccessDeniedTest

This test validates the behavior of the FSCTL_DELETE_REPARSE_POINT, which is used to delete a reparse point on a file or directory.

The code path that returns STATUS_ACCESS_DENIED is exercised by attempting to delete a reparse point on a file or directory with no WRITE access. The operation is expected to fail with STATUS_ACCESS_DENIED on NTFS5-compatible file systems.

Click to show or hide information. DelPointAttributeConflictTest

This test validates the behavior of the FSCTL_DELETE_REPARSE_POINT, which is used to delete a reparse point on a file or directory.

First, a reparse point is set on a file and directory with one GUID. Then, an attempt to delete the reparse points on the same file and directory is made, but with a different GUID. The operation is expected to fail on NTFS5-compatible file systems with the status code STATUS_REPARSE_ATTRIBUTE_CONFLICT.

Click to show or hide information. DelPointInvalidBufferSizeTest

This test validates the behavior of the FSCTL_DELETE_REPARSE_POINT, which is used to delete a reparse point on a file or directory.

The code path that returns STATUS_INVALID_BUFFER_SIZE is exercised by attempting to delete a reparse point on a file or directory with a NULL reparse buffer.

First, a reparse point is set on a file and directory. Then, an attempt is made to delete the reparse point on the file and directory while passing NULL as a reparse buffer argument to the NtFsControlFile() API. The operation is expected to fail with STATUS_INVALID_BUFFER_SIZE on NTFS5-compatible file systems.

Click to show or hide information. DelPointIoReparseDataInvalidTest

This test validates the behavior of the FSCTL_DELETE_REPARSE_POINT, which is used to delete a reparse point on a file or directory.

The code path that returns STATUS_IO_REPARSE_DATA_INVALID is exercised by using an input buffer length argument greater than REPARSE_DATA_BUFFER_HEADER_SIZE, an input buffer data length argument different than zero, or a buffer size argument different than the GUID header size (if ISV reparse tag). The operation is expected to fail in all of these cases with STATUS_IO_REPARSE_DATA_INVALID on NTFS5-compatible file systems.

Click to show or hide information. DelPointInvalidParmTest

This test validates the behavior of the FSCTL_DELETE_REPARSE_POINT, which is used to delete a reparse point on a file or directory.

The code path that returns STATUS_INVALID_PARAMETER is exercised by attempting to delete a reparse point on a volume or by using an output buffer argument. The operation is expected to fail in both cases with STATUS_INVALID_PARAMETER on supported file systems.

Click to show or hide information. DelPointIoReparseTagInvalidTest

This test validates the behavior of the FSCTL_DELETE_REPARSE_POINT, which is used to delete a reparse point on a file or directory.

The code path that returns STATUS_IO_REPARSE_TAG_INVALID is exercised by attempting to delete a reparse point on a file or directory while using a reparse tag equal to IO_REPARSE_TAG_RESERVED_ONE or IO_REPARSE_TAG_RESERVED_ZERO. The operation is expected to fail with STATUS_IO_REPARSE_TAG_INVALID on NTFS5-compatible file systems.

Click to show or hide information. DelPointIoReparseTagMismatchTest

This test validates the behavior of the FSCTL_DELETE_REPARSE_POINT, which is used to delete a reparse point on a file or directory.

The code path that returns STATUS_IO_REPARSE_TAG_MISMATCH is exercised by attempting to delete a reparse point file or directory with a different reparse tag. First, a reparse point is set on a file and directory with one reparse tag. Then, an attempt is made to delete the same file and directory while using a different reparse tag as argument. The operation is expected to fail with STATUS_IO_REPARSE_TAG_MISMATCH on NTFS5-compatible file systems.

Click to show or hide information. DelPointNotReparseTest

This test validates the behavior of the FSCTL_DELETE_REPARSE_POINT, which is used to delete a reparse point on a file or directory.

The code path that returns STATUS_NOT_A_REPARSE_POINT is exercised by attempting to delete a reparse point on a file or directory that has no prior reparse point set. The operation is expected to fail with STATUS_NOT_A_REPARSE_POINT on NTFS5-compatible file systems.

Click to show or hide information. SetPointEASNotSupportedTest

This test validates the behavior of the FSCTL_DELETE_REPARSE_POINT, which is used to delete a reparse point on a file or directory.

The code path that returns STATUS_EAS_NOT_SUPPORTED is exercised by attempting to set a reparse point on a file or directory with extended attributes. The operation is expected to fail with STATUS_EAS_NOT_SUPPORTED on NTFS5-compatible file systems because reparse points and extended attributes are mutually exclusive.

Click to show or hide information. SetPointAccessDeniedTest

This test validates that the File System is not be able to set reparse points on files and directories with no WRITE access.

Click to show or hide information. SetPointAttributeConflictTest

This test validates that the File System must not be able to set reparse points from files and directories with mismatched GUID.


TD-21.21 SparseFiles File System Test Group

The tests in this group include:

Click to show or hide information. SparseMoveFileTest

The defrag API call FSCTL_MOVE_FILE can be used with sparse files. If the VCN range to move is sparse, the specified LCN is not allocated. This test creates a sparse file, obtains the retrieval pointers of the file, and then attempts to move a sparse region over an already committed LCN range. The move should return success since the area takes no allocation. The attempt is then made over a sparse and nonsparse range. This should fail with STATUS_ALREADY_COMMITTED.

Click to show or hide information. SparseNonSparseStreamTest

The purpose of this test is to test the ability to have sparse and nonsparse data streams on a file. This test uses allocation size to determine this. The unnamed data stream of a file is opened and made sparse. Then a byte is written at the end of the stream. A named stream is then created on the file. The same write is done on the named nonsparse data stream. The allocation size of the file is then checked. The new allocation size is checked to be less than 10% + the size for the nonsparse region of the allocation necessary.

Click to show or hide information. NonSparseZeroDataTest

The purpose of this test is to ensure that FSCTL_SET_ZERO_DATA sets a range of a non-sparse file to zero. The test file is first opened. Then the file is written with 0xffs. The FSCTL is attempted on the first half of the file. The file is then read back and the first half is verified to be zeros, and the second half 0xffs.

Click to show or hide information. ResetSparseAttrOverwriteTest

When a sparse file is overwritten, it becomes a nonsparse file. This is tested by way of the sparse attribute, FILE_ATTRIBUTE_SPARSE_FILE. The attribute is checked before and after the overwrite. After the overwrite, the flag is checked to be reset.

Click to show or hide information. SparseZeroDataAllocTest

The purpose of this test is to ensure that FSCTL_SET_ZERO_DATA reduces the allocation size of the file. The test file is first opened and made sparse. Then the file is written with 0xffs. The allocation size is checked to see that at least 100% of the file size is allocated. The FSCTL is attempted on the first half of the file. The allocation size is again checked to verify that no more than 60% of the file size is allocated.

Click to show or hide information. SparseZeroDataTest

The purpose of this test is to ensure that FSCTL_SET_ZERO_DATA sets a range of a sparse file to zero. The test file is first opened and made sparse. Then the file is written with 1s. The FSCTL is attempted on the first half of the file. The file is then read back and the first half is verified to be zeros, and the second half 0xffs.

Click to show or hide information. SparseStreamTest

The purpose of this test is to test sparse streams by way of allocation size. The unnamed data stream of a file is opened and made sparse. Then a byte is written at the end of the stream. The allocation size is checked. The new allocation size is checked to be less than 10% of the allocation necessary.

Click to show or hide information. SparseStreamDirTest

The purpose of this test is to test sparse streams by way of allocation size. A named data stream of a directory is created and made sparse. Then a byte is written at the end of the stream. The allocation size is checked. The new allocation size is checked to be less than 10% of the allocation necessary.

Click to show or hide information. ResetSparseAttrSupersedeTest

When a sparse file is superseded, it becomes a nonsparse file. This is tested by way of the sparse attribute, FILE_ATTRIBUTE_SPARSE_FILE. The attribute is checked before and after the supersede. After the supersede, the flag is checked to be reset.

Click to show or hide information. SparseAllocatedRangesTest

The purpose of this test is to ensure that FSCTL_SET_ZERO_DATA reduces the allocation size of the file. The test file is first opened and made sparse. Then the file is written with 0xffs. The allocation size is checked to see that at least 100% of the file size is allocated. The FSCTL is attempted on the first half of the file. The allocation size is again checked to verify that no more than 60% of the file size is allocated.

Click to show or hide information. FileInformationSparseAttrTest

The purpose of this test is to test the FILE_ATTRIBUTE_SPARSE_FILE attribute flag. The attributes are obtained by using NtQueryInformationFile with the basic information class. The flag represents the sparse attribute on a stream by stream basis. If one stream in a file is opened that is not sparse, the flag is clear. If a different stream in the same file is opened that is sparse, the flag is then set.

Click to show or hide information. SparseCompressedStreamTest

Sparse files can be compressed using FSCTL_SET_COMPRESSION. The sparse extents are not changed after the compress. This test creates a sparse file, obtains the retrieval pointers of the file, and then attempts to compress the file. The retrieval pointers are again obtained and the sparse extent is verified to be the same. FSCTL_GET_RETRIEVAL_POINTERS is used to obtain the pointers.

Click to show or hide information. SparseUserMappedSectionTest

The purpose of this test is to test the creation of a user mapped section and view on a sparse file. The test file is first opened and made sparse. Then a byte is written at the end of the file. A section and view are then created on the file.

Click to show or hide information. SparseUserMapZeroTest

The purpose of this test is to ensure that FSCTL_SET_ZERO_DATA returns STATUS_USER_MAPPED_FILE when there is a user mapped section and view on a sparse file. The test file is first opened and made sparse. Then a byte is written at the end of the file. A section and view are then created on the file. The FSCTL is attempted and the expected status is verified.


TD-21.22 ExtendedSecurity File System Test

FindFilesBySidTest

The purpose of this test is to verify that FSCTL_FIND_FILES_BY_SID can be used to scan the file records and find entries owned by a specified SID. The FIND_BY_SID_DATA structure is used as input buffer to specify the SID. An output buffer aligned on a FILE_NAME_INFORMATION structure boundary is used to return the found files.


TD-21.23 ForcedDismount File System Test

ForceDismountTest

The purpose of this test is to verify that, in Windows 2000, the FSCTL_DISMOUNT_VOLUME can be issued on an active volume, that is, with opened file handles. This operation is expected to succeed, except in the following two cases:

  • The volume is the system drive, which cannot be dismounted. The operation fails with STATUS_ACCESS_DENIED.
  • The file system is pre-NT5 FAT, which requires exclusive-lock access to the volume before it can be dismounted. The operation fails with STATUS_NOT_LOCKED.


TD-21.24 Encryption File System Test Group

A programmer or user may mark a directory or file as encrypted. A file so marked is encrypted by NTFS using the current encryption driver. If the file is later marked as not encrypted, it is decrypted and left in a plaintext (not encrypted, but still protected by the NT security model) state.

Directories are not themselves encrypted. Rather, by default, in an "encrypted" directory all new files in the directory are encrypted at creation. A user must specifically change the status of a new file to decrypted if the user does not want the file to be encrypted. An encrypted directory is visible.

To encrypt a file, the CreateFile function with the FILE_ATTRIBUTE_ENCRYPTED flag is used. To encrypt an existing file, the EncryptFile function can be used. All data streams in the file are encrypted. If the file is already encrypted, EncryptFile does nothing but return a nonzero value, which indicates success. If the file is compressed, EncryptFile decompresses the file before encrypting it.

To decrypt an encrypted file, the DecryptFile function is used. If the file is not encrypted, DecryptFile does nothing but return a nonzero value indicating success.

To retrieve the encryption status of a file, the FileEncryptionStatus function is used. Alternatively, the GetFileAttributes function and the FILE_ATTRIBUTE_ENCRYPTED flag can be used.

Before the tests are run, the volume information should be queried to determine if Encryption is supported (FILE_SUPPORTS_ENCRYPTION). All tests are then run. The expectations of the tests should be altered depending on the determined support.

The call path from WIN32 is:

advapi.dll -> feclient.dll -rpc-> LSA

Click to show or hide information. SuperOverEncryptedTest

A file can be encrypted by using the NtCreateFile API with the FILE_ATTRIBUTE_ENCRYPTED flag specified. The FILE_SUPERSEDE, FILE_OVERWRITE, and FILE_OVERWRITE_IF dispositions can be used on an existing file. Encryption on the files is then tested by opening the file in a different process, with a different security token. ACCESS_DENIED should be returned.

Click to show or hide information. ReadWriteRawEncryptedTest

The raw encrypted data can be read and written using OpenEncryptedFileRaw, ReadEncryptedFileRaw, WriteEncryptedFileRaw, and CloseEncryptedFileRaw. These are used in off-line recovery. The operations are tested by encrypting a file then creating a new file and writing with the api's. The file size of the two files should match.

Click to show or hide information. RemoveUsersEncryptionTest

The RemoveUsersFromEncryptedFile function is used to remove a specified user from a list of users that are permitted to access a specified encrypted file. This is verified by encrypting a file in an alternate user context. Then, the QueryUsersOnEncryptedFile function is called to retrieve the number of users that are allowed access to the file. This number should be at least 1: the file owner. Finally, the RemoveUsersFromEncryptedFile function is called to remove the specified user from the list; the QueryUsersOnEncryptedFile is called again. The number of users allowed to decrypt the file should be one less than before.

Click to show or hide information. QueryUsersEncryptionTest

The QueryUsersOnEncryptedFile function is used to retrieve a list of users that are permitted to access a specified encrypted file. This is verified by encrypting a file in an alternate user context. Then, the QueryUsersOnEncryptedFile function is called to retrieve the number of users that are allowed access to the file. This number should be at least 1: the file owner.

Click to show or hide information. QueryRecoveryAgentsTest

The QueryRecoveryAgentsOnEncryptedFile function is used to retrieve a list of users that are permitted to recover a specified encrypted file. The recovery agent can always retrieve the file if the file owner can no longer do so. This is verified by encrypting a file in an alternate user context. Then, the QueryRecoveryAgentsOnEncryptedFile function is called to retrieve the number of users that are allowed recover to the file. This number should be at least 1: the recovery agent.

Click to show or hide information. EncryptDecryptFileTest

A file can be encrypted by using the EncryptFile function. Encryption on the files is tested by opening the file in a different process, with a different security token. ACCESS_DENIED should be returned. The file is then decrypted with the DecryptFile function. An attempt to open and read should be made. NO_ERROR should be returned.

Click to show or hide information. EncryptDecryptDirTest

A directory can be encrypted by using the EncryptFile function. When the file/dir attributes are read back, the encryption flag should be set. Directories can be decrypted by calling the DecryptFile function. The attributes should be consistent with the encryption state.

Click to show or hide information. EncryptionStatusTest

The FileEncryptionStatus call can be used to check the encryption status of a file or directory. The call is made on files and directories that are and are not encrypted. The FILE_IS_ENCRYPTED is checked for correctness.

Click to show or hide information. EncryptionDecompressionTest

In Windows 2000, file based compression and encryption are mutually exclusive. When the file is compressed and a call to EncryptFile is made, the file will be uncompressed in the process. The attributes on the file should then show encryption only.

Click to show or hide information. EncryptionCompressionTest

In Windows 2000, file based compression and encryption are mutually exclusive. If an attempt is made to encrypt a file that is already compressed. The file will be decompressed, and then encryption will be applied. This can be verified by first compressing a directory with FSCTL_SET_COMPRESSION. Then an encrypted file and directory are created with a call to NtCreateFile while specifying the FILE_ATTRIBUTE_ENCRYPTED flag. The attribute of the file and directory are read back; only the FILE_ATTRIBUTE_ENCRYPTED flag should be observed.

Click to show or hide information. EncryptionAttributeTest

GetFileAttributes can be used to check the encryption status of a file or directory. The call is made on files and directories that are and are not encrypted. FILE_ATTRIBUTE_ENCRYPTED is observed.

Click to show or hide information. DirectoryEncryptedSuperOverTest

An existing non-empty directory can be encrypted by using the EncryptFile function. The FILE_SUPERSEDE, FILE_OVERWRITE, and FILE_OVERWRITE_IF dispositions can then be used on the files in that directory. This will encrypt the files. Encryption on the files is then verified by opening the file in a different process, with a different security token. ACCESS_DENIED should be returned.

Click to show or hide information. DirectoryEncryptedNewFileTest

A directory can be encrypted by using the NtCreateFile API with the FILE_ATTRIBUTE_ENCRYPTED flag specified. A new file created under the encrypted directory should be encrypted by default. Encryption on the file is tested by opening the file in a different process, with a different security token. ACCESS_DENIED should be returned.

Click to show or hide information. DirectoryEncryptedNewDirTest

A directory can be encrypted by using the NtCreateFile API with the FILE_ATTRIBUTE_ENCRYPTED flag specified. A new directory created under the encrypted directory should be encrypted by default. Encryption on the directory is tested by opening the directory and verifying that FILE_ATTRIBUTE_ENCRYPTED is set.

Click to show or hide information. CreateEncryptedFileTest

A file can be encrypted by using the CreateFile function with the FILE_ATTRIBUTE_ENCRYPTED flag specified. The CREATE_NEW disposition must be used. Encryption on the file is tested by opening the file in a different process, with a different security token. ACCESS_DENIED should be returned.

Click to show or hide information. CreateEncryptedDirTest

A directory can be encrypted by using the NtCreateFile API with the FILE_ATTRIBUTE_ENCRYPTED flag specified. When the file/dir attributes are read back, the encryption flag should be set.AddUsersEncryptionTest The AddUsersToEncryptedFile function can be used to share encrypted files, i.e., allow other users to decrypt an encrypted file. This is verified by encrypting a file in an alternate user context. The QueryUsersOnEncryptedFile function is used to verify that the number of users allowed to access the file is 1. Then, the AddUsersOnEncryptedFile function is used to add another user to the encrypted file. The QueryUsersOnEncryptedFile function should now report that 2 users are allowed access to the encrypted file.


TD-21.25 Quotas File System Test Group

Quotas are used to limit the amount of data a user is allowed to save on a volume. The tests in this group are:

Click to show or hide information. VolumeQuotaEnforceTest

Quota usage changes are tracked and quota enforcement is done. This uses the FILE_VC_QUOTA_ENFORCE flag with NtSetVolumeInformation(), FileFsControlInformation. Attempts to exceed the quota should fail (DISK_FULL) and be logged in the event log if event logging is enabled.

Click to show or hide information. VolumeQuotaNoneTest

This test uses the FILE_VC_QUOTA_NONE flag, with NtSetVolumeInformation() and FileFsControlInformation class to disable quota usage tracking. Although quota usage changes are not tracked, the quota limits are not removed. This is the default for an NTFS volume.

Click to show or hide information. QuerySetQueryQuotaTest

NtQueryQuotaInformationFile() and NtSetQuotaInformationFile() allow sids (and their respective quota settings) to be queried and set to the volume quota index. NtQueryQuotaInformationFile() and NtSetQuotaInformationFile() use FILE_GET_QUOTA_INFORMATION to specify a SID. FILE_QUOTA_INFORMATION is used to set and get. It contains limits, thresholds, and a SID.

Click to show or hide information. VolumeQuotaTrackTest

This test uses the FILE_VC_QUOTA_TRACK flag, with NtSetVolumeInformation() and FileFsControlInformation class to enable disk Quota tracking, whereby Quota usage changes are tracked, but no quota enforcement is done. This means that no file system operation are failed for disk Quota violations and no disk quota violations events are generated if disk logging is disabled.

Click to show or hide information. VolumeQuotaUserLimitTest

We test the limit logging of user quotas with FILE_VC_LOG_QUOTA_LIMIT. This is applied with NtSetVolumeInformation, FileFsControlInformation. When the user quota exceeds the limit, the correct event should be generated.

Click to show or hide information. VolumeQuotaUserThresholdTest

We test logging of user quotas with FILE_VC_LOG_QUOTA_THRESHOLD. This is applied with NtSetVolumeInformation, FileFsControlInformation. When the user quota exceeds the threshold, the correct events should be generated.

Click to show or hide information. VolumeQuotaLimitTest

We test that the FILE_VC_LOG_VOLUME_LIMIT flag has no effect on disk Quotas. This is applied with NtSetVolumeInformation, FileFsControlInformation. When the user quota exceeds the limit, no disk Quota events are generated.

Click to show or hide information. VolumeQuotaThresholdTest

We test that the FILE_VC_LOG_VOLUME_THRESHOLD flag has no effect on disk Quotas. This is applied with NtSetVolumeInformation, FileFsControlInformation. When the user quota exceeds the limit, no disk Quota events are generated.


TD-21.26 LinkTracking File System Test Group

The Object IDs of files, directories and volumes allow IShellLink::Resolve broken links on the same volume and across volumes. This is tested by creating files/directories with and without Object IDs. The file/directories are moved, and the Resolve method is then invoked. Resolve has two approaches to finding target objects. The first is the distributed link tracking service. If the service is available, it can find an object that was on an NTFS version 5.0 volume and was moved to another location on that volume. It can also find an object that was moved to another NTFS version 5.0 volume, including volumes on other computers. To suppress the use of this service, set the SLR_NOTRACK flag.

The tests in this group are:

Click to show or hide information. IshellLinkResolveTest

The IShellLink interface can be used to create and resolve the object of a link that has moved on the same volume. This test creates two files. The ObjectId is deleted on one of the files with FSCTL_DELETE_OBJECT_ID. Two links are created with the IShellLink interface, one to each file. The target files are moved to a different directory. An attempt is made to resolve the links using IShellLink::Resolve. The test is repeated for target directories.

Click to show or hide information. IShellLinkResolveVolumeTest

The IShellLink interface can be used to create and resolve the object of a link that has been moved onto a different volume (on the same system). This test creates two files. The ObjectId is deleted on one of the files with FSCTL_DELETE_OBJECT_ID. Two links are created with the IShellLink interface, one to each file. The target files are moved to a different volume. An attempt is made to resolve the links using IShellLink::Resolve. The test is repeated for target directories.


TD-21.27 ChangeJournal File System Test Group

The tests in this group are:

Click to show or hide information. ChangeJournalTest

There are many events which are recorded in the change journal. The reasons can be tested by performing an operation that would cause the change to be recorded, and then reading the change journal.

CREATE

Create a new file. USN_REASON_FILE_CREATE

WRITE

Write new data at end of file. USN_REASON_DATA_EXTEND

SET_INFORMATION

Set end of file. USN_REASON_DATA_TRUNCATION

SET_EA

Set or Replace EA. USN_REASON_EA_CHANGE

FSCTL

Set Reparse Point. USN_REASON_REPARSE_POINT_CHANGE

Click to show or hide information. CreateChangeJournalTest

FSCTL_CREATE_USN_JOURNAL creates a USN journal the first time it's called. Otherwise it will either increase the size of the existing journal or have no effect.

Click to show or hide information. DeleteChangeJournalTest

FSCTL_DELETE_USN_JOURNAL is used when the user want to delete the current USN journal. This will initiate the work to scan the Mft and reset all USN values to zero and remove the UsnJournal file from the disk. This operation is tested with the help of FSCTL_QUERY_USN_JOURNAL.

Click to show or hide information. EnumMftUsnDataTest

The FSCTL_ENUM_USN_DATA operation creates an enumeration that lists the change journal entries between two specified boundaries. The FSCTL can be called multiple times on the same range by specifying an ordinal MFT_ENUM_DATA->StartFileReferenceNumber value. This test establishes a known set of USN records. The records are then read through FSCTL_ENUM_USN_DATA.

Click to show or hide information. QueryChangeJournalTest

FSCTL_QUERY_USN_JOURNAL returns the information about the current instance of the USN journal in USN_JOURNAL_DATA.

Click to show or hide information. ReadChangeJournalTest

FSCTL_READ_USN_JOURNAL has input READ_USN_JOURNAL_DATA and output USN_RECORD. This FSCTL returns the USN records from a specific starting USN. This test establishes a known set of USN records. The records are then read through a call to FSCTL_READ_USN_JOURNAL. The contents of the USN record are verified against the expected values.

Click to show or hide information. ReadFileChangeJournalTest

FSCTL_READ_FILE_USN_DATA is used with a file or directory handle. It returns the last USN_RECORD for the open handle.

Click to show or hide information. ChangeJournalTrimTest

The FSCTL_CREATE_USN_JOURNAL control can change the size of a USN journal. CREATE_USN_JOURNAL_DATA->MaximumSize. The allocation size should be returned to the free pool on the volume.

Click to show or hide information. WriteCloseRecordTest

FSCTL_WRITE_USN_CLOSE_RECORD writes a close USN record for the current file, and returns its USN.


TD-21.28 StreamEnhancements File System Test Group

Named streams have been enhanced to support renaming, deleting, querying. In addition, change notification events on name, size and write changes are also supported. The tests in this group are:

Click to show or hide information. StreamQueryNamesTest

The named streams in a file can now be queried using NtQueryInformationFile() with the FileStreamInformation class.

Click to show or hide information. StreamRenameTest

Streams can now be opened and renamed with the NtSetInformationFile() and FileRenameInformation class.

Click to show or hide information. StreamNotifySizeTest

NtNotifyChangeDirectoryFile() can be used with the FILE_NOTIFY_CHANGE_STREAM_SIZE filter. The file size of a stream is changed to cause this notification.

Click to show or hide information. StreamNotifyWriteTest

NtNotifyChangeDirectoryFile() can be used with the FILE_NOTIFY_CHANGE_STREAM_WRITE filter. Notification Actions: FILE_ACTION_MODIFIED_STREAM -- Modify :stream1

Click to show or hide information. StreamNotifyNameTest

NtNotifyChangeDirectoryFile() can be used with the FILE_NOTIFY_CHANGE_STREAM_NAME filter to monitor changes to stream names on a file or directory. The pair FILE_NOTIFY_CHANGE_STREAM_NAME, FILE_ACTION_ADDED_STREAM is observed when streams are added to a file. The pair FILE_NOTIFY_CHANGE_STREAM_NAME, FILE_ACTION_REMOVED_STREAM are added when a file containing named streams is overwritten or superseded.

Click to show or hide information. StreamDeleteTest

Named streams can now be opened and marked for deletion (and deleted on cleanup). This feature is tested here.


TD-21.29 DefragEnhancements File System Test Group

Tests in this group are:

Click to show or hide information. MoveDirTest

Directories can now be de-fragmented using FSCTL_GET_RETRIEVAL_POINTERS and FSCTL_MOVE_FILE. This test creates many files in a directory. Then, the retrieval pointers are obtained using a directory handle. The clusters are then moved using the directory handle, the retrieval pointers, and a volume handle.

Click to show or hide information. MoveViewTest

System view (security, quota, reparse, object ID) directories can now be de-fragmented using FSCTL_GET_RETRIEVAL_POINTERS and FSCTL_MOVE_FILE. First, "\$Extend\$Reparse:$R:$INDEX_ALLOCATION" is opened as a directory. The clusters are then moved using the directory handle, the retrieval pointers, and a volume handle.


TD-21.30 System Cache Test Description

Test Kit: HCT 11, HCT 10

Note This is the I/O Stress test in the HCT.

The System Cache test or File system Stress Kit (FSK, or IoStress) test suite contains tools and tests to thoroughly stress the file system of the Windows 2000 operating system.


I/O Stress Test Descriptions

These tests include:

Click to show or hide information. Mountpts

Enumerates all the volumes on the system, create a volume mount point and write the GUID path into a file in the root of the volume. Verify that the file at the root contains the correct GUID, both through the volume mount point and through ordinary means (drive letter, where this is possible).

Click to show or hide information. Rptags

Stresses FSCTL’s associated with Reparse Points.

Click to show or hide information. Usnstres

Stresses FSCTL’s associated with USN journal.

Click to show or hide information. Grow_shrink

Stresses file expansion and shrinking.

Click to show or hide information. Memfile and Unbuffio -

Tests aim to perform a number of memory and fileio operations simultaneously.

Click to show or hide information. Fs_compression and Cmpstress

Stress file compression and decompression

Click to show or hide information. Cancelio

Stresses the Cancelio API in conjunction with asynchronous ReadFile, WriteFile, and LockFileEx calls.

Click to show or hide information. Cmptest

Creates a compressed file, uncompresses it, verifies, compresses and verifies it again. The test varies the type of I/O, the type of access, and the type of data written into the file.

Click to show or hide information. Compstrs

Creates a file and then writes to the file the loaded images of the Kernel32.dll and Ntdll.dll in an infinite loop. It then compresses the file, sleeps for 0.5 seconds, and then uncompresses the file.

Click to show or hide information. File_notify

Sets up several notification handlers for directories in the stress tree and then waits for notifications from the system.

Click to show or hide information. Fscmprsn

Has the parent thread create a file and spawn other child threads. The child threads constantly toggle the compression state of the file. While the children are toggling the state of the file, the parent proceeds with several writes to the file until the file grows to a particular size. The parent stops all the child threads, verifies the contents of the file and toggles the state of the file, and then repeats the process.

Click to show or hide information. Dismount

Dismounts the drives every four hours.

Click to show or hide information. Objidstrs

Stresses FSCTL’s associated with an Object ID.

Click to show or hide information. Fragment

Creates a high degree of fragmentation on the current stress partition.

Click to show or hide information. Locktest

Stresses the file lock APIs.

Click to show or hide information. Sparsef

Stresses the Windows-specific sparse file APIs.

Click to show or hide information. Mktropcl, Lots_files, Allfs_strs

Create a large tree of directories and files.

Click to show or hide information. Ntfs_acl

Stresses setting up security attributes and DACLs.

Click to show or hide information. Syscache

Stresses the system cache.

Click to show or hide information. Tunnel

Stresses tunneling and link tracking behavior.

Click to show or hide information. Siss

Tests for Single Instance Storage functionality.


Memory_stress and Resource_consumer Descriptions

These are a mixture of test cases to stress memory, heap allocation, and so forth. These tests consist of the following components.

Click to show or hide information. Consume

The Consume stress test is a universal resource consumer. Depending on the command line, it can consume all physical memory, page file, CPU time, disk space, or kernel pool. It should be run it in parallel with other stress tests to put pressure on those components and force them to deal with low resource conditions.

Click to show or hide information. Lookaside

The Lookaside stress test exercises heap manager code paths for small block allocations (below 1,024 bytes). For these small blocks, the heap manager uses a different manager (lookaside manager). The scenario executed is multi-threaded random alloc/free operations.

Click to show or hide information. Race

The Race stress test exercises several scenarios that might expose race conditions. It executes multiple threads of same or similar operations concurrently. It also uses a worker thread that calls a system API passing a buffer as a parameter and a breaker thread that tries to change protection on the buffer passed to the system.

Click to show or hide information. Witness

The Witness stress test exercises the memory manager functionality by randomly executing alloc/free scenarios. The test keeps a simplistic model of the virtual space. Therefore, it can detect minor inconsistencies.

Click to show or hide information. Vmstress

The Vmstress stress test allocates and touches pages from multiple threads. In the process, it checks that the fill patterns are maintained and that we do not get pages from other processes.

Click to show or hide information. Pages

The Pages stress test forces several trashing patterns (large amounts of paging). This exercises the memory manager code paths involved in servicing page faults.

Click to show or hide information. Heaptest

The Heaptest stress test exercises the heap manager code paths. It runs from several threads a random alloc/free scenario. It is more effective in testing the code paths dealing with big heap blocks (above 16K). For small blocks, see the Lookaside test.

Click to show or hide information. Lockmem

The Lockmem test acquires chunks of memory from RAM and the Pagefile. It uses VirtualAlloc and VirtualLock to ensure that memory is allocated in RAM. In addition, it sleeps for a user defined time, unlocks the Memory, and releases it.


Setup for IO Stress Tests

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

User Controls - Steps to Run the I/O Stress Test Suite

Click to show or hide information. Launch

Invoking the Iostress.cmd script in the root directory starts the IoStress engine.

Click to show or hide information. Initialization File Format

[Driver1]

This is the name of the driver. This name should match the registry entry under

- HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services where the Filter Driver is installed as a service.

StartType = value

The valid values are: Boot, Auto, Demand, and Disabled.

DriverType = value

The valid value for the DriverType are FileSystem and Kernel.

BinPath =<string to driver path>

An example is c:\Winnt\system32\drivers\driver1.sys.

NeedsReboot = Value

You can specify Yes or No here. This is an optional field. By default, it is assumed that no driver needs a reboot when it is loaded.

GroupName=Value

You can specify a name for the load order group. If this field is missing, the group name is then termed the same name as the DriverName.

[Driver2]

...

...

Any line beginning with a semi colon (;) is considered a comment.

Click to show or hide information. User Interface

The utility parses the initialization file provided, queries the status of all the drivers installed, and puts it in the two list boxes. Most of the buttons are self-explanatory. Selecting them and pressing the Install button can install drivers in the Additional Available list. This moves them to the Currently Installed list.

Move Up: You can move drivers up and down. All the drivers are reconfigured with a dependency requirement on the drivers below them.

Apply: Your changes take effect when you click the apply button.

Similar to the Driver Verifier, making configuration changes in the filter driver utility may require a reboot. Again, the utility prompts you that in order to incorporate those changes, a reboot is required. This is just informational. IOStress automatically reboots the system at an appropriate juncture.

Click to show or hide information. Munger – System Settings Tab

The Munger sets up the environment for stress. For example, it puts debug flags in Boot.ini and changes registry settings for Resource timeout and Critical section timeout. Select Preferred Stress Settings. Any changes made require a reboot.

Click to show or hide information. Running Tests on Various Drives – Run Information Tab

Prior to a stress run, the utility installs UDF and CDFS drivers on your machine and maps two free drives on your system to these drivers. After the stress run is over, these drives are automatically deleted. These drivers are pseudo drivers to enable you to run Stress even if you do not have them installed on your system.

The utility then enumerates all the drives on the system. This includes the UDF and CDFS drives that were recently installed on your system. By default, this utility selects one drive of each type such as FAT, NTFS, FAT32, CDFS, and a remote drive. If there is no remote drive on your machine, this utility maps a loop back share on your machine.

The Run Information tab contains information about the temporary directory where stress will be run. If you are running Windows 2000 NTFS, you can choose encryption and compression as well.

In addition, you can also specify the duration of the stress run. The date should be specified in mm/dd/yyyy and time in HH:MM formats.

You can skip to run stress on your primary partition and choose all other options. The loop back redirected drive will appear in this section as a remote drive.

Click to show or hide information. Selecting Tests to Run – Test Selection Tab

The Test Selection tab has two list boxes: Currently selected tests and an Additional set. You can move the tests from one list box to another by selecting the tests and clicking the corresponding Add or Remove buttons. The Add and Remove buttons activate once you make your selection.

The default selection of the tests is random

Always select the test IOInit to run. This script launches all other tests.

The name of the tests appearing in the two list boxes have the drive letter appended to the name of the actual test. The drive letter indicates the drive on which the test will run. For example, the test with the name sampletest appears as sampletest_c and sampletest_d. You can choose to run sampletest_c and not run sampletest_d. In this figure, allfs_strs_I is already in the Selected Tests group and the user is also in the process of adding allfs_strs_e to run.

After you have chosen all the tests, click Run. This launches all of the selected stress tests.

Click to show or hide information. Stress Shutdown

You can shutdown the Stress test by clicking the Shutdown button. The Stress test reboots the system; when Windows restarts, it will perform chkdisk on all the drives and clean up the temporary stress files.

Click to show or hide information. Required Hardware

Use the Stress Kit to run file system stress on the following types of drives:

  • NTFS (local and remote)
  • FAT (local and remote)
  • DFS drives
  • Removable Media
  • Floppy Drives


Results Interpretation for I/O Stress Tests

The stress tests generate log files, which contains pertinent information about the status of the tests. These log files are stored in the directory %SystemRoot%\stresslog. Each test makes a directory inside this location and logs its information. The name of the log file indicates the name of the test and the drive on which it is run. For example, if the test Mktropcl is run on E:, the name of the generated log file will be c:\stresslog\mktropcl\mktropcl_E.log.


Appendixes

Appendix A - Filter Testing

N/A

Appendix B - Command Line Options

N/A

Appendix C - IFS Test Status Codes

N/A

Appendix D - Using NTLOG with IFS Test

N/A

Click to show or hide information. ChangeNotificationTest

There are many combinations of FILTERS, CAUSES, and ACTIONS. The notification events table is used for a coverage test of all expected notification behavior. A file handle is opened in the test directory and a thread is created that will write to the file. Meanwhile in the main thread the write is waited upon for 4 seconds, if the write does not occur a timeout will happen. When the write does occur the event is triggered and the test will make sure the correct ACTION was reported.

Click to show or hide information. PrepCompressionTest

Some file systems support compression on individual files. This test is run as part of the SetCompressionTest.

The Installable File System Test, IFS Test, was designed to test the compliance of installable file systems in the Microsoft Windows NT 4.0 and Windows 2000 Operating Systems. Its intended audience includes file system developers who want to verify that their drivers comply with a standard set of expected functionality. The IFS Test is run from the command line with several options specified. Each test that is run will return a test status block whether the test has passed or failed, or the test results can be viewed in NTLOG. The IFS Test was written with the following design goals in mind:

  • Subsystem Independence
  • Synthetic Operation Distinction
  • Separate Test Groups
  • Asynchronous / Synchronous Testing
  • Fault Identification
  • Coverage
  • Extensible
  • Development Guideline
  • Filter Testing


TD-21.31 DCDP 14-Day Stress (Anti-Virus) Test

This is preliminary documentation and subject to change.

Test Kit: HCT 11

Overview

The Datacenter Driver Program (DCDP) 14-Day Stress (Anti-virus) test is an extended version of the I/O Stress with Anti-Virus Scenario test and is designed to test driver compliance with the requirements for Datacenter driver qualification. Testing for this qualification is 14 days long, and the criterion for passing the test is 100% completion without failure. Drivers that achieve these qualifications have met the highest standard of Microsoft testing.

For information about the Datacenter Driver Program, see the white paper at http://www.microsoft.com/hwdev/platform/server/datacenter/default.asp

Overview of the test suite

The I/O Stress with Anti-virus Scenario is a test suite that contains tools and tests to thoroughly stress the file system. These include tests that:

  • Stress file compression and decompression.
  • Create fragmentation on the drive partition.
  • Lock and unlock memory.
  • Create large tree structures of directories and files.
  • Stress memory and heap allocation.
  • Stress the setup of security attributes and discretionary access control lists (DACL).
  • Stress the sparse file API.
  • Stress memory and file I/O operations simultaneously.

For more information about the test, see TD-21.30 System Cache Test Description and "I/O Stress Test Descriptions."

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The following software is required (at a minimum):

  • Windows .NET Server 2003, Enterprise Edition

Results Interpretation

The test generates a detailed log file of test results and displays on-screen pass or fail status. The name of the log file is IoStressRun.log. To pass the test, the test must run to completion without failure.


Chapter 22: Driver Quality Test Specification

This chapter describes Driver requirements and test tools. These requirements are specified in Microsoft Windows Logo Program System and Device Requirements.

This specification also describes the individual tests that verify the requirements for Driver Quality, under "Driver Quality Test Descriptions" later in this chapter.

Test Coverage

The driver quality tests consist of several tests that test the robustness of the driver. These tests can be broken down into tests that monitor the driver’s use of system resources and tests that verify ACPI compliance and Plug and Play Compliance.


Driver Quality Test Assertions

This section contains the test assertions for drivers.


Reference Documents for Driver Assertions

The Driver Quality tests requirements are specified in the following documents:

Microsoft Windows Driver Development Kit

http://www.microsoft.com/ddk/

Microsoft Windows Logo Program System and Device Requirements, Version 2.0

http://www.microsoft.com/hwdev/winlogo/
(listed as "WLP#" in these assertions)

PC 2001 System Design Guide and PC 99 System Design Guide

http://www.microsoft.com/hwdev/platform/pcdesign/desguide/pcguides.asp

If there are conflicts between the hardware and software specifications, refer to Microsoft Windows Logo Program (WLP) System and Device Requirements for guidance.


ChkINF Test Assertion Summary

The following table shows the test assertions associated with specific device setup classes.

Table 32-1. ChkINF Test Assertion Summary

Device setup class | Test assertion #
General ChkINF Test Assertions | 22.1.1001 – 22.1.1306
1394 Host Bus Controllers (Class = 1394) | See General ChkINF Assertions.
1394 Host Bus Controllers (Class = 1394) | See General ChkINF Assertions.
1394 Devices that support the 61883 protocol (Class = 61883) | See General ChkINF Assertions.
1394 Devices that support the AVC protocol (Class = AVC) | See General ChkINF Assertions.
Battery Devices (Class = Battery) | See General ChkINF Assertions.
Bluetooth Devices (Class = Bluetooth) | See General ChkINF Assertions.
CD-ROM Drivers (Class = CDROM) | See General ChkINF Assertions.
Disk Drives (Class=DiskDrive) | 22.24.8901
Display Adapters (Class=Display) | 22.11.6001 – 22.11.6003
Dot4 Devices (Class = Dot4) | See General ChkINF Assertions.
Dot4 Printers (Class = Dot4Print) | See General ChkINF Assertions.
Floppy Disk Controllers (Class = FDC) | See General ChkINF Assertions.
Floppy Disk Drives (Class = FloppyDisk) | See General ChkINF Assertions.
Hard Disk Controllers (Class = HDC) | See General ChkINF Assertions.
Human Input Devices (Class = HIDClass) | See General ChkINF Assertions.
Imaging Devices (Class = Image) | 22.12.2001 – 22.12.2005
IrDA Devices (Class = Infrared) | 22.13.3043 – 22.13.4207
Keyboards (Class = Keyboard) | 22.14.5001 – 22.14.5004
Multimedia (Class = Media) | 22.15.8001 – 22.15.8003
Medium Changers (Class = MediumChanger) | See General ChkINF Assertions.
Memory Technology Drivers (Class = MTD) | See General ChkINF Assertions.
Modems (Class = Modem) | 22.16.3033 – 22.16.6013
Monitors (Class = Monitor) | 22.17.3001 – 22.17.3003
Mice (Class = Mouse) | 22.18.5001 – 22.18.5004
Multifunction Devices (Class = Multifunction) | See General ChkINF Assertions.
Multi-port Serial Adapters (Class = MultiportSerial) | See General ChkINF Assertions.
Network Adapters (Class = Net) | 22.19.3043 – 22.19.4209
Network Clients (Class = NetClient) | 22.20.3043 – 22.20.4216
Network Service (Class = NetService) | 22.21.3043 – 22.21.4209
Network Transport (Class = NetTrans) | 22.22.3043 – 22.22.4215
PCMCIA Adapters (Class = PCMCIA) | See General ChkINF Assertions.
PnP Printers (Class = PnPPrinters) | See General ChkINF Assertions.
Ports - COM & LPT ports (Class = Ports) | See General ChkINF Assertions.
Printer Devices (Class=Printer) | 22.23.8521 – 22.23.8556
Processors (Class = Processor) | See General ChkINF Assertions.
1394 Devices that support the SBP2 protocol (Class = SBP2) | See General ChkINF Assertions.
SCSI and RAID Controllers (Class = SCSIAdapter) | See General ChkINF Assertions.
Security Accelerator Devices (Class = SecurityAccelerator) | See General ChkINF Assertions.
Smart Card Readers (Class = SmartCardReader) | See General ChkINF Assertions.
Storage Volumes (Class = Volume) | See General ChkINF Assertions.
System Devices (Class = System) | See General ChkINF Assertions.
Tape Drives (Class = TapeDrive) | See General ChkINF Assertions.
USB (Class = USB) | See General ChkINF Assertions.
Windows CE USB Active Sync Devices (Class = WCEUSBS) | See General ChkINF Assertions.
Activity Monitor File System Filters | See General ChkINF Assertions.
Anti-Virus File System Filters | See General ChkINF Assertions.
CFS Meta Data Server File System Filters | See General ChkINF Assertions.
Compression File System Filters | See General ChkINF Assertions.
Content Screener File System Filters | See General ChkINF Assertions.
Continuous Backup File System Filters | See General ChkINF Assertions.
Copy Protection File System Filters | See General ChkINF Assertions.
Encryption File System Filters | See General ChkINF Assertions.
File System Filters | See General ChkINF Assertions.
HSM File System Filters | See General ChkINF Assertions.
Open File Backup File System Filters | See General ChkINF Assertions.
Physical Quota Management File System Filters | See General ChkINF Assertions.
Quota Management File System Filters | See General ChkINF Assertions.
Replication File System Filters | See General ChkINF Assertions.
Security Enhancer File System Filters | See General ChkINF Assertions.
Undelete File System Filters | See General ChkINF Assertions.


Troubleshooting the Device Path Exerciser Test (HCT)

If a driver fails the Device Path Exerciser test, you can use the following steps to troubleshoot the problem. For information about command-line options and test categories, see TD-22.2 Device Path Exerciser Test Description.

The Device Path Exerciser test (Dc2.exe) runs under Driver Verifier. If a driver fails, the failure could occur while the driver is running under Driver Verifier, before the Device Path Exerciser test has been launched. To determine if this is the case, you can run the Driver Verifier test from Test Manager. For information about the Driver Verifier test, see TD-22.3 Driver Verifier.

Note A driver failure can cause the target system to become unresponsive or to generate a bug check. It is helpful to configure the target system to write the contents of memory to a file (a crash dump), so that you can attach a kernel debugger for further investigation.

Click to show or hide information. 1. Obtain the failure string

Open the Devpath.log file that corresponds to the test run when the failure occurred. Locate the Failure Point/Test Assertion and find the test command line that was used for the Device Path Exerciser test (Dc2) when the failure occurred.

570.4BC : Starting assertion 22.3.1

570.4BC : Assertion Title: The driver under test must not blue screen the system while running driver verifier.

570.4BC : Description: Running tests under driver verifier

570.7D0 : +VAR+INFO 0 :

570.7D0 : +VAR+INFO 0 : Starting test Device Path Exerciser

570.7D0 : +VAR+INFO 0 : Test command line: dc2 /hct -k /dr mydriver

If the Devpath.log file does not exist, you can also find the command line information from the Dc2.log file in the HCT\Testbin directory.

You need to identify the service name of the driver from the test command line. The service name of the driver follows the /dr option.

Click to show or hide information. 2. Enable Driver Verifier

To run the Device Path Exerciser test (Dc2.exe) under the same test conditions when the driver failure occurred, you must start the Driver Verifier program. This program requires a reboot of the system.

To enable Driver Verifier

  1. Open a command prompt, or click the Start button on the taskbar, and then click Run.
  2. Type the following command:

verifier /flags /0xFB /driver NAME [NAME ...]

Specify the name of the driver with the /driver NAME option. You can verify multiple drivers by listing the names separated by spaces.

  3. Reboot the computer so that the changes take effect.

Click to show or hide information. 3. Troubleshoot the Device Path Exerciser Test

To troubleshoot the Device Path Exerciser test

  1. In the HCT\Testbin directory, open the log file Dc2.log to see which device was tested and to determine which category of tests were running when the test failed. If you can identify the device and category, skip to step 3; otherwise, continue with step 2 below.

You may also be able to find this information in the file Dvsave.log (if it exists) that corresponds to the test run where the driver failure occurred. The Device Path Exerciser test copies the file Dc2.log to Dvsave.log.

  2. If the file Dc2.log does not give you the necessary information, you can run the Device Path Exerciser test program (Dc2.exe) with specific command-line options.
  1. Open a command prompt and browse to the HCT\testbin directory.
  2. Type the following command:

dc2 /hct -k /dr DriverServiceName /lra /ldi

Note You must use the service name for the driver with the /dr option. To determine the service name of the driver, open the Dc2.log file in the HCT\Testbin directory. Near the beginning of the log file, locate the line starting with Command Line and look for the /dr option. The value that follows the option is the service name. Use this name on the command line in step 2.

  3. After the test runs, open the file Diags.log to identify which device failed when the create-file I/O request packet was sent. When Dc2 first runs it calls ZwCreateFile for every device in the system, regardless of what you are testing.

  3. Once you identify the device that failed, identify the test category that was running and use the following command:

dc2 [/hct | /test-category] -k /dr DriverServiceName /lra /ldi /ltt

If you know the test category that failed, you can narrow the scope of the test by specifying the test category option in the command. If you are unsure of the specific test category, use the /hct option.

Note If the failing test category is IOCTL/FSCT Random Tests, note the seed=number that appears in the log file. To ensure that you consistently reproduce the failure scenario, use that seed number and append the random test seed option (/rs number) to the command line.

Note The addition of the /ltt option significantly increases the time that it takes to run the test, because of the increased logging that occurs.

  4. When the system crashes or the error occurs again, open the Dc2.log and note which test was running. Also look in the Diags.log to identify what was sent to the driver when the error occurred.
  5. You might need to do further debugging with a kernel debugger. If you have to re-run the Device Path Exerciser test, use the following command line to skip all of the passing tests and to run only those tests that are failing or those tests that have not yet run.

dc2 /hct /dr DriverServiceName /lra /ldi /ltt +r

Note (Optional) You could also verify that all tests pass with the exception of the failing test case. You can do this with the +c command line option, which causes the Device Path Exerciser test to skip previously failed cases:
dc2 /hct -k /dr DriverServiceName /lra /ldi /ltt +c

  6. Once you locate and fix the cause of the failure, you must re-run the test from Test Manager to create the passing logs. However, before you do that, you must disable Driver Verifier.

Click to show or hide information. 4. Disable Driver Verifier

To disable Driver Verifier

  1. Open a command prompt.
  2. Type the following command:

verifier /reset

  3. Reboot the computer so that the changes take effect.

Related Links

Device Path Exerciser Test: Troubleshooting Information


Selective Suspend on a USB root hub may cause excessive run times

The Device Path Exerciser test may take several days to run if Selective Suspend feature is enabled on any of the USB root hubs in the test system. Selective Suspend is a power-saving feature that allows drivers to turn off USB devices when the devices become idle.

Before running the Device Path Exerciser test, follow these instructions to disable Selective Suspend on each USB root hub in the test system. This reduces the time required to run the Device Path Exerciser test; however, the Device Path Exerciser test may still take several days to run, depending on the number of unsigned drivers in the test system.

To disable Selective Suspend on a USB root hub

  1. In Control Panel, double-click the System icon.
  2. In the System Properties dialog, click the Hardware tab, and then click the Device Manager button.
  3. In Device Manager, double-click Universal Serial Bus controllers, and then double-click USB Root Hub.
  4. In the USB Root Hub Properties dialog, click the Power Management tab, and then clear the Allow the computer to turn off this device to save power check box.
  5. Click OK.

Note If the test system implements more than one USB Root Hub, you will need to repeat steps 4 and 5 for each USB Root Hub listed in Device Manager.

Related Links

Device Path Exerciser Test: Troubleshooting Information


Troubleshooting: Dc2 has stopped making progress

The following output might appear in the command window and in the log file when the Device Path Exerciser test (Dc2) encounters a failed driver.

DC2 - Driver Test V3.2

DC2 has stopped making progress... Attempting to resume

DC2 has stopped making progress... Attempting to resume

DC2 has stopped making progress... Attempting to resume

DC2 has stopped making progress... Attempting to resume

DC2 has stopped making progress... Attempting to resume

DC2 has stopped making progress... Attempting to resume

DC2 has stopped making progress... Attempting to resume

DC2 has stopped making progress... Attempting to resume

DC2 has stopped making progress... Attempting to resume

DC2 has stopped making progress... Attempting to resume

DC2 has stopped making progress... Attempting to resume

DC2 appears to be hung. Terminating test process now.

This output, which ends with the "Terminating test process now" statement, usually indicates a problem with a device driver, a problem that prevents the driver from completing the I/O operation. If a driver has an I/O request packet (IRP) pending, the process that initiated that IRP cannot be closed until that IRP is successfully cancelled or completed. Because there is no guarantee that the Dc2 program can actually close in this situation, you will need to shutdown and restart the system.

Terminating the Dc2 process

When the message "DC2 appears to be hung. Terminating test process now," appears, wait approximately five minutes to give the process a chance to shut down.

After five minutes, if the Dc2 program appears unresponsive and the command window is still open, end the process as follows.

To end the Dc2 process

  1. Open Windows Task Manager. (Press Ctrl + Alt + Delete, or right-click on an empty space on the taskbar and click Task Manager.)
  2. From the Windows Task Manager, click the Processes tab and then select the Dc2.exe process.
  3. Click End Process. When the Task Manager Warning dialog box appears, click Yes to terminate the process.
  4. Wait approximately five minutes for the process to end. As an indicator, you can use the command window running the Dc2 process. The command window exits when the Dc2 process ends.
  5. When the Dc2 process ends, allow the WHQL Driver Verifier program to continue so that it can shutdown and restart the system.
  6. If the Dc2 process does not end, close Windows Task Manager.
  7. Switch to the WHQL Driver Verifier Test window and click the close button (the button in the upper-right corner of the window).
  8. Wait approximately one minute for the Driver Verifier test to terminate and reboot the system.
  9. If the system does not shutdown after one minute, you need to restart the system. To restart the system, press the reset button, or turn off and turn on the system.

The test log for the Device Path Exerciser test (Dvpath.log) records that this test run was stopped before completion. In Test Manager, this test run is listed as not successfully passed. The test fails, but you now have control of your system. For information about locating the cause of the failure, refer to the Dc2 test logs (Dc2.log) and see Troubleshooting the Device Path Exerciser Test (HCT).

Related Links

Device Path Exerciser Test: Troubleshooting Information


Debugging Lost I/O Request Packets

After an IOCTL test, and as part of a miscellaneous function call test, the Device Path Exerciser (Dc2) program issues a cancel request to the driver. If the driver is unable to handle the cancellation, I/O request packets (IRPs) may be lost (that is, they will never be completed by the IoCompleteRequest function call or passed to other drivers, but the device is finished with them). These lost IRPs cause the Dc2 process to stop responding. For some device paths, the I/O manager may display messages warning that IRPs didn’t cancel within an allotted time. You can use a kernel debugger to examine these lost IRPs.

To debug lost IRPs

  1. From the kernel debugger, use the following command to display a list of the current processes:

!process 0 0

  2. Select the Dc2 process, using the following command, replacing xxx with the Client ID (CID):

!process xxx

The IRP (possibly more than one) show up queued to one of the Dc2 threads.

  3. To determine which IRP was lost, use the following command, replacing xxx with the IRP address:

!IRP xxxx

Occasionally IOCTL or FSCTL requests pass parameter validation by a driver, but will be pending for a synchronous request (for example, a notify request to a driver). Usually, pressing CTRL + C ends a program, however, this command will not work with a lost IRP.

Related Links

Device Path Exerciser Test: Troubleshooting Information


General ChkINF Test Assertions

The following general Information File Syntax Checker (ChkINF) test assertions are tested in TD-22.1 ChkINF Test.

22.1.1001 This is not a valid driver INF.

Reference Document: Windows Driver Development Kit (DDK), "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1002 Unable to include item.

Full error text: "Unable to include %s. Note that only system provided INFs may be specified with the INCLUDE directive." %s resolves to the name of the INF that couldn’t be found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating Windows INF Files"
Test Description: TD-22.1 ChkINF Test

22.1.1003 Required sections must be present.

Full error text: "Section [%s] not defined." %s resolves to the name of the section not found. This applies to more than just required sections. If a user-defined section is referenced, but not present, this error is flagged. (for example, CopyFiles=Foo, but no [Foo] present)

Reference Document: Windows DDK, "INF File Sections and Directives," "Summary of INF Sections."
Test Description: TD-22.1 CheckINF Test

22.1.1004 Provider listed is Microsoft, but it should be the organization who wrote this INF.

Provider=Microsoft is illegal unless you are Microsoft.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 CheckINF Test

22.1.1005 The AlsoInstall directive is not valid in Windows NT/2000 specific sections.

The AlsoInstall directive should only be used if the INF file is provided by a vendor, and the device is installed on Windows 98/ME. For Windows 2000 and later versions, use the Include and Needs directives.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK; "Installing Core System Components for an Audio Adapter," "Installing in Windows 98/ME," and "Creating an INF File"
Test Description: TD-22.1 CheckINF Test

22.1.1006 Redefining Keys is illegal

Full error text: "Key %s redefined" %s resolves to the key that was redefined. Redefining keys is not actually illegal, but is bad form and should not be done.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 CheckINF Test

22.1.1007 Service installation section can only have one service name

Full error text: "Section [%s] already given for service named %s." The 1st %s resolves to the already referenced section, the second %s resolves to the name of the service.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5;
Windows DDK, "Creating an INF File"
Test Description: TD-22.1 CheckINF Test

22.1.1008 Signature is expected to be "$CHICAGO$","$WINDOWS 95$" or "$WINDOWS NT$

Signature="signature-name" can be any of $Windows NT$, $Chicago$, or $Windows 95$. The enclosing $ are required but these strings are otherwise case-insensitive. If the signature-name is none of these string values, the file is not accepted as a valid INF.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "INF Version Section" and Windows DDK, "Creating an INF File"
Test Description: TD-22.1 CheckINF Test

22.1.1009 Binary must not change for a given service name.

Full error text is: "Cannot use same binary %s for multiple services - already used for service named %s." %s resolves to the service name that was duplicated.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5;
Windows DDK, "Creating an INF File"

Test Description: TD-22.1 CheckINF Test

22.1.1010 ClassGUID= must match Class if both are present

Full error text: "ClassName is expected to be "%s"." The %s resolves to the expected class name based on the GUID given.

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives, INF Version Section
Test Description: TD-22.1 CheckINF Test

22.1.1011 There must only be one controlling service per driver

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 CheckINF Test

22.1.1012 DriverVer must be present and in mm/dd/yyyy,w[.x[.y[.z]]] format.

The mm/dd/yyyy value specifies the date of the driver package, including the driver files and the INF. A hyphen (-) can be used as the date field separator in place of the slash (/).

The x.y.v.z specifies an optional version number. This value is for display purposes only (for example, in the Device Manager). The OS does not use this value for driver selection.

Reference Document: Windows DDK; "INF Version Section" and "INF DriverVer Directive"
Test Description: TD-22.1 CheckINF Test

22.1.1013 Must only be one token on the left of = sign

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 CheckINF Test

22.1.1014 "Service name must not change for a given Binary.

Full error text: "Service %s already using binary %s." The 1st %s is the name of the service, the second in the name of the binary.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 CheckINF Test

22.1.1015 Each segment in DriverVer optional version must be between 0 and 65535 inclusive.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 CheckINF Test

22.1.1016 There is a max of 4 version segments in DriverVer optional segment

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 CheckINF Test

22.1.1017 Primary revision number must be greater than 0.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 CheckINF Test

22.1.1018 Required element not defined.

This error occurs when there is no non-optional element. Only flagged in a RegisterDlls section. (Note: This isn’t on the line RegisterDLLS= but in the section that is pointed to by the above directive.)

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 CheckINF Test

22.1.1022 %s should not have a value.

\"unused\" (field 3) should not have a value.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 CheckINF Test

22.1.1025 Defined item has no value

One of the following required items is undefined or has no value: destination-file-name, subkey, interface-install-section, install-section-name, hw-id, diskid, disk-description, ini-file, ini-section, ServiceName, ServiceInstallSection, ServiceName, etc.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 CheckINF Test

22.1.1028 All quoted lines must be closed.

Reference Document: Windows DDK, "INF Strings Section"
Test Description: TD-22.1 CheckINF Test

22.1.1029 The CopyFiles directive must not copy files of type .inf to the system INF directory or to any subdirectory of it.

The system will automatically copy the INF file, it should not be listed in a CopyFiles section.

Reference Document: Windows DDK, "INF CopyFiles Directive"
Test Description: TD-22.1 ChkINF Test

22.1.1030 The CopyFiles directive must not copy files of type .cat.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1031 The DelFiles directive must not delete files of type .inf.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1032 The DelFiles directive must not delete files of type .cat.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1034 Catalog files must not be listed in the SourceDiskFiles section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1039 Manufacturer section must have at least one entry.

Any INF that installs one or more devices must have a Manufacturer section. An vendor-supplied INF typically specifies only a single entry in this section. If multiple entries are specified, each entry must be on a separate line of the INF.

Note File system filter INF files use DefaultInstall sections instead of Manufacturers and Model sections.

Reference Document: Windows DDK, "INF Manufacturer Section"
Test Description: TD-22.1 ChkINF Test

22.1.1041 Last value is empty, remove trailing commas.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1042 Section listed twice in DestinationDirs.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1043 DirID value is missing.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "INF DestinationDirs Section" and Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1044 Wrong value for DirID.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "INF DestinationDirs Section" and Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1048 Strings section must have unique keys.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "INF Strings Section" and "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1050 RunOnce must use rundll32.exe

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1053 Must contain a CLASS directive.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "INF Version Section" and "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1054 Must contain a CLASSGUID directive.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "INF Version Section" and "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1055 ClassGUID must be in {nnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn} format

Each n is a hexadecimal digit.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "INF Version Section" and "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1058 Sections must have certain directives.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Sections and Directives" and "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1059 Certain classes are reserved for system use.

This Device class is either obsolete or reserved for system use.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1060 No value for %s

This occurs when a required value is not defined in one or more of the following sections:

  • BitReg section : "reg-root", "value-entry-name", "byte-mask", or "byte-to-modify"
  • Ini2Reg section: "ini-file", "ini-section", "reg-root", or "subkey"
  • RenFiles section: "old-source-file-name" or "new-dest-file-name"
  • UpdateIniFields section: "ini-file", "ini-section", or "profile-name"

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File" and "Sections and Directives"
Test Description: TD-22.1 ChkINF Test

22.1.1061 Value for EventLogType should be 'System', 'Application', or 'Security'

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1063 RegKey root values must be HKLM, etc…

The only valid regroots are: "HKCR", "HKCU", "HKLM", "HKU", and "HKR"

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1064 Catalog file must be in 8.3 format

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1065 Service cannot use both SERVICE_WIN32 and SERVICE_DRIVER

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1066 "Bad value for %s in %s."

There is a bad composite directive value for this directive.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1067 DriverVer date is in the future

The INF lists a date greater than the current date.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File" and "INF Version Section"
Test Description: TD-22.1 ChkINF Test

22.1.1068 Illegal Value for flags. (Expected null or 0)

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1069 DriverVer must be in mm/dd/yyyy format

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File" and "INF Version Section"
Test Description: TD-22.1 ChkINF Test

22.1.1071 Bad value %s for %s. Consult the DDK Documentation.

%s is the bad Value listed for item

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1072 %s not a defined model.

Models must be defined. This one was not.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1078 Description length is too long. Limit is 1024 characters.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1079 Directive: %s required (and must not be NULL) in section.

%s resolves to Provider or CmdLine.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1080 "Directive: %s required (and must not be NULL) in section.

%s resolves to DriverVer or Name.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1081 Catalogfile or Catalogfile.NT must be present in Version section and populated

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1082 Date (%s-%s-%s) is invalid.

This in not a valid date.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1085 Section directions must be one of the following:

The .ALPHA and .MIPS (and the related decorations) are not allowed. The .NTx86 and .Ntia64 decorations are not allowed in the SourceDisksFiles and SoruceDisksNames sections.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1086 "Bad value for %s in %s.".

Bad value for Day in DriverVer

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File" and "INF Version Section"
Test Description: TD-22.1 ChkINF Test

22.1.1087 Value side of directive cannot be blank.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1088 Certain parameters are required in certain values

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1089 A disabled service cannot be installed (StartType=0x4)

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1092 Explicit destination dir required (defaultdestdir entry allowed)

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1093 The system will automatically copy the inf file, it should not be listed in a copyfiles section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1094 CopyFiles directives should not list multiple filenames or mix filenames and file-list-sections.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1095 String token %s is not defined in this section.

Where %s resolves to the name of a string token. This occurs when using decorated [Strings.*] sections and not every section defines the same set of strings. Related to, but the inverse of warning 2209 (warnings are currently not part of this document).

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.1.1096 File is listed in unmatching SourceDisksFiles sections between this inf and layout.inf.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1098 Required directive cannot be set to a NULL value.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1099 Language IDs must be one of the following:

A language ID is a 16-bit value, which is the combination of a primary language ID, and a secondary language ID. The bits are allocated as follows:

+-----------------------+-------------------------+

| Sub-language ID | Primary Language ID |

+-----------------------+-------------------------+

15 10 9 0 bit

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1100 Priority value for ConfigPriority entries must be one of the following.

Valid values: HARDWIRED, DESIRED, NORMAL, SUBOPTIMAL, DISABLED, RESTART, REBOOT, POWEROFF, and HARDRECONFIG

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1101 Config type for ConfigPriority must be one of the following…

Valid Values: "Forced", "Basic", or (preferred) blank.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1102 IRQ Value for IRQConfig must be one of the following…

Valid Range: 0-15 inclusive.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1103 The hexadecimal integer value exceeds range.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1104 IRQConfig not assigned according to DDK specification

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1105 IOConfig not assigned according to DDK specification

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1106 Invalid DMA value for DMAconfig

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1107 DMAConfig not assigned according to DDK specification

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.1.1108 MEMConfig not assigned according to DDK specification

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1110 All files copied by inf must be referenced in sourcedisksfiles

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1112 Flag %s must be specified for this registry key.

Where %s is some flag value in the set (FLG_ADDREG_BINVALUETYPE, FLG_ADDREG_TYPE_BINARY, FLG_ADDREG_NOCLOBBER, FLG_ADDREG_DELVAL, FLG_ADDREG_APPEND, FLG_ADDREG_KEYONLY, FLG_ADDREG_OVERWRITEONLY, FLG_ADDREG_KEYONLY_COMMON, FLG_ADDREG_32BITKEY, FLG_ADDREG_TYPE_SZ, FLG_ADDREG_TYPE_MULTI_SZ, FLG_ADDREG_TYPE_EXPAND_SZ, FLG_ADDREG_TYPE_DWORD, FLG_ADDREG_TYPE_NONE)

Although the error gives the long name for the flag, the numeric value (as listed in the DDK docs AddReg section) must be used in the INF

This (currently) only occurs in AddReg section referenced by a DDInstall.HW or ClassInstall32 section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File" and "INF DDInstall.HW Section" and "INFClassInstall32 Section"
Test Description: TD-22.1 ChkINF Test

22.1.1113 Certain keys must be numeric

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1114 Certain keys must be 0 or 1

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1116 DeviceUpgradeUnsupported value must be numeric

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1117 Incorrect format for DeviceUpgradeUnsuported directive.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1118 Invalid value for SysSetupPnpFlags.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1119 Incorrect format for SysSetupPnpFlags directive.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1120 All entries in inf in %var% format must have corresponding entry in [Strings]

This is only true for non-quoted strings surrounded by %’s that are not within a [Strings] section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1198 INFs should use DOS-style end-of-line (<cr><lf>). This INF is using some other format.

This is Flagged when an INF is using some other (most likely UNIX <lf> only) style of end-of-line.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1301 Security descriptors must be enclosed in quotation marks.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1302 Filter drivers cannot be the controlling service.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.1.1306 File list in both a CopyFiles and [DelFiles|RenFiles] without COPYFLG_NOPRUNE (0x00002000) set.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test


Device Path Exerciser Test Assertions

Assertions in this section are tested in TD-22.2 Device Path Exerciser Test.

22.2.1 Unexpected entry points into the driver must not crash the driver

Reference document: Windows Logo Requirements Document, B1.4, B1.5
Test description: TD-22.2 Device Path Exerciser Test

22.2.2 Driver must be able to handle query functions with buffers that are too small to contain all the data to be returned.

Reference document: Windows Logo Requirements Document, B1.4, B1.5
Test description: TD-22.2 Device Path Exerciser Test

22.2.3 Driver must be able to handle IOCTL/FSCTL functions with missing buffers or buffers that are too small or contain garbage.

Reference document: Windows Logo Requirements Document, B1.4, B1.5
Test description: TD-22.2 Device Path Exerciser Test

22.2.4 Driver must be able to handle IOCTL/FSCTL with direct I/O or type3 buffers with data changing asynchronously.

Reference document: Windows Logo Requirements Document, B1.4, B1.5
Test description: TD-22.2 Device Path Exerciser Test

22.2.5 Driver must be able to handle IOCTL/FSCTL with bad pointers for type3 requests.

Reference document: Windows Logo Requirements Document, B1.4, B1.5
Test description: TD-22.2 Device Path Exerciser Test

22.2.6 Driver must be able to handle IOCTL/FSCTL and fast path query functions where the users buffer mapping may change asynchronously. Pages become unreadable at arbitrary execution points.

Reference document: Windows Logo Requirements Document, B1.4, B1.5
Test description: TD-22.2 Device Path Exerciser Test

22.2.7 Driver must be able to handle relative opens with strange file names, Opens to strange device objects like the direct device open or file system devices.

Reference document: Windows Logo Requirements Document, B1.4, B1.5
Test description: TD-22.2 Device Path Exerciser Test

22.2.8 Driver must be able to handle requests both synchronously and asynchronously to the device.

Reference document: Windows Logo Requirements Document, B1.4, B1.5
Test description: TD-22.2 Device Path Exerciser Test

22.2.9 Driver must be able to handle missing length checks for buffered IOCTLs and FSCTLs

The only protection mechanism afforded to the driver writer is the bits in the IOCTL or FSCTL that require read and/or write access to the handle (FILE_WRITE_ACCESS, FILE_READ_ACCESS). FILE_ANY_ACCESS requires no specific granted access to the file object and is used by the bulk of driver IOCTLs and FSCTLs.

Reference document: Common Driver Reliability Problems; Windows Logo Requirements Document, B1.4, B1.5
Test description: TD-22.2 Device Path Exerciser Test

22.2.10 Driver must be able to handle returning uninitialized data to the caller in the buffered I/O paths

Since the I/O manager presents variable-sized output buffers to drivers, care should be taken not to return uninitialized data to the caller. All data returned must be written by the driver to prevent information leakage problems.

Reference document: Common Driver Reliability Problems; Windows Logo Requirements Document, B1.4, B1.5
Test description: TD-22.2 Device Path Exerciser Test

22.2.11 The driver must do probes and enclose all buffer references in try/except blocks for Type3 (METHOD_ NEITHER) IOCTLs and FSCTLs

The I/O manager does no validation whatsoever for METHOD_NEITHER IOCTLs and FSCTLs. The driver must do probes and enclose all buffer references in try/except blocks.

Reference document: Common Driver Reliability Problems; Windows Logo Requirements Document, B1.4, B1.5
Test description: TD-22.2 Device Path Exerciser Test

22.2.12 Buffered I/O requests with embedded pointers need full validation

Often drivers will embed pointers within buffered requests. These requests need to be validated carefully.

Reference document: Common Driver Reliability Problems; Windows Logo Requirements Document, B1.4, B1.5
Test description: TD-22.2 Device Path Exerciser Test


Driver Verifier Test Assertions

22.3.1 The driver under test must not blue screen the system while running driver verifier.

Reference document: Windows Logo Requirements Document, B1.5, B7.1.3

Test description: TD-22.3 Driver Verifier


PMTE Test Assertions

Assertions in this section have moved to the ACPI Stress Test Assertions and are tested in TD-3.38 ACPI Stress Tests.

22.6.1 [Moved  see 3.54.1]
22.6.2 [Moved  see 3.54.2]
22.6.3 [Moved  see 3.54.3]
22.6.4 [Moved  see 3.54.4]
22.6.5 [Moved  see 3.54.5]


Plug and Play Driver Test Assertions

Assertions in this section are tested in TD-22.8 Plug and Play Driver Test.

22.8.1 The system must accept an upper filter on the target device stack

Reference document: Windows Logo Requirements Document, A1.1.3
Test description: TD-22.8 Plug and Play Driver Test

22.8.2 The system must be able to restart device stack along with the query-remove/remove path of the drivers.

Reference document: Windows Logo Requirements Document, A1.1.3
Test description: TD-22.8 Plug and Play Driver Test

22.8.3 The Plug and Play driver must allow driver updates.

Reference document: Windows Logo Requirements Document, A1.1.3
Test description: TD-22.8 Plug and Play Driver Test

22.8.4 The Plug and Play driver must accurately uninstall devices and scan for new hardware in Device Manager

Reference document: Windows Logo Requirements Document, A1.1.3
Test description: TD-22.8 Plug and Play Driver Test

22.8.5 The Plug and Play driver must perform a cancel-remove IRP when it fails a removal.

Reference document: Windows Logo Requirements Document, A1.1.3
Test description: TD-22.8 Plug and Play Driver Test

22.8.6 The Plug and Play driver must be able to accurately disable and enable devices.

Reference document: Windows Logo Requirements Document, A1.1.3
Test description: TD-22.8 Plug and Play Driver Test

22.8.7 The Plug and Play driver must be able to accurately perform a rebalance.

Reference document: Windows Logo Requirements Document, A1.1.3
Test description: TD-22.8 Plug and Play Driver Test

22.8.8 The Plug and Play driver must be able to accurately perform multiple functions and tasks.

Reference document: Windows Logo Requirements Document, A1.1.3
Test description: TD-22.8 Plug and Play Driver Test

22.8.9 The Plug and Play driver must be able to accurately accept a surprise removal of a device.

Reference document: Windows Logo Requirements Document, A1.1.3
Test description: TD-22.8 Plug and Play Driver Test


Signability Test Assertions

Assertions in this section are tested in TD-22.9 Signability Test Description.

Note These test assertions were previously referred to as the Information Catalog Syntax Checker Assertions.

22.9.1 Files on source media must expand properly via lzh or MSCab (basically files not corrupted or missing).

Reference document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test description: TD-22.9 Signability Test Description

22.9.2 Files on source media must not be zero length if copied by INF.

It is allowable to have zero length files if they are not copied by the INF.

Reference document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test description: TD-22.9 Signability Test Description

22.9.3 HWIDs must be formatted correctly.

Acceptable formats for hardware identifiers (ID) are bus specific.

Reference document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test description: TD-22.9 Signability Test Description

22.9.4 The INF file must have a Catalogfile directive that refers to the driver’s CAT file; For Windows 2000 or later, the INF file can use the Catalogfile.NT, Catalogfile.NTx86, or Catalogfile.NTia64 directives.

Reference document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test description: TD-22.9 Signability Test Description

22.9.5 Video capture device INF’s must have 'Include=ks.inf, kscaptur. inf,msyuv.dll' present.

Reference document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test description: TD-22.9 Signability Test Description

22.9.6 The DriverVer entry must be present in the INF file and must be in mm/dd/yyyy[,w.x.y.z] format

Reference document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test description: TD-22.9 Signability Test Description

22.9.7 The DriverVer entry in the INF file must specify a date later than RTM date of the operating system. After the OS RTM date, the DriverVer entry must not be postdated (dated later than the current date).

Reference document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File";
Test description: TD-22.9 Signability Test Description

22.9.8 The driver must not redistribute protected Windows system files.

In Windows 2000 and Windows XP, the INF file must not install or modify files designated as protected system files.

Information about Windows and Windows File Protection (WFP) is available at http://www.microsoft.com/hwdev/driver/sfp/wfp.asp.

For a list of the system files that are protected (at the time of this release of the Test Specification), see the WFP file list.

Reference document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test description: TD-22.9 Signability Test Description

22.9.9 Driver must not redistribute .vxd files for modem and media classes (WDM required).

Reference document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test description: TD-22.9 Signability Test Description

22.9.10 All entries specified with the CopyFiles directive must have a corresponding entry in the SourceDisksFiles section.

If your driver INF files do not copy files, you must still add the SourceDisksFiles and SourceDisksNames sections to your INF files and leave these sections empty.

Reference document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test description: TD-22.9 Signability Test Description

22.9.11 All SourceDisksFiles entries must point explicitly to a SourceDisksNames entry.

A common shortcut is to have a SourceDisksFiles entry with the equals sign and the disk ordinal, this breaks the signature. They must explicitly list a reference to a disk ordinal that exists in SourceDisksNames.

INCORRECT:

[MyCopyFiles]
Foo.sys

[SourceDisksFiles]
Foo.sys

[SourceDisksNames]
1=Otherfiles,,,
2=Interestingfiles,,,

CORRECT:

[MyCopyFiles]
Foo.sys

[SourceDisksFiles]
Foo.sys=2

[SourceDisksNames]
1=Otherfiles,,,
2=Interestingfiles,,,

Reference document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test description: TD-22.9 Signability Test Description

22.9.12 INFs must not copy .cat files.

Reference document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test description: TD-22.9 Signability Test Description

22.9.13 INFs must not copy INF files to %windir%\inf

Reference document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test description: TD-22.9 Signability Test Description


Short Driver Verifier Test Assertions

The following short driver verifier test assertions are tested in the Shrtver test.

22.10.1 The loading of a driver must not interfere with other components on the system.

Reference Document: Windows Logo Requirements Document, B1.5, B7.1.3

Test Description: TD-22.10 Short driver verifier test description


ChkINF Test (Class=Display) Assertions

The following display device class-specific ChkINF assertions are tested in TD-22.1 ChkINF Test.

22.11.6001 Directive %s invalid in this section.

Where %s resolves to invalid directive Name.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.11.6002 %s takes a single numeric parameter.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.11.6003 The only values %s allows are 0 and 1.

Where %s resolves to item in error.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test


ChkINF Test (Class=Image) Assertions

The following Image device class specific ChkINF assertions are tested in TD-22.1 ChkINF Test.

22.12.2001 The value of %s should be %s.

Where %s resolves to invalid directive Name.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.12.2002 Section [%s] could not be found.

Required section not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.12.2003 %s is expected to %s.

Where %s resolves to item in error.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.12.2004 Too many values for directive %s

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.12.2005 Unrecognized directive: %s

Where %s resolves to illegal directive.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test


ChkINF Test (Class=Infrared) Assertions

The following IrDA device class specific ChkINF assertions are tested in TD-22.1 ChkINF Test.

22.13.3043 Keyword Characteristics not defined in install section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.3044 Keyword BusType not defined in install section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.3045 Keyword Compatible not defined in Version section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.3046 Keyword Compatible should be equal to 1 if Signature is \$CHICAGO\$.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.4001 BusType does not match the NetCard model.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.4002 Characteristics can have only one of NCF_VIRTUAL,NCF_PHYSICAL & NCF_WRAPPER.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.4003 NCF_NO_SERVICE cannot be used with NCF_VIRTUAL or NCF_PHYSICAL.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.4005 Invalid interface used in Addreg section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.4006 Lower interface cannot have an install section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.4007 Reserved Word used as Parameter Key.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.4008 Invalid Value-Name for Parameter Key.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.4009 NCF_HAS_UI should be one of the characteristics for advanced parameters.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.4011 The AddService ServiceName parameter must match the NDI\\Service entry in the Registry.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.4030 Section [%s] is empty. It should contain \"*PNP8132\".

Required section not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.4031 String \"*PNP8132\" is missing for section [%s].

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.4032 Wrong strings in section [%s]. Only \"*PNP8132\" is allowed.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.4033 Incorrect number of parameters, expected %s.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.4100 Invalid Priority Value for ConfigPriority.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.4101 Invalid Config Type for ConfigPriority.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.4102 Invalid IRQ value for IRQconfig.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.4103 The hexadecimal integer value exceeds range.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.4104 IRQConfig not assigned according to DDK specification.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.4105 IOConfig not assigned according to DDK specification.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.4106 Invalid DMA value for DMAconfig.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.4107 DMAConfig not assigned according to DDK specification.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.4108 MEMConfig not assigned according to DDK specification.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.4200 Invalid value for ServiceType in Services Install Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.4201 Invalid value for StartType in Services Install Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.4202 Invalid value for ErrorControl in Services Install Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.4203 ServiceBinary value not defined in Services Install Section

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.4204 Invalid value for LoadOrderGroup in Services Install Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.4205 Invalid value for StartName in Services Install Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.4206 Services section not defined for \"%s\" model.

Required section not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.13.4207 "\"%s\" file not allowed in CopyFiles section.

Illegal file found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test


ChkINF Test (Class=Keyboard) Assertions

The following Keyboard device class specific ChkINF assertions are tested in TD-22.1 ChkINF Test.

22.14.5001 No corresponding [%s] section is defined.

Defined section not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.14.5002 Unknown directive: %s.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.14.5003 Service %s not valid for this model.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.14.5004 SharedDriver should be in the format 'SharedDriver=%DDInstall Section%,%Text String%.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test


ChkINF Test (Class=Media) Assertions

The following Media device class specific ChkINF assertions are tested in TD-22.1 ChkINF Test.

22.15.8001 GUID %s requires the non-localizable reference string \"%s\".

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.15.8002 All audio port device install sections must contain 'NEEDS=%s'.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.15.8003 All audio port device install sections must contain 'INCLUDE=%s’.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test


ChkINF Test (Class=Modem) Assertions

The following Modem device class specific ChkINF assertions are tested in TD-22.1 ChkINF Test.

22.16.3033 Illegal characters in string %s.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3034 Rank0 and Rank1 can't be the same.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3035 PCMCIA\\ prefix required for PCMCIA-modem id.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3036 PCMCIA id required.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3038 Star (*) format ID should be used for ISAPNP modems.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3040 Star (*) format ID should be used for BIOS modems.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3042 Keyword ADDREG not defined.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3043 UNIMODEM ID is not of the expected length..

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3045 Section [%s.NORESDUP] expected but missing.

Required section not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3046 \"HKR, %s\" already defined in this section. Keep last definition.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3047 Mandatory field <Key> is missing.

Required Item not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3049 Mandatory field [Value-entry-name] should be blank.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3050 %s does not have any Answer.

Required item not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3051 %s does not have any Hangup.

Required item not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3052 %s does not have any Init.

Required item not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3053 %s does not have any Reset.

Required item not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3054 More than one Reset in model %s.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3055 %s does not have any Monitor.

Required item not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3056 %s does not have any Settings,Prefix.

Required item not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3057 %s does not have any Settings,DialPrefix.

Required item not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3058 %s does not have any Settings,DialSuffix.

Required item not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3059 %s does not have any Settings,Terminator.

Required item not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3060 %s does not have any Responses.

Required item not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3061 %s does not have any Properties.

Required item not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3062 %s has more than one \"Properties\" entry.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3063 %s does not have any InactivityScale.

Required item not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3064 %s\'s properties expect a key \"Settings, %s\" which is not defined.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3065 %s: Command %s, level #%d not found.

Required item not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3066 %s: Command %s, levels #%d-#%d not found.

Required items not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3067 AT Command should not start with spaces.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3068 AT-Command \"None\" should not end with \"<CR>\".

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3069 AT-Command \"None\" suspicious.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3070 AT-Command \"NoResponse\" should not end with \"<CR>\".

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3071 AT-Command \"NoResponse\" suspicious.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3072 AT-Command string should start with \"AT\".

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3073 AT-Command string should end with \"<CR>\".

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3074 <CELLULAR_O> key - can no longer be used.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3075 Expect <Key> to be a quoted string.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3076 <Key> can't be empty string.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3077 Expect response to be in binary.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3078 Properties should have 8 DWORDS.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3079 InactivityScale should have 1 DWORD.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3080 <Value> is expected to have only hex digits.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3081 Expect <Value> to be a quoted string.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3082 <Value> can't be empty string.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3084 First field should be one of the HKR, HKU, HKLM, HKCR or HKCU keywords.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3086 Section [%s] is empty. It should contain \"*PNP0500\".

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3087 String \"*PNP0500\" is missing for section [%s].

Required section not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3088 Wrong strings in section [%s]. Only \"*PNP0500\" is allowed.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3089 A verbosity response of either V1 or V0 must be given for Init Settings.

Required section not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3090 Empty INF file.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3091 UNIMODEM id required for MF-modems.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3092 %s has more than one \"DCB\" entry.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3093 DCB structure should have 26 bytes.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3094 %s has more than one \"DeviceType\" entry.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3095 %s does not have any DeviceType.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3096 Too many bytes defined for DeviceType entry.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3097 DeviceType should be 01, 02 or 03.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3098 230K port declared for external device %s.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3099 VoiceProfile should have 4 bytes.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3100 %s: Monitor suspicious. Expect 1: \"ATS0=0<cr>\" and 2: \"None\".

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3101 SERENUM modem: no unimodem ID is permitted for the same parameterization.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3102 Identifier %s, only UNIMODEM ids are allowed in NORESDUP section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3104 Padded responses preferred.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3105 %s, duplicate rank 0 Id in file(s) \"%s\".

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3106 Voice modem \"%s\" (%s), minimal voice keys not present (Enumerator, VoiceProfile).

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3108 PnP ID declared rank 1 or greater (probably rank 0). Use one PnP rank 0 ID per device.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3109 Responses should have 10 bytes.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3114 Wrong value for response state.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3115 Wrong value for negotiated option.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3123 Missing %d basic numeric responses: %s.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3124 \"V1\" found but verbose responses are missing.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3125 \"V\" or \"V0\" found but numeric responses are missing.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3127 Missing %d basic verbose responses: %s.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3128 %d modems have the same name \"%s\" under manufacturer \"%s\".

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3129 Additional response \"%s\" should be given when stripped responses are used.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3130 Caller ID enabled in voice profile but \"EnableCallerID\" key not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3131 Distinctive ring enabled in voice profile but \"EnableDistinctiveRing\" key not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3132 \"VariableTerminator\" key needed if Caller ID or Distinctive ring enabled.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3133 Generate Digit enabled in voice profile but \"GenerateDigit\" key not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3134 Handset enabled in voice profile but \"%s\" key not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3136 SpeakerPhone enabled in voice profile but \"%s\" key not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3137 SpeakerPhoneSpecs should have 16 bytes.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3139 Mute enabled in voice profile but \"%s\" key not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3140 Voice enabled in voice profile but \"%s\" key not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3142 Set Baud Rate bit enabled in voice profile but \"VoiceBaudRate\" key not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3143 Parameter Strings \"%s\" not allowed in \"%s\" section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3144 \"%s\" model is missing \"%s\" AddReg section entry required for CallerID modems.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3145 AddService directive not present in \"%s\" section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3146 ServiceType directive should be 1 for the Service Install section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3147 StartType directive should be 0,1,2,3 or 4 for the Service Install section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3148 ErrorControl directive should be 0,1,2 or 3 for the Service Install section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3149 ServiceBinary directive should not be empty for the Service Install section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3150 LoadOrderGroup directive should be equal to \"Base\" for the Service Install section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3151 Service Install section not present for the AddService directive.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3152 \"%s\" [CopyFiles] not correct as defined in DestinationDirs section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3153 XformID for WaveDriver should be double byte entry and not dword.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.3200 PortDriver entry should be wdmmdmld.vxd for driver-based modems and serial.vxd for controller-based modems.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.6001 Command string is not quoted string.

This is a FAX specific error.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.6002 Missing command string.

This is a FAX specific error.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.6003 Invalid value for command string. Value should be \"19200\", \"38400\", \"57600\", \"115200\" or \"230400\".

This is a FAX specific error.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.6004 "Invalid value for command string. Value should be \"0\" or \"1\".

This is a FAX specific error.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.6005 Invalid value for command string. Value should be \"1\", \"2\" or \"20\".

This is a FAX specific error.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.6006 Invalid value for command string. Value should be \"14400\", \"12000\", \"9600\", \"7200\", \"4800\", \"2400\" or \"0\".

This is a FAX specific error.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.6007 \"HKR, Fax, EnableV17Send\" conflicts with \"HKR, Fax, HighestSendSpeed\".

This is a FAX specific error.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.6008 \"HKR, Fax, HighestSendSpeed\" conflicts with \"HKR, Fax, EnableV17Send\".

This is a FAX specific error.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.6009 \"HKR, Fax, HighestSendSpeed\" is slower than \"HKR, Fax, LowestSendSpeed\".

This is a FAX specific error.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.6010 \"HKR, Fax, LowestSendSpeed\" is faster than \"HKR, Fax, HighestSendSpeed\".

This is a FAX specific error.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.6011 %s does not have \"HKR, %s %s\".

This is a FAX specific error.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.6012 %s does not have \"HKR, %s\".

This is a FAX specific error.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.16.6013 %s does not have Fax.

This is a FAX specific error.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test


ChkINF Test (Class=Monitor) Assertions

The following MONITOR device class specific Information File Syntax Checker assertions are tested in TD-22.1 ChkINF Test.

22.17.3001 Missing a required regkey! (\"HKR,,NoInstallClass,,1\").

Required section not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.17.3002 Missing a required regkey! (\"HKR,,Icon,,-1\").

Required section not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.17.3003 Missing a required regkey! (\"HKR,,,,%MonitorClassName%\").

Required section not found.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test


ChkINF Test (Class=Mouse) Assertions

The following Mouse device class specific ChkINF assertions are tested in TD-22.1 ChkINF Test.

22.18.5001 No corresponding [%s] section is defined.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.18.5002 Unknown directive: %s.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.18.5003 Service %s not valid for this model.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.18.5004 SharedDriver should be in the format 'SharedDriver=%DDInstall Section%,%Text String%'.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test


ChkINF Test (Class=Net) Assertions

The following Network Adapter device class specific ChkINF assertions are tested in TD-22.1 ChkINF Test.

22.19.3043 Keyword Characteristics not defined in install section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.3044 Keyword BusType not defined in install section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.3045 Keyword Compatible not defined in Version section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.3046 Keyword Compatible should be equal to 1 if Signature is \$CHICAGO\$.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.4001 BusType does not match the NetCard model.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.4002 Characteristics can have only one of NCF_VIRTUAL,NCF_PHYSICAL & NCF_WRAPPER.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.4003 NCF_NO_SERVICE cannot be used with NCF_VIRTUAL or NCF_PHYSICAL.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.4005 Invalid interface used in Addreg section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.4006 Lower interface cannot have an install section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.4007 Reserved Word used as Parameter Key.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.4008 Invalid Value-Name for Parameter Key.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.4009 NCF_HAS_UI should be one of the characteristics for advanced parameters.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.4011 The AddService ServiceName parameter must match the NDI\\Service entry in the Registry.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.4030 Section [%s] is empty. It should contain \"*PNP8132\".

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.4031 String \"*PNP8132\" is missing for section [%s].

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.4032 Wrong strings in section [%s]. Only \"*PNP8132\" is allowed.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.4033 Incorrect number of parameters, expected %s.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.4100 Invalid Priority Value for ConfigPriority.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.4101 Invalid Config Type for ConfigPriority.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.4102 Invalid IRQ value for IRQconfig.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.4103 The hexadecimal integer value exceeds range.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.4104 IRQConfig not assigned according to DDK specification.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.4105 IOConfig not assigned according to DDK specification.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.4106 Invalid DMA value for DMAconfig.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.4107 DMAConfig not assigned according to DDK specification.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.4108 MEMConfig not assigned according to DDK specification.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.4200 Invalid value for ServiceType in Services Install Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.4201 Invalid value for StartType in Services Install Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.4202 Invalid value for ErrorControl in Services Install Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.4203 ServiceBinary value not defined in Services Install Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.4204 Invalid value for LoadOrderGroup in Services Install Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.4205 Invalid value for StartName in Services Install Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.4206 Services section not defined for \"%s\" model.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.4207 \"%s\" file not allowed in CopyFiles section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test

22.19.4208 Period required as prefix for MillenniumPreferred Directive in Version Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test


ChkINF Test (Class= NetClient) Assertions

The following Network Clients device class specific ChkINF assertions are tested in TD-22.1 ChkINF Test.

22.20.3043 Keyword Characteristics not defined in install section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.3045 Keyword Compatible not defined in Version section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.3046 Keyword Compatible should be equal to 1 if Signature is \$CHICAGO\$.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4003 NCF_NO_SERVICE cannot be used with NCF_VIRTUAL or NCF_PHYSICAL.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4004 Characteristics cannot have any of NCF_VIRTUAL, NCF_PHYSICAL, NCF_SOFTWARE_ENUMERATED, NCF_MULTIPORT_INSTANCED_ADAPTER, or NCF_FILTER.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4005 Invalid interface \"%s\" used in Addreg section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4006 Lower interface cannot have an install section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4009 NDI key should be created by Addreg section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4010 CoServices or ExcludeSetupStartServices key of Add-Registry Section should be of type REG_MULTI_SZ.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4011 The AddService ServiceName parameter must match the NDI\\Service entry in the Registry.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4033 Incorrect number of parameters, expected %s.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4100 CoServices Key should be present if a Service is defined in Addreg Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4101 \"%s\" Service found in ExcludeSetupStartServices not present in CoServices Key.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4102 Format for CLSID GUID key in AddReg section is wrong.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4103 Winsock Install Section not present.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4104 AddSock Directive not present in Winsock Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4105 TransportService value is not defined in Install Service Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4106 Format for ProviderID GUID key in Winsock Install section is wrong.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4107 Invalid Namespace \"%s\" used in Winsock Install section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4108 Winsock Remove Install Section not present.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4109 DelSock Directive not present in Winsock Remove Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4110 TransportService not matching for Winsock Install and Winsock Remove Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4111 ProviderID not matching for Winsock Install and Winsock Remove Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4112 TransportService Directive not present in Winsock Install Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4113 HelperDllName Directive not present in Winsock Install Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4114 MaxSockAddrLength Directive not present in Winsock Install Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4115 MinSockAddrLength Directive not present in Winsock Install Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4116 DelService value is not defined in Install Service Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4117 DelService Directive not present in Services Remove Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4120 Both Upper and Lower Interfaces should be present in AddReg Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4206 Services section not defined for \"%s\" model.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4207 \"%s\" file not allowed in CopyFiles section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4208 The values are incorrectly specified in RegisterDLL section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4210 DisplayName Directive not present in PrintProvider Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4211 PrintProviderName Directive not present in PrintProvider Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4212 PrintProviderDLL Directive not present in PrintProvider Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4213 NetworkProvider Key not present in add-registry section specified in Service Install Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4214 NetworkProvider Name SubKey not present in add-registry section specified in Service Install Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4215 NetworkProvider ProviderPath SubKey not present in add-registry section specified in Service Install Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.20.4216 Period required as prefix for MillenniumPreferred Directive in Version Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test


ChkINF Test (Class= NetService) Assertions

The following Network Service device class specific ChkINF assertions are tested in TD-22.1 ChkINF Test.

22.21.3043 Keyword Characteristics not defined in install section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.21.3045 Keyword Compatible not defined in Version section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.21.3046 Keyword Compatible should be equal to 1 if Signature is \$CHICAGO\$.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.21.4003 NCF_NO_SERVICE cannot be used with NCF_VIRTUAL or NCF_PHYSICAL.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.21.4004 Characteristics cannot have any of NCF_VIRTUAL, NCF_PHYSICAL, NCF_SOFTWARE_ENUMERATED, NCF_MULTIPORT_INSTANCED_ADAPTER, or NCF_FILTER.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.21.4005 Invalid interface \"%s\" used in Addreg section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.21.4006 Lower interface cannot have an install section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.21.4009 NDI key should be created by Addreg section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.21.4010 CoServices or ExcludeSetupStartServices key of Add-Registry Section should be of type REG_MULTI_SZ.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.21.4011 The AddService ServiceName parameter must match the NDI\\Service entry in the Registry.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.21.4033 Incorrect number of parameters, expected %s.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.21.4100 CoServices Key should be present if a Service is defined in Addreg Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.21.4101 \"%s\" Service found in ExcludeSetupStartServices not present in CoServices Key.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.21.4102 Format for CLSID GUID key in AddReg section is wrong.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.21.4116 DelService value is not defined in Install Service Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.21.4117 DelService Directive not present in Services Remove Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.21.4120 Both Upper and Lower Interfaces should be present in AddReg Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.21.4206 Services section not defined for \"%s\" model.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.21.4207 \"%s\" file not allowed in CopyFiles section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.21.4208 The values are incorrectly specified in RegisterDLL section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.21.4209 Period required as prefix for MillenniumPreferred Directive in Version Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test


ChkINF Test (Class= NetTrans) Assertions

The following Network Transport device class specific ChkINF assertions are tested in TD-22.1 ChkINF Test.

22.22.3043 Keyword Characteristics not defined in install section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.3045 Keyword Compatible not defined in Version section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.3046 Keyword Compatible should be equal to 1 if Signature is \$CHICAGO\$.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4003 NCF_NO_SERVICE cannot be used with NCF_VIRTUAL or NCF_PHYSICAL.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4004 Characteristics cannot have any of NCF_VIRTUAL, NCF_PHYSICAL, NCF_SOFTWARE_ENUMERATED, NCF_MULTIPORT_INSTANCED_ADAPTER or NCF_FILTER.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4005 Invalid interface \"%s\" used in Addreg section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4006 Lower interface cannot have an install section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4009 NDI key should be created by Addreg section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4010 CoServices or ExcludeSetupStartServices key of Add-Registry Section should be of type REG_MULTI_SZ.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4011 The AddService ServiceName parameter must match the NDI\\Service entry in the Registry.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4033 Incorrect number of parameters, expected %s.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4100 CoServices Key should be present if a Service is defined in Addreg Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4101 \"%s\" Service found in ExcludeSetupStartServices not present in CoServices Key.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4102 Format for CLSID GUID key in AddReg section is wrong.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4103 Winsock Install Section not present.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4104 AddSock Directive not present in Winsock Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4105 TransportService value is not defined in Install Service Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4106 Format for ProviderID GUID key in Winsock Install section is wrong.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4107 Invalid Namespace \"%s\" used in Winsock Install section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4108 Winsock Remove Install Section not present.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4109 DelSock Directive not present in Winsock Remove Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4110 TransportService not matching for Winsock Install and Winsock Remove Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4111 ProviderID not matching for Winsock Install and Winsock Remove Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4112 TransportService Directive not present in Winsock Install Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4113 HelperDllName Directive not present in Winsock Install Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4114 MaxSockAddrLength Directive not present in Winsock Install Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4115 MinSockAddrLength Directive not present in Winsock Install Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4116 DelService value is not defined in Install Service Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4117 DelService Directive not present in Services Remove Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4120 Both Upper and Lower Interfaces should be present in AddReg Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4206 Services section not defined for \"%s\" model.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4207 \"%s\" file not allowed in CopyFiles section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4208 The values are incorrectly specified in RegisterDLL section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4209 PrintMonitor Install Section not present.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4210 AddMonitor Directive not present in PrintMonitor Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4211 PrintMonitorName Directive not present in PrintMonitor Install Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4212 PrintMonitorDLL Directive not present in PrintMonitor Install Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4213 PrintMonitor Remove Install Section not present.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4214 DelMonitor Directive not present in PrintMonitor Remove Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.22.4215 Period required as prefix for MillenniumPreferred Directive in Version Section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test


ChkINF Test (Class=Printer) Assertions

The following printer device class specific ChkINF assertions are tested in TD-22.1 ChkINF Test.

22.23.8521 No CONFIGFILE directive was found in DDInstall section or referenced DATASECTION.

The required directive is missing.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8522 No DRIVERFILE directive was found in DDInstall section or referenced DATASECTION.

The required directive is missing.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8523 No DATAFILE directive was found in DDInstall section, referenced DATASECTION, or via implied section name.

The required directive is missing (and the DDInstall section name isn't the name of a file listed in SourceDisksFiles).

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8524 Printer Model \"%s\" install section [%s] not defined in this INF.

Install section must be defined in this INF (you can't use the #include directive to reference another INF file)

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8525 Printer Model \"%s\" install section [%s] conflicts with NTPrint.inf defined section of the same name.

There is an error on Printer Model line in the INF. The INF should not use sections names that also appear in the NTPrint.inf file (sections might get merged together).

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8526 DataSection directive %s may only occur once.

Only a single instance of this directive (CONFIGFILE, DATAFILE, DRIVERFILE, DEFAULTDATATYPE, HELPFILE, LANGUAGEMONITOR, PRINTPROCESSOR, VENDORSETUP) is allowed per DataSection.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8527 DDInstall section directive %s may only occur once.

Only a single instance of this directive (DATASECTION, DATAFILE, CONFIGFILE, DRIVERFILE, HELPFILE, LANGUAGEMONITOR, PRINTPROCESSOR, VENDORSETUP) is allowed per Install section.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8528 DDInstall section and referenced DATASECTION both define a %s directive.

The directive (CONFIGFILE, DATAFILE, DRIVERFILE, HELPFILE, LANGUAGEMONITOR, PRINTPROCESSOR, VENDORSETUP) occurs in both the DDInstall section and DDInstall section referenced DATASECTION.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8529 Invalid format. Should be of the form: %s

The directive's data is formatted incorrectly (applies to LanguageMonitor, PrintProcessor, and VendorSetup directives).

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8530 %s \"%s\" is not found in any SourceDisksFiles section.

The file is not listed in the SourceDisksFiles sections of the INF, NTPrint.INF, or Layout.INF (applies to the LanguageMonitor's MonitorDLLName).

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8531 %s \"%s\" is not found in a SourceDisksFiles section in this INF.

File is not listed in the SourceDisksFiles sections of the INF (applies to PrintProcessor's PrintProcDLLName and VendorSetup's DLLFileName).

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8532 Printer install section [%s] conflicts with NTPrint.inf section of the same name.

The INF files should not use sections names that also occur in NTPrint.inf file (the sections might get merged together).

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8533 Printer Model \"%s\" install section [%s] occurs more than once.

(Error on Printer Model line) The install section names must be unique. Check for a typo or a cut-and-paste error in the INF.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8534 Install section [%s] occurs more than once.

(Error on Install Section line) The install section names must be unique. Check for a typo or a cut-and-paste error in the INF.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8535 Printer Model \"%s\" install section [%s] exists with some but not all valid CPU decorated forms (".NTx86, .NTIA64, .AMD64")

If an Install section is decorated with a CPU type, it should also exist for every CPU type (.NTx86, .NTIA64, .AMD64).

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8536 \"%s\" is not a model name listed in this INF.

In the PreviousNames section, a current model name is given that does not appear in this INF.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8537 Invalid format. No previous names listed.

In the PreviousNames section, no previous names appear after the current model name.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8538 Invalid format. Missing previous name entry (extra commas?).

In the PreviousNames section, a previous name is blank.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8539 Previous name \"%s\" is a currently active model name (referenced in NTPrint.inf).

In the PreviousNames section, a name listed as a previous name is a current name in the NTPrint.inf file

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8540 Do not copy file %s directly, use INCLUDE=NTPrint.inf & appropriate NEEDS=.

Explicit references to select files (UNIDRV.DLL, UNIDRVUI.DLL, UNIRES.DLL, UNIDRV.HLP, STDNAMES.GPD, TTFSUB.GPD, PJLMON.DLL, sRGB.ICM, LOCALE.GPD) are inappropriate. Use the Include and Needs directives in the INF.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8541 File %s is not listed in the [SourceDisksFiles] section(s) of this INF.

File must be listed in the SourceDisksFiles section of the INF.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8542 File %s conflicts with file shipped in the OS (referenced in %s).

File has the same name as a system file (and is not allowed to be redistributed)

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8543 Install section [%s] not defined in this INF.

The Install section is not defined in this INF, but was found in an INF referenced with the Include directive.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8544 Install section [%s] conflicts with NTPrint.inf section of the same name (INCLUDE=NTPrint.inf exists).

(CopyFile referenced section) The INF file should not use sections names that also occur in NTPrint.inf (the sections might get merged together).

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8545 File %s ships with the OS. Do not list it in the [SourceDisksFiles] section(s) of this INF. Use %s instead.

The file is a Windows Operating System file; although the file cannot be redistributed, it may be referenced (and thus installed) by this INF as long as an Include=NTPrint.inf (or Layoutfile=Layout.inf) directive is used.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8546 File %s ships with the OS. Use %s to reference it.

The file is a Windows Operating System file; although the file cannot be redistributed, it may be referenced (and thus installed) by this INF as long as an Include=NTPrint.inf (or Layoutfile=Layout.inf) directive is used.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8547 \"%s\" is not an OEM (Manufacturer) name listed in this INF.

(OEM URLs section) The OEM name does not appear in the Manufacturers section of this INF.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8548 \"%s\" is not recognized (not OEMDriverFile[1-9] or OEMConfigFile[1-9]).

(OEMFiles section) Directives must be named OEMDriverfilex or OEMConfigFilex.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8549 %s is improperly numbered, expected %s%d.

(OEMFiles section) The OEMDriverfilex or OEMConfigFilex directives must be consecutively ordered.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8550 \"%s\" is not a DLL name.

(OEMFiles section) The OEMDriverfilex or OEMConfigFilex files must have .DLL extension.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8551 \"%s\" is not an ID listed in this INF.

(ControlFlags) The ID listed with the ExcludeFromSelect or the InteractiveInstall directives is not found in this INF. Check the ID to see if it has been typed correctly.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8552 Missing '\\' after Pnp Bus enumerator '%s'.

The hardware ID and compatible IDs must have a backslash (\) after any bus enumerator name ("LPTENUM, USBPRINT, DOT4PRT, MF").

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8553 Apparent Pnp Bus enumerator '%s' is not recognized as a valid enumerator ("LPTENUM, USBPRINT, DOT4PRT, MF").

The hardware ID or compatible ID contains a backslash (\), but the name of the enumerator before the backslash (\) is not valid.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8554 Install section [%s] conflicts with section [%s] already found for model '%s' under [%s].

The model is listed under more than one Manufacturer section (for example, multiple decorations), but uses different install sections.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8555 Previous name \"%s\" is an active model name listed in this INF.

The Previous name is also a current name.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test

22.23.8556 PnP Hardware ID [%s] conflicts with HWid for model '%s'.

Two different models have the same hardware ID, and that hardware ID is not listed with the InteractiveInstall directive.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"

Test Description: TD-22.1 ChkINF Test


ChkINF Test (Class=DiskDrive) Assertions

The following Disk Drive device class specific ChkINF assertions are tested in TD-22.1 ChkINF Test.

22.24.8901 The value for DISKCIPRIVATEDATA must not have bit 2 (0x4) set.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows DDK, "Creating an INF File"
Test Description: TD-22.1 ChkINF Test


Public Import Test Assertions

These assertions are tested in TD-22.11 Public Import Test Description.

22.25.1 The following list of device driver interfaces (DDI) must not be used and will be flagged as a failure. See the Public Import Test Illegal List.

Reference document: WLP# - B12.1.1.1
Test description: TD-22.11 Public Import Test Description

22.25.2 The following list of device driver interfaces (DDI) are not recommended to be used and will be flagged as a warning. See the Public Import Test Illegal List.

Reference document: WLP# - B12.1.1.1
Test description: TD-22.11 Public Import Test Description


Driver Quality Test Descriptions

This section describes the Driver Quality tests.

TD-22.1 ChkINF Test

Test Kit: HCT 11, HCT 10

The ChkINF test verifies the structure and syntax of device driver INF files. An INF file is a text file that is required for Windows device driver installation. The INF file contains device and driver information, including the driver files, registry entries, device IDs, catalog files, and version information required to install the device or driver. The exact contents and format of the INF file depend on the device setup class.

The ChkINF test is continually enhanced to support additional device classes and to handle new platform extensions, INF sections, and directives.

Click to show or hide information. Overview

The ChkINF test uses a Perl script to check the INF files.

A Perl interpreter is supplied with the HCT kit. When you run the test from Test Manager, the test results are written to the Infcheck.log file.

When you run the ChkINF test from the command line, the test writes the results to a summary file, which presents the results in HTML format. The summary file includes a list of the errors and warnings detected in each INF file, and includes an annotated version of the INF file that shows where the errors and warnings occurred. For more information about what is recorded in the file, please see the "Limitations" section in this test description.

Note The ChkINF test does not support Windows 98 or Windows Millennium INF files.

The ChkINF test includes support for all general INF sections and directives that apply to all classes of devices. The ChkINF test includes specific device class support for the following device setup classes:

1394 Host Bus Controllers (Class = 1394)
1394 Devices that support the 61883 protocol (Class = 61883)
1394 Devices that support the AVC protocol (Class = AVC)
1394 Devices that support the SBP2 protocol (Class = SBP2)
Battery Devices (Class = Battery)
Bluetooth Devices (Class = Bluetooth)
CD-ROM Drivers (Class = CDROM)
Disk Drives (Class = DiskDrive)
Display Adapters (Class = Display)
Dot4 Devices (Class = Dot4)
Dot4 Printers (Class = Dot4Print)
Floppy Disk Controllers (Class = FDC)
Floppy Disk Drives (Class = FloppyDisk)
Hard Disk Controllers (Class = HDC)
Human Input Devices (Class = HIDClass)
Imaging Devices (Class = Image)
IrDA Devices (Class = Infrared)
Keyboards (Class = Keyboard)
Medium Changers (Class = MediumChanger)
Memory Technology Drivers (Class = MTD)
Mice (Class = Mouse)
Modems (Class = Modem)
Monitors (Class = Monitor)
Multifunction Devices (Class = Multifunction)
Multimedia (Class = Media)
Multi-port Serial Adapters (Class = MultiportSerial)
Network Adapters (Class = Net)
Network Clients (Class = NetClient)
Network Service (Class = NetService)
Network Transport (Class = NetTrans)
PCMCIA Adapters (Class = PCMCIA)
Ports - COM & LPT serial ports (Class = Ports)
PnP Printers (Class = PnPPrinters)
Printer Devices (Class=Printer)
Processors (Class = Processor)
SCSI and RAID Controllers (Class = SCSIAdapter)
Security Accelerator Devices (Class = SecurityAccelerator)
Smart Card Readers (Class = SmartCardReader)
Storage Volumes (Class = Volume)
System Devices (Class = System)
Tape Drives (Class = TapeDrive)
USB (Class = USB)
Windows CE USB Active Sync Devices (Class = WCEUSBS)

The ChkINF test now checks for INF files that are used for installing file system filter drivers. The ChkINF test includes specific class support for the following classes of file system filter drivers:

Activity Monitor File System Filters
Anti-Virus File System Filters
CFS Meta Data Server File System Filters
Compression File System Filters
Content Screener File System Filters
Continuous Backup File System Filters
Copy Protection File System Filters
Encryption File System Filters
File System Filters
HSM File System Filters
Open File Backup File System Filters
Physical Quota Management File System Filters
Quota Management File System Filters
Replication File System Filters
Security Enhancer File System Filters
Undelete File System Filters

For more information on file system filter drivers, see the Installable File System (IFS) kit at http://www.microsoft.com/ddk/ifskit/.

Note that the ChkINF test has not been extensively tested. Please review your results carefully.

Click to show or hide information. Running the ChkINF test (from the command line)

Because the ChkINF test is a Perl script, you must obtain a Perl interpreter to use the script.

If you are running the test from the HCT kit, a Perl interpreter is included in the HCT\Testbin directory.

The ChkINF test requires a Perl interpreter that is version 5.003_07 or later. The ChkINF test should work with any version of Perl 5.0 or later but it has not been tested with any version previous to 5.003_07.

The ChkINF test has been tested with the following Perl interpreters:

  • GNU Perl 5.005_02 compiled for Win32®
  • GNU Perl 5.6.0 compiled for Win32
  • Perl for Win32 5.003_07 from ActiveWare Internet Corp.
  • ActivePerl 5.6.1.631 from ActiveState (http://www.activestate.com)

Microsoft neither endorses nor recommends any specific Perl interpreters.

Usage

The ChkINF test ships with the Windows DDK. If you have the Windows DDK, the ChkINF files are located in the %DDKRoot%\Tools\ChkINF subdirectory.

If you have installed the HCT kit, the ChkINF files are located in the HCT\Testbin directory.

To simplify running the Perl scripts, a batch file, ChkINF.bat, is provided.

The ChkINF.bat file takes the following arguments:

Syntax

ChkInf FileList [/L LogFile ] [/B] [/LO] [/DC Options]

Parameter | Description
FileList | Specifies the files to be used. This can be the name of a single INF file or a directory name. If a directory is specified, ChkINF looks for all INF files in this directory. Wildcards can be used (for example, net*.inf). The ChkINF test first expands all of the wildcards, and then processes all of the applicable INF files.
/L LogFile | Specifies the name of the log file to be created.
/B | Launches the default browser and displays the ChkINF results.
/LO | Compares all copied files (CopyFiles) with Layout.inf.
/DC Options | Specifies the device class-specific options that ChkINF should use when checking INF files. At present, the only supported option is NOFAX, which instructs ChkINF not to check any Fax keys present in modem INF files.

Click to show or hide information. Results Interpretation

If you are using the HCT and Test Manager, the test displays on-screen pass or fail status and writes the results to the Infcheck.log file.

The ChkINF test produces three types of files at the end of the checking process:

  • The Summary.htm file. This is a single HTML file that lists all of the INF files that were checked, along with the number of errors and warnings detected in each one. In this file, each INF file is linked to an individual *.htm results file.
  • A results file for each checked INF file. This file has the name of the INF file with the .htm file name extension.
  • An optional NT Log file may be created (see Syntax). If you are using the HCT, the test creates the log file Infcheck.log by default.

The individual results files include the following sections:

  • Errors: A list of the errors found in the INF file, along with the error message and the line in the INF file where it was detected. Each warning includes a link to its location in the Annotated INF section.
  • Warnings: A list of the warnings detected in the INF file, along with the warning message and the line in the INF file where it was detected. Each warning includes a link to its location in the Annotated INF section of the test results file.
  • Sections included from other infs: A list of the INF sections included from other INF files. Each INF section listed (for example, [AnotherINFFileDDInstall]]) provides a link to its location in the Sections included from other infs section that follows. This information is omitted if the INF being checked did not include any sections from other INF files.
  • Annotated INF: The complete source for the INF file, with the warning and error messages displayed adjacent to the line where the warning or error was detected.
  • Sections included from other infs: The complete source for the included sections, with warning and error messages displayed adjacent to the line where the warning or error was detected. This information is omitted if the INF being checked did not include any sections from other INF files.

The individual results .htm files are saved in the htm subdirectory in the directory from where you ran the ChkINF test.

Click to show or hide information. Limitations

The ChkINF test does not support Windows 98 or Windows Millennium INF files. The ChkINF test will not accurately check INF structure and syntax that is specific to Windows 98 or Windows Millennium INF files.

The ChkINF test has been tested with the following Perl interpreters:

  • GNU Perl 5.005_02 compiled for Win32®
  • GNU Perl 5.6.0 compiled for Win32
  • Perl for Win32 5.003_07 from ActiveWare Internet Corp.
  • ActivePerl 5.6.1.631 from ActiveState (http://www.activestate.com)

The ChkINF test now includes support for INF files saved in Unicode format, including Unicode Big Endian.

The ChkINF test must be executed on the target platform in order to accurately check sections included from other INF files using the Include and Needs directives.

The ChkINF test warns for any sections that are not referenced by a directive elsewhere in the INF file. This is a change from older versions of the test, which reported errors for sections not referenced.

The ChkINF test does not check for all relevant Registry keys set by an INF file. An INF file that passes with no errors might not function correctly.

The ChkINF test incorrectly reports an error if a single named service uses different binary names on the x86 and IA64 platforms.


TD-22.2 Device Path Exerciser Test Description

Test Kit: HCT 11

Note This test updates the Device Path Exerciser test (DevCtl) with a new executable program DevCtl version 2.0 (Dc2.exe), which replaces the DevCtl.exe program described in previous versions of the WHQL Test Specification. The Dc2 program features new command-line options and logging capabilities. For information about the previous Device Path Exerciser test, see the documentation that shipped with the HCT kits prior to HCT 11.0.

The Device Path Exerciser test is designed to crash drivers by calling them through various user-mode I/O interfaces, so developers can quickly find and correct potential security vulnerabilities in their device driver code. The causes for potential security vulnerabilities include the failure to check for buffer overflow, the inability to cope with bad data from user mode, or the mishandling of unexpected entry points into the driver. If left unidentified and uncorrected, such vulnerabilities could potentially allow malicious programs to issue denial-of-service attacks or otherwise bypass system security.

Overview

The Device Path Exerciser test identifies drivers that do not correctly handle the following calls:

  • Unexpected entry points into the driver, such as file system query functions directed to a sound card.
  • Query functions with buffers that are too small to contain all the data to be returned.
  • IOCTL/FSCTL functions with missing buffers, buffers that are too small, or buffers containing meaningless information.
  • IOCTL/FSCTL with direct I/O or type3 buffers with data changing asynchronously.
  • IOCTL/FSCTL with bad pointers for type3 requests.
  • IOCTL/FSCTL and fast path query functions where the user buffer mapping may change asynchronously, causing pages to become unreadable at arbitrary execution points.
  • Relative opens with strange file names or opens to strange device objects like the direct device open or file system devices.
  • Issues requests both synchronously and asynchronously to the device.

The Device Path Exerciser test verifies that the calls listed above are handled properly and do not cause any of the following events:

  • System crashes.
  • System memory pool corruption.
  • Memory leaks.
  • IRPs not completed correctly.

The Device Path Exerciser test runs iteratively, literally sending thousands of device control requests to a driver during the course of testing. A device driver is expected to deal with each of these requests properly. Sometimes dealing with a request "properly" means returning valid data. Typically, in these tests, it means rejecting a request that is malformed and that the driver doesn’t understand.

While the Device Path Exerciser runs, it writes lines to the file Dc2.log indicating, along with other information, the start and end of each category of test. If you run the Device Path Exerciser test from Test Manager, the Dc2.log for each test run is also copied to the file Dvsave.log. Each line is written with the "write-through" attribute and is written to disk, and then the buffer is flushed. As a result, if a crash occurs the offending operation is easy to identify by examining the log file, which should help in debugging the system. The Device Path Exerciser maintains a log of the operations that have crashed the system. Using the command-line options, you can run the Device Path Exerciser and skip those operations that caused a crash or skip those tests that have already run successfully.

Test Categories and Operations

The Device Path Exerciser test consists of individual operations and tests that are organized by category and are described in the following section. All these test categories and operations are performed when you run the Device Path Exerciser test from Test Manager. The Device Path Exerciser test opens the devices exported by a driver in each of the basic open modes, and (optionally) in each of the additional open modes. The test then runs through all the test categories selected in each of these modes. The Device Path Exerciser test verifies the robustness of device drivers and runs repetitively by design.

You can also specify the options and tests you want the Device Path Exerciser to perform from the command line. Use these options if you want to debug test failures or to exercise specific test features.

Click to show or hide information. Open (Create) Operations

These operations are performed iteratively for a specified device, or for each of the devices in the path of a specified driver. The devices are processed one at a time. The processing consists of opening the device in different ways, with several different options, and then optionally sending a series of requests to the device. All open operations are performed in user mode, using the appropriate native Windows NT API function call (such as ZwCreateFile, which is documented in the Windows Driver Development Kit (DDK)). If a test category is specified, those tests would be performed while the test device was open. For most test categories, tests are repeated for each successful open mode.

Click to show or hide information. Basic Open Operations

The basic open operations include the standard ways of opening the device, and these are the default open operations when you run the Device Path Exerciser test. There are no command line options that disable any of the basic open operations.

During basic open operations, the device is opened in various ways to prepare it for further testing. If any of the following operations fails and returns STATUS_SHARING_VIOLATION, a progressively more liberal ShareAccess is specified and the Create operation is repeated. If the operation fails and returns STATUS_ACCESS_DENIED, a progressively less RequestedAccess is requested and the create operation is repeated. In either case, an appropriate message is logged (with severity Error) to the file Diags.log (if logging is enabled).

The following operations form the basis upon which other Device Path Exerciser tests build. The basic open operations are:

  • Normal open. The device is opened, specifying the native device name only, for asynchronous operation.
  • Normal open with added backslash. This test probes how device drivers and file systems deal with a root directory path being supplied along with the device name. This test also how measures how security is implemented.
  • Open as a named pipe. This operation opens the device as a named pipe. In this test, the ShareAccess is initially set to share read and share write.
  • Open as a mailslot. The device is opened as a mailslot.
  • Open as a tree connection. The operation opens the device as a tree connection. In this test, the ShareAccess is initially set to share read and share write.

If one of the basic open operations succeeds, some requests are sent to the device using the opened handle to verify that the device can be used for an I/O operation.

Click to show or hide information. Example Log

The test log created (with /ltc option) for these operations appears below:

DC2 V3.2 Starting at Mon Apr 29 17:00:26 2002
Command Line: dc2 /ltc /ldn /lrn \device\null

START TESTING: device \device\null

Trying to open \device\null
Trying to open \device\null with added backslash
Trying to open \device\null as NamedPipe
Trying to open \device\null as Mailslot
Trying to open \device\null with option FILE_CREATE_TREE_CONNECTION

END TESTING: device \device\null

ALL TESTS COMPLETE at Mon Apr 29 17:00:27 2002 (elapsed time 00:00:01)

This test log was generated with the command line:

DC2 /ltc /ldn /lrn \device\null

If further tests were requested (by specifying a test category to be performed), those tests would be performed while the test device was open. For most test categories, tests are repeated for each successful open mode.

Click to show or hide information. Additional Open Operations

Additional open operations can be specified from the command line. These operations are performed in addition to the basic open operations. These additional operations include:

  • Synchronous open (/k).
  • Direct open (/dd).

Note If /dd is specified but /k is not specified, the direct open operations are not performed.

Click to show or hide information. Example Log

When you specify /k, a total of 8 open operations are performed, as shown in the following log (these operations assume that /dd was not also specified):

DC2 V3.2 Starting at Mon Apr 29 18:44:27 2002

Command Line: dc2 /k /ltc /ldn /lrn \device\null

START TESTING: device \device\null
Trying to open \device\null synchronous
Trying to open \device\null
Trying to open \device\null with added backslash
Trying to open \device\null synchronous as NamedPipe
Trying to open \device\null synchronous as Mailslot
Trying to open \device\null as NamedPipe
Trying to open \device\null as Mailslot
Trying to open \device\null with option FILE_CREATE_TREE_CONNECTION

END TESTING: device \device\null

ALL TESTS COMPLETE at Mon Apr 29 18:44:28 2002 (elapsed time 00:00:01)

When you specify /dd in addition to /k on the command line, this causes an additional synchronous open operation, the "direct device open" to be performed. If /dd is specified but /k is not specified, this open is not performed.

Click to show or hide information. Query/Set File and Volume Tests

These tests perform a variety of query and set operations on the opened file handle. Each query or set operation is issued with a valid buffer and a variety of buffer lengths, resulting in each type of request being issued a minimum of 1024 times. A single request of each type is also sent with an invalid buffer pointer and a zero buffer length. Requests are sent for a wide variety of information classes.

You select this test category with the /q option from the command line. This test is run on the basic and additional open operations, including relative open, if the sub-open test category is also selected.

When you specify test logging (/ltt), every operation (including the buffer pointers, length, and information class) and its result is logged to the file Dc2.log.

If the /pr (protection) test modifier is used, calls to ZwQueryInformationFile and ZwSetInformationFile are each repeated many times in rapid succession while the protection on the specified data buffer is changed.

Click to show or hide information. Security Tests

These tests perform a variety of query security and set security operations on the opened file handle. Each query or set operation is issue with a valid buffer and a variety of buffer lengths, resulting in each type of request being issued a minimum of 1024 times. A single request of each type is also sent with an invalid buffer pointer and a zero buffer length.

You select this test category with the /sd option on the command line. This test is run on the basic and additional open operations, including relative open, if the sub-open test category is also selected (/s).

If the /pr (protection) test modifier is used, calls to ZwQueryInformationFile and ZwSetInformationFile are each repeated many times in rapid succession while the protection on the specified data buffer is changed.

Click to show or hide information. Miscellaneous Test (Part 1)

You select this test category with the /m option from the command line. This test is run on the basic and additional open operations, including relative open, if the sub-open test category is also selected (/s).

  • Performs a series of ZwReadFile and ZwWriteFile operations, specifying valid data buffers pointers and varying lengths (including zero). The byte offsets specified include both zero byte offset and varying 64-bit bytes offsets. ZwWriteFile operations are also performed explicitly specifying a ByteOffset value of -1.
  • Performs cancel I/0 and flush buffers operations.
  • Generates a series of query directory operations for common information types with valid user data buffer pointers and varying buffer lengths (including zero).
  • Performs directory queries similar to those issued by programs running under control of the Virtual DOS Machine (VDM).
  • Performs section requests operations.
  • Performs file lock and unlock operations.

Click to show or hide information. Miscellaneous Test (Part 2)

You select this test category with the /m option from the command line. This test is run on the basic and additional open operations, including relative open, if the sub-open test category is also selected (/s).

This test performs a series of file attribute queries. These requests are issued with valid pointers to an ObjectAttributes structure.

Click to show or hide information. Sub-Open (Relative Open) Tests

You select this test category with the /s option from the command line. The sub-open tests are performed on each successful open in the basic open operations, plus each successful open in the additional open operations.

These open (ZwCreateFile) operations are issued relative to the handle obtained in the basic or additional open operations. Relative opens are performed for a wide variety of relative file names. Relative file names include NULL, space, backslash, many adjacent backslashes, and a name containing a long string of characters.

Click to show or hide information. Streams Tests

You select this test category with the /j option from the command line. These tests are run if the sub-open (relative open) tests are also requested.

The streams tests extend the sub-open tests by attempting to perform relative opens for a variety of "stream" names, legal and illegal, against the base file handle. When the streams tests are run, the stream names used are listed in Dc2.log.

Click to show or hide information. IOCTL/FSCTL Zero Length Buffer Tests

You select this test category with the /in (for IOCTL) or /fn (for FSCTL) options from the command line. This test is run on the basic and additional open operations.

These tests issue a sequence of IRP_MJ_DEVICE_CONTROL or IRP_MJ_FILE_SYSTEM_CONTROL request packets with zero specified for the input and output buffer lengths. The buffer pointers are specified as addresses high in kernel virtual address space (0xfffffc00).

The IOCTL or FSCTL code used is dynamically determined according to the command line options you specify. For each function from ioctl_min_function to ioctl_max_function an IOCTL or FSCTL is issued with that function and a device type ranging from ioctl_min_devtype to ioctl_max_devtype.

From the command line, set ioctl_min_function with the /fl option and ioctl_max_function with the /fu option (which default to 0 and 400, respectively). Use /dl for ioctl_min_devtype and /du for ioctl_max_devtype (which default to 0 and 200, respectively).

For each device type and function pair, each transfer method (METHOD_BUFFERED, METHOD_IN_DIRECT, METHOD_OUT_DIRECT, METHOD_NEITHER) and each type of requested access (FILE_READ_ACCESS, FILE_WRITE_ACCESS, FILE_ANY_ACCESS) is used.

Click to show or hide information. IOCTL/FSCTL Random Tests

You select this test category with the /ir (for IOCTL) or /fr (for FSCTL) options from the command line. This test is run on the basic and additional open operations.

These tests issue a sequence of IRP_MJ_DEVICE_CONTROL or IRP_MJ_FILE_SYSTEM_CONTROL request packets for random functions, device types, methods, and access specifications. I/O request packets are issued with both valid and invalid input and output buffer pointers and lengths. The content of the buffers, when they are valid, is random.

The range over which the device type and functions are chosen are specified by ioctl_min_devtype to ioctl_max_devtype and ioctl_min_function to ioctl_max_function.

From the command line, use /dl for ioctl_min_devtype and /du for ioctl_max_devtype (which default to 0 and 200, respectively). You can set ioctl_min_function with the /fl option and ioctl_max_function with the /fu option (which default to 0 and 400, respectively).

To log the control code, input buffer and output buffer information to the file Dc2.log, specify /ltt on the command line.

Click to show or hide information. Tailored IOCTL FSCTL Random Tests

These tests are automatically selected whenever the IOCTL/FSCTL random tests are selected. The tailored tests attempt to further probe IOCTL or FSCTL requests using a heuristic based on the results obtained during the basic IOCTL/FSCTL random tests. Depending on the results observed during testing, the Device Path Exerciser test might issue zero, few, or many additional IOCTL or FSCTL request in this category.

In and out buffer pointers and lengths may be valid or invalid, and a variety of transfer types might be used: METHOD_BUFFERED, METHOD_IN_DIRECT, METHOD_OUT_DIRECT, and METHOD_NEITHER.

To log the control code, input buffer and output buffer information to the file Dc2.log, specify /ltt on the command line.

Click to show or hide information. Open-Close Tests

This test spawns several threads; each thread performs several thousand create/close sequences.

To select this test category, specify the /oc option on the command line. The tests in this category are performed for only two of the basic open operations (normal open and open with trailing backslash). The open-close tests are run twice, just prior to normal open, and just prior to open with added backslash.

Click to show or hide information. Windows Socket (WinSock) Test

This test establishes a pair of sockets. The test then attempts to transmit the file, as described by the opened file handle, from one of the sockets using the fast transfer mechanism. This test is run on the basic and additional open operations.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The Device Path Exerciser test must be run with the Driver Verifier. Information about running the test from the command line is described below.

Click to show or hide information. DC2 Command Options

The Device Path Exerciser test provides a rich set of options for controlling the device tests when you run the test from the command line.

The basic syntax for the program is:

Dc2 [options] [/dr DriverServiceName ] [devnam]

Where:

Parameter | Description
/dr DriverServiceName | Specifies the service name of the device driver to test.
Devnam | Specifies the name of the device to open to issue requests. The name must be in native object tree format (for example, \device\null). If the devnam is omitted, the Device Path Exerciser program prompts for each device. You can skip to a particular device by typing a forward slash (/) and the first few characters of the device you want to match (for example, /null or /cdrom).
[options] | Specifies test behaviors, test parameters, and test categories. You can use the forward slash (/) and plus (+) to enable options; use minus (-) to disable options. These options are described in the following section.

The [options] for the DC2 test are grouped as follows:

Group | Description
Behaviors | These options determine how the Device Path Exerciser behaves when performing the requested tests.
Parameters | The configurable parameters for tests to be performed.
Test Categories | These options indicate which tests to perform.
Others | The logging and other special purpose options.

Click to show or hide information. Test Behavior Options

Use these options to modify how the tests are performed.

Option | Description
/al | If the test stops responding, this option will periodically attempt to alert test thread. Ends the test thread after 10 minutes if it does not appear to be responding.
/fi | Enables the Driver Verifier for SPECIAL_POOLING, FORCE_IRQL_CHECKING, ALLOCATION_FAILURES.
/c | Skips tests that previously caused a crash (based on the data from the file Crashn.log or the file Crash.log).
/dd | Enables direct device opens operations.
/im | Impersonates a user who is not a member of the Administrator group during testing.
/l | Logs the names of the test groups to the Crashn.log file. You can use these names to potentially restart the tests in the event of a system crash.
/n | Maps the zero page and fills it with NULL values. This is an attempt to discover drivers that dereference bad pointers.
/p | Checks for changes in pool usage; checks for changes in the lookaside list and changes in number of exceptions handled around each test group.
/pd | Displays the names of all the devices in the system on the terminal.
/pr | Continuously changes the protection of the buffer passed as an argument during each test.
/r | Skips tests that have been previously run (based on the file Crashn.log).
/v | Enables verbose mode.

Click to show or hide information. Test Parameters

Use these options to specify what to test.

Parameter | Description
/a | Tests all devices in the system (automatically).
/dl x | Sets lower limit for the Device Type portion in forming IOCTL and FSCTL codes to send to the driver.
/du x | Sets upper limit for the Device Type portion in forming IOCTL and FSCTL codes to send to the driver.
/dr DriverServiceName | Specifies driver mode. Use this option to specify the service name of the driver. Runs tests on all devices associated with that driver.
/d x | Specifies the name of the device to test.
/fl x | Sets lower limit for the Function Code portion in forming IOCTL and FSCTL codes to send to the driver.
/fu x | Sets upper limit for the Function Code portion in forming IOCTL and FSCTL codes to send to the driver.
/il x | Specifies the lower limit on the size of input buffers used in IOCTL and FSCTL codes sent to the driver.
/iu x | Specifies the upper limit on the size of input buffers used in IOCTL and FSCTL codes sent to the driver.
/ol x | Specifies the lower limit on the size of output buffers used in IOCTL and FSCTL codes sent to the driver.
/ou x | Specifies the upper limit on the size of output buffers used in IOCTL and FSCTL codes sent to the driver.
/rd | Chooses a random device to test.
/rs | Sets the seed number for the Random IOCTL/FSCTL tests.
/sl | Performs tests on symbolic links as well as native base devices.
/tt x | Sets the maximum tailored calls for discovered IOCTLs and FSCTLs.
/t x | Sets the maximum IOCTL/FSCTL calls made with random buffers.
/y | Enables disk devices (with /d or /rd options).

Click to show or hide information. Test Categories

Use these options to specify which test to run.

Test Category | Description
/e | As part of the query EA tests, sends a zero-length query EA with an invalid buffer address
/fr | Issues random FSCTL requests.
/fn | Issues FSCTL requests with zero length buffers.
/f | Issues random FSCTL requests with zero length buffers.
/i | Issues random IOCTL requests with zero length buffers.
/ir | Issues random IOCTL requests.
/in | Issues IOCTL requests with zero length buffers
/if | Issues random IOCTL and FSCTL requests with zero length buffers.
/j | As part of the sub-open tests, attempts to open and test device name with common stream names.
/k | Opens devices with synchronous access.
/m | Opens and performs cancels, flush buffers, query directory, create section, lock, unlock, VDM Control.
/od | Issues many concurrent, rapid, open and close requests to the device.
/q | Issues queries and sets for FileStandardInformation, FileFsVolumeInformation, etc.
/s | Specifies the sub-open (or relative open) tests.
/sd | Issues queries and sets for OWNER_SECURITY_INFORMATION, SACL_SECURITY_INFORMATION, etc.
/w | Specifies the Windows Socket (WinSock) test.

Click to show or hide information. Logging Options

Option

Description

/ltx

Controls logging to the file Dc2.log, where x specifies the level of logging. This information includes information about the tests performed.

a Log all information (same as t).

t Log each test message, as well as group and category messages.

  • Note: In this mode, every request sent to a driver is logged, which can generate a large amount of data and can substantially increase the time it takes to run the test. To improve performance, use this option only when multiple test categories are not chosen.

g Log group and category messages.

c Log category messages only.

n No test information is logged.

/ldy

Controls logging to the file Diags.log, where y specifies the diagnostic logging level. This information includes operational messages as well as detailed information about test outcomes.

a Log all information, warnings, errors, and fatal diagnostic errors

i Log information, warnings, errors, and fatal diagnostic errors.

e Log errors and fatal diagnostic errors.

f Log fatal diagnostic errors.

n No diagnostic logging is performed.

/lrz

Controls logging to the file Crashn.log, where z specifies the restart logging level. The restart information is used when you specify /c or /r on the command line.

a All restart information is logged.

n No information is logged.

/lv

A shortcut that specifies logging all diagnostic (/lda) and all test information (/lta).

Click to show or hide information. Default Options

When you run the program Dc2.exe without specifying any options, the following settings are used by default:

+im +l +al -dd -e -fn -fr -i -if -in -ir -j -k -m –n -oc -p -q -s -sd -j -k -w –c –r -f -fi -pr -sl +y +dl 0 +du 200 +fl 0 +fu 400 +il 0 +iu 512 +ol 0 +ou 512 +t 100000 +tt 10000 /ltt /ldi /lrn

Note that you use the prefixes plus (+) or a forward slash (/) to enable an option, and a minus (-) prefix to disable the option.

Click to show or hide information. HCT Option

When you run the Device Path Exerciser test (Dc2.exe) from Test Manager, or when you run the program from the command line with the /hct option, the following settings are used:

+dd +im +l +al +e +f +fn +fr +I +if +in +ir +j -k +m -n +oc -p -pr +q +s +sd -sl -w +y –c –r -fi +dl 0 +du 200 +fl 0 +fu 400 +il 0 +iu 512 +ol 0 +ou 512 +t 100000 +tt 10000 /ltc /ldn /lrn

Results Interpretation

When you run the test from Test Manager, the test displays the on-screen pass or fail status and writes the results to the log file Devpath.log.

The Device Path Exerciser test also writes test information to the Dc2.log file in the HCT\Testbin directory. The statement ALL TESTS COMPLETE as the last line in the file Dc2.log indicates a successful completion of the Device Path Exerciser test. When you run this test from Test Manager, the test copies the file Dc2.log to Dvsave.log for each test run.

Additional Debugging Information


Device Path Exerciser Test: Troubleshooting Information

Warning The Device Path Exerciser test runs under Driver Verifier. Any failure encountered with this test could result in severe system instability, lockups, or system stops. It may be necessary to reboot the computer in safe mode and disable Driver Verifier manually. If this happens, boot the computer into safe mode and run verifier /reset from the command line, and then boot the computer in normal mode.

Troubleshooting the Device Path Exerciser Test (HCT)

Selective Suspend on a USB root hub may cause excessive run times

Troubleshooting: Dc2 has stopped making progress

Debugging Lost I/O Request Packets

Using a kernel debugger to troubleshoot bug checks


TD-22.3 Driver Verifier

Test Kit: HCT 11, HCT 10

Overview

Driver Verifier is a tool that can monitor kernel-mode drivers and graphics drivers to verify that they are not making illegal function calls or causing system corruption. Driver Verifier can perform a large number of checks on these drivers, as well as subject them to a variety of stresses and tests to flush out improper behavior.

Driver Verifier can be used on any number of drivers simultaneously, or on one driver at a time. It has various options that can be enabled or disabled. This allows you to put a driver through heavy stresses or through a more streamlined test.

Click to show or hide information. Driver Verifier Options

Driver Verifier can perform any of the following actions.

Automatic Checks. | These checks are always performed on a driver that is being verified, regardless of which options have been selected. If the driver uses memory at an improper IRQL, improperly calls or releases spin locks and memory allocations, improperly switches stacks, or frees memory pool without first removing timers, Driver Verifier detects this behavior. When the driver is unloaded, Driver Verifier will check to see that it has properly released its resources.
Special Memory Pool | When this option is selected, Driver Verifier allocates most of the driver's memory requests from a special pool. This special pool is monitored for memory overruns, memory underruns, and memory that is accessed after it is freed.
Forcing IRQL Checking | When this option is selected, Driver Verifier places extreme memory pressure on the driver by invalidating pageable code. If the driver attempts to access paged memory at the wrong IRQL or while holding a spin lock, Driver Verifier detects this behavior.
Low Resources Simulation | When this option is selected, Driver Verifier randomly fails pool allocation requests and other resource requests. By injecting these allocation faults into the system, Driver Verifier tests the driver's ability to cope with a low-resource situation.
Memory Pool Tracking | When this option is selected, Driver Verifier checks to see if the driver has freed all its memory allocations when it is unloaded. This reveals memory leaks.
I/O Verification | When this option is selected, Driver Verifier allocates the driver's IRPs from a special pool, and monitors the driver's I/O handling. This detects illegal or inconsistent use of I/O routines.
DMA Verification | ( Windows XP and later) When this option is selected, Driver Verifier monitors the driver's use of DMA routines. This detects improper use of DMA buffers, adapters, and map registers.
Deadlock Detection | (Windows XP and later) When this option is selected, Driver Verifier monitors the driver's use of spin locks, mutexes, and fast mutexes. This detects if the driver's code has the potential for causing a deadlock at some point.
SCSI Verification | (Windows XP and later) When this option is selected, Driver Verifier monitors a SCSI miniport driver for improper use of exported SCSI port routines, excessive delays, and improper handling of SCSI requests.
Disk Integrity Verification | (Windows .NET Server 2003 and later) When this option is selected, Driver Verifier monitors hard disk access, and detects whether the disk is preserving its data correctly.

Driver Verifier can verify any number of drivers. However, the Special Memory Pool and I/O Verification options will be more effective when used on one driver at a time.

For complete information about the Driver Verifier and the Driver Verifier options, see the Windows Driver Development Kit.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

You can use the Verifier utility (Verifier.exe) to activate Driver Verifier from a command prompt.

If you enter the verifier command without any parameters, the Driver Verifier Manager appears. The Driver Verifier Manager provides a graphical interface to Driver Verifier.

For complete information about the Driver Verifier Manager and the Driver Verifier command line options, see the Windows Driver Development Kit.

Click to show or hide information. Command-Line Syntax

Windows 2000 Syntax:

verifier [ /flags Options [/iolevel Level] ] /all

verifier [ /flags Options [/iolevel Level] ] /driver DriverList

verifier /reset

verifier /query

verifier /log LogFileName [/interval Seconds]

verifier /volatile /flags VolatileOptions

verifier /volatile /adddriver VolatileDriverList

verifier /volatile /removedriver VolatileDriverList

verifier /?

Windows XP Syntax

verifier [ /standard | /flags Options ] [ /all | /driver DriverList ]

verifier /volatile /flags VolatileOptions

verifier /volatile /adddriver VolatileDriverList

verifier /volatile /removedriver VolatileDriverList

verifier /reset

verifier /querysettings

verifier /query

verifier /log LogFileName [/interval Seconds]

verifier /?

Windows .NET Server 2003 Syntax:

verifier [/disk] [ /standard | /flags Options ] [ /all | /driver DriverList ]

verifier /volatile /flags VolatileOptions

verifier /volatile /adddriver VolatileDriverList

verifier /volatile /removedriver VolatileDriverList

verifier /reset

verifier /querysettings

verifier /query

verifier /log LogFileName [/interval Seconds]

verifier /?

Click to show or hide information. Parameters

/flags Options

Specifies the Driver Verifier options that will be active after the next boot. In Windows 2000, this number must be entered in decimal format. In Windows XP and later, this number can be entered in decimal or in hexadecimal (with an 0x prefix) format. Any combination of the following values is allowed.

If you are using the HCT and you run the Driver Verifier test from Test Manager, all of the following options are selected except the low resources simulation. (/flags 0xFB).

Decimal | Hexadecimal | Action
1 | 0x01 (Bit 0) | Special Memory Pool
2 | 0x02 (Bit 1) | Forcing IRQL Checking
4 | 0x04 (Bit 2) | Low Resources Simulation
8 | 0x08 (Bit 3) | Memory Pool Tracking
16 | 0x10 (Bit 4) | I/O Verification
32 | 0x20 (Bit 5) | (Windows XP and later) Deadlock Detection
64 | 0x40 (Bit 6) | (Windows XP and later) Enhanced I/O Verification
128 | 0x80 (Bit 7) | (Windows XP and later) DMA Verification

The SCSI Verification option is not enabled through this method. For information about enabling SCSI Verification, see the Windows DDK.

/standard

(Windows XP and later) Causes the "standard" Driver Verifier options to be active after the next boot. The standard options are Special Memory Pool, Forcing IRQL Checking, Memory Pool Tracking, I/O Verification (but not the enhanced version), Deadlock Detection, and DMA Verification. This is equivalent to /flags 0xBB.

/iolevel Level

(Windows 2000 only) Specifies the level of I/O Verification. This can be 1 or 2, and is ignored unless I/O Verification has been enabled by using the /flags parameter. If this is omitted or equal to 1, only the Level 1 I/O Verification tests will be enabled. If this is equal to 2, both the Level 1 and Level 2 tests will be enabled. (In Windows XP and later, both levels are always active as long as I/O Verification is enabled.)

/disk

(Windows .NET Server 2003 and later) Causes the Disk Integrity Verification option to be active after the next boot.

/all

Causes Driver Verifier to verify all installed drivers after the next boot.

/driver DriverList

Causes the specified drivers to be verified after the next boot. Multiple drivers can be specified by listing their names, separated by spaces. Wildcard values, such as n*.sys, are not supported.

/volatile

Causes changes to be made to Driver Verifier's volatile settings. Volatile settings take effect immediately, rather than after a reboot. See the Windows DDK for more information.

/flags VolatileOptions

Specifies the Driver Verifier options that will be changed in a volatile manner. In Windows 2000, this number must be entered in decimal format. In Windows XP and later, this number can be entered in decimal or in hexadecimal (with an 0x prefix) format. Any combination of the following values is allowed.

Decimal | Hexadecimal | Action
1 | 0x01 (Bit 0) | Special Memory Pool
2 | 0x02 (Bit 1) | Forcing IRQL Checking
4 | 0x04 (Bit 2) | Low Resources Simulation

/adddriver VolatileDriverList

(Windows XP and later) Causes the specified drivers to be added to the volatile settings. Multiple drivers can be specified by listing their names, separated by spaces. Wildcard values, such as n*.sys, are not supported.

/removedriver VolatileDriverList

(Windows XP and later) Causes the specified drivers to be removed from the volatile settings. Multiple drivers can be specified by listing their names, separated by spaces. Wildcard values, such as n*.sys, are not supported.

/reset

Clears all Driver Verifier settings. After the next boot, no drivers will be verified.

/querysettings

(Windows XP and later) Displays a summary of the non-volatile Driver Verifier settings — the options selected and the drivers selected for verification. These are the settings that will be active after the next boot. For other ways to view these settings, see the Windows DDK.

/log LogFileName

Creates a log file with name LogFileName. At regular intervals, Driver Verifier statistics will be written to this file. If this command is launched from a Command Prompt Window, this command will not return a new prompt. To close the log file and return a prompt, use CTRL+C. After a reboot, this command must be used again if a new log file is desired.

/interval Seconds

Specifies the interval between log file updates. The default is 30 seconds.

/?

Causes command-line help information to be displayed.

For more information on the use of these commands, see the Windows DDK.

Results Interpretation

This section summarizes information about the parameters that might appear on the blue screen during bug checks.

Bug Check 0xC1: SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION
Bug Check 0xC2: BAD_POOL_CALLER
Bug Check 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION
Bug Check 0xC5: DRIVER_CORRUPTED_EXPOOL
Bug Check 0xC7: TIMER_OR_DPC_INVALID
Bug Check 0xC9: DRIVER_VERIFIER_IOMANAGER_VIOLATION
Bug Check 0xCC: PAGE_FAULT_IN_FREED_SPECIAL_POOL
Bug Check 0xCD: PAGE_FAULT_BEYOND_END_OF_ALLOCATION
Bug Check 0xD0: DRIVER_CORRUPTED_MMPOOL
Bug Check 0xD4: SYSTEM_SCAN_AT_RAISED_IRQL_CAUGHT_IMPROPER_DRIVER_UNLOAD
Bug Check 0xD5: DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL
Bug Check 0xD6: DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION

Bug Check 0xE6: DRIVER_VERIFIER_DMA_VIOLATION

Bug Check 0xF1: SCSI_VERIFIER_DETECTED_VIOLATION

For complete information on bug check codes, see the Windows DDK.

Warning Any failure encountered with this test will most likely result in severe system instability, lockups, or system stops. It may be necessary to reboot the computer in safe mode and disable Driver Verifier manually. If this is the case, boot the computer into safe mode and run verifier /reset from the command line, and then boot the computer in normal mode.

Debugging tips

For information about setting up the test system to a create memory dump file in the event of a system stop, and using a kernel debugger to examine the failure, see Using a kernel debugger to troubleshoot bug checks


Bug Check 0xC1: SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION

The SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION bug check has value 0x000000C1. This signals that the driver wrote to an invalid section of the special memory pool.

Parameters

The following parameters are displayed on the blue screen. Parameter 4 indicates the type of violation.

Parameter 1 | Parameter 2 | Parameter 3 |  | Parameter 4 | Description
Address that the driver tried to free | Reserved | zero | 0x20 | A driver attempted to free pool which was not allocated
Address that the driver tried to free | Bytes requested | Bytes calculated (actually given to the caller) |  | 0x21, 0x22 | A driver attempted to free a bad address
Address that the driver tried to free | Address where bits are corrupted | Reserved |  | 0x23 | A driver freed an address while nearby bytes on same page have been corrupted
Address that the driver tried to free | Address where bits are corrupted | Reserved | 0x24 | A driver freed an address when bytes after end of allocation have been overwritten
Current IRQL | Pool type | Number of bytes |  | 0x30 | A driver attempted to allocate pool at incorrect IRQL
Current IRQL | Pool type | Address that the driver tried to free |  | 0x31 | Attempt to free pool at incorrect IRQL

The _POOL_TYPE codes are enumerated in ntddk.h. In particular, zero indicates nonpaged pool and one indicates paged pool.

Resolving the Problem

Obtain a backtrace of the current thread. This backtrace will usually reveal the source of the error.


Bug Check 0xC2: BAD_POOL_CALLER

The BAD_POOL_CALLER bug check has value 0x000000C2. This signifies that the current thread is making a bad pool request. Typically, a bad pool request results from attempts to allocate memory from the pool at an invalid IRQL level, attempts to free a pool which was already freed, or attempts to allocate memory without a tag that identifies the driver.

Parameters

The following parameters are displayed on the blue screen. Parameter 1 indicates the type of violation.

Parameter 1 | Parameter 2 | Parameter 3 | Parameter 4 | Description
0x00 | 0 | Pool type | Pool tag | The current thread requested a zero-byte pool allocation.
0x01, 0x02, or 0x04 | Pointer to pool header | First part of pool header contents | 0 | Pool header has been corrupted.
0x06 | Reserved | Pointer to pool header | Pool header contents | The current thread attempted to free pool which was already freed.
0x07 | Reserved | Memory contents of the pool block | Pointer to pool header | The current thread attempted to free pool which was already freed.
0x08 | Current IRQL | Pool type | Size of allocation in bytes | The current thread attempted to allocate pool at an invalid IRQL.
0x09 | Current IRQL | Pool type | Address of pool | The current thread attempted to free pool at an invalid IRQL.
0x0A | Address of pool | Allocator's tag | Tag being used in the attempted free | The current thread attempted to free pool memory using the wrong tag. (The memory may belong to another component.)
0x0B, 0x0C, or 0x0D | Address of pool | Pool allocation's tag | Bad quota process pointer | The current thread attempted to release a quota on a corrupted pool allocation.
0x40 | Starting address | Start of system address space | Zero | The current thread attempted to free kernel pool at user-mode address.
0x41 | Starting address | Physical page frame | Highest physical page frame | The current thread attempted to free a nonallocated nonpaged pool address.
0x50 | Starting address | Start offset in pages from beginning of paged pool | Size of paged pool, in bytes | The current thread attempted to free a nonallocated paged pool address.
0x60 | Starting address | 0 | 0 | The current thread attempted to free an invalid contiguous memory address. (The caller of MmFreeContiguousMemory is passing a bad pointer.)
0x99 | Address being freed | 0 | 0 | The current thread attempted to free pool with an invalid address. (This code can also indicate corruption in pool header.)
0x9A | Pool type | Number of bytes requested | Pool tag | The current thread marked an allocation request MUST_SUCCEED. (This pool type is no longer supported.)
0x9B | Pool type | Number of bytes requested | Caller's address | The current thread attempted to allocate a pool with a tag of zero. (This would be untrackable, and possibly corrupt the existing tag tables.)
0x9C | Pool type | Number of bytes requested | Caller's address | The current thread attempted to allocate a pool with a tag of "BIG". (This would be untrackable, and could possibly corrupt the existing tag tables.)

The _POOL_TYPE codes are enumerated in ntddk.h. In particular, zero indicates nonpaged pool and one indicates paged pool.

Cause

A bad pool request has been made by the current thread.

Resolving the Problem

Activate Driver Verifier to obtain more information about these errors. For more information, see the Windows DDK.


Bug Check 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION

The DRIVER_VERIFIER_DETECTED_VIOLATION bug check has value 0x000000C4. This is the general bug check code for fatal errors found by Driver Verifier.

Parameters (General Driver Verifier codes)

The following parameters are displayed on the blue screen. Parameter 1 identifies the type of violation.

Parameter 1 | Parameter 2 | Parameter 3 | Parameter 4 | Description
0x00 | Current IRQL | Pool type | 0 | The driver requested a zero-byte pool allocation.
0x01 | Current IRQL | Pool type | Size of allocation, in bytes | The driver attempted to allocate paged memory at an IRQL above APC_LEVEL.
0x02 | Current IRQL | Pool type | Size of allocation, in bytes | The driver attempted to allocate nonpaged memory at an IRQL above DISPATCH_LEVEL.
0x10 | Bad Address | 0 | 0 | The driver attempted to free an address that was not returned from an allocate call.
0x11 | Current IRQL | Pool type | Address of pool | The driver attempted to free paged pool at an IRQL above APC_LEVEL.
0x12 | Current IRQL | Pool type | Address of pool | The driver attempted to free nonpaged pool at an IRQL above DISPATCH_LEVEL.
0x13 or 0x14 | Reserved | Pointer to pool header | Pool header contents | The driver attempted to free memory pool which was already freed.
0x15 | Timer entry | Pool type (-1 for Special Pool) | Pool address being freed | The driver attempted to free pool which contains an active timer.
0x16 | Reserved | Pool address | 0 | The driver attempted to free pool at a bad address (or passed invalid parameters to a memory routine).
0x17 | Resource entry | Pool type (-1 for Special Pool) | Pool address being freed | The driver attempted to free pool which contains an active ERESOURCE.
0x30 | Current IRQL | Requested IRQL | 0 | The driver passed an invalid parameter to KeRaiseIrql. (The parameter was either a value lower than the current IRQL, or a value higher than HIGH_LEVEL. This may be the result of using an uninitialized parameter.)
0x31 | Current IRQL | Requested IRQL | 0 | The driver passed an invalid parameter to KeLowerIrql. (The parameter was either a value higher than the current IRQL, or a value higher than HIGH_LEVEL. This may be the result of using an uninitialized parameter.)
0x32 | Current IRQL | Spin lock address | 0 | The driver called KeReleaseSpinLock at an IRQL other than DISPATCH_LEVEL.(This may be due to a double-release of a spin lock.)
0x33 | Current IRQL | Fast mutex address | 0 | The driver attempted to acquire fast mutex at an IRQL above APC_LEVEL.
0x34 | Current IRQL | Fast mutex address | 0 | The driver attempted to release fast mutex at an IRQL other than APC_LEVEL.
0x35 | Current IRQL | Spin lock address | Old IRQL | The kernel released a spin lock when not at DISPATCH_LEVEL.
0x36 | Current IRQL | Spin lock number | Old IRQL | The kernel released a queued spin lock when not at DISPATCH_LEVEL.
0x37 | Current IRQL | Thread APC disable count | Resource | The driver tried to acquire a resource, but APCs are not disabled.
0x38 | Current IRQL | Thread APC disable count | Resource | The driver tried to release a resource, but APCs are not disabled.
0x39 | Current IRQL | Thread APC disable count | Mutex | The driver tried to acquire a mutex "unsafe", but the IRQL was not APC_LEVEL on entry.
0x3A | Current IRQL | Thread APC disable count | Mutex | The driver tried to release a mutex "unsafe", but the IRQL was not APC_LEVEL on entry.
0x3B | Current IRQL | Object to wait on | Timeout parameter | The driver called KeWaitXxx at an IRQL of DISPATCH_LEVEL or higher. (This is permitted only if the driver already owns the DISPATCHER lock and it passes a timeout value of zero to the routine.)
0x3C | Handle passed to routine | Object type | 0 | The driver called ObReferenceObjectByHandle with a bad handle.
0x3D | 0 | 0 | Address of the bad resource | The driver passed a bad (unaligned) resource to ExAcquireResourceExclusive
0x40 | Current IRQL | Spin lock address | 0 | The driver called KeAcquireSpinLockAtDpcLevel at an IRQL other than DISPATCH_LEVEL.
0x41 | Current IRQL | Spin lock address | 0 | The driver called KeReleaseSpinLockFromDpcLevel at an IRQL other than DISPATCH_LEVEL.
0x42 | Current IRQL | Spin lock address | 0 | The driver called KeAcquireSpinLock at an IRQL above DISPATCH_LEVEL.
0x6F | MDL address | Physical page being locked | Highest physical page in the system | The driver passed a page to MmProbeAndLockPages that was not in the PFN database. (This often results from a driver that attempts to lock its own private dualport RAM. Such behavior can corrupt memory on machines with noncontiguous physical RAM.)
0x70 | Current IRQL | MDL address | Access mode | The driver called MmProbeAndLockPages at an IRQL above DISPATCH_LEVEL
0x71 | Current IRQL | MDL address | Process address | The driver called MmProbeAndLockProcessPages at an IRQL above DISPATCH_LEVEL.
0x72 | Current IRQL | MDL address | Process address | The driver called MmProbeAndLockSelectedPages at an IRQL above DISPATCH_LEVEL.
0x73 | Current IRQL | Low 32 bits of the physical address (all 64 bits in Win64) | Number of bytes | The driver called MmMapIoSpace at an IRQL above DISPATCH_LEVEL.
0x74 | Current IRQL | MDL address | Access mode | The driver called MmMapLockedPages in kernel mode at an IRQL above DISPATCH_LEVEL.
0x75 | Current IRQL | MDL address | Access mode | The driver called MmMapLockedPages in user mode at an IRQL above APC_LEVEL.
0x76 | Current IRQL | MDL address | Access mode | The driver called MmMapLockedPagesSpecifyCache in kernel mode at an IRQL above DISPATCH_LEVEL.
0x77 | Current IRQL | MDL address | Access mode | The driver called MmMapLockedPagesSpecifyCache in user mode at an IRQL above APC_LEVEL.
0x78 | Current IRQL | MDL address | 0 | The driver called MmUnlockPages at an IRQL above DISPATCH_LEVEL.
0x79 | Current IRQL | Virtual address being unmapped | MDL address | The driver called MmUnmapLockedPages in kernel mode at an IRQL above DISPATCH_LEVEL.
0x7A | Current IRQL | Virtual address being unmapped | MDL address | The driver called MmUnmapLockedPages in user mode at an IRQL above APC_LEVEL.
0x7B | Current IRQL | Virtual address being unmapped | Number of bytes | The driver called MmUnmapIoSpace at an IRQL above APC_LEVEL.
0x7C | MDL address | MDL flags | 0 | The driver called MmUnlockPages, and passed an MDL whose pages were never successfully locked.
0x7D | MDL address | MDL flags | 0 | The driver called MmUnlockPages, and passed an MDL whose pages are from nonpaged pool. (These should never be unlocked.)
0x80 | Current IRQL | Event address | 0 | The driver called KeSetEvent at an IRQL above DISPATCH_LEVEL.
0x81 | MDL address | MDL flags | 0 | The driver called MmMapLockedPages.
0x82 | MDL address | MDL flags | 0 | The driver called MmMapLockedPagesSpecifyCache with the BugCheckOnFailure parameter equal to TRUE. (This parameter should be set to FALSE.)
0x83 | Start of physical address range to map | Number of bytes to map | First page frame number that isn't locked down | The driver called MmMapIoSpace without having locked down the MDL pages.
0x84 | Start of physical address range to map | Number of bytes to map | First page frame number that is on the free list | The driver called MmMapIoSpace without having locked down the MDL pages (or after freeing the MDL pages).
0x85 | MDL address | Number of pages to map | First page frame number that isn't locked down | The driver called MmMapLockedPages without having locked down the MDL pages.
0x86 | MDL address | Number of pages to map | First page frame number that is on the free list | The driver called MmMapLockedPages without having locked down the MDL pages (or after freeing the MDL pages).
0x87 | Base physical page of the existing mapping (Shift left for physical address) | Number of pages already mapped in the existing mapping | MEMORY_CACHING_TYPE of the existing mapping | The driver called MmMapIoSpace, but the caller's cache type conflicts with an existing mapping.
0x88 | Base physical page of the requested mapping (Shift left for physical address) | Number of pages in the requested mapping | MEMORY_CACHING_TYPE of the requested mapping | The driver called MmMapIoSpace to map a physical range as non-cached or write-combined, but the caller's physical range already has an existing cached mapping.
0x89 | MDL address | Pointer to the non-memory page in the MDL | The non-memory page number in the MDL | An MDL is not marked as "I/O", but it contains non-memory page addresses.
0x8A | MDL address | Base physical page of the requested mapping (Shift left for physical address) | MEMORY_CACHING_TYPE of the requested mapping | The driver called MmMapLockedPagesXxx to map a physical range as non-cached or write-combined, but the caller's physical range already has an existing cached mapping.
0x90 | Reserved | Reserved | Reserved | The driver switched stacks, and the current stack is neither a thread stack nor a DPC stack. (Typically, the driver doing this should be on the stack obtained by the KB debugger command.)

The _POOL_TYPE codes are enumerated in ntddk.h. In particular, zero indicates nonpaged pool and one indicates paged pool.

Parameters (Memory Allocation Tracking codes)

The following parameters are used only when the Memory Pool Allocation Tracking option of Driver Verifier is active:

Parameter 1 | Parameter 2 | Parameter 3 | Parameter 4 | Description
0x51 | Base address of allocation | Corrupt address | Number of charged bytes | Driver is trying to free memory after having written past the end of the allocation
0x52 | Base address of allocation | Reserved | Number of charged bytes | Driver is trying to free memory after having written past the end of the allocation
0x53, or 0x54, 0x59 | Base address of allocation | Reserved | Reserved | Driver is trying to free memory after having written past the end of the allocation
0x60 | Bytes allocated from paged pool | Bytes allocated from nonpaged pool | Total number of unfreed allocations | Driver did not free all memory pools prior to unload
0x61 | Bytes allocated from paged pool | Bytes allocated from nonpaged pool | Total number of unfreed allocations | Driver is allocating pool (in another thread) at the same time as it is unloading

Resolving the Problem

If you are the driver writer, use the information obtained through this bug check to fix the bugs in your code.

If you are a system administrator, you should unload the driver if the problem persists.

After a Memory Allocation Tracking bug check, use the following command in the kernel debugger:

kd> dc ViBadDriver l1; dc @$p+4 l1; du @$p

This will return the name of the driver causing the error.

Then use the !verifier extension:

kd> !verifier 3 drivername.sys

This will return information about the leaked memory allocations.

For more information about this bug check, see the Windows DDK.


Bug Check 0xC5: DRIVER_CORRUPTED_EXPOOL

The DRIVER_CORRUPTED_EXPOOL bug check has value 0x000000C5. This signifies that the system attempted to access invalid memory at a process IRQL that was too high.

Parameters

The following parameters are displayed on the blue screen.

Parameter | Description
1 | Memory referenced
2 | IRQL at time of reference
3 | zero: Read 1: Write
4 | Address that referenced memory

Comments

A driver has probably corrupted the system pool. This code is usually issued when the corruption was in a small allocation (less than PAGE_SIZE).

Resolving the Problem

To deal with this bug, use the Special Pool option of Driver Verifier. If this fails to reveal the guilty driver, use the Global Flags utility to enable the Special Pool by pool tag.

See also Bug Check 0xD0

For more information about this bug check, see the Windows DDK.


Bug Check 0xC7: TIMER_OR_DPC_INVALID

The TIMER_OR_DPC_INVALID bug check has value 0x000000C7. This is issued if a kernel timer or delayed procedure call (DPC) is found somewhere in memory where it is not permitted.

Parameters

The following parameters are displayed on the blue screen.

Parameter | Description
1 | zero: Timer object one: DPC object two: DPC routine
2 | Address of object
3 | Beginning of memory range checked
4 | End of memory range checked

Comments

This condition is usually caused by a driver failing to cancel a timer or DPC before freeing the memory where it resides. When Driver Verifier is active, it will catch such errors and issue this bug check.

Resolving the Problem

If you are the driver writer, use the information obtained through this bug check to fix the bugs in your code.

If you are a system administrator, you should unload the driver if the problem persists.

For more information about this bug check, see the Windows DDK.


Bug Check 0xC9: DRIVER_VERIFIER_IOMANAGER_VIOLATION

The DRIVER_VERIFIER_IOMANAGER_VIOLATION bug check has value 0x000000C9. This is the bug check code for all Driver Verifier I/O Verification violations.

Parameters (I/O Verification Level 1)

When Driver Verifier is active and I/O Verification has been set to Level 1, various I/O violations will cause this bug check to be issued. The following parameters will be displayed on the blue screen. Parameter 1 identifies the type of violation.

Parameter 1 | Parameter 2 | Parameter 3 | Parameter 4 | Description
0x01 | Address of IRP being freed | 0 | 0 | The driver attempted to free an object whose type is not IO_TYPE_IRP.
0x02 | Address of IRP being freed | 0 | 0 | The driver attempted to free an IRP that is still associated with a thread.
0x03 | Address of IRP being sent | 0 | 0 | The driver passed IoCallDriver an IRP Type not equal to IRP_TYPE.
0x04 | Address of DeviceObject | 0 | 0 | The driver passed IoCallDriver an invalid device object.
0x05 | Address of DeviceObject associated with offending driver | IRQL before IoCallDriver | IRQL after IoCallDriver | The IRQL changed during a call to the driver dispatch routine.
0x06 | IRP status | Address of IRP being completed | 0 | The driver called IoCompleteRequest with a status marked as pending (or equal to -1).
0x07 | Address of cancel routine | Address of IRP being completed | 0 | The driver called IoCompleteRequest while its cancel routine was still set.
0x08 | Address of DeviceObject | IRP major function code | Exception status code | The driver passed IoBuildAsynchronousFsdRequest an invalid buffer.
0x09 | Address of DeviceObject | I/O control code | Exception status code | The driver passed IoBuildDeviceIoControlRequest an invalid buffer.
0x0A | Address of DeviceObject | 0 | 0 | The driver passed IoInitializeTimer a device object with an already-initialized timer.
0x0C | Address of I/O status block | 0 | 0 | The driver passed an I/O status block to an IRP, but this block is allocated on a stack which has already unwound past that point.
0x0D | Address of user event object | 0 | 0 | The driver passed a user event to an IRP, but this event is allocated on a stack which has already unwound past that point.
0x0E | Current IRQL | Address of IRP | 0 | The driver called IoCompleteRequest while the IRQL was above dispatch level.
0x0F | Address of the DeviceObject to which the IRP is being sent | Pointer to the IRP | Pointer to FileObject | The driver sent a create request with a file object that has been closed, or that had its open canceled.

In addition to the errors mentioned in the previous table, there are a number of I/O Verification errors that will cause Driver Verifier to halt the system, but which are not actually bug checks.

These errors cause messages to be displayed on the blue screen, in a crash dump file, and in a kernel debugger. These messages will appear differently in each of these locations. When these errors occur, the hexadecimal bug check code 0xC9 and the bug check string DRIVER_VERIFIER_IOMANAGER_VIOLATION do not appear on the blue screen or in the debugger, although they will appear in a crash dump file.

On the blue screen, the following data will be displayed:

  • The message IO SYSTEM VERIFICATION ERROR.
  • The message WDM DRIVER ERROR XXX, where XXX is a hexadecimal code representing the specific error. (See the table below for a list of the I/O error codes and their meanings.)
  • The name of the driver which caused the error.
  • The address in the driver's code where the error was detected (Parameter 2).
  • A pointer to the IRP (Parameter 3).
  • A pointer to the DeviceObject (Parameter 4).

If a kernel-mode crash dump has been enabled, the following information will appear in the crash dump file:

  • The message BugCheck 0xC9 (DRIVER_VERIFIER_IOMANAGER_VIOLATION).
  • The hexadecimal I/O error code. (See the table below for a list of the I/O error codes and their meanings.)
  • The address in the driver's code where the error was detected.
  • A pointer to the IRP.
  • A pointer to the DeviceObject.

If a kernel debugger is attached to the system which has caused this violation, the following information will be sent to the debugger:

  • The message WDM DRIVER ERROR, along with an assessment of the severity of the error.
  • The name of the driver which caused the error.
  • A descriptive string which explains the cause of this error. Often additional information is passed along, such as a pointer to the IRP. (See the table below for a list of these descriptive strings and what additional information is specified.)
  • A query for further action. Possible responses are b (break), i (ignore), z (zap), r (remove), or d (disable). Instructing the operating system to continue allows you to see what would happen "down the line" if this error had not occurred. Of course, this often will lead to additional bug checks. The "zap" option will actually remove the breakpoint that caused this error to be discovered.

Note

No other bug checks can be ignored in this manner. Only this kind of I/O Verification errors can be ignored, and even these errors can only be ignored if a kernel debugger is attached.

The following table lists those I/O Verification errors that can appear in Windows 2000 and later. In Windows 2000, these errors will only be displayed if I/O Verification is set to Level 2.

I/O Error Code | Severity | Description
0x200 | Unknown | This code covers all unknown I/O Verification errors.
0x201 | Fatal error | A device is deleting itself while there is another device beneath it in the driver stack. This may be because the caller has forgotten to call IoDetachDevice first, or the lower driver may have incorrectly deleted itself.
0x202 | Fatal error | A driver has attempted to detach from a device object that is not attached to anything. This may occur if detach was called twice on the same device object. (Device object specified.)
0x203 | Fatal error | A driver has called IoCallDriver without setting the CancelRoutine in the IRP to NULL. (IRP specified.)
0x204 | Fatal error | The caller has passed in NULL as a DeviceObject. This is fatal. (IRP specified.)
0x205 | Fatal error | The caller is forwarding an IRP that is currently queued beneath it. The code handling IRPs returning STATUS_PENDING in this driver appears to be broken. (IRP specified.)
0x206 | Fatal error | The caller has incorrectly forwarded an IRP (control field not zeroed). The driver should use IoCopyCurrentIrpStackLocationToNext or IoSkipCurrentIrpStackLocation. (IRP specified.)
0x207 | Fatal error | The caller has manually copied the stack and has inadvertently copied the upper layer's completion routine. Please use IoCopyCurrentIrpStackLocationToNext. (IRP specified.)
0x208 | Fatal error | This IRP is about to run out of stack locations. Someone may have forwarded this IRP from another stack. (IRP specified.)
0x209 | Fatal error | The caller is completing an IRP that is currently queued beneath it. The code handling IRPs returning STATUS_PENDING in this driver appears to be broken. (IRP specified.)
0x20A | Fatal error | The caller of IoFreeIrp is freeing an IRP that is still in use. (Original IRP and IRP in use specified.)
0x20B | Fatal error | The caller of IoFreeIrp is freeing an IRP that is still in use. (IRP specified.)
0x20C | Fatal error | The caller of IoFreeIrp is freeing an IRP that is still queued against a thread. (IRP specified.)
0x20D | Fatal error | The caller of IoInitializeIrp has passed an IRP that was allocated with IoAllocateIrp. This is illegal and unnecessary, and has caused a quota leak. Check the documentation for IoReuseIrp if this IRP is being recycled.
0x20E | Non-fatal error | A PNP IRP has an invalid status. (Any PNP IRP must have its status initialized to STATUS_NOT_SUPPORTED.) (IRP specified.)
0x20F | Non-fatal error | A Power IRP has an invalid status. (Any Power IRP must have its status initialized to STATUS_NOT_SUPPORTED.) (IRP specified.)
0x210 | Non-fatal error | A WMI IRP has an invalid status. (Any WMI IRP must have its status initialized to STATUS_NOT_SUPPORTED.) (IRP specified.)
0x211 | Non-fatal error | The caller has forwarded an IRP while skipping a device object in the stack. The caller is probably sending IRPs to the PDO instead of to the device returned by IoAttachDeviceToDeviceStack. (IRP specified.)
0x212 | Non-fatal error | The caller has trashed or has not properly copied the IRP's stack. (IRP specified.)
0x213 | Non-fatal error | The caller has changed the status field of an IRP it does not understand. (IRP specified.)
0x214 | Non-fatal error | The caller has changed the information field of an IRP it does not understand. (IRP specified.)
0x215 | Non-fatal error | A non-successful non-STATUS_NOT_SUPPORTED IRP status for IRP_MJ_PNP is being passed down stack. (IRP specified.) Failed PNP IRPs must be completed.
0x216 | Non-fatal error | The previously-set IRP_MJ_PNP status has been converted to STATUS_NOT_SUPPORTED. (IRP specified.)
0x217 | Non-fatal error | The driver has not handled a required IRP. The driver must update the status of the IRP to indicate whether or not it has been handled. (IRP specified.)
0x218 | Non-fatal error | The driver has responded to an IRP that is reserved for other device objects elsewhere in the stack. (IRP specified.)
0x219 | Non-fatal error | A non-successful non-STATUS_NOT_SUPPORTED IRP status for IRP_MJ_POWER is being passed down stack. (IRP specified.) Failed POWER IRPs must be completed.
0x21A | Non-fatal error | The previously-set IRP_MJ_POWER status has been converted to STATUS_NOT_SUPPORTED. (IRP specified.)
0x21B | Non-fatal error | A driver has returned a suspicious status. This is probably due to an uninitialized variable bug in the driver. (IRP specified.)
0x21C | Warning | The caller has copied the IRP stack but not set a completion routine. This is inefficient -- use IoSkipCurrentIrpStackLocation instead. (IRP specified.)
0x21D | Fatal error | An IRP dispatch handler has not properly detached from the stack below it upon receiving a remove IRP. (DeviceObject, Dispatch Routine, and IRP specified.)
0x21E | Fatal error | An IRP dispatch handler has not properly deleted its device object upon receiving a remove IRP. (DeviceObject, Dispatch Routine, and IRP specified.)
0x21F | Non-fatal error | A driver has not filled out a dispatch routine for a required IRP major function. (IRP specified.)
0x220 | Non-fatal error | IRP_MJ_SYSTEM_CONTROL has been completed by someone other than the ProviderId. This IRP should either have been completed earlier or should have been passed down. (IRP specified, along with the DeviceObject where it was targeted.)
0x221 | Fatal error | An IRP dispatch handler for a PDO has deleted its device object, but the hardware has not been reported as missing in a bus relations query. (DeviceObject, Dispatch Routine, and IRP specified.)
0x222 | Fatal error | A Bus Filter's IRP dispatch handler has detached upon receiving a remove IRP when the PDO is still alive. Bus Filters must clean up in FastIoDetach callbacks. (DeviceObject, Dispatch Routine, and IRP specified.)
0x223 | Fatal error | An IRP dispatch handler for a bus filter has deleted its device object, but the PDO is still present. Bus filters must clean up in FastIoDetach callbacks. (DeviceObject, Dispatch Routine, and IRP specified.)
0x224 | Fatal error | An IRP dispatch handler has returned a status that is inconsistent with the IRP's IoStatus.Status field. (Dispatch handler routine, IRP, IRP's IoStatus.Status, and returned Status specified.)
0x225 | Non-fatal error | An IRP dispatch handler has returned a status that is illegal (0xFFFFFFFF). This is probably due to an uninitialized stack variable. To debug this error, use the LN (List Nearest Symbols) command with the specified address.
0x226 | Fatal error | An IRP dispatch handler has returned without passing down or completing this IRP, or someone forgot to return STATUS_PENDING. (IRP specified.)
0x227 | Fatal error | An IRP completion routine is in pageable code. (This is never permitted.) (Routine and IRP specified.)
0x228 | Non-fatal error | A driver's completion routine has not marked the IRP pending if the PendingReturned field was set in the IRP passed to it. This may cause the OS to hang, especially if an error is returned by the stack. (Routine and IRP specified.)
0x229 | Fatal error | A cancel routine has been set for an IRP that is currently being processed by drivers lower in the stack, possibly stomping their cancel routine. (Routine and IRP specified.)
0x22A | Non-fatal error | The physical device object (PDO) has not responded to a required IRP. (IRP specified.)
0x22B | Non-fatal error | The physical device object (PDO) has forgotten to fill out the device relation list with the PDO for the TargetDeviceRelation query. (IRP specified.)
0x22C | Fatal error | The code implementing the TargetDeviceRelation query has not called ObReferenceObject on the PDO. (IRP specified.)
0x22D | Non-fatal error | The caller has completed a IRP_MJ_PNP it didn't understand instead of passing it down. (IRP specified.)
0x22E | Non-fatal error | The caller has completed a successful IRP_MJ_PNP instead of passing it down. (IRP specified.)
0x22F | Non-fatal error | The caller has completed an untouched IRP_MJ_PNP (instead of passing the IRP down), or non-PDO has failed the IRP using illegal value of STATUS_NOT_SUPPORTED. (IRP specified.)
0x230 | Non-fatal error | The caller has completed an IRP_MJ_POWER it didn't understand instead of passing it down. (IRP specified.)
0x231 | Fatal error | The caller has completed a successful IRP_MJ_POWER instead of passing it down. (IRP specified.)
0x232 | Non-fatal error | The caller has completed an untouched IRP_MJ_POWER (instead of passing the IRP down), or non-PDO has failed the IRP using illegal value of STATUS_NOT_SUPPORTED. (IRP specified.)
0x233 | Non-fatal error | The version field of the query capabilities structure in a query capabilities IRP was not properly initialized. (IRP specified.)
0x234 | Non-fatal error | The size field of the query capabilities structure in a query capabilities IRP was not properly initialized. (IRP specified.)
0x235 | Non-fatal error | The address field of the query capabilities structure in a query capabilities IRP was not properly initialized to -1. (IRP specified.)
0x236 | Non-fatal error | The UI Number field of the query capabilities structure in a query capabilities IRP was not properly initialized to -1. (IRP specified.)
0x237 | Fatal error | A driver has sent an IRP that is restricted for system use only. (IRP specified.)
0x238 | Warning | The caller of IoInitializeIrp has passed an IRP that was allocated with IoAllocateIrp. This is illegal, unnecessary, and negatively impacts performance in normal use. Check the documentation for IoReuseIrp if this IRP is being recycled.
0x239 | Warning | The caller of IoCompleteRequest is completing an IRP that has never been forwarded via a call to IoCallDriver or PoCallDriver. This may be a bug. (IRP specified.)
0x23A | Fatal error | A driver has forwarded an IRP at an IRQL that is illegal for this major code. (IRP specified.)
0x23B | Non-fatal error | The caller has changed the status field of an IRP it does not understand. (IRP specified.)

The following table lists additional I/O Verification errors that can appear in Windows XP and later. Some of these errors will only be revealed if Enhanced I/O Verification is activated.

I/O Error Code | Severity | Description
0x23C | Fatal error | A driver has completed an IRP without setting the cancel routine in the IRP to NULL. (IRP specified.)
0x23D | Non-fatal error | A driver has returned STATUS_PENDING but did not mark the IRP pending via a call to IoMarkIrpPending. (IRP specified.)
0x23E | Non-fatal error | A driver has marked an IRP pending but didn't return STATUS_PENDING. (IRP specified.)
0x23F | Fatal error | A driver has not inherited the DO_POWER_PAGABLE bit from the stack it has attached to. (DeviceObject specified.)
0x240 | Fatal error | A driver is attempting to delete a device object that has already been deleted via a prior call to IoDeleteDevice.
0x241 | Fatal error | A driver has detached its device object during a surprise remove IRP. (IRP and DeviceObject specified.)
0x242 | Fatal error | A driver has deleted its device object during a surprise remove IRP. (IRP and DeviceObject specified.)
0x243 | Fatal error | A driver has failed to clear the DO_DEVICE_INITIALIZING flag at the end of AddDevice. (DeviceObject specified.)
0x244 | Fatal error | A driver has not copied either the DO_BUFFERED_IO or the DO_DIRECT_IO flag from the device object it is attaching to. (DeviceObject specified.)
0x245 | Fatal error | A driver has set both the DO_BUFFERED_IO and the DO_DIRECT_IO flags. These flags are mutually exclusive. (DeviceObject specified.)
0x246 | Fatal error | A driver has failed to copy the DeviceType field from the device object it is attaching to. (DeviceObject specified.)
0x247 | Fatal error | A driver has failed an IRP that cannot legally be failed. (IRP specified.)
0x248 | Fatal error | A driver has added a device object that is not a PDO to a device relations query. (IRP and DeviceObject specified.)
0x249 | Non-fatal error | A driver has enumerated two child PDOs that returned identical Device IDs. (Both DeviceObjects specified.)
0x24A | Fatal error | A driver has mistakenly called a file I/O function at an IRQL other than PASSIVE_LEVEL.
0x24B | Fatal error | A driver has completed an IRP_MN_QUERY_DEVICE_RELATIONS request of type TargetRelations as successful, but did not properly fill out the request or forward the IRP to the underlying hardware stack. (DeviceObject specified.)
0x24C | Non-fatal error | A driver has returned STATUS_PENDING but did not mark the IRP pending by a call to IoMarkIrpPending. (IRP specified.)
0x24D | Fatal error | A driver has passed an invalid device object to a function that requires a PDO. (DeviceObject specified.)

Cause

See the description of each code in the Parameters section for a description of the cause.

Resolving the Problem

This bug check can only occur when Driver Verifier has been instructed to monitor one or more drivers. If you did not intend to use Driver Verifier, you should deactivate it. You might consider removing the driver which caused this problem as well.

If you are the driver writer, use the information obtained through this bug check to fix the bugs in your code.

For more information about this bug check, see the Windows DDK.


Bug Check 0xCC: PAGE_FAULT_IN_FREED_SPECIAL_POOL

The PAGE_FAULT_IN_FREED_SPECIAL_POOL bug check has value 0x000000CC. This signals that the system has referenced memory that was earlier freed.

Parameters

The following parameters are displayed on the blue screen.

Parameter | Description
1 | Memory address referenced
2 | zero: Read one: Write
3 | Address that referenced memory (if known)
4 | Reserved

If the guilty driver can be identified, its name is printed on the blue screen and stored in PUNICODE_STRING parameter of KiBugCheckDriver.

Comments

The system has accessed Special Pool memory that was already freed by a driver. This usually indicates a system-driver synchronization problem.

This cannot be protected by try - except; it can only be protected by a probe.

For more information about this bug check, see the Windows DDK.


Bug Check 0xCD: PAGE_FAULT_BEYOND_END_OF_ALLOCATION

The PAGE_FAULT_BEYOND_END_OF_ALLOCATION bug check has value 0x000000CD. This signals that the system accessed memory beyond the end of some driver's pool allocation.

Parameters

The following parameters are displayed on the blue screen.

Parameter | Description
1 | Memory address referenced
2 | zero: Read one: Write
3 | Address that referenced memory (if known)
4 | Reserved

If the guilty driver can be identified, its name is printed on the blue screen and stored in PUNICODE_STRING parameter of KiBugCheckDriver.

Comments

The driver allocated n bytes of memory from the Special Pool. Subsequently, the system referenced more than n bytes from this pool. This usually indicates a system-driver synchronization problem.

This cannot be protected by try - except; it can only be protected by a probe.

For more information about this bug check, see the Windows DDK.


Bug Check 0xD0: DRIVER_CORRUPTED_MMPOOL

The DRIVER_CORRUPTED_MMPOOL bug check has value 0x000000D0. This signifies that the system attempted to access invalid memory at a process IRQL that was too high.

Parameters

The following parameters are displayed on the blue screen.

Parameter | Description
1 | Memory referenced
2 | IRQL at time of reference
3 | zero: Read one: Write
4 | Address that referenced memory

Comments

A driver has probably corrupted the system pool. This code is usually issued when the corruption was in a large allocation (PAGE_SIZE or larger).

Resolving the Problem

To deal with this bug, use the Special Pool option of Driver Verifier. If this fails to reveal the guilty driver, use the Global Flags utility to enable the Special Pool by pool tag.

An alternate method is to set the \\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\ProtectNonPagedPool registry key equal to DWORD 1 and reboot. Then the system will unmap all freed nonpaged pool. This will prevent drivers from corrupting the pool. (This does not protect the pool from DMA hardware, however.)

See Also Bug Check 0xC5

For more information about this bug check, see the Windows DDK.


Bug Check 0xD4: SYSTEM_SCAN_AT_RAISED_IRQL_CAUGHT_IMPROPER_DRIVER_UNLOAD

The SYSTEM_SCAN_AT_RAISED_IRQL_CAUGHT_IMPROPER_DRIVER_UNLOAD bug check has value 0x000000D4. This signifies that a driver did not cancel pending operations before unloading.

Parameters

The following parameters are displayed on the blue screen.

Parameter | Description
1 | Memory referenced
2 | IRQL at time of reference
3 | zero: Read one: Write
4 | Address that referenced memory

If the guilty driver can be identified, its name is printed on the blue screen and stored in PUNICODE_STRING parameter of KiBugCheckDriver.

Comments

This driver failed to cancel lookaside lists, DPCs, worker threads, or other such items before unload. Subsequently, the system attempted to access the driver's former location at a raised IRQL.

Resolving the Problem

To deal with this bug, use a kernel debugger to get a stack trace. If the guilty driver has been identified, activate Driver Verifier and attempt to replicate this bug.

For more information about this bug check, see the Windows DDK.


Bug Check 0xD5: DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL

The DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL bug check has value 0x000000D5. This signals that a driver has referenced memory that was earlier freed.

Parameters

The following parameters are displayed on the blue screen.

Parameter | Description
1 | Memory address referenced
2 | zero: Read one: Write
3 | Address that referenced memory (if known)
4 | Reserved

If the guilty driver can be identified, its name is printed on the blue screen and stored in PUNICODE_STRING parameter of KiBugCheckDriver.

Comments

The Driver Verifier Special Pool has caught the driver accessing memory that was earlier freed.

This cannot be protected by try - except; it can only be protected by a probe.

For more information about this bug check, see the Windows DDK.


Bug Check 0xD6: DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION

The DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION bug check has value 0x000000D6. This signals the driver accessed memory beyond the end of its pool allocation.

Parameters

The following parameters are displayed on the blue screen.

Parameter | Description
1 | Memory address referenced
2 | zero: Read one: Write
3 | Address that referenced memory (if known)
4 | Reserved

If the guilty driver can be identified, its name is printed on the blue screen and stored in PUNICODE_STRING parameter of KiBugCheckDriver.

Comments

The driver allocated n bytes of memory and then referenced more than n bytes. The Driver Verifier Special Pool detected this violation.

For more information about this bug check, see the Windows DDK.


Bug Check 0xE6: DRIVER_VERIFIER_DMA_VIOLATION

The DRIVER_VERIFIER_DMA_VIOLATION bug check has a value of 0x000000E6. This is the bug check code for all Driver Verifier DMA Verification violations.

Parameters

The following parameters are displayed on the blue screen. Parameter 1 is the only parameter of interest; this identifies the exact violation.

Parameter | Description
0x03 | The driver freed the same DMA common buffer twice.
0x04 | The driver freed the same DMA adapter channel twice.
0x05 | The driver freed the same DMA map register twice.
0x06 | The driver freed the same DMA scatter-gather list twice.
0x0E | The driver attempted a DMA transfer without locking the buffer. The buffer in question was in paged memory.
0x0F | The driver or the hardware wrote past the end of its allocated DMA buffer.
0x18 | The driver attempted a DMA operation using an adapter that was already released and no longer exists.
0x19 | The driver passed a null DMA_ADAPTER value to a HAL routine.
0x1B | The driver passed an address and MDL to a HAL routine, but this address is not contained in this MDL.
0x1D | The driver attempted to map an address that was already mapped.

Cause

See the description of each code in the Parameters section for a description of the cause.

Resolving the Problem

This bug check can only occur when Driver Verifier has been instructed to monitor one or more drivers. If you did not intend to use Driver Verifier, you should deactivate it. You might consider removing the driver which caused this problem as well.

If you are the driver writer, use the information obtained through this bug check to fix the bugs in your code.

The Driver Verifier DMA Verification option is only available in Windows XP and later.

For more information about this bug check, see the Windows DDK.


Bug Check 0xF1: SCSI_VERIFIER_DETECTED_VIOLATION

The SCSI_VERIFIER_DETECTED_VIOLATION bug check has a value of 0x000000F1. This is the bug check code for all Driver Verifier SCSI Verification violations.

Parameters

The four bug check parameters are displayed on the blue screen. Parameter 1 identifies the type of violation.

Parameter 1 | Parameter 2 | Parameter 3 | Parameter 4 | Description
0x1000 | First argument passed | Second argument passed | Reserved | The miniport driver passed bad arguments to ScsiPortInitialize.
0x1001 | Delay, in microseconds | Reserved | Reserved | The miniport driver called ScsiPortStallExecution and specified a delay greater than 0.1 second, stalling the processor too long.
0x1002 | Address of routine that took too long | Address of miniport's HW_DEVICE_EXTENSION | Duration of the routine, in microseconds | A miniport routine called by the port driver took longer than 0.5 second to execute. (0.5 seconds is the limit for most routines. However, the HwInitialize routine is allowed 5 seconds, and the FindAdapter routine is exempt.)
0x1003 | Address of miniport's HW_DEVICE_EXTENSION | Address of the SRB | Reserved | The miniport driver completed a request more than once.
0x1004 | Address of the SRB | Address of miniport's HW_DEVICE_EXTENSION | Reserved | The miniport driver completed a request with an invalid SRB status.
0x1005 | Address of miniport's HW_DEVICE_EXTENSION | Address of LOGICAL_UNIT_EXTENSION | Reserved | The miniport driver called ScsiPortNotification to ask for NextLuRequest, but an untagged request is still active.
0x1006 | Address of miniport's HW_DEVICE_EXTENSION | Invalid virtual address | Reserved | The miniport driver passed an invalid virtual address to ScsiPortGetPhysicalAddress. (This usually means the address supplied doesn't map to the common buffer area.)
0x1007 | Address of ADAPTER_EXTENSION | Address of miniport's HW_DEVICE_EXTENSION | Reserved | The reset hold period for the bus ended, but the miniport driver still has outstanding requests.

Cause

See the description of each code in the Parameters section for an explanation of the cause.

Resolving the Problem

This bug check can only occur when Driver Verifier has been instructed to monitor one or more drivers. If you did not intend to use Driver Verifier, you should deactivate it. You might consider removing the driver which caused this problem as well.

If you are the driver writer, use the information obtained through this bug check to fix the bugs in your code.

The Driver Verifier SCSI Verification option is only available in Windows XP and later.

For more information about this bug check, see the Windows DDK.


TD-22.4 Blue Screen Catcher (WHQLDbg) Test Description

Overview

This test checks for the occurrence of a crash dump and gets the stack trace pertaining to the crash.

The purpose of the WHQLdbg.exe program is to ensure robustness of the printer driver while running the WHQL certification tests. This test runs on Windows 2000 and later operating systems. At this time, the program (version 0.5) only tracks kernel mode failures.

The main focus of the test is to ensure that when you are running the other WHQL tests, the printer driver or related systems do not cause a blue screen crash event. No fault injection settings are enabled.

WHQLdbg.exe will enable the following items:

  • Page heap for spooler
  • Heap tagging for spooler
  • Driver verifier
  • Heap tail checking for spooler
  • Heap free checking for spooler
  • Heap parameter checking for spooler
  • Heap validation on call for spooler
  • Place heap allocations at ends of pages and mark next page read only for spooler
  • Turns off reboot on crash
  • Setup log file for all debug output

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

To run this test, the debugger and kernel symbols must be on the system in the directory where WHQLdbg.exe program is located. In addition, the default memory dump settings must be active on the system.

Command line arguments

WHQLdbg.exe /on | Turns on debugging
WHQLdbg.exe /off | Turns off debugging
WHQLdbg.exe /check | Checks for a kernel mode breaks
WHQLdbg.exe /clean | Deletes the old dump file

Usage:

  • First the /on command should be called to enable debugging, the system needs to be rebooted for the settings to take effect.
  • Before each test is run, the /clean option should be called to wipe out any old breaks.
  • After each test the /check option should be called, this will generate the log file for pass or fail. If a break is found, the driver will be failed even if the WHQL test itself passed.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-22.5 Disabler

Overview

Disabler.exe is a command-line tool that repeatedly disables and re-enables (or, optionally, removes/refreshes) a Device Manager object for use in testing how that driver responds to many load/unload events. This test works on both Microsoft Windows 2000 and Microsoft Windows 98.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No additional hardware or software required.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-22.6 PMTE Test Description

This test has moved, see TD-3.38 ACPI Stress Tests.


TD-22.7 Off-limit API Checker

Overview

The objective of this test is to ensure that the driver does not call any APIs that are not exposed to the driver writer under the driver model. This test parses the binary to obtain the Import table and compares the list against a set of APIs that are "off-limits" for each driver model. WHQL will publish a list of APIs that should not be used for each driver model with Beta2 of the HCT.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No additional hardware or software required.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-22.8 Plug and Play Driver Test

Test Kit: HCT 11, HCT 10

Overview

The purpose of the Plug and Play Driver test is to provide driver writers with a tool that exercises various PnP related codes paths in the driver and user mode components. If used in conjunction with Driver Verifier, driver writers can feel more confident that their code is performing properly. This tool is only for use on Windows 2000.

Although by using this tool a driver will be forced to handle almost all the PnP IRPs, there are three areas that are stressed specifically: Removal, Rebalance, and Surprise Removal. The test provides a mechanism to test each of these separately or all together (that is, to stress the system). This is accomplished using a combination of user-mode API calls (using the test application) and kernel mode API calls (using an upper filter driver).

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

In order to run the test, the test’s INF (Pnpdtest.inf) must be copied to the %SystemRoot%\INF directory and the driver (Pnpfiltr.sys) must be copied to the %SystemRoot%\system32\drivers directory.

Click to show or hide information. Removal

Device removal is tested by selecting the target device and clicking the "Test Removal" button. This encompasses IRP_MN_QUERY_REMOVE_DEVICE, IRP_MN_CANCEL_REMOVE_DEVICE, and IRP_MN_REMOVE_DEVICE.

The test will attempt to install its upper filter driver on the target device stack. This results in a query-remove IRP - if this query-remove is failed the machine may need to be rebooted in order to get the filter driver onto the device stack. If the remove request is not vetoed, the device stack will be removed and restarted with the filter driver on top (class drivers and class filters on the FDO will still be above the test’s filter driver).

The test, using Setup APIs will cause a query-remove to be sent to the device stack. The filter driver will fail this remove request thus causing a cancel-remove IRP to be sent. The filter driver will assert that the cancel-remove was successful.

Next, the test app calls the appropriate class installer and any registered co-installers to disable/enable and remove/re-enumerate the device (this tests the class/co-installers handling of DIF_PROPERTYCHANGE with DICS_DISABLE, DICS_ENABLE, and DICS_PROPCHANGE). When receiving an IRP_MN_REMOVE_DEVICE, the filter driver will assert that the lower drivers completed it successfully.

The test will again call the class/co-installers this time with DIF_REMOVE and then will re-enumerate the device’s parent to attempt to restart the device.

Of course, each of these steps involves a preliminary remove request. If that request if vetoed, the device will not be removed. It is up to the driver writer’s discretion to veto a remove request when appropriate, such as while streaming video on a USB camera or if the target device is in the boot/paging path. Bear in mind that simply failing all remove requests is generally not good practice - it will not guarantee that driver will never receive a remove since a remove IRP will still be issued after a surprise removal or if anyone in the device stack fails a start IRP.

Click to show or hide information. Rebalance

Rebalance is tested by selecting the target device and clicking the "Test Rebalance" button. This encompasses IRP_MN_QUERY_STOP_DEVICE, IRP_MN_STOP_DEVICE, and IRP_MN_CANCEL_STOP_DEVICE.

As with the removal test, the test application will attempt to add an upper filter to the target device stack. If this is not successful (i.e., if someone on the target device stack failed the query-remove IRP) the machine may need to be rebooted in order to test rebalance.

Using Plug and Play Io APIs the test application and the filter driver will cause a query-stop IRP to be sent to the target device stack. The device stack will be guaranteed to receive a query-stop and cancel-stop IRP. The filter driver will assert that the cancel-stop IRP is not failed by lower drivers.

The device will only receive a stop IRP if the following two conditions are true:

  • The target device consumes hardware resources.
  • All drivers in the device stack (and children) succeed the query-stop IRP.

If both of these conditions are met, a stop IRP will be issued by the system, followed eventually by a start IRP. The filter driver will assert that the start IRP following a stop IRP is not failed.

If the target device does not consume hardware resources, stop IRP handling can still be tested. This is accomplished by testing rebalance on a resource consuming ancestor of the device. For example, consider a USB mouse connected to a USB controller enumerated by PCI. The mouse does not consume resources, but the USB controller does. If the USB controller and all its children succeed query-stop, the controller and all of its children will receive a stop IRP.

Click to show or hide information. Surprise Removal

The surprise removal test case PnP Surprise Removal (denumcmd /tc: sr) uses a private interface in PNP that simulates a surprise remove on a device (software simulation only). From a driver perspective, this test basically causes the operating system to generate all the IRPs that would normally occur if the device is surprise removed. Although the operating system provides a CM_DRP_REMOVAL_POLICY bit by which vendors can set CM_REMOVAL_POLICY_EXPECT_SURPRISE_REMOVAL (write caching disabled) or CM_REMOVAL_POLICY_EXPECT_ORDERLY_REMOVAL (write caching enabled), a USB, 1394 or Cardbus device can physically be surprise removed (by unplugging the cable) irrespective of this bit and the driver and device must be able to handle this scenario.

As with the previous tests, the test application will attempt to add an upper filter to the target device stack. If this is not successful the machine may need to be rebooted in order to test surprise removal.

When triggered by the test application, the filter driver will cause the system to send an IRP_MN_SURPRISE_REMOVAL to the device stack, followed by an IRP_MN_REMOVE_DEVICE. The filter driver will assert that both of these IRPs are completed successfully by lower drivers.

After handling these IRPs, the device will be marked by the system with the status code DN_HAS_PRIVATE_PROBLEM. The device will still appear in the device tree in Device Manager because, since it has not actually been physically removed, it will still be reported by its bus driver in response to an IRP_MN_QUERY_DEVICE_RELATIONS for BusRelations. In order to restore the device to working order, the PDO for the device must be deleted. This can be accomplished by rebooting the system, removing and re-enumerating the device’s parent, or physically removing the device and reattaching it.

Click to show or hide information. Stress

All of the above scenarios can be tested together by selecting the target device and clicking "Start Stress". The test application will randomly test rebalance and remove for five minutes after which it surprise removes the device. As with the above scenarios, the test application tries first to install an upper filter driver. If the filter is not successfully added, only remove and query-remove are guaranteed to be tested.

Results Interpretation

Errors encountered by the test in calls to Plug and Play APIs will be recorded to a log file. However, errors asserted by Driver Verifier and other built in verification mechanisms are not recorded.


TD-22.9 Signability Test Description

Test Kit: HCT 11, HCT 10

Note This test was previously referred to as the Information Catalog Syntax Checker Test.

Overview

This test examines the test device driver package for compatibility with the Microsoft digital signature process. The INF files for digitally signed driver packages must be free of errors that can interfere with the digital signature and may prevent successful installation of the driver. This test examines INFs for errors that prevent the operating system from recognizing the driver as digitally signed by Microsoft. The Signability test is required for devices using manufacturer-supplied drivers only.

Windows File Protection

In Windows 2000 and Windows XP, the device driver package must not redistribute protected system files. The INF file must not install or modify files designated as protected system files. All system files (.sys, .dll, .exe, and .ocx files) that ship on the Windows CD are protected. The True Type fonts, Micross.ttf, Tahoma.ttf, and Tahomabd.ttf, are also protected.

Information about Windows and Windows File Protection (WFP) is available at http://www.microsoft.com/hwdev/driver/sfp/wfp.asp.

For a list of the system files that are protected (at the time of this release of the Test Specification), see the WFP file list.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

To run the Signability test, the driver files must be available in their uninstalled format (for example, files on the source media).

Click to show or hide information. Command line options

You can also run the Signability test from the command prompt. During development, you might find this to be an efficient way to automate the testing of INF files for compatibility with specific operating system requirements. The program Signablity.exe is located in the \HCT\Testbin directory. The Signability test writes detailed test results to the file Signability.txt.

Syntax

The basic syntax for the program is:

Signability [/os:n ] [/driver: path ] [/auto] [/?]

Where:

Parameter

Description

/os: n

Tests the driver package for compatibility with the specified operating system (OS). The value n is a bit mask that selects the OS.

1 = Windows 98

2 = Window 2000

4 = Windows ME

8 = Windows XP

16 = Windows XP (64-Bit)

32 = Windows .NET Server 2003

The bit masks can be combined. For example, if you use the /os:7 option, the driver package is tested against Windows 98, Windows 2000, and Windows ME. (1 + 2 + 4 = 7)

/driver: path

Specifies the path to the driver distribution media.

/auto

Runs the test without requiring user interaction. This is useful for batch mode operation.

/?

Displays the command -line syntax.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program. You can examine test results in the Infcatr.log file.


TD-22.10 Short Driver Verifier Test Description

Test Kit: HCT 11, HCT 10

Overview

The Short Driver Verifier Test (shrtver.exe) uses Driver Verifier to test the stability of a driver or drivers. The test scans the system for unsigned drivers. If no such drivers exist the test ends and produces a passing log.

If there are drivers that need to be tested the Short Driver Verifier Test (SDVT) enables driver verifier and reboots the system. Once the system has rebooted, the SDVT runs the test modes and tests specified in the INI file (see below). Once the tests have completed, the SDVT resets driver verifier so that it is disabled and reboots the system again.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

There are three sections to the INI file. All are required, but they don’t need to be in any particular order. All capitalization needs to be followed because the program looks for these specific strings.

Click to show or hide information. Description section

This is a simple section that contains two lines and must follow this form:

[Description]

DriverCategory=Category

NumModes=Number of Driver Verifier Modes

[End Description]

The ‘DriverCategory’ is a string that will be displayed while the test is running, such as ‘System’ or ‘Network Interface Card.’ The ‘NumModes’ line defines the number of Driver Verifier (DV) modes that are listed in the Modes section.

Click to show or hide information. Device Class section

This section lists the number of device classes to test and then lists out the classes. For example:

[Device Classes]

NumClass=10

1394

ADAPTER

…

[End Device Classes]

All of the device classes are listed at the end of this document.

Click to show or hide information. Modes Section

This section lists the Driver Verifier (DV) modes to be run and the tests to be run under each mode. For example:

[Modes]

[DV Mode, DV Mode]

NumTests=5

test1.exe

Log=test1.log

test2.exe

Log=test2.log

…

[End]

[DV Mode]

NumTests=4

…

[End]

…

[End Modes]

Inside the Modes section are sections describing each mode to be run. The individual mode sections start with a line describing the DV Mode. DV Mode can be any of the following strings: special pool, pool tracking, fault injection, force irql, i/o checking:all (the :All is optional). These are the DV modes that can be run and any of them can be run together, simply separate the strings by commas inside the two brackets. The next line states how many tests there are to run under this mode and then the list of command lines and log file names immediately follows.

Results Interpretation

Warning Any failure encountered with this test will most likely result in severe system instability, lockups, or system stops. It may be necessary to reboot the computer in safe mode and disable Driver Verifier manually. If this is the case, boot the computer into safe mode and run verifier /reset from the command line, and then boot the computer in normal mode.


TD-22.11 Public Import Test Description

Test Kit: HCT 11, HCT 10

Overview

The Public Import test checks if any APIs called by drivers are "off-limits." This test is part of Signability and based on the driver class model. It scans all the files in the distribution media and identifies those that are linked to Ntoskrnl.exe and Hal.dll. The import table of those binaries is checked against the Public Import test illegal list (a list of unsupported Device Driver Interface [DDI] calls), which is derived by analyzing the import calls of all previously logo’d drivers.

Public Import Test Illegal List

Name of Function or Macro | Type | Error/Warn | Use instead
COMPUTE_PAGES_SPANNED | General | Error | ADDRESS_AND_SIZE_TO_SPAN_PAGES
EngCreateDeviceSurface | Printer | Error |
EngCreateBitmap | Printer | Error |
ExAcquireResourceExclusive | General | Error | ExAcquireResourceExclusiveLite
ExAcquireResourceShared | General | Error | ExAcquireResourceSharedLite
ExAllocateFromPagedLookasideList | NDIS | Error | NdisAllocateFromNPagedLookasideList
ExAllocateFromZone | General | Error |
ExConvertExclusiveToShared | General | Error | ExConvertExclusiveToSharedLite
ExDeleteResource | General | Error | ExDeleteResourceLite
ExExtendZone | General | Error |
Exfi386InterlockedDecrementLong | General | Warn |
Exfi386InterlockedIncrementLong | General | Warn |
ExfInterlockedAddULong | General | Reserved |
ExfInterlockedInsertHeadList | General | Reserved |
ExfInterlockedInsertTailLIst | General | Reserved |
ExfInterlockedRemoveHeadList | General | Reserved |
ExFreePool/withTag | General | OK for video miniports | use VideoPortFreePool, or NdisFreeMemory
ExFreeToPagedLookasideList | NDIS | Error | NdisFreeToNPagedLookasideList
ExFreeToZone | General | Error |
ExInitializePagedLookasideList | NDIS | Error | NdisInitializeNPagedLookasideList
ExInitializeResource | General | Error | ExInitializeResourceLite
ExInitializeWorkItem | General | Error | IoInitializeWorkitem
ExInitializeZone | General | Error |
ExInterlockedAllocateFromZone | General | Error |
ExInterlockedDecrementLong | General | Error | InterlockedDecrement
ExInterlockedExchangeUlong | General | Error | InterlockedExchange
ExInterlockedExtendZone | General | Error |
ExInterlockedFreeToZone | General | Error |
ExInterlockedIncrementLong | General | Error | InterlockedIncrement
ExIsFullZone | General | Error |
ExIsObjectInFirstZoneSegment | General | Error |
ExIsResourceAcquiredExclusive | General | Error | ExIsResourceAcquiredExclusiveLite
ExpInterlockedPopEntrySList | General | Warn |
ExpInterlockedPushEntrySList | General | Warn |
ExQueueWorkItem | General | Error | IoQueueWorkitem, or NdisScheduleWorkItem
ExReleaseResource | General | Error | ExReleaseResourceLite
ExReleaseResourceForThread | General | Error | ExReleaseResourceForThreadLite
ExSetTimerResolution | NDIS | Error | Feature not supported.
HalAllocateCommonBuffer | General | Error | AllocateCommonBuffer, or VideoPortAllocateCommonBuffer
HalAssignSlotResources | General | Error | PnP Manager
HalDisplayString | General | Error |
HalFreeCommonBuffer | General | Error | FreeCommonBuffer, or VideoPortFreeCommonBuffer
HalGetAdapter | General | Error | IoGetDMAAdapter
HalGetBusData | General | Error | PnP Manager IRP_MN_QUERY_INTERFACE and IRP_MN_READ_CONFIG
HalGetBusDataByOffset | General | Error | PnP Manager
HalGetDmaAlignmentRequirement | General | Error | GetDMAAlignment
HalGetInterruptVector | General | Error | PnP Manager or IoReportDetectedDevice
HalMakeBeep | General | Error |
HalReadDmaCounter | General | Error | ReadDMACounter
HalSetBusData | General | Error | IRP_MN_QUERY_INTERFACE and IRP_MN_WRITE_CONFIG
HalSetBusDataByOffset | General | Error |
HalTranslateBusAddress | General | Error | IRP_MN_QUERY_INTERFACE

Name of Function or Macro | Type | Error/Warn | Use instead
InitsafeBootMode | General | Warn |
IoAllocateAdapterChannel | General | Error | AllocateAdapterChannel
IoAllocateDriverObjectExtension | NDIS | Error | Use NdisAllocateMemoryWithTag
IoAllocateErrorLogEntry | NDIS | Error | NdisWriteErrorLogEntry, NdisWriteEventLogEntry
IoAllocateMdl | video | Warn |
IoAllocateMdl | NDIS | Error | Allow for NDIS/WDM; others use NdisAllocateBuffer.
IoAllocateWorkItem | NDIS | Error | Use NdisScheduleWorkItem
IoAssignResources | General | Error | Use PnP or IoReportDetectedDevice
IoAttachDevice | NDIS | Error | Feature not supported.
IoAttachDeviceByPointer | General | Error | IoAttachDevicetoDeviceStack
IoAttachDeviceToDeviceStack | NDIS | Error | Do not use this call." //note DDK recommends this DDI instead of IoAttachDevicebyPointer
IoBuildAsynchronousFsdRequest | NDIS | Error | Feature not supported.
IoBuildPartialMdl | NDIS | Error | Use NdisAllocateBuffer
IoBuildSynchronousFsdRequest | NDIS | Error | Feature not supported.
IoCancelIrp | NDIS | Error | Allow for NDIS/WDM
IoConnectInterrupt | NDIS Input | Error | NdisMRegisterInterrupt
IoCreateDevice | NDIS | Error | NdisMRegisterDevice
IoCreateSymbolicLink | NDIS | Error | Use NdisMRegisterDevice
IoCreateUnprotectedSymbolicLink | NDIS | Error | Feature not supported.
IoDeleteDevice | NDIS | Error | Use NdisMDeregisterDevice
IoDeleteSymbolicLink | NDIS | Error | Use NdisMDeregisterDevice
IoDetachDevice | NDIS | Error | Feature not supported.
IoDisconnectInterrupt | NDIS Input | Error | NdisMDeregisterInterrupt,
IoFlushAdapterBuffers | General | Error | FlushAdapterBuffers
IoFreeAdapterChannel | General | Error | FreeAdapterChannel
IoFreeMapRegisters | General | Error | FreeMapRegisters
IoFreeMdl | video | Warn |
IoFreeWorkItem | NDIS | Error | Use NdisFreeMemory on NDIS_WORK_ITEM.
IoGetAttachedDevice | General | Warn |
IoGetAttachedDeviceReference | NDIS | Error | Feature not supported.
IoGetDeviceInterfaceAlias | NDIS | Error | Feature not supported.
IoGetDeviceInterfaces | NDIS | Error | Feature not supported.
IoGetDeviceObjectPointer | NDIS | Error | Feature not supported.
IoGetDeviceProperty | NDIS | Error | Use NdisMQueryAdapterResources or NdisReadConfiguration.
IoGetDmaAdapter | NDIS | Error | Use NdisMInitializeScatterGatherDma
IoGetDriverObjectExtension | NDIS | Error | Feature not supported.
IoGetRelatedDeviceObject | NDIS | Error | Feature not supported.
IoInitializeTimer | NDIS | Error | Use NdisInitializeTimer etc
IoInvalidateDeviceRelations | NDIS | Error | Feature not supported.
IoInvalidateDeviceState | NDIS | Error | Use NdisMRemoveMiniport
IoMapTransfer | General | Error | MapTransfer
IoOpenDeviceInterfaceRegistryKey | NDIS | Error | Use NdisOpenConfiguration
IoOpenDeviceRegistryKey | NDIS | Error | Use NdisOpenConfiguration
IoQueryDeviceDescription | General | Error | IoGetDeviceProperty
IoQueueWorkItem | NDIS | Error | Use NdisScheduleWorkItem
IoReadPartitionTable | General | Error | IoReadPartitionTableEx
IoRegisterDeviceInterface | NDIS | Error | Feature not supported.
IoRegisterPlugPlayNotification | NDIS | Error | Feature not supported.
IoReleaseCancelSpinLock | NDIS | Error | Feature not supported.
IoReleaseRemoveLockAndWaitEx | General | Error | reserved for system use
IoReportResourceUsage | General | Error | IoReportResourceUsageForDetection
IoReportTargetDeviceChange | NDIS | Error | Feature not supported.
IoRequestDeviceEject | NDIS | Error | Feature not supported.
IoSetDeviceInterfaceState | NDIS | Error | Feature not supported.
IoSetPartitionInformation | General | Error | Use IoSetPartitionInformationEx
IoSetPartitionTable | General | Error | IoSetPartitionTableEx
IoStartTimer | NDIS | Error | Use NdisMSetTimer
IoStopTimer | NDIS | Error | Use NdisMCancelTimer
IoUnregisterPlugPlayNotification | NDIS | Error | Feature not supported.
IoUnregisterShutdownNotification | NDIS | Error | Feature not supported.
IoWMIAllocateInstanceIds | NDIS | Error | Feature not supported.
IoWMIDeviceObjectToProviderId | NDIS | Error | Feature not supported.
IoWMIRegistrationControl | NDIS | Error | Handled by NDIS.
IoWMISuggestInstanceName | NDIS | Error | Feature not supported.
IoWMIWriteEvent | NDIS | Error | NdisIndicateStatus
IoWriteErrorLogEntry | NDIS | Error | NdisWriteErrorLogEntry, NdisWriteEventLogEntry
IoWritePartitionTable | General | Error | IoWritePartitionTableEx
KeAcquireSpinLockRaiseToDpc | General | Warn |
KeAcquireSpinLockRaiseToSynch | NDIS | Error | Feature not supported.
KeAttachProcess | General except Anti-virus | Error |
KeBreakinBreakpoint | NDIS | Error | Feature not supported.
KeBugCheckEx | NDIS | Error | Feature not supported.
KeCancelTimer | NDIS | Error | NdisMCancelTimer
KeClearEvent | NDIS | Error | Use NdisResetEvent.
KeClearEvent | video | Error | VideoPortClearEvent //Note NDIS disallows this
KeDelayExecutionThread | NDIS | Error | Feature not supported.
KeDelayExecutionThread | video | Error | VideoPortStallExecution
KeDetachProcess | General except Anti-virus | Error |
KeEnterCriticalRegion | NDIS | Error | Feature not supported.
KeFlushWriteBuffer | NDIS | Error | Feature not supported.
KeGetCurrentIrql | video | Error | VideoPortGetCurrentIrql
KeGetDcacheFillSize | General | Error | GetDMAAlignment
KeInitializeApc | General | Warn |
KeInitializeDeviceQueue | NDIS | Error | Feature not supported.
KeInitializeDpc | NDIS | Error | NdisInitializeInterrupt
KeInitializeDpc | video | Error | VideoPortQueueDpc, NdisInitializeInterrupt
KeInitializeEvent | NDIS | Error | NdisInitializeEvent
KeInitializeMutex | NDIS | Error | Allow for NDIS/WDM
KeInitializeSemaphore | NDIS | Error | Allow for NDIS/WDM
KeInitializeSpinLock | video | Error | VideoPortXxxSpinLockXxx
KeInitializeTimer | NDIS | Error | NdisMInitializeTimer, NdisInitializeTimer
KeInitializeTimerEx | NDIS | Error | NdisMsetPeriodicTimer
KeInsertByKeyDeviceQueue | NDIS | Error | Feature not supported.
KeInsertDeviceQueue | NDIS | Error | Feature not supported.
KeInsertQueueApc | General | Warn | Feature not supported.
KeInsertQueueDpc | NDIS | Error | Feature not supported.
KeInsertQueueDpc | video | Error | VideoPortQueueDpc
KeLeaveCriticalRegion | NDIS | Error | Feature not supported.
KeNumberProcessors | General | Warn |
KeQueryActiveProcessors | General | Warn |
KeQueryInterruptTime | NDIS | Error | Feature not supported.
KeQueryPriorityThread | NDIS | Error | Feature not supported.
KeReadStateSemaphore | NDIS | Error | Feature not supported.
KeReadStateTimer | NDIS | Error | Feature not supported.
KeReleaseMutex | NDIS | Error | Allow for NDIS/WDM
KeReleaseSemaphore | NDIS | Error | Allow for NDIS/WDM
KeRemoveByKeyDeviceQueue | NDIS | Error | Feature not supported.
KeRemoveDeviceQueue | NDIS | Error | Feature not supported.
KeRemoveEntryDeviceQueue | NDIS | Error | Feature not supported.
KeRemoveQueueDpc | NDIS | Error | Feature not supported.
KeResetEvent | NDIS | Error | NdisResetEvent
KeRestoreFloatingPointState | NDIS | Error | Feature not supported.
KeSaveFloatingPointState | NDIS | Error | Feature not supported.
KeSetEvent | NDIS | Error | NdisSetEvent
KeSetEvent | video | Error | VideoPortSetEvent, NdisSetEvent
KeSetPriorityThread | NDIS | Error | Feature not supported.
KeSetTimer | NDIS | Error | NdisSetTimer
KeSetTimerEx | NDIS | Error | NdisMSetPeriodicTimer
KeSynchronizeExecution | NDIS | Error | NdisMSynchronizeWithInterrupt
KeTickCount | General | Warn |
KeWaitForMultipleObjects | NDIS | Error | Allow for NDIS/WDM.
KeWaitForSingleObject | NDIS | Error | NdisWaitEvent

Name of Function or Macro | Type | Error/Warn | Use instead
MmAllocateContiguousMemory | General | Error | MmAllocateContiguousMemorySpecifyCache, VideoPortAllocateContiguousMemory
MmBuildMdlForNonPagedPool | NDIS | Error | NdisAllocateBuffer
MmBuildMdlForNonPagedPool | video | Warn | NdisAllocateBuffer
MmCreateMdl | General | Error | IoAllocateMdl, NdisAllocateBuffer
MmCreateMdl | NDIS | Error | NdisAllocateBuffer
MmGetPhysicalAddress | video | Warn |
MmGetSystemAddressForMdl | General | Error |
MmGetSystemRoutineAddress | NDIS | Error | Feature not supported.
MmIsNonPagedSystemAddressValid | General | Error |
MmIsThisAnNtAsSystem | General | Error | RtlVerifyVersionInfo
MmLockPagableDataSection | NDIS | Error | Feature not supported.
MmMapIoSpace | NDIS Input | Error | NdisMMapIoSpace
MmMapLockedPages | General | Error | MmMapLockedPagesSpecifyCache
MmMapLockedPages | NDIS | Error | Use NdisQueryBufferSafe.
MmPageEntireDriver | NDIS | Error | Feature not supported.
MmProbeAndLockPages | NDIS | Error | Feature not supported.
MmProbeAndLockProcessPages | NDIS | Error | Feature not supported.
MmQuerySystemSize | video | Warn | _except_handler3
MmQuerySystemSize | NDIS | Error | Feature not supported.
MmResetDriverPaging | NDIS | Error | Feature not supported.
MmSetBankedSection | General | Warn |
MmSizeOfMdl | NDIS | Error |
MmUnlockPagableImageSection | NDIS | Error |
MmUnlockPages | NDIS | Error |
MmUnmapIoSpace | NDIS | Error | NdisMUnmapIoSpace
MmUnmapLockedPages | NDIS | Error |
MmIsDriverVerifying | General | Error |
NisMdCodePageTag | General | Warn |
NtBuildNumber | General | Warn | IoIsWdmVersionValid
NtClose | General | Warn |
NtDeviceIoControlFile | General | Warn |
NtOpenFile | General | Warn |
ObOpenObjectByPointer | General | Warn |
ObReferenceObjectByHandle | video | Warn |
PoCallDriver | NDIS | Error | Feature not supported - Implemented within NDIS.
PoCancelDeviceNotify | General | Warn |
PoRegisterDeviceForIdleDetection | NDIS | Error | Feature not supported.
PoRegisterDeviceNotify | General | Warn |
PoRegisterSystemState | NDIS | Error | Feature not supported - Implemented within NDIS.
PoRequestPowerIrp | NDIS | Error | Feature not supported - Implemented within NDIS.
PoSetPowerState | NDIS | Error | Feature not supported - Implemented within NDIS.
PoSetSystemState | NDIS | Error | Feature not supported - Implemented within NDIS.
PoStartNextPowerIrp | NDIS | Error | Feature not supported - Implemented within NDIS.
PoUnregisterSystemState | NDIS | Error | Feature not supported - Implemented within NDIS.
ProbeForRead | NDIS | Error | Feature not supported.
ProbeForWrite | NDIS | Error | Feature not supported.
PsCreateSystemThread | NDIS | Error | Feature not supported.
PsTerminateSystemThread | NDIS | Error | Feature not supported.
RaidPortReady | General | Error | StorPortReady
READ_PORT READ_PORT_Xxx | NDIS Input | Error | Use NdisReadPortXxx which map to READ_PORT_XXX.
READ_REGISTER_Xxx | Input |  |
READ_PORT_ULONG | video | Error | VideoPortReadPortUlong
READ_REGISTER_UCHAR | video | Error | VideoPortReadRegisterUchar
RtlAnsiCharToUnicodeChar | General | Warn |
RtlAssert | General | Warn |
RtlConvertLongToLargeInteger | General | Error | Please refer to the DDK for more information on the correct interfaces to use instead.
RtlConverULongToLargeInteger | General | Error | Please refer to the DDK for more information on the correct interfaces to use instead.
RtlDeleteRegistryValue | NDIS | Error | Feature not supported.
RtlEnlargedIntegerMultiply | General | Error | Please refer to the DDK for more information on the correct interfaces to use instead.
RtlEnlargedUnsignedMultiply | General | Error | Please refer to the DDK for more information on the correct interfaces to use instead.
RtlEnlargedUnisignedDivide | General | Error | Please refer to the DDK for more information on the correct interfaces to use instead.
RtlExtendedIntegerMultiply | General | Error | Please refer to the DDK for more information on the correct interfaces to use instead.
RtlExtendedLargeIntegerDivide | General | Error |
RtlExtendedMagicDivide | General | Error |
RtlFillBytes | General | Error |
RtlLargeIntegerAdd | General | Error |
RtlLargeIntegerAnd | General | Error |
RtlLargeIntegerArithmeticShift | General | Error |
RtlLargeIntegerDivide | General | Error |
RtlLargeIntegerEqualTo | General | Error |
RtlLargeIntegerEqualToZero | General | Error |
RtlLargeIntegerGreaterOrEqualToZero | General | Error |
RtlLargeIntegerGreaterThan | General | Error |
RtlLargeIntegerGreaterThanOrEqualTo | General | Error |
RtlLargeIntegerGreaterThanZero | General | Error |
RtlLargeIntegerLessOrEqualToZero | General | Error |
RtlLargeIntegerLessThan | General | Error |
RtlLargeIntegerLessThanOrEqualTo | General | Error |
RtlLargeIntegerLessThanZero | General | Error |
RtlLargeIntegerNegate | General | Error |
RtlLargeIntegerNotEqualTo | General | Error |
RtlLargeIntegerNotEqualToZero | General | Error |
RtlLargeIntegerShiftLeft | General | Error |
RtlLargeIntegerShiftRight | General | Error |
RtlLargeIntegerSubtract | General | Error |
RtlQueryRegistryValues | NDIS | Error | Use NdisReadConfiguration.
RtlRaiseException | General | Warn |
RtlTimeToSecondsSince1970 | General | Warn |
RtlUnwind | General | Warn |
RtlUpcaseUnicodeToMultiByteN | General | Warn |
RtlWriteRegistryValue | NDIS | Error | Use NdisWriteConfiguration.
RtlxAnsiStringToUnicodeSize | General | Warn |

Name of Function or Macro | Type | Error/Warn | Use instead
Wcslen | video | Error | link to libcntpr.lib instead
WRITE_PORT WRITE_PORT_Xxx | NDIS Input | Error | Use NdisWritePortXxx which map to WRITE_PORT_XXX.
WRITE_REGISTER_Xxx | Input |  |
WRITE_PORT_ULONG | video | Error | VideoPortWritePortUlong
WRITE_REGISTER_UCHAR | video | Error | VideoPortWriteRegisterUchar
WRITE_REGISTER_USHORT | video | Error | VideoPortWriteRegisterUshort
ZwCreateDirectoryObject | NDIS | Error | Feature not supported.
ZwCreateKey | NDIS | Error | Feature not supported.
ZwDeleteKey | NDIS | Error | Feature not supported.
ZwDeleteValueKey | General | Warn |
ZwEnumerateKey | NDIS | Error | Use NdisOpenConfigurationKeyByName/NdisOpenConfigurationKeyByIndex.
ZwEnumerateValueKey | NDIS | Error | Use NdisOpenConfigurationKeyByIndex and NdisReadConfiguration.
ZwFreeVirtualMemory | General | Warn |
ZwLoadDriver | General except Anti-virus | Error |
ZwMapViewOfSection | video | Warn |
ZwOpenKey | NDIS | Error | Use NdisOpenConfiguration.
ZwOpenSection | NDIS | Error | Feature not supported.
ZwOpenSection | video | Warn |
ZwQueryInformationFile | NDIS | Error | Feature not supported.
ZwQueryKey | NDIS | Error | Use NdisReadConfiguration.
ZwQuerySystemInformation | General | Warn |
ZwQueryValueKey | NDIS | Error | Use NdisReadConfiguration.
ZwReadFile | NDIS | Error | NdisMapFile, NdisUnmapFile
ZwSetSystemInformation | General | Warn |
ZwSetValueKey | NDIS | Error | Use NdisWriteConfiguration.
ZwUnloadDriver | General except Anti-virus | Error |
COMPUTE_PAGES_SPANNED | General | Error | ADDRESS_AND_SIZE_TO_SPAN_PAGES
ExAcquireResourceExclusive | General | Error | ExAcquireResourceExclusiveLite
ExAcquireResourceShared | General | Error | ExAcquireResourceSharedLite
ExAllocateFromPagedLookasideList | NDIS | Error | NdisAllocateFromNPagedLookasideList
ExAllocateFromZone | General | Error |
ExConvertExclusiveToShared | General | Error | ExConvertExclusiveToSharedLite
ExDeleteResource | General | Error | ExDeleteResourceLite
ExExtendZone | General | Error |
Exfi386InterlockedDecrementLong | General | Warn |
Exfi386InterlockedIncrementLong | General | Warn |
ExfInterlockedAddULong | General | Reserved |
ExfInterlockedInsertHeadList | General | Reserved |
ExfInterlockedInsertTailLIst | General | Reserved |
ExfInterlockedRemoveHeadList | General | Reserved |
ExFreePool/withTag | General | OK for video miniports | use VideoPortFreePool, or NdisFreeMemory
ExFreeToPagedLookasideList | NDIS | Error | NdisFreeToNPagedLookasideList
ExFreeToZone | General | Error |
ExInitializePagedLookasideList | NDIS | Error | NdisInitializeNPagedLookasideList
ExInitializeResource | General | Error | ExInitializeResourceLite

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

No additional hardware or software required.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-22.12 Sysparse Test Description

Test Kit: HCT 11

Overview

The Sysparse test inventories the devices, drivers, and software on the test system, and records this information in Sysparse.xml. The Sysparse test always passes; however, the information gathered by the Sysparse test is used as part of the submission log review to confirm the validity of failures of other tests. Specifically, the following types of information are collected in Sysparse.xml:

  • System Group: system dependant information
  • Device Group: information about the devices installed on the system
  • SystemService Group: information about the services running on the system
  • StartMenu Group: information about the programs installed on the start menu
  • Autorun Group: information about the programs that run when the user starts Windows XP on the system
  • Control Panel Group: information about the programs installed in the Control Panel
  • Uninstall Info Group: information about the programs listed in the Control Panel Add/Remove Programs dialog box

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; or Windows .NET Server 2003, Enterprise Edition.

Results Interpretation

The Sysparse test always passes.


WFP file list

Click to show or hide information. #

12520437.cpx

12520850.cpx

1394bus.sys

1394vdbg.sys

4mmdat.sys

61883.sys

6to4svc.dll

8514a.dll

Click to show or hide information. A

aaaamon.dll

access.cpl

acctres.dll

accwiz.exe

acgenral.dll

aciniupd.exe

aclayers.dll

acledit.dll

aclui.dll

acmsetup.exe

acmsetup.exe

acpi.sys

acpiec.sys

ACQ32.DLL

acregl.exe

acsetupc.dll

acsetups.exe

acsmib.dll

acspecfc.dll

acsr.exe

acssnap.dll

activeds.dll

activeds.tlb

actmovie.exe

actxprxy.dll

acverfyr.dll

acxtrnal.dll

adicsc.sys

adicvls.sys

admexs.dll

admin.dll

admin.exe

admparse.dll

admwprox.dll

admxprox.dll

adptif.dll

ADROT.dll

adsiis.dll

adsiisex.dll

adsldp.dll

adsldpc.dll

adsmsext.dll

adsnds.dll

adsnt.dll

adsnw.dll

advapi32.dll

advpack.dll

aec.sys

AF450.DLL

afd.sys

agentanm.dll

agentctl.dll

agentdp2.dll

agentdpv.dll

agentmpx.dll

agentpsh.dll

agentsr.dll

agentsvr.exe

agp440.sys

agpcpq.sys

agt0401.dll

agt0404.dll

agt0405.dll

agt0406.dll

agt0407.dll

agt0408.dll

agt0409.dll

agt040b.dll

agt040c.dll

agt040d.dll

agt040e.dll

agt0410.dll

agt0411.dll

agt0412.dll

agt0413.dll

agt0414.dll

agt0415.dll

agt0416.dll

agt0419.dll

agt041d.dll

agt041f.dll

agt0804.dll

agt0816.dll

agt0c0a.dll

agtctl15.tlb

agtintl.dll

ahui.exe

alg.exe

alifir.sys

alim1541.sys

alrsvc.dll

amd751.sys

amdk6.sys

amsint.sys

amstream.dll

ansi.sys

apcups.dll

apmbatt.sys

appconf.dll

append.exe

apphelp.dll

appmgmts.dll

appmgr.dll

appwiz.cpl

aqadmin.dll

aqueue.dll

archqic.sys

arp.exe

arp1394.sys

asctrls.ocx

asferror.dll

asfsipc.dll

asp.dll

aspperf.dll

asptxn.dll

asr_fmt.exe

asr_ldm.exe

asycfilt.dll

asyncmac.sys

at.exe

atalk.dll

atapi.sys

ati.dll

ati.sys

ati_det.sys

AtiBt829.sys

atidrab.dll

atimpab.sys

atiraged.dll

atiragem.sys

atitunep.sys

ATITVSnd.sys

atixbar.sys

atkctrs.dll

atl.dll

atlmc.sys

atmadm.exe

ATMARP.DLL

atmarpc.sys

atmarps.sys

atmepvc.sys

atmlane.sys

atmpvcno.dll

atmuni.sys

ATRACE.DLL

attrib.exe

audiosrv.dll

audstub.sys

authfilt.dll

author.dll

author.exe

authz.dll

autochk.exe

autoconv.exe

autodisc.dll

autofmt.exe

autolfn.exe

avc.sys

avcaudio.sys

avcstrm.sys

avicap.dll

avicap.dll

avicap32.dll

avifil32.dll

avifile.dll

avifile.dll

Click to show or hide information. B

basesrv.dll

batmeter.dll

batt.dll

battc.sys

bckg.dll

bckgres.dll

bckgzm.exe

bdaplgin.ax

bdasup.sys

beep.sys

bhsupp.dll

bidispl.dll

binlsvc.dll

blackbox.dll

bnts.dll

BONE.DLL

bootcfg.exe

bootok.exe

bootvid.dll

bootvrfy.exe

br549.dll

breecemc.sys

bridge.sys

brmfcwia.dll

browscap.dll

browselc.dll

browser.dll

browser.dll

browseui.dll

browsewm.dll

brpinfo.dll

btpagnt.dll

bulltlp3.sys

buslogic.sys

busmouse.sys

Click to show or hide information. C

c_g18030.dll

c_is2022.dll

c_iscii.dll

cabinet.dll

cabview.dll

cacls.exe

calc.exe

callcont.dll

CAMOCX.DLL

cap7146.sys

capesnpn.dll

cards.dll

catsrv.dll

catsrvps.dll

catsrvut.dll

cb32.exe

cbidf2k.sys

ccdecode.sys

ccfapi32.dll

ccfgnt.dll

cdaudio.sys

cdfs.sys

cdfview.dll

cdm.dll

cdmodem.dll

cdonts.dll

cdosys.dll

cdplayer.exe

cdrom.sys

certadm.dll

certcli.dll

certdb.dll

certenc.dll

CertMap.ocx

certmgr.dll

certmmc.dll

certocm.dll

certpdef.dll

certreq.exe

certsrv.exe

certutil.exe

CertWiz.ocx

certxds.dll

cewmdm.dll

cfgbkend.dll

cfgmgr32.dll

cfgwiz.exe

change.exe

changer.sys

charmap.exe

chglogon.exe

chgport.exe

chgusr.exe

chkdsk.exe

chkntfs.exe

chkr.dll

chkrres.dll

chkrzm.exe

chsbrkr.dll

chtbrkr.dll

ciadmin.dll

cic.dll

cidaemon.exe

cimw32ex.dll

cimwin32.dll

ciodm.dll

cipher.exe

cirrus.dll

cirrus_det.sys

cisvc.exe

cjime.exe

ckcnv.exe

cladmwiz.dll

class2.sys

classpnp.sys

clb.dll

clbcatex.dll

clbcatq.dll

clcreate.exe

cleanmgr.exe

clipbrd.exe

clipsrv.exe

clnetres.dll

clnetrex.dll

clspack.exe

cluadmex.dll

cluadmin.exe

cluadmmc.dll

clusapi.dll

cluscfg.exe

clusdisk.sys

clusiis4.dll

clusnet.sys

clusocm.dll

clusres.dll

clussprt.dll

clussvc.exe

cluster.exe

cmbatt.sys

cmcfg32.dll

cmd.exe

cmdial32.dll

cmdl32.exe

cmmgr32.exe

cmmon32.exe

cmnclim.dll

cmnquery.dll

cmnresm.dll

cmpbk32.dll

cmprops.dll

cmstp.exe

cmutil.dll

cnbjmon.dll

cnetcfg.dll

Cnfgprts.ocx

cnusd.dll

cnvfat.dll

coadmin.dll

colbact.dll

comaddin.dll

comadmin.dll

comcat.dll

comclust.exe

comctl32.dll

comdlg32.dll

commdlg.dll

commdlg.dll

common98.dll

common98.dll

comp.exe

compact.exe

compbatt.sys

compfilt.dll

compobj.dll

compstui.dll

comrepl.dll

comrepl.exe

comrereg.exe

comres.dll

comsetup.dll

comsnap.dll

comsvcs.dll

comuid.dll

conf.exe

confmrsl.dll

confmsp.dll

conime.exe

conman.exe

conman.exe

console.dll

control.exe

ContRot.dll

convert.exe

convlog.exe

convmsg.dll

corpol.dll

counters.dll

country.sys

cplexe.exe

cpqarray.sys

cprofile.exe

credui.dll

crtdll.dll

crusoe.sys

crypt32.dll

cryptdlg.dll

cryptdll.dll

cryptext.dll

cryptnet.dll

cryptsvc.dll

cryptui.dll

csamsp.dll

csapi3t1.dll

cscdll.dll

cscript.exe

cscui.dll

csrsrv.dll

csrss.exe

csvde.exe

ctfmon.exe

ctl3d32.dll

ctl3dv2.dll

cwcspud3.sys

Click to show or hide information. D

d3d8.dll

d3d8thk.dll

d3dim.dll

d3dim700.dll

d3dpmesh.dll

d3dramp.dll

d3dref.dll

d3drm.dll

d3dxof.dll

danim.dll

dao360.dll

dataclen.dll

datime.dll

davcdata.exe

davclnt.dll

daxctle.ocx

dbgeng.dll

dbghelp.dll

dbgtrace.exe

dbnetlib.dll

dc120.dll

dc120usd.dll

dc200usd.dll

dc210_32.dll

dc210usd.dll

dc240usd.dll

dc260usd.dll

dcap32.dll

dciman32.dll

dcomcnfg.exe

DComExt.dll

dcphelp.exe

dcpromo.dll

dcpromo.exe

ddeml.dll

ddeshare.exe

ddmprxy.exe

ddraw.dll

ddrawex.dll

ddrop.dll

ddsmc.sys

debug.exe

debugex.dll

DEFRAG.EXE

delttsul.exe

desk.cpl

deskadp.dll

deskmon.dll

deskperf.dll

devenum.dll

devmgr.dll

dfrgfat.exe

dfrgntfs.exe

dfrgres.dll

dfrgsnap.dll

dfrgui.dll

dfs.sys

dfscmd.exe

dfscore.dll

dfsgui.dll

dfsinit.exe

dfssetup.dll

dfsshlex.dll

dfssvc.exe

dgrpsetu.dll

dhcpcsvc.dll

dhcpmib.dll

dhcpmon.dll

dhcpsapi.dll

dhcpsnap.dll

dhcpssvc.dll

DHTMLED.OCX

diactfrm.dll

diantz.exe

digest.dll

dimap.dll

dinput.dll

dinput8.dll

directdb.dll

discmc.sys

discover.exe

disdnci.dll

disdnsu.dll

disk.sys

diskcopy.dll

diskdump.sys

diskperf.exe

diskperf.sys

dispex.dll

dlc.sys

dlcapi.dll

dlimport.exe

dllhost.exe

dllhst3g.exe

dlttape.sys

dmadmin.exe

dmband.dll

dmboot.sys

dmcompos.dll

dmconfig.dll

dmdlgs.dll

dmdskmgr.dll

dmdskres.dll

dmime.dll

dmintf.dll

dmio.sys

dmload.sys

dmloader.dll

dmocx.dll

dmremote.exe

dmscript.dll

dmserver.dll

dmstyle.dll

dmsynth.dll

dmusic.dll

DMusic.sys

dmutil.dll

dmview.ocx

dns.exe

dnsapi.dll

dnsmgr.dll

dnsperf.dll

dnsrslvr.dll

docprop.dll

docprop2.dll

domadmin.dll

dosapp.fon

doscalls.dll

doskey.exe

dosx.exe

Dot4.sys

Dot4Prt.sys

Dot4Scan.sys

dot4usb.sys

dplay.dll

dplaysvr.exe

dplayx.dll

dpmodemx.dll

dpnaddr.dll

dpnet.dll

dpnhpast.dll

dpnhupnp.dll

dpnlobby.dll

dpnmodem.dll

dpnsvr.exe

dpnwsock.dll

dpserial.dll

dpvacm.dll

dpvoice.dll

dpvsetup.exe

dpvvox.dll

dpwsock.dll

dpwsockx.dll

DR3020.DLL

drmclien.dll

drmk.sys

drmkaud.sys

drmstor.dll

drmv2clt.dll

drprov.dll

drvindex.inf

drwatson.exe

drwtsn32.exe

ds16gt.dLL

ds32gt.dll

dsadmin.dll

dsauth.dll

dscomobx.dll

dsctl.dll

dsdmo.dll

dsdmoprp.dll

dsfolder.dll

dshowext.ax

dskquota.dll

dskquoui.dll

dsound.dll

dsound3d.dll

DSPIMG32.DLL

dsprop.dll

dsprov.dll

dsquery.dll

dssbase.dll

dssec.dll

dssenh.dll

dsuiext.dll

dsuiwiz.dll

dswave.dll

dt_ctrl.dll

dt_ctrl.dll

dtcsetup.exe

dumprep.exe

duser.dll

dvdplay.exe

dvdupgrd.exe

dvusd.dll

dwwin.exe

dx3j.dll

dx7vb.dll

dx8vb.dll

dxapi.sys

dxdiag.exe

dxg.sys

dxgthk.sys

dxmasf.dll

dxmrtp.dll

dxtmsft.dll

dxtmsft3.dll

dxtrans.dll

Click to show or hide information. E

edb500.dll

edlin.exe

efs.sys

efsadu.dll

elmsmc.sys

els.dll

em556n4a.sys

em556n4b.sys

em556n4i.sys

encinst.exe

enet5.sys

enum1394.sys

epcfw2k.sys

epstw2k.sys

ersvc.dll

es.dll

esent.dll

esent97.dll

esentprf.dll

esentutl.exe

ess.sys

esscli.dll

ESSM2E.sys

et4000.sys

et4000_det.sys

eudcedit.exe

eventcls.dll

eventlog.dll

eventvwr.exe

evntagnt.dll

evntcmd.exe

evntrprv.dll

evntwin.exe

exabyte1.sys

exabyte2.sys

examc.sys

exe2bin.exe

expand.exe

explorer.exe

expsrv.dll

exstrace.dll

extrac32.exe

exts.dll

Click to show or hide information. F

f3ahvoas.dll

fastfat.sys

fastopen.exe

fastprox.dll

faultrep.dll

faxadmin.dll

faxcom.dll

faxcover.exe

faxdrv.dll

faxevent.dll

faxext32.dll

faxmapi.dll

faxocm.dll

faxperf.dll

faxqueue.exe

faxroute.dll

faxsend.exe

faxshell.dll

faxsvc.exe

faxt30.dll

faxtiff.dll

faxui.dll

faxxp32.dll

fc.exe

fcachdll.dll

fd16_700.sys

fdc.sys

fde.dll

fdeploy.dll

feclient.dll

fem556na.sys

fem556nb.sys

fem556ni.sys

filemgmt.dll

find.exe

findstr.exe

finger.exe

fips.sys

fireport.sys

fixmapi.exe

fjtwusd.dll

flattemp.exe

fldrclnr.dll

flpydisk.sys

fmifs.dll

fnfilter.dll

foghorn.sys

fontext.dll

fontsub.dll

fontview.exe

forcedos.exe

fortutil.exe

fp30reg.dll

fp40ext.dll

fp4amsft.dll

fp4anscp.dll

fp4apws.dll

fp4areg.dll

fp4atxt.dll

fp4autl.dll

fp4avnb.dll

fp4avss.dll

fp4awebs.dll

fp4awel.dll

fp98sadm.exe

fp98swin.exe

fpadmcgi.exe

fpadmdll.dll

fpcount.exe

fpencode.dll

fpexedll.dll

fpmmc.dll

fpmmcsat.dll

fpnwclnt.dll

fpremadm.exe

FRAME.DLL

framebuf.dll

framedyn.dll

freecell.exe

fs_rec.sys

FS2.DLL

fscfg.dll

fsconins.dll

fsusd.dll

fsutil.exe

fsvga.sys

ftdisk.sys

ftlx0411.dll

ftlx041e.dll

ftp.exe

ftpctrs2.dll

ftpmib.dll

ftpsapi2.dll

ftpsvc2.dll

ftsrch.dll

fuusd.dll

fwdprov.dll

fxsapi.dll

fxscfgwz.dll

fxsclnt.exe

fxsclntr.dll

fxscom.dll

fxscomex.dll

fxscover.exe

fxsdrv.dll

fxsevent.dll

fxsext32.dll

fxsmon.dll

fxsocm.dll

fxsperf.dll

fxsres.dll

fxsroute.dll

fxssend.exe

fxsst.dll

fxssvc.exe

fxst30.dll

fxstiff.dll

fxsui.dll

fxswzrd.dll

fxsxp32.dll

Click to show or hide information. G

g711codc.ax

g723codc.ax

gameenum.exe

gameenum.sys

gcdef.dll

gcr410p.sys

gdi.exe

gdi32.dll

genan5.sys

getmac.exe

getuname.dll

gfototwn.dll

glmf32.dll

glu32.dll

gpedit.dll

gpkcsp.dll

gpkrsrc.dll

gptext.dll

gpupdate.exe

grovel.exe

grovmsg.dll

grpconv.exe

guitrn.dll

guitrn_a.dll

gzip.dll

Click to show or hide information. H

h261_32.ax

h263_32.ax

h323.tsp

h323cc.dll

h323msp.dll

hcappres.dll

hccoin.dll

hdwwiz.cpl

help.exe

helpctr.exe

helphost.exe

helpsvc.exe

hexedit.dll

hh.exe

hhctrl.ocx

hhctrlui.dll

hhsetup.dll

hid.dll

hidbatt.sys

hidclass.sys

hidgame.sys

hidparse.sys

hidphone.tsp

hidserv.dll

hidserv.exe

hidswvd.sys

hidusb.sys

himem.sys

hlink.dll

HMMAPI.DLL

hnetcfg.dll

hnetmon.dll

hnetwiz.dll

hostmib.dll

hostname.exe

hotplug.dll

hours.ocx

hpdigwia.dll

hpgt21tk.dll

hpgt33tk.dll

hpgt42tk.dll

hpgtmcro.dll

hpmc.sys

hpmon.dll

hpn.sys

hpojwia.dll

hposcl10.dll

hpousd10.dll

hpscnmgr.dll

hpsj32.dll

hpsjinst.dll

hpsjmcro.dll

hpsjrreg.exe

hpsjusd.dll

hpt4qic.sys

HR132.DLL

hr1w.dll

hrtz.dll

hrtzres.dll

hrtzzm.exe

htimage.exe

httpext.dll

httpmib.dll

httpodbc.dll

htui.dll

hwxjpn.dll

Click to show or hide information. I

i2omgmt.sys

i2omp.sys

i8042prt.sys

ias.dll

iasacct.dll

iasads.dll

iashlpr.dll

iasmmc.dll

iasnap.dll

iasperf.dll

iaspipe.dll

iaspolcy.dll

iasrad.dll

iasrecst.dll

iassam.dll

iassdo.dll

iassvcs.dll

iasuserr.dll

ibmsync.sys

icaapi.dll

Icam3.sys

icfgnt5.dll

ichaud.sys

icmp.dll

icmui.dll

icwconn.dll

icwconn1.exe

icwconn2.exe

icwdial.dll

icwdl.dll

icwhelp.dll

icwphbk.dll

icwres.dll

icwrmind.exe

icwtutor.exe

icwutil.dll

idq.dll

idwlog.exe

ie4uinit.exe

ieakeng.dll

ieaksie.dll

ieakui.dll

iedkcs32.dll

IEINFO5.OCX

iepeers.dll

iernonce.dll

iesetup.dll

ieshwiz.exe

IEXPLORE.EXE

iexpress.exe

ifmon.dll

ifsutil.dll

igmpagnt.dll

igmpv2.dll

iis.dll

iisadmin.dll

iischema.dll

iisclex3.dll

iisclex4.dll

iisclus3.dll

iiscrmap.dll

iisdbg.dll

iisext.dll

iisfecnv.dll

iislog.dll

iismap.dll

iismui.dll

iisreset.exe

iisrstap.dll

iisrstas.exe

iisRtl.dll

iissuba.dll

iissync.exe

iisui.dll

ils.dll

ilscfg.exe

ilsdbx.dll

imadmui.dll

imagehlp.dll

imagemap.exe

imapi.exe

imapi.sys

imejpcus.dll

imejpdct.dll

imejpknl.dll

imejpmgr.exe

imejpuex.exe

imejputy.dll

imepad.dll

imeshare.dll

imeskdic.dll

imeskf.dll

imgutil.dll

imirror.dll

imm32.dll

imsinsnt.dll

indicdll.dll

inetcfg.dll

inetcomm.dll

inetcpl.cpl

inetcplc.dll

inetinfo.exe

inetmgr.dll

inetmgr.exe

inetmib1.dll

inetpp.dll

inetppui.dll

inetres.dll

inetsloc.dll

inetwiz.exe

infoadmn.dll

infocomm.dll

infoctrs.dll

infosoft.dll

initpki.dll

inport.sys

input.dll

inseng.dll

instdss5.dll

instips5.dll

instlsa5.dll

instm165.dll

instm3x5.dll

instndi5.dll

instrdp5.dll

instrsa5.dll

instsch5.dll

intelide.sys

internat.exe

intl.cpl

iologmsg.dll

ipbootp.dll

ipconf.tsp

ipconfig.exe

ipfltdrv.sys

iphlpapi.dll

ipinip.sys

ipmontr.dll

ipnat.sys

ipnathlp.dll

ippromon.dll

iprip.dll

iprip2.dll

iprop.dll

iprtprio.dll

iprtrmgr.dll

ipsec.sys

ipsec6.exe

ipseccmd.exe

ipsecmon.exe

ipsecsnp.dll

ipsecsvc.dll

ipsink.ax

ipsmsnap.dll

ipsnap.dll

ipv6.exe

ipv6mon.dll

IPX.DLL

ipxmontr.dll

ipxpromn.dll

ipxrip.dll

ipxroute.exe

ipxrtmgr.dll

ipxsap.dll

ipxsnap.dll

ipxwan.dll

irclass.dll

irda.sys

irenum.sys

irftp.exe

irmon.dll

irprops.cpl

irsir.sys

IS01.DLL

IS410.DLL

IS450.DLL

IS4X.DLL

IS50.DLL

IS60.DLL

isapips.dll

isapnp.sys

isatq.dll

iscomlog.dll

isign32.dll

isignup.exe

ism.dll

ismip.dll

ismserv.exe

ismsink.dll

ismsmtp.dll

isrpc.dll

itircl.dll

itss.dll

iuctl.dll

iuengine.dll

iwrps.dll

ixsso.dll

Click to show or hide information. J

javacypt.dll

javaprxy.dll

javart.dll

jdbgmgr.exe

jet.dll

jet500.dll

jetconv.exe

jetpack.exe

jit.dll

jobexec.dll

JOY.CPL

jscript.dll

jsproxy.dll

JUPI32.DLL

jupiw.dll

jvcmc.sys

jview.exe

Click to show or hide information. K

kbd101.dll

kbd101a.dll

kbd101b.dll

kbd101c.dll

kbd103.dll

kbd106.dll

kbd106n.dll

kbda1.dll

kbda2.dll

kbda3.dll

kbdal.dll

kbdarme.dll

kbdarmw.dll

kbdax2.dll

kbdaze.dll

kbdazel.dll

kbdbe.dll

kbdbene.dll

kbdblr.dll

kbdbr.dll

kbdbu.dll

kbdca.dll

kbdcan.dll

kbdclass.sys

kbdcr.dll

kbdcz.dll

kbdcz1.dll

kbdcz2.dll

kbdda.dll

kbddiv1.dll

kbddiv2.dll

kbddv.dll

kbdes.dll

kbdest.dll

kbdfa.dll

kbdfc.dll

kbdfi.dll

kbdfo.dll

kbdfr.dll

kbdgae.dll

kbdgeo.dll

kbdgkl.dll

kbdgr.dll

kbdgr1.dll

kbdhe.dll

kbdhe220.dll

kbdhe319.dll

kbdheb.dll

kbdhela2.dll

kbdhela3.dll

kbdhept.dll

kbdhid.sys

kbdhu.dll

kbdhu1.dll

kbdibm02.dll

kbdic.dll

kbdindev.dll

kbdinguj.dll

kbdinhin.dll

kbdinkan.dll

kbdinmar.dll

kbdinpun.dll

kbdintam.dll

kbdintel.dll

kbdir.dll

kbdit.dll

kbdit142.dll

kbdjpn.dll

kbdkaz.dll

kbdkor.dll

kbdkyr.dll

kbdla.dll

kbdlk41a.dll

kbdlk41j.dll

kbdlt.dll

kbdlt1.dll

kbdlv.dll

kbdlv1.dll

kbdmac.dll

kbdmon.dll

kbdne.dll

kbdnec.dll

kbdnec95.dll

kbdnecat.dll

kbdnecnt.dll

kbdno.dll

kbdpl.dll

kbdpl1.dll

kbdpo.dll

kbdro.dll

kbdru.dll

kbdru1.dll

kbdsf.dll

kbdsg.dll

kbdsl.dll

kbdsl1.dll

kbdsp.dll

kbdsw.dll

kbdsyr1.dll

kbdsyr2.dll

kbdtat.dll

kbdth0.dll

kbdth1.dll

kbdth2.dll

kbdth3.dll

kbdtuf.dll

kbdtuq.dll

kbduk.dll

kbdur.dll

kbdurdu.dll

kbdus.dll

kbdusa.dll

kbdusl.dll

kbdusr.dll

kbdusx.dll

kbduzb.dll

kbdvntc.dll

kbdycc.dll

kbdycl.dll

kd1394.dll

kdcom.dll

kdcsvc.dll

kdsui.dll

kdsusd.dll

kdusd.dll

kerberos.dll

kernel32.dll

key01.sys

keyboard.drv

keyboard.drv

keyboard.sys

keymgr.dll

kmddsp.tsp

kmixer.sys

kod2x0.dll

korwbrkr.dll

kousd.dll

krnl386.exe

krnlprov.dll

ks.sys

ksclockf.ax

ksdata.ax

ksecdd.sys

ksinterf.ax

KSOLAY.ax

ksproxy.ax

ksqmf.ax

kstvtune.ax

ksuser.dll

ksvpintf.ax

kswdmcap.ax

ksxbar.ax

Click to show or hide information. L

label.exe

ladmin2x.dll

ladminpx.dll

ladminx.dll

LANE.DLL

langwrbk.dll

laprxy.dll

lbrtfdc.sys

lcwiz.exe

LDAP.DLL

ldapaclx.dll

ldapctrx.dll

ldapdbx.dll

ldapsvcx.dll

ldifde.exe

lgacrop.dll

lgbClb.dll

lgdClb.dll

lgdecomp.dll

Lgdeskew.dll

lgdpinnc.dll

lgdvrc.dll

LginstSc.dll

Lgmntr.dll

lgprgres.dll

LgpUsb.dll

lgpusbrc.dll

lgpusbui.dll

lgtw.dll

lgusbcmd.dll

licenoc.dll

licmgr.exe

licmgr10.dll

licwmi.dll

lights.exe

linkinfo.dll

LLC.DLL

llsmgr.exe

llsrpc.dll

llssrv.exe

lmhsvc.dll

lmmib2.dll

lmrt.dll

lnkstub.exe

loadperf.dll

localmon.dll

localsec.dll

localspl.dll

localui.dll

locator.exe

lodctr.exe

log.dll

logagent.exe

logdrive.dll

loghours.dll

logman.exe

logoff.exe

LOGON.DLL

logon.scr

logonui.exe

logscrpt.dll

logui.ocx

lonsint.dll

loop.sys

lpdsvc.dll

lpk.dll

lpq.exe

lpr.exe

lprhelp.dll

lprmon.dll

lprmonui.dll

lrwizdll.dll

LSARPC.DLL

lsasrv.dll

lsass.exe

lserver.exe

lt200.sys

ltotape.sys

lvcam.sys

lvsound.sys

lz32.dll

lzexpand.dll

lzexpand.dll

Click to show or hide information. M

m3091dc.dll

m3092dc.dll

MAC.DLL

macfile.exe

mag_hook.dll

magnify.exe

mailmsg.dll

main.cpl

makecab.exe

mammoth.sys

mbslgn32.dll

mcast.dll

mcastmib.dll

mcd.sys

mcd32.dll

mcdsrv32.dll

mchgrcoi.dll

mciavi.drv

mciavi.drv

mciavi32.dll

mcicda.dll

mciole16.dll

mciole32.dll

mciqtz32.dll

mciseq.dll

mciseq.drv

mciseq.drv

mciwave.dll

mciwave.drv

mciwave.drv

md5filt.dll

mdhcp.dll

mdminst.dll

MDSPRIV.dll

mdsync.dll

mem.exe

memcard.sys

memgrp.dll

metadata.dll

mf.sys

MF3.DLL

mf3216.dll

mfc40.dll

mfc40u.dll

mfc42.dll

mfc42u.dll

mfcsubs.dll

MFS06CX.DLL

MFS06CZ.DLL

MFS06SP.DLL

MFS08SP.DLL

MFS12CX.DLL

MFS12SP.DLL

mga.dll

mga_det.sys

mgmtapi.dll

micross.ttf

midimap.dll

migism.dll

migism_a.dll

migisol.exe

miglibnt.dll

migload.exe

migpwd.exe

migregdb.exe

migwiz.exe

migwiz_a.exe

mimefilt.dll

mindex.dll

miniqic.sys

MISCAN32.DLL

mlang.dll

mll_hp.dll

mll_mtf.dll

mll_qic.dll

mmc.exe

mmcbase.dll

mmcndmgr.dll

mmcshext.dll

mmdet.dll

mmdrv.dll

mmefxe.ocx

mmfutil.dll

mmsys.cpl

mmsystem.dll

mmsystem.dll

mmtask.tsk

mmtask.tsk

mmutilse.dll

mnmdd.dll

mnmdd.sys

mnmsrvc.exe

mobsync.dll

mobsync.exe

modem.sys

MODEMCSA.sys

modemui.dll

modern.fon

modex.dll

mofcomp.exe

mofd.dll

moricons.dll

mouclass.sys

mouhid.sys

mountmgr.sys

mountvol.exe

mouse.drv

mouse.drv

moviemk.exe

mpe.sys

mpg2splt.ax

MPG4C32.dll

mpg4dmod.dll

mpg4ds32.ax

MPHASE32.DLL

mplay32.exe

mplayer2.exe

mpnotify.exe

mpr.dll

mprapi.dll

mprddm.dll

mprdim.dll

mprmsg.dll

mprsnap.dll

mprui.dll

mq1repl.dll

mq1sync.exe

mqac.sys

mqad.dll

MQADS.DLL

mqbkup.exe

mqcertui.dll

mqclus.dll

mqdbodbc.dll

MQDSCLI.DLL

MQDSSRV.DLL

mqexchng.exe

mqgentr.dll

mqise.dll

mqlogmgr.dll

mqmailoa.dll

mqmailvb.dll

mqmig.exe

mqmigrat.dll

MQOA.DLL

mqoa.tlb

mqoa10.tlb

mqoa20.tlb

mqperf.dll

mqqm.dll

mqrperf.dll

mqrt.dll

mqrtdep.dll

mqsec.dll

mqsnap.dll

mqsvc.exe

mqtgsvc.exe

mqtrig.dll

mqupgrd.dll

mqutil.dll

mqxp32.dll

mrinfo.exe

mrxdav.sys

mrxsmb.sys

msaatext.dll

msacm.dll

msacm32.dll

msadce.dll

msadcer.dll

msadcf.dll

msadcfr.dll

msadco.dll

msadcor.dll

msadcs.dll

msadds.dll

msadds32.ax

msaddsr.dll

msader15.dll

msado15.dll

msado20.tlb

msado21.tlb

msado25.tlb

msado26.tlb

msadomd.dll

msador15.dll

msadox.dll

msadrh15.dll

msafd.dll

msapsspc.dll

msasn1.dll

msaudite.dll

msawt.dll

mscandui.dll

mscat32.dll

mscdexnt.exe

msclus.dll

mscms.dll

msconf.dll

msconfig.exe

mscpx32r.dll

mscpxl32.dLL

msctf.dll

msctfp.dll

msdadc.dll

msdaenum.dll

msdaer.dll

msdaora.dll

msdaorar.dll

msdaosp.dll

msdaprsr.dll

msdaprst.dll

msdaps.dll

msdarem.dll

msdaremr.dll

msdart.dll

msdart32.dll

msdasc.dll

msdasql.dll

msdasqlr.dll

msdatl2.dll

msdatl3.dll

msdatsrc.tlb

msdatt.dll

msdaurl.dll

msdfmap.dll

msdtc.exe

msdtclog.dll

msdtcprx.dll

msdtcstp.dll

msdtctm.dll

msdtcui.dll

msdtcuiu.dll

msdv.sys

msdvdopt.dll

msdxm.ocx

msdxmlc.dll

msexch40.dll

msexcl40.dll

MSF06CX.DLL

MSF06CZ.DLL

MSF06SP.DLL

MSF08SP.DLL

MSF12CX.DLL

MSF12SP.DLL

msfaxmon.dll

msfs.sys

MSFSIO.sys

msg.exe

msgame.sys

msgina.dll

msgpc.sys

msgr3en.dll

msgrocm.dll

msgsvc.dll

mshearts.exe

mshta.exe

mshtml.dll

mshtml.tlb

mshtmled.dll

mshtmler.dll

msi.dll

msident.dll

msidle.dll

msidlpm.dll

msidntld.dll

msidpe.dll

msieftp.dll

msiexec.exe

msihnd.dll

msimg32.dll

msimn.exe

msimsg.dll

msimtf.dll

msinfo32.dll

msinfo32.exe

msiprov.dll

msir2jp.dll

msircomm.sys

msiregmv.exe

msisam11.dll

msisip.dll

msjava.dll

msjdbc10.dll

msjet40.dll

msjetoledb40.dll

msjint40.dll

msjro.dll

msjter40.dll

msjtes40.dll

mskssrv.sys

mslbui.dll

msls31.dll

msltus40.dll

mslwvtts.dll

MSMGR32.DLL

msmpu401.sys

msmqocm.dll

msmusd.dll

msnetobj.dll

msnsspc.dll

msobcomm.dll

msobdl.dll

msobjs.dll

msobmain.dll

msobshel.dll

MSOBWEB.DLL

msoe.dll

msoeacct.dll

msoeres.dll

msoert2.dll

msoobe.exe

msorc32r.dll

msorcl32.dll

mspaint.exe

mspatcha.dll

mspbde40.dll

mspclock.sys

mspmsp.dll

mspmspsv.dll

msports.dll

mspqm.sys

msprivs.dll

msr2c.dll

msr2cenu.dll

msratelc.dll

msrating.dll

msrd2x40.dll

msrd3x40.dll

msrepl40.dll

MSRIFFWV.sys

msrle32.dll

MSRPC.DLL

msscds32.ax

msscp.dll

msscript.ocx

mssetup.dll

mssetup.dll

mssign32.dll

mssip32.dll

mssoap1.dll

mssoapr.dll

MSSTI.DLL

msswch.dll

msswchx.exe

MST120.DLL

MST123.DLL

mstape.sys

mstask.dll

mstask.exe

MSTEE.sys

mstext40.dll

mstime.dll

mstinit.exe

mstlsapi.dll

mstsc.exe

mstsc.exe

mstscax.dll

msttssyn.dll

mstvca.dll

mstvgs.dll

msuni11.dll

msutb.dll

msv1_0.dll

msvcirt.dll

msvcp50.dll

msvcp60.dll

msvcrt.dll

msvcrt20.dll

msvcrt40.dll

msvfw32.dll

msvidc32.dll

msvidctl.dll

msvideo.dll

msvideo.dll

msw3prt.dll

mswdat10.dll

mswebdvd.dll

mswmdm.dll

mswsock.dll

mswstr10.dll

msxactps.dll

msxbde40.dll

msxml.dll

msxml2.dll

msxml2r.dll

msxml3.dll

msxml3r.dll

msxmlr.dll

msyuv.dll

mtsadmin.tlb

mtstocom.exe

mtxclu.dll

mtxdm.dll

mtxex.dll

mtxlegih.dll

mtxoci.dll

muisetup.exe

multibox.dll

mup.sys

mwcpa32.dll

mycomput.dll

mydocs.dll

myinfo.dll

Click to show or hide information. N

nabtsfec.sys

nac.dll

napmmc.dll

narrator.exe

narrhook.dll

nbf.sys

nbtstat.exe

ncobjapi.dll

NCP.DLL

ncpa.cpl

ncprov.dll

ncrc710.sys

ncxpnt.dll

nddeapi.dll

nddeapir.exe

nddenb32.dll

ndis.sys

ndisip.sys

ndisnpp.dll

ndistapi.sys

ndisuio.sys

ndiswan.sys

ndproxy.sys

ndptsp.tsp

ne2000.sys

net.exe

net1.exe

netapi.dll

netapi.dll

netapi32.dll

NETBIOS.DLL

netbios.sys

netbt.sys

netcfgx.dll

netdde.exe

netdet.dll

netdtect.dll

netdtect.sys

netevent.dll

neth.dll

netid.dll

netlogon.dll

netlogon.dll

netman.dll

netmon.exe

netmsg.dll

netoc.dll

netplwiz.dll

netrap.dll

netsetup.exe

netsh.exe

netshell.dll

netstat.exe

netui0.dll

netui1.dll

netui2.dll

newdev.dll

NEXTLINK.dll

nic1394.sys

nlhtml.dll

nlsfunc.exe

nmapi.dll

nmas.dll

nmasnt.dll

nmchat.dll

nmcom.dll

nmevtmsg.dll

nmft.dll

nmmkcert.dll

nmnt.sys

nmoldwb.dll

nmsupp.dll

nmwb.dll

nntpadm.dll

nntpapi.dll

nntpctrs.dll

nntpfs.dll

nntpmib.dll

nntpsnap.dll

nntpsvc.dll

notepad.exe

notepad.exe

notiflag.exe

npdrmv2.dll

npdsplay.dll

npfs.sys

nppagent.exe

npptools.dll

npwmsdrm.dll

nscirda.sys

NSCMPERF.dll

nscomdlg.ocx

nsepm.dll

nserror.dll

nsfts.dll

nslookup.exe

nsmmc.sys

NSUMPERF.dll

nt5.cat

nt5inf.cat

ntapm.sys

ntbackup.exe

ntbooks.exe

ntdll.dll

ntdos.sys

ntdos404.sys

ntdos411.sys

ntdos412.sys

ntdos804.sys

ntdsa.dll

ntdsapi.dll

ntdsatq.dll

ntdsbcli.dll

ntdsbmsg.dll

ntdsbsrv.dll

ntdsetup.dll

ntdskcc.dll

ntdsmsg.dll

ntdsperf.dll

ntdsutil.exe

ntdsxds.dll

ntevt.dll

ntfrs.exe

ntfrsapi.dll

ntfrsprf.dll

ntfrsupg.exe

ntfs.sys

ntfsdrv.dll

ntio.sys

ntio404.sys

ntio411.sys

ntio412.sys

ntio804.sys

ntkrnlpa.exe

ntlanman.dll

ntlanui.dll

ntlanui2.dll

ntlsapi.dll

ntmarta.dll

ntmsapi.dll

ntmsdba.dll

ntmsevt.dll

ntmsmgr.dll

ntmssvc.dll

ntoc.dll

ntoskrnl.exe

ntprint.dll

ntsd.exe

ntsdexts.dll

ntshrui.dll

ntvdm.exe

ntvdmd.dll

null.sys

nusrmgr.cpl

nw16.exe

nwapi16.dll

nwapi32.dll

nwc.cpl

nwcfg.dll

nwevent.dll

nwlnkflt.sys

nwlnkfwd.sys

nwlnkipx.sys

nwlnknb.sys

nwlnkspx.sys

nwprovau.dll

nwrdr.sys

nwscript.exe

nwwks.dll

Click to show or hide information. O

oakley.dll

objsel.dll

occache.dll

ocgen.dll

ockodak.dll

ocmanage.dll

ocmsn.dll

odbc16gt.dll

odbc32.dll

odbc32gt.dll

odbcad32.exe

odbcconf.dll

odbcconf.exe

odbcconf.rsp

odbccp32.cpl

odbccp32.dll

odbccr32.dll

odbccu32.dll

odbcint.dll

odbcji32.dll

odbcjt32.dll

odbcp32r.dll

odbctrac.dll

oddbse32.dll

odexl32.dll

odfox32.dll

odpdx32.dll

odtext32.dll

oeimport.dll

oemig50.exe

oemiglib.dll

offfilt.dll

ohci1394.sys

ole2.dll

ole2disp.dll

ole2nls.dll

ole32.dll

oleacc.dll

oleaccrc.dll

oleaut32.dll

olecli.dll

olecli.dll

olecli32.dll

olecnv32.dll

oledb32.dll

oledb32r.dll

oledb32x.dll

oledlg.dll

oleprn.dll

olepro32.dll

olesvr.dll

olesvr.dll

olesvr32.dll

olethk32.dll

oobebaln.exe

opengl32.dll

openhci.sys

oprghdlr.sys

os2.exe

os2srv.exe

os2ss.exe

oschoice.exe

osk.exe

ospf.dll

ospfagnt.dll

ospfmib.dll

osuninst.dll

osuninst.exe

Click to show or hide information. P

p3.sys

p6xx_32.dll

p6xxusd.dll

packager.exe

PageCnt.dll

panmap.dll

parallel.sys

parport.sys

parser.dll

partmgr.sys

parvdm.sys

pathping.exe

pautoenr.dll

pax.exe

pchshell.dll

pchsvc.dll

pci.sys

pciide.sys

pciidex.sys

pcmcia.sys

pdh.dll

pentnt.exe

perc2.sys

perc2hib.sys

perfctrs.dll

perfdisk.dll

perfmon.exe

perfnet.dll

perfnw.dll

perfos.dll

perfproc.dll

perfts.dll

perm2.sys

perm2dll.dll

PermChk.dll

philcam1.dll

philtune.sys

phime.exe

photowiz.dll

pid.dll

pidgen.dll

pifmgr.dll

ping.exe

ping6.exe

pjlmon.dll

plasmc.sys

plugin.ocx

plustab.dll

pmspl.dll

pmxgl.dll

pmxmcro.dll

pmxviceo.dll

pngfilt.dll

pnmsrvsx.dll

pnrmc.sys

polagent.dll

poledit.exe

policman.dll

polstore.dll

portcls.sys

powercfg.cpl

powerfil.sys

powrprof.dll

ppa.sys

ppa3.sys

PPP.DLL

prflbmsg.dll

print.exe

printui.dll

proccon.dll

proccon.exe

procconmd8.exe

procconsvc.exe

processr.sys

profdef.dll

profmap.dll

progman.exe

proquota.exe

Protected File

provthrd.dll

proxycfg.exe

psapi.dll

psbase.dll

pschdprf.dll

psched.sys

pscr.sys

psisload.dll

psnppagn.dll

pstorec.dll

pstorsvc.dll

ptpusb.dll

ptpusd.dll

pwdssp.dll

pws.exe

pwsdata.dll

pwstray.exe

pyime.exe

Click to show or hide information. Q

qappsrv.exe

qcap.dll

qcut.dll

qdv.dll

qdvd.dll

qic157.sys

ql1240.sys

qlstrmc.sys

qmgr.dll

qmgrprxy.dll

qntmmc.sys

qosname.dll

qprocess.exe

quartz.dll

query.dll

query.exe

quser.exe

qv.dll

qv.sys

qv_det.sys

qv2kux.sys

qvusd.dll

qwinsta.exe

Click to show or hide information. R

racpldlg.dll

rapilib.dll

rasacd.sys

rasadhlp.dll

rasadmin.exe

rasapi32.dll

rasauth.dll

rasauto.dll

rasautou.exe

raschap.dll

rasctrs.dll

rasdial.exe

rasdlg.dll

rasdlg4.dll

rasgprxy.dll

rasgtwy.dll

rasirda.sys

rasl2tp.sys

rasman.dll

rasmans.dll

rasmontr.dll

rasmxs.dll

rasphone.exe

rasppp.dll

raspppoe.sys

raspptp.sys

raspti.sys

rasrad.dll

rassapi.dll

rassauth.dll

rasscrpt.dll

rasser.dll

rassfm.dll

rastapi.dll

rastls.dll

rasuser.dll

rawwan.sys

rca.sys

rcamsp.dll

rcbdyctl.dll

rcimlby.exe

rcp.exe

rdbss.sys

rdchost.dll

rdpcdd.sys

rdpcfgex.dll

rdpclip.exe

rdpdd.dll

rdpdr.dll

rdpdr.dll

rdpdr.sys

rdpsnd.dll

rdpwd.sys

rdpwsx.dll

rdsaddin.exe

rdshost.exe

recover.exe

redbook.sys

redir.exe

reg.exe

reg32.dll

regapi.dll

regedit.exe

regedt32.exe

regini.exe

register.exe

regsvc.dll

regsvc.exe

regsvr32.exe

regtrace.exe

regwiz.exe

regwizc.dll

relay.dll

relog.exe

remotepg.dll

REMOTESP.TSP

remrras.exe

rend.dll

repdrvfs.dll

replace.exe

reset.exe

resrcmon.exe

resutils.dll

rexec.exe

riched20.dll

riched32.dll

rigpsnap.dll

ripagnt.dll

riprep.exe

risetup.exe

rmcast.sys

rndismp.sys

rnr20.dll

rootmdm.sys

route.exe

routeext.dll

routemon.exe

router.exe

routetab.dll

rpcns4.dll

RpcProxy.dll

rpcref.dll

rpcrt4.dll

rpcss.dll

rrasprxy.dll

rrcm.dll

rsabase.dll

RsAdmin.dll

rsaenh.dll

RsCommon.dll

RsConn.dll

RsEng.exe

RsEngPs.dll

RsFilter.sys

RsFsa.exe

rsfsaps.dll

rsh.exe

rshx32.dll

RsIdb.dll

RsJob.dll

RsLaunch.exe

rsm.exe

RsMover.dll

rsmps.dll

rsmsink.exe

rsmui.exe

rsnotify.exe

rsopprov.exe

rsoptcom.dll

RsShell.dll

RsSub.exe

RsSubPs.dll

RsTask.dll

RsTore.exe

rstrui.exe

RSVP.DLL

rsvp.exe

rsvpmsg.dll

rsvpperf.dll

rsvpsp.dll

rtcdll.dll

rtcshare.exe

rtipxmib.dll

rtm.dll

rtrfiltr.dll

rtrupg.dll

rtumext.dll

rtutils.dll

runas.exe

rundll32.exe

runonce.exe

rvse.dll

rvseres.dll

rvsezm.exe

rw001ext.dll

rwinsta.exe

rwnh.dll

Click to show or hide information. S

s3legacy.dll

s3legacy.sys

s3legacy_det.sys

safrcdlg.dll

safrdm.dll

safrslv.dll

samlib.dll

samsrv.dll

sapi.cpl

sapi.dll

sapisvr.exe

savedump.exe

sbp2port.sys

sc.exe

scarddlg.dll

scardssp.dll

scardsvr.exe

sccbase.dll

sccsccp.dll

scecli.dll

scesrv.dll

schannel.dll

schedsvc.dll

schmmgmt.dll

schupgr.exe

sclgntfy.dll

scrcons.exe

scrdenrl.dll

scrdenrl.dll

scrdenrl.dll

scredir.dll

script.dll

script.fon

script_a.dll

scripto.dll

scripto.dll

scrnsave.scr

scrobj.dll

scrrun.dll

scsiport.sys

scsiprnt.sys

scsiscan.sys

sdbinst.exe

sdpblb.dll

seaddsmc.sys

secedit.exe

seclogon.dll

secrcw32.dll

secur32.dll

security.dll

sefilshr.dll

sendcmsg.dll

sendmail.dll

sens.dll

sensapi.dll

senscfg.dll

seo.dll

seos.dll

serenum.sys

serial.sys

serialui.dll

sermouse.sys

serscan.sys

servdeps.dll

services.exe

serwvdrv.dll

sessmgr.exe

sethc.exe

setreg.exe

setup_wm.exe

setup50.exe

setupapi.dll

setupcl.exe

setupdll.dll

setupqry.dll

sfc.dll

sfc.exe

sfc_os.dll

sfcfiles.dll

sfloppy.sys

sfmapi.dll

sfmatalk.sys

sfmatmsg.dll

sfmctrs.dll

sfmmon.dll

sfmmsg.dll

sfmprint.exe

sfmpsdib.dll

sfmpsexe.exe

sfmpsfnt.dll

sfmpsprt.dll

sfmsrv.sys

sfmsvc.exe

sfmwshat.dll

sgibvid.dll

sglfb.dll

shadow.exe

share.exe

shcmn.dll

shdoclc.dll

shdocvw.dll

shell.dll

shell.dll

shell32.dll

shfolder.dll

shgina.dll

shim.dll

shimeng.dll

shimgvw.dll

shlwapi.dll

shmedia.dll

shmgrate.exe

shrpubw.exe

shscrap.dll

shsvcs.dll

shtml.dll

shtml.exe

shutdown.exe

shvl.dll

shvlres.dll

shvlzm.exe

sigtab.dll

sigverif.exe

simpdata.tlb

simptcp.dll

sis.sys

sisbkup.dll

skdll.dll

skeys.exe

slayerxp.dll

slbcsp.dll

slbkygen.dll

slbrsrc.dll

slbs.dll

slip.sys

SM5932.DLL

sm59w.dll

SM8132.DLL

sm81w.dll

SM8732.DLL

sm87w.dll

SM8932.DLL

sm89w.dll

SM8A32.DLL

sm8aw.dll

SM8C32.DLL

sm8cw.dll

SM8D32.DLL

sm8dw.dll

SM9032.DLL

sm90w.dll

SM9132.DLL

sm91w.dll

SM9232.DLL

sm92w.dll

SM9332.DLL

sm93w.dll

sm9aw.dll

SMA032.dll

sma0w.dll

sma3w.dll

SMB.DLL

smb0w.dll

smb3w.dll

smb6w.dll

smbbatt.sys

smbclass.sys

smbhc.sys

smclib.sys

smi2smir.exe

smierrsm.dll

smierrsy.dll

smimsgif.dll

smlogcfg.dll

smlogsvc.exe

smss.exe

smtpadm.dll

smtpapi.dll

smtpcons.dll

smtpctrs.dll

smtpmib.dll

smtpsnap.dll

smtpsvc.dll

sndblst.dll

sndblst.sys

sndrec32.exe

sndvol32.exe

SNMP.DLL

snmp.exe

snmpapi.dll

snmpcl.dll

snmpincl.dll

snmpmib.dll

snmpsmir.dll

snmpsnap.dll

snmpstup.dll

snmpthrd.dll

snmptrap.exe

snprfdll.dll

snyaitmc.sys

softkbd.dll

softkey.dll

softpub.dll

sol.exe

sonyait.sys

sonydcam.sys

sonymc.sys

sort.exe

sound.drv

sound.drv

spchtel.dll

spcmdcon.sys

spcommon.dll

spcplui.dll

spctramc.sys

speech.dll

spider.exe

splitter.sys

spoolss.dll

spoolsv.exe

sprestrt.exe

sptip.dll

spttseng.dll

spud.sys

sqlunirl.dll

sqlxmlx.dll

sr.sys

srchctls.dll

srchui.dll

srclient.dll

srdiag.exe

srgb color space profile.icm

sRGBColorSpaceProfile.icm

srrstr.dll

srsvc.dll

srusbusd.dll

srusd.dll

srv.sys

srvmgr.exe

srvsvc.dll

srvwiz.dll

ss3dfo.scr

ssbezier.scr

ssdpapi.dll

ssdpsrv.dll

ssflwbox.scr

ssinc.dll

ssmarque.scr

ssmypics.scr

ssmyst.scr

sspifilt.dll

sspipes.scr

ssstars.scr

sstext3d.scr

status.dll

staxmem.dll

stclient.dll

STDOLE.TLB

stdole2.tlb

stdole32.tlb

stdprov.dll

sti.dll

sti_ci.dll

stimon.exe

stisvc.exe

stivs32.dll

STKmc.sys

stobject.dll

storage.dll

storedbx.dll

storprop.dll

stream.sys

streamci.dll

streamip.sys

streams.sys

strmdll.dll

subst.exe

svcext.dll

svchost.exe

svcpack.dll

sw_effct.dll

sw_wheel.dll

swenum.sys

swmidi.sys

swpdflt2.dll

swpidflt.dll

swprv.dll

swusbflt.sys

sxs.dll

syncapp.exe

synceng.dll

syncui.dll

synth.dll

synth.sys

sysaudio.sys

SYSDM.CPL

sysedit.exe

sysinv.dll

syskey.exe

sysmod.dll

sysmod_a.dll

sysmon.ocx

sysocmgr.exe

syssetup.dll

system.drv

system.drv

systray.exe

Click to show or hide information. T

t2embed.dll

tahoma.ttf

tahomabd.ttf

tandqic.sys

tape.sys

tapi.dll

tapi.dll

tapi3.dll

tapi32.dll

tapiperf.dll

tapisnap.dll

tapisrv.dll

tapiui.dll

taskkill.exe

tasklist.exe

taskman.exe

taskman.exe

taskmgr.exe

tcmsetup.exe

TCPIP.DLL

tcpip.sys

tcpip6.sys

tcpmib.dll

tcpmon.dll

tcpmonui.dll

tcpsvcs.exe

tcptest.exe

tcptsat.dll

tdasync.sys

tdc.ocx

tdi.sys

tdipx.sys

tdnetb.sys

tdpipe.sys

tdspx.sys

tdtcp.sys

TELEPHON.CPL

telnet.exe

termdd.sys

termmgr.dll

termsrv.dll

termsrv.exe

tftp.exe

tftpd.exe

Thawbrkr.dll

themes.exe

themeui.dll

thumbvw.dll

timedate.cpl

timer.drv

timer.drv

timeserv.exe

tlntadmn.exe

tlntsess.exe

tlntsvr.exe

tlntsvrp.dll

tls236.dll

tmplprov.dll

toolhelp.dll

tools.dll

tosdvd.sys

trace.dll

tracerpt.exe

tracert.exe

tracert6.exe

traffic.dll

TRAIL.DLL

trialoc.dll

trident.sys

TRIEDIT.DLL

trksvr.dll

trkwks.dll

trnsprov.dll

tsadmin.exe

tsappcmp.dll

TSBMCE.sys

tscc.dll

tscfgwmi.dll

tscon.exe

tsctrc.dll

tsctrc.dll

tscupgrd.exe

tsd32.dll

tsddd.dll

tsdiscon.exe

tsec.dll

tshoot.ocx

tskill.exe

tsoc.dll

tsprof.exe

tsshutdn.exe

tsuserex.dll

twain.dll

twain_32.dll

twrc120.dll

twrc200.dll

twui120.dll

twui200.dll

twunk_16.exe

twunk_32.exe

txfaux.dll

txflog.dll

typelib.dll

typeperf.exe

Click to show or hide information. U

u1220_32.dll

u1220usd.dll

udfs.sys

udhisapi.dll

ufat.dll

uhcd.sys

uihelper.dll

ulib.dll

umandlg.dll

umaxcam.dll

umaxp60.dll

umaxpcls.sys

umaxu12.dll

umaxu22.dll

umaxu40.dll

umaxud32.dll

umaxusd.dll

umdmxfrm.dll

umpnpmgr.dll

uniansi.dll

uniime.dll

UNIMDM.TSP

unimdmat.dll

uniplat.dll

unlodctr.exe

unregmp2.exe

unsecapp.exe

untfs.dll

update.sys

updprov.dll

upg351db.exe

UPLOADM.EXE

upnp.dll

upnpcont.exe

upnphost.dll

upnpui.dll

ups.exe

upwizun.exe

ureg.dll

url.dll

urlmon.dll

usb8023.sys

USBAUDIO.sys

usbcamd.sys

usbcamd2.sys

usbccgp.sys

usbd.sys

usbehci.sys

usbhub.sys

usbintel.sys

usbmon.dll

usbohci.sys

usbport.sys

usbprint.sys

usbscan.sys

usbser.sys

usbstor.sys

usbuhci.sys

usbui.dll

user.exe

user32.dll

userenv.dll

userinit.exe

usp10.dll

usrmgr.exe

utildll.dll

utilman.exe

uxtheme.dll

Click to show or hide information. V

vbajet32.dll

vbisurf.ax

vbscript.dll

vcdex.dll

vcmd.exe

vcmshl.dll

Vdict.dll

vdmdbg.dll

vdmredir.dll

ver.dll

ver.dll

verifier.dll

verifier.exe

version.dll

vfpodbc.dll

vfwwdm32.dll

vga.dll

vga.drv

vga.drv

vga.sys

vga256.dll

vga64k.dll

vgaoem.fon

vgx.dll

viaagp.sys

viaide.sys

videoprt.sys

viewprov.dll

VINES.DLL

vjoy.dll

vmhelper.dll

vmmreg32.dll

volsnap.sys

vslinka.sys

vss_ps.dll

vssadmin.exe

vssapi.dll

vssvc.exe

VText.dll

vwipxspx.dll

vwipxspx.exe

Click to show or hide information. W

w32.dll

w32time.dll

w32tm.exe

w32topl.dll

w3ctrs.dll

w3ext.dll

w3scfg.dll

w3svapi.dll

w3svc.dll

w95upgnt.dll

wab.exe

wab32.dll

wab32res.dll

wabfind.dll

wabimp.dll

wabmig.exe

wam.dll

wamps.dll

wamreg.dll

wamregps.dll

wanarp.sys

wangqic.sys

watchdog.sys

wavemsp.dll

wb32.exe

wbemads.dll

wbemads.tlb

wbemcntl.dll

wbemcomn.dll

wbemcons.dll

wbemcore.dll

wbemdisp.dll

WBEMDISP.TLB

wbemess.dll

wbemperf.dll

wbemperm.exe

wbemprox.dll

wbemsvc.dll

wbemtest.exe

wbemupgd.dll

wceusbsh.sys

wdigest.dll

wdmaud.sys

wdvga.sys

wdvga_det.sys

webcheck.dll

webclnt.dll

webhits.dll

webvw.dll

weitekp9.dll

weitekp9.sys

weitekp9_det.sys

welcome.exe

wextract.exe

wfwnet.drv

wfwnet.drv

wiaacmgr.exe

WIADEFUI.DLL

WIADSS.DLL

wiafbdrv.dll

wiamsmud.dll

WIASCR.DLL

WIASERVC.DLL

WIASHEXT.DLL

wiavideo.dll

wiavusd.dll

wifeman.dll

win32k.sys

win32spl.dll

win87em.dll

winchat.exe

winfax.dll

winhelp.exe

winhlp32.exe

winhlp32.exe

wininet.dll

winipsec.dll

winlogon.exe

winmgmt.exe

winmgmtr.dll

winmine.exe

winmm.dll

winmsd.exe

winnls.dll

winntbbu.dll

winrep.exe

winrnr.dll

wins.exe

winscard.dll

winsctrs.dll

winsevnt.dll

winsmib.dll

winsmon.dll

winsock.dll

WINSPL.DLL

winspool.drv

winspool.drv

winspool.exe

winsrpc.dll

winsrv.dll

winssnap.dll

winsta.dll

winstrm.dll

wintrust.dll

winver.exe

wisc10.dll

wizmgr.exe

wjview.exe

wkssvc.dll

wlbs.exe

wlbs.sys

wlbsctrl.dll

wlbsprov.dll

wldap32.dll

wlnotify.dll

wmadmod.dll

wmadmoe.dll

wmasf.dll

wmdmlog.dll

wmdmps.dll

wmerrenu.dll

wmi.dll

wmi2xml.dll

wmiacpi.sys

wmiadap.exe

wmiapres.dll

wmiaprpl.dll

wmiapsrv.exe

wmic.exe

wmicookr.dll

wmicore.dll

wmidcprv.dll

wmidx.ocx

wmilib.sys

wmimsg.dll

wmipcima.dll

wmipdskq.dll

wmipicmp.dll

wmipiprt.dll

wmipjobj.dll

wmiprop.dll

wmiprov.dll

wmiprvsd.dll

wmiprvse.exe

wmipsess.dll

wmiscmgr.dll

wmisvc.dll

wmitimep.dll

wmiutils.dll

wmmfilt.dll

wmmres.dll

wmmutil.dll

wmnetmgr.dll

wmp.ocx

wmpcd.dll

wmpcore.dll

wmplayer.exe

wmploc.dll

wmpshell.dll

wmpstub.exe

wmpui.dll

wmpvis.dll

wmsdmod.dll

wmsdmoe.dll

wmsocm.dll

wmstream.dll

wmv8dmod.dll

wmv8ds32.ax

wmvcore.dll

wmvdmod.dll

wmvdmoe.dll

wmvds32.ax

wordpad.exe

wow32.dll

wowdeb.exe

wowexec.exe

wowfax.dll

wowfaxui.dll

wpabaln.exe

wpnpinst.exe

WrapSAPI.dll

write.exe

ws2_32.dll

ws2help.dll

ws2ifsl.sys

wscript.exe

wsecedit.dll

wshatm.dll

wshclus.dll

wshcon.dll

wshext.dll

wship6.dll

wshirda.dll

wshisn.dll

wshnetbs.dll

wshom.ocx

wshrm.dll

wshtcpip.dll

wsnmp32.dll

wsock32.dll

wstdecod.dll

wtsapi32.dll

wttss22.dll

wuauclt.exe

wuaueng.dll

wuauserv.dll

wupdinfo.dll

wupdmgr.exe

wuv3is.dll

wzcdlg.dll

wzcsapi.dll

wzcsvc.dll

Click to show or hide information. X

xactsrv.dll

Xcommand.dll

xcopy.exe

xenroll.dll

xenroll.dll

xenroll.dll

Xlisten.dll

XNS.DLL

xolehlp.dll

xrxflnch.exe

XTel.Dll

Xvoice.dll

Click to show or hide information. Z

zclientm.exe

zcorem.dll

zeeverm.dll

zipfldr.dll

znetm.dll

zoneclim.dll

zonelibm.dll

zoneoc.dll


Using a kernel debugger to troubleshoot bug checks

A driver failure can cause the target system to become unresponsive or to generate a system stop, or bug check. When Windows encounters a condition that compromises the safe operation of the system, the system halts and displays error information on the screen. The system can also be configured to write the contents of system memory to a log file, creating a memory dump, or crash dump file. With the help of a kernel-mode debugger, you can use the information contained in the crash dump to analyze the cause of the failure.

Click to show or hide information. Using a kernel-mode debugger

The following section outlines the steps required to set up your system for kernel-mode debugging.

Click to show or hide information. Setting up the system for debugging

You can run the kernel-mode debugger on the target system (local), or on a host development system (remote). After you decide where you want to debug the crash dump file, install the debugging tools and symbol files on that system. It might be preferable to use the kernel-mode debugger on the host system where you have access to source code and symbols for your driver. In either case, you need to enable the target system to write memory dump files.

Note It is possible to configure the target system to break into the kernel debugger when a bug check occurs. However, this setup is not recommended if you are using the HCT. Using the crash dump file and the kernel debugger is the best option for initial analysis of the bug check.

Click to show or hide information. Installing the Debugging Tools for Windows

If you have not already done so, you must obtain and install the Debugging Tools for Windows package. This package includes the Microsoft Windows Debugger (WinDbg), which can be used for user-mode and kernel-mode debugging. The debugger supports Microsoft Visual Studio debug symbol (.pdb) and COFF symbol (.dbg) file formats. This package also includes detailed documentation that describes setting up and using a kernel debugger.

You can install the Debugging Tools for Windows from the Customer Support Diagnostics CD, the Platform SDK, the Windows DDK, or from the Web at http://www.microsoft.com/ddk/debugging.

Click to show or hide information. Enabling the memory dump file on the target system

During a system stop, Windows displays the error information on screen, often referred to as the stop screen. This information includes the bug check code and other system data that provide valuable information about the cause and the location of the failure. When crash dumps are enabled, Windows saves all the bug check information to a file along with the contents of memory, saving the state of the system at the moment of the failure. To create a memory dump file (or crash dump) for post-stop analysis, you need to modify the Windows Startup and Recovery settings.

Note You must be a system administrator to modify these settings.

To change the Startup and Recovery settings

  1. Log on to the target system as an administrator.
  2. Open the Control Panel and double-click the System icon.
  3. Select the Advanced tab, and click Settings under Startup and Recovery.
  4. For the Write debugging information options, select Kernel memory dump.

This recovery option writes the entire contents of kernel memory to a file. This kernel memory dump file is significantly smaller than the complete memory dump, but it provides enough information for most kernel-mode debugging purposes. The default path and name for the kernel memory dump file is %SystemRoot%\Memory.dmp.

  5. After you have made the changes, restart the target system.

Click to show or hide information. Installing the Windows symbol files

You can run the kernel-mode debugger on a host development system, or on the target system. In either case, you must obtain and install the Windows symbols that match the operating system (OS) of the target system. That is, the symbols must correspond with the version of the OS running on the system where the memory dump file is created. For example, it the target system is running Windows XP and you are doing the debugging on the host system, which is running Windows 2000, you would need to install the Windows XP debugging symbols on the host system. The Windows symbols must be installed on the system that runs the kernel debugger.

You can download the debugging symbols from http://www.microsoft.com/ddk/debugging/symbols.asp

Click to show or hide information. Obtaining the source code and debugging symbols for your driver

If the cause of the system stop is the device driver you are testing, you might want to have access to the driver source code and symbols. If the bug check information provides an address where the failure occurred, you may be able to locate the instruction in the driver source code.

Click to show or hide information. Running the tests and creating the memory dump file

From Test Manager, run the test that caused the system stop. This time the bug check generates the crash dump file. If you are running the kernel debugger on a host development system, you will need to transfer the crash dump file from the target system. If you enable the target system to do a complete memory dump, this file can be quite large, equal to the amount of physical memory on the system. You may need to plan a suitable method of transferring the data if the target and host systems are not connected on a network.

Click to show or hide information. Running the kernel debugger

After you create the crash dump file, you can load the file into the kernel debugger. These procedures describe using the Microsoft Windows Debugger (WinDbg).

To run the kernel debugger

  1. From the Start menu, select Debugging Tools for Windows, and then click WinDbg.
  2. From the File menu, select Symbol File Path and browse to the directory where you loaded the Windows symbol files.
  3. Select Open Crash Dump from the File menu and specify the name of the crash dump file.

On the target system, the default name and location for the file is %SystemRoot%\Memory.dmp.

When the crash dump file loads, the initial bug check information appears. This information includes the bug check code, specified in hexadecimal. Depending upon the type of system stop, the bug check code can be followed immediately by up to four additional bug check parameters. One of the parameters is often the address of the instruction where the failure occurred. If the driver that caused the crash can be identified, the name of the driver also appears.

The following is an example of a crash dump file:

Loading Dump File [C:\WINDOWS\MEMORY.DMP]

Kernel Dump File: Full address space is available

Symbol search path is: c:\windows\symbols\exe

..........

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck D5, {a7ab3f80, 1, f95e3639, 0}

Probably caused by : xxx_zzz.sys ( xxx_zzz+1639 )

Click to show or hide information. Analyzing the crash dump file

After you load the crash dump file into the kernel debugger, you can obtain more information about the events that caused the crash.

From the debugger command prompt, enter the following command:

!analyze -v

This command provides a detailed analysis of the bug check. The following is a sample output:

kd> !analyze -v

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL (d5)

Memory was referenced after it was freed.

This cannot be protected by try-except.

When possible, the guilty driver's name (Unicode string) is printed on

the bugcheck screen and saved in KiBugCheckDriver.

Arguments:

Arg1: a7ab3f80, memory referenced

Arg2: 00000001, value 0 = read operation, 1 = write operation

Arg3: f95e3639, if non-zero, the address which referenced memory.

Arg4: 00000000, (reserved)

Debugging Details:

------------------

WRITE_ADDRESS: a7ab3f80 Special pool

FAULTING_IP:

xxx_zzz+1639

f95e3639 897718 mov [edi+0x18],esi

MM_INTERNAL_CODE: 0

IMAGE_NAME: xxx_zzz.sys

MODULE_NAME: xxx_zzz

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: D5_W

In this example, the symbolic name of bug check 0xD5 is DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL. And the !analyze –v command provided more detail about the nature and location of the failure. For information about bug check codes and their parameters, refer to the Driver Verifier information in the DDK.

If you have the source code and symbols for the driver xxx_zzz.sys, you could use the address provided in Arg3, 0xf95e3639, to locate the place in the source code where the memory access occurs. From the Edit menu, choose Go to Address, and then enter 0xf95e3639 ("the address that referenced memory").

The basic information provided here should be enough to help you to get started using the bug check codes to find out more about the nature of the driver failure. For detailed information about kernel-mode debugging and the device driver operation, see the documentation for the Windows Driver Development Kit and the Debugging Tools for Windows package.

Click to show or hide information. Debugging I/O verification errors

When you run Driver Verifier or the Device Path Exerciser tests from Test Manager (HCT), Driver Verifier runs with the I/O Verification option selected. Bug checks can be issued for various I/O violations. These violations can result in Bug Check 0xC9, DRIVER_VERIFIER_IOMANAGER_VIOLATION. In addition, I/O verification errors can occur that cause the system to halt, but which are not actually bug checks. In these cases, the bug check screen (or stop screen) does not display the bug check code, the messages IO SYSTEM VERIFICATION ERROR and WDM DRIVER ERROR appear, along with the hexadecimal I/O error code.

However, the kernel-mode crash dump file contains the bug check code (major code: 0xC9) and hexadecimal I/O error code (minor code: 0x200 to 0x2FF).

Using this information, you can verify the bug check online. If available, the links contain debugging tips or other useful information that you can use to solve problems with device driver I/O activities. You can also search for the bug check codes in the Windows DDK.

Click to show or hide information. Example of an I/O verification error

WDM DRIVER ERROR: [my400.sys @ 0xFC784346] An IRP dispatch handler has

returned without passing down or completing this Irp or

someone forgot to return STATUS_PENDING. (Irp = 92258F00

).

IRP_MJ_DEVICE_CONTROL

[ DevObj=80D86BB8, FileObject=FFB74AA0, Parameters=00000028 00000018 00210012 00

http://www.microsoft.com/hwdq/bc/default.asp?os=5.1.3609&major=0xc9&minor=0x226&

Click to show or hide information. For information about I/O Verification errors

Bug check 0xC9, 0x201

http://www.microsoft.com/hwdq/bc/default.asp?os=5.1.3609&major=0xc9&minor=0x201&

Bug check 0xC9, 0x202

http://www.microsoft.com/hwdq/bc/default.asp?os=5.1.3609&major=0xc9&minor=0x202&

Bug check 0xC9, 0x203

http://www.microsoft.com/hwdq/bc/default.asp?os=5.1.3609&major=0xc9&minor=0x203&

Bug check 0xC9, 0x204

http://www.microsoft.com/hwdq/bc/default.asp?os=5.1.3609&major=0xc9&minor=0x204&

Bug check 0xC9, 0x205

http://www.microsoft.com/hwdq/bc/default.asp?os=5.1.3609&major=0xc9&minor=0x205&

Bug check 0xC9, 0x206

http://www.microsoft.com/hwdq/bc/default.asp?os=5.1.3609&major=0xc9&minor=0x206&

Bug check 0xC9, 0x207

http://www.microsoft.com/hwdq/bc/default.asp?os=5.1.3609&major=0xc9&minor=0x207&

Bug check 0xC9, 0x208

http://www.microsoft.com/hwdq/bc/default.asp?os=5.1.3609&major=0xc9&minor=0x208&

Bug check 0xC9, 0x209

http://www.microsoft.com/hwdq/bc/default.asp?os=5.1.3609&major=0xc9&minor=0x209&

Bug check 0xC9, 0x210

http://www.microsoft.com/hwdq/bc/default.asp?os=5.1.3609&major=0xc9&minor=0x210&

Related Links

Device Path Exerciser Test: Troubleshooting Information


Chapter 23: Network Adapter Test Specification

Introduction to Network Adapter Test

Network Driver Interface Specification (NDIS) provides a common mechanism by which any given NDIS-compatible transport driver can communicate with any NDIS-compatible network adapter driver. Moreover, it provides for multiple transports to work over multiple network adapters by supporting multiplexing between transports and drivers.


Network Adapter Test Assertions

This section contains the test assertions for network adapters.

Asynchronous Transfer Mode (ATM) Test Assertions

This section contains the Asynchronous Transfer Mode (ATM) assertions for the TD-23.1 NDIS Test Tool.

23.1.1 The Network Adapter must have the ability to add additional local ATM addresses on which the card can receive calls. (1c_AddAddr)

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.2 The Network Adapter must have the ability to send/receive packets of a range of sizes on a CBR (constant bit rate) call. (1c_CSend)

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.3 The Network Adapter must have the ability to send/receive packets of a range of sizes on a CBR (constant bit rate) call. (1c_CStress)

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.4 The Network Adapter must have the ability to query the GUIDs using WMI. (1c_GUIDwithWMIAtm)

This tests the querying of driver information using WMI. This test only has meaning for Windows 98 and Windows NT 5.0. In general, this script is testing ndis.sys and WMI rather than your driver. If your driver exports any private GUIDs to WMI, you need to look at the last few variations to make sure your driver is handling these correctly. The test uses a QueryGlobalStatistics call with OID_GEN_SUPPORTED_GUIDS to get the list of private GUIDs exported by your driver. It then attempts to query these GUIDs using WMI. The Ndis Tester is not able to verify the values returned by most of these GUIDs. You should check this log carefully for problems.

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.5 The Network Adapter must have the ability to hibernate and restore. (1c_Hibernate)

Also the communication must still works after restoring from hibernation.

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.6 The Network Adapter must have the ability to query the information OIDs. (1c_InfoOIDsAtm)

Only the required ATM OIDs are queried and checked. This test performs a series of NdisRequest calls to the driver, to verify that it supports the querying of all required information OIDS The NDIS Tester is not able to verify the values returned by most of these OIDs. You should check this log carefully for problems.

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.7 The initialization time for a network card must not be too long. (1c_InitTimeAtm)

It tests the cable disconnected case first and then the cable connected case.

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.8 The Network Adapter must have the ability to hibernate and restore. (1c_load)

Also the communication must still works after restoring from hibernation.

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.9 The Network Adapter must have the ability to make different types of calls to itself through the ATM switch. (1c_MakeCall)

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.10 The Network Adapter must have the ability to detect media connect / disconnect. (1c_media)

This test verifies the ability of a network card to detect media connect/disconnect and makes a call to verify the connection.

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.11 The Network Adapter must have the ability to send/receive on multiple calls simultaneously. (1c_MultiSend)

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.12 The Network Adapter must have the ability to open and close Adapter repeatedly. (1c_OpenCard)

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.13 The Network Adapter must have the ability to open and close SAPs (service access points). (1c_OpenSAP)

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.14 The Network Adapter must have the ability to open and close VCs (virtual circuits). (1c_OpenVC)

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.15 The Network Adapter must have the ability to handle a reset when packets are being sent and received. (1c_resetatm)

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.16 The Network Adapter must have the ability to send/receive packets on different types of calls. (1c_SendAtm)

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.17 The Network Adapter must have the ability to open and close an address family. (1c_SetAf)

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.18 The Network Adapter must have the ability to send packets of different sizes. (1c_SrQueue)

The test forces various types of packet queuing on received packets

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.19 The Network Adapter must have the ability to send packets of different sizes. (1c_SSend)

This tests the ability to send/receive packets of a range of sizes on a UBR (unspecified bit rate) calls.

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.20 The Network Adapter must have the ability to standby/restore. (1c_StandBy)

This tests the ability to standby and restore. It also makes sure that communication still works after restoring from standby.

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.21 The Network Adapter must have the ability to query the information OIDs (object IDs). (1c_StatOIDsAtm)

Only the required ATM OIDs are queried and checked. This performs a series of NdisRequest calls to the driver, to verify that it supports the querying of all required information OIDs The Ndis Tester is not able to verify the values returned by most of these OIDs. The logs should be checked carefully for problems.

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.22 The Network Adapter must have the ability to stress send/receive on UBR (unspecified bit rate) calls. (1c_StressAtm)

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.23 The Network Adapter must have the ability to send/receive on multiple calls simultaneously. (1c_StrSend)

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.24 Performance Profile Tests on CBR (constant bit rate) Calls. (2c_CProf)

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.25 The Network Adapter must have the ability to send packets on CBR (unspecified bit rate) calls. (2c_CSend)

This tests the ability to send/receive packets of a range of sizes on a CBR call.

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.26 The Network Adapter must have the ability to stress send/receive on CBR (constant bit rate) calls. (2c_CStress)

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.27 The Network Adapter must have the ability of the test ATM device to make calls to the ATM Support Card. (2c_MakeCall)

This tests the ability to make different types of calls to itself through the ATM switch.

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.28 The Network Adapter must have the ability to send/receive on multiple calls. (2c_MultiSend)

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.29 The Network Adapter must have the ability of the test ATM device to make party calls to the Support Card. (2c_PartyCall)

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.30 Performance Profile Tests on UBR (unspecified bit rate) Calls. (2c_PProf)

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.31 The Network Adapter must have the ability to receive packets in promiscuous mode. (2c_Promis)

In a local area network (LAN), promiscuous mode is a mode of operation in which every data packet transmitted is received and read by every network adapter. Promiscuous mode must be supported by each network adapter as well as by the input/output driver in the host operating system. Promiscuous mode is often used to monitor network activity.

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.32 The Network Adapter must have the ability to send packets of different sizes. (2c_SrQueue)

This test forces various types of packet queuing on received packets.

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.33 The Network Adapter must have the ability to send packets on UBR (unspecified bit rate) calls. (2c_SSend)

This tests the ability to send/receive packets of a range of sizes on a UBR (unspecified bit rate) call.

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool

23.1.34 The Network Adapter must have the ability to stress send/receive on UBR (unspecified bit rate) call. (2c_Stress)

Reference Document: WLP# - B7.1.1.1
Test Description: TD-23.1 NDIS Test Tool


Network Adapter Test Descriptions

This section describes the tests provided.


IrDA Test Assertions

This section contains the IrDA assertions for the TD-23.1 NDIS Test Tool.

23.2.1 The Network Adapter must have the ability to query the GUIDs using WMI. (1c_GUIDwithWMIIrda)

This tests the querying of driver information using WMI. This test only has meaning for Windows 98 and Windows NT 5.0. In general, this script is testing ndis.sys and WMI rather than your driver. If your driver exports any private GUIDs to WMI, then you need to look at the last few variations to make sure your driver is handling these correctly. The test uses a QueryGlobalStatistics call with OID_GEN_SUPPORTED_GUIDS to get the list of private GUIDs exported by your driver. It then attempts to query these GUIDs using WMI. The NDIS test is not able to verify the values returned by most of these GUIDs. You should check this log carefully for problems.

Reference Document: WLP# - B2.3.1.4
Test Description: TD-23.1 NDIS Test Tool

23.2.2 The Network Adapter must have the ability to query the information OIDs (1c_InfoOIDsIrda)

This performs a series of NdisRequest calls to the driver, to verify that it supports the querying of all required information OIDs. The Ndis Tester is not able to verify the values returned by most of these OIDs. You should check this log carefully for problems.

Reference Document: WLP# - B2.3.1.4
Test Description: TD-23.1 NDIS Test Tool

23.2.3 The Network Adapter must have the ability to reset the card without damaging queues, etc. (1c_resetirda)

This attempts to reset the card multiple times, while at the same time sending lots of packets over that card. It tests to make sure that the card can reset itself and that it deals properly with packets that have been given to it to send when interrupted by a reset.

Reference Document: WLP# - B2.3.1.4
Test Description: TD-23.1 NDIS Test Tool

23.2.4 The Network Adapter must have the ability to set baud rate on IrDA driver. (1c_SetBaud)

Reference Document: WLP# - B2.3.1.4
Test Description: TD-23.1 NDIS Test Tool

23.2.5 The Network Adapter must have the ability to query the statistics OIDs (1c_StatOIDsIrda)

Only the required IrDA OIDs are going to be queried for and checked. Actual querying for optional OIDs is not currently performed. This gets the list of OIDs supported for QueryGlobalStatistics, and proceeds to query all of them. It then proceeds to do a QueryAllGlobalStatistics The NDIS Tester is not able to verify the values returned by most of these OIDs. You should check this log carefully for problems.

Reference Document: WLP# - B2.3.1.4
Test Description: TD-23.1 NDIS Test Tool

23.2.6 The Network Adapter must have the ability to hibernate and restore. (2m_Hibernate)

This verifies the ability to hibernate and restore. It also makes sure that communication with the network (i.e. with the test server) still works after restoring from hibernation.

Reference Document: WLP# - B2.3.1.4
Test Description: TD-23.1 NDIS Test Tool

23.2.7 The Network Adapter must have the ability to load and unload the driver (2m_Load)

This verifies the ability to hibernate and restore. It also makes sure that communication with the network (that is, with the test server) still works after restoring from hibernation.

Reference Document: WLP# - B2.3.1.4
Test Description: TD-23.1 NDIS Test Tool

23.2.8 The Network Adapter must have the ability to receive packets sent by remote. (2m_Rcv)

Reference Document: WLP# - B2.3.1.4
Test Description: TD-23.1 NDIS Test Tool

23.2.9 The Network Adapter must have the ability to use sendpackets over IrDA. (2m_Send)

The server sends the packets and the client receives them. This tests the handling of NdisSendPackets by ndis.sys. If your driver actually supports SendPackets, you should see arrays of packets of the appropriate size handled to your driver during this test.

Reference Document: WLP# - B2.3.1.4
Test Description: TD-23.1 NDIS Test Tool

23.2.10 The Network Adapter must have the ability to Standby and restore (2m_Standby)

This verifies the ability to Standby and restore. It also makes sure that communication with the network (that is, with the test server) still works after restoring from standby.

Reference Document: WLP# - B2.3.1.4
Test Description: TD-23.1 NDIS Test Tool


LAN Test Assertions

This section contains the local area network (LAN) assertions for the TD-23.1 NDIS Test Tool.

23.3.1 The Network Adapter must have the ability to query the 64 bit OIDs. (1c_64BitOIDs)

This tests OID_GEN_XMIT_OK and OID_GEN_RCV_OK. It does not attempt to verify the values themselves. It only checks that the queries are properly handled. If the driver does not support 64-bit queries, it is warned unless it a gig adapter. Gig adapters are required to support 64 bit queries. The OID is queried three times -

1: With a null buffer: It should return 0 bytes written, 8 bytes needed.

2: With a 4 byte buffer: It should return 4 bytes written, 8 bytes needed.

3: With an 8 byte buffer: It should return 8 bytes written, 8 bytes needed.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.2 The Network Adapter must have the ability to cancel send packets (1c_CancelSend)

This is REQUIRED for certification of NDIS 5.1 miniports. This runs the performance command with a flag set that causes the ndistest.sys driver to cancel packets when enough been queued up.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.3 The Network Adapter must have the ability to handle failed NDIS calls. (1c_CancelTimer)

This is the same as 1c_faulthandler but it has an additional test for NdisMCancelTimer failure. This is not currently required for WQHL. It will be in the future. This verifies the driver’s ability to properly handle failures in the following NDIS calls.

NdisMAllocateMapRegisters

NdisMRegisterInterrupt

NdisMAllocateSharedMemory

NdisMRegisterIoPortRange

PCI & PCMCIA read config space

PCI & PCMCIA write config space

The driver should not crash.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.4 The Network Adapter must have the ability to handle failed NDIS calls. (1c_FaultHandling)

This verifies the drivers ability to properly handle failures in the following NDIS calls.

NdisMAllocateMapRegisters

NdisMRegisterInterrupt

NdisMAllocateSharedMemory

NdisMRegisterIoPortRange

PCI & PCMCIA read config space

PCI & PCMCIA write config space

The driver should not crash.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.5 The Network Adapter must have the ability to query the GUIDs using WMI (1c_GUIDwithWMI)

This tests the querying of driver information using WMI. This test only has meaning for Windows 98 and Windows NT 5.0. In general, this script is testing ndis.sys and WMI rather than the driver. If the driver exports any private GUIDs to WMI, then look at the last few variations to make sure the driver is handling these correctly. The test uses a QueryGlobalStatistics call with OID_GEN_SUPPORTED_GUIDS to get the list of private GUIDs exported by the driver. It then attempts to query these GUIDs using WMI. The NDIS test is not able to verify the values returned by most of these GUIDs. You should check this log carefully for problems.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.6 The Network Adapter must have the ability to query the information OIDs (1c_InfoOIDs)

Only the required 802_11 OIDs are going to be queried for and checked. This performs a series of NdisRequest calls to the driver, to verify that it supports the querying of all required information OIDs The Ndis Tester is not able to verify the values returned by most of these OIDs. You should check this log carefully for problems.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.7 The NIC init time must not be too long (1c_InitTime)

This verifies that the initialization time for a network card is not too long. It first tests the cable-disconnected case and then the cable-connected case.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.8 If supported, the Network Adapter (NIC) must have the ability to perform IPSec Security Associations (SA) offload. (1c_OffloadIPSecConfig)

This verifies the availability of network adapters, configuration, and services required for the IP Security protocol SA offload tests.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.9 The Network Adapter must have the ability of miniport to detect invalid task offload information. (1c_offloadneg)

This verifies the ability of the NIC miniport to detect invalid task offload information passed down from the protocols.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.10 The Network Adapter must have the ability to be repeatedly opened and closed. (1c_OpenClose)

This verifies the ability to open and close an adapter multiple times. Actually, miniport drivers are opened once (by ndis.sys), so this script really is testing NDIS, not the driver.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.11 The Network Adapter must have the ability to reset the card without damaging queues, etc. (1c_Reset)

This attempts to reset the card multiple times, while at the same time sending lots of packets over that card. It tests to make sure that that card can reset itself and that it deals properly with packets that have been given to it to send when interrupted by a reset.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.12 The Network Adapter must have the ability to send packets. (1c_Send)

This tests the ability to send data, both singly and in bursts. It tries sending to all the various address types supported by the media type of the current driver. As far as it is concerned, no one is listening to the data being sent.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.13 The Network Adapter must have the ability to send various packet types, and to receive them only when the filter is set properly. (1c_SendRecv)

This tests for the ability to receive loopback packets with a variety of address types on a variety of filter settings. It uses one open instance to send and eight to receive. Each of the eight has a different filter setting. This way all supported filter settings can be tested quickly, with the bonus that we are also testing to make sure that there is no "crosstalk" -- that is, that an open instance receives a packet that it should not. It tests the sending of packets with both send and send packets.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.14 The Network Adapter must have the ability to resend and appropriately receive particular types of packets. (1c_SendRecvResend)

If errors are seen, you may be able to isolate them by running the 1c_srrxx scripts

This tests for the ability to receive loopback packets with a variety of address types on a variety of filter settings. It uses one open instance to send and one instance to receive and resend the packet. When the packet send contains a resend address, and the receiver on receiving the packet would resend the packet to that address. The test tries various combinations of send/resend address and receive filters on both the sender and the receiver.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.15 The Network Adapter must have the ability to set and read the functional address for token ring cards. (1c_SetFunctional)

This tests the ability of token ring drivers to set the current functional address on multiple open instances. It also verifies that a query of the driver returns the correct functional address for that open instance.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.16 The Network Adapter must have the ability to set the group address. (1c_SetGroup)

This verifies the ability to set the group addresses from two different open instances. This tests the ability of token ring drivers to set or clear the single group address on the card. Note that even newer cards (whose hardware could support multiple group addresses) are required to support just the single group address.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.17 The Network Adapter must have the ability to set the lookahead size. (1c_SetLookahead)

This verifies the ability to set the lookahead size from two different open instances. It verifies that the lookahead length on your card can be set to everything up to -- but NOT exceeding -- the value returned from OID_GEN_MAXIMUM_LOOKAHEAD. Note that this script is not verifying that the card is actually using this value correctly.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.18 The Network Adapter must have the ability to set multicast address. (1c_SetMulticast)

This verifies the ability to set the multicast address for multiple open instances. It tests the ability of Ethernet and FDDI drivers to set up multiple multicast addresses. It does not test to see that the card is actually able to receive on all these different addresses (that comes later). It just verifies that multicast addresses can be set (and deleted), and that a query will return the correct list.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.19 The Network Adapter must have the ability to query the statistics OIDs. (1c_StatOIDs)

Only the required 802_11 OIDs are going to be queried for and checked. Actual querying for optional OIDs is not currently performed. It gets the list of OIDs supported for QueryGlobalStatistics, and proceeds to query all of them. It then proceeds to do a QueryAllGlobalStatistics The Ndis Tester is not able to verify the values returned by most of these OIDs. You should check this log carefully for problems.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.20 The Network Adapter must have the ability to perform the one card loopback stress test. (1c_Stress)

This does loopback stress. It is normally only done for drivers that support their own loopback and for full MAC drivers.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.21 The Network Adapter must have the ability to change Ethernet address. (2c_AddressChange)

This verifies the ability to change the Ethernet address by changing the parameter in the registry. It tests the ability of NDIS and the driver to override the adapter's current MAC address by writing a new address into the driver's registry with registry value NetworkAddress. The driver should receive the new address when it calls NdisReadNetworkAddress during initialization.

Sequence of events

  1. Read current NetworkAddress parameter in registry so it can be restored at the end.
  2. Query the card to find it's current and permanent Ethernet address.
  3. Stop the driver.
  4. Write the new Ethernet address into registry.
  5. Start the driver.
  6. Query the card to find it's current and compare to expected setting.
  7. Query the card to find it's permanent address and make sure it hasn't changed.
  8. Have the server send 100 packets to the new current address.
  9. Have the server send 100 packets to the original current address (expecting 0 pkts received).
  10. Stop the driver.
  11. Put the original NetworkAddress into the registry.
  12. Start the driver.
  13. Query the card to find it's current and permanent Ethernet address and make sure they are the same as at the start.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.22 The Network Adapter must have the ability to be connected. (2c_checkconnection)

This verifies that the two test cards are connected (works only for same machine). For remote machine, would need to change adapterlist to indicate appropriate remote card. Assumes that the test card is at least able to send packets. It returns a 0 if everything is fine, else returns 5.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.23 The Network Adapter must have the ability to withstand deadlocks (2c_Deadlock)

This verifies the ability of NDIS to withstand potential deadlock situations.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.24 The Network Adapter must have the ability to hibernate and restore. (2c_hibernate)

This verifies the ability to hibernate and restore. It also makes sure that communication with the network (that is, with the test server) still works after restoring from hibernation.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.25 The Network Adapter must have the ability to detect load and unload the miniport driver (with and without sends commencing). (2c_LoadUnload)

This verifies the ability to detect load and unload the miniport driver (with and without sends commencing). There are 3 parts to this test:

1: Load/Unload 10 times (verify connectivity/link after each one)

2: Load/Unload 20 times as fast as possible

3: Load/Unload while sending/receiving

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.26 The Network Adapter must have the ability to detect media connects/disconnects. (2c_MediaCheck)

This verifies the ability to detect media connects/disconnects. It verifies the reconnect is detected properly with long (>30 seconds) disconnects and that communication with the server is restored. There are 3 major passes completed in this test:

Pass 0 = short disconnect event

Pass 1 = long disconnect event (>30 seconds)

Pass 2 = disconnect/unload/load/connect

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.27 The Network Adapter must have the ability of the NIC to compute & verify Tcp/Udp/Ip checksum. (2c_OffloadCheckSum)

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.28 The Network Adapter must have the ability of IPSec offload capable NICs to properly perform crypto operations on TCP/UDP/IP packets (2c_OffloadIPSecFunctional)

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.29 The Network Adapter must have the ability of the NIC to segment large TCP/IP packets. (2c_OffloadLargeSend)

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.30 The Network Adapter must have the ability to respond correctly to unusual Task Offload requests. (2c_OffloadTaskMisc)

This verifies the ability of Task Offload capable NICs to respond correctly to some unusual requests.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.31 Measures performance blast throughput (2c_PerformanceBlast)

This does a Performance blast test with directed addresses. This has the test and support cards both sending packets as fast as possible while the other side tries to count them.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.32 Measures performance using directed addresses (2c_PerformanceProfile)

This measures the Performance profile of the card using directed addresses.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.33 802.1p priority Test (2c_Priority)

This will test 802.1p using the following:

- Send mechanism with DIRECTED packets

- SendPacket mechanism with DIRECTED packets

- SendPacket mechanism with BROADCAST packets

- SendPacket mechanism with MULTICAST packets (802.3)

- SendPacket mechanism with FUNCTIONAL packets (802.5)

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.34 The Network Adapter must have the ability to receive with queuing of packets on all receives. (2c_ReceivePackets)

This forces various types of packet queuing on received packets. Only to be used with drivers that support ReceivePackets. It is REQUIRED for drivers that support ReceivePackets. It tests that queuing of packets for later analysis, along with the driver's handling of NdisReturnPackets. The script tests single, double, and triple queuing of the packets. It is only run for drivers that support Ndis4.0 style receive packet indications.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.35 Lookahead bytes must appear in the lookahead buffer. (2c_RecvLookahead)

This verifies that lookahead bytes truly appear in the lookahead buffer.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.36 The Network Adapter must have the ability to receive on multiple multicast Addresses. (2c_RecvMulticast)

This tests that the card can actually receive on as many different multicast addresses as it claims to support. It uses up all available multicast addresses, and then tries to send packets to each of those addresses. It checks to make sure that packets are only received on those multicast addresses that are actually active. This test requires that both Support card and test card be miniports.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.37 The Network Adapter must have the ability to sends IP Packets if UseIPPackets option is set in ndtsession. (2c_SendPackets)

This sends IP Packets if UseIPPackets option is set in ndtsession otherwise it sends normal ndistest packets.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.38 The Network Adapter must have the ability to send various packet types, and to receive them only when the filter is set properly (2c_SendRecv1)

Two Machine Card Send/Receive Tests with only 1 receiver. This tests that the card is able to correctly receive packets with different addressing types that are actually sent across the wire. It uses one open instance to send and one to receive. The sender is the remote card, while the receiver is the test card. This test is to check if the filtering of packets is done by the driver and not by NDIS.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.39 The Network Adapter must have the ability to send various packet types, and to receive them only when the filter is set properly. (2c_SendRecv8)

Two Machine Card Send/Receive Tests with 8 simultaneous receivers. This tests that the card is able to correctly receive packets with different addressing types that are actually sent across the wire. It uses one open instance to send and eight to receive. Each of the eight has a different filter setting. This way all supported filter settings can be tested quickly, with the bonus that we are also testing to make sure that there is no "crosstalk" -- i.e., that an open instance receives a packet that it should not. It tests the sending of packets with both send and sendpackets.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.40 The Network Adapter must have the ability of the queueing of packets on all receives. (2c_SendRecvQueued)

This forces various types of packet queueing on received packets. Only to be used with NDIS 4.0 drivers that support ReceivePackets. It is REQUIRED for drivers that support ReceivePackets.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.41 The Network Adapter must have the ability to perform certain activities simultaneously. (2c_Simultaneous)

This test will start multiple stress tests between the client test and Support adapters. Some of the opens will hold the packets for a short time after receiving them. This is controlled by setting the setreceiveoption of each open. While the stress tests are running another open is used to change the packet filter, add and remove multicast addresses, and add and remove wake patterns.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.42 The Network Adapter must have the ability to standby and restore. (2c_standby)

This verifies the ability to standby and restore. It also makes sure that communication with the network (that is, with the test server) still works after restoring from hibernation.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.43 Two machine, two card stress tests, Client. (2c_StressClient)

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.44 Two machine, two card stress tests, Server. (2c_StressServer)

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.45 The Network Adapter must have the ability to force NdisTransferData to be called on all received packets. (2c_TransferData)

This tests the TransferData function, which may be part of the driver or (for most miniports), part of ndis.sys itself. The receive path is forced to call NdisTransferData, with the starting point for the transfer set a random points within the packet. It is run in both Ndis3.0 and Ndis4.0 receive mode. A modified stress test is run as a part of this script

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.46 The Network Adapter must have the ability to do WOL (wake on LAN) using magic packet. (2m_WOLMagicPacket)

This is required only if the card claims support for certification.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.47 The Network Adapter must have the ability to do WOL using pattern match. (2m_WOLPattern)

This is required only if the card claims support for certification.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool

23.3.48 [NEW v0.3] The NDIS miniport driver must be deserialized. (WHQLConfigCheck)

For Windows .NET Server 2003, Enterprise Edition and Windows .NET Server 2003, Datacenter Edition, the NDIS miniport driver must be deserialized. A deserialized miniport driver can achieve significantly better performance than a serialized miniport driver when running on a multi-processor system.

Reference Document: WLP# - B7.1.4; Windows DDK, "NDIS Miniport Drivers."
Test Description: TD-23.1 NDIS Test Tool

23.3.49 [NEW v0.3] The driver must use scatter/gather DMA and must not use map registers. (WHQLConfigCheck)

For Windows .NET Server 2003, Enterprise Edition and Windows .NET Server 2003, Datacenter Edition, the driver must use scatter/gather DMA, which includes the SCATTER_GATHER_LIST structure and the GetScatterGatherList and PutScatterGatherList routines. Using the scatter /gather routines for DMA operations can improve utilization of system resources by not locking these resources down statically, which would occur if map registers were used.

Reference Document: WLP# - B7.1.4; Windows DDK; See "High Performance Network Adapters and Drivers in Windows" at http://www.microsoft.com/hwdev/tech/network/NetAdapters-Drvs.asp
Test Description: TD-23.1 NDIS Test Tool

23.3.50 [NEW v0.3] The network adapter must be able to address memory above 4 GB and support 64-bit addressing for DMA operations. (WHQLConfigCheck)

All physical memory is treated as general-purpose memory, so no new APIs are needed to access I/O above the 4 GB physical memory address. Also, direct I/O can be done for greater than 4 GB physical addresses (this requires Dual Address Cycle [DAC]-capable or 64-bit PCI devices). Devices and drivers that can perform direct I/O beyond 4 GB are considered Large Memory Enabled (LME).

Hardware devices should be DAC or 64-bit capable with LME drivers; otherwise, the device will function as a "legacy" 32-bit device and will be double-buffered, with lower relative performance.

For Windows .NET Server 2003, Enterprise Edition and Windows .NET Server 2003, Datacenter Edition, the driver must support 64-bit DMA operations. When the miniport driver calls the NdisMInitializeScatterGatherDma function, the Dma64BitAddresses must be set to TRUE.

Reference Document: WLP# - B7.1.4; Windows DDK
Test Description: TD-23.1 NDIS Test Tool

23.3.51 [NEW v0.3] The system must have 6 GB of RAM (minimum). (WHQLConfigCheck)

For Windows .NET Server 2003, Enterprise Edition and Windows .NET Server 2003, Datacenter Edition, this is a requirement for testing Physical Address Extension (PAE) memory support. For information about PAE, please see the "Physical Address Extension (PAE)" topic in the Appendix of the latest Windows DDK.

Reference Document: WLP# - B7.1.4; Windows DDK
Test Description: TD-23.1 NDIS Test Tool

23.3.52 [NEW v0.3] The system must have at least four processors. (WHQLConfigCheck)

For Windows .NET Server 2003, Enterprise Edition and Windows .NET Server 2003, Datacenter Edition, at least four processors are required for testing.

Reference Document: WLP# - B7.1.4
Test Description: TD-23.1 NDIS Test Tool


NDIS (IPSec) Test Assertions

This section contains the detailed list of IP Security SA Offload test assertions. These assertions are tested in TD-23.3 NDIS (IPSec).

23.4.1 If the Network Adapter (NIC) supports IPSec Security Association(SA) offload, the Security Associations must be offloaded into the hardware.

Reference document: WLP# - A6.R.2; Microsoft® Windows Driver Development Kit (DDK), Offloading IP Security Tasks
Test description: TD-23.3 NDIS (IPSec) Test

23.4.2 If supported, IPSec must be transparent to all protocols above IP layer.

The network interface card(s) (NIC) must transparently support different Transport/Application layer protocols even after setting up a security association. This is tested using ping (with different options), tracert, ftp (get/put), xcopy, net view, net use, and ftp (send/receive).

Reference document: WLP# - A6.R.2; RFC 2401, Security Architecture for the Internet Protocol
Test description: TD-23.3 NDIS (IPSec) Test


VPN Compliance Test Assertions

These assertions are tested in TD-23.2 VPN Compliance Test.

23.5.1 Route Inspection Test

This test determines what routes are added and removed during the lifecycle of a VPN connection using the VPN Software (Pre-Connect, Connected, and Disconnected).

Reference document: WLP# - B1.4.3
Test description: TD-23.2 VPN Compliance Test

23.5.2 Interface Inspection Test

This test determines what network interfaces are added and removed during the lifecycle of a VPN connection using the VPN Software (Pre-Connect, Connected, and Disconnected).

Reference document: WLP# - B1.4.3
Test description: TD-23.2 VPN Compliance Test

23.5.3 Port Inspection Test (TCP)

This test determines changes to TCP ports during the lifecycle of a VPN connection using the VPN Software (Pre-Connect, Connected, and Disconnected).

Reference document: WLP# - B1.4.3
Test description: TD-23.2 VPN Compliance Test

23.5.4 Port Inspection Test (UDP)

This test determines changes to UDP ports during the lifecycle of a VPN connection using the VPN Software (Pre-Connect, Connected, and Disconnected).

Reference document: WLP# - B1.4.3
Test description: TD-23.2 VPN Compliance Test

23.5.5 WAN Device Inspection Test

This test enumerates the wide area network (WAN) devices that Windows XP reports as being present when the VPN Software is installed.

Reference document: WLP# - B1.4.3
Test description: TD-23.2 VPN Compliance Test

23.5.6 WAN Connection Inspection Test

This test enumerates the wide area network (WAN) connections that Windows XP reports as being present when the VPN Software is installed and connected.

Reference document: WLP# - B1.4.3
Test description: TD-23.2 VPN Compliance Test

23.5.7 Simple TCP Test

This test evaluates the reliability of the network layer that is provided by the VPN Software.

Reference document: WLP# - B1.4.3
Test description: TD-23.2 VPN Compliance Test

23.5.8 Multi-threaded, multi-socket TCP Test

This test evaluates the reliability of the network layer that is provided by the VPN Software when under stress.

Reference document: WLP# - B1.4.3
Test description: TD-23.2 VPN Compliance Test

23.5.9 Large Data Transfer Test

This test evaluates the reliability of the network layer that is provided by the VPN Software when for large data transfers (1 GB or larger).

Reference document: WLP# - B1.4.3
Test description: TD-23.2 VPN Compliance Test


DCDP 14-Day Stress (Network) Test Assertions

This is preliminary documentation and subject to change.

23.6.1 [NEW v0.3] The network device and driver must run under test for 14 days without failure.

Reference documents: WLP# - B7.1.4; See the "The Datacenter Driver Program" white paper at http://www.microsoft.com/hwdev/platform/server/datacenter/default.asp
Test descriptions: TD-23.4 DCDP 14 Day Stress (Network) Test


TD-23.1 NDIS Test

Test Kit: HCT 11, HCT 10

The Network Driver Interface Specification (NDIS) test checks the interface for network drivers used in Windows operating systems.

Overview of the NDIS Tests

Click to show or hide information. ATM Functional Scripts

The ATM scripts are used for testing ATM and ADSL drivers. The comments below look at these scripts in the approximate order in which they are called. Note that reset-related problems (which can potentially occur at any time) are discussed under 1c_reset.tst. General send failures and receive failures are discussed under 1c_sends.tst. Call related problems are discussed under 1c_mkcal.tst. A handy tool to use in addition to the NDIS tester is atmadm. This utility can help you diagnose problems related to making calls. It gives you statistics from the call manager.

Click to show or hide information. IrDA Functional Scripts

The IrDA scripts are used for testing IrDA drivers.

Click to show or hide information. LAN Functional Scripts

The Local area network (LAN) scripts are used for testing Ethernet, Token Ring, and FDDI drivers. They are also used for testing intermediate miniports such as AtmLane.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-23.2 VPN Compliance Test

Test Kit: HCT 11

This test evaluates and verifies the compatibility of independently developed virtual private network (VPN) products.

Overview

The VPN Compliance test requires a minimum of three computers. The first computer must be capable of running Windows XP and the test VPN software. For the purposes of this test, this computer is known as the Test VPN Client. The second computer serves as a VPN gateway, and must be compatible with the test VPN software. The second computer is known as the VPN Gateway. The third computer must be capable of running Windows XP. This third computer is known as the Conformance Test Server.

The Test VPN Client must be located on an IP network that is logically separate and distinct from the Conformance Test Server. The Conformance Test Server must be accessible by the Test VPN Client only through the VPN Gateway and only when the Test VPN Client is connected to the VPN Gateway using the test VPN software.

Figure 1. VPN Compliance Test Setup

Conformance Test Server

The Conformance Test Server must be on an isolated logical IP network segment and must be accessible by the Test VPN Client only when the Test VPN Client is connected to the VPN Gateway.

VPN Gateway

The VPN Gateway is a computer or other device that is capable of terminating calls from the Test VPN Client. Any VPN Gateway is acceptable for purposes of this test provided it is capable of forwarding an IP datagram to and from the remote network and the Test VPN Client. The gateway must facilitate distinct and separate logical IP networks. As shown in Figure 1, the networks, labeled IP Network Cloud and Remote IP Network Cloud, must be distinct and separate.

Configuration of the VPN Gateway is implementation-specific. Please refer to the documentation that accompanied your VPN Gateway or contact the gateway manufacturer for configuration details.

Before beginning the test, you should verify that the connection to the VPN Gateway from the Test VPN Client is properly configured and that the Test VPN Client can ping the Conformance Test Server.

Test VPN Client

On the VPN Test Client, you must install the VPN software and perform the vendor-specific configuration to enable the client to successfully connect to the VPN Gateway and to ping the VPN Conformance Server. When installation is complete and connectivity to the VPN Gateway has been verified, disconnect the VPN Client from the VPN Gateway (if connected) and begin the test.

Important When you start the VPN Compliance test on the Test VPN Client, the VPN Client cannot be connected to the VPN Gateway by the VPN software.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test requires Windows XP Professional; Windows .NET Server 2003, Standard Edition; or Windows .NET Server 2003, Enterprise Edition, and the test VPN software.

Results Interpretation

The test writes the pass/fail results to a log file VPNCOMP_NTLOG.txt. Test activity is also recorded in the file VPNCOMP.txt.


TD-23.3 NDIS (IPSec) Test

Test Kit: HCT 11

Overview

This test verifies that the Security Associations (SA), designed to protect IP Security (IPSec) communications, are offloaded into the hardware. The hardware, a network interface card (NIC), maintains the SA tables to improve performance when processing encrypted send packets. The test verifies that the NIC transparently supports different transport/application layer protocols after setting up the SA tables.

Definitions

Encapsulating Security Payload (ESP)

The ESP is the protocol header inserted into an IP datagram to provide confidentiality, data origin authentication, anti-replay, and data integrity services to IP. It is defined in RFC 2406.

Authentication Header (AH)

The AH is an IPSec protocol used to provide data integrity, data origin authentication, and optional limited anti-replay services to IP. It is defined in RFC 2402.

Transport Mode

In transport mode, AH and ESP intercept the packets flowing from the transport layer into the network layer and provide the configured security.

Tunnel Mode

This mode is used when the IP security is provided by a device that did not originate the packets, as in the case of VPNs, or when the packet needs to be secured to a destination that is different from the actual destination.

Test Methodology

After setting up the machines in different modes (Transport/Tunnel) and different combinations of cryptographic settings, the test tries to verify two basic functionalities:

  • Protocol Transparency
  • Security Association Offload

Protocol Transparency

The Protocol Transparency Test suite has the following components:

  • Checking if the SA is setup.
  • Ping Test.
  • Large Ping Test
  • Timestamp Ping Test
  • Tracert Test
  • FTP put Test
  • FTP get Test
  • XCopy Test
  • File Compare Test
  • Net View Test
  • Net Use Test
  • TFTP send Test
  • TFTP receive Test

This test generates network traffic between the client and server machines.

Security Association Offload

After making sure that a Security Association is set up, the Security Association Offload Test verifies if the Security Association was actually offloaded to the hardware.

Test Scenarios

The protocol transparency and SA offload functions are tested on four different scenarios

  • Transport Mode – The Client and Server set up an SA in Transport mode.
  • Router-to-Router Tunnel Mode – Router1 and Router2 set up an SA in Tunnel mode.
  • End-to-End Tunnel Mode – Client and Server set up an SA in Tunnel mode.
  • Transport through Tunnel Mode – Client and Server make a Transport mode SA and Router1-Router2 make a Tunnel mode SA.

All these scenarios are tested for all the possible combinations of AH, ESP and combined AH ESP.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Software

Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; or Windows .NET Server 2003, Enterprise Edition.

Results Interpretation

The results are integrated with the NDIS test. Different HTML files are generated for the four scenarios.

Protocol Transparency Failure

A failure is indicated by any of the following error messages:

  • Ping Failed
  • Large Ping Failed
  • TimeStamp Ping Failed
  • Tracert Failed
  • FTP put Failed
  • FTP get Failed
  • XCopy to Failed
  • XCopy from Failed
  • File Compare Failed
  • Net View Failed
  • Net Use Failed
  • TFTP send Failed
  • TFTP receive Failed

Security Association Offload Failure

A failure is indicated by the following error message:

  • SA Offload Failed

This means that the IPSec driver gets the information that the SA can be offloaded, but the operation fails when the driver tries to do so.


TD-23.4 DCDP 14-Day Stress (Network) Test

This is preliminary documentation and subject to change.

Test Kit: HCT 11

Overview

The Datacenter Driver Program (DCDP) 14-Day Stress (Network) test is an extended version of the Network Driver Interface Specification (NDIS) test for network devices and is designed to test device and driver compliance with the requirements for Datacenter driver qualification. Testing for this qualification is 14 days long and the criterion for passing the test is 100% completion without failure. Devices and drivers that achieve these qualifications have met the highest standards of Microsoft testing.

For more information about the Datacenter Driver Program, see the white paper at http://www.microsoft.com/hwdev/platform/server/datacenter/default.asp

Overview of test steps

The DCDP 14-Day Stress (Network) test is based upon four NDIS test scripts for network devices and includes some additional communication tests. These tests run repeatedly for 14 days. The NDIS test scripts run in one of two modes, silent mode and normal mode. In silent mode, the failures are suppressed. In normal mode, failures are recorded.

Click to show or hide information. Communication test

The communication test verifies basic send-and-receive capabilities. The test sends 100 packets from the test adapter (on the test system) to the support adapter (on the support system); the packets are sent slowly. The support adapter receives the packets and echoes them back. In normal operation, none of these packets are dropped. However, to account for variations in real-world activities, the test allows for 150 send and 150 receive operations to fail in a single day. More losses cause a test failure.

Click to show or hide information. Load/Unload test

This test is run once at the beginning of the first day of the test and again at the end of the last day. This test loads and unloads the miniport driver multiple times and then verifies connectivity. (2c_LoadUnload)

Click to show or hide information. Daily test sequence

Every 24 hours, the test repeats the following sequence:

  • If the device supports offloading TCP/IP checksum tasks, the test verifies that the task offload and the checksums are performed correctly. (2c_OffloadChecksum)
  • If the device supports offloading the segmentation of large TCP/IP packets, the test verifies that the device can perform the Large Send Offload (LSO). (2c_OffloadLargeSend)
  • The test places the device under stress and then verifies that the device can handle simultaneous activities. (2c_Simultaneous)

The test then performs the following loop for the rest of the day:

  • Runs the Offload Checksum test in silent mode, if the device supports TCP/IP offload checksum. (2c_OffloadChecksum)
  • Runs the communication test.
  • Runs the Large Send Offload test in silent mode, if the device supports TCP/IP offload large send. (2c_OffloadLargeSend)
  • Runs the communication test.
  • Runs the simultaneous test in silent mode. (2c_Simultaneous)

Click to show or hide information. Test wrap up

After 14 days, the test runs the Offload Checksum test, Large Send Offload test, and Simultaneous test one last time to make sure that the device did not start failing on the last day. Finally, the Load/ Unload test runs in normal mode to wrap up the test.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The following software is required (at a minimum):

  • Windows .NET Server 2003, Enterprise Edition

Results Interpretation

The test generates a detailed log file of test results and displays on-screen pass or fail status. The name of the log file is NDIStest.log. To pass the test, the test must run to completion without failure. For information about the specific tests, you can use Test Manager to check the individual test logs. The main test results appear in the log file 2c_14DayTest.htm. You can use this file to view the results of the tests described here.

Click to show or hide information. Debugging a test failure

There are several conditions that can cause the DCDP 14-Day Stress test to fail. When the test fails, the system can become unresponsive, or a bug check can occur. However, if you have a kernel debugger attached to the server, it is possible to debug or obtain more information about the failure. For information about debugging NDIS drivers and NDIS debugger extensions, please refer to the latest Windows DDK.

For information about using a kernel debugger, see the Debugging Tools for Windows package. This package includes the Microsoft Windows Debugger (WinDbg), which can be used for user-mode and kernel-mode debugging. This package also includes detailed documentation that describes setting up and using a kernel debugger.

You can install the Debugging Tools for Windows from the Customer Support Diagnostics CD, the Platform SDK, the Windows DDK, or from the Web at http://www.microsoft.com/ddk/debugging.


Chapter 24: Cluster Test Specification

Overview

This document describes the test specification for service validation of a server cluster configuration. Note: Server cluster was previously named Microsoft Cluster Server (Server Cluster).

Test Configuration

Creating a server cluster requires PCI, PCI-X-based Intel Pentium or equivalent "x86" or "IA64" systems connected to a shared storage bus and configured as described in the following list. For development purposes, any PCI-based system listed on the HCL can be used as a server cluster node. The shared storage system can be based on Fibre Channel or SCSI. Only 2-node server clusters running 32-bit Enterprise Server are supported on SCSI storage. Fibre Channel storage is supported on all cluster configurations.

Fibre Channel-based solutions must meet the following conditions:

  • At least one storage subsystem is interconnected to the server nodes with Host Bus Adapters. The server nodes may connect directly to the storage or may use one or more Fibre Channel switch or Hub. Note: Hubs and switches cannot be used together on the same Fibre Channel bus. The use of hubs is not supported for clusters with more than two nodes.
  • The Fibre Channel storage subsystem must have at least N non-quorum hard disk drives, where N is equal to the number of nodes of the system being certified. At a minimum, there will be N Logical Unit Numbers (LUNs) to form partitions for testing. Each partition must have two GB (2 x 230 Bytes) of free space after installation of the Microsoft Cluster Service (MSCS) System, and must be formatted for the Basic Windows NT file system (NTFS) only.
  • The Fibre Channel storage device allows multi-port devices.
  • Loop initialization primitive (LIP) reset must be disabled on the host bus adapter (HBA).
  • At least one disk on each node is not attached to any of the shared buses.
  • The Windows operating system is installed entirely on the non-shared disk(s) of each system. All paging files and system files must be on non-shared disks.
  • At least one shared LAN is for intra-cluster communication. A single network adapter in each system must be attached to this LAN and configured with the TCP/IP protocol. Each adapter must be assigned an address on the same IP subnet. The intra-cluster network must use PCI network interface cards (NICs).
  • At least one shared LAN is configured for client access to the cluster. A single network adapter in each system must be attached to this LAN and configured with the TCP/IP protocol. Each adapter must be assigned an address on the same IP subnet. Clients can be connected to this LAN by a routed IP network. The same LAN (and IP subnet) can be used for both intra-cluster communication and client access.
  • One static TCP/IP address is provided for the cluster and one is provided for each resource group that is created. Clients that access cluster services use these resource group addresses.

SCSI-based solutions must meet the following conditions:

  • At least one shared SCSI bus formed by a PCI-based SCSI controller is installed in each system.
  • The SCSI IDs of the two controllers on a shared bus must be different. By default, SCSI controllers are assigned ID 7. One ID must be changed to another value (for example, 6) before they can both be connected to the same bus.
  • The boot-time SCSI bus reset operation should be disabled on both controllers attached to a shared bus. This option can be disabled using the configuration utilities supplied by the manufacturer. However, some SCSI cards may not support this feature. Disabling this feature will make systems boot faster, but will not prevent the tests from running.
  • The SCSI external shared storage bus must have at least N non-quorum hard disk drives, where N is equal to the number of nodes of the system being certified. At a minimum, there will be N Logical Unit Numbers (LUNs) to form partitions for testing. Each partition must have two GB (2 x 230 Bytes) of free space after installation of the Microsoft Cluster Service (MSCS) System, and must be formatted for the Basic Windows NT file system (NTFS) only.
  • At least one disk on each node is not attached to any of the shared buses.
  • The Windows operating system is installed entirely on the non-shared disk(s) of each system. All paging files and system files must be on non-shared disks.
  • At least one shared LAN is for intra-cluster communication. A single network adapter in each system must be attached to this LAN and configured with the TCP/IP protocol. Each adapter must be assigned an address on the same IP subnet. The intra-cluster network must use PCI NICs.
  • At least one shared LAN is configured for client access to the cluster. A single network adapter in each system must be attached to this LAN and configured with the TCP/IP protocol. Each adapter must be assigned an address on the same IP subnet. Clients can be connected to this LAN by a routed IP network. The same LAN (and IP subnet) can be used for both intra-cluster communication and client access.
  • One static TCP/IP address is provided for the cluster and one is provided for each resource group that is created. Clients that access cluster services use these resource group addresses.

Figure 1a illustrates a typical Server Cluster SCSI configuration. Figure 1b illustrates a typical Server Cluster Fibre Channel configuration.

Figure 1a. Standard Server Cluster configuration using SCSI (or SSA) adapters

Figure 1b. Standard Server Cluster configuration using Fibre Channel adapters


Installing OS Components for Tests in Validation Kit

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

To run the tests in the Validation testing, install the dependent services on all the cluster nodes. The following components are needed:

Click to show or hide information. Installing test components for WINS

On each Windows .NET Server 2003, Enterprise Edition or Windows .NET Server 2003, Datacenter Edition node, go to: Start -> Settings -> Control Panel, and then double-click Add/Remove Programs.

Click the Add/Remove Windows Components button. Under the Windows Components Wizard scroll down to the Network Services list item.

Highlight the item and click the Details button. Select the list item check box for Windows Internet Name Service (WINS). Click OK.

Follow the directions for the rest of the prompts. You will need to assign a static IP address to each of the network interface cards on the cluster nodes for WINS to work correctly.


Specific installation details

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The Domain Controller

This is the first installation that must be completed. The domain controller (DC) must be:

  • In the same domain as the test cluster and test client machines.
  • In the same Active Directory site as the test cluster and clients.
  • Configured to contain a copy of the global catalog.

The Cluster

The Cluster service should be configured next.

Installing test components for Autosniff

Before running autosniff, network monitoring must be enabled on the client master. To install network monitoring:

  1. From the task bar select Start -> Settings -> Control Panel.
  2. Double-click Add/Remove Programs.
  3. Click the Add/Remove Windows Components button.
  4. Under the Windows Components Wizard highlight the Management and Monitoring Tools list item and click Details.
  5. Select the list item check box for Network Monitor Tools.
  6. Click OK.


Server Cluster Configuration

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The following lists constitute the Server Cluster configuration that is required for server cluster validation.

Click to show or hide information. Hardware Requirements for a Server Cluster System

  • 256-MB minimum system memory
  • Hard disk drive(s) used to boot each node of the cluster (can be IDE, SCSI, or RAID controller). These drives must not be connected to the shared storage bus for the server cluster.
  • PCI SCSI, Fibre Channel, or RAID controllers must be installed on each node of the cluster, and connected to drives used for the shared storage bus (different from the drives used for the internal boot drive on each cluster node)
  • Two network cards for each node of the cluster: used for intra-cluster and client communications. (At a minimum, you should be able to configure two different Ethernet ports for two separate LANs on each node of the cluster)

Only PCI network adapters and storage devices should be used in a server cluster.

In addition to the minimum system requirements for a cluster, Microsoft requires the following for system validation:

  • At least N+1 shared logical unit numbers (LUNs) on the storage bus (SCSI, Fibre Channel, etc.) for every node of the cluster, where N is equal to the number of nodes of the system being certified. This means that a 4-node cluster would have at least 5 LUNs, an 8-node cluster would have 9 LUNs, etc. LUNs are logical drives that are seen at the Windows 2000 SCSI class driver and can represent many physical drives in some RAID implementations. These LUNs should have at least two GB (2 x 230 bytes) of free space. Microsoft recommends that the number of disks on the shared bus represent a typical customer configuration.
  • At least eight client machines + one client master machine that can connect to the cluster using a TCP/IP network. Client requirements are detailed below in the section titled "Client Requirements for a Server Cluster System".
  • At least one static IP address must be assigned to each disk on the shared bus. One of these static IP addresses will be used to setup the cluster virtual server. The remaining static IPs will be used to setup additional virtual servers for testing. The client-server tests will stress each of these virtual roots. These static IP addresses must be on the same subnet mask as the server cluster nodes and the client machines.
  • Minimum of at least one GB free hard disk space on the system drive of each cluster node after OS installation.

It is highly recommended that all disks should be formatted as Basic NTFS. The shared bus disks intended for clustering must be formatted as Basic NTFS.

Click to show or hide information. Supported Cluster Topologies—Single Site Cluster

The following table shows the supported cluster topologies for cluster servers that operate at a single site.

Operating System | Number of Nodes | Storage Interconnect
Windows .NET Server 2003, Enterprise Edition (32-bit version) | 2 nodes | SCSI or Fibre Channel
Windows .NET Server 2003, Enterprise Edition (32-bit version) | 2–8 nodes | Fibre Channel
Windows .NET Server 2003, Datacenter Edition (32-bit version) | 2–8 nodes | Fibre Channel
Windows .NET Server 2003, Datacenter Edition (64-bit version) | 2–8 nodes | Fibre Channel
Windows .NET Server 2003, Datacenter Edition (64-bit version) | 2–8 nodes | Fibre Channel

Note: Hubs are not supported in cluster configurations that have more than 2 nodes.

Click to show or hide information. Network requirements for running tests

The tests will generate a lot of network traffic between client machines and cluster nodes. The following are Microsoft requirements and recommendations for the cluster networks:

  • Microsoft recommends that all of the client machines and cluster nodes be on a dedicated network. The cluster nodes will experience very high stress loads with file I/O, IIS queries, and FTP queries. This is by design and is done to simulate the real-world customer usage of high-end cluster configurations. The network stress loads, however, are probably higher than what any customer would utilize under normal circumstances. It is therefore recommended that all testing be done on a dedicated network.
  • The cluster nodes may be setup as domain controllers. However, the best results for this heavy level of stress testing are obtained when there is another server that is always up providing domain services. This testing can and does reboot cluster nodes.
  • The client machines, client master machine, and the cluster nodes must all be a member of this same domain. This account has local administrator rights on each machine. Use this same account for the cluster service, as it requires local administrator privileges to administer the cluster.

Click to show or hide information. Client Requirements for a Server Cluster System

The client machines will be used to simulate client-server stress against the cluster. The eight required client machines cannot be used to test more than one cluster at a time. The idea of having eight dedicated clients is that Microsoft can run many tests on each node, simulating many real-world clients. For each cluster you want to test in parallel, you must have a different set of client machines. These clients must meet the following hardware and software requirements:

  • If Server Cluster validation is being done with Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition; or Windows .NET Server 2003, Datacenter Edition, each client must be on the HCL and running Windows XP Professional.
  • Each client should have at least 128 MB of memory 256MB is preferred.
  • Each client should have a minimum of one GB of free hard drive space after OS installation.
  • Each client should be at least a Pentium III (500 MHz) or newer machine. Microsoft recommends a client mix as close to your typical customers’ use as possible.
  • Each client must have an HCL validated network card installed.
  • Each client must be able to communicate with the cluster over TCP/IP.
  • The clients must be in the same domain as the cluster nodes.
  • The clients must be all on the same subnet as the cluster nodes.

An additional client will also be needed as the client monitoring system (also called the "client master" or "client monitor" below.) This client should be separate from the clients used for client-server stress testing. It has the same hardware requirements as the other client machines except:

  • The client master should be running Windows .NET Server 2003, Standard Edition
  • This machine should have at least 256 MB of memory plus one free serial port for kernel debug connection.
  • The client master must also be able to communicate through TCP/IP with all of the tests systems and it should be able to handle at minimum 100 concurrent network sessions. This includes the eight clients as well as the cluster nodes.
  • A large number of logs may be copied at the end of the test run from all clients. As a result, it is advised that this system have enough disk space (approximately three GB.)

The client master is used to:

  • Run the Server Cluster Administrator tool to monitor the status of the cluster.
  • Provide a share point to start up the client tests on the other clients.
  • Execute automated failover testing.
  • Serve as the kernel debugger for each server node. Please see documentation in the Windows Device Driver Kit (DDK) for setting up a kernel debugger.

Click to show or hide information. Server Cluster Configuration Components

A Server Cluster hardware configuration consists of three main components.

  • Two or more servers.
  • A shared bus storage configuration using fibre or multi-initiator SCSI.
  • Two network interface cards in each server, one used as the "interconnect" for intra-cluster communications.

All three components must be on the appropriate Microsoft HCL. Microsoft views Server Cluster requirements as a superset of standard server HCL requirements. However, the standard HCL is a starting point for Server Cluster configurations. Server Cluster validation is designed primarily to ensure that a given hardware cluster configuration will work with Server Cluster. The HCT kit is used to ensure proper functionality of hardware with stand alone Windows NT Server, Windows 2000 Server, Advanced Server, and Datacenter Server, or Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition; and Windows .NET Server 2003, Datacenter Edition.

The Cluster configurations listed on the HCL will be a complete configuration as described in the previous section. However, a particular configuration is not a validated Server Cluster configuration until it has successfully gone through the cluster system validation process, which is described in the rest of this document.

One goal of each configuration should be to eliminate any Single Point of Failure (SPOF). This can include power failures, SCSI cables coming loose, disk cabinets failing, etc. Because a Server Cluster is intended to serve as the foundation for highly available systems, it is recommended (though not required) that configurations minimize or eliminate SPOF hardware configurations.

Click to show or hide information. Servers in a Server Cluster Configuration

The server requirements for a server cluster are fairly minimal. Microsoft requires the server to have PCI slots because all the shared SCSI adapters that Microsoft has tested are PCI-based controllers. Server Cluster is designed to work in any x86 (Pentium-class or better) and IA64 servers on the HCL list, including uniprocessor and multiprocessor machines. All servers must go through normal HCL testing before any Server Cluster configuration testing and must be on the appropriate HCL list.

Click to show or hide information. Shared Storage Bus in a Server Cluster Configuration

The shared SCSI or Fibre Channel bus is probably the most sensitive part of a Server Cluster configuration. There are multiple components that potentially make up the shared bus, although not all are required for any given configuration. Please keep in mind this list may not be complete, but is intended as a general guide to current components. These components are:

  • Fibre Channel Adapter or SCSI Adapter
  • RAID Controller (SCSI or Fibre Channel, and may or may not be part of the Storage Array)
  • Storage Array (SCSI or Fibre Channel)
  • Fibre Channel HUB or Switch

All of these components must be on their respective HCL, as either cluster device qualified or cluster storage block qualified components, before any server cluster testing will be done. Any of these components that are already on the HCL can be submitted to Microsoft for cluster candidate component testing. If the component is not on the HCL, or the device is not on the cluster component list, then both normal HCL testing and cluster candidate component testing can be done with the same submission. They will be tested in a variety of configurations to help ensure that any independent hardware vendor will be able to use them in a server cluster configuration.

Figure 2. Server Cluster component and system validation process

Click to show or hide information. Interconnect Cards in a Server Cluster Configuration

Interconnect cards are what a Server Cluster uses to communicate between the nodes of a cluster. This Ethernet network needs to be high-speed and highly reliable. The most important aspects of this are the speed at which packets can be sent over the network, the number of dropped packets, and the reliability.

Note: Interconnect cards must pass normal validation for Network Interface Cards (NICs).

NIC Teaming is not supported on Windows NT 4.0, Windows 2000, or Windows .NET Server 2003 family platforms.

Click to show or hide information. How to configure private cluster networks (or cluster intra-communication networks)

This is one of the ways you can configure the private network.

  • Connect all machines on the private network to a hub.
  • Assign the static IP Address of 10.1.0.1 with a subnet mask of 255.255.0.0 for the cluster node 1.
  • For node 2, assign 10.1.0.2 with subnet mask of 255.255.0.0, and so on. To set the IP Address, go to Start Menu->Settings->Network and Dial-up Connections. Right click the private connection, and select Properties. Select the properties for Internet Protocol (TCP/IP). Choose "Use the following IP Address" and specify the above-mentioned IP addresses.

Alternatively, you could set up a Windows 2000 domain controller (DC) with a DHCP Scope of 10.1.0.2 through 10.1.0.20, subnet mask of 255.255.0.0, and have a NIC on the DC with a statically-assigned address in the 10.x.x.x range. Obviously, DHCP would hand out leases with IP addresses similar to the scenario above. This also means the Domain Controller will need to have a private NIC.

Click to show or hide information. Setting the cluster network priorities

An important configuration required on the cluster side, is to set the priorities on the usage of networks for internal cluster communications. Make sure that the private network has priority over the public. Since the test kit will be running tests on the clients against the public network, it is a requirement that the internal cluster communication be done over a separate network (private).

To do that, right click on the cluster name in Cluster Administrator. Click Properties, and then go to Network Priority. Make sure your private network is the first on top of the list.

Click to show or hide information. Renaming Cluster Resources

The Cluster kit prefixes the resource it creates with "HCT-". If you decide to rename any of the cluster resource before starting the test, make sure you don’t start with "HCT-".

Click to show or hide information. Server Clusters and Storage Blocks

In Windows .NET Server 2003, Enterprise Edition and Windows .NET Server 2003, Datacenter Edition, server clusters may contain up to eight nodes. To help manage the number of permutations and combinations under test, Microsoft defines the concept of "blocks," introducing the notion of a "Cluster Server Block" and a "Cluster Storage Block." A valid cluster configuration is the combination of a Cluster Server Block with a compatible Cluster Storage Block. Microsoft will support any combination of Cluster Server Block and Cluster Storage Block if they have already been through the "Designed for Windows" logo program.

A Cluster Server Block is defined as a server with a specific Host Bus Adapter (HBA) for connection to the storage component.

A Cluster Storage Block is a storage solution, including a switch or hub with a specific Host Bus Adapter (HBA).

Cluster solutions are tested with the Windows .NET Server 2003 Cluster HCT as in previous releases.

Combining a WHQL Cluster Server Block with a compatible Cluster Storage Block (leveraging and building on previous test results) can create additional cluster solutions.

A Cluster Server Block is compatible with a Cluster Storage Block if the Host Bus Adapters, HBA firmware versions, number of HBAs, and HBA driver versions are all identical, in addition to the type, and firmware version of the HUB or switch.

Example:

  • A vendor can run a Cluster HCT test with server 1 using HBA 1 connected to Storage 1. This testing would result in a Cluster Server Block listing of server 1 with HBA 1, and a Cluster Storage Block listing of HBA 1 with Storage 1.
  • A vendor can then run Cluster HCT test with server 2 using HBA 1 with Storage 2, thus listing a Cluster Server Block of server 2 with HBA 1 and a Cluster Storage Block of HBA 1 with Storage 2.
  • A vendor can now leverage the above test results, combining any combination of Cluster Server and Cluster Storage Blocks (since all blocks share a common HBA) and thus create additional cluster solutions.

In our experience it has been observed that changing the server doesn't affect the working of a cluster. However, a cluster is very sensitive to changes in HBA, Switch, Hub and Storage. Leveraging this experience, you can define a Cluster Server Block so that cluster would not require re-validation with any changes within the Cluster Server Block. The criteria for the Cluster Server Block and Cluster Storage Block are described in the following sections.

Click to show or hide information. Cluster Server Block

If a server in a Cluster Server Block is certified then any server in that block should be considered certified for clustering. The following guidelines apply to all servers in the Cluster Server Block:

  1. Same processor mother board with CPU Speed range delta of less than 500MHZ
  2. Same PCI Bus speed, testing 66 implies 33
  3. Same Bus Width, testing 64 implies 32
  4. Same Vendor, although if the architecture is different enough then the vendor will categorize it as a separate block
  5. HBA including Driver and any Filter Drivers
  6. Same CPU type (i.e., slot1, slot2, socket flip-chip, etc) = same block
  7. Same system board = same block

A certified server of a server block along with a HBA constitutes a Cluster Server Block. Any changes in HBA or Server as defined by the Cluster Server Block requires new validation.

A server block can contain multiple server types of the same vendor, but the HBA, firmware, driver, and any accompanying filter driver, must be the same on all the nodes of the cluster.

Click to show or hide information. Cluster Storage Block

The entire Cluster Storage Block can be validated. The Cluster Storage Block consists of the following components:

  • HBA (H)
  • Interconnect (F)
  • Storage

A Cluster Solution consists of the Server Block and the Storage Block.

Click to show or hide information. Cluster Solution

(Can be validated)

  • Cluster Server Block
  • Cluster Storage Block
  • Microsoft will support any combinations of a Cluster Server Block and a Cluster Storage Block if they have already been validated.

Click to show or hide information. Supported Server

Microsoft supports any server cluster qualified using "supported" server.

Click to show or hide information. Server Cluster with different server types

You can build a server cluster with different types of servers (as long as the servers are from the same vendors) and extrapolate several HCL listings for these servers from a single test. Servers in the server cluster configuration can be different as long as the HBA, driver, firmware, filter driver, switch and shared storage remain the same among these combinations.

For example, a vendor has the following servers, HBA, switch, and storage hardware for cluster qualification:

  • 4 different server types: A, B, C, and D from same vendor
  • 2 different HBAs: HBA-A, HBA-B
  • 1 Switch: SW-1
  • 1 Storage: ST –1

To qualify the hardware, the vendor can run two 4-node tests using the following configurations:

Configuration 1:

ABCD (each containing HBA-A) + HBA-A + SW-1 + ST-1

Configuration 2:

ABCD (each containing HBA-B) + HBA-B + SW-1 + ST–1

The vendor does not need to submit different combinations of the above four servers (ABCD) with HBA-A+SW-1+ST-1 or HBA-B+SW-1+ST-1. Only two submissions are required, one for each HBA + SW + ST.

If the two configurations shown above are qualified, it is assumed that the following configurations are also supported:

AACD + HBA-A + SW-1 + ST-1

ABCC + HBA-B + SW-1 + ST–1

…Etc.

Click to show or hide information. Majority Node Set Server Cluster with Shared Storage

The Microsoft Cluster qualification process is designed to test the interaction between the Windows operating system and the storage subsystem. With Windows .NET Server 2003, Microsoft provides a quorum resource called "Majority Node Set" that removes the need to use a shared storage device as the quorum resource. Microsoft does not require a qualification for a majority node set server cluster. However, if a majority node set server cluster is used with shared storage system, you are required to run the regular cluster HCT kit. For a majority node set type of server cluster that is configured to have shared storage for application data, the same cluster qualification rules apply and the HCT tests must be run. All server clusters that have shared disks (whether the quorum resource is a shared disk or majority node set) must be qualified using the cluster HCT test and must be listed on the HCL to be supported by Microsoft.

A majority node set server cluster will be listed on HCL like any other server cluster. Microsoft does not maintain a specific HCL listing for majority node set server clusters. The server cluster HCT is aware of the majority node set resource and will failover node accordingly.

If you plan to use majority node set for quorum and want to qualify this cluster with shared storage, the server cluster must contain more than 2 nodes. Any test run with a 2-node majority node set cluster with shared storage will not be valid.

Click to show or hide information. Qualification requirements for Server Clusters in a SAN Environment

Microsoft fully supports multiple clusters and/or servers deployed on a single fibre-channel switched fabric and sharing the same storage controllers, as long as the configuration is qualified by following rule:

  • The storage pieces that are qualified for single cluster must also be qualified for Cluster/Multi-Cluster Device test.

Note To obtain the Cluster/Multi-cluster device test, contact WHQL

Example:

Cluster/Multi-cluster device HCL list:

  • Storage Controller St1<HBA H1, Switch S1>
  • Storage Controller St2<HBA H2, Switch S2>

Cluster HCL list:

  • 2-node server cluster AS1
  • Server 1: Server Box S1, 256Mb, 700Mhz PIII, HBA H1
  • Server 2: Server Box S2, 256Mb, 700Mhz PIII, HBA H1
  • Switch: S1
  • Storage: Storage Controller St1
  • 4-node server cluster AS2
  • Server 1: Server Box S5, 512Mb, 1.2Ghz PIV, HBA H1
  • Server 2: Server Box S6, 512Mb, 1.2Ghz PIV, HBA H1
  • Server 3: Server Box S7, 512Mb, 1.2Ghz PIV, HBA H1
  • Server 4: Server Box S8, 512Mb, 1.2Ghz PIV, HBA H1
  • Switch: S1
  • Storage: Storage Controller St1
  • 2-node server cluster AS3
  • Server 1: Server Box S10, 256Mb, 700Mhz PIII, HBA H2
  • Server 2: Server Box S11, 256Mb, 700Mhz PIII, HBA H2
  • Switch: S2
  • Storage: Storage Controller St2

Click to show or hide information. Geographically Dispersed Server Cluster Validation Process

You can use the Windows Clustering technology to implement geographically dispersed server clusters in which the nodes of a single cluster can be deployed on several different sites. The Microsoft server clustering software itself is unaware of the extended nature of these types of clusters; the network and storage architectures used to build these geographic server clusters are responsible for preserving the server cluster semantics. Fundamentally, the network and storage architecture of geographically dispersed server clusters must meet the following requirements:

  • The private and public network connections between cluster nodes must each appear as a single, non-routed LAN (for example, using technologies such as VLANs to ensure that all nodes in the cluster appear on the same IP subnets). In these cases, the network connections must be able to provide guaranteed maximum round trip latency between nodes of no more than 500 milliseconds.
  • Any geographically replicated storage technologies used must preserve single disk semantics, such as persistent arbitration of a logical unit to the Microsoft server cluster product. The quorum disk must be replicated in real-time, synchronous mode across all sites.

Adding data replication software and extended LAN hardware to existing, already validated configurations can create many geographically dispersed solutions. However, these solutions radically change the nature of a pre-validated configuration, particularly with respect to timing and latency. Microsoft therefore requires that both the hardware and software configuration of a geographically dispersed server cluster be validated and listed on the cluster Hardware Compatibility List (HCL) before Microsoft considers them to be supported.

At this time, geographically dispersed server cluster configurations are limited to cluster nodes located at two distinct sites.

Click to show or hide information. Supported Geo-Cluster Topologies

The following table shows the supported cluster topologies for clusters servers that operate at two geographic locations.

Operating System | Number of Nodes | Storage Interconnect
Windows .NET Server 2003, Enterprise Edition (32-bit version) | 2–8 nodes | Fibre Channel
Windows .NET Server 2003, Datacenter Edition (32-bit version) | 2–8 nodes | Fibre Channel
Windows .NET Server 2003, Enterprise Edition (64-bit version) | 2–8 nodes | Fibre Channel
Windows .NET Server 2003, Datacenter Edition (64-bit version) | 2–8 nodes | Fibre Channel

Note: Microsoft supports geographically dispersed server clusters when the cluster size is not greater than the number of nodes listed in the preceding table.

Click to show or hide information. Geo-Cluster: Validation Process

Geographically dispersed server clusters are validated as follows:

  • The servers and the basic storage units used in the geographic server cluster configuration first must be validated as either a Windows® 2000 Advanced; Datacenter Server; Windows .NET Server 2003, Enterprise Edition; or Windows .NET Server 2003, Datacenter Edition cluster configuration using the Cluster HCT kit. This prerequisite ensures the basic cluster capabilities of the server and storage hardware.
  • With the cluster reconfigured as a geographically dispersed server cluster, the configuration must pass all tests. Note that ALL phases of the test must be run to completion. The logs submitted must be complete.

Geographically dispersed server clusters are validated using the standard self-test process specific to the type of submission.

Note: That an existing configuration must be fully retested if it is later reconfigured as a geographically dispersed cluster. For example, if a 4-node cluster is validated and on the HCL, that 4-node configuration must be fully retested if it is to be deployed in a geographically dispersed configuration.

Click to show or hide information. Geo-Cluster: HCL entry and submission process

A geographically dispersed server cluster must GUARANTEE that the round-trip latency of the network between cluster nodes is at most 500 ms. To ensure that the configuration conforms to the requirements, an additional step is required in the validation process. A network latency test must be run on the configuration being validated and the log from that test must be attached to the submission package. The Latency test is part of the MovN test that needs to be selected manually on the configuration tab. If this test is selected the Latency log is collected automatically by the MovN test suite.

A submission package for a geographically dispersed server cluster consists of the following:

  • The standard HCT submission package for a cluster validation.
  • A readme.txt identifying this submission as a geographically dispersed server cluster submission.
  • A log file containing the network latency test output.

Click to show or hide information. Geo-Cluster: Microsoft support

As described above, a geographically dispersed server cluster must GUARANTEE a maximum 500 ms round-trip latency between cluster nodes. When a geographic server cluster installation is deployed, the vendor or the customer must run the network latency test to ensure that the specific configuration conforms to the guarantees. If the inter-site links are changed (for example, an alternative carrier is used) the link must be re-validated using the latency test.

In the event of an issue with a geographically dispersed server cluster, the Microsoft® support organization requires:

  • Logs from the latency test showing that the inter-site link is of sufficient quality.
  • Cluster logs, which are important because they can indicate if there were issues with the latency of cluster heartbeats during normal operation.

Click to show or hide information. Geographically Dispersed Cluster Checklist

  • All kernel components that have logo requirements must be validated and signed if required by Windows Hardware Quality Labs (WHQL) before a configuration is submitted for geographic cluster validation.
  • A device independent vendor (DIV) must have an agreement in place with the OEM before they can use OEM validated systems in their own submissions.
  • Servers, network infrastructure, and storage infrastructure must be validated before it can be validated for a geographic server cluster. For example, for a Windows® 2000 Datacenter Server geographically dispersed server cluster, the servers must be validated as Windows 2000 Datacenter Servers.
  • If this installation involves Windows Datacenter Server, the Datacenter Server HCTs must pass with all kernel drivers loaded and operational, including those used by the cluster services.
  • Any changes to the kernel-mode components (new versions) must pass the appropriate HCT refresh tests. For example, for Datacenter Server validation, new versions must pass refresh tests as part of a Datacenter Server configuration. (Criteria defined in the HCT documentation)
  • All required phases of the cluster validation must be run to completion and the logs submitted. HCT test phases cannot be manually terminated.
  • The cluster team reserves the right to probe deeper into some of the areas if there is insufficient information to guarantee correct operation.
  • Any changes to the software that modify the quorum algorithm or the mirroring mechanism in a fundamental way must be re-reviewed by Microsoft.
  • Any changes to the cluster-specific software (new versions) must pass the HCT refresh (criteria defined in the HCT documentation)
  • A re-review of the software design is unnecessary unless the quorum or mirroring software mechanism is changed (bug fixes to an existing review do not require re-review - in this case, the existing contingency can be referenced).

Click to show or hide information. Changes to a Cluster Solution

For "Refresh Test To Achieve Logo", the cluster configuration must pass the following tests:

  • Signed Driver Check
  • Validate N Node

 | No Retest Required | Full Retest | Refresh Test To Achieve Logo
Server | Changing the number of processors in a multiprocessor server. (Example 2->4 or4->2) |  |
 | Changing the network card used for client access as long as this new card is in on the HCL. |  | New Service Pack and/or Hot Fixes
 | Changing the internal bus used to boot the system. | Changing the server used in the configuration. We determine a different server if there is a separate entry in the HCL for that server. |
 | Adding more memory to the server. |  |
 | Changing the speed of the processors in the server with a delta of less than 500MHz. |  | Changing the speed of the processors in the server with a delta of 500MHz or more.
 | Changes to the BIOS settings or firmware version |  |
 | Any changes to devices that are not on the cluster candidate component HCL, such as internal CD-ROM drives, tape drives, video cards, and so on. |  | Change or Add new drivers to any of the node
Storage / RAID Controller | Changing the Raid level used in HW raid. Going from all Raid 1 sets to all Raid 10 sets for example doesn’t make it a new configuration. When the SCSI devices are tested at Microsoft they will be configured and tested in all different configurations. | Changing or adding a SCSI HW RAID box of a different type than previously validated. | Updates to existing Driver or Filter Driver or firmware
 | Adding another SCSI HW RAID box of the same type, as long as that RAID box is on a bus with a SCSI HBA previously in the configuration. |  | Additional Storage I/O Path(s)
 | Adding more disks to a configuration |  |
Fibre Host Bus Adapter | Adding another Fibre HBA of the same type, as long as the storage solution on that new bus is the same as the original tested configuration. |  | Changes to the HBA Firmware or Software Driver
 | **In a multi-node system, running with 2 like HBAs allows for use of either separately, or in a 2-node configuration |  | Change to a different type of HBA card(s)
 | Changes to the support of the PCI bus speed. Some adapter can support 33mhz and 66mhz. |  | Change to the BIOS settings
Switches and Hubs | Changing the number of ports within a switch block | Changing or adding a fibre channel switch or hub of a different type than previously validated. | Changing or adding a fibre channel switch firmware version to a version other than previously validated.
 |  |  | Changes to a switch or the switch software
SCSI Host Adapter | Adding another SCSI HBA of the same type, as long as the storage solution on that new bus is the same as the original tested configuration. | Changing or adding a SCSI RAID adapter of a different type than previously validated. |
 |  | Changing or adding a SCSI HBA of a different type than previously validated. |
Geographically Dispersed Clusters |  | Change inter-site interconnect technology (e.g. T1 to ATM) | Change VLAN technology
 |  | Change quorum arbitration mechanism | Update data mirroring s/w (if host-based s/w)
*** Communication Link |  | Different type of equipment. | Changes to firmware, software, and/or hardware components

** In a validated multi-node cluster:

Node 1 & 2 has HBA type H1 and Node 3 & 4 has HBA type H2. A valid 2-node configuration can be created using any combination of HBA of type H1 and/or H2.

*** Communication Link is the hardware component that linked the two storages that are geographically separated. This equipment is usually found in a Geo-Cluster configuration.


Server Cluster System Validation Test Assertions

This section contains the detailed list of test assertions for Server Cluster System Validation Test

Signed Driver Check Test Assertions

Assertions in this section are tested in TD-24.1 Signed Driver Check Test

24.1.1 All drivers must be signed by WHQL

Reference Document: WLD - A6.4.6, A6.4.7, B10.9.3.3
Test Description: TD-24.1 Signed Driver Check Test


Hardware Tests Assertions

Note These assertions are obsolete and have been removed from HCT kit.

24.2.1 [DELETED]
24.2.2 [DELETED]


Validate 1 Node Tests Assertions

Assertions in this section are tested in TD_24.3 Validate 1 Node Cluster Test.

24.3.1 The cluster must work in a one node configuration, and must pass stress testing in this configuration.

Reference Document: WLD - A6.4.6, A6.4.7, B10.9.3.3
Test Description: TD-24.3 Validate 1 Node Cluster Test


Validate N Node Tests Assertions

Assertions in this section are tested in TD-24.4 Validate N Node Cluster Test.

24.4.1 The cluster must work in a configuration with all nodes joined to the cluster, and cluster resources can successfully be moved between nodes.

Reference Document: WLD - A6.4.6, A6.4.7, B10.9.3.3
Test Description: TD-24.4 Validate N Node Cluster Test

24.4.2 The cluster must work in a configuration with all nodes joined to the cluster, and failover works properly when a cluster node crashes.

Reference Document: WLD - A6.4.6, A6.4.7, B10.9.3.3
Test Description: TD-24.4 Validate N Node Cluster Test


Move N Node Tests Assertions

Assertions in this section are tested in TD-24.5 Move N Node Cluster Test

24.5.1 The cluster must work in a configuration with all nodes joined to the cluster, and cluster resources can successfully be moved between nodes.

Reference Document: WLD - A6.4.6, A6.4.7, B10.9.3.3
Test Description: TD-24.5 Move N Node Cluster Test

24.5.2 Geographically Distributed Clusters: the cluster network must have acceptable latency.

Reference Document: WLD - A6.4.6, A6.4.7, B10.9.3.3
Test Description: TD-24.5 Move N Node Cluster Test


Server Cluster System Validation Test Descriptions

This section presents the system configuration criteria for a Microsoft Cluster Server (Server Cluster) system. Note that all components in a cluster system must be validated to run on Windows .NET Server 2003 and be listed on the HCL before they will be considered for Server Cluster-specific testing. Components that are not on the HCL must pass HCT tests prior to Server Cluster testing. Server Cluster testing is designed specifically for cluster requirements, not general Windows .NET Server 2003 family requirements.


Setup for Server Cluster Testing

Click to show or hide information. Maximizing Test Results for HCL Listing purposes

Maximizing test results will reduce your test team's work effort and get you the most listings for minimal effort. As a general statement, testing with the more complex Windows .NET Server 2003 family will also enable you to list the simpler SKUs as noted herein.

If a vendor successfully completes 2-node, 4-node, or 8-node Datacenter Server HCT Cluster testing, they are also assumed to pass for Enterprise Server under the respective number of nodes and no further testing is required; they may request immediate HCL listing for Enterprise Server.

If a vendor successfully completes 8-node Datacenter Server HCT Cluster testing, they are assumed to pass for 2-node, 4-node, 6-node (or any combination as long as the number of nodes remain less than or equal to 8 nodes) Datacenter and Enterprise Server Cluster testing and no further testing is required for the tested hardware; they may request immediate HCL listing for 2-node, 4-node, 6-node, 8-node Datacenter or Enterprise Server.

If a vendor successfully completes Enterprise Server Cluster testing they are NOT assumed to be tested for Datacenter Server. They must be tested separately with Datacenter Server.

If a vendor successfully completes 2-node cluster HCT testing, they are NOT assumed to be tested for greater than 2-node cluster.

Click to show or hide information. Cluster Validation Overall Process

This section summarizes the overall process with the cluster HCT. The following steps are ordered and correspond directly to how the tests will be run in relation with hardware/software setup. This should be followed precisely to avoid wasting test cycles.

Set up the hardware as shown in Figure 1a or Figure 1b.

Figure 1a. Standard Server Cluster configuration using SCSI (or SSA) adapters

Figure 1b. Standard Server Cluster configuration using Fibre Channel adapters

  1. Install the desired operating system on all the cluster nodes, clients and client master. During installation you should install components for the tests described in the Section titled "Installing OS Components for Tests in Validation Kit". You should also create a domain account, give the account local admin privileges on all machines and use this to log onto all machines during all test phases (cluster nodes, master client and clients).
  2. Run the "Signed Driver Check" test on the cluster node that has the maximum processors and memory.
  3. Reboot node 1 and turn all the other nodes off.
  4. Create a partition on each shared drive.
  5. Format each shared drive with Basic NTFS.
  6. Configure clustering on node 1 (that is, form a one-node cluster).
  7. Run the Validate 1 Node test.
  8. Power on the rest of the nodes.
  9. Join new nodes to the cluster created in step 6.
  10. With all the nodes having joined the cluster, run the Validate N Node test.
  11. With all the nodes having joined the cluster in the previous tests, run Move N Node test. If this is a Geo-Cluster, you need to manually check the following tests: TLSrv_Srv and TLClt_Srv.
  12. Submit results to WHQL.


TD-24.1 Signed Driver Check Test Description

Test Kit: HCT 11, HCT 10

Overview

This test verifies that all drivers are signed by the Windows Hardware Quality Labs (WHQL). In addition, the test also verifies the vendor ID of hardware components.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test should run on the cluster node with the maximum number of processors and memory.

Results Interpretation

The test writes the results to the file Chklogo5.log. The log file must not report errors, unsigned drivers, or mismatched vendor IDs. If any of these failures occurs, they must be addressed, and the test needs to be rerun. A "clean" log is required before this test can be considered successfully completed.

If you are unsure of a vendor ID number for a component, please contact WHQL at whqlsys@microsoft.com for more information.


TD-24.2 Hardware Tests

Note The following cluster server tests have been removed from the HCT kit:

  • Client Server Phase 1: Client test
  • Client Server Phase 1: Server test
  • Client Server Phase 2: Run test
  • Client Server Phase 2: Setup test


TD-24.3 Validate 1 Node Cluster Test Description

Test Kit: HCT 11, HCT 10

Overview

This test validates that all of the cluster resources will work with only a single node. This is an important test case—in the event of failure, users will expect their system to function just as if this were a N-node cluster with N-1 nodes failed, although with performance loss.

This test is started from the client master. Also, on the client master, the following services are running:

Click to show or hide information. Spsrv

The cluster validation kit depends heavily on this service. It is started on the cluster nodes and the clients in addition to the client master. The kit uses this for all communication with any other machine. It is also used to start, stop and monitor tests.

Click to show or hide information. Autosniff

Another process running on the master client is autosniff. This process sniffs network traffic that may turn out useful when performing triage on failures. These sniffs will be stored in .cap files in your testbin folder.

The test utilizes a minimum of 8 client machines to run stress tests against the cluster. These tests are designed to simulate the most common cluster resources that users will run on a clustered system. The client tests running on the clients against the cluster include the following file I/O tests:

Click to show or hide information. Lrgfile Test

Creates a large file and then reads backward and shrinks the file while checking read data.

Click to show or hide information. Mapfile Test

Sets up memory-mapped files to the cluster. It then modifies a section of the mapped file, committing these changes to disk by flushing the file mapping. After the flush operation completes, the test will read the data back into memory and compare that the correct data was written to the disk.

Click to show or hide information. WINS tests

Verifies that WINS is responding to client name registration, name queries and name releases.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Click to show or hide information. Required Hardware

One-node cluster. All other machines (that will join the cluster later on) should be turned off.

  • Shared storage partitioned and formatted in Basic NTFS.
  • All machines (nodes, master client and clients) should be logged using the same domain account that has local admin privileges on all these machines.
  • The cluster nodes and the master client should have two different LANs, and on each LAN all machines on the same subnet, and the public network joined to the same domain.

Click to show or hide information. How to run

  1. On the master client, under the "Installed Test Categories", select the "Cluster Servers – ALL: Cluster Servers " option.
  2. Under "Manual Tests", select "Validate 1 Node", click the "Add Selection" button, then click the "Start Tests" button.
  3. Type in the cluster name. If you make a mistake, simply type over the name.
  4. Click the Verify button. This will attempt to connect with the cluster and query the node names.
  5. Type in each client name and add the name to the list by using the Add button. If you make a mistake select the client name you wish to remove and click the Del button. The number of entered client names is displayed immediately to the right in the 'Num Clients:' field.
  6. Any changes to any of the up-down controls on the side will imply an invalid submission. These are there, however, to enable experimenting with the test kit.
  7. Click the Start button.

After the test attempts to install SRV on all nodes and clients, a dialog titled "Specify static IP Addresses" will appear. The dialog will request one IP address per non-quorum disk resource on each network visible to the clients. If your hardware setup is consistent with Figure 1 presented earlier, then only one network is visible to clients and this will be selected by default. If more than one network (cluster network) is visible to the clients, you have to choose the public one, select it with the checkmark box, and enter IP addresses for this network only. Use the combo dropdown box to specify which network the IP addresses are for, then add the static IP address for that network by typing them into the box and using the Add button. If you entered the wrong address select the incorrect address and click the Del button to remove it. Then click OK when done.

The validation kit will then create the cluster resources necessary for the tests, start the tests and display the test list running on the clients.

When the test is done, the validation kit will stop the tests running on the clients, copy back test logs, cleanup cluster resources and create a summary log.

Results Interpretation

For troubleshooting failures, refer to the section on interpreting the different logs. Here is list of common mistakes users make while running HCT kit:

  • Installing Windows XP Professional on Client master machine.
  • Entering a wrong IP Address for the given subnet mask when HCT prompts for IP Address.
  • Installing different numbers of Network Interface cards on cluster nodes.
  • The domain/user account, which is being used by HCT to do authentication, does not have local administrative privilege on all client machines and cluster nodes.
  • Services required by tests haven't been installed prior to test runs.
  • Cluster nodes don't meet minimum hardware requirements.
  • Client tests don't stop. If this happens you can restart the clients before the next run.
  • The cluster resources created aren’t cleaned up at the end. You can use the Cleanup tool shipped with the kit in the HCT directory. Running "Cleanup –clustername:<clustername> -clean clusflags:1" on the client master will offline and delete the resources created by the kit.
  • Use the WTTCopyLogs tool to collect logs from the cluster nodes. Running "WTTCopyLogs -server:<clustername> -dest:. -ini:.\WTTCopyLogsCluster.ini" on the client master (from testbin directory) will collect cluster logs, event logs, spsrv logs and other logs from all the cluster nodes. If you don’t run this from the testbin directory, make sure to change the -ini parameter to point to WTTCopyLogsCluster.ini in your testbin directory. You will need to run this utility before you quit the test run, as it requires spsrv service to be on the cluster nodes. If you want to copy logs from the clients as well, you have to set an environment variable (HCTClients) before running the WTTCopyLogs utility. You can set the environment variable using the command: "set HCTClients=Client1,Client2, etc."
  • A large time difference between the machines in the test setup (clients, master client, or cluster nodes) will cause an error in the "Setting up Srv" phase. To resolve this, run "net time /domain:<domainname> /set" to sync the time with the domain.

There are many log files to be used to find problems. The log created by this test is vald1.log in your HCT directory. This is a good starting point to triage a lot of the above problems. Searching for SEV2 in this log is the best way to start.

Other useful logs may be: cluster logs, test logs, event logs, spsrv logs and autosniff logs (these are *.cap files.)

Note that the test logs and cluster logs are in GMT while the event logs are in local time. To translate between both, you need to find out the time difference between both. One way of doing this is to open any of the test logs and look at the very first line (in local) and compare that will the first line after the log header.

**** NTLOG INITIATED +DATE+10/12/2001 +TIME+16:13:12…

0CA0.0E08 2001/10/12-23:13:12.134 VAR[INFO ] 0 : [WTT]LogFile: .\Vald1.log Created.

This means that GMT is 16:13:12 when local was 23:13:12. So, the time difference is 7 hours.


Lrgfile Test Description

Overview

This test creates a large file and then reads backward and shrinks the file while checking read data.

This test requires that one of the shared drives be set up with both a file share and a network name. The file share allows mapping from a logical name to a physical partition; the network name allows clients to access the file share. The scripts will set all of this up when they are run from the client monitoring system.

The Lrgfile test uses unbuffered I/O only and retries on every file I/O operation.

You do not need to know the syntax of these test programs. The test launcher will start the test when it is run on each client machine. If the cluster is set up using the well-known names that Microsoft provides, no further input will be required.

The Lrgfile program will run as a generic cluster application on the server. This allows the tests to provide local heavy I/O stress on the cluster as well as client I/O stress. This is helpful in ensuring that the SCSI bus can handle failovers when large I/O operations are present on the bus. Validation test runs two slightly different variations of the Lrgfile test: one locally on cluster server node (as Generic Application resource) and one as a client on client machine.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The Lrgfile test requires 4 MB of space on tested drive. If there is not enough space, the Lrgfile test exits.

Results Interpretation

If the Lrgfile test fails, look for the file Lrgfile.log. This log file contains error information and the reason(s) for failure. Because the Lrgfile test is run with -Vn switch (leaving n MB of free space on disk), a common problem is that there is not enough space to start the test. The Lrgfile test retries 15 times with 1-second pause between retries before exiting with this error. Another common problem is disk media failure. Such a problem is reported as data corruption because expected data was not read from the disk. To eliminate that kind of error run the Lrgfile test locally on the server. You can find Lrgfile.exe in your HCT\Testbin directory, or on HCT CD. Copy it on server node and run the following command from the Windows command prompt.

lrgfile -r10 -p32 -b8 -dX:

-r10 means run 10 times

-p32 means that the Lrgfile test will use 32*4 KB chunks of data for each write/read operation

-b8 means that the Lrgfile test will use 8 buffers for asynchronous write/read

-dX: replace X with suspected shared drive letter. Be sure that the disk is online on the node that runs the Lrgfile test!

The Lrgfile test creates a temporary file that will grow until it consumes entire available disk space. The test then reduces the size of the file while checking data. Do not move/failover disk resources during this test. After the Lrgfile test finishes, look in the log file Lrgfile.log (in the same directory Lrgfile.exe was run from) and search for data errors (for example, Disk data error: Chunk#xpct 0x12, chunk#got 0x0, Page#=0). If you see this error your disk likely failed and is unreliable. If your disk passes this test, but does not pass the node test with random moves/failovers, it may point to the cache problem. If both tests pass, but the client test does not, it points to a problem in the redirector. In this case, data was not written on the disk, but was cached (usually on hardware level) and reported as saved at the time prior to failover/move.

Most of other errors are either due to cluster service / resource failure or network failure.


Mapfile Test Description

Overview

This file system test sets up memory-mapped files to the cluster. It then modifies a section of the mapped file, committing these changes to disk by flushing the file mapping. After the flush operation completes, the test will read the data back into memory and compare that the correct data was written to the disk. If a failover happens before the flush operation, all changes are discarded and the test restarts. If a failover happens while the test is in the verification state, it will simply redo the verification.

This test requires that one of the shared drives be set up with both a file share and a network name. The file share allows mapping from a logical name to a physical partition; the network name allows clients to access the file share. The scripts will set all of this up when they are run from the client monitoring system.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Results Interpretation

The Mapfile test requires 4 MB of space on tested drive. If there is not enough space, the Mapfile test exits. Another common problem is network failure or cluster service/resource failure. If the test fails because of data corruption problems (read data differs from expected data), the cause is not easy to determine. In most cases, the data was not written on the disk, but was cached (usually on hardware level) and reported as saved at the time prior to failover/move. For information on how to eliminate disk-media problems, see the Results Interpretation section in the Lrgfile test description.


WINS Test Description

Overview

This test verifies that the Windows Internet Name Service (WINS) is responding to client name registration, name queries and name releases. This test is binary - either the service is working or it’s not working.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

On each Windows NET Enterprise or Datacenter Server cluster node:

Go to Start -> Settings -> Control Panel. Double-click Add/Remove Programs. Click the Add/Remove Windows Components button.

Under the Windows Components Wizard scroll down to the Network Services, list item. Highlight the item and click the Details button.

Select the list item check boxes for Dynamic Host Configuration Protocol (DHCP) and/or for Windows Internet Name Service (WINS). Click OK.

Follow the directions for the rest of the prompts. You will need to assign a static IP address on each of the network interface cards on the cluster nodes for DHCP and WINS to work correctly.

Results Interpretation

If one of the tests fails, it will indicate that WINS is not functioning properly. In this case, check to see if the WINS service has started or if the failover occurred correctly. If WINS failed to start on a failover, or it failed to move to the other node, check the entries in the event log and in the cluster log for information that may determine why WINS failed.


TD-24.4 Validate N Node Cluster Test Description

Test Kit: HCT 11, HCT 10

Overview

This test ensures all the cluster operations between nodes, such as, move and failover, will work. You need to run this test with all the nodes having joined the cluster intended for validation. This test is run from the client master.

In this test, the same tests shown in Validate 1 NodeTest are running, with the following exceptions:

  • One additional process will be present on the client master: spfail. While client tests are running, spfail will initiate asynchronous move cluster resource group operations and cluster node crashes.
  • The autosniff process started in Vald1 Test is not started in this test. Instead, the same functionality is replaced by the netsniff dll loaded within spfail. This will also create the network sniffs that may turn useful during triaging. These sniffs will be stored in .cap files in your testbin folder.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The cluster being validated:

  • Shared bus storage partitioned and formatted in NTFS.
  • All machines (nodes, master client and clients) should be logged in using the same domain account that has local admin privileges on all these machines.

Click to show or hide information. How to run

  • On the master client, under the "Installed Test Categories", select the "Cluster Servers – ALL: Cluster Servers " option.
  • Under "Manual Tests", select "Validate N Node", click the "Add Selection" button, then click the "Start Tests" button.
  • Type in the cluster name. If you make a mistake, simply type over the name.
  • Click the Verify button. This will attempt to connect with the cluster and query the node names.
  • Type in each client name and add the name to the list by using the Add button. If you make a mistake select the client name you wish to remove and click the Del button. The number of entered client names is displayed immediately to the right in the 'Num Clients:' field.
  • Any changes to any of the up-down controls on the side will imply an invalid submission. These are there, however, to enable experimenting with the test kit.
  • Click the Start button.
  • After the test attempts to install SRV on all nodes and clients, a dialog titled "Specify static IP Addresses" will appear. The dialog will request one IP address per non-quorum disk resource on each network visible to the clients. If your hardware setup is consistent with Figure 1 presented earlier, then only one network is visible to clients and this will be selected by default. If more than one network (cluster network) is visible to the clients, you have to choose the public one, select it with the checkmark box, and enter IP addresses for this network only. Use the combo dropdown box to specify which network the IP addresses are for, then add the static IP address for that network by typing them into the box and using the Add button. If you entered the wrong address select the incorrect address and click the Del button to remove it. Then click OK when done.

The validation kit will then create the cluster resources necessary for the tests, start the tests and display the test list running on the clients.

When the test is done, the validation kit will stop the tests running on the clients, copy back test logs, cleanup cluster resources and create a summary log.

Results Interpretation

For troubleshooting failures, refer to the section on interpreting the different logs. Here is list of common mistakes users make while running HCT kit:

  • Installing Windows XP Professional instead of Windows .NET Server 2003, Standard Edition on the client master machine.
  • Entering wrong IP Address for the given subnet mask when HCT prompts for an IP Address.
  • Installing different numbers of Network Interface cards on cluster nodes. Each node should have the same number of NICs as all other nodes in the cluster.
  • The domain/user account, which is being used by HCT to do authentication, does not have local administrator privilege on all client machines and cluster nodes.
  • Services required by tests haven't been installed prior to test runs.
  • Cluster nodes don't meet minimum hardware requirements.
  • Client tests don't stop. If this happens you can restart the clients before the next run.
  • The cluster resources created aren't cleaned up at the end. You can use the Cleanup tool shipped with the kit in the HCT directory. Running "Cleanup -clustername:<clustername>" on the client master will first take offline, then delete all the resources created by the kit.
  • Use the WTTCopyLogs tool to collect logs from the cluster nodes. Running "WTTCopyLogs -server:<clustername> -dest:. -ini:.\WTTCopyLogsCluster.ini" on the client master (from testbin directory) will collect cluster logs, event logs, spsrv logs and other logs from all the cluster nodes. If you don’t run this from the testbin directory, make sure to change the -ini parameter to point to WTTCopyLogsCluster.ini in your testbin directory. You will need to run this utility before you abort the test run, as it requires spsrv service to be on the cluster nodes. If you want to copy logs from the clients as well, you have to set an environment variable (HCTClients) before running the WTTCopyLogs utility. You can set the environment variable using the command: "set HCTClients=Client1,Client2, etc."
  • A large time difference between the machines in the test setup (clients, master client, or cluster nodes) will cause an error in the "Setting up Srv" phase. To resolve this, run "net time /domain:<domainname> /set" to sync the time with the domain.

There are many logs file that can be used to find problems. The log created by this test is valdN.log in your HCT directory. This is a good starting point to triage a lot of the problems described above. Searching for SEV2 in this log is the best way to start. In most cases, the reason for the kit failure is that a critical process, for example, spfail, stops. The spfail log in your HCT directory would be an important log to figure out what was going on with the cluster state.

Other useful logs to review when troubleshooting are: cluster logs, test logs, event logs, spsrv logs and autosniff logs.

Note that the test logs and cluster logs are in GMT while the event logs are in local time. To translate between both, you need to find out the time difference between both. One way of doing this is to open any of the test logs and look at the very first line (in local) and compare that will the first line after the log header.

**** NTLOG INITIATED +DATE+10/12/2001 +TIME+16:13:12…

0CA0.0E08 2001/10/12-23:13:12.134 VAR[INFO ] 0 : [WTT]LogFile: .\ValdN.log Created.

This means that GMT is 16:13:12 when local was 23:13:12. So, the time difference is 7 hours.


Failover Test Description

Overview

The failover test is designed to crash one node of a cluster and then the other node. It waits for the crashed node to reboot and then it crashes the next node. This means that the client programs can expect to have access to the cluster resources at all times, except when actual failovers are happening. This test ensures that the controller firmware and also the miniport driver for the controller don’t stall while rebooting when the other side has SCSI reservations on the shared drives. It allots time for each server to reboot after a crash. If the server fails to reboot within the allotted time, it registers a failure. This is how most Windows NT/Windows 2000/Windows .NET Server 2003 family setups will work when the default is to have the node crash dump and then automatically reboot after a failure.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test will run automatically, there is no user interaction required.

Results Interpretation

The name of the logfile is spfail.log. Search for the "SEV2" from the beginning of the log file. The first occurrence of the SEV2 error is the cause for the failure of the spfail.exe. To get an explanation for an error code, use 'net helpmsg error-code' command. For example:

C:\ >net helpmsg 1722

The RPC server is unavailable.

At least one node should be up during any phase of testing. If all the nodes die then spfail typically gets a 1722 error code (RPC Server unavailable error).

Another typical reason why a spfail test fails is if the node fails to reboot after the crash. In this case, spfail.exe will time-out.

Click to show or hide information. Debugging common SPFAIL failures: Case 1:

0554.02AC 1999/11/07-00:07:45.502 +VAR+SEV2 963 : MNSEM2N3(MNSEM2N3) is not restarted in 29 minutes Ping did not succeed

This means that the node MNSEM2N3 is not restarted after the crash. Check to see if the node is hung during the boot up. Most hangs happen during the system bios initialization. This in most cases is a H/W issue.

Click to show or hide information. Debugging common SPFAIL failures: Case 2:

0354.0510 1999/11/04-03:30:40.762 +VAR+SEV2 59 : WaitForGroupState: GetClusterGroupState returned ClusterGroupFailed Group=Cluster Group Node=I2DELL1N1 GLE=5038 Retries=11

If you see a Group Failed with 5038 (or Timeout with 1460), look for the actual resource that is failed (or timed out).

0354.0510 1999/11/04-03:30:40.992 +VAR+INFO 60 : Resource=MS Mail Connector Interchange Node:I2DELL1N1 Group:Cluster Group Status:Failed

In the example above the resource "MS Mail Connector Interchange" failed. Troubleshooting the failure of this particular resource will resolve the spfail test failure.

Click to show or hide information. Troubleshooting Failover

To check if the spsrv is installed and functioning properly on each node run the following commands from the client monitor.

"spsrvcl -host:<node name> -cmd:ping" and

"spsrvcl -host:<node name> -cmd:ping -input:crash"

Both the above commands should return status=0 for success. Success of the first command implies that spsrv is up and running. Success of the second command implies that the spsrv did not load the remclus.dll which is a required component to crash the node.

To manually crash the node, run the following command in a command window.

"spsrvcl -host:<node name> -cmd:crash"


TD-24.5 Move N Node Cluster Test Description

Test Kit: HCT 11, HCT 10

Overview

This test will ensure the resource move operation, the most common operation, will work properly. At the same time the test will verify that latency of heartbeat messages between cluster nodes does not exceed expected values during the resource move operation. You need to run this test with all the nodes joined to the cluster intended for validation. This test is run from the client master:

  • On the client master, run the process called spfail. While client tests are running, spfail will initiate asynchronous move cluster resource group operations and cluster node crashes. The client tests are engineered to tolerate interruptions of cluster services. The tests perform re-try operations for a limited time interval. If spfail detects that the resource remains offline or unavailable for too long, the test will exit.
  • The Latency Validation Test monitors the round-trip latency of UDP packets between nodes in the cluster. If the latency is above the pre-defined threshold, the tool writes warning message into a log file. The test consists of two executables, the UDP socket client - WTTLatencyValdCli.exe and the UDP socket server - WTTLatencyValdSrv.exe. The client sends out a request to the server, the server receives the packet and sends back a response. The server and client applications are installed on every node of a cluster. Every client application sends messages to the servers on each node and measures the round trip time for every response. This way the test measures the time latency for every pair of the nodes. Both server and client applications create a standard Windows NT log files - WTTLatencyValdCli.LOG on client side and WTTLatencyValdSrv.LOG on server side.
  • The autosniff process started in Vald 1 Test is not started in this test. Instead, the same functionality is replaced by the netsniff dll loaded within spfail. This will also create the network sniffs that may turn useful during triaging. These sniffs will be stored in .cap files in your testbin folder.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

  • The cluster being validated must meet the following conditions:
  • The cluster storage device must be partitioned and formatted in Basic NTFS.
  • All machines (nodes, master client and clients) should be logged in using the same domain account that has local administrator privileges on all these machines.

Click to show or hide information. How to run

  1. On the master client, under the "Installed Test Categories", select the "Cluster Servers – ALL: Cluster Servers " option.
  2. Under "Manual Tests", select "Move N Node", click the "Add Selection" button, then click the "Start Tests" button.
  3. Type in the cluster name. If you make a mistake, simply type over the name.
  4. Click the Verify button. This will attempt to connect with the cluster and query the node names.
  5. Type in each client name and add the name to the list by using the Add button. If you make a mistake select the client name you wish to remove and click the Del button. The number of entered client names is displayed immediately to the right in the 'Num Clients:' field.
  6. Any changes to any of the up-down controls on the side will imply an invalid submission. These are there, however, to enable experimenting with the test kit.
  7. Click the Start button.

After the test attempts to install SRV on all nodes and clients, a dialog titled "Specify static IP Addresses" will appear. The dialog will request one IP address per non-quorum disk resource on each network visible to the clients. If your hardware setup is consistent with Figure 1 presented earlier, then only one network is visible to clients and this will be selected by default. If more than one network (cluster network) is visible to the clients, you have to choose the public one, select it with the checkmark box, and enter IP addresses for this network only. Use the combo drop-down box to specify which network the IP addresses are for, then add the static IP address for that network by typing them into the box and using the Add button. If you entered the wrong address select the incorrect address and click the Del button to remove it. Then click OK when done.

The validation kit will then create the cluster resources necessary for the tests, start the tests and display the test list running on the clients.

When the test is done, the validation kit will stop the tests running on the clients, copytest logs, clean up cluster resources and create a summary log.

Results Interpretation

For troubleshooting failures, refer to the section on interpreting the different logs. Here is list of common mistakes user makes while running HCT kit:

Installing Windows XP Professional instead of Windows .NET Server 2003, Standard Edition on the client master machine.

Entering the wrong IP Address for the given subnet mask when the HCT prompts for an IP Address.

Installing different numbers of Network Interface cards on cluster nodes. Each node should have the same number of NICs as all other nodes in the cluster.

  • The domain/user account, which is being used by HCT to do authentication, does not have local administrative privilege on all client machines and cluster nodes.
  • Services required by tests haven't been installed prior to test runs.
  • Cluster nodes don't meet minimum hardware requirements.
  • Client tests don't stop. If this happens, you can restart the clients before the next run.
  • The cluster resources created aren't cleaned up at the end. You can use the Cleanup tool shipped with the kit in the HCT directory. Running "Cleanup -clustername:<clustername>" on the client master will offline and delete the resources created by the kit.
  • Use the WTTCopyLogs tool to collect logs from the cluster nodes. Running "WTTCopyLogs -server:<clustername> -dest:. -ini:.\WTTCopyLogsCluster.ini" on the client master (from testbin directory) will collect cluster logs, event logs, spsrv logs and other logs from all the cluster nodes. If you don’t run this from the testbin directory, make sure to change the -ini parameter to point to WTTCopyLogsCluster.ini in your testbin directory. If you want to copy logs from the clients as well, you have to set an environment variable (HCTClients) before running the WTTCopyLogs utility. You can set the environment variable using the command: "set HCTClients=Client1,Client2, etc."
  • A large time difference between the machines in the test setup (clients, master client and/or cluster nodes) will cause an error in the "Setting up Srv" phase. To resolve this, run "net time /domain:<domainname> /set" to sync the time with the domain.

There are many logs file to be used to find problems. The log created by this test is movN.log in your HCT\testbin directory. This is a good starting point to triage a lot of the above problems. Searching for SEV2 in this log is the best way to start. In most cases, the reason for the kit failure is that a critical process, namely spfail.exe, stops. The spfail log in your HCT directory would be an important log to figure out what was going on with the cluster state.

For results of time latency validation you should look into the client side log file - WTTLatencyValdCli.LOG.

All the errors during execution will show up in the log file. Any time when time latency occurred to be more then specified there would be the warning in the log - LATENCY VALIDATION ERROR! Did not receive the message back in <> milliseconds.

If the Log Level specified is 4 or higher then the test reports PASS and FAIL for every variation, and the tests passed if all the variations passed.

For any log level there will be string which shows how many variations were executed, how many packages were late, how many packages were lost, what is the minimal and maximal values for the time latency during the test. The string should be the following

VAR[WARN ] <> : [TST]Latency Validation Test finished. Server:<Server_Name> Late packets: 0 Lost packets: 0 SentPackets: 1000000 Min Latency: <Number> Max Latency: <Number>(wttlatencyvalidclifunctiontable.cpp@226)

Other useful logs may be: cluster logs, test logs, event logs, spsrv logs and autosniff logs.


Geo-Cluster Test Checklist

24.6.1 | Any changes to the software that modify the quorum algorithm or the mirroring mechanism in a fundamental way must be re-reviewed by Microsoft.
24.6.2 | Any changes to the software (new versions) must pass the HCT
24.6.3 | Servers, network infrastructure, and storage infrastructure must be validated before it can be validated for a geographic server cluster. For example, for a Windows 2000 Datacenter Server geographically dispersed server cluster, the servers must be validated as Windows 2000 Datacenter Servers.
24.6.4 | If you have kernel-mode components, they must be validated on a Windows Datacenter Server platform before being validated on a geographically dispersed server cluster configuration.
24.6.5 | WHQL must sign kernel-mode drivers, unless they grant a waiver.
24.6.6 | External devices use automatic termination or an accessible on-board termination switch

Including the hardware and software requirements.


Chapter 25: Printer Test Specification

Overview

This chapter describes printer device tests for requirements defined in Microsoft Windows Logo Program System and Device Requirements.

This chapter is intended as an overview of tests for OEMs and IHVs, and as a guide to actual test development for software engineers. It is not designed to provide a complete test plan or testing procedure for printing subsystems, printers, or printer drivers.

The Printer Test Specification is divided into two main sections. The first covers test coverage, functional requirements, and test assertions; the second covers the actual test implementations. Legacy tests are not covered in depth in this document.

Test Coverage

The Printer tests exercise the printer hardware and driver to test compliance with Microsoft Windows Logo Program System and Device Requirements.

Test Methology

Each individual test case is composed of two parts: confirmation that the required feature is present, as reported by the printer driver, and verification that the feature is truly supported by the hardware (or by a combination of hardware and driver software), as expected for that printer device type. For instance, it is expected that if your printer hardware supports color that it will produce reasonable results within the capabilities of the device. However, for devices that for instance do not support graphics, such as text only printers, it is expected that the driver will handle the graphic calls, but that the output on the device will not render the images.

The fact that the expectations for the resultant output from the tests that require visual inspection sometimes makes it difficult to determine the correctness of the output. The output should be compared to output of other devices of the same capabilities. For instance, compare PostScript based laser printer output with output from other PostScript based laser printers. It is sometimes useful to compare output from similar but slightly different technologies (i.e. non-PostScript and PostScript output for same printer hardware or ink jet with laser printers), but this is usually difficult, because it relies mostly upon the reviewer’s ability to distinguish between technology differences.

The methodologies for verifying compliance with a particular test assertion can be divided into 2 general categories:

  • Visual test – The test relies upon user interaction to visually inspect or compare images. In all instances where a visual test is necessary, the pass or fail criteria is explicit to help the tester make objective decisions. For example, a printer test image is designed to accentuate wrong implementations and make the failure case obvious.
  • Automated Implementation test – The test determines compliancy by results a APIs and DDIs supported by the driver. The test checks the returns and general functionality of the APIs and DDIs with what is expected based of SDK, DDK, and implementation expectations of the operating system.

While each test case may use a single test method or several in combination, the majority of the tests use the both methods. No matter how good the automation, to test certain aspects of the printer (both the driver and device) output must be generated and evaluated.


Printer Test Assertions Summary

This section contains the test assertions for printers.

Table 25-1. Printer Test Assertion Summary

assertion # | Reference document | Test Coverage Section and Test Name
25.1.1 | WL-B8.1.4.5 | Device is available immediately following installation (PrintInstant.exe)
25.2.1 | WL-B8.1.3.3 & B8.1.3.4 | Printer Device Capabilities (PrDevCap.exe)
25.3.x | WL-B8.1.3.2 | Printable regions accuracy (PrntArea.exe)
25.4.x | WL-B8.1.3.1 | Windows application compatibility (WinParty.exe)
25.5.1 - 5 | WL-B8.1.2.4 & B8.1.4.7 | Windows Color Quality specification compliancy for printers (PrintColor.exe)
25.6.1 | WL-B8.1.1 | Windows API and DDI compatibility (PrintCert.exe)
25.7.x | WL-B8.1.1.4 | 16-bit application print compatibility (Print16.exe)
25.8.x | WL-B8.1.4.3 | Standard port monitor compatibility (HCTAddPort.exe)


Printer Test Assertions

This section contains the detailed list of test assertions.


Reference Documents for Printer Assertions

Microsoft Windows Driver Development Kit

http://www.microsoft.com/ddk/

Microsoft Windows Logo Program System and Device Requirements, Version 2.0

http://www.microsoft.com/hwdev/winlogo/
(listed as "WLP#" in these assertions)

PC 2001 System Design Guide and PC 99 System Design Guide

http://www.microsoft.com/hwdev/platform/pcdesign/desguide/pcguides.asp

Windows Color Quality Specifications for Printer OEMs

http://www.microsoft.com/hwdev/tech/color/default.asp


Device Availability Assertions

This assertion is not tested as the PrintInstant test is obsolete.

25.1.1 Device is available immediately following installation

Reference Document: WL# -B8.1.4.5; PC 2001 System Design Guide - PRNT-0304
Test Description: TD-25.1 Device is available immediately following installation


Printer Device Capabilities Assertions

These assertions are tested in the DEVMODE test.

25.2.1 Driver is user mode

Reference Document: WL-B8.1.4.10; PC 2001 System Design Guide - PRNT-0307
Test Description: TD-25.2 Printer Device Capabilities


Windows Color Quality Assertions

These assertions are tested in TD-25.5 Windows Color Quality compliancy for printers.

25.5.1 Divide by zero calculation error

Reference Document: WLP# - B8.1.2.4; Windows Color Quality Specification for Printer OEM; PC 2001 System Design Guide - PRNT-301
Test Description: TD-25.5 Windows Color Quality compliancy for printers

25.5.2 Device colors average Delta E* is not <= 20.0

Reference Document: WLP# - B8.1.2.4; Windows Color Quality Specification for Printer OEM; PC 2001 System Design Guide - PRNT-301
Test Description: TD-25.5 Windows Color Quality compliancy for printers

25.5.3 Device colors Mean Square Root Delta E* is not <= 67.0

Reference Document: WLP# - B8.1.2.4; Windows Color Quality Specification for Printer OEM; PC 2001 System Design Guide - PRNT-301
Test Description: TD-25.5 Windows Color Quality compliancy for printers

25.5.4 Center colors average Delta E* is not <= 12.0

Reference Document: WLP# - B8.1.2.4; Windows Color Quality Specification for Printer OEM; PC 2001 System Design Guide - PRNT-301
Test Description: TD-25.5 Windows Color Quality compliancy for printers

25.5.5 Center colors Mean Square Root Delta E* is not <= 45.0

Reference Document: WLP# - B8.1.2.4; Windows Color Quality Specification for Printer OEM; PC 2001 System Design Guide - PRNT-301
Test Description: TD-25.5 Windows Color Quality compliancy for printers


Windows API and DDI Compatibility Assertions

These assertions are tested in the PrintCert.exe test.

25.6.1 Windows APIs and DDIs for printing are supported

Reference Document: WLP#-B8.1.1.1; Windows Platform SDK "Windows GDI" and Windows DDK "Printer Drivers and Spooler Components"
Test Description: TD-25.6 Windows API and DDI compatibility


16 bit Application Print Compatibility Assertions

These assertions are tested in the Print16.exe test.

25.7.1 Printer driver must be compatible with 16-bit applications

Reference Document: WLP# - B8.1.1.4; Windows XP/Windows 2000: "Printer Drivers and Spooler Components" in the Windows DDK
Test Description: TD-25.7 16 bit Application Print Compatibility (Print16)


Printer Test Descriptions

This section describes the tests provided.

TD-25.1 Device Availability (PrintInstant)

This test is obsolete and is no longer in the test kit.

Overview

The tool verifies there is no reboot in between the printer installation and the printer is printable after installation.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The tool needs to be run before the printer is installed and then again after. Here are the command line switches to use for the calls:

Before Printer Install: PrintInstant -before

After Printer Install: PrintInstant -printer \\Server\Printer -log WHQL.result

Results Interpretation

Success if the tool doesn’t log an NT event log failure for the printer and a page is printed.


TD-25.2 Printer Device Capabilities (PrDevCap)

Test Kit: HCT 11, HCT 10

Overview

Tests to make sure the printer's capabilities conform to standard WHQL guidelines. Checks DEVMODE, driver name, port name, filenames, driver version, technology, SpecVersion, DEVMODE size, Private driver-data size, and driver are user mode.

This test only has an assertion for the new point of failure for kernel mode printer drivers. The legacy test cases do not have assertions.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Install the printer or printers to be tested and run PrDevCap.exe.

Results Interpretation

Text based log file will have PASS or FAIL string if the testing passed of failed. This test produces no output.


TD-25.3 Printable Regions Accuracy (PrntArea)

Test Kit: HCT 11, HCT 10

This is a legacy test. It has no new points of failure and no assertions.

Overview

Tests the Printable Regions accuracy of the driver. This is done by producing two pages of output that consist of lines drawn at the edge of the printable region specified by the driver, one inch in from the page edge, and a two by two inch box.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Install the printers or printers to be tested and run "prntarea /a /d /e".

Results Interpretation

This test produces 2 pages of output per supported pager size (one page portrait and the other landscape). User must verify that an outside box is printed at the edge of the printable area of the page. They must also verify that an interior box is printed with a one-inch margin from the edge of the paper. A third box is printed somewhere in the middle of the page that is two by two inches.


TD-25.4 Windows Application Compatibility (WinParty) Test Description

Test Kit: HCT 11, HCT 10

This is a legacy test and has no test assertions.

Overview

This test verifies the standard application compatibility of a printer driver with the Windows operating system.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Operating system:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition

Additional software requirements:

  • Microsoft Office XP Professional (includes Access 2002, Excel 2002, PowerPoint 2002, and Word 2002)

OR

  • Microsoft Office 2000 (includes Access 2000, Excel 2000, PowerPoint 2000, and Word 2000)

Results Interpretation

The test generates a detailed log file of test results (Winparty.log) and displays on-screen pass or fail status.

For more information about this test, please refer to the file AppTest Documentation.doc. You can find this file in the directory \HCT\Testbin\Tstfiles\Wrd.


TD-25.5 Windows Color Quality Compliancy for Printers (PrintColor) Test Description

Test Kit: HCT 11, HCT 10

Overview

This is a quantitative test of the color quality produced by color printing devices. The test produces UI that the user enters the color measurements from measuring a series of color patches that are output. The color patches and procedure for producing them as well as a detailed description of the procedures and the under lying color science is in the Windows Color Quality Specification for Printer OEMs.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Install a printer and print the color patches as specified in Windows Color Quality Specification for Printer OEMs. Then run PrintColor.exe which will calculate the Delta E* and output a log of the results.

Results Interpretation

The test will log an NT event log failure if the color quality, as represented by the color measurements, are not within acceptable color quality as outlined in Windows Color Quality Specification for Printer OEMs.


TD-25.6 Windows API and DDI Compatibility (PrintCert) Test Description

Test Kit: HCT 11, HCT 10

Overview

This test is designed to exercise printer driver by calling GDI APIs to determine Windows API and DDI compatibility. This test has to parts: 1) that the printer driver correctly supports and implements the DDI and thus will not fail or cause a failure when its DDIs are exercised, and 2) that the printer produces the expected output for the various GDI APIs within the limitations of its capabilities.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Install the printers to be tested and then run PrintCert.exe.

Results Interpretation

This test will produce an NT event log file with any problems that the tool encountered while generating the output. The output most be visually inspected to ascertain if it produced correct output with regards to the devices capabilities.


TD-25.7 16 bit Application Print Compatibility (Print16) Test Description

Overview

Test the 16-bit application compatibility of a printer driver.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Install the printer or printers to be tested and then run Print16.exe.

Results Interpretation

If any errors occur while generating the print job, the test will log an NTLog failure. The output should be visually inspected.


Chapter 26: Hardware Abstraction Layers (HALs) Test Specification

Test Kit: HCT 10, HCT 11

Overview

The purpose of the HAL HCT kit is to test third party (non-Microsoft) hardware abstraction layer (HAL) files intended for use in Windows 2000 Datacenter or Windows .NET Server 2003, Datacenter Edition. HALs that are not intended for Datacenter class servers should not be tested with this test kit.

Note For a Windows 2000 Datacenter HAL HCT submission, use Windows 2000 Datacenter. For a Windows .NET Server 2003 HAL HCT submission, use Windows .NET Server 2003, Datacenter Edition.

The HAL HCT kit tests the DMA and timing APIs, which can cause difficult to diagnose problems when they malfunction. Some aspects of the HAL, such as interrupt routing, cannot be tested in a platform-independent way, so these APIs are not covered by the HAL test kit. Many HAL APIs can be tested merely by successfully booting the test server.


Running the HAL Test Kit

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

To run the HAL Test Kit you must have the hardware and software described under Test Tools and Equipment installed on the test server.

To run the HAL Test Kit

  1. Click Start and select Run.
  2. In the Run window, type cmd and click OK.
  3. In the command window, type cd haltest and press the Enter key.
  4. In the command window, type haltest all and press the Enter key.

The HAL Test Kit will run and log test results in Haltest.log.

See Command Line Codes used for Debugging


Command Line Codes used for Debugging

haltest.exe <function> [<subtest>] [duration <n seconds>] [interrupt <vector>] [port <timer port>] [iterations <n iterations>] [interval <n microseconds>] [logfile <file name>] [verbose] [continuous]

haltest.exe all [verbose] [logfile <file name>]

haltest.exe [verbose] [logfile <file name>]

Run without parameters, Haltest will launch a graphic user interface (GUI).

Click to show or hide information. Function codes

HSPI

HalSetProfileInterval

HSTI

HalSetTimeIncrement

KQPC

KeQueryPerformanceCounter

KSEP

KeStallExecutionProcessor

DMA

DMA tests

Click to show or hide information. Sub-test codes

If no sub-test is specified, all applicable sub tests will be run in order.

FLOOD

Flood tests

BACK

Backoff tests

LAPSE

Lapse test

STRESS

Stress test

Click to show or hide information. Global settings

All

Runs all tests and all subtests.

Logfile <filename>

Used to specify the name of the log file.

Verbose

Print more information to the logs and the debugger. Also may cause certain tests to break into the debugger when certain errors are encountered (so they may be more easily debugged).

Click to show or hide information. Settings that are only defined for certain tests

(see individual test descriptions)

Duration <seconds>

Specify how long the test should last.

Interval <microseconds>

Specify the time between subsequent reads.

Iterations <iterations>

Number of iterations to run.

Continuous

Runs test in an infinite loop.

Click to show or hide information. Additional information the test may need from the user

Interrupt <vector>

Interrupt vector used by HAL API being run. That is, if testing profile interrupt, should be the IDT vector corresponding to the profile interrupt. This only needs to be specified on a non-Microsoft HAL.

Port <timer port>

In certain cases, it is not always apparent whether it is the hardware or the HAL that is buggy. Port will read from the timer port instead of the HAL. This number is only necessary when port is not in the ACPI tables.


KeQueryPerformanceCounter Test Assertions

These assertions are tested in TD-26.1 KeQueryPerformanceCounter Test Description.

26.1.1 The value returned by KeQueryPerformanceCounter must increase monotonically at all times.

This includes when the performance counter is read over a short interval as well as a long one. The tolerance is +- 10%.

Reference document: WLP# - A6.R; Hardware Design Guide Version 2.0 for Microsoft Windows NT Server
Test description: TD-26.1 KeQueryPerformanceCounter Test Description

26.1.2 The value returned by KeQueryPerformanceCounter cannot decrease.

Reference document: WLP# - A6.R; Hardware Design Guide Version 2.0 for Microsoft Windows NT Server
Test description: TD-26.1 KeQueryPerformanceCounter Test Description


KeStallExecutionProcessor Test Assertions

These assertions are tested in TD-26.2 KeStallExecutionProcessor Test Description.

26.2.1 KeStallExecutionProcessor must stall for at least the amount of time indicated, regardless of the length of the intended stall.

Reference document: WLP# - A6.R; Hardware Design Guide Version 2.0 for Microsoft Windows NT Server
Test description: TD-26.2 KeStallExecutionProcessor Test Description

26.2.2 KeStallExecutionProcessor must stall for a reasonable amount of time.

KeStallExecutionProcessor must return within 200% of the time intended for the stall.

Reference document: WLP# - A6.R; Hardware Design Guide Version 2.0 for Microsoft Windows NT Server
Test description: TD-26.2 KeStallExecutionProcessor Test Description


HalSetTimeIncrement Test Assertions

These assertions are tested in TD-26.3 HalSetTimeIncrement Test Description.

26.3.1 Back-to-back clock tick interrupts must be received within 10% of the time returned by HalSetTimeIncrement.

Reference document: WLP# - A6.R; Hardware Design Guide Version 2.0 for Microsoft Windows NT Server
Test description: TD-26.3 HalSetTimeIncrement Test Description

26.3.2 The average time between clock tick interrupts must be within 1% of the time returned by HalSetTimeIncrement.

Reference document: WLP# - A6.R; Hardware Design Guide Version 2.0 for Microsoft Windows NT Server
Test description: TD-26.3 HalSetTimeIncrement Test Description


HalSetProfileInterval Test Assertions

These assertions are tested in TD-26.4 HalSetProfileInterval Test Description.

26.4.1 [New - v.0.9] HalStartProfileInterrupt must start the recurring profile interrupt.

Reference document: WLP# - A6.R; Hardware Design Guide Version 2.0 for Microsoft Windows NT Server
Test description: TD-26.4 HalSetProfileInterval Test Description

26.4.2 HalStopProfileInterrupt must stop the recurring profile interrupt.

Reference document: WLP# - A6.R; Hardware Design Guide Version 2.0 for Microsoft Windows NT Server
Test description: TD-26.4 HalSetProfileInterval Test Description

26.4.3 Back-to-back profile interrupt must be received within 10% of the time returned by HalSetProfileInterval.

Reference document: WLP# - A6.R; Hardware Design Guide Version 2.0 for Microsoft Windows NT Server
Test description: TD-26.4 HalSetProfileInterval Test Description

26.4.4 The average time between profile interrupts must be within 2% of the time returned by HalSetProfileInterrupt.

Reference document: WLP# - A6.R; Hardware Design Guide Version 2.0 for Microsoft Windows NT Server
Test description: TD-26.4 HalSetProfileInterval Test Description


DMA Test Assertions (HAL)

26.5.1 DMA must transfer all length transfers, from any address to any address, using both scatter-gather lists and individual mapped transfers.

DMA API functionality is required for the system to boot.

24-bit, 32-bit, and 64-bit bus-master DMA must be faithfully transferred for all length transfers, from any address to any address, using both scatter-gather lists and individual mapped transfers.

The APIs GetScatterGatherList and PutScatterGatherList must work in a multithreaded environment.

Reference document: WLP# - A6.R; Hardware Design Guide Version 2.0 for Microsoft Windows NT Server
Test description: TD-26.5 DMA Test Description (HAL).


DMA Stress Test Assertions (HAL)

26.6.1 The DMA must have the ability to queue requests for scatter gather and manage access to several adapters at once.

Reference document: WLP# - A6.R; Hardware Design Guide Version 2.0 for Microsoft Windows NT Server
Test description: TD-26.6 DMA Stress Test Description (HAL)


HAL Test Descriptions

This section contains the detailed test descriptions.

TD-26.1 KeQueryPerformanceCounter Test Description

Overview

The system performance counter must always increase. For certain applications to function correctly (multimedia and some network & video drivers), the performance counter must also increase monotonically. If the performance counter jumps around or goes backwards, the KeQueryPerformanceCounter logs an error.

The "flood" test queries the performance counter repeatedly at a spacing of a few microseconds to the precision of the performance counter. By using the PCI SCSI Controller as an independent timer, it is possible to make sure that the performance counter ticks are not deviating from the expected frequency, and make to sure that there are no local inconsistencies in performance counter output. The flood test cycles through the active processors, making sure that the performance counter is not processor dependent.

The "backoff" test queries the performance counter over variable periods of time, starting at a few microseconds between queries and increasing the time between queries until there are minutes between each query. If the performance counter frequency is slightly irregular, this test will log a failure.

A couple of incidents have arisen where performance counter problems occur randomly once an hour or even once every several hours. It is possible from the command line to specify an indefinite-length test that will run until it is told to stop or until an error occurs. This is not a regular diagnostic test but can be a useful for debugging.

The final KeQueryPerformanceCounter test is a hardware test. If the "flood" and "backoff" tests fail, this test will determine if the issue that caused the "flood" or "backoff" tests to fail is a hardware or software issue. This is an ACPI only test - it will not run on non-ACPI HALs.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Note: Tests can be run individually for debugging purposes, but the preferred method for running the HAL test kit is to run it with one command, as described above.

To run KeQueryPerformanceCounter

  • Flood test:
    haltest KQPC FLOOD
    [ITERATIONS <# iterations> | CONTINUOUS]
    [INTERVAL <# of microseconds between reads]
  • Backoff test:
    haltest KQPC BACK
  • Hardware test:
    haltest KQPC STRESS [CONTINUOUS] [PORT <timer port number>]
Required Hardware

See Required Hardware paragraph in TD-26.5 DMA Test Description

Required Software

Windows 2000 Datacenter or Windows .NET Server 2003, Datacenter Edition

Note For a Windows 2000 Datacenter HAL HCT submission, use Windows 2000 Datacenter. For a Windows .NET Server 2003 HAL HCT submission, use Windows .NET Server 2003, Datacenter Edition.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-26.2 KeStallExecutionProcessor Test Description

Overview

The KeStallExecutionProcessor test "stalls" the processor for at least the amount of time specified by the stall parameter. The test prints a warning when stalling for longer than specified. Like the KeQueryPerformanceCounter tests, KSEP tests has a "flood" and "backoff" version. The "flood" version stalls the processor for short durations, the "backoff" version stalls the processor for progressively longer durations.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Note: Tests can be run individually for debugging purposes, but the preferred method for running the HAL test kit is to run it with one command, as described above.

To run KeStallExecutionProcessor

  • Flood Test:
    haltest KSEP FLOOD [INTERVAL <stall time usec>]
  • Backoff Test:
    haltest KSEP BACK [INTERVAL <max stall time usec>]
Required Hardware

See Required Hardware paragraph in TD-26.5 DMA Test Description

Required Software

Windows 2000 Datacenter or Windows .NET Server 2003, Datacenter Edition

Note For a Windows 2000 Datacenter HAL HCT submission, use Windows 2000 Datacenter. For a Windows .NET Server 2003 HAL HCT submission, use Windows .NET Server 2003, Datacenter Edition.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-26.3 HalSetTimeIncrement Test Description

Overview

There are four different tests for HalSetTimeIncrement. The "flood" test compares the intervals between consecutive interrupts, the "lapse" test computes the number of interrupts received over a period of about a minute, and the "backoff" test steps through each supported time increment value. The "stress" test changes the time increment several thousand times to ensure that it has no adverse effects on the timing of the system.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Note: Tests can be run individually for debugging purposes, but the preferred method for running the HAL test kit is to run it with one command, as described above.

To run HalSetTimeIncrement

  • Flood test:
    haltest HSTI FLOOD [INTERVAL <increment usec>]
  • Backoff Test:
    haltest HSTI BACK
  • Lapse Test:
    haltest HSTI LAPSE [DURATION <duration sec>]
  • Stress Test:
    haltest HSTI STRESS
Required Hardware

See Required Hardware paragraph in TD-26.5 DMA Test Description

Required Software

Windows 2000 Datacenter or Windows .NET Server 2003, Datacenter Edition

Note For a Windows 2000 Datacenter HAL HCT submission, use Windows 2000 Datacenter. For a Windows .NET Server 2003 HAL HCT submission, use Windows .NET Server 2003, Datacenter Edition.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-26.4 HalSetProfileInterval Test Description

Overview

There are tree different tests for HalSetProfleInterval. The "flood" test compares the intervals between consecutive interrupts. The "lapse" test computes the number of interrupts received over a period of about a minute. The "stress" test changes the time increment several thousand times to ensure that it has no adverse effects on the timing of the system.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Note: Tests can be run individually for debugging purposes, but the preferred method for running the HAL test kit is to run it with one command, as described in Running the HAL Test Kit.

To Run HalSetProfileInterval

  • Flood test:
    haltest HSPI FLOOD [INTERVAL <increment usec>]
  • Lapse Test:
    haltest HSPI LAPSE [DURATION <duration sec>]
  • Stress Test:
    haltest HSPI STRESS
Required Hardware

See Required Hardware paragraph in TD-26.5 DMA Test Description

Required Software

Windows 2000 Datacenter or Windows .NET Server 2003, Datacenter Edition

Note For a Windows 2000 Datacenter HAL HCT submission, use Windows 2000 Datacenter. For a Windows .NET Server 2003 HAL HCT submission, use Windows .NET Server 2003, Datacenter Edition.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-26.5 DMA Test Description

Overview

The DMS Test consists of the following tests:

Click to show or hide information. Large Buffer Test

This test allocates the largest buffer possible (up to a maximum amount of 0x0FFF FFFF) and does DMA transfers to and from this buffer. The number of map registers available for the device and the availability of common buffer space limit actual transfer size, however, so the entire is broken up into manageable bits (up to the maximum size allowed).

Click to show or hide information. Small Buffer Test

The small-buffer test sends a single byte down each byte channel to ensure that the hardware / software is capable of doing versatile transfers.

Click to show or hide information. Misaligned Data Test

The misaligned test does 2 byte transfers to every odd byte position in just over a page -so a single 2-byte transfer will end up crossing cache lines and page boundaries.

Click to show or hide information. Misaligned Page Plus Test

This test does DMA to a buffer that is the PAGE_SIZE + 2 bytes long, but is aligned in such a way that it occupies three separate pages.

Click to show or hide information. Single Page Test

This test copies one aligned memory "page" to another.

Click to show or hide information. First/Last page test

Verifies that DMA can be transferred to both the first & last page of physical memory.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Note: this test can be run individually for debugging purposes, but the preferred method for running the HAL test kit is to run it with one command, as described above

To run the DMA tests

haltest DMA

Required Hardware

The DMA tests require a Symbios PCI SCSI controller that uses one of the following chipsets:

  • Symbios 875 and Symbios 876: For systems with 32 bit PCI busses.
  • Symbios 22910: For systems with 64-bit PCI busses, or systems that use hardware map registers

To pass the DMA timer tests, the processor clocks in the test system must be synchronized in a multiprocessor system. While this should be true for systems running HALs shipped with Windows 2000, it may not be true for hardware running a custom HAL. The DMA timer tests use a PCI SCSI controller card using the Symbios 875, 876, or 22910 chipset as an external counter.

The HAL test driver for these cards (haltest.sys) must be installed manually using device manager.

Required Software

Windows 2000 Datacenter or Windows .NET Server 2003, Datacenter Edition

Note For a Windows 2000 Datacenter HAL HCT submission, use Windows 2000 Datacenter. For a Windows .NET Server 2003 HAL HCT submission, use Windows .NET Server 2003, Datacenter Edition.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-26.6 DMA Stress Test Description (HAL)

Overview

The DMA stress tests run each of DMA tests in a separate thread, alternating between different adapters and DMA modes (packet vs. scatter-gather). The test runs for several minutes and tests the ability of the HAL to queue requests for scatter gather and manage access to several adapters at once. Since each test thread has its own common buffer or "device memory," the tests should not interfere with each other.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Note: Tests can be run individually for debugging purposes, but the preferred method for running the HAL test kit is to run it with one command, as described above.

To run the DMA Stress tests:

haltest DMA STRESS

Required Hardware

See Required Hardware paragraph in TD-26.5 DMA Test Description (HAL)

Required Software

Windows 2000 Datacenter or Windows .NET Server 2003, Datacenter Edition

Note For a Windows 2000 Datacenter HAL HCT submission, use Windows 2000 Datacenter. For a Windows .NET Server 2003 HAL HCT submission, use Windows .NET Server 2003, Datacenter Edition.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


Chapter 27: Windows Sockets Direct Test Specification

Overview

A system area network (SAN) is a high-performance connection-oriented network that can link a cluster of computers. A SAN delivers high bandwidth (1 or greater Gbps) with low latency. Cable lengths between nodes on a SAN are limited to range from a few meters to a few kilometers.

Networking applications can benefit from using a SAN. However, because a SAN exposes a private network interface, most networking applications, which are written to use TCP/IP through Windows Sockets, cannot benefit from using a SAN unless they are modified to use the SAN interface. The Windows Sockets Direct (WSD) components shown in the following diagram allow applications to benefit from using a SAN, without modifying those applications. That is, Windows Sockets Direct allows applications to use a SAN transparently.

The following diagram shows the architecture required to support a SAN. The shaded areas represent components that a SAN NIC vendor supplies to enable use of a SAN.

Figure 27.1 SAN architecture

The following list defines the components in Figure 27.1.

Windows Sockets application

Application that interfaces with Windows Sockets for network services.

Windows Sockets

The Windows Sockets interface (Ws2_32.dll).

Windows Sockets SPI

The Windows Sockets service provider interface (SPI).

Windows Sockets switch

The Windows Sockets switch switches between use of the standard TCP/IP service provider and the WSD path.

TCP/IP service provider

A user-mode DLL and associated kernel-mode proxy driver that comprise the standard base Windows Sockets service provider for TCP/IP. The proxy driver exposes a TDI interface.

TCP/IP

The standard TCP/IP protocol driver.

SAN service provider

The user-mode DLL portion of the SAN service provider.

Proxy driver for a SAN service provider

The kernel-mode proxy driver of the SAN service provider.

NDIS miniport driver

The NDIS miniport driver that supports communication to the SAN NIC using the standard TCP/IP protocol driver.

SAN transport

A reliable transport service, which can be fully implemented in the NIC, fully implemented in software, or implemented in a combination of both hardware and software.

SAN NIC

The physical SAN network interface controller (NIC).

Test scope

Since WSD is limited to TCP socket connections made through Winsock API calls, the test effort for WSD focuses on ensuring parity between behavior over the ‘normal’ TCP/IP protocol path and the WSD path that goes over the WSD Vendor Components. This functionality and stress parity is necessary to achieve the WSD goal of providing seamless support for existing TCP/IP Winsock applications.

The test scope focuses on testing the WSD Vendor Components (WSD VC), which are comprised of the vendor’s WSD Service Provider (WSD SP), SAN Proxy Driver(s), and the associated vendor NDIS driver(s). However, these tests are not a substitute for testing any NDIS drivers that may be associated with a particular WSD SP. The vendor’s NDIS driver must be tested separately and must be able to pass all NDIS tests as well as the tests described in this document.


Reference Documents for WSD

Microsoft Windows Driver Development Kit

http://www.microsoft.com/ddk/

Windows 2000 DDK topics:
System Area Networks
Windows Sockets Direct section under System Area Networks
Windows Sockets Direct SPI Reference

Windows 2000 DDK header file:
Windows Sockets Direct header file: ws2san.h

Microsoft Windows Logo Program System and Device Requirements, Version 2.0

http://www.microsoft.com/hwdev/winlogo/
(listed as "WLP#" in these assertions)

For questions, please send email

saninfo@microsoft.com


Windows Sockets Direct Test Assertions

This section contains the detailed list of test assertions.

Windows Sockets Direct Application Compatibility Assertions

27.1.1 Windows Sockets Direct Vendor Components should allow all applications that work in an Ethernet environment to use SAN transparently.

Reference document: WLP# - A6.4.8; Windows DDK - "System Area Networks"
Test description: All Windows Sockets Direct Test Descriptions

27.1.2 All TCP traffic, destined for the local subnet, generated by an application using Winsock calls should go over the WSD Path.

Reference document: WLP# - A6.4.8; Windows DDK - "System Area Networks"
Test description: All Windows Sockets Direct Test Descriptions


Windows Sockets Direct SPI Assertions

Reference Document: Windows DDK - "Windows Sockets Direct SPI Reference"

Test description: Each of the following assertions is tested by a set of scripts listed under that assertion. Each script executes variations of a different Winsock API. The variations are generated by changing the parameter values that are passed to the API being tested, and changing the order in which the API being tested is called relative to the other APIs.

These scripts are executed as part of test: HAPI Functional tests. The scripts executed by this test are not limited to the ones listed below. The test executes many scripts that do not directly test the WSD SP and SAN Proxy driver(s), but may exercise the NDIS driver for the SAN card. For certification it is required that all scripts pass with a 100% pass rate.

Main Scripts: Set of scripts that are used to exercise the particular SPI being tested.

Related Scripts: Set of scripts that may not directly test the WSD SP and SAN Proxy driver(s), but do exercise the NDIS driver for the SAN card. For example, the scripts that use UDP for communication, do not go over the WSD path, instead they go over the regular TCP path and exercise the NDIS mini-port driver for the card.

27.2.1 The Windows Sockets Direct service provider must export the required set of SPI calls.

Main Scripts:

Almost all scripts cause the WSD switch to load the WSD SP. Whenever the WSD SP is loaded, the switch checks to make sure the WSD SP exports all required SPIs.

Reference document: WLP# - A6.4.8; Windows DDK - "Windows Sockets Direct SPI Reference"
Test description: TD-27.4 WSD VCs Functional tests

27.2.2 The Windows Sockets Direct service provider should implement WSPAccept() call as described in the DDK.

Main Scripts:

acceptt0.tst and acceptt1.tst (Variations of accept() call using stream sockets)

acceptn0.tst and acceptn1.tst (Variations of Nonblocking accept() call using stream sockets)

waceptt0.tst and waceptt1.tst (Variations of WSAAccept() call using stream sockets)

waceptn0.tst and waceptn1.tst (Variations of Nonblocking WSAAccept() call using stream sockets)

queue0.tst and queue1.tst (Variations to test listen backlog using stream sockets)

Related Scripts:

acceptu.tst (Variations of accept() using datagram sockets)

acceptun.tst (Variations of nonblocking accept() using datagram sockets)

acceptr.tst (Variations of nonblocking accept() using raw sockets)

Reference document: WLP# - A6.4.8; "Windows Sockets Direct SPI Reference"
Test description: TD-27.4 WSD VCs Functional tests

27.2.3 The Windows Sockets Direct service provider should implement WSPBind() call as described in the DDK.

Main Scripts:

bindt.tst (Variations of bind() call using stream sockets)

Related Scripts:

bindu.tst (Variations of bind() using datagram sockets)

bindr.tst (Variations of bind() using raw sockets)

Reference document: Windows DDK - "Windows Sockets Direct SPI Reference"
Test description: TD-27.4 WSD VCs Functional tests

27.2.4 The Windows Sockets direct service provider should implement WSPCleanup() call as described in the DDK.

Main Scripts:

start.tst (Variations of WSACleanup() call)

Related Scripts:

Almost all scripts exercise WSACleanup()

Reference document: Windows DDK - "Windows Sockets Direct SPI Reference"
Test description: TD-27.4 WSD VCs Functional tests

27.2.5 The Windows Sockets Direct service provider should implement WSPCloseSocket() call as described in the DDK.

Main Scripts:

closet0.tst and closet1.tst (Variations of closesocket() using stream sockets)

closemt0.tst and closemt1.tst (Multithreaded variations of closesocket() using stream sockets)

Related Scripts:

closeu0.tst and closeu1.tst (Variations of closesocket() using datagram sockets)

closer0.tst and closer1.tst (Variations of closesocket() using raw sockets)

shutt0.tst and shutt1.tst (Variations of shutdown() using stream sockets)

shutu0.tst and shutu1.tst (Variations of shutdown() using datagram sockets)

shutuc0.tst and shutuc1.tst (Variations of shutdown() using unconnected datagram sockets)

Reference document: WLP# - A6.4.8; Windows DDK - "Windows Sockets Direct SPI Reference"
Test description: TD-27.4 WSD VCs Functional tests

27.2.6 The Windows Sockets Direct service provider should implement WSPConnect() call as described in the DDK.

Main Scripts:

cont0.tst and cont1.tst (Variations of connect() call using unbound stream sockets)

contb0.tst and contb1.tst (Variations of connect() call using bound stream sockets)

connt0.tst and connt1.tst (Variations of nonblocking connect() using stream sockets)

wcontb0.tst and wcontb1.tst (Variations of WSAConnect() using stream sockets)

connex0.tst and connex1.tst (Variations of ConnectEx() call)

Related Scripts:

conu0.tst and conu1.tst (Variations of connect() using unbound datagram sockets)

conub0.tst and conub1.tst (Variations of connect() using bound datagram sockets)

conrb0.tst and conrb1.tst (Variations of connect() using bound raw sockets)

Almost all scripts exercise WSPConnect()

Reference document: WLP# - A6.4.8; Windows DDK - "Windows Sockets Direct SPI Reference"
Test description: TD-27.4 WSD VCs Functional tests

27.2.7 The Windows Sockets Direct service provider should implement WSPDuplicateSocket() call as described in the DDK.

Main Scripts:

Dupsrv.exe, Dupcli.exe and Duphlp.exe (variations of socket duplication using stream sockets)

Reference document: WLP# - A6.4.8; Windows DDK - "Windows Sockets Direct SPI Reference"
Test description: TD-27.4 WSD VCs Functional tests

27.2.8 The Windows Sockets Direct service provider should implement WSPEnumNetworkEvents() call as described in the DDK.

Main Scripts:

Wnetev0.tst and Wnetev1.tst (variations of WSAEnumNetworkEvents() call using stream sockets)

Related Scripts:

Almost all scripts exercise WSPEnumNetworkEvents()

Reference document: WLP# - A6.4.8; Windows DDK - "Windows Sockets Direct SPI Reference"
Test description: TD-27.4 WSD VCs Functional tests

27.2.9 The Windows Sockets Direct service provider should implement WSPEventSelect() call as described in the DDK.

Main Scripts:

Wnetev0.tst and Wnetev1.tst (variations of WSAEventSelect() call using stream sockets)

Related Scripts:

Almost all scripts make WSD switch exercise the Windows Sockets Direct service provider’s WSPEventSelect()

Reference document: WLP# - A6.4.8; Windows DDK - "Windows Sockets Direct SPI Reference"
Test description: TD-27.4 WSD VCs Functional tests

27.2.10 The Windows Sockets Direct service provider should implement WSPGetOverlappedResult() call as described in the DDK.

Main Scripts:

Wgetov0.tst and Wgetov1.tst (Variations of WSAGetOverlappedResult() call using stream sockets)

Related Scripts:

Almost all scripts make Winsock Direct switch exercise Winsock Direct provider’s WSPGetOverlappedResult()

Reference document: WLP# - A6.4.8; Windows DDK - "Windows Sockets Direct SPI Reference"
Test description: TD-27.4 WSD VCs Functional tests

27.2.11 The Windows Sockets Direct service provider should implement WSPGetQOSByName() call as described in the DDK.

Main Scripts:

Wgqos.tst (variations of WSPGetQOSByName() call using stream sockets)

Reference document: WLP# - A6.4.8; Windows DDK - "Windows Sockets Direct SPI Reference"
Test description: TD-27.4 WSD VCs Functional tests

27.2.12 The Windows Sockets Direct service provider should implement WSPGetSockOpt() call as described in the DDK.

Main Scripts:

Tcpgetoptt.tst (variations for getsockopt() call using stream sockets)

Related Scripts:

When the Windows Sockets Direct service provider is loaded by WSD switch, the switch calls provider’s WSPGetSockOpt() function to determine characteristics like SO_RDMA_THRESHOLD_SIZE and SO_MAX_RDMA_SIZE.

Reference document: WLP# - A6.4.8; Windows DDK - "Windows Sockets Direct SPI Reference"
Test description: TD-27.4 WSD VCs Functional tests

27.2.13 The Windows Sockets Direct service provider should implement WSPIoctl() call as described in the DDK.

Main Scripts:

ioctlt.tst (Variations of ioctlsocket() call using stream sockets)

wioctlt.tst (Variations for WSAIoctl() call using stream sockets)

Related Scripts:

When the Windows Sockets Direct service provider is loaded by WSD switch, the switch exercises provider’s WSPIoctl() function to get the list of addresses supported by the provider, the extension function pointers that a Windows Sockets Direct service provider can support.

Reference document: WLP# - A6.4.8; Windows DDK - "Windows Sockets Direct SPI Reference"
Test description: TD-27.4 WSD VCs Functional tests

27.2.14 The Windows Sockets Direct service provider should implement WSPListen() call as described in the DDK.

Main Scripts:

Listent0.tst listent1.tst (Variations of listen() call using stream sockets)

Queue0.tst Queue1.tst (Variations to test listen backlog)

Related Scripts:

Almost all server side scripts post listen() thus exercising provider’s WSPListen().

Reference document: WLP# - A6.4.8; Windows DDK - "Windows Sockets Direct SPI Reference"
Test description: TD-27.4 WSD VCs Functional tests

27.2.15 The Windows Sockets Direct service provider should implement WSPRecv() call as described in the DDK.

Main Scripts:

recvt0.tst recvt1.tst (Variations of blocking recv() call using stream sockets)

recvnt0.tst recvbt1.tst (Variations of nonblocking recv() call using stream sockets)

recvu0.tst recvu1.tst (Variations of blocking recv() call using datagram sockets)

recvr0.tst recvr1.tst (Variations of blocking recv() call using raw sockets)

wrecvt0.tst wrecvt1.tst (Variations of WSARrecv() call using stream sockets)

wrecvnt0.tst wrecvnt1.tst (Variations of nonblocking WSARrecv() call using stream sockets)

worecvt0.tst worecvt1.tst (Variations of overlapped WSARrecv() call using stream sockets)

Reference document: WLP# - A6.4.8; Windows DDK - "Windows Sockets Direct SPI Reference"
Test description: TD-27.4 WSD VCs Functional tests

27.2.16 The Windows Sockets Direct service provider should implement WSPSend() call as described in the DDK.

Main Scripts:

sendt0.tst sendt1.tst (Variations of send() call using stream sockets)

sendu0.tst sendu1.tst (Variations of send() call using datagram sockets)

sendr0.tst sendr1.tst (Variations of blocking send() call using raw sockets)

wsendt0.tst wsendt1.tst (Variations of WSASend() call using stream sockets)

wosendt0.tst wosendt1.tst (Variations of overlapped WSASend() call using stream sockets)

Reference document: WLP# - A6.4.8; Windows DDK - "Windows Sockets Direct SPI Reference"
Test description: TD-27.4 WSD VCs Functional tests

27.2.17 The Windows Sockets Direct service provider should implement WSPSetSockOpt() call as described in the DDK.

Main Scripts:

tcpsetoptt.tst (Variations of setsockopt() call using stream sockets)

Reference document: WLP# - A6.4.8; Windows DDK - "Windows Sockets Direct SPI Reference"
Test description: TD-27.4 WSD VCs Functional tests

27.2.18 The Windows Sockets Direct service provider should implement WSPSocket() call as described in the DDK.

Main Scripts:

All scripts. When a script opens a stream socket, it exercise provider’s WSPSocket()

Reference document: WLP# - A6.4.8; Windows DDK - "Windows Sockets Direct SPI Reference"
Test description: TD-27.4 WSD VCs Functional tests

27.2.19 The Windows Sockets Direct service provider should implement WSPStartupEx() call as described in the DDK.

Main Scripts:

All scripts. WSD switch calls WSPStartupEx() while loading the Windows Sockets Direct service provider.

Reference document: WLP# - A6.4.8; Windows DDK - "Windows Sockets Direct SPI Reference"
Test description: TD-27.4 WSD VCs Functional tests


Windows Sockets Direct Test Descriptions

This section contains the detailed test descriptions.

Required Testing Setup

The following tests require 2 server class machines. Each machine should have at least one SAN interface.

Each machine must have at least one Ethernet adapter, which is used for control message exchange between machines (Message Card) using NDIS Tester. The Ethernet adapters must also be on the same TCP/IP Subnet.

Note: The following tests have to be run each of the following configurations:

OS/WSD Vendor Component (VC) Type | Number of Processors
Free | 2 or more
Debug/Checked with driver verifier enabled on WSD VCs and selected Microsoft components. See below for more details on setting up the two systems for this configuration. | 2 or more

This is not a full debug/checked build of the OS. This is the base "free" system with a few selected Microsoft system debug binaries. You will need a debug/checked version of the OS on CD though in order to copy the files over.

If you are running a service pack build, you will need the debug binaries from the service pack as well. You may want to copy all the checked binaries to a single directory if the latest binaries are in separate locations.

To find out exactly what files are needed, open a command prompt and run:

<root>\wsdbin\CheckedPrep.vbs /?

  1. Run the GetBuildType.cmd in <root>\wsdbin dir. It should return

MP_Debug.

If not, do the following to copy the debug binaries and turn on driver verifier for required drivers:

a. <root>\wsdbin\disableSFP.vbs

b. reboot (must have kernel debugger attached)

c. <root>\wsdbin\CheckedPrep <src of debug binaries>

d. reboot again

  2. If GetBuildType returns MP_Debug, then make sure driver verifier is running on all the drivers list in CheckedPrep.vbs /?, as well as any vendor drivers. From a command prompt type verifier /query. It will return a list of drivers that are currently being verified. If all the required drivers are not listed, then do step 1 over again.

After any reboots, go through 1 & 2 again to ensure you have a debug system that is running the required drivers under driver verifier.

It should be noted that if your system is not in the right state, the tests will fail. For example if you have a MP_Debug system, but driver verifier hasn't been enabled, the tests will immediately fail.

Once in the "Free" or "Debug/Checked" state, do the following assuming that NDIS Tester and the WSD Test Kit has been installed on both Machine A and Machine B. Machine A will be the "client" and Machine B will be the "server". Client and Server here refer to the client and server modes of NDIS Tester. After installing, you will need to log off and back on again as administrator in order to setup certain privileges for some of the functional tests.

In order for the scripts to appear in the NDIS Tester harness, the following must be done:

On Server, logged on as Administrator:

  1. Launch NDIS Tester using wsdstart.cmd
  2. Select the "TESTS" tab
  3. Choose the Ethernet adapter from the "MESSAGE" drop down list
  4. Select the "SERVER" radio/option button
  5. Check "SERVERNAME: <IP AddressServer>" over <SAN Adapter> from the "SUPPORT DEVICES" list
  6. Click on "START…" button
  7. From command prompt, net use \\clientname\ipc$ /u:clientname\administrator "<PW>". This is necessary to be able to copy log files back and forth.

On Client, logged on as Administrator:

  1. Launch NDIS Tester using wsdstart.cmd
  2. Select the "TESTS" tab
  3. Choose the Ethernet adapter from the "MESSAGE" drop box
  4. Choose "<IP AddressClient>" over <SAN Adapter> from the "TEST" drop down list
  5. Check "SERVERNAME: <IP AddressServer>" over <SAN Adapter> from the "SUPPORT DEVICES" list
  6. From command prompt: net use \\servername\ipc$ /u:servername\administrator "<PW>". This is necessary to copy log files back and forth.

Note: At this point, all of the WinSock Direct tests will appear. The scripts names that appear will be referred to below. To run a script individually, one must select the "MANUAL TESTS" radio/option button, "CLEAR ALL" the tests, check the test to run and click "START…".

NDIS Tester provides a log file for each test run, which can be viewed. For WSD tests, the NDIS Tester log only says if there was an error, and not what the exact error is. To find out, open the log file, click on the failed variation links. If there was a problem running the script, there will be information on that, but if a test itself failed, after being successfully launched, scroll to the bottom of the log file and click on the link to the summary log file that failed. At this point you'll be looking at an NTLOG formatted log file. You will need to scroll down until you see a summary section such as this:

37C.6F4 : WSD_FAIL

37C.6F4 : NTLOG REPORT -------------------------------------------------------

37C.6F4 : Tests Total 0 | Variations Total 3

37C.6F4 : ------------------------------------------------------------------

37C.6F4 : Tests Passed 0 0% | Variations Passed 2 66%

37C.6F4 : Tests Warned 0 0% | Variations Warned 0 0%

37C.6F4 : Tests Failed sev3 0 0% | Variations Failed sev3 0 0%

37C.6F4 : Tests Failed sev2 0 0% | Variations Failed sev2 0 0%

37C.6F4 : Tests Failed sev1 0 0% | Variations Failed sev1 1 33%

37C.6F4 : Tests Blocked 0 0% | Variations Blocked 0 0%

37C.6F4 : Tests Aborted 0 0% | Variations Aborted 0 0%

37C.6F4 : --------------------------------------------------------------------

Above this, there may be links to even more detailed log files, including an indication as to whether failures exist in these log files, for example:

37C.6F4 : Attempted: 2 Failed: 1 \\WSDSAN\c$\ndt\wsdlogs\MP_Free\FinalLogs\HAPI_c.log.htm

37C.6F4 : Attempted: 1 Failed: 0

\\WSDSAN\C$\ndt\wsdlogs\MP_Free\FinalLogs\hapi_s.log

By following each of the failure links, you will get to the actual log file containing more detailed information on why a variation failed, for example:

37C.6F4 : LaunchIt v1.1.9 start logging

37C.6F4 : Launched: C:\ndt\wsdbin\x86\hapilog.exe hapi.sum

37C.6F4 : FAILED. Exit code of application was not 0. Code: 1

37C.6F4 : Exit code returned FAIL.

37C.6F4 : ####################################################################

37C.6F4 : BEGIN LOG FROM APPLICATION: hapi.sum

37C.6F4 : ####################################################################

37C.6F4 : Test Harness -- Variation Summary:

37C.6F4 : Testname Total Passed Failed Warned Vars Failed Machine Info

37C.6F4 : ---------- ----- ------ ------ ------ ----------- -------------

37C.6F4 : wjoint0 1 0 1 0 1 x86 WinNT 5.0.2195.Service Pack 2, TCP/IP

37C.6F4 : wjoint1 1 0 1 0 6 x86 WinNT 5.0.2195.Service Pack 2, TCP/IP

37C.6F4 : ---------- ------ ------ ------ ------

37C.6F4 : total 2 0 1 0

The log files are put into the <root>\wsdlogs\MP_Free or MP_Debug directory, which has the following structure:

FinalLogs contains the final merge log files for client and server logs.

NTLogs contains the individual NTLog formatted files for each test

IncludeLogs contains text formatted logs that are generated by specific test apps that are automatically included inside of NTLog formatted logs, but kept here for completeness.

HAPILogs\<platform> contains the individual log files for individual HAPI scripts, which are combined into a hapi.sum file, which is in turn included into an NTLog formatted file. See TD-27.4's Results Interpretation section for more details on HAPI logs.


TD-27.1 Basic Connectivity Test Description (wsdping)

Overview

This test assures basic connectivity between two machines over WSD Path. WSDPing client will connect to the server and send some data over the WSD path. Client then waits for replies from the server, if it is not able to establish connection over the WSD path or if replies from server are not received, the client side of wsdping.exe will fail. wsdping.exe uses the send()/recv() WinSock APIs to send and receive data. The server listens on the specified port, then creates a new thread for each connection that comes in which handles receiving the data from the client and echoing it back to the client, then terminating the thread. The client simply connections and then does a series of sends to the server, receives the echoed data, then repeats the process for the specified number of "pings."

Setup

Required Hardware

This test requires 2 server class machines. Each machine should have at least one SAN interface.

Each machine must have at least one Ethernet adapter, which is used for control message exchange between machines (Message Card) using NDIS Tester. The Ethernet adapters must also be on the same TCP/IP Subnet.

See required testing setup above.

Test Execution

To run this test individually, do the following from NDIS Tester:

On Client:

1. Select "MANUAL TESTS" radio/option button

2. Click on "CLEAR ALL" button

3. Check "wsdping_bascon.wsf" script

4. Click "START…" button

Expected execution time: 75 seconds.

Results Interpretation

Server and all clients should complete without any failures, in the expected execution time. For more details, NDIS Tester log "wsdping_bascon.htm" provides links to the following log files:

Final Log

FinalLogs\final_wsdping_bascon.log

Final Client Log

FinalLogs\wsdping_bascon_c.log

Final Server Log

FinalLogs\wsdping_bascon_s.log

Supporting Logs:

5 logs: NTLogs\wsdping_bascon_li_c_<client IP>_X.log, where X is 1-5

Individual pass/fail results with details will be in the supporting logs.

Exact Pass/Fail String:

WSD_PASS/WSD_FAIL in final log.


TD-27.2 Large Message Pings Test Description (wsdping)

Overview

Ten wsdping.exe clients connect and do 64K send()s to the wsdping.exe server. Clients then wait for replies from the server. If the connection cannot be established over WSD Path or a reply is not received from the server in the specified time, the clients log a failure in their specific log file.

Setup

Required Hardware

This test requires 2 server class machines. Each machine should have at least one SAN interface.

Each machine must have at least one Ethernet adapter, which is used for control message exchange between machines (Message Card) using NDIS Tester. The Ethernet adapters must also be on the same TCP/IP Subnet.

See required testing setup above.

Test Execution

To run this test individually, do the following from NDIS Tester:

On Client:

1. Select "MANUAL TESTS" radio/option button

2. Click on "CLEAR ALL" button

3. Check "wsdping_lmpingmm.wsf" script

4. Click "START…" button

Expected execution time: 20 minutes

Results Interpretation

Server and client should complete without any failures, in the expected execution time. or more details, NDIS Tester log "wsdping_lmpingmm.htm" provides links to the following log files:

Final Log

FinalLogs\final_wsdping_lmpingmm.log

Final Client Log

FinalLogs\wsdping_lmpingmm_c.log

Final Server Log

FinalLogs\wsdping_lmpingmm_s.log

Supporting Logs:

10 logs: NTLogs\wsdping_lmpingmm_li_c_<client IP>_X.log, where X is 1-10,

Individual pass/fail results with details will be in the supporting logs.

Exact Pass/Fail String:

WSD_PASS/WSD_FAIL in final log.


TD-27.3 Send Sizes and Data Verification Test Description (wsdping)

Overview

In this test, 48 wsdping.exe clients do send()s of different sizes, starting from 0 bytes going up to 65537 bytes. It also verifies that the data echoed back by the wsdping.exe server is the same as what was sent by the clients.

Setup

Required Hardware

This test requires 2 server class machines. Each machine should have at least one SAN interface.

Each machine must have at least one Ethernet adapter, which is used for control message exchange between machines (Message Card) using NDIS Tester. The Ethernet adapters must also be on the same TCP/IP Subnet.

See required testing setup above.

Test Execution

To run this test individually, do the following from NDIS Tester:

On Client:

1. Select "MANUAL TESTS" radio/option button

2. Click on "CLEAR ALL" button

3. Check "wsdping_incsizedv.wsf" script

4. Click "START…" button

Expected execution time: 75 seconds

Results Interpretation

Server and client should complete without any failures, in the expected execution time. For more details, NDIS Tester log "wsdping_ incsizedv.htm" provides links to the following log files:

Final Log

FinalLogs\final_wsdping_incsizedv.log

Final Client Log

FinalLogs\wsdping_incsizedv_c.log

Final Server Log

FinalLogs\wsdping_incsizedv_s.log

Supporting Logs:

48 logs: NTLogs\wsdping_incsizedv_li_c_<client IP>_X.log, where X is the byte size sent.

Individual pass/fail results with details will be in the supporting logs.

Exact Pass/Fail String:

WSD_PASS/WSD_FAIL in final log.


TD-27.4 WSD Service Provider Functional Tests (HAPI)

Overview

These tests are used to perform functional testing of WSD. These scripts test Winsock APIs to ensure all applications that use TCP/IP over Ethernet, work over WSD as well.

Setup

Required Hardware

This test requires 2 server class machines. Each machine should have at least one SAN interface.

Each machine must have at least one Ethernet adapter, which is used for control message exchange between machines (Message Card) using NDIS Tester. The Ethernet adapters must also be on the same TCP/IP Subnet.

See required testing setup above.

Test Execution

To run this test individually, do the following from NDIS Tester:

On Client:

1. Select "MANUAL TESTS" radio/option button

2. Click on "CLEAR ALL" button

3. Check "hapi.wsf" script

4. Click "START…" button:

Expected execution time: 120 minutes

Results Interpretation

Server and client should complete without any failures, in the expected execution time.

For more details, NDIS Tester log "hapi.htm" provides links to the following log files:

Final Log

FinalLogs\final_hapi.log

Final Client Log

FinalLogs\hapi_c.log

Final Server Log

FinalLogs\hapi_s.log

Supporting Logs:

NTLogs\hapi_li_c.log

NTLogs\hapi_hapilog_c.log

~267 logs: HAPILogs\<processor archictecture>\*.log

Individual pass/fail results with details will be in the supporting logs. Hapi_hapilog_c.log contains a summary of the tests, including failures. If a failure is logged for a test, for example, sendt1, then the detailed log file for that test is found in the HAPILogs directory, for example, HAPILogs\x86\sendt1.log..

Exact Pass/Fail String:

WSD_PASS/WSD_FAIL in final log.


TD-27.5 Latency Test Description (tping/tpong)

Overview

This test verifies that the latency over the WSD link is within acceptable limits. tping.exe connects to tpong.exe and does a small sized send(), and waits for the response from server. It repeats this until the time specified (in seconds) on the command line (with parameter –t) expires.

Setup

Required Hardware

This test requires 2 server class machines. Each machine should have at least one SAN interface.

Each machine must have at least one Ethernet adapter, which is used for control message exchange between machines (Message Card) using NDIS Tester. The Ethernet adapters must also be on the same TCP/IP Subnet.

See required testing setup above.

Test Execution

To run this test individually, do the following from NDIS Tester:

On Client:

1. Select "MANUAL TESTS" radio/option button

2. Click on "CLEAR ALL" button

3. Check "PingPong_Latency.wsf" script

4. Click "START…" button

Expected execution time: 5 minutes

Results Interpretation

Server and client should complete without any failures, in the expected execution time.

Average latency as reported by the client should be less than 250 microseconds.

For more details, NDIS Tester log "pingpong_latency.htm" provides links to the following log files:

Final Log

FinalLogs\final_pingpong_latency.log

Final Client Log

FinalLogs\pingpong_latency_c.log

Final Server Log

FinalLogs\pingpong_latency_s.log

Supporting Logs:

NTLogs\pingpong_latency_c_li.log

NTLogs\pingpong_latency_c_tping.log

Individual pass/fail results with details will be in the supporting logs. The pingpong_latency_c_tping.log file contains the actual latency recorded by the test..

Exact Pass/Fail String:

WSD_PASS/WSD_FAIL in final log.


TD-27.6 Data Verification Test Description (verisrv/vericli)

Overview

This test verifies that data transferred over WSD doesn’t get corrupted. verisrv.exe send()s out data to the vericli.exe, which does the verification of this data. The pattern sent as data is a 'long' counter, which is incremented and written in the send buffer, for each set of 32 bits of data being sent.

Setup

Required Hardware

This test requires 2 server class machines. Each machine should have at least one SAN interface.

Each machine must have at least one Ethernet adapter, which is used for control message exchange between machines (Message Card) using NDIS Tester. The Ethernet adapters must also be on the same TCP/IP Subnet.

See required testing setup above.

Test Execution

To run this test individually, do the following from NDIS Tester:

On Client:

1. Select "MANUAL TESTS" radio/option button

2. Click on "CLEAR ALL" button

3. Check "verif_dataverify.wsf" script

4. Click "START…" button

Expected execution time: 45 minutes

Results Interpretation

Server and client should complete without any failures, in the expected execution time.

For more details, NDIS Tester log "verif_dataverify.htm" provides links to the following log files:

Final Log

FinalLogs\final_verif_dataverify.log

Final Client Log

FinalLogs\verif_dataverify_c.log

Final Server Log

FinalLogs\verif_dataverify_s.log

Supporting Logs:

Same as final client/server logs.

Individual pass/fail results with details will be in the supporting logs..

Exact Pass/Fail String:

WSD_PASS/WSD_FAIL in final log.


TD-27.7 Data Verification Test Description (sockdie)

Overview

This test verifies that data transferred over WSD doesn’t get corrupted under high CPU usage conditions.

Setup

Required Hardware

This test requires 2 server class machines. Each machine should have at least one SAN interface.

Each machine must have at least one Ethernet adapter, which is used for control message exchange between machines (Message Card) using NDIS Tester. The Ethernet adapters must also be on the same TCP/IP Subnet.

See required testing setup above.

Test Execution

To run this test individually, do the following from NDIS Tester:

On Client:

1. Select "MANUAL TESTS" radio/option button

2. Click on "CLEAR ALL" button

3. Check "sockdie_dataverify.wsf" script

4. Click "START…" button

Expected execution time: 5 hours.

Results Interpretation

Server and client should complete without any failures, in the expected execution time.

For more details, NDIS Tester log "sockdie_dataverify.htm" provides links to the following log files:

Final Log

FinalLogs\final_sockdie_dataverify.log

Final Client Log

FinalLogs\sockdie_dataverify_c.log

Final Server Log

FinalLogs\sockdie_dataverify_s.log

Supporting Logs:

Same as final client/server logs.

Individual pass/fail results with details will be in the supporting logs.

Exact Pass/Fail String:

WSD_PASS/WSD_FAIL in final log.


TD-27.8 Small Message Throughput Test Description (sockdie)

Overview

The test verifies a basic level of performance over WSD when performing small size message transfers. The client tries to maintain a specified number (-c command line option) of connections to the server. The server services each request by sending a large number of small sized buffers to the client. This scenario represents a typical WSD deployment scenario where end nodes establish connections (generally with a relatively long connection lifetime) and exchange small sized messages. For example, web server-to-SQL database connectivity.

Setup

Required Hardware

This test requires 2 server class machines. Each machine should have at least one SAN interface.

Each machine must have at least one Ethernet adapter, which is used for control message exchange between machines (Message Card) using NDIS Tester. The Ethernet adapters must also be on the same TCP/IP Subnet.

See required testing setup above.

Test Execution

To run this test individually, do the following from NDIS Tester:

On Client:

1. Select "MANUAL TESTS" radio/option button

2. Click on "CLEAR ALL" button

3. Check "sockdie_smtput.wsf" script

4. Click "START…" button:

Expected execution time: 6 hours

Results Interpretation

Server and client should complete without any failures, in the expected execution time.

Average Throughput reported by the server at the end of a 6 hours run should be at least 25 Mbytes/Sec.

For more details, NDIS Tester log "sockdie_smtput.htm" provides links to the following log files:

Final Log

FinalLogs\final_sockdie_smtput.log

Final Client Log

FinalLogs\sockdie_smtput_c.log

Final Server Log

FinalLogs\sockdie_smtput_s.log

Supporting Logs:

NTLogs\sockdie_smtput_s_li.log

NTLogs\sockdie_smtput_s_stresspr.log

Individual pass/fail results with details will be in the supporting logs. The sockdie_smtput_s_stresspr.log file contains the throughput results recorded by the test.

Exact Pass/Fail String:

WSD_PASS/WSD_FAIL in final log.


TD-27.9 Large Message Throughput Test Description (sockdie)

Overview

The test verifies a basic level of performance over WSD when performing large size message transfers. The client tries to maintain a specified number of connections to the server. The server services each request by sending a large number of large sized buffers to the client. This scenario causes the WSD to use RDMA capabilities of the SAN card.

Setup

Required Hardware

This test requires 2 server class machines. Each machine should have at least one SAN interface.

Each machine must have at least one Ethernet adapter, which is used for control message exchange between machines (Message Card) using NDIS Tester. The Ethernet adapters must also be on the same TCP/IP Subnet.

See required testing setup above.

Test Execution

To run this test individually, do the following from NDIS Tester:

On Client:

1. Select "MANUAL TESTS" radio/option button

2. Click on "CLEAR ALL" button

3. Check "sockdie_lmtput.wsf" script

4. Click "START…" button

Expected execution time: 6 hours.

Results Interpretation

Server and client should complete without any failures, in the expected execution time.

Average Throughput reported by the server at the end of a 6 hours run should be at least 80 Mbytes/Sec.

For more details, NDIS Tester log "sockdie_lmtput.htm" provides links to the following log files:

Final Log

FinalLogs\final_sockdie_lmtput.log

Final Client Log

FinalLogs\sockdie_lmtput_c.log

Final Server Log

FinalLogs\sockdie_lmtput_s.log

Supporting Logs:

NTLogs\sockdie_lmtput_s_li.log

NTLogs\sockdie_lmtput_s_stresspr.log

Individual pass/fail results with details will be in the supporting logs. The sockdie_lmtput_s_stresspr.log file contains the throughput results recorded by the test.

Exact Pass/Fail String:

WSD_PASS/WSD_FAIL in final log.


TD-27.10 Maximum Connections Per Second Test Description (sockdie)

Overview

The test verifies a basic level of performance (measured in terms of connections per second) over WSD when client creates very short-lived connections with the server.

Setup

Required Hardware

This test requires 2 server class machines. Each machine should have at least one SAN interface.

Each machine must have at least one Ethernet adapter, which is used for control message exchange between machines (Message Card) using NDIS Tester. The Ethernet adapters must also be on the same TCP/IP Subnet.

See required testing setup above.

Test Execution

To run this test individually, do the following from NDIS Tester:

On Client:

1. Select "MANUAL TESTS" radio/option button

2. Click on "CLEAR ALL" button

3. Check "sockdie_maxcps.wsf" script

4. Click "START…" button

Expected execution time: 6 hours.

Results Interpretation

Server and client should complete without any failures, in the expected execution time.

Average Connections/Sec as reported by the server at the end of the test run should be at least 50 Connections/Sec.

For more details, NDIS Tester log "sockdie_maxcps.htm" provides links to the following log files:

Final Log

FinalLogs\final_sockdie_maxcps.log

Final Client Log

FinalLogs\sockdie_maxcps c.log

Final Server Log

FinalLogs\sockdie_maxcps s.log

Supporting Logs:

NTLogs\sockdie_maxcps s_li.log

NTLogs\sockdie_maxcps s_stresspr.log

Individual pass/fail results with details will be in the supporting logs. The sockdie_maxcps_s_stresspr.log file contains the throughput results recorded by the test.

Exact Pass/Fail String:

WSD_PASS/WSD_FAIL in final log.


TD-27.11 Transmit File Stress with Socket Reuse Test Description (sockdie)

Overview

The server uses TransmitFile() with TF_REUSE_SOCKET to send data

Setup

Required Hardware

This test requires 2 server class machines. Each machine should have at least one SAN interface.

Each machine must have at least one Ethernet adapter, which is used for control message exchange between machines (Message Card) using NDIS Tester. The Ethernet adapters must also be on the same TCP/IP Subnet.

See required testing setup above.

Test Execution

To run this test individually, do the following from NDIS Tester:

On Client:

1. Select "MANUAL TESTS" radio/option button

2. Click on "CLEAR ALL" button

3. Check "sockdie_txfile.wsf" script

4. Click "START…" button

Expected execution time: 6 hours.

Results Interpretation

Server and client should complete without any failures, in the expected execution time.

For more details, NDIS Tester log "sockdie_txfile.htm" provides links to the following log files:

Final Log

FinalLogs\final_sockdie_txfile.log

Final Client Log

FinalLogs\sockdie_txfile_c.log

Final Server Log

FinalLogs\sockdie_txfile_s.log

Supporting Logs:

Same as final client/server logs.

Individual pass/fail results with details will be in the supporting logs.

Exact Pass/Fail String:

WSD_PASS/WSD_FAIL in final log.


TD-27.12 Nonblocking Winsock API Stress Test Description (nblocks/sockdiec)

Overview

This test stresses the nonblocking Winsock calls like select, nonblocking send() and recv(). The server has a master thread which is responsible for accept()ing the incoming connections, and then assigning these connections to the worker threads. Worker threads send a user-specified amount of data back to the client.

Setup

Required Hardware

This test requires 2 server class machines. Each machine should have at least one SAN interface.

Each machine must have at least one Ethernet adapter, which is used for control message exchange between machines (Message Card) using NDIS Tester. The Ethernet adapters must also be on the same TCP/IP Subnet.

See required testing setup above.

Test Execution

To run this test individually, do the following from NDIS Tester:

On Client:

1. Select "MANUAL TESTS" radio/option button

2. Click on "CLEAR ALL" button

3. Check "nonblocking.wsf" script

4. Click "START…" button:

Expected execution time: 6 hours

Results Interpretation

Server and client should complete without any failures, in the expected execution time.

For more details, NDIS Tester log "nonblocking.htm" provides links to the following log files:

Final Log

FinalLogs\final_nonblocking.log

Final Client Log

FinalLogs\sockdie_nonblocking_c.log

Final Server Log

FinalLogs\nblocks_nonblocking_s.log

Supporting Logs:

Same as final client/server logs.

Individual pass/fail results with details will be in the supporting logs.

Exact Pass/Fail String:

WSD_PASS/WSD_FAIL in final log.


TD-27.13 Socket Duplication Stress Test Description (wsclonec/sockdies)

Overview

This test stresses the socket duplication code paths of the WSD Vendor Components. The client side (wsclonec.exe) starts a controller thread for each connection that is to be established with the server. Each of these controller threads accepts a connection, then launches 4 child processes (cchild.exe), and duplicates the connected socket to each of the child processes. All child processes simultaneously post recv()s on the duplicated socket to receive the data being sent by the server.

Setup

Required Hardware

This test requires 2 server class machines. Each machine should have at least one SAN interface.

Each machine must have at least one Ethernet adapter, which is used for control message exchange between machines (Message Card) using NDIS Tester. The Ethernet adapters must also be on the same TCP/IP Subnet.

See required testing setup above.

Test Execution

To run this test individually, do the following from NDIS Tester:

On Client:

1. Select "MANUAL TESTS" radio/option button

2. Click on "CLEAR ALL" button

3. Check "duplication.wsf" script

4. Click "START…" button

Expected execution time: 6 hours.

Results Interpretation

Server and client should complete without any failures, in the expected execution time.

For more details, NDIS Tester log "duplication.htm" provides links to the following log files:

Final Log

FinalLogs\final_duplication.log

Final Client Log

FinalLogs\wsclonec_duplication_c.log

Final Server Log

FinalLogs\sockdie_duplication_s.log

Supporting Logs:

Same as final client/server logs.

Individual pass/fail results with details will be in the supporting logs.

Exact Pass/Fail String:

WSD_PASS/WSD_FAIL in final log.


Chapter 28: Storage Test Specification

Overview

This chapter describes storage device tests for requirements defined in Microsoft Windows Logo Program System and Device Requirements.

This chapter is intended as an overview of tests for OEMs and IHVs, and as a guide to actual test development for software engineers. It is not designed to provide a complete test plan or testing procedure for storage subsystems or storage drivers.

The Storage Test Specification is divided into two main sections. The first covers test coverage, functional requirements, and test assertions; the second covers the actual test implementations. Legacy tests are not covered in depth in this document.


Storage Test Assertions

This section contains the detailed list of test assertions for storage devices and drivers.


Reference Documents for Storage Test Assertions

Functional requirements specified in the following documents:

ATA/ATAPI-5

ATA standards: Global Engineering Documents at http://global.ihs.com/

Microsoft Windows Logo Program System and Device Requirements, Version 2.0

http://www.microsoft.com/hwdev/winlogo/
(listed as "WLP#" in these assertions)

Microsoft Windows Driver Development Kit

http://www.microsoft.com/ddk/

MMC-2 - Multi-Media Command Set-2

Global Engineering Documents at http://global.ihs.com/
(incorporates information defined in Enhanced Music CD Specification)

NCITS Serial Bus Protocol-2 (SBP-2) transport protocols (ANSI NCITS 3.25-1998)

Global Engineering Documents at http://global.ihs.com/

PC 2001 System Design Guide and PC 99 System Design Guide

http://www.microsoft.com/hwdev/platform/pcdesign/desguide/pcguides.asp

Small Computer Interface (SCSI-2)

[X3.131:1994] standard
Global Engineering Documents at http://global.ihs.com/


DMA Test Assertions

Assertions in this section are tested in the TD-28.1 DMA test.

28.1.1 Validate that PIO modes are followed by the spec.

If PIO mode 1 is supported PIO mode 0 shall also be supported. Verify that this is true.

Reference document: WLP# - B10.1.4.6; PC 2001 - STOR-0341; SDG3:146; ATA/ATAPI-5 Spec T13 1321D Rev 1b, Section 8.37.10, Page 167-168
Test description: TD-28.1 DMA Test

28.1.2 Validate that SW DMA modes are followed by the spec.

If SW DMA mode 1 is supported SW DMA mode 0 shall also be supported. Currently these are not set and are reserved in ATA/ATAPI-4 to 5.

Reference document: WLP# - B10.1.4.6; PC 2001 - STOR-0341; SDG3:146; ATA/ATAPI-4 to 5
Test description: TD-28.1 DMA Test

28.1.3 Validate that MW DMA modes are followed by the spec.

If MW DMA mode 1 is supported MW DMA mode 0 shall also be supported. Verify that this is true.

Reference document: WLP# - B10.1.4.6; PC 2001 - STOR-0341; SDG3:146; ATA/ATAPI-5 Spec T13 1321D Rev 1b, Section 8.37.10, Page 167-168
Test description: TD-28.1 DMA Test

28.1.4 Validate that Ultra DMA modes are followed by the spec.

If Ultra DMA mode 1 is supported Ultra DMA mode 0 shall also be supported. Verify that this is true.

Reference document: WLP# - B10.1.4.6; PC 2001 - STOR-0341; SDG3:146; ATA/ATAPI-5 Spec T13 1321D Rev 1b, Section 8.37.10, Page 167-168
Test description: TD-28.1 DMA Test


Hard Disk Drive Manual Assertions

Assertions in this section are tested in TD-28.3 Hard Disk Drive Manual Test Checklist Test Description.

28.3.1 Hard disk supports partitions larger than 8 GB

Reference document: WLP#- B10.4.4.2; SDG3:224
Test description: TD-28.3 Hard Disk Drive Manual Test Checklist Test Description

28.3.2 Hard disk can boot from OS loader

Reference document: WLP#- B10.4.4.2; SDG3:224
Test description: TD-28.3 Hard Disk Drive Manual Test Checklist Test Description


CD/DVD Drives - Manual Assertions

Assertions in this section are tested in TD-28.4 CD/DVD Driver Manual Test Checklist.

28.4.1 Moved - see 1.36.1
28.4.1.1 CD-enhanced compatible

Reference document: WLP Requirements - B10.5.4.2.2; PC 2001 STOR-0352; SDG3:186
Test description: TD-28.4 CD/DVD Driver Manual Test Checklist

28.4.1.2 Supports specified logical and physical CD formats

Reference document: WLP Requirements - B10.5.4.2.3; STOR-0353; STOR-0355; SDG3:187
Test description: TD-28.4 CD/DVD Driver Manual Test Checklist

28.4.1.3 Supports the READ CD-DA command as defined in the MMC-2 standard

Reference document: WLP Requirements - B10.5.4.2.4; STOR-354; SDG3:188
Test description: TD-28.4 CD/DVD Driver Manual Test Checklist

28.4.1.4 Supports digital audio detection and digital audio quality on CD-ROM drive

Reference document: WLP Requirements - B10.5.4.2.5; STOR-0357
Test description: TD-28.4 CD/DVD Driver Manual Test Checklist

28.4.2 - 28.4.5 Moved - see 1.36.2 - 1.36.5


Tape Drive Manual Assertions

See Chapter 1, "Tape Drive Ease-of-Use/Manual Assertions"


Media Changer Devices Manual Assertions

See Chapter 1, "Media Changer Devices Ease-of-Use/Manual Assertions"


RAID Manual Test Assertions

See Chapter 1, "RAID Ease-of-Use/Manual Assertions"


Network Storage Device Manual Test Assertions

Assertions in this section are tested in TD-28.8 Network Storage Manual Test Checklist Test Description.

28.8.1 Driver with special parameters includes Help file that is installed as part of the driver installation routine.

Reference document: WLP#- WL-4; B1.4.7; B7.1.4.1
Test description: TD-28.8 Network Storage Manual Test Checklist Test Description

28.8.2 If the device's Properties dialog box includes an Advanced tab, all INF strings displayed are spelled correctly.

Reference document: WLP#- WL-4; B1.1.1; B7.1.4.2
Test description: TD-28.8 Network Storage Manual Test Checklist Test Description

28.8.3 Any diagnostics or utilities included with the device works correctly

Reference document: WLP#- WL-4; B1.1.1; B7.1.4.2
Test description: TD-28.8 Network Storage Manual Test Checklist Test Description

28.8.4 DELETED
28.8.5 DELETED
28.8.6 Device with USB, IEEE 1394, or PC Card external connectivity capabilities correctly supports hot plugging or unplugging per its bus class

Reference document: WLP#- SYS–0030
Test description: TD-1.1 Windows Experience Checklist


CD-R/CD-RW Functionality Test Assertions

Assertions in this section are tested in the TD-28.9 CD-R/CD-RW Functionality Test.

28.9.1 CD-R and CD-RW Drivers must have Feature 0001h: Core

TEST UNIT READY: Insert a medium. Query its type and flag.

Reference document: WLP# - B10.5.1, B10.5.2.1; SFF 8090 (Mt. Fuji) specification, page 225 to 261; SFF 8090 (Mt. Fuji) v5 MMC specification, page 202
Test description: TD-28.9 CD-R/CD-RW Functionality Test

28.9.2 CD-R and CD-RW Drivers must have Feature 0002h: Morphing.

PREVENT/ALLOW MEDIUM REMOVAL: Press "eject" button when recording. It shall not eject.

GET EVENT/STATUS NOTIFICATION: PnP scenario shall be correctly implemented. For example, it shall return IMAPI_E_DEVICE_NOTPRESENT for a removed active recorder. Block/Track/Burn complete notification shall be detected while burning the audio CD.

Reference document: WLP# - B10.5.1, B10.5.2.1; SFF 8090 (Mt. Fuji) specification, page 225 to 261; SFF 8090 (Mt. Fuji) v5 MMC specification, page 202
Test description: TD-28.9 CD-R/CD-RW Functionality Test

28.9.3 CD-R and CD-RW Drivers must have Feature 0003h: Removable Medium.

START/STOP UNIT:

For STOP UNIT, issue IOCTL to eject CD tray.

For START UNIT, put a data CD in the CD tray, (automatically) load CD tray, and find the first file/directory in the CD.

Reference document: WLP# - B10.5.1, B10.5.2.1; SFF 8090 (Mt. Fuji) specification, page 225 to 261; SFF 8090 (Mt. Fuji) v5 MMC specification, page 202
Test description: TD-28.9 CD-R/CD-RW Functionality Test

28.9.4 CD-R and CD-RW Drivers must have Feature 0010h: Random Readable, PP=1

READ (random): Read random files in a data CD-R(W).

READ CAPACITY: Get used, available data block counts in CD-R(W). Logical data block size shall be equal to the value returned by GetDataBlockSize().

Read/Write Error Recovery: Damage a small area in the beginning of a blank medium on purpose and see if the medium is still usable.

Reference document: WLP# - B10.5.1, B10.5.2.1; SFF 8090 (Mt. Fuji) specification, page 225 to 261; SFF 8090 (Mt. Fuji) v5 MMC specification, page 202
Test description: TD-28.9 CD-R/CD-RW Functionality Test

28.9.5 CD-R and CD-RW Drivers must have Feature 001Dh: MultiRead

"LU (logical unit) shall read all CD media types": Ask to insert different media. Do QueryMediaType and ask users to verify the media type.

For CD-R drive, it shall be able to read CD-ROM and CD-R types of media. For CD-RW drive, it shall be able to read CD-ROM, CD-R, and CD-RW types of media.

Reference document: WLP# - B10.5.1, B10.5.2.1; SFF 8090 (Mt. Fuji) specification, page 225 to 261; SFF 8090 (Mt. Fuji) v5 MMC specification, page 202
Test description: TD-28.9 CD-R/CD-RW Functionality Test

28.9.6 CD-R and CD-RW Drivers must have Feature 001Eh: CD Read

"LU shall be capable of reading CD media, e.g. CD-ROM, CD-R and CD-RW": Create the following six media: data CD-ROM, data CD-R, data CD-RW, audio CD-ROM, audio CD-R, and audio CD-RW. See if data can be read from explorer, and audio (CDDA) can be read from media player.

For CD-R drive, it shall be able to read CD-ROM and CD-R types of media. For CD-RW drive, it shall be able to read CD-ROM, CD-R, and CD-RW types of media.

Reference document: WLP# - B10.5.1, B10.5.2.1; SFF 8090 (Mt. Fuji) specification, page 225 to 261; SFF 8090 (Mt. Fuji) v5 MMC specification, page 202
Test description: TD-28.9 CD-R/CD-RW Functionality Test

28.9.7 CD-R and CD-RW Drivers must have Feature 0021h: Incremental Streaming Writable

"LU can write data to a contiguous region, and can append data to a limited number of locations on the media":

(1) Write data to a CD-R(W);

(1) Append data to the same CD-R(W), i.e. Multi-session data recording.

Reference document: WLP# - B10.5.1, B10.5.2.1; SFF 8090 (Mt. Fuji) specification, page 225 to 261; SFF 8090 (Mt. Fuji) v5 MMC specification, page 202
Test description: TD-28.9 CD-R/CD-RW Functionality Test

28.9.8 CD-RW Driver must have Feature 0023h: Formattable

FORMAT UNIT: Erase a CD-RW.

Reference document: WLP# - B10.5.1, B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification, page 202
Test description: TD-28.9 CD-R/CD-RW Functionality Test

28.9.9 CD-RW Driver must have Feature 0026h: Restricted Overwrite

Not tested

Reference document: WLP# - B10.5.1, B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification, page 202
Test description: TD-28.9 CD-R/CD-RW Functionality Test

28.9.10 CD-R and CD-RW Drivers must have Feature 002Dh: CD Track at Once

"Support for sequential Track at Once recording to write-once or rewritable media": Audio recording for multiple tracks.

Reference document: WLP# - B10.5.1, B10.5.2.1; SFF 8090 (Mt. Fuji) specification, page 225 to 261; SFF 8090 (Mt. Fuji) v5 MMC specification, page 202
Test description: TD-28.9 CD-R/CD-RW Functionality Test

28.9.11 CD-R and CD-RW Drivers must have Feature 0105h: Time-out

"LU always responds to Commands within a set time period. If a command cannot complete normally within the allotted time, it completes with an error": Try to erase a CD-ROM. It shall return an error.

Reference document: WLP# - B10.5.1, B10.5.2.1; SFF 8090 (Mt. Fuji) specification, page 225 to 261; SFF 8090 (Mt. Fuji) v5 MMC specification, page 202
Test description: TD-28.9 CD-R/CD-RW Functionality Test

28.9.12 CD-R and CD-RW Drivers must have Feature 0107h: Real-Time Streaming

"A host may request a lower rate than the Logical Unit's maximum to identify a need for a continuous stream of data": Record data at 1x speed.

Reference document: WLP# - B10.5.1, B10.5.2.1; SFF 8090 (Mt. Fuji) specification, page 225 to 261; SFF 8090 (Mt. Fuji) v5 MMC specification, page 202
Test description: TD-28.9 CD-R/CD-RW Functionality Test


Crashdump Test Assertions

Assertions in this section are tested in the TD-28.11 Crashdump Test

28.11.1 INACCESSIBLE_BOOT_DEVICE

Full Memory Dump:

1.1 Pre-crash and crashdump file devnode count must match.
1.2 Bugcheck code and user parameter must match.
Verify Advanced RISC Computing specification name for the device.
1.3 All loaded drivers should be written to dump file.
1.4 Verify processes and all children threads.
1.5 CPU vendors info must match. Verify threads running on all CPUs.
1.6 Dump file size must be greater than physical memory size.
1.7 Verify memusage summary info.
1.8 Verify virtual memory summary info.
1.9 Verify resource locks summary info.

Reference document: WLP# - B10.1.1; Windows 2000 DDK
Test description: TD-28.11 Crashdump Test Description

28.11.2 INACCESSIBLE_BOOT_DEVICE

Kernel Memory Dump

2.1 Pre-crash and crashdump file devnode count must match.
2.2 Bugcheck code and user parameter must match.
2.3 All loaded drivers should be written to dump file.
2.4 Verify processes and all children threads.
2.5 CPU vendors info must match. Verify threads running on all CPUs.
2.6 Dump file size must be 1/3 (relative) of physical memory size.
2.7 Verify memusage summary info.
2.8 Verify virtual memory summary info.
2.9 Verify resource locks summary info.

Reference document: WLP# - B10.1.1; Windows 2000 DDK
Test description: TD-28.11 Crashdump Test Description

28.11.3 INACCESSIBLE_BOOT_DEVICE

Mini Memory Dump

3.1 Bugcheck code and user parameter must match.
3.2 Dump file size must be 64KB.

Reference document: WLP# - B10.1.1; Windows 2000 DDK
Test description: TD-28.11 Crashdump Test Description

28.11.4 KMODE_EXCEPTION_NOT_HANDLED

Full Memory Dump:

4.1 Pre-crash and crashdump file devnode count must match.
4.2 Bugcheck code and user parameter must match.
Verify Advanced RISC Computing specification name for the device.
4.3 All loaded drivers should be written to dump file.
4.4 Verify processes and all children threads.
4.5 CPU vendors info must match. Verify threads running on all CPUs.
4.6 Dump file size must be greater than physical memory size.
4.7 Verify memusage summary info.
4.8 Verify virtual memory summary info.
4.9 Verify resource locks summary info.

Reference document: WLP# - B10.1.1; Windows 2000 DDK
Test description: TD-28.11 Crashdump Test Description

28.11.5 KMODE_EXCEPTION_NOT_HANDLED

Kernel Memory Dump

5.1 Pre-crash and crashdump file devnode count must match.
5.2 Bugcheck code and user parameter must match.
5.3 All loaded drivers should be written to dump file.
5.4 Verify processes and all children threads.
5.5 CPU vendors info must match. Verify threads running on all CPUs.
5.6 Dump file size must be 1/3 (relative) of physical memory size.
5.7 Verify memusage summary info.
5.8 Verify virtual memory summary info.
5.9 Verify resource locks summary info.

Reference document: WLP# - B10.1.1; Windows 2000 DDK
Test description: TD-28.11 Crashdump Test Description

28.11.6 KMODE_EXCEPTION_NOT_HANDLED

Mini Memory Dump

6.1 Bugcheck code and user parameter must match.
6.2 Dump file size must be 64KB.

Reference document: WLP# - B10.1.1; Windows 2000 DDK
Test description: TD-28.11 Crashdump Test Description

28.11.7 DATA_BUS_ERROR

Full Memory Dump:

7.1 Pre-crash and crashdump file devnode count must match.
7.2 Bugcheck code and user parameter must match.
Verify Advanced RISC Computing specification name for the device.
7.3 All loaded drivers should be written to dump file.
7.4 Verify processes and all children threads.
7.5 CPU vendors info must match. Verify threads running on all CPUs.
7.6 Dump file size must be greater than physical memory size.
7.7 Verify memusage summary info.
7.8 Verify virtual memory summary info.
7.9 Verify resource locks summary info.

Reference document: WLP# - B10.1.1; Windows 2000 DDK
Test description: TD-28.11 Crashdump Test Description

28.11.8 DATA_BUS_ERROR

Kernel Memory Dump

8.1 Pre-crash and crashdump file devnode count must match.
8.2 Bugcheck code and user parameter must match.
8.3 All loaded drivers should be written to dump file.
8.4 Verify processes and all children threads.
8.5 CPU vendors info must match. Verify threads running on all CPUs.
8.6 Dump file size must be 1/3 (relative) of physical memory size.
8.7 Verify memusage summary info.
8.8 Verify virtual memory summary info.
8.9 Verify resource locks summary info.

Reference document: WLP# - B10.1.1; Windows 2000 DDK
Test description: TD-28.11 Crashdump Test Description

28.11.9 DATA_BUS_ERROR

Mini Memory Dump

9.1 Bugcheck code and user parameter must match.
9.2 Dump file size must be 64KB.

Reference document: WLP# - B10.1.1; Windows 2000 DDK
Test description: TD-28.11 Crashdump Test Description

28.11.10 IOCTL_BUGCHECK_CUSTOM

Full Memory Dump:

10.1 Pre-crash and crashdump file devnode count must match.
10.2 Bugcheck code and user parameter must match.
Verify Advanced RISC Computing specification name for the device.
10.3 All loaded drivers should be written to dump file.
10.4 Verify processes and all children threads.
10.5 CPU vendors info must match. Verify threads running on all CPUs.
10.6 Dump file size must be greater than physical memory size.
10.7 Verify memusage summary info.
10.8 Verify virtual memory summary info.
10.9 Verify resource locks summary info.

Reference document: WLP# - B10.1.1; Windows 2000 DDK
Test description: TD-28.11 Crashdump Test Description

28.11.11 IOCTL_BUGCHECK_CUSTOM

Kernel Memory Dump

11.1 Pre-crash and crashdump file devnode count must match.
11.2 Bugcheck code and user parameter must match.
11.3 All loaded drivers should be written to dump file.
11.4 Verify processes and all children threads.
11.5 CPU vendors info must match. Verify threads running on all CPUs.
11.6 Dump file size must be 1/3 (relative) of physical memory size.
11.7 Verify memusage summary info.
11.8 Verify virtual memory summary info.
11.9 Verify resource locks summary info.

Reference document: WLP# - B10.1.1; Windows 2000 DDK
Test description: TD-28.11 Crashdump Test Description

28.11.12 IOCTL_BUGCHECK_CUSTOM

Mini Memory Dump

12.1 Bugcheck code and user parameter must match.
12.2 Dump file size must be 64KB.

Reference document: WLP# - B10.1.1; Windows 2000 DDK
Test description: TD-28.11 Crashdump Test Description


Red Book Test Assertions

Assertions in this section are tested in TD-28.12 Red Book Test Description

28.12.1 Sector accurate reads

RawTrackAlignment Routine Description:

This function will test the drives ability to seek tracks. This will read a sector from each track on the CD and store the contents of each sector. Then this will do enough reads to clear out the buffer in the CDROM. Once the buffer is cleared this will go through again to each track and read a sector and compare it to the first run.

Arguments:

ThreadD = Thread Data.

pvTracks = Used to track the results.

Return Value:

EXIT_SYSTEM = Tells the test to exit.

STATUS_SUCCESS = Success

Reference document: WLP# - B10.5.4.2
Test description: TD-28.12 Red Book Test Description

28.12.2 Sector reads

Sector reads 1 Block Size:

Reference document: WLP# - B10.5.4.2
Test description: TD-28.12 Red Book Test Description

28.12.3 Device should report mode page 2A

Device should report CDDA commands as supported

Device should report CDDA streaming as accurate

Device should not report block descriptor in the header

Reference document: WLP# - B10.5.4.2; Red Book
Test description: TD-28.12 Red Book Test Description


MMC Command Test Assertions

Assertions in this section are tested in TD-28.13 MMC Command Description.

28.13.1 The logical unit must be able to erase the entire disk, if erasable: BLANK.1

Send this command with the Blanking type code Blank the Entire disk with immediate bit one, with LBA value 0x0000.

Test the unit if it is in busy state (sense key/asc/ascq = 02/04/*), using TEST_UNIT_READY command.

Wait until the disk is erased (maximum time limit is 60 minutes).

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.2 The logical unit must be able to close the track specified in CDB: CLOSETRCK.1

Send the command with session bit set to zero, track bit set to one and Track/Rzone number set to one, this should close the track number in CDB (0x01).

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.3 The logical unit must be able to close the disk: CLOSESESSION.1

Then send the command with session bit set to one, track bit set to zero and Track/Rzone number set to zero, should close the session (disk). If not all tracks in the last session are complete; generate a CHECK CONDITION Status, sense code of SESSION FIXATION ERROR- INCOMPLETE TRACK IN SESSION.

Test the unit if it is in busy state (sense key/asc/ascq = 02/04/ *), using TEST_UNIT_READY command

Wait until the disk is closed (maximum time limit is 60 minutes)

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.4 The logical unit must be able to format the media: FORMAT.1

Send down the format command as:

  • CmpList – set to one
  • Parameter header as ( 4 bytes in order)
    0x00 – Reserved1
    0x86 – Second byte
    0x00 – Reserved2
    0x00 – Reserved3
  • Formattable capacity descriptor

Test if the logical Unit is in busy state (sense key/asc/ascq = 02/04/*) using TEST_UNIT_READY Command.

Wait for the format complete (Maximum Time is 180 minutes).

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.5 The logical unit must be able to return the nominal performance for reading: GETPERFORMANCE.1

Send the command with Data Type filed set to 0x10,Type field set to 0x00,LBA set to 0x0000,and Maximum number of descriptor field set to 0x01.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.6 The logical unit must be able to return the nominal performance for writing: GETPERFORMANCE.2

Send the command with Data Type filed set to 0x14,Type field set to 0x00,LBA set to 0x0000,and Maximum number of descriptor field set to 0x01.

Test for Start LBA field equal to 0x0000 and Start Performance field equal to 706 and End Performance filed equal to 1058.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.7 The device must support/current feature/profile list: GETCONFG.1

Send the command with RT field set to 0x00 (All feature list), SFN set to 0x00 (Profile list) and allocation length Equal to 0x08 (Header size). If data length returned from the device is less than or equal to 4, FAIL.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.8 The profile list, core features are always current: GETCONFG.2

First, send the command with RT field set to 0x01 (current features), SFN set to 0x00 (profile list) and allocation length equal to 0x08.

Send the command with RT field set to 0x01 (current features) , SFN set to 0x00 ( profile list) and allocation length equal to the data length returned from the previous command

If the first current feature is not 0x00 (profile list), FAIL, else

If the second current feature is not 0x01 (Core feature), FAIL

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.9 The current features list start with SFN specified (0x0001 in this case): GETCONFG.3

First, send the command with RT field set to 0x01 (current features) , SFN set to 0x01 ( profile list) and allocation length equal to 0x08.

Send the command with RT field set to 0x01 (current features), SFN set to 0x01 (profile list) and allocation length equal to the data length returned from the previous command

If the first current feature is not 0x01 ( core feature), FAIL.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.10 The data returned is for core (0x0001) feature only: GETCONFG.4

First, send the command with RT field set to 0x02 (one or zero features) , SFN set to 0x01 ( core feature) and allocation length equal to 0x08.

Send the command with RT field set to 0x02 (one or zero features), SFN set to 0x01 (core feature) and allocation length equal to the data length returned from the previous command

If first feature is not 0x01 (core feature) or the data returned is of more than one feature, FAIL.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.11 The device returns no data for an unsupported (reserved, 0x00f4) feature: GETCONFG.5

Send the command with RT field set to 0x02 (one or zero features) , SFN set to 0xf4 and allocation length equal 0x08

If data length returned is greater then 0x04, FAIL

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.12 There is no check condition with allocation length 0x00: GETCONFG.6

Send the command with RT field set to 0x01 (current list), SFN set to 0x00 and allocation length equal 0x00

If there is any check condition, FAIL.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.13 The features from the current list and all features list are equal and same: GETCONFIG.7

First, send the command with RT field set to 0x01 (current features), SFN set to 0x00 (profile list), exclude Vendor Unique features and allocation length equal to 0x08.

Send the command with RT field set to 0x01 (current features), SFN set to 0x00 (profile list) and allocation length equal to the data length returned from the previous command

Then

Send the command with RT field set to 0x00 (all features), SFN set to 0x00 (profile list), (Persistent bit set to one) and allocation length equal to 0x08.

Send the command with RT field set to 0x00 (all features), SFN set to 0x00 (profile list) and allocation length equal to the data length returned from the previous command

Compare the current features from both of the above command,

If current features are not same and equal, FAIL

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.14 The logical unit must be able to get the eject media event by the logical unit: GETEVENTNOTFN.2

There should be a Media Event with sub event Eject Request/Media removal. Before the Eject Request event there may be a device busy event. This will be tested for 1000 times to get an eject request at maximum.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.15 The logical unit must be able to get the insert media event by the logical unit: GETEVENTNOTFN.1

There should be a Media Event with sub event New Media. Before new media event, there may be a device busy event. This will be tested for 1000 times to get a new media event.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.16 The logical unit must have the type and name of the device handle created to: INQUIRY.1

Send the command EVPD field set to zero, Page code 0x0 (to get the general information about the target, handle created to), CmdDt set to 0x0,and buffer size of Inquiry data, print the device code and type.

If device, the handle created to is not of type CD ROM (0x05), fail the test.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.17 The logical unit must be able to set mode parameter page: MODESELECT.1

Reserved

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.18 The logical unit must be able to set default values of error recovery mode page: MODESELECT.2

Reserved

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.19 The logical unit must be able to set write parameter mode page: MODESELECT.3

Read the pages current values and set the mode page values according to the media in the drive and current features.

For CDR/RW

Write type – CD track at once

Data mode - Mode 1.

Session format – cd-da or other data cd, s

Multi Session – Next session allowed

Link size - 2 KB

For DVD R:

Write type – incremental streaming

Data mode - Mode 1.

Session format – cd-da or other data cd.

Multi session – next session allowed.

Link size – 2 KB.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.20 The logical unit must be able to set default values of write parameter mode page:

This will set the default values of the write parameter mode page back.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.21 The logical unit must be able to return all supported mode pages current values: MODESENSE.1

Send the command with DBD field set to 0x01, PC field set to 0x00, page code field set to 0x3fh, allocation length equal to size of (Mode Parameter Header). This command will return the length of data it has.

Then send the command with the data length returned from previous command, this will returns all supported mode pages with current values.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.22 The logical unit must be able to return all changeable mode pages values: MODESENSE.2

Send the command with DBD field set to 0x01, PC field set to 0x01, page code field set to 0x3fh, allocation length equal to size of (Mode Parameter Header). This command will return the length of data it has.

Then send the command with the data length returned from previous command, this will returns all supported mode pages with changeable values.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.23 The logical unit must support the C/DVD capabilities page: MODESENSE.3

Send the command with DBD field set to 0x01, PC field set to 0x01, page code field set to 0x2ah, allocation length equal to size of (Mode Parameter Header). This command will return the length of data it has.

Then send the command with the data length returned from previous command, this will return the c/dvd mode page’s current values.

Verify here the page code and page length, should be equal to 0x2A, and 0x18.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.24 The logical unit must return current read write error recovery mode page (0x01): MODESENSE.4

RESERVED

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.25 The logical unit must return changeable read write error recovery mode page (0x01): MODESENSE.5

RESERVED

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.26 The logical unit must be able to get the c/dvd write parameters mode page (0x05): MODESENSE.6

Send the command with DBD field set to 0x01, PC field set to 0x00, page code field set to 0x05h, allocation length equal to size of (Mode Parameter Header). This command will return the length of data it has.

Then send the command with the data length returned from previous command, this will return the write parameters mode page current values.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.27 The logical unit must be able to lock the media: PRVNTMDMREMBAL.1

Send the command, with prevent and persistent bit set to one, this will disable any eject mechanism, until the Host issues an eject request.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.28 The logical unit must be able to release the media: ALLWMDMREMBVL.2

Send the command with persistent bit set to one and prevent bit set to zero, this command ,make the logical unit to respond to eject media commands.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.29 The logical unit should not check condition for transfer length equal to zero: READ (10).1

Send the command with transfer length equal to zero; this should not be an error, if error fails the command.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.30 The logical unit must be able to read the data from LBA (0x0000): READ (10).2

Send the command with a valid LBA and transfer length equal to 0x01,this should return 2048 bytes from the device, if bytes returned are less than 2048 fail the command.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.31 The logical unit should not check for condition of transfer length zero: READ (12). 1

Send the command with transfer length equal to zero, FUA set to 0x01, and this should not be an error, if error fails the command.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.32 The logical unit must be able to validate the check condition with FUA and streaming bit both set to one: READ (12).2

Send the command with streaming bit set to one and FUA set one, the logical shall terminate the command with CHECK CONDITION status, ILLEGAL REQUEST, INVALID FIELD IN CDB.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.33 The logical unit must be able to read one block of data with streaming bit set from LBA zero: READ (12). 3

Send the command with a valid LBA and transfer length equal to 0x01,this should return 2048 bytes from the device, if bytes returned are less than 2048, fail the command.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.34 The logical unit (audio CD) must return the CD-DA data: READCD.1

Send down the command with expected sector type field set to 0x1 – CD DA

Moreover, test the length returned, required are 2352 bytes

Verify here the data length returned should be equal to 2352 bytes

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.35 The logical unit (data CD) should not check for the condition of transfer length is zero: READCD.1

Send down the command with expected sector type 0x00 (No sector type checking) with allocation length equal to zero. This should not generate any check condition.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.36 The logical unit must return the user data, for all sectors (no sector type checking): READCD.2

Send down the command with expected sector type 0x00 (No sector type checking), LBA set to 0x0000,with allocation length equal to 0x800. This should return the data from LBA specified of one block length i.e. 0x800.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.37 The logical unit data from the start of MSF address to ending address should be 2048 bytes: READCDMSF.1

Verify here the returned data length should be 2048 bytes.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.38 The logical unit must be able to read the last addressable LBA and block length information of the media: READCPCTY.1

Send this command with Reladr, LBA, and PMI fields with zero values. This will return the Read capacity of the logical unit in an 8-byte response data.

Verify here The Block size returned should be equal to 0x800.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.39 The logical unit must be able to return the information about mounted disc: READDSCINFO.1

First, send down the command with allocation length equal to 2, to read the number of bytes available.

The send down the command with the allocation length equal to the byes returned from previous command.

This command is used to find out type of media and its status i.e. blank, incomplete etc.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.40 The logical unit must be able to return all the available DVD structures: READDVDSTRUCT.1

Send the command with address field set to zero, format field set to 0x3f, layer number 0x01, allocation length equal to 4 . This command will return the length of the data available.

Send the command with address field set to zero, format field set to 0x3f, layer number 0x01, allocation length equal to the length returned in previous command. This should return all supported DVD structures.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.41 The logical unit must be able to return the maximum capacity descriptor and formatable capacity descriptor, if any: READFRMTCPCTY.1

First send the command with allocation length of 4,this command will give you the length in bytes of the capacity list that follow. The capacity list length of size 256 is valid.

Then send the commands with allocation length of the size of capacity list

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.42 The logical unit (CD) must be able to return the TOC for the first track media: READTOCPMAATIP.1

Send the command with MSF field set to one, with data Allocation length equal to 4,header size.

Then send the command the command with MSF field set to one, allocation length equal to the length from Previous command, track/session field set to one and Format field set to 0x0000.

Verify here the TOC returned is for the first track or not.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.43 The logical unit (CD) must be able to get session information for the media: READTOCPMAATIP.2

Send the command with MSF field set to one, allocation length equal to 4-header size.

Then send the command with MSF set to one, Allocation length equal to the length from previous command, track/session number field equal to zero and format code set to 0x0001.

Verify here the first complete session shall be set to one.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.44 The logical unit (CD) must be able to read the full TOC for the specified session (0x01): READTOCPMAATIP.3

Send the command with MSF field set to one, allocation length equal to 4-header size.

Then send the command with MSF field set to one, allocation length equal to the length from previous command, track/session field set to one and format field set to 0x0010.

Verify here the first complete session number set to one, and session number field set to one.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.45 The logical unit (DVD) must be able to read the fabricated TOC for first track of DVD media: READTOCPMAATIPDVD.1

Send the command with MSF field set to one, with data Allocation length equal to 4,header size.

Then send the command the command with MSF field set to one, allocation length equal to the length from Previous command, track/session field set to one and Format field set to 0x0000.

Verify here the TOC returned is for the first track or not.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.46 The logical unit (DVD) must be able to read the fabricated session information for the DVD media: READTOCPMAATIPDVD.2

Send the command with MSF field set to one, allocation length equal to 4-header size.

Then send the command with MSF set to one, Allocation length equal to the length from previous command, track/session number field equal to zero and format code set to 0x0001.

Verify here the first complete session shall be set to one.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.47 The logical unit must be able to return the information of the first track: READTRCKINFMN.1

Send the command with Address/Number type field set to one, LBA/track/session number field set to one, and Allocation length equal to 2, header length.

Send the command with Address/Number type field set to one, LBA/track/session number field set to one, and Allocation length equal to the length returned from the previous command.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.48 The logical unit must be able to send OPC information: SENDOPCINFO.1

If the host will send more that one OPC table entries with the same value in the OPC Speed field, the command shall terminate with CHECK CONDITION status, 5/26/00 INVALID FIELD IN PARAMETER LIST.

The response for this command will be of 8 bytes, having OPC speed in Kbytes per second and OPC value.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.49 The logical unit must be able to request the unit to be in ready state: STARTUNIT.1

Send the command with Immed bit set to one, LoEj set to one, start set to one, and power condition set 0x00,

This will close the tray if the device is a tray type.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.50 The logical unit must be able to request the logical unit to stop operation and ejecting the media if any: STOPUNIT.1

Send the command with immed bit set to one, start bit set zero, LoEj set to one, this command will eject the media from the drive, if media is of tray type.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.51 The logical unit must be able to perform the synchronize cache operation: SYNCCACHE

Send the command with immediate bit set to one.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.52 The logical unit must be able to verify the data: VERIFY.1

Send the command with LBA equal to 0x0000, transfer length equal to 0x01, data buffer of 0x800 bytes, and look for the check condition if there is any.

Verify here the returned data length is equal to 0x800.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.53 The logical unit (CD-R) must be able to perform writes of 256 blocks of data and 151 blocks of post GAP: WRITE10.1

Make sure media is blank

Set read write mode page to:

Track at once,

Mode1,

Next session allowed

Link size (2kb)

Set CD speed to 4x

Send OPC information

Write 256 +151 block of data

Close tack/session

Verify the data written 256 blocks of user data (one) and 151 post gap (zeros)

Restore default values of write parameter mode page

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.54 The logical unit (CD-RW) must be able to perform writes of 256 blocks of data and 151 blocks of post GAP: WRITE10.1

Media is blank or not and make sure if media is erasable

If media erasable, set cd speed to 4x , Send OPC information and Blank the disc.

Verify the media again after blanking

Set write parameter mode page to

Write type – cd track at once

Data mode – Mode 1

Disk type - cd da or other disks

Multisession – next session allowed

Link size – 2kb

Write 256+151 block of data

Close track/session

Verify the written data 256 blocks of user data (one) and 151-post gap (zeros)

Restore default values of write parameter mode page

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.55 The logical unit (DVD-RAM/RW) must be able to perform random writing of blocks on DVD-RW: WRITE10.1

Make sure random writable feature is current

Set CD speed to 4x

Send OPC information

Make sure the media is formattable

If formattable format the disc

Verify the format operation succeeds, do Read format capacity

Write the data skipping 0x10 blocks

Verify the data written

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.56 The logical unit (DVD-R) must be able to perform writes of 256 blocks of data and 151 blocks of post GAP: WRITE10.1

Make sure media is blank and erasable

If erasable and not blank

Set CD speed to 4x

Send OPC Information

Set write parameter mode page:

Write type – incremental streaming

Data mode – Mode 1

Disk type – cd da or other data disk

Multisession – next session allowed

Link size – 2 kb

Write 256 + 151 block of user data

Close track/session

Verify the written data 256 blocks of user data (1), and 151 blocks of zeros.

Restore write parameter default values

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description

28.13.57 The logical unit must be able to write data to the medium and be verified:

Send the command with LBA equal to zero and transfer length equal to 0x01.

Reference document: WLP# - B10.5.2.1; SFF 8090 (Mt. Fuji) v5 MMC specification
Test description: TD-28.13 MMC Command Description


Storage Data Verification Filter Test Assertions

Assertions in this section are tested in TD-28.14 Storage Data Verification Filter Test Description.

28.14.1 Data corruption must not occur on any disk read or write.

Reference document: WLP#- B1.3, B10.1.3.2, B10.1.4.7 and B10.9.3
Test description: TD-28.14 Storage Data Verification Filter Test Description


DCDP 14-Day Stress (Storage) Test Assertions

This is preliminary documentation and subject to change.

28.15.1 [NEW v0.3] The storage device and driver must run under test for 14 days without failure.

Reference documents: WLP# - B10.1.1; See the "The Datacenter Driver Program" white paper at http://www.microsoft.com/hwdev/platform/server/datacenter/default.asp
Test descriptions: TD-28.15 DCDP 14 Day Stress (Storage) Test


Storage Test Descriptions

DMA Timing Test: The DMA Timing Portion of the test will run in 3 sections for each IDE/ATAPI device on the system. The device is first queried to determine which timing modes it supports. For each timing mode that the device supports the registry will be updated to reflect the intended mode. The channel that the device is attached to will then be enumerated to cause the ATAPI driver to reprogram the timing registers on the controller. The registry will then be checked to ensure that the proper timing mode was set, and log an error if not. The three sections are lowest mode to highest mode, lowest mode being PIO0 and highest mode being MAXMODE (currently UDMA5), highest mode to lowest mode, and lowest mode to highest mode with pause. The third scenario gives time (default 20000 milliseconds) for CRC errors to occur, causing the ATAPI driver to time the device at a lower timing mode. The test will determine if a lower mode has been entered at the end of the pause time.

FILEIO verification: The FILEIO verification portion of the test runs while the DMA Timing portion is occurring. The algorithm uses a recursive function to copy all files from each disk to all other disks which are not read only. For example, a system with 2 hard drives and 1 CDROM would create 6 threads, HD0-HD0, HD1-HD0, CDROM-HD0, HD1-HD1, HD0-HD1, and CDROM-HD1. The entire directory structure except for directories which commonly contain in use files, such as the system directory, program files, and the HCT directory, will be copied up to 6 directories deep. After a file is copied, it is compared to the source. A match results in a pass, a mismatch results in a fail. After the file is compared it is deleted. Disks with less than one megabyte of storage remaining will be treated as read-only.


TD-28.1 DMA Test Description

Test Kit: HCT 11, HCT 10

Overview

The DMA test checks the ability of a driver to set a specified DMA (Direct Memory Access) timing mode for a device. For all devices in the system, the DMA test attempts to cause all timing modes supported by the device to be programmed. There are three variations: highest mode to lowest mode; lowest mode to highest mode; lowest mode to highest mode with a pause (the default is 20000 milliseconds) between variations. The test also runs multithreaded file I/O in the background, runs file I/O with copy from each available source to each valid destination, compares the copied data, and reports passes or failures based on the compare function.

The DMA test is an Automated test designed to ensure that ATA/ATAPI storage drivers correctly time devices as specified by the user or the system. If the system has a controller that supports ULTRADMA 3 or above, you must attach an 80 cable for accurate results.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

A system running Windows XP configured with at least one ATA/ATAPI device to run. If a system is using the PCIIDE mini driver, the system will fail all DMA variations except for PIO4 and the mode that the device was running at boot time. This is due to the generic nature of the driver not knowing which registers to use to setup timing modes.

Results Interpretation

The test displays the on-screen pass or fail status and writes the results to the log file Dmatest.log.

Error messages include the following:

SEV1 - UDMA3 or UDMA4 Not timed. This could be due to the controller not supporting UDMA3 or UDMA4

SEV2 - Data Corruption occurred during file I/O and the device was timed to a lower timing mode

SEV3 - Transfer mode UDMA2 and below not timed. This could be due to the controller not supporting UDMA2 or below.

  1. Unable to communicate with %s. Cannot Test:
  • This indicates that the device is not responding to commands. This is due to a hardware failure or a device being incorrectly detected by the test.
  2. Device has a different timing mode after sustained IO during %s:
  • Check the event log for CRC errors. This is a device failure.
  3. "Failed: 10.3.8 Peripherals comply with ATA/ATAPI-5. Running %s instead":
  • If UDMA5 and the controller does not support UDMA5 this is not a failure.
  • If UDMA3 or 4 and the controller does not support UDMA3 or 4, this is not a failure
  • If UDMA2 or Below, several conditions may apply

a. The Bus Mastering Bit Is not set by the BIOS SFF-8388i

b. The Controller is using PCIIDE as the driver. This indicates that the controller manufacturer needs to write an IDE miniport for the chipset

c. CRC errors happened immediately after timing the transfer mode

  4. TestBug:Attempted to Go to an Unrecognized DMAMode:
  • This indicates that the test did something incorrectly. This error indicates memory corruption or a mistake made by the test and should not be seen. This does not indicate a failure.
  5. NO VALID MODE SUPPLIED-Driver is Reporting that device is not running any Timing Mode:
  • The driver is not correctly updating the registry to show which mode it is running. This is a driver failure.
  6. ReadFile (Source=%s) Failed with error %d:
  • This could be caused by files on the devices being in use. This is considered a bug in the test, and does not constitute a failure.
  7. "The File %s failed to match with %s at offset %d\n:
  • If the file is in use, close the file and start again.
  • If the file is not in use, this constitutes a device failure to provide reliable transfers in DMA.


TD-28.2 General Storage Device Manual Test Checklist \Test Description

Assertions in this section are tested by affirming the related capability in this checklist.

28.2.1 | Storage device driver runs in 32-bit protected mode under Windows 98/Me after installation
28.2.2 | Bus type is clearly indicated using ANSI approved icons on connectors for all adapters and peripherals
28.2.3 | Terminator power is supplied to the SCSI bus with overcurrent protection
28.2.4 | External connector meets SCSI-2 or later standard
28.2.5 | Controller and peripheral connections include Pin 1 cable designation; shielded device connector meets SCSI-2 or later standard
28.2.6 | External devices use automatic termination or an accessible on-board termination switch
28.2.7 | Option ROM supports virtual DMA services


TD-28.3 Hard Disk Drive Manual Test Checklist Test Description

Assertions in this section are tested by affirming the related capability in this checklist.

28.3.1 | Hard disk supports partitions larger than 8 GB
28.3.2 | Hard disk can boot from OS loader


TD-28.4 CD/DVD Driver Manual Test Checklist Test Description

Assertions in this section are tested by affirming the related capability in this checklist.

28.4.1.1 | CD-enhanced compatible
28.4.1.2 | Supports specified logical and physical CD formats
28.4.1.3 | Supports the READ CD-DA command as defined in the MMC-2 standard
28.4.1.4 | Supports digital audio detection and digital audio quality on CD-ROM drive


TD-28.5 Tape Drive Manual Test Checklist Test Description

See TD-1.27 Tape Drive Ease-of-Use/Manual Checklist


TD-28.6 Media Changer Manual Test Checklist Test Description

See TD-1.28 Media Changer Devices Ease-of-Use/Manual Checklist


TD-28.7 RAID Manual Test Checklist Test Description

See TD-1.29 RAID Ease-of-Use/Manual Checklist


TD-28.8 Network Storage Manual Test Checklist Test Description

Assertions in this section are tested by affirming the related capability in this checklist.

28.8.1 | Driver with special parameters includes Help file that is installed as part of the driver installation routine.
28.8.2 | If the device's Properties dialog box includes an Advanced tab, all INF strings displayed are spelled correctly.
28.8.3 | Any diagnostics or utilities included with the device works correctly
28.8.4 | Any diagnostics or utilities included with the device can be accessed from the Network Control Panel Advanced Properties page
28.8.6 | Device with USB, IEEE 1394, or PC Card external connectivity capabilities correctly supports hot plugging or unplugging per its bus class


TD-28.9 CD-R/CD-RW Functionality Test

Test Kit: HCT 11, HCT 10

Note This test was previously called the WHQL Test For CD-R(W) Using IMAPI Test Tool.

Overview

The existing IMAPI test tool is used to do limited WHQL test for CD-R or CD-RW writers. The test uses many of the mandatory features for CD-R(W) through the high level API function calls. By mapping the mandatory features to the high level API test cases, these test cases have good coverage on the MMC packet commands that are required by each feature. Therefore, the passes or failures of the API test cases will give us a rough idea whether the device is compliant to MMC specification or not.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The tool consists of five major parts, each represented by a .cpp file. IMAPIMSTest.cpp file is where the "main" function is. Users call "IMAPIMSTest" by issuing a command, along with the arguments, from the command window. The usage information will be printed if you issue "IMAPIMSTest" or "IMAPIMSTest /?" Here are the explanations of these commands.

Command | Description
IMAPIMSTest [-?|/?|-h|/h] | Print out the help message.
IMAPIMSTest -t <testcase_name> -a <testcase_arg1> <testcase_arg2> ... | Run a single test case.
IMAPIMSTest -f <test configuration filename> | Run all tests specified in the configuration file.
IMAPIMSTest –s | Generate a sample test configuration file.

Users can run a single test case by issuing "IMAPIMSTest -t <testcase_name> -a <testcase_arg1> <testcase_arg2> …". <Testcase_name> specifies which test users want to run. <Testcase_args> are the arguments for this test case. For example, it allows you to specify the CD writer you want the test to run on. IMAPIMSTest.cpp parses the command line arguments, sets the corresponding flags, retrieves the test case name and parameters, and stores them in the global variables called "gszArgs" and "gArgCout". It also initializes NTLOG for logging, initializes COM in multi-threaded object concurrency mode. Then it looks up its dispatching table, a big array called "pTestDispatch" which contains "name-to-function" mappings for test cases. It then finds out the pointer to the test case function, i.e. the function that performs the test case, and then calls it. After finishing the test case, the main function calls "GetStatistics()" to obtain the test PASSED and FAILED statistics.

Users can also call IMAPIMSTest by passing in a test configuration file. That is, issue the command "IMAPIMSTest -f <test configuration filename>". A test configuration file contains a list of tests to be run. Test cases are separated by ";" tokens and are specified exactly the same way as if they are passed in as a single test case. IMAPIMSTest will run one test by another in the file and gather the test PASSED and FAILED information for all these test cases.

For easy starting-up, the tool provides a way to generate a sample test configuration file automatically. Type "IMAPIMSTest -s" will create a sample file for you.

The test case functions are distributed in four other .cpp files, namely, MSTIDiscMaster.cpp, MSTIDiscRecorder.cpp, MSTIRedbookDiscMaster.cpp and MSTIJolietDiscMaster.cpp. For example, MSTIDiscMaster.cpp has all the test cases for IDiscMaster interface, MSTIDiscRecorder has all the test cases for IDiscRecorder interfaces, and so on.

Test case functions all have the same prototype, that is,

void function_name(void);

This makes the dispatching much easier. The functionality test cases all bear a prefix "FUNC_" so they can be easily distinguished from the regression tests and stress tests that will be implemented later on. The naming convention of the test case functions is:

Prefix_InterfaceName_APIFunctionName_TestSpecificName

Where,

Prefix: "FUNC_" for functionality (regression) tests;

"LONG_" for long-haul tests;

"STRE_" for stress tests.

InterfaceName: could be "IDiscMaster", "IDiscRecorder", and so on.

APIFunctionName: If this test case function only performs the tests for one IMAPI function, this is the name of that function.

TestSpecificName: This part usually describes which test scenario is performed by the function.

Here is an example,

void FUNC_IDiscMaster_Open_OtherApp();

This is a test case for testing the Open function in IDiscMaster. The scenario is to try to open the DiscMaster that has already been opened by another application.

Required Hardware
  • CD-R or CD-RW writer
  • Hard drive with at least 800M free space for the stash file generated by IMAPI

Required Software

  • IMAPI

Results Interpretation

The test creates both good scenarios and bad scenarios. Then it checks the actual outcomes with the expected ones. The test writes the results of the comparison and reports the unexpected outcomes to the log file ImapiMSTest.log.


TD-28.10 Media Changer Stress Test

Test Kit: HCT 11, HCT 10

Note This test was previously called the TD-28.10 NTMS Stress Test. Note that the Removable Storage Management (RSM) technology was previously named NTMS.

Overview

This test does all RSM operations that do not require human intervention and can run for a specified length of duration. The test tries to isolate classes of API calls to help identify problem areas. Stressing RMS is very confusing because it is a slow system by nature. Since RMS only manages storage devices such as tapes and doesn't come in the way of actual reading or writing data, confusion mounts. Basically the stress program should keep making sensible RMS requests repeatedly by acting as a bunch of rogue applications. It would be more pertinent to write small but meaningful RMS "baby" applications - and swamp RMS with requests to service them - via a Launch program, which would do so in a single/multithreaded manner. That stressing would aim to see how RMS handles contention. Stressing individual sub-components of RMS is also important if such a thing is possible.

Each RMS "baby" application will be considered as a scenario. A scenario will report an error if something wrong has happened. A scenario by itself will not stress RMS. But putting lots of such scenarios together and running them from different threads at a time, will tend to stress RMS. So the failure of the test is not the failure of a scenario, but it is failure of RMS under the stressed situation.

Click to show or hide information. Test Scenarios

Scenario 1: Open and Close RMS session.

This scenario consists of two simple RMS API calls, viz., OpenNtmsSession() and CloseNtmsSession. In this, session(s) will be opened and will be closed after waiting for some time. The two sub-scenarios under this follow:

  • Scenario 1A:

Open an RMS session;

Wait for some time; // Wait time can be varied across runs

Close the RMS session;

Repeat the whole, until the end is signaled;

  • Scenario 1B:

Open N RMS sessions; // Where N is a predetermined number, which can be varied across runs.

Wait for some time;

Close all opened RMS sessions;.

Repeat the whole, until the end is signaled;

Scenario 2: Enumerate all the objects in the system and get the information available on them.

This scenario consists of two basic RMS APIs, viz., EnumarateNtmsObject() and GetNtmsObjectInformation() . Here all possible RMS objects are enumerated and for every type of object a list of all the objects available in the current system is made. Each list also consists of all possible information available on the objects, which is returned by the GetNtmsObjectInformation() on each of them. The two sub-scenarios under this follow:

  • Scenario 2A:

For (every possible TYPE of RMS object)

{

Enumerate all RMS objects in the system of the TYPE;

Make a list of all those objects;

For (each OBJECT in the list)

Get Information about the OBJECT and add it in the list;

}

Repeat the whole, until the end is signaled;

  • Scenario 2B:

For (every possible TYPE of RMS object)

{

Enumerate all RMS objects in the system of the TYPE;

Make a list of all those objects;

For (each OBJECT in the list)

Get Information about the OBJECT and add it in a local list;

Compare the information received now, with information available from any other previous run, which is available in a global list;

If some change is found in the comparison, update the global list;

}

Repeat the whole, until the end is signaled;

Scenario 3: Create and Delete Media Pool(s).

In this scenario, application Media pools are created for the available Media Types in the current RMS system and then deleted after a wait for some time. The RMS APIs used significantly in this scenario are, EnumerateNtmsObject, CreateNtmsMediaPool() and DeleteNtmsMediaPool().The five sub-scenarios follow:

  • Scenario 3A:

Enumerate All possible RMS Media Types in the current RMS system;

Choose one of the TYPEs randomly;

Create an Application Media Pool for the Chosen TYPE;

Wait for some time;

Delete the newly created Application Media Pool.;

Repeat the whole, until the end is signaled;

  • Scenario 3B:

Enumerate All possible RMS Media Types in the current RMS system;

Choose one of the TYPEs randomly;

Create N (user defined) number of Application Media Pools for the Chosen TYPE;

Wait for some time;

Delete all the newly created Application Media Pools.;

Repeat the whole, until the end is signaled;

  • Scenario 3C:

Enumerate All possible RMS Media Types in the current RMS system;

For (Each of the Available Media TYPEs)

Create an Application Media Pool for the TYPE;

Wait for some time;

Delete all newly created Application Media Pools;

Repeat the whole, until the end is signaled;

  • Scenario 3D:

Recursively create N Media Pools of media Pools,

i.e., a pool of depth N-1.

Back track the whole tree and delete all the nodes crossed.

Repeat the whole, until the end is signaled;

  • Scenario 3E:

Create a Media Pool of pools (A root pool);

Create a media pool of any type (from the available types) under the Root pool;

Wait for some time;

Delete the SubPool ;

Delete the RootPool.

Repeat the whole, until the end is signaled;

Scenario 4: Move Media back and forth between Media Pools.

In this scenario, in general the media are moved across different Media Pools. It is always made sure that both the source and destination Media Pools are for same Media Type and also the move is allowed (e.g., no try is made to move a Media from Foreign Pool to Application Pool ). The RMS APIs used significantly in this scenario are, EnumerateNtmsObject, GetNtmsObjectInformation(), CreateNtmsMediaPool(), MoveToNtmsMediaPool() and DeleteNtmsMediaPool(). The different variations of this follow:

  • Scenario 4A :

Enumerate all possible Media Pools available in the current system;

Find a FREE_POOL;

Find the TYPE of Media for the FREE_POOL;

Create an Application_Media_Pool for the TYPE;

Enumerate all the Media in the FREE_POOL;

Randomly choose one of the media from the Free Pool;

Move the chosen media from the FREE_POOL to the Application_Media_Pool;

Wait for some time;

Move the media back from the Application_Media_Pool to the FREE_POOL;

Delete the newly created Application_Media_Pool;

Repeat the whole, until the end is signaled;

  • Scenario 4B :

Enumerate all possible Media Pools available in the current system;

Find a FREE_POOL;

Find the TYPE of Media for the FREE_POOL;

Create an Application_Media_Pool for the TYPE;

Enumerate all the Media in the FREE_POOL;

Move all the media from the FREE_POOL to the Application_Media_Pool;

Wait for some time;

Move all the media back from the Application_Media_Pool to the FREE_POOL;

Delete the newly created Application_Media_Pool;

Repeat the whole, until the end is signaled;

  • Scenario 4C:

Enumerate all possible Media Pools available in the current system;

For (Each Media Pool)

If (It is an Import Pool or an Unrecognized Pool)

Find the Free Pool of the same type;

Move all Media from the Import/Unrecognized Pool

To the Free Pool;

Repeat the whole, until the end is signaled;

  • Scenario 4D:

Enumerate all possible Media Pools available in the current system;

Choose a FREE_POOL having some media in it;

Create two application pools P1 and P2 for the same media type as

Of the FREE_POOL;

Move all media from the FREE_POOL to Pool P1;

Wait for some time;

Move all media from the Pool P1 to P2;

Wait for some time;

Move all media from the Pool P2 to the FREE_POOL;

Delete both P1 and P2;

Repeat the whole, until the end is signaled;

  • Scenario 4E:

Enumerate all possible Media Pools available in the current system;

Find a SCRATCH_POOL;

Find the TYPE of Media for the FREE_POOL;

Create an APPLICATION_POOL_1, which will be a Pool of Pools;

Create two other application media pools APPLICATION_POOL_1\POOL1 and APPLICATION_POOL_1\POOL2 for the TYPE;

Enumerate all the Media in the FREE_POOL;

Move all the media from the FREE_POOL to the APPLICATION_POOL_1\POOL1;

Move all the media from APPLICATION_POOL_1\POOL1 to the APPLICATION_POOL_1\POOL2;

Move all the media back from the APPLICATION_POOL_2 to the FREE_POOL;

Repeat the whole, until the end is signaled;

Scenario 5: Allocate and Deallocate Media.

In this scenario some Media are allocated from some newly created (created by the application) Media Pool and then Deallocated. The major RMS APIs used over here are AllocateNtmsMedia() and DeallocateNtmsMedia(). The different variations of this follow:

  • Scenario 5A:

Enumerate all possible Media Pools available in the current system;

Find a FREE_POOL;

Find the TYPE of Media for the FREE_POOL;

Create an APPLICATION_POOL for the same TYPE;

Move a randomly chosen MEDIA from the FREE_POOL to the APPLICATION_POOL;

Allocate the MEDIA;

for some time;

Deallocate the MEDIA;

Move the MEDIA back to the FREE_POOL ;

Delete the APPLICATION_POOL;

Repeat the whole, until the end is signaled;

  • Scenario 5B:

Enumerate all possible Media Pools available in the current system;

Find a FREE_POOL;

Find the TYPE of Media for the FREE_POOL;

Create an APPLICATION_POOL for the TYPE;

Move all MEDIA from the FREE_POOL to the APPLICATION_POOL;

Allocate all MEDIA one by one;

Wait for some time;

De-allocate all MEDIA;

Move all the MEDIA back to the SCRATCH_POOL ;

Repeat the whole, until the end is signaled;

  • Scenario 5C:

Enumerate all possible Media Pools available in the current system;

Find a FREE_POOL;

Find the TYPE of Media for the FREE_POOL;

Create an APPLICATION_POOL for the same TYPE;

Move a randomly chosen MEDIA from the SCRATCH_POOL to the APPLICATION_POOL;

While (Not End Signal)

Allocate the MEDIA;

Wait for some time;

De-allocate the MEDIA;

Move the MEDIA back to the FREE_POOL ;

Delete the APPLICATION_POOL;

Repeat the whole, until the end is signaled;

  • Scenario 5D:

Enumerate all possible Media Pools available in the current system;

Find a FREE_POOL;

Find the TYPE of Media for the FREE_POOL;

Create an APPLICATION_POOL for the same TYPE;

Set the Allocation policy for the APPLICATION_POOL as NTMS_ALLOCATE_FROMSCRATCH;

Set the De-allocation policy for the APPLICATION_POOL as NTMS_DEALLOCATE_TOSCRATCH;

Allocate a MEDIA;

Wait for some time;

De-allocate the MEDIA;

Delete the APPLICATION_POOL;

Repeat the whole, until the end is signaled;

Scenario 6: This scenario will deal with the mounting and dismounting of RMS Media.

The scenario will mount some RMS media and then will dismount all those after waiting for some time.

  • Scenario 6A:

Enumerate all possible Media Pools available in the current system;

Find a FREE_POOL;

Find the TYPE of Media for the FREE_POOL;

Create an APPLICATION_POOL for the same TYPE;

Move a randomly chosen MEDIA from the FREE_POOL to the APPLICATION_POOL;

Allocate the MEDIA;

Mount the MEDIA to an unspecified drive;

Wait for some time;

Dismount the MEDIA;

De-allocate the MEDIA;

Move the MEDIA back to the FREE_POOL ;

Delete the APPLICATION_POOL;

Repeat the whole, until the end is signaled;

  • Scenario 6B:

Choose an online LIBRARY from the system;

Enumerate all possible Media Pools available in the LIBRARY;

Find a FREE_POOL from the above list of pools;

Find the TYPE of Media for the FREE_POOL;

Create an APPLICATION_POOL for the TYPE;

Move all MEDIA from the FREE_POOL to the APPLICATION_POOL;

Allocate all MEDIA one by one;

Find the number of Drives available in the LIBRARY;

Find the Min of Number of Drives and the Number of Media; // This is the //number of mounts can be done at a time;

Mount Min number of MEDIA into Min number of Drives;

Wait for some time;

Dismount all MEDIA;

De-allocate all MEDIA;

Move all the MEDIA back to the SCRATCH_POOL ;

Repeat the whole, until the end is signaled;

Scenario 7:

It is a simple scenario in which we just take the Back-Up of the RMS Database. The RMS API used is ExportNtmsDatabase(). This function is called in a loop until the end of the whole execution, with an interval time predetermined, but modifiable across runs.

Scenario 8:

This scenario will be using the RMS APIs OpenNtmsNotification(), WaitForNtmsNotification() and CloseNtmsNotification(). Each scenario function will be, opening an RMS notification channel for a particular type of RMS object and then WaitFor the notification till the end of the program execution. If some notification is received before, the Wait will be called again in a loop. After the program execution time is over, the loop will be broken and the channel will be closed. There will be one thread for each type of RMS object.

Description:

For (Each possible object TYPE)

Start a Thread;

In the Thread, Open a Notification channel for the TYPE;

While (Not end signaled)

Wait for a Notification, with some TIMEOUT value;

Close the Notification channel;

End Thread;

End For;

Scenario 9:

This scenario will deal with Operator request APIs, viz., SubmitNtmsOperatorRequest(), WaitFor NtmsOpeartorRequest(), and CancelNtmsOperatorRequest(). A set of operator requests can be made and then cancelled after waiting for some time. As there will be no operator intervention during the run of the test, this assures the requests not getting serviced.

  • Scenario 9A:

Submit an operator Request;

Wait for some finite time;

Cancel the Request;

  • Scenario 9B:

Submit one Request of every possible type of Operator Request;

Wait for some finite time;

Cancel all the Requests;

Scenario 10: Get and Set object information.

This scenario consists of two major RMS APIs, viz., GetNtmsObjectinformation() and SetNtmsObjectInformation(). The information about all the objects are read by using GetNtmsObjectInfirmation() and then some of the writable parameters are changed through SetNtmsObjectInformation(). The attributes chosen to Set are only those which are writable for any type of object.

Description :

Enumerate all possible objects in the system;

For (Each OBJECT)

Get the Information about the OBJECT;

Set some writable field(s) of the Information;

End For;

Scenario 11: Set and Get NtmsObjectAttribute.

This scenario deals with creating and retrieving private data for an object using the RMS APIs SetNtmsObjectAttribute and GetNtmsObjectAttribute(). First for all objects in the system Set an attribute and its data. Attribute name and data are generated using a common algorithm, so that there will be no need to store the information and can be reproduced anytime.

  • Scenario 11A:

Enumerate all the objects in the RMS system;

For (All objects in the RMS system)

SetNtmsObjectAttribute for that object;

Wait for some time;

For (All objects in the RMS system)

GetNtmsObjectAttribute for that object;

  • Scenario 11B:

Enumerate all the objects in the RMS system;

For (All objects in the RMS system)

SetNtmsObjectAttribute for that object;

Wait for some time;

For (All objects in the RMS system)

(Re) SetNtmsObjectAttribute for that object;

// i.e. Set attribute with zero length.

Scenario 12: This scenario will use GetNtmsMediaPoolName() API.

Here we get the names of the all-possible Media Pools available in the media. We also create some Pools of our own and get the name for all.

  • Scenario 12A:

Enumerate all available Media pools in the system;

For (Each one of the Media Pools)

Get the name of the Media Pool;

  • Scenario 12B:

Enumerate all available Media pools in the system;

Create some application Media Pools and add those to the list of Pools;

For (Each one of the Media Pools)

Get the name of the Media Pool;

Scenario 13:

This scenario will do an Inventory of the RMS system after every one hour or so.

Scenario 14:

This scenario deals with the library request ordering. One can get the order of all the library requests currently in the system by using the GetNtmsRequestOrder API and do a reordering through SetNtmsRequestOrder. In this scenario some of the library requests are made and then the order of those are set through the API. It is ensured that the requests are not satisfied and at the end, all are cancelled.

Description:

Enumerate all the libraries in the system;

Choose one of the online libraries;

Fire some library request APIs;

For (Each of the requests made)

Get the order of each of the requests;

Set the order to some different value;

End for;

Scenario 15 : Add and delete media types.

In this scenario, some new media types are added to a library. The process will result in some new system media pools for the new types. Then that media type will be delete from the library, causing the deletion of all those system pools. The major APIs used in this scenario are, AddNtmsMediaType(), DeleteNtmsMediaType().

  • Scenario 15A:

Enumerate all libraries in the system;

Choose one online library;

Find all media types, which are not there in the system currently;

If (there is any such media type)

Choose one of those;

Add the media type to the chosen library;

Wait for some time;

Delete the newly added media type from the library;

End If;

Repeat the whole till the end is signaled.

  • Scenario 15B:

Enumerate all libraries in the system;

Choose one online library;

Find all media types, which are not there in the system currently;

If (there is any such media type)

For (Each of such media type)

Add the media type to the chosen library;

Wait for some time;

Delete the newly added media type from the library;

End For;

End If;

Repeat the whole till the end is signaled.

  • Scenario 15C:

Find all media types which are not there in the system currently;

If (there is any such media type)

Enumerate all libraries in the system;

For (Each online library)

Add a new media type to the chosen library;

Wait for some time;

the newly added media type from the library;

End For;

End If;

Repeat the whole till the end is signaled.

  • Scenario 15D:

Enumerate all libraries in the system;

Choose one online library;

Find all media types, which are not there in the system currently;

If (there is any such media type)

Add all the new media types to the chosen library;

Wait for some time;

Delete all the newly added media types from the library;

End If;

Repeat the whole till the end is signaled.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test can be run on a local as well as a remote server.

Results Interpretation

The test logs the results of each scenario. A failure will receive a SEV tag. The log results are programmatically examined at the end of the test. Any failure of any one scenario will result in a failure of the test. Otherwise the test will log a passing result.


TD-28.11 Crashdump Test Description

Test Kit: HCT 11, HCT 10

Overview

This test installs and starts a dummy driver service on the local system and simulates system crashes by sending bug check codes through this dummy driver. Once the system reboots, the test runs automatically and examines the previous crash by analyzing the memory dump file through the kernel debugger, and by parsing the debugger output. The test loops through this process until all crash scenarios are completed.

Crash Scenarios

Full Memory Dump

1.Y INACCESSIBLE_BOOT_DEVICE (Bugcheck code 0x0000007B)

4.Y KMODE_EXCEPTION_NOT_HANDLED (Bugcheck code 0x0000001E)

7.Y DATA_BUS_ERROR (Bugcheck code 0x0000002E)

10.Y IOCTL_BUGCHECK_CUSTOM (Bugcheck code 0x69696969)

Kernel Memory Dump

2.Y INACCESSIBLE_BOOT_DEVICE

5.Y KMODE_EXCEPTION_NOT_HANDLED

8.Y DATA_BUS_ERROR

11.Y IOCTL_BUGCHECK_CUSTOM

Mini Memory Dump

3.Y INACCESSIBLE_BOOT_DEVICE

6.Y KMODE_EXCEPTION_NOT_HANDLED

9.Y DATA_BUS_ERROR

12.Y IOCTL_BUGCHECK_CUSTOM

For the full and kernel memory dump, this test verifies the following before/after crash information (Each first-level bullet item corresponds to an assertion statement in the test. Actual debugger commands are enclosed in square brackets):

X.1 [!devnode 0 1] Devnode count and checks instance ID for each devnode.

X.2 [.bugcheck] Bugcheck code and bugcheck parameters.

X.3 [!drivers] Driver counts and checks driver name for each driver.

X.4 [!process 0 7] Process count (except System Idle process) and process ID, in addition, this test checks for the following data in the dump file but does not validate value and correctness:

  • Process Address
  • Process Environment Block (PEB)
  • Parent ID
  • Elapsed Time
  • User Time
  • Kernel Time
  • Paged Pool
  • Non-Paged Pool
  • Working Set Size (Now, Min, and Max)
  • Thread (except for threads spawned by CrashdumpTest.exe) parent ID, in addition, this test checks for the following data in the dump file but does not validate value and correctness:
  • Thread Address
  • Thread Environment Block (TEB)
  • Thread ID
  • Owning Process Address
  • Service Dispatch Table
  • State
  • Start Address
  • Priority
  • Stack Trace

X.5 [!cpuinfo proc] CPU vendor string, processor control region, and current running thread for each CPU.

X.6 [n/a] Dump file size matches the corresponding crash scenario.

X.7 [!memusage] Memory usage information, this test checks for the following data in the dump file but does not validate value and correctness:

  • Zeroed
  • Free
  • Standby
  • Modified
  • Modified No Write
  • Active/Valid
  • Transition
  • Unknown
  • Total
  • Usage Summary

X.8 [!vm] Virtual memory information, this test checks for the following data in the dump file but does not validate value and correctness:

  • Physical Memory
  • Current Page File Size
  • Minimum Page File Size
  • Available Pages
  • ResAvail Pages
  • Locked IO Pages
  • Free System PTEs
  • Free NP PTEs
  • Free Special NP
  • Modified Pages
  • Non-Paged Pool Usage
  • Non-Paged Pool Max
  • Paged Pool Usage
  • Paged Pool Maximum
  • Shared Commit
  • Special Pool
  • Shared Process
  • Paged Pool Commit
  • Driver Commit
  • Committed pages
  • Commit limit
  • Total Private
  • Terminal Server Memory Usage By Session
  • Session Paged Pool Maximum
  • Session View Space Maximum

X.9 [!locks] Resource lock information.

For the mini-dump, this test verifies the following before/after crash information (Each first-level bullet item corresponds to an assertion statement in the test. Actual debugger commands are enclosed in square brackets):

X.1 [.bugcheck] Bugcheck code and bugcheck parameters.

X.2 [n/a] Dump file size matches the corresponding crash scenario.

WARNING entries

The following is listed of drivers and processes that this test will treat as special case, and it will log all of the following as WARNING entries:

Drivers:

  • wch711nt.sys
  • mskssrv.sys
  • mspclock.sys
  • rca.sys
  • mspqm.sys
  • asyncmac.sys
  • dmboot.sys
  • ndisuio.sys

Processes:

  • wmiadap.exe
  • userinit.exe

Test Architecture

This test acts as the control of a state machine where each state represents a different crash scenario. The test starts in the RESET state. In RESET state, the test sets up and configures the local system for auto-reboot after a system crash. In addition, the test also checks that symbols and debuggers are installed on the local system. If they are not found in the default location of C:\, the test prompts you for a location. To stop and reset the test at any time, press Ctrl + C.

Note After the reboot, you may need to logon using your system password. To avoid the need to logon after each crash recovery, see the topic "Security and the HCT kit" in the HCT documentation for information on how to enable autologon, and the security considerations of doing so.

Following the RESET state, the test enters the testing phase and goes through different crash scenario states. During each state, the test completes the following tasks:

  1. Loads previous system configuration from file.
  2. Analyzes previous crash.
  3. Saves current system configuration to file.
  4. Records and closes all logging information.
  5. Crashes the system again with the current scenario.

If you terminate the test by pressing CTRL + C, or if the test is unable to continue (for example, due to network failure), the test stops and no logging information is produced.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Software

  • CrashdumpTest.EXE.
  • Windows XP.
  • Windows Kernel Debugger (Local or on network share).
  • Windows Kernel Debugger symbol files (Local or on network share).
  • NTLog.DLL.

Results Interpretation

When the test is in the stop state, the utility will produce a log file (CrashdumpTest.LOG) in the %SYSTEMROOT% directory. Due to the multiple reboot requirement of this test, the utility records all intermediate logging info into a binary file. The utility appends to this binary file until it reaches the stop state, where it will parse back the binary file and record all logging info into a plain text file using the APIs exported by NTLog.DLL. For correctness of the logging mechanism, the intermediate binary log file is encrypted.

CrashdumpTest.exe will analyze debugger output one line at a time. Once the test has successfully launched the Kernel Debugger (KD), it will send a command down and starts to sit in a while loop until the KD prompt is detected (which indicates KD is ready for a new command). In each iteration of the while loop, the function DM_GetKDOutput is called to retrieve one line.

The DM_GetKDOutput API will signal busy and hint the caller should wait before calling this function again to get the next line. If the KD hangs and the caller does not receive a ready signal to submit a new command from this function, CrashdumpTest.exe will timeout, terminate, and log failure.

Parsing each output is done by the test function UTIL_Split. This function calls on _tcstok to parse out individual tokens (Please refer to section 4.7 for complete API reference).

In the final log file, the assertions statements are labeled in the following format:

ASSERTION X.Y text

X has a value between (1 to 12), representing the crash scenarios.

Y has a value between (1 to 9), representing the test cases.

text is the assertion description.

For full and kernel dumps, there are nine assertions for each of the four bug check codes. For mini dumps, there are two assertions (section 3.1) for each of the four bug check codes. Combined, there are a total of 80 assertions.

The test should pass at 80 / 80 assertions (100%) and allow warnings due to special case drivers and processes


TD-28.12 Red Book Test Description

Test Kit: HCT 11, HCT 10

Overview

The test will determine if the CD-ROM can do Raw Reads with no problems. To do this the CD-ROM needs to support the CDDA bit and CDDA stream must be accurate. If the drive does not support these bits then it will fail this portion of the test, but will keep on running. The test will also query the device using the SCSI pass through to see get its inquiry data from it.

Detailed Description

Raw Track Alignment: This portion of the test will test the ability of the CD-Rom to find its way back to the beginning of each even track.

How It Is Done: Each even track is read and kept in memory. Then two full tracks are read to clear the buffer. Then each even track is re-read again and compared with the first read to make sure the reads are correct.

Sector/Sample Alignment: This portion of the test will test the ability to read raw data in a continuous stream and test the data to see if it is all continuous in the reads in data.

How It Is Done: We will be reading from only two even tracks, but we will read each complete track using various sector sizes starting from 1 and ending with 26. Then with each read we test to make sure that each read is butted against each other, that each read does not produce sectors filled with zeros and that there are no missing samples. Within each individual sector we make sure that the samples are all butted against each other, the left and the right are the same and that there are no missing samples.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Hardware

Standard machine with at least one CD-ROM.

NOTE: This test must be run with a CD that has special tracks created with another test in order to work correctly.

Required Software

This test must be run with the HCT 10.0 CD in the tray of the device under test. The HCT CD has a special track that is required by this test to properly run.

Results Interpretation

All errors will be written into a log file in the directory the test was run from.


TD-28.13 MMC Command Description

Test Kit: HCT 11, HCT 10

Overview

The Microsoft Windows XP and Windows Whistler Server operating systems use the MMC-1, MMC-2, MMC-3 and SFF-8090i (Mt. Fuji) standards as the basis for supporting CD-ROM, DVD-ROM, CD-RW, CD-R and DVD_RAM devices.

Required MMC Commands

Blank Command 0xA1

This command provides the ability to erase any part of a CD-RW or DVD-RW disc. These are the fields that are most important for Windows (and that are tested in HCT 10 and later versions):

  • Immed, 1-bit field; allows execution of blank command as an immediate operation.
  • If set to 0, then the requested operation is executed to completion prior to returning status. If Immed is 1, then status is returned once the operation has begun.
  • Blanking Type, 3-bit field; identifies the method and coverage of blanking.
  • Start Address / Track Number, 4-byte field; is the LBA (Logical Block Address) that a range begins:
  • When Blanking Type is blank a Track Tail, this field indicates the start LBA.
  • When blanking type is Blank the entire disk, this field is reserved.
  • When Blanking Type is Blank a Track, this field indicates the track. When the logical unit change Status (NOT READY, READY), a class 1 event is generated.

Close Track /Session Command 0x5B

This command allows closure of either a track or a session. These are the fields that are most important for Windows (and that are tested in HCT 10 and later versions):

  • Immed, 1-bit field; when set to 0, the requested close operation is executed to completion prior to returning status, if set to 1, then status is returned once the close operation ha begun.
  • Track, 1-bit field; may be either 0 or 1.
  • Session, 1-bit field.
  • Track/Rzone number, 2-byte; sSpecifies the track/session to be closed.

Format Unit Command 0x04

This command formats a medium into initiator addressable logical blocks per the initiator defined options. The medium may be certified and control structures created for the management of the medium and defects.

One field is important for Windows (and is tested in HCT 10 and later versions):

  • CmpList.
    When set to 1, indicates the parameter list is complete and logical unit should ignore all the existing parameter.

Format Parameters:

  • Format List Header: 4-byte header to be sent down
  • Reserved1
  • 1-byte field; with following bits

FOV | Format options valid; if set to 1 indicates that logical unit should ignore the existing setting of the remaining fields of this byte.
DPRY | Disable primary, if set to 0, indicates the logical unit should retain the manufacturer certification list (Plist). Should be 0 for DVD RAM,CD-RW, and DVD-RW.
DCRT | Disable certification; if set to 1, indicates the logical unit must not perform any vendor-specific medium certification process. Must be set to 0 for CD-RW.
STPF | Stop format; must be set to 0.
IP | Initialization pattern; must be set to 0.
Try-Out | When set to 1, must check whether the format operation is possible with existing parameters.
Immed | Must be set to 1 for immediate status; if set to 0, the status will be returned after completion of operation (format).
VS | Vendor specific.

  • Reserved2
  • Reserved3
  • Formattable capacity descriptor
  • 8-byte descriptor, returned from the READ_FORMAT_CAPACITY Command

Get Performance Command 0xAC

This command provides a method for the initiator to profile the performance of the logical unit. The command also provides a means to the initiator to get status and events that occurred during Playback/recording operation. Performances parameters are reported separately for read and write.

These are the fields that are most important for Windows (and that are tested in HCT 10 and later versions):

  • Data Type, 5-bit field; value dependent on the type field of the CDB.
  • Type, 1-byte field; specifies which type of data must be transferred,
  • When set to 00h, it indicates the Performance data must be transferred. In this Type field, the value of LBA is of importance if Except bits (two LSB bits in the data type field) are 01b.
  • When set 01h, indicates the unusable area data must be transferred for this case the media should be writable else the logical unit terminates the command with Check Condition status, invalid field in CDB. The two MSB bits of data type field of the CDB are reserved for this type
  • When set to 02h, indicates the Defect Status data must be transferred.
  • This command reports Defect Status data to the initiator that is created by certification on the Restricted Overwrite media. If the mounted media is not a restricted overwrites media or if the logical unit does not support certification, this command must be terminated with Check Condition status, invalid field in CDB.
  • All other values are reserved.
  • Starting LBA, 4-byte field; specifies the starting LBA where from /to data is to be transferred.
  • Maximum number of descriptors, 2-byte field; specifies the number of descriptors returned to the initiator based on the field values specified in Type and Data type fields of CDB.

Get Configuration Command 0x46

This command is used to provide information of the overall capabilities of the logical unit. These are the fields that are most important for Windows (and that are tested in HCT 10 and later versions):

  • RT (Requested Type), 2-bit field; used to inform the device on what it should return.
  • 00b indicates that the logical unit must return all the supported features, no mater their current state.
  • 01b indicates that the logical unit must return only the supported features that are in an active state.
  • 10b will return only the feature that was indicated in the SFN bit or 0.
  • 11b reserved.
  • SFN (Starting Feature Number); used to determine the start location for retrieving the features. The maximum numbers of features that are supported are 65,536.
  • Allocation Length; used to tell the device the size of the current buffer.

Get Event/Status Notification 0x4A

This command requests the logical unit to report events and statuses as specified in the Notification Class Request field and provides asynchronous notification. These are the fields that are most important for Windows (and that are tested in HCT 10 and later versions):

  • IMMED (Immediate), 1-bit field; used specify the mode of the logical unit:
  • When set to 1 = Polling mode; logical unit must support this mode. In this case, the initiator will issue these commands at periodic intervals; the target must complete this command with the most recently available event status requested.
  • When set to 0 = Asynchronous mode; logical unit must support this mode. In this case, initiator will issue a single Get Event command. If the initiator requests asynchronous mode using a request that is not queued or overlapped, the command must fail as an illegal request.
  • Notification Class Request, 1-byte field; specifies that the logical unit report the event(s) from the event classes requested in this field.
  • Allocation Length; specifies the maximum Event Notification Response length in bytes that must be transferred from the logical unit to the initiator.

Inquiry Command 0x12

This command requests that information regarding parameters of the logical unit be sent to the host computer. This command must return data Check Condition status only when the logical unit cannot return the requested data. The Inquiry data should be returned even though the peripheral logical unit may not be ready for other commands. These are the fields that are most important for Windows (and that are tested in HCT 10 and later versions):

  • EPVD (Enable Vital Product Data), 1-bit field; specifies what type of information this command should return.

If set to 0, then it should return information such as:

Peripheral qualifier, peripheral device type, vendor identification, product identification, product revision level, vendor specific data, and so on.

If set to 1, then it should return the page identified by the Page or Operation Code field.

  • Page or Operation Code, 1-byte field; specifies which to be returned when EPVD bit is set to 1.
  • Allocation length field must indicate the maximum number of bytes that may be transferred to the host.
  • Command Support data (CmdDt), 1-bit field; used to request the logical unit return the command support data specified by the page or operation code field.
  • This capability is not used by CD or DVD logical unit. If this field is set to 1, the command should return Check Condition Status, 5/24/00 Invalid Field In CDB

Mode Select (10) 0x55

This command provides a means for the host to specify medium and logical unit parameters to the logical unit. Host should issue a Mode Sense (10) command prior to each Mode Select(10) command to determine supported pages, page lengths, and other parameters. These are the fields that are most important for Windows (and that are tested in HCT 10 and later versions):

  • SP (Save Pages), 1-bit field; when set to 0 indicates the logical unit must perform the specified Mode Select (10) operation, and must not save any pages. When set to 1 indicates that the logical unit must perform the specified Mode Select (10) command, and must save to a non-volatile vendor-specific location all the savable pages. If a logical unit support saved pages, it must save only one copy of the page.
  • Parameter List Length: This is a 2-byte field; specifies the maximum length in bytes of the mode parameter list that must be transferred from the host to the logical unit after the command packet is transferred. If the Parameter List length results in the truncation of any mode parameter header or mode Page, the logical unit must terminate the command with Check Condition Status, 5/1A/00 Parameter List Length error.

Mode Sense (10) 0x5A

The mode sense (10) Command provides a means for a logical unit to report parameters to the host. These are the fields that are most important for Windows (and that are tested in HCT 10 and later versions):

  • DBD (Disable Block Descriptor), 1-bit field; when set to 0, must specify that a Block Descriptor may be returned. When set to 1, indicates no block descriptor should return.
  • PC (Page Control), 2-bit field; defines the type of mode parameter values to be returned in the mode pages:

00b specifies Current values
01b specifies Changeable values
10b specifies Default values
11b specifies Saved values

  • Page Code, 6-bit field; specifies which Mode Page(s) to return. If a host issues a Mode Sense (10) command with a page code value not implemented by the logical unit, the logical unit must return the Check Condition status, 5/24/00 Invalid Field In CDB. A page code 3Fh indicates that al the Mode Pages implemented by the logical unit must be returned to the host.
  • Allocation Length, 2-byte field; indicates the size in bytes to be returned to the host.

It must return the requested page in the specified mode, provided page must be implemented by the logical unit; otherwise, an error 5/24/00 Invalid Field In CDB must be returned.

Prevent/Allow Medium Removal Command 0x1E

This command requests that the logical unit enable or disable the removal of the medium in the logical unit.

These are the fields that are most important for Windows (and that are tested in HCT 10 and later versions):

  • Persistent, 1-bit field; if set to 1, indicates that this will be a Persistent Prevent/Allow Medium Removal Command.
  • Prevent, 1-bit field; if set to 1, indicates prevent medium removal; if set to 0, indicates allow Medium removal.

All media after initial drive spin-up must remain locked in the drive until the host issues an eject request, or the persistent prevent status is reset and the hardware eject mechanism again becomes available.

Read (10) Command 0x28

This command requests that the logical unit must transfer data to the host. These are the fields that are most important for Windows (and that are tested in HCT 10 and later versions):

  • FUA (Force Unit Access), 1-bit field; when set to 0, indicates that the logical unit must access the media in performing the command. If set to 0, indicates that the logical unit may satisfy the command by accessing the cache memory.
  • Logical Block Address (LBA), 4-byte field; indicates the starting address from where the read operation starts.
  • Transfer Length, 2-byte field; specifies the number of contiguous logical blocks of data that must be transferred.

Although this command is capable of returning a variety of data, this command must only return the "user data" portion of sector.

Read (12) Command 0xA8

Read command request the logical unit transfer data to the initiator. The most recent data value written in the addressed logical block must be returned. These are the fields that are most important for Windows (and that are tested in HCT 10 and later versions):

  • Reladdr, 1-bit field.
  • DPO (Disable Page Out), 1-bit field; set to 0.
  • FUA (Force Unit Access), 1-bit field; when set to 1, indicates that the logical unit must access the media in performing the command. When set to 0, indicates that the logical unit may satisfy the command by accessing the cache memory.
  • Logical Address Block, 4-byte field; indicates the address from where the data is to be read.
  • Transfer Length, 4-byte field; specifies the number of contiguous logical blocks of data that must be transferred.
  • Streaming, 1-bit field; when set to 1, indicates that the stream playback operation must be used for the command. If set to 0, indicates that the conventional read operation must be used for this command.

Read CD Command 0xBE

This command provides a single standard, universal way of accessing CD data. This command is generic to all types of CD data formats. These are the fields that are most important for Windows (and that are tested in HCT 10 and later versions):

  • Reladr, 1-bit field; must be set to 0.
  • Expected Sector Type, 3-bit field; used as a filter or mask to select the types of data format information returned to the initiator. The sector or sectors that do not match will not be transferred to the initiator.

000b, indicates all types of sectors (required)
001b, CD-DA
010b, Mode1 (required)
011b, Mode 2 formless (required)
100b, Mode 2 form1 (required)
101b, Mode 2 form 2 (required)
110b-111b, reserved

  • Starting Logical Block Address, 4-byte field; specifies the logical block that the read operation must begin.
  • Sync, 1-bit field; when set to 1, indicates that the Sync field from the sector must be included in the data stream. When set to 0, indicates that the Sync field must not be included in the data stream.
  • Header Code, 2-bit field; encoded to select header/Sub-header information that should be included in the returned data stream:

00b = none
01b = header only
10b = sub-header only
11b = all headers

  • User Data, 1-bit field; when set to 1, indicates that the user data part of a CD sector must be Returned in the data stream. When set to 0, indicates user data must not be returned to the initiator.
  • EDC &ECC, 1-bit field; when set to 1, indicates that the EDC&ECC field must be included in the data stream. When set to 0, indicates that EDC&ECC data must not be included in the data stream.
  • Error Field, 2-bit field; used to specify that if any of the C2 and/or Block error data will be included in the returned data stream. Encoded as follows:

00b = none
01b = C2 error block data
10b = C2 and Block Error bits
11b = reserved

  • Sub-channel selection bits, three-bit field; indicates that CD sub-channel information is to be included in the data stream. Encoded as follows:

000b = no sub-channel
001b = RAW
010b = Q
011b = Reserved
100b = P-W
101b-111b = Reserved

  • Transfer length, 3-byte field; specifies the size in bytes to be returned in response to the command.

Read CD MSF Command 0xB9

This command provides a single standard command format for accessing CD data via MSF addressing. These are the fields that are most important for Windows (and that are tested in HCT 10 and later versions):

  • Starting M Field, 1-byte field; specify the starting Minute field of the MSF address format.
  • Starting S Field, 1-byte field; specifies the starting Second field of the MSF address format.
  • Starting F Field, 1-byte field; specifies the starting Frame field of the MSF address format.
  • Ending M Field, 1-byte field; specifies the ending Minute field of the MSF address format.
  • Ending S Field, 1-byte field; specifies the ending Second field of the MSF address format.
  • Ending F Field, 1-byte field; specifies the ending Frame field of the MSF address format.
  • Sector type, 3-bit fields; for description, see "Read CD Command 0xBE"

Read Capacity Command 0x25

This command provides a means for the initiator to request information regarding the capacity of the logical unit. These are the fields that are most important for Windows (and that are tested in HCT 10 and later versions):

  • Reladr, 1-bit field.
  • Logical Block Address, 4-byte field.
  • PMI, 1-bit field.

Read Disc Information Command 0x51

This command provides information about all discs. The parameters returned by the logical unit are specific to the media that is currently installed in the logical unit. One field is most important for Windows (and is tested in HCT 10 and later versions):

  • Allocation Length, which specifies the number of disc information bytes returned.

Read DVD Structure 0xAD

This command requests that the DVD logical unit transfer data from areas on the DVD Media to the initiator. These are the fields that are most important for Windows (and that are tested in HCT 10 and later versions):

  • Address field, 4-byte field; values depend on the values in the Format field.
  • Format field, 1-byte field; indicates the type of information requested by the initiator.

The address field values will be, according to format field, as follows:

  • If format field has 05h, the address field will be LBA
  • If format field has 0Ch, the address field contains the field number of RMD block that is recorded in the last Border-out. Field numbers of RMD block are integers assigned in ascending order in the range of 0 to 14.
  • If format field is 0Dh, address field will contains sector number of RMA where the RMA read operation must begin. The RMA sector size is 2KB. The RMA number is assigned to each sector of RMA.
  • If format field has 30h, address field will contain the Content Descriptor desired.

For other formats, the address field is reserved.

  • Layer Number, 1-byte field; specifies the layer number for the response data returned by the READ DVD Structure command.
  • Allocation Length, 2-byte field; specifies the size of the response returned to the initiator
  • AGID, 2-bit field; used only when Format field has 2h; for all other values, it is reserved.

Read Format Capacities Command 0x23

This command allows the initiator to request a list of the possible format capacities for an installed random-writable media. The allocation length field specifies the maximum number of bytes that an initiator has allocated for returned data.

Read TOC/PMA/ATIP Command 0x43

This command requests that the logical unit transfer data from the table of contents, the program memory area (PMA), and the Absolute Time in Pre-Grove (ATIP) from CD media. These are the fields that are most important for Windows (and that are tested in HCT 10 and later versions):

  • MSF, 1-bit field; when set to 0, indicates that LBA format should be used for the address and offset. If set to 1, indicates that MSF format of addressing should be used.
  • Format, 4 bit field; specifies the nature of the response data, usage of track/session field, returned to the initiator. Encoded as follows:
  • 0000b = TOC data should be returned for the specified track number.
  • 0001b = session info should be returned; track/session field is reserved.
  • 0010b = Full TOC data should be returned for the specified session number.
  • 0011b = PMA data should be returned; track/session field is reserved.
  • 0100b = ATIP; returns the ATIP format; track and session number is reserved.
  • 0101b = CD-TEXT, which is information that is recorded in the lead-in area as R-W Sub-channel Data should be returned; track/session field is reserved.
  • All other format codes are reserved.
  • Track/Session Number field, 1-byte field; specifies the starting track number for which the data must be returned. A value of AAh requests that the starting address of the lead-out area be returned.

If the track/session field is not valid for the currently installed medium, the command must be terminated with Check Condition Status.

  • Allocation Length, 2-byte field; specifies the maximum size of the response in bytes.

Read Track Information 0x52

This command provides the information about a track, regardless of its status. These are the fields that are most important for Windows (and that are tested in HCT 10 and later versions):

  • Address/Number type, 2-bit field; specifies the type contents in the LBA/Track/session number field in the CDB.
  • LBA/Track/Session Number, 4-byte field; used to specify the block, track, session number of which information to be read. Encoded, based on the Address/Number type field as follows:
  • 00b = this field will have LBA.
  • 01b = this field can have 00h, valid track number, and FFh for lead-in area of the disc, track number, and track number of invisible or incomplete track.
  • 10b = this field will have a session number.
  • 11b = this field is reserved.
  • Allocation Length, 2-byte field; specifies the response size in bytes.

For CD, if TOC/PMA is unreadable, the command must be terminated with Check Condition Status, sense code of Unable To Recover Table-Of-Contents.

For DVD, if RMA/RMD in border-out is unreadable, the command must terminate with Check Condition Status, sense code L-EC Uncorrectable Error.

Request Sense 0x03

The Request Sense Command requests the logical unit to transfer sense data to the host. One field is most important for Windows (and is tested in HCT 10 and later versions):

  • Allocation Length Field, 1-byte field; must be set to at least 18 bytes.

The sense data of at least 18 bytes (if less than 18 bytes, the host should assume the rest of the bytes are zeros) must be available if:

  • An error condition (Check Condition) had previously been reported to the Host.
  • Other information is available in any field.

If the logical unit doesn’t have, any sense information to return, it should return a sense key of NO SENSE.

Send OPC Information 0x54

This command is used to restore the Optimum Power Calibration (OPC) values to the logical unit for a specific disc. For CD, it is used in conjunction with the Read Disc Information command. These are the fields that are most important for Windows (and that are tested in HCT 10 and later versions):

  • DoOpc, 1-bit field; if set to 1, indicates the logical unit must perform an OPC operation to set the OPC values for the current speed. These OPC values must become current. If set to 0 indicates the logical unit sets OPC values to those sent in the Parameter List.
  • Parameter List length, 2-byte field; indicates the number of the parameter bytes to be transferred. This value must be an integral multiple of 8.

The host must transfer 0 or more OPC table entries.

If the host will send more that one OPC table entries with the same value in the OPC Speed field, the command must terminate with Check Condition status, 5/26/00 Invalid Field In Parameter List.

The response for this command will be of 8 bytes, having OPC speed in KB per second and OPC value.

Start/Stop Unit Command 0x1B

This command requests that the logical unit enable or disable media access operations.

These are the fields that are most important for Windows (and that are tested in HCT 10 and later versions):

  • Immed, 1-bit field; if set to 0, indicates the status should be returned after the operation is completed. If set to 1, indicate the status should be return as the Command packet has been sent.
  • Start, 1-bit field; if set to 1, requests the logical unit be made ready for use. If set to 0, indicates that the logical unit be stopped.
  • LoEj (load/eject), 1-bit field; if set to 1, indicates that the medium be unloaded if the start bit is 0, if set to 0, indicates that no action be taken regarding loading or ejecting. If set to 1 and start bit is 1, indicates that the medium be loaded.
  • Power condition, 4-bit field; requests the logical unit be placed into the power state. If any bit is set in this field, then the start and the LoEj bits must be ignored. Encoded as follows:
  • 0h = No change in power conditions or in which logical unit is controlling power conditions.
  • 1h = reserved.
  • 2h = place logical unit into the Idle state; standby timer is reloaded
  • 3h = place logical unit into the Standby state.
  • 4h = reserved.
  • 5h = Place logical unit into sleep state. Before entering the sleep state, all buffers must be successfully flushed by the logical unit. If the sleep command is successful, the host must not issue new commands after receiving the successful completion status.
  • 6h – Fh = Reserved

Synchronize Cache Command 0x35

This command assures all remaining data in the data buffer has been written to the media. Logical blocks are not necessarily removed from the cache memory as a result of the cache flush operation. These are the fields that are most important for Windows (and that are tested in HCT 10 and later versions):

  • Immed, 1-bit field; if set to 1, indicates that the logical unit must return status when the command descriptor block has been validates. If set to 1, the status should come after completion of command.
  • Logical Block Address, 4-byte field; may be ignored by the logical unit.
  • Number of blocks, 2-byte field, specifies the number of contiguous logical blocks within the range.

Test Unit Ready 0x00

This command provides a means to check whether the logical unit is ready.

Verify (10) 0x2F

This command requests the logical unit to verify data on the medium. These are the fields that are most important for Windows (and that are tested in HCT 10 and later versions):

  • BlkVfy, 1-bit field; when set to 1, causes the verification of blank pages.
  • Logical Block Address, 4-byte field; indicates the starting address for the verification.
  • Verification Length; specifies the number of contiguous logical blocks of data or blanks that must be verified

Write (10) 0x 2A

This command must use the write parameters mode page to determine its operating behavior. These are the fields that are most important for Windows (and that are tested in HCT 10 and later versions):

  • Reladr, 1-bit field; must be set to 0
  • FUA (Force Unit Access), 1-bit field; if set to 1, indicates that the logical unit should access the media in performing the command before returning GOOD status. If set to 1, indicates that logical unit may satisfy the command by accessing the cache memory.
  • DPO (Disable Page Out), 1-bit field; if set to 1, indicates that the logical unit must assign the logical blocks accessed by this command the lowest priority for being fetched into or retained by cache. If set to 0, indicates that the priority must be determined by the Retention Priority fields in the cache page. Logical unit may ignore this field.
  • Logical Block Address, 4-byte field; indicates where the write operation must begin.
  • Transfer Length, 2-byte field; indicates number of contiguous logical blocks of data that must be transferred.

Write (12) 0xAA

This command requests that the logical unit write the data transferred from the initiator to the medium. These are the fields that are most important for Windows (and that are tested in HCT 10 and later versions):

  • Reladr, 1-bit field; set to 0.
  • EBP (()), 1-bit field; set to 0.
  • FUA (Force Unit Access), 1-bit field; if set to 1, indicates that the logical unit should access the media in performing the command before returning GOOD status. If set to 1, indicates that logical unit may satisfy the command by accessing the cache memory.
  • DPO (0), 1-bit field; logical unit may ignore this field.
  • Transfer Length, 4-byte field; indicates the length of the data written; must be an integral multiple of Blocking factor.
  • Logical Block Address, 4-byte field; indicates the logical block where the write operation must occur.

Write And Verify (10) 0x2E

This command requests the logical unit to write data transferred from the initiator to logical unit and verify after writing that data is correctly written. These are the fields that are most important for Windows (and that are tested in HCT 10 and later versions):

  • Logical Block address, 4-byte field; indicates where data is to transfer.
  • Transfer Length, 4-byte field; indicates the length of the data to be transferred.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Profiles define a base set of functions for logical units. Logical units that list a profile as current must support all features required by that profile. Logical units may support some features in addition to those required by the profile.

List of Commands for Every Current Profile

DVD RAM/RW | Get configuration Prevent/Allow Medium removal Test Unit Ready Mode Sense10 Write10 Set CD Speed Send OPC Information Read Format Capacity Format Synchronize Cache Read10 ReadTOCPMAATIP ReadDVDStructure Write And Verify Read Capacity Read12. Start/Stop Unit.
DVD ROM | Get configuration Prevent/Allow Medium Removal Mode sense10 ReadTOCPMAATIP Read Capacity Read10 Read DVD Structure Read12 Start/Stop Unit.
DVD R | Get configuration Prevent/Allow Medium Removal Mode sense10 Mode select 10 ReadTOCPMAATIP Read Capacity Read Disc Information Set CD Speed Send OPC Information Blank Read Track Information Read DVD Structure Read10 Read12. Start/Stop Unit.
CD R | Get Configuration Prevent/Allow Medium Removal Mode sense10 Mode Select 10 ReadTOCPAMAATIP Read Disc Information Read Track Information Read Capacity Set CD Speed Send OPC Information Write10 Read CD Read CD MSF Read 10 Read 12 Start/Stop Unit.
CD RW | Get configuration Prevent/Allow Medium Removal Mode sense10 Mode Select10 ReadTOCPAMAATIP Read Disc Information Read Track Information Set CD Speed Send OPC Information Blank Write10 Read10 Read CD Read CD MSF Read12 Start/Stop Unit.

A CD-R/RW drive that identifies itself as CD-RW capable must support the following capabilities:

Capability | Description
Profile List | A list of all profiles supported by the device.
Core | Basic functionality.
Morphing | Ability to notify Initiator about operational changes and accept Initiator requests to prevent operational changes.
Removable Medium | The medium may be removed from the device.
Random Readable | Read ability for storage devices with random addressing.
Multi-Read | The Logical Unit complies with OSTA Multi-read.
CD Read | The ability to read CD specific structure.
Incremental Streaming | Write support for sequential recording.
Formattable | Support for formatting the media.
Restricted Overwrite | Write support for media that shall be written in multiples of Logical blocks.
CD Track at once | Ability to write CD with track at once recording.
Defect management | Ability of the drive/media system to provide an apparently defect-free space.
Power management | Initiator and device directed power management.
Timeout | Ability to respond to all commands within a specific time.
Real-Time Streaming | Ability to read and write using Initiator requested performance parameters.

Required Hardware

DVD writer in your machine

Hard drive with at least 800M free space for the stash file generated by IMAPI

Required Software

IMAPI

Results Interpretation

When called MAPI creates both good scenarios and bad scenarios. Then it checks the actual outcomes with the expected ones, logs the results of the comparison and reports the unexpected outcomes.


TD-28.14 Storage Data Verification Filter Test Description

Test Kit: HCT 11

This test checks the disk system to ensure no data corruption occurs. The test verifies data by generating a checksum on each disk write, and verifying the checksum on each disk read. In the case of a checksum mismatch, the test logs an error to a file (DataVerFilter.log).

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Operating system: Windows XP Professional; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition; Windows .NET Server 2003, Datacenter Edition

The tests in the Storage HCT kit are used in several different test system configurations in each test category. Please refer to the test procedure documentation for your specific test category for information on required system configurations and test procedures.

Results Interpretation

The results are written to a log file (DataVerFilter.log). To pass the test, no CRC checksum errors must occur on any disk read or write access.


TD-28.15 DCDP 14-Day Stress (Storage) Test

This is preliminary documentation and subject to change.

Test Kit: HCT 11

Overview

The Datacenter Driver Program (DCDP) 14-Day Stress (Storage) test is designed to test device and driver compliance with the requirements for Datacenter driver qualification. Testing for this qualification is 14 days long, and the criterion for passing the test is 100% completion without failure. Devices and drivers that achieve these qualifications have met the highest standards of Microsoft testing.

For more information about the Datacenter Driver Program, see the white paper at http://www.microsoft.com/hwdev/platform/server/datacenter/default.asp

The DCDP 14-Day Stress (Storage) test is based upon extended versions of several storage device and controller tests and is designed to stress SCSI controllers, Fibre Channel controllers, RAID controllers, and RAID systems.

Disk stress test

This test verifies that the storage devices and controllers correctly read and write data. The test uses multiple threads to read, write, and verify a 1-MB pattern to stress disk drive access against supported SCSI, ATA/ATAPI, Fibre Channel, and RAID hardware arrays. The test writes the pass or fail results to the log file Diskload.log.

SysCache test

This test places the device under stress by reading, writing, and verifying data written to system cache. For information about the individual test cases, see the TD-21.15 ReadWrite File System Test Group. The test writes the pass or fail results to the log file Drvcache.log.

Datacenter SQL I/O test

This file system stress test simulates the activity of a local file system running Microsoft SQL Server. The test first creates two files of size 2 GB each that serve as the database. After the data files are created and verified, the test spawns multiple threads that begin random asynchronous I/O operations on the data files. The I/O operations include unbuffered 16-KB read/write I/O requests. The read/write ratio is 3:2. The test is configured to maintain 400 I/O requests pending. The test writes the detailed results to the file Dtc_sqlio.log. For more information about the test, see the TD-30.13 DTC_Sqlio Test Description.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The following software is required (at a minimum):

  • Windows .NET Server 2003, Enterprise Edition

Results Interpretation

The test generates a detailed log file of test results and displays on-screen pass or fail status. The name of the log file is Dcdpstrs.log. To pass, the test must run to completion without failure. For information about the specific tests, you can use Test Manager and the Log Viewer to check the individual test logs. Note that the individual tests do not have to pass for the device and driver to receive an overall pass. The individual tests are primarily used to stress the driver.

Click to show or hide information. Debugging a test failure

There are several conditions that can cause the DCDP 14-Day Stress test to fail. When the test fails, the system can become unresponsive, or a bug check can occur. However, if you have a kernel debugger attached to the server, it is possible to debug or obtain more information about the failure.

For information about using a kernel debugger, see the Debugging Tools for Windows package. This package includes the Microsoft Windows Debugger (WinDbg), which can be used for user-mode and kernel-mode debugging. This package also includes detailed documentation that describes setting up and using a kernel debugger.

You can install the Debugging Tools for Windows from the Customer Support Diagnostics CD, the Platform SDK, the Windows DDK, or from the Web at http://www.microsoft.com/ddk/debugging.


Chapter 29: Headless Test Tool Test Specification

Overview

Windows XP provides native support for "headless server" operation (no keyboard, mouse, or monitor present),on x86-based platforms. Support for full headless server operation for Intel Itanium-based platforms will be available in a future version of Windows after Windows XP.


Reference Documents for Headless Test Assertions

Extensions to VT100 Terminal Definition

http://www.microsoft.com/hwdev/platform/server/headless/default.asp

Hardware Design Guide Version 3.0 for Microsoft Windows 2000 Server

http://www.microsoft.com/hwdev/platform/pcdesign/desguide/serverdg.asp
(referred to as "SDG3" in this chapter)

Microsoft Windows Logo Program System and Device Requirements, Version 2.0

http://www.microsoft.com/hwdev/winlogo/
(listed as "WLP#" in these assertions)

Serial Port Console Redirection Table

http://www.microsoft.com/hwdev/platform/server/headless/default.asp


Headless Support Test Tool Test Assertions

This section contains the detailed list of test assertions.
Assertions are tested in TD-29.1 Headless Support Test Description.

29.1.1 There must be a valid ACPI Serial Port Console Redirection table.

If no valid SPCR table is detected, a brief message is displayed on the system console informing the user.

Reference document: WLP# - B4.2.1; SDG3:21.2; Serial Port Console Redirection Table
Test description: TD-29.1 Headless Support Test Description

29.1.2 The Universal Asynchronous Receiver/Transmitter (UART) module must be able to be accurately initialized with data from SPCR table.

Assuming a valid SPCR is found, several of the significant settings will be displayed. The UART is then initialized and tested for authenticity (the data given in the SPCR table may not be pointing to a valid UART).

Reference document: WLP# - B4.2.1; SDG3:21.2; Extensions to the VT100 Terminal Definition
Test description: TD-29.1 Headless Support Test Description

29.1.3 The loop back test must be able to be accurately performed on the UART.

If the UART is deemed to be valid (a standard loop back test is used), then a validation message will be displayed.

Reference document: WLP# - B4.2.1; SDG3:21.2; Extensions to the VT100 Terminal Definition
Test description: TD-29.1 Headless Support Test Description

29.1.4 Data must be able to be accurately sent through the UART.

If the UART is deemed to be valid, then a random string is generated. The random string is then sent through the UART. The test will then wait for the user to enter the string back. The results of the users input are then tested against the original random string to ensure they match.

Reference document: WLP# - B4.2.1; SDG3:21.2; Extensions to the VT100 Terminal Definition
Test description: TD-29.1 Headless Support Test Description

29.1.5 Data must be able to be accurately returned through the UART.

If the strings match, the user will see a confirmation message.

Reference document: WLP# - B4.2.1; SDG3:21.2; Extensions to the VT100 Terminal Definition
Test description: TD-29.1 Headless Support Test Description

29.1.6 The UART must accurately report errors.

If the strings do *not* match, the user will see a confirmation message.

Reference document: WLP# - B4.2.1; SDG3:21.2; Extensions to the VT100 Terminal Definition
Test description: TD-29.1 Headless Support Test Description

29.1.7 UART test results must be accurately recorded.

Once the test has completed, the test will create a file on the boot media called Spcrtest.txt. A pass/failure message will be written to the logfile.

Reference document: WLP# - B4.2.1; SDG3:21.2; Extensions to the VT100 Terminal Definition
Test description: TD-29.1 Headless Support Test Description


Headless Test Tool Test Descriptions

This section contains the detailed test descriptions.

TD-29.1 Headless Support Test Description

Overview

The headless support test will determine the existence and validity of an ACPI Serial Port Console Redirection (SPCR) table. The test will attempt to detect this table, and if a valid table is discovered, several additional steps will be taken.

Several of the significant settings will be displayed.

The settings will be used to attempt initialization of a UART.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

It is important to note that this test must be run in real-mode. No OS support is required. For that reason, the test poses as an OS loader and executes when the machine’s BIOS attempts to boot from media (putting the test on a floppy works very well). The following steps should be used to prepare the test:

  1. Format a floppy so that a boot sector gets written to it (this happens automatically under NT/Windows2000/Windows XP).
  2. Copy the test to the floppy, carefully renaming it ntldr.
  3. Reboot the machine and allow it to boot from this floppy.

Results Interpretation

  • If no valid SPCR table is detected, a brief message is displayed on the system console of the form: "No SPCR table detected.".

The test will walk the ACPI tables, looking for a table with the signature "SPCR". If such a table is found, a checksum is performed, the UART address is tested against NULL, and the AddressSpaceID field is tested against 0 (system I/O) and 1 (memory mapped I/O). If these pass, the SPCR table is deemed to be present.

  • Assuming a valid SPCR is found, several of the significant settings will be displayed. The UART is then initialized and tested for authenticity (the data given in the SPCR table may not be pointing to a valid UART).

There is no test here.

  • If the UART is deemed to be valid (a standard loop back test is used), then a validation message will be displayed: "UART address verified."

The UART is put into loop back mode. It is important that emulated UARTs support loop back mode.

  • If the UART is deemed to be valid, then a random string is generated. The random string is then sent through the UART of the form: "Please enter the following test string: '%d'\r\n", RandomNumber1". The test will then wait for the user to enter the string back. The results of the users input are then tested against the original random string to ensure they match.

The user should ensure that the UART address and baud rates shown match what the actual hardware is supporting. This will be the likely cause of failure in this step.

  • If the strings match, the user will see a message of the form: "Identical string returned. '%d'\r\n", RandomNumber2"

If the strings do not match, the user will see a message of the form: "Inconsistent string returned. '%d'\r\n", RandomNumber2". Program control is then sent back up to step 4.

The test will be reading input from the UART, so it is important that communications to the UART be validated.


Chapter 30: Datacenter Server Test Specification

This chapter specifies tests that determine compliance with key requirements for Datacenter servers as defined in the Microsoft Windows Logo Program System and Device Requirements.

This chapter is intended as an overview of the tests, and as a guide to actual test development for software engineers. It is not designed to provide a complete test plan or testing procedures for Datacenter servers.

Overview

Windows .NET Server 2003, Datacenter Edition is designed for enterprises that need very reliable high-end hardware and software for high-traffic computer networks. These test specifications describe the stress tests that use a set of clients and a remote test host to simulate real-world server scenarios.

Datacenter Server Stress tests

These tests run in the background to provide a stress load, and if they do not fail, and the system runs for the specified time, the test run is a success.

The stress tests include the following types of client-server tests:

  • File I/O using a Server Message Block (SMB) share
  • Telephony Application Program Interface (TAPI) test
  • Internet Information Server (IIS) tests
  • Winsock test
  • Local server-based file system tests

These tests are designed to stress the most common server services that users run on a high-end server system. By default, these tests run for 14 days, as required for Datacenter validation, at which time the tests shutdown. The log files from the individual test are examined and summarized into one log file on the client master. This summary log (Dcsrvtst.log) is used for submitting the results to WHQL. If the server fails the test, you can examine the individual log files on the client and server systems in detail to determine the specific reasons for failure during the test run.

The client-server tests are distributed across the client nodes. Not all tests run on each client. The client tests use the name of the server or one of the associated IP addresses to access the server services.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The following software is required:

  • Windows .NET Server 2003, Datacenter Edition operating system installed on the test server.
  • Windows .NET Server 2003, Standard Edition operating system installed on the remote test host and each of the eight desktop client machines.

For test procedures and the specific hardware and software requirements, see the Datacenter Server Stress test in the HCT kit.

Results Interpretation

The Datacenter Server Stress test writes the pass/fail results to the summary log file Dcsrvtst.log.


Datacenter Server Test Assertions

This section contains the detailed list of test assertions for Datacenter Server tests

File I/O using a Server Message Block (SMB) share Tests Assertions

The Assertions for the File I/O using a Server Message Block (SMB) share Tests are tested in TD-30.1 Lrgfile Test Description, TD-30.2 Mapfile Test Description, TD-30.3 Unbuf Test Description, TD-30.4 FsCmprsn Test Description, TD-30.5 FSSTRS_SRV\CLNT Client/Server Test Description

30.1.1 The file I/O must be operational over a SMB share.

Operations tested include reads/write I/Os, unbuffered, asynchronous, mapped I/O and NTFS compression

Reference document: WLP# - B7.0; Platform DDK (Files and I/O)
Test description: TD-30.1 Lrgfile Test Description, TD-30.2 Mapfile Test Description, TD-30.3 Unbuf Test Description, TD-30.4 FsCmprsn Test Description, TD-30.5 FSSTRS_SRV\CLNT Client/Server Test Description


TAPI API Tests Assertions

The Assertions for the Telephony Application Program Interface (TAPI) API Tests are tested in TD-30.6 Srvapp Test Description, TD-30.7 Tclient Test Description, TD-30.8 Clntapp Test Description

30.6.1 The TAPI 2.2 API implementation must behave as described in the published Platform SDK.

Reference document: WLP# - B7.0; PC 2001 System Design Guide, Telephony; Platform SDK (Networking and Directory Services, Network Communication, Telephony Application Programming, TAPI Version 2.2)
Test description: TD-30.6 Srvapp Test Description, TD-30.7 Tclient Test Description, TD-30.8 Clntapp Test Description


Winsock Sock_Srv/Sock_Clnt Test Assertions

Assertions in this section are tested in TD-30.11 Winsock Sock_Srv/Sock_Clnt Test Description

30.11.1 The server must have the ability to accept a large number of TCP connections without adversely affecting the system.

Reference document: WLP# - A6.4.8
Test description: TD-30.11 Winsock Sock_Srv/Sock_Clnt Test Description


Local Server-based file System Tests Assertions

The Assertions for the Local server-based file system Tests are tested in TD-30.12 DTC_Bangfs Test Description, TD-30.13 DTC_Sqlio Test Description

30.12.1 The file I/O must be operational on a local volume.

Operations tested include NTFS compression, encryption, mapped i/o, USN, streams, reparse points, sparse files, object ids and extended attributes. Also tests data integrity in a simulated SQL database scenario.

Reference document: WLP# - B7.0; Platform DDK (Files and I/O)
Test description: TD-30.12 DTC_Bangfs Test Description, TD-30.13 DTC_Sqlio Test Description


IIS Stress Test (Webslug) Test Assertions

Assertions in this section are tested in TD-30.14 IIS Stress Test (Webslug) Description

30.14.1 The server must have the ability to accept a large number of hits, valid and invalid requests, at random without adversely affecting the system.

Reference document: WLP# - B7.1.4.1; B7.1
Test description: TD TD-30.14 IIS Stress Test (Webslug) Description


Print Test Assertions

Assertions in this section are tested in TD-30.15 Print Test Description

30.15.1 The print server must be able to accept print jobs and all print jobs must be able to be successfully de-spooled.

Reference document: WLP# - B8.1.1.1
Test description: TD-30.15 Print Test Description


DTC Shutdown/Restart Test Assertions

These assertions are tested in TD-30.16 DTC Shutdown/Restart Test.

30.16.1 The system must shutdown remotely without requiring intervention. This shutdown must occur while the system is under stress created by client systems accessing system local resources and processes local to the system.

The system must shutdown remotely without requiring the intervention of any of the following services or tools:

  • Local system Task Manager
  • Special operating system management tools such as tlist or kill on the server system
  • Operating system management tools such as EMS on the server system
  • Operating system and OEM management tools such as SAC EMS on the server system
  • System locally initiated hardware reset switch
  • System locally initiated hardware crash/NMI switch
  • System locally initiated hardware power switch
  • Service Processor or Remote Management adapters that in any way can force a shutdown, reset or power cycle

Reference document: WLP# - A1.1.2; Windows Driver Development Kit
Test description: TD-30.16 DTC Shutdown/Restart Test

30.16.2 The system must reboot without device or driver conflicts (including device interrupt conflicts, device memory range conflicts, and device DMA channel conflicts).

This assertion is verified by checking that there are no errors in the boot log (Ntbtlog.txt), the system event log, and in the devnode object tree of the operating system.

Reference document: WLP# - A1.1.2; Windows Driver Development Kit
Test description: TD-30.16 DTC Shutdown/Restart Test


Datacenter Server Test Descriptions

Test Kit: HCT 11

The Datacenter Server Stress tests can be grouped into the following types of tests:

  1. File I/O using a Server Message Block (SMB) share
  • Lrgfile Test
  • Mapfile Test
  • Unbuf Test
  • FsCmprsn Test
  • FSSTRS_SRV\CLNT Client/Server Test
  2. Telephony Application Program Interface (TAPI) test
  • Srvapp Test
  • Tclient Test
  • Clntapp Test
  3. Internet Information Server (IIS) tests
  • Gqstress Test
  • Ftpstress Test
  4. Winsock test
  • Sock_Srv/Sock_Clnt Test
  5. Local server-based file system tests
  • DTC_Bangfs Test
  • DTC_Sqlio Test

These tests are designed to stress the most common server services that users will run on a high-end server system.


TD-30.1 Lrgfile Test Description

Overview

This test creates a large file, and then reads backward, shrinking the file while checking read data.

The Lrgfile test uses unbuffered I/O only and retries on every file I/O operation.

You do not need to know the syntax of these test programs. Test Manager starts the test when it is run on each client machine. If the server is set up using the well-known names that Microsoft provides, no further input will be required.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Software

The following software is required:

  • Windows .NET Server 2003, Datacenter Edition operating system installed on the test server.
  • Windows .NET Server 2003, Standard Edition operating system installed on the remote test host and each of the eight desktop client machines.

For test procedures and the specific hardware and software requirements, see the Datacenter Server Stress test in the HCT kit.

The Lrgfile test requires 4 MB of space on the tested drive. If there is not enough space, the Lrgfile test exits.

Results Interpretation

If the Lrgfile test fails, look for the file Lrgfile.log. This log file contains error information and the reason(s) for failure. Because the Lrgfile test is run with the -Vn switch (leaving n MB of free space on disk), a common problem is not having enough space to start the test. The Lrgfile test retries 15 times with 1-second pause between retries before exiting with this error. Another common problem is disk media failure. Such a problem is reported as data corruption because expected data was not read from the disk. To eliminate that kind of error run the Lrgfile test locally on the server. You can find Lrgfile.exe in your HCT\Testbin directory, or on HCT CD. Copy it on server node and run the following command from the Windows command prompt.

lrgfile -r10 -p32 -b8 -dX:

-r10 means run 10 times

-p32 means that the Lrgfile test will use 32*4 KB chunks of data for each write/read operation

-b8 means that the Lrgfile test will use 8 buffers for asynchronous write/read

-dX: replace X with suspected shared drive letter. Be sure that the disk is online on the node that runs the Lrgfile test!

The Lrgfile test creates a temporary file that will grow until it consumes entire available disk space. The test then reduces the size of the file while checking data. Do not move/failover disk resources during this test. After the Lrgfile test finishes, look in the log file Lrgfile.log (in the same directory Lrgfile.exe was run from) and search for data errors (for example, Disk data error: Chunk#xpct 0x12, chunk#got 0x0, Page#=0). If you see this error your disk likely failed and is unreliable. If your disk passes this test, but does not pass the node test with random moves/failovers, it may point to the cache problem. If both tests pass, but the client test does not, it points to a problem in the redirector. In this case, data was not written on the disk, but was cached (usually on hardware level) and reported as saved at the time before the failover/move.

Most of other errors are either due to network failure.


TD-30.2 Mapfile Test Description

Overview

This file system test sets up memory-mapped files to the server. It then modifies a section of the mapped file, committing these changes to disk by flushing the file mapping. After the flush operation is complete, the test reads the data back into memory and then verifies that the correct data was written to the disk. If a failover happens before the flush operation, all changes are discarded and the test restarts.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Software

The following software is required:

  • Windows .NET Server 2003, Datacenter Edition operating system installed on the test server.
  • Windows .NET Server 2003, Standard Edition operating system installed on the remote test host and each of the eight desktop client machines.

For test procedures and the specific hardware and software requirements, see the Datacenter Server Stress test in the HCT kit.

Results Interpretation

The Mapfile test requires 4 MB of space on tested drive. If there is not enough space, the Mapfile test exits. Another common problem is network failure. If the test fails because of data corruption problems (read data differs from expected data), the cause is not easy to determine. In most cases, the data was not written on the disk, but was cached (usually on hardware level) and reported as saved at the time prior to the failover/move. For information on how to eliminate disk-media problems, see the Results Interpretation section in the Lrgfile test description.


TD-30.3 Unbuf Test Description

Overview

This test (ios_unbufw.exe) performs asynchronous writes and reads in various combinations in attempt to stress parts of the asynchronous I/O system. This test uses completion ports to perform the asynchronous I/O.

The different variables for test combinations include:

  • Buffered/unbuffered I/O
  • Pre-allocated disk space/new file
  • Extending existing file/over writing existing file
  • Size of the target file
  • Number of concurrent I/O threads
  • Size of each I/O

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Software

The following software is required:

  • Windows .NET Server 2003, Datacenter Edition operating system installed on the test server.
  • Windows .NET Server 2003, Standard Edition operating system installed on the remote test host and each of the eight desktop client machines.

For test procedures and the specific hardware and software requirements, see the Datacenter Server Stress test in the HCT kit.

Results Interpretation

The I/O is written out in a computable pattern and then read back and verified. If an error is detected, the test will optionally force a break into the debugger so that someone familiar with the inner workings of file systems can examine the state of the system. In the HCT kit, this feature is disabled and errors are simply written to the log file (Unbufw.log).


TD-30.4 FsCmprsn Test Description

Overview

The file system compression test (Ios_fscmprsn) is a stress test written to exercise the NTFS compression engine. This test can also run on FAT and other file systems.

To exercise NTFS compression, the test performs the following algorithm

  1. Walks the specified <srcDirectory> (tree).
  2. Inserts the contents of readable files into Fscmprsn.dat. This insertion begins at the end of the file, plus or minus a randomly chosen delta. In this manner, the test grows the file, by default, up to 5 MB.
  3. Verifies the contents of the file. The test does this by reconstructing the files contents in sections and then doing a comparison.
  4. Toggles the file's compression state.
  5. Repeats steps 3, and then 4, and then 3.
  6. Deletes Fscmprsn.dat
  7. Continues at step 1, (at the next file) until there are no more files in the tree.

For the HCT kit, after step 7 the test deletes the Fscmprsn.dat file and starts over at the beginning of the source tree. The %Windir% directory is used for the <srcDirectory>. As such, the test ignores files that cannot be opened shared for read access.

This stress test deliberately forces NTFS to handle writes in the middle of a compressed file, as well as extending and truncating an existing compressed file.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Software

The following software is required:

  • Windows .NET Server 2003, Datacenter Edition operating system installed on the test server.
  • Windows .NET Server 2003, Standard Edition operating system installed on the remote test host and each of the eight desktop client machines.

For test procedures and the specific hardware and software requirements, see the Datacenter Server Stress test in the HCT kit.

Results Interpretation

If an error is detected, the test will optionally force a break into the debugger so that someone familiar with the inner workings of file systems can examine the state of the system. In the HCT kit, this feature is disabled and errors are logged.


TD-30.5 FSSTRS_SRV\CLNT Client/Server Test Description

Overview

The test creates a hierarchy of directories and files under a given path. You can specify the number of directories and files created as well as the percentage of disk space to be utilized while doing so.

The files that are created can be .doc files, reparse points, sparse files or regular files. The test provides options to set Object ID’s on the files. The files can also optionally have alternate data streams, Extended Attributes and security descriptors applied on them. Utilizing these options, which can be provided as command line arguments, the directory hierarchy created can be highly heterogeneous in nature.

The FSSTRS_SRV and FSSTRS_CLNT tests differ only in the locality of the destination system that is stressed. The FSSTRS_CLNT test stresses a remote server system while FSSTRS_SRV is run locally.

The respective launch scripts invoke the test with three different command lines. After each invocation, the test does some cleanup and pauses for two minutes, thereby providing other tests in the stress suite a chance to run. This set of actions is then iterated over endlessly in the launch scripts.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Software

The following software is required:

  • Windows .NET Server 2003, Datacenter Edition operating system installed on the test server.
  • Windows .NET Server 2003, Standard Edition operating system installed on the remote test host and each of the eight desktop client machines.

For test procedures and the specific hardware and software requirements, see the Datacenter Server Stress test in the HCT kit.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-30.6 Srvapp Test Description

Overview

The srvapp ensures that ESP is installed on the test machine with 50 line devices. Then it opens all these line devices and waits for LINECALLSTATE messages on them. It reacts to the following LINECALLSTATE messages as follows (other messages are ignored) LINECALLSTATE_OFFERING lineAnswer
LINECALLSTATE_DISCONNECTED lineDeallocateCall
LINECALLSTATE_IDLE lineDeallocateCall

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Software

The following software is required:

  • Windows .NET Server 2003, Datacenter Edition operating system installed on the test server.
  • Windows .NET Server 2003, Standard Edition operating system installed on the remote test host and each of the eight desktop client machines.

For test procedures and the specific hardware and software requirements, see the Datacenter Server Stress test in the HCT kit.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-30.7 Tclient Test Description

Overview

The tclient itself does not make any TAPI calls. It has the responsibility of starting the desired number of clntapps on the test machine and starting a new one whenever a clntapp process dies. It passes the command line arguments appropriately to clntapp. Clntapp itself is a standalone executable and can be started from the command line directly (refer Usage).

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Software

The following software is required:

  • Windows .NET Server 2003, Datacenter Edition operating system installed on the test server.
  • Windows .NET Server 2003, Standard Edition operating system installed on the remote test host and each of the eight desktop client machines.

For test procedures and the specific hardware and software requirements, see the Datacenter Server Stress test in the HCT kit.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-30.8 Clntapp Test Description

Overview

The Clntapp test makes most of the API calls listed above and attempts to stress TAPI by putting some randomization in the order in which the API calls are made and the arguments of these calls. Each of the scenarios makes TAPI calls in a different manner in order to generate a different sequence of TAPI calls.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Software

The following software is required:

  • Windows .NET Server 2003, Datacenter Edition operating system installed on the test server.
  • Windows .NET Server 2003, Standard Edition operating system installed on the remote test host and each of the eight desktop client machines.

For test procedures and the specific hardware and software requirements, see the Datacenter Server Stress test in the HCT kit.

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-30.9 Gqstress Test Description

Optional test: Current test is TD-30.14 IIS Stress Test (Webslug)

Overview

This test is designed to do constant IIS queries against the virtual root set up in each disk group. The test will make sure that the virtual root is online. If the test is unable to access the root, it will retry the operation. The test will allow the root to be offline for a certain period of time. This test can simulate thousands of queries in a short time; it is designed to stress the IIS virtual roots. Each client will have one instance of this test doing queries against each IIS virtual root that is a WWW root.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Software

The following software is required:

  • Windows .NET Server 2003, Datacenter Edition operating system installed on the test server.
  • Windows .NET Server 2003, Standard Edition operating system installed on the remote test host and each of the eight desktop client machines.

For test procedures and the specific hardware and software requirements, see the Datacenter Server Stress test in the HCT kit.

Results Interpretation

The name of the log file is gqstress.log. A SEV2 error indicates a failure. The most probable cause for the test failure is that IIS may not be started, crashed or security problems. Ensure that IIS is installed and running. Use the IIS Service Manager to check whether the IIS service is started. You can use Microsoft Internet Explorer to see if IIS is accessible from the client. If IIS is up and running check if all the virtual roots that are created are up and running (You can do this from IIS Service manager).

Do the following from the client browser to check if the IIS, network connectivity & security are fine.

  • Go to the IIS service manager & disable NT LM authentication (on the nodes). This is because gqstress does not support NT LM authentication.
  • From the browser fetch http://<servername>, and http://<ipaddress>. Both of them should fetch the default IIS home page.
  • If 172.31.224.44 is the IP address used for the test. Then you can fetch the gqstress.htm from the browser as follows: http://172.31.224.44/w3svc_q/gqstress/gqstress.htm. The server name could also be substituted for the IP address.


TD-30.10 Ftpstress Test Description

Optional test: Current test is TD-30.14 IIS Stress Test (Webslug)

Overview

As part of the setup, Microsoft will copy some small test files to the test disks. This test will use FTP transfers to move that file back and forth from the clients. In the case of a failure, it will redo the last operation. It will keep track of which files have been successfully transferred to the server, and then verify that those files are actually on the server.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Software

The following software is required:

  • Windows .NET Server 2003, Datacenter Edition operating system installed on the test server.
  • Windows .NET Server 2003, Standard Edition operating system installed on the remote test host and each of the eight desktop client machines.

For test procedures and the specific hardware and software requirements, see the Datacenter Server Stress test in the HCT kit.

Results Interpretation

The name of the log file is Ftpcont.log. The following warning in Ftpcont.log indicates a failure:

"FAIL: Max time out".

The most probable cause for the test failure is that ftp server may not be started or crashed. Ensure that ftp service is installed, running and accessible. Use the IIS Service Manager to check whether the FTP service is started. You can use the ftp client program that comes with Windows XP to check if ftp service is accessible from the client.


TD-30.11 Winsock Sock_Srv/Sock_Clnt Test Description

Overview

This test is a pair of client-server applications that test the ability of Winsock to accept a large number of connections, in a scenario similar to a web/ftp server.

There must be only one machine running the server binary (Sockdies.exe). There is no restriction on the number of client machines. Each of these should be running the client binary (Sockdiec.exe).

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Software

The following software is required:

  • Windows .NET Server 2003, Datacenter Edition operating system installed on the test server.
  • Windows .NET Server 2003, Standard Edition operating system installed on the remote test host and each of the eight desktop client machines.

For test procedures and the specific hardware and software requirements, see the Datacenter Server Stress test in the HCT kit.

Results Interpretation

For example, the type of the server machine, as well as the number of clients connected greatly affects the results.

Each side (client or server), creates a log file called: sockdie{s,c}.log.<computer name>.

This test stresses the system and runs without interruption for as long as the system is up. The test will only exit on fatal error conditions, such as extremely low resource availability.


TD-30.12 DTC_Bangfs Test Description

Overview

This stress test does random, file system control code (FSCTL) tests on multiple files. The test creates 100 files, 100 streams and 100 hardlinks and performs random fsctls on them. The fsctls include compression, encryption, mapped i/o, usn, streams, reparse points, sparse files, object id’s and extended attributes. The test will run until the disk is filled to 80% and then it will clean up the files and restart over.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Software

The following software is required:

  • Windows .NET Server 2003, Datacenter Edition operating system installed on the test server.
  • Windows .NET Server 2003, Standard Edition operating system installed on the remote test host and each of the eight desktop client machines.

For test procedures and the specific hardware and software requirements, see the Datacenter Server Stress test in the HCT kit.

Results Interpretation

The test may find a system bug, which could cause a blue screen event or could trigger an ASSERT statement in checked builds of the operating system. Please follow general kernel debugging procedures if a system crash occurs.


TD-30.13 DTC_Sqlio Test Description

Overview

This file system stress test tries to simulate the activity of a Microsoft SQL server on the local file system. The test first uses the program Dtc_rapidfile.exe to create two files of size 2 GB each that serve as the database. After the data files are created and verified, the program Dtc_sqlio.exe is launched and it spawns multiple threads that do random asynchronous unbuffered 16 kb read/write I/O on the data files. The read/write ratio is 3:2. The test is configured to maintain 400 I/Os pending.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Software

The following software is required:

  • Windows .NET Server 2003, Datacenter Edition operating system installed on the test server.
  • Windows .NET Server 2003, Standard Edition operating system installed on the remote test host and each of the eight desktop client machines.

For test procedures and the specific hardware and software requirements, see the Datacenter Server Stress test in the HCT kit.

Results Interpretation

The test places a lot of load on the disk subsystem and may cause disk timeouts or failures to show up in the event log. These should be followed up with the appropriate disk/host adapter vendor. The test will also fail if it finds data corruption. In this case the test log will contain information about the corrupted data.


TD-30.14 IIS Stress Test (Webslug) Description

Overview

The Internet Information Services (IIS) Stress Test (Webslug) generates valid and invalid requests at random, and then sends them to the server.

Based on input parameters, such as load, the type of requests, the number of worker threads, and logging, the test starts up and begins repeatedly sends requests to the server using various connections. The list of URLs to use is specified in a file. The test uses most of the HTTP method requests, including GET, HEAD, TRACE, OPTIONS, and PUT. The test can also distort the URLs and corrupt the headers before sending requests.

In addition to the above inputs, the IIS Stress test can take the throttle level as an input during run time; thereby, balancing the load on the server using feedback mechanisms. The results are posted on the output console. This information can include the number of current active connections, the total number of active connections, the number of failed connections, the number of bytes sent/received, and the last error recorded. The output console is updated every two seconds.

On the server-side, the IIS Stress test starts the monitoring process, that checks for the number of active worker processes in the server at a time.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Software

The following software is required:

  • Windows .NET Server 2003, Datacenter Edition operating system installed on the test server.
  • Windows .NET Server 2003, Standard Edition operating system installed on the remote test host and each of the eight desktop client machines.

For test procedures and the specific hardware and software requirements, see the Datacenter Server Stress test in the HCT kit.

Results Interpretation

The test writes the pass/fail results to the log file Dcsrvtst.log.

While the test runs, the IIS Stress test also records test activity and status. The log files Runstress.log, and Reportstatus.log are written to the directory %SystemDrive%\webtest\stress on the server.

Debugging tips

If the IIS Stress test fails, the following information may help you to identify the cause of the failure, or to gather information that can be helpful in determining the cause.

Click to show or hide information. Connect a kernel debugger to the server

There are several conditions that can cause the test to fail. When the test fails, the system can become unresponsive, or a bug check can occur. However, if you have a kernel debugger attached to the server, it is possible to debug or obtain more information about the failure. The following conditions may cause a break into the debugger:

  • Access violations (which cause a stop screen unless a debugger is setup)
  • An ASSERT in the code
  • A breakpoint that someone has set
  • When the system stops responding (or hangs)

While the IIIS Stress test runs, a monitoring script checks for worker process deadlocks. If the script finds more than 15 worker processes active, the script breaks the system into the kernel debugger. In this situation, you may see the following information displayed in the kernel debugger:

!!!!!!!!!!!!!!!!!!!!!! Broken in by the IIS Stress Harness !!!!!!!!!!!!!!!!!!!

15 or more worker processes are active

!!!!!!!!!!!!!!!!!!!!!! Broken in by the IIS Stress Harness !!!!!!!!!!!!!!!!!!!

For information about using a kernel debugger, see the Debugging Tools for Windows package. This package includes the Microsoft Windows Debugger (WinDbg), which can be used for user-mode and kernel-mode debugging. This package also includes detailed documentation that describes setting up and using a kernel debugger.

You can install the Debugging Tools for Windows from the Customer Support Diagnostics CD, the Platform SDK, the Windows DDK, or from the Web at http://www.microsoft.com/ddk/debugging.

Click to show or hide information. Check the output console for the current number of connections

While the IIS Stress test runs, you can check the output console for the current number of connections (the number of connections needs to be greater than zero, but may be zero when the test sleeps or when the run time throttle-level input is zero). Also check the count of new connections and failed connections. If there is one failed connection incremented for every new connection, the client is unable to reach the server. The last socket error number encountered is also displayed. Additional information includes the different error codes and the number of times they were returned. Note that there is no persistent log of all this information on the client-side.

Click to show or hide information. Stopping or pausing the test

The IIS Stress test exits normally when:

  • The timer expires or the timer is killed, thus triggering a shutdown of the test.
  • When you enter Q in the IIS Stress test input/output console.

The test can also be paused (from the input/output console) in its current state for any diagnosis and resumed later.


TD-30.15 Print Test Description

Overview

This test is designed to exercise the print spooler component by simulating application printing to server-based print queues. After creating the target print queues on the server, the test continually submits various types of print jobs (Raw, Text, GDI-based) to these queues. The queues are monitored to ensure the print jobs spool and despool properly. No physical printers are used and no physical output is produced.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Software

The following software is required:

  • Windows .NET Server 2003, Datacenter Edition operating system installed on the test server.
  • Windows .NET Server 2003, Standard Edition operating system installed on the remote test host and each of the eight desktop client machines.

For test procedures and the specific hardware and software requirements, see the Datacenter Server Stress test in the HCT kit.

Results Interpretation

The log file generated contains setup results and a summary of Pass/Fail results. A small percentage of failures is expected and are usually due to 'race-conditions' between multiple clients printing to the same queue, high network load, high server load, or extremely light server load (server can process print jobs faster than the clients can submit and verify them). Setup failures are usually due to failure to run with Administrator access. Success is best described as the server continues to accept print jobs and all print jobs successfully get de-spooled to the (phantom) printer (no jobs get 'stuck').


TD-30.16 DTC Shutdown/Restart Test

Test Kit: HCT 11

Overview

This test verifies that the datacenter server can shutdown and restart without causing hardware failures.

This test requires the test system to restart. If the test system is password protected, each time the system restarts the test pauses until the user enters a valid password.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Software

The following software is required for this test:

  • Windows .NET Server 2003, Datacenter Edition

Results Interpretation

The test writes the pass/fail results to the log file Dcsrvld.log.


Chapter 31: IrDA Test Specification

Overview

This document describes assertions and tests for Infrared Data Association (IrDA) Network Driver Interface Specification (NDIS). These tests specifications are independent of the operating system or the intermediate telephony layer support in operating system. The test specifications are independent of bus types (PCI, USB, CardBus, etc.) unless specifically stated.

This document describes basic functionality tests for IrDA NDIS, which is divided into Transport, Driver, and Modem Test subsets.

Click to show or hide information. IrDA Transport Test Subset

IrDA transport tests assess the interoperability between the third party drivers and Microsoft IrDA stack. Whereas NDIS test ensures driver's proper data delivery methods, transport tests ensure proper content is being delivered. In addition, transport tests check for multi socket and multi threading ability further ensuring that certified IrDA devices and drivers successfully interoperate and work with Windows.

The IrDA Transport Test consists of 17 individual test cases; only 12 Transport Tests are required for WHQL certification. Necessary time to execute all tests is about five minutes.

Click to show or hide information. IrDA Driver Tests Subset

Driver Tests subset, which include following tests:

i. 1c_FaultHandling.wsf

ii. 1c_InfoOIDs.wsf

iii. 1c_Reset.wsf

iv. 1c_SetBaud.wsf

v. 1c_SetLookahead.wsf

vi. 1c_StatOIDs.wsf

vii. 2m_Hibernate.wsf

viii. 2m_Load.wsf

ix. 2m_Send.wsf

x. 2m_Standby.wsf

xi. 2m_Recv.wsf

Click to show or hide information. IrDA Modem Test Subset

These modem tests with their assertions are described in Chapter 20: Modem Test Specification. The modem subset is further divided into five divisions with the following tests:

  • MCT Core Test Descriptions
  • TD-20.1 Send File Test (SENDFILE)
  • TD-20.2 Compression Test (COMPRESSION)
  • TD-20.3 Error Control Test (ERRCTRL)
  • TD-20.4 Forced Error Control Test (FERRCTRL)
  • TD-20.5 Speed Test (SPEED)
  • MCT Options Test Descriptions
  • TD-20.6 Speed Adjust Test (SPEEDADJUST)
  • TD-20.7 Inactivity Timeout Test (INACTIVITY)
  • TD-20.8 Hardware FlowControl Test (FLOWCTRLHARD)
  • TD-20.9 Software FlowControl Test (FLOWCTRLSOFT)
  • TD-20.10 CallSetup Timeout Test (CALLSETUP)
  • MCT Interactive Tests
  • TD-20.11 BlindDial Test (BLINDDIAL)
  • TD-20.12 Speaker Volume Test (SPEAKERVOL)
  • TD-20.13 Speaker Mode Test (SPEAKERMODE)
  • TD-20.14 CallerID Test (CALLERID)
  • MCT Voice Tests
  • TD-20.15 Generate Digits Test (GENDIGITS)
  • TD-20.16 Monitor Digits Test (MONDIGITS)
  • TD-20.17 Handset HookSwitch Test (HSHOOKSWITCH)
  • TD-20.18 SpeakerPhone HookSwitch Test (SPHOOKSWITCH)
  • TD-20.19 SpeakerPhone Volume/Gain Test (SPVOLGAIN)
  • TD-20.20 Handset Audio Test (HSAUDIO)
  • TD-20.21 Line Audio Test (LINEAUDIO)
  • MCT V.250 Tests
  • TD-20.22 AT +GCI Test (ATGCI)

These modem tests with their assertions are described in Chapter 20: Modem Test Specification.

Click to show or hide information. Reference Documents for IrDA Transport

Bellcore Technical References

http://www.telcordia.com/index.html

Communications Device Class Power Management Reference Specification, V. 2.0

[MOD-0381, 0382]
http://www.microsoft.com/hwdev/resources/specs/pmref/PMcom.asp

EIA Standard #ANSI/EIA-516-88

Joint EIA/CVCC Recommended Practice for Teletext: North American Basic Teletext Specification (NABTS) - http://www.tiaonline.org/

ETSI (European Telecommunication Standards Institute)

http://www.etsi.org/

ITU (International Telecommunication Union) communications standards

http://www.itu.int/publications/index.html

Microsoft Windows Driver Development Kit

http://www.microsoft.com/ddk/

Microsoft Windows Logo Program System and Device Requirements, Version 2.0

http://www.microsoft.com/hwdev/winlogo/
(listed as "WLP#" in these assertions)

USB Class Definitions for Communications Devices

Version 1.1 for External Devices
http://www.usb.org/developers/docs.html

PC 2001 System Design Guide and PC 99 System Design Guide

http://www.microsoft.com/hwdev/platform/pcdesign/desguide/pcguides.asp

PHS Internal Access Forum Specification (PIAFS)

http://www.arib.or.jp/

SII NS-2482-30

http://www.sii.co.jp/js/nshp/product/index-e.html (English);
http://www.sii.co.jp/js/nshp/product/ (Japanese)


IrDA Transport Test Assertions

This section contains the detailed list of test assertions for IrDA Transport.

Random Sock Connect/Disconnect Test Assertions

Assertions in this section are tested in TD-31.1 Random Sock Connect/Disconnect Test Description

31.1.103 closesocket() inside DisconnectMe() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.1 Random Sock Connect/Disconnect Test Description

31.1.120 socket(AF_RDA, SOCK_STREAM, 0) returned INVALID_SOCKET.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.1 Random Sock Connect/Disconnect Test Description

31.1.121 ConnectMe() returned FALSE while trying to connect a randomly selected socket from the socket pool.

Usually preceded by assertion 101 or 102 (see General Assertions for description).

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.1 Random Sock Connect/Disconnect Test Description

31.1.122 closesocket() returned SOCKET_ERROR while trying to disconnect randomly selected socket form the socket pool.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.1 Random Sock Connect/Disconnect Test Description


Single Sock Connect/Disconnect Test Assertions

Assertions in this section are tested in TD-31.2 Single Sock Connect/Disconnect Test Description

31.2.103 closesocket() inside DisconnectMe() returned SOCKET_ERROR. Error code shown at end of line.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.2 Single Sock Connect/Disconnect Test Description

31.2.123 socket(AF_RDA, SOCK_STREAM, 0) returned INVALID_SOCKET.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.2 Single Sock Connect/Disconnect Test Description

31.2.124 ConnectMe() returned FALSE while trying to connect the socket.

Usually preceded by assertion 101 or 102 (see General Assertions for description).

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.2 Single Sock Connect/Disconnect Test Description

31.2.125 closesocket() returned SOCKET_ERROR while trying to disconnect the socket.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.2 Single Sock Connect/Disconnect Test Description


Multi Sock Connect/Disconnect Test Assertions

Assertions in this section are tested in TD-31.3 Multi Sock Connect/Disconnect Test Description.

31.2.103 closesocket() inside DisconnectMe() returned SOCKET_ERROR. Error code shown at end of line.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.3 Multi Sock Connect/Disconnect Test Description

31.3.126 socket(AF_RDA, SOCK_STREAM, 0) returned INVALID_SOCKET.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.3 Multi Sock Connect/Disconnect Test Description

31.3.127 ConnectMe() returned FALSE while trying to connect the socket.

Usually preceded by assertion 101 or 102 (see General Assertions for description).

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.3 Multi Sock Connect/Disconnect Test Description

31.3.128 closesocket() returned SOCKET_ERROR while trying to disconnect a socket.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.3 Multi Sock Connect/Disconnect Test Description


Discovery Test Assertions

Assertions in this section are tested in TD-31.4 Discovery Test Description.

31.4.129 socket(AF_RDA, SOCK_STREAM, 0) returned INVALID_SOCKET.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.4 Discovery Test Description

31.4.130 Memory allocation returned NULL.

Unable to allocate DEVICELIST array which holds the enumerated devices. Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.4 Discovery Test Description

31.4.131 closesocket() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.4 Discovery Test Description

31.4.132 getsockopt(,,IRLMP_ENUMDEVICES,,) returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.4 Discovery Test Description

31.4.133 closesocket() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.4 Discovery Test Description

31.4.134 Enumerated 0 devices.

The enumeration process failed or no devise are with in range.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.4 Discovery Test Description

31.4.135 closesocket() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.4 Discovery Test Description

31.4.136 closesocket() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.4 Discovery Test Description


IrDA Protocol Service Test Assertions

Assertions in this section are tested in TD-31.5 IrDA Protocol Service Test Description.

31.5.137 OpenSCManager() returned NULL.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.5 IrDA Protocol Service Test Description

31.5.138 OpenService() returned NULL.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.5 IrDA Protocol Service Test Description

31.5.139 ControlService() returned FALSE.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.5 IrDA Protocol Service Test Description

31.5.140 OpenSCManager() returned NULL.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.5 IrDA Protocol Service Test Description

31.5.141 OpenService() returned NULL.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.5 IrDA Protocol Service Test Description

31.5.142 StartService() returned FALSE.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.5 IrDA Protocol Service Test Description


IrDA Monitor Service Test Assertions

Assertions in this section are tested in TD-31.6 IrDA Monitor Service Test Description.

31.6.137 OpenSCManager() returned NULL.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.6 IrDA Monitor Service Test Description

31.6.138 OpenService() returned NULL.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.6 IrDA Monitor Service Test Description

31.6.139 ControlService() returned FALSE.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.6 IrDA Monitor Service Test Description

31.6.140 OpenSCManager() returned NULL.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.6 IrDA Monitor Service Test Description

31.6.141 OpenService() returned NULL.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.6 IrDA Monitor Service Test Description

31.6.142 StartService() returned FALSE.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.6 IrDA Monitor Service Test Description


Single Sock Data Loop Test Assertions

Assertions in this section are tested in TD-31.7 Single Sock Data Loop Test Description.

31.7.101 connect() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.7 Single Sock Data Loop Test Description

31.7.102 ioctlsocket(,FIONBIO,) returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.7 Single Sock Data Loop Test Description

31.7.103 closesocket() inside DisconnectMe() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.7 Single Sock Data Loop Test Description

31.7.104 The two buffers compared are not identical

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.7 Single Sock Data Loop Test Description

31.7.105 send() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.7 Single Sock Data Loop Test Description

31.7.106 send() returned 0.

Expected to receive more than 0 bytes.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.7 Single Sock Data Loop Test Description

31.7.110 recv() returned 0.

Expected to receive more than 0 bytes.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.7 Single Sock Data Loop Test Description

31.7.143 socket(AF_RDA, SOCK_STREAM, 0) returned INVALID_SOCKET.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.7 Single Sock Data Loop Test Description

31.7.144 Memory allocation returned NULL. Unable to allocate the receive buffer.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.7 Single Sock Data Loop Test Description

31.7.145 Number of bytes sent is not equal to number of bytes received.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.7 Single Sock Data Loop Test Description

31.7.146 The two (send and receive) buffers are not identical.

Usually preceded by assertion 104

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.7 Single Sock Data Loop Test Description

31.7.147 SendBuffer() returned FALSE.

Usually preceded by assertion 105, 106 or 108. (See General Assertions for description)

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.7 Single Sock Data Loop Test Description

31.7.148 RecvBuffer() returned FALSE.

Usually preceded by assertion 109 and 110. (See General Assertions for description)

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.7 Single Sock Data Loop Test Description


Single Sock Data Loop (Random Data) Test Assertions

Assertions in this section are tested in TD-31.8 Single Sock Data Loop (Random Data) Test Description.

31.8.101 connect() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.8 Single Sock Data Loop (Random Data) Test Description

31.8.102 ioctlsocket(,FIONBIO,) returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.8 Single Sock Data Loop (Random Data) Test Description

31.8.103 closesocket() inside DisconnectMe() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.8 Single Sock Data Loop (Random Data) Test Description

31.8.104 The two buffers compared are not identical

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.8 Single Sock Data Loop (Random Data) Test Description

31.8.105 send() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.8 Single Sock Data Loop (Random Data) Test Description

31.8.106 send() returned 0.

Expected to receive more than 0 bytes.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.8 Single Sock Data Loop (Random Data) Test Description

31.8.110 recv() returned 0.

Expected to receive more than 0 bytes.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.8 Single Sock Data Loop (Random Data) Test Description

31.8.143 socket(AF_RDA, SOCK_STREAM, 0) returned INVALID_SOCKET.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.8 Single Sock Data Loop (Random Data) Test Description

31.8.144 Memory allocation returned NULL. Unable to allocate the receive buffer.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.8 Single Sock Data Loop (Random Data) Test Description

31.8.145 Number of bytes sent is not equal to number of bytes received.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.8 Single Sock Data Loop (Random Data) Test Description

31.8.146 The two (send and receive) buffers are not identical.

Usually preceded by assertion 104

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.8 Single Sock Data Loop (Random Data) Test Description

31.8.147 SendBuffer() returned FALSE.

Usually preceded by assertion 105, 106 or 108. (See General Assertions for description)

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.8 Single Sock Data Loop (Random Data) Test Description

31.8.148 RecvBuffer() returned FALSE.

Usually preceded by assertion 109 and 110. (See General Assertions for description)

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.8 Single Sock Data Loop (Random Data) Test Description


Single Sock Data Loop (Random Data Length) Test Assertions

Assertions in this section are tested in TD-31.9 Single Sock Data Loop (Random Data Length) Test Description.

31.9.101 connect() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.9 Single Sock Data Loop (Random Data Length) Test Description

31.9.102 ioctlsocket(,FIONBIO,) returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.9 Single Sock Data Loop (Random Data Length) Test Description

31.9.103 closesocket() inside DisconnectMe() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.9 Single Sock Data Loop (Random Data Length) Test Description

31.9.104 The two buffers compared are not identical

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.9 Single Sock Data Loop (Random Data Length) Test Description

31.9.105 send() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.9 Single Sock Data Loop (Random Data Length) Test Description

31.9.106 send() returned 0.

Expected to receive more than 0 bytes.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.9 Single Sock Data Loop (Random Data Length) Test Description

31.9.110 recv() returned 0.

Expected to receive more than 0 bytes.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.9 Single Sock Data Loop (Random Data Length) Test Description

31.9.143 socket(AF_RDA, SOCK_STREAM, 0) returned INVALID_SOCKET.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.9 Single Sock Data Loop (Random Data Length) Test Description

31.9.144 Memory allocation returned NULL. Unable to allocate the receive buffer.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.9 Single Sock Data Loop (Random Data Length) Test Description

31.9.145 Number of bytes sent is not equal to number of bytes received.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.9 Single Sock Data Loop (Random Data Length) Test Description

31.9.146 The two (send and receive) buffers are not identical.

Usually preceded by assertion 104

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.9 Single Sock Data Loop (Random Data Length) Test Description

31.9.147 SendBuffer() returned FALSE.

Usually preceded by assertion 105, 106 or 108. (See General Assertions for description)

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.9 Single Sock Data Loop (Random Data Length) Test Description

31.9.148 RecvBuffer() returned FALSE.

Usually preceded by assertion 109 and 110. (See General Assertions for description)

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.9 Single Sock Data Loop (Random Data Length) Test Description


Single Sock Data Loop (Random Data & Random Data Length) Test Assertions

Assertions in this section are tested in TD-31.10 Single Sock Data Loop (Random Data & Random Data Length) Test Description.

31.10.101 connect() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.10 Single Sock Data Loop (Random Data & Random Data Length) Test Description

31.10.102 ioctlsocket(,FIONBIO,) returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.10 Single Sock Data Loop (Random Data & Random Data Length) Test Description

31.10.103 closesocket() inside DisconnectMe() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.10 Single Sock Data Loop (Random Data & Random Data Length) Test Description

31.10.104 The two buffers compared are not identical

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.10 Single Sock Data Loop (Random Data & Random Data Length) Test Description

31.10.105 send() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.10 Single Sock Data Loop (Random Data & Random Data Length) Test Description

31.10.106 send() returned 0.

Expected to receive more than 0 bytes.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.10 Single Sock Data Loop (Random Data & Random Data Length) Test Description

31.10.110 recv() returned 0.

Expected to receive more than 0 bytes.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.10 Single Sock Data Loop (Random Data & Random Data Length) Test Description

31.10.143 socket(AF_RDA, SOCK_STREAM, 0) returned INVALID_SOCKET.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.10 Single Sock Data Loop (Random Data & Random Data Length) Test Description

31.10.144 Memory allocation returned NULL. Unable to allocate the receive buffer.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.10 Single Sock Data Loop (Random Data & Random Data Length) Test Description

31.10.145 Number of bytes sent is not equal to number of bytes received.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.10 Single Sock Data Loop (Random Data & Random Data Length) Test Description

31.10.146 The two (send and receive) buffers are not identical.

Usually preceded by assertion 104

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.10 Single Sock Data Loop (Random Data & Random Data Length) Test Description

31.10.147 SendBuffer() returned FALSE.

Usually preceded by assertion 105, 106 or 108. (See General Assertions for description)

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.10 Single Sock Data Loop (Random Data & Random Data Length) Test Description

31.10.148 RecvBuffer() returned FALSE.

Usually preceded by assertion 109 and 110. (See General Assertions for description)

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.10 Single Sock Data Loop (Random Data & Random Data Length) Test Description


Multi Sock Data Loop Test Assertions

Assertions in this section are tested in TD-31.11 Multi Sock Data Loop Test Description.

31.11.101 connect() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.11 Multi Sock Data Loop Test Description

31.11.102 ioctlsocket(,FIONBIO,) returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.11 Multi Sock Data Loop Test Description

31.11.103 closesocket() inside DisconnectMe() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.11 Multi Sock Data Loop Test Description

31.11.104 The two buffers compared are not identical

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.11 Multi Sock Data Loop Test Description

31.11.105 send() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.11 Multi Sock Data Loop Test Description

31.11.106 send() returned 0.

Expected to receive more than 0 bytes.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.11 Multi Sock Data Loop Test Description

31.11.110 recv() returned 0.

Expected to receive more than 0 bytes.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.11 Multi Sock Data Loop Test Description

31.11.143 socket(AF_RDA, SOCK_STREAM, 0) returned INVALID_SOCKET.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.11 Multi Sock Data Loop Test Description

31.11.144 Memory allocation returned NULL. Unable to allocate the receive buffer.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.11 Multi Sock Data Loop Test Description

31.11.145 Number of bytes sent is not equal to number of bytes received.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.11 Multi Sock Data Loop Test Description

31.11.146 The two (send and receive) buffers are not identical.

Usually preceded by assertion 104

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.11 Multi Sock Data Loop Test Description

31.11.147 SendBuffer() returned FALSE.

Usually preceded by assertion 105, 106 or 108. (See General Assertions for description)

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.11 Multi Sock Data Loop Test Description

31.11.148 RecvBuffer() returned FALSE.

Usually preceded by assertion 109 and 110. (See General Assertions for description)

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.11 Multi Sock Data Loop Test Description


Multi Sock Data Loop (Random Data) Test Assertions

Assertions in this section are tested in TD-31.12 Multi Sock Data Loop (Random Data) Test Description.

31.12.101 connect() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.12 Multi Sock Data Loop (Random Data) Test Description

31.12.102 ioctlsocket(,FIONBIO,) returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.12 Multi Sock Data Loop (Random Data) Test Description

31.12.103 closesocket() inside DisconnectMe() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.12 Multi Sock Data Loop (Random Data) Test Description

31.12.104 The two buffers compared are not identical

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.12 Multi Sock Data Loop (Random Data) Test Description

31.12.105 send() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.12 Multi Sock Data Loop (Random Data) Test Description

31.12.106 send() returned 0.

Expected to receive more than 0 bytes.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.12 Multi Sock Data Loop (Random Data) Test Description

31.12.110 recv() returned 0.

Expected to receive more than 0 bytes.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.12 Multi Sock Data Loop (Random Data) Test Description

31.12.143 socket(AF_RDA, SOCK_STREAM, 0) returned INVALID_SOCKET.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.12 Multi Sock Data Loop (Random Data) Test Description

31.12.144 Memory allocation returned NULL. Unable to allocate the receive buffer.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.12 Multi Sock Data Loop (Random Data) Test Description

31.12.145 Number of bytes sent is not equal to number of bytes received.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.12 Multi Sock Data Loop (Random Data) Test Description

31.12.146 The two (send and receive) buffers are not identical.

Usually preceded by assertion 104

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.12 Multi Sock Data Loop (Random Data) Test Description

31.12.147 SendBuffer() returned FALSE.

Usually preceded by assertion 105, 106 or 108. (See General Assertions for description)

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.12 Multi Sock Data Loop (Random Data) Test Description

31.12.148 RecvBuffer() returned FALSE.

Usually preceded by assertion 109 and 110. (See General Assertions for description)

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.12 Multi Sock Data Loop (Random Data) Test Description


Multi Sock Data Loop (Random Data Length) Test Assertions

Assertions in this section are tested in TD-31.13 Multi Sock Data Loop (Random Data Length) Test Description.

31.13.101 connect() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.13 Multi Sock Data Loop (Random Data Length) Test Description

31.13.102 ioctlsocket(,FIONBIO,) returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.13 Multi Sock Data Loop (Random Data Length) Test Description

31.13.103 closesocket() inside DisconnectMe() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.13 Multi Sock Data Loop (Random Data Length) Test Description

31.13.104 The two buffers compared are not identical

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.13 Multi Sock Data Loop (Random Data Length) Test Description

31.13.105 send() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.13 Multi Sock Data Loop (Random Data Length) Test Description

31.13.106 send() returned 0.

Expected to receive more than 0 bytes.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.13 Multi Sock Data Loop (Random Data Length) Test Description

31.13.110 recv() returned 0.

Expected to receive more than 0 bytes.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.13 Multi Sock Data Loop (Random Data Length) Test Description

31.13.143 socket(AF_RDA, SOCK_STREAM, 0) returned INVALID_SOCKET.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.13 Multi Sock Data Loop (Random Data Length) Test Description

31.13.144 Memory allocation returned NULL. Unable to allocate the receive buffer.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.13 Multi Sock Data Loop (Random Data Length) Test Description

31.13.145 Number of bytes sent is not equal to number of bytes received.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.13 Multi Sock Data Loop (Random Data Length) Test Description

31.13.146 The two (send and receive) buffers are not identical.

Usually preceded by assertion 104

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.13 Multi Sock Data Loop (Random Data Length) Test Description

31.13.147 SendBuffer() returned FALSE.

Usually preceded by assertion 105, 106 or 108. (See General Assertions for description)

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.13 Multi Sock Data Loop (Random Data Length) Test Description

31.13.148 RecvBuffer() returned FALSE.

Usually preceded by assertion 109 and 110. (See General Assertions for description)

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.13 Multi Sock Data Loop (Random Data Length) Test Description


Multi Sock Data Loop (Random Data & Random Data Length) Test Assertions

Assertions in this section are tested in TD-31.14 Multi Sock Data Loop (Random Data & Random Data Length) Test Description.

31.14.101 connect() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.14 Multi Sock Data Loop (Random Data & Random Data Length) Test Description

31.14.102 ioctlsocket(,FIONBIO,) returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.14 Multi Sock Data Loop (Random Data & Random Data Length) Test Description

31.14.103 closesocket() inside DisconnectMe() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.14 Multi Sock Data Loop (Random Data & Random Data Length) Test Description

31.14.104 The two buffers compared are not identical

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.14 Multi Sock Data Loop (Random Data & Random Data Length) Test Description

31.14.105 send() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.14 Multi Sock Data Loop (Random Data & Random Data Length) Test Description

31.14.106 send() returned 0.

Expected to receive more than 0 bytes.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.14 Multi Sock Data Loop (Random Data & Random Data Length) Test Description

31.14.110 recv() returned 0.

Expected to receive more than 0 bytes.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.14 Multi Sock Data Loop (Random Data & Random Data Length) Test Description

31.14.143 socket(AF_RDA, SOCK_STREAM, 0) returned INVALID_SOCKET.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.14 Multi Sock Data Loop (Random Data & Random Data Length) Test Description

31.14.144 Memory allocation returned NULL. Unable to allocate the receive buffer.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.14 Multi Sock Data Loop (Random Data & Random Data Length) Test Description

31.14.145 Number of bytes sent is not equal to number of bytes received.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.14 Multi Sock Data Loop (Random Data & Random Data Length) Test Description

31.14.146 The two (send and receive) buffers are not identical.

Usually preceded by assertion 104

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.14 Multi Sock Data Loop (Random Data & Random Data Length) Test Description

31.14.147 SendBuffer() returned FALSE.

Usually preceded by assertion 105, 106 or 108. (See General Assertions for description)

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.14 Multi Sock Data Loop (Random Data & Random Data Length) Test Description

31.14.148 RecvBuffer() returned FALSE.

Usually preceded by assertion 109 and 110. (See General Assertions for description)

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.14 Multi Sock Data Loop (Random Data & Random Data Length) Test Description


Multi-thread Socket Data Loop Test Assertions

Assertions in this section are tested in TD-31.15 Multi-thread Socket Data Loop Test Description.

31.15.149 Unable to allocate the send buffer.

Memory allocation returned NULL. Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.15 Multi-thread Socket Data Loop Test Description

31.15.150 Unable to allocate the receive buffer.

Memory allocation returned NULL. Error code is show at end of the line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.15 Multi-thread Socket Data Loop Test Description

31.15.151 CreateEvent() returned NULL.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.15 Multi-thread Socket Data Loop Test Description

31.15.152 CreateThread returned NULL.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.15 Multi-thread Socket Data Loop Test Description

31.15.153 socket(AF_RDA, SOCK_STREAM, 0) returned INVALID_SOCKET.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.15 Multi-thread Socket Data Loop Test Description

31.15.154 ConnectMe() returned FALSE while trying to connect the socket.

Usually preceded by assertion 101 or 102 (see General Assertions for description).

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.15 Multi-thread Socket Data Loop Test Description

31.15.155 SendBuffer() returned FALSE.

Usually preceded by assertion 105, 106 or 108 (see General Assertions for description)

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.15 Multi-thread Socket Data Loop Test Description

31.15.156 SendBuffer() returned FALSE.

Usually preceded by assertion 105, 106 or 108 (see General Assertions for description)

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.15 Multi-thread Socket Data Loop Test Description

31.15.157 RecvBuffer() returned FALSE.

Usually preceded by assertion 109 and 110. (see General Assertions for description)

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.15 Multi-thread Socket Data Loop Test Description

31.15.158 Number of bytes sent is not equal to number of bytes received.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.15 Multi-thread Socket Data Loop Test Description

31.15.159 The two (send and receive) buffers are not identical.

Usually preceded by assertion 104

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: TD-31.15 Multi-thread Socket Data Loop Test Description


General IrDA Transport Test Assertions

Assertions in this section are General assertions and are used in multiple IrDA Transport Tests.

31.19.101 connect() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: N/A

31.19.102 ioctlsocket(,FIONBIO,) returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: N/A

31.19.103 closesocket() inside DisconnectMe() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: N/A

31.19.104 The two buffers compared are not identical

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: N/A

31.19.105 send() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: N/A

31.19.106 send() returned 0.

Expected to receive more than 0 bytes.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: N/A

31.19.107 Requested test termination (user hit the Exit button).

The test did not complete therefore it is failure.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: N/A

31.19.108 select() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: N/A

31.19.109 recv() returned SOCKET_ERROR.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: N/A

31.19.110 recv() returned 0.

Expected to receive more than 0 bytes.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: N/A

31.19.137 OpenSCManager() returned NULL.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: N/A

31.19.138 OpenService() returned NULL.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: N/A

31.19.139 ControlService() returned FALSE.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: N/A

31.19.140 OpenSCManager() returned NULL.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: N/A

31.19.141 OpenService() returned NULL.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: N/A

31.19.142 StartService() returned FALSE.

Error code is shown at end of line.

Reference document: WLP# - B2.3; PC 2001 System Design Guide, Chapter 14, "Network Communications." - IrDA Requirements for Network Communications.
Test description: N/A


IrDA Test Descriptions

This section contains the detailed IrDA test descriptions. There are three subsets of IrDA tests.

  • IrDA Transport Tests
  • Driver Tests
  • Modem Tests


IrDA Transport Tests Descriptions

Test Kit: HCT 11, HCT 10

This section contains the detailed IrDA Transport test descriptions.

Required Tests

  • Single Sock Connect/Disconnect Test
  • Multi Sock Connect/Disconnect Test Description
  • Discovery Test Description
  • Single Sock Data Loop Test
  • Single Sock Data Loop (Random Data) Test
  • Single Sock Data Loop (Random Data Length) Test
  • Single Sock Data Loop (Random Data & Random Data Length) Test
  • Multi Sock Data Loop Test
  • Multi Sock Data Loop (Random Data) Test
  • Multi Sock Data Loop (Random Data Length) Test
  • Multi Sock Data Loop (Random Data & Random Data Length) Test
  • Multi-thread Socket Data Loop Test

Optional Tests

  • Random Sock Connect/Disconnect Test
  • IrDA Protocol Service Test
  • IrDA Monitor Service Test Description


TD-31.1 Random Sock Connect/Disconnect Test Description

Overview

This is an IrDA Transport test. The Random Sock Connect/Disconnect test runs in a loop from zero to "Number of Repetitions" (user defined number). Socket is selected randomly from the available socket pool. This socket is connected (if currently in disconnected state) or disconnected (if currently in connected state).

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Standard system

Results Interpretation

A pass/fail indication of compliance with this requirement is displayed and logged by the test program.


TD-31.2 Single Sock Connect/Disconnect Test Description

Overview

This is a IrDA Transport test. Single socket is connected and disconnected "Number of Repetitions" times. This test is required for WHQL certification

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Standard system

Results Interpretation

Pass: All connect/disconnect attempts were successfully executed.


TD-31.3 Multi Sock Connect/Disconnect Test Description

Overview

This is a IrDA Transport test. Multi sockets are connected and disconnected "Number of Repetitions" times. First they are all connected and then they are all disconnected.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Standard system

Results Interpretation

Pass: All connect/disconnect attempts were successfully executed.


TD-31.4 Discovery Test Description

Overview

This IrDA Transport test enumerates all the available IrDA devices within range "Number of Repetitions" times.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Standard system

Results Interpretation

Pass: At list one device was enumerated.


TD-31.5 IrDA Protocol Service Test Description

Overview

This IrDA Transport test restarts IrDA protocol service "Number of Repetitions" times.

Optional for WHQL certification

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Standard system

Results Interpretation

Pass: Successfully restarted every time.


TD-31.6 IrDA Monitor Service Test Description

Overview

This IrDA Transport test restarts IrDA monitor service "Number of Repetitions" times.

Optional for WHQL certification

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Standard system

Results Interpretation

Pass: Successfully restarted every time.


TD-31.7 Single Sock Data Loop Test Description

Overview

This IrDA Transport test sends and receives different buffer sizes to an IrDA stream and verifies if the buffer sent is identical to the buffer received.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Standard system

Results Interpretation

Pass: Successfully send, receive and compared the send/receive buffers.


TD-31.8 Single Sock Data Loop (Random Data) Test Description

Overview

This IrDA Transport test sends and receives randomly generated data in different buffer sizes to an IrDA stream and verifies if the buffer sent is identical to the buffer received.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Standard system

Results Interpretation

Pass: Successfully send, receive and compared the send/receive buffers.


TD-31.9 Single Sock Data Loop (Random Data Length) Test Description

Overview

This IrDA Transport test sends and receives data that has randomly generated data lengths to an IrDA stream and verifies if the data sent is identical to the data received.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Standard system

Results Interpretation

Pass: Successfully send, receive and compared the send/receive buffers.


TD-31.10 Single Sock Data Loop (Random Data & Random Data Length) Test Description

Overview

This IrDA Transport test sends and receives randomly generated data that has randomly generated data lengths to an IrDA stream and verifies if the data sent is identical to the data received.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Standard system

Results Interpretation

Pass: Successfully send, receive and compared the send/receive buffers.


TD-31.11 Multi Sock Data Loop Test Description

Overview

This IrDA Transport test sends and receives different buffer sizes to multiple IrDA streams and verifies if the buffer send is identical to the buffer received.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Standard system

Results Interpretation

Pass: Successfully send, receive and compared the send/receive buffers.


TD-31.12 Multi Sock Data Loop (Random Data) Test Description

Overview

This IrDA Transport test sends and receives randomly generated data of different buffer sizes to multiple IrDA streams and verifies if the buffer sent is identical to the buffer received.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Standard system

Results Interpretation

Pass: Successfully send, receive and compared the send/receive buffers.


TD-31.13 Multi Sock Data Loop (Random Data Length) Test Description

Overview

This IrDA Transport test sends and receives data of randomly generated data lengths to multiple IrDA streams and verifies if the data sent is identical to the data received.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Standard system

Results Interpretation

Pass: Successfully send, receive and compared the send/receive buffers.


TD-31.14 Multi Sock Data Loop (Random Data & Random Data Length) Test Description

Overview

This test sends and receives randomly generated data of randomly generated data lengths to multiple IrDA streams and verifies if the data sent is identical to the data received.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Standard system

Results Interpretation

Pass: Successfully send, receive and compared the send/receive buffers.


TD-31.15 Multi-thread Socket Data Loop Test Description

Overview

This IrDA Transport test sends and receives different buffer sizes to multiple IrDA streams with each connection carried out in a separate thread and verifies if the buffer send is identical to the buffer received.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Standard system

Results Interpretation

Pass: Successfully send, receive and compared the send/receive buffers.


Modem Tests Descriptions

The modem tests with their assertions are described in Chapter 20: Modem Test Specification.


Chapter 32: Bluetooth Test Specification

Overview

Bluetooth is a low-power, low-bandwidth radio technology designed for personal area networks. Essentially, Bluetooth is a cable replacement technology. Bluetooth is unique in that it has some attributes that are similar to a cable and others that are similar to a network.

For those working on Bluetooth technology perhaps the major drawback is that the Bluetooth connection is non-reliable. That is, there is no guarantee of correct delivery of a packet. This lack of reliable delivery is compounded by the transitory nature of the devices that typically utilize Bluetooth. The connection to a remote device can come and go as the device moves in and out of range, or even as a person passes between the devices.

Fortunately, many of the problems inherited from Bluetooth technology’s network-like attributes are solved by common networking protocols. Therefore, Microsoft views the Bluetooth specification as best utilized underneath existing networking stacks.

In addition, some vendors are already using Bluetooth strictly for cable replacement, in most cases replacing a serial cable. To support both the network and cable-replacement deployment of Bluetooth technology, Microsoft supports the following Bluetooth specifications:

  • Personal area networking profile (PAN)
  • RFCOMM (serial cable emulation)
  • Human interface device (HID)
  • Hardcopy cable replacement profile (HCRP)
  • Dial-up networking (DUN)

The HID, HCRP, and DUN specifications are self-sufficient in that Microsoft provides the Bluetooth-stack-to-existing-stack implementation, so that no additional third-party development work is necessary.

Both PAN and RFCOMM use Winsock to expose the application programming interface (API) to allow third-party applications to add value to the Microsoft Bluetooth implementation.

Note The Microsoft implementation of PAN complies with the Bluetooth Special Interest Group (SIG) specification for the Bluetooth Network Encapsulation Protocol (BNEP) layer; however, only IP version 6 (IPv6) is exposed on top of this layer. For more information, see the Microsoft web site at http://www.microsoft.com/hwdev/tech/network/bluetooth/default.asp.

At the lower level, Microsoft supports the USB and UART host controller interface (HCI) transports as defined in the Bluetooth specification Part H. Microsoft also supports the Cambridge Silicon Radio (CSR) BCSP HCI transport and expects to support the PCI HCI transport when it is adopted by the SIG.

By supporting SIG-specified physical transport interfaces, Microsoft provides a well-defined interface for hardware. This relieves third-party developers from having to spend valuable resources on proprietary interface support and provides a robust, reliable, and consistent user experience.

As a result of the Microsoft implementation, third-party developers need not write any kernel-mode components to support either Bluetooth hardware or Bluetooth applications on the Microsoft Windows XP platform. In fact, there is no support for developing third-party kernel-mode components. Again, this should provide for a more robust, reliable, and consistent user experience while reducing the industry’s cost in supporting Bluetooth technology.

This reliability is further enhanced by the selection of two radios, one from CSR and one from Silicon Wave, to be used as the benchmark for Bluetooth testing in WHQL. These radios have been extensively tested for interoperability together and with other manufacturers’ radios.


Bluetooth Test Specification


Reference Documents for Bluetooth Assertions

The Bluetooth functional requirements are specified by the following sources:

Bluetooth Special Interest Group (SIG)

http://www.bluetooth.com

Bluetooth Specification, Version 1.1.

Core Specification (Volume 1) and Profile Definitions (Volume 2)
http://www.bluetooth.com

Bluetooth Wireless Technologies

Microsoft Windows support for Bluetooth technologies
http://www.microsoft.com/hwdev/tech/network/bluetooth

Microsoft Windows Driver Development Kit

http://www.microsoft.com/ddk/

Microsoft Windows Logo Program System and Device Requirements, Version 2.0

http://www.microsoft.com/hwdev/winlogo/
(listed as "WLP#" in these assertions)

PC 2001 System Design Guide and PC 99 System Design Guide

http://www.microsoft.com/hwdev/platform/pcdesign/desguide/pcguides.asp


Test Assertion Summary

The following table lists the test assertions, references, and tests used to verify the compatibility of Bluetooth controllers with Windows XP.

Table 32-1. Bluetooth Test Assertion Summary

Test assertion # | Reference document | Comments
32.1.1 | WLP - B2.3.3.1, B2.3.4.5, B2.3.5.1 | TD-32.1.1 Initialization Test Description
32.2.1 - 32.2.3 | WLP - B2.3.3.1, B2.3.4.5, B2.3.5.1 | TD-32.1.2 Inquiry and Discovery Test Description
32.3.1 - 32.3.3 | WLP - B2.3.3.1, B2.3.4.5, B2.3.5.1 | TD-32.1.3 Connection and Disconnect Test Description
32.4.1 - 32.4.2 | WLP - B2.3.3.1, B2.3.4.5, B2.3.5.1 | TD-32.1.4 Data Transfer Test Description
32.5.1 - 32.5.2 | WLP - B2.3.3.1, B2.3.4.5, B2.3.5.1 | TD-32.1.5 Authentication and Encryption Test Description


Bluetooth Test Assertions

This section contains the detailed list of test assertions.


Initialization Test Assertions

The following Bluetooth hardware assertions are tested in TD-32.1.1 Initialization Test Description.

32.1.1 The Host Controller Interface (HCI) of the test device must be compatible with the Windows XP Bluetooth stack.

Reference document: WLP# - B2.3.3.1, B2.3.4.5, B2.3.5.1
Test description: TD-32.1.1 Initialization Test Description


Inquiry and Discovery Test Assertions

The following Bluetooth hardware assertions are tested in TD-32.1.2 Inquiry and Discovery Test Description.

32.2.1 The device must not respond to inquiry when in non-discoverable mode.

Reference document: WLP# - B2.3.3.1, B2.3.4.5, B2.3.5.1
Test description: TD-32.1.2 Inquiry and Discovery Test Description

32.2.2 The device must respond to inquiry when in discoverable mode.

Reference document: WLP# - B2.3.3.1, B2.3.4.5, B2.3.5.1
Test description: TD-32.1.2 Inquiry and Discovery Test Description

32.2.3 The device must be able to perform an inquiry.

Reference document: WLP# - B2.3.3.1, B2.3.4.5, B2.3.5.1
Test description: TD-32.1.2 Inquiry and Discovery Test Description

32.2.4 The device must respond to inquiry when in discoverable, non-connectable mode.

Reference document: WLP# - B2.3.3.1, B2.3.4.5, B2.3.5.1
Test description: TD-32.1.2 Inquiry and Discovery Test Description


Connection and Disconnect Test Assertions

The following Bluetooth hardware assertions are tested in TD-32.1.3 Connection and Disconnect Test Description.

32.3.1 The device must accept a connection initiated by a known (bonded) device when in non-discoverable mode.

Reference document: WLP# - B2.3.3.1, B2.3.4.5, B2.3.5.1
Test description: TD-32.1.3 Connection and Disconnect Test Description

32.3.2 The device must accept a connection initiated by a known (bonded) device when in discoverable mode.

Reference document: WLP# - B2.3.3.1, B2.3.4.5, B2.3.5.1
Test description: TD-32.1.3 Connection and Disconnect Test Description

32.3.3 The device must be capable of establishing a connection to a remote device.

Reference document: WLP# - B2.3.3.1, B2.3.4.5, B2.3.5.1
Test description: TD-32.1.3 Connection and Disconnect Test Description

32.3.4 The device must be capable of establishing a connection to a remote device when in non-connectable mode.

Reference document: WLP# - B2.3.3.1, B2.3.4.5, B2.3.5.1
Test description: TD-32.1.3 Connection and Disconnect Test Description

32.3.5 The device must reject a connection request from a remote device when in non-connectable mode.

Reference document: WLP# - B2.3.3.1, B2.3.4.5, B2.3.5.1
Test description: TD-32.1.3 Connection and Disconnect Test Description


Data Transfer Test Assertions

The following Bluetooth hardware assertions are tested in TD-32.1.4 Data Transfer Test Description.

32.4.1 The device must be capable of transferring data over an established channel.

Reference document: WLP# - B2.3.3.1, B2.3.4.5, B2.3.5.1
Test description: TD-32.1.4 Data Transfer Test Description

32.4.2 The device must be capable of accepting data from a remote device.

Reference document: WLP# - B2.3.3.1, B2.3.4.5, B2.3.5.1
Test description: TD-32.1.4 Data Transfer Test Description


Authentication and Encryption Test Assertions

The following Bluetooth hardware assertions are tested in TD-32.1.5 Authentication and Encryption Test Description.

32.5.1 The device must be capable of accepting a request for bonding from a remote device and establishing an encrypted channel.

Reference document: WLP# - B2.3.3.1, B2.3.4.5, B2.3.5.1
Test description: TD-32.1.5 Authentication and Encryption Test Description

32.5.2 The device must be capable of bonding with and establishing an encrypted connection to a remote device.

Reference document: WLP# - B2.3.3.1, B2.3.4.5, B2.3.5.1
Test description: TD-32.1.5 Authentication and Encryption Test Description


Bluetooth Test Descriptions

This section contains the detailed test descriptions for the Bluetooth tests.


TD-32.1 Bluetooth Controller Test

Test Kit: HCT 11

The Bluetooth Controller Test verifies conformance with the Windows Logo requirements for Bluetooth devices and compatibility with the Windows XP Bluetooth stack. Specifically, the test focuses on the host controller (the radio portion) of the test device.

Bluetooth Test System Overview

To run the Bluetooth tests, you need a Test System (which includes the test device) and a Test Control System. Together, these systems form a piconet. A piconet is a small, ad hoc network created when two or more Bluetooth-compatible devices share the same communications channel. One device acts as the master of the piconet, while the other devices act as slaves. Up to seven slaves can be active on a single piconet. To communicate, Bluetooth uses frequency hopping spread spectrum signals (FHSS). The master sets the hopping sequence and the slaves synchronize to the master.

To register, control and record the results of the tests, you must have an Ethernet connection between the Test System and the Test Control System.

Figure 1: Bluetooth Controller Test Configuration

Test System

The Test System must be a computer capable of running a version of the Windows XP operating system that incorporates the Microsoft Bluetooth software stack and the Bluetooth profiles required by the test device. The Bluetooth test device is attached to this system. For the specific operating system requirements, see the following Setup section.

Test Control System

The Test Control System drives the Bluetooth controller tests in a manner that verifies conformance to the Windows Logo requirements for Bluetooth devices and compatibility with the Windows XP Bluetooth stack. The Test Control System must be a computer capable of running a version of the Windows XP operating system that incorporates the Microsoft Bluetooth software stack. For the specific operating system requirements, see the following Setup section. A test application (Mjolnir.exe) runs on the Test Control System.

The Bluetooth device attached to the Test Control System must be an Authorized Bluetooth Control Device.

Authorized Bluetooth Control Devices

The Bluetooth radio portion of the Test Control System must be a known-good device. For the purposes of this test, certain devices have been recognized as Authorized Bluetooth Control Devices.

Cambridge Silicon Radio (http://www.csr.com), and Silicon Wave (http://www.siliconwave.com) provide the Authorized Bluetooth Control devices. Information on obtaining these devices is available on their respective web sites.

Overview of Test Steps

The Bluetooth Controller test completes the following steps for each protocol and profile to be tested:

  1. The test sets up any required structures or settings for running the tests.
  2. To synchronize test execution, two cooperating programs attempt to establish communication over a control channel (an IP connection). One program runs on the Test Control System and the other runs on the Test System. The program (Mjolnir.exe) attempts to find its counterpart on the local area network using TCP/IP. If the two systems are not on a TCP/IP network, the Bluetooth Controller test cannot run.
  3. After establishing communications, the following automated test cases run.

TD-32.1.1 Initialization Test

TD-32.1.2 Inquiry and Discovery Test

TD-32.1.3 Connection and Disconnect Test

TD-32.1.4 Data Transfer Test

TD-32.1.5 Authentication and Encryption Test

  4. The test logs the evidence of Bluetooth compliance to a file.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • Windows XP SP1 Bluetooth stack (available through SP1 supplemental OEM pre-install kit release and through independent hardware vendor redistribution)
  • Any drivers that do not ship with the operating system.
  • Bluetooth test device.
  • Authorized Bluetooth control device

Results Interpretation

The test generates a detailed log file of test results named Btdetail.log, and displays on-screen pass or fail status.


TD-32.1.1 Initialization Test

Test Kit: HCT 11

Overview

The Host Controller Interface (HCI) provides a command interface to the baseband controller and link manager, and access to hardware status and control registers. This interface provides a uniform method of accessing the Bluetooth baseband capabilities.

To be compatible with Windows XP, the HCI implementation must conform with the Microsoft white paper "The Bluetooth HCI interface to Windows XP," the Bluetooth Specification Version 1.1, Part H1, the Microsoft Windows Logo Program System and Device Requirements and with one of the following specifications:

  • Bluetooth Specification Version 1.1, Part H2, HCI USB Transport Layer
  • Bluetooth Specification Version 1.1, Part H4, HCI UART Transport Layer
  • HCI BCSP Transport Layer.

The test does not directly verify HCI compliance; however, the test device must implement the HCI correctly for successful completion of this test.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test runs automatically as a part of the Bluetooth Controller test. The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • Any drivers that do not ship with the operating system.
  • Bluetooth test device.
  • Authorized Bluetooth control device

Results Interpretation

The test generates a detailed log file of test results and displays on-screen pass or fail status. If this test fails, the test log may show the device as not loaded.


TD-32.1.2 Inquiry and Discovery Test

Test Kit: HCT 11

Overview

Bluetooth devices use the inquiry and discovery processes to search for and discover other Bluetooth-enabled devices and services within range.

This test verifies that that the test device can properly perform the inquiry and discovery processes, and that the test device properly responds to inquiries from other Bluetooth devices while it is in discoverable and non-discoverable modes.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test runs automatically as a part of the Bluetooth Controller test. The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • Any drivers that do not ship with the operating system.
  • Bluetooth test device.
  • Authorized Bluetooth control device

Results Interpretation

The test generates a detailed log file of test results and displays on-screen pass or fail status.


TD-32.1.3 Connection and Disconnect Test

Test Kit: HCT 11

Overview

This test verifies that the test device can initiate, accept, and terminate connections properly.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test runs automatically as a part of the Bluetooth Controller test. The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • Any drivers that do not ship with the operating system.
  • Bluetooth test device.
  • Authorized Bluetooth control device

Results Interpretation

The test generates a detailed log file of test results and displays on-screen pass or fail status.


TD-32.1.4 Data Transfer Test

Test Kit: HCT 11

Overview

This test verifies that the test device can accept and transfer data of various sizes over an established connection.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test runs automatically as a part of the Bluetooth Controller test. The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • Any drivers that do not ship with the operating system.
  • Bluetooth test device.
  • Authorized Bluetooth control device

Results Interpretation

The test generates a detailed log file of test results and displays on-screen pass or fail status.


TD-32.1.5 Authentication and Encryption Test

Test Kit: HCT 11

Overview

This test verifies that the test device can properly bond with, and can accept bonding to, a remote Bluetooth device.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

This test runs automatically as a part of the Bluetooth Controller test. The test environment requires the following hardware and software:

  • Windows XP Professional with Service Pack 1; Windows .NET Server 2003, Standard Edition; Windows .NET Server 2003, Enterprise Edition.
  • Any drivers that do not ship with the operating system.
  • Bluetooth test device.
  • Authorized Bluetooth control device

Results Interpretation

The test generates a detailed log file of test results and displays on-screen pass or fail status.


Chapter 33: Fault Tolerant Server Test Specification

Test Kit: HCT 11

This chapter specifies tests that determine compliance with key requirements for fault tolerant servers defined in Microsoft Windows Logo Program System and Device Requirements.

This chapter is intended as an overview of the tests, and as a guide to actual test development for software engineers. It is not designed to provide a complete test plan or testing procedures for fault tolerant servers.

Overview

A fault tolerant server must respond reliably in the event of hardware or software failure to ensure against loss of data. This test stresses the memory mirroring functions of the fault tolerant server set.

Physical Memory Mirroring is a new feature in Microsoft® Windows® .NET Server 2003, Enterprise Edition and Windows .NET Server 2003, Datacenter Edition. The underlying hardware technology is typically highly proprietary to each fault tolerant OEM and no uniform API to test this functionality currently exists. Because OEMs of fault-tolerant systems must provide a convenient means to test this new functionality, the fault tolerant test program has been developed in order to verify memory-mirroring functionality.

This test uses the same test mechanism used for stress-testing Windows .NET Server 2003, Datacenter Edition and server clusters, and shares some of the same low-level tests. Once the server system is placed under a load, the test initiates the creation (and subsequent destruction) of physical memory mirrors.

Stress Tests

These tests run in the background to provide a stress load, and if they do not fail, and the system runs for specified time, the test run is a success.

The stress tests include the following types of client-server tests:

  • File I/O using a SMB share
  • Winsock test
  • Terminal Server Virtual Channels API test
  • Local server-based tests

These tests are designed to stress the most common server services that users run on a high-end server system. By default, these tests run for 14 days, as required for fault tolerant server validation, at which time the tests shutdown. The log files from the individual tests are examined and summarized into one log file on the client master. This summary log (Mmtst.log) is used for submitting the results to WHQL. If the server fails the Fault Tolerant Server test, you can examine the individual log files on the client and server systems in detail to determine the specific reasons for failure during the test run.

The client-server tests are distributed across the client nodes. Not all tests will run on each client. The client tests will use the server's name or one of the associated IP addresses to access the server services.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

For test procedures and the specific hardware and software requirements for running this test, see the Fault Tolerant Server Test in the HCT kit.

Click to show or hide information. Interpreting the logs

When the Fault Tolerant Server is complete a summary log (Mmtst.log) is generated. If all of the tests started successfully the first part of the log will be a listing of the machines involved. The log file should look something like the following:

****

+VAR+INFO 0 : [] : 2195 Service Pack 1, cpu:0, level:6, num: 1, mem:511, page: 1023

<computer>: is the computer name of the system

<type>: is either client, node or local

cpu: is the platform type ( 0 for x86, 2 for alpha) any entry for IA64?

level: is the level of the chip ( 4, 5, 6 for x86 21064, 21164 for alpha)

num: is the number of processors in the system

mem: is the amount of physical memory (in meg)

page: is the max commit limit (in meg)

If the test failed to complete there should be a line like this:

+VAR+SEV2 0 : Test stopped with XXX minutes elapsed.

Where XXX is less than the expected time. This should be next to another line indicating the state the test was in when it exited.

+VAR+SEV2 1 : Tests did not complete

Exiting while in state: <StateText> : <StateNum>

Possible states include:

<StateText> | Description
Unknown: | This is an unmapped error the indicates the value.
Stopped:, Connect_Error, Start_Error Running and Stop_Error: | The test was stopped by the user while in this state.
Running_Error: | This indicates a failure in one of the critical processes. This usually means that communication was lost with an Spsrv process on one of the systems. This could be due to a network problem or could indicate that one of the test systems crashed or rebooted.
Others | The logging and other special purpose options.

The critical process that failed is usually indicated a few lines above the "Exiting while…" statement. For example, if the Run_dtc_bangfs.cmd test exited, you would see a message similar to the following:

+VAR+SEV2 0 : A critical process: cmd.exe run_dtc_Bangfs.cmd has stopped on <computer-name>

In this case, to get more information, you look for the file Run_dtc_bangfs.log on <computer-name>. If Spsrv is the critical process, look for the file %Windir%\System32\Spsrv.log. For most other test processes the log file is located in the %Windir%\Mmtest or one of the Mmtest subdirectories.

The Fault Tolerant test does not restart the system. Therefore, if one of the systems was restarted, or if it stops responding, it usually indicates that the system crashed.

By default, the test creates the Memory.dmp file in the %Windir% directory. You can use a debugger from the Windows DDK to examine this file. Alternatively, you could install the kernel debugger on a separate system (such as the client master) and catch the crash as it occurs. For information on setting up a debugger, and on kernel mode debugging in general, see the Windows DDK documentation. The Windows DDK also covers debugging a crash dump.

If the system stops before the boot option prompt during startup, you may have a hardware/firmware problem. Consult your vendor on how to resolve this issue.

If you suspect a communication problem, you can find additional debugging information in the Spsrv.log. The Spsrv.log is in the %Windir%\System32 directory on every system running Spsrv as a service. On the client master, the Spsrv.log is in the HCT\Testbin directory with the other test logs. Communication problems are usually a result of problems in the network configuration. Consult your systems administrator, and refer to the network adapter validation in the HCT kit.

If the test ran to completion it is still possible for the test to fail if:

  1. Communications are lost to one or more of client Spsrv processes.
  2. Communications are lost with the server node (that is, the server in the server test kit)
  3. Clean up of the test resources failed.
  4. The test started without sufficient client Spsrv processes, node Spsrv processes, or the local Spsrv process registered with Valdkit.exe.

This last point can be verified by counting the number of Spsrv processes of each of the respective types. There should be a list of the processes running at the time the test exited in the log file. The list is in the form:

+VAR+INFO 2 : <process>|<pid>|<mem>|<state>|<elapsed> <time>|<computer>|<type>


Fault Tolerant Server Test Assertions

This section contains the detailed list of Fault Tolerant Server test assertions.

File I/O Testing Using an SMB Share Test Assertions

Assertions in this section are tested in TD-33.1 File I/O Testing Using an SMB Share Test Description.

33.1.1 The system must pass an asynchronous I/O stress test

The different variables for test combinations include:

Buffered/unbuffered I/O

Pre-allocated disk space/new file

Extending existing file/over writing existing file

Size of the target file

Number of concurrent I/O threads

Size of each I/O

Reference document: WLP# - A6.4.7; Fault-Tolerant Hardware
Test description: TD-33.1 File I/O Testing Using an SMB Share Test Descriptions

33.1.2 [DELETED]

The File System Compression test has been removed from the HCT kit.


IIS Testing (Winsock test) Test Assertions

Assertions in this section are tested in TD-33.4 IIS Testing (Winsock test ) Test Description

33.4.1 The IIS server must return correct data from the drives.

Reference document: WLP# - A6.4.7; Fault-Tolerant Hardware
Test description: TD-33.4 IIS Testing (Winsock test ) Test Descriptions


Terminal Server Virtual Channels API Test Assertions

Note The TD-33.6 Terminal Server Virtual Channels API test has been removed from the HCT kit. The assertion 33.6.1 is no longer tested.

33.6.1 [DELETED]


Kernel Stress Test Assertions

Assertions in this section are tested in TD-33.7 Kernel Stress Tests Description

33.7.1 The system must pass a multithreaded stress test for the heap manager.

Reference document: WLP# - A6.4.7; Fault-Tolerant Hardware
Test description: TD-33.7 Kernel Stress Tests Description

33.7.2 The system must pass a stress test for heap look-aside lists.

Reference document: WLP# - A6.4.7; Fault-Tolerant Hardware
Test description: TD-33.7 Kernel Stress Tests Description

33.7.3 The system must pass a stress test for cache manager.

Reference document: WLP# - A6.4.7; Fault-Tolerant Hardware
Test description: TD-33.7 Kernel Stress Tests Description

33.7.4 The system must pass a stress test for the virtual space manager.

Reference document: WLP# - A6.4.7; Fault-Tolerant Hardware
Test description: TD-33.7 Kernel Stress Tests Description

33.7.5 The system must pass a stress test for race conditions.

Reference document: WLP# - A6.4.7; Fault-Tolerant Hardware
Test description: TD-33.7 Kernel Stress Tests Description

33.7.6 The system must pass a stress tests using the Configuration Manager (CM) APIs to make calls to the kernel Plug and Play Manager.

Reference document: WLP# - A6.4.7; Fault-Tolerant Hardware
Test description: TD-33.7 Kernel Stress Tests Description


Kernel Regression Test Assertions

Assertions in this section are tested in TD-33.14 Kernel Regression Test Description

33.14.1 The system must pass a regression test for memory allocation APIs.

Reference document: WLP# - A6.4.7; Fault-Tolerant Hardware
Test description: TD-33.14 Kernel Regression Test Descriptions

33.14.2 The system must pass a regression test for HeapAlloc & HeapRealloc APIs.

Reference document: WLP# - A6.4.7; Fault-Tolerant Hardware
Test description: TD-33.14 Kernel Regression Test Descriptions

33.14.3 The system must pass a regression test for kernel-mode addresses protection.

Reference document: WLP# - A6.4.7; Fault-Tolerant Hardware
Test description: TD-33.14 Kernel Regression Test Descriptions

33.14.4 The system must pass a Floating point test exercises math operations.

Reference document: WLP# - A6.4.7; Fault-Tolerant Hardware
Test description: TD-33.14 Kernel Regression Test Descriptions

33.14.5 The system must pass a regression test for MoveMemory, CopyMemory, ZeroMemory and FillMemory functions.

Reference document: WLP# - A6.4.7; Fault-Tolerant Hardware
Test description: TD-33.14 Kernel Regression Test Descriptions

33.14.6 The system must pass a regression test for NtWaitForSingleObject, NtWaitForMultipleObjects and NtSignalandWaitForSingleObject APIs.

Reference document: WLP# - A6.4.7; Fault-Tolerant Hardware
Test description: TD-33.14 Kernel Regression Test Descriptions

33.14.7 The system must pass a regression test for CreateFiber, GetFiberData, GetCurrentFiber, SwitchToFiber, ConvertThreadToFiber, DeleteFiber, SetThreadIdealProcessor, QueueUserAPC, InterlockedExchangeAdd and InterlockedCompareExchange APIs.

Reference document: WLP# - A6.4.7; Fault-Tolerant Hardware
Test description: TD-33.14 Kernel Regression Test Descriptions

33.14.8 The system must pass a regression test for race condition at thread/process termination.

Reference document: WLP# - A6.4.7; Fault-Tolerant Hardware
Test description: TD-33.14 Kernel Regression Test Descriptions

33.14.9 The system must pass a regression test for thread pooling.

Reference document: WLP# - A6.4.7; Fault-Tolerant Hardware
Test description: TD-33.14 Kernel Regression Test Descriptions

33.14.10 The system must pass a regression test for Memory Management PDK.

Reference document: WLP# - A6.4.7; Fault-Tolerant Hardware
Test description: TD-33.14 Kernel Regression Test Descriptions


Fault Tolerant Server Test Descriptions

This section contains the detailed test descriptions.

TD-33.1 File I/O Testing Using an SMB Share Test Description

Overview

These tests require that one of the test drives be set up with a file share. This file share is automatically setup by the process (valdkit.exe) that is started on the client monitoring system.

Click to show or hide information. Asynchronous I/O stress test

This test (ios_unbufw.exe) performs asynchronous writes and reads in various combinations in attempt to stress parts of the asynchronous I/O system. This test uses completion ports to perform the asynchronous I/O.

The different variables for test combinations include:

  • Buffered/unbuffered I/O
  • Pre-allocated disk space/new file
  • Extending existing file/over writing existing file
  • Size of the target file
  • Number of concurrent I/O threads
  • Size of each I/O

The I/O is written out in a computable pattern and then read back and verified. If an error is detected, the test will optionally force a break into the debugger so that someone familiar with the inner workings of file systems can examine the state of the system. In the HCT kit, this feature is disabled and errors are simply written to the log file (Unbufw.log).

Click to show or hide information. File System Compression test

Note The File System Compression test has been removed.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Note All components in the Client and Server systems must be validated (logo'd) prior to running this test on Windows .NET Server 2003, Datacenter Edition or Windows .NET Server 2003, Enterprise Edition. Components that are not validated (logo'd) on the HCL must pass HCT tests prior to running this test.

The following software is required to run this test:

  • Windows .NET Server 2003, Datacenter Edition or Windows .NET Server 2003, Enterprise Edition operating system for the test server
  • Windows .NET Server 2003, Enterprise Edition operating system for the remote test host
  • Windows® XP Professional (the latest update) for the eight client systems
  • The current release of the Windows HCT 11.0 kit
  • Microsoft Terminal Server for the test server
  • An OEM supplied dynamic-link library (OEMDLL.DLL) that translates the Mmtest.exe function requests to the form needed by the OEM proprietary drivers and HAL that manage and operate the memory mirror hardware. For more information on this file, see the OEMDLL.DLL requirements for the Fault Tolerant Server test in the HCT kit.

Results Interpretation

Review the test logs and other sources of network information:

  • The file Mmtst.log in the HCT\Testbin directory
  • The file Spsrv.log in the HCT\Testbin directory on the client master and in the %Windir%\System32 directory on the server and the clients.
  • The *.log and *.txt files from %Windir%\Mmtest\ and underneath directories on all client(s) and the server.
  • System and Application event logs from the Server system.
  • Output from the command Ipconfig /all on all systems.
  • Output from the command net use on all systems
  • Output from ping and net view commands from the client master against the server and the clients
  • Output from ping and net view commands from the server against the clients and the client master.


TD-33.4 IIS Testing (Winsock test) Test Description

Overview

As part of the server setup script, the Valdkit test program copies some HTML files to the test drives. The test then sets up virtual directories pointing to the target test disks. It modifies the Microsoft® Internet Information Server (IIS) client tests to continually poll the IIS server for information. This test simulates what an Internet Explorer version 3.0 (or higher) or other browser client would see by constantly accessing the IIS pages on the server. It will also retry in the case of errors being returned from the IIS server. The test performs operations to make sure that the IIS server is returning correct data from the test drives.

This test is totally automated, and connects to the IIS virtual root on each disk using the network name. A virtual root is a mapping from an IIS alias to a physical location on a disk located on the IIS server machine. A typical example would be http:\\ServerName\Home mapped to I:\wwwroot\home.html, where ServerName is the network name and Home is the IIS alias or virtual root.

There are two virtual roots for each disk:

WWW root

FTP root

The clients access specific files for each virtual root. For the WWW and FTP roots, the Valdkit test program copies HTML files from the client monitoring system to the server.

Winsock Sock_Srv/Sock_Clnt Test

This test runs a pair of client-server applications that test the ability of Winsock to accept a large number of connections, a scenario similar to a Web/FTP server. Only one system can be running the server executable file (Sockdies.exe). There is no restriction on the number of client machines that can run the client executable file (Sockdiec.exe).

Problem Resolution:

The type of the server system, as well as the number of clients connected, greatly affects the results.

Each side (client or server), creates a log file called

sockdie{s,c}.log.<computer name>

This test stresses the system and runs without interruption for as long as the system is up. The test will only exit on fatal error conditions, such as extremely low resource availability.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Note All components in the Client and Server systems must be validated (logo'd) prior to running this test on Windows .NET Server 2003, Datacenter Edition or Windows .NET Server 2003, Enterprise Edition. Components that are not validated (logo'd) on the HCL must pass HCT tests prior to running this test.

The following software is required to run this test:

  • Windows .NET Server 2003, Datacenter Edition or Windows .NET Server 2003, Enterprise Edition operating system for the test server
  • Windows .NET Server 2003, Enterprise Edition operating system for the remote test host
  • Windows® XP Professional (the latest update) for the eight client systems
  • The current release of the Windows HCT 11.0 kit
  • Microsoft Terminal Server for the test server
  • An OEM supplied dynamic-link library (OEMDLL.DLL) that translates the Mmtest.exe function requests to the form needed by the OEM proprietary drivers and HAL that manage and operate the memory mirror hardware. For more information on this file, see the OEMDLL.DLL requirements for the Fault Tolerant Server test in the HCT kit.

Results Interpretation

Review the test logs and other sources of network information:

  • The file Mmtst.log in the HCT\Testbin directory
  • The file Spsrv.log in the HCT\Testbin directory on the client master and in the %Windir%\System32 directory on the server and the clients.
  • The *.log and *.txt files from %Windir%\Mmtest\ and underneath directories on all client(s) and the server.
  • System and Application event logs from the Server system.
  • Output from the command Ipconfig /all on all systems.
  • Output from the command net use on all systems
  • Output from ping and net view commands from the client master against the server and the clients
  • Output from ping and net view commands from the server against the clients and the client master.


TD-33.6 Terminal Server Virtual Channels API test Description

Note This test has been removed from the HCT kit.


TD-33.7 Kernel Stress Tests Description

Overview

All these local server-based tests run on the server.

Click to show or hide information. Heap - Multithreaded test

The Kernel Stress tests consists of two test programs: Launheap.exe and Heaptest.exe.

The program Launheap.exe launches the Heaptest.exe test program with appropriate parameters, which include the number of iterations, allocations limit, maximum size of a single allocation, the number of threads and a seed value.

The program Heaptest.exe is a multithreaded stress test for the heap manager. It creates a heap and then starts some number of threads. In every thread, blocks of memory from the heap are allocated, verified, reallocated and freed.

The errors encountered are not recorded, the target of this test being major problems in the operating system (blue screen crash events, bug checks, etc.).

Click to show or hide information. Heap Lookaside test

The Heap Lookaside test is a stress test for heap lookaside lists.

The test starts a number of threads. In every thread a heap is created and blocks of memory from the heap are allocated, verified, reallocated and freed.

This test is a stress application designed to run without interruption for as long as the system is up. It will only exit on fatal error conditions, like extremely low resource availability. The errors encountered are not recorded, the target of this test being major problems in the operating system (blue screen crash events, bug checks, etc.).

Click to show or hide information. Cache1 test

The Cache1 test is a stress test for cache manager. The test launches one write thread and several read threads. After some amount of information is written the reading threads verify it. The data written at any location is the not of the offset at that location. The write thread seeks to any random location and writes a random size region. It keeps track of the region it has written to and the regions it hasn't written to. The reading thread verifies both the non-zero and zero regions.

This test is a stress application designed to run without interruption for as long as the system is up. It will only exit on fatal error conditions, like extremely low resource availability. The errors encountered are not recorded, the target of this test being major problems in the operating system (blue screen crash events, bug checks, etc.).

Click to show or hide information. Witness Map test

The Witness Map test is a stress test for the virtual space manager. It dynamically stresses the memory manager with commit/free scenarios. The main property of the test is that it automatically adapts to the memory available and tries to use as much memory as possible.

This test is a stress application designed to run without interruption for as long as the system is up. It will only exit on fatal error conditions, like extremely low resource availability. The errors encountered are not recorded, the target of this test being major problems in the operating system (blue screen crash events, bug checks, etc.).

Click to show or hide information. Race test

The Race test is a stress test for race conditions. There are two threads, the worker that tries to perform some work by calling a system API, and the breaker that tries at the same time to free the worker's buffers. The purpose of the test is to assure that the API can recover from this kind of error.

This test is a stress application designed to run without interruption for as long as the system is up. It will only exit on fatal error conditions, like extremely low resource availability. The errors encountered are not recorded, the target of this test being major problems in the operating system (blue screen, bug checks, etc.).

Click to show or hide information. BPStress test

The BPStress test is part of the system stress suite. It uses the Configuration Manager (CM) APIs to make calls to the kernel Plug and Play Manager, and it attempts to use those CM calls that are more likely to cause problems.

The test will create two threads that will perform independent testing. Each thread will traverse the whole device tree and will call the same API or API sequence for each node. One thread will make a top-bottom traversal, while the second will do a bottom-up one. After each thread completed its traversal, they enter in a sleep state for a random amount of time. The choice of the next test to be performed is also randomly.

This test is a stress application designed to run without interruption for as long as the system is up. It will only exit on fatal error conditions, like extremely low resource availability. The errors encountered are not recorded, the target of this test being major problems in the operating system (blue screen crash events, bug checks, etc.).

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Note All components in the Client and Server systems must be validated (logo'd) prior to running this test on Windows .NET Server 2003, Datacenter Edition or Windows .NET Server 2003, Enterprise Edition. Components that are not validated (logo'd) on the HCL must pass HCT tests prior to running this test.

The following software is required to run this test:

  • Windows .NET Server 2003, Datacenter Edition or Windows .NET Server 2003, Enterprise Edition operating system for the test server
  • Windows .NET Server 2003, Enterprise Edition operating system for the remote test host
  • Windows® XP Professional (the latest update) for the eight client systems
  • The current release of the Windows HCT 11.0 kit
  • Microsoft Terminal Server for the test server
  • An OEM supplied dynamic-link library (OEMDLL.DLL) that translates the Mmtest.exe function requests to the form needed by the OEM proprietary drivers and HAL that manage and operate the memory mirror hardware. For more information on this file, see the OEMDLL.DLL requirements for the Fault Tolerant Server test in the HCT kit.

Results Interpretation

Review the test logs and other sources of network information:

  • The file Mmtst.log in the HCT\Testbin directory
  • The file Spsrv.log in the HCT\Testbin directory on the client master and in the %Windir%\System32 directory on the server and the clients.
  • The *.log and *.txt files from %Windir%\Mmtest\ and underneath directories on all client(s) and the server.
  • System and Application event logs from the Server system.
  • Output from the command Ipconfig /all on all systems.
  • Output from the command net use on all systems
  • Output from ping and net view commands from the client master against the server and the clients
  • Output from ping and net view commands from the server against the clients and the client master.


TD-33.14 Kernel Regression Test Description

Overview

All of these local server-based tests run on the server.

Click to show or hide information. GLAlloc test

The Global alloc test is a regression test for memory allocation APIs.

First the test passes bad parameters to GlobalAlloc and verifies the result. Then it fragments the memory by allocating and freeing 1M blocks interspersed with 4K blocks. It also allocates local memory with LMEM_FIXED and tries to get a handle to the memory. Then it creates an able to grow heap, makes large size allocations and verifies that it is possible to walk through the heap and find the allocations.

The test creates a log file named galloc.log in the %windir%\mmtest\ directory.

Click to show or hide information. HAlloc test

The Halloc test is a regression test for HeapAlloc & HeapRealloc APIs.

The test creates a heap and then gets the heap allocated using HeapAlloc / HeapRealloc. The allocated heap is verified to conform to the flags specified.

The test creates a log file named Halloc.log in the %Windir%\Mmtest\ directory.

Click to show or hide information. AddrProt test

The Address Protection test is kernel regression test for kernel-mode addresses protection.

It tries to read and write kernel-mode addresses and reports a bug if any of this operations succeeded.

The test creates a log file named KrrnAddr.log in the %Windir%\Mmtest\ directory.

Click to show or hide information. Floating Point test

The Floating Point test exercises math operations.

The test creates a log file named Paranoia.log in the %Windir%\Mmtest directory.

Click to show or hide information. Move/Copy/Zero/FillMemory test

The Move/Copy/Zero/FillMemory test performs MoveMemory, CopyMemory, ZeroMemory and FillMemory functions.

The test creates a log file named Movecopy.log in the %Windir%\Mmtest directory.

Click to show or hide information. WaitObj Regress test

The WaitObj Regress test is a regression test for NtWaitForSingleObject, NtWaitForMultipleObjects and NtSignalandWaitForSingleObject APIs.

The test creates an event object or an array of the objects and verifies that if an event object or the objects signaled than a correspondent API would give a proper result. Also it verifies that the API would time out if an Event object did not signal.

The test creates a log file named Waitobjregrs.log in the %Windir%\Mmtest\ directory.

Click to show or hide information. APCs and Fibers test

The test is a regression test for CreateFiber, GetFiberData, GetCurrentFiber, SwitchToFiber, ConvertThreadToFiber, DeleteFiber, SetThreadIdealProcessor, QueueUserAPC, InterlockedExchangeAdd and InterlockedCompareExchange APIs.

The test converts threads to fibers, creates fibers, when every fiber is executed it deletes them and verifies the result of execution. It queues APCs for test threads and verifies the result.

The test creates a log file named Apcfiber.log in the %Windir%\Mmtest\ directory.

Click to show or hide information. TermRace test

The test is a regression test for race condition at thread/process termination.

In this test a process/thread is terminated while having a pending APC.

The test creates a log file named TermRace.log in the %Windir%\Mmtest\ directory.

Click to show or hide information. ThreadPool Timer Queue test

The test is a regression test for thread pooling. It creates timer queues, timers in queues, changes time due for timers, deletes timers and queues, verifies that all the timers fired properly and callback threads started as intended.

The test creates a log file named Tptimerq.log in the %Windir%\Mmtest\ directory.

Click to show or hide information. Memory Management PDK test

The test is a regression test for Memory Management PDK. It creates the number of threads where all memory allocations are done. Then the test verifies that the allocations made by different threads are transparent to each other.

The test creates a log file named Memmpdkt.log in the %Windir%\Mmtest directory.

Click to show or hide information. Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Note All components in the Client and Server systems must be validated (logo'd) prior to running this test on Windows .NET Server 2003, Datacenter Edition or Windows .NET Server 2003, Enterprise Edition. Components that are not validated (logo'd) on the HCL must pass HCT tests prior to running this test.

The following software is required to run this test:

  • Windows .NET Server 2003, Datacenter Edition or Windows .NET Server 2003, Enterprise Edition operating system for the test server
  • Windows .NET Server 2003, Enterprise Edition operating system for the remote test host
  • Windows® XP Professional (the latest update) for the eight client systems
  • The current release of the Windows HCT 11.0 kit
  • Microsoft Terminal Server for the test server
  • An OEM supplied dynamic-link library (OEMDLL.DLL) that translates the Mmtest.exe function requests to the form needed by the OEM proprietary drivers and HAL that manage and operate the memory mirror hardware. For more information on this file, see the OEMDLL.DLL requirements for the Fault Tolerant Server test in the HCT kit.

Results Interpretation

Review the test logs and other sources of network information:

  • The file Mmtst.log in the HCT\Testbin directory
  • The file Spsrv.log in the HCT\Testbin directory on the client master and in the %Windir%\System32 directory on the server and the clients.
  • The *.log and *.txt files from %Windir%\Mmtest\ and underneath directories on all client(s) and the server.
  • System and Application event logs from the Server system.
  • Output from the command Ipconfig /all on all systems.
  • Output from the command net use on all systems
  • Output from ping and net view commands from the client master against the server and the clients
  • Output from ping and net view commands from the server against the clients and the client master.


Chapter 34 Intel Itanium Machine Check Architecture (MCA) Test Specification

WHQL Test Specification

Previous Next

Chapter 34: Intel Itanium Machine Check Architecture (MCA) Test Specification

This chapter describes the machine check error handling requirements and the tests that determine hardware compliance with the Microsoft® Windows® Logo Program System and Device Requirements.

The Intel® Itanium™ machine check architecture provides error handling features for fault detection, correction, and recovery.

The Machine Check test determines whether a platform delivers the appropriate information in error records for machine checks. These records are delivered from the System Abstraction Layer (SAL) and are reported by Windows through the Windows Management Interface (WMI).

Error records delivered to Windows must be compliant with the Intel SAL 3.0 specification, and all WHQL requirements, including the PC 2001 System Design Guide. The test compares the information in the delivered error record to these requirements.


Intel Itanium Machine Check Architecture Test Reference

Functional requirements are specified in the following documents:

Microsoft® Design Guide 3.0

http://www.Microsoft.com/hwdev/platform/pcdesign/desguide/serverdg.asp

Microsoft Hardware Developer Information

http://www.microsoft.com/hwdev/default.asp

Intel System Abstraction Layer 3.0 Specification

http://developer.intel.com/design/itanium/downloads/245359.htm

Intel Itanium Processor Family Error Handling Guide

http://developer.intel.com/design/itanium/downloads/249278.htm


Machine Check Architecture Test Assertions

The following sections describe the MCA test assertions.


Record Header Assertions

These assertions are tested in TD-34.1 Machine Check Errors Test Description.

34.1.1 The REVISION field must match SAL 3.0 Specification or greater.

Reference Document: WLP # - A5.1.3
Test Description: TD-34.1 Machine Check Errors Test Description

34.1.2 The ERR_SEVERITY field must contain a value of 0 or 1 for fatal error records.

Reference Document: WLP # - A5.1.3
Test Description: TD-34.1 Machine Check Errors Test Description

34.1.3 The ERR_SEVERITY field must contain a value of 2 for corrected errors.

Reference Document: WLP # - A5.1.3
Test Description: TD-34.1 Machine Check Errors Test Description

34.1.4 The reserved bits in the ERR_SEVERITY field must contain a 0 value.

Reference Document: WLP # - A5.1.3
Test Description: TD-34.1 Machine Check Errors Test Description

34.1.5 The reserved bits in the VALIDATION_BITS field must contain a 0 value.

Reference Document: WLP # - A5.1.3
Test Description: TD-34.1 Machine Check Errors Test Description

34.1.6 The RECORD_LEN field must match the total size of the Record Header and all sections.

Reference Document: WLP # - A5.1.3
Test Description: TD-34.1 Machine Check Errors Test Description

34.1.7 The TIME_STAMP field must contain valid data.

Reference Document: WLP # - A5.1.3
Test Description: TD-34.1 Machine Check Errors Test Description


Section Header Assertions

These assertions are tested in TD-34.1 Machine Check Errors Test Description.

34.2.1 The GUID field must contain the proper GUID for the error type.

Reference Document: WLP # - A5.1.3
Test Description: TD-34.1 Machine Check Errors Test Description

34.2.2 The REVISION field must match SAL 3.0 Specification or greater.

Reference Document: WLP # - A5.1.3
Test Description: TD-34.1 Machine Check Errors Test Description

34.2.3 If the error is not corrected, bit 0 in the ERROR_RECOVERY_INFO field must not be set.

Reference Document: WLP # - A5.1.3
Test Description: TD-34.1 Machine Check Errors Test Description

34.2.4 If the error is corrected, bit 0 in the ERROR_RECOVERY_INFO field must be set.

Reference Document: WLP # - A5.1.3
Test Description: TD-34.1 Machine Check Errors Test Description

34.2.5 If the error is corrected, the Containment Warning bit (bit 1) in the ERROR_RECOVERY_INFO field must not be set.

Reference Document: WLP # - A5.1.3
Test Description: TD-34.1 Machine Check Errors Test Description

34.2.6 If the error is corrected, the Reset bit (bit 2) in the ERROR_RECOVERY_INFO field must not be set.

Reference Document: WLP # - A5.1.3
Test Description: TD-34.1 Machine Check Errors Test Description

34.2.7 Bits 6-3 in the ERROR_RECOVERY_INFO field are reserved and must be null.

Reference Document: WLP # - A5.1.3
Test Description: TD-34.1 Machine Check Errors Test Description

34.2.8 The RESERVED field must contain a 0 value.

Reference Document: WLP # - A5.1.3
Test Description: TD-34.1 Machine Check Errors Test Description


Processor Device Error Section Assertions

These assertions are tested in TD-34.1 Machine Check Errors Test Description.

34.3.1 If the error is recoverable, the PSI_STATIC_STRUCT_VALID_BIT must be set.

Reference Document: WLP # - A5.1.3
Test Description: TD-34.1 Machine Check Errors Test Description

34.3.2 For cache errors, the CACHE_CHECK_NUM bits in the PROCESSOR_SPECIFIC_ERROR_RECORD body structure must contain the correct number of cache errors.

Reference Document: WLP # - A5.1.3
Test Description: TD-34.1 Machine Check Errors Test Description

34.3.3 For each cache error, the CACHE_ERROR_STRUCT must be correctly populated.

Reference Document: WLP # - A5.1.3
Test Description: TD-34.1 Machine Check Errors Test Description

34.3.4 If the error is recoverable, the PSI_STATIC_STRUCT must be correctly populated.

Reference Document: WLP # - A5.1.3
Test Description: TD-34.1 Machine Check Errors Test Description


TD-34.1 Machine Check Errors Test Description

Test Kit: HCT 11

The MCA test determines whether a platform delivers appropriate information in error records for machine checks. These records are delivered from the System Abstraction Layer (SAL) and are reported by Windows through the Windows Management Interface (WMI).

Error records delivered to Windows must be compliant with the Intel SAL 3.0 specification, and all WHQL requirements including the System Design Guide. The test compares the information in the delivered error record to these requirements.

Overview of Test Steps

The test program first inserts a fatal error to generate a Machine Check Abort event. This necessarily generates a bug check and forces the system to restart. Upon startup, the system should report the error to the Hardware Abstraction Layer (HAL), and then pass it to the WMI. The test program then queries WMI for the fatal error record, and then tests the record.

After this, the test registers itself with WMI as a temporary event consumer for machine checks. The test program inserts a correctable error and waits for WMI notification that a machine check for this event occurred. Upon notification, it receives the error record and tests it.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The MCA tests require that the test system is an Intel® Itanium™-based system running firmware compliant with the SAL 3.0 specification.

The test requires that the target system be running one of the 64-bit versions of the Windows® .NET Server 2003 family. In addition, a driver must be installed that allows the insertion of the error events.

Results Interpretation

The test generates a detailed log file of test results and displays on-screen pass or fail status.


Chapter 35: Media Appliance Test Specification

Overview

The Media Appliance test specification defines the requirements and test tools needed to ensure that the transfer of content to the media appliance device provides a rich user experience. The client transfer software must provide a Microsoft® Windows Media™ Device Manager (WMDM) Service Provider (SP) as described in the Microsoft Platform Software Development Kit (SDK).

This specification also outlines the tests that verify the requirements for Portable Audio Players.


Reference Documents for Media Appliance Test Assertions

Functional requirements specified in the following documents:

Microsoft® Platform Software Development Kit (SDK)

http://www.microsoft.com/msdownload/platformsdk/sdkupdate/

Also provided through MSDN Professional subscription

Microsoft® Windows Driver Development Kit (DDK)

http://www.microsoft.com/ddk/


Portable Audio Player Test Assertions

This section contains the detailed list of test assertions for the Portable Audio Player test.


WMDM Content Transfer Test Assertions

This section contains test assertions related to transferring content to various media appliance device types. The content includes Window Media™ Audio (WMA) format and MPEG-1 audio layer 3 (MP3) format.

These test assertions are used in the TD-35.2 WMDM Content Transfer Test.

35.1.1 The device must be able to accept the transfer of multiple WMA format files through WMDM.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK
Test description: TD–35.2 WMDM Content Transfer Test

35.1.2 The device must be able to fail gracefully when the storage capacity of the device is exceeded during the transfer of WMA format files.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK
Test description: TD–35.2 WMDM Content Transfer Test

35.1.3 The device must be able to accept initialization of the device storage and the transfer of WMA format files.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK
Test description: TD–35.2 WMDM Content Transfer Test

35.1.4 The device must be able to accept the transfer of multiple MP3 format files.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK
Test description: TD–35.2 WMDM Content Transfer Test

35.1.5 The device must be able to fail gracefully when the storage capacity of the device is exceeded during the transfer of WMA format files.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK
Test description: TD–35.2 WMDM Content Transfer Test

35.1.6 The device must be able to accept initialization of the device storage and the transfer of WMA format files.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK
Test description: TD–35.2 WMDM Content Transfer Test


WMDM Service Provider Test Assertions

The following section lists the test assertions related to the Service Provider (SP) plug-in module. The Microsoft® Windows Media™ Device Manager (WMDM) uses this module to enumerate and control media devices. The SP must implement all documented interfaces and return the appropriate return codes.


IMDServiceProvider Interface Test Assertions

These test assertions are used in the TD-35.1 WMDM Service Provider Test. Implementation details and expected return codes for valid and invalid parameters are described in the Microsoft® Platform Software Development Kit (SDK).

35.2.1.1 The client transfer software must correctly implement the IMDServiceProvider::GetDeviceCount method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.1.2 The client transfer software must correctly implement the IMDServiceProvider::EnumDevices method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test


IMDSPDevice Interface Test Assertions

These test assertions are used in the TD-35.1 WMDM Service Provider Test. The Microsoft® Platform Software Development Kit (SDK) describes implementation details and expected return codes for valid and invalid parameters.

35.2.2.1 The client transfer software must correctly implement the IMDSPDevice::GetDeviceIcon method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.2.2 The client transfer software must correctly implement the IMDSPDevice::GetFormatSupport method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.2.3 The client transfer software must correctly implement the IMDSPDevice::EnumStorage method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.2.4 The client transfer software must correctly implement the IMDSPDevice::GetManufacturer method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.2.5 The client transfer software must correctly implement the IMDSPDevice::GetName method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD – 35.2 WMDM Service Test

35.2.2.6 The client transfer software must correctly implement the IMDSPDevice::GetPowerSource method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.2.7 The client transfer software must correctly implement the IMDSPDevice::GetSerialNumber method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.2.8 The client transfer software must correctly implement the IMDSPDevice::GetStatus method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.2.9 The client transfer software must correctly implement the IMDSPDevice::GetType method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.2.10 The client transfer software must correctly implement the IMDSPDevice::GetVersion method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.2.11 The client transfer software must correctly implement the IMDSPDevice::SendOpaqueCommand.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test


IMDSPEnumDevice Interface Assertions

These test assertions are used in the TD-35.1 WMDM Service Provider Test. The Microsoft® Platform Software Development Kit (SDK) describes implementation details and expected return codes for valid and invalid parameters.

35.2.3.1 The client transfer software must correctly implement the IMDSPEnumDevice::Clone method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.3.2 The client transfer software must correctly implement the IMDSPEnumDevice::Next method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.3.3 The client transfer software must correctly implement the IMDSPEnumDevice::Reset method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.3.4 The client transfer software must correctly implement the IMDSPEnumDevice::Skip method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test


IMDSPEnumStorage Interface Assertions

These test assertions are used in the TD-35.1 WMDM Service Provider Test. The Microsoft® Platform Software Development Kit (SDK) describes implementation details and expected return codes for valid and invalid parameters.

35.2.4.1 The client transfer software must correctly implement the IMDSPEnumStorage::Clone method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.4.2 The client transfer software must correctly implement the IMDSPEnumStorage::Next method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.4.3 The client transfer software must correctly implement the IMDSPEnumStorage::Reset method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.4.4 The client transfer software must correctly implement the IMDSPEnumStorage::Skip method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test


IMDSPObject Interface Assertions

These test assertions are used in the TD-35.1 WMDM Service Provider Test. The Microsoft® Platform Software Development Kit (SDK) describes implementation details and expected return codes for valid and invalid parameters.

35.2.5.1 The client transfer software must correctly implement the IMDSPObject::Close method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.5.2 The client transfer software must correctly implement the IMDSPObject::Delete method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.5.3 The client transfer software must correctly implement the IMDSPObject::Move method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.5.4 The client transfer software must correctly implement the IMDSPObject::Open method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.5.5 The client transfer software must correctly implement the IMDSPObject::Read method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.5.6 The client transfer software must correctly implement the IMDSPObject::Rename method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.5.7 The client transfer software must correctly implement the IMDSPObject::Seek method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.5.8 The client transfer software must correctly implement the IMDSPObject::Write method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test


IMDSPStorage Interface Assertions

These test assertions are used in the TD-35.1 WMDM Service Provider Test. The Microsoft® Platform Software Development Kit (SDK) describes implementation details and expected return codes for valid and invalid parameters.

35.2.6.1 The client transfer software must correctly implement the IMDSPStorage::CreateStorage method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.6.2 The client transfer software must correctly implement the IMDSPStorage::EnumStorage method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.6.3 The client transfer software must correctly implement the IMDSPStorage::GetAttributes method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.6.4 The client transfer software must correctly implement the IMDSPStorage::GetDate method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.6.5 The client transfer software must correctly implement the IMDSPStorage::GetName method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.6.6 The client transfer software must correctly implement the IMDSPStorage::GetRights method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.6.7 The client transfer software must correctly implement the IMDSPStorage::GetSize method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.6.8 The client transfer software must correctly implement the IMDSPStorage::GetStorageGlobals method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.6.9 The client transfer software must correctly implement the IMDSPStorage::SendOpaqueCommand method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.6.10 The client transfer software must correctly implement the IMDSPStorage::SetAttributes method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test


IMDSPStorageGlobals Interface Assertions

These test assertions are used in the TD-35.1 WMDM Service Provider Test. The Microsoft® Platform Software Development Kit (SDK) describes implementation details and expected return codes for valid and invalid parameters.

35.2.7.1 The client transfer software must correctly implement the IMDSPStorageGlobals::GetCapabilities method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.7.2 The client transfer software must correctly implement the IMDSPStorageGlobals::GetDevice method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.7.3 The client transfer software must correctly implement the IMDSPStorageGlobals::GetRootStorage method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.7.4 The client transfer software must correctly implement the IMDSPStorageGlobals::GetSerialNumber method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.7.5 The client transfer software must correctly implement the IMDSPStorageGlobals::GetStatus method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.7.6 The client transfer software must correctly implement the IMDSPStorageGlobals::GetTotalBad method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.7.7 The client transfer software must correctly implement the IMDSPStorageGlobals::GetTotalFree method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.7.8 The client transfer software must correctly implement the IMDSPStorageGlobals::GetTotalSize method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test


IMDSPDevice2 Interface Test Assertions

These test assertions are used in the TD-35.1 WMDM Service Provider Test. The Microsoft® Platform Software Development Kit (SDK) describes implementation details and expected return codes for valid and invalid parameters.

35.2.8.1 The client transfer software must correctly implement the IMDSPDevice2::GetFormatSupport2 method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.8.3 The client transfer software must correctly implement the IMDSPDevice2::GetSpecifyPropertyPages method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.8.4 The client transfer software must correctly implement the IMDSPDevice2::GetStorage method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test


IMDSPStorage2 Interface Test Assertions

These test assertions are used in the TD-35.1 WMDM Service Provider Test. The Microsoft® Platform Software Development Kit (SDK) describes implementation details and expected return codes for valid and invalid parameters.

35.2.9.1 The client transfer software must correctly implement the IMDSPStorage2::CreateStorage2 method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.9.2 The client transfer software must correctly implement the IMDSPStorage2::GetAttributes2 method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.9.3 The client transfer software must correctly implement the IMDSPStorage2::GetStorage method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test

35.2.9.4 The client transfer software must correctly implement the IMDSPStorage2::SetAttributes2 method.

Reference document: WLP# - B1.3.1; Microsoft Platform SDK, "Service Provider Interfaces"
Test description: TD–35.1 WMDM Service Provider Test


Portable Audio Player Test Descriptions

This section details the Portable Audio Player test description.


TD-35.1 WMDM Service Provider Test Description

Test Kit: HCT 11

Overview

This test verifies the implementation of the Microsoft® Windows Media™ Device Manager (WMDM) Service Provider interfaces. The WMDM uses the Service Provider plug-in module to enumerate and control media devices. This test verifies proper usage of the interfaces and the documented return codes.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Hardware

This test requires special media appliance test hardware.

Required Software

This test requires the following software:

  • Windows XP Professional, Windows XP Home Edition; Windows .NET Server 2003, Standard Edition; or Windows .NET Server 2003, Enterprise Edition operating system
  • Any drivers that do not ship with Windows XP

Results Interpretation

This test writes the results to the Sptest.log file. You can find the log file in the same directory as the Sptest.exe file. The log file must indicate that all the test cases have been completed successfully. Each interface test describes the parameters passed into the interface, the return code, and the expected return code. See the Microsoft® Platform Software Development Kit (SDK) documentation for descriptions on proper usage and expected return codes.


TD-35.2 WMDM Content Transfer Test Description

Test Kit: HCT 11

Overview

The test verifies that the Microsoft® Windows Media™ Device Manager (WMDM) can transfer and delete Windows Media Audio (WMA) content and, if the device supports it, Mpeg 3 layer 3 (MP3) content. This test also verifies that each device storage, both internal memory and removable storage media, can be initialized or formatted.

The test completes the following actions for each storage media on the device:

  1. Deletes any test content on the device; transfers enough WMA content to fill the device; deletes the test content; transfers again.
  2. Deletes any test content on the device; transfers enough WMA content to exceed the capacity of the device; deletes the test content; transfers again.
  3. Repeats the steps 1 and 2 for MP3 content (if the format is supported).
  4. Initializes the storage media; transfers one WMA format file; deletes the file; transfers again.
  5. Initializes the storage media; transfers one MP3 format file (if the format is supported); deletes the file; transfers again.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Required Hardware

This test requires special media appliance test hardware.

Before you start the test, you can populate the device with content to decrease the test run time. The test removes up to 64 MB of content from the device prior to transferring content. With large hard drives (more than 8 GB), putting content into the storage media in advance allows the device to complete the test in a reasonable time, yet it still verifies the transfer of large amounts of data. Having content in place prior to testing also facilitates testing the transfer of content that exceeds the storage capacity of the device. The device initialization tests remove all content.

Required Software

This test requires the following software:

  • Windows® XP Professional, Windows XP Home Edition, Windows .NET Server 2003, Standard Edition; or Windows .NET Server 2003, Enterprise Edition operating system

Results Interpretation

The test writes the results to the Wmdmcopy.log file. You can find the log file in the same directory as the Wmdmcopy.exe program. The log file must indicate that all the test cases have been completed successfully. Each test case describes the transfer scenario and the result of the transfer. For information about the Microsoft® Windows Media™ Device Manager (WMDM), see the Microsoft Software Development Kit (SDK) documentation.


Chapter 36 Server Appliance Test Specification

Overview

To improve the usability and reliability of remotely managed server and server appliance products that are built using the Microsoft® .NET Server, Microsoft recommends extending the standard server hardware and BIOS requirements. The extended server hardware requirements include a local display, local keypad, watchdog timer, and Non-Volatile Random Access Memory (NVRAM). The extended BIOS requirements include a failover capability, a capability that allows the server appliance to boot from an alternate operating system partition, if the primary operating system fails to boot correctly.

This chapter describes the tests designed to validate that these extensions have been implemented correctly to work with the Microsoft .NET Server NET Server Remote Administration Tools. Systems that pass these tests and all of the Windows .NET Server 2003 family logo requirements may be listed as meeting the Server Appliance attribute requirements.


Reference Documents for Server Appliance Test Assertions

Functional requirements are specified in the following documents:

Microsoft Design Guide 3.0

http://www.microsoft.com/hwdev/platform/pcdesign/desguide/serverdg.asp

Microsoft Server Appliance Kit (SAK)

http://www.microsoft.com/windows/serverappliance

Microsoft Hardware Developer Information

http://www.microsoft.com/hwdev/default.asp


Server Appliance Test Assertion Summary

The following table lists the test assertions for the server appliance tests.

Table 36-1. Server Appliance Test Assertion Summary

Assertion # | Reference Document | Test Description
36.1.1 | Server Appliance Attribute Requirements, Chapter 7, "High Availability Requirements," #43, "Bit-mapped LCD and driver meet requirements." | TD-36.1 Server Appliance Local Display Test Description
36.2.1 | Server Appliance Attribute Requirements, Chapter 7, "High Availability Requirements," #46, "Local keypad and driver meet requirements." | TD-36.2 Server Appliance Local Keypad Test Description
36.3.1 | Server Appliance Attribute Requirements, Chapter 7, "High Availability Requirements," #48, "Watchdog timer hardware meets requirements." | TD-36.3 Server Appliance Watchdog Timer Test Description
36.4.1 | Server Appliance Attribute Requirements, Chapter 7, "Additional BIOS and NVRAM Requirements," #54, "NVRAM hardware and driver meet requirements." | TD-36.4 Server Appliance Non-Volatile RAM (NVRAM) Test Description
36.5.1 | Server Appliance Attribute Requirements, Chapter 7, "Additional BIOS and NVRAM Requirements," #53, "BIOS failover algorithm meets requirements." | TD-36.5 Server Appliance Failover Test Description


Server Appliance Test Assertions

This section contains the detailed list of test assertions.


Server Appliance Local Display Test Assertions

36.1.1 The bit-mapped LCD and display driver must meet the Server Appliance requirements.

If the Windows .NET Server 2003 appliance includes a bit-mapped LCD display, it must be 64 pixels high and 128 pixels wide. The display driver must comply with the guidelines in the Microsoft Server Appliance Kit.

Reference document: WLP# - B1.3.1; Server Appliance Attribute Requirements, Chapter 7, "High Availability Requirements," #43, "Bit-mapped LCD and driver meet requirements."

Test description: TD–36.1 Server Appliance Local Display Test Description


Server Appliance Local Keypad Test Assertions

36.2.1 The local keypad and driver meet the Server Appliance requirements.

If the Windows .NET Server 2003 appliance includes a local keypad, it must have six buttons: the Left, Right, Up, and Down direction keys, and the Enter, and Escape (Cancel) keys. If the Server Appliance includes a keypad, a driver must be provided that complies with the guidelines in the Microsoft Server Appliance Kit.

Reference document: WLP# - B1.3.1; Server Appliance Attribute Requirements, Chapter 7, "High Availability Requirements," #46, "Local keypad and driver meet requirements."

Test description: TD–36.2 Server Appliance Local Keypad Test Description


Server Appliance Watchdog Timer Test Assertions

36.3.1 The watchdog timer and driver meet the Server Appliance requirements.

If the Windows .NET Server 2003 appliance uses a hardware watchdog timer, a driver must be included that complies with the guidelines in the Microsoft Server Appliance Kit.

Reference document: WLP# - B1.3.1; Server Appliance Attribute Requirements, Chapter 7, "High Availability Requirements," Watchdog Timer, #48, "Watchdog timer hardware meets requirements."

Test description: TD–36.3 Server Appliance Watchdog Timer Test Description


Server Appliance NVRAM Test Assertions

36.4.1 The Non-Volatile RAM (NVRAM) hardware and driver meet the Server Appliance requirements.

If the Windows .NET Server 2003 appliance uses NVRAM to provide the BIOS and operating system a method of determining whether the operating system is capable of booting, a NVRAM driver must be provided that complies with the guidelines in the Microsoft Server Appliance Kit.

Reference document: WLP# - B1.3.1; Server Appliance Attribute Requirements, Chapter 7, "Additional BIOS and NVRAM Requirements," #54, "NVRAM hardware and driver meet requirements."

Test description: TD–36.4 Server Appliance NVRAM Test Description


Server Appliance Failover Test Assertions

36.5.1 BIOS failover algorithm meets server appliance requirements

If the Windows .NET Server 2003 appliance implements a failover algorithm in the BIOS, the algorithm must comply with the guidelines in the Microsoft Server Appliance Kit.

Reference document: WLP# - B1.3.1; Server Appliance Attribute Requirements, Chapter 7, "Additional BIOS and NVRAM Requirements," #53, "BIOS fail-over algorithm meets requirements."

Test description: TD–36.5 Server Appliance Failover Test Description


Server Appliance Test Descriptions

This section contains the detailed test descriptions.


TD-36.1 Server Appliance Local Display Test Description

Test Kit: HCT 11

Overview

This test verifies that the local display hardware (and driver) can correctly handle the bitmap or LED bit code that a user mode application, such as the local display manager service, sends to it.

The test first queries the driver to determine the capabilities of the hardware. If the display type is SA_DISPLAY_TYPE_BIT_MAPPED_LCD, this test sends a bitmap containing a random sequence of four numeric characters to the server appliance LCD. You then read the four numbers on the LCD, and enter them into the LCD text field in the Server Appliance Test window. The test compares the numbers you enter with the four random digits sent to the LCD. If they match exactly, the test passes. If they do not match exactly, the test fails. The test results are written in the test log.

If the display type is only SA_DISPLAY_TYPE_LED, or the display type is SA_DISPLAY_TYPE_CHARACTER_LCD, an error is logged because these types of displays are currently not supported.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

To set up the Local Display test

  1. Install Windows .NET Server 2003 on the main operating system (OS) partition.
  2. Install the local display hardware driver.
  3. Run Sasetup.msi and install the Local UI Framework
  4. Install the Server Appliance test on the main OS partition.

Required Hardware

Local display hardware must be a set of LEDs, a 128-pixel (w) by 64-pixel (h) bitmap LCD, or both. For a description of these requirements, see the Server Appliance Attribute Requirements (Chapter 7, requirement #43).

Results Interpretation

The test records the LCD digits, the LED bit code, and the results to a log file (Sadisplay.log) using the following format:

Local Display Test:

LCD digits: xxxx

Digits entered: yyyy

Result: PASS (or FAIL)

The log file must have one passing test result.


TD-36.2 Server Appliance Local Keypad Test Description

Test Kit: HCT 11

This test verifies that the keypad hardware and driver can correctly send input to a user mode application, such as the local display manager service.

The test generates a list of the six key types in random order and displays them in the Server Appliance Test window — for example, Up, Enter, Cancel, Right, Down, Left. You then have 20 seconds to press the keys in the order listed on the server appliance keypad. The test compares the keys pressed with the random sequence displayed on the Server Appliance Test window. If they match, the test passes. If they do not match, the test fails.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

To set up the Local Keypad test

  1. Install the local display hardware drivers.
  2. Install Windows .NET Server 2003 on the main operating system (OS) partition.
  3. Run Sasetup.msi and install the Local UI Framework feature.
  4. Install the Server Appliance test on the main OS partition.

Required Hardware

The local keypad hardware must include a 6-button keypad, with Up, Down, Left, Right, Enter, and Escape (Cancel) keys. For a description of these keys, see the Server Appliance Attribute Requirements, Chapter 7, "Local Keypad."

Results Interpretation

The test logs the key code and the test result to a file (Sakeypad.log) using the following format:

Keypad Test:

Expected key sequence: K1, K2, K3, K4, K5, K6

Observed key sequence: Ka, Kb, Kc, Kd, Ke, Kf

Result: PASS (or FAIL)

The log file must have at least one passing test result, where the expected key sequence equals the observed key sequence.

For more information about key definition, please see the Server Appliance Kit section of the Windows .NET Driver Development Kit (DDK).


TD-36.3 Server Appliance Watchdog Timer Test Description

Test Kit: HCT 11

This test is designed to simulate automatic reboot technology required in Server Appliances. This test verifies that the watchdog hardware and its associated driver installed on the test system are implemented with the required features and can correctly work with a user-mode application, such as the remote server monitor service.

The test involves the following procedures:

  • Verifies that the watchdog timer is enabled.
  • Verifies that the maximum countdown time is within the required range.
  • Verifies that the countdown timer can be stopped.
  • Verifies that the countdown timer can be restarted.
  • Verifies that the countdown timer can restart the device if it reaches zero. For this last test case, you will need to rerun the watchdog test immediately after the watchdog timer restarts the system.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

To set up the Watchdog Timer test

  1. Install Windows .NET Server 2003 on the main operating system (OS) partition.
  2. Install the Server Appliance test on the main OS partition.
  3. Enable the hardware watchdog timer.

Required Hardware

A hardware watchdog timer and driver as described in the reference document, Server Appliance Attribute Requirements, Chapter 7, "Watchdog Timer."

Results Interpretation

The Watchdog Timer test writes the name of the test and the test result to a log file (Sawatchdog.log) and uses the following format:

Watchdog timer test.

Watchdog maximum count test <time stamp>.

Result: PASS (or FAIL)

Watchdog Stop Test:

C0=xxxxxx <time stamp>

C1=yyyyyy <time stamp>

Result: PASS (or FAIL).

Watchdog Restart Test. <time stamp>:

C10 <time stamp>

C11 <time stamp>

C12 <time stamp>

Result: PASS (or FAIL)

Watchdog Expiration Test. <time stamp>

Result: PASS (or FAIL).

If system successfully passes the Watchdog Timer test, the system restarts.


TD-36.4 Server Appliance NVRAM Test Description

Test Kit: HCT 11

This test verifies that the Non-Volatile Random Access Memory (NVRAM) hardware and its associated driver can correctly be written to and read by a user-mode application, such as the remote server monitor service. This test runs twice to verify that contents in NVRAM remain the same before and after restarting the system.

The test involves the following test cases

  • Verifies that it can write to NVRAM.
  • Verifies that the NVRAM is unchanged after a restart.
    For this last test case you must rerun the NVRAM test immediately after the system restarts.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

To set up the NVRAM test

  1. Install Windows .NET Server 2003 on the main operating system (OS) partition.
  2. Install the NVRAM hardware drivers.
  3. Install the Server Appliance test on the main OS partition.

Required Hardware

The Server Appliance must implement the NVRAM hardware as described in the reference document, Server Appliance Attribute Requirements, Chapter 7, "Additional BIOS and NVRAM Requirements."

Results Interpretation

The test writes the written value and the read value and the test results to a log file (Sanvram.log) using the following format:

NVRAM Test:

XN0: xxxxxxxx <time stamp> (104 bytes)

N1: yyyyyyyy <time stamp> (104 bytes)

Result: PASS (or FAIL).

The system successfully passes the Server Appliance NVRAM test when the log file has at least one passing test result.


TD-36.5 Server Appliance Failover Test Description

Test Kit: HCT 11

This test verifies that the system has failover capability; that is, the system has backup mechanisms that can automatically and transparently take over operations when a failure occurs with the operating system on the main hard disk drive partition. The test is designed to simulate loss of the main OS partition, and verify that the backup OS partition is available to complete the test.

Overview

The test must be installed in both operating systems (main and backup), on one or more hard disk drives. This test runs twice to verify that the backup partition is able to complete the test after the failure of the main partition.

Running the test

  1. The system boots from the main OS and then forces a failover to the backup OS.
  2. Once the system is up and running again, you run the test a second time.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

To set up the Server Appliance Failover test

  1. Install Windows .NET Server 2003 on both the main operating system (OS) partition and the backup OS partition following the instructions in the Server Appliance Kit.
  2. Install the NVRAM hardware drivers on both OS partitions.
  3. Install the Server Appliance test in both operating system partitions.
  4. Enable the hardware watchdog timer.

Required Hardware

The Server Appliance must implement the NVRAM hardware as described in the reference document, Server Appliance Attribute Requirements, Chapter 7, "Additional BIOS and NVRAM Requirements."

Results Interpretation

The test writes the result to a log file (Safailover.log) using following format:

Fail-over test:

Result: PASS (or FAIL)

The system successfully passes the Server Appliance Failover test when the log file has at least one passing test result.


Glossary

WHQL Test Specification

Previous

Glossary - Windows Hardware Quality Labs

Asterisk (*) indicates term that appears in the Microsoft Computer Dictionary (2001 edition of Encarta).
A double-asterisk (**) indicates that the term appears in the Computer Dictionary, but the definition here is different.

Microsoft, ActiveX, BizTalk, Direct3D, DirectDraw, DirectShow, DirectX, IntelliMirror, MS-DOS, Win32, Windows, Windows Media, and Windows NT are trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries. Other product and company names mentioned herein may be the trademarks of their respective owners.

© 2002 Microsoft Corporation. All rights reserved.

This glossary is provided by the Windows Hardware Quality Labs at Microsoft.

#

2-D

Two-dimensional.

3-D*

Three-dimensional.

4GT

4-gigabyte RAM tuning.

8-VSB

Advanced Television Systems Committee (ATSC) 8-vestigial side band.

A

AA

See anti-aliasing.

AAC

Advanced audio compression/decompression.

ABP

Address Book Provider. A provider process.

ABR

Available bit rate.

AC*

Alternating current.

AC-3

An audio standard developed by Dolby Laboratories for delivering 5.1 audio (front left, front center, front right, back left, back right, low-frequency enhance). This system compresses six channels of digital audio into 384 Kbps rather than 4 Mbps uncompressed.

AC '97

A compression/decompression standard for audio released in 1997.

Accelerated Graphics Port (ACP)*

An interconnect between high-performance, 3-D graphics components. The interconnect is based on a set of performance extensions or enhancements to PCI.

access control entry (ACE)

An individual entry in an access control list (ACL). An access control entry (ACE) describes the access rights to a system resource by a specific user or group of users.

access control list (ACL)*

A list of ACEs that is ordered.

access right

A permission that is granted to a process.

access violation

An attempt to execute a memory operation that is not allowed by the fundamental page protection. See the Windows DDK.

ACE

See access control entry and advanced computing environment

ACK*

A signal that acknowledges the receipt of a signal.

ACL

See access control list.

ACM*

See Audio Compression Manager.

ACP

The ANSI code page that is active. Whenever an application calls one of the ‘A’ entry points, The Microsoft Windows® operating system uses this ANSI codepage to automatically convert Unicode.

ACPI**

See Advanced Configuration and Power Interface.

ACPI hardware

Computer system-board hardware that supports features required for operating system-controlled power management and computer-system configuration. ACPI hardware supports the interfaces to required features with the Description Tables. These tables are specified in the ACPI Specification.

ACPI Machine Language (AML)

Pseudocode for a virtual machine. An operating system that is compatible with ACPI supports this virtual machine in which ACPI control methods are written.

ACPI Name Space

A hierarchical tree structure in memory that the operating system controls. This tree structure contains named objects that can be data objects, control-method objects, and bus and device package objects. All the information in the ACPI Name Space comes from the Differentiated System Description Table in the ACPI BIOS.

ACS

Admission Control Service.

active device

A device that is active and not in the Suspend state.

Active Directory (AD)**

Builds applications that give a single point of access to multiple directories in a network. These directories can be based on LDAP, NDS, or NTDS.

A/D

Analog-to-digital.

Adapter**

See device.

adapter object

An object type that is available only in kernel mode. The I/O Manager defines the object. The fundamental HAL component supports the object. An adapter object represents a hardware bus adapter or DMA controller channel. Adapter objects "connect" different kinds of devices on the bus or DMA controller, with each device (or kind of device) using its own driver.

ADC*

See analog-to-digital converter

add-on devices

Devices added to the base computer system to increase functionality, for example, audio, networking, graphics, and SCSI controller. Add-on devices fall into two categories: devices built onto the system board and devices on expansion cards. You can add expansion cards to the computer through a system board connector, such as a connector on the PCI bus.

Address*

1. A number that specifies a location in memory where data is stored.
2. A name or token that specifies a particular computer or site on the Internet or other network.
3. A code that specifies an e-mail destination.

ADF

automatic document feeder.

ADO

Microsoft® ActiveX™ data objects. A unit of information that can be addressed individually in the ActiveX architecture.

ADPCM*

Adaptive differential pulse code modulation. This is an encoding format that stores audio information in a digital format.

ADSI

Active Directory Service Interfaces.

ADSL*

See Asymmetric digital subscriber line.

ADT

1. Attribute definition table.
2. Abstract data type.

Advanced Computing Environment (ACE)

A consortium of hardware and software companies that promote a computing environment that is accessible.

Advanced Configuration and Power Interface (ACPI)**

An abstract interface that defines a power management and configuration mechanism for hardware and operating systems. Part of the industry-wide OnNow Initiative, ACPI is defined in the industry-sponsored ACPI Specification.

Advanced Power Management (APM)**

An older power management technology, used in mobile PCs before the implementation of ACPI. APM is a software interface that functions between the BIOS power-management software that is specific to the hardware and a power-management policy driver that is run by the operating system.

Advanced RISC Computing (ARC)**

A RISC-based computer architecture standard that is associated with the ACE consortium. ARC machines include both RISC-based and CISC-based platforms.

advertisement

A client machine advertises these files as available, but they are not actually installed. The files are available to the client machine through the network.

AEC

Acoustic echo cancellation.

affinity

1. An attribute that is defined by a programmer. The attribute is part of a process, a thread, or both on a multiprocessor platform.

2. The set of processors on which a particular interrupt is enabled. See the Windows DDK.

agent**

Software that runs on a client computer. Administrative software running on a server uses the agent software. Agents typically support administrative actions, for example, detecting computer system information or running services.

AGP*

See Accelerated Graphics Port.

Alert**

A Boolean operation that breaks the execution of a thread when the thread either is in an alert wait state or polls the alerted flag.

algorithm**

In compression software, refers to a specific formula that compresses or decompresses video or other data.

alias*

An alternative label for an object.

aliasing*

In computer graphics, the jagged appearance of curves or diagonal lines on a display screen. This appearance is caused by low screen resolution.

alpha blending

Alpha or transparency blending that approximates how transparent surfaces distort light rays.

AMA

Active member address. In ACPI terminology, also refers to AM_ADDR.

AML

See ACPI Machine Language.

AMR

Audio modem riser.

analog**

A method of signal representation by infinite numeric values that do not vary. Analog measurements include readings of voltage and current. Compare with digital.

analog-to-digital converter (ADC)*

A device that converts an analog signal from a monitoring device to binary code. An analog signal is a continuously varying signal. Compare with DAC.

analog video

A video signal that represents an infinite number of non-varying gradations between video levels. Compare with digital video.

anamorphic

Unequally scaled in vertical and horizontal dimensions.

ANSI**

1. American National Standards Institute. An organization that develops and publishes standards for voluntary use in the United States. This organization establishes standards and is not affiliated with the government.

2. The Microsoft Windows ANSI character set. This set is includes ISO 8859/x plus additional characters. This set was originally based on an ANSI draft standard. The MS-DOS® operating system uses the ANSI character set if ANSI.SYS is installed.

anti-aliasing (AA)**

When combining images in graphics-display technology, AA is a form of interpolation. The combination averages the pixels along the transitions between images to provide a smooth transition.

AOAC

Always on/always connected.

AP

Access point.

A/PC

Auto PC.

APC

See asynchronous procedure call.

API*

See Application programming interface.

APIC

Advanced Programmable Interrupt Controller.

APIPA

Automatic programmable IP addressing.

APM*

See Advanced Power Management.

appliance**

A device with a single or limited purpose with functionality. This functionality is similar to a simple consumer appliance.

appliance server**

An inexpensive computing device used for specific tasks including Internet connectivity or file-and-print services. The server does not possess the capabilities or software of a typical server for general office use. But the server is easy to use.

application-programming interface (API)*

A set of routines that application programs use to request and perform lower-level services. The operating system performs these lower-level services.

APS

Analog protection system.

AR_ADDR

Access Request Address.

arbitrary thread context

See thread object.

arbitrator

A software module in Windows that handles the allocation of hardware resources among devices.

ARC

See Advanced RISC Computing.

architecture**

A general term referring to the structure of all or part of a computer system. Architecture also refers to the design of operating system software, such as components of the operating system. Architecture can also refer to the combination of hardware and basic software that links machines on a network.

ARGB

Alpha, red, green, blue.

ARMD

ATAPI Removable Media BIOS Specification.

ARP*

Address Resolution Protocol.

Artifact

An anomaly in a video image.

AS

Advanced Server.

ASCII*

American Standard Code for Information Interchange. The most popular coding method used by small computers for converting letters, numbers, punctuation, and control codes into digital form. The ASCII character set is used by MS-DOS. ASCII, the US national variant of ISO 646, is a 7-bit character set encoding that contains characters for uppercase and lowercase English, American English punctuation, base 10 numbers, and a few control characters. Although very primitive, ASCII’s set of 128 characters is the one common denominator contained in all the other common character sets.

ASF**

Advanced Systems Format.

ASIC

An integrated circuit that is specific to an application.

ASL

ACPI Source Language. The programming-language equivalent for AML. ASL is compiled into AML images.

ASP*

Active server pages.

aspect ratio*

The relationship between width and height. When an image is displayed on different screens, the aspect ratio must remain the same to avoid either vertical or horizontal stretching.

ASPI*

Advanced SCSI Programming Interface.

assigned configuration

Drivers examine this portion of the device node to determine which resources are allocated for the device. For Plug and Play devices, the assigned resources for a device can change dynamically.

associated IRP

One of a set of IRPs. The highest-level driver in a chain of layered drivers creates the associated IRP. It specifies the delivery of an I/O request to a lower-level driver. When all associated IRPs in the set are processed, the I/O Manager completes the original request. See also IRP.

ASSP

Application-specific Standard Protocol.

ASVD

Analog simultaneous voice/data.

asymmetrical compression

A system that requires more processing ability to compress than to decompress an image. Asymmetrical compression is typically used for the mass distribution of programs on media, for example, CD-ROM. Compare with symmetrical compression.

asymmetric digital subscriber line (ADSL)*

ADSL moves data over regular phone lines. An ADSL circuit is much faster than a regular phone connection. ADSL wires that enter the subscriber’s location are the same (copper) wires that the regular phone service uses.

asynchronous

An operation that proceeds independently of any timing mechanism such as a clock. Compare with synchronous.

asynchronous I/O

A model for I/O. In this model, the operations performed to satisfy I/O requests do not necessarily occur in sequence. The application that originally made the request can continue performing instead of waiting for its I/O to complete. The I/O Manager, or a higher-level driver, can reorder I/O requests upon receipt. A lowest-level driver can start an I/O operation on a device before it has completed the preceding request, particularly in a multiprocessor machine.

asynchronous procedure call (APC)**

A control object that is defined by the kernel. The object represents a procedure that is called asynchronously. APCs depend on the context of the thread. That is, they are queued to a particular thread for execution. There are three different types of APCs in the kernel: User APC, Kernel APC, and Special Kernel APC. See the Windows DDK.

AT#UD

Unimodem Diagnostics Command.

ATA**

AT Attachment. Also known as IDE. ATA defines the physical, electrical, transport, and command protocols for the internal attachment of storage devices.

ATAPI*

ATA Packet Interface. A device that implements the packet-command feature set. A hardware and software specification that describes the interface between a host computer and CD-ROM drives that use the ATA bus.

AT command set

The standard V.250 command set that modems use.

ATM**

Asynchronous transfer mode. A transmission protocol that segments user activity into small, permanent-sized units called cells. These cells are transmitted to their destination, where they are reassembled into the original traffic. During transmission, cells from different users may be intermixed asynchronously to maximize utilization of network resources.

ATSC

Advanced Television Systems Committee.

ATU-C

Termination of Digital Subscriber Line at the Central Office. See also DSLAM.

ATU-R

Termination of Digital Subscriber Line at the customer’s location. See also DSL.

ATVEF

Advanced Television Enhancement Forum.

Audio Class

The class of filters that handles pulse-code modulation, or similar digitized data or analog signals. A WDM minidriver supports audio devices under the WDM digital-audio architecture.

Audio Compression Manager (ACM)

A device-driver manager that controls which applications are required to play or record sounds. ACM manages the following types of drivers: codec, format-converter, and filter.

Audio mixing

The method of combining multiple streams of audio data into a single stream through addition and clipping.

AUI*

Attachment Unit Interface. Part of the Ethernet standard that specifies how to connect a cable to an Ethernet card. AUI specifies a connection to a transceiver that plugs into a 15-pin socket on the network adapter.

Authentication**

The validation of a user.

Authorization**

The granting or denying access to resources.

A/V

Audio/video.

AVD

Alternating voice/data.

AVGA

Advanced VGA.

AVHDD

Audio/video hard-disk drive.

AVI*

Audio/Video Interleaved, a multimedia file format.

B

B2B

Business-to-business relationship.

B2C

Business-to-consumer relationship.

B2E

Business-to-employee relationship.

backing store

A device such as a disk that holds mass storage to provide backup memory for paging when physical memory is full. See also paging file.

backup*

A duplicate of a program, disk, or data. This duplicate is created either for archiving or to protect valuable files from loss.

balance set

The set of processes currently in the operating system. In particular, the processes whose threads are available for execution. See the Windows DDK.

bandwidth**

The capacity of data transfer of a digital communications system, for example, the Internet or a local area network (LAN). Bandwidth is expressed in the number of bits that a system can transfer in a second, for example, bits per second (bps) or kilobits per second (Kbps).

BAR

Base address register.

base character

1. A character that has meaning independent of other characters.

2. Any graphical character that is not a diacritic.

baseline**

1. An informal definition of operating system components or performance. New design or testing criteria are defined on these components or performance.

2. In the printing and display of characters, an imaginary horizontal line with which the base of each character is aligned, excluding descenders.

BCB

See buffer control block.

BDA

1. Broadcast Driver Architecture.

2. BIOS data area.

BDC

Backup domain controller.

BDK

Business Development Kit.

BER

Bit Error Rate.

BiDi

Bi-directional text. A mixture of characters that are read from left to right and characters that are read from right to left. For example, most Arabic, Hebrew, Farsi, and Urdu characters are read from right to left. However, numbers and quoted Western terms within the text of these languages read from left to right.

big-endian**

A processor-memory architecture in which byte N is the most significant. For a big-endian configuration, the most significant bit of a 16-bit short value is the leftmost bit at byte N. The least significant bit is the rightmost bit of byte (N + 1). See also little endian.

bilinear textures

A technique for correlating texture. This technique averages the colors of surrounding texels to determine the texture color.

BIOS*

Basic input/output system. A set of routines in firmware to support the transfer of information between elements of the computer such as memory, disks, and the monitor.

BIOS enumerator

A component of the BIOS that identifies all hardware devices on the motherboard in a computer system that does not support ACPI Plug and Play. The BIOS supports an API to query all Plug and Play devices in a computer using a common method.

BIS**

Boot Integrity Services.

bit map**

Representation of characters or graphics by individual pixels. The pixels can be arranged in rows (horizontal) and columns (vertical). Each pixel can be represented by either 1 bit (simple black and white) or up to 32 bits (high-definition color).

bitmapped graphics

Images created with matrices of pixels or dots. See also raster graphics.

bit rate**

1. The streaming speed of digital content on a network. Bit rate is usually measured in kilobits per second (Kbps), for example, 28.8 Kbps.

2. The speed at which binary content moves across a network. The speed is measured in kilobits per second (Kbps).

bit specifications

Number of colors or levels of gray that can be displayed simultaneously. The amount of memory in the graphics controller card controls the display. An 8-bit controller can display 256 colors or levels of gray; a 16-bit controller can display 64,000 colors; and a 24-bit controller can display16.8 million colors.

BizTalk

1. Framework based on Extensible Markup Language (XML) and industry standards for sharing information.

2. Microsoft BizTalk™ Server 2000 technology, which supports the integration of Internet application through XML.

blackpoint

The input level where the device begins to display color output.

Blt

Block transfer.

Bluetooth wireless technology.

A specification for radio links between mobile PCs, mobile phones, and other portable devices. These radio links are small-form factor, low cost, and short range, too.

BOOTP*

Boot Protocol.

bootstrap loader*

A program that is run automatically when a computer is switched on (booted). After first performing a few basic hardware tests, the bootstrap loader loads and passes control to a larger loader program. Then, the larger program typically loads the operating system. The bootstrap loader normally resides in the computer's read-only memory (ROM).

bottom up

Arrangement of pixel data in memory. The lowest-addressed pixels correspond to the lower-left corner of the image and proceed to the right with increasing memory address. The highest addressed pixels correspond to the upper-right corner of the image.

BPB

BIOS Parameter Blocks.

BPC

Broadcast PC.

bpp

Bits per pixel. The number of bits that represent the color value of each pixel in a digitized image.

bps*

Bits per second. The number of bits transferred per second in a data-communications system. A measure of speed.

BRDF

Bi-directional Reflectance Distribution Functions.

BRI*

Basic Rate Interface.

brightness**

The value associated with a pixel. This value represents the gray value of the pixel in the range of black to white.

broadband**

A high-speed transmission through communication lines or services that operate at T1 rates (1.544 Mbps) or higher.

Broadcast Architecture

The set of technologies that enable PCs to receive broadcast data.

BSD

Berkeley Software Distribution (UNIX).

BTh

See Bluetooth wireless technology.

BTS

Microsoft BizTalk Server.

buffer*

A reserved portion of memory in which data is temporarily held. The data is held pending the completion of its transfer to or from a storage device, or another location in memory.

buffer control block (BCB)

An opaque Cache Manager structure. BCB maintains state as a file system pins and releases data (for example, its volume structure) in the cache.

bulk transfer

One of the four USB transfer types, where transport of command, data, and status occurs only by way of Bulk endpoints. Bulk transfer occurs directly between the host and the device. Bulk transfer uses any available bandwidth and can be delayed until bandwidth is available.

bus compliance

A device is in compliance with a bus specification when it implements all functional, protocol, electrical, and mechanical aspects stated in that specification.

bus driver

A bus driver services a bus controller, adapter, or bridge. Microsoft provides bus drivers for most common buses, including IEEE1394, PCI, PnPISA, SCSI, and USB. A bus driver enumerates the devices on its bus and respond to certain PnP and power management IRPs. During enumeration, a bus driver identifies the devices on its bus and creates device objects for them. See the Windows DDK.

bus enumerator*

In a Plug and Play operating system, a bus driver that detects devices located on a specific bus. The driver then loads information about the devices into the hardware tree.

BW

Bandwidth.

C

C#

See Microsoft C#.

C2**

A security class of the U.S. Department of Defense Trusted Computer System Evaluation Criteria (DOD 4200.28.STD).

CA*

Certificate Authority.

cabinet file

A set of installation files that are compressed. These files have a file name extension of .cab.

cache**

A memory subsystem for storing copies of data values that are used frequently, so the data can be retrieved for quick access.

Cache Manager

An operating system component that provides support of file caching for file-system drivers.

CAD*

Computer-aided design.

CAL**

Channel abstraction layer.

calibration

To establish predictable behavior in a device. For color calibration, you must characterize a device before you can calibrate it. See also characterization.

CAM

See Common Access Method.

CAP

1. Carrier-less amplitude/phase modulation.

2. Competitive Access Provider.

CAPI

Communications API.

CAPP

Controlled Access Protection Profile.

Card Services

Protected-mode Windows 95/98 virtual device driver. This driver is linked with the PCMCIA bus driver. Card Services transfer the event notification from socket services to the PCMCIA bus driver. Card Services also provides information from the computer’s cards to the PCMCIA bus driver and establishes the configuration for cards in the adapter sockets.

CBQ

Class-based queuing.

CBR

Constant Bit Rate.

CBT*

Computer-based training.

CCB

See context control block.

CCITT*

Comite Consultatif Internationale de Telegraphie et Telephonie (Consultative Committee for International Telephone and Telegraph). An international standards organization that creates communications protocols. These protocols facilitate global compatibility for the transmission of voice, data, and video across all computing and telecommunications equipment.

CCP**

Compression Control Protocol.

CD**

Compact disc.

CDB

See command descriptor block.

CDC

Communications class device.

CDFS*

CD-ROM file system.

CD-I

Compact disc-interactive.

CDM

Common Diagnostic Model.

CDMA*

Code division multiple access.

CDO

Collaboration data objects.

CDPD*

Cellular digital packet data.

CD-R

Compact disc-recordable.

CD-R2

Physical format for CD read-only.

CD-ROM

Compact disc read-only memory. A storage medium with a spiral format that is constant linear velocity (CLV). This is the same format as compact audio discs and some video discs. CD-ROMs can hold about 550 MB of data.

CD-RW, CDR/W*

Compact disc-readable/writable.

CE

Consumer electronics.

CEBus

Consumer electronics bus.

CEDR

Windows CE driver repository.

CFM

Cubic feet per minute.

CHAP*

Challenge Handshake Authentication Protocol.

character**

1. The simplest element that represents written languages. The appearance of a character is not constant. Its appearance depends on the font and the context of surrounding text. See also Glyph.

2. A code element.

character encoding

A one-to-one mapping between a set of characters and a set of numbers. The numbers represent text in software.

characterization

The measurement of the initial state of a device.

chase

To follow a linked list, queue, or other software-defined path. For example, when a file system encounters a symbolic-link file within the specification of a path, it "chases the symbolic link" to redirect operations to the destination file. See also Symbolic link.

checked build

A version of the operating system that is compiled with debugging symbols. It is also built with special support for debugging software components such as new drivers. See also Free build.

child process*

A process initiated by another process. The initiating process is called the parent process. See the Windows DDK.

chroma, chrominance**

The color portion of the video signal that includes hue and saturation information. Requires luminance (also called light intensity) to render it visible.

CHS

Cylinder head sector

CI

1. Component instrumentation. A specification for Desktop Management Interface (DMI) related to the service layer.

2. Calling indicator. One of four calling signal tones. CI indicates the type of call (Data, FAX send/receive, Videotex, or H.324, as defined by V.8 for exchanging preliminary information).

CID

1. Compatible ID.

2. See Client identifier.

CIE

Commission International de l’Eclairage. The international commission on illumination and a developer of color-matching systems.

CIFS*

Common Internet File System.

CIM**

Common Information Model. Describes the Web-based Enterprise Management (WBEM) data representation that is now a standard. This standard is sponsored by the Distributed Management Task Force.

CIMOM

CIM Object Manager. A key component of the Web-based Enterprise Management (WBEM)architecture. Formerly HMOM.

CINF

The Check INF tool for modems.

CIP**

Common isochronous packet.

CIS

Card Information Structure. CIS describes the PC Card’s resource requirements and other characteristics. The operating system uses this information to configure the device in Plug and Play operations.

CISC*

Complex instruction set computing.

class**

For hardware, the method for grouping particular types of devices and buses according to the basic ways that they can be installed and managed by the operating system. The hardware tree is organized by device class, and Windows uses class installers to install drivers for all hardware classes. See also Setup Class.

class driver

A class driver is an intermediate driver designed to provide a simple interface between a minidriver and the operating system. Microsoft provides the class driver. A vendor provides the minidriver. Under WDM, the minidriver registers its associated hardware adapters with the class driver. The class driver then creates a file object to represent each adapter that registers.

class GUID

A GUID that identifies a particular class.

Class ID

Part of a device identifier that identifies the class of the device to indicate compliance with a published device class specification. Industry standards may exist that allow communication to take place between the operating system and a device of a particular class. For example, USB includes an industry standard specification for communication with mass storage devices. The operating system can load a class driver on the basis of the device’s class ID if the device does not require a specific matching driver or a specific matching driver is not available.

CLB

Component Load Balancing.

CLEC*

Competitive Local Exchange Carrier.

CLI

Command-line interface.

client identifier

A unique value that identifies a thread.

client/server model

A model for structuring applications or operating systems. In this model, the system is divided into processes (servers). Each of these processes (servers) provides a set of specialized services to other processes (clients).

client system

1. A computer that runs the specific Windows operating system for which the test device is acquiring the "Designed for Windows" logo. The test device must be installed on this computer.

2. A computer that is running a client version of the Windows operating system such as Windows XP, Windows 2000 Professional, or Windows ME.

CLV

Constant linear velocity.

CMI**

1. Control Method Interface.

2. Computer-managed instruction.

CMM

Color Management Model.

CMOS**

Complementary Metal-Oxide Semiconductor. A chip that stores information about the hardware on a computer.

CMP

1. Cellular multiprocessing.

2. Connection-management protocol.

CMS**

1. Communication Management Services.

2. Color Management System.

CMTS

Cable modem termination system.

CMYK**

Cyan, magenta, yellow, and black. A mixing model or method that describes colors that many printing systems use. CMYK starts with the color white and subtracts percentages of cyan (blue), magenta (red), and yellow to produce desired colors.

CN

Common name.

CNR

The interface specification for Communication and Network Riser (CNR).

code*

Program instructions. Source code consists of statements that are written by a programmer in a programming language. Machine code consists of numerical instructions that the computer can recognize and execute. These instructions were converted from source code.

codec**

Coder-decoder. A filter that manipulates data by some method. Typically, the method is the compression or decompression of the data stream.

code page / code set**

An ordered set of characters in which a numeric index (codepoint value) is associated with each character. A table can represent a codepage in a table as a correlation between characters to single-byte values or multibyte values. Many code pages share the ASCII character set for characters in the range 0x00 – 0x7F.

code point

The numeric index of a character within a code page.

co-installer

A co-installer is a Microsoft Win32® DLL that assists in device installation on Windows 2000 and later operating systems. Setup API calls co-installers for assistance or as filters for Class Installers.

For example, an IHV might provide a co-installer to write device-specific information to the registry. An INF file cannot handle this information.

collided page fault

A situation where one thread creates a page fault while an in-page I/O operation for another thread is performed on the same page.

color depth

The number of colors that can be displayed simultaneously. The number of colors that can be displayed or the number of bits per pixel (bpp) can indicate color depth.

color keying

The superimposition of one image over another for special effects.

colorspace

Describes a set of colors and their relationships. An example of a colorspace is CIE XYZ or sRGB. The colorspace of a device describes its color gamut and the characteristics of the color output with that gamut.

COM**

1. Component Object Model. COM defines how OLE (object linking and embedding) objects and their clients interact within processes or across process boundaries.

2. Legacy serial port.

command descriptor block (CDB)

A structure, defined by the SCSI-II standard, that communicates requests to a device on a SCSI bus.

command packet

A data structure that is transmitted to the device by a PACKET command. The command packet includes the command and the parameters of the command.

commitment

The Memory Manager's current value for paging file usage.

Common Access Method*

An interface definition for SCSI devices.

Compatible ID

Identifiers that represent devices that are compatible with a given device, which means they can be driven effectively by the same driver. The operating system can load a driver on the basis of the device’s compatible IDs if the device does not require a specific matching driver or a specific matching driver is not available. A device can have zero or more compatible IDs. See also Device ID, Hardware ID, Instance ID. See the Windows DDK.

compatibility mode**

A parallel-port channel that is asynchronous and provides host-to-peripheral connectivity. This is defined in the IEEE 1284–1994 standard. It is also compatible with existing peripherals that attach to a parallel port that is Centronics style.

complex script

Scripts that require special processing to display, print, and edit.

compliance

A device, computer system or operating system is in compliance with a specification when it implements all functional aspects explicitly stated as required in that specification.

composite character

A text element that consists of a base character and a diacritic or accent mark.

composite video*

A signal that combines the luminance, chrominance, and synchronized information of a video single onto a single line. This is the most prevalent National Television System Committee (NTSC) video format.

compressed video

A digital video image or segment that is processed through a variety of computer algorithms and other techniques. These algorithms and techniques reduce the amount of data required to represent the content. Therefore, the reduced size of the data reduces the storage requirements.

compression

The translation of data (video, audio, digital, or a combination) to a more compact form for storage or transmission.

concatenate*

To join sequentially.

Configuration Manager

The Plug and Play operating system component in Windows 95/98 that manages the process of locating devices, establishes their nodes in the hardware tree, and runs the resource allocation process.

connection**

If implemented in hardware or software, a negotiated method of communication between devices.

connectionless networking

Networking based on media, for example, IEEE 802 LAN adapters and Fiber Distributed Data Interface (FDDI) adapters.

context

The execution state of a thread at any given point in time. See the Windows DDK.

context control block (CCB)

An internal file-system structure. In this structure, a file system maintains each file-object state for an open instance of a file. See also FCB and DCB.

context record

An operating system-defined structure, containing the current register state for an exception handler. See also SEH.

contrast*

The range of light and dark values in a picture. Contrast can also be a measure of the content of brightness in an image.

controllerless modem

Also known as host-based controller. A modem that consists of a digital-signal processor (DSP) without the usual microcontroller. The host CPU provides the AT command interpreter, modem-control functions, and v.42bis implementation. Compare with software modem.

controller object

An object type available only in kernel mode that is defined by the I/O Manager. A controller object represents a hardware controller or channel. The driver calls IoAllocateController to perform synchronized I/O on attached devices. Controller objects connect a set of similar devices that are attached to a controller with a single driver.

control method

A definition of how an operating system that is compatible with the Advanced Configuration and Power Interface (ACPI) can perform a simple hardware task. For example, the operating system uses control methods to read the temperature of a thermal zone. Control methods are written in an encoded language called AML (ACPI Machine Language).

control objects

A class of object types that are defined by the kernel. These object types manage all kernel-mode operations, except dispatching and synchronization. See the Windows DDK.

control transfer

One of the four USB transfer types. Control transfers support configuration, command, and status-type communications between client and function.

convergence**

In an RGB monitor, where red, green, and blue signals all converge in one pixel.

CPE

Customer Provided Equipment.

CPI**

1. Cycles per instruction

2. Characters per inch. A measurement that indicates the number of characters per inch that can be printed. This measurement typically is used by a dot-matrix printer.

CPL

File name extension for a control panel application.

CPTWG

Copyright Protection Technical Working Group.

CPU**

Central processing unit. A computational and control unit of a computer. The CPU is the device that interprets and executes instructions.

CRC*

Cyclic redundancy check.

critical section

A piece of code that has exclusive access to a resource temporarily. For example, a critical section can be device-state data stored in a device extension to which access must be synchronized among some number of routines.

CRL

Certificate Revocation List.

CRM

Customer relations management.

CRS

Content replication service

CRT*

Cathode ray tube. The glass display device in video computer terminals. Monitors can be called CRTs.

CS**

1. Computer science.

2. Name for the pcode compiler.

3. Customer service.

CSA

1. Connection and Streaming Architecture. Kernel-mode streaming in Windows ME, Windows 2000, and later operating systems.

2. CallPath Services Architecture. IBM’s computer host to PBX interface.

CSC

1. Client-side caching.

2. Color-Space Conversion.

CSEL

Cable Select.

CSN

Card-Select Number. Through the isolation process, the BIOS or operating system creates a handle. The number is assigned as a unique identifier to each Plug and Play card on the ISA bus.

CSNW

Client Services for Networks.

CSP

Cryptographic Service Provider.

CSR

Control and status register.

CSS

Copy scramble system.

CT

Computer Telephony.

CTS**

Clear-To-Send.

CVS

Continuous variable slope delta modulation.

CW

Control Word.

D

D/A

Digital-to-analog.

DAA

Data access arrangement.

DAC**

1. Digital-to-analog converter.

2. Device Access Code

DACL

See Discretionary access control list.

DAP

Directory Access Protocol.

DARPA

Defense Advanced Research Project Agency.

DASD

Direct-access storage device.

DAT

1. Digital audio tape. In addition to the tape cassette, DAT identifies a type of digital tape recorder and player.
2. Dynamic address translation.

data flow**

An arbitrary method of defining a class of connection between devices. Data flow facilitates identification of pin pairs that present compatible flow values. Therefore, the pin pairs are more likely to be able to establish a connection.

data rate*

The speed of a data transfer process. The speed is typically expressed in bits-per-second or bytes-per-second.

dB*

Decibel.

DBC

Device Bay Controller.

dBr

Decibels above reference noise.

DBS

Direct broadcast satellite.

DC

1. Direct current.

2. Domain controller.

3. Device context.

DCB

See Directory control block.

DCC

Darwin Component Code.

DCD**

1. Data Carrier Detected.

2. Digital capture device.

DCE**

Data circuit-terminating equipment or data-communications equipment. DCE typically refers to a modem device.

DCF

Data Call-First model.

DCI

Display Control Interface.

DCM

1. Device-control module.

2. Digital Content Management.

DCOM

Distributed-Component Object Model.

DCT

Discrete cosine transform.

DDC**

Display Data Channel. The standard for monitors for implementing Plug and Play capability. The communications channel between a monitor and the display adapter to which it is connected. This channel allows the monitor to convey its identity to the display adapter.

DDC2B

Display Data-Channel Standard Level 2B.

DDE**

Dynamic Data Exchange.

DDF

Data decryption field.

DDI

Device-driver interface.

DDK*

Driver Development Kit.

DDL*

Data-definition language.

DDM

Device-driver module.

DDML

Display-driver management layer.

DDN

Defense Data Network.

DDR

Double data rate.

DDRAM

Direct dynamic RAM (DRAM).

DDS**

1. Distributed-Data Server.

2. Digital-Data Service.

deadlock*

An error condition that occurs at runtime when two threads of execution are blocked. Each thread waits to acquire a resource that the other holds. Both threads are unable to run.

decompression

To reverse the procedure run by compression software. The compressed data, therefore, returns to its original size and condition.

decorated section

An INF file section whose name contains a suffix that identifies a particular platform or operating system. For example, [SourceDisksNames.x86] and [aha154x.ntx86] are examples of decorated sections. Decorated sections contain installation information that is only relevant to the platform or operating system the suffix specifies.

default address

An address defined by the USB Specification. A USB device uses this address when it is initially started or re-established. The default address is 00h.

deferred procedure call

A control-object type that is defined in the kernel. A DPC represents a procedure that is to be called later. DPCs are executed in kernel mode at IRQL DISPATCH_LEVEL. See the Windows DDK.

deinterlace

To combine two interlaced fields into a single frame that is not interlaced. Deinterlacing removes artifacts and improves the quality of encoded video.

density

The degree of darkness of an image.

depth-based fog

Blending the color of objects in a scene with a specific fog color. The depth of an object in the scene or its distance from the viewpoint determine the color and the blending.

DES*

Data Encryption Standard.

device**

Any circuit that performs a specific function, for example, a parallel port or a display adapter.

Device Bay

An industry specification that defines a mechanism for the addition and upgrading of PC peripheral devices without opening the chassis.

Device Class

Either a Setup Class or a Device Interface Class.

device class compliance

A device is in device- class compliance when it implements all functional aspects explicitly stated in the specification that describes the device class.

device co-installer

See co-installer.

device dependent

The condition where the implementation of specific software depends on the specific physical device in a computer system. Compare device independent.

device extension

For many drivers, a device extension is the primary and sole global data-storage area of the driver. It maintains the device state and contains any operating system-defined objects and other data required by the driver.

device independent

The condition where the implementation of specific software does not depend on the specific physical devices in a computer system. Compare device dependent.

device ID

A unique identifier for a hardware device that the operating system uses to determine the proper driver to load. A device ID is a vendor-defined numeric value that uniquely identifies a device. The underlying bus driver for a device returns the device ID to the operating system. The operating system then uses the device ID to create a subkey for the device in the registry and to identify the driver to load for the device.

device interrupt request level

The IRQL at which a specified device interrupts. See also DIRQL, IRQL, IDT. See the Windows DDK.

device interface

Device functionality that a driver reveals to applications or other operating system components. A driver can expose zero, one, or more than one interface for a particular device. Each device interface is a member of a Device Interface Class.

Device Interface Class

A group of device interfaces with the same functionality. See the Windows DDK.

device object

The I/O Manager defines a kernel-mode object. This device object represents a physical, logical, or virtual device. Each driver calls IoCreateDevice to create and initialize a device object for each physical, logical, or virtual device that the driver services. See also device extension, Devnode, Driver object. See the Windows DDK.

device power policy owner

The driver for a device that controls its power policy. The owner determines when the driver sleeps and when it wakes. Typically, the function driver for the device performs this function. The driver requests power IRPs to put the device to sleep or wake it up.

device power state

The level of power usage and functionality of a device. These are four discrete device power states: D0, D1, D2, D3.

device queue object

A control-object type that queues I/O requests for subsequent processing. As an object type, it is defined by the kernel and applicable only in kernel mode. A device queue object has an associated executive spin lock and a state that is Busy or Not-Busy. See the Windows DDK.

device stack

A chain of attached device objects that represent the drivers for a device. See the Windows DDK.

device tree

The device tree contains information about the devices on the computer system. The operating system uses information from drivers and other components to update the tree as devices are added or removed. See the Windows DDK.

Devnode

An internal structure that represents a device on the computer system. See the Windows DDK.

DFS*

Distributed file system.

DHCP*

Dynamic Host-Configuration Protocol.

DIAC

Dedicated inquiry-access code

Diacritic

1. Any mark placed over, under, or through a character, usually to indicate a change in phonetic value from the unmarked state.

2. A character that is attached to or overlays a another base character. Most diacritics are characters that contain no spacing and do not increase the width of the base character.

DIB*

1. Device-independent bitmap. DIB is a file format that ensures that the loading and display of bitmap graphics created using one application appears exactly the way they appeared in the original application.

2. Directory information base.

DIFF

Differential.

digital**

Signal representation by a set of discrete numerical values, versus a current or voltage that is continuously fluctuating. Compare with analog.

Digital Rights Management (DRM)

The technology that packages Windows Media® files. DRM also manages the rights for accessing those files.

digital-signal processor (DSP)*

An integrated circuit designed for data manipulations that are performed at high speed. Audio, communications, image manipulation, and other data-acquisition and data-control applications use DSP.

digital video

A video signal represented by binary numbers that are readable by computer. These numbers describe a finite set of colors and luminance levels. Compare with analog video.

digitization

The transformation of analog video signal into digital information.

DIP**

Dual inline package. A small switch that changes hardware settings.

Direct3D

Microsoft Direct3D® is a component of the Microsoft DirectX® API. Direct3D provides the API that software can use to accelerate the display of 3-D graphics without requiring information about the capabilities of the actual hardware on the computer system where the software is running.

DirectDraw

Microsoft DirectDraw® is a component of the DirectX API that provides direct access to display devices and maintains compatibility with Windows graphics-rendering components. DirectDraw provides the API that software can use to accelerate the display of graphics without requiring the information about the capabilities of the actual hardware on the computer system where the software is running.

direct memory access (DMA)**

DMA is a method of transferring data between a device and main memory without intervention by the CPU. The device or a DMA controller chip handles the DMA.

directory control block (DCB)

DCB is an internal NTFS file-system structure in which the file system maintains the state for an open instance of a directory file.

directory file

A file that points to or lists a set of named file objects.

Directory files that are on a disk that are represented in the NT kernel as file objects, not as object directory objects. See also file object and object directory object.

directory object

See object directory object.

DirectShow

Microsoft DirectShow® is an API for client-side playback, transformation, and capture of a wide variety of data formats. DirectShow is the successor to Microsoft Video for Windows (VfW) and Microsoft ActiveMovie™. For developers, the component architecture of DirectShow simplifies the support of custom data formats or creates custom effects and transforms on standard formats. DirectShow provides default support for MPEG-1 (including MP3), MPEG-2 parsing and multiplexing, MPEG-4, AVI, WAV, RIFF, and DVD.

DirectX*

Microsoft DirectX is an advanced set of multimedia APIs built into Windows operating systems. DirectX provides a standard development platform for Windows-based PCs by enabling software developers to access specialized hardware features without having to write code that is hardware-specific.

discretionary access control list

Part of the security descriptor for an object. The DACL can be applied to a newly created object to restrict access to the object. See also ACE, access right, ACL, and security descriptor.

Dir-sync

See DSS.

disk I/O controller

Also called hard-disk controller (HDC). A special-purpose chip and circuitry that directs and controls reading from and writing to the disk drive on a computer.

DISP

Directory-Information Shadowing Protocol

dispatch state

The state in which a thread can be at any given moment, including Initialized, Ready, Standby, Running, Waiting, and Terminated.

dispatcher objects

A class of object types that are defined by the kernel. These objects manage the processes of dispatching and synchronization. See the Windows DDK.

display resolution

The number of pixels (horizontal and vertical) that are displayed on the screen.

DIT

Directory information tree.

DLC**

1. Digital Loop Carrier.

2. Data Link Control.

DLL**

DLLs are modules that contain functions and data. A DLL is loaded at run time by its calling modules (.exe or .dll). When a DLL is loaded, it is correlated into the address space of the calling process.

DLS

1. Distributed Link Services.

2. Downloadable Sound.

DMA*

See direct memory access.

DMI*

Desktop Management Interface. A framework created by the Distributed Management Task Force (DMTF). DMTF specifications define interfaces that are industry standards for providing hardware instrumentation and management applications.

DMT

Discrete multitone.

DMTF*

Distributed Management Task Force.

DN

Distinguished name.

DNS**

Domain Name System.

dock**

To insert a portable computer into a base unit. Cold docking means that the docking process must begin when the computer is in a power off (S5) state, and the computer must be powered on before the docking process is complete. Hot docking means the computer can be docked while running at full power.

docking station*

The base computer unit into which a user can insert a portable computer. After inserting the portable computer into the docking station, the combination becomes equivalent to a desktop PC. A typical docking station provides drive bays, expansion slots, all the ports on an equivalent desktop computer, and AC power.

DOCSIS*

Data-Over-Cable Service Interface Specification.

DOM**

Distributed Operations Master.

dongle**

A physical device, attached to an I/O port of a PC that adds hardware capabilities.

DOP

Directory Operational Protocol.

DOS**

Disk operating system. See also MS-DOS.

Dot4

1. IEEE 1284.4, Standard for Data Delivery and Logical Channels for IEEE Standard 1284 Interfaces.

2. The device class under Windows 2000 and later operating systems for a parent device that controls the operation of a multifunction IEEE 1284.4 peripheral device.

double-byte character set

DBCS is a specific type of a character set that can use more than one byte to represent a single character. It includes some characters that consist of 1 byte and some characters that consist of 2 bytes. Languages like Chinese, Japanese, and Korean use DBCS.

doubleword

A unit of data consisting of two contiguous words (connected bytes, not text). The microprocessor of the computer handles these words together.

DPA

Distributed password authentication.

DPC

See deferred procedure call.

DPI*

Dots-per-inch.

DPMS*

Display Power-Management Signaling.

DRAM*

Dynamic RAM.

DRF

Data recovery field.

driver**

Kernel-mode code. A driver that either controls or emulates a hardware device.

driver node

An entry in the INF Models section that refers to the support for installing a device, for example, any services, device-specific co-installers, and registry entries.

driver object

An object in kernel mode that represents the load image of a driver. The I/O Manager uses this object to locate certain entry points in the driver.

driver stack

Device objects that forward IRPs to other device objects. Stacking always occurs from the bottom up and is torn down from the top.

Driver Verifier

A utility for testing drivers that monitors the activities of the driver in a variety of different error conditions. These errors include invalid use of memory pool, spin locks, and input/output routines. When Driver Verifier detects one of these errors, it issues a bug check.

DRM

See Digital Rights Management.

DRMK

DRM kernel.

DRQ

Data request.

DRS

Driver referral server.

DS**

1. Directory Services.

2. Digital services.

3. Digital signal.

DSA*

Directory server agent.

DSC

Digital still camera.

DSDT

Differentiated System Description Table. In an ACPI BIOS, the DSDT contains the Differentiated Definition Block. This block supplies the implementation and configuration information about the base computer system. The operating system always inserts the DSDT information into the ACPI Namespace at system boot time, and never removes it.

DSE

Development software engineer.

DSL*

Digital subscriber line.

DSLAM*

DSL access multiplexer.

DSP*

See digital-signal processor.

DSS**

Digital satellite system. Motion-video test procedures use this system.

DSSS

Direct Sequence Spread Spectrum. DSSS modulates frequency using a predefined "spreading code" algorithm. DSSS jumps much faster than Frequency-Hopping Spread Spectrum (FHSS).

DSVD

Digital simultaneous voice/data.

DTE

Data terminal equipment. DTE typically refers to a PC.

DTMF**

Dual-tone modulation frequency.

DTR*

Data-terminal ready.

DTV**

Digital television. DTV standards allow standard resolution mode in addition to HDTV mode. Resolution mode has about twice the horizontal resolution of conventional analog broadcasts. Video uses MPEG-2 digital compression, and audio uses AC-3 (Digital Dolby) compression.

DUN

Dial-up networking.

DV

1. Digital video.

2. Data voice.

DVB

Digital video broadcasting.

DVB/DAVIC

Digital Video Broadcasting/Digital Audio-Visual Council.

DVC

Digital video compression.

DVCR

Digital-video cassette recorder.

DVD**

An optical disk storage format that encompasses audio, video, and computer data.

DVHS

Digital-VHS.

DVI**

Digital Visual Interface, an industry standard for a digital display-device interconnect interface.

DVR

Digital-video recorder.

DX8

DirectX version 8.0.

dynamic detection

The process by which an operating system detects the addition or removal of a new device from a PC. Dynamic detection allows the operating system and applications to immediately begin to use the added devices or to stop using the removed devices without restarting the computer system.

E

EA

Extended attribute. The user describes extended information about a file through an extended attribute. The EA is viewed as a name-value pair without a type. The operating system typically uses the EA to store the icon for an image or to indicate that the file is a symbolic link.

EAP

Extensible Authentication Protocol.

EAPOL

EAP over LAN.

EBD

Emergency boot disk.

EC

Embedded controller.

ECA

Enrollment Certification Authority.

ECC*

Error-correction code.

ECM

Entitlement-control message.

ECMA*

European Computer Manufacturers Association.

ECN

Engineering Change Notice (for PCI specification).

ECP*

Extended capabilities port, as defined in the IEEE 1284–1994 specification. This port provides PC-to-peripheral and peripheral-to-PC data transfers.

ECR

Engineering change request for PCI.

EDID

Extended-Display Identification Data.

EDK

Extension Development Kit.

EDMA

Enhanced-dynamic RAM.

EDT

European Deaf Telephone.

EE

Eastern European.

EEPROM*

Electrically erasable programmable ROM.

EET

Enhanced environment technology.

EFI

Extensible Firmware Interface.

EFS

Encrypting file system.

EIA*

Electronic Industries Association.

EIDE*

Enhanced IDE (also E-IDE).

EIO

Extended I/O.

EISA*

Extended Industry Standard Architecture.

EMB

Extended memory block.

embedded controller

The general class of microcontrollers that supports OEM-specific implementations, primarily in mobile devices. The embedded controller performs low-level functions through an interface to the host microprocessor.

embedded controller interface**

ACPI defines a standard hardware and software communications interface between an operating system driver and an embedded controller—for example, Smart Battery and AML code. The interface allows any operating system to provide a standard driver that can directly communicate with an embedded controller in the system. This communication allows other drivers to communicate with and use the resources of system embedded controllers.

EMF

Enhanced metafile.

EMI

Electromagnetic interference.

encoding

A method (algorithm) for presenting characters in digital form by correlating sequences of code values of into sequences of bytes. (For example, ASCII, Unicode, and Windows 1252)

encrypt**

To programmatically disguise content to hide its substance. Encrypted content, often called a cipher, cannot be played without reversing its format into clear content through the process of decryption.

endpoint address

The combination of an endpoint number and an endpoint direction on a Universal Serial Bus (USB) device. Each endpoint address supports data transfer in one direction.

end-user defined character

EUDC is a special character such as a rare ideograph that the user creates with an editor and assigns to a code point within a reserved range. Such characters are not automatically recognized by the operating system for functions such as sorting.

enumeration

The process by which Plug and Play identifies logical devices and buses during computer system startup. Plug and Play identifies the available resources of the logical devices and buses.

enumerator

A Plug and Play device driver that detects devices below its own device node on the hardware tree and creates unique device IDs. The driver also reports to the Windows Configuration Manager during startup. For example, a SCSI adapter provides a SCSI enumerator that detects devices on the SCSI bus.

EPF

Electronic picture frame.

EPG

Electronic program guide.

EPP

Enhanced parallel port.

ERP*

Enterprise resource planning.

ESCD

Extended-System Configuration Data.

ESD**

1. Electrostatic discharge.

2. Electronic software distribution.

ESDI*

Enhanced Small-Device Interface.

ESP**

1. EFI system partition.

2. Enhanced serial port.

ETK

Embedded Toolkit for Windows CE.

ETSI

European Telecommunications Standards Institute.

event object

One or more threads can wait upon this user-mode object until the event is set to the Signaled state. Every user-mode event object is implemented through the use of a kernel-mode event object that is. A kernel-mode event object is an instance of a dispatcher object type that is defined by the kernel. See the Windows DDK.

event set

A uniquely identified set that represents a group of items about which a client can be notified.

ExCA

Exchangeable Card Architecture.

exception**

A synchronous error condition. This condition results from the execution of a particular machine instruction. See also SEH.

exclusive device

A device for which a miniport driver is dedicated. It is responsible for supporting a single kernel-mode driver. A display adapter is considered an exclusive device.

executive**

The set of kernel-mode components that form the base Microsoft Windows NT® or later operating system. See the Windows DDK.

executive worker threads

See system worker threads.

EXIF

Exchangeable image-file format.

expansion bus**

A group of control lines that provide a buffered interface to devices. These devices can be located either on the system board or on cards that are plugged into expansion connectors. Common expansion buses included on the system board are USB, PC Card, and PCI.

expansion card**

A card that connects to an expansion bus. The card contains one or more devices.

expansion ROM

See option ROM.

F

FACS

Firmware ACPI Control Structure.

FADT

Fixed ACPI Description Table. This table in the computer system’s firmware contains the I/O port locations of permanent ACPI feature registers.

FAQ*

Frequently asked questions.

FAT*

File allocation table. FAT is a table or list that an operating system maintains. It tracks the status of various segments of disk space used for file storage.

fault tolerance**

A feature of the Windows NT and later operating systems. This feature includes the Win32-based Disk Administrator utility that is visible to the end user. Ftdisk, an intermediate driver, handles disk partition mirroring, striping, and volume set management. This supporting driver is supplied by the operating system.

FCA

Fibre Channel Arbitrated Loop.

FCB**

A file control block is an internal file system structure in which a file system maintains the state of an open file.

FCC*

Federal Communications Commission.

FCP

Function Control Protocol.

FC-PH

Fibre Channel Physical.

FDC

Floppy disk controller. FDC is a special-purpose chip and circuitry that directs and controls reading from and writing to a disk drive.

FDDI*

Fiber Distributed Data Interface.

FDO

Functional device object. A device object created by a PnP function driver using IoCreateDevice. An FDO represents a function driver in the stack of PnP drivers for a device.

FEC

Forward error correction.

FEK

File Encryption Key.

FET*

Field-effect transistor.

FFT*

Fast Fourier transform.

FH

Frequency hopping.

FHS

Frequency hop synchronization.

FHSS

Frequency-Hopping Spread Spectrum. FHSS uses a synchronized clocking algorithm and jumps around to different carrier frequencies.

FiDO

Filter device object.

field**

One half (every other line) of a television picture (frame). A field is one complete vertical scan of the picture. One field contains 262.5 lines. Two fields create a complete television picture (frame). The lines of the first field are vertically interlaced with the lines of second field to create 525 lines of resolution.

FIFO*

First in/first out. A method for processing a queue. Items in the queue are removed in the same order in which they were added.

file object

An object that is visible in user mode. It represents an open instance of a file, device, directory, volume, and so on. A file object is accessed through the file handle that is returned by a function of the protected subsystem. See the Windows DDK.

filter driver

Filter drivers are optional drivers that add value to or modify the behavior of a device. A filter driver can service one or more devices. See the Windows DDK.

filters

A program or set of features within a program that reads its standard or designated input, transforms the input in some way, then writes the output to a designated destination. See the Windows DDK.

FIPS*

Federal Information Processing Standards.

FIR

Fast IR.

firmware*

Software routines stored in read-only memory (ROM). Unlike random access memory (RAM), read-only memory stays intact in the absence of electrical power. Startup routines and low-level input/output instructions are stored in firmware. See also BIOS, EFI.

flash**

A type of non-volatile memory built into the unit or available as a PC Card. You can write flash memory in blocks or over the entire chip. This ability facilitates erasing or updating.

flat shading

A method of shading. Flat shading calculates a single intensity value for the rendered polygon that is used for the surface of the entire polygon. This is also known as "constant" or "faceted" shading.

FM*

Frequency modulation.

FNO

Foreign Namespace Object.

fog effects

The blending of objects in the distance. The blending occurs with an established color to yield a haze effect in an image.

font**

A collection of glyphs that display text in a particular typeface.

font association

The substitution of missing glyphs with glyphs from an appropriate font that is listed in the registry. Applies only to ANSI text APIs. An ANSI codepage identifies the substitute font. Font association is restricted to scripts and fonts that correlate codepoints to glyphs one-to-one. The operating system recreates the registry setting whenever the user changes system locale, updates language support, or changes user interface language.

FOP

Fan-Out-PHY.

formatted text

Text that is displayed with multiple attributes such as typeface, slant, weight, and color. Formatting can include special effects such as shading, underlining, and blinking.

FOURCC

Four-character codes. These codes are stored in the file headers of files that contain multimedia data. FOURCCs describe the software technology that was used to produce the multimedia data. See the Windows DDK.

FP

Floating point.

fps

Frames-per-second.

FQDN

Fully qualified domain name.

FR

Frame relay.

frame**

A single screen-sized image. You can display this image in sequence with other, slightly different images to create animated drawings. A video frame consists of two interlaced fields of either 525 lines (NTSC) or 625 lines (PAL/SECAM). These frames progress at 30 frames-per-second (NTSC) or 25 frames-per-second (PAL/SECAM). Film runs at 24 frames-per-second.

frame rate**

The number of frames displayed, per second, in video. High-frame rates generally produce better quality video, because there are more frames. This smoothes the movement in the video.

free build

A version of the operating system that has been compiled and built without symbols and support for debugging software components. This reduces the size and increases the speed of the free build, because it lacks debugging symbols and checks. See also checked build.

FRS

File Replication Service.

FRU

Field Replaceable Units.

FS**

A file-system driver that registers itself with the I/O Manager as an active file system.

FS A

Full-scale, A-weighted. FS A indicates that decibels are measured relative to full scale using "A weighting" filters. FS A is used to measure the dynamic-range performance of digital/audio recording and playback.

FSB

Front-side bus.

FSD

File system driver. Refers to the portion of a driver that executes in the context of the caller.

FSIP

Full-scale input.

FSK*

Frequency-shift keying.

FSOP

Full-scale output.

FSP

The file system process usually refers to a set of device-dedicated or system-worker threads that help an FSD to complete work. However, FSP can also refer to a kernel-mode process that an FSD establishes. See the Windows DDK.

FSRTL

File-System Run-Time Library.

FTL

File-translation layer.

FTP*

File-transfer protocol.

FTS

Fault-tolerance system.

full duplex*

Indicates bidirectional data flow.

full-motion video**

Video reproduction at 30 frames-per-second (NTSC-original signals) or 25 frames-per-second (PAL-original signals). See also frame.

functional device

See filters.

functional test

A functional test verifies that all the functions of a feature have been correctly implemented.

function driver

A function driver is the primary driver for a device. It provides the operational interface for a device. A function driver typically handles read-and-write operations and manages device power policy. See the Windows DDK.

G

G.Lite (G.922.2)

1. A DSL that is universal.

2. A DSL that is splitterless. See also splitterless.

G11N

Abbreviated form of GLOBALIZATION; that is, G + 11 characters + N.

GAL

Global address list.

gamma

The exponent in a color-space equation that relates the intensity of output to the input signal.

gamut

The range of colors that a color-capable device can produce.

GART

GART is the chipset hardware that the operating system uses to correlate locked pages onto physical memory. AGP devices can use these correlations.

GB*

Gigabyte.

GC

Global catalog.

GDI*

Graphics Device Interface.

GDT

Global Descriptor Table.

GFX

Global effects.

GIDEI

General Input-Device Emulation Interface.

GIF*

Graphics Interchange Format.

GINA

Graphical Identification and Authentication.

globalization

The design and development of a software product to perform in multiple locations.

glyph

A graphical representation of a character, a part character (for example, a diacritic such as ° or ?), or a sequence of characters (for example, a ligature).

Gouraud shading

A method of shading based on the interposition of lines of a polygon from its vertices. The shading value for the vertices is calculated from the normal of the vertex. Gouraud shading is also known as "color-interpolation" or "intensity-interpolation" shading.

GP

General protection.

GPE

General Purpose Event.

GPO

Group-policy object.

GPT

GUID partition table.

GPU

graphics processing unit.

graceful recovery

The termination of a process that allows the operating system or parent process to regain control. A graceful recovery does not crash the machine or create a GPF or blue screen. The user is not required to close the application. Rather, the user can continue to use the other functionality of the application. Also called graceful exit.

graphics**

Generally refers to computer graphics, including the software engine and hardware adapter that render images on screen.

gray scale**

The spectrum (range) of shades of black of an image.

group*

In networking, an account that contains other accounts, called members. Permissions and rights granted to a group are also granted to its members.

group policy

Specifies configurations for groups of users and computers. These groups include software policies, scripts, user documents and configurations, application deployment, and security configurations.

GSM*

Global System for Mobile Communications.

GSNW

Gateway Services for Networks.

GSS-API

Generic Security Service Application Program Interface.

GSTN

General Switched Telephone Network.

GTF

Generalized Timing Formula.

GUI*

graphical user interface. An interface that represents programs, files, and options with graphical images. These images can include icons, menus, and dialog boxes. The user selects and activates these options by pointing and clicking with a mouse or with the keyboard. A particular GUI item (for example, a scroll bar) works the same way in all applications.

GUID**

globally unique identifier. A GUID consists of a 16-byte value generated from the unique identifier on an adapter, the current date and time, and a sequence number. GUIDs allow the creation of identifiers that will not overlap with other identifiers that are created in a similar way.

H

H.323**

ITU standards to perform multimedia conferences over IP.

H.324**

ITU-T standard that specifies procedures for video telephony between computers over a GSTN.

HAL**

Hardware Abstraction Layer. An executive component in Windows NT and later operating systems that provides support that is specific to a particular hardware platform. HAL provides support for the Kernel, I/O Manager, kernel-mode debuggers, and device drivers that are the lowest level. The HAL exports routines that extract hardware details that are platform-specific about caches, I/O buses, and interrupts. HAL provides an interface between the hardware of the platform and the operating system software.

hardware branch

The hardware archive root key in the registry. This key is a superset of the memory-resident hardware tree. Although the hardware tree contains information only about current devices, the registry contains a complete list of all the hardware that has been installed on the particular computer. The hardware root key is \\Hkey_Local_Machine\Hardware.

hardware dependent

The condition where the implementation of specific software depends on the specific physical computer hardware. Compare Hardware independent.

hardware exception

See SEH.

hardware ID

The most specific device identifier as defined by the device’s vendor. The PnP Manager uses this string to find a match for an INF file for a device. A device can have one or more hardware IDs. See the Windows DDK. See also Device ID, Compatible ID, Instance ID.

hardware independent

The condition where the implementation of specific software does not depend on the actual physical computer hardware. Compare hardware dependent.

hardware priority

See IDT and IRQL.

hardware tree**

A record in RAM of the current configuration of the computer hardware. The record is based on the information for all devices in the hardware branch of the registry. The operating system creates the hardware tree whenever it starts or whenever a dynamic change occurs to the hardware configuration.

HAVi

Home Audio Video interoperability.

HBA

Host Bus Adapter. A hardware device that connects the operating system and a SCSI bus. A SCSI miniport driver manages the lower layers of the SCSI-II protocol on the HBA. See also miniport driver, port driver, class driver, SFD, and SCSI.

HCA

Host channel adapter.

HCAL

Hardware-channel abstraction layer.

HCD

Host controller driver. For USB, HCD defines a driver stack that controls the USB chipset to which a device is attached.

HCI

Host controller interface. An example of an HCI is the computer’s hardware interface that supports USB.

HCL

Hardware Compatibility List. HCL is a registry of products that WHQL has tested. These products passed Windows compatibility testing.

HCT

Hardware Compatibility Tests. HCT is a collection of tests from WHQL that verify hardware and device driver operations under a specific operating situation. These tests exercise the combination of a device, a software driver, and an operating system under controlled conditions. The tests then verify that all components operate properly.

HDC

Hard-disk controller. A combination of chip and circuitry that directs and controls the reading from and writing to the hard disk drive in a computer.

HDCP

High-definition Digital Content Protection.

HDD

Hard-disk drive.

HDLC*

High-Level Data Link Control.

HDTV**

High-definition TV. A new television display standard that doubles the 525 lines per picture to 1050 lines and increases the screen aspect ratio from 12:9 to 16:9. This aspect ratio creates a television screen that is shaped like a movie screen.

headless

A server appliance that does not require a keyboard, pointing device, or monitor for display or input.

heap**

See pool memory.

HEL

Hardware Emulation Layer. An interface that DirectDraw provides. This interface emulates features in software.

HFC

Hybrid fiber-coax.

hibernate state

System power state S4. In this state, the power is turned off, but the operating system can resume quickly from a file written to disk before power was shut off. See also hibernation file.

hibernation file

A system-image file that is written to disk immediately before the computer transitions to system state S4. Upon restarting, the hibernate state is loaded so the operating system can resume from its previous location. See also hibernate state.

HID

Human Interface Device.

HID specification

See Human Interface Device specification.

high-contrast support

Part of Accessibility options established for users who require a high degree of contrast to be able to read screen text.

high resolution**

An adjective that describes the image quality of a display device that can use a large number of pixels per square inch.

HIPPI*

High-Performance Parallel Interface.

HMA*

High-Memory Area. Under early versions of Windows, the first 64K of extended memory.

HMMP

HyperMedia Management Protocol. The summary of CIM objects and the operations on those CIM objects.

HMMS

See CIM.

HMOM

See CIMOM.

HomePNA

The Home Phoneline Networking Alliance. This alliance develops specifications for interoperable, home-networked devices that use the existing wiring.

host**

A server computer that has access to other computers on the network. A host computer provides services to computers that connect to it on a network. For example, the services can include news, mail, or data.

host controller

The USB interface of the host.

host-to-peripheral

A direct connection between the host PC hardware and the peripheral hardware.

HRFWG

The HomeRF Working Group. This group provides the foundation for a broad range of interoperable consumer devices. The foundation establishes an open-industry specification for wireless digital communication between PCs and consumer electronic devices. The devices can be anywhere in and around the home. The HRFWG is developing a specification for wireless communications in the home. This specification is called the Shared Wireless Access Protocol (SWAP).

HPC

Handheld PC.

HPFS

High-Performance File System.

HRTF

Head Related Transfer Function.

HSB*

Hue-saturation-brightness. With the HSB model, you can define all colors by expressing their levels of hue, saturation, and brightness, in percentages.

HSCDS

High-speed cable data services.

HSM

Hierarchical storage management.

HSSDC

High-speed serial data connector.

HTML*

Hypertext Markup Language.

HTTP*

Hypertext Transfer Protocol.

hub**

A device that provides additional connections for other devices. For example, a USB hub is a USB device that provides connections for additional USB devices.

hue**

The color tint of an image. Three factors determine the color of the analog video signal: hue, saturation, and luminance.

Human Interface Device (HID) specification

The device-class definition developed by the USB standards group for HIDs. The HID specification provides a basis for the WDM input-device support. The specification also unifies input devices by providing flexible data reporting.

HUT

HID Usage Tables.

HW RAID

A RAID set where all RAID operations are performed in the RAID hardware. These operations are performed without knowledge of the operating system.

hyperspace**

A block of virtual memory somewhere in kernel space. This memory is dedicated to the use of the Memory Manager. Every instance of a virtual address space that is user-mode has an associated hyperspace area. In this hyperspace area, the Memory Manager maintains internal data (for example, page table pages and WSLs) for the current process. See also Kernel.

Hz*

Hertz.

I

I2O*

Intelligent I/O.

I18N

Abbreviated form of INTERNATIONALIZATION. I + 18 characters + N.

IA-32, IA-64*

Intel Architectures for 32-bit and 64-bit platforms.

IAC**

Inquiry Access Code.

IAL

Intel Architecture Labs.

IANA*

Internet Assigned Numbers Authority.

IA-PC

Intel Architecture Personal Computer. A general term for computers built with processors that conform to the Intel Architecture instruction set.

IAS

Information Access Service.

ICC

International Color Consortium. ICC is an industry organization that creates and promotes the standardization of an open, color-management system architecture that can work on multiple platforms. This consortium does not favor a specific vendor.

ICD

Installable Client Driver. An OpenGL driver model in which the driver implements the entire OpenGL pipeline.

ICM**

Image Color Management.

ICMP*

Internet Control Message Protocol.

ICP

Internet content provider.

ICS

Internet Connection Sharing.

ID

Identifier. Generally, an ID is any text string used as a label. For example, the name of a procedure in a program or the unique name of a hard drive can be an ID.

IDB

An internal structure. The kernel uses an IDB.

iDCT

Inverse Discrete Cosine Transform.

IDE**

Integrated Device Electronics. A type of disk-drive interface where the controller electronics reside on the drive. This eliminates the requirement for a separate adapter. See also ATA.

IDSL*

Internet Digital Subscriber Line. IDSL is the basic rate service of ISDN that is deployed using DSL technology.

IDT

1. Internet Development Toolbox.

2. Interrupt Dispatch Table. A call table that the kernel defines. It contains first-level entries that are platform-dependent. See the Windows DDK.

IEAK

Internet Explorer Administration Kit.

IEC

International Electrotechnical Commission.

IEEE**

Institute of Electrical and Electronics Engineers Founded. IEEE is an organization composed of engineers, scientists, and students. IEEE is best known for the development of standards for the computer and electronics industry.

IETF

Internet Engineering Task Force.

IF

Implementers Forum.

IFS**

Installable file system.

IGMP*

Internet Group Management Protocol.

IGN

Internet group names.

IHV

Independent hardware vendor.

IIS*

Internet Information Server.

ILEC*

Independent (or Incumbent) Local Exchange Carrier.

ILMI

Interim Local Management Interface.

IM*

Instant messaging.

IMADPCM

Music-oriented codec.

Image**

The computerized representation of a picture or graphic.

image resolution

The fineness or coarseness of a digitized image. Image resolution is measured in dots per inch (DPI).

IMAPI

Image Mastering API.

IMD

Intermodulation Distortion.

IME

See Input Method Editor.

IMM

See Input Method Manager.

IMS

Integrated Management System.

INF file

An INF file is an ASCII or Unicode text file that provides device and driver information. This information includes the driver files, registry entries, device IDs, catalog files, and version information that is required to install the device or driver.

input class

The class of filters that provide an interface for HID hardware. Under the WDM HID architecture in the Windows operating system, HID hardware includes USB and legacy devices, plus proprietary and other HID hardware.

Input language

A language entered into a computer system for processing. The language can be entered through the keyboard, a speech-to-text converter, or an IME.

Input Locale

Pairing of input language and method of input determines what language is currently being entered and how. See also Locale, System Locale, User Locale, User Interface (UI) Language.

Input Method Editor

IME is a software program that facilitates entering text with large character sets such as Chinese, Japanese, and Korean.

Input Method Manager

IMM is the module in Windows that handles communication between IMEs and applications.

instance ID

A string that distinguishes a device from other devices of the same type on a machine. An instance ID is a string (without any path-separator characters) that contains serial-number information, if supported by the underlying bus, or some kind of location information. The format of the string is bus specific. An instance ID is persistent across system boots.

instantiate*

In object-oriented programming, the creation of an instance of a class.

instrumentation

A mechanism for reporting information about the state of system hardware and software. This allows management applications to determine and change the state of a system. Instrumentation notifies the management application of the state changes, too

integral subsystem

A protected subsystem that performs an essential operating-system task. In Windows NT and later operating systems, the integral subsystems include the Local Security Authority, the Security Accounts Manager, the Session Manager, and the network server. See also protected subsystem.

integrated device

Any device that is provided on the system board instead of an expansion card. For example, the devices can include parallel ports, display adapters, and network adapters.

integration test

An integration test verifies the functionality and correctness of the implementation of a feature. The feature must be fully integrated with other operating system components.

intelligent streaming

A type of streaming that detects network conditions. Intelligent streaming then adjusts the properties of a video or audio stream to maximize quality. Intelligent streaming is only available for content encoded by using a multiple-bit rate profile.

IntelliMirror

Microsoft IntelliMirror® is a set of management technologies that reflect systems, data, and applications on a server.

interactive video**

A video program and a computer program that run simultaneously with each other. In interactive video, the user’s actions, choices, and decisions affect the way in which the program develops.

interconnect**

Electrical or mechanical connection. Interconnect is the physical connection and communication between two components in a computer system.

interface*

1. The point at which a connection is made between two elements. This connection allows them to work with each other.

2. Software that enables a program to work with the user (the user interface, which can be a command-line interface, menu-driven, or a graphical user interface). This interface can also be with another program or the hardware of the computer.

3. An adapter, plug, or other device that connects pieces of hardware with the computer so that information can be moved. For example, standardized interfaces such as RS-232-C standard and SCSI enable communications between computers and printers or disks.

interframe coding

Compression techniques that track the differences between frames of video. Compared to intraframe coding, interframe coding provides more compression over a range of frames.

interlaced**

To display video by using a field. Interlaced video uses two video fields to create a single frame of video. Each field of video contains alternating lines of an image. Field 1 displays the odd numbered lines, and field 2 displays the even numbered lines. Interlacing saves bandwidth when the video is transmitted as a television broadcast or on cable.

intermediate driver

An intermediate driver processes I/O requests between high-level and low-level drivers. The highest-level driver is typically a file system driver. The lowest-level driver controls the hardware device for which the request is directed. See also class driver, filter driver, layered driver.

Internationalization

Term used to indicate Globalization and Localizability. I18N is a common abbreviation for Internationalization because the "I" in International is followed by 18 letters and ends with the letter "N."

interpolation

To average pixel information when scaling an image. To reduce the size of an image, pixels are averaged to create a single new pixel. To increase the size of an image, additional pixels are created by averaging pixels of the smaller image.

interrupt**

An asynchronous hardware signal. An interrupt typically indicates that a peripheral device requires service. The processor detects the interrupt. An interrupt causes the processor to save its current state, to branch to an established location, and to resume execution at that location. See also IDT.

interrupt object

A control object type that the kernel defines. An interrupt object operates only in kernel mode and connects a hardware interrupt source and an ISR to an IDT entry. Or, an interrupt object connects an ISR and an interrupt transfer routine to a second-level IDT entry. The interrupt transfer routine depends on the ISR at its IRQL. See the Windows DDK.

interrupt transfer

One of the four USB transfer types. Small data, non-periodic, low-frequency, and bounded latency are characteristics of interrupt transfer. Interrupt transfers typically handle service requirements.

invalid page

A page-sized range of virtual addresses for which a page fault occurs when any address in the range is referenced. For drivers, referencing an invalid page causes a fatal page fault. The fatal page fault does not occur if the driver is running at an IRQL <= APC_LEVEL when the reference occurs.

I/O

Input/output.

IOCTL

Input/output control. A custom class of IRPs available to user mode. Each WDM class driver has a set of IOCTLs that communicates with applications. The IOCTLs give information to the class driver about the intended use by applications. The class driver performs all IOCTL parameter validation.

I/O stack location

An I/O stack location refers to the parts of an IRP that are allocated for each driver in a chain of layered drivers. Each driver owns one of the stack locations in the packet. Each driver obtains driver-specific information about what I/O operation to perform on the specified device. The driver must use the supplied parameters. See the Windows DDK.

I/O status block

A data structure that is part of each IRP. An I/O status block serves two purposes:

For asynchronous operating system calls, it provides a method for determining the effectiveness of the service upon completion of the IRP. It also provides more information about the effectiveness of the service. See the Windows DDK.

IOS

I/O Supervisor.

IP*

1. Internet Protocol.
2. Intellectual property.

IPC*

Interprocess communication.

IP multicasting**

Sending data to distributed servers on the multicast backbone. For large amounts of data, IP multicast is more efficient than normal Internet transmissions, because the server can broadcast a message to many recipients simultaneously. Unlike traditional Internet traffic that requires separate connections for each source-destination pair, IP multicasting allows many recipients to share the same source. Therefore, one set of packets is transmitted for all the destinations.

IPC*

Interprocess communication.

IPL*

Initial program load. The computer system uses this device during startup. IPL loads an operating system into memory.

IPOA

IP over ATM.

IPP*

Internet Printing Protocol.

IPSec

IP Security.

IPX

Internetwork Packet Exchange.

IPX/SPX

Internetwork Packet Exchange/Sequenced Packet Exchange Protocol.

IR

Infrared.

IRAM

Intelligent RAM.

IRC*

Internet relay chat.

IrDA*

Infrared Data Association.

IRDP

Internet Router Discovery Protocol.

IrLAP

IR Link Access Protocol.

IrLMP

IR Link Management Protocol.

IRP

I/O request packet. Data structures that drivers use to communicate with each other. The basic method of communication between kernel-mode device drivers. An IRP is an important data structure for WDM. WDM features multiple layered drivers. Therefore, an IRP presents every I/O request. The IRP is passed from one driver layer to another, until the request is complete. When a driver receives an IRP, it performs the operation the IRP specifies. Then the driver either passes the IRP back to the I/O Manager for disposal or onto an adjacent driver layer.

See the Windows DDK. See also I/O status block and device object.

IRP_MJ_XXX

IRP Major. One of a predefined class of IRPs that a device can accept.

IRQ**

Interrupt request. A device can use IRQ to request service from its software driver.

IRQL

Interrupt request level. IRQL is the priority level of the hardware at which a specific kernel-mode routine runs.

IrTran-P

Infrared Transfer Picture.

ISA*

Industry Standard Architecture.

ISAPI*

Internet Server API.

ISDN*

Integrated Service Digital Network. A set of communications standards that allow a single phone line or optical cable to carry voice, digital-network services, and video.

ISIS**

Image and Scanner Interface Specification.

ISO*

International Organization for Standardization.

isochronous

Communication protocol that is based on time segments instead of handshaking. For example, a process might contain 20 percent of total bus bandwidth. During its time segment, the process can stream data.

isochronous data

A stream of data. Its delivery date implies its timing.

isochronous transfer

A data transmission type that is steady and related to timing. It does not consider guaranteed delivery of data.

isolation

The Plug and Play process that distinguishes between devices on an ISA bus after computer system startup.

ISO/OSI

ISO Open Systems Interconnection model. A layered architecture that standardizes levels of service. The architecture also standardized types of interaction for computers exchanging information through a communications network.

ISP*

Internet service provider.

ISR

Interrupt service routine. A routine that services a device when the device generates an interrupt. An ISR of a kernel-mode driver executes at raised IRQL, usually at the DIRQL of the interrupt objects established for its device. For example, drivers connected to second-level IDT entries execute at the IRQL of the first-level entry. See the Windows DDK.

IST

Interrupt service thread.

ISV*

Independent software vendor.

ITU*

International Telecommunications Union.

ITU-T*

International Telecommunications Union – Telecommunications Standardization Sector.

ITV

Interactive television.

IVR*

Interactive voice response.

IXC

Inter Exchange Carriers.

J

JNI

Java Native Interface.

JPEG

Joint Photographic Experts Group. A working committee under the guidance of the ISO that works to define a proposed universal standard for the digital compression and decompression of still images.

K

K or KB*

Kilobyte (1024 bytes)

KBC

Keyboard controller.

Kbps

Kilobits per second.

KCC

Knowledge Consistency Checker.

KDC

Key Distribution Center.

KDT

Keyboard definition table.

kernel**

The core of the layered architecture that manages the basic operations of Windows NT and later operating systems.

kernel mode

The privileged processor mode in which the Windows executive component runs. A driver or thread that runs in kernel mode has access to system memory and hardware. See also executive, user mode.

kernel space

A block of virtual memory that is dedicated to the kernel-mode code. Typically, in Windows NT and later versions, kernel space is a range of virtual addresses of high order. These spaces are one to two gigabytes in size. See also hyperspace, pool memory, and user space.

kernel streaming object

An individual kernel-streaming component. The client views the component as a file object. The object includes filters, pins, clocks, and allocators. See also file object.

keyboard layout**

A standard arrangement of characters on a keyboard. This arrangement defines which keys produce particular characters or scan codes.

key object

An object type that the Configuration Manager defines to represent an entry in the registry database. Each instance of a key object represents a registry node. A registry node is part of the registry path to a set of subkeys. See also registry, value entry.

kHz*

Kilohertz.

KMixer

Kernel Mixer.

knowledge worker**

User (other than IT professionals) who uses PC technology to access data for analysis and communication.

KS

Kernel streaming.

Kss

Kilo-samples per second.

L

L10N

Abbreviated form of LOCALIZATION. That is, L + 10 characters + N.

L2

Level 2.

L2TP

Layer 2 Tunneling Protocol.

LAN*

Local area network. A group of computers and other devices spread over a relatively limited area. They are connected by a communications link that enables any device to interact with any other device on the network. Compare with WAN.

LANE

LAN Emulation.

Language Group

The script families supported in Windows 2000 and later operating systems.

Language ID

A 16-bit value that identifies a language. A LangID consists of a primary language and a sub-language.

LAPM

Link Access Protocol, Modem.

latched interrupt

An interrupt that occurs at the transition from deasserted to asserted in the IRQ line.

latency*

The amount of time that is required to send a packet from one point to another.

layered driver

One of a collection of drivers that respond to the same IRPs. Layered driver describes the highest-level and lowest-level drivers in a chain of layered drivers. These layered drivers process the same IRPs and all intermediate drivers in the chain. See also class driver, filter driver, intermediate driver, and I/O stack location.

LBA*

Logical block address or logical block addressing. A unit of data that the host computer supplies or requests.

LBFO

Load balancing and fail-over.

LBN

Logical block number. LBN identifies a physical block on a disk. LBN uses a logical address rather than physical disk values (for cylinder, track, and sector) to perform this identification. For a disk with N blocks, the corresponding LBNs are numbered 0 through (N – 1). See also MCB and VBN.

LC

Linear control.

LCC**

Logical link control.

LCD*

Liquid crystal display.

LDAP*

Lightweight Directory Access Protocol. A network protocol designed to work on TCP/IP stacks to extract information from a hierarchical directory, for example, X.500. This gives users a single tool to scrutinize data to find a particular piece of information. This piece of information can include a user name, e-mail address, security certificate, or other contact information.

LDT

Lightning Data Transport.

lead byte

The byte value that is the first half of a double-byte character. See also double –byte character set.

LEC

LAN emulation clients.

LED*

Light-emitting diode.

legacy**

Any feature in the computer system that is based on older technology and for which newer technologies are available for that feature. See legacy device, legacy mode.

legacy device

Typically, a legacy device is:
1. A device that does not use PCI, USB, IEEE 1394, or later physical interconnect that is fully Plug and Play compliant.
2. A device that cannot be configured or managed using either ACPI mechanisms or Plug and Play methods to specify resource configurations.

legacy mode

Non-ACPI legacy mode is the operational mode in which ACPI is disabled in the system BIOS. In this mode, the interrupt router routes interrupts to the system management interrupt (SMI) instead of the system control interrupt (SCI). Power management, if supported, is provided through the APM 1.2 feature. Auto-configuration is supported through the ESCD, system device nodes, ISA PnP configuration registers, PCI configuration registers, or USB or IEEE 1394 enumeration and configuration mechanisms.

Legacy PCI devices or systems

A class of devices or systems that comply with PCI Local Bus Specification, Revision 2.1 or Revision 2.0. These kinds of devices and systems do not support deterministic configuration because they do not supply unique device identifiers.

level-sensitive interrupt

An interrupt that occurs when the signal is asserted in the IRQ line.

LFN

Long file name.

ligature

Two or more characters combined to represent a single typographical character. The modern Latin script uses a few. Other scripts use many ligatures that depend on font and style. Some languages possess mandatory ligatures, for example, Arabic. Other languages possess characters that were derived from ligatures. An example of this derivation is the German ligature of long and short "s" (ß), and the ampersand (&), which is the contracted form of the Latin word et.

line of business

1. OEM division that is dedicated to a particular business sector.

2. Application that is created to support specific business requirements in an enterprise.

little-endian**

Refers to memory architecture of a processor in which the byte layout is:

  • A word composed of bytes N and (N + 1).
  • A doubleword composed of bytes N, (N + 1), (N + 2), and (N + 3).
  • A K-byte memory entity composed of bytes N, (N + 1), . . . ,(N + K – 1).
  • The address of the preceding word, doubleword, or K-byte entity is its least significant byte, N.

Intel microprocessors always support little-endian addressing. For a little-endian configuration, the least significant bit of a 16-bit short value is the "rightmost" bit at byte N, while the most significant bit is the "leftmost" bit of byte (N + 1). See also big endian.

LM

Link Manager.

LME

Large Memory Enabled.

LMP

Link Manager Protocol.

load balancing**

Scales the performance of a server-based program. This scaling is performed through the distribution of its client requests across multiple servers within the cluster by using Windows Clustering. Each host can specify the load percentage that it will handle, or the load can be equally distributed across all the hosts. If a host fails, Windows Clustering dynamically redistributes the load among the remaining hosts.

load/stress test

Verifies the functionality of the implementation of a feature under system-load conditions that are stressful.

LOB

Line of business.

local bus

A system bus that is connected directly to the microprocessor on a system board. Informally, the term refers to system-board buses that are located closer to the microprocessor than ordinary expansion buses (that is, with less buffering).

locale

A collection of rules and data specific to a language and a geographic area. Locales include information on sorting rules, date and time formatting, numeric and monetary conventions, and character classification. Microsoft uses this term in combination with others to specify a subclass of these preferences.

Microsoft deals with four different areas pertaining to locales: System Locale, User Locale, Input Locale, User Interface (UI) Language.

Locale ID

LCID is a 32-bit value that identifies a locale. An LCID consist of a LangID and the ID of a sort key.

Localizability

The process of developing a program core with features and code design that do not assume a single locale or script.

Localization**

The customization or translation of the separated data and resources required for a specific region or language. L10N is a common abbreviation for Localization, where the L in Localization is followed by 10 letters and ends with the letter "N".

local memory

Random access memory that is directly associated with the graphics accelerator. Sometimes referred to as the "local frame buffer."

logical memory**

A correlation between physical memory of the computer system and an address range that is accessible to devices. HAL provides this correlation (or mapping). See also map.

logical order

The order of characters in text that corresponds to the order in which they are input (for example when writing by hand, or keying in text using a keyboard). Compare with Visual order.

long file name (LFN)**

LFN is any file name with a length that exceeds 8 characters in the file name and 3 characters in the file name extension. A long file name can also contain lowercase characters or other characters that are not valid in the 8.3 namespace.

lookaside list

A queue that the operating system manages. It is from this queue that entries of an established size can be allocated. Entries can be deallocated dynamically into this queue. Callers of the lookaside list routines of the Ex(ecutive) Support can use a lookaside list to manage any collection of established-size buffers that are sized dynamically. The lookaside list also manages structures with content that the caller determines. See the Windows DDK.

LORG

Large organization.

lossless compression**

Ensures that the original data can be recovered exactly, with no loss in image quality.

lossy compression**

The original data is not completely recoverable. Although image quality may suffer, many experts believe that up to 95 percent of the data in a typical image may be discarded without a noticeable loss in resolution.

LRU

Least-recently used. Algorithm for paging.

LPAR

Logical partitioning.

LPC

1. Low pin count.

2. Local procedure call. See also IPC and port object.

LPCM

Location PCM.

LPT*

Line printer.

LRU

Least-recently used.

LS120**

Laser storage 120 MB. This is a floppy drive that is ATAPI (ARMD-compliant), and high-density, that can read and write standard 1.44 megabyte floppy disks. It can also read and write proprietary 120-MB media.

LSA

Local Security Authority. An integral subsystem that is responsible for the management of security access tokens for users.

LSB*

Least significant bit.

LSI*

Large-scale integration.

LTR

Left to right. See reading order.

LU*

Logical unit.

LUID

Locally unique identifier. See SID, GUID.

luminance**

Describes the black-and-white component of a video signal. The amount of luminance contained in a video signal is directly related to the amount of light intensity. The amount of luminance is also related to brightness, which is one of the three image characteristics coded in composite television (represented by the letter Y). See also YUV.

LUN

Logical unit number.

LVD

Low Voltage Differential.

LVE

Live Video Extensions.

M

MAC**

1. Media Access Control.

2. Message Authentication Code.

MACL

Mandatory access control list. A part of the security descriptor for each object in a computer system with a B1 or higher security rating. The U.S. National Computer Security Center provides these ratings.

macro pixel

A group of the minimum numbers of pels that are required to define a minimum number of pixels. These pixels must be defined in such a way that these pels do not participate in the definition of any other pixels.

MADK

Microsoft ActiveX Development Kit.

map**

1. To translate a virtual address into a physical address or vice versa.

2. To translate an address that is relative to into a logical address. A device will use this logical address as if it were a physical address. See also HAL.

3. To alias an interrupt vector that is relative to a to an interrupt vector that is assigned by the operating system.

MAPI*

Messaging Application Programming Interface.

map register

An internal structure that HAL uses during DMA. HAL uses the structure to alias a logical page to a page of physical memory. See also DMA.

master clock

Controls the rate of reference time within a graph. Filters within the graph use the master to synchronize presentation times. The master clock provides a standard mechanism to query the reference time, physical clock time, and rate (compared to the system clock) of the owner of the master clock. The master clock also establishes event notifications based on position changes in the master clock’s reference time.

MB*

Megabyte.

MBONE*

Multicast backbone.

MBR**

1. Master Boot Record.

2. Multiple bit rate.

Mb/s

Megabits per second.

MC**

1. Momentary control.

2. Megacycle.

MCA

Micro Channel Architecture.

MCB

Map control block. An MCB is a structure that file systems use to map the VBNs for a file to the corresponding LBNs on the disk.

MCD

1. Miniclient driver. An OpenGL driver model in which the driver handles only those features that can be accelerated in hardware. MCD leverages the implementation of software to manage the rest of the pipeline.

2. Master Copy Distribution.

MCI*

Media Control Interface.

MCIS

Microsoft Commercial Internet System.

MCL

Microsoft Compatibility Labs.

MCNS

Multimedia Cable Network System.

MCSC

Microsoft Certified Support Center.

MCT

Modem Compatibility Test.

MD5

Message-digest has function. IP Security protocol uses this function.

MDCT

Modified Discrete Cosine Transform.

MDI*

Multiple-document interface.

MDK

Modem Developers Kit.

MDL

Memory descriptor list. In Windows NT, an opaque structure that Memory Manager defines. MDL uses an array of physical-page frame numbers to describe the pages that back a virtual memory range. See the Windows DDK.

Medium

The underlying method that a device connection uses to communicate. For example, IRPs communicate through IoCallDriver.

MEI

Matsushita Electronics Incorporated.

MEMS

MicroElectroMechanical Systems.

MESN

Media Event Status Notification.

metadata*

Information stored with a file that describes elements of the content, for example, the title, author, or copyright. A metafile contains the information.

method*

A routine that handles standard operations on every instance of the object type. Standard operations can include open, close, delete, parse, dump, and read or reset security attributes. An object type supplies a method.

method set

Windows 2000 and later operating systems use a method set to perform an action and to provide a way to access related actions. An example of an action is the allocation of memory. Each method set has a unique identifier that retrieves that method set and can be fulfilled either synchronously or asynchronously. A resource method set contains resource-specific methods for manipulating a type of resource by a kernel-mode client. It is used in resource allocation by enumerated devices on a bus.

MF

More fragments (bit).

MFC*

Microsoft Foundation Class library.

MFP*

Multi-function peripheral.

MFT

Master file table.

MHz*

Megahertz.

MI**

1. Management Interface.

2. Multiple inheritance.

MIB

Management Information Base.

Microsoft C#

An object-oriented programming language designed to exploit the power of XML-based Web services on the Microsoft .NET platform.

middleware*

Software that exists between two or more types of software and translates information between them. Middleware can cover a broad spectrum of software. Typically, it sits between an application and an operating system, a network operating system, or a database management system. Examples of middleware include network control programs.

MIDI*

Musical Instrument Digital Interface. A connection for computer control of musical instruments and devices. MIDI is an industry, hardware, and data standard for communicating between hardware. Most references involve only the data standard. The data stream is a byte stream that controls musical instruments and stores the output of such instruments.

MIMD*

Multiple instruction multiple data.

minidriver

A DLL that is hardware-specific. The minidriver uses a Microsoft-provided class driver to accomplish most actions through functions call and provides only device-specific controls. Under WDM, the minidriver uses the device object of the class driver to produce system calls.

miniport driver**

A kernel-mode driver that is specific to a device. A miniport driver is linked to a port driver that provides an interface between the port driver and the operating system. This is typically implemented as a dynamic-link library. See the Windows DDK.

MIP

Multimission Interactive Picture.

MIP-mapped textures

A texture map that filters and stores texture information at different spatial bandwidths. Each filtered image, or level, in the MIP map is a power of two smaller than the former level. Objects that appear to be close to the viewer use a high-resolution level. Objects that are farther away use lower-resolution levels.

MIPS*

Millions of instructions per second. MIPS is a common measure of processor speed.

mirror driver

An intermediate driver that maintains a duplicate of a disk partition. The intermediate driver is layered somewhere between a file system and a disk device driver. The fault-tolerant disk driver, Ftdisk, is a mirror driver.

MIS*

Management information system.

mixer class

The class of filters that deal with manipulating controls, for example, volume and treble.

MLAN

Music LAN.

MLD

MLD denotes a metric of similarity, called Mean Level Difference.

MMC**

1. Microsoft Management Console.

2. Multimedia Command Set

MMC2

Multimedia Command Set 2.

MMC3

Multimedia Command Set 3.

MMDS

Multichannel Multipoint Distribution System.

MME

Microsoft Mobile Explorer.

MMF

Micron multimode fiber.

MMHID

Multimedia Human Input Device.

MMIO

Memory-mapped I/O.

MMU*

Memory-management unit.

mode*

The state of a computer or a program that is in operation. For example, edit mode is the state in which a program accepts changes to a file.

modem*

Short for modulator/demodulator. A communications device that converts between digital data (from a computer or terminal) and analog audio signals. (These audio signals can pass through a standard telephone line.) International standards for modems are specified by the International Telecommunications Union, or ITU.

MOF

Managed Object Format.

monolithic driver

A driver that has many different classes of functionality contained in the same driver.

motherboard**

See system board.

mount**

Operation that requests a file system to render a volume useable by the I/O Manager.

MP@ML

Main Profile at Main Level.

MP3

MPEG 1, Layer 3. An audio compression technology.

MPAA

Motion Picture Association of America.

MPEG*

Moving Picture Expert Group. Refers to one of several standard video-compression schemes. MPEG is a codec that compresses full-screen, digital video into a small data stream.

MPIO

Multi-path I/O.

MPP**

1. Multimedia peripheral port.

2. Massively parallel processing.

3. Massively parallel processor.

MPPE

Microsoft Point-to-Point Encryption.

MPS

Multiprocessor Specification.

MPX

Multiplexed.

MRL

Memory Read Line.

MRM

Memory Read Multiple.

MRU

Most recently used.

ms*

Millisecond.

MSB*

Most significant bit.

MSC+

Mass Storage Class plus.

MSCDEX

Microsoft CD-ROM Extensions.

MSCS

Microsoft Cluster Service (MSCS) System is the clustering feature of Microsoft Windows NT Server 4.0 Enterprise Edition, Windows 2000 Advanced Server, Windows 2000 Datacenter Server, and later versions of these operating systems.

MSDE

Microsoft Data Exchange.

MSDL

Microsoft Download Library.

MSDN

Microsoft Developer Network.

MSDV

Microsoft Digital Video Infrastructure.

MSEN

Media Status Event Notification.

MSI

1. Message-signaled interrupts.

2. Medium-scale integration.

3. Microsoft Windows Installer.

eeMSMQ

Microsoft Message Queue Server.

MSP**

1. TAPI media service provider.

2. Message Security Protocol.

MSPI

SPI for MSPs.

MSR

Microsoft Research.

MSU

Memory storage unit.

Mt. Rainier

The Mt. Rainier Group is comprised of Philips, Microsoft, Compaq, Sony, and Adaptec. This group proposes an open industry standard to simplify use of CD-RW, increase compatibility and performance, and enable operating system support.

MTA

Multimedia terminal adapter.

MTD

Memory technology driver.

MTF

Microsoft tape format.

MTS

Microsoft Transaction Server.

MTU*

Maximum Transmission Unit.

MUD**

Master User Domain.

MUI

Multilingual user interface.

MultiByte Character Set (MBCS)

A mixed-width character set in which some characters consist of more than 1 byte. A double-byte character set (DBCS) is a specific type of multibyte character set.

multicast

A method of distributing content. Multicast uses multiple clients sharing a stream from a server.

Multicast Address Dynamic Client Allocation Protocol (MADCAP)

An extension to the DHCP protocol standard that supports dynamic assignment and configuration of IP multicast addresses on TCP/IP-based networks.

multifunction device

A piece of hardware that supports multiple discrete functions on a single adapter.

multimedia*

Refers to the delivery of information that combines different content formats. These formats can include motion video, audio, still images, graphics, animation, and text.

multimedia processing driver

See filters.

multiple bit rate (MBR) video

A feature of Windows Media Technologies that supports the creating and streaming of video streams that are multiple-encoded within one Windows Media stream.

multiprocessor system**

A computer platform with more than one CPU. Windows NT and later versions run on multiprocessor computers. These computers are configured to be homogeneous, closely coupled, and symmetric.

music class

The class of filters that work with music data, for example, ZIPI or MIDI.

mutex object

A type of dispatcher object that applies only to kernel mode. The Kernel defines a mutex object and provides deadlock-free access to a resource that is mutually exclusive. See the Windows DDK.

MUX*

Multiplexer.

MV

Motion vector.

MWI

Memory Write and Invalidate.

N

NABTS

North American Basic Teletext.

NAK*

Negative acknowledge.

NAS

Network attached storage.

NAT*

Network address translation.

National Language Support (NLS)

A set of system functions in Windows 9x that provides national language support. NLS is information based on language and cultural convention. See also Unicode.

native services

The set of built-in user-mode routines exported by the Windows executive for use only by protected subsystems.

NBDD

NetBIOS datagram distribution server.

NBNS

NetBIOS name server.

NC**

1. Network computer.

2. Naming context.

NCB

Network control block.

NCITS

National Committee for Information Technology Standards.

NCP

NetWare core protocol.

NCSC

National Computer Security Center.

NDA

Non-Disclosure Agreement.

NDIS*

Network Driver Interface Specification. The interface for network drivers used in Windows and Windows NT-based operating systems. NDIS provides a common mechanism by which any given transport driver that is NDIS-compatible can communicate with any network-adapter driver that is NDIS-compatible. NDIS provides for multiple transports to work over multiple network adapters because it supports multiplexing between transports and drivers.

NDS*

Novell NetWare Directory Services. A feature introduced in Novell Netware version 4.0. This feature provides access to directories that may be located on one or more servers.

.NET

Microsoft vision and road map for its next generation of software and services.

Net PC**

Network PC. An industry-defined, legacy specification for a Windows-based PC system that can boot through remote access to a server and user server-based resources for most computing actions.

NetBEUI

NetBIOS Enhanced User Interface.

NetBIOS

Network basic input output system.

NetBT

NetBIOS over TCP/IP.

NetX

NetWare 3.x client shell.

NFS*

Network File System.

NGWS

Next Generation Windows Services.

nibble mode

A channel that is asynchronous and serves as a channel from peripheral to host. Nibble mode is defined in the IEEE 1284-1944standard. Nibble mode provides a channel for the peripheral to send data to the host. This is a common method to identify the peripheral.

NIC**

Network interface card.

NICAM

Near-Instantaneous Companded Audio Multiplex.

NIDRR

National Institute for Disability and Rehabilitation Research.

NIS*

Network Information Service.

NIUF

National ISDN User’s Forum.

NLB

Network Load Balancing.

NLS**

See National Language Support.

NMI

See Nonmaskable Interrupt. An interrupt that cannot be overruled by another service request. A hardware interrupt is nonmaskable if the processor-interrupt flag cannot mask it.

NNTP*

Network News Transfer Protocol.

non-interlaced**

The method of scanning all lines on a display. The scan moves from top to bottom in sequential order at a specific rate per second. Computers typically use non-interlaced monitors. This differs from television, which uses an interlaced scanning method.

non-local memory

Main computer system memory that can be accessed by the core logic chipset to support AGP operations.

Nonmaskable Interrupt (NMI)**

An interrupt that cannot be overruled by another service request. A hardware interrupt is nonmaskable if the processor-interrupt flag cannot mask it.

non-paged pool

See pool memory.

non-spacing character

A character that has no meaning by itself, but overlaps a base character to modify it. Sometimes referred to as a "combining character". An example of the character is a diacritic.

NOS*

Network operating system.

NP

Network provider.

NPI

Network provider interface.

nrt

Non-real time.

ns

Nanosecond.

NSAP

Network Service Access Point.

NSP

Native signal processing.

NT-1*

Network Terminator 1.

NtDetect

See ARC.

NTFS**

A file system that is native to Windows NT and later versions of the operating system. NTFS supports file system and file-data recovery. It also supports storage media that is extremely large, file-granular compression, and various other features.

NTKERN

The Windows 98 version of the kernel component in Windows NT.

NTLM

Windows NT LAN Manager.

NTSC*

National Television System Committee of the Electronics Industries Association (EIA). The NTSC establishes standards for television and video in the United States. NTSC is the broadcast standard for the United States and Japan. See also PAL format, SECAM.

NTSC format

A color-television format that has: 525 scan lines, a field frequency of 60 Hz, a broadcast bandwidth of 4 MHz, a line frequency of 15.75 KHz, a frame frequency of 1/30 of a second, and a color subcarrier frequency of 3.58 MHz. See also PAL format and SECAM.

NTS/E

Windows NT Server, Enterprise Edition.

NUMA*

Non-Uniform Memory Access architecture.

NVRAM

Non-volatile RAM.

O

OAL

OEM Adaptation Layer.

OAM

Operation and maintenance.

OBEX

Object Exchange protocol.

object**

A single, runtime instance of object type that the operating system defines. Objects visible in user mode include process, thread, section, file, event, semaphore, key, timer, port, object directory, symbolic link, I/O completion port, and token objects. Many user-mode objects are implemented through the use of a corresponding kernel-mode object. See the Windows DDK.

object directory object

A type defined by the Object Manager. The object directory object implements object names that are hierarchical.

The file-system directories are implemented as file objects, not as object directory objects.

object type

An opaque data structure that defines a protected entity that is implemented and manipulated by the operating system. For example, the system service that reads a file operates on an open file object. See the Windows DDK. See also opaque.

OCR*

Optical character recognition.

OCX*

OLE custom control.

ODBC*

Open database connectivity.

ODI*

Open Datalink Interface.

ODSI

Open Directory Services Interface.

OEM*

Original equipment manufacturer. OEM is used in Microsoft documentation and web pages primarily to refer to PC system manufacturers.

OEMCP

Default OEM codepage of the operating system. The OEM codepage is the one used for conversions of text-mode applications that are MS-DOS-based.

OEX

OLE system control.

OFDM

Orthogonal Frequency Division Multiplexing.

OFS

Object File System.

OHCI

Open Host Controller Interface.

OID

Object ID.

OLE*

Object linking and embedding. OLE is a way to transfer and share information among applications. OLE is based on the COM programming model and binary standard.

OnNow

A design initiative that seeks to create all the components required for a comprehensive, system-wide approach to controlling system and device configuration and power management.

OO*

Object oriented.

OOB

Out-of-band channel.

OOBE

Out-of-box experience.

OOC

On-off control.

OOP*

Object-oriented programming. A programming paradigm in which a program is viewed as a collection of discrete objects. The objects are self-contained collections of data structures and routines that interact with other objects.

opaque

Pertains to any data structure, including an operating system-defined object. The data structure is defined with an internal structure that is intentionally hidden. It is known only to the executive component that defined the type. However, the defining component supplies operating system services and kernel-mode support routines to manipulate opaque objects. User-mode data types can also be opaque.

opcode*

Operation code.

OpenGL

Open Graphics Library. An API for 2-D and 3-D color-graphics programming. OpenGL is independent of operating systems and is an industry standard. It is typically used for engineering, visualization, simulation, and other graphics-intensive applications.

OpenHCI

Open Host Controller Interface.

OpenType*

A font format jointly developed by Microsoft and Adobe Systems, Inc. This format accommodates the addition of Type 1 (PostScript) font data to a TrueType font.

OpenType Layout

An extension to the OpenType format. OpenType Layout provides support for international and high-end typography.

OPK

OEM preinstallation kit.

option ROM

Read-only memory that is optional and located on an expansion card. Option ROMs usually contain additional firmware required to properly boot the peripheral that is connected to the expansion card. An example of such a peripheral is a hard drive. See also expansion ROM.

OR*

A logical operation for combining two bits or two Boolean values. If one or both values are true, it returns the values of true. Compare with XOR.

ORB*

Operation request broker.

OS*

Operating system.

OSC

One-shot control.

OSF*

Open Software Foundation.

*OSI

Open System Interface.

OSP

Online Service Provider.

OSPF*

Open Shortest Path First (interior gateway protocol).

OSPM

OS-directed power management.

OSR

OEM service release.

OSTA

Optical Storage Technology Association.

OT

Output terminal.

OTC

On-tape catalog.

OU

Organizational Unit.

Overlap

Overlap is a protocol that allows devices that require extended command time to perform a bus release. This allows the other devices on the bus to execute commands.

P

PAC

Privilege Attribute Certificate.

packed (format)

The grouping of pels near the lowest level of pixel aggregation possible. For example, 4:2:2 YVU data can be presented at Y0, U0, Y1, V0; or 4:1:1. YVU data can be presented as U0, Y0, V0, Y1, U1, Y2, V1, Y3, Y4, Y5, Y6, Y7. Other packed presentations are possible. They differ slightly in the grouping or order, but are similar in that they are presented by small aggregations of pixels.

packed-pixel frame buffer

A portion of the display memory that holds the contents of a single screen image. The screen bits are stored in a single plane and each pixel on the screen has a set of two or more corresponding bits that define the pixel color.

packet*

A bundle of data organized in a group for transmission. Packets typically contain three elements: control information, data to be transferred, and error detection and correction bits.

PAD*

Packet assemblers/disassemblers.

PAE

1. Physical Address Extensions.

2. Port Access Entity.

page frame**

A block of contiguous physical memory that stores the contents of a virtual page. The size of the virtual page and page frame are usually identical. However, the size of a page frame depends on the microprocessor.

paged pool

See pool memory.

paging file

An operating system file that contains the contents of virtual pages that have been paged out of memory. See also backing store and system paging file.

PAL format

Phase Alternation Line format. PAL format is the European video standard, except for France. See also NTSC and SECAM.

PAN

Personal Area Network.

PAP*

Password Authentication Protocol.

parent

A device, bus, function, or process at one level of a hierarchy. The parent controls the behavior of components below it in the hierarchy.

PBX*

Private Branch Exchange.

PC**

1. Personal computer.

2. Packet classifier.

PC 2001; PC 99

Design guidelines for PC systems and peripherals, co-authored by Intel Corporation and Microsoft Corporation in the PC 2001 and PC 99 Hardware Design Guides.

PCB*

Printed circuit board.

PC Card**

A trademark of PCMCIA. A removable device that plugs into a PCMCIA slot. Use the PC Card as a memory-related peripheral.

PCI**

Peripheral Component Interconnect. A high-performance bus that is 32-bit or 64-bit. It is designed to be used with devices that contain high-bandwidth requirements, for example, the display subsystem. It is an I/O bus that can be configured dynamically.

PCI PM

PCI Bus Power Management Specification.

PCIC

PC Card I/O cards.

PCI-X

An extension to PCI, designed to address the need for increased bandwidth of PCI devices.

PCM

See Pulse coded modulation.

PCMCIA*

Personal Computer Memory Card International Association. This term often refers to a controller for a type of expansion card that is described in the PCMCIA standards.

PCP

Printer Control Protocols.

PCR

1. Peak cell rate.

2. Processor control registers. An internal data structure in which the Windows kernel stores information according to individual processors.

PCS**

Personal Communications System.

PCT*

1. Private communication technology.

2. Program comprehension tool.

PDA*

Personal digital assistant.

PDC*

Primary domain controller.

PDEV

Physical display device.

PDK

Peripheral Developers Kit.

PDL*

Page Description Language.

PDO**

Physical device object. A device object that the bus driver creates using IoCreateDevice. A PDO represents the underlying bus driver in the stack of PnP drivers for a device. The PDO is at the bottom of the device stack of drivers for a device.

PDU

Protocol data unit.

PE

Portable EXE.

PEB

Process environment block.

pel (pixel element)**

In a color space with multiple elements per pixel, pel indicates a datum that is a constituent value of one or more pixels.

performance test

A performance test measures the throughput or processing-completion time of a feature implementation.

perspective correction

A process that correctly alters textured triangles in a scene. This lends the impression that the vertices of the triangle are at different distances from the viewer. Specifically, the triangle has perspective.

PFN

1. Page frame number.

2. The database in which the Memory Manager maintains information about every physical page in the operating system. Each PFN is an index for a physical page in the array of records that comprises the PFN database. See also PTE.

PHY

Physical layer device.

PIC*

Programmable interrupt controller.

PID

1. Product ID.

2. Program ID.

PIL

Integrated PHY and Link.

PIL-FOP

Integrated PHY and link, Fan-out PHY (defined in the IEEE 1394 specification).

PIM*

Personal information manager.

PIMA

Photographic and Imaging Manufacturers Association.

pin**

A set of filter-defined properties in kernel streaming and DirectShow that specify a connection endpoint. For example, on a filter, a pin can describe audio input.

pin factory

A collection of properties that describe a potential connection point to a filter. A pin factory generates pin instances of that category. Each pin factory has an identifier that is filter unique. It allows support of pin-specific properties or data formats. This is a zero-based count by which the pin factory can be identified. The count stays constant between the creation of pin instances.

pin instance

An instance that a pin factory creates. It represents one end of a connection point between filters. A pin instance represents the embodiment of a connection through a particular data format and communications methodology. Used for control and data flow. Pin instances support, at minimum, a connection property set.

PIO*

See Programmed I/O.

PIP

Picture-in-picture.

pipe**

A logical abstraction that represents the association between an endpoint on a device and software on the host.

PIT

Programmable interrupt timer.

PITL

Priority issue tracking list.

pixel**

Pixel element. The required information that specifies the appearance of the minimum subset of an image. Portions of this information may apply to more than one pixel.

pixel drops

The unavailability of a pixel. The unavailability can be the absence of any pel. When pixel drops occur, packed formats typically lose all pels for the affected pixels. But planar formats typically lose individual pels. This is readily apparent upon consideration of their grouping.

pixel format

The color depth of an image, usually measured in RGB or YUV.

PK

Public Key.

PKCS

Public-Key Cryptography Standards.

PKI

Public Key Infrastructure.

PKT

Partition Knowledge Table.

plain text**

A string of text to be displayed with one value for each text attribute, specifically, one typeface, one slant, and one weight. Contrast with Formatted text.

planar**

See system board.

planar format

When pels are grouped by color space basis vector, the format is planar. For example, 4:2:2 YVU data can be provided with Y pels grouped together, U pels grouped together, and V pels grouped together.

platform**

A platform is the motherboard with add-in hardware, the BIOS, and the low-level drivers. These components comprise a PC product. Low-level drivers include WDM class and minidrivers.

player

A client program or control that receives multimedia content that is streamed from a server or played from local files. Windows Media Player is an example of a player.

playlist

A list of links to various digital media files on a computer, a network, or the Internet.

PLD*

Programmable logic device.

PLDA

Private Loop Direct Attach.

PLL

Phase lock loop.

Plug and Play**

A set of specifications together with firmware and operating system capability to automatically configure a computer system and its peripheral devices. Plug and Play also specifies a set of device driver interfaces for device drivers. See also PnP.

Plug and Play BIOS

A BIOS used on non-ACPI PCs running Windows 95/98. The Plug and Play BIOS configures adapters and system-board devices during computer-system power up. The BIOS also provides runtime-configuration services for system-board devices after startup. See also ACPI.

Plug and Play Compliance

A device, operating system, or BIOS is in Plug and Play compliance when it meets all Plug and Play requirements stated in the current Windows Logo Program requirements.

PMD

Physical Media Dependent.

PME or PME#

Power management event.

PnP**

The Plug and Play Manager component in Windows 2000 and later operating system.

PO

Power management component in kernel.

POF

Plastic Optical Fiber.

polling**

A technique used in device drivers to ask multiple devices whether they contain data to transmit. The devices are polled one at a time.

PON

Passive Optical Network.

pool memory

Regions located in kernel space from which memory blocks can be allocated and deallocated dynamically. Some other systems call this "heap memory." The Memory Manager creates two kinds of pools for the operating system and drivers to use: paged pool and nonpaged pool. See the Windows DDK.

POP**

1. Point-of-presence.

2. Post Office Protocol.

port**

A connection or socket that connects a device to the computer. These devices include a printer, monitor, or modem. The computer sends information to the device through a cable.

port driver

A low-level driver that responds to a set of device-control requests that the operating system defines. This same driver can possibly respond to an additional set of device-control requests sent down by a corresponding class driver. This additional set of device-control requests is private and defined by the driver. A port driver insulates class drivers from the specifics of host bus adapters and synchronizes operations for all its class drivers.

port object

An instance of an object type that represents a conduit for messages between local processes. The LPC model uses a port object as an object that is accessible to user-mode processes through operating system services. The server process defines a connection-port object that is named. The server establishes two communication-port objects that are not named when a client process connects to the named port.

port replicator**

A docking-station substitute intended to provide convenient, one-step connection to multiple desktop devices. This is a low-cost substitute, too.

POSIX

Portable Operating System Interface for Unix. In Windows NT and later versions, a protected subsystem that supports the POSIX standard.

POST

Power On Self Test. A procedure of the system BIOS that identifies, tests, and configures the PC in preparation to load the operating system.

POTS

Plain Old (analog) Telephone Service/system.

power management**

Mechanisms in software and hardware that minimize system-power consumption, manage computer system thermal limits, and maximize system battery life. In Windows, power management is an interface that PnP provides to manipulate the power state on a hardware device.

powered off

The removal of power from the computer, either by a physical switch or through operating system software. This is the S5 (off) sleep state that is defined in the ACPI specification.

powered on

The application of electrical power to the computer through of the physical power switch.

power policy

For power management, the decisions that determine how to save energy and when to sleep. These decisions are based on end-user preferences, application requirements, and system-hardware capabilities.

power resources

Resources including power planes and clock sources that a device requires to operate in a specific power state.

power state

One of a set of discrete operating levels for a computer system or device. This is characterized by its power consumption, available functionality, hardware latency, and ability to wake.

P/PC

Pocket PC.

PPDT

Peer-to-Peer Data Transport.

PPF

Personal Preference File.

PPP*

Point-to-Point Protocol.

PPPoE

PPP over Ethernet.

PPTP*

Point-to-Point Tunneling Protocol.

PRCB

Processor Control Block. An extension of the PCR.

Precomposed character

A single character that represents a sequence of characters. Typically a precomposed character is a combination of a base character and one or more diacritics.

PRI

Primary Rate Interface.

priority**

An attribute of a thread that determines when and how often the thread is scheduled to run. The priority for a running thread falls into either of two classes, variable priority or real-time priority. Each class has sixteen levels. See the Windows DDK.

priority boosts

A set of constant values defined by the operating system. These boosts are supplied when drivers complete an IRP. For example, drivers for interactive devices usually call IoCompleteRequest with a priority boost value that is device-type-specific.

Private Use Area

PUA is the area in Unicode from U+E000 through U+F8EE. This area is reserved for vendor-specific or user-designated characters.

probe

To check whether a memory access to a data entity is allowed without causing an access violation.

process object

A control object type that is kernel defined. It represents the virtual address space and control information necessary for the execution of a set of thread objects.

program guide

The on-screen user interface that allows users to select, manage, and search television programs and other content-viewing options.

programmed I/O (PIO)

A technique that transfers data between a device and computer system memory using system-space virtual addresses that are remapped, rather than using DMA.

property set

In Windows NT and later versions of the operating system that support WDM, a method defined to establish and retrieve properties on a driver. Each property set has a unique identifier, which represents types of related information and which is used to access the property set.

protected subsystem

A service that runs in user mode and appears to perform operating system functions by calling system services. The service performs these functions for its native applications and subsystem-specific drivers. Its interface to end-users emulates another operating system, including Windows or POSIX, on top of the kernel. See also integral subsystem.

protocol

A collection of rules or standards designed to enable computers to connect with or communicate with one another. A protocol allows the computers to exchange information with as little error as possible.

PS

Packet scheduler.

PS/2

Personal System/2.

PSS

Product Support Services.

PSTN

Public Switched Telephone Network.

PTE

Page table entry. The Memory Manager uses a PTE to represent the state of a virtual page.

PTH

Plated-through-hole.

PTP

Picture Transfer Protocol.

PTT

Post, Telephone, and Telegraph.

pulse**

To configure an event to the Signaled state. Also to satisfy as many contingencies on the event as possible and to reconfigure the event to the Not-Signaled state.

pulse coded modulation (PCM)**

1. A method of encoding information in a signal by varying the amplitude of pulses. PCM is the most common method of encoding an analog signal into a digital bit stream.

2. A subclass of the Microsoft waveform (WAV) file format. In PCM, linear samples store data for WAV files. In contrast, ADPCM records deltas between samples.

push technology**

In client/server applications, to send data to a client without a client request. An example of push technology is sending e-mail. In contrast, the World Wide Web is based on pull technology. In pull technology, the client browser must request a web page before it is sent. Broadcast media are push technologies because they send information regardless of whether anyone is tuned in.

PVC*

Permanent virtual circuit.

PVR

Personal Video Recorder.

PWC

Progressive Wavelet Codec.

Px64

A draft standard for motion video compression in videophone and teleconferencing applications. It is designed for 64-Kbps transmission channels. Also called CCITT Recommendation H.261.

PXB

PCI bridge.

PXE

Preboot Execution Environment.

Q

QAM*

Quadrature amplitude modulation.

QFE

quick-fix engineering (or quickly corrected engineering).

QIC

Quarter-Inch Cartridge Drive Standards, Inc. An international trade association dedicated to promoting use of quarter-inch tape technology and products.

QoS

Quality of Service.

quantum**

A brief period of time when a given thread executes in a multitasking operating system. It performs the multitasking before it is rescheduled against other threads with the same priority. Previously known as a "time slice."

quota

A limit for individual processes on the use of system resources. Under Windows NT and later versions, a quota establishes limits on the system resources that can be used by the threads of the process. This includes quotas for paging-file, paged-pool, and nonpaged-pool usage.

R

RADIUS*

Remote Authentication Dial-In User Service.

RADSL (RA-ADSL)*

Rate adaptive asymmetric digital subscriber line.

RAID*

Redundant array of independent disks.

raised IRQL

Any hardware priority that the operating system assigns where kernel-mode code runs. This priority must be greater than IRQL PASSIVE_LEVEL. See also IRQL.

RAM*

Random access memory. Semiconductor-based memory that can be read and written by the microprocessor or other hardware devices.

RAMDAC*

RAM digital-to-analog converter. A chip built into some VGA and SVGA display adapters. This chip translates the digital representation of a pixel into the analog information that the monitor requires to display it.

range**

A finite and discrete sequence of values. A set of discontiguous physical pages or a file stored in discontiguous sectors on disk can back a virtual address range.

RAPI

Remote API.

RAS**

1. Remote Access Service.

2. Remote access server.

3. Reliability, Availability, Serviceability.

raster*

A rectangular pattern of lines.

raster graphics*

Also bitmapped graphics. Images defined as a set of pixels or dots in a column-and-row format.

rasterization*

The conversion of vector graphics to equivalent images composed of pixel patterns. These patterns can be stored and manipulated as sets of bits.

RASUM

Reliability, Availability, Scalability/Serviceability, Usability, Manageability.

RAW

An FSD supplied by the operating system that is the final opportunity for all I/O requests requiring file-system support. When the I/O Manager calls active file systems to mount a volume, RAW is always called last. This is because it recognizes all disk and tape media. RAW is not an acronym.

raw mode**

The mode of operation in which a device-driver stack does not include a function driver. The bus driver primarily controls a device running in raw mode. Upper-level, lower-level, and bus filter drivers or any combination of these might be included in the driver stack.

RBC

reduced block commands.

RDMA

Remote DMA.

RDN

Relative Distinguished Names.

RDR

See Redirector.

reading order

The overall direction of a sequence of text. Words in a specific script always flow in the direction associated with that script. For example, you read LTR for Latin and RTL for Hebrew.

real time

Refers to an operating mode under which data is received and processed. The results are returned instantaneously.

real-time processing

Processing that supports real-time functions, for example, telephony.

Red Book audio

The data format standard for conventional audio CDs that home stereo systems use.

redirector (RDR)**

A network file-system driver supplied by the operating system that provides access to files on remote machines.

reference**

In testing for the Windows Logo Program for hardware, "reference" refers to a logoed device or computer system used as a control device or system. A reference tests another device that is acquiring a logo.

refresh rate*

The frequency at which data on the screen is redrawn. Faster refreshing results in less apparent screen flickering, but increases the utilization of the frame buffer.

region**

A range of virtual addresses. When a user-mode caller creates a section or maps a view, it must specify a region. The Memory Manager rounds down the starting address of the specified region to the nearest 64K boundary. The Memory Manager rounds up its size in bytes to the boundary of the size of the next host page.

registry**

A database containing configuration and control data for the operating system. This information includes which file systems and drivers to load at computer system boot. The Configuration Manager exports system services to manipulate registry key objects that are contained in the database. See also key object.

REJ

Rapid economic justification.

release delta

The time between the release of the domestic product and the release of the localized edition.

resolution**

Number of pixels per unit of area. A display with a finer grid contains more pixels. Therefore, the display has a higher resolution and is capable of reproducing greater detail in an image.

resource**

1. A general term that refers to IRQ signals, DMA channels, I/O port addresses, and memory addresses for Plug and Play.

2. An entity that is visible to one or more processes. These entities can include a device object, file object, section object, variable, structure, or buffer. See the Windows DDK.

resource arbitrator

In Plug and Play device configuration, the Configuration Manager uses a set of functions to arbitrate and allocate resources on the PC.

resource conflict

In Plug and Play device configuration, the condition that occurs if more than one device attempts to use a resource that cannot be shared. Conflicts can cause the device to be partially functional or nonfunctional. Conflicts can also cause the PC to malfunction completely.

resource data type function

A function that describes the resource requirements of an ISA expansion card. The function also describes the programmability available on the card and its interdependencies.

resource descriptor

An entry in a resource requirements list. This list specifies a range of hardware resources that a device instance can use. The list also specifies an entry in a resource list that specifies a hardware resource that has been assigned to a device instance.

RF*

Radio frequency.

RFC*

Request for Comments.

RFC1483

Internet Request for Comments 1483. This is a standard for multi-protocol encapsulation over ATM networks

RFP

Request for Proposals.

RGB*

red-green-blue.

1. The primary colors in color video. RGB often describes a video scheme for recording color and the equipment that uses it.

2. A computer color-display output signal comprised of separately controllable red, green, and blue signals. Compare this with composite video, in which signals are combined prior to output. RGB monitors typically offer higher resolution than composite monitors. Compare with CMYK.

RID

Relative ID.

RIM Blackberry device

Hardware that supports a mobile e-mail solution on a Mobitex network.

RIP**

1. Routing Information Protocol.

2. Raster image processor.

RIPL

Remote Initial Program Load.

RIS

Remote Installation Server.

RISC*

Reduced Instruction Set Computing.

RLE*

Run-length encoding. A data-compression technique in which successive bytes of identical data are converted into a 2-byte pair. The pair consists of the repeated data byte and the repeat count.

RM

Resource management.

RMS

Root-mean-square.

RNA

Remote network access.

RNDIS

Remote NDIS.

ROM*

Read-only memory.

root hub

A USB hub directly connected to the host controller.

router**

A device that connects two or more networks. It also carries data forward. A router determines the location of the destination computer. It then finds the best way to transmit the data there.

RP

Recommended practice.

RPC*

Remote procedure call. A call from a thread of one process (the client) to a thread of another process (the server). The thread that is being called (the server) exists in a different address space, usually on another networked machine. See also IPC.

RR

Review Request.

RSA

Public-key cipher for encryption/decryption.

RSDT

Root System Description Table contains a list of pointers to other tables and identifies the computer system.

RSM

Removable Storage Manager.

RSOP

Resultant Set of Policies (WMI).

RSSI

Received Signal Strength Indication.

RSVP*

Resource Reservation Setup Protocol.

RSX

Intel Realistic Sound eXperience.

rt

Real time.

RTC

Real-time clock.

RTL

Right-To-Left. The directions characters are displayed in Middle Eastern languages like Arabic, Hebrew, Farsi and Urdu.

Rtl routines

There are two general sets of (C) Runtime Library routines that the operating system supplies. Both user mode and kernel mode are supplied one set each. All kernel-mode drivers can call the kernel-mode RtlXxx.

RTOS

Real-time operating system.

RTP*

1. Real-time transport protocol.

2. Real-Time Protocol.

RTS*

Request to Send.

run**

1. To execute on a processor.

2. Within an MCB, a contiguous range of VBNs that are mapped to a contiguous range of LBNs.

runtime priority inversion

A condition that occurs when threads with mismatched priority attributes share resources. The condition can also occur when a higher priority thread waits for a lower priority thread to complete some action. See the Windows DDK.

RWS

Remote Winsock.

RX

Receiver.

S

SAC

1. Secure, Authenticated Channel.

2. Secure Admin Console.

SACL

System access control list. A part of the security descriptor for an object. It maintains auditing information according to individual objects. See also security descriptor, ACE, ACL.

SAF

Support Automation Framework.

SAK

Server Appliance Kit.

SAM

Security Accounts Manager. An integral subsystem that maintains a database of information on user accounts.

SAMI

Synchronized Accessible Media Interchange.

sampling**

The first step in the process of converting an analog signal into a digital representation. This is accomplished by measuring the value of the analog signal at regular intervals. The intervals are called samples. These values are then encoded to provide a digital representation of the analog signal.

SAN**

1. Storage area network.

2. System area network.

SAP

1. Service Advertising Protocol.

2. Secure Audio Path.

SAR

Segmentation and re-assembly.

saturation**

The extremes of operating range. The output is constant, regardless of changes in input.

SBCS

Single-byte Character Set. A character encoding in which each character is represented by 1 byte. Single-byte character sets are mathematically limited to 256 characters.

SBP

1. Serial Bus Protocol.

2. Serial Block Protocol.

SBS

1. Small Business Server.

2. Smart Battery System.

SBS-IF

Smart Battery System Implementer's forum.

SBSM

SBS Manager.

scalability

The ability of an operating system to use multiple processors and to vary the information content of a program by changing the amount of data that is stored, transmitted, or displayed. In a video image, this translates to the creation of larger or smaller windows of video on screen (shrinking effect).

scaling*

Process of uniformly changing the size of characters or graphics.

SCAM

SCSI Configured Automatically.

scene geometry

A collection of polygon data that composes a 3-D image.

SCI

System control interrupt. Hardware uses a system interrupt to notify the operating system of ACPI events. The SCI is a low-level interrupt that is active and shareable.

SCID

Service channel ID.

SCL

System clock line.

SCP

Simple Control Protocol.

SCPD

Service Control Protocol Definition.

Script**

A collection of characters for displaying written text, all of which possess a common characteristic that justifies their consideration as a distinct set. One script may be used for several different languages. Some written languages require multiple scripts In this context, script has nothing to do with programming scripts such as Perl or VB Script.

SCSI**

Small computer system interface (pronounced "scuzzy"). An I/O bus based on the ANSI SCSI-II standard, designed as a method for connecting several classes of peripherals to a host system. This design does not require modifications to generic hardware and software.

ScsiPort routines

An interface to miniport drivers that are HBA-specific. The SCSI port driver that the operating system supplies exports these drivers. SCSI miniport drivers call these routines to obtain all operating system-specific support. The routines require this operating system support to perform I/O operations. Drivers of mass-storage devices that are non-SCSI also can use this interface. Non-SCSI device drivers are implemented as a pseudo-SCSI miniport.

SCT

Software Compatibility Test.

SD

1. Service Discovery.

2. Secure Digital.

SDDB

Service Discovery Database.

SDDV

Standard Definition Digital Video.

SDE

Software development engineers.

SDK*

Software development kit.

SDMI*

Secure Digital Music Initiative.

SDP

Session Description Protocol.

SDRAM*

Synchronous DRAM.

SDU

Service data unit.

SE

Single-ended.

sealed case

A computer system design that does not provide internal expansion slots that are accessible to the end user. A sealed case can provide external expansion capabilities.

SECAM

Sequential Couleur a Memoire (Sequential Color with Memory). The television standard for France, Russia, and most of Eastern Europe. As with PAL, SECAM is based on a 50-Hz power system. However, SECAM uses a different encoding process and displays 819 horizontal lines per frame at a scan rate of 25 frames per second (50 fields per second). See also NTSC and PAL format.

section object

A user-mode object type that represents a memory entity. This entity can be mapped onto a range of virtual addresses in the address space of a process.

Secure Digital Music Initiative (SDMI)*

SDMI is an organization that establishes standards for secure digital music. One of the primary goals of SDMI is to create a framework for the secure distribution of music from the Internet to personal computers and portable devices.

security descriptor

A data structure that holds security information according to individual objects. This includes the object's owner, group, protection attributes, and audit information. See also ACE, ACL, SACL, SID.

security violation

An attempt to access an object without having the correct, granted access rights for the requested operation. See also ACE, ACL.

SEH

Structured exception handling. A feature of the Windows NT and later versions operating system, which support control transfers to exception handlers when certain runtime exceptions occur.

semaphore object

A user-mode semaphore moderates access to resources. This allows some maximum number of threads to access the resources protected by the semaphore. The number of threads is specified when the semaphore object is created.

separators

Symbols that separate items in a list, mark the thousands place in numbers, or represent the decimal point. Different locales follow different conventions for separators.

sequencer

Hardware or software functionality that interprets a music data stream that is time-stamped and sends packets to music hardware at the appropriate time.

server**

1. A process with one or more threads that accept requests from client processes. See also client/server model.

2. Any file system driver that provides remote access to files, named pipes, communication devices, or print devices, or any combination of these.

server system

In testing for the Windows Logo Program for hardware, "server system" refers to a computer that runs the specific Windows operating system for which the test device is acquiring a logo. See also reference device.

SES

1. Storage enclosure services.

2. Solution Exchange Standard.

Session Manager

An integral subsystem that starts and keeps track of logon sessions. The Session Manager also serves as an intermediary between protected subsystems.

SETP

Secure Electronic Transactions Process.

setup*

The software routine that installs the files and configuration settings for an operating system or application. The process allows a software program to run on a computer.

Setup Class

A group of devices that are set up and configured in the same way. For example, the same class installer installs the drivers for all the devices in a specific setup class.

Microsoft defines common setup classes. IHVs and OEMs can define additional setup classes.

Setup GUID

A GUID that identifies a setup class.

SFA

Sales force automation.

SFD

SCSI filter driver. An add-on driver that is layered above an existing SCSI class driver. An SFD intercepts requests for a particular device that is a SCSI peripheral device. The SFD has special features that are not shared by other SCSI devices of its class. Or the SFD does not accept standard SCSI-II CDBs to establish requests that are device specific.

SFF

Small Form Factor.

SFM

Services for Macintosh (in earlier versions of Windows NT operating systems).

SFP

System File Protection.

SFS

Shared file system.

SHA*

Secure Hash Algorithm.

SID

1. Subsystem ID.

2. Security identifier. A value that is unique across time and space. An SID identifies a process in the Security system. SIDs can identify an individual process that usually contains the logon identifier of a user. Or an SID can identify a group of processes.

SIG*

Special interest group.

signable

The ability of digitally signing a test device driver.

signaled

One of two possible states for kernel-defined dispatcher objects. Dispatcher objects support synchronization. When the kernel configures a dispatcher object to the Signaled state, any threads waiting on the object are released from their wait. After they are released, they become eligible for execution.

SIGNC

Special Internet Group Name Cache.

SIMD*

Single-instruction, multiple-data.

Sim-ship

Simultaneous ship. The release of localized editions of a product at the same time or soon after the domestic edition is released, usually within 30 days.

single-byte coding scheme

A character-encoding scheme, for example, ASCII, which uses a byte to represent each character. See also Unicode.

sink**

In terms of device stacking in DirectShow, sink indicates that a pin represents possible connections that are attached to, rather than those that attach. Compare with source.

SIP**

Sound input peripheral.

SIR*

Serial Infrared.

SIT

Special Information Tone.

Slant

The obliqueness or tilt of the glyphs in a font. The most common slants are "regular" and "italic."

SLDRAM

Synchronous link DRAM.

Sleep State

A computer system or device state other than the System Working State (S0) or Device Working State (D0).

SLI

Scan Line Interleave.

SLIP*

Serial Line Internet Protocol.

SMART**

Self-monitoring, analysis, and reporting technology.

smart card**

A small electronic device about the size of a credit card that contains an embedded integrated circuit. Smart cards are used for a variety of purposes such as storing medical records, storing digital cash, and generating network IDs.

smart phone

Wireless mobile device combining platform software, browser, modem chipset, and telephone handset.

SMB

Server message block.

SMBIOS

System management BIOS.

SMBus

System Management Bus. A two-wire interface based on the I²C protocol. The SMBus is a low-speed bus that provides positive addressing for devices and bus arbitration.

SMBus interface

ACPI defines a standard hardware and software communications interface between an operating system bus driver and an SMBus controller. The SMBus controller uses an embedded controller.

SMI

System management interrupt.

SMP*

Symmetric multiprocessing.

SMP machine

Symmetric multiprocessor machine. See multiprocessor machine.

SMPTE timecode

An 80-bit standardized edit time code adopted by the Society of Motion Picture and Television Engineers. See also timecode.

SMS**

1. Microsoft Systems Management Server.
2. Short messaging service.

SMT*

Surface-mount technology.

SMTP*

Simple Mail Transfer Protocol.

SNA*

Systems Network Architecture.

snapshot**

An image in time of the current data on a logical volume.

SNIA

Storage Network Industry Association.

SNMP*

Simple Network Management Protocol.

SNR

signal-to-noise ratio (also S/N).

SOAP

Simple Object Access Protocol. An RPC mechanism based on XML that sends commands and receives values over HTTP.

SO/CO

Service Office/Central Office.

Socket Services

In Windows 9x, a protected-mode VxD that manages PC Card hardware. Provides a protected-mode PCMCIA Socket Services 2.x interface for use by Card Services. A socket-services driver must be implemented for each separate PC Card controller on the computer system.

software device

A filter in kernel streaming and DirectShow that has no underlying hardware associated with it.

software modem

Performs signal processing on the host CPU and implements the controller using V.42bis. The modem hardware consists of a telephone-line interface. The hardware also consists of conversion circuitry that is digital-to-analog and analog-to-digital. The hardware does not contain a DSP or a microcontroller. Compare with controllerless modem.

SOHO*

Small Office/Home Office.

SORG

Small Organization.

Sound Blaster*

Hardware produced by Creative Labs, Inc. that represents a fundamental hardware interface for both audio and music (specifically MIDI) data. It is an important interface for MS-DOS–based games.

source**

In terms of device stacking in kernel streaming or DirectShow, source indicates that a pin represents possible connections that attach, rather than those that are attached to. Compare with sink.

SP

1. Service pack. For example, Windows 2000 SP1.

2. Service provider.

S/PDIF

Sony/Phillips Digital Interface Format. A standard for digital connection of consumer audio devices.

special pool

A part of the non-paged memory pool. When Driver Verifier is active and the Special Memory Pool option is selected, the special pool allocates certain memory requests. This allows Driver Verifier to monitor the memory usage of the driver for overruns and underruns. See also pool memory, Driver Verifier.

specular highlighting

A highlight or reflection observed on any shiny surface. Specular reflection creates highlighting on shiny surfaces. Normal reflection is diffused reflection. Specular reflection inclines towards the color of the light source, rather than the normal reflected color of the object.

SPI

Service Provider Interface. SPI is a component in Microsoft networking, TAPI, and other communications technologies.

SPID

Service profile identifier.

spin down

A power-management ability in which a hard drive shuts down its spindle motor.

spin lock

A spin lock is a synchronization mechanism that is low-level and defined by the kernel. A driver can use a spin lock to synchronize access to a shared resource, particularly in a multiprocessor machine. Any other kernel-mode component that runs at raised IRQL can use spin lock, too.

splitterless

1. A network that supplies signals to outputs. These outputs are individually matched and isolated from each other.

2. A cable TV device that is coaxial.

SPX**

Sequenced Packet Exchange.

SQL*

Structured Query Language.

SRAM*

Static RAM.

SRB

1. Stream request blocks.

2. SCSI request block. An operating system-defined structure that delivers I/O requests from a SCSI class driver to the SCSI port driver.

SRC

1. Sample rate converter.

2. Seamless rate change.

sRGB:

Standard RGB is a standard colorspace that integrates base-average-monitor gammas that are installed and whitepoint standard values from broadcast studio recommendation ITU 709.

SSA*

Serial Storage Architecture.

SSDP

Simple Service Discovery Protocol.

SSE*

Streaming SIMD Extensions. SSE denotes a metric of similarity, which is called Sum of Squared Errors.

SSI**

1. Single system image.

2. Small-scale integration.

SSIMD

Symmetrical SIMD.

SSL*

Secure Sockets Layer.

SSO

Single Sign On.

SSPI

Security Support Provider Interface.

stack**

1. A region of reserved memory in which programs store status data. This data can include procedure and function call addresses, passed parameters, and local variables.

2. In driver architecture, a chain of attached device objects that represent the drivers for a device. For PnP devices, the device object at the bottom of the device stack is the physical device object (PDO). This PDO was created by the underlying bus driver.

startup**

1. To start or reset a computer. To perform a startup, you can turn on the power, press a reset button on the computer case, or issue a software command to restart. Also called reboot, bootstrap, boot up.

2. To execute the bootstrap loader program.

static resources

Device resources that cannot be configured or relocated. These device resources can include IRQ signals, DMA channels, I/O port addresses, and memory addresses.

static VxD

A VxD that is loaded statically during Windows 9x operating system startup.

STB

Set-top box.

stepping

Stepping refers to versions of processors. Lower steppings come before higher steppings. Each stepping has a set of errata and remedies associated with it.

STI

See Still Imaging Architecture.

Still Image Architecture (STI)

A WDM architecture for still-image devices under Windows 98 and Windows 2000. A still-image minidriver provides support for still-image devices. These devices can include scanners and cameras under the WDM Still Image architecture. See also Windows Image Acquisition.

Still Image plug-in

A module that manages the translation of standard DDI calls to device-specific sequences. This supports vendor-specific device features. The plug-in is limited to Still Image class architecture.

STLP

Secure Transport Layer Protocol.

stream**

An object representing an entity on an adapter. The stream can receive, process, or supply data. A stream is identical to a WDM Stream architecture pin.

streaming**

A method of delivering content, The content located on a server is transmitted across a network in a continuous flow. The client software can then use it. By streaming data, the player can begin rendering the content immediately instead of waiting for an entire file to be downloaded.

stream file object

A virtual file that represents on-disk data that is associated with a file. Some of the data might not be part of the physical file that backs a file object. See also volume file.

stripe driver

An intermediate driver. A stripe driver improves performance for file accesses in comparison to the underlying disk driver. A stripe driver is layered somewhere between the FSD and a disk device driver. It distributes pieces of each file over a set of partitions concurrently. Therefore, it reduces the time for synchronous read/write operations.

STS/EN

Status and Enable bits (ACPI).

STT*

Secure Transaction Technology.

SU

Selector unit.

Subclass ID

Part of a device’s Plug and Play identifier that identifies the subclass of the device within its device class. For example, within the mass storage device class, USB defines the subclasses mass storage (which includes floppy disk drives, hard disk drives, and so on), CDROM, and Tape.

subject

The combination of a security token and an associated program that uses operating system services.

supervisor mode

See kernel mode.

SVC*

Switched virtual circuit.

SVD

Simultaneous voice/data. A technology used in TAPI-based modem technology.

SVGA*

Super VGA.

SVID

Subsystem Vendor ID.

S-Video

Also Y/C video. A video signal that separates the luminance and color (Y and C) components of the signal. This improves the quality over composite video. S-Video is the type of video signal used in the Hi8 and S-VHS videotape formats. It transmits luminance and color portions separately, using multiple wires. It therefore avoids the NTSC encoding process and its loss of picture quality.

SW RAID

In Windows NT Server and later versions, the use of the Ftdisk driver with "dynamic disks" to combine several physical disks and create one logical fault-tolerant (FT) volume.

syllabary

A set of written characters in which each character represents a syllable, for example, a consonant sound followed by a vowel sound. Examples of syllabaries include Japanese Katakana/Hiragana and the Indic scripts.

symbolic link**

1. An instance of the symbolic-link object type. It represents a "soft alias" that equates one name to another within the name space of the Object Manager.

2. A file object with special properties. When a symbolic-link file is encountered as a component of a pathname, the file system is redirected to a specific file. The redirection occurs instead of opening the file itself.

symbolic link object

An instance of a type defined by the Object Manager. The symbolic link object translates a reference to one named object into a different name.

symmetrical compression

A compression system that requires equal processing for compression and decompression of an image. Examples of types of applications that use symmetrical compression include still-image databasing, still-image transmission (color fax), video production, video mail, videophones, and video conferencing. Compare with asymmetrical compression.

Synchronization Manager

In Windows 2000 and later versions of the operating system, a centralized location for the user to synchronize all offline data that is personally owned.

synchronous**

Any operation that proceeds under control of a clock or timing mechanism. Compare with asynchronous.

Synchronous Access Mode (SAM)

Defined by V.80, SAM allows the data protocols in a modem to be bypassed. SAM also allows any arbitrary, non-traditional protocol to be implemented in the host, for example, H.324 video telephony systems.

system board**

The primary circuit board in a computer system that contains most of the basic components of the system. Also motherboard or planar.

system context

The volatile data in the computer system that the device driver does not save.

system devices

Devices on the system board. These devices are typically integrated in the supporting chipset. The devices can include interrupt controllers, keyboard controller, real-time clock, DMA page registers, DMA controllers, memory controllers, FDC, ATA ports, serial and parallel ports, and PCI bridges.

system locale

Determines which script non-Unicode applications will support. It is the locale emulated by the operating system, as seen by applications. See script

For example, if the system locale for U.S. Windows XP is established for Hebrew, then ANSI applications will see it as Hebrew localized Windows XP. However, the user interface of the operating system will still be in English.

The system locale is system wide and therefore applies to all users. Changing the system locale requires a reboot.

Systems Management Server*

Provides a management service that is centralized for distributed systems.

system paging file

An operating system file that contains the contents of paged pool allocations that are currently paged out to backing store. See also pool memory, paging file.

system power policy

The rules that control when the computer system goes to sleep and how it wakes up. With input from the user, applications, and drivers, the Power Manager enforces two such sets of rules. One set of rules governs performance when the computer system is running on AC power. The other set of rules govern conservation when the computer system is running on battery or UPS power.

system power state

The level of power usage and functionality of the computer system as a whole. These six discrete system power states (S0, S1, S2, S3, S4, and S5). Every computer system must support the S0 (fully operational computer system working state) and S5 (off) states. Support for intermediate states S1 through S4 depends on support from the computer system and device hardware and drivers.

system services

The set of user-mode routines that is native and exported by the Windows executive for use only by protected subsystems. See also Zw routines.

system space

See kernel space.

system worker threads

A set of kernel-mode threads provided by the Executive Support component. Drivers, particularly FSDs, use these threads to accomplish work within a nonarbitrary thread/process context. See also FSP, thread object.

system working state

System state S0. This is the fully on, fully operational power state.

T

tape miniclass driver

A driver that is specific to SCSI devices. It is linked with the SCSI tape-class driver that is supplied by the operating system. If a tape miniclass driver calls those routines in the tape class driver, the miniclass driver can be portable across Windows operating systems.

TAPI*

Telephony Application Program Interface. A set of Win32-based calls. Applications use these calls to control modems and telephones by routing application function calls to the appropriate service provider DLL for a modem.

TB**

1. Terabyte.

2. Translation buffer. See TLB.

TBD

To be determined.

TC

Traffic control.

TCO*

Total cost of ownership.

TCP*

Transmission Control Protocol.

TCP/IP**

Transport control protocol/interface protocol. TCP/IP is a software protocol for communications between computers.

TDD

Telephone Device for the Deaf.

TDI

Transport Driver Interface.

TDM**

Time division multiplexing.

TDMA**

Time division multiplexing access.

TE

Terminal equipment.

TEB

Thread environment block.

Telecine

A name for a process of converting to Television field rates from Cinematography frame rates.

telephony*

Telephone technology.

telset

Local telephone instrument.

test assertion

In testing for the Windows Logo Program for hardware, a test assertion is a statement that clarifies or provides additional detail with respect to a testable requirement. The intent of a test assertion is to remove any ambiguity from a requirement by clearly stating assumptions.

test suite

A test suite is a collection of tests that collectively verify the implementation of a feature.

texel

For 3-D graphics, texel refers to the individual color values that compose the 2-D array of color values of a texture. Each texel has a unique address in the texture.

TFTP

Trivial File Transfer Protocol.

TGT

Ticket Granting Ticket.

THD+N

Total harmonic distortion plus noise.

thin client**

A software layer of a small client for a centrally managed, network terminal. The thin client allows the user access to server-hosted applications and data.

thread locale

The locale of a given thread. Upon creation, the thread locale is inherited from the current User Locale. It can be changed at run time to any valid locale (per thread). Calls to NLS APIs can use this locale to format numbers, date, and time.

thread object

A user-mode thread object that represents a path of execution within the current process.

TIA**

Telecommunications Industry Association.

TID

Target identifier. One of eight target controllers on a SCSI-II bus through which peripheral devices can be addressed. The peripheral devices can be addressed either as numbered TIDs or as logical units (LUs) that are subordinate to a particular TID.

timecode

For MPEG, time reference that is measured frame-by-frame and uses address codes. It is recorded on the spare track of a videotape or inserted in the vertical blanking interval. It is an eight-digit number, encoding time in hours, minutes, seconds, and video frames, for example, 02:04:48:26.

timeout**

The detection of a lack of bus activity for some predetermined interval.

timer object

A timer object is an instance of a dispatcher-object type that is defined by the kernel. User-mode timer objects can synchronize the execution of specific actions, optionally an APC, with time. Kernel-mode timer objects synchronize the execution of specific actions, in particular a DPC, with time.

TinyTP

IrDA transport protocol.

TLB

Translation look-aside buffer.

TLC

Third-level cache.

TLS

Transport Layer Security protocol.

toaster device

In the Windows DDK sample code, a "toaster device" standards for a peripheral device of an unknown class. Used to illustrate general principles and processes for device drivers.

token object

A security object type that represents an authenticated user process. Every process has an assigned token, which becomes the default token for each of the threads of that process. However, an individual thread can be assigned a token that overrides this default.

top down

An order or arrangement of pixel data in memory. The order starts with the lowest-addressed pixels corresponding to the upper-left corner of the image. It then proceeds to the right with increasing memory address, with the highest-addressed pixels corresponding to the lower-right corner of the image.

TOS

Type of service.

TP**

1. Twisted pair.

2. Transaction processing.

TR

Token Ring.

transfer**

One or more bus transactions to move information between a software client and its function.

transform**

A set in kernel streaming and DirectShow that defines the access to a filter actually provided by a pin. Each pin supports one transform.

trap handler**

A body of code in the kernel to which the processor transfers control when an interrupt or exception occurs. The trap handler determines the type of condition that caused the interrupt or exception and transfers control to an ISR or exception handler.

TSD

Type-specific driver.

TSP

TAPI call control service provider.

TTL*

Transistor-transistor logic.

tuple**

A data structure that PCMCIA defines as a single, specific characteristic of a PC Card device. Tuples are chained together to form the CIS. Tuples consist of a tuple code, an offset to the next tuple, and a number of bytes specific to the tuple. See also CIS.

TVCF

Telephone Voice Call First model. This is available on data/fax modems that support H.324 video telephony. It is also known as V.8 prime or V.8’.

TWAIN**

API for image acquisition developed by an association of industry leaders. TWAIN is not an acronym but refers to a line from a Rudyard Kipling poem: "...and never the twain shall meet..."

typeface**

Name given to a particular style of text. In contrast, a font is an implementation of a typeface.

U

UADSL

Universal Asymmetrical Digital Subscriber Line.

UART*

Universal Asynchronous Receiver/Transmitter. A module composed of a circuit that contains both the receiving and transmitting circuits that are required for asynchronous serial communication.

UAS

User account system.

UAWG

Universal ASDL Working Group.

UBR

Unspecified bit rate.

UCT

Universal coordinated time.

UDF

Universal disk format.

UDP

User Datagram Protocol.

uDSL

Universal Digital Subscriber Loop.

UGA

Universal Graphics Adapter.

UHCI

Universal Host Controller Interface.

UHF

Ultra-high frequency.

UI*

User interface.

ULS

User Location Service.

UMA**

1. Uniform Memory Access.

2. Upper Memory Area. Usually 384K bytes of memory located between 640K and 1024K.

3. Unified Memory Architecture.

UMB*

Upper Memory Block. An area of the UMA that is not currently in use.

UNC*

Uniform Naming Convention.

UNI

User Network Interface.

unicast*

A method of providing content in which each client receives a unique stream from a server. No other client has access to the stream.

Unicode**

An encoding scheme that is standard, fixed-width, and 16-bit character. The operating system uses this scheme to provide support for natural languages that are specific to the locale. See also NLS. Unicode is the first level of ISO 10646.

unidriver

Universal printer driver.

Unimodem

Universal modem driver. A driver-level component that uses modem description files to control its interaction with the communications driver.

universal naming convention (UNC)**

The operating system for indicating names of servers and computers, for example, \\Servername\Sharename.

UP**

Uniprocessor (single CPU).

UPnP

Universal Plug and Play.

UPS*

Uninterruptible power supply. A device connected between a computer and a power source. This device ensures that electrical flow to the computer is not interrupted because of a blackout. It also protects the computer against potentially damaging events such as power surges and brownouts.

upstream*

The direction of data flows towards the host. An upstream port is the port on a device that is electrically closest to the host. The specific host generates upstream data traffic from the hub.

URB

USB request block. Clients send URB transfers to the bus by including a pointer in an IRP to a URB structure. A function within the URB identifies the specific request.

URL*

Uniform Resource Locator.

USB*

Universal Serial Bus. A serial interface that is bidirectional, isochronous, and dynamically attachable, as defined in the Universal Serial Bus Specification.

USB class

The class of filters under the Windows operating system that provides a bus interface and bus enumerator for USB.

USBD

USB driver, a Windows operating system component.

user

The customer who uses a computer system or software product. See also user mode.

user interface language

Language in which the operating system displays its menus, help files, and dialog boxes. See also Locale, System Locale, User Locale, and Input Locale.

User Locale

The user preferences for formatting of dates, currencies, and numbers. The user locale is configured according to a single user. It does not require a reboot or logoff/logon. See also Locale, System Locale, Input Locale, and User Interface Language.

user mode

The nonprivileged processor mode in which application code executes, including protected subsystem code in Windows NT and later versions of the operating system. User-mode applications cannot gain access to operating system data except by calling functions supplied by the subsystem. See also kernel mode. See the Windows DDK.

user space

A block of virtual memory, dedicated to the use of the current user-mode process. Generally, the Windows NT and later versions user space is a range of virtual addresses of low-order. The space is around two gigabytes in size. See also hyperspace, kernel space, section object, view.

USN

Update Sequence Number.

UTC*

Coordinated Universal Time (often spelled out as Universal Coordinated Time). It is the standard time common to every place in the world. Formerly and still widely called Greenwich Mean Time (GMT) and World Time. It is expressed using a 24-hour clock.

UTP*

Unshielded twisted pair.

V

V

1. Volt.

2. Version.

V.250

ITU-T Recommendation. This is a superset of the TIA-602 basic AT command set. New components include a standard for extending the AT command set and standard extensions for the following: modem ID, port control, modulation control and reporting, error control, and data compression control and reporting.

V.251

ITU-T Recommendation. This specifies a standard set of commands that enables the DTE (PC) to use V.25, V.8. It also allows the standard set of commands to participate in V.8 bis call control for point-to-point data calls, voice/data/video calls, and voice-to-data transitions.

V.8

ITU-T Recommendation. This defines procedures for starting sessions of data transmission over a GSTN.

V.8 bis

ITU-T Recommendation. This defines procedures for the identification and selection of common modes of operation. The operations occur between DCE and DTE over the GSTN and on leased point-to-point telephone circuits.

V.8 prime (V.8’)

An extension of V.8 procedures which provides an interim method of transitioning from telephony to H.324 during an existing voice call. The V.8 procedures were defined after H.324 was approved, but before V.8 bis, Also known as Voice Call First model.

V.80

ITU-T Recommendation. This defines in-band DCE control and synchronous data modes for asynchronous DTE.

VA

Video acceleration.

valid page

A virtual page that is currently in physical memory. See also invalid page.

value entry

A named value with assigned data within a registry key. See also registry, key object.

VAR*

Value added reseller. A company that resells hardware and software packages to developers or end users.

VBE

VESA BIOS Extension.

VBI

Vertical blanking interval. The required time interval between television fields. The time interval allows the scanning gun to move from the bottom to the top of the screen for the start of the next field.

VBN

Virtual block number. A virtual block number identifies a block that is relative to the start of a file. For a file with N blocks of data, the corresponding VBNs are numbered 1 through N.

VBR

Variable bit rate.

VC

1. Virtual circuit.

2. Virtual channel.

VCACHE

In Windows 9x, a 32-bit cache driver that is protected-mode.

VCB

Volume control block. A file-system structure that is internal. In this structure, a file system maintains state information about a mounted volume.

VCDFSD

Virtual CD-ROM file system driver.

VCF

Voice Call First model. Available on voice modems that support H.324 video telephony. Also known as V.8 prime.

VCI

Virtual channel identifier.

VCOMM

In Windows 9x, a 32-bit communications driver that is protected-mode.

VCR

Video cassette recorder. An analog magnetic recording and playback machine. A VCR is used for recording and viewing full-motion video. It is also useful as a data backup device.

VDC

Volts Direct Current.

VDD*

Virtual display device driver.

VDIF

Video Display Information Format.

VDM**

1. Virtual DOS machine. A protected subsystem that emulates MS-DOS and DOS-based Windows within Windows NT and later versions.

2. Virtual device manager.

3. Video display metafile.

VDMA

Virtual DMA.

VDMAD

Virtual DMA device.

VDS

Virtual DMA services.

vector graphics**

Images defined by set of straight lines. The straight lines are defined by the locations of the end points.

VESA*

Video Electronics Standards Association. A governing body that establishes standards for the video and graphics portions of the electronics industry.

VfW

Video for Windows.

VGA**

A display adapter setting for 640x480-pixels color resolution.

VHF

Very high frequency.

VHN

video home network.

video codecs

Full-color video. Requires 3 bytes per pixel, at 640x480 resolution. This equals closely 1 MB of digital data per frame. This means that a developer could easily use 1 GB of hard-disk space by storing less than one minute of digital-video information that is uncompressed.

Video Port routines

An interface to miniport drivers that are specific to graphics adapters. The video port driver supplied by the operating system exports these drivers. Video miniport drivers call these routines to obtain all operating system support required to perform I/O operations.

view**

A whole or partial mapping of a section object in the virtual address space of a process.

virtual memory**

A view of memory that does not necessarily correspond to the underlying physical-memory structure. For example, a given range of virtual addresses might be mapped to and backed by some number of discontiguous physical pages. This can occur even though the corresponding virtual pages can be accessed as a single, contiguous range.

visual order

The ordering used to display glyphs on a screen, printed page, or other medium. Visual order is typically used with bi-directional text, because reordering is required to go from logical order to visual order. Compare with Logical order.

VLB*

VESA local bus.

VLIW*

Very large instruction word.

VLM**

1. NetWare 4.x client shell.

2. Very Large Memory.

VM*

Virtual machine. Software that mimics the performance of a hardware device.

VMCB

Volume map control block. An opaque structure that stores VBN-to-LBN mappings for an a volume file of an IFS.

VMR

Video-mixing renderer.

VoIP*

Voice over Internet Protocol.

volume**

Under Windows NT and later versions of the operating system, volume is the general term that refers to all of the following entities that can be created and used on a computer:

Primary partition
Logical drive in an extended partition
Volume set
Stripe set
Mirror set
Stripe set with parity

A volume is formatted for use by a file system, and it has a single drive letter assigned to it.

volume file

A virtual file that certain file systems maintain. The contents of the volume file map metadata structures of the on-disk file system. A volume file is a type of stream file.

VPB

Volume parameter block. A VPB is a structure that the I/O Manager defines. The VPB maps a volume device object of a file system to the device or partition upon which the volume is mounted. The device object of the file system represents the volume (VPB) mounted on the actual device (physical device object). See also mount.

VPE

Video Port Extensions. These extensions to the DirectDraw API control the video stream from the video port within the context of VGA memory.

VPI

Virtual path identifier.

VpicD

Virtual programmable interrupt controller device.

VPN*

Virtual private network.

Vpp

Voltage peak-to-peak.

VRAM*

Video RAM.

VRML*

Virtual Reality Modeling Language.

VRMS

Volts root-mean-square.

VRP

Video request packet. A structure that communicates control requests of device I/O from a display driver to its corresponding miniport driver that is adapter specific.

VSD

Vendor-specific driver.

Vsync

Vertical synchronization.

VTOA

Voice Telephony over ATM.

VUDA

VESA Unified Graphics Architecture.

VxD*

Virtual device driver. A device driver that runs at the privileged ring 0 protected mode of the microprocessor under Windows 9x operating systems.

W

W3C

World Wide Web Consortium.

Waking

The transition from a sleeping state to the working state.

WAN*

Wide area network. A communications network that connects areas that are separated geographically. Compare with LAN.

watchdog (timer or driver)

A hardware device that monitors system health and functionality through communications with the system software. The communication is through a dedicated device driver.

WBEM*

Web-based Enterprise Management. A DMTF initiative to provide a standards-based mechanism for information exchange between management applications and managed components.

WC

Write combining.

WDCTRL

Western Digital–compatible hard-disk controller.

WDL*

Windows Driver Library. Obsolete term.

WDM**

See Windows Driver Model.

WDM Comm

WDM Communications Class.

WDMCSA

WDM Connection and Streaming Architecture.

WDM DDK

An earlier DDK that provided the supplementary header files used together with the Windows NT DDK to build WDM drivers. Replaced by the current Windows DDK.

WDM power management

Facilities provided in WDM for drivers to implement power policy and control. DDIs are defined for synchronizing power-state changes with other power-management activities in the operating system. DDIs are also defined for detecting device idleness. IRPs are defined for establishing power sate, enabling wakeup, and querying power status.

WDM streaming

A kernel-mode extension of DirectShow that is WDM-based. It provides kernel connection and streaming services that the WDM Stream class driver and system software components use. WDM streaming provides low-level services for the lowest latency streaming. DirectShow provides higher-level features. Operating system support includes a Stream class driver that supports minidrivers for audio, video, and other types of stream input, output, and acceleration.

web blade

Internet server appliance.

web service

Internet-based application, management, or other functionality provided as a commercial service.

WEN

Windows for Express Networks.

WEP

Wired Equivalent Privacy. Both client and access point contain encryption keys. Data is encrypted before it is sent through the air. If a station receives a packet that isn’t encrypted, it is dropped.

WfM

Wired for Management, in initiative from Intel Corporation.

WFP

Windows File Protection.

WHIIG

Windows Hardware Instrumentation Implementation Guidelines

whitepoint

Whitepoint is the color produced by the device as it creates its whitest color in its colorspace. Whitepoint is measured in degrees Kelvin of black body radiation.

WHQL

Windows Hardware Quality Labs. Formerly Microsoft Compatibility Labs. WHQL provides compatibility testing services to test hardware and drivers for Windows operating systems. WHQL administers testing for the "Designed for Microsoft Windows" logo programs.

WIA

Windows Image Acquisition.

Win32 API

A 32-bit API for Windows operating systems. Win32 API includes sophisticated operating system capabilities, security, and API routines for Windows-based applications.

window turn

Turning a window refers to the process of filling an MCB with the appropriate retrieval pointers. This maps a VBN for a file to an LBN for a disk.

Windows**

Refers to the entire family of Microsoft Windows operating systems.

Windows Driver Model (WDM)*

A driver model based on the Windows NT driver model. WDM provides a model for writing kernel-mode drivers and minidrivers. It also provides extensions for Plug and Play and power management.

Windows installer service

Provides end users with a way to install and remove applications or software components, as required. System administrators can more easily manage applications and support roaming users.

Windows Management Instrumentation (WMI)

Extensions to WDM developed for Windows 98/ME, Windows 2000, and later versions of the operating system to provide an operating system interface. It is through this interface that instrumented components can provide information and notifications.

Windows Media Player**

A client/control that receives a stream from a Windows Media server or local content for playback. It can run as a stand-alone client executable program. Windows Media Player can also be embedded in a Web page, C++ program or a Microsoft Visual Basic program that uses the client ActiveX control.

Windows Media streaming library

A library providing a set of APIs convert audio data into a specified digital format. This format provides convenient storage and retrieval using computer technology, usually involving compression and encryption technology.

Windows NT**

Refers to the Microsoft Windows NT version 3.1, 3.51, or 4.0 operating system.

Windows NT driver model

The layered device driver model used under the Windows NT operating system.

WinHEC

Windows Hardware Engineering Conference.

WINS*

Windows Internet Name Service.

Winsock*

Windows Sockets.

WLAN*

Wireless LAN.

WMA*

Windows Media Audio.

WMC

Windows Media Container.

WMDM

Windows Media Device Manager.

WME

Windows Media Embedded PAK.

WMF**

1. Windows Media Format.

2. Windows Metafile Format (an older usage).

WMI

See Windows Management Instrumentation.

WMP

Windows Media Player.

WMT

Windows Media Technologies.

WMTV

Windows Media TV (Stream).

WMV

Windows Media Video.

workstation

In general, a powerful computer with considerable calculating and graphics capabilities.

World-Ready

A product is World-Ready when:

1. It has provisions for the input, display, and output of a defined set of language scripts that are supported by Unicode and data relating to specific geographic areas, and

2. It has been designed and coded to allow for the simplest translation process for the localization of its data and resources.

working set

The set of pages that are resident for a given process while it has one or more running threads. See also balance set, quota.

WORM*

Write-once, read many.

WOSA*

Windows Open System Architecture.

WOW64

Windows on 64-bit Windows.

WPS**

1. Windows Printing System.

2. Workplace shell.

WQL

WMI Query Language.

write combining memory

Processors that support write-combining (WC) memory combine several partial (line) write transactions into a single line write transaction. This is performed through internal CPU (write combining) buffers. This allows for great performance improvement of frame buffer accesses.

writing system

The collection of scripts and orthography required to represent a given human language in visual media.

WSD

Winsock Direct.

WSDP

Winsock Direct Path.

WSH

Windows Scripting Host.

WSL

Working set list. The set of WSLEs for the current process.

WSLE

Working set list entry.

WSP

WinSock Proxy.

WSS

Windows Sound System.

WWW*

World Wide Web.

WYSIWYG*

What You See Is What You Get.

X

XBDA

Extended BIOS Data Area.

xDSL*

general class of DSL technologies.

XFN

X/Open Federated Naming.

XGA*

Extended Graphics Array.

XML*

Extensible Markup Language.

XMS*

Extended-Memory Specification.

XOR*

Exclusive OR. A Boolean operation that yields "true" if and only if one of its operands is true and the other is false. Compare with OR.

Y

Y2K

Year 2000.

YcrCb

See YUV.

YUV

The method of color encoding to transmit color video images and to maintain compatibility with black-and-white video. YUV uses less bandwidth than the three separate video signals in an RGB video transmission. It consists of two major components:

  • Luminance (Y), which corresponds to the brightness of an image pixel.
  • Chrominance (UV or CrCb), which corresponds to the color of an image pixel.

Z

Z

Z axis. For graphical displays, the optical axis that is perpendicular to X and Y axes.

Z-based fog

See depth-based fog.

Z buffer

A memory buffer that stores the depth of all pixels in a scene. The Z buffer determines which triangle of many overlapping triangles is closest to the viewer.

ZIPI

A MIDI-like serial data format for musical instruments. ZIPI provides a more hierarchical method of addressing instruments and an extensible command set.

ZV

Zoomed Video.

Zw routines

A set of entry points parallel to the operating system services of the executive. A call to a ZwXxx entry point from kernel-mode code supplies the corresponding system service. See also system services, probe. See the Windows DDK.


Untitled

Figure 1a. Standard MSCS configuration using SCSI (or SSA) adapters


Untitled

Figure 1b. Standard MSCS Configuration using Fibre channel adapters


Untitled

Figure 2. Server Cluster component and system validation process


Untitled

Figure 27.1 SAN architecture