> -----Original Message----- > From: Garrett Cooper [mailto:yaneg...@gmail.com] > Sent: Friday, August 13, 2010 3:35 PM > To: Mitani > Cc: ltp-list@lists.sourceforge.net; 當座 健市 > Subject: Re: [LTP] [PATCH] fix "hugeshmat01" test > > 2010/8/9 Mitani <mit...@ryobi.co.jp>: > > Hi, > > > > I tried to run hugeshmat01 testcase, but it failed. > > This testcase failed in following systems. > > - RHEL5.5-ia64 > > - RHEL4.8-x86_64 > > - RHEL4.8-ia64 > > > > I used latest git: > > ltp-dev-7c67a09a10268b5f9f503e0254f1f0f9f5ac2b69.tar.gz > > This testcase failed also in previous gits. > > > > > > RHEL5.5-ia64 log: > > ------------ > > hugeshmat01 1 TPASS : conditions and functionality are > correct > > hugeshmat01 2 TFAIL : hugeshmat01 call failed - errno = 22 : > Invalid > > argument > > hugeshmat01 3 TBROK : Remaining cases broken > > ------------ > > > > It is caused by "EINVAL" failure of shmat(). > > > > ---(hugeshmat01.c)--------- > > [...] > > for (i=0; i<TST_TOTAL; i++) { > > > > /* > > * Use TEST macro to make the call > > */ > > errno = 0; > > addr = shmat(*(TC[i].shmid), (void > *)(TC[i].addr), > > TC[i].flags); > > [...] > > ------------ > > > > In second loop (i=1), arguments of shemat() are followings: > > > > shmat(id, 0x10000000eee, SHM_RND) > > > > This test expects that the return value of shmat() is rounded down > to > > a multiple of SHMLBA. > > But shmat() failed in some systems. > > I deduced that "0x10000000eee" address may be outside of hugepages > area. > > > > So I used the return value of first loop's shmat() instead of fixed > > address ("0x10000000eee"). > > And the test succeeded. > > The question I have to pose is: why would it do this if the other > address was deallocated? > > Thanks, > -Garrett
Hi, "hugeshmat01" test has three fase tests. In these tests, second one failed in my several x64_64 and ia64 architecture machines. The first is the test for shmat() with 0 address in 2nd argument. The second is the test for shmat() with unaligned address in 2nd argument. In the first test, it is expected that 0 addressed shmat() returns with new aligned address. In the second test, it is expected that unaligned addressed shmat() returns with aligned address. This second test uses the fixed address "0x10000000eee" for unaligned address. When a fixed address was specified, this address may be the address which other processes use depending on a case. This may be out of user space. The dynamic address gotten by the first test's shmget() is the address without such a risk, I think. I performed this revision to reduce the risk of the second test by reusing a address gotten by the first test. Thank you-- -Tomonori Mitani ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list
