1924 2012-01-18 23:59:13 +0000 [LTP] 'vma01' case failed on non-x86 platforms with Yocto 1.2 M2 rc1 2021-05-20 15:35:30 +0000 1 1 6 Yocto Project Subprojects Kernel kernel-tooling 1.2 x86 Multiple RESOLVED FIXED Medium normal Future 1 yi.zhao bruce.ashfield 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 --- --- No (bug/feature does not impact docs) oldest_to_newest 18257 0 yi.zhao 2012-01-18 23:59:13 +0000 Tree/branch: poky/1.2_M2 Commit: 0f4d99d207b224bb9ce23de00a48f795ae20b3a0 Image location: http://autobuilder.pokylinux.org/nightly/20120111-3/machines/ LTP version: 20110915 'vma01' case failed on beagleboard, routerstationpro and mpc8315e-rdb. The error message is like below: ############ vma01 0 TINFO : t = 0x4000c000 vma01 0 TINFO : v = 0x40107000 u = 0x4000f000 vma01 0 TINFO : s = 0x4000f000, t = 0x40012000 vma01 0 TINFO : s = 0x40012000, t = 0x40013000 vma01 1 TBROK : unexpected VMA found. vma01 2 TBROK : Remaining cases broken ############# Steps: ###### 1. root@beagleboard:~# cd /opt/ltp/testcases/bin/ 2. root@beagleboard:/opt/ltp/testcases/bin# ./vma01 ###### 19335 1 bruce.ashfield 2012-03-22 14:29:33 +0000 Do we know if these same failures happen in qemu ? We have some hardware issues, and can't reproduce these at the moment. 19473 2 yi.zhao 2012-03-26 08:30:43 +0000 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 ###### 19732 3 yang.shi 2012-03-31 01:06:58 +0000 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. 19734 4 dvhart 2012-03-31 01:23:54 +0000 And this is precisely why LTP test case bugs so frequently languish. Nice work Yang Shi. 19739 5 bruce.ashfield 2012-03-31 03:26:09 +0000 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. 74225 6 randy.macleod 2017-06-15 15:24:46 +0000 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. 74774 7 ross.burton 2017-07-05 10:53:36 +0000 Waiting For Upstream status is being removed, changing to Accepted. 83714 8 akuster 2019-05-03 01:46:27 +0000 (In reply to comment #7) > Waiting For Upstream status is being removed, changing to Accepted. is this still an issue? 90438 9 richard.purdie 2021-05-20 15:35:30 +0000 http://downloads.yoctoproject.org/releases/yocto/yocto-3.3/testreport.txt shows vma01 isn't marked as failing anywhere