-
Notifications
You must be signed in to change notification settings - Fork 124
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
perf/perf_24x7_hardware_counters.py: check_valid_chip - Update testcase to avoid failures #2787
base: master
Are you sure you want to change the base?
perf/perf_24x7_hardware_counters.py: check_valid_chip - Update testcase to avoid failures #2787
Conversation
Command: perf stat -v -e hv_24x7/PM_PHB0_0_CYC,domain=1,chip=<value> Maximum chip value which can be assigned is 65535 Anything above that range should fail and this test is used to verify that Hence, setting invalid_chip=65536 can directly test the command In scenarious where multiple chip values are tested, this testcase can fail if the chip values passed before 65536 are in the accepted range. Signed-off-by: Misbah Anjum N <[email protected]>
Maximum Chip value which can be taken is 65535
|
OS: Fedora40Before the patch: invalid_chip = [self.chips, 65536]STATUS: FAIL
Exaplanation:-at line: invalid_chip = [self.chips, 65536] Command: |
OS: Fedora40After the patch: invalid_chip = 65536STATUS: PASS
Exaplanation:-at line: invalid_chip = 65536 Command: |
Tested in OS RHEL9.3 with the patchSTATUS: PASS
|
The supported chip id value is taken as below from lscpu output.
So, lets take chip = 2*2 = 4 which means 0,1,2,3 are valid and self.chip which is 4 becomes invalid as value is starting from 0. So the test case logic is correct for invalid chip which is testing self.chips and 65536. You need to check debug log to see why exactly test case is failing. valid chip value = 0 to self.chips-1 |
result on a lpar where we have chip value as 4.
|
@misanjumn can you attach relevant debug logs captured during a failed run so that they can be reviewed to debug this problem? |
res = self.event_stat1(cmd) | ||
if res.exit_status == 0: | ||
self.fail("perf unable to recognise invalid chip value") | ||
invalid_chip = 65536 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you have a meaning full name, max_range ?
if res.exit_status == 0: | ||
self.fail("perf unable to recognise invalid chip value") | ||
invalid_chip = 65536 | ||
if self.rev == '004b' or self.rev == '004e': |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if self.rev in ['004b' , '004e']:
@misanjumn any update here ? |
With code self.chips = 2
But the exit status for Command perf stat with the self.chips = 2 is 0:
Corresponding debug.log for
Since the exit status is 0, the code logic takes the command execution as pass and hence gives FAIL as perf unable to recognise invalid chip value |
In the test machine:-
But chip value = 2 is being tested in the test-case since:-
|
@disgoel @misanjumn so where are we on this? Is this(perf stat with self.chip as chip value returns success) an actual bug or a test case issue? |
perf/perf_24x7_hardware_counters.py: check_valid_chip - Update testcase to avoid failures
Command: perf stat -v -e hv_24x7/PM_PHB0_0_CYC,domain=1,chip=value
Maximum chip value which can be assigned is 65535
Anything above that range should fail and this test is used to verify that
Hence, setting invalid_chip=65536 can directly test the command In scenarious where multiple chip values are tested, this testcase can fail if the chip values passed before 65536 are in the accepted range.
Signed-off-by: Misbah Anjum N [email protected]