Jupiter Kernel Test

From DDCIDeos
Jump to navigationJump to search

Jupiter kernel test epicenter.

Weekly meeting

When: Wed at 1pm MDT
Where: meet.google.com/icx-bdfk-xxs
Phone Number: (‪US‬) ‪+1 402-736-0286‬ PIN: ‪477 445 675#‬
What: Address issues/roadblocks.

Team

Andre Martinez

Gary Kindorf

Ron Rische (RDR)

Oscar Soto

Daniel Riquelme

Hernaldo Ramirez

E-Mail to the whole team

Development Environment

  • Use the latest stable Jupiter environment, then add the following unreleased:
    • nothing right now


New kernel features

  • 36-bit
  • LFS/MFS/KFS
  • multiple WAT
  • aligned TLS reserve
  • Drop support for e500mc and e5500 ppc subarchitectures, qemu-ppc will be a 6500.
  • scheduler pad pool limitation. The pad pool feature may not be used when there are multiple schedulers defined. See PCR:14335.

Tasks

Baseline (20210513)

PCRs

See readme-wiki-pcrs.txt for automated maintenace of the PCR tables on this wiki.

PCR Title Assignee Estimate Remaining Comments
PCR:14703 Test: TPK105 fails on x86 with kernel mode error because linked image address preconditions not met N/A 0 0 Post Jupiter verification for x86.
Total @sum(column) days @sum(column) days

Work not captured in PCRs

Title Assignee Estimate Remaining Comments
Structural coverage analysis for ppc,arm 20 5 Currently at ~99.8% instrumented_optimized. A few more issues to resolve.
problems.mk 15 10 Fix random platform problems other test problems not captured in PCRs. 
 tpk120 continues to fail instrumented even with more thread budget.
 tpk230 fails on tfhost but not when run from local machine - strange.
Total @sum(column) @sum(column)

Requires Investigation

  • ls10x8ardb (DeosLS1048ARDB-1) - fails to consume all RAM e.g. tpk009, tpk012, tpk945(custom) - BSP issue? Board issue?
  • de-ls1048a (DeosLS1048A-GL2-1) - does not mode change properly - BSP issue? Is this related to PCR 13403
  • jupiter kernel reports event 0x39 (insufficient_tls_quota) for test processes - Kernel issue? No. Kernel test makefile includes -lansi; however, does not include libansi.fp.xml

Review Activity

Test Results

20230113 (zcu102: release, instrumented, instrumented_optimized variants)

20230110 (zcu102: release, instrumented, instrumented_optimized variants)

20230108 (dpm2 pidu nai68ppc2: release, instrumented, instrumented_optimized variants)

20221222 (pidu nai68ppc2: release, instrumented, instrumented_optimized variants)

20221218 (zcu102: release, instrumented, instrumented_optimized variants)

20221217 (dpm2 pidu: release, instrumented, instrumented_optimized variants)

20221216 (nai68ppc2: release, instrumented, instrumented_optimized variants)

20221215 (dpm2 zcu102: release, instrumented, instrumented_optimized variants)

20221213 (zcu102: release, instrumented, instrumented_optimized variants)

20221209 (dpm2: release variant)

20221208 (nai68ppc2: release, instrumented, instrumented_optimized variants)

20221208 (pidu: release, instrumented, instrumented_optimized variants)

20221206 (pidu nai68ppc2: instrumented, instrumented_optimized variants)

20221204 (pidu nai68ppc2: instrumented, instrumented_optimized variants)

20221202 (pidu nai68ppc2: instrumented, instrumented_optimized variants)

20221130 (nai68ppc2: instrumented, instrumented_optimized variants)

20221130 (pidu: instrumented, instrumented_optimized variants)

20221121 (pidu qemu-arm nai68ppc2 qemu-ppc: debug, release, instrumented, instrumented_optimized variants)

20221113 (dpm2 pidu nai68ppc2: debug, release, instrumented, instrumented_optimized variants)

20221031 (ls1043ardb: debug, release, instrumented, instrumented_optimized variants)

20221017 (celestial: debug, release, instrumented, instrumented_optimized variants)

20221010 (dpm2 pidu zcu102 nai68ppc2: debug, release, instrumented, instrumented_optimized variants)

20220926 (dpm2 pidu zcu102 nai68ppc2: debug, release, instrumented, instrumented_optimized variants)

20220911 (dpm2 pidu zcu102 qemu-arm nai68ppc2 qemu-ppc: debug, release, instrumented, instrumented_optimized variants)

20220907 (dpm2 pidu zcu102 qemu-arm nai68ppc2 qemu-ppc: debug, release, instrumented, instrumented_optimized variants)

20220815 (dpm2 pidu zcu102 qemu-arm nai68ppc2 qemu-ppc minnow-turbot-quad: debug, release, instrumented, instrumented_optimized variants)

20220809 (dpm2 pidu: release variant)

20220803 (pidu zcu102 nai68ppc2: debug, release, instrumented, instrumented_optimized variants)

20220725 (pidu zcu102 nai68ppc2: debug, release, instrumented, instrumented_optimized variants)

20220722 (dpm2 pidu: crittime)

20220620 (dpm2 pidu celestial nai68ppc2: debug, release, instrumented, instrumented_optimized variants)

20220615 (dpm2 pidu celestial nai68ppc2: debug, release, instrumented, instrumented_optimized variants)

20220603 (s32v234: debug, release variants)

20220530 (dpm2 pidu zcu102 celestial nai68ppc2: debug, release, instrumented, instrumented_optimized variants)

20220523 (dpm2 pidu zcu102 celestial: debug, release, instrumented, instrumented_optimized variants)

20220516 (dpm2 pidu zcu102 celestial: debug, release, instrumented, instrumented_optimized variants)

20220509 (dpm2 pidu zcu102 celestial: debug, release, instrumented, instrumented_optimized variants)

20220502 (zcu102 celestial: debug, release, instrumented, instrumented_optimized variants)

20220425 (dpm2 jacinto7evm ls1043ardb zcu102 celestial: crittime, debug, release, instrumented variants)

20220418 (ls1043ardb zcu102 celestial: crittime, debug, release, instrumented variants)

20220415 (pidu: crittime, debug, release, instrumented variants)

20220411 (pidu zcu102 celestial: release, debug, crittime, instrumented variants)

20220404 (pidu zcu102 celestial: release, debug, instrumented variants)

20220331 (jacinto7evm: release, debug variants)

20220218 (pidu nai68ppc2: release, debug variants)

20220217 (pidu: release, debug variants)

20211124 (pidu, celestial, minnow-turbot-quad: release, debug variants)

20211026 (ls10x8ardb celestial: release, debug variants)

20211022 (dpm2 pidu: release, debug variants)

20211021 (dpm2: release, debug variants)

20211020 (pidu: release, debug variants)

20211019 (dpm2, pidu: release, debug variants)

20210819 (imx8qm, zcu102, nai68ppc2: release, debug variants)

20210818 (imx8qm, zcu102, nai68ppc2: release, debug, crittime, instrumented variants)

20210817 (dpm2, imx8qm, pidu, zcu102, nai68ppc2: release, debug variants)

20210804 (dpm2, imx8qm, pidu, zcu102: release, debug variants)

20210720 (dpm2, imx8qm, pidu, zcu102, nai68ppc2: release, debug variants)

20210706 (dpm2, imx8qm, pidu, zcu102, nai68ppc2, minnow-turbot-quad: release, debug variants)

20210621 (dpm2, imx8qm, pidu, zcu102)

20210620 (dpm2, imx8qm, pidu, zcu102)

20210616 (dpm2, imx8qm, pidu, zcu102)

20210430 (dpm2, imx8qm, pidu, zcu102, nai68ppc2, minnow-turbot-quad: release, debug variants)

  • NOTE: Using ARM BSPs with TLB fixes PCR 13403 and PCR 13408
  • NOTE: The dpm2 and pidu are Durants customer BSPs based on zcu102 and imx8qm respectively.
  • NOTE: The dpm2 board does not use TFTPBOOT and therefore has older Boot without TLB fix.
  • results

20210403 (imx8qm, zcu102, nai68ppc2, minnow-turbot-quad: release, debug variants)

20210331 (imx8qm, zcu102, nai68ppc2, minnow-turbot-quad: release, debug variants)

20210326 (imx8qm, zcu102, nai68ppc2, minnow-turbot-quad: release, debug variants)

20210312 (imx8qm, zcu102, nai68ppc2, minnow-turbot-quad: release, debug variants)

20210307 (zcu102, nai68ppc2: release, debug variants)

Harrys Program Kernel Test Newsgroup

To capture generally useful discussions, this newsgroup is the preferred form of communication. The visibility also enables the kernel development staff to assist in answering questions.


sign up here

view the archive here

start a new discussion by sending email to kernel-tests@deos.ddci.com

Other Relevant Project Wikis and Documentation

  • Configure Open Arbor for test development This is also a necessary prerequisite for using the Open Arbor debugger on a test procedure.
  • The kernel release notes (./output/desk/help/deos-kernel-release-notes.htm contains a list of changed features/APIs.


Test Case guidance

  • Ensure that the trace tags section includes both the interface requirement tag and the requirement under test tag. For example, test cases for the API getEventHandle() requirement DDD_DEOS_EVT_60.1 should be listed under both DDD_DEOS_EVT_50 and DDD_DEOS_EVT_60.1 trace tags.
    Rationale: The trace matrix can identify all tests affected by an API change.
  • Ensure there are unique test cases for each expected result and for each unique set of inputs. Testing an API with 3 unique expected results should have a minimum of 3 test cases. More test cases may be required if inputs values have unique states. For example, getEventHandle() expected output of eventInvalidProcessHandle can be achieved by 3 classes of an input process handle and therefore requires 3 test cases.
    Rationale: Clear linkage/trace from test procedure to test case document for reviews/auditors.
  • Ensure that the comments section is marked with <p> None </p> if there are no additional comments.
    Rationale: Clear indication that additional comments were not overlooked.

CAN file guidance

  • Ensure that the CAN file only lists expected test cases to run.
    Rationale: We don't want any tests procedures which fail to run or which run and don't pass to be accepted.
  • If a CAN file and test procedure are both being modified, please update the CAN file to match the following format:

[PppDddL:000] BEGIN:
[PppDddL:001] PASSED: Test Case Ttt
[PppDddL:002] PASSED: Test Case Ttt
[PppDddL:003] END.

Where Ppp is the test prefix e.g. TPK, Ddd is the test number e.g. 240, L is the letter of the procedure/process writing the output e.g. A, and Ttt is the test case.
Note1: The numbers between [] and after : are in hexadecimal format.
Note2: The CAN output should match the expected order that the test procedure(s) will execute.

  • A test procedure may require more than one core (CPU) to verify operation per the requirement. In this case, there is typically a PppDdd-uni-processor.can file in the alt-can folder with the notation: test case is only valid on multi-processor systems. The PddDdd.can file in the can folder should contain a TODO and be marked a 6 in the status file with an appropriate Note if:
    • The test procedure is not complete for multi-processor testing.
    • Or, does not handle cross core memory consistency with appropriate memory barriers.

Test procedure guidance

  • Eliminate compiler warnings. Be careful with cases
  • You might not be the first editor since a TPK was last reviewed; check the history. Remember that we need review independence. If a co-worker has modified the file already, consider letting them work on that file instead of you. The last verification was in 2021.
  • The TPK makefile.mk and the := operator. Please model your makefile.mk files after the example below. If a test needs to modify or extract registry data, use HACK_REGISTRY (not sed/awk...). This is a good example.
    • There is just one ":=" assignment (testid := $(TESTID)). This is still required for test-utils reasons. All other assignments use "="
    • The variable "testid" is only assigned, and not referenced.
  • Have a test that should interact with multiple cores, but you cannot find a way for the test to incorporate multiple cores should they exist? Please document that test in problems.mk in the symbol MULTICORE_TESTS_WITH_UNICORE_IMPLEMENTATIONS. These tests will have to be revisited on the next verification cycle.
  • Have a test that should interact with multiple cores (CPU), ensure that the appropriate memory barriers are used for memory consistency. If barriers can't be used for this verification cycle, ensure a TODO is left in the can file (see guidance above).
  • 20190515: Have a test that needs to query the state of a threads' current exception mask value? Right now, there is no way to read that value directly; instead, you will need to install and exception handler for each exception, raise each exception, and verify the handler is invoked. Before you do that, lets hear back from the kernel team, as I have put in a request for a means of reading a threads' exception mask directly.
  • Interceptor PAL (iPal) tests which are testing an OPTIONALPALPPI API should setup the interceptor PAL with $(eval $(call SETUP_INTERCEPTPAL,...))
    Otherwise, if not testing an OPTIONALPALPPI API should setup the interceptor PAL with $(eval $(call SETUP_INTERCEPTPAL_VARIANT,...))


Commit Feedback

During the test development phase of the project, DDC-I staff will be peer reviewing commits. When feedback is provided, it will generally be provided in a patch attached to the PCR used to make the commit, with a reference to the specific commit comment in the PCR. Authors should apply the patch, ask any related questions, re-test the resulting changes, and re-commit. It is fairly common for the patch utility to fail due to whitespace and line ending changes. This is the recommended sequence for applying a patch: 

patch -p0 --verbose --dry-run --ignore-whitespace --fuzz 3 < [patch file]

If that dry-run completes successfully, you can then apply the patch via 

patch -p0 --ignore-whitespace --fuzz 3 < [patch file]

If the patch fails, consider manually converting all the line ending of the patch file and the files to be modified to unix with: d2u filename

Retrieved from "https://ddci.zapto.org/ddciWiki/index.php?title=Jupiter_Kernel_Test&oldid=61522"