WHQL Test Specification

February 15, 2001

Microsoft Corporation


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 - 2001 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

Draft Version: 0.7 — Date: February 12, 2001

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® Whistler operating system.

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 Windows Whistler, plus many tests first introduced for Windows 2000 and Windows Millennium Edition (Windows Me).

This test specification is owned and managed by Microsoft Corporation.

Beta Reviewers Notes: In this beta review draft of the Test Specifications, please note the following issues:

1. All tests to be documented in the Test Specification are not completely described in this beta review draft. The designation "TBD" indicates that additional information will be provided in a future draft.

2. Complete, up-to-date references have not yet been provided for Windows Logo Program requirements and design guides.

3. References to "Windows 2000" in assertions and test descriptions apply for Windows Whistler, unless otherwise noted.

Guidelines for Reviewer Comments: Please submit beta review comments as defined in the HCT Kit beta release notes, following these guidelines:

* Review test assertions to ensure that these are aligned with the Reference Documents that specify the related requirement.

* Review test assertions for clarity, and request additional information that you might need.

* Identify any new or untested assertions that you want to see defined.

* Identify any assertions that might not be testable.

* Identify any assertions that would result in a failure of any product that meets requirements specified in the Reference Documents but is implemented differently than specified in the assertion.

* You do not need to comment on "TBD" items.


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/onnow/download/LFreeACPI.doc.

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/1394/
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/audio/AMR.htm

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/onnow/download/LFreeACPI.doc

ACPI Docking for Windows 2000

http://www.microsoft.com/hwdev/onnow/ACPIdock.htm

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

http://www.teleport.com/~acpi/

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/network/dsl/

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/stds/stsubj.html

Application Specification for Microsoft Windows 2000, 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

http://www.t13.org
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.ptltd.com/techs/specs.html

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/stan_rps.html

Audio and Windows web page

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

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/specs/PMref/

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.ptltd.com/techs/specs.html

Bluetooth Implementation and Windows web page

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

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/network/cable/

CardBus Host Controllers and Windows Compatibility

http://www.microsoft.com/hwdev/busbios/CARDBUS1.HTM

CardBus Technology and Windows web page

http://www.microsoft.com/hwdev/cardbus/
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/devdes/gdi.htm

Ccport and Windows 98 Second Edition

http://www.microsoft.com/hwdev/devdes/modem_up.htm

Color Coding for Connectors

http://www.pcdesguide.org/documents/pc99icons.htm

Color Management and Windows Operating Systems web page

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

Common Application Environment (CAE) Specification

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

Common Information Model (CIM)

http://www.dmtf.org/work/cim.html

Communications Device Class Power Management Reference Specification, Version 1.0

http://www.microsoft.com/hwdev/specs/PMref/

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

http://www.ptltd.com/techs/specs.html

Compatibility Testing for Hot-Plugging Support for PCI Devices

http://www.microsoft.com/hwdev/pci/hotplugtest.htm

Compatibility Testing Requirements for Display and Video Miniport Drivers

http://www.microsoft.com/hwdev/video/vidminiport.htm

Computer Display Monitor Timing Specifications, Version 1, Revision 0.8

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

Configuring PCI-PCI Bridges on Windows 2000 and Windows Whistler

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

Configuring PCI-to-PCI Bridges with VGA Cards

http://www.microsoft.com/hwdev/pci/vgacard.htm

Data-Over-Cable Service Interface Specifications (DOCSIS)

http://www.cablemodem.com/

Debug Port Specification

http://www.microsoft.com/hwdev/NewPC/debugspec.htm

Default Device Class Power Management Reference Specification, Version 1.0

http://www.microsoft.com/hwdev/specs/PMref/

Designing HID Game Controllers for DirectInput

http://www.microsoft.com/hwdev/devdes/hidgame.htm

Designing Multifunction Devices for Windows Operating Systems

http://www.microsoft.com/hwdev/mf/download/mfdesign.zip

Design Rule for Camera File system (DCF) Specification

http://www.jeida.or.jp/document/standard/jeida49-2.html#english

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

http://www.dmtf.org/tech/specs.html

Device Bay Specification, Version 1.0

http://www.device-bay.org

Device class power management reference specifications

http://www.microsoft.com/hwdev/specs/PMref/

Digital Audio and Windows white papers

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

Digital Video Camcorder Support in Windows 98 and Windows 2000

http://www.microsoft.com/hwdev/vidcap/DVCam.htm

Digital Visual Interface (DVI), Revision 1.0

http://www.ddwg.org

Display Adapter Drivers and Windows Millennium Hibernation

http://www.microsoft.com/hwdev/video/Mill_D3display.htm

Display Adapters and Windows web page

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

Display Device Class Power Management Reference Specification, Version 1.0b

http://www.microsoft.com/hwdev/specs/PMref/

Display Technology web page

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

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/network/dsl/

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/devdes/dvdwp.htm

DVD Multifunction Devices: Avoiding Multiple Logical Unit Devices

http://www.microsoft.com/hwdev/dvd/multiLUN.htm

DVD Physical Format documents

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

DVD Playback and Windows web page

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

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/newpc/

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.ptltd.com/techs/specs.html

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/devdes/cddigital.htm

Enumerating Serial Devices in Windows 2000

http://www.microsoft.com/hwdev/desinit/serddvr.htm

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/headless/

External DSL Modems Design Guidelines

http://www.microsoft.com/hwdev/network/dsl/extdslmodems.htm

Fibre Channel Physical (FC-PH), Revision 4.3

http://www.fibrechannel.com

GDI+: Next-Generation Graphics Device Interface

http://www.microsoft.com/hwdev/video/gdinext.htm

Global Engineering Documents

http://global.ihs.com

Guidelines for WDM-based Software Modems

http://www.microsoft.com/hwdev/modem/softmodem.htm

Handshake procedures for digital subscriber line (DSL) transceivers

http://www.itu.int/

Hardware Design Guide Version 3.0 for Microsoft Windows 2000 Server

http://www.microsoft.com/hwdev/serverdg.htm

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 2000 web page

http://www.microsoft.com/hwdev/pci/hotplugpci.htm

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

http://www.i2osig.org (special interest group)

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/profiles.html

Icons for PCs web page

http://www.pcdesguide.org/documents/icons.htm

IEC 61883 Digital Interface for Consumer Electronic Audio/Video Equipment

https://domino.iec.ch/webstore/webstore.nsf/Welcome?ReadForm

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.walkingdog.com/

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/1394/

Implementing Display Control Panel Extensions in Windows 95/98

http://www.microsoft.com/hwdev/devdes/displaycpl.htm

Implementing Legacy Audio Devices on the PCI Bus

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

InfiniBand Trade Association

http://www.sysio.org

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/infrared/

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/specs/PMref/PMinput.htm

Input Device Drivers and Windows 2000

http://www.microsoft.com/hwdev/input/drv.htm

Input Devices and Windows web page

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

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/audio/DRM.htm

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 2000

http://www.microsoft.com/hwdev/infrared/IrDAPnP.htm

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

http://www.microsoft.com/hwdev/infrared/IrCOMM.htm

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

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

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/d14717.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/d14721.html

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

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

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

http://www.iso.ch/cate/d29257.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/d26536.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/d14735.html

ISO/IEC 10373:1993 Identification cards—Test methods

http://www.iso.ch/cate/d18434.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/newpc/io-apic.htm

Key Support and Keyboard Scan Codes for Windows web page

http://www.microsoft.com/hwdev/desinit/scancode.htm

Legacy-Free Hardware and BIOS Requirements

http://www.microsoft.com/hwdev/NewPC/LF.htm

Legacy PCI Interrupt Routing and CardBus in Windows 2000

http://www.microsoft.com/hwdev/cardbus/Spir.htm

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/busbios/usbhost.htm

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/respec/storspec.htm

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/efi/

Microsoft information for hardware manufacturers

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

Microsoft Platform SDK, including Win32® and Win64™ APIs

http://msdn.microsoft.com/downloads/sdks/platform/platform.asp
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/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/developers/specification/index.php3?t2=1

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/modem/

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/mf/

Multifunction Print Device Design Guidelines

http://www.microsoft.com/hwdev/mf/mfp.htm

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/desguid/smp.htm

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

http://www.osta.org/html/mrspec.html

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/network/

Network Device Class Power Management Reference Specification, Version 1.0a

http://www.microsoft.com/hwdev/specs/PMref/

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.pcdesguide.org/documents/keycode.htm

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

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

OpenCable specification

http://www.opencable.com

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

http://www.microsoft.com/hwdev/respec/busspecs.htm

PAE Server Design web page

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

Parallel and Serial (COMM) Technology and Windows web page

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

PC 2001 System Design Guide

http://www.pcdesguide.org/pc2001.htm

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.pcdesguide.org/library/pccard.htm

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

http://www.microsoft.com/HWDev/specs/PMref/PMcard.htm

PC Card Standard, Release 7

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

PC Card Voltage Requirements for Windows Operating Systems

http://www.microsoft.com/hwdev/cardbus/pccardvlt.htm

PC Design Guides web page

http://www.pcdesguide.org

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/developers/specification/

PCI and Windows web page

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

PCI Device Subsystem IDs and Windows

http://www.microsoft.com/hwdev/devdes/pciids.htm

PCI Hot-Plug Specification, Revision 1.0

http://www.pcisig.com/developers/specification/

PCI IDE Controller Specification, Revision 1.0

http://www.pcisig.com/developers/docs/

PCI IRQ Routing on a Multiprocessor ACPI System

http://www.microsoft.com/hwdev/onnow/acpi-mp.htm

PCI Local Bus Specification, Revision 2.2 (PCI 2.2)

http://www.pcisig.com/developers/specification/

PCI Power Management and Device Drivers

http://www.microsoft.com/hwdev/desinit/pcipm.htm

PCI Subsystem IDs and PCI-to-PCI Bridge Devices

http://www.microsoft.com/hwdev/pci/pcibridge.htm

PCI to PCI Bridge Architecture Specification, Revision 1.1

PCI SIG
http://www.pcisig.com/developers/specification/

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

http://www.pcisig.com/developers/specification/

Personal Computer Audio Quality Measurements

by Dr. Steven Harris and Cliff Sanchez, Crystal Semiconductor
http://www.cirrus.com/products/papers/meas/meas.html

PIAFS - PHS Internal Access Forum Specification

http://mitf.arib.or.jp/e/menu.html

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 2000 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/respec/pnpspecs.htm

Porting Your Driver to 64-bit Windows

http://www.microsoft.com/hwdev/64bitWindows/

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/print/

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

http://www2.qic.org/qic/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 2000

http://www.microsoft.com/hwdev/storage/RSM.htm

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://developer.intel.com/design/ia-64/downloads/245359.htm

SBP-2 Support and Windows 2000

http://www.microsoft.com/hwdev/print/sbp2_w2000.htm

Scan Code Mapper for Windows 2000

http://www.microsoft.com/hwdev/input/W2kscan-map.htm

Scan Codes for Keyboard Power Switches

http://www.microsoft.com/hwdev/desinit/scancode.htm

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/headless/

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/tech/

SII NS-2482-30

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

Simple Boot Flag Specification, Version 1.0

http://www.microsoft.com/hwdev/desinit/simp_bios.htm

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/smartcard/

SMART IOCTL API Specification, v.1.1

http://www.microsoft.com/hwdev/download/respec/iocltapi.rtf

Specification for Exchangeable image file format (EXIF)

http://www.jeida.or.jp/document/standard/jeida49.html

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/pci/pciidspec.htm

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/modem/comndset.htm

STD-201: Extensions to NDIS for Wireless WANs

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

Still Image Architecture and Windows 2000

http://www.microsoft.com/hwdev/stillimage/w2STI.htm

Still Image Devices and Windows web page

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

Storage Device Class Power Management Reference Specification, Version 1.0a

http://www.microsoft.com/hwdev/specs/PMref/

Storage Technology web page

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

Streaming Media Technology

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

Supporting PAE Memory under Windows 2000

http://www.microsoft.com/hwdev/newPC/PAEdrv.htm

Supporting Removable Devices under Windows

http://www.microsoft.com/hwdev/busbios/rem_devs.htm

System Management BIOS Reference Specification, Version 2.3

http://www.phoenix.com/techs/specs.html

System Test Implementers Forum

http://www.systemtest.org

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/respec/commspec.htm

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://www2.fm.intel.com/pcd_ae/public/general/specs_ind/USB/uhci_1_1.pdf

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/video/clrtype.htm

UPS Applet for Windows 2000

http://www.microsoft.com/hwdev/onnow/ups.htm

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/usb/

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

http://www.microsoft.com/hwdev/busbios/usbpnp.htm

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/devdes/vcomm.htm

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.html

Video Capture

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

Videophone-ready Modem Handbook, Version 1.0

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

WDM Audio Drivers for Windows 2000

http://www.microsoft.com/hwdev/devdes/wdmaudio.htm

WDM Kernel Streaming Architecture

http://www.microsoft.com/hwdev/desinit/csa1.htm

WDM Video Capture Overview

http://www.microsoft.com/hwdev/desinit/vidcap.htm

Web-Based Enterprise Management (WBEM) information

http://www.dmtf.org/

Windows 2000 Support for Mobile System Displays

http://www.microsoft.com/hwdev/video/mobiledisplay.htm

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/color/

Windows DDK, including Windows 95 DDK; Windows 98 DDK; Windows DDK (incorporates Windows Me DDK, Windows 2000 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/wdm/

Windows Hardware Instrumentation Implementation Guidelines (WHIIG), Version 1.0

http://www.pcdesguide.org/whiig.htm

Windows Image Acquisition web page

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

Windows Logo Program for Hardware

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

Windows Management Instrumentation (WMI) and Win32 Extensions schema

http://msdn.microsoft.com/downloads/sdks/wmi/

Windows Modem Update

http://www.microsoft.com/hwdev/devdes/modem_up.htm

WMI web page

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

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/hid/audctrl.htm

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 2000 at http://www.microsoft.com/hwdev/PlugnPlay/no_reboot.htm.
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 Whistler.

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 Whistler 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 four 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

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/products/papers/meas/meas.html

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/products/papers/meas/meas.html


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 - TBD
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 - TBD
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 - TBD
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 - TBD
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 - TBD
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 - TBD
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 - TBD
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 - TBD
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 - TBD
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 - TBD
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 - TBD
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 - TBD
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 - TBD
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 - TBD
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 - 1.34.7 DELETED - See 28.2.1 - 28.2.7

General Storage Device Manual Test Assertions in Chapter 28, WHQL Storage Test Specifications.

[CLARIFIED v.0.5a]

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 Whistler 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 DELETED - see 28.3.3

[CLARIFIED v.0.5a]

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

[CLARIFIED v.0.5a]

1.36.1 DELETED - see 28.4.1
1.36.2 - 1.36.9 - DELETED See 28.4.2 - 28.4.5

Tape Drive Ease-of-Use/Manual Assertions

[CLARIFIED v.0.5a]

1.37.1 - 1.37.4 - DELETED - SEE 28.5.1 - 28.5.4

Media Changer Devices Ease-of-Use/Manual Assertions

[CLARIFIED v.0.5a]

1.38.1 - 1.38.3 - DELETED - SEE 28.6.1- 28.6.3

RAID Ease-of-Use/Manual Assertions

[CLARIFIED v.0.5a]

1.39.1 - 1.39.4 - DELETED - See 28.7.1 - 28.7.4


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 Whistler.
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 Whistler Profession/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.

Monitor Two-System Test System Identification

Test system/display adapter #1

System #1 Name:

System BIOS Name:

System BIOS Version:

Display Adapter #1 Name:

Display Adapter Driver File Name and Version:

Display Adapter BIOS Version:

Comments:

Test system/display adapter #2

System #2 Name:

System BIOS Name:

System BIOS Version:

Display Adapter #2 Name:

Display Adapter Driver File Name and Version:

Display Adapter BIOS Version:

Comments:


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.

Video Capture Applications and Utilities Used for Verification

Application Name (comma-separated list):

Verification Tips:

  • Image Quality: Use a Laser disc player or equivalent to test for step capturing, if applicable. Use a frame accurate video deck as a source for testing adapters that support frame accurate step capturing video content and utilize animation source material, such as "Beyond the Mind’s Eye." Test to verify proper step capture operation with Adobe Premiere 4.0 (or higher), and a DirectShow-compliant video capture application or equivalent. View the individual frames and construct a movie file. Compare the movie file to the original to verify that color and a satisfactory image quality has been preserved.
  • Time Code Control: Use source material with visibly embedded time code and compare the final output to the source original.

Supported CODECs

Video size | Required duration per color depth | Supported CODECs
80x60 | 10 minutes |
160x120 | 10 minutes |
240x180 | 10 minutes |
320x240 | 10 minutes |
640x480 | 10 minutes |
Other sizes | 10 minutes |

Verification Tips: Capture motion video clips with Asymetrix Digital Video Producer, In:Sync RazorPremiere, or Adobe Premiere 4.0 (or higher). You MUST capture clips of the following sizes with all supported CODECs (Cinepak, Indeo, and so on).


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.

DVD Applications and Utilities Used for Verification

Application Name (comma-separated list):

DVD-MPEG Playback Test System Description

Computer:

Motherboard:

BIOS, Version, Date:

Processor:

RAM:

PCI Chip Set:

CardBus Controller:

ATA Controller:

Hard Drive:

DVD ROM Drive:

Display Adapter

Display Driver Set Version:

Video Adapter Memory:

DirectX Version:

Audio Adapter:

Audio Driver Set Version:

Network Adapter:

Network Adapter Driver Set Version:

DVD Titles used to test the DVD solution:


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

[Clarification - v.0.7]

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

  1. With the system off, install the Input Test device.

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

  2. Boot the system and allow the operating system to install the Test device.
  3. The Test device must become immediately functional without a reboot.

Note: All buttons or wheels present on the device must be fully functional without a reboot. However, if an application is provided that supports additional functionality, the installation of this application can reboot the system once.

To verify wheel mouse functionality after installation

  1. Right-click My Computer and choose Explore.
  2. In the Windows Explorer application, verify that the window view is not set for List, and resize the window as necessary to display scroll bars.
  3. Position the Test device anywhere in the explorer window and roll the wheel forward and backward. The explorer window must scroll up and down in direct response to the wheel.
  4. Exercise any additional wheel features of the Test device according to the instructions with any Microsoft Office 2000 products and the Internet Explorer 5.0 installed on the Test system, including:
  • Scroll: Position the Test device anywhere in the application window and roll the wheel forward and backward. The application window must scroll up and down in direct response to the wheel.
  • Autoscroll: Position the Test device anywhere in the application window and click the wheel. An origin mark (double- or quad-headed arrow) is displayed either in the document or in the scroll bar. Four arrows indicate scrolling in any direction; two arrows indicate scrolling up and down or side to side. Move the mouse a short distance from the origin mark. The window must automatically scroll in direct response to the movement of the Test device. A second click on the wheel must cancel Autoscroll.
  • Pan: Position the Test device anywhere in the application window and click and hold down (not roll) the wheel button. An origin mark is displayed in the document. Move the mouse a short distance from the origin mark. The application window must pan in direct response to the movement of the Test device. Releasing the wheel must cancel Pan.
  • Zoom: With applications such as Microsoft Word 2000 or Microsoft Excel 2000, the wheel mouse can be used to zoom in/out of the document. To zoom in, hold down the CTRL key while rolling the wheel forward. To zoom out, hold down the CTRL key while rolling the wheel backward.

To verify correct functionality when reinstalling vendor-supplied PS/2-compatible drivers

  1. In Windows Control Panel, double-click the System icon and click the Device Manager tab.
  2. Under hardware type, click the Mouse listing and highlight the P/S2 Compatible Mouse Port icon.
  3. Click Properties.
  4. Click the Driver tab, click Update Driver, and then select Next.
  5. Select Display A List Of All Drivers, and then click Next.
  6. Click Have Disk and guide the wizard to the vendor-supplied INF-based installation.
  7. Verify that the appropriate Hardware ID for the Test device was to the following key in the Registry:

My Computer\HKEY_LOCAL_MACHINE\Enum\…

  8. Verify functionality input test device and any vendor-supplied control panel applets.

To verify input device operation with applications

  1. Manually test the device with the Microsoft Office 2000 Professional software suite, multimedia applications, such as Microsoft Internet Explorer, Encarta, Dangerous Creatures, and so on.
  2. Manually test the device with MS-DOS-based applications that require mouse support, such as games, CAD/CAM applications, and so on. Test MS-DOS-based applications in both full-screen and windowed environments.
  3. Verify that on-the-fly switching from MS-DOS-based applications to Windows produces no irregularities.


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

System Configuration for Smart Card Testing

Test machine description:

PnP BIOS:

First I/O Port:

Last I/O Port:

IRQ Level:

DMA Channel:

DMA Channel:

DMA Channel:

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- 1.34.7 | See TD-28.2 General Storage Device Manual Test Checklist Test Description- [CLARIFIED v.0.5a]
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 Whistler 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

[CLARIFIED v.0.5a]

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

See TD-28.3 Hard Disk Drive Manual Test Checklist Test Description

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

See TD-28.4 CD/DVD Driver Manual Test Checklist

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

See TD-28.5 Tape Drive Manual Test Checklist Test Description

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

See TD-28.6 Media Changer Manual Test Checklist Test Description

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

See TD-28.7 RAID Manual Test Checklist Test Description


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 Manger. 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

Draft Version: 0.7 — Date: February 12, 2001

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

[CLARIFIED v.0.5]

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.16.1-2.16.5, 2.21.6-2.21.20 | TD-2.19 Simple_Network Protocol Test (SimpleFileTest) | Tests all of the interfaces that implement the Simple File System Protocol, including File Io, Volume Open and File Handle.
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.2 Console I/O Protocol (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.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.

[CLARIFIED v.0.5] Detailed cross-references replaced “See Table of Tests” throughout this section.


Reference Document Sources for EFI Assertions

[CLARIFIED v.0.5] Functional requirements are defined in the following documents:

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

http://www.teleport.com/~acpi/

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/serverdg.htm

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/efi/

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: 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: 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: 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: 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: 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: 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: 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: 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: Extensible Firmware Interface Specification, Sections 3.1.1 and 3.1.4.
Test description: TD-2.1.3 Wait Periodic Timer Events Tes; 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: 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: TBD.
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: TBD.
Test description: TD-2.1.2 Wait Relative Timer Events Test; 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: TBD.
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: 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: TBD.
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: TBD.
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: TBD.
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: 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: TBD.
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: TBD.
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: TBD.
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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 TBD.

Reference Document: 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: Extensible Firmware Interface Specification, Section 3.2.1.
Test description: TD-2.2 Memory Allocation Services Tests

2.5.25 For valid paramerter combination and valid buffersize, GetMemoryMap succeeds and returns the EFI memory descriptor table.

Reference Document: 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: 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: 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: TBD.
Test description: TD-2.3.1 Protocols Consistency Test

2.6.2 InstallProtocolInterface should not succeed with a NULL protocol interface: FAILED.

Reference Document: TBD.
Test description: TD-2.3.1 Protocols Consistency Test

2.6.3 InstallProtocolInterface should not succeed with an invalid interface type: FAILED.

Reference Document: TBD.
Test description: TD-2.3.1 Protocols Consistency Test

2.6.4 InstallProtocolInterface should not succeed upon a spurious handle.

Reference Document: TBD.
Test description: TD-2.3.1 Protocols Consistency Test

2.6.5 InstallProtocolInterface should succeed with all valid parameters.

Reference Document: TBD.
Test description: TD-2.3.1 Protocols Consistency Test

2.6.6 LocateHandle should not succeed with a NULL GUID.

Reference Document: TBD.
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: TBD.
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: TBD.
Test description: TD-2.3.1 Protocols Consistency Test

2.6.9 LocateHandle should succeed with all valid and related arguments.

Reference Document: TBD.
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: TBD.
Test description: TD-2.3.1 Protocols Consistency Test

2.6.11 HandleProtocol should not succeed when queried with a NULL GUID.

Reference Document: TBD.
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: TBD.
Test description: TD-2.3.1 Protocols Consistency Test

2.6.13 HandleProtocol should succeed when queried with all valid parameters.

Reference Document: TBD.
Test description: TD-2.3.1 Protocols Consistency Test

2.6.14 UninstallProtocolInterface should succeed with all valid and related parameters.

Reference Document: TBD.
Test description: TD-2.3.1 Protocols Consistency Test

2.6.15 ReinstallProtocolInterface should not succeed with a NULL GUID.

Reference Document: TBD.
Test description: TD-2.3.1 Protocols Consistency Test

2.6.16 ReinstallProtocolInterface should not succeed with a spurious GUID.

Reference Document: TBD.
Test description: TD-2.3.1 Protocols Consistency Test

2.6.17 ReinstallProtocolInterface should not succeed with spurious old protocol interface.

Reference Document: TBD.
Test description: TD-2.3.1 Protocols Consistency Test

2.6.18 ReinstallProtocolInterface should not succeed with a NULL new protocol.

Reference Document: TBD.
Test description: TD-2.3.1 Protocols Consistency Test

2.6.19 LocateHandle must succeed for an installed protocol.

Reference Document: TBD.
Test description: TD-2.3.1 Protocols Consistency Test

2.6.20 HandleProtocol should succeed with all valid and related arguments.

Reference Document: TBD.
Test description: TD-2.3.1 Protocols Consistency Test

2.6.21 ReinstallProtocolInterface should succeed with all valid parameters.

Reference Document: TBD.
Test description: TD-2.3.1 Protocols Consistency Test

2.6.22 ReinstallProtocolInterface should succeed with all valid parameters.

Reference Document: TBD.
Test description: TD-2.3.1 Protocols Consistency Test

2.6.23 UninstallProtocolInterface should not succeed with a NULL GUID.

Reference Document: TBD.
Test description: TD-2.3.1 Protocols Consistency Test

2.6.24 UninstallProtocolInterface should not succeed with a spurious GUID.

Reference Document: TBD.
Test description: TD-2.3.1 Protocols Consistency Test

2.6.25 UninstallProtocolInterface should not succeed with a NULL interface.

Reference Document: TBD.
Test description: TD-2.3.1 Protocols Consistency Test

2.6.26 UninstallProtocolInterface should not succeed with a spurious interface.

Reference Document: TBD.
Test description: TD-2.3.1 Protocols Consistency Test

2.6.27 All the protocol handle services have non NULL function pointers.

Reference Document: TBD.
Test description: TD-2.3.1 Protocols Consistency Test


Protocol Services: Functionality Assertions

Assertions in this section are tested in TD-2.3 Protocol Handerler Services Tests.

2.7.1 LocateHandle should return EFI_NOT_FOUND when a queried protocol is not present.

Reference Document: TBD.
Test description: TD-2.3 Protocol Handerler 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: TBD.
Test description: TD-2.3 Protocol Handerler 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: TBD.
Test description: TD-2.3 Protocol Handerler Services Tests

2.7.4 Any valid EFI driver image present in the fle system can be loaded and started.

Reference Document: TBD.
Test description: TD-2.3 Protocol Handerler 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: TBD.
Test description: TD-2.3 Protocol Handerler Services Tests

2.7.6 A protocol interface that is successfully installed on a valid device handle can be uninstalled using UninstallProtocolInterface.

Reference Document: TBD.
Test description: TD-2.3 Protocol Handerler Services Tests

2.7.7 For a driver image that is successfully loaded and started it should be possible to unload it.

Reference Document: TBD.
Test description: TD-2.3 Protocol Handerler Services Tests

2.7.8 InstallProtocolInterface must succeed when valid protocol interfaces are installed on an existing and valid device handle.

Reference Document: TBD.
Test description: TD-2.3 Protocol Handerler Services Tests

2.7.9 UninstallProtocolInterface must succeed on previously installed valid protocol interfaces.

Reference Document: TBD.
Test description: TD-2.3 Protocol Handerler Services Tests


Protocol Services: Installation and Notifications Assertions

Tests for assertions in this section are described in TD-2.3 Protocol Handerler Services Tests.

2.8.1 CreateEvent succeeds for valid parameter combination.

Reference Document: TBD.
Test description: TD-2.3 Protocol Handerler 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: TBD.
Test description: TD-2.3 Protocol Handerler 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: TBD.
Test description: TD-2.3 Protocol Handerler 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: TBD.
Test description: TD-2.3 Protocol Handerler 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: TBD.
Test description: TD-2.3 Protocol Handerler 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: TBD.
Test description: TD-2.3 Protocol Handerler 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 HandlleProtocol must successfully return a pointer to the protocol's interface.

Reference Document: TBD.
Test description: TD-2.3 Protocol Handerler 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: TBD.
Test description: TD-2.3 Protocol Handerler 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: TBD.
Test description: TD-2.3 Protocol Handerler 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: TBD.
Test description: TD-2.3 Protocol Handerler 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: TBD.
Test description: TD-2.3 Protocol Handerler 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: TBD.
Test description: TD-2.3 Protocol Handerler 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: TBD.
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: TBD.
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: TBD.
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: TBD.
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: TBD.
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: TBD.
Test description: TD-2.4 Image Services Tests

2.10.4 LoadImage() loads images in succession.

Reference Document: TBD.
Test description: TD-2.4 Image Services Tests

2.10.5 StartImage starts an image already loaded in memory.

Reference Document: TBD.
Test description: TD-2.4 Image Services Tests

2.10.6 StartImage starts images in succession.

Reference Document: TBD.
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: TBD.
Test description: TD-2.4 Image Services Tests

2.10.8 StartImage starts an image loaded in memory.

Reference Document: TBD.
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: TBD.
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: TBD.
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: TBD.
Test description: TD-2.5 Variable Services Tests

2.11.4 Setvariable() would not work if given an invalid argument.

Reference Document: TBD.
Test description: TD-2.5 Variable Services Tests

2.11.5 Setvariable() would not work if the size of the variable to be stored is more than 1024 bytes.

Reference Document: TBD.
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: TBD.
Test description: TD-2.5 Variable Services Tests

2.11.7 GetVariable() returns a 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: TBD.
Test description: TD-2.5 Variable Services Tests

2.11.8 Getvariable() would not work if given an invalid argument.

Reference Document: TBD.
Test description: TD-2.5 Variable Services Tests

2.11.9 The Globally Defined Variables should be present in the Variable Store.

Reference Document: TBD.
Test description: TD-2.5 Variable Services Tests

2.11.10 The SetVariable() sets a variable in the variable storewhich is an integer.

Reference Document: TBD.
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: TBD.
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: TBD.
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: TBD.
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: TBD.
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: TBD.
Test description: TD-2.5 Variable Services Tests

The GetNextVariableName() gets the next variable in the variable store list.

Reference Document: TBD.
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: TBD.
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: TBD.
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: TBD.
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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: TBD.
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: TBD.
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 is invalid.

Reference Document: TBD.
Test description: TD-2.6 Time Services Test

2.12.4 The function Stall() stalls the processor for the specified seconds.

Reference Document: TBD.
Test description: TD-2.6 Time Services Test

2.12.5 Daylight savings time is activated and the time is adjusted.

Reference Document: TBD.
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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 boottime.

Reference Document: 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: 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: 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: TBD.
Test description: TD-2.8 Miscellaneous Services

2.14.2 GetNextMonotonicCount() returns the next monotonically increasing count each time it is called.

Reference Document: TBD.
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: TBD.
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: TBD.
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: 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: 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: 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: 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: Extensible Firmware Interface Specification, Section 3.8.5, page 98.
Test description: TD-2.4.5 Runtime Services Test


EFI Image (LOADED_IMAGE) Protocol Assertions

TDB


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: TBD.
Test description: TD-2.10 Device Path Protocol Test

2.16.2 The device supports Device Path protocol.

Reference Document: TBD.
Test description: TD-2.10 Device Path Protocol Test

2.16.3 The Device Path Type is valid.

Reference Document: TBD.
Test description: TD-2.10 Device Path Protocol Test

2.16.4 The Device Path Sub Type is valid.

Reference Document: TBD.
Test description: TD-2.10 Device Path Protocol Test

2.16.5 The Device Path Length is valid.

Reference Document: TBD.
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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 corrently.

Reference Document: 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: 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: 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 as sertions 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: TBD
Test description: TD-2.11.3 Console I/O Test

2.18.2 OutputString succeeds in printing the given unicode string.

Reference Document: TBD
Test description: TD-2.11.3 Console I/O Test

2.18.3 All SIMPLE_TEXT_OUTPUT protocol sevices have non-NULL function pointers.

Reference Document: TBD
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: TBD
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: 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: 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 datawritten to the disk is correct.

Reference Document: 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: 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: 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: 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: 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 perfomed on every accessible block. Verify accessible range is accurate and appropriate. Verify that data written to the disk is correct.

Reference Document: 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: TBD.
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: TBD.
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: TBD.
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: TBD.
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: TBD.
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: TBD.
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: TBD.
Test description: TD-2.14 File System Protocol Test

2.21.8 The file position is at the end of the file.

Reference Document: TBD.
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: TBD.
Test description: TD-2.14 File System Protocol Test

2.21.10 The file position is at the beginning of the file.

Reference Document: TBD.
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: TBD.
Test description: TD-2.14 File System Protocol Test

2.21.12 The file position is at the beginning of the file.

Reference Document: TBD.
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: TBD.
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: TBD.
Test description: TD-2.14 File System Protocol Test

2.21.15 It is not possible to write to a closed file.

Reference Document: TBD.
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: TBD.
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: TBD.
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: TBD.
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: TBD.
Test description: TD-2.14 File System Protocol Test

2.21.20 The root directiry handle can be used to close the root directory.


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: TBD.
Test description: TD-2.15 Load File Protocol Test

2.22.2 The call to LoadFile() succeeds.

Reference Document: TBD.
Test description: TD-2.15 Load File Protocol Test

2.22.3 The number of bytes read by LoadFile() is correct.

Reference Document: TBD.
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: TBD.
Test description: TD-2.15 Load File Protocol Test


Serial IO 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: TBD.
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: TBD.
Test description: TD-2.16 Serial I/O Protocol Test

2.23.3 The serial loopback driver can be reset.

Reference Document: TBD.
Test description: TD-2.16 Serial I/O Protocol Test

2.23.4 The attributes of serial loopback port can be set.

Reference Document: TBD.
Test description: TD-2.16 Serial I/O Protocol Test

2.23.5 The serial loopback port attributes are set correctly.

Reference Document: TBD.
Test description: TD-2.16 Serial I/O Protocol Test

2.23.6 The baud rate in the mode structure is incorrect.

Reference Document: TBD.
Test description: TD-2.16 Serial I/O Protocol Test

2.23.7 The FIFO depth in the mode structure is incorrect.

Reference Document: TBD.
Test description: TD-2.16 Serial I/O Protocol Test

2.23.8 DTR and RTS can be set.

Reference Document: TBD.
Test description: TD-2.16 Serial I/O Protocol Test

2.23.9 DTR and RTS are set correctly.

Reference Document: TBD.
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: TBD.
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: TBD.
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: TBD.
Test description: TD-2.17 Unicode Collation Protocol Test

2.24.2 A handle can be opened to the Unicode Collation.

Reference Document: TBD.
Test description: TD-2.17 Unicode Collation Protocol Test

2.24.3 String “abc” is less than string “xyz”.

Reference Document: TBD.
Test description: TD-2.17 Unicode Collation Protocol Test

2.24.4 String “789” is greater than string “123”.

Reference Document: TBD.
Test description: TD-2.17 Unicode Collation Protocol Test

2.24.5 String “ABC” is equal to string “ABC”.

Reference Document: TBD.
Test description: TD-2.17 Unicode Collation Protocol Test

2.24.6 String :abc” is equal to string “ABC”.

Reference Document: TBD.
Test description: TD-2.17 Unicode Collation Protocol Test

2.24.7 String *def* is found in string “abcdefghij”.

Reference Document: TBD.
Test description: TD-2.17 Unicode Collation Protocol Test

2.24.8 String *DEF* is found in string “abcdefghij”.

Reference Document: TBD.
Test description: TD-2.17 Unicode Collation Protocol Test

2.24.9 String ?b*E?[gz]* is found in string “abcdefghij”.

Reference Document: TBD.
Test description: TD-2.17 Unicode Collation Protocol Test

2.24.10 String ?b*Y?[gz]* is not found in string “abcdefghij”.

Reference Document: TBD.
Test description: TD-2.17 Unicode Collation Protocol Test

2.24.11 String intel8086 can be converted to uppercase.

Reference Document: TBD.
Test description: TD-2.17 Unicode Collation Protocol Test

2.24.12 String “INTEL8086” can be converted to lowercase.

Reference Document: TBD.
Test description: TD-2.17 Unicode Collation Protocol Test

2.24.13 String “intel” equals string “INTEL”.

Reference Document: TBD.
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: TBD.
Test description: TD-2.17 Unicode Collation Protocol Test

2.24.15 The language string has valid languages in it.

Reference Document: TBD.
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: TBD.
Test description: TD-2.18 PXE Base Code Protocol Test

2.25.2 Accessing PXE Basecode Interface.

Reference Document: TBD.
Test description: TD-2.18 PXE Base Code Protocol Test

2.25.3 Setting up and starting the PXE Boot Environment.

Reference Document: TBD.
Test description: TD-2.18 PXE Base Code Protocol Test

2.25.4 DHCP Protocol loaded successfully.

Reference Document: TBD.
Test description: TD-2.18 PXE Base Code Protocol Test

2.25.5 DHCP Discover Protocol executed successfully.

Reference Document: TBD.
Test description: TD-2.18 PXE Base Code Protocol Test

2.25.6 Initiating MTFTP Hand shake.

Reference Document: TBD.
Test description: TD-2.18 PXE Base Code Protocol Test

2.25.7 Downloading remote file over local machine.

Reference Document: TBD.
Test description: TD-2.18 PXE Base Code Protocol Test

2.25.8 Accessing remote file to get file size.

Reference Document: TBD.
Test description: TD-2.18 PXE Base Code Protocol Test

2.25.9 Validity of Remote Image.

Reference Document: TBD.
Test description: TD-2.18 PXE Base Code Protocol Test

2.25.10 Cleaning up the PXE Boot Environment.

Reference Document: TBD.
Test description: TD-2.18 PXE Base Code Protocol Test


Simple_Network Protocol Assertions

The assertions in this section are tested in TD-2.19 Simple_Network Protocol Test.

TBD


WHQL Test Specification

Previous Next

File System Format Assertions

TBD


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: TBD.
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: TBD.
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: TBD.
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: TBD.
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: TBD.
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: TBD.
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: TBD.
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: TBD.
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: TBD.
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

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

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

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

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.

TBD

Results Interpretation

If the test fails in steps 1-7, it fails the test.


TD-2.1.5 Signal Relative Timer Events Test

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 can not 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

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 8. 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 can not 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

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 can not 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

The Memory Allocate Free Pool test verifies that repeated memory allocations and freeings 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 small.
  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

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

The Memory Allocate Free Pages test verifies that repeated memory allocations and freeings 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

The Memory Allocate Free Pages Below 8MB test verifies that repeated memory allocations and freeings 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

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

The Memory Allocate Free Pages at Address test verifies that repeated memory allocations and freeings 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

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 a 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

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, 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

The Protocols Consistency test performs consistency checks on the following EFI protocol services: InstallProtocolInterface, UnInstallProtocolInterface, ReinstallProtocolInterface, LocateHandle, HandleProtocol, 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 the services that attempts to use the service with various combinations of either 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 all have non NULL function pointers. An assertion failure is generate otherwise.
  2. InstallProtocolInterface is invoked 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), with an invalid interface type, a spurious device handle.
  3. InstallProtocolInterface is invoked with all valid parameters and checked for a successful installation of a specific protocol on a specific handle.
  4. LocateHandle is invoked several times, once each with all valid parameters, but: a NULL GUID, an uninstalled protocol’s GUID, an invalid search type.
  5. LocateHandle is invoked 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 invoked several times, once each with all valid parameters, but without: a NULL GUID, a spurious GUID, a spurious old-protocol interface, a NULL new protocol interface.
  8. ReinstallProtocolInterface is invoked with all valid parameters and checked for a successful installation.
  9. UninstallProtocolInterface is invoked 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 invoked 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.

TBD

Results Interpretation

TBD


TD-2.3.2 Protocol Services Test

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

TBD


TD-2.3.3 Register Protocol Notify Test

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 also keeps count of the number of times 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() boottime 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

TBD


TD-2.3.4 Nested Protocol Notify Test

TBD

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

TBD

Results Interpretation

TBD


TD-2.3.5 Protocol Install Notify Test

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.

TBD

Results Interpretation

TBD


TD-2.3.6 Multiple Protocol Install Test

TBD

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

TBD

Results Interpretation

TBD


TD-2.3.7 Required Protocols Present Test

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 failtures 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

TBD


TD-2.4 Image Services Tests

The tests in this section include:


TD-2.4.1 LoadImage Test

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

TBD


TD-2.4.2 ImageStart Test

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

TBD


TD-2.4.3 MultipleLoadStart Test

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

TBD


TD-2.4.4 LoadMemoryImage Test

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

TBD


TD-2.4.5 Runtime Services Test

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 both at 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 both at 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 both at 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 both at 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 both at 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 both at 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. Assertions still TBD.

  • 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

TBD


TD-2.5 Variable Services Tests

The tests in this section include:


TD-2.5.1 NV_Variables Test

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

TBD


TD-2.5.2 MandatoryVSVariables Test

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

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

TBD


TD-2.6 Time Services Test

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, 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

TBD


TD-2.7 Virtual Memory Services Test

TBD


TD-2.8 Miscellaneous Services

This section includes the following tests:


TD-2.8.1 SystemReset Test

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

TBD


TD-2.8.2 MonotonicCountCheck Test

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, andthe 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

TBD


TD-2.8.3 WatchDogTimer Test

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.9 EFI Image (LOADED_IMAGE Protocol) Tests

TBD


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

TBD


TD-2.11 Device I/O Protocol Tests

The tests in this section include:


TD-2.11.1 Device I/O Test

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 of 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

TBD


WHQL Test Specification

Previous Next

TD-2.11.2 Console I/O Protocol

TBD


TD-2.11.3 Console I/O Test

This test 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. 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.

TBD

Results Interpretation

TBD


TD-2.12 Block I/O Protocol Test

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 and 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 and 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 of 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 and 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 and 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

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 and 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 and 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 of 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 and 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 and 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

TBD


TD-2.14 File System Protocol Test

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

TBD


TD-2.15 Load File Protocol Test

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 Testrequire 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

TBD


TD-2.16 Serial I/O Protocol Test

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 connectior(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 are 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

TBD


TD-2.17 Unicode Collation Protocol Test

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

TBD


TD-2.18 PXE Base Code Protocol Test

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, 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

TBD


TD-2.19 Simple_Network Protocol Test

TBD


WHQL Test Specification

Previous Next

TD-2.20 File System Format Test

TBD


TD-2.21 Boot Manager Variables Test

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 seqeunce 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 and 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

TBD


Chapter 3: Advanced Configuration and Power Interface Test Specification

Draft Version: 0.7 — Date: February 12, 2001

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. This section includes an overview of each test and reference hardware, BIOS, test results interpretation instructions, and a list of outstanding issues for each test.


Reference Document Sources for ACPI Assertions

Hardware and BIOS functional requirements specified in the following documents:

  • Advanced Configuration and Power Interface Specification, Revision 1.0, 1.0(a) and 1.0b,
    http://www.teleport.com/~acpi/

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.pcdesguide.org/library/http://www.pcdesguide.org/library/(@http://www.pcdesguide.org/library/)
  • 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)
TD-3.11 Legacy / ACPI State Transition (ACPILAST)
TD-3.14 ACPI Power Button and Sleep Button (ACPIPBT)
TD-3.15 ACPI Power Management Timer (ACPIPMT)
TD-3.18 ACPI Sleep Wake Control (ACPISWCT)

Also, see “ACPI Assertions Not Tested” for a list of the register hardware assertions to implement ACPI that are not tested.

[CLARIFIED v.0.7 - add WLP# references]

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 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 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)

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)

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 [CLARIFIED v.0.5] 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 Power Button and Sleep Button (ACPIPBT) and TD-3.15 ACPI 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 Power Button and Sleep Button (ACPIPBT) and TD-3.15 ACPI 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 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 Power Button and Sleep Button (ACPIPBT), TD-3.18 ACPI Sleep Wake Control (ACPISWCT)


ACPI Processor Hardware Assertions

The following processor hardware assertions implement ACPI. These assertions are tested in TD-3.3 ACPI Processor Power State Transition (ACPIPPST) and TD-3.26 Unique P_BLK Test.
[CLARIFIED v.0.7 - added WLP#]

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 [NEW 0.5] Multi-processor systems implement multi-processor configuration support with an 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 Unique P_BLK Test


ACPI Device Hardware Assertions

The following device hardware assertions implement ACPI.

These assertions are tested in TD-3.5 ACPI Device Power Management (ACPIDPMT).
[CLARIFIED v.0.7 - added WLP #]

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 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 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 Docking and Undocking Test (ACPIDOCK).

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: [CLARIFIED v.0.7] WLP# - A1.1.2; A1.4.2; ACPI Specification, Revision 1.0b, Sections 3.7 and 4.5.
Test description: TD-3.4 ACPI Docking and 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 Smart Battery Interface Test (ACPISBIT) and TD-3.2 ACPI Control Method Battery Interface Test (ACPICMB).
[CLARIFIED v.0.7 - added WLP#]

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 Smart Battery Interface Test (ACPISBIT)

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 Smart Battery Interface Test (ACPISBIT)

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 Smart Battery Interface Test (ACPISBIT)

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 Smart Battery Interface Test (ACPISBIT)

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 Smart Battery Interface Test (ACPISBIT)

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 Smart Battery Interface Test (ACPISBIT)

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 Smart Battery Interface Test (ACPISBIT)

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 Smart Battery Interface Test (ACPISBIT)

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 Smart Battery Interface Test (ACPISBIT)

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 Smart Battery Interface Test (ACPISBIT)

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 Smart Battery Interface Test (ACPISBIT)

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 Smart Battery Interface Test (ACPISBIT)

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 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 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 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 Smart Battery Interface Test (ACPISBIT)

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 Smart Battery Interface Test (ACPISBIT)

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 Smart Battery Interface Test (ACPISBIT)

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 Smart Battery Interface Test (ACPISBIT)

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 Smart Battery Interface Test (ACPISBIT)

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 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.

[CLARIFIED v.0.7 - added WLP#]

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)

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)

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 Lid Switch (ACPILID)


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 Legacy / ACPI State Transition (ACPILAST)

[CLARIFIED v.0.7 - added WLP#]

3.7.1 [CLARIFIED v.0.5] 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 [CLARIFIED v.0.5] 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 Power Button and Sleep Button (ACPIPBT).

[CLARIFIED v.0.7 - added WLP #]

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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 Power Management Timer (ACPIPMT).

[CLARIFIED v.0.7 - added WLP#]

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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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).

[CLARIFIED v.0.7 - added WLP#]

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

3.10.72 [NEW v.0.5] 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 [NEW v.0.5] 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)


ACPI Resource Configuration Hardware Assertions

The following resource configuration hardware assertions implement ACPI.

These assertions are tested in TD-3.16 ACPI Resource Configuration Test (ACPIRCT) and TD-3.29 Docking Test.

[CLARIFIED v.0.7 — added WLP#]

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

3.11.7 [NEW v.0.5] 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 Docking and Undocking Test (ACPIDOCK)

[CLARIFIED v.0.7 — added WLP#]

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 Docking and 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 Docking and 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) and TD-3.26 Unique P_BLK Test

[CLARIFIED v.0.7 — added WLP#]

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 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 an 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 an 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 [CLARIFIED v.0.5] 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 Table and Name Space Dump (ACPIDUMP).

[CLARIFIED v.0.7 — added WLP#]

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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space Dump (ACPIDUMP)

3.14.5 [CLARIFIED v.0.5] Each register in the general-purpose register block is 32-bit aligned.

Reference document: [CLARIFIED v.0.7] WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Section 4.7.4.1.
Test description: TD-3.6 ACPI Table and Name Space Dump (ACPIDUMP)


Various ACPI Register Hardware Assertions

The following register hardware assertions implement ACPI.

These assertions are tested in:
TD-3.11 Legacy / ACPI State Transition (ACPILAST)
TD-3.14 ACPI Power Button and Sleep Button (ACPIPBT)
TD-3.15 ACPI Power Management Timer (ACPIPMT)
TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

[CLARIFIED v.0.7 — added WLP#]

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)

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 Power Button and Sleep Button (ACPIPBT), TD-3.15 ACPI Power Management Timer (ACPIPMT) and TD-3.16 ACPI Resource Configuration Test (ACPIRCT)


Unconnected Interrupt Assertion

This register hardware assertion is used to implement ACPI. This assertion is tested by the ACPI Hardware Assertions Checklist.

[CLARIFIED v.0.7 — added WLP#]

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

[CLARIFIED v.0.7 — added WLP#]

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)

[CLARIFIED v.0.7 — added WLP#]

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)


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 Table and Name Space Dump (ACPIDUMP) and TD-3.23 ACPI BIOS Assertion Checklist

[CLARIFIED v.0.7 — added WLP#]

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 Table and Name Space 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 Table and Name Space 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 Control Method Battery Interface Test (ACPICMB) and TD-3.9 ACPI Smart Battery Interface Test (ACPISBIT)

[CLARIFIED v.0.7 — added WLP#]

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 Control Method Battery Interface Test (ACPICMB) and TD-3.9 ACPI Smart Battery Interface Test (ACPISBIT)

3.20.2 [CLARIFIED v.0.5] 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 Smart Battery Interface Test (ACPISBIT)

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 Smart Battery Interface Test (ACPISBIT)

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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 Smart Battery Interface Test (ACPISBIT)

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 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 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 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 Smart Battery Interface Test (ACPISBIT)

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 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 Smart Battery Interface Test (ACPISBIT)

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 Smart Battery Interface Test (ACPISBIT)

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 Smart Battery Interface Test (ACPISBIT)

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 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 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 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 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 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 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 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 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 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 Control Method Battery Interface Test (ACPICMB)

3.20.40 [NEW v.0.5] 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)

[CLARIFIED v.0.7 — added WLP#]

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 [CLARIFIED v.0.5] 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 [CLARIFIED v.0.5] 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 [CLARIFIED v.0.5] 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).

[CLARIFIED v.0.7 — added WLP#]

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 Processor Throttling (CPUTHRTL)


ACPI Docking and Undocking BIOS Assertions

The following docking and undocking BIOS assertions implement ACPI.

These assertions are tested in TD-3.4 ACPI Docking and Undocking Test (ACPIDOCK) and TD-3.29 Docking Test

[CLARIFIED v.0.7 — added WLP#]

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 Docking and 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 Docking and 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 Docking and 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 Docking and 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 Docking and 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 Docking and 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 Docking and 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 Docking and 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 Docking and 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 Docking and 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 Docking and 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 Docking and 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 Docking and Undocking Test (ACPIDOCK)

3.23.14 [NEW v.0.5] 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

3.23.15 [NEW v.0.5] 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


ACPI Device Power Management BIOS Assertions

The following device power management BIOS assertions implement ACPI.

These assertions are tested in TD-3.5 ACPI Device Power Management (ACPIDPMT)

[CLARIFIED v.0.7 — added WLP#]

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 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 Device Power Management (ACPIDPMT)

3.24.3 [CLARIFIED v.0.5] 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 Table and Name Space Dump (ACPIDUMP)
TD-3.24 Reserved Name Usage Test
TD-3.28 USB Root Hub _ADR Test

[CLARIFIED v.0.7 — added WLP#]

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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space 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 Table and Name Space Dump (ACPIDUMP)

3.25.70 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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

3.25.73 [NEW v.0.5] 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 Interrupt 15h Function E820h System Address Map (I15_E820).

[CLARIFIED v.0.7 — added WLP#]

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 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 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 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 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 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 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 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 APICs.

Reference document: WLP# - A1.1.2; ACPI Specification, Revision 1.0a, Sections 14.1 and 14.2.
Test description: TD-3.21 ACPI 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 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 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 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 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 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 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 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 Test (ACPIECIT).

[CLARIFIED v.0.7 — added WLP#]

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 Test (ACPIECIT)

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 Test (ACPIECIT)

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 Test (ACPIECIT)

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 Test (ACPIECIT)

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 Test (ACPIECIT)

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 Test (ACPIECIT)

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 Test (ACPIECIT)

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 Test (ACPIECIT)

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 Test (ACPIECIT)

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 Test (ACPIECIT)

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 Test (ACPIECIT)

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 Test (ACPIECIT)

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 Test (ACPIECIT)

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 Test (ACPIECIT)

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 Test (ACPIECIT)


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).

[CLARIFIED v.0.7 — added WLP#]

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 [NEW v.0.5] 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 Docking and Undocking Test (ACPIDOCK).

[CLARIFIED v.0.7 — added WLP#]

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 Docking and 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 Docking and 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 Docking and 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 Docking and 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 Docking and 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 Docking and 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 Docking and 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 Docking and 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 Docking and 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 Docking and 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 Docking and 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 Docking and 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 Docking and 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 Docking and Undocking Test (ACPIDOCK)

3.29.15 Devices that have a _EJD object cannot have any _EJx control methods.

[INVALID; CLARIFIED v.0.7]

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 Docking and 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 Docking and 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 Docking and 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 Docking and 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 Docking and 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 Legacy / ACPI State Transition (ACPILAST).

[CLARIFIED v.0.7 — added WLP#]

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 Legacy / ACPI State Transition (ACPILAST)

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 Legacy / ACPI State Transition (ACPILAST)

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 Legacy / ACPI State Transition (ACPILAST)

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 Legacy / ACPI State Transition (ACPILAST)

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 Legacy / ACPI State Transition (ACPILAST)

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 Legacy / ACPI State Transition (ACPILAST)

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 Legacy / ACPI State Transition (ACPILAST)

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 Legacy / ACPI State Transition (ACPILAST)

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 Legacy / ACPI State Transition (ACPILAST)

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 Legacy / ACPI State Transition (ACPILAST)

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 Legacy / ACPI State Transition (ACPILAST)


ACPI Lid Switch BIOS Assertions

The following ACPI lid switch BIOS assertions implement ACPI.

These assertions are tested in TD-3.12 ACPI Lid Switch (ACPILID).

[CLARIFIED v.0.7 — added WLP#]

3.31.1 [CLARIFIED v.0.5] 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 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 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 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 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 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 Interrupt Routing Table (ACPIIRT).

[CLARIFIED v.0.7 — added WLP#]

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 Interrupt Routing Table (ACPIIRT)

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 Interrupt Routing Table (ACPIIRT)

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 Interrupt Routing Table (ACPIIRT)

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 Interrupt Routing Table (ACPIIRT)

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 Interrupt Routing Table (ACPIIRT)

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 Interrupt Routing Table (ACPIIRT)

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 Interrupt Routing Table (ACPIIRT)

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 Interrupt Routing Table (ACPIIRT)

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 Interrupt Routing Table (ACPIIRT)

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 Interrupt Routing Table (ACPIIRT)

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 Interrupt Routing Table (ACPIIRT)

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 Interrupt Routing Table (ACPIIRT)

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 Interrupt Routing Table (ACPIIRT)

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 Interrupt Routing Table (ACPIIRT)

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 Interrupt Routing Table (ACPIIRT)

3.32.16 [NEW v.0.5] 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 Power Management Timer (ACPIPMT).

[CLARIFIED v.0.7 — added WLP#]

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 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 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 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).

[CLARIFIED v.0.7 — added WLP#]

3.34.1 [CLARIFIED v.0.5] 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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)

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 Test (ACPIRCT)


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).

[CLARIFIED v.0.7 — added WLP#]

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

3.35.20 [NEW v.0.5] 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)

[CLARIFIED v.0.7 — added WLP#]

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)

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)

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)

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)

3.36.5 [CLARIFIED v.0.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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

3.36.27 [CLARIFIED v.0.5] 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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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 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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)


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) and TD-3.25 Thermal Model Test and TD-3.27_BBN Resolution Test.

[CLARIFIED v.0.7 — added WLP#]

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)

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)

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)

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)

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)

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)

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)

3.37.8 [CLARIFIED v.0.5] 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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

3.37.21 [NEW v.0.5] 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 [NEW v.0.5] 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

3.37.23 [NEW v.0.5] 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

3.37.24 [NEW v.0.5] 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


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

[CLARIFIED v.0.7 — added WLP#]

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 [NEW v.0.5] 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 [NEW v.0.5] 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_BBN Resolution Test

3.38.24 [NEW v.0.5] 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 Test (ACPIECIT) and TD-3.9 ACPI Smart Battery Interface Test (ACPISBIT).

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/.

[CLARIFIED v.0.7 — added WLP#]

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 Smart Battery Interface Test (ACPISBIT)

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 Smart Battery Interface Test (ACPISBIT)
(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 Smart Battery Interface Test (ACPISBIT)
(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 Smart Battery Interface Test (ACPISBIT)
(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 Smart Battery Interface Test (ACPISBIT)

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 Smart Battery Interface Test (ACPISBIT)
(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 Test (ACPIECIT)

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 Test (ACPIECIT)

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 Test (ACPIECIT)

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 Test (ACPIECIT)

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 Test (ACPIECIT)

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 Test (ACPIECIT)

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 Test (ACPIECIT)

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 Smart Battery Interface Test (ACPISBIT)

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 Smart Battery Interface Test (ACPISBIT)

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 Smart Battery Interface Test (ACPISBIT)

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 Smart Battery Interface Test (ACPISBIT)
(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 Smart Battery Interface Test (ACPISBIT)

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 Test (ACPIECIT)

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 Test (ACPIECIT)

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 Test (ACPIECIT)

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 Test (ACPIECIT)

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 Test (ACPIECIT)

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 Test (ACPIECIT)

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 Test (ACPIECIT)

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 Test (ACPIECIT)

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 Test (ACPIECIT)

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 Test (ACPIECIT)

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 Test (ACPIECIT)

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 Test (ACPIECIT)

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 Test (ACPIECIT)


ACPI Register Implementation Hardware Assertions Not Tested

The following lists the remaining register hardware assertions to implement ACPI that are not tested.

[CLARIFIED v.0.7 — added WLP#]

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 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.

[CLARIFIED v.0.7 — added WLP#]

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.

[NEW v.0.5] – All assertions in this section are new.

[CLARIFIED v.0.7 — added WLP#]

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

[CLARIFIED v.0.7 — added WLP#]

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 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

[NEW v.0.3] – All assertions in this section are new.

[CLARIFIED v.0.7 — added WLP#]

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

[NEW v.0.3] – All assertions in this section are new.

[CLARIFIED v.0.7 — added WLP#]

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: [CLARIFIED v.0.7] 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

[NEW v.0.5] – All assertions in this section are new.

[CLARIFIED v.0.7 — added WLP#]

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

[NEW v0.5] – All assertions in this section are new

[CLARIFIED v.0.7 — added WLP#]

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


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

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

TBD

Results Interpretation

TBD


TD-3.2 ACPI Control Method Battery Interface Test (ACPICMB)

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

TBD

Results Interpretation

TBD


TD-3.3 ACPI Processor Power State Transition (ACPIPPST)

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 Docking and Undocking Test (ACPIDOCK)

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

TBD

Results Interpretation

TBD


TD-3.5 ACPI Device Power Management (ACPIDPMT)

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 Table and Name Space Dump (ACPIDUMP)

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 Test (ACPIECIT)

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)

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 Smart Battery Interface Test (ACPISBIT)

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

TBD

Results Interpretation

TBD


TD-3.10 ACPI Interrupt Routing Table (ACPIIRT)

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 Legacy / ACPI State Transition (ACPILAST)

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 Lid Switch (ACPILID)

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

TBD

Results Interpretation

TBD


TD-3.13 ACPI Multi-Processor Table (ACPIMPT)

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 Power Button and Sleep Button (ACPIPBT)

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 Power Management Timer (ACPIPMT)

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 Test (ACPIRCT)

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)

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 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)

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)

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 Processor Throttling (CPUTHRTL)

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 Interrupt 15h Function E820h System Address Map (I15_E820)

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

[NEW v.0.5]

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 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 create 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 Whistler.

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

[NEW v.0.5]

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 create 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

TBD

Results Interpretation

TBD


TD-3.26 Unique P_BLK Test

[NEW v.0.5]

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 create 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

TBD

Results Interpretation

TBD


TD-3.27_BBN Resolution Test

[NEW v.0.5]

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 create internal ACPI namespace

3. Search for multiple devices with an _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

TBD

Results Interpretation

TBD


TD-3.28 USB Root Hub _ADR Test

[NEW v.0.5]

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 create 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

TBD

Results Interpretation

TBD


TD-3.29 Docking Test

[NEW v.0.5]

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 create 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

TBD

Results Interpretation

TBD


TD-3.30 Video Extensions Test

[NEW v.0.5]

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 create 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

TBD

Results Interpretation

TBD


TD-3.31 Power Button - Sleep State Test

[NEW v.0.5]

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


Chapter 4: PCI Test Specification

Draft Version: 0.7 — Date: February 12, 2001

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 Whistler.

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/specs/PMref/

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 Whistler 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.pcdesguide.org/library/http://www.pcdesguide.org/library/(@http://www.pcdesguide.org/library/)

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

http://www.pcisig.com/developers/specification/

PCI IDE Controller Specification, Revision 1.0

http://www.pcisig.com/developers/docs/

PCI Local Bus Specification, Revision 2.2 (PCI 2.2)

http://www.pcisig.com/developers/specification/

Platform PCI Compliance Test Adapter, External Design Specification

http://www.systemtest.org/specs/(@http://www.systemtest.org/specs/http://www.systemtest.org/specs/(@http://www.systemtest.org/specs/)


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 Whistler.

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 Whistler—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: 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: 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: 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: 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: 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: 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: 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 [NEW v.0.5] PCI-To-PCI Bridge devices must support the PCI power management register interface.

Reference documents: [CLARIFIED v.0.80a] 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 Whistler— 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: 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: 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: 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: 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: 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 Whistler— 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: 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 [CLARIFIED v.0.5] 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: 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: 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: 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: 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 [CLARIFIED v.0.5] The DSI bit (bit 5) indicates whether special initialization of this function is required. This bit is read only.

Reference document: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 Whistler— 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 Whistler— inTD-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: 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: 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: 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: 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: 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: 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: 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 Whistler—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: 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: 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: 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: 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: 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: 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 Whistler—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: [CLARIFIED - v.0.8a] 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: [CLARIFIED - v.0.8a] 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: [CLARIFIED - v.0.8a] 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: [CLARIFIED - v.0.8a] 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: [CLARIFIED - v.0.8a] 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: [CLARIFIED - v.0.8a] 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: [CLARIFIED - v.0.8a] 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: [CLARIFIED - v.0.8a] 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 and D3 Cold states.

Reference document: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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

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: 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: 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: PCI 2.1 Specification, ECN.
Test description: TD-4.3 PCI Maximum Completion Time Test (PCIMCT)

4.14.4 [CLARIFIED] 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: 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: 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: 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: 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: Reference not specified
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 Multiple PME# Assertion Test (PCIPME2).

4.16.1 System software must enable PCI functions before asserting the PME# signal.

Reference document: PCI Bus Power Management 1.1 Specification, Section 7.
Test descriptions: TD-4.7 PCI PME# Signal Routing Test (PCIPME1)and
TD-4.8 Multiple PME# Assertion Test (PCIPME2)

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: 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 Multiple PME# Assertion Test (PCIPME2)

4.16.3 Software must enable the PME# signal by setting the PME_En bit in the PMCSR Register.

Reference document: 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 Multiple PME# Assertion Test (PCIPME2)

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: 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 Multiple PME# Assertion Test (PCIPME2)

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: 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 Multiple PME# Assertion Test (PCIPME2)

4.16.6 The PME# signal is an optional open-drain, active low signal.

Reference document: PCI Bus Power Management 1.1 Specification, Section 7.
Test descriptions: TD-4.7 PCI PME# Signal Routing Test (PCIPME1)and
TD-4.8 Multiple PME# Assertion Test (PCIPME2)

4.16.7 The PME# signal must be assigned to pin 14A of the standard PCI connector.

Reference document: PCI Bus Power Management 1.1 Specification, Section 7.
Test descriptions: TD-4.7 PCI PME# Signal Routing Test (PCIPME1)and
TD-4.8 Multiple PME# Assertion Test (PCIPME2)

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: 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 Multiple PME# Assertion Test (PCIPME2)

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: 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 Multiple PME# Assertion Test (PCIPME2)

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: 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 Multiple PME# Assertion Test (PCIPME2)

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: 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 Multiple PME# Assertion Test (PCIPME2)

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: 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 Multiple PME# Assertion Test (PCIPME2)

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: 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 Multiple PME# Assertion Test (PCIPME2)

4.16.14 The system software must be able to service multiple PME# signals that different functions generate simultaneously.

Reference document: PCI Bus Power Management 1.1 Specification, Section 8.4.1.
Test descriptions: TD-4.8 Multiple PME# Assertion Test (PCIPME2)

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: 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 Multiple PME# Assertion Test (PCIPME2)


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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 Vaux Auxiliary Power Test (PCIVAUX).

4.18.1 A 3.3Vaux power supply must be present whenever AC power is applied to the system.

Reference document: PCI Bus Power Management 1.1 Specification, Section 7.
Test description: TD-4.10 PCI 3.3 Vaux Auxiliary Power Test (PCIVAUX)

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: PCI Bus Power Management 1.1 Specification, Section 7.2.
Test description: TD-4.10 PCI 3.3 Vaux Auxiliary Power Test (PCIVAUX)

4.18.3 Power-managed systems that support PME# generation while in D3 Cold state require an auxiliary power source.

Reference document: PCI Bus Power Management 1.1 Specification, Section 7.2.
Test description: TD-4.10 PCI 3.3 Vaux Auxiliary Power Test (PCIVAUX)

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: PCI Bus Power Management 1.1 Specification, Section 7.2.1.
Test description: TD-4.10 PCI 3.3 Vaux Auxiliary Power Test (PCIVAUX)

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: PCI Bus Power Management 1.1 Specification, Section 7.2.1.
Test description: TD-4.10 PCI 3.3 Vaux Auxiliary Power Test (PCIVAUX)

4.18.6 If 3.3Vaux power is supported, it must be routed to all PCI slots on the motherboard.

Reference document: PCI Bus Power Management 1.1 Specification, Section 7.2.1.
Test description: TD-4.10 PCI 3.3 Vaux Auxiliary Power Test (PCIVAUX)

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: PCI Bus Power Management 1.1 Specification, Section 7.2.2.
Test description: TD-4.10 PCI 3.3 Vaux Auxiliary Power Test (PCIVAUX)

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: PCI Bus Power Management 1.1 Specification, Section 7.2.2.
Test description: TD-4.10 PCI 3.3 Vaux Auxiliary Power Test (PCIVAUX)

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: PCI Bus Power Management 1.1 Specification, Section 7.2.2.
Test description: TD-4.10 PCI 3.3 Vaux Auxiliary Power Test (PCIVAUX)

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: PCI Bus Power Management 1.1 Specification, Section 7.2.1.
Test description: TD-4.10 PCI 3.3 Vaux Auxiliary Power Test (PCIVAUX)

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: PCI Bus Power Management 1.1 Specification, Section 7.3.1.
Test description: TD-4.10 PCI 3.3 Vaux Auxiliary Power Test (PCIVAUX)

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: PCI Bus Power Management 1.1 Specification, Section 7.3.1.
Test description: TD-4.10 PCI 3.3 Vaux Auxiliary Power Test (PCIVAUX)

4.18.13 The system must be capable of delivering up to 66mW (20mA @ 3.3VDC) to each disabled PCI expansion slot.

Reference document: PCI Bus Power Management 1.1 Specification, Section 7.3.1.
Test description: TD-4.10 PCI 3.3 Vaux Auxiliary Power Test (PCIVAUX)

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: PCI Bus Power Management 1.1 Specification, Section 7.4.1.
Test description: TD-4.10 PCI 3.3 Vaux Auxiliary Power Test (PCIVAUX)

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: PCI Bus Power Management 1.1 Specification, Section 5.6.
Test description: TD-4.10 PCI 3.3 Vaux Auxiliary Power Test (PCIVAUX)

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: PCI Bus Power Management 1.1 Specification, Section 5.6.
Test description: TD-4.10 PCI 3.3 Vaux Auxiliary Power Test (PCIVAUX)

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: PCI Bus Power Management 1.1 Specification, Section 5.6.
Test description: TD-4.10 PCI 3.3 Vaux Auxiliary Power Test (PCIVAUX)

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: PCI Bus Power Management 1.1 Specification, Section 5.6.
Test description: TD-4.10 PCI 3.3 Vaux Auxiliary Power Test (PCIVAUX)

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: PCI Bus Power Management 1.1 Specification, Section 5.6.
Test description: TD-4.10 PCI 3.3 Vaux Auxiliary Power Test (PCIVAUX)


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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: [CLARIFIED v.0.80a] 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: [CLARIFIED v.0.80a] 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: [CLARIFIED v.0.80a] 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: [CLARIFIED v.0.80a] 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: [CLARIFIED v.0.80a] 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 an 3.3Vaux-enabled system must range from 3.0V-3.6V.

Reference document: [CLARIFIED v.0.80a] 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: [CLARIFIED v.0.80a] 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: 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: 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: 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: 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: [CLARIFIED v.0.80a] 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: [CLARIFIED v.0.80a] 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: [CLARIFIED v.0.80a] 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: [CLARIFIED v.0.80a] WLP#-B6.1.5.9; PC 2001 System Design Guide - MOD-0381, PC 99 System Design Guide - 19.38.
Test descriptions: WLP# -B1.4.5; 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: [CLARIFIED v.0.80a] 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: [CLARIFIED v.0.80a] 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: [CLARIFIED v.0.80a] 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: [CLARIFIED v.0.80a] 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 Config Space Header Assertions

These assertions are tested in TD-4.29 PCITest.exe Test.

General Assertions

4.26.1 [NEW v.0.55] 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 PCITest.exe Test

4.26.2 [NEW v.0.55] 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 PCITest.exe Test

Interrupt Setting Assertions

4.27.1 [NEW v.0.5] 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: PCI 2.2 Specification section 6.2.4.
Test Description: TD-4.29 PCITest.exe Test

4.27.2 [NEW v.0.55] 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: PCI Local Bus Specification 2.2 Section 6.2.4 (see footnote #43).
Test Description: TD-4.29 PCITest.exe Test

Vendor ID / Device ID / Subsystem Vendor ID / Subsystem Device ID assertions

4.29.1 [NEW v.0.5] Support for the Subsystem Device ID and Subsystem Vendor ID registers requires nonzero values to be populated for both of these registers.

Reference Documents: [CLARIFIED v.0.80a] PC 2001 System Design Guide, Section, PCI-0126, PC 99 System Design Guide, ECN Section 9.11.
Test Description: TD-4.29 PCITest.exe Test

4.29.2 [NEW v.0.55] Each subsystem ID register must be Read Only.

Reference Documents: [CLARIFIED v.0.80a] PC 2001 System Design Guide - PCI-0126, PC 99 System Design Guide - Section 9.11.
Test Description: TD-4.29 PCITest.exe Test


PCI Base Address Register Assertions

These assertions are tested in TD-4.29 PCITest.exe Test.

I/O Base Address Register Assertions

4.30.1 [NEW v.0.55] For I/O Base Address Registers, bit 1 is reserved and must return 0.

Reference Documents: PCI Local Bus Specification 2.2 Section 6.2.5.1
Test Description: TD-4.29 PCITest.exe Test

4.30.2 [NEW v.0.55] Devices that map control functions into I/O space must not consume more than 256 bytes per I/O Base Address Register.

Reference Documents: PCI Local Bus Specification 2.2 Section 6.2.5.1
Test Description: TD-4.29 PCITest.exe Test

Memory Base Address Register Assertions

4.31.1 [NEW v.0.55] The PCI memory range specified for this BAR is invalid if the ending address is smaller than the beginning address.

Reference Documents: PCI Local Bus Specification 2.2 Section 6.2.5.1
Test Description: TD-4.29 PCITest.exe Test

4.31.2 [NEW v.0.55] 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: PCI Local Bus Specification 2.2 Section 6.2.5.1
Test Description: TD-4.29 PCITest.exe Test

PCI IDE Specific Assertions

4.32.1 [NEW v.0.55] 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: PCI IDE Specification 1.0 Section 2.3.
Test Description: TD-4.29 PCITest.exe Test

4.32.2 [NEW v.0.55] 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: PCI IDE Specification 1.0 Section 2.3.
Test Description: TD-4.29 PCITest.exe Test

4.32.3 [NEW v.0.5] 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: PCI IDE Specification 1.0 Section 2.3.
Test Description: TD-4.29 PCITest.exe Test

4.32.4 [NEW v.0.55] 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: PCI IDE Specification 1.0 Section 2.3.
Test Description: TD-4.29 PCITest.exe Test


PCI Power Management Register Assertions

These assertions are tested in TD-4.29 PCITest.exe Test.

Capability Pointer Assertions

4.33.1 [NEW v.0.55] The value returned from the Device Capability Identifier must be a SIG assigned ID code.

Reference Documents: PCI Local Bus Specification 2.2 Appendix H.
Test Description: TD-4.29 PCITest.exe Test

4.33.2 [NEW v.0.5] Each Capability Pointer in the Capabilities list must be DWORD aligned.

Reference Documents: PCI Local Bus Specification 2.2 Section 6.7
Test Description: TD-4.29 PCITest.exe Test

4.33.3 [NEW v.0.55] The Device Capabilities pointer must not point to the first 40 bytes of PCI config space, which is reserved for the header, and must allow for at least 8 bytes at the end of config space (the Capability structure is 8 bytes long).

Reference Documents: PCI Power Management Specification 1.1 Section 3.1
Test Description: TD-4.29 PCITest.exe Test

Power Management Control Block Assertions

4.34.1 [NEW v.0.55] 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: PCI Power Management Specification 1.1 Section 3.2.3
Test Description: TD-4.29 PCITest.exe Test

4.34.2 [NEW v.0.55] 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: PCI Power Management Interface Specification 1.1 section 3.2
Test Description: TD-4.29 PCITest.exe Test

4.34.3 [NEW v.0.55] The 16-bit Power Management Capabilities register must be Read Only.

Reference Documents: PCI Power Management Specification 1.1 Section 3.2.3.
Test Description: TD-4.29 PCITest.exe Test

4.34.4 [NEW v.0.5] 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.

Referring Document: PCI Power Management Specification 1.1 Section 3.2.3.
Test Description: TD-4.29 PCITest.exe Test

4.34.5 [NEW v.0.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: PCI Power Management Specification 1.1, Section 3.2.3.
Test Description: TD-4.29 PCITest.exe Test

4.34.6 [NEW v.0.5] 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: PCI Power Management Specification 1.1 section 8.1.
Test Description: TD-4.29 PCITest.exe Test

4.34.7 [NEW v.0.5] The device has bit 0 of the Command Register (I/O enable) set, but it is read only.

Reference Documents: PCI Local Bus Specification 2.2 section 6.2.2.
Test Description: TD-4.29 PCITest.exe Test

4.34.8 [NEW v.0.5] The device has bit 1 of the Command Register (Memory Enable) set, but it is read only.

Reference Documents: PCI Local Bus Specification 2.2 section 6.3.3.
Test Description: TD-4.29 PCITest.exe Test

4.34.9 [NEW v.0.5] 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: PCI Power Management Specification 1.1, Section 3.2.3.
Test Description: TD-4.29 PCITest.exe Test

4.34.10 [NEW v.0.5] Bit 15 in the Power Management Capabilities register was not Read Only.

Reference Documents: PCI Power Management Specification 1.1, Section 3.2.3.
Test Description: TD-4.29 PCITest.exe Test

4.34.11 [NEW v.0.5] The indicated bits in the Power Management Control Block were not read only.

Reference Documents: PCI Power Management Specification 1.1, Section 3.2.3.
Test Description: TD-4.29 PCITest.exe 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 me 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 Whistler.

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 Whistler.

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.

PCISID requires a target platform that implements a PCI 2.1-based bus. The target platform must also be ACPI-compliant.

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)

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)

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)

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)

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 an 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)

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.

To avoid conflicts, the PCIPME1 test requires the operating system to be configured to not use ACPI mode. 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 Multiple PME# Assertion Test (PCIPME2)

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).”


TD-4.9 PCI Device Wake-up Test (PCIWAKE)

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 Vaux Auxiliary Power Test (PCIVAUX)" 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.

To avoid conflicts, the PCIWAKE test requires that the operating system be configured to not use ACPI mode. 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 Vaux Auxiliary Power Test (PCIVAUX)

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 Vaux Auxiliary Power Test (PCIVAUX)" 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.

To avoid conflicts, the PCIVAUX test requires that the operating system be configured to not use ACPI mode. 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)

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)

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

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 Me.

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

[CLARIFIED v.0.5]
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 Me 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 FltSim) Switch test (S3 state).

a. Launch Microsoft Combat Fltsim 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

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 FltSim) Switch test (S3 state).

a. Launch Microsoft Combat Fltsim 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 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

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 Me.

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

[CLARIFIED v.0.5]
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 Me 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

[CLARIFIED v.0.5]
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 Me 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 Me, 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

[CLARIFIED v.0.5]
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

[CLARIFIED v.0.5]
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 Me, 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

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 Me.

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

[CLARIFIED v.0.5]
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 Me 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

[CLARIFIED v.0.5]
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 an incoming network event is received by the networking device, while 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 Me 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 Me 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.24 PCI D3 Network Device Functionality Test Under Windows 2000

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

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 an incoming network event is received by the networking device 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 [New - v.0.5] PCITest.exe Test

This test will attempt to read from and write to various regions of PCI config 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.


Chapter 5: Graphics Adapter Test Specification

Draft Version: 0.7 — Date: February 12, 2001

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 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 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 3 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 which provides some useful command line options. Run these tests with -? (e.g. 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 which indicates the difference between the source and Direct3D reference images 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 | Terminal Services - Console Disconnect Assertions | TD-5.1 Terminal Services – Console Disconnect Test
5.2.1 | WL-B4.2.1 (PC 2001 Ch 10) | ExtEsc Test
5.3.1 |  | Illegal Imports
5.4.1-3 | PC99 14.27.2, 14.27.3, 14.33 | Compare Caps
5.9.1-35 | DX DDK | 5.9 Ddraw
5.10.1 | SDK | 5.10 Video Output
5.13.1 | DX8 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 | DX DDK & SDK | 5.20 Display Basic 3D
5.21.1 | DX DDK & SDK | 5.21 Wire Frame
5.22.1-12 | DX DDK & SDK | 5.22 Texture
5.23.1 | DX DDK & SDK | 5.23 Z Compare
5.24.1 | DX DDK & SDK | 5.24 Basic Rasterization
5.25.1 | DX DDK & SDK | 5.25 Overdraw/Underdraw
5.26.1-2 | DX DDK & SDK | 5.26 Perspective
5.27.1 | DX DDK & SDK | 5.27 SubPixel Texture
5.28.1 | DX DDK & SDK | 5.28 Display Texture Handle
5.29.1-19 | DX DDK & SDK | 5.29 Alpha Blending
5.30.1 | DX DDK & SDK | 5.30 Z Write Test
5.31.1 | DX DDK & SDK | 5.31 W Buffer
5.32.1 | DX DDK & SDK | 5.32 Palettized textures – Force Update
5.33.1-5 | DX DDK & SDK | 5.33 Fogging
5.34.1-8 | DX DDK & SDK | 5.34 Lighting
5.35.1 | DX DDK & SDK | 5.35 Compressed Texture
5.36.1 | DX DDK & SDK | 5.36 Stencil
5.37.1-3 | DX DDK & SDK | 5.37 Multi-texturing Tests
5.38.1 | DX DDK & SDK | 5.38 Mip-mapped Texture Tests
5.39.1 | DX DDK & SDK | 5.39 Display Simultaneous Features
5.40.1 | DX DDK & SDK | 5.40 Specular Highlighting
5.41.1 | DX DDK & SDK | 5.41 Clear Offscreen/Texture Surface
5.42.1-2 | DX DDK & SDK | 5.42 Multi-sampling
5.43.1 | DX DDK & SDK | 5.43 Present Validation
5.44.1 | DX DDK & SDK | 5.44 Matrix Palette Skinning
5.45.1 | DX DDK & SDK | 5.45 The Blt Queue Test
5.46.1 | DX DDK & SDK | 5.46 The Lockable Depth Buffer Test
5.47.1-2 | DX DDK & SDK | 5.47 The Point Sprite Test
5.53.1-2 | DX DDK & SDK | 5.53 Set Render Target Tests
5.54.1 | DX DDK & SDK | 5.54 GetRasterStatus
5.55.1 | DX DDK & SDK | 5.55 Vertex Buffer and Index
5.56.1-3 | DX DDK & SDK | 5.56 Clipping
5.57.1-3 | DX DDK & SDK | 5.57 Multipass Z-Fighting
5.58.1 | DX DDK & SDK | 5.58 State Blocks
5.59.1 | DX DDK & SDK | 5.59 Vertex Buffer Rendering Tests
5.60.1 | DX DDK & SDK | 5.60 Vertex Tweening Tests
5.61.1 | DX DDK & SDK | 5.61 Vertex Blending Tests
5.62.1 | DX DDK & SDK | 5.62 Texture Coordinate Generation Tests
5.63.1 | DX DDK & SDK | 5.63 Pixel Shaders Tests
5.64.1 | DX DDK & SDK | 5.64 Surfaces Tests
5.65.1 | DX DDK & SDK | 5.65 Texture Update
5.66.1 | DX DDK & SDK | 5.66 Vertex Shaders
5.67.1 | DX DDK & SDK | 5.67 Volume Texture
5.68.1 | DX DDK & SDK | 5.68 MipMapping Test
5.69.1 | DX DDK & SDK | 5.69 High Order Surfaces
5.70.1 | DX DDK & SDK | 5.70 Memory/Texture Management
5.71.1 | DX DDK & SDK |
5.72.1 | DX DDK & SDK | 5.72 Morph – Invalid Params
5.100.1-6 | DX7 DDK & SDK | 5.20 Display Basic 3D Requirements
5.101.1-7 | DX7 DDK & SDK | 5.22 Texture Tests
5.102.1 | DX7 DDK & SDK | 5.36 Stencil Test
5.103.1 | DX7 DDK & SDK | 5.37 Multi-texturing Tests
5.104.1 | DX7 DDK & SDK | 5.40 Specular Highlighting
5.105.1 | DX7 DDK & SDK | 5.39 Display Simultaneous Features
5.106.1 | DX7 DDK & SDK | TBD “Overdraw/Underdraw test”
5.107.1 | DX7 DDK & SDK | 5.36 Stencil Test
5.108.1-2 | DX7 DDK & SDK | 5.53 Set Render Target Tests
5.109.1 | DX7 DDK & SDK | TBD “TL Vertex Clip”
5.110.1 | PC99 , DX7 DDK & SDK | TBD
5.111.1 | PC99 , DX7 DDK & SDK | TBD
5.112.1 | PC99 , DX7 DDK & SDK | TBD
5.113.1 | DX7 DDK & SDK | 5.113 Palettized Textures
5.120.1-6 | DX6 DDK & SDK | 5.20 Display Basic 3D Requirements
5.121.1-4 | DX6 DDK & SDK | 5.22 Texture Tests
5.122.1 | DX6 DDK & SDK | 5.36 Stencil
5.123.1 | DX6 DDK & SDK | 5.31 W Buffer
5.124.1 | DX6 DDK & SDK | TBD “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 | Win2K DDK | 5.150 Display Windows 2000 GDI
5.170.1-13 | Logo B4.1.4.11 | 5.170 Video Rendering Display
5.170.14-17 | Logo B4.1.4.19 | 5.170 Video Rendering Display
5.171.1 | Logo B4.1.1.9 | 5.170 Video Rendering Display
5.190.1-3 | DX DDK & SDK | Assertion 3.41.1-3
5.191.1-3 | DX DDK & SDK | Assertion 3.42.1-3
5.192.1-6 | DX DDK & SDK | Assertion 3.43.1-6
5.192.7 | DX 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

[CLARIFIED v.0.7]

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.html

Display Device Class Power Management Specification, V. 2.0

http://www.microsoft.com/hwdev/specs/PMref/PMdisplay.htm

Ergonomic timings for supported resolutions, based on VESA standards

http://www.vesa.org/standards.html
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 Whistler/Windows 2000: "Display and Video Miniport Drivers" (includes DirectX DDKs) and "Multiple Monitor Support in the Display Driver" in the Windows DDK

PC 2001 System Design Guide and PC 99 System Design Guide

http://www.pcdesguide.org/library/http://www.pcdesguide.org/library/(@http://www.pcdesguide.org/library/)


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 (a.k.a. Blue Screen of Death) 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: TBD
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 DDraw 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 DDraw 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 DDraw 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 DDraw 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 DDraw 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 DDraw 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 DDraw 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 DDraw 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 DDraw 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 DDraw 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 DDraw 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 DDraw 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 DDraw 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 DDraw 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 DDraw 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 DDraw 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 DDraw 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 DDraw 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 DDraw 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 DDraw 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 DDraw 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 DDraw 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 DDraw 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 DDraw 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 DDraw 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 DDraw 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 DDraw 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 DDraw 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 DDraw 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 DDraw 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 DDraw 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 DDraw 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 DDraw Test Description

5.9.35 Blt – Textures

[New - v. 0.7b]

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 facillate 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 DDraw 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

Todd and Marty – I think we will need to break down this section into smaller sections in order to accommodate writing Test Description (each assertion needs to reference a Test Description). Some possible sections to break this down into is

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 - martinlo
  • The Shading – Flat/Gouraud test - Test ensures that the graphics adapter supports Flat and Gouraud shading.
  • The Modulating – No Diffuse test - martinlo

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 ??? martinlo ??? 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 of 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.

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

TBD

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.

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 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

[New - v.0.7]

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

[Clarification - v. 0.7b]

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 Managment 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.

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: TD-5.72 Morph – Invalid Params Test Description


Video Memory Volume Texture Test Assertions - DirectX

[New - v.0.7]

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

[New - v.0.7]

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

[New - v.0.7]

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


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: “TBD Overdraw”


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: “TBD TL Vertex Clip”


Multitexturing Test Assertions – DirectX 7

5.110.1 PC99 #29 Multitexturing

PC99 Guide

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: “TD-5. TBD”


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. TBD”


AntiAlias Test Assertions – DirectX 7

5.112.1 PC99 #28 AntiAlias

PC99 Guide

Reference Documents: DirectX DDK, DirectX SDK.
Test Description: “TD-5. TBD”


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: “TBD 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 Enalbe() and Disable() functions first. This code is demonstarted 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::GetVerticalBlanckStatus(). 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

[New - v.0.7]

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 The Check Resolution (chndsp) test

Test changes to every enumerated display mode, and validates the mode if the change was successful.

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, VeiwportExt 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 Blended test

[Modified - v.0.7]

The GDI Alpha Blended test displays a series of blends on the display surface and in memory, using various alpha blending configurations. These images are compared against one another with some varying tolerance. 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# - 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.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.11, 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.11, 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.11, 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.11, 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.11, DirectX SDK – DirectShow Reference, DirectX DDK – Design Guide – DirectDraw DDI
Test Description: TD-5.170 Video Rendering Display Test Description

5.170.9 The YUV Blt Performance test

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 blts an offscreen YUV surface 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 us.

Wait: The time spent doing the blt, which should be greater than 1 ms and less than 6 ms. If this is less than 1 ms, 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 ms, depending on the current video refresh rate.

Lock2: The time to lock an offscreen surface after a blt, which should be less than 100 us. The locked surface is not used in a previous blt, and wherefore the lock should succeed immediately. If the lock takes more than 100 us, it is an indication that either the hardware is poor or the lock function is not implemented properly.

Correct Output: flashing 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.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.11, 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.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 flag is set (see D3DPRIMCAPS), if so the test precedes as below, if not, the test will verify that the call to CreateSurface fails, if not, then the test will fail.

This creates a 16-bit RGB 3D render target overlay surface with 2 backbuffers. It then creates 2 additional textured 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 (not stepped up the next power of two in size) of the overlay surface, and 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.

Output: Pass/Fail Messages, Blue background is painted with a moving green box

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.14 FOURCC Blt and Stretch Test

Test Description: The FOURCC Blt and Stretch test creates a YUV offscreen surface (YUY2 and UYVY for now) and an RGB texture offscreen (we test 32-bit RGB 08888, 16-bit 565, and 16-bit 555 formats), initializes the YUV surface to black in the center with linearly increasing intensity as you get to the corners, then does several YUV->RGB stretchblts and checks the output by locking the RGB surface and checking the output pixel values against the function that was used to initialize the YUV surface.

Output: Pass/Fail Messages,

Reference documents: WLP# - B4.1.4.19, 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

Test Description: TBD

Output: Pass/Fail Messages,

Reference documents: WLP# - B4.1.4.19, DirectX SDK – DirectShow Reference, DirectX DDK – Design Guide – DirectDraw DDI
Test Description: TD-5.170 Video Rendering Display Test Description

5.170.16 Update Overly Test

Test Description: TBD

Output: Pass/Fail Messages,

Reference documents: WLP# - B4.1.4.19, 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

Test Description: TBD

Output: Pass/Fail Messages,

Reference documents: WLP# - B4.1.4.19, 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 some configurations, the word "Test!" should be alpha-blended over the top. 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 FltSim) 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


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.21System-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 Whistler.


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.

Copy ExtEsc.exe to the machine and run "extesc /d /r /p /o".

Results Interpretation

ExtEsc.exe will produce a assertion log that will have the line Results: PASSED if the test passed. If the test fails, the machine will have a kernel mode break (a.k.a. Blue Screen of Death).


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.

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. 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 pas.


TD-5.9 DDraw Test Description

Overview

Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select invidual 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 follow 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 choosen 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. (Really doesn’t belong here)

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 Souce 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 choosen 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 choosen 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.

[Clarification - v.0.7]

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 choosen such that they overlapp. 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 enviroment 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

[New - v. 0.7b]

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.10 Video Output Test Description

Overview

TBD


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.

DirectX 6

TBD

DirectX 7

TBD

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.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 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. 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 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 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

TBD

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. 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 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. 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

TBD

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. Additional information is generated on failure cases.


TD-5.26 Perspective Test Description

Overview

TBD

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. Additional information is generated on failure cases, which includes TBD


TD-5.27 SubPixel Texture Test Description

Overview

TBD

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. Additional information is generated on failure cases, which includes TBD


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 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.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 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. 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

TBD

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. Additional information is generated on failure cases.


TD-5.31 W Buffer Test Description

Overview

TBD

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. 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 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. 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 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. 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

TBD

Click to show or hide information. Luminance

TBD

Click to show or hide information. Lightmap

TBD

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 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. Additional information is generated on failure cases.


TD-5.35 Compressed Texture Test Description

Overview

TBD

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. 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 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. 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 comliant behavior.


TD-5.37 Multi-texturing Tests Description

Overview

TBD

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. Additional information is generated on failure cases.


TD-5.38 Mip-mapped Texture Tests Description

Overview

TBD

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. 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 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. 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 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. 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. For each scan line the edge intersects, there is one pixel on the left of the edge and one pixel on the right of the edge.

d = x(edge) – x(left pixel);

if (d <= 0.5)

{

IdealLeftPixel = ScaleColor(d+0.5, LeftColor, 0.5-d, RightColor);

IdealRightPixel = RightColor;

}

else

{

IdealLeftPixel = LeftColor;

IdealRightPixel = ScaleColor(d-0.5, LeftColor, 1.5-d, RightColor);

}

If antialiasing were not enabled, we know what would be the color of the left and right pixels. They are taken as "wrong colors". Then for each left and right pixels surrounding the edge, 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.

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] = 25%
ReqConf[D3DMULTISAMPLE_3_SAMPLES] = 30%
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%

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
  • 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. The striped pattern is used to help with debugging as it depicts the LOD that has been chosen for the texture. The LOD’s alternates from Vertical to Horizontal stripes starting with 7 different colored stripes for LOD 0 which is a 128*128 texture with a decreasing numbers of different colored stripes as the LODs increase.

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.

Finally all caps that are essential to point sprite functioning correctly but should not prevent the test from running are checked. For example the MaxPointSize cap which should be set to 16 or greater. The test can still run if this is 4 however this is not an acceptable value.

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 Tests Description

WHQL Test Specification

Previous Next

TD-5.53 Set Render Target Test Description

[Modified - v.0.7]

Overview

Set Render Target

TBD

Set Render Target - Invalid

TBD

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 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. 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 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. Additional information is generated on failure cases, which includes stateblock number and repro scenario (ie. What was recorded/applied in the stateblock ). You can pass the stateblock number to the test through the "-testblock" commandline 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 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. 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 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. 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 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. Additional information is generated on failure cases.


TD-5.63 Pixel Shaders Tests Description

Overview

The test verifies pixel shader capabilities of the device by rendering a quad using different code for pixel pipeline. Test executes following groups:

Test | Group
PSOps | blending instructions test group
PSAddress | texture addressing test group
PSDestMod | destination modes test group
PSInstMod | instruction modifiers test group
PSRegister | registers test group
PSSrcMod | operand modifiers test group

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. 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 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.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 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.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 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. Additional information is generated on failure cases.


TD-5.67 Volume Texture Test Description

Overview

TBD

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. Additional information is generated on failure cases, which includes TBD


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 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. 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 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. 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.

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 Microsoft Windows 2000 operating system must be installed, as well as DirectX version 5 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 560 variations run, 560 variations passed.


TD-5.73 Volume Texture Update Test Description

[New - v.0.7]

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 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.74 Anisotropic Texture Filtering Test Description

[New - v.0.7]

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 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. Additional information is generated on failure cases.


TD-5.75 Line Style Test Description

[New - v.0.7]

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 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.


TD-5.113 Palettized Textures Test Description

Overview

TBD

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. Additional information is generated on failure cases.


TD-5.129 OpenGL Test Description

Overview

TBD


TD-5.130 Display Windows 9x GDI Test Description

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 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

[New - v.0.7]

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

[Modified - v.0.7]

The GDI Alpha Blend Test

Overview

The GDI Alpha Blend Test is composed of three separate tests, General, Stretching, and Boundary and Per Pixel.

Click to show or hide information. The General Test

The General Test performs a series of alpha blends onto a display surface while the same blend is performed in memory. Then the two images are compared with a tolerance of +/- 1 on each ARBG value. The blend is based on a constant alpha, which will vary between 0, 32, 64, 128, 160, 192, 224, and 255. The source and destination image will be the same size and will be performed in all modes the graphics adapter enumerates.

Click to show or hide information. The Stretching Test

The Stretching 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 a 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. 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. This test will run on displays which support 800x600x32.

Click to show or hide information. The Boundary and Per-Pixel Test

The Boundary and Per-Pixel Test performs a series of alpha blends onto a display surface using per-pixel alpha values. Blends will occur on totally on the screen as well as partially off. The same blend will be done in memory and will compared using a tolerance of +/- 1 on each ARGB value. The source and destination images will be the same size. This test will run on displays which support 640x480x32

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

A test system with Windows 2000 or greater 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. Additional information is generated on failure cases, which includes the position of the failed pixel and the display and memory values for that position.


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

Must meet minimum blt performance criteria for YUV surfaces.

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

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.


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

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

TBD

Setup

Microsoft Windows 98/ME or Windows 2000 operating system must be installed on the test system.

Results

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.


Chapter 6: Digital and Broadcast Video Test Specification

Draft Version: 0.7 — Date: February 12, 2001

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 or Windows 2000.

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 system. 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 98. 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

[CLARIFIED v.0.7]

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.pcdesguide.org/library/http://www.pcdesguide.org/library/(@http://www.pcdesguide.org/library/)


Video Input Format

Analog input supports 720x480 decode to 4:2:2.
Assertions in this section are tested in TD-6.1 Video Input Format Test

6.1.1 Input is either ‘YUY2’ or ‘UYVY’ YVU 4:2:2 format.

[CLARIFIED v.0.55] This assertion is replaced by assertion 6.1.5.

Reference document: PC 99 System Design Guide - 15.30.
Test description: TD-6.1 Video Input Format Test

6.1.2 Vertical resolution is PAL 576 line or NTSC 480 line standard.

Reference document: WLP# - B11.1.4.4; PC 2001 System Design Guide, VID-0215, GRPH-0207.4; PC 99 System Design Guide - 15.30.
Test description: TD-6.1 Video Input Format Test

6.1.3 Input frame rate is described as PAL 25.0fps or NTSC 29.97fps standard.

Reference document: WLP# - B11.1.4.4; PC 2001 System Design Guide, VID-0215, PC 99 System Design Guide - 15.30.
Test description: TD-6.1 Video Input Format Test

6.1.4 Horizontal resolution is 720, 704, 640, 512, 480, 360, or 352 pixels.

[CLARIFIED v.0.7]
Reference document: WLP# - B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.30.
Test description: TD-6.1 Video Input Format Test

6.1.5 [NEW v.0.5] Input must support YUY2 format.

Reference documents: WLP# - B11.1.4.4; PC 2001 System Design Guide, VID-0215.9, GRPH-0207.3; PC 99 System Design Guide - 15.30.
Test description: TD-6.1 Video Input Format Test


Video Input Data Rate

Frame rate is within 0.2% of PAL 25.0fps or NTSC 29.97fps standard.
Assertions in this section are tested in TD-6.2 Video Input Video Data Rate Test.
[CLARIFIED - v.0.8 - precise references for this section]

6.2.1 Frame rate is within 20% of expected during first ten seconds.

Reference document: WLP# - B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.30.
Test description: TD-6.2 Video Input Video Data Rate Test

6.2.2 Delivered frame rate is within 0.2% of PAL 25.0fps or NTSC 29.97fps standard.

Reference document: WLP# - B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.30.
Test description: TD-6.2 Video Input Video Data Rate Test

6.2.3 Delivered frames have no pixel drops greater than 16 pixels in size.

Reference document: WLP# - B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.30.
Test description: TD-6.2 Video Input Video Data Rate Test

6.2.4 Delivered frames have fewer than one hundred pixels dropped.

Reference document: WLP# - B11.1.4.4; PC 2001 System Design Guide - VID-0215; PC 99 System Design Guide - 15.30.
Test description: TD-6.2 Video Input Video Data Rate Test

6.2.5 No more than 2 frames are dropped in each half second of capture.

Reference document: WLP# - B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.30.
Test description: TD-6.2 Video Input Video Data Rate Test

6.2.6 No more than 3 frames are dropped in each minute of capture.

Reference document: WLP# - B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.30.
Test description: TD-6.2 Video Input Video Data Rate Test

6.2.7 No more than 6 frames are dropped during test period.

Reference document: WLP# - B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.30.
Test description: TD-6.2 Video Input Video Data Rate Test

6.28 No more than 0.1% of all input pixels are in error.

Reference document: WLP# - B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.30.
Test description: TD-6.2 Video Input Video Data Rate Test


Video Input Disk Data Rate

Video capture must support data rates of up to 3.7MB/s.
Assertions in this section are tested in TD-6.3 Video Capture Disk Data Rate Test.

6.3.1 Captured file contains 3.7MB/s of combined video and audio data.

Reference document: WLP# - B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.31.
Test description: TD-6.3 Video Capture Disk Data Rate Test


Video Input Image Orientation

Assertions in this section are tested in TD-6.4 Video Input Image Orientation Test.
[CLARIFIED - v.0.8 - precise references for this section]

6.4.1 Input VIDEOINFO’s BITMAPINFOHEADER "biHeight" MSB is Zero.

Reference document: WLP# - B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.34.
Test description: TD-6.4 Video Input Image Orientation Test

6.4.2 Input VIDEOINFO’s BITMAPINFOHEADER "biHeight" is either 480 or 576.

Reference document: WLP# - B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.34.
Test description: TD-6.4 Video Input Image Orientation Test

6.4.3 Input image is presented in top down order.

Reference document: PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.34.
Test description: TD-6.4 Video Input Image Orientation Test

6.4.4 Input image is presented without field inversion.

Reference document: WLP# - B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.34.
Test description: TD-6.4 Video Input Image Orientation Test


Video Input Image Quality

Assertions in this section are tested in TD-6.5 Video Input Image Quality Test.
[CLARIFIED - v.0.8 - precise references for this section]

6.5.1 Image Detail: Input image has correct image detail.

Reference document: WLP# - B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.30.
Test description: TD-6.5 Video Input Image Quality Test

6.5.2 Image Levels: Input image has correct image levels.

Reference document: WLP# - B11.1.4.4; PC 2001 System Design Guide, VID-0215; PC 99 System Design Guide - 15.30.
Test description: TD-6.5 Video Input Image Quality Test


Video Copyright Protection

This is not currently tested.[CLARIFIED v.0.7]
Previously defined tests are described in TD-6.6 Video Copyright Protection Test

6.6.1 Regionalized material plays appropriate to region.

This is not currently tested.[CLARIFIED v.0.7]

Reference document: PC 99 System Design Guide - 15.29.
Test description: TD-6.6 Video Copyright Protection Test

6.6.2 APS is present on analog outputs when content protected material is played back.

This is not currently tested.[CLARIFIED v.0.7]

Reference document: PC 99 System Design Guide - 15.29.
Test description: TD-6.6 Video Copyright Protection Test

6.6.3 APS is not present on analog outputs when non content protected material is played back.

This is not currently tested.[CLARIFIED v.0.7]

Reference document: PC 99 System Design Guide - 15.29.
Test description: TD-6.6 Video Copyright Protection Test


Video Elementary Stream Routing

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: Not tested


Video Overlay Support

Assertions in this section are tested in TD-6.8 Video Overlay Test.

[CLARIFIED - v.0.8 - precise references for this section]

6.8.1 Hardware supports video overlay surface with scaling.

Reference document: WLP# - B11.1.4.4; PC 2001 System Design Guide ,GRPH-0207; PC 99 System Design Guide - 14.14.
Test description: TD-6.8 Video Overlay Test

6.8.2 Hardware supports VGA destination color keying for video rectangle.

Reference document: WLP# - B4.1.4.11; PC 2001 System Design Guide, GRPH-0395; PC 99 System Design Guide - 14.15.
Test description: TD-6.8 Video Overlay Test

6.8.3 Overlay accepts input at 720x576 at 24 fps and 16 bpp, minimally.

[CLARIFIED v.0.5] – Replaced with assertion 6.8.7.
Reference document: WLP# - B4.1.4.11; PC 2001 System Design Guide, GRPH–0207; PC 99 System Design Guide - 14.14.1.
Test description: TD-6.8 Video Overlay Test

6.8.4 Overlay supports at least one common YUV format.

[CLARIFIED v.0.55] – Replaced with assertion 6.8.8.
Reference document: WLP# - B4.1.4.11; PC 2001 System Design Guide, GRPH–0207; PC 99 System Design Guide - 14.14.3.
Test description: TD-6.8 Video Overlay Test

6.8.5 Overlay provides high quality scaling.

Reference document: WLP# - B4.1.4.11; PC 2001 System Design Guide, GRPH–0207; PC 99 System Design Guide - 14.14.4.
Test description: TD-6.8 Video Overlay Test

6.8.6 Overlay supports 720x480/576 surfaces.

[CLARIFIED v.0.55] – Replaced with assertion 6.8.9.
Reference document: WLP# - B4.1.4.11; PC 2001 System Design Guide, GRPH–0207; PC 99 System Design Guide - 14.14.1.
Test description: TD-6.8 Video Overlay Test

6.8.7 [NEW v.0.5] Overlay accepts input at 1280x720 at 24 fps with 16bpp and 32bpp color modes.

Reference documents: WLP# - B4.1.4.11; PC 2001 System Design Guide, GRPH-0207.1;
PC 99 System Design Guide - 14.14.1.
Test description: TD-6.8 Video Overlay Test

6.8.8 [NEW v.0.5] Overlay supports YUY2 and YV12 color formats.

Reference documents: WLP# - B4.1.4.11; PC 2001 System Design Guide, VID-0215.9, GRPH-0207.3; PC 99 System Design Guide - 14.14.3.
Test description: TD-6.8 Video Overlay Test

6.8.9 [NEW v.0.5] The video overlay must be fully operative at 640 × 480 and 1024 × 768 and color depths of 16 bpp and 32 bpp.

Reference documents: WLP# - B4.1.4.11; PC 2001 System Design Guide, GRPH-0207.2; PC 99 System Design Guide - 14.14.1.
Test description: TD-6.8 Video Overlay Test


DVD Playback

Assertions in this section are tested in TD-6.9 Video DVD Playback Test.
[CLARIFIED - v.0.8 - precise references for this section]

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 DVD Playback 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 DVD Playback 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 DVD Playback Test


Video Quality Assertions

Assertions in this section are tested in TD-6.10 Video Quality Test.
[CLARIFIED - v.0.8 - precise references for this section]

6.10.1 [NEW v.0.5] 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.10 Video Quality Test


CPU Utilization Assertions

Assertions in this section are tested in TD-6.11 CPU Utilization Test.
[CLARIFIED - v.0.8 - precise references for this section]

6.11.1 [NEW v.0.5] 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 55% of the CPU. Measurements are in addition to observed utilization prior to playback.

Reference document: WLP# - B4.1.4.11; PC 2001 System Design Guide, VID-0215.6
Test Description: TD-6.11 CPU Utilization Test


YUV Test Assertions

Assertions in this section are tested in TD-6.12 YUV Test.
[CLARIFIED - v.0.8 - precise references for this section]

6.12.1 [NEW v.0.5] MPEG-2 decoders must support YUY2 format.

Reference document: WLP# - B4.1.4.11; PC 2001 System Design Guide, VID-0215.9
Test Description: 6.12 YUV Test

6.12.2 [NEW v.0.5] Graphics adapters must support both YUY2 and YV12 as an overlay format.

Reference document: WLP# - B4.1.4.11; PC 2001 System Design Guide, VID-0215.9
Test Description: 6.12 YUV Test


De-interlacing Assertions

Assertions in this section are tested in TD-6.13 De-interlacing Test.
[CLARIFIED - v.0.8 - precise references for this section]

6.13.1 [NEW v.0.5] 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.13 De-interlacing Test

6.13.2 [NEW v.0.5] 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.13 De-interlacing Test


Pull-Down Assertions

Assertions in this section are tested in TD-6.14 Pull-Down Test.
[CLARIFIED - v.0.8 - precise references for this section]

6.14.1 [NEW v.0.5] 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.14 Pull-Down Test


Refresh Sync Assertion

Assertions in this section are tested in TD-6.15 Refresh Sync Test.
[CLARIFIED - v.0.8 - precise references for this section]

6.15.1 [NEW v.0.5] MPEG-2 files with interlaced NTSC material is played back on 85 Hz refresh systems so that no frames are ever skipped and no frame is ever repeated more than twice.

Reference document: WLP# - B4.1.4.11; PC 2001 System Design Guide, VID-0215.13
Test Description: TD-6.15 Refresh Sync Test


Audio/Video Sync Assertions

Assertions in this section are tested in TD-6.16 Audio/Video Sync Test.
[CLARIFIED - v.0.8 - precise references for this section]

6.16.1 [NEW v.0.5] A video stream that contains any simultaneous audio and video events must play those events back within 75ms.

Reference document: WLP# - B4.1.4.11; PC 2001 System Design Guide, VID-0215.8
Test Description: TD-6.16 Audio/Video Sync Test


DXVADecoder Assertions

Assertions in this section are tested in TD-6.18 DXVADecoder Test Description.

[NEW v.0.7]

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 DXVADecoder Test Description


Video DVD Lost Test Assertions

Assertions in this section are tested in TD-6.19 Video DVD Lost Test.

6.19.1 [New v.0.7] 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.19 Video DVD Lost Test

6.19.2 [New v.0.7] 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.19 Video DVD Lost Test

6.19.3 [New v.0.7] 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.19 Video DVD Lost Test

6.19.4 [New v.0.7] 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.19 Video DVD Lost Test

6.19.5 [New v.0.7] 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.19 Video DVD Lost Test

6.19.6 [New v.0.7] 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.19 Video DVD Lost Test

6.19.7 [New v.0.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.19 Video DVD Lost Test

6.19.8 [New v.0.7] 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.19 Video DVD Lost Test

6.19.9 [New v.0.7] 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.19 Video DVD Lost Test

6.19.10 [New v.0.7] 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.19 Video DVD Lost Test

6.19.11 [New v.0.7] 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.19 Video DVD Lost Test

6.19.12 [New v.0.7] 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.19 Video DVD Lost Test

6.19.13 [New v.0.7] 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.19 Video DVD Lost Test

6.19.14 [New v.0.7] 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.19 Video DVD Lost Test

6.19.15 [New v.0.7] 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.19 Video DVD Lost Test

6.19.16 [New v.0.7] 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.19 Video DVD Lost Test

6.19.17 [New v.0.7] 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.19 Video DVD Lost Test

6.19.18 [New v.0.7] 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.19 Video DVD Lost Test

6.19.19 [New v.0.7] 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.19 Video DVD Lost Test

6.19.20 [New v.0.7] 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.19 Video DVD Lost Test

6.19.21 [New v.0.7] 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.19 Video DVD Lost Test

6.19.22 [New v.0.7] 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.19 Video DVD Lost Test

6.19.23 [New v.0.7] 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.19 Video DVD Lost Test

6.19.24 [New v.0.7] 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.19 Video DVD Lost Test

6.19.25 [New v.0.7] 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.19 Video DVD Lost Test

6.19.26 [New v.0.7] 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.19 Video DVD Lost Test

6.19.27 [New v.0.7] 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.19 Video DVD Lost Test

6.19.28 [New v.0.7] 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.19 Video DVD Lost Test

6.19.29 [New v.0.7] 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.19 Video DVD Lost Test

6.19.30 [New v.0.7] 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.19 Video DVD Lost Test

6.19.31 [New v.0.7] 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.19 Video DVD Lost Test

6.19.32 [New v.0.7] 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.19 Video DVD Lost Test

6.19.33 [New v.0.7] 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.19 Video DVD Lost Test

6.19.34 [New v.0.7] 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.19 Video DVD Lost Test

6.19.35 [New v.0.7] 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.19 Video DVD Lost Test

6.19.36 [New v.0.7] 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.19 Video DVD Lost Test

6.19.37 [New v.0.7] 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.19 Video DVD Lost Test

6.19.38 [New v.0.7] 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.19 Video DVD Lost Test

6.19.39 [New v.0.7] 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.19 Video DVD Lost Test

6.19.40 [New v.0.7] 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.19 Video DVD Lost Test

6.19.41 [New v.0.7] 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.19 Video DVD Lost Test

6.19.42 [New v.0.7] 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.19 Video DVD Lost Test

6.19.43 [New v.0.7] 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.19 Video DVD Lost Test

6.19.44 [New v.0.7] 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.19 Video DVD Lost Test

6.19.45 [New v.0.7] 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.19 Video DVD Lost Test

6.19.46 [New v.0.7] 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.19 Video DVD Lost Test

6.19.47 [New v.0.7] 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.19 Video DVD Lost Test

6.19.48 [New v.0.7] 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.19 Video DVD Lost Test

6.19.49 [New v.0.7] 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.19 Video DVD Lost Test

6.19.50 [New v.0.7] 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.19 Video DVD Lost Test

6.19.51 [New v.0.7] 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.19 Video DVD Lost Test

6.19.52 [New v.0.7] 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.19 Video DVD Lost Test

6.19.53 [New v.0.7] 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.19 Video DVD Lost Test

6.19.54 [New v.0.7] 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.19 Video DVD Lost Test

6.19.55 [New v.0.7] 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.19 Video DVD Lost Test

6.19.56 [New v.0.7] 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.19 Video DVD Lost Test

6.19.57 [New v.0.7] 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.19 Video DVD Lost Test

6.19.58 [New v.0.7] 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.19 Video DVD Lost Test

6.19.59 [New v.0.7] 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.19 Video DVD Lost Test

6.19.60 [New v.0.7] 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.19 Video DVD Lost Test

6.19.61 [New v.0.7] 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.19 Video DVD Lost Test

6.19.62 [New v.0.7] 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.19 Video DVD Lost Test

6.19.63 [New v.0.7] 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.19 Video DVD Lost Test

6.19.64 [New v.0.7] 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.19 Video DVD Lost Test

6.19.65 [New v.0.7] 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.19 Video DVD Lost Test

6.19.66 [New v.0.7] 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.19 Video DVD Lost Test

6.19.67 [New v.0.7] 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.19 Video DVD Lost Test

6.19.68 [New v.0.7] 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.19 Video DVD Lost Test

6.19.69 [New v.0.7] 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.19 Video DVD Lost Test

6.19.70 [New v.0.7] 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.19 Video DVD Lost Test

6.19.71 [New v.0.7] 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.19 Video DVD Lost Test

6.19.72 [New v.0.7] 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.19 Video DVD Lost Test

6.19.73 [New v.0.7] 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.19 Video DVD Lost Test

6.19.74 [New v.0.7] 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.19 Video DVD Lost Test

6.19.75 [New v.0.7] 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.19 Video DVD Lost Test

6.19.76 [New v.0.7] 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.19 Video DVD Lost Test

6.19.77 [New v.0.7] 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.19 Video DVD Lost Test

6.19.78 [New v.0.7] 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.19 Video DVD Lost Test

6.19.79 [New v.0.7] 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.19 Video DVD Lost Test

6.19.80 [New v.0.7] 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.19 Video DVD Lost Test

6.19.81 [New v.0.7] 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.19 Video DVD Lost Test

6.19.82 [New v.0.7] 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.19 Video DVD Lost Test

6.19.83 [New v.0.7] 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.19 Video DVD Lost Test

6.19.84 [New v.0.7] 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.19 Video DVD Lost Test

6.19.85 [New v.0.7] 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.19 Video DVD Lost Test

6.19.86 [New v.0.7] 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.19 Video DVD Lost Test

6.19.87 [New v.0.7] 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.19 Video DVD Lost Test

6.19.88 [New v.0.7] 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.19 Video DVD Lost Test

6.19.89 [New v.0.7] 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.19 Video DVD Lost Test

6.19.90 [New v.0.7] 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.19 Video DVD Lost Test

6.19.91 [New v.0.7] 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.19 Video DVD Lost Test

6.19.92 [New v.0.7] 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.19 Video DVD Lost Test

6.19.93 [New v.0.7] 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.19 Video DVD Lost Test

6.19.94 [New v.0.7] 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.19 Video DVD Lost Test

6.19.95 [New v.0.7] 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.19 Video DVD Lost Test

6.19.96 [New v.0.7] 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.19 Video DVD Lost Test

6.19.97 [New v.0.7] 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.19 Video DVD Lost Test

6.19.98 [New v.0.7] 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.19 Video DVD Lost Test

6.19.99 [New v.0.7] 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.19 Video DVD Lost Test

6.19.100 [New v.0.7] 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.19 Video DVD Lost Test

6.19.101 [New v.0.7] 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.19 Video DVD Lost Test

6.19.102 [New v.0.7] 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.19 Video DVD Lost Test

6.19.103 [New v.0.7] 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.19 Video DVD Lost Test

6.19.104 [New v.0.7] 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.19 Video DVD Lost Test

6.19.105 [New v.0.7] 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.19 Video DVD Lost Test

6.19.106 [New v.0.7] 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.19 Video DVD Lost Test

6.19.107 [New v.0.7] 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.19 Video DVD Lost Test

6.19.108 [New v.0.7] 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.19 Video DVD Lost Test

6.19.113 [New v.0.7] 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.19 Video DVD Lost Test

6.19.114 [New v.0.7] 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.19 Video DVD Lost Test

6.19.116 [New v.0.7] 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.19 Video DVD Lost Test

6.19.117 [New v.0.7] 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.19 Video DVD Lost Test

6.19.119 [New v.0.7] 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.19 Video DVD Lost Test

6.19.120 [New v.0.7] 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.19 Video DVD Lost Test

6.19.123 [New v.0.7] 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.19 Video DVD Lost Test

6.19.124 [New v.0.7] 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.19 Video DVD Lost Test

6.19.126 [New v.0.7] 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.19 Video DVD Lost Test

6.19.127 [New v.0.7] 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.19 Video DVD Lost Test

6.19.129 [New v.0.7] 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.19 Video DVD Lost Test

6.19.130 [New v.0.7] 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.19 Video DVD Lost Test

6.19.132 [New v.0.7] 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.19 Video DVD Lost Test

6.19.133 [New v.0.7] 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.19 Video DVD Lost Test

6.19.137 [New v.0.7] 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.19 Video DVD Lost Test

6.19.138 [New v.0.7] 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.19 Video DVD Lost Test

6.19.143 [New v.0.7] 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.19 Video DVD Lost Test

6.19.144 [New v.0.7] 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.19 Video DVD Lost Test

6.19.147 [New v.0.7] 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.19 Video DVD Lost Test

6.19.148 [New v.0.7] 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.19 Video DVD Lost Test

6.19.149 [New v.0.7] 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.19 Video DVD Lost Test

6.19.150 [New v.0.7] 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.19 Video DVD Lost Test

6.19.151 [New v.0.7] 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.19 Video DVD Lost Test

6.19.152 [New v.0.7] 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.19 Video DVD Lost Test

6.19.153 [New v.0.7] 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.19 Video DVD Lost Test

6.19.154 [New v.0.7] 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.19 Video DVD Lost Test

6.19.155 [New v.0.7] 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.19 Video DVD Lost Test

6.19.156 [New v.0.7] 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.19 Video DVD Lost Test

6.19.157 [New v.0.7] 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.19 Video DVD Lost Test

6.19.158 [New v.0.7] 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.19 Video DVD Lost Test

6.19.159 [New v.0.7] 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.19 Video DVD Lost Test

6.19.160 [New v.0.7] 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.19 Video DVD Lost Test

6.19.161 [New v.0.7] 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.19 Video DVD Lost Test

6.19.162 [New v.0.7] 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.19 Video DVD Lost Test

6.19.163 [New v.0.7] 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.19 Video DVD Lost Test

6.19.164 [New v.0.7] 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.19 Video DVD Lost Test

6.19.165 [New v.0.7] 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.19 Video DVD Lost Test

6.19.166 [New v.0.7] 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.19 Video DVD Lost Test

6.19.167 [New v.0.7] 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.19 Video DVD Lost Test

6.19.168 [New v.0.7] 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.19 Video DVD Lost Test

6.19.169 [New v.0.7] 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.19 Video DVD Lost Test

6.19.170 [New v.0.7] 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.19 Video DVD Lost Test

6.19.171 [New v.0.7] 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.19 Video DVD Lost Test

6.19.172 [New v.0.7] 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.19 Video DVD Lost Test

6.19.173 [New v.0.7] 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.19 Video DVD Lost Test

6.19.174 [New v.0.7] 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.19 Video DVD Lost Test

6.19.175 [New v.0.7] 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.19 Video DVD Lost Test

6.19.176 [New v.0.7] 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.19 Video DVD Lost Test

6.19.177 [New v.0.7] 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.19 Video DVD Lost Test

6.19.178 [New v.0.7] 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.19 Video DVD Lost Test

6.19.179 [New v.0.7] 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.19 Video DVD Lost Test

6.19.180 [New v.0.7] 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.19 Video DVD Lost Test

6.19.181 [New v.0.7] 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.19 Video DVD Lost Test

6.19.182 [New v.0.7] 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.19 Video DVD Lost Test

6.19.183 [New v.0.7] 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.19 Video DVD Lost Test

6.19.184 [New v.0.7] 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.19 Video DVD Lost Test

6.19.185 [New v.0.7] 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.19 Video DVD Lost Test

6.19.186 [New v.0.7] 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.19 Video DVD Lost Test

6.19.187 [New v.0.7] 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.19 Video DVD Lost Test

6.19.188 [New v.0.7] 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.19 Video DVD Lost Test

6.19.189 [New v.0.7] 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.19 Video DVD Lost Test

6.19.190 [New v.0.7] 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.19 Video DVD Lost Test

6.19.191 [New v.0.7] 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.19 Video DVD Lost Test

6.19.192 [New v.0.7] 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.19 Video DVD Lost Test

6.19.193 [Clarified v.0.7] 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 Lost Test

6.19.194 [Clarified v.0.7] 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 Lost 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, Sections 15.30, 15.31, and 15.34. These items together define a system capability that supports high (consumer electronics) quality video capture.

TD-6.1 Video Input Format Test

This test determines whether the video input subsystem indicates that it supports the required YVU 4:2:2 input formats at required frame and field (if applicable) rates and resolutions.

1. Input must support YUY2 format.
[Winlogo 1.1] Input is either ‘YUY2’ or ‘UYVY’ YVU 4:2:2 format.

[CLARIFIED v.0.5] The change for this assertion is required in order to be consistent with assertion 6.12.2. This test passes if input can support YUY2 format.

2. Vertical resolution is PAL 576 line or NTSC 480 line standard.

This test passes if the input indicates 576/480 pixels high for a PAL/NTSC configuration. The test also inspects the system for an indication that both fields of PAL or NTSC interlaced scan video are being made available. Failing this portion of the test terminates the remainder of the test immediately.

3. Input frame rate is described as PAL 25.0fps or NTSC 29.97fps standard.

This test passes if the input is indicated to have a frame rate of 25/29.97fps for a PAL/NSTC configuration. Additionally, this test fails if the test is configured for either PAL or NTSC but not configured for the corresponding PAL or NTSC frame rates.

Failing this portion of the test terminates the remainder of the test immediately.

4. Horizontal resolution is 720, 704, 640, 512, 480, 360, or 352 pixels.

This test passes if the indicated input width is one of the above widths. Failing this portion of the test terminates the remainder of the test immediately.


TD-6.2 Video Input Video Data Rate Test

This test verifies frame rates and checks for pixel errors and dropped frames. The PAL or NTSC frame rate is used as the basis for the comparison, not the frame rate indicated to the filter graph components since the test is concerned with adherence to these standards, not with self consistency between drivers and hardware.

1. Frame rate is within 20% of expected during first ten seconds.

This test fails if during the first ten seconds, following the transition of the test filter graph into RUN state, the actual frame rate is not within 20% of the indicated frame rate. The frame rate used for the calculations in this test includes consideration of errors found within frames. Frames which are considered dropped for other purposes are considered dropped with respect to this test and frame rate.

2. Delivered frame rate is within 0.2% of PAL 25.0fps or NTSC 29.97fps standard.

This passes if the measured frame rate is within 0.2% of the frame rate associated with the relevant video standard, but produces a warning indication if the measured frame rate is not within 0.1% of the required frame rate.

3. Delivered frames have no pixel drops greater than 16 pixels in size.

This test uses buffer scrubbing to detect pixels that have not been updated. The test passes, without warning, if no delivered frames have this error and passes with a warning if one or more delivered frames have this error. A frame with this error is considered dropped, contributing to the total number of frames dropped.

4. Delivered frames have fewer than one hundred pixels dropped.

This test uses buffer scrubbing to detect pixels that have not been updated. The test passes, without warning,, if no delivered frames have this error and passes with a warning if one or more delivered frames have this error. A frame with this error is considered dropped, contributing to the total number of frames dropped.

5. No more than 2 frames are dropped in each half second of capture.

This test passes if no 1/2 second (non-rolling) period of capture had more than two dropped frames.

6. No more than 3 frames are dropped in each minute of capture.

This test passes if no one minute (non-rolling) period of capture has more than three frames dropped.

7. No more than 6 frames are dropped during the test period.

This test passes if during the test period no more than six frames are dropped.

8. No more than 0.1% of all input pixels are in error.

This test passes if no more than 0.1% of all input pixels which should have been provided from the subsystem during the test period are dropped.


TD-6.3 Video Capture Disk Data Rate Test

The video capture disk data rate test determines whether the system provides support for up to 3.7MB/s of capture data being placed on the disk drive. The capture stream contains both video and audio data.

Captured file contains 3.7MB/s of combined video and audio data. The test passes if the capture file contains at least 3.7MB/s of capture data from the test.


TD-6.4 Video Input Image Orientation Test

This test verifies that YUV frames are presented in top-down order. Additionally, left-right orientation and correct field interleaving are verified. The test also checks that the image orientation is correctly indicated in the image headers. A test pattern is used to automate the test, which starts when the pattern is recognized at the input. The test pattern is recognized even if the various inversions that are tested for are present. In some rare instance the test pattern may not be recognized in which case the test will not be run. If the required input is not detected during the period of testing, this test produces an indication that it was not run. The procedure to run the test is to present the SMPTE BARS pattern for thirty seconds, beginning thirty seconds into the test.

1. Input VIDEOINFO's BITMAPINFOHEADER "biHeight" MSB is zero.

The input image is required to be stored in top-down order. A legacy function of the "biHeight" member of the BITMAPINFOHEADER structure was to carry, as an overload of its sign, an indication of image order. This is no longer permissible. The test passes if the high order bit of the biHeight value is clear.

2. Input VIDEOINFO's BITMAPINFOHEADER "biHeight" is either 480 or 576.

The input image height should, with a cleared sign bit, be 480/576, for a NTSC/PAL source. The test passes if the value is 480 or 576.

3. Input image is presented in top down order.

The input image must be stored with the data for the upper left corner of the frame at the lowest memory address, proceeding first to the right and then down with increasing memory addresses. The test checks for both upside down and mirror imaging inversions. The SMTPE bars must be present at the input for this test to run. The test passes after the color bars are detected at the input and are presented in the required layout.

4. Input image is presented without field inversion.

The input image must be provided with fields correctly interwoven in memory with the top field occupying the first and alternate lines of the frame, and the bottom field occupying the second and alternate lines of the frame. The test uses the SMTPE bars test pattern. The test passes if the input test pattern is detected and is not in a field inverted order.


TD-6.5 Video Input Image Quality Test

This test assesses input image quality. The test requires input of the Snell and Wilcox SW2 test pattern. Presently this test applies to NTSC systems only and is not to be run on PAL systems. The input is compared to a reference version of the image. The reference version of the image was generated using the Panasonic DVL909 DVD combi-player. Multiple frames of the input were acquired averaging the pels to generate the reference frame.

The test ignores small horizontal and vertical displacements of the input image when compared to the reference image and determines whether the captured frame approximately matches the frame. The portions of this test which require known input automatically recognize the presence of the required input. Automatic recognition of the input signal occurs only if Test 6.4 has previously run and passed. The procedure to run the test is to present the SW2 pattern for 30 seconds after presenting the SMPTE BARS pattern for the above test.

1. Image Detail: Input image has correct image detail.

This portion of the test assesses the degree of difference between the input image and the reference version of the image. It is keyed towards detail (high frequency) information. The test passes if the input test pattern is detected and found not to differ significantly from the reference image detail.

2. Image Levels: Input image has correct image levels.

This portion of the test assesses the degree of difference between the input image and the reference version of the image. It is keyed towards average values (low frequency content). The test passes if the difference, as measured by the MLD, is less than the required threshold values. For grey areas the threshold is fifteen for luminance and ten for chrominance. For colored areas the threshold is fifteen for luminance and thirty for chrominance. This allows for variations among individual DVD players.

Input Signal Specification

Video input of both the SMPTE BARS and the Snell and Wilcox SW2 test pattern, derived from the Joe Kane’s Video Essentials DVD, is required for the above tests. The input signals are specified in the following table.

Signal | Source | Media | UPC | Title | Ch/Trk | Second.Frame
SW2 525 D1 | DVD | Video Essentials | 6 47715-0711-2 5 | 15 | 11 | 0:37.2
SMPTE BARS | DVD | Video Essentials | 6 47715-0711-2 5 | 15 | 6 | STILL

Audio

The audio input subsystem should be initialized to provide 44.1 kHz 16 bit per sample PCM stereo (CD Quality) audio. Audio and Video streaming capture are performed simultaneously for the duration of the tests.


TD-6.6 Video Copyright Protection Test

(This test has been eliminated.) [CLARIFIED v.0.7]

This test applies to DVD playback and analog copy protection. It verifies three assertions:

  • Verification that an "in-region" DVD can be played and that an "out-of region" DVD cannot be played.
  • Verification that the analog TV out port cannot be used to make a useful analog copy of the protected DVD contents (APS).
  • Verification that the analog TV out port can be used to make a useful analog copy of unprotected DVD contents.

Regionalized material plays appropriate to region.

This test passes if an in-region DVD plays back correctly and an out-of-region DVD fails to play back correctly.

This test passes if a content protected DVD played through an analog output fails to record in an acceptable manner using a VCR.

APS is not present on analog outputs when non content protected material is played back.

This test passes if a non content protected DVD played through an analog output can be successfully recorded using a VCR.

The second sub-test does not apply to systems that do not have analog TV-out capability. The test does not verify that DVD content is copy protected in the digital domain. That is, it may be possible to make a digital copy of a DVD and play it—the inability to do this is not tested. The test does not verify any compliance itself but prompts the user through the appropriate testing procedure. The test proceeds as follows:

  1. Inform the user that if a DVD player is being tested that can switch regions a
    limited number of times (used by laptops), then the player region should not be
    switched during the test.
  2. Prompt user to insert a DVD intended for the player region and start playback.
  3. Query user if playback functions properly. Log response. A "yes" answer passes this part of the test.
  4. Prompt user to insert DVD intended for a different region than the player region.
  5. Query user if playback functions properly. Log response. A "no" answer passes
    this part of the test.
  6. Query user if the system supports analog-TV output of the DVD contents, either
    through the decoder or the graphics subsystem. A "no" answer passes this part of the test.
  7. A "yes" answer prompts the user to connect a video cassette recorder (VCR) to
    the analog-TV output, insert a copy protected DVD (local region) into the player, the test starts the playback and analog recording begins using the VCR.
  8. After 3 minutes of recording the user is prompted to stop recording and to
    attempt playing back the recorded tape on a TV monitor.
  9. The user is queried to grade the tape quality as either viewable or non-viewable. An answer of "non-viewable" passes the test.
  10. The user is prompted to insert a non-copy protected DVD (local region) into the player. The test starts the playback and the analog recording begins using the VCR.
  11. After 3 minutes of recording the user is prompted to stop recording and to
    attempt playing back the recorded tape on a TV monitor.
  12. The user is queried to grade the tape quality as either viewable or non-viewable. An answer of "viewable" passes the test.

The test must be run in a graphics mode of at least 16 bits/pixel and 800x600 resolution or better.

Requirements

The test requires the following types of DVDs:

  • In-region DVD – a DVD intended for the same market as the player.
  • Out-of-region DVD – a content protected DVD intended for a different market region than the player.
  • An APS copy protected DVD – this DVD can be same as the first DVD.
  • A DVD without APS copy protection.

A conventional analog VCR is required for the APS tests.

Results Interpretation

The test generates three partial-test pass/fail results. All sub-tests must be passed to pass test 6.6. The output log reports the overall pass/fail result and the results for each of the following three sub-tests.

  • In-region sub-test: pass/fail
  • Out-of-region sub-test: pass/fail
  • Analog copy protect: pass/fail (pass because of no analog TV-out is noted in log)


TD-6.7 Video Elementary Stream Routing Test

(This test has been eliminated.)


TD-6.8 Video Overlay Test

This test verifies graphics solution overlay capabilities that are required for video playback. The test must be run in a graphics mode of at least 16 bits/pixel and 800x600 resolution or better.

1. Hardware supports video overlay surface with scaling.

The test passes if the graphics solution supports overlay and has scaling capabilities. The following scaling ratios are verified:

Table 6-1. (X,Y) Overlay Scaling Tests

Input | Display | Scale H/V
352x576 | 704x576 | 2:1/1:1
352x480 | 704x480 | 2:1/1:1
352x288 | 704x576 | 2:1/2:1
352x240 | 704x480 | 2:1/2:1
704x576 | 352x288 | 1:2/1:2
704x480 | 352x240 | 1:2/1:2

2. Hardware supports VGA destination color keying for video rectangle.

The test passes if color keying for a video rectangle is supported. The test runs through various color key test scenarios and queries the user if the simulated video frames were visible as required, depending on the color key configuration.

3. Overlay accepts input at 1280x720 at 24 fps and 16 bpp, minimally.

The test streams a single frame of 1280x720 resolution to overlay to simulate video streaming. The maximum achievable frame rates are reported. The test passes if frames can be streamed to overlay at least 24 fps

[WinLogo 1.1] Overlay accepts input at 720x576 at 24 fps and 16 bpp, minimally.

The test streams a single frame of 720x576 resolution to overlay to simulate video streaming. The maximum achievable frame rates are reported. The test passes if frames can be streamed to overlay at least 24 fps.

4. Overlay accepts input at 720x576 at 24 fps and 16 bpp, minimally.
[WinLogo 1.1] Overlay supports at least one common YUV format.

This portion of the test verifies that the graphics adapter can generate overlay surfaces that support certain FourCC defined color formats. Each supported format is tested but it is only necessary to support one format to pass. However, if the overlay device claims to support a format but fails the test for that format, the entire test fails. The applicable FourCC formats are YUY2 and YV12.

5. Overlay provides high quality scaling.

The specification of this test is to be determined.

6. The video overlay must be fully operative at 640×480 and 1024×768 and color depths of 16 bpp and 32 bpp.
[WinLogo 1.1] Overlay supports 720x480/576 surfaces.

The test passes if overlay supports both of the above resolutions. The test sets up appropriate overlay surfaces (for each combination of the listed resolutions and color modes) and queries the user if they have been visible.


TD-6.9 Video DVD Playback Test

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.

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.

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.

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.10 Video Quality Test

[NEW v.0.5]

Most of the assertions for this test have been dropped. The assertion related to dropped frames is still in effect.

The motivation of the test is to ensure that systems can process and decode video streams with typical resolutions and frame rates without unnecessary quality degradation. While this should hold true for all types of video sources, the test focuses on MPEG-2 streams and uses custom MPEG-2 files to make compliance determinations. Quality is assessed in two places: 1) in memory, 2) at the optional TV Out port.

The test assesses the following video stream attributes:

  • Frame rate delivery.
  • Dropped frames.
  • Pixel corruption.
  • Image detail.
  • Color accuracy.

Note: Systems without DVD drives are not exempt from the test as MPEG-2 decoding and video stream handling is a basic system requirement.

Many mobile systems do not need to meet all of the Video Quality Test requirement depending on the type of panel used by the mobile system.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test relies on a supplied MPEG-2 file. The file(s) are supplied on a DVD ROM but systems that ship without DVD drives may copy them as file(s) to the hard disk to run the test. The test assesses video quality at the TV Out port, if available. The TV Out test requires a second system that captures the TV Out signal and analyzes it.

Results Interpretation

The Video Quality Test provides pass or fail results for both phases and the overall test result. The test also provides additional diagnostic information.


TD-6.11 CPU Utilization Test

[NEW v.0.5]
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 requirement does not apply to many mobile systems.

The test assesses CPU utilization during playback of the reference stream. The file(s) are supplied on a DVD ROM but systems that ship without DVD drives may copy the file(s) to disk to run the test.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test relies on a supplied MPEG-2 file. The file(s) are supplied on a DVD ROM but systems that ship without DVD drives may copy them as file(s) to the hard disk to run the test.

Results Interpretation

The CPU Utilization test provides pass or fail results on the assertions and additional diagnostic information.


TD-6.12 YUV Test

[NEW v.0.5]

To ensure that video filter stacks can be built with generic components using DirectShow, it is necessary to support a standard color format for video data interchange. The YUY2 format is required to be supported by the MPEG-2 decoder and both formats YUY2 must be supported by the graphics adapter overlay mechanism.

The test interrogates the MPEG-2 decode filter for support of the required color formats. If the decode filter finds support for the YUY2 format, then the test plays an MPEG-2 file encoded with that particular format. The test also investigates the overlay capabilities of the graphics adapter for YUY2 and YV12 compliance.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The system must have MPEG-2 decoding capabilities in either hardware, software, or as a hybrid.

Results Interpretation

The YUV Test generates pass or fail results for both the decoder and the graphics adapter. Both components must pass to pass the test.


TD-6.13 De-interlacing Test

[NEW v.0.5]

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.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The system must have MPEG-2 decoding capabilities in either hardware, software, or as a hybrid to play back the supplied MPEG-2 reference file.

Results Interpretation

The test determines compliance with both assertions. Both assertions must pass to pass the test.


TD-6.14 Pull-Down Test

[NEW v.0.5]

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 supplied MPEG-2 reference file. The system must have MPEG-2 decoding capabilities in either hardware, software, or as a hybrid.

Results Interpretation

The test determines compliance with the assertion. There is no diagnostic information.


TD-6.15 Refresh Sync Test

[NEW v.0.5]

Ideally, video frames are updated in lock-step with the refresh rate. For NTSC this would mean, for example, that the screen is refreshed at 59.54 Hz. However, when video is presented in a window (versus full screen) other windows would suffer from the low refresh rate. Thus when a video stream is played back on a 85 Hz refresh screen video frames need to be repeated or updated during refresh in a manner that is least irritating to the viewer. The repeat pattern is different for different frame rate to refresh ratios. The test addresses only NTSC and 85 Hz, respectively.

The test plays back an included MPEG-2 file that contains material that allows the DVI test device and the test software to determine if a frame is ever skipped or repeated more than once. The test evaluates three minutes of playback and permits 1 frame to be dropped to tolerate other causes for dropped frames.

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

The test determines compliance with the assertion and provides dropped frame diagnostic information.


TD-6.16 Audio/Video Sync Test

[NEW v.0.5]

MPEG-2 playback must be audio/video synchronized to avoid irritating lip-sync issues. Unsynchronized speech at slip rates of more than 100ms is easily noticed and unpleasant. While a maximum synchronization error of 75ms can be noticed in some cases it is sufficient for a high-quality experience for most content. As playback synchronization does not affect edit synchronization, where a much better level of synchronization is required, the 75ms tolerance does not deteriorate as a result of editing and re-editing.

The test uses three MPEG-2 files with facial and audio content. All MPEG’s will have the same audio and video content. Two of those files will have skewed audio/video data, where audio leads the video in one and video leads the audio in the other. The extent of the intended skews is 4 frames. The remaining MPEG has a properly synchronized data.

These MPEG-files are shown to the operator. If the operator chooses the synchronized MPEG files as having acceptable audio/video synchronized streams, then the test passes. The test has a total of 7 trials, where 3 of the trials use the properly synchronized MPEG and the other 4 trials use the skewed MPEG.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

The test requires three supplied MPEG-2 files and a system capable of decoding the files in a hardware method, a software method, or a hybrid method.

Results Interpretation

The test determines compliance with the assertion if the operator chooses the properly synchronized MPEG at least two of the 3 times it is played. If the user ever chooses a skewed MPEG more than once, then the test automatically fails.


TD-6.17 MSWebDVD Test Description

[Clarified v.0.7]

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, frame stepping, and image capturing) on various decoders. 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. Capturing a screen image is that last of the tests, a new form comes up in windowed mode to allow this test to come up.

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. Microsoft Windows 98/ME or Microsoft 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-6.18 DXVADecoder Test Description

[NEW v.0.5]

Overview

The DXVADecoder 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 are 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 Lost Test

The purpose of this test is to verify that basic DVD playback actions like fast forwarding, rewinding, navigating through menus and chapters, and time play. In addition, 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

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

The test determines compliance with the assertions.


Chapter 7: Video Telephony Test Specification

Draft Version: 0.7 — Date: February 12, 2001

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

[CLARIFIED v.0.7]

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.pcdesguide.org/library/http://www.pcdesguide.org/library/(@http://www.pcdesguide.org/library/)

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

Draft Version: 0.7 — Date: February 12, 2001

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.pcdesguide.org/library/http://www.pcdesguide.org/library/(@http://www.pcdesguide.org/library/)
  • PCI Bus Power Management Interface Specification, Revision 1.1 (PCI-PM)
    http://www.pcisig.com/developers/specification/
  • PCI Local Bus Specification, Revision 2.2 (PCI 2.2)
    http://www.pcisig.com/developers/specification/
  • Microsoft Windows Driver Development Kit
    http://www.microsoft.com/ddk/
    See "AGP Support" in the Windows Whistler 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: [CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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;n 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 AGP 2.0 Interface Test.

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: [CLARIFIED v.0.7] 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 AGP 2.0 Interface Test

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:[CLARIFIED v.0.7] 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 AGP 2.0 Interface Test

8.2.3 All AGP capability structures must contain a read-only status register and a read/write command register.

Reference documents: [CLARIFIED v.0.7] 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 AGP 2.0 Interface Test

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).

Reference documents: [CLARIFIED v.0.7] 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 AGP 2.0 Interface Test

8.2.5 All AGP compliant devices must support the AGP_ENABLE command bit.

Reference documents:[CLARIFIED v.0.7] 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 AGP 2.0 Interface Test

8.2.6 [CLARIFIED v.0.5] All AGP compliant devices implemented on desktop PCs must correctly report at least AGP 2X capability.

Integrated graphics solutions require the equivalent of AGP 1X or better.

Reference documents: [CLARIFIED v.0.7] 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 AGP 2.0 Interface Test

8.2.7 All AGP compliant systems are required to provide a minimum Graphics Aperture size setting of 64MB (recommended).

Reference documents: [CLARIFIED v.0.7] WLP# - B4.1.4.9; PC 2001 System Design Guide - GRPH-0163; PC 99 System Design Guide - 14.51.
Test description: TD-8.1 AGP 2.0 Interface Test

8.2.8 [NEW v.0.5] All AGP devices support a valid AGP 2.0 capability structure.

Reference documents: [CLARIFIED v.0.7] 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 AGP 2.0 Interface Test

8.2.9 [NEW v.0.5] 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: [CLARIFIED v.0.7] 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 AGP 2.0 Interface Test


AGP Memory Management Assertions

The following AGP memory management compliance assertions are tested with TD-8.2 AGP Graphics Address Relocation Table Test.

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: [CLARIFIED v.0.7] 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 Test

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: [CLARIFIED v.0.7] 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 Test

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: [CLARIFIED v.0.7] 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 Test

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: [CLARIFIED v.0.7] 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 Test

8.3.5 [CLARIFIED v.0.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 Test


AGP Transfer Mode Assertion

The following AGP transfer mode compliance assertion is tested with TD-8.3 AGP 2.0 Transfer Mode Test.

8.4.1 [CLARIFIED v.0.5] All AGP compliant devices implemented on desktop PCs must be capable of supporting AGP 2X data transfer mode.

Integrated graphics solutions require the equivalent of AGP 1X or better.

Reference documents:[CLARIFIED v.0.7] 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 AGP 2.0 Transfer Mode Test

8.4.2 [NEW v.0.5] Discrete graphics solutions require the equivalent of AGP 2.X or better.

Reference documents: [CLARIFIED v.0.7] 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 AGP 2.0 Transfer Mode Test

8.4.3 [NEW v.0.5] Integrated graphics solutions require the equivalent of AGP 1.X or better.

Reference documents: [CLARIFIED v.0.7] 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 AGP 2.0 Transfer Mode Test


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 AGP 2.0 Interface Test

[CLARIFIED v.0.5] – 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.
  • All AGP compliant devices must correctly report and be capable of managing a command request queue that contains at least one 32-bit command.
  • 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 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 initilization
  • 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 AGP 2.0 Transfer Mode Test

[CLARIFIE v.0.5] – Updated from AGP 1.0 to AGP 2.0.

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 largest possible surface size (up to a test-imposed maximum of about 8 MB) will be used. An attempt is made to create a textured AGP surface. Only if that fails will a non-textured surface be created.

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: 8 bits, 16 bits, 32 bits, and 64 bits, respectively. By reversing the bit order on these boundaries, errors between transfers are more likely to be detected. The remaining bits in each test case are padded with alternating all 1’s and 0’s. Since write-combining delivers information out-of-order, reordering errors are more easily detected.

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 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.

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

Draft Version: 0.7 — Date: February 12, 2001

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

[CLARIFIED v.0.7a]

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.pcdesguide.org/library/http://www.pcdesguide.org/library/(@http://www.pcdesguide.org/library/)

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

http://www2.fm.intel.com/pcd_ae/public/general/specs_ind/USB/uhci_1_1.pdf

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 are provided in the test descriptions.

[CLARIFIED - V. 0.7a - WLP requirements references]

9.1.1 System includes USB with two USB ports, minimum.

Reference documents: 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 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: PC 99 System Design Guide - 7.3.
Test description: TD-9.11 USB Specification Version 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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.

[CLARIFIED - V. 0.7a - WLP requirements references]

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: 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: PC 99 System Design Guide - 7.6.
Test description: TD-9.12 USB Host Controller Version Compliance Test

9.1.B1 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW] 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 [NEW v.0.5] 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

[CLARIFIED - V. 0.7a - WLP requirements references]

9.1.8 [CLARIFIED v.0.5] USB hubs comply with the USB 1.1 specification.

Reference documents: WLP# - B2.6.2; PC 99 System Design Guide - 7.8
Test description: TD-9.11 USB Specification Version 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 [NEW v.0.5] 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 Version Compliance Test

9.1.C2 [NEW v.0.5] 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 [NEW v.0.5] 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 Version Compliance Test

9.1.C3.1 [NEW v.0.5] 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 Version Compliance Test

9.1.C3.2 [NEW v.0.5] 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 Version Compliance Test

9.1.C4 [NEW v.0.5] 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

[CLARIFIED - V. 0.7a - WLP requirements references]

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 [CLARIFIED v.0.5] 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 [CLARIFIED v.0.5] 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 [CLARIFIED v.0.5] 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: 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 [NEW v.0.5] 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 Version Compliance Test

9.1.17 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 Version Compliance Test

9.1.24 [NEW v.0.5] 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 Version Compliance Test


USB Manual Interoperability Test Assertions

Assertions in this section are tested in TD-9.18 USB Manual Interoperability Test.
[CLARIFIED - V. 0.7a - WLP requirements references]

9.18.1 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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

The assertions in this sections are tested in TD-9.19 USB Port Reporting Test
[CLARIFIED - V. 0.7a - WLP requirements references]

9.19.1 [NEW v.0.5] 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.1 [NEW v.0.5] 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 Selective Suspend Test Description.
[CLARIFIED - V. 0.7a - WLP requirements references]

9.20.1 [NEW v.0.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.20 Selective Suspend Test Description

9.20.2 [NEW v.0.5] 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 Selective Suspend Test Description

9.20.3 [NEW v.0.5] 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 Selective Suspend Test Description

9.20.4 [NEW v.0.5] 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 Selective Suspend Test Description)


Device Enumeration Stress Test Assertions

The assertions in this sections are tested in TD-9.21 Device Enumeration Stress Test Description.
[CLARIFIED - V. 0.7a - WLP requirements references]

9.21.1 [NEW v.0.5] 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 Device Enumeration Stress Test Description

9.21.2 [NEW v.0.5] 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 Device Enumeration Stress Test Description

9.21.3 [NEW v.0.5] 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 Device Enumeration Stress Test Description

9.21.4 [NEW v.0.5] 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 Device Enumeration Stress Test Description

9.21.5 [NEW v.0.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 Device Enumeration Stress Test Description

9.21.6 [NEW v.0.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.21 Device Enumeration Stress Test Description

9.21.7 [NEW v.0.5] 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 Device Enumeration Stress Test Description

9.21.8 [NEW v.0.5] 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 Device Enumeration Stress Test Description

9.21.9 [NEW v.0.5] 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 Device Enumeration Stress Test Description

9.21.10 [NEW v.0.5] 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 Device Enumeration Stress Test Description


Address Test Assertions

Assumptions in this section are tested in TD-9.22 Address Test Description.
[CLARIFIED - V. 0.7a - WLP requirements references]

9.22.1 [NEW v.0.5] 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 Address Test Description

9.22.2 [NEW v.0.5] 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 Address Test Description

9.22.3 [NEW v.0.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.22 Address Test Description

9.22.4 [NEW v.0.5] 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 Address Test Description


Device Control Requests Test Assertions

The assertions in this section are tested in TD-9.23 Device Control Requests Test Description
[CLARIFIED - V. 0.7a - WLP requirements references]

9.23.1 [NEW v.0.5] 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 Device Control Requests Test Description

9.23.2 [NEW v.0.5] 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 Device Control Requests Test Description

9.23.3 [NEW v.0.5] 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 Device Control Requests Test Description

9.23.4 [NEW v.0.5] 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 Device Control Requests Test Description

9.23.5 [NEW v.0.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 Device Control Requests Test Description

9.23.6 [NEW v.0.5] 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 Device Control Requests Test Description

9.23.7 [NEW v.0.5] 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 Device Control Requests Test Description

9.23.8 [NEW v.0.5] 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 Device Control Requests Test Description

9.23.9 [NEW v.0.5] 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 Device Control Requests Test Description


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

[DELETED v.0.5]

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

[DELETED v.0.5]

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

[DELETED v.0.5]

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

[DELETED v.0.5]

Assertion 9.1.8 superseded by assertion 9.1.C1.

See test description TD-9.11 USB Specification Version Compliance Test.


TD-9.5 USB Port Power Switching Test Description

[CLARIFIED v.0.55]

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 Me, Windows 2000 or later versions of a Windows based O/S
  • 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

[CLARIFIED v.0.5]

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 Me, Windows 2000 or later versions of a Windows based O/S
  • 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

[CLARIFIED v.0.5]
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 Me, Windows 2000 or later versions of a Windows based O/S
  • 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

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 Me, Windows 2000 or later versions of a Windows operating system
  • 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

[CLARIFIED v.0.5]
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

[NEW v.0.5]
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 Me, Windows 2000 or later versions of Windows based O/S
  • 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 Version Compliance Test Description

[NEW v.0.5]

Overview

The test queries all USB devices and hubs in the system to determine which level of USB specification they support. Everything in the system must indicate compliance with Universal Serial Bus Specification 1.1 or 2.0. The test enumerates the USB bus through the USB software stack. Each device and hub in the system is queried to determine which level of the USB specification that it supports. 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 bit 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 Me, Windows 2000 or later versions of Windows based O/S
  • 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.

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

[NEW v.0.55]

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 – [CLARIFIED v.0.7] 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 Me, Windows 2000 or later versions of Windows based O/S
  • 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

[NEW v.0.5]

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 Me

Under 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 Me, Windows 2000 or a later version of Windows based O/S
  • 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

[NEW v.0.5]

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 softw are 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 Me, Windows 2000 or later versions of Windows based O/S
  • 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

[NEW v.0.5]

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 Me, Windows 2000 or later versions of Windows based O/S
  • 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

[NEW v.0.55]

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 Me, Windows 2000 or later versions of Windows based O/S
  • 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

[NEW v.0.5]

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 Me, Windows 2000 or later versions of Windows based O/S
  • 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

[NEW v0.5]

Overview

This test verifies that the USB device under test, or the system under test, 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 the following USB device tree. (Please see WHQL web site for a list of recommended USB devices.)

System

Port 1: USB Speakers (Isochronous)

Port 2: USB Hub #1

USB Hub #1

Port 1: USB Hub #2

Port 2: USB Mouse

USB Hub #2:

Port 1: USB Keyboard

Port 2: Quad Hub #3

USB Hub #3:

Port 1: USB Joystick

Port 2: USB Scanner / Printer (Bulk)

Port 3: USB Camera (Isochronous)

Once the required device tree is created, USB Verifier is installed on the device nodes, and the tool begins to track the data and driver behavior. Depending on the device under test, the user is required to exercise the USB device tree in the following manner:

System or Host Controller Test Procedure

The above 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 under test 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 hardware and software:

  • Windows Whistler Operating System.
  • (3) Four Port USB hubs
  • (1) USB Speakers
  • (1) USB Camera
  • (1) USB Printer or Scanner
  • (1) USB Mouse
  • (1) USB Keyboard
  • (1) USB Joystick
  • Device or system under test

Results Interpretation

The test fails if:

  • The required USB device tree is not created and/or 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

[NEW v0.5]

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 examine 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 Whistler 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 Selective Suspend Test Description

Overview

Whistler 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 Whistler 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 Device Enumeration Stress Test Description

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 Whistler 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 Addresss (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 Addresss (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 Whistler 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 Address Test Description

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

- Config. 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 Whistler 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 Device Control Requests Test Description

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 Addresss (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 Addresss (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 Whistler 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.


Chapter 10: ATA/ATAPI Peripheral and Controller Test Specification

Draft Version: 0.7 — Date: February 12, 2001

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

[CLARIFIED v.0.80a]

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/download/devdes/atamed.rtf

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.pcdesguide.org/library/http://www.pcdesguide.org/library/(@http://www.pcdesguide.org/library/)

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.

[CLARIFIED v.0.80a - added precise WLP References]

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 [CLARIFIED v.0.5] 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 [NEW v.0.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 [NEW v.0.5] 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.

[CLARIFIED v.0.80a - added precise WLP References]

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: Test Not Specified

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: Test Not Specified

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: Test Not Specified

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: Test Not Specified

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: Test Not Specified

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: Test Not Specified

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: Test Not Specified

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: Test Not Specified

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: Test Not Specified

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: Test Not Specified

10.2.11 [NEW v.0.5] 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: Test Not Specified


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.

[CLARIFIED v.0.80a - added precise WLP References]

10.3.1 Controller and peripherals comply with ATA-2, ATA-3 or ATA/ATAPI-4 protocols.

Reference Documents: 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: 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: PC 99 System Design Guide - 10.17.
Test Description: TD-10.6 ATA/ATAPI Hard Disk Drive Power Management Capability Test

10.3.5 [CLARIFIED v.0.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 [NEW v.0.5] 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 [NEW v.0.5] 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: PC 99 System Design Guide - 18.15.
Test Description: Test Not Specified


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.

[CLARIFIED v.0.80a - added precise WLP References]

10.5.1 Controller and peripherals comply with: ATA-2, ATA-3 or ATA/ATAPI-4 protocols.

Reference Documents: 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: 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 [NEW v.0.5] 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 [NEW v.0.5] 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 [NEW v.0.5] 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: 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.

[CLARIFIED v.0.80a - added precise WLP References]

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: Test Not Specified

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: Test Not Specified

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: Test Not Specified

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: Test Not Specified

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: Test Not Specified

10.6.6 OS enumeration of all ATAPI devices complies with ATA/ATAPI-4 or SFF 8020I v.2.5.

Reference Documents: PC 99 System Design Guide - 10.11.
Test Descriptions: Test Not Specified

10.6.7 [NEW v.0.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: Test Not Specified


ATA/ATAPI-5 DVD Assertions

The following ATA/ATAPI-5 DVD assertions are tested.

[CLARIFIED v.0.80a - added precise WLP References]

10.7.1 Controller and peripherals comply with: ATA-2, ATA-3 or ATA/ATAPI-4 protocols.

Reference Documents: 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: 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 [NEW v.0.5] 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 [NEW v.0.5] 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: 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.

[CLARIFIED v.0.80a - added precise WLP References]

10.8.1 [CLARIFIED v.0.5] 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: Test Not Specified

10.8.2 DVD drive meets minimum compatibility requirements.

Reference Documents: PC 99 System Design Guide - 18.27.
Test Descriptions: Test Not Specified

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: Test Not Specified

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: None

10.8.5 [NEW v.0.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: Test Not Specified


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

[CLARIFIED v.0.5]

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

[CLARIFIED v.0.5]
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

[CLARIFIED v.0.5]
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

[CLARIFIED v.0.5]
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

[CLARIFIED v.0.5]

Assertion 10.1.1 is superseded by assertions 10.1.5 and 10.3.8.

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

[CLARIFIED v.0.5]

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

[CLARIFIED v.0.5]

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 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
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

[CLARIFIED v.0.5]

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

[CLARIFIED v.0.5]

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

[CLARIFIED v.0.5]

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

[CLARIFIED v.0.5]

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

[CLARIFIED v.0.5] – Merged into 10.2.


TD-10.13 ATAPI-5 Capability Test

[NEW v.0.5]

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

[NEW v.0.5]

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

[CLARIFIED v.0.5] – Merged into 10.3.


TD-10.17 ATAPI-5 Compliance Test

[NEW v.0.5]

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

[NEW v.0.5]

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

Draft Version: 0.7 — Date: February 12, 2001

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 | [CLARIFIED] 4K( min. impedance (Tip to ground) | Checklist
11.3.7 | [CLARIFIED] 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 | [CLARIFIED] 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 | [CLARIFIED] 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

[CLARIFIED v.0.80]

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.pcdesguide.org/library/

Personal Computer Audio Quality Measurements

http://www.cirrus.com/products/papers/meas/meas.html


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).

[CLARIFIED v.0.80 - WLP# references added]

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).

[CLARIFIED v.0.80 - WLP# references added]

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 [CLARIFIED v.0.5] 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 [CLARIFIED v.0.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).

[CLARIFIED v.0.80 - WLP# references added]

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 [CLARIFIED v.0.5] 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 [CLARIFIED v.0.5] 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).

[CLARIFIED v.0.80 - WLP# references added]

11.4.1 [CLARIFIED v.0.5] 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 [CLARIFIED v.0.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

Draft Version: 0.7 — Date: February 12, 2001

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 Preboot 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 (if implemented)

System BIOS provides remote lockout capability

Test Methodology

Three 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, if implemented, Boot Integrity Service capability. 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 third type of test verifies the SUT can successfully install Windows 2000 Professional using Windows 2000 Remote Installation Services (RIS). Windows 2000 Remote Installation Services works with PXE 2.0 enabled computers to allow for an unattended installation to be done over a network.

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 three Windows 2000 servers 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
  • A Windows 2000 Professional 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

[CLARIFIED v.0.80a]

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.pcdesguide.org/library/http://www.pcdesguide.org/library/(@http://www.pcdesguide.org/library/)

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.

[CLARIFIED v.0.80a - add WLP# references]

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 [CLARIFIED v.0.5] F12 key must force a system boot initiated from the network adapter.

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 [Revised v.0.80a] System UUID is provided.

Reference document: WLP# - A1.1.4; PC 2001 System Design Guide - BIOS-0014.3
Test description: TD-12.3 UUID Present in Printed Form 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 [NEW v.0.5] System BIOS provides Remote Lockout Capability.

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 [NEW v.0.5; revised 0.80a] BIOS supports Boot Integrity Services (BIS), if system includes BIS support

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.


TD-12.1 BIOS Supports Booting System from the Network Test

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

[CLARIFIED v.0.5]
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 in Printed Form Test

WHQL Test Specification

Previous Next

TD-12.3 UUID Present

[CLARIFIED v.0.5; Revised v.0.80a]
Test is not specified.


TD-12.4 Remote Boot Supported Test

[CLARIFIED v.0.5]
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

[CLARIFIED v.0.5]
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

[NEW v.0.5]
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.

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 "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 either Remote Lockout Capability is not available or not implemented correctly the system fails the test.


TD-12.7 BIOS Supports Boot Integrity Service Test

[NEW v.0.5]
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

[NEW v.0.5]

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"


Chapter 13: Digital Still Imaging and WIA Test Specification

Draft Version: 0.7 — Date: February 12, 2001

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 Whistler, and later versions of the operating system.

For systems shipping before July 2000 running Windows 2000 or Windows 98, 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 "Whistler."

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 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

Tests execute on systems that are Windows Logo Program compliant, running either Windows 98/Me or Windows 2000. 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.


Reference Documents for Still Imaging Test Assertions

[CLARIFIED v.0.7a]

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/profiles.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 Whistler 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.pcdesguide.org/library/


Digital Still Imaging Test Assertions

ICC, Image Download, and PC-Compatible Test Assertions

[CLARIFIED v.0.7a - add WLP# requirements]

The assertions in this section are tested in:
TD-13.1 ICC Profile Test
TD-13.2 Image Download Test
TD-13.3 PC-Compatible Files System Test

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 ICC 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 ICC 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 ICC 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 ICC 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 ICC 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 ICC 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 ICC 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 ICC 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 ICC 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 ICC 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 ICC 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 ICC 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 ICC 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 ICC 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 ICC 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 ICC 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 ICC Profile 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

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

[CLARIFIED v.0.7a - add WLP# requirements]

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

[CLARIFIED v.0.7a - add WLP# requirements]
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 [New - v.0.7] 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 [New - v.0.7] 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 [New - v.0.7] 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 [New - v.0.7] 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 [New - v.0.7] 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 [New - v.0.7] 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 [New - v.0.7] 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 [New - v.0.7] 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 [New - v.0.7] 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 [New - v.0.7] 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 [New - v.0.7] 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 [New - v.0.7] 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 [New - v.0.7] 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 [New - v.0.7] 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 [New - v.0.7] 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 [New - v.0.7] 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 [New - v.0.7] 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 [New - v.0.7] 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 [New - v.0.7] 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 [New - v.0.7] 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 [New - v.0.7] 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 [New - v.0.7] 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 [New - v.0.7] 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 [New - v.0.7] 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 [New - v.0.7] 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 [New - v.0.7] 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 [New - v.0.7] 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 [New - v.0.7] 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 [New - v.0.7] 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 [New - v.0.7] 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 [New - v.0.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 [New - v.0.7] 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 [New - v.0.7] 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

[Clarified - v.0.7]


WIA Micro-Driver Required Functions Test Assertions

[Clarified - v.0.7]

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

[Clarified - v.0.7]

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

[Clarified - v.0.7]

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

[Clarified - v.0.7]

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

[New - v.0.7]

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: TBD


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 ICC Profile Test

Setup

The ICC color management test enumerates all available still imaging devices. If there is more than one device connected, the operator selects the device under examination.

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 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 the tag data that is present are 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.

Results Interpretation

All assertions exercised by the ICC Profile test must pass for the test to pass. The log indicates the profile interpretation and lists all header values in hexadecimal form and indicates the appropriate meaning of the value.


TD-13.2 Image Download Test

The objective of this test is to ascertain that the 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-Compatible Files System Test

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

General

The 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.

Test Environment

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.


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

[New - v.0.7]

# - 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

[New - v.0.7]

# - 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

[New - v.0.7]

# - 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

[New - v.0.7]

# - 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

[New - v.0.7]

# - 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

[New - v.0.7]

# - 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

[New - v.0.7]

# - 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

[New - v.0.7]

# - 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

[New - v.0.7]

# - 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

[New - v.0.7]

# - 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

[New - v.0.7]

# - 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

[New - v.0.7]

# - 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

[New - v.0.7]

# - 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

[New - v.0.7]

# - 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

[New - v.0.7]

# - 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

[New - v.0.7]

# - 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

[New - v.0.7]

# - 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

[New - v.0.7]

# - 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

[New - v.0.7]

# - 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

[New - v.0.7]

# - 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

[New - v.0.7]

# - 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

[New - v.0.7]

# - 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

[New - v.0.7]

# - 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

[New - v.0.7]

# - 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

[New - v.0.7]

# - 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

[New - v.0.7]

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

[New - v.0.7]

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

[New - v.0.7]

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

[Modified - v.0.7]

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

[New - v.0.7]

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

[New - v.0.7]

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

[New - v.0.7]

# - 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

[New - v.0.7]

# - 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

[New - v.0.7]

# - 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

[Clarified - v.0.7]

Overview

MicroDrvTest.exe is a tool to test IHV-supplied WIA micro-drivers for their flatbed scanners. 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.

MicroDrvTest.exe tests 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:

  5. 1. Have a Windows version that supports WIA and the flatbed scanner connected to the test machine.
  6. 2. Turn power on.
  7. 3. Run MicroDrvTest.exe.
  8. 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".
  9. 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

Draft Version: 0.7 — Date: February 12, 2001

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 card, previously referred to as PCMCIA cards, 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 "CardBus 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.pcdesguide.org/library/pccard.htm (or in PC 2001 System Design Guide .CHM file)

Microsoft Windows Driver Development Kit

http://www.microsoft.com/ddk/
See "Supporting Multifunction PCI Devices" and "System-Supplied Setup Classes" in the Windows Whistler 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.pcdesguide.org/library/

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/developers/specification/

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.pc-card.com/bookstore.htm

PCI to PCMCIA CardBus Bridge Register Description

http://www.pc-card.com/bookstore.htm

PCI Local Bus Specification, Revision 2.2 (PCI 2.2)

http://www.pcisig.com/developers/specification/


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: 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)


PC 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/Card Power Management Register Assertions

The following CardBus Bridge/Card Power Management Register assertions are tested in the CardBus Bridge/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card Power Management Register Test (CBPMREG)

14.9.14 [CLARIFIED v.0.5] 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card Power Management Register Test (CBPMREG)

14.9.25 [CLARIFIED v.0.5] 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/Card Power Management Register Test (CBPMREG)

14.9.26 [CLARIFIED v.0.5] 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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/Card 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.11Clearing 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)


CardBus 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 ExCA Compatibility Test (EXCA)

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)

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)

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)

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)

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)

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)

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)

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/Card Power Management Register Test (CBPMREG)

The purpose of the CBPMREG test is to probe CardBus Bridge/Card 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/cards 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)

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)

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

Draft Version: 0.7 — Date: February 12, 2001

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.pcdesguide.org/library/


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.

15.5.1 [NEW v.0.5] 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 [NEW v.0.5] 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)

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)

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)

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)

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

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

This test is an operator dependent test. 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. If the desktop properly appears, then the test passes.


Chapter 16: Audio Test Specification

Draft Version: 0.7 — Date: February 12, 2001

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 messages.

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 IA-32 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 or Windows 2000 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. The general architecture of the system is shown in Figure 16-1.

Figure 16-1 SAServer Architecture

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 accessable 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

[Clarified - v.0.8]

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.pcdesguide.org/library/
  • 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 Whistler 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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 restared.

Reference document: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio DirectSound Driver Test (DsDrvTst)

16.4.16 Same as 16.4.9 except that this test is testing random format wave data.

Reference document: [Clarified - v.0.8] 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 Audio DirectSound Driver Test (DsDrvTst)

16.4.17 Same as 16.4.10 except that this test is testing random format wave data.

Reference document: [Clarified - v.0.8] 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 Audio DirectSound Driver Test (DsDrvTst)

16.4.18 Same as 16.4.11 except that this test is testing random format wave data.

Reference document: [Clarified - v.0.8] 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 Audio DirectSound Driver Test (DsDrvTst)

16.4.19 Same as 16.4.12 except that this test is testing random format wave data.

Reference document: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio DirectSound Driver Test (DsDrvTst)

16.4.200 The DirectSound device must support DirectSoundCaptureEnumerate API, which queries SysAudio device info.

Reference document: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio DirectSound Driver Test (DsDrvTst)

16.4.204 The DirectSound device must support IDirectSoundCaptureBuffer::GetFormat API.

Reference document: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.3 The mixerGetDevCaps must not write more than cbmxcaps bytes into the pmxcaps buffer.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.4 The mixerGetDevCaps must not crash if cbmxcaps bytes passed in less than the sizeof (MIXERCAPS).

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.5 mixerOpen must work with the CALLBACK_WINDOW flag specified.

Reference document: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.7 mixerOpen must work with the MIXER_OBJECTF_MIXER flag specified.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.8 Mixer APIs called on a closed mixer handle (via mixerClose) will fail.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.9 mixerGetLineInfo must produce a unique mixer ID for each DST line.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.10 mixerGetLineInfo must produce a unique mixer ID for each SRC line.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.11 mixerGetLineInfo must return information about each mixer line.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.12 mixerGetLineInfo must return correct information about each component type.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.13 mixerGetLineInfo must return correct information about each available target type.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.14 mixerGetLineControls must return unique control id for each control.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.15 mixerGetLineControls must return consistent control information if called with MIXER_GETLINECONTROLSF_ONEBYID flag.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.16 mixerGetLineControls must return consistent control information if called with MIXER_GETLINECONTROLSF_ONEBYTYPE flag.

Reference document: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.18 mixerGetLineControls must return error, if called with an invalid dwControlId using MIXER_GETLINECONTROLSF_ONEBYID flag.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.19 mixerGetLineControls must return error, if called with an invalid dwControlType using MIXER_GETLINECONTROLSF_ONEBYTYPE flag.

Reference document: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.21 mixerSetControlDetails and mixerGetControlDetails must work for all mixer control details properly. (VALUE)

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.22 mixerSetControlDetails and mixerGetControlDetails must work for all mixer control detail properly. (LISTTEXT)

Reference document: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.25 mixerGetControlDetails must return MIXERR_INVALCONTROL if invalid dwControlId is passed.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.26 mixerGetControlDetails must return error if invalid cChannel is passed.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.27 mixerGetControlDetails must return error if invalid cMultipleItems is passed.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.28 mixerSetControlDetails must return MIXERR_INVALCONTROL if invalid dwControlId is passed.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.29 mixerSetControlDetails must return error if invalid cChannel is passed.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.30 mixerSetControlDetails must return error if invalid cMultipleItems is passed.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.31 Verifies that mixerSetControlDetails works for all controls in a uniform manner.

Reference document: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.33 Changing master volume must affect wave playback volume.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.34 Changing master volume must affect MIDI playback volume.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.35 Changing master volume must affect CD playback volume.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.36 Changing master volume must affect Line-In playback volume.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.37 Changing master volume balance must affect wave playback balance.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.38 Changing master volume balance must affect MIDI playback balance.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.39 Changing master volume balance must affect CD playback balance.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.40 Changing master volume balance must affect Line-In playback balance.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.41 Changing wave volume must affect wave playback volume.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.42 Changing MIDI volume must affect MIDI playback volume.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.43 Changing CD volume must affect CD playback volume.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.44 Changing Line-In volume must affect Line-In playback volume.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.45 Changing wave volume balance must affect wave playback volume.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.46 Changing MIDI volume balance must affect MIDI playback balance.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.47 Changing CD volume balance must affect CD playback balance.

Reference document: [Clarified - v.0.8] 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 Audio Mixer Driver Test (MIXDRV32)

16.8.48 Changing Line-In volume balance must affect Line-In playback balance.

Reference document: [Clarified - v.0.8] 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 Audio 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 [image] { 1, 2}
  • nSamplesPerSec [image] {8k, 11025, 16k, 22050, 32k, 44100, 48k }
  • wBitsPerSample [image] { 8, 16 }

Reference document: [Clarified - v.0.8] 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 [image] { 1, 2 }
  • nSamplesPerSec [image] { 8k, 11025, 16k, 22050, 32k, 44100, 48k }
  • wBitsPerSample [image] { 8, 16 }

Reference document: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio 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: [Clarified - v.0.8] 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 Audio Full Duplex Test (FDuplex)

Note: Test assertions 16.16.x through 16.29.x are undefined.


Audio Quality Test Assertions

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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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 samplerate. Deviations from linearity must be within the following tolerances: max < 4 ms, standard deviation < 1 ms.

Reference document: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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 samplerate. Deviations from linearity must be within the following tolerances: max < 4 ms, standard deviation < 1 ms.

Reference document: [Clarified - v.0.8] 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

[New - v.0.2]

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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] WLP# B3.1.1
Test description: TD-16.11 KS DirectMusic Filter Test (KSDMTst.exe) Description


DMDrv Test Assertions

[New - v.0.2]

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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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 fata.

Reference document: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.75-16.34.77 Verifies that we can get, increase, and decrease volume via GUID_DMUS_PROP_Volume, if it claims to be supported.

Reference document: [Clarified - v.0.8] WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.78-16.34.79 Verifies that we can get and set GUID_DMUS_PROP_WriteLatency, if it claims to be supported.

Reference document: [Clarified - v.0.8] WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.80-16.34.81 Verifies that we can get and set GUID_DMUS_PROP_WritePeriod, if it claims to be supported.

Reference document: [Clarified - v.0.8] WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

16.34.82-16.34.84 Verifies that we can get, increase, and decrease volume via KSPROPERTY_SYNTH_VOLUME, if it claims to be supported.

Reference document: [Clarified - v.0.8] WLP# B3.1.1
Test description: TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description


AC3Test Test Assertions

[New - v.0.2]

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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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 preceeds it.

Reference document: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] WLP# B3.1.1
Test description: TD-16.13 AC-3 Driver (AC3Test.exe)Test Description


GFX Test Assertions

[New - v.0.8]

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: [Clarified - v.0.8] WLP# B3.1.1
Test description: TD-16.35 GFX (gfxtest.exe) Test Description

16.36.100 addplayremoveplay_defaultzone.

[New - v.0.8a]

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.

[New - v.0.8a]

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.

[New - v.0.8a]

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.

[New - v.0.8a]

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.

[New - v.0.8a]

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.

[New - v.0.8a]

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.

[New - v.0.8a]

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.

[New - v.0.8a]

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.

[New - v.0.8a]

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 Audio DirectSound Driver Test (DsDrvTst)

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 or Windows 2000 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)

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 in 5 secs)

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 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. Refer to TD-16.7 Audio Quality Test (AUDQLTY) setup for details.

Windows 98 Second Edition or Windows 2000 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.3 Audio Mixer Driver Test (MIXDRV32)

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 or Windows 2000 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)

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 or Windows 2000 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)

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 or Windows 2000 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 Audio Full Duplex Test (FDuplex)

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 or Windows 2000. 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)

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 or Windows 2000.

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 and Windows 2000 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 Remote Process Invoking feature runs SAServer whenever it is needed)

Windows 98 Second Edition and Windows 2000

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 99 Audio Device Test (PC99Aud)

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 or Windows 2000.

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)

Note: This test is no longer done

Overview

The Digital Rights Management test assures that the audio device complies with portions of Windows Millennium Edition DRM Supplement to the Windows 2000 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)

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 or Windows 2000 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

[New - v.0.5]

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 Whistler.

Results Interpretation

A test case can pass, fail, abort, or return pending.


TD-16.12 DirectMusic Driver (DMDrv.exe) Test Description

[New - v.0.5]

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 Whistler.

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

[New - v.0.5]

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 Whistler. 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

[New - v. 0.8a]

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

TBD

Results Interpretation

TBD


TD-16.35 GFX (gfxtest.exe) Test Description

[New - v. 0.8a]

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 Whistler. 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 retriece 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 Whistler. 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

Draft Version: 0.7 — Date: February 12, 2001

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 shownin
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.pcdesguide.org/library/


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 [CLARIFIED - 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 [NEW v.0.5] 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)

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.
    [CHANGED TO 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)

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)

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

Draft Version: 0.7 — Date: February 12, 2001

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/NewPC/debugspec.htm
  • Legacy-Free Design Requirements
    http://www.microsoft.com/hwdev/NewPC/LF.htm
  • PC 2001 System Design Guide and PC 99 System Design Guide,
    http://www.pcdesguide.org/library/
  • 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: [Clarified - v.0.8] WLP# - A1.4.3; 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 MSDOS 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: [Clarified - v.0.8] WLP# - A4.4.8; PC 2001 System Design Guide - SYS-0042.
Test description: TD-18.1 Legacy Free Test (LegFree)

18.1.3 Secondary boot and upgrade capability is independent of FDC-based floppy disk drive.

Reference documents: [Clarified - v.0.8] WLP# - A1.4.8; PC 2001 System Design Guide - SYS-0067.
Test description: TD-18.1 Legacy Free Test (LegFree)

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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] WLP# - A4.4.7; PC 2001 System Design Guide - INPT-0133.
Test description: TD-18.1 Legacy Free Test (LegFree)

18.3.3 System recovery media must not be provided on floppy disks. Bootable CD or DVD is the recommended media.

Reference documents: [Clarified - v.0.8] WLP# - A4.4.3; PC 2001 System Design Guide - BIOS-0005.1; SYS-0039; MOBL-0072.
Test description: TD-18.1 Legacy Free Test (LegFree)

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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] WLP# - A1.4.10; PC 2001 System Design Guide - BIOS-0012.
Test description: TD-18.1 Legacy Free Test (LegFree)

18.4.6 System timer is supported at system boot.

The ROM BIOS must make sure that the timer is on at system boot and that timer interrupts are occurring as part of POST or RESET.

Reference documents: [Clarified - v.0.8] WLP# - A1.4.11; PC 2001 System Design Guide - BIOS-0005.5.
Test description: TD-18.1 Legacy Free Test (LegFree)

18.4.7 The LEGACY_DEVICES flag is set to 0 in the ACPI Fixed ACPI Description Table (FADT).

Reference documents: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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.)

Reference documents: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] 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: [Clarified - v.0.8] WLP# - A1.4.12; PC 2001 System Design Guide - SYS-0001.3.
Test description: TD-18.1 Legacy Free Test (LegFree)

18.5.4 [CLARIFIED v.0.8] If IEEE 1394 is implemented, the host controller must comply with IEEE 1394a and 1394 OHCI 1.0.

Reference documents: [Clarified - v.0.8] 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 [CORRECTED - v.0.8] DELETED
18.5.10 [CORRECTED - v.0.8] 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)

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

Draft Version: 0.7 — Date: February 12, 2001

The purpose of this test specification is to provide test coverage for 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

Reference Document Sources for IEEE 1394 Assertions

[CLARIFIED v.0.7]

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.pcdesguide.org/library/

SBP-2 Support and Windows 2000

http://www.microsoft.com/hwdev/print/sbp2_w2000.htm


Data Transfer 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: [CLARIFIED v.0.7] WLP#-B2.2.1.3; PC 2001 System Design Guide - 1394-0096.
Test Description: TD-19.1 Data Transfer Rate 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: [CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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


IEEE 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: [CLARIFIED v.0.7] WLP#-B2.2.4.2; PC 2001 System Design Guide - 1394-0099; IEEE 1212-2000.
Test Description: TD-19.17 IEEE 1394 Configuration ROM Test (1394node.exe) Description

19.18.2 Devices must supply textual descriptors for the Vendor_ID and Model_ID entries of the Configuration ROM.

Reference document: [CLARIFIED v.0.7] WLP#-B2.2.4.12; PC 2001 System Design Guide - 1394-0099; IEEE 1212-2000.
Test Description: TD-19.17 IEEE 1394 Configuration ROM Test (1394node.exe) Description


IEEE 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: [CLARIFIED v.0.7] WLP#-B2.2.1.3; PC 2001 System Design Guide - 1394-0096.
Test description: TD-19.18 IEEE 1394 Interoperability Test (1394hct.exe –I) Description


IEEE 1394 Test Descriptions

TD-19.1 Data Transfer Rate Test Description

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

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

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

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 HostController Power Management Test Description

WHQL Test Specification

Previous Next

TD-19.5 Host Controller Power Management Test Description

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.

TBD: hardware and software requirements

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

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

The device is connected to two other devices through different ports. Then, the device is powered off. The two powered devices must be able to communicate, using the unpowered device as a repeater. All serial bus traffic must be passed across the unpowered device.

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

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

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

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

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

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

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

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

TBD


TD-19.15 POWER_CHANGE Config ROM Test Description

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

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 IEEE 1394 Configuration ROM Test (1394node.exe) Description

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 IEEE 1394 Interoperability Test (1394hct.exe –I) Description

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

TBD


Chapter 20: Modem Test Specification

Draft Version: 0.7 — Date: February 12, 2001

This document describes assertions and tests for Modems This document also provides test coverage information to facilitate initial development and review cycle processes focussing 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

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/specs/PMref/PMcom.htm

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.pcdesguide.org/library/

PHS Internal Access Forum Specification (PIAFS)

http://mitf.arib.or.jp/e/menu.html

SII NS-2482-30

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


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)TD-20.3 Error Control Test (ERRCTRL)(TS_470)

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)TD-20.3 Error Control Test (ERRCTRL)(TS_470)


Forced Error Control - Modeme eAssertions

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 modem supports AT+GCI=? command, it displays the list of countries 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 modem supports AT+GCI=? command, the list of countries 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 modem supports AT+GCI? command, country code returned by this command is present in the list of countries 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

Results Interpretation

Failures in SENDFILE3 and SENDFILE8 can be caused due to wrong setting of phone numbers, line failures, interop 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.

1. COMPRESSION will perform the following steps:

2. Static Initialization of Test and Reference Modem

3. Dynamic Initialization with AT Command to set compression ON for Test and Reference Modem

4. Test Modem setting up call using ATDT and getting Connection Response.(Dial Mode)

5. ASSERT (20.2.1): Check Connection Response to verify if Compression 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 compression OFF for Test and Reference Modem

11. Test Modem setting up call using ATDT and getting Connection Response.(Dial Mode)

12. ASSERT (20.2.2.): Check Connection Response to verify if Compression Bit is OFF

13. ASSERT (20.1.1): Test Fail if Connection is not established

14. Send ASCII data from Test Modem and Receive same ASCII data on Reference Modem.

15. ASSERT (20.1.2): Test Fail if CRC value for the ASCII data does not match.

16. Hang up Call for Test and Reference Modem

17. Dynamic Initialization with AT Command to set compression ON for Test and Reference Modem

18. Test Modem setting up call using ATA and getting Connection Response.(Answer Mode)

19. ASSERT (20.2.1): Check Connection Response to verify if Compression Bit is ON

20. ASSERT (20.1.1): Test Fail if Connection is not established

21. Send ASCII data from Test Modem and Receive same ASCII data on Reference Modem

22. ASSERT (20.1.2): Test Fail if CRC value for the ASCII data does not match.

23. Hang up Call for Test and Reference Modem

24. Dynamic Initialization with AT Command to set compression OFF for Test and Reference Modem

25. Test Modem setting up call using ATA and getting Connection Response.(Answer Mode)

26. ASSERT (20.2.2): Check Connection Response to verify if Compression Bit is OFF

27. ASSERT (20.1.1): Test Fail if Connection is not established

28. Send ASCII data from Test Modem and Receive same ASCII data on Reference Modem.

29. ASSERT (20.1.2): Test Fail if CRC value for the ASCII data does not match.

30. Hang up Call for Test and Reference Modem

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

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

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

Results Interpretation

Failures in SPEED3 and SPEED6 can be caused due to wrong setting of phone numbers, line failures, interop 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 Pass 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

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, interop 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 InactivityTimeout 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.

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, interop 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 Pass 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.

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, interop 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 Pass 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.

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, interop 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

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 which 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. The user needs to 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

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 a 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

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

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

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

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

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

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

Results Interpretation

Failure in SPHOOKSWITCH8, SPHOOKSWITCH13 and SPHOOKSWITCH18 is caused if user thinks that the modem did not work with speaker and microphone. 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

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

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

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 Warning and End Test
  4. ASSERT (20.22.1): Check if the list of countries 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 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 Warning and End Test
  8. ASSERT (20.22.3): For country code returned, check if it is present in the list got in Step 4.

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

Draft Version: 0.7 — Date: February 12, 2001

This chapter describes the anti-virus file system test assertions tested.


References for Anti-Virus File System Test Assertions

Application Specification for Microsoft Windows 2000 for Desktop Applications"

http://msdn.microsoft.com/winlogo/


Anti-virus File System Test Assertions

This section provides 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 assertions to comply with that are not to be 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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
Test descriptions: Not tested

21.1.9 All file system filters must propagate fast IO callbacks.

Reference documents: TBD
Test descriptions: Not tested

21.1.10 File system filters must be able to handle dynamic volumes that can appear or disappear.

Reference documents: TBD
Test descriptions: Not tested

21.1.11 File system filters must be responsive to HSM.

Reference documents: TBD
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: TBD
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 future Whistler requirement, all kernel mode drivers must be right-click installable by an INF file.

Reference documents: TBD
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 future requirement for Whistler

Reference documents: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
Test descriptions: TD-21.16 SectionCaching File System Test Group – DataImageCoherencyTest

21.16.7 The file system will not supercede or overwrite files when a view on a user mapping exists.

Reference documents: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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 a files and directories provided that BACKUP/RESTORE privileges are enabled.

Reference documents: TBD
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: TBD
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: TBD
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: TBD
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 can not be reset.

Reference documents: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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 a non-sparse files to zero.

Reference documents: TBD
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 nonsparse file when it is a overwritten.

Reference documents: TBD
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: TBD
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 a sparse files.

Reference documents: TBD
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: TBD
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: TBD
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 nonsparse file when the file is superseded.

Reference documents: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
Test descriptions: TD-21.22 ExtendedSecurity File System TestTD-21.22 ExtendedSecurity File System Test(TS_658) – 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: TBD
Test descriptions: TD-21.22 ExtendedSecurity File System TestTD-21.22 ExtendedSecurity File System Test(TS_658) – 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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
Test descriptions: TD-21.27 ChangeJournal File System Test Group

21.27.14 The change journal must accurately report the allocation size.

Reference documents: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
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: TBD
Test descriptions: TD-21.29 DefragEnhancements File System Test Group – MoveViewTest


I/O Stress 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: TBD
Test descriptions: TD-21.30 I/O Stress Test Description


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

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 which 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 filenames that differ only in case. That is when two filenames are identical except for case, they are considered different files. This is verified by using the create file function with several filenames 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 filenames. That is when a file is created with a mixed case filename, the directory contents when queried return filenames that reflect the original mixed case. This is verified by using the create file function call with several filenames that have mixed case. The directory is then queried. The returned filenames 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 filenames 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 filename. 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 filenames and several filenames that use extended characters. The directory is then queried. The returned short and long filenames 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 filename is created within the upper bound of the maximum component length. Only the filename 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 a 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 should return a 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 should return a 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 a 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. The 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 testfile is opened and an attempt is made to rename the filename to an existing filename. 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 testfile or directory is renamed to an existing filename (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 testfile is opened twice (two handles are opened to the same file), a file rename is attempted on both handles, 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. A 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

TBD

Click to show or hide information. NotificationCleanupFileSizeTest

TBD

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

TBD

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 open 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

TBD - 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

TBD


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 filesystem 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 with a 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

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 a 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

TBD

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 handle 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 superceded 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 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.

The code path that returns STATUS_REPARSE_ATTRIBUTE_CONFLICT is exercised by attempting

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 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 which 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

TBD

Click to show or hide information. SetPointAttributeConflictTest

TBD


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, i.e., with opened file handles. This operation is expected to succeed, except for two cases: i) the volume is the system drive, which cannot be dismounted. The operation fails with STATUS_ACCESS_DENIED; ii) 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 is 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, 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 filesystem 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 specifing 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 I/O Stress Test Description

The 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.


IO 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. This test is Windows 2000 specific

Click to show or hide information. Usnstres

Stresses FSCTL’s associated with USN journal. This test is Windows 2000 specific.

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. This test is Windows 2000 specific.

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 2000 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 IO 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

TBD

Appendix B - Command Line Options

TBD

Appendix C - IFS Test Status Codes

TBD

Appendix D - Using NTLOG with IFS Test

TBD

Appendix E - File System Test Groups

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


Chapter 22: Driver Quality Test Specification

Draft Version: 0.7 — Date: February 12, 2001

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.


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.pcdesguide.org/library/

If there are conflicts between the hardware and software specifications, refer to Microsoft Windows Logo Program (WLP) System and Device Requirements for guidance.


Driver Quality Test Assertions

This section contains the test assertions for drivers.

Information File Syntax Checker Assertions

[CLARIFIED v.0.7] The following general Information File Syntax Checker assertions are tested in TD-22.1 ChkINF Test.

22.1.1001 This is not a valid driver INF.

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Design Guide, Chapter 3 "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 2000 DDK, "Creating Windows 2000 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. (I.e. CopyFiles=Foo, but no [Foo] present)

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Summary of INF Sections

Test Description: TD-22.1 CheckINF Test

22.1.1004 Provider listed is Microsoft, but 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 2000 DDK, "Creating Windows 2000 INF Files"

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 and later versions. For Windows 2000 and later versions, use the Include and Needs directives

Reference Document: WLP# - B1.4.2; Windows DDK Help Documentation; Supporting Common Device Types, Streaming Device, Design Guide, Part 3: "Audio Drivers, Audio Miniport Drivers", Installing a Port Class Audio Adapter, Installing Core System Components for an Audio Adapter, Installing on Windows 98 and Later Versions; WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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; Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives, INF Version Section; WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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"." %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 2000 DDK, "Creating Windows 2000 INF Files"

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 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.1013 Must only be one token on the left of = sign

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

Test Description: TD-22.1 CheckINF Test

22.1.1028 All quoted lines must be closed.

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives, INF Strings Section

Test Description: TD-22.1 CheckINF Test

22.1.1029 Inf must not copy another inf to \inf or subdir

The system will automatically copy the inf file, it should not be listed in a copyfiles section.

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives, INF CopyFiles Directive

Test Description: TD-22.1 ChkINF Test

22.1.1030 Inf files must not copy .cat files

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows 2000 DDK, "Creating Windows 2000 INF Files"

Test Description: TD-22.1 ChkINF Test

22.1.1031 Inf must not delete files of type inf.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows 2000 DDK, "Creating Windows 2000 INF Files"

Test Description: TD-22.1 ChkINF Test

22.1.1032 Inf files must nor rename files to *.inf or *.cat

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows 2000 DDK, "Creating Windows 2000 INF Files"

Test Description: TD-22.1 ChkINF Test

22.1.1034 Catalog files should not be listed in SourceDiskFiles.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows 2000 DDK, "Creating Windows 2000 INF Files"

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 for non-FSFilter INFs. The new FSFilter INF definition uses [DefaultInstall] sections instead of [Manufacturers] & [%Model%].

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives, 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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

Test Description: TD-22.1 ChkINF Test

22.1.1043 DirID value is missing.

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives, INF DestinationDirs Section; WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows 2000 DDK, "Creating Windows 2000 INF Files"

Test Description: TD-22.1 ChkINF Test

22.1.1044 Wrong value for DirID.

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives, INF DestinationDirs Section; WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows 2000 DDK, "Creating Windows 2000 INF Files"

Test Description: TD-22.1 ChkINF Test

22.1.1048 Strings section must have unique keys

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives, INF Strings Section; WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

Test Description: TD-22.1 ChkINF Test

22.1.1053 Must contain a CLASS directive.

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives, INF Version Section; WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows 2000 DDK, "Creating Windows 2000 INF Files"

Test Description: TD-22.1 ChkINF Test

22.1.1054 Must contain a CLASSGUID directive.

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives, INF Version Section; WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows 2000 DDK, "Creating Windows 2000 INF Files"

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: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives, INF Version Section; WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows 2000 DDK, "Creating Windows 2000 INF Files"

Test Description: TD-22.1 ChkINF Test

22.1.1058 Sections must have certain directives…

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives; WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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: DDK Directive section

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives, INF Version Section; WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

Test Description: TD-22.1 ChkINF Test

22.1.1069 DriverVer must be in mm/dd/yyyy format

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives, INF Version Section; WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

Test Description: TD-22.1 ChkINF Test

22.1.1081 Catalogfile or Catalogfile.NT must be present in Version section and popluated

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

Test Description: TD-22.1 ChkINF Test

22.1.1086 "Bad value for %s in %s.".

Bad value for Day in DriverVer

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives, INF Version Section; WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

Test Description: TD-22.1 ChkINF Test

22.1.1089 A disabled service canot be installed (StartType=0x4)

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

Test Description: TD-22.1 ChkINF Test

22.1.1098 Required directive can not be set to a NULL value.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

Test Description: TD-22.1 ChkINF Test

22.1.1100 Priority value for configpriorities 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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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: DDK DDInstall.HW & ClassInstall32 sections; WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

Test Description: TD-22.1 ChkINF Test

22.1.1198 NFs 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 2000 DDK, "Creating Windows 2000 INF Files"

Test Description: TD-22.1 ChkINF Test

22.1.1199 Illegal in Microsoft internal INFs.

This error occurs when ChkINF is run with the undocumented /MS flag, /MS changes certain default behaviors and makes ChkINF assume the INF being parsed is an in-the-box Microsoft INF instead of a third party, separate disk INF.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

Test Description: TD-22.1 ChkINF Test


Devctl Test Assertions

Assertions in this section are tested in TD-22.2 Devctl 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 Devctl 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 Devctl Test

22.2.3 Driver must be able to handle IOCTL/FSCTL functions with missing buffers or buffers that are two small or contain garbage.

Reference document: Windows Logo Requirements Document, B1.4, B1.5
Test description: TD-22.2 Devctl 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 Devctl 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 Devctl 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 Devctl 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 Devctl 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 Devctl 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 Devctl 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 Devctl 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 Devctl 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 Devctl 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 are tested in TD-22.6 PMTE Test Description.

22.6.1 [New - v.0.5] 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-22.6 PMTE Test Description

22.6.2 [New - v.0.5] 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-22.6 PMTE Test Description

22.6.3 [New - v.0.5] 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-22.6 PMTE Test Description

22.6.4 [New - v.0.5] The devices must still work after each S state transition.

Reference document: Windows Logo Requirements Document, B1.4.5
Test description: TD-22.6 PMTE Test Description

22.6.5 [New - v.0.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-22.6 PMTE Test Description


Plug and Play Driver Test Assertions

Assertions in this section are tested in TD-22.8 Plug and Play Driver Test.

22.8.1 [New - v.0.5] 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 [New - v.0.5] 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 [New - v.0.5] 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 [New - v.0.5] 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 [New - v.0.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 [New - v.0.5] 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 [New - v.0.5] 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 [New - v.0.5] 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 [New - v.0.5] 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


Information Catalog Syntax Checker Assertions

Assertions in this section are tested in TD-22.9 Information Catalog Syntax Checker Test Description.

22.9.1 [CLARIFIED v.0.7] 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 2000 DDK, "Creating Windows 2000 INF Files"
Test description: TD-22.9 Information Catalog Syntax Checker Test Description

22.9.2 [CLARIFIED v.0.7] 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 2000 DDK, "Creating Windows 2000 INF Files"
Test description: TD-22.9 Information Catalog Syntax Checker Test Description

22.9.3 HWID's must be formatted correctly.

Acceptable formats for hardware identifiers are bus specific.

Reference document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows 2000 DDK, "Creating Windows 2000 INF Files"
Test description: TD-22.9 Information Catalog Syntax Checker Test Description

22.9.4 Must be a Catalogfile= line, Catalogfile.NT or Catalogfile.NTx86 or Catalogfile.NTia64 ok for 2K only infs

Reference document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows 2000 DDK, "Creating Windows 2000 INF Files"
Test description: TD-22.9 Information Catalog Syntax Checker Test Description

22.9.5 [CLARIFIED v.0.7] 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 2000 DDK, "Creating Windows 2000 INF Files"
Test description: TD-22.9 Information Catalog Syntax Checker Test Description

22.9.6 DriverVer must be present and must be in mm/dd/yyyy[,w.x.y.z] format

Reference document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows 2000 DDK, "Creating Windows 2000 INF Files"
Test description: TD-22.9 Information Catalog Syntax Checker Test Description

22.9.7 [CLARIFIED v.0.7] DriverVer must be greater than or equal to current date or greater than OS ship date, whichever is greater.

Reference document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows 2000 DDK, "Creating Windows 2000 INF Files"
Test description: TD-22.9 Information Catalog Syntax Checker Test Description

22.9.8 Driver must not redist Microsoft originated files (uses wfp.mdb)

wfp.mdb is a database containing a list of files for each operating system that are protected and cannot be redistributed by 3rd parties. Query this for each file and make sure vendors are not redistributing it.

Reference document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows 2000 DDK, "Creating Windows 2000 INF Files"
Test description: TD-22.9 Information Catalog Syntax Checker Test Description

22.9.9 Driver must not redist .vxd files for modem and media classes (WDM required)

Reference document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows 2000 DDK, "Creating Windows 2000 INF Files"
Test description: TD-22.9 Information Catalog Syntax Checker Test Description

22.9.10 [CLARIFIED v.0.7] All entries in copyfiles sections must have a corresponding entry in sourcedisksfiles.

Reference document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows 2000 DDK, "Creating Windows 2000 INF Files"
Test description: TD-22.9 Information Catalog Syntax Checker 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 sourcedisks names.

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 2000 DDK, "Creating Windows 2000 INF Files"
Test description: TD-22.9 Information Catalog Syntax Checker Test Description

22.9.12 Infs must not copy .cat files.

Reference document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows 2000 DDK, "Creating Windows 2000 INF Files"
Test description: TD-22.9 Information Catalog Syntax Checker 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 2000 DDK, "Creating Windows 2000 INF Files"
Test description: TD-22.9 Information Catalog Syntax Checker Test Description


Short Driver Verifier Test Assertions

[New v.0.7] The following short driver verifier test assertions are tested in the shrtver test.

22.10.1 TBD.

Reference Document: Windows Logo Requirements Document, B1.5, B7.1.3

Test Description: TD-22.10 Short driver verifier test description


Information File Syntax Checker (CLASS=DISPLAY) Assertions

[New v.0.7]

The following display device class specific Information File Syntax Checker 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 2000 DDK, "Creating Windows 2000 INF Files"
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 2000 DDK, "Creating Windows 2000 INF Files"
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 2000 DDK, "Creating Windows 2000 INF Files"
Test Description: TD-22.1 ChkINF Test


Information File Syntax Checker (CLASS=IMAGE) Assertions

[New v.0.7]

The following IMAGE device class specific Information File Syntax Checker 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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

Test Description: TD-22.1 ChkINF Test


Information file syntax checker (CLASS=INFRARED) assertions

[This section is New for v.0.7]

The following IrDA device class specific Information File Syntax Checker 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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

Test Description: TD-22.1 ChkINF Test


Information file syntax checker (CLASS=KEYBOARD) assertions

[This section is New for v.0.7]

The following KEYBOARD device class specific Information File Syntax Checker 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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

Test Description: TD-22.1 ChkINF Test


Information file syntax checker (CLASS=MEDIA) assertions

[This section is New for v.0.7]

The following MEDIA device class specific Information File Syntax Checker 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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

Test Description: TD-22.1 ChkINF Test


Information file syntax checker (CLASS=MODEM) assertions

[This section is New for v.0.7]

The following MODEM device class specific Information File Syntax Checker 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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

Test Description: TD-22.1 ChkINF Test

22.16.3200 PortDriver entry should be wdmmdmld.vxd for driverbased modems and serial.vxd for controllered modems.

Reference Document: WLP# - B1.4.2; PC 2001 - SYS-0025.5; Windows 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

Test Description: TD-22.1 ChkINF Test


Information file syntax checker (CLASS=MONITOR) assertions

[This section is New for v.0.7]

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

Test Description: TD-22.1 ChkINF Test


Information file syntax checker (CLASS=MOUSE) assertions

[This section is New for v.0.7]

The following MOUSE device class specific Information File Syntax Checker 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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

Test Description: TD-22.1 ChkINF Test


Information file syntax checker (CLASS=NET) assertions

[This section is New for v.0.7]

The following Network Adapter device class specific Information File Syntax Checker 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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

Test Description: TD-22.1 ChkINF Test


Information file syntax checker (CLASS= NETCLIENT) assertions

[This section is New for v.0.7]

The following Network Clients device class specific Information File Syntax Checker 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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

Test Description: TD-22.1 ChkINF Test


Information file syntax checker (CLASS= SERVICE) assertions

[This section is New for v.0.7]

The following Network Service device class specific Information File Syntax Checker 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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

Test Description: TD-22.1 ChkINF Test


Information file syntax checker (CLASS= NETTRANS) assertions

[This section is New for v.0.7]

The following Network Transport device class specific Information File Syntax Checker 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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

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 2000 DDK, "Creating Windows 2000 INF Files"

Test Description: TD-22.1 ChkINF Test


Driver Quality Test Descriptions

This section describes the tests provided.

TD-22.1ChkINF Test

This program is an INF File Syntax Checker. An INF file or Information file is a file created for a particular adapter that provides the operating system with information required to set up a device, such as a list of valid logical configurations for the device, the names of driver files associated with the device, and so on. An INF file is typically provided by the device manufacturer on a disk with an adapter.

Click to show or hide information. Overview

ChkINF is a Perl script that checks the structure and syntax of Microsoft Windows 2000and Windows Whistler device driver .inf files. Results are presented in HTML format, and include a list of the errors and warnings detected in each .inf file, with each error and warning shown next to the errant .inf file entry. Please note the Limitations section below. Note that ChkINF does not support Windows 98 or Windows Millennium .inf files.

The tool includes support for all .inf sections and directives that apply to all classes of devices. ChkINF includes specific device class support for the following device classes:

1394 Host Bus Controllers (class = 1394)
Battery Devices (class = Battery)
CD-ROM Drivers (class = CDROM)
Disk Drives (class = DiskDrive)
Display Adapters (class = Display)
Dot4 Devices (class = Dot4)
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)
SCSI and RAID Controllers (class = SCSIAdapter)
Smart Card Readers (class = SmartCardReader)
Storage Volumes (class = Volume)
System Devices (class = System)
Tape Drives (class = TapeDrive)
USB (class = USB)

ChkINF does not check device specific INF extension for the following device classes:

Printers (class = Printer)

The tool has not been extensively tested. Review your results carefully.

Click to show or hide information. Running the Tool

Note: Because ChkINF is a Perl script, in order to use the tool you will need to obtain a Perl interpreter. ChkINF requires a Perl interpreter that is Version 5.003_07 or greater. ChkINF should work with any version of Perl 5.0 or greater, but has not been tested with any versions previous to 5.003_07.

ChkINF has been tested with the following Perl interpreters:

GNU Perl 5.005_02 compiled for Win32
Perl for Win32 5.003_07 from ActiveWare Internet Corp.

Microsoft neither endorses nor recommends any specific Perl interpreters.

ChkINF is located in the <DDKRoot>\Tools\Chkinf subdirectory, and should be executed from the Command Prompt.

A batch file, ChkINF.bat, is provided for smooth execution. ChkINF takes the following arguments:

Usage: ChkInf[.bat] <FileList> /L <LogFile> [/B] [/DC <Options>]

<FileList> | FileName | Wildcard List | Directory Name
/L <LogFile> | Write an NT Log File Named <LogFile>
/B | Launch Default Browser and Display Results
/I <Dir> | Look for INCLUDEd infs in <Dir> instead of current directory
/LO | Verify files copied (CopyFiles) against Layout.inf
/DC <Options> | Use Device Class <Options> When Checking .infs
/DC FAX | Check any Fax keys present in Modem .inf files only only

Notes

  • "FileName" is the name of a single .inf file.
  • "Wildcard" List is a DOS wildcard (as in "net*.inf"). ChkINF automatically expands wildcards and checks all applicable .inf files.
  • ChkINF checks all .inf files located in the "DirectoryName" subdirectory.
  • /L creates an NT log file.
  • The only Device Class option currently supported by the /DC argument is the FAX option, as listed above.

Click to show or hide information. Output

ChkINF produces three types of files at the end of the checking process.

  • Summary.htm: A single HTML file that lists all of the one or more .inf files that were checked, along with the number of errors and warnings detected in each one. The name of each .inf file is linked to the respective .htm file described below.
  • NameofINFfile.htm: Results file produced for each checked .inf file.
  • An optional NT Log file may be created (see Running the Tool).

NameofINFfile.htm includes the following:

  • 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 (see below).
  • 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 (see below).
  • Sections included from other infs: A list of the sections included from other .inf files. Each section listed includes a link to its location in the Sections included from other infs section (see below). This item 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 section is omitted if the INF being checked did not include any sections from other INF files.

These files are saved into the subdirectory Htm, located off the directory from which ChkINF is invoked.

Click to show or hide information. Limitations

ChkINF does not support Windows 98 .inf files. ChkINF will not accurately check .inf structure and syntax that is specific to Windows 98 .inf files.

The tool does not perform device-class-specific testing for the following device classes:

Keyboards (class = Keyboard)

ChkINF 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.

ChkINF does not support Unicode. To run ChkINF on a Unicode .inf file, first save the file as an ASCII text file.

ChkINF must be executed on the target platform in order to accurately check sections included from other INF files via Include and Needs directives.

ChkINF warns for any sections that are not referenced by a directive elsewhere in the INF file. This is a change from previous versions of the tool, which reported errors for un-referenced sections.

ChkINF does not check for all relevant Registry keys set by an .inf file. An .inf file that passes with no errors may not function correctly.


TD-22.2 Devctl Test

This program is designed to crash drivers by calling them through various user mode I/O interfaces. It does not test the functionality but rather the dis-functionality of drivers. Drivers should be resilient to bad data from user mode in exactly the same way that kernel entry points have to be. If they are not resilient then they open up denial of service attacks and in some cases a mechanism to bypass system security.

This program attempts to locate drivers that don’t handle these calls gracefully:

  • Unexpected entry points into the driver. For example file system query functions 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 or buffers that are two small or contain garbage.
  • 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 users buffer mapping may change asynchronously. Pages become unreadable at arbitrary execution points.
  • Relative opens with strange file names, Opens to strange device objects like the direct device open or file system devices.
  • Issues requests both synchronously and asynchronously to the device.

Graceful behavior does not include any of the following:

  • The system crashes.
  • System memory pools are corrupted.
  • Memory is leaked.
  • IRPs are not completed correctly.

While the program runs it writes lines to the file crashn.log. After each line is written the file is flushed so that in the event of a crash the offending operation is easy to determine should the system be difficult to debug. The flush operation makes this operation expensive so in some places only one portion of a block of operations is logged. For example, only logs for IOCTL for a particular function value are logged rather than each IOCTL. When the program is restarted it takes the last line from crashn.log and places it in the file crash.log. This is assumed to be a failed operation. Operations within crash.log are not performed again by default.

After each operation is performed a check on consumed memory within the system is done. The pool tag database and lookaside information is queried. If this operation caused either one of these memory sources to be depleted the operation is repeated. Obviously this increase in memory consumption may have had nothing to do with the request that was just performed. Typically the second call won’t see an increase and the program continues. Real memory leaks show up as a vast number of repeated calls and the tag in question raised to the top of the poolmon display sorted by difference (d).

For calls that would typically be buffered I/O operations the program tracks the number of exceptions the operating system has dispatched. If the number of exceptions increases the operation is also repeated. Although buffered I/O operations may also reference the users address space, its rare and exception dispatching may signal an internal error that’s being handled by an exception handler masking a true parameter or handle validation problem. Devctl can run with the bottom hardware page mapped so that NULL pointer de-references don’t raise exceptions but return garbage. This gives another possible path to show up bad validation.

Candidates for pool leaks and exceptions are logged to a file (diags.txt) should the leak not crash the system or the many repeated calls are missed by the user.

The programs basic execution passes are:

  • Issue various opens. Synchronous, Asynchronous, Direct, Relative (with various filenames). These catch drivers that are unaware of the relative open semantics and the fact they have to do their own security checks and drivers that may have word integer overflow problems manipulating file names.
  • Issue queries for just about all possible items the driver might understand.
  • Issue miscellaneous functions with the file handle like flush, create section, read and write (for asynchronous handles only). Reads and writes for obscure file offsets are performed. These include append writes where the file offset is a 2^64-1 and reads and writes where the offset is an unsigned 63 bit quantity that wraps to a signed 64 bit value when the length is added on. These catch read and write paths that don’t know the full semantics of file offsets or have overflow problems in their validation.
  • Issue miscellaneous handle less functions such as NtDeletefile, NtQueryFullAttributesFile etc. These exercise some of the fast open paths used for network queries etc.
  • Issue an IOCTL and FSCTL pass with zero length input and output buffers. This pass detects the most common driver error of not checking buffer length properly.
  • Issue random IOCTL and FSCTL calls with random size buffers. For buffered I/O requests the buffers are valid but contain random data. For Direct I/O requests the buffers are valid, contain random data that changes asynchronously with this threads execution and are butted to the ends of H/W pages to make more likely references beyond buffer end will fail.
  • For type 3 buffers the pointers are random.

The basic syntax for the program is:

devctl [/i] [/l] [/il nn] [/iu mm] [devnam]

/ and + enable options
- disables options

/a | Do all devices in system. Don't prompt for yes/now etc
/al | Alert the main thread periodically
/c | Enable or disable skipping operations that aborted or crashed
/dl nn | Sets lower limit for device type portion of IOCTL and FSCTL code
/du nn | Sets upper limit for device type portion of IOCTL and FSCTL code
/e | Enable or disable zero length EA's, needed on checked builds
/f | Enable or disable all FSCTL paths
/fn | Enable or disable FSCTL paths with null buffers
/fr | Enable or disable FSCTL paths with random buffers
/fl nn | Sets lower limit for function portion of IOCTL and FSCTL code
/fu nn | Sets upper limit for function portion of IOCTL and FSCTL code
/h /? | Prints this message
/g c h | Grabs a handle from another process
/I | Enable or disable all IOCTL paths
/if | Enable or disable all FSCTL and IOCTL paths
/in | Enable or disable IOCTL paths with null buffers
/ir | Enable or disable IOCTL paths with random buffers
/l | Enable or disable logging and skipping failing functions
/m | Enable or disable the miscellaneous functions
/n | Map zero page so that NULL pointer de-references don't raise
/p | Enable or disable the checks on pool usage via tags and lookaside lists
/q | Enable or disable the normal handle query functions
/r | Enable or disable skipping operations already logged as done
/s | Enable or disable the sub or relative opens to obtain handles
/t nn | Set maximum number of IOCTL/FSCTL calls made with random buffers
/v | Enable or disable the printing of error status values for calls

Devnam is the device to open to issue requests. It must be in native object tree format like ’\device\null’. If this is omitted the program prompts for each device in turn. You can skip to a particular device by typing ‘/prefix’ where prefix is the first few characters of the device you want to match.

Click to show or hide information. Here is a typical run:

E:\neillc\devctl>obj\i386\devctl \device\null

Listen socket on port 1192 address 172.31.236.194

Trying to open device \device\null synchronous

Opened crashn.log for reading

Lookaside: PooL, size 128 up 2

Pool: Mdl , Paged up 0, NonPaged up 128

\device\null Open synchronous

Opened file \device\null with access 1f03ff

Pool: File, Paged up 0, NonPaged up 192

Pool: CcBc, Paged up 0, NonPaged up 160

\device\null NtQueryObject ObjectNameInformation

NtQueryObject failed c0000004

NtQueryObject failed c0000004

Lookaside: Pool, size 128 up 1

NtQueryObject failed c0000004

\device\null NtQueryInformationFile FileBasicInformation

\device\null NtQueryInformationFile FileStandardInformation

\device\null NtQueryInformationFile FileInternalInformation

…

…

E:\neillc\devctl>obj\i386\devctl

Listen socket on port 1194 address 172.31.236.194

Device 809A61A0 registered with WMI

Device 8098FC20 registered with WMI

Device 8098F660 registered with WMI

Device 80945B30 registered with WMI

Device 8093DB50 registered with WMI

Device 80948040 registered with WMI

Device 80954040 registered with WMI

Device 80954A80 registered with WMI

Device 80947040 registered with WMI

Device 80947A20 registered with WMI

Device 80946040 registered with WMI

Device 80946A20 registered with WMI

Device 80943A60 registered with WMI

Device 80945040 registered with WMI

Device 80945CF0 registered with WMI

Device 8093DCF0 registered with WMI

Open device Cdfs? /null

Matching "null" against "Cdfs"

Matching "null" against "000126"

Matching "null" against "ASYNCMAC"

Matching "null" against "Afd"

Matching "null" against "Beep"

Matching "null" against "CdRom0"

Matching "null" against "DmLoader"

Matching "null" against "Floppy0"

Matching "null" against "FloppyPDO0"

Matching "null" against "FsWrap"

Matching "null" against "FtControl"

Matching "null" against "Gpc"

Matching "null" against "Hal Pci 0"

Matching "null" against "IdeDeviceP0T0L0"

Matching "null" against "IdeDeviceP1T1L0"

Matching "null" against "IdeFdo809a1288Channel0"

Matching "null" against "IdeFdo809a1288Channel1"

Matching "null" against "IdePort0"

Matching "null" against "IdePort1"

Matching "null" against "Ip"

Matching "null" against "KeyboardClass0"

Matching "null" against "KsecDD"

Matching "null" against "LanmanDatagramReceiver"

Matching "null" against "LanmanRedirector"

Matching "null" against "LanmanServer"

Matching "null" against "Mailslot"

Matching "null" against "MountPointManager"

Matching "null" against "Mup"

Matching "null" against "NTPNP_PCI0000"

Matching "null" against "NamedPipe"

Matching "null" against "Ndis"

Matching "null" against "Null"

Open device Null? y

Trying to open device Null synchronous

Opened crashn.log for reading

Lookaside: Pool, size 32 up 4

Pool: AfdC, Paged up 0, NonPaged up 192

\Device\Null Open synchronous

Opened file Null with access 1f03ff

Pool: File, Paged up 0, NonPaged up 192

\Device\Null NtQueryObject ObjectNameInformation

NtQueryObject failed c0000004

NtQueryObject failed c0000004

Lookaside: Pool, size 128 up 1

Lookaside: Pool, size 192 up 1

NtQueryObject failed c0000004

\Device\Null NtQueryInformationFile FileBasicInformation

\Device\Null NtQueryInformationFile FileStandardInformation

\Device\Null NtQueryInformationFile FileInternalInformation

\Device\Null NtQueryInformationFile FileEaInformation

\Device\Null NtQueryInformationFile FileAccessInformation

\Device\Null NtQueryInformationFile FileNameInformation

\Device\Null NtQueryInformationFile FileModeInformation

\Device\Null NtQueryInformationFile FileAlignmentInformation

Lookaside: PooL, size 128 up 1

Pool: Sect, Paged up 128, NonPaged up 0

Pool: CcSc, Paged up 0, NonPaged up 320

\Device\Null NtQueryInformationFile FileAllInformation

\Device\Null NtQueryInformationFile FileStreamInformation

Pool: VadS, Paged up 0, NonPaged up 32

\Device\Null NtQueryInformationFile FilePipeInformation

\Device\Null NtQueryInformationFile FilePipeLocalInformation

\Device\Null NtQueryInformationFile FilePipeRemoteInformation

^C

E:\neillc\devctl>

Here is an example leak:

C:\>g:\nt\nttest\security\tiger\devctl\obj\i386\devctl -if

…

Open device \Device\000167? /dfs

…

Open device \Dfs? y

…

\Dfs Open synchronous

Opened file Dfs with access 1f03ff

…

\Dfs NtQueryVolumeInformationFile FileFsVolumeInformation

Pool: Mup , Paged up 0, NonPaged up 131136

Lookaside: Scs$, size 64 up 2

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Hal , Paged up 0, NonPaged up 288

Pool: Irp , Paged up 0, NonPaged up 384

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Lookaside: Ntfi, size 264 up 1

Pool: Mup , Paged up 0, NonPaged up 130944

Lookaside: Ntfi, size 264 up 2

Lookaside: Scs$, size 64 up 1

Pool: Mup , Paged up 0, NonPaged up 131008

Pool: Mup , Paged up 0, NonPaged up 129536

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131008

Lookaside: Ntfi, size 264 up 1

Lookaside: Scs$, size 64 up 1

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 130752

Pool: Mup , Paged up 0, NonPaged up 130944

Pool: Mup , Paged up 0, NonPaged up 131008

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Lookaside: PooL, size 256 up 1

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Lookaside: Scs$, size 64 up 2

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Hal , Paged up 0, NonPaged up 288

Pool: Irp , Paged up 0, NonPaged up 768

^C

Memory: 65080K Avail: 3424K PageFlts: 0 InRam Krnl: 4632K P: 1916K

Commit: 52972K Limit: 666632K Peak: 108844K Pool N: 6312K P:10324K

Tag Type Allocs Frees Diff Bytes Per Alloc

Mup Nonp 84551 ( 0) 9870 ( 0) 74681 4779584 ( 0) 64

SYSA Paged 2227 ( 0) 750 ( 0) 1477 67136 ( 0) 45

CM Paged 6542 ( 0) 5854 ( 0) 688 8877504 ( 0) 12903

Vad Nonp 1460 ( 0) 1000 ( 0) 460 29440 ( 0) 64

File Nonp 3434 ( 0) 3137 ( 0) 297 57024 ( 0) 192

C:\>type diags.txt

\Dfs NtQueryVolumeInformationFile FileFsAttributeInformation Pool: Mup , Paged

up 0, NonPaged up 65600

The IOCTL and FSCTL passes take a long time as the space is huge. You can get must quicker coverage if you know the range of IOCTLs the driver accepts. Here is the procedure with IPNAT:

//

// NAT-supported IOCTL constant declarations

//

#define IOCTL_IP_NAT_SET_GLOBAL_INFO \

_IP_NAT_CTL_CODE(0, METHOD_BUFFERED, FILE_WRITE_ACCESS)

#define IOCTL_IP_NAT_CREATE_INTERFACE \

_IP_NAT_CTL_CODE(2, METHOD_BUFFERED, FILE_WRITE_ACCESS)

…

…

#define IOCTL_IP_NAT_DELETE_REDIRECT \

_IP_NAT_CTL_CODE(13, METHOD_BUFFERED, FILE_WRITE_ACCESS)

The first number in this macro is the function number. You can limit devctl to just cover this range with a command like devctl +fl 0 +fu 13. This limits both the IOCTL and FSCTL zero length and random buffer calls. This will run quite quickly so its probably worth increasing the number of random buffers the program throws at the driver with say +t nnnn.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Devctl must be run with Driver verifier.

Results Interpretation

After IOCTL passes and as part of a ‘miscellaneous function calls pass’ devctl issues a cancel request to the driver. IRPs that were lost (never completed by calling IoCompleteRequest or passed to other drivers but finished with by the device) will cause the process to hang. Through some paths popups appear from the I/O manager warning that IRPs didn’t cancel within an allotted time. These lost IRPs are easily debugged by issuing ‘!process 0 0’ from the debugger. Select the devctl process via a ‘!process xxx’ where xxx is the CID (Client ID) . The IRP (possibly more that one) will show up queued to one of the devctls threads. Use ‘!IRP xxxx’ where xxx is the IRP address to work out what IRP was lost. Occasionally IOCTL or FSCTL requests will pass parameter validation by a driver and will pend for a synchronous request (say some kind of notify request to a driver). Hitting ^C will cause the program to terminate in this case but not for a lost IRP case.


TD-22.3 Driver Verifier

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.

When the driver is unloaded, Driver Verifier checks to see that the driver has properly cleaned up its queues, worker threads, and other such items.

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.

Click to show or hide information. Driver Verifier Options

In addition, 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, or frees memory pool without first removing timers, Driver Verifier will detect 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 active, 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 active, 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 active, 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 active, 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 active, 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 Whistler only) When this option is active, Driver Verifier monitors the driver's use of DMA routines. This detects improper use of DMA buffers, adapters, and map registers.

Click to show or hide information. Automatic Checks

Driver Verifier performs the following actions whenever it is verifying one or more drivers. Enabling or disabling any of Driver Verifier’s options does not affect these actions.

Verification of IRQL and Memory Routines. Driver Verifier monitors the selected driver for the following forbidden actions:

  • Raising IRQL by calling KeLowerIrql
  • Lowering IRQL by calling KeRaiseIrql
  • Requesting a size zero memory allocation
  • Allocating or freeing paged pool at an IRQL above APC_LEVEL
  • Allocating or freeing nonpaged pool at an IRQL above DISPATCH_LEVEL
  • Trying to free an address that was not returned from a previous allocation
  • Trying to free an address that was already freed
  • Acquiring or releasing a fast mutex at an IRQL above APC_LEVEL
  • Acquiring or releasing a spin lock at an IRQL other than DISPATCH_LEVEL
  • Double-releasing a spin lock.
  • Specifying an illegal or random (uninitialized) parameter to any one of several APIs.

If Driver Verifier is not active, these violations might not cause an immediate system crash in all cases. Driver Verifier monitors the driver's behavior and issues bug check 0xC4 if any of these violations occur.

Checking Freed Memory Pool for Timers. Driver Verifier examines all memory pool freed by the driver being verified. If any timers remain in this pool, bug check 0xC7 is issued. (Forgotten timers can eventually lead to system crashes that are notoriously difficult to account for.)

Checking on Driver Unload. After a driver that is being verified unloads, Driver Verifier performs several checks to make sure that the driver has cleaned up. In particular, Driver Verifier looks for:

  • Undeleted timers
  • Pending deferred procedure calls (DPCs)
  • Undeleted lookaside lists
  • Undeleted worker threads
  • Undeleted queues
  • Other similar resources

Problems such as these can potentially cause system bug checks to be issued a while after the driver unloads, and the cause of these bug checks can be hard to determine. When Driver Verifier is active, such violations will result in bug check 0xC7 being issued immediately after the driver is unloaded. See Bug Check 0xC7 for a list of the bug check parameters.

Graphics Drivers. These automatic checks are not performed when verifying a graphics driver.

Click to show or hide information. Special Memory Pool

Memory corruption is a common driver problem. Driver errors can result in crashes long after the errors are made. The most common of these errors is accessing memory that has already been freed, and allocating n bytes and then accessing n+1 bytes.

To detect memory corruption, Driver Verifier can allocate driver memory from a special pool and monitor that pool for incorrect access.

Two alignments of the special pool are available. The Verify End alignment is better at detecting access overruns, and the Verify Start alignment is better at detecting access underruns. (Note that the vast majority of memory corruptions are due to overruns, not underruns.)

When Special Memory Pool is active and Verify End has been selected, each memory allocation requested by the driver is placed on a separate page. The highest possible address that allows the allocation to fit on the page is returned, so that the memory is aligned with the end of the page. The previous portion of the page is written with special patterns. The previous page and the next page are marked inaccessible.

If the driver attempts to access memory after the end of the allocation, Driver Verifier will detect this immediately, and will issue bug check 0xCD. If the driver writes in the memory prior to the beginning of the buffer, this will (presumably) alter the patterns. When the buffer is freed, Driver Verifier will detect the alteration and issue bug check 0xC1.

If the driver reads or writes to the buffer after freeing it, Driver Verifier will issue bug check 0xCC.

When Verify Start is selected, the memory buffer is aligned with the beginning of the page. With this setting, underruns cause an immediate bug check and overruns cause a bug check when the memory is freed. This option is otherwise identical to the Verify End option.

Verify End is the default alignment, as overrun errors are much more common in drivers than underrun errors. To alter this setting, use the Global Flags Utility.

An individual memory allocation can override these settings and choose its alignment by calling ExAllocatePoolWithTagPriority with the Priority parameter set to XxxSpecialPoolOverrun or XxxSpecialPoolUnderrun. (This routine cannot activate or deactivate the special pool, or request the special pool for a memory allocation, which would otherwise be allocated from normal pool. Only the alignment can be controlled from this routine.)

Monitoring the Special Pool. The Global Counters screen of Driver Verifier Manager can be used to monitor special pool use.

If the Allocations Succeeded: Special Pool counter is equal to the Allocations Succeeded counter, then the special pool has been sufficient to cover all memory allocations. If Allocations Succeeded: Special Pool counter is less than Allocations Succeeded counter, then the special pool has been exhausted at least once.

These counters do not track allocations whose size is one page or larger, since the special pool is not applicable to them.

The kernel debugger extension !verifier can also be used to monitor special pool use. It presents similar information to that of Driver Verifier Manager. For information about debugger extensions, see the documentation in the Debugging Tools for Windows package.

Activating This Option. The Special Memory Pool option can be activated for one or more drivers by using the Driver Verifier Manager graphical interface or the verifier.exe command-line. It can be activated for tagged memory pools by using the Global Flags Utility.

The Verify Start and Verify End alignments can be set with the Global Flags Utility, regardless of whether the special pool is being used for drivers or for pool tags.

Graphics Drivers. When the Special Memory Pool option is active, Driver Verifier allocates most of the driver's memory requests from a special pool. This special pool is monitored for memory overruns, memory under-runs, and memory that is accessed after it is freed.

Click to show or hide information. Forcing IRQL Checking

Although kernel-mode drivers are forbidden to access pageable memory at a high IRQL or while holding a spin lock, such an action might not be noticed if the page has not actually been trimmed.

When Forcing IRQL Checking is enabled, Driver Verifier will provide extreme memory pressure on the selected driver. Whenever a driver being verified requests a spin lock, calls KeSynchronizeExecution, or raises the IRQL to DISPATCH_LEVEL or higher, all of the driver's pageable code and data (as well as system pageable pool, code, and data) are marked as trimmed. If the driver attempts to access any of this memory, Driver Verifier issues a bug check.

This memory pressure will not directly affect drivers that are not selected for verification, since other drivers' IRQL raises will not cause this action. However, when a driver that is being verified raises the IRQL, Driver Verifier trims pages that can be used by drivers that are not being verified. Thus errors by drivers that are not being verified might occasionally be caught when this option is active.

Monitoring IRQL Raises and Spin Locks. The Global Counters screen of Driver Verifier Manager can be used to monitor IRQL raises, spin locks, and calls to KeSynchronizeExecution made by drivers being verified. It also includes a count of all pageable memory trims forced by Driver Verifier.

The kernel debugger extension !verifier can also be used to monitor these statistics. It presents similar information to that of Driver Verifier Manager. In addition, in Windows Whistler, the !verifier 0x8 extension will display a log of recent IRQL changes made by drivers being verified. For information about debugger extensions, see the documentation in the Debugging Tools for Windows package.

Activating This Option. The Forcing IRQL Checking option can be activated by using the Driver Verifier Manager graphical interface or the verifier.exe command-line.

Click to show or hide information. Low Resources Simulation

When Low Resources Simulation is enabled, Driver Verifier will cause a random selection of the driver's memory allocations to fail. This tests the driver's ability to react properly to low-memory and other low-resource conditions.

To accurately simulate a low-memory condition, these allocation faults are not injected until seven minutes after system startup. Therefore, any driver errors that are exposed by this action should be treated as legitimate run-time problems, not as unrealistic scenarios.

Allocation requests marked MUST_SUCCEED are not subject to this action. A maximum of one page of MUST_SUCCEED pool is permitted.

Driver Verifier can verify selected drivers or all drivers at the same time.

Monitoring the Low Resources Simulation. The Global Counters screen of Driver Verifier Manager can be used to monitor the number of times Driver Verifier deliberately fails resource allocations.

The kernel debugger extension !verifier can also be used to monitor this statistic. It presents similar information to that of Driver Verifier Manager. In addition, in Windows Whistler, the !verifier 0x4 extension will display a log of faults injected by Driver Verifier.

For information about debugger extensions, see the documentation in the Debugging Tools for Windows package.

Activating This Option. The Low Resources Simulation option can be activated by using the Driver Verifier Manager graphical interface or the verifier.exe command-line.

Graphics Drivers. When the Low Resources Simulation option is active, Driver Verifier randomly fails memory 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.

Click to show or hide information. Memory Pool Tracking

Memory Pool Tracking monitors the memory allocations made by the driver. At the time that the driver is unloaded, Driver Verifier ensures that all allocations made by the driver have been freed.

Unfreed memory allocations (also called memory leaks) are a common cause of lowered operating system performance. These can fragment the system pools and eventually cause system crashes.

When this option is active, Driver Verifier will issue bug check 0xC4 (with Parameter 1 equal to 0x60) if a driver unloads without freeing all its allocations.

If Driver Verifier issues this bug check with Parameter 1 equal to 0x51, 0x52, 0x53, 0x54, or 0x59, the driver has written to memory outside of its allocations. In this case, you should enable Special Memory Pool to locate the source of the error.

See Bug Check 0xC4 for a list of the bug check parameters.

Monitoring Memory Pool Tracking. The Pool Tracking screen of Driver Verifier Manager can be used to monitor paged and non-paged pool allocations.

The kernel debugger extension !verifier 0x3 can be used to locate outstanding memory allocations after the driver is unloaded, or to track the current allocations while the driver is running. This extension also shows the pool tag, the size of the pool, and the address of the allocator for each allocation. For information about debugger extensions, see the documentation in the Debugging Tools for Windows package.

Activating This Option. The Memory Pool Tracking option can be activated by using the Driver Verifier Manager graphical interface or the verifier.exe command-line.

Click to show or hide information. I/O Verification

Driver Verifier has two versions of the I/O Verification option. The Level 1 I/O Verification allocates the driver's IRPs from a special pool and monitors the driver's I/O handling for various improper actions. Level 2 I/O Verification performs all the Level 1 actions, as well as a number of more detailed and extensive checks on the driver's I/O use.

Level 2 I/O Verification is a much stronger way to test a driver's I/O use. However, this heightened level of scrutiny uses more memory thereby possibly reducing the performance level of the operating system.

Level 1 I/O Verification. When Level 1 I/O Verification is enabled, all IRPs obtained through IoAllocateIrp are allocated from a special pool and their use is tracked.

Additionally, Driver Verifier checks for invalid I/O calls, including:

  • Attempts to free an IRP whose type is not IO_TYPE_IRP
  • Passes of invalid device objects to IoCallDriver
  • Passes of an IRP to IoCompleteRequest that contains invalid status or that still has a cancel routine set
  • Changes to the IRQL across a call to the driver dispatch routine
  • Attempts to free an IRP that remains associated with a thread
  • Passes of a device object to IoInitializeTimer that already contains an initialized timer
  • Passes of an invalid buffer to IoBuildAsynchronousFsdRequest or IoBuildDeviceIoControlRequest
  • Passes of an I/O status block to an IRP, when this I/O status block is allocated on a stack that has unwound too far
  • Passes of an event object to an IRP, when this event object is allocated on a stack that has unwound too far

Because the special IRP pool is of limited size, I/O Verification is most effective when it is only used on one driver at a time.

I/O Verification Level 1 failures cause bug check 0xC9 to be issued. The first parameter of this bug check indicates what violation has occurred. See bug check 0xC9 for a full parameter listing.

Level 2 I/O Verification: I/O Verification Level 2 errors are displayed in different ways: on the blue screen, in a crash dump file, and in a kernel debugger.

On the blue screen, these errors are noted by the message IO SYSTEM VERIFICATION ERROR and the string WDM DRIVER ERROR XXX, where XXX is an I/O error code.

In a crash dump file, these errors are noted by the message BugCheck 0xC9 (DRIVER_VERIFIER_IOMANAGER_VIOLATION), along with the I/O error code. In this case, the I/O error code appears as the first parameter of the bug check 0xC9.

In a kernel debugger (KD or WinDbg), these errors are noted by the message WDM DRIVER ERROR and a descriptive text string. When the kernel debugger is active, it is possible to ignore the Level 2 errors and resume system operation. (This is not possible with any other bug checks.)

The blue screen, the crash dump file, and the kernel debugger each display additional information as well. For a full description of all I/O Verification Level 2 error messages, see Bug Check 0xC9.

Activating This Option. The I/O Verification option can be activated, and its level can be specified, by using the Driver Verifier Manager graphical interface or the verifier.exe command-line.

Click to show or hide information. DMA Verification

DMA Verification monitors the use of Direct Memory Access (DMA). Since the DMA routines have changed as Windows has developed, many drivers make incorrect use of DMA calls. Moreover, some driver writers attempt to bypass the HAL DMA subsystem altogether. This practice can introduce insidious bugs into the driver.

The DMA Verification option of Driver Verifier attempts to catch common DMA errors. Along with the !dma kernel debugger extension, it can be used to verify that a driver is using DMA in a proper manner.

This Driver Verifier option is only available in Windows Whistler and later versions.

When DMA Verification is active, the following common misuses of the DMA routines are detected:

  • Overrunning the DMA memory buffer (these overruns can be made by the hardware or the driver)
  • Attempting to use an adapter that was already freed and no longer exists
  • Double-freeing a common buffer, adapter channel, map register, or scatter-gather list
  • Leaking memory by not freeing common buffers, adapter channels, map registers, scatter-gather lists, or adapters
  • Having more than one adapter channel present for an adapter at one time
  • Allocating too many map registers
  • Not flushing adapter buffers
  • Double-mapping of map registers
  • Performing DMA on a pageable buffer (all buffers should be locked before DMA transfer begins)
  • Performing DMA on an MDL with mangled flags
  • Calling DMA routines at an improper IRQL

Driver Verifier monitors the driver's behavior and issues bug check 0xE6 if any of these violations occur.

Monitoring DMA Verification. The kernel debugger extension !dma can be used to display a wealth of DMA information. It can display various details about the behavior of each DMA adapter. For information about debugger extensions, see the documentation in the Debugging Tools for Windows package.

The DMA Verification option can be activated by using the verifier.exe command-line. It cannot be set with the Driver Verifier Manager graphical interface.

Different Types of DMA. DMA is a mechanism through which a hardware device can transfer data to or from memory without using the processor. The processor is required to set up the transfer, and the device will signal the processor when it has completed the transfer. The advantage of this system is that the processor can perform other tasks while the DMA transfer is being performed.

Types of DMA used in Windows 2000 and later versions:

Common-buffer DMA | Common-buffer DMA is performed when the system can allocate a single buffer that is accessible by both the hardware and the software. The driver is responsible for synchronizing accesses to the buffer. The memory is not cached, making this synchronization easier for the driver. After setting up a common buffer, both the driver and the hardware can write directly to the addresses in the buffer without any intervention from the HAL.
Packet DMA | Packet DMA is performed when there is a single existing buffer that must be mapped for use by the hardware. An example of using packet DMA is the transfer of a file from memory to a disk. Using common-buffer DMA in this situation would be wasteful, because the file would have to be transferred to the common buffer before the hardware could transfer it to the disk. Instead, the HAL is consulted; it gives the driver the information it needs to help the hardware find the actual buffer in memory. This operation is complicated by the need for the routines involved to work across different architectures.
Scatter-Gather DMA | Scatter-gather DMA is a shortcut method that sets up several packet DMA transfers at once. If you are transferring a packet over the network, for example, each part of the network stack adds its own header (TCP, IP, Ethernet, and so forth). These headers are all allocated from different places in memory. In this case, the scatter-gather DMA saves time by issuing a batch request to the HAL to map each header plus the data segment for access by the hardware. Instead of having to call the packet DMA routines on each part of the packet, this method calls each routine once, and lets the HAL be responsible for mapping each one individually. Note: Scatter-gather capability does not mean that the device can use the scatter-gather routines. Scatter-gather capability refers to a flag in the device description that indicates that the device is able to read or write from any area in memory, instead of just a certain range.
System DMA | System DMA is performed by programming the system DMA controller on the motherboard to do the transfer directly. Only ISA cards can use system DMA.

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.

The verifier.exe utility can be used to activate Driver Verifier from the MS-DOS Command Prompt window.

Command-Line 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 /?

Click to show or hide information. Parameters

/all

Causes Driver Verifier to verify all installed drivers after the next boot.

Options

Specifies the Driver Verifier options that will be active after the next boot. This number must be entered in decimal format. Any combination of the following values is allowed. (If Driver Verifier is being activated for the first time and the /flags parameter is omitted, the default is 11 = 1+2+8.)

Value | Action
1 (Bit 0) | Special Memory Pool
2 (Bit 1) | Forcing IRQL Checking
4 (Bit 2) | Low Resources Simulation
8 (Bit 3) | Memory Pool Tracking
16 (Bit 4) | I/O Verification (or DMA Verification 3/4 see the Level parameter)

Level

Specifies the level of I/O Verification or DMA Verification. This can be 1, 2, or 3. Entering "1" or "2" will activate Level 1 or Level 2 I/O Verification, respectively. Entering "3" will activate DMA Verification, as well as Level 2 I/O Verification.

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.

/reset

This clears all Driver Verifier settings. After the next boot, no drivers will be verified.

/query

Causes a summary of Driver Verifier's current data to be displayed on the screen. This data includes a count of memory allocations, IRQL raises, spin locks, and other data relevant to Driver Verifier's actions.

LogFileName

Creates a log file with name LogFileName. At regular intervals, a count of memory allocations, IRQL raises, spin locks, and other data relevant to Driver Verifier's actions will be written to this file. (If this command is launched from an MS-DOS Command Prompt Window, this command will not return a new prompt. To close the log file and return a prompt, use the CTRL+C key.)

Seconds

Specifies the interval between log file updates. The default is 30 seconds.

/volatile

Causes changes to be made to Driver Verifier's volatile settings. Volatile settings take effect immediately, rather than after a reboot. They last until the next boot, or until they are changed again by the Verifier Command Line or by the Driver Verifier Manager.

VolatileOptions

Specifies the Driver Verifier options that will be changed in a volatile manner. This number must be entered in decimal format. Only Special Memory Pool, Forcing IRQL Checking, and Low Resources Simulation can be set in a volatile manner. Any combination of the following values is allowed:

Value | Action
1 (Bit 0) | Special Memory Pool
2 (Bit 1) | Forcing IRQL Checking
4 (Bit 2) | Low Resources Simulation

VolatileDriverList

(Windows Whistler only) With the /adddriver keyword, this causes the specified drivers to be added to the volatile settings. With the /removedriver keyword, this 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. (Drivers can be added or removed only if they are not currently loaded. Moreover, drivers can be added only if there was at least one driver scheduled to be verified at the time of the most recent boot.)

/?

Causes command-line help information to be displayed.

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 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 | Attempt to free pool which was not allocated
Address that the driver tried to free | Bytes requested | Bytes calculated | 0x21, |
0x22 | Attempt to free a bad address |  |  |
Address that the driver tried to free | Address where bits are corrupted | Reserved | 0x23 | Freeing an address when nearby bytes on same page have been corrupted
Address that the driver tried to free | Address where bits are corrupted | Reserved | 0x24 | Freeing an address when bytes after end of allocation have been overwritten
Current IRQL | Pool type | Number of bytes | 0x30 | Attempt 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.

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
0x01, 0x02, or 0x04 | Pointer to pool header | First part of pool header contents | Zero | Pool header has been corrupted
0x06 | Reserved | Pointer to pool header | Pool header contents | Attempt to free pool which was already freed
0x07 | Reserved | Pointer to pool header | Zero | Attempt to free pool which was already freed
0x08 | Current IRQL | Pool type | Size of allocation | Attempt to allocate pool at an invalid IRQL
0x09 | Current IRQL | Pool type | Address of pool | Attempt to free pool at an invalid IRQL
0x40 | Starting address | Start of system address space | Zero | Attempt to free kernel pool at user-mode address
0x41 | Starting address | Physical page frame | Highest physical page frame | Attempt 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 | Attempt to free a nonallocated paged pool address
0x99 | Address being freed | zero | Zero | Attempt to free pool with invalid address (or corruption in pool header)

The _POOL_TYPE codes are enumerated in ntddk.h. In particular, zero indicates nonpaged pool and one indicates paged pool.

Resolving the Problem

Activate the Driver Verifier to obtain more information about these errors.


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 | Zero | Call to allocate zero bytes (minimum allocation one byte)
0x01 | Current IRQL | Pool type | Number of bytes | Attempt to allocate paged memory at an IRQL above APC_LEVEL
0x02 | Current IRQL | Pool type | Number of bytes | Attempt to allocate nonpaged memory at an IRQL above DISPATCH_LEVEL
0x03 | Current IRQL | Pool type | Number of bytes | Attempt to allocate too much of the MUST_SUCCEED pool (one page maximum)
0x10 | Bad Address | zero | Zero | Trying to free an address that was not returned from an allocate call
0x11 | Current IRQL | Pool type | Address of pool | Attempt to free paged pool at an IRQL above APC_LEVEL
0x12 | Current IRQL | Pool type | Address of pool | Attempt to free nonpaged pool at an IRQL above DISPATCH_LEVEL
0x13 or 0x14 | Reserved | Pointer to pool header | Pool header contents | Attempt to free memory pool which was already freed
0x15 | Timer entry | Pool type (-1 for Special Pool) | Pool address being freed | Attempt to free pool which contains an active timer
0x16 | Reserved | Pool address | Zero | Attempt to free pool at bad address, passing invalid parameters to memory routine
0x17 | Resource entry | Pool type (-1 for Special Pool) | Pool address being freed | Attempt to free pool which contains an active ERESOURCE
0x18 | Timer entry | -1 | DLL base address | Attempt to unload a driver whose DLL contains an active timer
0x19 | Resource entry | -1 | DLL base address | Attempt to unload a driver whose DLL contains an active ERESOURCE
0x30 | Current IRQL | Requested IRQL | Zero | Attempt to lower the IRQL in KeRaiseIrql (or supplying an uninitialized parameter as IRQL)
0x31 | Current IRQL | Requested IRQL | Zero | Attempt to raise the IRQL in KeLowerIrql (or supplying an uninitialized parameter as IRQL)
0x32 | Current IRQL | Spin lock address | Zero | Call to KeReleaseSpinLock at an IRQL other than DISPATCH_LEVEL (perhaps due to double-release of spin lock)
0x33 | Current IRQL | Fast mutex address | Zero | Attempt to acquire fast mutex at an IRQL above APC_LEVEL
0x34 | Current IRQL | Fast mutex address | Zero | Attempt to release fast mutex at an IRQL other than APC_LEVEL
0x35 | Current IRQL | Spin lock address | Old IRQL | Kernel is releasing a spin lock when not at DISPATCH_LEVEL
0x36 | Current IRQL | Spin lock number | Old IRQL | Kernel is releasing a queued spin lock when not at DISPATCH_LEVEL
0x37 | Current IRQL | Thread APC disable count | Resource | A resource is being acquired, but APCs are not disabled
0x38 | Current IRQL | Thread APC disable count | Resource | A resource is being released, but APCs are not disabled
0x39 | Current IRQL | Thread APC disable count | Mutex | A mutex is being acquired "unsafe", but IRQL is not APC_LEVEL on entry
0x3A | Current IRQL | Thread APC disable count | Mutex | A mutex is being released "unsafe", but IRQL is not APC_LEVEL on entry
0x40 | Current IRQL | Spin lock address | Zero | Call to KeAcquireSpinLockAtDpcLevel at an IRQL other than DISPATCH_LEVEL
0x41 | Current IRQL | Spin lock address | Zero | Call to KeReleaseSpinLockFromDpcLevel at an IRQL other than DISPATCH_LEVEL
0x42 | Current IRQL | Spin lock address | Zero | Call to KeAcquireSpinLock at an IRQL above DISPATCH_LEVEL
0x70 | Current IRQL | MDL address | Access mode | Call to MmProbeAndLockPages at an IRQL above DISPATCH_LEVEL
0x71 | Current IRQL | MDL address | Process address | Call to MmProbeAndLockProcessPages at an IRQL above DISPATCH_LEVEL
0x72 | Current IRQL | MDL address | Process address | Call to 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 | Call to MmMapIoSpace at an IRQL above DISPATCH_LEVEL
0x74 | Current IRQL | MDL address | Access mode | Call to MmMapLockedPages in kernel mode at an IRQL above DISPATCH_LEVEL
0x75 | Current IRQL | MDL address | Access mode | Call to MmMapLockedPages in user mode at an IRQL above APC_LEVEL
0x76 | Current IRQL | MDL address | Access mode | Call to MmMapLockedPagesSpecifyCache in kernel mode at an IRQL above DISPATCH_LEVEL
0x77 | Current IRQL | MDL address | Access mode | Call to MmMapLockedPagesSpecifyCache in user mode at an IRQL above APC_LEVEL
0x78 | Current IRQL | MDL address | Zero | Call to MmUnlockPages at an IRQL above DISPATCH_LEVEL
0x79 | Current IRQL | Virtual address being unmapped | MDL address | Call to MmUnmapLockedPages in kernel mode at an IRQL above DISPATCH_LEVEL
0x7A | Current IRQL | Virtual address being unmapped | MDL address | Call to MmUnmapLockedPages in user mode at an IRQL above APC_LEVEL
0x7B | Current IRQL | Virtual address being unmapped | Number of bytes | Call to MmUnmapIoSpace at an IRQL above APC_LEVEL
0x7C | MDL address | MDL flags | Zero | Call to MmUnlockPages passed an MDL whose pages were never successfully locked
0x7D | MDL address | MDL flags | Zero | Call to MmUnlockPages passed an MDL whose pages are from nonpaged pool (these should never be unlocked)
0x80 | Current IRQL | Event address | Zero | Call to KeSetEvent at an IRQL above DISPATCH_LEVEL

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.


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


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.


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 | zero | Zero | Attempt to free object whose type is not IO_TYPE_IRP
0x02 | Address of IRP being freed | zero | Zero | Attempt to free IRP still associated with a thread
0x03 | Address of IRP being sent | zero | Zero | Call to IoCallDriver with IRP Type not equal to IRP_TYPE
0x04 | Address of DeviceObject | zero | Zero | Invalid device object passed to IoCallDriver
0x05 | Address of DeviceObject associated with offending driver | IRQL before IoCallDriver | IRQL after IoCallDriver | IRQL not preserved across call to driver dispatch routine
0x06 | IRP status | Address of IRP being completed | Zero | IoCompleteRequest called with status marked as pending or equal to -1
0x07 | Address of cancel routine | Address of IRP being completed | Zero | IoCompleteRequest called with cancel routine still set
0x08 | Address of DeviceObject | IRP major function code | Exception code | Invalid buffer passed to IoBuildAsynchronousFsdRequest
0x09 | Address of DeviceObject | I/O control code | Exception code | Invalid buffer passed to IoBuildDeviceIoControlRequest
0x0A | Address of DeviceObject | zero | Zero | Device object with an already-initialized timer passed to IoInitializeTimer
0x0C | Address of IO status block | zero | Zero | I/O status block passed to IRP is allocated on stack which has already unwound past that point
0x0D | Address of user event object | zero | Zero | Event passed to IRP is allocated on stack which has already unwound past that point
0x0E | Current IRQL | Address of IRP | Zero | Call to IoCompleteRequest with IRQL above DPC

Parameters (I/O Verification Level 2)

When Driver Verifier is active and I/O Verification has been set to Level 2, all the bug check parameters listed in the Level 1 section above are possible. In addition, many more I/O violations will be detected.

The Level 2 error codes are displayed in different ways on the blue screen, in a crash dump file, and in a kernel debugger. Note that 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 name of the driver which caused the error, along with the address in the driver's code where the error was detected.
  • The message WDM DRIVER ERROR XXX, where XXX is a hexadecimal code representing the specific error. (See the following list of the I/O error codes and their meanings.)

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 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 that 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 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.

Note No other bug checks can be ignored in this manner. Only I/O Verification Level 2 errors which occur when a kernel debugger is present can be ignored.

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.


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 which 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 which 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.


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.


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


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.


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 which 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 which was earlier freed.

This cannot be protected by try - except; it can only be protected by a probe.


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.


TD-22.4 WHQLDbg

Overview

This is a monitoring test that monitors if a crash dump has occurred and gets the stack trace pertaining to the crash.

The purpose of WHQLdbg is too ensure robustness of the printer driver while running the WHQL certification tests. This tool will work on Windows 2000 and later operating system. At this time WHQLdbg.exe Version 0.5 is setup only to track kernel mode failures.

The main focus of the test is too ensure that when using the other WHQL tools, the printer driver or related systems do not cause the system to blue screen. 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.

In order to run this tool the debugger and kernel symbols must be on the systemin the dir where WHQLdbg is executed from. Also 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

TBD


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.

TBD

Results Interpretation

TBD


TD-22.6 PMTE Test Description

[New - v.0.5]

Overview

PMTE is a power management test. It tests devices in a system for functionality, and at the same time cycles the system and supports sleep states.

The devices tested:

DISKS
CD-ROMS
Serial ports
Modems
Sound output
IRDA
Parallel ports

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

A kernel debugger is needed because PMTE will break into the debugger when a test process is hanging. This way the issue can be debugged. Since PMTE cycles the system through the system states, the only way to know what was done last when the system hangs, is from what PMTE has logged to the debugger.

Required Hardware

None. Only the machine or specific hardware that is being certified is needed.

Required Software

Kernel Debugger

Results Interpretation

PMTE will log errors on a nonworking device before or after going to a sleep state. It will also log an error if the system fails to go into a sleep state, and others. The default log file name is pmte.log.

Click to show or hide information. Reading pmte.log

PMTE basically pauses and restarts all the device tests, and puts the system into different sleep states. It does these actions synchronously. In the log file any of these actions is preceded with a ===. If one of these major would fail it would contain a line like below.

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 PMTE reports..

Below 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 ,Seach for devnodes with problems

This log snippet indicates that PMTE

  1. Initialized all the tests,
  2. Check media for all devices
  3. Enable the hiberfile
  4. Restarted testing all device
  5. Waited for 30 seconds
  6. Pause testing of all devices
  7. Waited for 5 seconds
  8. Then enable RTC timer to wake in 4 minutes, and put the system to S1 sleep

Click to show or hide information. Detailed Description of Times in Pmte.log

When PMTE does a major action it logs a time with it. The times in pmte.log are in the below format. (D:25 H:18 M:26 S:44) These are absolute times.

    === TME_RESTART_TESTING all tests ===

This action is to start or restart testing devices. A list of device follows.

    === TME_PAUSE_TESTING all tests ===

This action is to pause testing of devices. A list of device follows. Depending on how PMTE was started, not all test will actual pause I/O on this. Device types that can support to do I/O with out getting errors to the device while we are going to suspend will usually not pause I/O. Disks and sound devices are an example of these devices. But comports and modems will pause I/O before we suspend.

    === S# , Wake method: # Set to wake in # Min. Latency ### Sec. Count # ===

    === S# , Wake method: # . Count # ===

This action states that we are 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:

  • "Manual" - The user needs to press the power button to wake the system.
  • "RTC" - System will wake automatically using the RTC timer.
  • "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 is the number that indicates how much later a system can actually wake then what Min reads till we will flag it 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

When an error is reported from testing a device, it is done when I pause or restart testing a device. Each error will consist of multiple lines and each line will be preceded with the word ERROR. See examples below.

=== 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 because one of the device tests are not responding usually means that there is some problem with the device this test is testing. Depending on how PMTE is started PMTE will do different things when a test is hanging. It any case it logs an error that the test timed out to ACK (acknowledge) the state change (see first red line below). After that line it list the test in question. Below is an example log snippet where the devnodes test is hanging.

=== 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. PMTE will also log the elapsed time. In the example below the system woke to soon, the system work in 1.46 minutes even so the RTC timer was programmed to wake the system in 4.

=== 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 to 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 example below. It shows that the system failed to go into S4 (hibernate). This error is also preceded with the word ERROR. The first line will read

"ERROR Work item completed with Error Code: #### "

Where #### is the error number the going to seep API returned. The next error line gives what this error 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)

* * *


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 not exposed to the driver writer under the driver model. This test parses the binary to obtain the imports 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.

TBD

Results Interpretation

TBD


TD-22.8 Plug and Play Driver Test

Overview

The purpose of the Plug and Play Driver test is to provide driver writers with a tool which 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 (i.e, stress). This is accomplished using a combination of user mode API calls (via the test app) and kernel mode API calls (via 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/reenumerate 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 reenumerate 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

Surprise removal is tested by selecting the target device and clicking "Test Surprise Removal". This encompasses IRP_MN_SURPRISE_REMOVAL followed by IRP_MN_REMOVE_DEVICE.

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 reenumerating 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 Information Catalog Syntax Checker Test Description

Overview

Describe test here ChkCatR

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

TBD

Results Interpretation

TBD


TD-22.10 Short Driver Verifier Test Description

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 drivers that are not signed by the Windows 2000 real or beta authority. 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. Ex:

[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 DV modes to be run and the tests to be run under each mode. Ex:

[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, and/or crashes. 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, then reboot in normal mode.


Chapter 23: Network Adapter Test Specification

Draft Version: 0.7 — Date: February 12, 2001

Introduction to Network Adapter Test

<add intro here>


Network Adapter Test Assertions

This section contains the test assertions for network adapters.

23.1.1 Assertion name

Reference Document: TBD
Test Description: "TD-23.1 Test Name"


Network Adapter Test Descriptions

This section describes the tests provided.

TD-23.1 Test Name

Describe test here

Setup

Results Interpretation

TD-23.2 Test Name

Describe test here

Setup

Results Interpretation


Chapter 24: Cluster Test Specification

Draft Version: 0.7 — Date: February 12, 2001

Overview

This document describes the test specification for Microsoft Cluster Service (MSCS) system validation, including the hardware and software requirements.

Test Configuration

Creating an MSCS cluster requires two PCI-based Intel Pentium or equivalent "x86" or "IA64" systems configured as described in the following list. For development purposes, any PCI-based system listed on the Windows 2000 HCL can be used as an MSCS cluster node.

  • 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 must be changed to another value (for example, 6) before they are both connected to the same bus.
  • The boot-time SCSI bus reset operation should also be disabled on each controller attached to a shared bus. This option can be disabled using the configuration utilities supplied by the manufacturer. Some SCSI cards may not support this feature though. It will make systems boot faster to disable it but will not prevent the tests from running.
  • At least two external SCSI disks attached to one of the shared buses. Each disk must be formatted for Windows NT file system (NTFS) only. A single partition is recommended on each disk because logical partitions cannot be independently failed over. The same drive letter should be permanently assigned to a given shared disk on each system.
  • At least one disk on each system is not attached to any of the shared buses.
  • Windows 2000 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 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 for the cluster and one is for each resource group that will be created. Clients to access cluster services will use these addresses. These addresses must be supplied to the MSCS setup and administration programs when resource groups are created.

Figure 1a illustrates a typical MSCS SCSI configuration. Figure 1b illustrates a typical MSCS Fibre Channel configuration.

Figure 1a Standard MSCS configuration using SCSI (or SSA) adapters

Figure 1a. Standard MSCS configuration using SCSI (or SSA) adapters

.

Figure 1b Standard MSCS Configuration using Fibre channel adapters

Figure 1b. Standard MSCS 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 optional test components for DHCP or WINS

On each Windows 2000 Advanced 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 may 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.

Click to show or hide information. Installing optional test components for FTP

The FTP service is not installed by default on Windows 2000. To install it on each Windows 2000 Advanced or Datacenter Server:

Go to Start -> Settings -> Control Panel from the task bar.

Double click Add/Remove Programs.

Click Add/Remove Windows Components button.

Under the Windows Components Wizard highlight the Internet Information Services (IIS) list item and click the Details button.

Select the list item check box for File Transfer Protocol (FTP) Server. Click OK. Follow the directions for the rest of the prompts.

Click to show or hide information. Installing optional test components for MSMQ

Prior to running the MSMQ HCT test, MSMQ must be manually installed and configured in the lab environment.

There are three types of installations to be completed:

  • The domain controller installation
  • The cluster installation
  • The client installation

Perform the installation in the order indicated in Specific installation details.


For all installations

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

  • To install MSMQ go to: Start -> Settings -> Control Panel. Double click Add/Remove Programs. Click the Add/Remove Windows Components button. Under the Windows Components Wizard click the Message Queuing Services check box. Click the Next button and proceed through the setup, accepting the default settings.
  • Do not select the "enable routing services" checkbox when installing MSMQ. (This is not a default selection.)
  • Detailed help for installing and configuring MSMQ is available in the online Windows 2000 help. The steps below are configuration guidelines to accommodate the test environment. For all other issues, please consult the online help.


For the cluster and client installations

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

You should not be prompted for Windows 2000 MSMQ server; it should be auto detected.

If you are prompted, then either MSMQ is not installed on a properly selected DC, or a configuration error has been made.

This does not necessarily block the MSMQ HCT test, but indicates a sub-optimum enterprise configuration for the test.

At the prompting dialog, you may type in the name of the DC on which you installed MSMQ. Setup should proceed normally after that.


Specific installation details

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

Click to show or hide information. The Domain Controller

This is the first installation that must be completed. The target DC must be selected carefully if there is more than one to choose from in the Windows 2000 enterprise. The DC must be:

  • A Windows 2000 Domain Controller
  • In the same domain as the test cluster and test client machines.
  • In the same Active Directory site as the cluster and clients. In fact, before the MSMQ is installed on the DC, confirm that a subnet is defined that associates the IP addresses of the DC, cluster and clients with the same site.
  • The DC must be configured to contain a copy of the global catalog.

If these steps are done correctly, the following MSMQ installations will auto-detect the DC, and the MSMQ HCT test will run smoothly.

Allow some time (~30 minutes) after this MSMQ installation before attempting the cluster and client installations. This is to allow for internal and intra-site replication of the MSMQ server objects.

To install MSMQ on the DC, perform the steps in For all installations.

Click to show or hide information. The Cluster

The cluster should be installed next. There are five separate installations involved - one installation for each node to cluster MSDTC, one installation for each cluster node MSMQ, and one for the MSMQ cluster resource.

MSMQ requires that MSDTC be clustered and the MSDTC resource online before the MSMQ cluster resource can be created.

Perform the installations in this order:

  • Clustering MSDTC

On each node of a working cluster go to the command line and run the program: comclust.exe. This should create the resource MSDTC and bring it online. By default this should show up in the 'Cluster Group'. Use the console command:

cluster.exe res

to confirm this, or use the cluster administrator application.

  • Initial MSMQ installations

On each node of the working cluster, install MSMQ as noted in For all installations.

  • Clustering MSMQ

In the cluster group that contains the MSDTC resource, create the MSMQ resource manually with the steps outlined in the online help topic: "To configure Message Queuing resources for server clusters"

Click to show or hide information. The Clients

On each test client, install MSMQ as noted in For all installations.


MSCS System Validation Test Assertions

24.1.1 Assertion name

Reference Document: TBD
Test Description: " TD-24.1 Client-Server General Tests Descriptions "


MSCS System Validation Test Descriptions

This section presents the system configuration criteria for an Microsoft Cluster Server (MSCS) system. Note that all components in a cluster system must be validated to run on Windows Whistler and be on the HCL before they will be considered for MSCS-specific testing. Components that are not on the HCL must pass HCT tests prior to MSCS testing, because MSCS testing is designed to test MSCS requirements, not general Windows Whistler requirements.


MSCS Configuration

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

For this type of hardware testing, the HCT kit and BackOffice® testing programs are used. The following lists constitute an MSCS configuration.

Click to show or hide information. Server Requirements for an MSCS System

  • 256-MB minimum system memory
  • System BIOS and firmware
  • Internal drive(s) used to boot each node of the cluster (can be either IDE or SCSI )
  • PCI SCSI, Fibre Channel, or RAID controller and drives used for the storage bus (different from the one used for the internal boot drive)
  • Network card(s) used for intra-cluster and client communications.

No ISA network card or storage devices should be used in a cluster.

In addition to the minimum system requirements for a cluster, Microsoft will require the following for system validation:

At least two shared disks on the storage bus (SCSI, Fibre Channel, etc.). These are logical drives that are seen at the Windows 2000 SCSI class driver and can represent many physical drives in some RAID implementations. Microsoft recommends that the number of disks on the shared bus represent a typical customer configuration. The client-server tests will exercise a default maximum of eight shared disks. The default maximum is configurable through the test GUI.

At least eight client nodes + 1 client master node that can connect to the cluster using a network using TCP/IP. Client requirements are detailed below.

At least one static IP address per disk on the shared bus. One of these static IP addresses will be used to setup up the cluster virtual server. The remaining static IP’s 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 client machines and also the cluster servers.

  • Minimum of at least 250 MB free hard disk space on system drive

It is highly recommended that all disks should be formatted as NTFS. The shared disks in cluster must be formatted as NTFS.

Click to show or hide information. Network requirements for running tests

The phase 2-5 tests will generate a lot of network traffic doing client/server type of IO. We recommend that all of the client machines and cluster nodes be on a private network. The cluster nodes may be setup as domain controllers. However we find that the best results for this heavy level of stress testing is to have another server that is always up providing domain services.

The client nodes, client master node, and the cluster nodes must all be a member of this same domain. We typically have our lab setup to have all machines logged on as the same domain account that has local administrator rights on each node. We use this same account for the cluster service also.

The server 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 what we believe will be 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. We recommend that all testing be done on a private network.

Click to show or hide information. Client Requirements for an MSCS System

The client machines will be used to simulate client-server stress against the cluster. The eight required client nodes 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 MSCS certification is being done with Windows NT Server 4.0 Enterprise Edition, each client must be on the Windows 2000 HCL and running Windows NT Workstation 4.0. If MSCS certification is being done with Windows 2000 Advanced Server or Windows 2000 Datacenter Server, each client must be on the Windows 2000 HCL and running Windows 2000 Professional.
  • Each client should have at least 128 MB of memory
  • Each client should be at least a Pentium II -class or better machine. Microsoft recommends a client mix as close to your typical customers’ use as possible. Microsoft uses six 128-MB Pentium II machines, and two high-end workstations.
  • Each client must have an HCL 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.

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 other client machines except that it should be running Windows 2000 Server or Windows 2000 Advanced Server and it should have at least 256 MB of memory plus two free serial ports. The client master must also be able to communicate through TCP/IP with all of the test systems and it should be able to handle minimum 100 concurrent network sessions. This includes the eight clients as well as the cluster nodes. The client master is used to:

  • Run the MSCS cluster administrator to monitor the status of the cluster.
  • Provide a share point to start up the client tests on the other clients.
  • Cause automated failover testing in testing Phase 2-5.
  • Serve as the kernel debugger for each server node. This requires a free serial port for each cluster node to set up the kernel debugger. Please see documentation in the Windows 2000 device driver kit (DDK) for setting up a kernel debugger.

Click to show or hide information. MSCS Configuration Components

An MSCS configuration consists of three main components.

  • Two or more servers.
  • A shared disk configuration using fibre or multi-initiator SCSI.
  • The "interconnect" network interface card in each server used for intracluster communications.

All three must be on the appropriate Microsoft HCL. Microsoft views MSCS requirements as a superset of normal HCL requirements. However, the normal HCL is a starting point for MSCS configurations. MSCS validation is designed primarily to ensure that a given hardware cluster configuration will work with MSCS. The HCT kit is used to ensure proper functionality of hardware with normal one-node Windows NT Server or Windows 2000 Server.

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 MSCS configuration until it has successfully gone through the 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. This can include power failures, SCSI cables coming loose, disk cabinets failing etc. Because MSCS is intended to serve as the foundation for highly available systems, it is recommended (though not required) that configurations minimize or eliminate single-points-of-hardware-failure configurations.

Click to show or hide information. Servers in an MSCS Configuration

The MSCS server requirements 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. MSCS is designed to work in any x86 (Pentium-class or better) server on the HCL list, including uniprocessor and multiprocessor machines. All servers must go through normal HCL testing before any MSCS configuration testing and must be on the appropriate HCL list.

Click to show or hide information. Shared Storage Bus in an MSCS Configuration

The shared SCSI bus is probably the most sensitive part of an MSCS configuration. There are four components that potentially make up the shared SCSI bus, although not all four are required for any given configuration. The components are:

  • Fibre Channel Adapter or SCSI Adapter
  • RAID Controller (SCSI or Fibre Channel)
  • RAID System (SCSI or Fibre Channel)

All of these components must be on their respective HCL before any MSCS testing will be done. Microsoft has categories on the HCL for cluster candidate components of these types. 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, 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 IHV will be able to use them in an MSCS configuration.

Figure 2 MSCS component and system certification process

Figure 2. MSCS component and system certification process

Click to show or hide information. Interconnect Cards in an MSCS Configuration

Interconnect cards are what MSCS uses to communicate between the nodes of a cluster. This 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.

Interconnect cards must pass normal certification for Network Interface Cards.

NIC Teaming is not supported on Windows NT 4.0 Clustering as well as Windows 2000 clustering.

Click to show or hide information. How to configure private cluster networks

This is one of the ways you can configure the private networks. Connect all the private networks to the hub. Assign the static IP Address of 10.1.0.1 with a subnet mask of 255.255.0.0 for the cluster node1. For node2 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, select Properties. Select the properties for Internet Protocol (TCP/IP). Choose "Use the following IP Address" and specify the above mentioned IP Addresses.

Click to show or hide information. Cluster Server and Storage Blocks

In Windows Whistler, clusters may contain up to four nodes. To help manage the number of permutations and combinations under test we are defining 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 cluster server block with a compatible cluster storage block.

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 Whistler Cluster HCT much as in previous releases, however positive test results will result in the WHQL listing of a Cluster server block and a Cluster Storage Block.

Combining a WHQL Cluster Server block with a compatible Cluster Storage Block thus 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) is identical.

Example:

  • A vendor can run a Cluster HCT test with server model 1 using HBA 1 connected to Storage 1. This testing would result in a server block listing of server 1 w/HBA 1, and a storage block listing of HBA 1 w/Storage 1.
  • A vendor can then run Cluster HCT test with server model 2 using HBA 1 w/Storage 2, thus listing a server block of server 2 w/HBA 1 and a storage block of HBA 1 w/Storage 2.
  • A vendor can now leverage the above test results, combining any combination of server and storage blocks since all the blocks share a common HBA and thus creating additional cluster solutions.

In our experience we observe 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, it is possible to define a server family so that cluster would not require re-certification with any changes within the server family. Following are some of the criteria for Server Family:

Click to show or hide information. Server Family (SF):

If a server in a family is certified then any server in that family should be considered certified for clustering.

  • Same processor family with CPU Speed range of 500MHZ
  • Same PCI Bus speed (can it vary?)
  • Same Vendor, although if the architecture is different enough then the vendor will categorize it as a separate family

Click to show or hide information. HBA Block (H):

HBA Block (H) (Cannot be qualified separately for clustering)

  • Filter Driver
  • Driver
  • Actual HBA

A server of a server family along with a HBA Block constitutes 'Server Family Block'. Any changes in HBA Block or Server as defined by server family will require new certification.

Click to show or hide information. Server Family Block

(Cannot be qualified separately)

A server from server family

HBA Block (H)

A Storage block contains HBA block, Switch/hub and Storage. The HBA Block overlaps with HBA block of Server. So if a Server Family block is certified with a given HBA then any Storage block certified with that HBA is considered certified. Any changes in the building block will require new certification.

Click to show or hide information. Storage Block

(Can be qualified and will replace existing Cluster Device testing)

  • HBA Block (H)
  • Fabric (F)
  • Storage

Cluster configuration will consists of Server Family Block and Storage Block.

Click to show or hide information. Cluster Configuration

(Can be qualified)

  • Server Block
  • Storage Block

Microsoft will support any combinations of Server Family Block (SFB) & Storage Block (SB) including rolling upgrades if they qualify the following tests.

  • Homogeneous.

Every Server Family Block (SFB) should be qualified with every Storage Block (SB).

  • Heterogeneous.

Click to show or hide information. Heterogeneous Configurations For Multinode Clusters

In Windows Whistler, clusters may contain up to four nodes. A multinode cluster is defined as any cluster in which two or more servers have been configured. Multinode clusters may be homogenous, i.e. consisting of an identical server, as defined in the previous description of changes affecting the cluster. Multinode clusters may also be heterogeneous, in which case each change to the composition of the cluster servers would require a re-certification.

In order to reduce the overhead of testing an exponentially growing number of distinct configurations, the following rules may be applied towards the classifying heterogeneous multinode configurations as unchanged, in which case no new submission is required. These rules assume that all four of the servers would be considered heterogeneous, as described in the previous section, and will be referred to as servers A, B, C, and D.

  • In order to qualify for heterogeneous cluster configurations, representative servers from the heterogeneous set of servers families {A, B, C, D} must have qualified via an HCT submission in a homogenous cluster composed of the same server type. Where A, B, C, D are server families. Thus, the pre-requisite for submitting a cluster configuration of type {ABCD} is the qualification of four clusters of types {AAAA}, {BBBB}, {CCCC}, {DDDD}.
  • All of the homogenous clusters must have qualified with the same storage component, where storage component is defined as the same RAID device under the descriptions provided earlier.
  • All of the homogenous clusters must have qualified with the same HBA.
  • The heterogeneous clusters must utilize the same storage and HBA components that were submitted for the homogenous qualifications.
  • Having met the above conditions, a single qualification of a cluster consisting of server types {ABCD} will be sufficient to cover all the combinatorial configurations possible, such as {AAAB, ABAB, ACCC}.
  • A submission of a heterogeneous configuration of four nodes validates the use of those servers in configurations with less nodes without requiring any further certification.

In the event of a new server type E, it can be derived from these rules that it is possible to qualify all combinations of {A, B, C, D, E} by submitting two configurations: {EEEE, BCDE}

Sliding window is used to maintain transitive relationship between Server Family Block and Storage Block. For example

(Server Family) SF1, SF2, Sf3, SF4, SF5 with (HBA) H1, (HBA) H2, (HBA) H3, (HBA) H4, (HBA) H5and (HBA) H6 with (Fabric) F1+(Storage) R1) and (Fabric) F1+(Storage) R1)

Following will be the combinations for the above example

SF1+H1, SF2+H2, SF3+H3, SF4+H4 with F1+R1, SF1+H1, SF2+H2, SF3+H3, SF4+H4 with F2+R2

SF2+H2, SF3+H3, SF4+H4, SF5+H5 with F1+R1, SF2+H2, SF3+H3, SF4+H4, SF5+H5 with F2+R2 (NOTE: both SF & H1 are varied)

SF2+H3, SF3+H4, SF4+H5, SF5+H6 with F1+R1, SF2+H3, SF3+H4, SF4+H5, SF5+H6 with F2+R2 (NOTE: Since SF is done, only H is varied)

For SF=1, H=3 (change driver or multi path version), F=2 (change in firmware), hence SB=5. Number of servers in SF=12

Homogenous = 1 X 5 = 5

Heterogeneous = 1 + 1 = 2

Total = 7.

If above 7 tests are performed then Microsoft will support any combination of the above pieces including rolling upgrades. The above proposal will reduce the number of combinations.

Click to show or hide information. Rolling Upgrades

To be defined. The test needs to support a customer configuration of three servers running Windows 2000 and one server running Windows Whistler.

Click to show or hide information. Geographically Dispersed Clusters

Microsoft Server Clustering can be used to implement geographically dispersed clusters where the members of a single cluster can be deployed on several different sites. The Microsoft Server Clustering product itself is unaware of the extended nature of these types of cluster and it is the responsibility of the network and storage architectures used to build these geographic clusters to preserve the semantics, in particular:

The private and public network connections between cluster nodes must appear as a single, non-routed LAN using technologies such as VLANs. In these cases, the connections network must be such that they can provide guaranteed maximum round trip latency between nodes of no more than 1/2 second.

Any geographically replicated storage technologies must preserve single disk semantics such as persistent arbitration of a logical unit to the MSCS server cluster product. The quorum disk must be replicated in real-time, synchronous mode across all sites. Many geographically dispersed solutions can be created by adding data replication software and extended LAN hardware to existing, already certified configurations, however, these solutions radically change the nature of a pre-certified configuration particularly in respect to timing and latency. Microsoft therefore requires both the hardware and software configuration of a geographically dispersed cluster be certified and listed on the cluster HCL list before Microsoft supports them.

Geographically dispersed clusters are certified as follows:

The servers and the basic storage units used in the geographic cluster configuration must be first certified as either a 2-node Advanced Server or Data Center MSCS configuration or a 4-node Data Center MSCS configuration before being certifiable as a geographically dispersed cluster. This ensures the basic cluster capabilities of the server and storage hardware including phase 1 of the cluster HCT in a standard (non geographically dispersed) configuration.

With the cluster re-configured as a geographically dispersed cluster, the configuration must pass all HCT tests with the possible exception of phase 1.

If the geographically dispersed configuration does not behave like a single SCSI-based configuration, the phase 1 HCT tests will not pass successfully. In these cases, phase 1 of the tests can be substituted with a design review by the Microsoft cluster server team. This design review will be organized with appropriate members of the cluster team to validate the approach used for protecting and replicating data across the sites as well as network topology and architecture.

Click to show or hide information. Changes that Constitute a Different Cluster Configuration

As shown in Figure 2, the final cluster configuration consists of three main components. Any major change to these components will result in a new cluster configuration and therefore will require new validation testing. Defining configurations in this way ensures that the end product will work correctly when MSCS is installed. Major changes are defined as the following:

  • Changing the server used in the configuration. We determine a different server if the server is part of a different family.
  • Changing the server from a uniprocessor to a multiprocessor model.
  • Changing the server from a multiprocessor to a uniprocessor model.
  • Changing or adding a SCSI HBA of a different type than previously validated.
  • Changing or adding a SCSI RAID HBA of a different type than previously validated.
  • Changing or adding a SCSI HW RAID box of a different type than previously validated.
  • Changing or adding a Fibre Channel switch of a different type than previously validated.
  • Changing or adding a Fibre Channel switch firmware version to a version other than previously validated.
  • Changing or adding a Fibre Channel hub of a different type than previously validated.

Click to show or hide information. Changes That Do Not Constitute a Different Cluster Configuration

Microsoft wants to provide as much flexibility as possible for system vendors to build cluster configurations while at the same time ensuring that the configurations will work correctly. Changes to configurations that don’t have a major impact on the operability of MSCS will not constitute a new configuration.

Depending on the results of the system validation testing, Microsoft can change the process to allow more or fewer variations within a configuration. The following changes are believed to have no major impact upon MSCS and therefore do not constitute a new configuration. Therefore, when making these changes, no new validation needs to be done. However, it is recommended that all systems be tested periodically. Non-major changes are defined as the following:

  • 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 the number of processors in a multiprocessor server. (example 2->4 or 4->2)
  • Changing the network card used for client access as long as this new card is in on the HCL.
  • Changing the interconnect card. As long as the new card is a PCI 100% compliant NDIS card and on the HCL.
  • Changing the internal bus used to boot the system.
  • Adding more memory to the server.
  • Changing the speed of the processors in the server.
  • 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.
  • Adding another SCSI RAID HBA of the same type, as long as the storage solution on that new bus is the same as the original tested configuration.
  • 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.
  • Adding more disks to a configuration.
  • 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.


Setup for MSCS 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 the minimal effort. As a general statement, testing with the more complex Windows Whistler SKUs will also enable you to list the simpler SKUs as noted herein.

If a vendor successfully completes 2 Node Datacenter HCT Cluster testing, they are assumed to pass for Advanced Server too and no further testing is required; they may request immediate listing for Advanced Server.

If a vendor successfully completes 4 Node Datacenter HCT Cluster testing, they are assumed to pass for 2 Node Datacenter Cluster testing and no further testing is required; they may request immediate listing for 2 Node Datacenter

If a vendor successfully completes Advanced Server Cluster testing they are NOT assumed to be tested for Datacenter. They must test separately with Datacenter.

If a vendor successfully completes 2-node cluster HCT testing, they are NOT assumed to be tested for 4 node.

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 1 earlier in this document.

  1. Install the desired operating system on all the cluster nodes, clients and client master. During installation you should install components for tests in Section X (LINK TO APPROPRIATE SECTION). You should also create a domain account, give that account admin privileges on all machines and use this to log on all machines during all test phases (cluster nodes, master client and clients).
  2. Run Chklogo Phase (LINK TO APPROPRIATE SECTION) on the cluster that is max'ed out with resources.
  3. Run Hardware Phase tests (LINK TO APPROPRIATE SECTION).
  4. Reboot node 1 and turn all the other nodes off.
  5. Create a partition on each shared drive.
  6. Format each shared drive with NTFS.
  7. For Windows 2000, install MSCS software on node 1.
  8. Configure clustering on node 1 (i.e. form a one node cluster).
  9. Run Vald1 Phase.
  10. Turn on another node.
  11. For Windows 2000, install MSCS software on that node.
  12. Join the cluster created in step 9.
  13. For 2-node cluster certification, go to step 19.
  14. For more than 2-node cluster certification, run Vald2 Phase.
  15. Turn on all remaining nodes.
  16. For Windows 2000, install MSCS software on all these nodes.
  17. Join all these nodes to the cluster created in step 9.
  18. Run ValdN Phase.
  19. With all the nodes having joined the cluster in the previous phases, run MovN Phase.
  20. Submit results to WHQL.


ChkLogo Phase Test

Overview

This test will verify that the drivers on the system are logo'd. The log file created by the test is LOGFILENAME

<[Optional Subheads] Use "Label" Style>

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 max'ed out with hardware resources.

Click to show or hide information. How to run

On the node:

On the "Available Tests" list, click the "Cluster" plus box.

Select "Logo'd Components Test".

Click the "Add Selection" button.

Click the "Start Tests" button.

Results Interpretation

TBD


Hardware Phase (48 hours)

Overview

Hardware Phase is designed to stress the hardware of the cluster configuration, as depicted in Figure 1a or Figure 1b, to verify its ability to support MSCS. This phase consists of two tests: CliSrv1 and CliSrv2. Each of which is expected to take one day.

During Hardware Phase testing, the MSCS software must not be installed. It is not necessary that disks attached to the shared storage bus be formatted with any file system. Hardware Phase performs tests that write to the shared disks, any user or file system data previously stored on the disk will be lost. After this phase, the shared disks will need to be reformatted and mounted. However, Hardware Phase tests rely on the disk signature to identify shared disks, therefore it is necessary that each disk have a unique disk signature.

The shared storage bus is an integral part of the cluster's hardware configuration. This bus may be a SCSI bus as depicted in Figure 1a or a Fibre Channel Fabric or Arbitrated Loop as depicted in Figure 1b. This testing stress the shared storage bus by issuing SCSI commands to the SCSI bus or to the SCSI protocol on the Fibre Channel.

If the cluster hardware configuration includes a hardware RAID component, the disk arrays must be configured on that component before testing begins. These arrays will be treated as any other disk drive.

These tests will run on each disk found on the shared storage bus. These tests are broken into two categories:

Click to show or hide information. Cache Coherency Tests

These tests write a generated test pattern of a random length to blocks on the disk, with the Forced Unit Access (FUA) and Disable Page Out (DPO) bits set. The other initiator will issue a read command, also with the FUA and DPO bits set, and then compare the data in memory. Variations of this test will select the starting block address of the write and read commands to generate random and sequential I/O patterns. Each node will participate in both the "writer" and "reader" roles.

Click to show or hide information. Re serve/Release Tests

These tests will insure that drivers, shared disks, and other SCSI components correctly implement SCSI Reserve and Release commands, the MSCS shared disk arbitration relies on this mechanism. One initiator will reserve the disk, commands issued to the disk from the other initiator should fail with "Reservation Conflict" status. These tests also insure that reservations are broken with a bus reset.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

In CliSrv1: Each process will create a standard Windows NT log file with the results from the test. The "Cluster N Node Test Server" processes create log files named NnodeSim_Server.log, there will be one of these files on each node which participated in the test. The "Cluster N Node Test Client" process creates a log file named NnodeSim_Client.log, there will be one such file created on the node that served as the test client.

In CliSrv2: LOGFILES

Click to show or hide information. Requirements

[Clarification - v.0.7]

  • Nodes should not have clustering installed. If a cluster setup already exists, then you need to remove that. In Windows 2000, uninstall cluster service. In Whistler, run "cluster node <nodename> /force" on each node to ensure that you don’t have an active cluster working.
  • All partitions on shared disks should be removed. This can be done through Disk Management.
  • CliSrv1 runs on the cluster nodes only.
  • CliSrv2 requires an extra client in addition to the nodes.

Click to show or hide information. How to run CliSrv1

You need to designate one of the nodes to act as a client and the rest as servers:

  1. On node 1 (acting as the client):
  2. On the "Available Tests" list, click the "Cluster" plus box.
  3. Select "CliSrv1 - Client".
  4. Click the "Add Selection" button.
  5. Click the "Start Tests" button. This will start 2 processes (and 2 command windows). One process is the "Cluster N Node Test Client", "the other is the Cluster N Node Test Server".
  6. Then, on all other nodes (acting as severs):
  7. On the "Available Tests" list, click the "Cluster" plus box.
  8. Select "CliSrv1 - Server".
  9. Click the "Add Selection" button.
  10. Click the "Cluster\CliSrv\Cluster N Node Test Server" plus box under "Selected Tests".
  11. Double-click the text under the plus box and change Param2 ("Client Name") to the name of the computer serving as the test client.
  12. Click OK.
  13. Click the "Start Tests" button. This will start 1 process and 1 command window. The process is the Cluster N Node Test Server.

Click to show or hide information. How to run CliSrv2

You need a client in addition to the nodes. The nodes are designated as servers.

  1. On the client, on the "Available Tests" list, click the "Cluster" plus box.
  2. Select "CliSrv2 - Client". Click the "Add Selection" button.
  3. Click the "Start Tests" button. This will start 2 processes (and 2 command windows). One process is the "Cluster N Node Test Client", "the other is the Cluster N Node Test Server".
  4. Then, on the nodes (acting as servers):
  5. On the "Available Tests" list, click the "Cluster" plus box.
  6. Select "CliSrv2 - Server".
  7. Click the "Add Selection" button.
  8. Click the "Cluster\CliSrv\Cluster N Node Test Server" plus box under "Selected Tests".
  9. Double-click the text under the plus box and change Param2 ("Client Name") to the name of the computer serving as the test client.
  10. Click OK.
  11. Click the "Start Tests" button.. This will start 1 process and 1 command window. The process is the Cluster N Node Test Server.

Results Interpretation

If the hardware test fails you should look at all of log files. All variation and statistics gathering is done on the test client. However, error conditions such as I/O failures will be reported in the server log file.

From the HCT test manager, you can easily view the results of each test. If the test fails, it will report on the client side why the test failed. If the actual failure happened on the server node, you should look at both log files to determine which command failed and why it failed.

Click to show or hide information. Problem Resolution:

If the NNodeSim.exe test fails you should look at all of log files. All variation and statistics gathering is done on the test client. However, error conditions such as I/O failures will be reported in the server log file.

Here is a list of the common problems this test has found:

  • Release command. This SCSI II command should never fail. Even if the initiator issuing the release currently doesn't have a reservation. The semantics of this command is that after it completes the issuing initiator no longer owns a reservation.
  • No commands besides inquiry and request sense should work from an initiator, if another initiator currently has a reservation on a disk. This test will attempt to do write, read, and test unit ready commands that should fail in this scenario.
  • Write caching problems. If the controller or RAID device does any write caching it must guarantee the cache for both paths.


Validate 1 Node Phase (24 hours) Tests

Overview

This phase of the testing is to ensure that all of the cluster resources will work with only a single node. This is an important case because 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 run from the client master. Also, on the client master, the following are running:

Click to show or hide information. Spsrv

This is a service that the validation kit depends heavily on. 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 will sniff network traffic that may turn out useful triaging failures.

The test will utilize 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 are:

File IO tests consist of the following 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. Manyfile Test

Creates many small files

Click to show or hide information. FTP test

Copies some small test files to the shared disks, then uses FTP to transfer them from the client nodes and verify that those are actually the files on the server.

Click to show or hide information. IIS test

Simulates IIS activity on the cluster root. The test will create a web page and sends queries to it simulating thousands of hits in a short time

Click to show or hide information. Printer test

Spools printer jobs to the shared drive and then the clients will check their print jobs.

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 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.

Click to show or hide information. How to run

[Clarification - v.0.7]

  1. On the master client, On the "Available Tests" list, click the "Cluster" plus box.
  2. Select "Validate 1 Node", click the "Add Selection" button, 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

A dialog titled "Specify static IP Addresses" will appear. The dialog will request one IP address per 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 and enter IPs 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. Repeat this operation for each network. 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

[Clarification - v.0.7]

For trouble shooting failures, refer to the section on interpreting the different logs. Here is list of common mistakes user makes while running HCT kit:

  • Entering Duplicate IP Addresses that are already in use.
  • Installing Windows 2000 Professional on Client master machine.
  • Entering 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> -clusflags:1" on the client master will offline and delete the resources created by the kit. Make sure you have spsrv service started on the cluster nodes and the client master by running "spsrv – install" then "net start spsrv".
  • Use the WTTCopyLogs tool to collect logs from the cluster nodes.

There are many logs file to be used to find problems. The log created by this phase 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.


TD-24.1 Lrgfile Test Descriptions

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. All of this will be set up by the scripts when they are run from the client monitoring system.

Lrgfile uses unbuffered I/O only and retries on every file I/O operation.

The user will not be required to know the syntax of these test programs. The test launcher will start the test when it is run on each client node. 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 LRGFILE: 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.

Mapfile test requires 4 MB of space on tested drive. If there is not enough space, Mapfile exits.

Results Interpretation

If LRGFILE test fails, look for LRGFILE.LOG log file. This file should contain error information and reason for failure. Since LRGFILE test is run with -Vn switch (leave n MB of free space on disk), common problem is that test did not start at all, because there was not enough space to start the test. LRGFILE 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 LRGFILE test locally on server. You can find LRGFILE.EXE in your HCT\TESTBIN directory or on HCT CD. Copy it on server node and run command from WINDOWS NT console.

lrgfile -r10 -p32 -b8 -dX:

-r10 means run 10 times

-p32 means that LRGFILE will use 32*4 KB chunks of data for each write/read operation

-b8 means that LRGFILE will use 8 buffers for asynchronous write/read

-dX: replace X with suspected shared drive letter. Be sure that disk is online on the node that runs LRGFILE!

LRGFILE will grow temporary test until it consumes entire available disk space, than shrinks file back while checking data. DO NOT MOVE/FAILOVER DISK RESOURCE DURING THIS TEST. After LRGFILE finishes, look in the log file LRGFILE.LOG (in the same directory LRGFILE.EXE was run from) and search for data errors (e.g. Disk data error: Chunk#xpct 0x12, chunk#got 0x0, Page#=0). If you see this error your disk failed and is unreliable. If your disk passes this test, but does not pass node test with random moves/failovers, it point to the cache problem. If both tests pass but client test does not it points to the problem in redirector. Mostly, 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.


TD-24.2 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 phase, 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. All of this will be set up by the scripts 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.

Mapfile test requires 4 MB of space on tested drive. If there is not enough space, Mapfile exits.

Results Interpretation

Mapfile test requires 4 MB of space on tested drive. If there is not enough space, Mapfile exits. Another common problem is network failure or cluster service/resource failure. If test fails because of data corruption problem (read data differs from expected), the cause is not easy to determine. Mostly, 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. See LRGFILE Problem resolution paragraph how to eliminate disk-media problem.


TD-24.3 MANYFILE Test Description

Overview

TBD

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

TBD

Results Interpretation

TBD


TD-24.4 FTP stress Test Descriptions

Overview

As part of the setup, Microsoft will copy some small test files to the shared disks. This test will use FTP transfers to move that file back and forth from the client nodes. 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.

The FTP service is not installed by default on Windows 2000. To install it on each Windows 2000 Advanced or Datacenter Server, see Installing OS Components for Tests in Validation Kit.

Results Interpretation

The name of the log file is ftpcont.log. A "FAIL: Max time out" indicates a failure. 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 95 or NT to check if ftp service is accessible from the client.


TD-24.5 Gqstress Test (IIS test)Descriptions

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 is expected during failovers because the network name and IP address have to be moved to the other server. 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.

The FTP service is not installed by default on Windows 2000. To install it on each Windows 2000 Advanced or Datacenter Server, see Installing OS Components for Tests in Validation Kit.

Results Interpretation

The name of the log file is gqstress.log. A SEV2 error indicates a failure. It is normal to have time out as it happens during fail over. 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://clustername, http://nodename1, http://nodename2, http://netname1, http://netname2. All of them should fetch the default IIS home page.
  • If 172.31.224.44 is the static IP address used for a group. Then 172-31-224-44 will be the name of the Cluster resource. Then you can fetch the gqstress.htm from the browser as follows: http://172-31-224-44/w3svc_q/gqstress/gqstress.htm.


TD-24.6 Print Server Test Description

Overview

For Printer Server Testing clients will spool print jobs to the print server, the print server will spool the jobs to the shared drive, and then the clients will check their print jobs. In the case of failover, the clients will check that their print jobs are still available when the print server moves to the other node.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

TBD

Results Interpretation

For trouble shooting printing, here are some things to check.

Click to show or hide information. Rolling upgrade

If jobs are lost on a NT4 node fail over to a Win2000 node (or the reverse), check the the Printer:Properties:Advanced:Enable advanced printing features is turned off (this is on Win2000). On NT4, turn on Printer:Properties:General:Print Processor:Always spool RAW datatype.

Click to show or hide information. Missing Printers

Verify that the correct print drivers are installed on each node. Go to each node (print folder:server properties:drivers and install the driver needed by the printer. You can do this locally or remotely.

Click to show or hide information. Resource won't come online or jobs are missing on failover

Check that the spool directory (print folder:server properties:advanced, Spool Folder) is set to a directory on the shared disk.

Click to show or hide information. Ports are missing

On Win2000, you need new port monitors. LprMon and the Standard TCP/IP port monitor have been revised to support clustering. Other third party monitors may not work unless they have been updated by the ISV.


TD-24.7 WINS Test Description

Overview

This test verifies that 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 2000 Advanced 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 may 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 the user should check to see if the WINS service has started or if it has failed over correctly. If WINS failed to start on a fail over or it failed to move to the other node there should be event log entries in the event log and there should also be entries in the cluster log that can bee looked at to determine why WINS failed.


Validate 2 Node Phase (24 hours)

Overview

This phase of the testing is to ensure that all of the cluster operations between nodes such as move, failover, etc. will work. You do NOT need to run this phase for a two-node cluster certification. This test is run from the client master.

In this phase, the same tests shown in Validate 1 Node Phase are running. However, 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 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 kit will abort the run.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

  • Two-node cluster. All other machines (that will join the cluster later on) should be turned off.
  • Shared storage partitioned and formatted in NTFS.
  • You should be logged on all machines (nodes, master client and clients) 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 "Available Tests" list, click the "Cluster" plus box. Select " Validate 2 Node ".

Click the "Add Selection" button. 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

A dialog titled "Specify static IP Addresses" will appear. The dialog will request one IP address per disk resource per network visible to the clients. 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. Repeat this operation for each network. 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 trouble shooting failures, refer to the section on interpreting the different logs. Here is list of common mistakes user makes while running HCT kit:

  • Entering Duplicate IP Addresses that are already in use.
  • Installing Windows 2000 Professional on Client master machine.
  • Entering 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>" 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.

There are many logs file to be used to find problems. The log created by this phase is vald2.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.


TD-24.8 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 Server setups will work when the default is to have the node crashdump 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.

TBD

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. e.g.

C:\ >net helpmsg 1722

The RPC server is unavailable.

At least one node should be up during the entire phase 4 and 5 testing. If both the nodes die then spfail typically gets a 1722 error code (RPC Server unavailable error).

Another typical reason why a spfail fails is if the node fails to boot 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 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 actually resouce 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 this case the resource "MS Mail Connector Interchange" failed. Now trouble shoot why did this resource failed.

Click to show or hide information. Trouble shooting 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 from the cmd window.

"spsrvcl -host:<node name> -cmd:crash"


Validate N Node Phase

Overview

This phase of the testing is to ensure that all of the cluster operations between nodes such as move, failover, etc. will work. You need to run this phase with all the nodes having joined the cluster intended for certification. This test is run from the client master.

In this phase, the same tests shown in Validate 1 Node Phase are running. However, 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 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 kit will abort the run.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

  • The cluster being certified: a two or four-node cluster
  • Shared storage partitioned and formatted in 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.

Click to show or hide information. How to run

On the "Available Tests" list, click the "Cluster" plus box.

Select " Validate N Node ".

Click the "Add Selection" button.

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

A dialog titled "Specify static IP Addresses" will appear. The dialog will request one IP address per disk resource per network visible to the clients. 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. Repeat this operation for each network. 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 trouble shooting failures, refer to the section on interpreting the different logs. Here is list of common mistakes user makes while running HCT kit:

  • Entering Duplicate IP Addresses that are already in use.
  • Installing Windows 2000 Professional on Client master machine.
  • Entering 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>" 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.

There are many logs file to be used to find problems. The log created by this phase is valdN.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.


Move N Node Phase (48 hours)

Overview

This phase of the testing is to ensure that the resource move operation, the most common operation, will work. You need to run this phase with all the nodes having joined the cluster intended for certification. This test is run from the client master.

This phase is the same as Validate N Node Phase except for spfail process. In this phase, spfail doesn't crash nodes, but only moves groups between cluster nodes.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

  • The cluster being certified: a two or four-node cluster
  • Shared storage partitioned and formatted in 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.

Click to show or hide information. How to run

On the "Available Tests" list, click the "Cluster" plus box.

Select " Move N Node".

Click the "Add Selection" button.

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

A dialog titled "Specify static IP Addresses" will appear. The dialog will request one IP address per disk resource per network visible to the clients. 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. Repeat this operation for each network. 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 trouble shooting failures, refer to the section on interpreting the different logs. Here is list of common mistakes user makes while running HCT kit:

  • Entering Duplicate IP Addresses that are already in use.
  • Installing Windows 2000 Professional on Client master machine.
  • Entering 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>" 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.

There are many logs file to be used to find problems. The log created by this phase is movN.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.


Chapter 25: Printer Test Specification

Draft Version: 0.7 — Date: February 12, 2001

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 | 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.pcdesguide.org/library/

Windows Color Quality Specifications for Printer OEMs

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


Device Availability Assertions

These assertions are tested in the PrintInstant test.

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 NTLog failure

Reference Document: WLP# - B8.1.4
Test Description: TD-25.7 16 bit Application Print Compatibility (Print16)


Standard Port Monitor Compatibility Assertions

These are tested by the port monitor test.

25.8.1 Standard port monitor failure

Reference Document: WLP# - B8.1.4.3; PC 2001 System Design Guide - PRNT-0295.
Test Description: TD-25.8 Standard Port Monitor Compatibility (HCTAddPort)


Printer Test Descriptions

This section describes the tests provided.

TD-25.1 Device Availability (PrintInstant)

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 a NTLog failure for the printer and a page is printed.


TD-25.2 Printer Device Capabilities (PrDevCap)

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)

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.

This test is a legacy test and has no new points of failures and no assertions.

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)

Overview

This tests printer drivers’ application compatibility and output quality.

This is a legacy test and has no assertions.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

See WinParty documentation.

Results Interpretation

See WinParty documentation.


TD-25.5 Windows Color Quality (PrintColor)

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 NTLog 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)

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 a NTLog 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)

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 occurs will generating the print job the tool will log an NTLog failure. The output should be visually inspected.


TD-25.8 Standard Port Monitor Compatibility (HCTAddPort)

Overview

This test that a printer is capable of working with the Standard TCP/IP Port monitor.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

TBD

Results Interpretation

TBD


Chapter 26: Hardware Abstraction Layers (HALs) Test Specification

Draft Version: 0.7 — Date: February 12, 2001

Overview

The purpose of the HAL test kit is to test third party (non-Microsoft) Hardware Abstraction Layers (HALs) intended for use in Windows 2000 Datacenter class servers. HALs that are not indended for Datacenter class servers should not be tested with this test kit.

The HAL test 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.


HAL Test Assertions

This section contains the detailed list of test assertions.

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.

[New - v.0.5] This includes when the performance counter is read over a short interval as well as a long one. The tolerance is +- 10%.

Reference document: TBD
Test description: TD-26.1 KeQueryPerformanceCounter Test Description

26.1.2 The value returned by KeQueryPerformanceCounter cannot decrease.

[New - v.0.5]

Reference document: TBD
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.

[New - v.0.5]

Reference document: TBD
Test description: TD-26.2 KeStallExecutionProcessor Test Description

26.2.2 KeStallExecutionProcessor must stall for a reasonable amount of time.

[New - v.0.5] KeStallExecutionProcessor must return within 200% of the time intended for the stall.

Reference document: TBD
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.

[New - v.0.5]

Reference document: TBD
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.

[New - v.0.5]

Reference document: TBD
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 HalStartProfileInterrupt must start the recurring profile interrupt.

[New - v.0.5]

Reference document: TBD
Test description: TD-26.4 HalSetProfileInterval Test Description

26.4.2 HalStopProfileInterrupt must stop the recurring profile interrupt.

[New - v.0.5]

Reference document: TBD
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.

[New - v.0.5]

Reference document: TBD
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.

[New - v.0.5]

Reference document: TBD
Test description: TD-26.4 HalSetProfileInterval Test Description


DMA Test Assertions

DMA API Functionality 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.

26.5.1 DMA must transfer all length transfers, from any address to any address, using both scatter-gather lists and individual mapped transfers.

[New - v.0.5]

Reference document: TBD
Test description: TD-26.5 DMA Test Description


DMA Stress Test Assertions

26.6.1 The DMA must have the ability to queue requests for scatter gather and manage access to several adapters at once.

[New - v.0.5]

Reference document: TBD
Test description: TD-26.6 DMA Stress Test Description


HAL Test Descriptions

This section contains the detailed test descriptions.

TD-26.1 KeQueryPerformanceCounter Test Description

[New - v.0.5]

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

Results Interpretation

TBD


TD-26.2 KeStallExecutionProcessor Test Description

[New - v.0.5]

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

Results Interpretation

TBD


TD-26.3 HalSetTimeIncrement Test Description

[New - v.0.5]

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

Results Interpretation

TBD


TD-26.4 HalSetProfileInterval Test Description

[New - v.0.5]

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

Results Interpretation

TBD


TD-26.5 DMA Test Description

[New - v.0.5]

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

Results Interpretation

< TBD >


TD-26.6 DMA Stress Test Description

[New - v.0.5]

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

Required Software

Windows 2000 Datacenter

Results Interpretation

TBD


Chapter 27: Windows Sockets Direct Test Specification

Draft Version: 0.7 — Date: February 12, 2001

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.

The NDIS test kit can be obtained separately from: http://www.microsoft.com/hwtest/testkits.


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:[CLARIFIED v.0.7] 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:[CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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: [CLARIFIED v.0.7] 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.

Also each machine must have at least one Ethernet adapter, which is used for control message exchange between machines.

NOTE: The following tests have to be run 4 times, once for each of the following configurations:

OS/WSD VC Type | Number of Processors
Free | 1
Debug/Checked with gflags and driver verifier enabled on WSD VCs and selected Microsoft components. Tests will enable these settings automatically. | 1
Free | 2 or more
Debug/Checked with gflags and driver verifier enabled on WSD VCs and selected Microsoft components. Tests will enable these settings automatically. | 2 or more


TD-27.1 Basic Connectivity Test Description (Wsdping.exe)

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.

Setup

Required Hardware

Two server class machines, each machine should have at least one SAN interface.

Test Execution

On Machine A, from command prompt:

wsdping_bascon_s.wsf

On Machine B, from command prompt, launch 5 instances of the following command:

wsdping_bascon_c.wsf

Expected execution time: 10 minutes

Results Interpretation

Server and all clients should complete without any failures, in the expected execution time. Review the test results in the generated log files (final_wsdping_bascon_s.log and final_wsdping_bascon_c.log) for specific details.

Exact Pass/Fail String:

WSD_PASS/WSD_FAIL


TD-27.2 Large Message Pings Test Description (Wsdping.exe)

Overview

WSDPing clients connect to the server and do 64K send()s to the Wsdping server. Clients then wait for replies from the server, if connection cannot be established over WSD Path or a reply is not received from the server in the specified time, the client reports a failure.

Setup

Required Hardware

Two server class machines, each machine should have at least one SAN interface.

Test Execution

On Machine A, from command prompt:

wsdping_lmpingmm_s.wsf

On Machine B, from command prompt, launch 50 instances of the following command:

wsdping_lmpingmm_c.wsf

Expected execution time: 360 minutes

Results Interpretation

Server and all clients should complete without any failures, in the expected execution time. Review the test results in the generated log files (final_wsdping_lmpingmm_s.log and final_wsdping_lmpingmm_c.log) for specific details.

Exact Pass/Fail String:

WSD_PASS/WSD_FAIL


TD-27.3 Send Sizes and Data Verification Test Description (Wsdping.exe)

Overview

In this test, Wsdping client does send()s of different sizes, starting from 0 bytes going up to 1MB. It also verifies that the data echoed back by the Wsdping server is the same as what was sent by the client.

Setup

Required Hardware

Two server class machines, each machine should have at least one SAN interface.

Test Execution

On Machine A, from command prompt:

wsdping_incsizedv_s.wsf

On Machine B, from command prompt:

wsdping_incsizedv_c.wsf

Expected execution time: 360 minutes

Results Interpretation

Server and all clients should complete without any failures, in the expected execution time. Review the test results in the generated log files (final_wsdping_incsizedv_s.log and final_wsdping_incsizedv_c.log) for specific details.

Exact Pass/Fail String:

WSD_PASS/WSD_FAIL


TD-27.4 WSD Service Provider Functional Tests

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

Two server class machines, each machine should have at least one SAN interface.

Test Execution

On Machine A, at the command prompt:

hapi_s.wsf

On Machine B, at the command prompt:

hapi_c.wsf

Expected execution time: 300 minutes

Results Interpretation

Server side results will be on Machine A and client side results on Machine B, under

<WSDHCTKIT Dir>\<BuildType>\hapilogs\%PROCESSOR_ARCHITECTURE%

  1. Copy all *.log files from these two locations to a single directory.
  2. Run "hapisum2.exe *.log" in the directory with all results. This will prepare a summary of results in Hapi.sum file.

Server and all clients should complete with 100% Pass Rate, in the expected execution time. Review the test results in the generated log files (Sfinal_hapi_s.log and final_hapi_c.log) for specific details.

Exact Pass/Fail String:

WSD_PASS/WSD_FAIL


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

Two server class machines, each machine should have at least one SAN interface.

Test Execution

On Machine A, at the command prompt:

pingpong_latency_s.wsf

On Machine B, at the command prompt:

pingpong_latency_c.wsf

Expected execution time: 5 minutes

Results Interpretation

Average latency as reported by the client should be less than 250 microseconds. Review the test results in the generated log files (final_pingpong_latency_s.log and final_pingpong_latency_c.log) for specific details.

Exact Pass/Fail String:

WSD_PASS/WSD_FAIL


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

Two server class machines, each machine should have at least one SAN interface.

Test Execution

On Machine A, at the command prompt:

verif_dataverify_s.wsf

On Machine B, at the command prompt:

verify_dataverify_c.wsf

Expected execution time: 45 minutes

Results Interpretation

Review the test results in the generated log files (final_verif_dataverify_s.log and final_verify_dataverify_c.log) for specific details. Verify that the client reports no data mismatch errors.

Exact Pass/Fail String:

WSD_PASS/WSD_FAIL


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

Two server class machines, each machine should have at least one SAN interface.

Test Execution

On Machine A, at the command prompt:

sockdie_dataverify_s.wsf

On Machine B, at the command prompt:

sockdie_dataverify_c.wsf

Expected execution time: 720 minutes

Results Interpretation

Review the test results in the generated log files (final_sockdie_dataverify_s.log and final_sockdie_dataverify_c.log) for specific details. Verify that the client does not report any data mismatch errors.

Exact Pass/Fail String:

WSD_PASS/WSD_FAIL


TD-27.8 Small Message Throughput Test

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

Two server class machines, each machine should have at least one SAN interface.

Test Execution

On Machine A, at the command prompt:

sockdie_smtput_s.wsf

On Machine B, at the command prompt:

sockdie_smtput_c.wsf

Expected execution time: 720 minutes

Results Interpretation

Average Throughput reported by the server at the end of a 12 hours run should be at least 25 Mbytes/Sec. Review the test results in the generated log files (final_sockdie_smtput_s.log and final_sockdie_smtput_c.log) for specific details..

Exact Pass/Fail String:

WSD_PASS/WSD_FAIL


TD-27.9 Large Message Throughput Test Description

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 (-c command line option) 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

Two server class machines, each machine should have at least one SAN interface.

Test Execution

On Machine A, at the command prompt:

sockdie_lmtput_s.wsf

On Machine B, at the command prompt:

sockdie_lmtput_c.wsf

Expected execution time: 720 minutes

Results Interpretation

Average Throughput reported by the server at the end of a 12 hours run should be at least 80 Mbytes/Sec. Review the test results in the generated log files (final_sockdie_lmtput_s.log and final_sockdie_lmtput_c.log) for specific details.

Exact Pass/Fail String:

WSD_PASS/WSD_FAIL


TD-27.10 Maximum Connections Per Second Test Description

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

Two server class machines, each machine should have at least one SAN interface.

Test Execution

On Machine A, at the command prompt:

sockdie_maxcps_s.wsf

On Machine B, at the command prompt:

sockdie_maxcps_c.wsf

Expected execution time: 720 minutes

Results Interpretation

Average Connections/Sec as reported by the server at the end of the test run should be at least 50 Connections/Sec. Review the test results in the generated log files (final_sockdie_maxcps_s.log and final_sockdie_maxcps_c.log) for specific details.

Exact Pass/Fail String:

WSD_PASS/WSD_FAIL


TD-27.11 Transmit File Stress with Socket Reuse Test Description

Overview

The server uses TransmitFile() with TF_REUSE_SOCKET to send data

Setup

Required Hardware

Two server class machines, each machine should have at least one SAN interface.

Test Execution

On Machine A, at the command prompt:

sockdie_txfile_s.wsf

On Machine B, at the command prompt:

sockdie_txfile_c.wsf

Expected execution time: 720 minutes

Results Interpretation

The test must run with 12 hours of uninterrupted runtime. Review the test results in the generated log files (final_sockdie_txfile_s.log and final_sockdie_txfile_c.log) for specific details.

Exact Pass/Fail String:

WSD_PASS/WSD_FAIL


TD-27.12 Nonblocking Winsock API Stress Test Description (Nblocks.exe)

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

Two server class machines, each machine should have at least one SAN interface.

Test Execution

On Machine A, at the command prompt:

nblocks_nonblocking_s.wsf

On Machine B, at the command prompt:

sockdie_nonblocking_c.wsf

Expected execution time: 720 minutes

Results Interpretation

The test must run with 12 hours of uninterrupted runtime. Review the test results in the generated log files (final_nblocks_nonblocking_s.log and final_sockdie_nonblocking_c.log) for specific details.

Exact Pass/Fail String:

WSD_PASS/WSD_FAIL


TD-27.13 Socket Duplication Stress Test Description (Wsclonec.exe)

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

Two server class machines, each machine should have at least one SAN interface.

Test Execution

On Machine A, at the command prompt:

sockdie_duplication_s.wsf

On Machine B, at the command prompt:

wsclonec_duplication_c.wsf

Expected execution time: 720 minutes

Results Interpretation

The test must run with 12 hours of uninterrupted runtime. Review the test results in the generated log files (final_sockdie_duplication_s.log and final_wsclonec_duplication_c.log) for specific details.

Exact Pass/Fail String:

WSD_PASS/WSD_FAIL


Chapter 28: Storage Test Specification

Draft Version: 0.7 — Date: February 12, 2001

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.


Reference Documents for Storage Test Assertions

[CLARIFIED v.0.5a]

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.pcdesguide.org/library/

Small Computer Interface (SCSI-2)

[X3.131:1994] standard
Global Engineering Documents at http://global.ihs.com/


Storage Test Assertions

This section contains the detailed list of test assertions for storage devices and drivers.

IDE DMA Test Assertions

[CLARIFIED - v.0.5a - Add references]

Assertions in this section are tested in TD-28.1 IDE DMA Test Description

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 IDE DMA Test Description

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 IDE DMA Test Description

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 IDE DMA Test Description

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 IDE DMA Test Description


General Storage Device Manual Test Assertions

Assertions in this section are tested in TD-28.2 General Storage Device Manual Test Checklist Test Description.

28.2.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-28.2 General Storage Device Manual Test Checklist Test Description

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

[CLARIFIED - v.0.5a]

Reference document: WLP#- B10.3.4.5.1; PC2001 - SCSI-0108; SDG3:163
Test description: TD-28.2 General Storage Device Manual Test Checklist Test Description

28.2.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-28.2 General Storage Device Manual Test Checklist Test Description

28.2.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-28.2 General Storage Device Manual Test Checklist Test Description

28.2.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-28.2 General Storage Device Manual Test Checklist Test Description

28.2.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-28.2 General Storage Device Manual Test Checklist Test Description

28.2.7 Option ROM supports virtual DMA services

Reference document: WLP#- B10.3.4.5.8; PC2001 - SCSI-0104; SDG3:146
Test description: TD-28.2 General Storage Device Manual Test Checklist Test Description


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

28.3.3 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-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 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-28.4 CD/DVD Driver Manual Test Checklist

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 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-28.4 CD/DVD Driver Manual Test Checklist

28.4.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-28.4 CD/DVD Driver Manual Test Checklist

28.4.4 DVD drive supports MMC-2

Reference document: WLP#- B10.5.4.3.2; PC2001 - STOR-0361; SDG3:192
Test description: TD-28.4 CD/DVD Driver Manual Test Checklist

28.4.5 DVD drive supports defect management

Reference document: WLP#- B10.5.4.3.2; PC2001 - STOR-0361; SDG3:192
Test description: TD-28.4 CD/DVD Driver Manual Test Checklist


Tape Drive Manual Assertions

Assertions in this section are tested in TD-28.5 Tape Drive Manual Test Checklist Test Description.

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

Reference document: WLP#- B10.5.4.3.2
Test description: TD-28.5 Tape Drive Manual Test Checklist Test Description

28.5.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-28.5 Tape Drive Manual Test Checklist Test Description

28.5.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-28.5 Tape Drive Manual Test Checklist Test Description

28.5.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-28.5 Tape Drive Manual Test Checklist Test Description


Media Changer Devices Manual Assertions

Assertions in this section are tested in TD-28.6 Media Changer Manual Test Checklist Test Description.

28.6.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-28.6 Media Changer Manual Test Checklist Test Description

28.6.2 SCSI tape changer and driver support auto-configuration

Reference document: WLP#- B10.8.4.2; SDG3:200
Test description: TD-28.6 Media Changer Manual Test Checklist Test Description

28.6.3 SCSI tape and optical disk changer support auto-configuration

Reference document: WLP#- B10.8.4.3; SDG3:201
Test description: TD-28.6 Media Changer Manual Test Checklist Test Description


RAID Manual Test Assertions

Assertions in this section are tested in TD-28.7 RAID Manual Test Checklist Test Description.

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

[CLARIFIED - v.0.5a]

Reference document: WLP#- B10.9.4.1
Test description: TD-28.7 RAID Manual Test Checklist Test Description

28.7.2 RAID supports include notification of failed drive

Reference document: WLP#- B10.9.4.3; SDG3:219
Test description: TD-28.7 RAID Manual Test Checklist Test Description

28.7.3 RAID subsystem supports automatic replacement of failed drive

Reference document: WLP#- B10.9.4.4; SDG3:220
Test description: TD-28.7 RAID Manual Test Checklist Test Description

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

Reference document: WLP#- B10.9.4.5; SDG3:221
Test description: TD-28.7 RAID Manual Test Checklist Test Description


Network Device Manual Test Assertions

WHQL Test Specification

Previous Next

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

[CORRECTED v.0.5a]

28.8.5 DELETED

[CORRECTED v.0.5a]

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


WHQL Test For CD-R(W) Using IMAPI Test Assertions

Assertions in this section are tested in TD-28.9 WHQL Test For CD-R(W) Using IMAPI Test Tool Description.

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: SFF 8090 (Mt. Fuji) specification, page 225 to 261; SFF 8090 (Mt. Fuji) v5 MMC specification, page 202
Test description: TD-28.9 WHQL Test For CD-R(W) Using IMAPI Test Tool Description

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: SFF 8090 (Mt. Fuji) specification, page 225 to 261; SFF 8090 (Mt. Fuji) v5 MMC specification, page 202
Test description: TD-28.9 WHQL Test For CD-R(W) Using IMAPI Test Tool Description

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: SFF 8090 (Mt. Fuji) specification, page 225 to 261; SFF 8090 (Mt. Fuji) v5 MMC specification, page 202
Test description: TD-28.9 WHQL Test For CD-R(W) Using IMAPI Test Tool Description

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: SFF 8090 (Mt. Fuji) specification, page 225 to 261; SFF 8090 (Mt. Fuji) v5 MMC specification, page 202
Test description: TD-28.9 WHQL Test For CD-R(W) Using IMAPI Test Tool Description

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: SFF 8090 (Mt. Fuji) specification, page 225 to 261; SFF 8090 (Mt. Fuji) v5 MMC specification, page 202
Test description: TD-28.9 WHQL Test For CD-R(W) Using IMAPI Test Tool Description

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: SFF 8090 (Mt. Fuji) specification, page 225 to 261; SFF 8090 (Mt. Fuji) v5 MMC specification, page 202
Test description: TD-28.9 WHQL Test For CD-R(W) Using IMAPI Test Tool Description

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: SFF 8090 (Mt. Fuji) specification, page 225 to 261; SFF 8090 (Mt. Fuji) v5 MMC specification, page 202
Test description: TD-28.9 WHQL Test For CD-R(W) Using IMAPI Test Tool Description

28.9.8 CD-RW Driver must have Feature 0023h: Formattable

FORMAT UNIT: Erase a CD-RW.

Reference document: SFF 8090 (Mt. Fuji) v5 MMC specification, page 202
Test description: TD-28.9 WHQL Test For CD-R(W) Using IMAPI Test Tool Description

28.9.9 CD-RW Driver must have Feature 0026h: Restricted Overwrite

Not tested

Reference document: SFF 8090 (Mt. Fuji) v5 MMC specification, page 202
Test description: TD-28.9 WHQL Test For CD-R(W) Using IMAPI Test Tool Description

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: SFF 8090 (Mt. Fuji) specification, page 225 to 261; SFF 8090 (Mt. Fuji) v5 MMC specification, page 202
Test description: TD-28.9 WHQL Test For CD-R(W) Using IMAPI Test Tool Description

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: SFF 8090 (Mt. Fuji) specification, page 225 to 261; SFF 8090 (Mt. Fuji) v5 MMC specification, page 202
Test description: TD-28.9 WHQL Test For CD-R(W) Using IMAPI Test Tool Description

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: SFF 8090 (Mt. Fuji) specification, page 225 to 261; SFF 8090 (Mt. Fuji) v5 MMC specification, page 202
Test description: TD-28.9 WHQL Test For CD-R(W) Using IMAPI Test Tool Description


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 IDE DMA Test Description

Overview

DMATEST tests the ability of a driver to set a specified DMA (Direct Memory Access) Timing mode for a device. For all devices in the system, DMATEST will attempt 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 (default 20000 milliseconds) between variations. The test also runs multithreaded FILEIO in the background. FILEIO with copy from each available source to each valid destination, compare the copied data, and report passes or failures based on the compare function. Logging uses NTLOG.DLL if available or a built in logging routine.

The IDE DMA test is an Automated test designed to ensure that IDE storage drivers correctly time devices as specified by the user or the system. If the machine has a controller which supports ULTRADMA 3 or above, an 80 cable must be attached by the user to for accurate results.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.

A machine running Whistler must be configured with at least one IDE device to run. The test has no software dependencies, but will have a better formatted log if NTLOG.DLL is present. If a machine 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

All errors will be written into the log file, ‘DMATEST.LOG’ in the directory the test was run from.

SEV1 - UDMA3 or UDMA4 Not timed. This could be due to the controller not supporting UDMA3 or UDMA4

SEV2 - Data Corruption occurred during FILEIO and the device was timed to a lower timing mode

SEV3 - Transfermode 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:
  • Chapter 2 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:
  • Chapter 3 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":
  • Chapter 4 If UDMA5 and the controller does not support UDMA5 this is not a failure.
  • Chapter 5 If UDMA3 or 4 and the controller does not support UDMA3 or 4, this is not a failure
  • Chapter 6 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:
  • Chapter 7 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:
  • Chapter 8 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:
  • Chapter 9 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:
  • Chapter 10 If the file is in use, close the file and start again.
  • Chapter 11 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

WHQL Test Specification

Previous Next

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
28.3.3 | Hot-swappable drive offered for server systems includes a local disk drive replacement indicator


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 | CD device provides 8x minimum transfer rate or better performance
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
28.4.2 | DVD storage device Provides 2 MB per second minimum transfer rate or better performance anywhere on the disc
28.4.3 | DVD drive supports logical and physical CD formats
28.4.4 | DVD drive supports MMC-2
28.4.5 | Read/Write (the FAQ referenced specifies that this applies only to R/W DVD drives). DVD drive supports defect management


TD-28.5 Tape Drive Manual Test Checklist Test Description

Assertions in this section are tested by affirming the related capability in this checklist.

28.5.1 | ATAPI tape device supports the termination scheme defined in ATA/ATAPI-5
28.5.2 | Driver for tape device is integrated with Removable Storage Manager
28.5.3 | Single-backup tape device designed for Windows Server meets 10 GB minimum capacity requirements
28.5.4 | Single-backup tape device designed for Windows Advanced Server meets 20 GB minimum capacity requirements


TD-28.6 Media Changer Manual Test Checklist Test Description

Assertions in this section are tested by affirming the related capability in this checklist.

28.6.1 | CD changer device that supports 7 discs or less complies with MMC-2
28.6.2 | SCSI tape changer and driver support auto-configuration
28.6.3 | SCSI tape and optical disk changer support auto-configuration


TD-28.7 RAID Manual Test Checklist Test Description

Assertions in this section are tested by affirming the related capability in this checklist.

28.7.1 | All external SCSI connectors for RAID are labeled with ANSI approved icon for bus type
28.7.2 | RAID support includes notification of failed drive
28.7.3 | RAID subsystem supports automatic replacement of failed drive
28.7.4 | RAID subsystem supports manual replacement of failed drive


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 WHQL Test For CD-R(W) Using IMAPI Test Tool Description

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 testcase. 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 testcases. It then finds out the pointer to the testcase function, i.e. the function that performs the testcase, and then calls it. After finishing the testcase, 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. Testcases are separated by ";" tokens and are specified exactly the same way as if they are passed in as a single testcase. IMAPIMSTest will run one test by another in the file and gather the test PASSED and FAILED information for all these testcases.

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 testcase 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.

Testcase functions all have the same prototype, that is,

void function_name(void);

This makes the dispatching much easier. The functionality testcases 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 testcase 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 testcase 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 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.10 NTMS STRESS TEST Description

Overview

This test will do all NTMS operations that do not require any human intervention in a method and can run for a specified length of duration. The test will try to isolate classes of API calls to help identify problem areas. Stressing NTMS is very confusing because it is a slow system by nature. Since NTMS 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 NTMS requests repeatedly by acting as a bunch of rogue applications. It would be more pertinent to write small but meaningful NTMS "baby" applications - and swamp NTMS 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 NTMS handles contention. Stressing individual sub-components of NTMS is also important if such a thing is possible.

Each NTMS "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 NTMS. But putting lots of such scenarios together and running them from different threads at a time, will tend to stress NTMS. So the failure of the test is not the failure of a scenario, but it is failure of NTMS under the stressed situation.

Invocation

Stress.exe /L <log file> /n: [ipabc] /d <Duration of run> /h <Server Name> /s: [pw]

All the command line arguments are optional.

/L <Log file> : The file name for logging can be specified with this option.

The default Log File name is "stress.log".

/n [ipabc] : To specify logging levels.

I for TLS_INFO;

P for TLS_PASS;

A for TLS_ABORT;

B for TLS_BREAK;

C for TLS_CALLTREE;

Default value is : TLS_SEV3 | TLS_SEV2 | TLS_SEV1 | TLS_WARN | TLS_TEST | TLS_VARIATION | TLS_MONITOR;

/d < Duration of run >:

Duration of the total stress to run for. Default value is 8hrs.

/h <server name> : Name of the Remote NTMS server.

Default is the local machine.

/s :[pw] : NtLog style.

P for TLS_PROLOG;

W for TLS_WINDOW;

Default is TLS_REFRESH.

Scenario 1: Open and Close NTMS session.

This scenario consists of two simple NTMS 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 NTMS session;

Wait for some time; // Wait time can be varied across runs

Close the NTMS session;

Repeat the whole, until the end is signaled;

  • Scenario 1B:

Open N NTMS sessions; // Where N is a predetermined number, which can be varied across runs.

Wait for some time;

Close all opened NTMS 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 NTMS APIs, viz., EnumarateNtmsObject() and GetNtmsObjectInformation() . Here all possible NTMS 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 NTMS object)

{

Enumerate all NTMS 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 NTMS object)

{

Enumerate all NTMS 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 NTMS system and then deleted after a wait for some time. The NTMS APIs used significantly in this scenario are, EnumerateNtmsObject, CreateNtmsMediaPool() and DeleteNtmsMediaPool().The five sub-scenarios follow:

  • Scenario 3A:

Enumerate All possible NTMS Media Types in the current NTMS 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 NTMS Media Types in the current NTMS 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 NTMS Media Types in the current NTMS 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 NTMS 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 NTMS 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 NTMS Media.

The scenario will mount some NTMS 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 NTMS Database. The NTMS 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 NTMS APIs OpenNtmsNotification(), WaitForNtmsNotification() and CloseNtmsNotification(). Each scenario function will be, opening an NTMS notification channel for a particular type of NTMS 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 NTMS 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 NTMS 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 NTMS 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 NTMS system;

For (All objects in the NTMS system)

SetNtmsObjectAttribute for that object;

Wait for some time;

For (All objects in the NTMS system)

GetNtmsObjectAttribute for that object;

  • Scenario 11B:

Enumerate all the objects in the NTMS system;

For (All objects in the NTMS system)

SetNtmsObjectAttribute for that object;

Wait for some time;

For (All objects in the NTMS 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 NTMS 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(ies). 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. The server name can be specified on the command line.

Results Interpretation

TBD


Chapter 29: Headless Test Tool Test Specification

Draft Version: 0.7 — Date: February 12, 2001

Overview

Windows Whistler provides native support for "headless server" operation 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 Whistler.


Reference Documents for Headless Test Assertions

Extensions to VT100 Terminal Definition

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

Hardware Design Guide Version 3.0 for Microsoft Windows 2000 Server

http://www.microsoft.com/hwdev/serverdg.htm
(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/headless/


Headless Test Tool Test Assertions

This section contains the detailed list of test assertions.
Assertions are tested in TD-29.1 Headless Test Description.

[CLARIFIED - v.0.5a - added references]

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: SDG3:21.2; Serial Port Console Redirection Table
Test description: TD-29.1 Headless 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: SDG3:21.2; Extensions to the VT100 Terminal Definition
Test description: TD-29.1 Headless 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: SDG3:21.2; Extensions to the VT100 Terminal Definition
Test description: TD-29.1 Headless 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: SDG3:21.2; Extensions to the VT100 Terminal Definition
Test description: TD-29.1 Headless 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: SDG3:21.2; Extensions to the VT100 Terminal Definition
Test description: TD-29.1 Headless 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: SDG3:21.2; Extensions to the VT100 Terminal Definition
Test description: TD-29.1 Headless 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: SDG3:21.2; Extensions to the VT100 Terminal Definition
Test description: TD-29.1 Headless Test Description


Headless Test Tool Test Descriptions

This section contains the detailed test descriptions.

TD-29.1 Headless Test Description

Overview

This 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/Whistler).
  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: Data Center Server Test Specification

Expand all contracted text Show All

WHQL Test Specification

Previous Next

Chapter 30: Datacenter Server Test Specification

Draft Version: 0.7 — Date: February 12, 2001

Overview

The Datacenter Server system specification describes the hardware and software requirements for the validation process.

This test kit in intended for use on Windows 2000 Datacenter

Test Assertion Summary

This section presents the system configuration criteria for a Datacenter Server test system. Note that all components in this system must be logo’d to run on Windows 2000. Components that are not on the HCL must pass HCT tests prior to running Client Server Validation testing. This is because Client Server Validation testing is designed to test server requirements, not general Windows NT/2000 requirements.

Click to show or hide information. Datacenter Server Requirements for Client Server Validation

A Datacenter server must have:

  • 512-MB minimum system memory
  • Two additional disk drives separated from the system disk. These disk drives will be used for testing and must be on a separate disk bus then the system installation disk. These test drives must have must at least 10 GB of free space. We recommend using Hardware RAID stripe volumes for the data disks, with a minimum of five (5) disks per volume.
  • At least one 100 Mbit network card for connecting to the clients and the client master. The network card must be #PAE capable.
  • At least one 100 Mbit capable Full duplex Switch or Hub, to setup the network.
  • 2 GB free hard disk space on system installation drive is required.
  • The test system must have at least 8 processors.

Click to show or hide information. Client Requirements for Running Tests

Eight (8) client machines will be used to simulate client-server stress against the server. The eight required client systems cannot be used to test more than one server at a time. For each server system that 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:

  • Each client must be on the Windows NT/2000 HCL list.
  • Each client should have at least 64 MB of memory
  • Each client should be at least a Pentium equivalent or better machine. Microsoft recommends a client mix as close to your typical customers’ use as possible. Each client must use a network card that is listed on the HCL.
  • Each client must be able to communicate with the server over a 100 Mbit TCP/IP network.
  • The clients must be in the same domain as the server.
  • Each client must have Windows 2000 with Service Pack 1 installed.
  • 2 GB free hard disk space on system installation drive

An additional client will also be to serve as a launch platform and monitoring station for the tests. This client master should be separate from the clients used for client-server stress testing.

The client master must meet the following hardware and software requirements:

  • The client master is connected to the server and all eight clients through the TCP/IP network using a switching hub. The client master must have Windows 2000 Server installed.
  • 256-MB minimum system memory
  • Network card to connect to the server. This network should be 100 Mbits.
  • 2 GB free hard disk space on system installation drive

The client master is used to:

  • Provide a share point to start up the client tests on the other nodes.
  • Initiate the client-server tests, monitor the test status, shutdown the client-server tests and summarize the results.
  • Optionally serve as the kernel debugger for the server. This requires a free serial port. Please see documentation in the Windows 2000 device driver kit (DDK) for setting up a kernel debugger.

Figure 1. Standard Server Test configuration

Standard Server Test configuration

Figure 1.1 Gigabit Server Test configuration

Gigabit Server Test configuration

Figure 1.2 Segmented network Server Test configuration (disks not shown)

Segmented network Server Test configuration

Click to show or hide information. Network Requirements for Running Tests

The test will generate high network traffic doing client-server type of I/O. We recommend that all client systems and server system be on a private network.

The clients, client master and the server systems must all be a member of this same domain. We typically have our lab setup to have all machines logged on as the same domain account, which has administrator rights on each system.

The server will experience very high stress loads with file I/O, IIS queries, FTP queries and socket queries. This is done to simulate real world customer usage of high-end server configurations. The network stress loads however are probably higher than what any customer would normally utilize.

In addition to the standard network configuration in Figure 1, two alternative configurations are also possible for the test. Figure 1.1 is a gigabit network where the server has a gigabit net card and the switch is used as an uplink for the clients, and client master to the server.

Figure 1.2 is a segmented network where the clients are distributed between multiple network cards on the server. Both additional examples provide a means to allow for increased network bandwidth for higher stress loads. Notice in Figure 1.2 the client master as well as the server must be able to see all test networks.

Any of the mentioned examples may be used for submission.


Datacenter Server Test Assertions

This section contains the detailed list of test assertions.

Lrgfile Test Assertions

Assertions in this section are tested in TBD

30.1.1 TBD

Reference document: TBD
Test description: TBD


Datacenter Server Test Descriptions

The client-server tests can be broken down in the following type of tests:

  1. File I/O using a Server Message Block (SMB) share
  • Chapter 2 Lrgfile Test
  • Chapter 3 Mapfile Test
  • Chapter 4 Unbuf Test
  • Chapter 5 FsCmprsn Test
  • Chapter 6 FSSTRS_SRV\CLNT Client/Server Test
  2. Telephony Application Program Interface (TAPI) test
  • Chapter 7 Srvapp Test
  • Chapter 8 Tclient Test
  • Chapter 9 Clntapp Test
  3. Internet Information Server (IIS) tests
  • Chapter 10 Gqstress Test
  • Chapter 11 Ftpstress Test
  4. Winsock test
  • Chapter 12 Sock_Srv/Sock_Clnt Test
  5. Local server-based file system tests
  • Chapter 13 DTC_Bangfs Test
  • Chapter 14 DTC_Sqlio Test

These tests are designed to stress the most common server services that users will run on a high-end server system. By default, these tests will run for 14 days, as required for Datacenter validation, at which time the tests will shutdown. The tests log files will then be examined and summarized into one log file on the client master. This ‘summary’ log will later be used for submitting the results to WHQL. If the test kit fails the individual log files on the client and server systems can be examined 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 servers name or one of the associated IP addresses to access the server services. A GUI interface (valdclus.exe) will setup and configure the server as well as the client systems for the tests.


TD-30.1 Lrgfile Test Description

Overview

This test creates a large file and then reads backward and shrinks the file while checking read data.

Lrgfile uses unbuffered I/O only and retries on every file I/O operation.

The user will not be required to know the syntax of these test programs. The test launcher will start the test when it is run on each client node. If the server is set up using the well-known names that Microsoft provides, no further input will be required.

Setup

This section summarizes setup for both the hardware and software.

Before running the Client Server Validation Test:

  1. Set up the hardware as shown in Figure 1, 1.1 or 1.2 in this document.
  2. Install Windows 2000 Datacenter Server on the server system.
  3. Install FTP service – Optional: This test is not required
  4. Install Windows 2000 Server and the latest service pack on the client master.
  5. Install Windows 2000 Professional and the latest service pack on the eight client systems.
  6. Run the Client Server Validation test (Datacenter Server Test) from the client master system.

Results Interpretation

If LRGFILE test fails, look for LRGFILE.LOG log file. This file should contain error information and reason for failure. Since LRGFILE test is run with -Vn switch (leave n MB of free space on disk), common problem is that test did not start at all, because there was not enough space to start the test. LRGFILE 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 LRGFILE test locally on server. You can find LRGFILE.EXE in your HCT\TESTBIN directory or on HCT CD. Copy it on server node and run command from WINDOWS NT console.

    lrgfile -r10 -p32 -b8 -dX:

-r10 means run 10 times

-p32 means that LRGFILE will use 32*4 kB chunks of data for each write/read operation

-b8 means that LRGFILE will use 8 buffers for asynchronous write/read

-dX: replace X with suspected shared drive letter. Be sure that disk is online on the node that runs LRGFILE!

LRGFILE will grow temporary test until it consumes entire available disk space, than shrinks file back while checking data. DO NOT MOVE/FAILOVER DISK RESOURCE DURING THIS TEST. After LRGFILE finishes, look in the log file LRGFILE.LOG (in the same directory LRGFILE.EXE was run from) and search for data errors (e.g. Disk data error: Chunk#xpct 0x12, chunk#got 0x0, Page#=0). If you see this error your disk failed and is unreliable. If your disk passes this test, but does not pass node test with random moves/failovers, it point to the cache problem. If both tests pass but client test does not it points to the problem in redirector. Mostly, 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 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 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.

Setup

TBD

Required Hardware

TBD

Required Software

TBD

Results Interpretation

Mapfile test requires 4 MB of space on tested drive. If there is not enough space, Mapfile exits. Another common problem is a network failure. If test fails because of data corruption problem (read data differs from expected), the cause is not easy to determine. Mostly, 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. See LRGFILE Results Interpretation paragraph how to eliminate disk-media problem.


TD-30.3 Unbuf Test Description

Overview

UnbufW is an Async IO stress test. It performs asynchronous writes and reads in various combinations in attempt to stress parts of the async IO system. This test uses completion ports to perform the async IO.

The different variables for test combinations include:

  • buffered/unbuffered IO
  • pre-allocated disk space/new file
  • extending existing file/over writing existing file
  • size of the target file
  • number of concurrent io threads
  • size of each IO

Setup

TBD

Required Hardware

TBD

Required Software

TBD

Results Interpretation

The IO's are 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 the state of the system can be examined by a file system guru. In the HCT kit this feature is disable and errors are simply logged.


TD-30.4 FsCmprsn Test Description

Overview

The fscmprsn test (i.e. file system compression test) is a stress test written to exercise the NTFS compression engine. This test can also run on FAT and other file systems, but that is less interesting.

To exercise NTFS compression the test performs the following algorithm:

1. Walks the specified <srcDirectory> (tree)

2. Insert the contents of readable files into fscmprsn.dat. This insert begins at the end of the file +/- some randomly chosen delta. In this manner it grows the file, by default, up to 5M.

3. Verify the contents of the file. It does this by reconstructing the files contents in sections and then comparing.

4. Toggle the file's compression state

5. Repeat 3, then 4, then 3.

6. Delete fscmprsn.dat

7. Continue at 1, (at the next file) until 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 is engineered to ignore files that cannot be opened shared for read access.

The nature of this stress test is to deliberately force NTFS to handle writes in the middle of a compressed file as well as extending and truncating an existing compressed file.

Setup

TBD

Required Hardware

TBD

Required Software

TBD

Results Interpretation

Errors are logged and optionally the test can force a break into the debugger so that a file system guru can examine the state.


TD-30.5 FSSTRS_SRV\CLNT Client/Server Test Description

Overview

The test creates a hierarchy of directories and files under a given path. The user 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

TBD

Required Hardware

TBD

Required Software

TBD

Results Interpretation

TBD


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

TBD

Required Hardware

TBD

Required Software

TBD

Results Interpretation

TBD


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

TBD

Required Hardware

TBD

Required Software

TBD

Results Interpretation

TBD


TD-30.8 Clntapp Test Description

Overview

Clntapp 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

TBD

Required Hardware

TBD

Required Software

TBD

Results Interpretation

TBD


TD-30.9 Gqstress Test Description

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

TBD

Required Hardware

TBD

Required Software

TBD

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

Overview

This test is not required for Datacenter Server testing (Optional).

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

TBD

Required Hardware

TBD

Required Software

TBD

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 2000 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

TBD

Required Hardware

TBD

Required Software

TBD

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 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.


TD-30.12 DTC_Bangfs Test Description

Overview

This file system stress test does random fsctl tests on multiple files. The test is configured to create 100 files, 100 streams and 100 hardlinks and perform 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 ands restart over.

Setup

TBD

Required Hardware

TBD

Required Software

TBD

Results Interpretation

The test may find a system bug in which case it will bluescreen the machine or cause may cause asserts to fire on a checked build. Please follow general bluescreen debugging procedures to debug any system crashes.


TD-30.13 DTC_Sqlio Test Description

Overview

This file system stress test tries to simulate the activity of a SQL server on the local file system. The test first uses dtc_rapidfile.exe to create 2 files of size 2gb each that serve as the database. After the data files are created and verified, the dtc_sqlio.exe is launched and it spawns multiple threads that do random async unbuffered 16kb 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

TBD

Required Hardware

TBD

Required Software

TBD

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.


Glossary

#

2-D

two-dimensional

3-D

three-dimensional

4GT

4 GB RAM Tuning

8-VSB

ATSC 8-Vestigial Side Band

A

AA

See anti-aliasing

AAC

Advanced Audio Codec

ABP

Address Book Provider

ABR

available bit rate

AC

alternating current

AC-3

An audio standard developed by Dolby Laboratories for delivering 5.1 audio. This system compresses six channels of digital audio into 384 Kbps versus 4 Mbps uncompressed.

AC '97

Audio Codec '97

ACK

acknowledgment signal

ACL

access control list

ACP

Acronym for the ANSI Codepage in use. Microsoft Windows NT uses this codepage to convert to/from Unicode automatically whenever an application calls one of the 'A' entry points.

ACPI

See Advanced Configuration and Power Interface.

ACPI hardware

Computer hardware with the features necessary to support operating system power management and with the interfaces to those features described using the Description Tables as specified in Advanced Configuration and Power Interface Specification

ACPI Name Space

A hierarchical tree structure in operating system controlled memory that contains named objects. These objects can be data objects, control method objects, bus and device package objects, and so on. All the information in the ACPI Name Space comes from the Differentiated System Description Table.

ACS

Admission Control Service

Active Device

A device that is powered and is not in the Suspend state.

Active Directory

Provides the ability to build applications that give a single point of access to multiple directories in a network environment, whether those directories are LDAP, NDS, or NTDS based directories.

A/D

analog-to-digital

adapter

See device.

ADC

analog-to-digital converter

add-on devices

Devices that are traditionally added to the base PC system to increase functionality, such as audio, networking, graphics, SCSI controller, and so on. Add-on devices fall into two categories: devices built onto the system board and devices on expansion cards added to the system through a system board connector such as PCI.

ADF

Automatic Document Feeder

ADO

ActiveX Data Objects

ADPCM

Adaptive Differential Pulse Code Modulation. An encoding format for storing audio information in a digital format.

ADSI

Active Directory Service Interfaces

ADSL

Asymmetric Digital Subscriber Line. A method for moving data over regular phone lines. An ADSL circuit is much faster than a regular phone connection, and the wires coming into the subscriber’s premises are the same (copper) wires used for regular phone service.

ADT

attribute definition table

Advanced Configuration and Power Interface (ACPI)

A specification that defines an interface to the system board that enables the operating system to implement operating system directed–power management and system configuration. Following the ACPI allows system manufacturers to build systems consistent with the OnNow design initiative for instantly available PCs.

Advanced Power Management (APM)

A software interface (defined by Microsoft and Intel) between hardware-specific power management software (such as that located in a system BIOS) and an operating system power management driver.

advertisement

Where files are shown on a client machine as being available, but are not actually installed. They are available to the client machine through the network.

AEC

acoustic echo cancellation

agent

Software that runs on a client computer for use by administrative software running on a server. Agents are typically used to support administrative actions, such as detecting system information or running services.

AGP

Accelerated Graphics Port – A high performance, component level interconnect, targeted at 3D graphical display applications and based on a set of performance extensions or enhancements to PCI.

AGP system memory

See Non-local memory.

algorithm

In compression software, refers to a specific formula used to compress or decompress video or other data.

alpha blending

Alpha or transparency blending attempts to approximate the way transparent and translucent surfaces distort light rays.

AMA

active member address, also AM_ADDR

AML

ACPI Machine Language. Pseudocode for a virtual machine supported by an ACPI-compatible operating system and in which ACPI control methods are written. The AML encoding definition is provided in section 16 of the Advanced Configuration and Power Interface Specification.

AMR

audio modem riser

analog

A method of signal representation by an infinitely smooth universe of numeric values. Measurements that are characterized as analog include readings of voltage and current. Compare with digital.

analog video

A video signal that represents an infinite number of smooth gradations between given video levels. Compare with digital video.

anamorphic

Unequally scaled in vertical and horizontal dimensions.

ANSI

1. American National Standards Institute. A standards-setting, non-governmental organization that develops and publishes standards for voluntary use in the United States.

2. The Microsoft Windows ANSI character set, essentially ISO 8859/x plus additional characters, which was originally based on an ANSI draft standard. MS-DOS uses the ANSI character set if ANSI.SYS is installed.

anti-aliasing (AA)

A form of interpolation used in graphics display technology when combining images; pixels along the transitions between images are averaged to provide a smooth transition.

AOAC

always on/always connected

AP

access point

A/PC

Auto PC

APC

asynchronous procedure call

API

Application programming interface. A set of routines that an applications program uses to request and carry out lower-level services performed by a computer operating system.

APIC

Advanced Programmable Interrupt Controller

APIPA

automatic programmable IP addressing

APM

See Advanced Power Management.

appliance

Single- or limited-purpose device, with simple consumer appliance-like functionality.

appliance server

A relatively low-cost computing device used for specific tasks, including Internet connectivity and file and print. Does not have the full capabilities or software of a typical server that is sold for general-purpose office use, but has and extremely high ease-of-use associated with it.

APS

analog protection system

AR_ADDR

Access Request Address

arbitrator

1. A software module in Windows that handles the allocation of hardware resources among devices.

2. Under Windows 95, the Plug and Play device driver responsible for allocating a specific resource among all drivers that require the resource. For example, VDMAD is a DMA-channel arbitrator, and VPICD has services for allocating IRQ lines. Windows 95 provides arbitrators for standard I/O, memory, hardware interrupt, and DMA-channel resources.

ARC

Advanced RISC Computing

architecture

A general term referring to the structure of all or part of a computer system. Also refers to the design of system software, such as the operating system, as well as referring to the combination of hardware and basic software that links machines on a computer network.

ARGB

alpha red, green, blue

ARMD

ATAPI Removable Media BIOS Specification

ARP

Address Resolution Protocol

artifact

An unintended, unwanted visual aberration 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 DOS. ASCII, the US national variant of ISO 646, is a 7-bit character set encoding that contains characters for upper and lowercase English, American English punctuation, base 10 numbers, and a few control characters. Although very primitive, it's important to note that ASCII’s set of 128 characters is the one common denominator contained in all the other common character sets.

ASF

Advanced Streaming Format

ASIC

application-specific integrated circuit

ASL

ACPI Source Language. The programming-language equivalent for AML. ASL is compiled into AML images. The ASL statements are defined in section 15 of the Advanced Configuration and Power Interface Specification.

ASP

active server pages

aspect ratio

The relationship of width and height. When an image is displayed on different screens, the aspect ratio must be kept the same to avoid either vertical or horizontal stretching.

ASPI

Advanced SCSI Programming Interface

assertion

An assertion is a truth statement declaration of a feature criterion that extracts the precise requirement(s) from a source document’s text. Assertions are derived from all pertinent documents such as design guides, industry specifications, and industry standards documents. Assertions include criteria that are both testable and non-testable. The set of assertions forms an interpretation of the source document. See also Test Assertion.

assigned configuration

Drivers examine this portion of the device node to determine which resources have been allocated for the device. For Plug and Play cards, the assigned resources for a device can change dynamically or from one system start-up to the next.

ASSP

Application-specific Standard Protocol

ASVD

analog simultaneous voice/data

asymmetrical compression

A system that requires more processing capability to compress than to decompress an image. It is typically used for the mass distribution of programs on media such as CD-ROM, where significant expense can be incurred for the production and compression of the program, but the playback system must be low cost. Compare with symmetrical compression.

asynchronous

An operation that proceeds independent of any timing mechanism, such as a clock. Compare with synchronous.

AT

IBM registered trademark for PC/AT

AT#UD

Unimodem Diagnostics Command

ATA

AT Attachment. More commonly known as IDE. ATA defines the physical, electrical, transport and command protocols for the internal attachment of storage devices. A compatible register set, and a 40-pin connector and its associated signals. An integrated bus usually used between host processors and disk drives.

ATAPI

ATA Packet Interface. A device implementing the Packet Command feature set. A hardware and software specification that documents the interface between a host computer and CD-ROM drives using the ATA bus.

ATM

Asynchronous transfer mode. A transmission protocol that segments user traffic into small, fixed-size units called cells, which 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

DSL termination at CO, also DSLAM

ATU-R

DSL termination at user side, also DSL modem

ATVEF

Advanced Television Enhancement Forum

audio class

The class of filters that deals with pulse code modulation or similar digitized data or analog signals. A WDM audio minidriver provides support for audio devices under the WDM digital audio architecture.

Audio Compression Manager (ACM)

A device-driver manager that controls which applications are required in order to play or record sounds. ACM manages the following types of drivers: compressor and decompressor (codec) drivers, format converter drivers, and filter drivers. If a source file was created on a computer that was not running Windows, it cannot use an ACM codec and thus cannot be used by Windows Media Technologies.

audio mixing

The method of combining multiple streams of audio data into a single stream through some method such as addition and clipping.

AUI

Attachment Unit Interface. The portion of the Ethernet standard that specifies how a cable is to be connected to an Ethernet card. AUI specifies a cable connected to a transceiver that plugs into a 15-pin socket on the network adapter.

authentication

The process of validating a user.

authorization

The process of granting or denying access to protected resources.

A/V

audio/video

AVD

alternating voice/data

AVGA

Advanced VGA

AVHDD

A/V Hard Disk Drive

AVI

Audio Video Interleaved

B

B2B

Business to business

B2C

business to consumer

B2E

business to employee

bandwidth

The data transfer capacity of a digital communications system, such as the Internet or a local area network (LAN). Bandwidth is usually expressed in the number of bits that a system is capable of transferring in a second: bits per second (bps) or kilobits per second (Kbps).

BAR

base address register

base character

One or more of:

  • A character that has meaning independent of other characters.
  • Any graphical character that is not a diacritic.
  • Any graphical character that is not, itself, a diacritic.

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. Most Arabic, Hebrew, Farsi and Urdu characters, for example, are read from right to left, but numbers and quoted Western terms within these languages' text are read from left to right.

bilinear textures

A texture-mapping technique that averages the colors of surrounding texels to determine the texture color.

BIOS

Basic input/output system. A set of routines that works closely with the hardware to support the transfer of information between elements of the system, such as memory, disks, and the monitor. Although critical to performance, the BIOS is usually invisible to the end user; however, programmers can access it.

BIOS enumerator

Responsible in a non-ACPI Plug and Play system for identifying all hardware devices on the motherboard of the computer. The BIOS supports an API that allows all Plug and Play computers to be queried in a common manner.

BIS

Boot Integrity Services

bit map

Representation of characters or graphics by individual pixels 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).

bit mapped graphics

Images created with matrices of pixels or dots. Also raster graphics.

bit rate

1. The speed at which digital content in general is streamed 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 can move across a network. It usually is measured in kilobits per second (Kbps).

bit specifications

Number of colors or levels of gray that can be displayed at one time. Controlled by the amount of memory in the computer’s graphics controller card. An 8-bit controller can display 256 colors or levels of gray; a 16-bit controller, 64,000 colors; and a 24-bit controller, 16.8 million colors.

BizTalk

1. Framework based on XML schemas and industry standards for sharing information.

2. Microsoft BizTalk Server 2000 technology, which supports Internet application integration via XML.

Blackcomb

Code name for the version of the operating system after Windows "Whistler," based on Windows NT technology.

blackpoint

A device's blackpoint is the input level where the device just begins to show color output.

blt

block transfer

Bluetooth

Bluetooth wireless technology. A wireless LAN that used spread spectrum technology (low-power frequency hopping) in the 2.4 GHz band.

BNC

Bayonet Nut Connector (Also British Naval Connector or Bayonet Neil Consulman)

BOOTP

Boot Protocol

Bottom up (order)

Arrangement of pixel data in memory with the lowest addressed pixels corresponding to the lower left corner of the image, proceeding to the right with increasing memory address, with the highest addressed pixels corresponding to the upper right corner of the image.

BPB

BIOS Parameter Blocks

BPC

Broadcast PC

bpp

Bits per pixel. The number of bits used to 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, representing its gray value from black to white.

broadband

A high-speed transmission. The term generally refers to 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.

BTS

Microsoft BizTalk Server

buffer

A reserved portion of memory in which data is temporarily held pending an opportunity to complete its transfer to or from a storage device or another location in memory.

bulk transfer

Bulk transfers are non-periodic, large bursty communication typically used for a transfer that can One of the four USB transfer types. Uses any available bandwidth and can also be delayed until bandwidth is available.

bus compliance

A device is in bus compliance with a bus specification when it implements all functional, protocol, electrical, and mechanical aspects explicitly stated in that specification.

bus enumerator

In a Plug and Play system, a bus device driver that detects devices located on a specific bus and loads information about devices into the hardware tree.

BW

bandwidth

C

C#

Old name for ADE (from C++)

CA

certificate authority

C2

A security class of the Department of Defense Trusted Computer System Evaluation Criteria (DOD 4200.28.STD)

cache

A special memory subsystem in which frequently used data values are duplicated for quick access.

CAD

computer-aided design

CAL

channel abstraction layer

calibration

Calibrating a device means to cause it to behave in a known manner. Characterization is a necessary prelude to calibration.

CAM

Common Access Method

CAP

Carrier less Amplitude/Phase modulation

CAPI

Communications API

CAPP

Controlled Access Protection Profile

Card Services

Under Windows 95, a protected-mode system component that is a VxD linked with the PCMCIA bus driver. Card Services passes the event notification from socket services to the PCMCIA bus driver, provides information from the computer’s cards to the PCMCIA bus driver, and sets up the configuration for cards in the adapter sockets.

CBQ

class-based queuing

CBR

constant bit rate

CBT

computer-based training

CCITT

Comite Consultatif Internationale de Telegraphie et Telephonie (Consultative Committee for International Telephone and Telegraph). An international standards organization dedicated to creating communications protocols that will enable global compatibility for the transmission of voice, data, and video across all computing and telecommunications equipment.

CCP

Compression Control Protocol

CD

compact disc

CDB

command descriptor blocks

CDC

communications class device

CDFS

CD-ROM File System

CD-I

compact disk-interactive

CDM

Common Diagnostic Model

CDMA

Code Division Multiple Access

CDO

Collaboration Data Objects

CDPD

Cellular Digital Packet Data

CD-R

compact disk-recordable

CD-R2

Physical format for CD read-only

CD-ROM

Compact disc read-only memory. A 4.75-inch laser-encoded optical memory storage medium (developed by NV Philips and Sony Corporation) with the same constant linear velocity (CLV) spiral format as compact audio discs and some videodiscs. CD-ROMs can hold about 550 MB of data.

CD-RW, CDR/W

compact disk-readable/writable

CE

consumer electronics

CEBus

Consumer Electronics Bus

CEDR

Windows CE Driver Repository

CFM

cubic feet per minute

CGA

Color Graphics Adapter, A video adapter capable of 320 x 200 graphics resolution with four colors.

CHAP

Challenge Handshake Authentication Protocol

character

1. The simplest element used to represent written languages. Note that the appearance of a character is not constant: a character's appearance depends on the font used as well as the context of surrounding text. See also Glyph.

2. A code element.

character encoding

A one-to-one mapping from a set of characters into a set of numbers, used to represent text in software

characterization

The measurement of a device's initial state.

chroma, chrominance

1. The color portion of the video signal that includes hue and saturation information. Requires luminance, or light intensity, to make it visible.

2. Hue is defined as tint. Saturation indicates the degree to which the color is diluted by luminance (or by white light). Compare with luminance.

CHS

cylinder head sector

CI

1. Component Instrumentation. A specification for DMI related to the service layer.

2. Calling Indicator – One of four calling signal tones defined by V.8 for exchanging preliminary information. CI is used to indicate the call type (Data, FAX send/receive, Videotex, or H.324).

CID

CompatibleID

CIE

Commission International de l’Eclairage. The international commission on illumination. Developer of color matching systems.

CIFS

Common Internet File System

CIM

Common Information Model. Describes the WBEM data representation schema that is now a DMTF-sponsored industry standard.

CIMOM

CIM Object Manager. A key component of the WBEM architecture. A central message of WBEM is uniform data representation encapsulated in object-oriented fashion in the CIM. Formerly HMOM.

CINF

check (modem) INF tool

CIP

common isochronous packet

CIS

card information structure

CISC

complex instruction set computing

class

For hardware, the manner in which devices and buses are grouped for purposes of installing and managing device drivers and allocating resources. The hardware tree is organized by device class, and Windows 95 uses class installers to install drivers for all hardware classes.

class driver

A driver that provides system-required, hardware-independent support for a given class of physical devices. Such a driver communicates with a corresponding hardware-dependent port driver, using a set of system-defined device control requests, possibly with additional driver-defined device control requests. Under WDM, the class driver creates a device object to represent each adapter registered by minidrivers. The class driver is responsible for multiprocessor and interrupt synchronization.

CLB

Component Load Balancing

CLEC

Competitive Local Exchange Carrier

CLI

command line interface

client system

A computer using the specific Windows operating system that the test device is acquiring a logo for. This computer must also have the test device installed.

CLV

constant linear velocity

CMI

1. Control Method Interface

2. computer-managed instruction

CMM

Color Management Model

CMOS

Complementary Metal-Oxide Semiconductor, A low power consumption chip used to store information about your computer's hardware.

CMR

Communication and Network Riser (CNR) interface specification

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-black. A mixing model or method of describing colors used with many printing systems. Uses subtractive primaries, starting with white and subtracting percentages of cyan (blue), magenta (red), and yellow to yield desired colors.

CN

Common Name

Code Page / Code Set (also code-page, code page)

An ordered set of characters in which a numeric index (codepoint value) is associated with each character. This term is generally used in the context of codepages defined by Windows 3.1 or MS-DOS, and may also be called a "character set" or charset.

A code page can be represented in a table as a mapping of characters to single-byte values or multibyte values. Many code pages share the ASCII character set for characters in the range 0x00 – 0x7F.

codec

1. Coder-decoder. A filter data that manipulates in some form, usually by compressing or decompressing the data stream.

2. compressor/decompressor

color depth

The number of simultaneous colors that are displayable. Color depth can be indicated as the number of colors displayable or the number of bits per pixel (bpp).

color keying

To superimpose one image over another for special effects.

colorspace

A color space is a way to describe a set of colors and their relationships. An example of a colorspace is CIE XYZ. A device’s colorspace describes its color gamut and the characteristics of the color output with that gamut.

COM

1. Component Object Model; the core of OLE(object linking and embedding). Defines how OLE objects and their clients interact within processes or across process boundaries.

2. Legacy serial port.

command packet (ATA)

A command packet is a data structure transmitted to the device by a PACKET command that includes the command and command parameters.

compatibility mode

An asynchronous, host-to-peripheral parallel port channel defined in the IEEE 1284–1944 standard. Compatible with existing peripherals that attach to the Centronics-style PC parallel port.

Complex Script

Scripts that require special processing to display, print, and edit.

For more information, see Complex Scripts at http://www.microsoft.com/globaldev/FAQs/Complex.asp

compliance

A platform is in compliance with a specification when it implements all functional aspects explicitly stated in that specification.

Composite character (also composed character)

A text element consisting of a base character AND a diacritic or accent mark. Although most common in the Latin script, other scripts (including Greek, Devanagari and Tamil) have composite characters too.

composite video

A signal that combines the luminance, chrominance, and synchronized video information onto a single line. This has been the most prevalent NTSC video format.

compressed video

A digital video image or segment that has been processed using a variety of computer algorithms and other techniques to reduce the amount of data required to accurately represent the content and thus the space required to store the content.

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 Windows Plug and Play system component that drives the process of locating devices, setting up their nodes in the hardware tree, and running the resource allocation process. Each of the three phases of configuration management—boot time, real mode, and protected mode—have their own configuration managers.

connection

A negotiated method of communication between devices, whether implemented in hardware or software.

connectionless networking

Networking based on media such as IEEE 802 LAN adapters and Fiber Distributed Data Interface (FDDI) adapters.

contrast

The range of light and dark values in a picture; or a measure of brightness content in an image. The range between the lightest tones and the darkest tones in an image.

controllerless modem

Also host-based controller. A modem that consists of a DSP without the usual microcontroller. The host CPU provides the AT command interpreter, modem-control functions, and v.42bis implementation. Compare with software modem.

control method

A definition of how an ACPI-compatible operating system can perform a simple hardware task. For example, the operating system invokes control methods to read the temperature of a thermal zone. Control methods are written in an encoded language called AML(ACPI Machine Language).

control transfer

One of the four USB transfer types. Control transfers support configuration/command/status type communications between client and function.

convergence

In an RGB monitor, where red, green, and blue signals all converge in one pixel. At full convergence, the RGB pixel would be white.

CPE

Customer Provided Equipment

CPI

1. Cycles Per Instruction

2. Characters per inch, The number of characters per inch that can be printed. Usually used when referring to a dot matrix printer.

CPL

Control panel applet

CPTWG

Copyright Protection Technical Working Group

CPU

Central processing unit. A computational and control unit of a computer; the device that interprets and executes instructions. By definition, the CPU functions as the "brain" of the computer.

CRC

cyclic redundancy check

CRL

Certificate Revocation List

CRM

customer relations management

CRS

Content Replication Service

CRT

Cathode Ray Tube, The picture tube in a monitor. Monitors are often informally referred to as CRTs.

CS

Computer Science (also name for the pcode compiler), also Customer Service

CSA

Connection and Streaming Architecture. Kernel-mode streaming in WDM.

CSC

1. Client-side caching

2. Color Space Conversion

CSEL

Cable Select

CSN

Card Select Number. The handle created by the system BIOS or the operating system through the isolation process and 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

DAP

Directory Access Protocol

DARPA

Defense Advanced Research Project Agency

DASD

direct access storage device

DAT

1. Digital audio tape. A consumer recording and playback media for high-quality audio.

2. dynamic address translation

data rate

The speed of a data transfer process, normally 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

DCC

Darwin Component Code

DCD

1. Data Carrier Detected

2. digital capture device

DCE

Data Circuit-Terminating Equipment or Data Communications Equipment, 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 Plug and Play baseline for monitors. The communications channel between a monitor and the display adapter to which it is connected. This channel provides a method for 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

1. device driver interface

2. display device driver

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 DRAM

DDS

1. Distributed Data Server

2. Digital Data Service

decompression

To reverse the procedure conducted by compression software, and thereby return compressed data to its original size and condition.

default address

An address defined by the USB Specification and used by a USB device when it is first powered or reset. The default address is 00h.

default pipe

The message pipe created by the USB System Software to pass control and status information between the host and a USB device’s endpoint zero.

deinterlace

To combine two interlaced fields into a single frame that is not interlaced. Deinterlacing is done to remove artifacts and improve the quality of encoded video.

density

The degree of darkness of an image. Also, the percent of screen used in an image.

depth-based fog

Color blending objects in a scene with a chosen fog color based on the depth of an object in a scene or its distance from the viewpoint.

DES

Data Encryption Standard

device

Any circuit that performs a specific function, such as a parallel port.

Device Bay

An industry specification that defines a mechanism for both peripheral devices and system bays. Allows adding and upgrading PC peripheral devices without opening the chassis.

device class compliance

A device is in device class compliance when it implements all functional aspects explicitly stated in the device class specific specification.

device ID

A unique ASCII string for the device created by enumerators to identify a hardware device and used to cross-reference data about the device stored in the registry. Distinguishes each logical device and bus from all others on the system.

device node

The basic data structure for a given device, built by the Configuration Manager. Device nodes are built into memory at system startup for each device and enumerator. Each device node contains information about the device, such as currently assigned resources.

device object

A kernel-mode–only object type used to represent a physical, logical, or virtual device whose driver has been loaded into the system.

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 preceding base character . Most diacritics are non-spacing characters that do not increase the width of the base character .

DIB

1. Device-independent bitmap. A file format designed to ensure that bitmap graphics created using one application can be loaded and displayed in another application exactly the way they appeared in the originating application.

2. Directory Information Base

DIFF

Differential

digital

A method of signal representation by a set of discrete numerical values, as opposed to a continuously fluctuating current or voltage. Compare with analog.

digital rights management (DRM)

The technology for packaging Windows Media files and managing the rights for accessing those files.

digital video

A video signal represented by computer-readable binary numbers that describe a finite set of colors and luminance levels. Compare with analog video.

digitization

The process of transforming analog video signal into digital information.

DIP

Dual Inline Package, A small switch used to change hardware settings.

Direct3D

Microsoft Direct3D is a component of the Microsoft DirectX API designed to enable game and 3D graphics on a computer running Microsoft Windows operating system. Direct3D provides device-dependent access to 3D video-display hardware in a device-independent manner.

DirectDraw

Microsoft DirectDraw is a component of the DirectX API that provides direct access to display devices while maintaining compatibility with the Windows graphics device interface (GDI). It is not a high-level graphics API. DirectDraw provides a device-independent way for games and Windows subsystem software, such as 3D graphics packages and digital video codecs, to gain access to the features of specific display devices.

DirectShow

Microsoft DirectShow is a cross-platform API for developers of multimedia applications that provides a user-mode connection and Stream architecture to support high-quality digital video, high-fidelity audio, and special effects.

DirectX

Microsoft DirectX is a low-level API that provides user-mode media interfaces for games and other high-performance multimedia applications. DirectX is a thin layer, providing direct access to hardware services, and takes advantage of available hardware accelerators and emulates accelerator services when accelerators are not present.

Dir-sync

See DSS.

disk I/O controller

Also HDC. A special-purpose chip and circuitry that directs and controls reading from and writing to a computer’s disk drive.

DISP

Directory Information Shadowing Protocol

display resolution

The number of pixels (horizontally and vertically) that are displayed on the screen.

DIT

Directory Information Tree

DLC

1. Digital Loop Carrier

2. Data Link Control

DLL

Dynamic link library. API routines that user-mode applications access through ordinary procedure calls. The code for the API routine is not included in the user’s executable image. Instead, the operating system automatically point the executable image to the DLL procedures at run time.

DLS

1. Distributed Link Services

2. Downloadable Samples

3. Downloadable Sound

DMA

Direct memory access. A method of transferring data between device and host (or vice versa) without the intervention of the microprocessor. The system board uses a DMA controller to handle a fixed number of channels, each of which can be used by only one device at a time.

DMI

Desktop Management Interface. A framework created by the DMTF. DMTF specifications define industry-standard interfaces for instrumentation providers 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 the computer must begin from a power-off state and restart before docking. Hot docking means the computer can be docked while running at full power. See also warm docking.

docking station

The base computer unit into which a user can insert a portable computer, expanding it to a desktop equivalent. 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 a PC’s I/O port, that adds hardware capabilities.

DOP

Directory Operational Protocol

DOS

Disk Operating System, A computer operation system responsible for file access, storage, organization, and execution.

Dot4

1. IEEE P1284.4, Standard for Data Delivery and Logical Channels for IEEE Std. 1284 Interfaces.

2. In the DDK, the device setup class for a parent device that controls the operation of a multifunction IEEE 1284.4 peripheral device.

Double-byte character set (DBCS)

DBCS is a specific type of Multi-byte character set. It includes some characters that consist of 1 byte and some characters that consist of 2 bytes. Used for languages like Chinese, Japanese and Korean

DPA

Distributed Password Authentication

DPC

Deferred procedure call. Method used in Windows NT and Windows 2000 for event scheduling.

DPI

dots per inch

DPMI

DOS Protected Mode Interface

DPMS

Display Power Management Signaling

DRAM

dynamic RAM

DRF

Data Recovery Field

driver

Kernel-mode code used either to control or emulate a hardware device.

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.

DRM

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, contains ASL Contains Namespace Contains Control Methods

DSE

development software engineer

DSL

Digital Subscriber Line

DSLAM

DSL Access Multiplexer

DSP

Digital signal processor. An integrated circuit designed for high-speed data manipulations. Used in audio, communications, image manipulation, and other data-acquisition and data-control applications.

DSS

Digital Satellite System. This system is used in motion video test procedures.

DSSS

Direct Sequence Spread Spectrum, Modulates frequency using a predefined "spreading code" algorithm. Jumps much faster than FHSS

DSVD

Digital Simultaneous Voice/Data

DTE

Data Terminal Equipment – typically refers to a PC.

DTMF

Dual-Tone Modulation Frequency.

DTR

Data Terminal Ready

DTV

Digital television. DTV standards allow standard resolution mode—with about twice the horizontal resolution of conventional analog broadcasts—as well as HDTV mode. 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

Digital video disk. Optical disk storage that encompasses audio, video, and computer data.

DVHS

Digital-VHS

DVI

Digital Visual Interface

DVR

Digital Video Recorder

DX8

DirectX Version 8.0

dynamic detection

The process by which a system can detect that a new device has been added or removed from the PC. This process allows the operating system and applications to immediately begin using the added devices or stop using the removed devices without rebooting the system.

E

EA

extended attributes

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

ECP

Extended capabilities port. An asynchronous, 8-bit–wide parallel channel defined by IEEE 1284–1944 that 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

EGA

Enhanced Graphics Adapter, A video adapter capable of 640 x 350 resolution with 16 colors chosen from a palette of 64 colors.

EIA

Electronic Industries Association

EIDE

Enhanced IDE (also E-IDE)

EIO

Extended I/O

EISA

Extended Industry Standard Architecture. A 32-bit PC expansion bus designed as a superset of the ISA bus. Designed to expand the speed and data width of the legacy expansion bus while still supporting older ISA cards.

EMB

extended memory block

embedded controller

The general class of microcontrollers used to support OEM-specific implementations, mainly in mobile environments. The embedded controller performs complex low-level functions through a simple interface to the host microprocessor(s).

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. This allows any operating system to provide a standard driver that can directly communicate with an embedded controller in the system, thus allowing other drivers to communicate with and use the resources of system embedded controllers.

EMF

1. enhanced metafile

2. electromotive force

EMI

electromagnetic interference

EMS

Emergence Management Services Expanded-Memory Specification, A description of a technique for adding memory to IBM PC and compatible computers; also called LIM EMS because it was developed by Lotus/Intel/Microsoft.

Encoding

A method (algorithm) for presenting characters in digital form by mapping sequences of code values of into sequences of bytes. (e.g. ASCII, Unicode, Windows 1252)

encrypt

To programmatically disguise content to hide its substance. Encrypted content, often called a cipher, cannot be played without first being changed back into clear content through the process of decryption.

endpoint address

The combination of an endpoint number and an endpoint direction on a USB device. Each endpoint address supports data transfer in one direction.

End-User Defined Character (EUDC)

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. Note that such characters are not automatically recognized by the system for functions such as sorting.

enumeration

The process by which logical devices and buses, and their available resources, are identified by Plug and Play during system setup.

enumerator

A Plug and Play device driver that detects devices below its own device node, creates unique device IDs, and reports to 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 set

A uniquely identified set that represents a group of items about which a client can be notified.

ExCA

Exchangeable Card Architecture

EXIF

Exchangeable Image File format

expansion bus

A group of control lines that provide a buffered interface to devices 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 and contains one or more devices.

expansion ROM

See option ROM.

F

FACS

Firmware ACPI Control Structure

FADT

Fixed ACPI Description Table, contains I/O port locations of fixed feature registers Contains details about ACPI features (e.g. how to enable ACPI mode, which IRQ the SCI is wired to, etc.) Critical for proper ACPI operation

FAQ

frequently asked questions

FAT

File allocation table. A table or list maintained by an operating system to keep track of the status of various segments of disk space used for file storage.

FCA

Fibre Channel Arbitrated Loop

FCB

file control block

FCC

Federal Communications Commission

FCP

function control protocol

FC-PH

Fibre Channel Physical

FDC

Floppy disk controller. A special-purpose chip and associated circuitry that directs and controls reading from and writing to a computer’s disk drive.

FDDI

Fiber Distributed Data Interface

FDO

functional device object

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, uses a synchronized clocking algorithm and jumps around to different carrier frequencies.

FiDO

filter device object

field

One half of a television picture. One complete vertical scan of the picture, containing 262.5 lines. Two fields make a complete television picture (frame). The lines of field 1 are vertically interlaced with the lines of field 2 for 525 lines of resolution.

FIFO

First in/first out. A method for processing a queue in which items are removed in the same order they were added.

filters

1. Components that provide the basic building blocks for processing data.

2. Under the WDM Stream architecture, also known as a functional device or multimedia processing driver. Each filter’s capability is described in part by a number of connection points called pins. Each pin can consume, produce, or both consume and produce a data stream such as digital audio. Specialized tasks can be solved by connecting filters by way of their pins into a topology—for example, to play filtered and mixed audio.

3. Under WDM, a filter is implemented as a kernel-mode entity that is a device object implemented by a kernel driver.

.4. Under DirectShow, a filter is a user-mode entity that is an instance of a COM object, usually implemented by a DLL.

FIPS

Federal Information Processing Standards

FIR

fast IR

flash (disk or drive)

A type of non-volatile memory built into the unit or available as a PC Card that can be plugged into a PCMCIA slot. Flash memory can be written in blocks or over the entire chip, making it easy to erase or update.

flat shading

A method of shading that calculates a single intensity value for the rendered polygon that is used for the entire polygon surface. This is also known as "constant" or "faceted" shading.

FM

frequency modulation

FNO

Foreign Namespace Object

Font

A collection of glyphs for displaying text in a particular typeface.

Font association

Mechanism for substituting missing glyphs with glyphs from an appropriate font listed in the registry. Applies only to ANSI text APIs. The substitute font is identified by an ANSI codepage.

Font association is restricted to scripts and fonts that map codepoints to glyphs one to one. The registry setting is recreated by the system whenever the user changes system locale, updates language support, or changes user interface language. See also Font linking and Font fallback.

Font fallback

Mechanism for providing an alternate font for runs of characters not representable by the original font. Understands complex scripts and typographic effects.

Font fallback is to a hard coded list of standard fallback fonts according to Unicode character range. Font fallback defaults are:

Scripts Fallback Font

Most text Microsoft Sans Serif

Armenian Sylfaen

Georgian Sylfaen

Devanagari Mangal

Syriac Estrangela Edessa

Tamil Latha

Font linking

Mechanism for substituting missing glyphs with glyphs from an appropriate font listed in the registry. Applies only to Unicode APIs. Substitute fonts are provided only for a few base fonts.

Font linking is restricted to scripts and fonts that map codepoints to glyphs one to one. The registry setting is recreated by the system whenever the user changes system locale, updates language support, or changes user interface language. See also Font association and Font fallback.

FOP

Fan-Out-PHY

Formatted text

Text displayed with multiple attributes, such as typeface, slant, weight, and color, and special effects such as shading, underlining, and blinking.

FOURCC

A format tag. FOUR Character Code specifies every non-opaque aspect of the image format as present in memory except the image height and width. The unambiguous nature of the format interpretation provided using this enables various components, both software and hardware, to inter-operate. Some FOURCC’s specify formats are opaque or meaningful only to a particular piece of software or hardware. Examples of these include most FOURCC’s for compressed formats, and some FOURCC’s associated with specialized graphics controller capabilities. For more generally open image formats, a FOURCC specifies the relation of in memory pixels to image area, the size in bits of pel representation, the alignment constraint for non-byte sized pels, and the grouping of pels into pixels.

FP

floating point

fps

frames per second

FQDN

fully qualified domain name

FR

frame relay

frame

A single screen-sized image that can be displayed 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), running 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, which makes movement in the video appear smoother.

FRS

File Replication Service

FRU

Field Replaceable Units

FS A

Decibels relative to full scale measured using "A weighting" filters.

FSB

front-side bus

FSD

file system driver

FSIP

full-scale input

FSK

frequency-shift keying

FSOP

full-scale output

FSRTL

File System Run Time Library

FTL

file translation layer

FTP

file transfer protocol

FTS

fault tolerance system

full duplex

In terms of data flow, indicates bi-directional 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 the functionality, or correctness, of a feature implementation.

G

G.Lite (G.922.2)

1. Universal DSL

2. splitterless DSL

G11N

Abbreviated form of GLOBALIZATION. G + 11 characters + N.

GAL

Global Address List

gamma

Gamma is the exponent in the equation relating output intensity to the input signal.

gamut

Gamut is the range of colors a device can produce.

GART (Graphics Address Remapping Table)

The GART is setup by the O/S to map locked pages onto physical memory located within the Graphics Aperture. The GART Memory-based translation table allows "re-mapping" of disjointed pages of physical system memory into a contiguous view that can be used by AGP devices.

GB

gigabyte

GC

Global Catalog

GDI

Graphics Device Interface – Microsoft’s hardware-independent interface for 2D drawing and windowing commands.

GDT

Global Descriptor Table

GFX

global effects

GIDEI

General Input Device Emulation Interface

GIF

Graphics Interchange Format

GINA

Graphical Identification and Authentication

Globalization

Designing and developing a software product to function in multiple locales. This process involves identifying the locales that must be supported, designing features which support those locales, and writing code that functions equally well in any of the supported locales. In other words, adding support for input, display, and output of a defined set of language scripts relating to specific geographic areas.

Glyph

A graphical representation of either a character (a, ?, ?, ?), a part character (e.g. a diacritic: °, ?) or a sequence of characters (for example, a ligature: fi).

Gouraud shading

A method of shading based on linear interpolation of a polygon from its vertices. The shading value for the vertices is calculated from the normal of the vertex. This 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

Also called graceful exit. Termination of a process that allows the operating system or parent process to regain normal control. Does not crash the machine or result in a GPF or blue screen. User is not required to close the application, and can continue to use the other functionality.

Graphics Aperture

The Graphics Aperture defines the maximum amount of physical memory the core chipset addresses as AGP system memory. The size and location of the Aperture is configured (in the core chipset) by the BIOS during system boot-up. Since the Aperture is simply an address base and range register set, not a direct mapping table (as is GART), the Aperture is likely to be greater than the amount of physical memory actually installed in the system. This allows for application growth via system memory upgrades.

gray scale

The spectrum (range) of shades of black that an image has.

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

Used to specify settings for groups of users and computers, including software policies, scripts, user documents and settings, application deployment, and security settings.

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, A graphical interface that enables a user to start programs, choose commands, and manage files and other options by pointing to pictorial representations (icons) and lists of menu items on the screen.

GUID

Globally unique identifier. A 16-byte value generated from the unique identifier on an adapter, the current date and time, and a sequence number. This is used to allow any party to create identifiers that will be guaranteed not to overlap with other similarly created identifiers.

H

H.323

ITU standards for multimedia conferencing over IP

H.324

ITU-T Recommendation which specifies procedures for video telephony between computers over a GSTN.

HAL

Hardware Abstraction Layer – A device-specific interface, provided by the device manufacturer, that DirectDraw and Direct3D use to work directly with the display hardware.

hardware branch

The hardware archive root key in the registry that is a superset of the memory-resident hardware tree. Although the hardware tree contains information only about those devices currently detected and running in the system, the registry contains a complete list of all hardware ever installed on the particular computer. The hardware root key is \\Hkey_Local_Machine\Hardware.

hardware tree

A record in RAM of the current system configuration based on the information for all devices in the hardware branch of the registry. The hardware tree is created each time the system is started or whenever a dynamic change occurs to the system configuration.

HAVi

Home Audio Video interoperability

HBA

Host Bus Adapter

HCA

host channel adapter

HCAL

hardware channel abstraction layer

HCI

Host controller interface. For example, a system-level interface supporting USB.

HCL

Hardware Compatibility List. A registry of products that have been tested by WHQL and that have passed Windows compatibility testing.

HCT

Hardware Compatibility Tests. A suite of tests from Windows Hardware Quality Labs that verify hardware and device driver operations under a specific operating environment. These tests exercise the combination of a device, a software driver, and an operating system under controlled conditions to verify that all components operate properly.

HDC

Hard disk controller. A special-purpose chip and circuitry that directs and controls reading from and writing to a computer’s disk drive.

HDCP

High definition Digital Content Protection

HDD

hard disk drive

HDLC

High-Level Data Link Control

HDTV

High-definition TV. A proposed standard that recommends doubling the current 525 lines per picture to 1050 lines, and increasing the screen aspect ratio (that is, width to height) from the current 12:9 to 16:9, which would create a television screen shaped more like a movie screen.

headless

BIOS or server appliances without display or input peripherals, such as a keyboard, pointing device, or video monitor.

HEL

Hardware Emulation Layer – An interface that is provided by DirectDraw that emulates features in software.

HFC

hybrid fiber-coax

HID

Human Interface Device

HID specification

The device class definition developed by the USB standards group for Human Interface Devices. Serves as the basis for WDM input device support, and unifies input devices by providing flexible data reporting, typeless data, and arrayed and variable input and output.

high-contrast support

Part of Accessibility options set by users to indicate that they require a high degree of contrast to improve screen legibility.

high resolution

An adjective describing improvement in display image quality as a result of increasing the number of pixels per square inch.

HIPPI

High-Performance Parallel Interface

HMA

High-Memory Area, The first 64K of extended memory, accessible through extended memory manager such as HIMEM.SYS.

HMMP

HyperMedia Management Protocol. The encapsulation of CIM objects and operations on those objects.

HMMS

See CIM.

HMOM

See CIMOM.

HomePNA

The Home Phoneline Networking Alliance (HomePNA) has been formed to develop specifications for interoperable, home-networked devices using the phone wiring already in place.

HomeRF

The HomeRF Working Group (HRFWG) was formed to provide the foundation for a broad range of interoperable consumer devices by establishing an open industry specification for wireless digital communication between PCs and consumer electronic devices anywhere in and around the home. The HRFWG is developing a specification for wireless communications in the home called the Shared Wireless Access Protocol (SWAP).

host controller

The host’s USB interface.

HPC

Handheld PC

HPFS

High-Performance File System

HRTF

Head Related Transfer Function

HSB

Hue-saturation-brightness. With the HSB model, all colors can be defined by expressing their levels of hue (the pigment), saturation (the amount of pigment), and brightness (the amount of white included), 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 USB device that provides additional connections to the USB.

hue

The color tint of an image. The color of the analog video signal is determined by three factors: hue, saturation, and luminance.

Human Interface Device specification

The device class definition developed by the USB standards group for HIDs. Serves as the basis for the WDM input device support, and unifies input devices by providing flexible data reporting, typeless data, and arrayed and variable input and output.

HUT

HID Usage Tables

HW RAID

A RAID that is done with no knowledge of the operating system. As far as Windows NT knows, these RAID sets appear to be a normal physical disk and the RAID operations are all done in hardware.

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 descriptive term for computers built with processors conforming to the architecture defined by the Intel processor family based on the 486 instruction set and having an industry-standard PC architecture.

IAS

Information Access Service

ICC (Video)

International Color Consortium. In this context, support refers to the operating system’s ability to translate images between different colorimetric interpretations if a device ships with a profile.

ICD

Installable Client Driver. An OpenGL driver model in which the driver is responsible for implementing the entire OpenGL pipeline. Intended for high-end graphics cards that implement most of the OpenGL pipeline in hardware.

ICM

Image Color Management

ICMP

Internet Control Message Protocol

ICP

Internet content provider

ICS

Internet Connection Sharing

ID

Identifier. Generally, any text string used as a label, such as the name of a procedure or a variable in a program, or the name attached to a hard drive or floppy disk.

iDCT

Inverse Discrete Cosine Transform

IDE

Integrated Device Electronics. A type of disk-drive interface where the controller electronics reside on the drive itself, eliminating the need for a separate adapter card. See also ATA.

IDSL

Internet Digital Subscriber Line. ISDN basic rate service deployed using low-bandwidth DSL technology.

IDT

1. Internet Development Toolbox

2. Interrupt Dispatch Table

IEAK

Internet Explorer Administration Kit

IEC

International Electrotechnical Commission

IEEE

Institute of Electrical and Electronics Engineers, pronounced "I-triple-E." Founded in 1963, IEEE is an organization composed of engineers, scientists, and students. IEEE is best known for developing standards for the computer and electronics industry.

IETF

Internet Engineering Task Force

IF

Implementers Forum

IFS

Installable File System Manager

IGMP

1. Internet Group Management Protocol

2. Internet Group Membership Protocol

IGN

Internet group names

IHV

independent hardware vendor

IIS

Internet Information Server

ILEC

Independent (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 an image as it is digitized; measured in dots per inch (DPI), typically ranging from 200 to 400 DPI.

IMAPI

Image Mastering API

IMD

Intermodulation Distortion

IME

See Input Method Editor

IMM

See Input Method Manager

IMS

Integrated Management system

in

In terms of data flow, indicates consumption of data. An in pin is compatible with an out pin.

INF file

An INF file is an ASCII or Unicode text file that provides device and driver information, including the driver files, registry entries, device IDs, catalog files, and version information required to install the device or driver.

input class

The class of filters that provide an interface for HID hardware, including USB and legacy devices, plus proprietary and other HID hardware, under the WDM HID architecture.

Input language

A language to be inputted into the system, be it through the keyboard, a speech-to-text converter or an IME.

Input Locale

Pairing of input language (LangID) 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)

A software program used to enter text with large character sets, such as Chinese, Japanese, and Korean.

Input Method Manager (IMM)

The module in Windows that handles communication between Input Method Editors (IMEs) and applications.

instantiate

In object-oriented programming, to create an instance of a class.

instrumentation

A mechanism for reporting information about the state of system hardware and software to enable management applications to ascertain and change the state of a system and to be notified of state changes.

integrated device

Any device—such as a parallel port, graphics adapter—that is designed on the system board rather than on an expansion card.

integration test

An integration test verifies the functionality and correctness of a feature implementation when it is fully integrated with other system components (higher level class and mini drivers, etc.).

intelligent streaming

A type of streaming that detects network conditions and 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 mirror systems, data, and applications on a server.

interactive video

A video program and a computer program running in tandem under the control of the user. In interactive video, the user’s actions, choices, and decisions genuinely affect the way in which the program unfolds.

interframe coding

Compression techniques that track the differences between frames of video. This results in more compression over a range of frames than intraframe coding.

interlaced

To display video by using a half-resolution image known as a field. Interlaced video uses two video fields to make 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.

Internationalization

Term used out side of Microsoft 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

The process of averaging pixel information when scaling an image. When reducing the size of an image, pixels are averaged to create a single new pixel; when an image is scaled up in size, additional pixels are created by averaging pixels of the smaller image.

interrupt transfer

One of the four USB transfer types. Interrupt transfer characteristics are small data, non-periodic, low-frequency and bounded latency. Interrupt transfers are typically used to handle service needs.

I/O

Input/output. Two of the three activities that characterize a computer (input, processing, and output). Refers to the complementary tasks of gathering data for the microprocessor to work with and make the results available to the user through a device such as the display, disk drive, or printer.

IOCTL

Input/output control. A custom class of IRPs available to user mode. Each WDM class driver has a set of IOCTLs that it uses to communicate with applications. The IOCTLs give the class driver information about intended usage by applications. The class driver performs all IOCTL parameter validation.

IOS

I/O supervisor

IP

Internet Protocol

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. This means that just one set of packets is transmitted for all the destinations.

IPC

interprocess communication

IPL

Initial program load. A device used by the system during the boot process to load 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 a key data structure for WDM, which features multiple layered drivers. In WDM, every I/O request is represented by an IRP that 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, and then either passes the IRP back to the I/O Manager for disposal or onto an adjacent driver layer. An IRP packet consists of two parts: a header and the I/O stack locations.

IRP_MJ_XXX

IRP Major. One of a predefined class of IRPs that a device can accept.

IRQ

Interrupt request. A method by which a device can request to be serviced by the device’s software driver. The system board uses a PIC to monitor the priority of the requests from all devices. When a request occurs, a microprocessor suspends the current operation and gives control to the device driver associated with the interrupt number issued. The lower the number—for example, IRQ3—the higher the priority of the interrupt. Many devices only support raising requests of specific numbers..

IRQL

IRQ level

IrTran-P

Infrared Transfer Picture

ISA

Industry Standard Architecture. An 8-bit (and later, a 16-bit) expansion bus that provides a buffered interface from devices on expansion cards to the PC internal bus.

ISAPI

Internet Server API

ISDN

Integrated Service Digital Network. A set of communications standards that enable a single phone line or optical cable to carry voice, digital network services, and video.

ISIS

Image and Scanner Interface Specification

isochronous

Refers to a communication protocol based on time slices rather than handshaking. For example, a process might have 20 percent of total bus bandwidth. During its time slice, the process can stream data.

isochronous data

A stream of data whose timing is implied by its delivery rate.

isolation

The Plug and Play process by which cards on an ISA bus are distinguished from each other after system startup.

ISO

International Organization for Standardization

isochronous

Refers to a communication protocol based on time slices rather than handshaking. For example, a process might have 20 percent of total bus bandwidth. During its time slice, the process can stream data.

Isochronous Data

A stream of data where the timing is implied by the delivery rate.

Isolation

The Plug and Play process by which cards on an ISA bus are distinguished from each other after system startup.

ISO/OSI

ISO Open Systems Interconnection model. A layered architecture that standardizes levels of service and types of interaction for computers exchanging information through a communications network.

ISP

Internet service provider

ISR

Interrupt service routine. A routine whose function is to service a device when it generates an interrupt.

IST

interrupt service thread

ISV

independent software vendor

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 is attempting to define a proposed universal standard for the digital compression and decompression of still images for use in computer systems.

K

KB

Kilobyte (1024 bytes) (referred to as K in Microsoft Knowledge Base articles)

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 most basic operations of the operating system, such as sharing the processor between different blocks of executing code, handling hardware exceptions, and other hardware-dependent functions.

kernel mode

The processor mode that allows full, unprotected access to the system. A driver or thread running in kernel mode has access to system memory and hardware.

Keyboard layout

A standard arrangement of characters on a keyboard that defines which keys produce particular characters or scan codes.

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. L + 10 characters + N.

L2

Level 2

L2TP

Layer 2 Tunneling Protocol

LAN

Local area network. A group of computers and other devices dispersed over a relatively limited area and 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 Enabling

1. Adding support to software for document content in a particular language. In this sense, to enable an application for Japanese means to modify the software so that the user can enter, display, edit, and print text containing Japanese.

2. Modifying software so that it can be localized to a particular language. In this sense, enabling for Japanese means to modify software so that it can display Japanese text correctly in menus, dialog boxes, and other user interface elements. Note that in either sense, an enabled product may still have the user interface in English, i.e., it may not be localized. Contrast Localization.

Language Group

Term used to describe the supported script families in Windows 20000.

Language ID (LangID)

A 16-bit value that identifies a language. A LangID consists of a primary language, such as Arabic, and a sub-language, such as Arabic for Saudi Arabia.

LAPM

Link Access Protocol, Modem

latency

The amount of time it takes to send a packet from one designated point to another.

layered driver

One of a collection of drivers that responds to the same IRPs. Layered driver describes the highest-level and lowest-level drivers in a chain of layered drivers that process the same IRPs, along with all intermediate drivers in the chain.

LBA

Logical block address. A unit of data supplied or requested by a host computer.

LBA

logical block addressing

LBFO

load balancing and fail-over

LC

linear control

LCC

logical link control

LCD

liquid crystal display

LDAP

Lightweight Directory Access Protocol

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 PC system based on older technology for which compatibility continues to be maintained in other system components. This document defines legacy in two distinct ways. See Legacy Device and Legacy Mode.

legacy device

Non-ISA PnP/PCI/USB/IEEE 1394 legacy device is the term used by this document for devices that require either ACPI configuration mechanisms or Plug-n-Play system device nodes to specify resource configurations.

legacy mode

Non-ACPI legacy mode is the operational mode in which ACPI is disabled. 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, and auto-configuration is supported through the ESCD, system device nodes, ISA PnP configuration registers, PCI configuration registers, and USB/IEEE 1394 enumeration and configuration mechanisms.

Legacy PCI Devices/Systems

A class of devices or systems which are compliant with PCI Local Bus Specification, Revision 2.1 or Revision 2.0.

LFN

long file name

Ligature

Two or more characters combined to represent a single typographical character. The modern Latin script uses only a few. Other scripts use many ligatures that depend on font and style. Some languages, such as Arabic, have mandatory ligatures; other languages have characters that were derived from ligatures, such as the German ligature of long and short "s" (ß) and the ampersand (&), which is the contracted form of the Latin word et.

LIM

Lotus-Intel-Microsoft

line of business

1. OEM division specifically focused on a particular business sector

2. Application created specifically to support specific business needs in an enterprise.

LM

Link Manager

LME

Large Memory Enabled

LMP

Link Manager Protocol

load balancing

Scaling the performance of a server-based program by distributing 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

A load/stress test verifies the functionality of a feature implementation under stressful system load conditions.

LOB

line of business

local bus

Usually refers to a system bus directly connected to the microprocessor on a system board. Used colloquially to refer to system board buses located closer to the microprocessor than are ordinary expansion buses (that is, with less buffering), which are therefore capable of greater throughput.

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)

A 32-bit value that identifies a locale. An LCID consist of a LangID and a sort key ID.

Localizability

Process of developing a program core whose features and code design don't make assumptions based on a single locale or script.

Localization

The process of customizing or translating the separated data and resources needed for a specific region or language. L10N is a common abbreviation for Localization because the L in Localization is followed by 10 letters and ends with the letter "N".

local memory

Random access memory associated directly with the graphics accelerator. Sometimes referred to as the "local frame buffer."

Logical order

The ordering of characters in text corresponding to the order in which they are inputted (such as when writing by hand, or keying in text using a keyboard). Contrast Visual order.

long filename (LFN)

Any filename that exceeds 8.3 characters in length or contains any lowercase characters or any characters that are not valid in the 8.3 namespace. For every long filename, an alias entry is generated that complies with the 8.3 filename rules for backward compatibility.

LORG

large organization

lossless compression

Ensures that the original data is exactly recoverable 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 apparent resolution.

LRU

Least-recently used. Algorithm for paging.

LPAR

logical partitioning

LPC

low pin count

LPCM

location PCM

LPT

line printer

LRU

least-recently used

LS120

Laser storage 120 MB. An ATAPI (ARMD compliant) high density floppy drive that can read and write standard 1.44 megabyte floppy discs as well as proprietary 120 megabyte media.

LSA

Local Security Authority

LSB

least significant bit

LSI

large-scale integration

luminance

Used to describe 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. Also, brightness; 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

macro pixel

An aggregation of the minimum numbers of pels needed to define a minimum number of pixels such that these pels do not participate in the definition of any other pixels.

MADK

Microsoft ActiveX Development Kit

MAPI

Messaging Application Programming Interface

master clock

Controls the rate of reference time within a graph and is used by filters within the graph to synchronize presentation times. Provides a standard mechanism to query the reference time, to query the physical clock time and rate (compared to the system clock) of the owner of the master clock, and to establish 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

Momentary control; megacycle

MCA

Micro Channel Architecture. The design of the bus used in most IBM model PS/2 models. MCA is not compatible with ISA or EISA adapter cards.

MCD

1. Miniclient Driver. An OpenGL driver model in which the driver is responsible only for handling those features that can be accelerated in hardware, leveraging software implementation to handle 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

MDCT

Modified Discrete Cosine Transform

MDI

multiple-document interface

MDK

Modem Developers Kit

MDL

Memory descriptor list. In Windows NT, an opaque structure, defined by Memory Manager, that uses an array of physical page frame numbers to describe the pages that back a virtual memory range.

MEI

Matsushita Electronics Incorporated

MEMS

MicroElectroMechanical Systems

MESN

Media Event Status Notification

metadata

Information about content, such as the title, author or copyright. The information is contained in a metafile.

method set

Used in Windows NT, Windows 2000, and WDM drivers to perform an action, such as allocating memory, and to provide a way to access related actions. Each method set has a unique identifier used to retrieve 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, and 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

MIDI

Musical Instrument Digital Interface. An industry-standard connection for computer control of musical instruments and devices. A hardware and data standard for communicating between hardware. Most references involve only the data standard, which is a byte stream used for controlling musical instruments and storing the output of such instruments.

MIMD

multiple instruction multiple data

minidriver

A hardware-specific DLL that 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 class driver’s device object to make system calls.

miniport driver

A device-specific kernel-mode driver linked to a Windows NT, Windows 2000, or a WDM port driver, usually implemented as a DLL that provides an interface between the port driver and the system.

MIP

Multimission Interactive Picture

MIP-mapped textures

A texture map that pre-filters and stores texture information at different spatial bandwidths. Each pre-filtered image, or level, in the MIP map is a power of two smaller than the previous level. A high-resolution level is used for objects that are close to the viewer, while lower-resolution levels are used as the object moves farther away.

MIPS

Millions of instructions per second. A common measure of processor speed.

MIS

management information system

mixer class

The class of filters that deal with manipulating controls such as volume, treble, and so on.

MLAN

Music LAN

MLD

In the context of this document, MLD is used to denote a metric of similarity, which we call Mean Level Difference. Given image components I and I’, this is computed on an h*w block as

.

MMC

Microsoft Management Console

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

MOF

Managed Object Format

monolithic driver

A driver that has many different classes of functionality contained in the same driver.

motherboard

See system board.

MP@ML

Main Profile at Main Level

MP3

MPEG 1, Layer 3. A technology for compressing audio while retaining the original level of quality heard during playback.

MPAA

Motion Picture Association of America

MPEG

Moving Picture Expert Group. Used when referring to one of several standard video-compression schemes. A codec for squeezing full-screen, VHS-quality digital video into a small data stream so it can be played from a CD-ROM drive.

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 high-availability clustering feature of Microsoft Windows NT Server 4.0 Enterprise Edition, Microsoft Windows 2000 Advanced Server, and Microsoft Windows 2000 Datacenter Server.

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

MSMQ

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 (Philips, Microsoft, Compaq, Sony, and Adaptec) proposes an open industry standard for making CD-RW easier to use, increasing compatibility and performance, and enabling 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)

MultiByte Character Set. A mixed-width character set, in which some characters consist of more than 1 byte. A double byte character set (DBCS), which is a specific type of multibyte character set, includes some characters that consist of 1 byte and some characters that consist of 2 bytes.

multicast

A method of distributing content in which multiple clients share a stream from a server.

multicast address dynamic client allocation protocol (MADCAP)

An extension to the DHCP protocol standard used to support dynamic assignment and configuration of IP multicast addresses on TCP/IP-based networks.

multifunction device

A piece of hardware that supports multiple, discrete functions, such as audio, mixer, and music, on a single adapter.

multimedia

Refers to the delivery of information that combines different content formats, such as motion video, audio, still images, graphics, animation, text, and so forth.

multimedia processing driver

See filters.

multiple bit rate (MBR) video

A feature of Windows Media Technologies that supports the creating and streaming of multiple encoded video streams within one Windows Media stream. By using multiple bit rate video in Windows Media Encoder, you can create Windows Media-based content that has a variety of video streams at variable bandwidths ranging from 28.8 Kbps through 300 Kbps, as well as a separate audio stream. After receiving this multiple encoded stream, the server determines which bandwidth to stream based on the network bandwidth available. Multiple bit rate video is not supported on generic HTTP servers.

music class

The class of filters that deal with music data, such as ZIPI or MIDI.

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)

The set of system functions in 32-bit Windows that contain national language support (information that is based on language and cultural convention).

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

NDD

Norton Disk Doctor

NDIS

Network Driver Interface Specification. The interface for network drivers used in Windows and Windows NT-based operating systems, including Windows 2000. 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.

NDS

1. NetWare Directory Service

2. Novell Directory Services

.NET

Microsoft vision and road map for its next generation of software and services.

Net PC

Network PC

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

An asynchronous, peripheral-to-host channel defined in the IEEE 1284-1944 standard. Provides a channel for the peripheral to send data to the host, which is commonly used as a means of identifying the peripheral.

NIC

network interface card

NICAM

Near-Instantaneously 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

natural language support

NMI

Nonmaskable Interrupt. An interrupt that cannot be overruled by another service request. A hardware interrupt is called nonmaskable if it cannot be masked by the processor interrupt flag.

NNTP

Network News Transfer Protocol

non-interlaced

The method of scanning all lines on a display from top to bottom in sequential order at a specific rate per second. Unlike television, which uses an interlaced scanning method, computers typically use non-interlaced monitors.

non-local memory

Main system memory that can be accessed by the core logic chipset for supporting AGP operations.

Non-spacing character

A character, such as a diacritic, that has no meaning by itself, but overlaps a base character to modify it. Sometimes referred to as a "combining character".

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

NTDS

Windows NT Directory Service

NTFS

An advanced file system designed for use specifically with the Windows NT and Windows 2000 operating systems. NTFS supports file system recovery and extremely large storage media, in addition to other advantages.

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 standards-setting body for television and video in the United States. Sponsor of the NTSC standard for encoding color, a coding system compatible with black-and-white signals and the first system used for color broadcasting in the United States. The broadcast standard for the United States and Japan. See also PAL format and SECAM.

NTSC format

A color-television format having 525 scan lines, a field frequency of 60 Hz, a broadcast bandwidth of 4 MHz, line frequency of 15.75 KHz, 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

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. Used primarily to refer to PC systems manufacturers.

OEMCP

Default OEM codepage of the system. The OEM codepage is the one used for conversions of MS-DOS based text mode applications.

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. 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 system and device power control. OnNow is a term for a system that is always on but appears off and that responds immediately to user or other requests.

OO

object oriented

OOB

1. out-of-box

2. out-of-band channel

OOBE

out-of-box experience

OOC

On-off control

OOP

object-oriented programming

opcode

Open Host Controller Interface

OpenGL

Open Graphics Library. An operating system independent, industry-standard API for2-D and 3-D color graphics programming. Typically used for engineering, visualization, simulation, and other graphics-intensive applications.

OpenHCI

Operation Code

OpenType

A font format jointly developed by Microsoft and Adobe Systems, Inc. to allow for the addition of Type 1 (PostScript) font data to a TrueType font.

OpenType Layout

An extension to the OpenType format designed to provide support for international and high-end typography.

OPK

OEM preinstallation kit

option ROM

Optional read-only memory found on an expansion card. Option ROMs usually contain additional firmware required to properly boot the peripheral connected to the expansion card, for example, a hard drive. 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

out-

In terms of data flow in kernel streaming and DirectShow, indicates production of data. An out pin is compatible with an in pin.

Overlap

Overlap is a protocol that allows devices that require extended command time to perform a bus release so that commands may be executed by the other device on the bus.

P

PAC

Privilege Attribute Certificate

packed (format)

When pels are grouped near the lowest level of pixel aggregation possible, we say the format is packed. 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, differing slightly in the grouping or order, but common 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 with screen bits stored in a single plane and with each pixel on the screen having a set of two or more corresponding bits that define the pixel color.

packet (USB)

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

PAL format

Phase Alternation Line format. The European video standard, except for France. See also NTSC and SECAM.

PAN

Personal Area Network

PAP

Password Authentication Protocol

PBX

Private Branch Exchange

PC

1. personal computer

2. packet classifier

PC 2001 / PC 99

The design guidelines for PC systems and peripherals defined in the PC 2001 and PC 99 Hardware Design Guides.

PC Card

A trademark of PCMCIA. A removable device that is designed to be plugged into a PCMCIA slot and used as a memory-related peripheral.

PCB

printed circuit board

PCI

Peripheral Component Interconnect. A high-performance, 32-bit or 64-bit bus designed to be used with devices that have high bandwidth requirements, such as the display subsystem.

PCI PM

PCI Bus Power Management Specification, Revision 1.0 or higher

PCIC

PC Card I/O cards

PCI-X

A proposed extension to PCI.

PCM

Pulse coded modulation. A method of encoding information in a signal by varying the amplitude of pulses. The most common method of encoding an analog signal into a digital bit stream.

PCMCIA

Personal Computer Memory Card International Association. Sometimes used to refer to a controller for a type of expansion card documented in the PCMCIA standards.

PCP

Printer Control Protocols

PCR

peak cell rate

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

PDU

protocol data unit

PE

Portable EXE

pel (Pixel Element)

In a color space with multiple elements per pixel, we use Pel to indicate a datum that is a constituent value of one or more pixels. For example, in a 4:2:2 YVU color space, Y0 is a Pel, U0 is a Pel, and Y1 is a Pel. U0 is a constituent of both the first and second pixels, while the Y values are constituents of one pixel each. In a 5:5:5 RGB color space, each of the five bits R, G, and B values is a Pel.

performance compliance

A device or system is in performance compliance when it meets all performance criteria specified in the PC 99 System Design Guide.

performance test

A performance test measures the throughput or turn-around time of a feature implementation.

perspective correction

A process that correctly alters textured triangles in a scene to lend the impression that the triangles' vertices are at different distances from the viewer (that is, the triangle has perspective).

PHY

physical layer device

PIC

programmable interrupt controller

PID

1. Product ID

2. program ID

PIF

program information file

PIL

Integrated PHY and Link

PIL-FOP

Integrated PHY and link, Fan-out PHY

PIM

Personal Information Manager, (calendar, contacts, inbox, tasks and notes) Pocket PC software.

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, audio input can be described by a pin on a filter.

PIO

Programmed Input/Output

PIP

picture-in-picture

pipe

A logical abstraction representing 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 information needed to specify 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. This can be due to the absence of any pel. When pixel drops occur, packed formats typically lose all pels for the affected pixels, while planar formats typically lose individual pels, as is readily apparent when considering 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, i.e., one typeface, one slant, and one weight. Contrast Formatted text.

planar

See system board.

planar (format)

When pels are grouped by color space basis vector, we say 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, as defined and used in this document, is the motherboard and add-in hardware, the BIOS, and the low-level drivers (i.e., WDM class and mini drivers) that comprise a PC product.

Platform Compliance

A system is in platform compliance if it meets all system requirements specified in the PC 99 System Design Guide.

player

A client program or control that receives multimedia content 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 design philosophy and set of specifications that describe hardware and software changes to the PC and its peripherals that automatically identify and arbitrate resource requirements among all devices and buses on the system. Plug and Play specifies a set of device driver interface elements that are used in addition to, not in place of, existing driver architectures.

Plug and Play BIOS

A BIOS with responsibility for configuring Plug and Play cards and system-board devices during system power up. 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.

PM Compliance

A device is in power management compliance with a device-specific power management specification when it implements all power management aspects explicitly stated in that specification.

PMD

Physical Media Dependent

PME

power management event (also PME#)

PO

Power management component in kernel

POF

Plastic Optical Fiber

polling

Asking multiple devices, one at a time if they have data to transmit

PON

Passive Optical Network

POP

1. point-of-presence

2. Post Office Protocol

port

A connection or socket used to connect a device—such as a printer, monitor, or modem— to the computer. Information is sent from the computer to the device through a cable.

port driver

A low-level driver that responds to a set of system-defined device control requests and possibly to an additional set of driver-defined (private) device control requests sent down by a corresponding class driver. A port driver insulates class drivers from the specifics of host bus adapters and synchronizes operations for all its class drivers.

port replicator

Low-cost docking-station substitute intended to provide convenient, one-step connection to multiple desktop devices.

POSIX

Portable Operating System Interface for Unix

POST

Power On Self Test. A procedure of the system BIOS that identifies, tests, and configures the PC in preparation for loading the operating system.

POTS

Plain Old (analog) Telephone Service/system

power management

Mechanisms in software and hardware to minimize system power consumption, manage system thermal limits, and maximize system battery life. Power management involves trade-offs among system speed, noise, battery life, processing speed, and power consumption.

power policy

For power management, the decisions that determine how to save energy and when to go to sleep, based on end-user preferences, application needs, and system hardware capabilities.

power resources

Resources such as power planes, clock sources, and so on that a device requires to operate in a given power state.

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

Precomposed character

A single character that represents a sequence of characters, usually a combination of a base character and one or more diacritics.

PRI

Primary Rate Interface

Private Use Area (PUA)

The area in Unicode from U+E000 through U+F8EE that is set aside for vendor-specific or user-designated characters.

program guide

The on-screen user interface that allows users to select, manage, and search television programs and other content-viewing options.

property set

In Windows NT, Windows 2000, and WDM device driver models, a method defined to set and get properties on a driver. Each property set has a unique identifier, which represents types of related information and is used to access the property set.

PS

packet scheduler

PS/2

Personal System/2

PSS

Product Support Services

PSTN

Public Switched Telephone Network

PTH

plated-through-hole

PTP

Picture Transfer Protocol

PTT

Post, Telephone, and Telegraph

Pulse Code Modulation (PCM)

A sampling technique for digitizing analog signals, especially audio signals. When you encode audio by using PCM, no compression is applied.

push technology

In client/server applications, to send data to a client without the client requesting it—for example, sending e-mail. In contrast, the World Wide Web is based on pull technology, where the client browser must request a web page before it is sent. Broadcast media are push technologies because they send information out regardless of whether anyone is tuned in.

PVC

permanent virtual circuit

PVR

Personal Video Recorder

PWC

Progressive Wavelet Codec

Px64

Also CCITT Recommendation H.261. A draft standard for motion video compression in videophone and teleconferencing applications, designed for 64-Kbps transmission channels.

PXB

PCI bridge

PXE

Preboot Execution Environment

Q

QAM

quadrature amplitude modulation

QFE

quick-fix engineering

QIC

Quarter-Inch Cartridge Drive Standards, Inc. An international trade association dedicated to promoting use of quarter-inch tape technology and products. For more information, visit the web site at http://www.qic.org/.

QoS

Quality of service

R

RADIUS

Remote Authentication Dial-In User Service

RADSL (RA-ADSL)

rate adaptive asymmetric digital subscriber line

RAID

redundant array of independent disks

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 that translates the digital representation of a pixel into the analog information needed by the monitor to display it.

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 (images described mathematically as points connected by straight lines) to equivalent images composed of pixel patterns that can be stored and manipulated as sets of bits.

RASUM

reliability, availability, scalability/serviceability, usability, manageability

RAW

read and write

RBC

reduced block commands

RDMA

remote DMA

RDN

Relative Distinguished Names

RDR

redirector

Reading order

The overall direction of a sequence of text. Whereas words in a given script always flow in the direction associated with that script (for example, LTR for Latin, RTL for Hebrew), the flow sentence itself depends on the reading order. For example, a mixture of Arabic and English text may be regarded as French embedded in an overall Arabic sentence, implying RTL reading order, or as Arabic embedded in French, implying LTR reading order.

real time

In computing, 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 such as telephony.

Red Book audio

The data format standard for conventional audio CDs used in home stereo systems.

reference

A logo'd device or system used as a control device or system, to test 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 frame buffer utilization.

registry

In Windows and Windows NT operating systems, the tree-structured hierarchical database where general system hardware and software settings are stored. The registry supersedes the use of separate INI files for all system components and applications that know how to store values in the registry.

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 and thus has a higher resolution and is capable of reproducing greater detail in an image.

resource

1. Any sort of set from which a subset can be allocated for use by a client, such as memory or bus bandwidth. This is not the same as resources that are allocated by Plug and Play.

2. A general term that refers to IRQ signals, DMA channels, I/O port addresses, and memory addresses for Plug and Play.

resource arbitrator

In Plug and Play device configuration, a set of functions used by the configuration manager to arbitrate and allocate resources on the PC.

resource conflict

In Plug and Play device configuration, the result of more than one device sharing the same, nonshareable resource. Conflicts can cause the device to be partially functional or nonfunctional, or can cause the PC to malfunction completely.

resource data type function

A function that describes the resource requirements of an ISA expansion card as well as the programmability available on the card and its interdependencies.

RF

radio frequency

RFC

Request for Comments

RFC1483

Internet Request for Comments 1483, a standard for multiprotocol encapsulation over ATM networks

RFP

request for proposals

RGB

Red-green-blue. The primary colors in color video. Often used to describe a video color-recording scheme and the equipment that uses it. Also, a computer color-display output signal comprised of separately controllable red, green, and blue signals (as opposed to 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, consisting 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. This hub is attached to the host.

router

A device that connects two or more networks, and carries data forward. A router determines where the destination computer is located, and then finds the best way to transmit the data there.

RP

recommended practice

RPC

remote procedure call

RR

Review Request

RSA

public-key cipher for encryption/decryption

RSDT

Root System Description Table, contains a list of pointers to other tables and Can be used to identify the 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.

RTOS

real-time operating system

RTP

1. real-time transport protocol

2. Real-Time Protocol

RTS

Request to Send

RWS

Remote Winsock

RX

Receiver

S

SAC

1. Secure, Authenticated Channel

2. Secure Admin Console

SAF

Support Automation Framework

SAK

Server Appliance Kit

SAM

Security Accounts Manager

SAMI

Synchronized Accessible Media Interchange

sampling

The first step in the process of converting an analog signal into a digital representation. Accomplished by measuring the value of the analog signal at regular intervals (called samples). These values are then encoded to provide a digital representation of the analog signal.

SAN

Storage area network

SAP

1. Service Advertising Protocol

2. Secure audio path

SAR

segmentation and re-assembly

saturation

The extremes of operating range wherein 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 a system to take advantage of 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 creating 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

SCI

System control interrupt. A system interrupt used by hardware to notify the operating system of ACPI events. The SCI is an active low, shareable, level interrupt.

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 have a common characteristic that justifies their consideration as a distinct set. One script may be used for several different languages (for example, Latin script, which covers all of Western Europe), and some written languages require multiple scripts (for example, Japanese, which requires at least three scripts: the hiragana and katakana syllabaries and the Kanji ideographs imported from China). Note that this sense of the word 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 designed as a method for connecting several classes of peripherals to a host system without requiring modifications to generic hardware and software.

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 PC system design that does not provide end-user–accessible internal expansion slots. This is the equivalent of "no user-serviceable parts inside" for consumer electronics or appliances. 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, but it 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.

Secure Digital Music Initiative (SDMI)

An organization that sets standards for secure digital music. One of the main goals of SDMI is to create a framework for the secure distribution of music from the Internet to personal computers and portable devices.

Separators

Symbols used to 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 time-stamped music data stream and sends packets to music hardware as their time comes due.

server system

A computer using the specific Windows operating system that the test device is acquiring a logo for. This computer must also have the reference device installed.

SES

1. storage enclosure services

2. Solution Exchange Standard

SETP

Secure Electronic Transactions Process

SFA

sales force automation

SFF

Small Form Factor

SFM

Services for Macintosh

SFP

System File Protection

SFS

shared file system

SHA

Secure Hash Algorithm

SID

Subsystem ID

SIG

special interest group

signable

The capability of having a test device driver digitally signed.

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.

sink

In terms of device stacking in DirectShow, indicates that a pin represents possible connections that are attached to, rather than those that attach. Compare with source.

SIP

sound input peripheral

SIPC

Simply Interactive PC

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

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, including 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, as well as bus arbitration.

SMBus interface

ACPI defines a standard hardware and software communications interface between an operating system bus driver and an SMBus controller using an embedded controller.

SMI

system management interrupt

SMP

symmetric multiprocessing

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. A remote-procedure call mechanism based on XML that sends commands and receives values over HTTP.

SO/CO

Service Office/Central Office

socket services

In Windows, 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 that is used.

software device

A filter in kernel streaming and DirectShow (formerly ActiveMovie) that has no underlying hardware associated with it.

software modem

Also host-based signal processing or pumpless modem. Performs signal processing on the host CPU and implements the controller using V.42bis. The modem hardware consists of a telephone-line interface and digital-to-analog and analog-to-digital conversion circuitry. 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 for MS-DOS–based games one of the major hardware interfaces for both audio and music (specifically MIDI) data.

source

In terms of device stacking in kernel streaming or DirectShow, indicates that a pin represents possible connections that attach, rather than those that are attached to. Compare with sink.

SP

1. service pack (example: Windows NT 4.0 SP4)

2. service provider

S/PDIF

Sony/Phillips Digital Interface Format. The current standard for digital connection to consumer audio devices is the S/PDIF connector. Microsoft is encouraging the use of USB or IEEE 1394 as the digital connection between stereo equipment and PCs rather than adapting S/PDIF to meet PC needs.

Specular highlighting

A highlight or reflection observed on any shiny surface. Highlighting on shiny surfaces is caused by specular reflection (whereas normal reflection is diffused reflection). Specular reflection tends towards the color of the light source, rather than the normal reflected color of the object.

SPI

Service Provider Interface. Component in Microsoft networking, TAPI, and other communications technologies.

SPID

service profile identifier

spin down

A power-management capability in which a hard drive shuts down its spindle motor.

SPX

Sequenced Packet Exchange

SQL

Structured Query Language, Commonly pronounced "sequel," a database query and programming sub-language originally developed for IBM mainframe computers. There is now an ANSI-standard SQL definition for all computer systems.

SRAM

static RAM

SRB

stream request blocks

SRC

1. sample rate converter

2. seamless rate change

sRGB:

Standard RGB is a standard colorspace derived by Microsoft and HP, integrating installed base average monitor gammas and whitepoint standard values from broadcast studio recommendation ITU 709.

SSA

Serial Storage Architecture

SSDP

Simple Service Discovery Protocol

SSE

Streaming SIMD Extensions. In the context of this document, SSE is used to denote a metric of similarity, which we call Sum of Squared Errors. Given image components I and I’, this is computed on an h*w block as

.

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

static resources

Device resources, such as IRQ signals, DMA channels, I/O port addresses, and memory addresses, that cannot be configured or relocated.

static VxD

A VxD that is loaded statically during system startup. A static VxD can be loaded in a number of different ways, including device enumeration by the Plug and Play static device enumerator.

STB

set-top box

stepping

Versions of processors are referred to as steppings. Lower steppings come before higher steppings, each stepping has a set of errata and fixes associated with it.

STI

Microsoft Windows Still Imaging Architecture that is supported in Windows 98 and in Windows 2000.

Still Image Architecture

A WDM architecture for still-image devices. A still-image minidriver provides support for still-image devices such as scanners and cameras under the WDM Still Image architecture.

Still Image plug-in

In the Still Image class architecture, a module that manages the translation of standard DDI calls to device-specific sequences in order to support vendor-specific device features.

STLP

Secure Transport Layer Protocol

stream

An object representing an entity on an adapter capable of receiving, processing, or supplying data. Notice that a stream is identical to a WDM Stream architecture pin. A stream can accept data from or supply data to the processor, such as a stream representing an MPEG input, or can simply route data through hardware, such as a stream representing an NTSC output jack on the back of an adapter. The purpose of representing non-data hardware with a stream is that the properties of the hardware can be controlled by software.

streaming

A method of delivering content in which content located on a server is transmitted across a network in a continuous flow and then used by client software. By streaming data, the player can begin rendering the content immediately instead of waiting for an entire file to be downloaded.

STS/EN

Status and Enable bits (ACPI)

STT

Secure Transaction Technology

SU

Selector unit

SVC

switched virtual circuit

SVD

Simultaneous voice/data. A technology used in TAPI-based modem technology.

SVGA

Super VGA. A video standard established by VESA to provide high-resolution color display on IBM-compatible computers. The most commonly implemented SVGA standard is 1024x768 pixels resolution.

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 for improved quality over composite video. The type of video signal used in the Hi8 and S-VHS videotape formats. It transmits luminance and color portions separately, using multiple wires, thus avoiding the NTSC encoding process and its inevitable loss of picture quality.

SW RAID

This is what is meant when using the Windows NT Server Ftdisk driver or Windows 2000 "dynamic disks" to take several physical disks and make one logical fault-tolerant (FT) volume out of them.

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.

symmetrical compression

A compression system that requires equal processing capability for compression and decompression of an image. This form of compression is used in applications in which both compression and decompression are used frequently. Examples include still-image databasing, still-image transmission (color fax), video production, video mail, videophones, and video conferencing. Compare with asymmetrical compression.

Synchronization Manager

A centralized location for the user to synchronize all personally-owned offline data. It provides a common UI that a mobile user can use to prepare a computer for use away from a network.

synchronous

Any operation that proceeds under control of a clock or timing mechanism. Compare with asynchronous.

Synchronous Access Mode

Defined by V.80, S.A.M. allows the data protocols in a modem to be bypassed and allow any arbitrary, non-traditional protocol to be implemented in the host (such as H.324 video telephony systems).

system board

Also motherboard or planar. The primary circuit board in a system that contains most of the basic components of the system.

system context

The volatile data in the system that is not saved by a device driver.

system devices

Devices on the system board, such as interrupt controllers, keyboard controller, real-time clock, DMA page registers, DMA controllers, memory controllers, FDC, ATA ports, serial and parallel ports, PCI bridges, and so on. These devices are typically integrated in the supporting chip set.

System Locale

Not really a locale. Determines which script non-Unicode applications will support. It is the locale emulated by the system, as seen by applications.

For example, if the system locale for US Windows 2000 is set to Hebrew, then ANSI applications will see it as Hebrew localized Windows 2000, although the user interface of the system will still be in English.

The system locale is system wide, in that it applies to all users. Changing the system locale requires a reboot.

Systems Management Server

Provides a centralized management service for distributed systems.

T

TAPI

Telephony Application Program Interface. A set of Win32-based calls that applications use to control modems and telephones by routing application function calls to the appropriate service provider DLL for a modem.

TB

terabyte

TBD

To be determined

TC

traffic control

TCO

total cost of ownership

TCP

Transmission Control Protocol

TCP/IP

Transport control protocol/interface program. A software protocol developed by the Department of Defense for communications between computers.

TDD

Telephone Device for the Deaf

TDI

Stands for Transport Driver Interface. TDI allows you to write new transport drivers that are independent of the network card. You can also write network applications to use TDI rather than relying on a certain protocol, such as NetBIOS or IPX.

TDM

time division multiplexing

TDMA

time division multiplexing access

TE

terminal equipment

Telecine

A name for a process of converting to Television field rates from Cinematography frame rates. The process is sometimes referred to as 3:2 pulldown. In this process, 24 frame per second film frames are post processed to generate two streams of fields, yielding 48 fields per second. The resulting field streams are upsampled by replicating selected fields at a rate of one replication for every four original source fields. To provide a more visually pleasing result, the phase of this replication is different in each stream. The resulting video content, when viewed in a progressive environment, is seen to consist of three ‘good’ frames – frames where both fields came from the same film source frame – and two ‘bad’ frames– where the fields are from different film source frames. Note: It is possible, if this is the only processing the film/video has been subjected to, to reconstruct the original film source field pairs and thus the original film frames. In practice, video post production frequently involves any of several steps that interfere with the ability to do this. Video mode edits, and compositing with material originally produced as video (interlaced scan with a difference in time between the interlaced samples) are two examples of such steps. Telecine is sometimes used to name a machine that implements the process.

telephony

Telephone technology.

telset

local telephone instrument

Test assertion

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 a feature implementation.

texel

Individual elements of a texture map. A texture map is a digitized or synthesized image which can be "mapped" onto a surface.

TFTP

Trivial File Transfer Protocol

TGT

Ticket Granting Ticket

THD+N

total harmonic distortion plus noise

thin client

Small client software layer for a centrally managed, network terminal, allowing the user access to server-hosted applications and data.

Thread Locale

The locale of a given thread. Gets inherited upon creation from the current User Locale and can be changed at run time to any valid locale (per thread). Calls to NLS APIs can use this locale to format numbers, date, time ...

TIA

Telecommunications Industry Association

timecode

For MPEG, frame-by-frame address code time reference 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.

TinyTP

IrDA transport protocol

TLC

Third-level cache

TLS

Transport Layer Security protocol

top down (order)

Arrangement of pixel data in memory with the lowest addressed pixels corresponding to the upper left corner of the image, proceeding 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.

TREC

Texture and Rendering Engine Compression

TSD

type-specific driver

TSP

TAPI call control service provider

TSR

Terminate and Stay Resident, A program running under MS-DOS that remains loaded in memory even when it is not running so that it can be quickly invoked for a specific task performed while any other application program is operating.

TTL

transistor-transistor logic

tuple

A data structure defined by the PCMCIA to describe a single, specific characteristic of a PC Card device. Tuples are chained together to form the CIS, which describes to system software the PC Card’s resource requirements and other characteristics. Tuples consist of a tuple code, an offset to the next tuple, and a number of bytes specific to the tuple.

TVCF

Telephone Voice Call First model (also known as V.8 prime or V.8’). Available on data/fax modems that support H.324 video telephony.

TWAIN

API for image acquisition developed by an association of industry leaders. The specification is available from http://www.twain.org.

TXD

transmission data (also XOR)

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 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. This area of memory is normally reserved for running system hardware such as the monitor.

3. Unified Memory Architecture

UMB

Upper Memory Block. An area of the UMA that is not currently in use. Adapter Cards use upper memory block addresses. Device drivers and TSRs can be loaded into the UMBs with the correct software and hardware.

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

Unicode is a large character set that includes most of the world’s languages. It is 16-bits encoding. This allows 65,000 characters. This form is called UCS-2, i.e., Universal Character Set 2-bytes. Unicode is the first level of ISO 10646, and it is also called a BMP (Basic Multilingual plane) or Plane Zero

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.

Uniscribe

The Unicode Script Processor built into Windows 2000. Uniscribe supports line measurement, display, caret movement, character selection, justification, and linebreaking, of Unicode plaintext and rich text. Uniscribe covers most characters in Unicode.

universal naming convention (UNC)

The system for indicating names of servers and computers, such as //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 that ensures that electrical flow to the computer is not interrupted because of a blackout and, in most cases, 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 electrically closest to the host that 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 bidirectional, isochronous, dynamically attachable serial interface for adding peripheral devices such as game controllers, serial and parallel ports, and input devices on a single bus.

USB class

The class of filters under WDM that provides a bus interface and bus enumerator for USB.

USBD

1. USB driver

2. USB device

User Interface (UI) 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, numbers, etc. The user locale is a per-user setting, and does not require a reboot or logoff/logon. See also Locale, System Locale, Input Locale, and User Interface (UI) Language).

user mode

The nonprivileged processor mode in which application code executes, including protected subsystem code in Windows NT and Windows 2000.

user-mode drivers

Microsoft Win32-based multimedia drivers and VDDs for MS-DOS–based applications with application-dedicated devices. For more information, see the Multimedia Drivers and Virtual MS-DOS Drivers documentation in the Windows NT and Windows 2000 DDKs.

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 also World Time. It is expressed using a 24-hour clock.

UTP

unshielded twisted pair

V

V

volt

V.250

ITU-T Recommendation, which 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 modem ID, port control, modulation control and reporting, error control, and data compression control and reporting.

V.251

ITU-T Recommendation which specifies a standard set of commands that enables the DTE (PC) to use V.25, V.8, and 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 which defines procedures for starting sessions of data transmission over a GSTN.

V.8 bis

ITU-T Recommendation which defines procedures for the identification and selection of common modes of operation 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 (defined after H.324 was approved, but before V.8 bis), which provides an interim method of transitioning from telephony to H.324 during an existing voice call. Also known as "Voice Call First."

V.80

ITU-T Recommendation which defines in-band DCE control and synchronous data modes for asynchronous DTE.

VA

Video acceleration

VAR

Value added reseller. A company that resells hardware and software packages to developers and/or end users.

VBE

VESA BIOS Extension

VBI

Vertical blanking interval. The time interval between television fields needed for the scanning gun to move from the bottom to the top of the screen for the start of the next field.

VBR

variable bit rate

VC

1. virtual circuit

2. virtual channel

VCACHE

In Windows, a 32-bit protected-mode cache driver.

VCDFSD

virtual CD-ROM file system driver

VCF

Voice Call First model (also known as V.8 prime). Available on voice modems that support H.324 video telephony.

VCI

virtual channel identifier

VCOMM

In Windows, a 32-bit protected-mode communications driver.

VCR

Video cassette recorder. An analog magnetic recording and playback machine. Usually used for recording and viewing full-motion video; 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

2. virtual device manager

3. video display metafile

VDMA

virtual DMA

VDMAD

virtual DMA device

VDS

virtual DMA services

vector graphics

Images defined by sets of straight lines, defined in turn 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

Video graphics array. A video adapter that supports 640x480-pixels color resolution. Video display standard for boot devices under Windows operating systems. Provides medium-resolution text and graphics.

VHF

very high frequency

VHN

video home network

video codecs

Full-color video. Requires 3 bytes per pixel, at 640x480 resolution; equals nearly 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 uncompressed digital video information.

Visual order

The ordering used to display glyphs on a screen, printed page, or other medium. Usually used with bi-directional text, because reordering is required to go from logical order to visual order. Contrast 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.

VMR

Video mixing renderer

VoIP

Voice over Internet Protocol

VPE

Video Port Extensions. Extensions to the DirectDraw API to 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

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. Can extend the services of the Windows kernel, supervise hardware operations, or perform both functions. Such driver files are usually named according to the scheme VxD, where x refers to the device or service supported.

W

W3C

World Wide Web Consortium

WAN

Wide area network. A communications network that connects geographically separated areas. Compare with LAN.

warm docking

A method of removing or installing a mobile system in a docking station with which the computer can be docked or undocked while in a reduced power state, such as suspend.

watchdog (timer or driver)

A hardware device used to monitor continuing system health and functionality through communications with the system software using a dedicated device driver.

WBEM

Web-based Enterprise Management. A DMTF initiative to provide a standards-based mechanism to specify information exchange between management applications and managed components. This work was recently transferred to the DMTF by BMC Software, Inc., Cisco Systems, Inc., Compaq Computer Corporation, Intel Corporation, and Microsoft Corporation.

WC

write combining

WDCTRL

Western Digital–compatible hard disk controller

WDL

Windows Driver Library. See WHQL.

WDM

Windows Driver Model. A 32-bit driver model based on the Windows NT driver model that is designed to provide a common architecture of I/O services for all Windows operating systems for specific classes of drivers. A driver model based on the Windows 2000 driver model that is designed to provide a common architecture of I/O services and binary-compatible device drivers for both Windows 2000 and Windows operating systems for specific classes of drivers. These driver classes include USB and IEEE 1394 buses, audio, still-image capture, video capture, and HID-compliant devices such as USB mice, keyboards, and joysticks. Provides a model for writing kernel-mode drivers and minidrivers, and provides extensions for Plug and Play and power management.

WDM Comm

WDM Communications Class

WDMCSA

WDM Connection and Streaming Architecture

WDM DDK

Provides the supplementary header files used together with the Windows NT DDK to build WDM drivers.

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 system and for detecting device idleness. IRPs are defined for setting power sate, enabling wakeup, and querying power status.

WDM streaming

A WDM-based kernel-mode extension of DirectShow, providing kernel connection and streaming services as used by the WDM Stream class driver and system software components provided in future versions of all Windows operating systems, such as the cross-process audio mixer and sample rate converter. 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 have 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

WFP

Windows File Protection

WHIIG

Windows Hardware Instrumentation Implementation Guidelines

Whistler

Code name for next version of the Windows 2000 operating system, based on NT technology.

whitepoint

Whitepoint is the color produced by the device as it makes 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. Provides compatibility testing services to test hardware and drivers for all Windows operating systems. Administers testing for the "Designed for Microsoft Windows" logo programs. For more information, see the Web site at: http://www.microsoft.com/hwtest/.

WIA

Windows Image Acquisition

Win32 API

A 32-bit application programming interface for Windows operating systems that includes sophisticated operating system capabilities, security, and API routines for Windows-based applications.

Windows

Refers to the entire family of Microsoft Windows operating systems, including Windows 98, Windows 2000, and any add-on capabilities and any later versions of the operating system.

Windows 2000

The Microsoft Windows 2000 operating system, including any add-on capabilities and later versions of the operating system.

Windows driver model

See WDM.

Windows installer service

Provides end users with a way to install and remove applications, or components of software as needed. System administrators can more easily manage applications and support roaming users.

Windows Management Instrumentation

Extensions to WDM developed for Windows 2000 and Windows to provide an operating system interface through which 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 either can run as a stand-alone client executable program or 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 that are used to convert audio data into a specified digital format for convenient storage and retrieval using computer technology, usually involving compression and encryption technology.

Windows NT

Refers to the Microsoft Windows NT version 5.0 operating system, including any add-on capabilities and any later versions of the operating system, unless specific design issues are defined that relate to version 5.0.

Windows NT driver model

The layered device driver model used under the Windows NT operating system. For information, see Inside Windows NT, by Helen Custer (Microsoft Press, 1993).

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

WMI

Windows Management Instrumentation. Extensions to WDM developed for Windows 2000 and Windows 98 to provide an operating system interface through which instrumented components can provide information and notifications.

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 Unicode supported language scripts and data relating to specific geographic areas, and

2. It has been designed and coded to allow the localization of its data and resources to be as close to being just a translation process as possible.

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 supporting WC memory combine several partial (line) write transactions into a single line write transaction, using 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

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. A video adapter produced by IBM capable of 1024 x 768 resolution and 256 colors.

XML

Extensible Markup Language

XMS

Extended-Memory Specification, A specification developed by Lotus, Intel, Microsoft, and AST Research that defines a software interface that allows real-mode applications to use extended memory and certain areas of conventional memory not managed by DOS.

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 for transmitting color video images while maintaining compatibility with black-and-white video. Uses less bandwidth than the three separate video signals in an RGB video transmission. Consists of two major components: luminance (Y), which corresponds to the brightness of an image pixel, and 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.

ZAK

Zero Administration Kit for Windows NT Workstation

ZAW

Zero Administration Windows

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.

Zero Administration initiative for Windows

Also Zero Administration initiative. An initiative that focuses on improving Windows and Windows NT for maximum automation of administrative tasks with centralized control and maximum flexibility.

ZIPI

A MIDI-like serial data format for musical instruments. Provides a more hierarchical method of addressing instruments and an extensible command set.

ZV

Zoomed Video