|
Chapter 3. Test Strategy
To begin, install the card in the system under test and verify that the device shows up in the OBP device tree using the procedure in Navigate Through Device Tree Using OpenBoot Commands.
Note If the device does not appear in the device tree, the test fails. The model 16000P PCI card and driver from AuroraTechnologies is shown as an example in the test steps below.
Install the card in the selected PCI slot in the test system.
The following procedure uses OpenBootTM commands to verify that the system being tested sees and recognizes the newly installed PCI devices.
- At the ok prompt type:
to show all PCI devices. The output should look similar to this partial sample:
/pci@1f,4000/AURA,oregano@2 <== (Aurora(16000P) card installed as device 2)
/pci@1f,4000/scsi@3
/pci@1f,4000/network@1,1
/pci@1f,4000/ebus@1
|
- Change directories to the device path:
ok
cd /pci@1f,4000/AURA,oregano@2
|
-
List properties of
AURA,oregano@2
:
Example output of
.properties
command:
card_ type
00 00 00 03 assigned-addresses
82001010 00000000 00012000 00000000 00000100
82001018 00000000 00013000 00000000 00000200 reg
0000
1000 00000000 00000000 00000000 00000000
(NOTE: In above line, first 2 hex digits, emboldened, are the bus number = 0 )
02001010 00000000 00000000 00000000 00000100
02001018 00000000 00000000 00000000 00000200 pci_ slot
00 00 10 00 copyright
Copyright (c) 1997 Aurora Technologies, Inc. prom-version
1.9 manufacturer
Aurora Technologies, Inc. model
16000P name
AURA,oregano fcode-rom-offset
00000000 fast-back-to-back devsel-speed
00000001 class-code
00078000 interrupts
00000001 max-latency
00000000 min-grant
00000000 subsystem-vendor-id
0000125c subsystem-id
00000640 revision-id
00000002 device-id
0000906d vendor-id
000010b5
|
A test script called
crdtst
is provided in the
SUNWpcict
package. It verifies that a card is in compliance with the PCI 2.1 (Hardware) Standard. Install the
crdtst
test script from the
SUNWpcict
package, then follow the instructions in the
README
file.
Note -
If the card is not PCI compliant, the Market Development Engineer will inform the IHV of PCI noncompliance, and the verification of the product could be discontinued until the IHV provides a compliant product.
The following suggestions apply to installing your driver in a Solaris system.
Note -
Become the superuser before using the
pkgadd
or
pkgrm
commands.
-
Become superuser and boot the system:
Note -
If both the
/etc/path_to_inst
file and backups have been removed or compromised,
boot -ar
will regenerate the
path_to_inst
with a new configuration of PCI cards.
-
Using pkgadd, install the driver from the list of loadable drivers using one of the following three methods.
-
To use
pkgadd
from diskette, insert the diskette into the drive and type:
This will create
device_node
.
Type:
to show
device_node
.
To load the driver, type:
#
pkgadd -d /vol/dev/
device_ node
|
-
To use
pkgadd
from CD-ROM, insert the disk into the drive and type:
to show
device_node
.
To load the driver, type:
#
pkgadd -d /cdrom/
device_ node
|
-
You can also load the driver using such methods as
tar
,
install
,
sh
, etc.)
When the driver has been loaded, you should see a message similar to this in the command window:
Installation of
AURAsio16
was successful
|
-
Verify that the driver loaded properly by using the
modinfo
command to
grep
for installed modules:
You should see a line such as:
24 50882000 b46c 139 1 sio16 (Aurora CL-CD180/1865 driver)
|
-
Check that the driver aliases entry was installed properly by typing:
#
cat /etc/driver_ aliases | grep sio16
|
You should see driver aliases:
-
Check that the physical device node was created:
-
Verify that the logical device node was created:
Note -
In this example look in the
cua
directory; it should list ports 0-15.
The following procedure should ensure a successful system boot with PCI card device drivers installed. No ERROR or WARNING messages should be displayed.
-
Use
uadmin
to
sync
and halt the system gracefully:
-
At the
ok
prompt, boot the system:
-
Check that the driver aliases entry was installed properly by typing:
#
cat /etc/driver_ aliases | grep
sio16
|
You should see driver aliases such as
sio16AURA,oregano
.
-
Check whether the logical device node was created:
Note -
In this example look in the
cua
directory; it should list ports 0-15.
Functional testing is performed on an individual basis using either Sun or IHV provided test suites and tools at Sun's East Coast I/O Testing Lab in Burlington, MA, or at the IHV facility.
In either case, if functional tests pass, all test setups, lab venues, and actual tests performed will be documented in a report to be placed on Sun's external PCI web site. See Appendix A
for a sample report.
If the test failed, Sun will report the errors to the IHV. If the problem can be fixed on the same day, Sun will restart the testing. If testing cannot continue due to schedule conflicts, another date will be scheduled.
If testing cannot continue, the assigned Market Development Engineer will report the problem to the IHV and follow up on the problem. The test date will be rescheduled, and the same test procedure will be used.
The
ddbct
script tests a binary executable driver to determine whether it is compliant with the Solaris DDI, and thus likely to work with future Solaris operating environment releases. The script produces a file that contains any non-compliant procedures.
You will need to be superuser to install
ddbct
.
-
Copy the
ddbct_install.sh
file from the Driver Development Web site to your system. Reply
yes
when it asks whether to install Perl.
-
Add this path so the system can find
ddbct
:
#
set path=($path/opt/SUNWddbct/bin)
|
-
Change directories to the usual location for PCI 32-bit driver modules; there are three possible choices:
-
The location can be
/kernel/drv
if the driver is needed during initial boot.
-
The location can be
/usr/kernel/drv
if the driver is an add-on, application-specific driver.
-
The location can be
/platform/SUN4u/kernel/drv
if the driver is platform specific.
#
cd /platform/SUN4u/kernel/drv
|
-
Verify whether you are running a 64-bit kernel by typing:
You should see this output:
sparcv9plus+vis sparcv9 sparcv8plus+vis...
|
-
Determine whether the driver is 64-bit clean by typing:
You should see this output:
AURAsio16: ELF 64-bit MSB relocatable SPARCV9 Version 1
|
-
Change directories to the 64-bit driver module location; there are three possible choices:
-
The location can be
/kernel/drv/sparcv9
if the driver is needed during initial boot.
-
The location can be
/usr/kernel/drv/sparvc9
if the driver is an add-on, application-specific driver.
#
cd /usr/kernel/drv/sparcv9
|
-
The location can be
/platform/SUN4u/kernel/drv/sparcv9
if the driver is platform specific.
#
cd /platform/SUN4u/kernel/drv/sparcv9
|
-
Run the
ddbct
script on driver module
AURAsio16
:
By default,
ddbct
puts its working files in the
/tmp
directory; to look at it, type:
If a problem was encountered and reported previously or if the IHV needs to bring in its own test suites and equipment, the test engineer will assist the IHV representatives during their visit to the lab.
Always use
pkgrm
to remove device drivers when removing PCI cards or changing their locations on Sun systems.
You will need to be superuser to run
pkgrm
.
-
Use the
pkgrm
command to remove the module.
In a command window, you should see messages such as:
Removal of
AURAsio16
was successful.
|
appear when the process has completed.
-
Check for removal of card instance and module:
#
cat /etc/driver_ aliases | grep
AURAsio16
#
modinfo | grep
AURAsio16
|
You should not see any reference to the driver that was removed.
The card test results (Third-Party Test Report) will be posted on Sun's external PCI web site, referenced from the two Third-Party PCI card pages by clicking on Test Report next to the card name: http://www.sun.com/io_technologies/pci/pci.cards.cat.html and http://www.sun.com/io_technologies/pci/pci.cards.ihv.html.
The Sun support engineer assigned to the IHV will record problems, analyze them, and communicate the details to the rest of the support team members. Common problems should be resolved more quickly through these mutual discussions.
If a problem is caused by the IHV driver or hardware, the support engineer will provide details to the IHV after analyzing the problem. Problem diagnosis and resolution is the responsibility of the IHV. The IHV will also provide any new versions of hardware and/or drivers.
|