This document provides a cookbook approach to performing interoperability testing of USB devices and hubs. The procedures assume that the reader understands which tests are applicable, and reading the procedures before executing them is strongly recommended. Although these guidelines appear to be extensive, they outline the minimum testing that should be required prior to shipping a USB product. It is required that prior to beginning testing, all systems that will be used in the testing be configured with a fresh installation of the operating system. Two drive images will need to be captured before beginning interoperability testing. These images provide a means for timely recreation of a failing scenario as well as verification of problem resolution. These images will also allow for quick restoration of the test environment in the event of a system lock-up or other catastrophic problem. The content of these images will be outlined later in this document. This document also outlines requirements for performing testing. These requirements include: System platforms Software applications, drivers, and tools Other USB devices, other than the Device Under Test or the Hub Under Test. It is recommended that these be procured prior to beginning testing in order to expedite the testing process. USB interoperability is the ability of a USB device to operate, without side effects, in the presence of other USB devices. Interoperability testing of USB is necessary because of the nature of the architecture. USB provides the opportunity for an end-user to add and remove devices to a system without ever opening up the system chassis or removing power from the system. There are few limitations of the architecture, and therefore the number of devices and the variation of device mix are virtually unpredictable. This document is intended to provide a cookbook approach for performing interoperability testing for: A USB device without other USB devices A USB device with other USB devices A USB hub-type device There are some features of USB that add complexity to interoperability testing. Device driver must be able to handle system power state change requests gracefully. While idle, a device driver must allow the system to enter a sleep state. However, while idle there are cases in which a device driver might be allowed to prevent the system from entering a sleep state. For more information on this topic, see the white paper, Understanding WDM Power Management, in the whitepapers section on USB-IF website at http://www.usb.org/developers/whitpapr.html. Since USB has dynamic plug and play capability, the system hardware and operating system immediately detect a device attached to or removed from the system. This requires a device driver to be dynamically loaded and unloaded. In addition, an end-user has the ability to add and remove devices to the system configuration or reboot the system at any time. This also provides opportunity to have a dynamic system topology, where the end-user can move devices from one place to another. An end-user has the ability to expand the number of devices added to a system. Typically the system has two USB ports, and the end-user can add additional ports to the system by use of USB hubs, allowing up to 126 devices to be added behind a single USB host controller. USB has limited bandwidth. This bandwidth is dynamic, meaning that bandwidth can be consumed as devices become active and also may not be available when a device attempts to activate. Device drivers must be aware of this and handle the situation gracefully. The following tables outline the minimum list of items that must be available in order to complete USB interoperability testing. Additional devices can be added to this configuration to expand the testing environment. How many Device Manufacturer Description 1 UHCI host controller UHCI system or add-in card 1 OHCI host controller OHCI system or add-in card Software Version Description Location Windows 98 SE 4.10.2222A USB-IF compliance tool environment UsbCheck.exe 3.2 or later USB-IF compliance test http://www.usb.org/developers/tools.html Hidview.exe 3.6 or later USB-IF compliance test http://www.usb.org/developers/tools.html Linux 2.3.99 or later Operating System kernel http://www.kernel.org GNU/Linux distribution To be specified Linux user environment Additional Device Driver (if any) Test Application (if any) isoc-soak Linux bandwidth consumption program Not yet available Below is a listing of suggested devices used for testing. These devices are not required, but are suggested. What is required is that the selected devices provide data transfers via isochronous, bulk, and interrupt protocols. How many Device Manufacturer Description 2 Device Under Test Device to be tested 1 Similar device Same class device as Device Under Test Not required for hub testing 1 Internet Keyboard Pro Microsoft Composite Keyboard/Hub 1 M-BA47 Logitech Wheel Mouse 3 Hub 4 (or more) port self-powered or bus-powered and self-powered hub 1 Hub 4 port bus-powered or bus-powered and self-powered hub 1 DSS350 Philips Speakers 1 Zip 250 Drive Iomega Mass Storage 1 HP895C Hewlett Packard Printer 1 1595 Zoom Telephonics Digital video camera 5 5 metre cable USB A-B cable For the purposes of this document, USB interoperability is the defined as the ability of one USB device to operate, without side effects, in the presence of other USB devices. The goal is an enjoyable end-user experience. USB devices should operate as the end-user would expect. All hub vendors and device vendors should do device interoperability testing. Performing interoperability testing in all hardware areas will ensure the overall health of the USB technology. Broad consumer acceptance of USB should be the goal of the entire USB community. Interoperability testing should be done as part of the development cycle. Due to the time involved in doing this testing, it is recommended that this testing be done a minimum of three times in the development phase. Interoperability testing can flush out problems with hardware, device drivers, and application software. Interoperability testing is not intended to be part of the manufacturing process. The following is a list of side effects that must not occur during USB interoperability testing. This is a list of the most frequent side effects, and is not meant to be a complete list. Any side effect in addition to those on this list must be resolved prior to production release of the Device Under Test. Core dumps, kernel oopses and kernel panics are never acceptable. Host controller drivers, device drivers and applications should handle all situations gracefully, informing the end-user of any issues that occur with either a device or limited resources. Device attach and device driver load should not cause or require the system to reboot. Linux systems should require reboot only after a kernel upgrade. At no time should a device or device driver cause the operating system to hang. Again, the end-user should be informed of limitations on required resources, system resources or USB resources. USB devices are expected to be available at all times after the device is attached. Application software should check to ensure that the USB device is available before attempting to connect the device driver to the USB device. The end-user should be informed of any issues when connecting to the device. To re-iterate, the ultimate concern is the end-user experience. In short, the device and associated software should operate as the end-user would expect. Again, remembering that USB is a dynamic plug and play bus, several end-user scenarios are required to be tested. The end-user plugs the device into a USB port while the system is powered. The system hardware and system software will recognize the device, and load the appropriate device drivers as necessary. Device drivers MUST be able to be loaded without any application software being installed. This means that device drivers MUST be outside any application setup program. If the device requires application software in order to operate, then application software will be required to be loaded. The USB device, device driver, and application software must be able operate directly after application installation. Application installation cannot be required prior to attaching the device to the system. Device drivers must be outside any application setup program. After the device is attached to the system, the end-user may reboot the system without turning off power to the system. This is referred to as a warm reboot. The USB device, device driver, and application software must be able operate after the warm reboot. After the device is attached to the system, the end-user may shut down the system, that is turn off power, and power the system up again. This is referred to as a cold boot. The USB device, device driver, and application software must be able operate after the cold boot. After the device is attached to the system, the end-user may detach the device at any time, then reattach the device. This is referred to as asynchronous device detach and reattach to the same USB port. No driver installation disk should be required after reattach. The USB device, device driver, and application software must be able operate after device detach and reattach. After a device is attached to the system, the end-user can detach the device and attach it at another port in the USB topology. The USB device, device driver, and application software must be able operate after USB topology changes. The USB device and device driver must be able to operate after device topology changes. The end-user may choose to remove the application software associated with the device. The application software removal process needs to be tested to ensure that it is clean and complete. Application software removal must not cause other devices in the system to stop operating. Device interoperability starts with device operability. Device operability is defined as a device operating, without side effects, in typical end-user scenarios, without the presence of other USB devices. A USB device must be able to operate by itself in a system prior to pursuing device interoperability. Device operability tests will ensure solid robust operation before moving on to interoperability testing. There are two drive images that will be used when performing device operability and interoperability testing. These images are used to quickly refresh the system after lock-ups or system instability. These images would also be used after problem identification and resolution have been completed and retest is required. By using these drive images, problems can be reproduced quickly and easily. Before each test in the checklists in Appendix B, there will be a statement as to which drive image to use prior to beginning testing. This disk image is created from a fresh Linux distribution installed, possibly with a kernel upgrade performed. The USB drivers that are required to be installed are the UHCI host controller driver, the OHCI host controller driver and the usbdevfs driver. For non-hub devices, the appropriate kernel driver should also be installed. The primary purpose of this drive image is to allow for initial device operability testing. This image will also be used when performing Device Under Test installation prior to the Gold Tree device installation. This image is taken immediately after operating system configuration and installation has completed. This disk image is created from a fresh Linux distribution installation, with additional Gold Tree device drivers and associated applications installed if not already included. The purpose of this drive image is for Gold Tree device interoperability testing. This image is taken after the operating system is installed and appropriate drivers are configured, and the entire Gold Tree of devices is attached and associated applications are installed. It is assumed that the test machine has at least two partitions, one for the test configuration, and one as a test management environment. The space available for the test management environment needs to be contain sufficient free space to contain two additional files, each the size of the test configuration partition. For example, given a 6G hard drive, create a 1G partition and a 5G partition. Install the development / test management environment on the 5G partition, ensuring that at least 2G remains free on this partition. Then install the test configuration on the 1G hard drive. Depending the Linux distribution installed, it may be neccessary to perform a kernel upgrade as described in the Linux Kernel HOWTO. Make the first test image using dd. Typical usage, if the test configuration is installed on the first extended partition of the first ide drive would be dd if=/dev/hda5 of=CleanOSBuild bs=8192. Install any additional drivers neccessary for the Gold Tree. With the standard Gold Tree, this should only require building and installing the drivers present in the kernel tree. Make the second test image using dd. Typical usage, if the test configuration is installed on the first extended partition of the first ide drive would be dd if=/dev/hda5 of=GoldTreeBuild bs=8192. Record the following information: Manufacturer, part number and serial number of Device(s) Under Test Manufacturer, part number and serial number of similar device Full details of Gold Tree devices and host controllers Linux kernel version and contents of /usr/src/linux/.config Linux distribution tested Date and time of test start Device compliance tests are essentially independent of the operating system environment and other devices. If compliance testing has been previously completed, it need not be repeated. The compliance tests applicable to devices are: Power consumption requirements, which is to be performed in accordance with http://www.usb.org/developers/data/currentDraw.pdf Device framework (Chapter 9 tests) in accordance with http://www.usb.org/developers/data/usbcomp.exe, including HIDview testing if applicable. Signal quality in accordance with http://www.usb.org/developers/data/usbsignalquality.pdf The USB-IF compliance tests verify that a device responds correctly to USB device commands, and any failures or other problem indications must be resolved before continuing with later tests. This process can not be performed with Linux at this time, and is provided in anticipation of a suitable tool being developed. Run the isoc-soak program and verify that the Device Under Test gracefully handles limited isochronous bandwidth situations. This application will consume increasingly larger amounts of USB bandwidth, and should be started just prior to plugging the Device Under Test. Isochronous device applications are required to notify the user of this limited bandwidth issue and provide possible resolutions. This test is designed to show basic operation, and is primarily to ensure that the Device Under Test and driver combination is functional before later tests. Install the CleanOSBuild image using something like the following command: dd if=CleanOSBuild of=/dev/hda5 bs=8192. Perform all typical end-user scenarios at one root port on the UHCI controller in the system: Hot attach - no installation is required. Application installation - if required to show functionality Warm boot - system remains functional Cold boot - system remains functional Asynchronous detach and reattach USB topology change - no driver modification required If any problems occur during this scenario, they need to be resolved prior to continuing to subsequent tests. This test is designed to show basic operation, and is primarily to ensure that the Device Under Test and driver combination is functional before later tests. Install the CleanOSBuild image using something like the following command: dd if=CleanOSBuild of=/dev/hda5 bs=8192. Perform all typical end-user scenarios at one root port on the OHCI controller in the system: Hot attach - no installation is required. Application installation - if required to show functionality Warm boot - system remains functional Cold boot - system remains functional Asynchronous detach and reattach USB topology change - no driver modification required If any problems occur during this scenario, they need to be resolved prior to continuing to subsequent tests. This test is designed to show operation under moderate signal and timing stress. Install the CleanOSBuild image using something like the following command: dd if=CleanOSBuild of=/dev/hda5 bs=8192. Construct a hub tree as follows: Using a five metre cable, connect one self-powered hub to a UHCI root hub port. This self-powered hub is the tier one hub. Connect combined keyboard / hub to port 2 of the tier one hub. This keyboard / hub is the tier two hub. Using a five metre cable, connect one self-powered hub to port 2 on the tier two hub. This self-powered hub is the tier three hub. Using a five metre cable, connect one bus-powered hub to port 1 on the tier three hub. This bus-powered hub is the tier four hub. Using a five metre cable, connect one self-powered hub to port 1 on the tier four hub. This self-powered hub is the tier five hub. Perform all typical end-user scenarios at the ports behind the tier five hub downstream in the system. This should use a five metre cable if the Device Under Test has a removable cable. Hot attach - no installation is required. Application installation - if required to show functionality Warm boot - system remains functional Cold boot - system remains functional Asynchronous detach and reattach USB topology change - no driver modification required If the device operates successfully when attached to the root hub, but does not operate correctly behind external hubs, the most likely problem is the Device Under Test drawing excessive current. If any problems occur during this scenario, they need to be resolved prior to continuing to subsequent tests. This test is designed to show operation under moderate signal and timing stress. Install the CleanOSBuild image using something like the following command: dd if=CleanOSBuild of=/dev/hda5 bs=8192. Construct a hub tree as follows: Using a five metre cable, connect one self-powered hub to a OHCI root hub port. This self-powered hub is the tier one hub. Connect combined keyboard / hub to port 2 of the tier one hub. This keyboard / hub is the tier two hub. Using a five metre cable, connect one self-powered hub to port 2 on the tier two hub. This self-powered hub is the tier three hub. Using a five metre cable, connect one bus-powered hub to port 1 on the tier three hub. This bus-powered hub is the tier four hub. Using a five metre cable, connect one self-powered hub to port 1 on the tier four hub. This self-powered hub is the tier five hub. Perform all typical end-user scenarios at the ports behind the tier five hub downstream in the system. This should use a five metre cable if the Device Under Test has a removable cable. Hot attach - no installation is required. Application installation - if required to show functionality Warm boot - system remains functional Cold boot - system remains functional Asynchronous detach and reattach USB topology change - no driver modification required Devices that do not operating behind a hub, but do operate behind the system root port, are typically due to over-current failures. If any problems occur during this scenario, they need to be resolved prior to continuing to subsequent tests. The end user may have a requirement to have more than one identical device attached to the system. Verify that the device application and device driver operate with multiple identical devices attached to the system. Using the same hub tree as the Fifth Tier Operation - UHCI test, add the second Device Under Test using a five metre cable to a spare port on the tier five hub. If applicable, add the "similar device" to a spare port on the tier five hub. Ensure all three devices are fully functional: Hot attach - no installation is required. Application installation - if required to show functionality Warm boot - system remains functional Cold boot - system remains functional Asynchronous detach and reattach USB topology change - no driver modification required Suspend / Resume - functional after resume Suspend / Remote-wake (if applicable) - functional after wake-up The end user may have a requirement to have more than one identical device attached to the system. Verify that the device application and device driver operate with multiple identical devices attached to the system. Using the same hub tree as the Fifth Tier Operation - OHCI test, add the second Device Under Test using a five metre cable to a spare port on the tier five hub. If applicable, add the "similar device" to a spare port on the tier five hub. Ensure all three devices are fully functional: Hot attach - no installation is required. Application installation - if required to show functionality Warm boot - system remains functional Cold boot - system remains functional Asynchronous detach and reattach USB topology change - no driver modification required The philosophy behind device interoperability is to start with a known good topology, known as a Gold Tree. The Gold Tree is a group of devices that have been proven to have no interoperability problems. It is permissable to use an alternate tree to that described in this procedure, however this must be fully recorded and any major variances justified. Construct the Gold Tree as follows: Using a five metre cable, connect one self-powered hub to a UHCI root hub port. This self-powered hub is the tier one hub. Connect combined keyboard / hub to port 2 of the tier one hub. This keyboard / hub is the tier two hub. Using a five metre cable, connect one self-powered hub to port 2 on the tier two hub. This self-powered hub is the tier three hub. Using a five metre cable, connect one bus-powered hub to port 1 on the tier three hub. This bus-powered hub is the tier four hub. Using a five metre cable, connect one self-powered hub to port 1 on the tier four hub. This self-powered hub is the tier five hub. Add the Logitech Wheel Mouse to port 1 on the tier one hub. Add the Iomega Zip250 drive to port 2 on the tier three hub. Add the Philips DSS350 speakers to port 2 on the tier four (bus powered) hub. Add the Zoom 1595 camera to port 1 on the tier five hub. Load the GoldTreeBuild image using something like the following command: dd if=GoldTreeBuild of=/dev/hda5 bs=8192. Boot to the Gold Tree configuration. If not already mounted, mount the usbdevfs file system using the following command: mount -t usbdevfs usbdevfs /proc/bus/usb. If the Device Under Test has a detachable cable, remove the supplied cable and use a five metre cable for tests. Connect the Device Under Test to a spare port on each hub. Ensure that the Device Under Test is fully and correctly enumerated at each port. It may be neccessary to check the contents of /proc/bus/usb/devices to verify this. Also check that if an appropriate driver is built into the kernel, the device is correctly associated with the driver, or that if an appropriate driver is not built into the kernel, the user is provided with instructions on what action is required. This test shall be recorded as a failure if any of the following occur: device is incorrectly enumerated device will not fully enumerate kernel oops, panics, locks up or reboots device is not associated with a driver and does not make it clear what action the user needs to take to install a driver user action required involves a reboot If neccessary, install the required user space software. This test shall be recorded as a failure if any of the following occur: installation does not complete without core dump installation requires reboot library dependencies or other installation conflicts cannot be automatically resolved If the device is provided with specific drivers that are meant to be used instead of the normal kernel drivers, install them now. The new driver should be recognised by the kernel and reported in /proc/bus/usb/drivers . This test shall be recorded as a failure if any of the following occur: installation does not complete without kernel oopses, panics, reboots or lock-ups installation requires reboot any device stops working Disconnect the USB Gold Tree from the root hub on the UHCI controller and connect the whole tree to a root hub port on the OHCI controller. Load the GoldTreeBuild image using something like the following command: dd if=GoldTreeBuild of=/dev/hda5 bs=8192. Boot to the Gold Tree configuration. If not already mounted, mount the usbdevfs file system using the following command: mount -t usbdevfs usbdevfs /proc/bus/usb. Connect the Device Under Test to a spare port on each hub. Ensure that the Device Under Test is fully and correctly enumerated at each port. It may be neccessary to check the contents of /proc/bus/usb/devices to verify this. Also check that if an appropriate driver is built into the kernel, that the device is correctly associated with the driver, or that if an appropriate driver is not built into the kernel, that the user is provided with instructions on what action is required. This test shall be recorded as a failure if any of the following occur: device is incorrectly enumerated device will not fully enumerate kernel oops, panics, locks up or reboots device is not associated with a driver and does not make it clear what action the user needs to take to install a driver user action required involves a reboot If neccessary, install the required user space software. This test shall be recorded as a failure if any of the following occur: installation does not complete without core dump installation requires reboot library dependencies or other installation conflicts cannot be automatically resolved If the device is provided with specific drivers that are meant to be used instead of the normal kernel drivers, install them now. The new driver should be recognised by the kernel and reported in /proc/bus/usb/drivers . This test shall be recorded as a failure if any of the following occur: installation does not complete without kernel oopses, panics, reboots or lock-ups installation requires reboot any device stops working Ensure that all devices in the Gold Tree are fully functional. If any device is not fully functional, or causes a kernel oops, panic, reboot or lock-up during operation, record this test as a failure. Set system to play an MP3 (of Van Halen's "Dreams") from the Zip250 drive to the USB speakers. Display streaming video from the Zoom 1595 camera. Disconnect the Logitech Wheel Mouse from the tier one hub and plug it into the spare port on the tier two hub. Ensure that the Device Under Test continues to operate normally under this load. Ensure that the Gold Tree devices continue to operate normally. Ensure that Device Under Test is stopped. Detach Device Under Test. Reattach Device Under Test to the hub port it was detached from. If the Device Under Test is not fully functional, or the Detach / Reattach causes a kernel oops, panic, reboot or lock-up during operation, record this test as a failure. Ensure that Device Under Test is in use. Detach Device Under Test. Reattach Device Under Test to the hub port it was detached from. If the Device Under Test is not fully functional and has not recovered from the detach, or the Detach / Reattach causes a kernel oops, panic, reboot or lock-up during operation, record this test as a failure. Ensure that Device Under Test is stopped. Detach Device Under Test from the tier five hub . Reattach Device Under Test to port 3 of the tier three hub. If the Device Under Test is not fully functional, or the Detach / Reattach causes a kernel oops, panic, reboot or lock-up during operation, record this test as a failure. Sync filesystems and reboot system using the reboot command. When system is restarted, ensure that the Device Under Test is fully functional. Test is to be recorded as failed if Device Under Test is not fully functional. Sync filesystems and halt system using the halt command. When system is halted, power system off. Wait two minutes. Power system back up and boot into test configuration. When system is restarted, ensure that the Device Under Test is fully functional. Test is to be recorded as failed if Device Under Test is not fully functional. Record the date and time the test finished and summarise test results. Record the following information: Manufacturer, part number and serial numbers of Hubs Under Test Full details of Gold Tree devices and host controllers Linux kernel version and contents of /usr/src/linux/.config Linux distribution tested Date and time of test start Hub compliance tests are essentially independent of the operating system environment and other devices. If compliance testing has been previously completed, it need not be repeated. The compliance tests applicable to hubs are: Power consumption requirements, which is to be performed in accordance with http://www.usb.org/developers/data/currentDraw.pdf Device framework (Chapter 9 and Chapter 11 tests) in accordance with http://www.usb.org/developers/data/usbcomp.exe Signal quality in accordance with http://www.usb.org/developers/data/usbsignalquality.pdf Droop / drop testing in accordance with http://www.usb.org/developers/data/dropDroop_99.pdf The USB-IF compliance tests verify that a hub responds correctly to USB device commands, and any failures or other problem indications must be resolved before continuing with later tests. This test is designed to show basic operation, and is primarily to ensure that the Hub Under Test and driver combination is functional before later tests. Install the CleanOSBuild image using something like the following command: dd if=CleanOSBuild of=/dev/hda5 bs=8192. Perform all typical end-user scenarios at one root port on the UHCI controller in the system: Hot attach - no installation is required. Warm boot - system remains functional Cold boot - system remains functional Asynchronous detach and reattach USB topology change (switch ports) - no driver modification required If any problems occur during this scenario, they need to be resolved prior to continuing to subsequent tests. This test is designed to show basic operation, and is primarily to ensure that the Hub Under Test and driver combination is functional before later tests. Install the CleanOSBuild image using something like the following command: dd if=CleanOSBuild of=/dev/hda5 bs=8192. Perform all typical end-user scenarios at one root port on the OHCI controller in the system: Hot attach - no installation is required. Warm boot - system remains functional Cold boot - system remains functional Asynchronous detach and reattach USB topology change - no driver modification required If any problems occur during this scenario, they need to be resolved prior to continuing to subsequent tests. This test is designed to show operation under moderate signal and timing stress. Install the CleanOSBuild image using something like the following command: dd if=CleanOSBuild of=/dev/hda5 bs=8192. Construct a hub tree as follows: Using a five metre cable, connect one self-powered hub to a UHCI root hub port. This self-powered hub is the tier one hub. Connect combined keyboard / hub to port 2 of the tier one hub. This keyboard / hub is the tier two hub. Using a five metre cable, connect one self-powered hub to port 2 on the tier two hub. This self-powered hub is the tier three hub. Using a five metre cable, connect one bus-powered hub to port 1 on the tier three hub. This bus-powered hub is the tier four hub. Using a five metre cable, connect the Hub Under Test to port 1 on the tier four hub. Perform all typical end-user scenarios at the ports behind the tier four hub in the system Hot attach - no installation is required. Application installation - if required to show functionality Warm boot - system remains functional Cold boot - system remains functional Asynchronous detach and reattach USB topology change - no driver modification required . If the Hub Under Test operates correctly when attached to the root hub, but does not work correctly when attached to the tier four hub, the most likely cause is excessive current draw. If any problems occur during this scenario, they need to be resolved prior to continuing to subsequent tests. This test is designed to show operation under moderate signal and timing stress. Install the CleanOSBuild image using something like the following command: dd if=CleanOSBuild of=/dev/hda5 bs=8192. Construct a hub tree as follows: Using a five metre cable, connect one self-powered hub to a OHCI root hub port. This self-powered hub is the tier one hub. Connect combined keyboard / hub to port 2 of the tier one hub. This keyboard / hub is the tier two hub. Using a five metre cable, connect one self-powered hub to port 2 on the tier two hub. This self-powered hub is the tier three hub. Using a five metre cable, connect one bus-powered hub to port 1 on the tier three hub. This bus-powered hub is the tier four hub. Using a five metre cable, connect the Hub Under Test to port 1 on the tier four hub. Perform all typical end-user scenarios at the ports behind the tier five hub downstream in the system. Hot attach - no installation is required. Application installation - if required to show functionality Warm boot - system remains functional Cold boot - system remains functional Asynchronous detach and reattach USB topology change - no driver modification required If the Hub Under Test operates correctly when attached to the root hub, but does not work correctly when attached to the tier four hub, the most likely cause is excessive current draw. If any problems occur during this scenario, they need to be resolved prior to continuing to subsequent tests. The end user may have a requirement to have more than one identical hub attached to the system. Therefore, it is important to verify that the device application and device driver operate with multiple identical hubs attached to the system. Using the same hub tree as the Fifth Tier Operation - UHCI test, add the second Hub Under Test using a five metre cable to a spare port on the tier four hub. Ensure both hubs are fully functional: Hot attach - no installation is required. Application installation - if required to show functionality Warm boot - system remains functional Cold boot - system remains functional Asynchronous detach and reattach USB topology change - no driver modification required . The end user may have a requirement to have more than one identical hub attached to the system. Therefore, it is important to verify that the device application and device driver operate with multiple identical hubs attached to the system. Using the same hub tree as the Fifth Tier Operation - OHCI test, add the second Hub Under Test using a five metre cable to a spare port on the tier four hub. Ensure both hubs are fully functional: Hot attach - no installation is required. Application installation - if required to show functionality Warm boot - system remains functional Cold boot - system remains functional Asynchronous detach and reattach USB topology change - no driver modification required The philosophy behind hub interoperability is to start with a known good topology, known as a Gold Tree. The Gold Tree is a group of devices that have been proven to have no interoperability problems. It is permissable to use an alternate tree to that described in this procedure, however this must be fully recorded and any major variances justified. Construct the self-powered Gold Tree as follows: Using a five metre cable, connect one self-powered hub to a UHCI root hub port. This self-powered hub is the tier one hub. Connect combined keyboard / hub to port 2 of the tier one hub. This keyboard / hub is the tier two hub. Using a five metre cable, connect one self-powered hub to port 2 on the tier two hub. This self-powered hub is the tier three hub. Using a five metre cable, connect one bus-powered hub to port 1 on the tier three hub. This bus-powered hub is the tier four hub. Using a five metre cable, connect the self-powered Hub Under Test to port 1 on the tier four hub. Add the Logitech Wheel Mouse to port 1 on the tier one hub. Add the Iomega Zip250 drive to port 2 on the tier three hub. Add the Zoom 1595 camera to port 1 on the Hub Under Test (tier five hub). Add the Philips DSS350 speakers to port 2 on the Hub Under Test (tier five hub). Add the Hewlett Packard HP895C printer to port 3 on the Hub Under Test (tier five hub). Load the GoldTreeBuild image using something like the following command: dd if=GoldTreeBuild of=/dev/hda5 bs=8192. Boot to the Gold Tree configuration. Do not load any other software. If not already mounted, mount the usbdevfs file system using the following command: mount -t usbdevfs usbdevfs /proc/bus/usb. Check the contents of /proc/bus/usb/devices to ensure that all devices are correctly enumerated. Ensure that all devices in the Gold Tree are fully functional. If any device is not detected, is not fully functional, or causes a kernel oops, panic, reboot or lock-up during operation, record this test as a failure. Set system to play an MP3 (of Van Halen's "Dreams") from the Zip250 drive to the USB speakers. Display streaming video from the Zoom 1595 camera. Disconnect the Logitech Wheel Mouse from the tier one hub and plug it into port 4 (the spare port) on the Hub Under Test (tier five hub). Ensure that the Hub Under Test continues to operate normally under this load. Ensure that the Gold Tree devices continue to operate normally. Disconnect the Logitech Wheel Mouse from the Hub Under Test (tier five hub) and plug it into port 1 on the tier one hub. Ensure that all device attached to the Hub Under Test (tier five hub) are not in use. Detach Hub Under Test. Reattach Hub Under Test to the hub port it was detached from. If the Hub Under Test, or any other device, is not fully functional, or the Detach / Reattach causes a kernel oops, panic, reboot or lock-up during operation, record this test as a failure. Ensure that the devices attached to the Hub Under Test (tier five hub) are in use. Detach Hub Under Test. Reattach Hub Under Test to the hub port it was detached from. If the Hub Under Test, or any other device, is not fully functional and has not recovered from the detach, or the Detach / Reattach causes a kernel oops, panic, reboot or lock-up during operation, record this test as a failure. Ensure that the devices attached to the Hub Under Test (tier five hub) are not in use. Detach Hub Under Test from the tier four hub. Reattach Hub Under Test to port 3 of the tier three hub. If the Hub Under Test, or any other device is not fully functional, or the Detach / Reattach causes a kernel oops, panic, reboot or lock-up during operation, record this test as a failure. Detach Hub Under Test from the tier three hub, and attach Hub Under Test to port 1 of the tier four hub. Sync filesystems and reboot system using the reboot command. When system is restarted, ensure that the Hub Under Test (tier five hub) is fully functional. Test is to be recorded as failed if the Hub Under Test, or any other device, is not fully functional. Sync filesystems and halt system using the halt command. When system is halted, power system off. Wait two minutes. Power system back up and boot into test configuration. When system is restarted, ensure that the Hub Under Test is fully functional. Test is to be recorded as failed if the Hub Under Test, or any other device, is not fully functional. Construct the self-powered Gold Tree as follows: Using a five metre cable, connect one self-powered hub to an OHCI root hub port. This self-powered hub is the tier one hub. Connect combined keyboard / hub to port 2 of the tier one hub. This keyboard / hub is the tier two hub. Using a five metre cable, connect one self-powered hub to port 2 on the tier two hub. This self-powered hub is the tier three hub. Using a five metre cable, connect one bus-powered hub to port 1 on the tier three hub. This bus-powered hub is the tier four hub. Using a five metre cable, connect the self-powered Hub Under Test to port 1 on the tier four hub. Add the Logitech Wheel Mouse to port 1 on the tier one hub. Add the Iomega Zip250 drive to port 2 on the tier three hub. Add the Zoom 1595 camera to port 1 on the Hub Under Test (tier five hub). Add the Philips DSS350 speakers to port 2 on the Hub Under Test (tier five hub). Add the Hewlett Packard HP895C printer to port 3 on the Hub Under Test (tier five hub). Load the GoldTreeBuild image using something like the following command: dd if=GoldTreeBuild of=/dev/hda5 bs=8192. Boot to the Gold Tree configuration. Do not load any other software. If not already mounted, mount the usbdevfs file system using the following command: mount -t usbdevfs usbdevfs /proc/bus/usb. Check the contents of /proc/bus/usb/devices to ensure that all devices are correctly enumerated. Ensure that all devices in the Gold Tree are fully functional. If any device is not detected, is not fully functional, or causes a kernel oops, panic, reboot or lock-up during operation, record this test as a failure. Set system to play an MP3 (of Van Halen's "Dreams") from the Zip250 drive to the USB speakers. Display streaming video from the Zoom 1595 camera. Disconnect the Logitech Wheel Mouse from the tier one hub and plug it into port 4 (the spare port) on the Hub Under Test (tier five hub). Ensure that the Hub Under Test continues to operate normally under this load. Ensure that the Gold Tree devices continue to operate normally. Disconnect the Logitech Wheel Mouse from the Hub Under Test (tier five hub) and plug it into port 1 on the tier one hub. Ensure that all device attached to the Hub Under Test (tier five hub) are not in use. Detach Hub Under Test. Reattach Hub Under Test to the hub port it was detached from. If the Hub Under Test, or any other device, is not fully functional, or the Detach / Reattach causes a kernel oops, panic, reboot or lock-up during operation, record this test as a failure. Ensure that the devices attached to the Hub Under Test (tier five hub) are in use. Detach Hub Under Test. Reattach Hub Under Test to the hub port it was detached from. If the Hub Under Test, or any other device, is not fully functional and has not recovered from the detach, or the Detach / Reattach causes a kernel oops, panic, reboot or lock-up during operation, record this test as a failure. Ensure that the devices attached to the Hub Under Test (tier five hub) are not in use. Detach Hub Under Test from the tier four hub. Reattach Hub Under Test to port 3 of the tier three hub. If the Hub Under Test, or any other device is not fully functional, or the Detach / Reattach causes a kernel oops, panic, reboot or lock-up during operation, record this test as a failure. Detach Hub Under Test from the tier three hub, and attach Hub Under Test to port 1 of the tier four hub. Sync filesystems and reboot system using the reboot command. When system is restarted, ensure that the Hub Under Test (tier five hub) is fully functional. Test is to be recorded as failed if the Hub Under Test, or any other device, is not fully functional. Sync filesystems and halt system using the halt command. When system is halted, power system off. Wait two minutes. Power system back up and boot into test configuration. When system is restarted, ensure that the Hub Under Test is fully functional. Test is to be recorded as failed if the Hub Under Test, or any other device, is not fully functional. Construct the bus-powered Gold Tree as follows: Using a five metre cable, connect one bus-powered hub to a UHCI root hub port. This bus-powered hub is the tier one hub. Using a five metre cable, connect one self-powered hub to port 2 on the tier one hub. This self-powered hub is the tier two hub. Connect combined keyboard / hub to port 1 of the tier two hub. This keyboard / hub is the tier three hub. Using a five metre cable, connect one self-powered hub to port 1 on the tier three hub. This self-powered hub is the tier four hub. Using a five metre cable, connect the bus-powered Hub Under Test to port 1 on the tier four hub. Add the Logitech Wheel Mouse to port 1 on the tier one hub. Add the Iomega Zip250 drive to port 2 on the tier two hub. Add the Zoom 1595 camera to port 2 on the tier four hub. FixME - additional isoc IN device required. Add the Philips DSS350 speakers to port 2 on the Hub Under Test (tier five hub). Add the Hewlett Packard HP895C printer to port 3 on the Hub Under Test (tier five hub). Load the GoldTreeBuild image using something like the following command: dd if=GoldTreeBuild of=/dev/hda5 bs=8192. Boot to the Gold Tree configuration. Do not load any other software. If not already mounted, mount the usbdevfs file system using the following command: mount -t usbdevfs usbdevfs /proc/bus/usb. Check the contents of /proc/bus/usb/devices to ensure that all devices are correctly enumerated. Ensure that all devices in the Gold Tree are fully functional. If any device is not detected, is not fully functional, or causes a kernel oops, panic, reboot or lock-up during operation, record this test as a failure. Set system to play an MP3 (of Van Halen's "Dreams") from the Zip250 drive to the USB speakers. Display streaming video from the Zoom 1595 camera. Disconnect the Logitech Wheel Mouse from the tier one hub and plug it into port 4 (the spare port) on the Hub Under Test (tier five hub). Ensure that the Hub Under Test continues to operate normally under this load. Ensure that the Gold Tree devices continue to operate normally. Disconnect the Logitech Wheel Mouse from the Hub Under Test (tier five hub) and plug it into port 1 on the tier one hub. Ensure that all device attached to the Hub Under Test (tier five hub) are not in use. Detach Hub Under Test. Reattach Hub Under Test to the hub port it was detached from. If the Hub Under Test, or any other device, is not fully functional, or the Detach / Reattach causes a kernel oops, panic, reboot or lock-up during operation, record this test as a failure. Ensure that the devices attached to the Hub Under Test (tier five hub) are in use. Detach Hub Under Test. Reattach Hub Under Test to the hub port it was detached from. If the Hub Under Test, or any other device, is not fully functional and has not recovered from the detach, or the Detach / Reattach causes a kernel oops, panic, reboot or lock-up during operation, record this test as a failure. Ensure that the devices attached to the Hub Under Test (tier five hub) are not in use. Detach Hub Under Test from the tier four hub. Reattach Hub Under Test to port 3 of the tier two hub. If the Hub Under Test, or any other device is not fully functional, or the Detach / Reattach causes a kernel oops, panic, reboot or lock-up during operation, record this test as a failure. Detach Hub Under Test from the tier two hub, and attach Hub Under Test to port 1 of the tier four hub. Sync filesystems and reboot system using the reboot command. When system is restarted, ensure that the Hub Under Test (tier five hub) is fully functional. Test is to be recorded as failed if the Hub Under Test, or any other device, is not fully functional. Sync filesystems and halt system using the halt command. When system is halted, power system off. Wait two minutes. Power system back up and boot into test configuration. When system is restarted, ensure that the Hub Under Test is fully functional. Test is to be recorded as failed if the Hub Under Test, or any other device, is not fully functional. Construct the bus-powered Gold Tree as follows: Using a five metre cable, connect one bus-powered hub to an OHCI root hub port. This bus-powered hub is the tier one hub. Using a five metre cable, connect one self-powered hub to port 2 on the tier one hub. This self-powered hub is the tier two hub. Connect combined keyboard / hub to port 1 of the tier two hub. This keyboard / hub is the tier three hub. Using a five metre cable, connect one self-powered hub to port 1 on the tier three hub. This self-powered hub is the tier four hub. Using a five metre cable, connect the bus-powered Hub Under Test to port 1 on the tier four hub. Add the Logitech Wheel Mouse to port 1 on the tier one hub. Add the Iomega Zip250 drive to port 2 on the tier two hub. Add the Zoom 1595 camera to port 2 on the tier four hub. FixME - additional isoc IN device required. Add the Philips DSS350 speakers to port 2 on the Hub Under Test (tier five hub). Add the Hewlett Packard HP895C printer to port 3 on the Hub Under Test (tier five hub). Load the GoldTreeBuild image using something like the following command: dd if=GoldTreeBuild of=/dev/hda5 bs=8192. Boot to the Gold Tree configuration. Do not load any other software. If not already mounted, mount the usbdevfs file system using the following command: mount -t usbdevfs usbdevfs /proc/bus/usb. Check the contents of /proc/bus/usb/devices to ensure that all devices are correctly enumerated. Ensure that all devices in the Gold Tree are fully functional. If any device is not detected, is not fully functional, or causes a kernel oops, panic, reboot or lock-up during operation, record this test as a failure. Set system to play an MP3 (of Van Halen's "Dreams") from the Zip250 drive to the USB speakers. Display streaming video from the Zoom 1595 camera. Disconnect the Logitech Wheel Mouse from the tier one hub and plug it into port 4 (the spare port) on the Hub Under Test (tier five hub). Ensure that the Hub Under Test continues to operate normally under this load. Ensure that the Gold Tree devices continue to operate normally. Disconnect the Logitech Wheel Mouse from the Hub Under Test (tier five hub) and plug it into port 1 on the tier one hub. Ensure that all device attached to the Hub Under Test (tier five hub) are not in use. Detach Hub Under Test. Reattach Hub Under Test to the hub port it was detached from. If the Hub Under Test, or any other device, is not fully functional, or the Detach / Reattach causes a kernel oops, panic, reboot or lock-up during operation, record this test as a failure. Ensure that the devices attached to the Hub Under Test (tier five hub) are in use. Detach Hub Under Test. Reattach Hub Under Test to the hub port it was detached from. If the Hub Under Test, or any other device, is not fully functional and has not recovered from the detach, or the Detach / Reattach causes a kernel oops, panic, reboot or lock-up during operation, record this test as a failure. Ensure that the devices attached to the Hub Under Test (tier five hub) are not in use. Detach Hub Under Test from the tier four hub. Reattach Hub Under Test to port 3 of the tier two hub. If the Hub Under Test, or any other device is not fully functional, or the Detach / Reattach causes a kernel oops, panic, reboot or lock-up during operation, record this test as a failure. Detach Hub Under Test from the tier two hub, and attach Hub Under Test to port 1 of the tier four hub. Sync filesystems and reboot system using the reboot command. When system is restarted, ensure that the Hub Under Test (tier five hub) is fully functional. Test is to be recorded as failed if the Hub Under Test, or any other device, is not fully functional. Sync filesystems and halt system using the halt command. When system is halted, power system off. Wait two minutes. Power system back up and boot into test configuration. When system is restarted, ensure that the Hub Under Test is fully functional. Test is to be recorded as failed if the Hub Under Test, or any other device, is not fully functional. Record the date and time the test finished and summarise test results. dd is a standard part of all unix installations, and is a utility program that, amongst other attributes, allows the user to capture a snapshot of the hard drive (or partition) and restore it quickly and easily. By using dd, interoperability problem scenarios can be quickly reproduced and retested after solutions have been implemented. There are other disk image capture utilities on the market. Determine which utility is best for your environment. I am indebted to all the developers who have worked on Linux USB. This document is based on the USB Interoperability Guidelines written by Daniel J Phelps and others of Intel Corporation. Changes to make this document applicable to Linux are Copyright (C) Brad Hards (2000). This document may be distributed only subject to the terms and conditions set forth in the Linux Documentation Project License as detailed at http://www.linuxdoc.org/COPYRIGHT.html.