1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
|
How to use RUN-TIME tests.
1. Install the tests (see HOW_TO_INSTALL).
2. Tune the test suite to your current need by
setting appropriately variables SETN (and run4)
which handle the test suite settings (see file
aslts/src/runtime/cntl/runmode.asl).
3. You can use utility Do to run the specified set of tests
in all specified modes of runs. It supports the automated
logging out of results of test runs and allows to compare
results. See comment to utility Do.
4. You can run any particular aml test from the aslts/tmp/aml
directory passing immediately its pathname to acpiexec
utility.
5. You can change the current direstory to the particular test,
run '<ASL> MAIN.asl' for compiling the test and then run AcpiExec
utility with the obtained .aml code.
6. The aml test after completion reports its status: [PASS|FAIL|BLOCKED|SKIPPED].
PASS - success, no errors encountered in the functionality of the product
FAIL - the test encountered errors - improper functionality of the product
BLOCKED - the test was blocked (was not run), it is applied for the tests which
are temporary causing abort or hang of execution due to the errors in
the product
SKIPPED - the test was skipped (was not run), it is applied in case when the
result of the test is undefined under the particular conditions
7. How to treat the results of run-time tests.
A. Successful run.
After the run completion the following summary lines
are printed out by ASLTS:
a) "Run time (in seconds): 0x0000000000000031"
b) "The total number of exceptions handled: 0x0000000000000005"
c) "TEST ACPICA: 64-bit : PASS"
The line (a) shows the run time in seconds
measured by the ASL-Timer operator.
The line (b) reports the number of exceptions which
took place during the test execution.
The line (c) reports the summary status of test run
as [PASS|FAIL|BLOCKED|SKIPPED], and the mode of run
as 32-bit or 64-bit.
B. Failed run.
a) "Run time (in seconds): 0x0000000000000031"
b) "The total number of exceptions handled: 0x0000000000000005"
c) "TEST ACPICA: 64-bit : FAIL : Errors # 0x0000000000000009"
The number of errors (9 here) is reported as
Errors # 0x0000000000000009".
C. The layout of the particular error message.
"---------- ERROR : 0x000000001903301A, 0x0000000000033017, m503"
"TITLE : Miscellaneous named object creation"
"COLLECTION : functional"
"TEST CASE : name"
"TEST : PCG0"
"ERROR, file : package.asl"
" index : 000000000000001A"
"CHECKING, file : package.asl"
" method : m123"
" index : 0000000000000017"
"(r):"
0x0000000000000025
"(e):"
0x0000000000000027
"---------- END."
Explanations:
0x000000001903301A,
0x0000000000033017 - two 32-bit words of opcode of error
(see "The layout of opcode of error" below)
m503 - there is usually the name of method (usually, the name of
method conglomeration of tests) or some brief diagnostic
message explanation/designation/naming of error
"TITLE : the common intention of the test
"COLLECTION : functional/complex/exceptions/..
"TEST CASE : the name of test case (bfield, arithmetic, opackageel, ...)
"TEST : the name of test (simplest unit reported by diagnostics
and supplied with the satatus line)
"ERROR, file : the name of file where the error reporting
function (err()) was invoked
" index : index of error inside that file where err()
was invoked (each invocation of err() differs
with its index)
"CHECKING, file : the name of the file where the checking was initiated
" method : the name of method initiated the checking
" index : index of the checking inside the file "CHECKING, file"
(r): - usually, the following value is a received one
(e): - usually, the following value is an expected one
D. The errors (now 200 max) are summarized as follows at the
end of the test output (example of test Reference).
"========= ERRORS SUMMARY (max 200):"
"reference, ref50.asl, 0000000000000003, ref50.asl, 0000000000000000, m22c"
"reference, datastproc.asl, 000000000000000F, ref50.asl, 0000000000000001, m22c"
"reference, ref50.asl, 0000000000000007, ref50.asl, 0000000000000000, m234"
"reference, ref50.asl, 0000000000000007, ref50.asl, 0000000000000000, m234"
"reference, datastproc.asl, 0000000000000001, ref50.asl, 0000000000000013, m365"
"reference, datastproc.asl, 0000000000000001, ref50.asl, 0000000000000015, m365"
"reference, datastproc.asl, 0000000000000001, ref50.asl, 0000000000000017, m365"
"========= END."
Explanations:
"reference, datastproc.asl, 0000000000000001, ref50.asl, 0000000000000017, m365"
reference - the name of test case
datastproc.asl - the name of file where the error was revealed and reported
by invoking err(..,index,..)
0000000000000001 - index of error inside that (datastproc.asl) file
ref50.asl - the name of file where the checking was initiated
0000000000000017 - index of that checking inside that (ref50.asl) file
m365 - diagnostic message (usually, the name of method conglomeration of tests)
(see additionally file aslts/TESTS)
8. The layout of opcode of error (three 32-bit words)
0xctfffeee
0xmmzzzuuu
0xnnnnnnnn
c - index of tests collection
t - index of test inside the collection
f - absolute index of file reporting the error
e - index of error (inside the file)
z - absolute index of file initiating the checking
u - index of checking
n - name of Method initiating the checking
m - miscellaneous:
1) in case of TCLD tests there is an
index of bug stored (max 600)
How to use ASL-compilation control test collection
==================================================
The tests of ASL Compiler to check its ability to detect,
report and reject wrong ASL code are given in directory:
aslts/src/compilation/collection
At present, no utility is provided to perform automated
run and verification of these tests.
The tests contain wrong ASL code so no resulting files of
compilation are expected. The expected are Warning and Error
messages to be reported by ASL Compiler for incorrect ASL code.
The utility should be ever implemented to parse the output of
ASL Compiler for these files to check presence of the expected
messages in it.
|
