| Summary: | [LTP] 'vma01' case failed on non-x86 platforms with Yocto 1.2 M2 rc1 | ||
|---|---|---|---|
| Product: | [Yocto Project Subprojects] Kernel | Reporter: | Yi Zhao <yi.zhao> |
| Component: | kernel-tooling | Assignee: | Bruce Ashfield <bruce.ashfield> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium | CC: | akuster, bruce.ashfield, dvhart, jessica.zhang, jiajun.xu, jingdong.lu, liang.li2, liming.wang, mark.hatle, randy.macleod, richard.purdie, sgw, yi.zhao, yp.kernel.watcher, yp.watcher |
| Version: | 1.2 | ||
| Target Milestone: | Future | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
|
Description
Yi Zhao
2012-01-18 23:59:13 UTC
Do we know if these same failures happen in qemu ? We have some hardware issues, and can't reproduce these at the moment. I have tested this case in qemu sato-sdk image with 1.2 M3. On qemuarm and qemuppc, this issue also happened: ############## root@qemuarm:/opt/ltp/testcases/bin# ./vma01 parent: t = 0x400fa000 child : u = 0x400fd000 vma01 0 TINFO : s = 0x400fd000, t = 0x40100000 vma01 1 TBROK : no matched s = 0x40100000 found. vma01 2 TBROK : Remaining cases broken vma01 1 TBROK : unexpected VMA found. vma01 2 TBROK : Remaining cases broken root@qemuarm:/opt/ltp/testcases/bin# ############## On qemumips, the case could pass: ############## root@qemumips:/opt/ltp/testcases/bin# ./vma01 parent: t = 0x778d2000 child : u = 0x778cf000 vma01 0 TINFO : s = 0x778cf000, t = 0x778d2000 vma01 0 TINFO : s = 0x778d2000, t = 0x778d5000 vma01 1 TPASS : two 3*ps VMAs found. root@qemumips:/opt/ltp/testcases/bin# ################ Steps: ###### 1. root@beagleboard:~# cd /opt/ltp/testcases/bin/ 2. root@beagleboard:/opt/ltp/testcases/bin# ./vma01 ###### Looked into the test case code, it sounds the test case assumes child vma pointer < parent vma pointer. It's true on x86, but false on ppc and arm. So, on ppc and arm, the test case will search vma out of the bound to cause the issue. And, although "u = mmap(t + 3*ps, 3*ps, PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE, 0, 0);" is called to get child vma pointer, however, kernel assigns child vma pointer to "t - 3*ps" on x86. According to man page of mmap, the addr parameter is just a hint, so kernel doesn't make sure the final address is as same as addr parameter. So, it sounds a test case bug. And this is precisely why LTP test case bugs so frequently languish. Nice work Yang Shi. Agreed. Great investigation Yang. I've change the state on this to waitforupstream, since it is a LTP bug. We should bring this to the attention of the LTP maintainers via ltp-list@lists.sourceforge.net and pick up a fix later. For now, we'll mark this as a know and understood failure. Catalin is getting involved in oe-core so this is a good defect to work on. Catalin, Please check if this is fixed in the version of LTP used in oe-core/master or even the most recent version of LTP's development tree. Waiting For Upstream status is being removed, changing to Accepted. (In reply to comment #7) > Waiting For Upstream status is being removed, changing to Accepted. is this still an issue? http://downloads.yoctoproject.org/releases/yocto/yocto-3.3/testreport.txt shows vma01 isn't marked as failing anywhere |