>>> On 3/31/2010 at 03:22 AM, in message <[email protected]>, Rishikesh K Rajak <[email protected]> wrote: > Hi Murlin, > > Can you please look into this problem again ? It seems you had some > discussion > with garret to reach to some conclusion about the reported failure. >
I'm trying to get back to it, but have been swamped with work right now. The inherent problem is the fact that the test is based on a macro used during kernel build/compile time which was hard coded at one point in time. The maximum number of swap files supported can vary based on kernel compile time switches. I really don't think we want to try and build a kernel module or try to build the test assuming kernel headers and complete config are always available. > -Rishi > > On Sat, Mar 13, 2010 at 01:56:25PM -0800, Garrett Cooper wrote: >> On Sat, Mar 13, 2010 at 9:26 AM, Murlin Wenzel <[email protected]> wrote: >> >>>> On 3/13/2010 at 12:32 AM, in message >> > <[email protected]>, Garrett >> > Cooper >> > <[email protected]> wrote: >> >> On Thu, Mar 11, 2010 at 7:48 AM, Murlin Wenzel <[email protected]> wrote: >> >>>>>> On 3/10/2010 at 05:15 AM, in message >> >>> <[email protected]>, Rishikesh K Rajak >> >>> <[email protected]> wrote: >> >>>> On Thu, Feb 25, 2010 at 11:56:15AM +0530, Rishikesh K Rajak wrote: >> >>>>> On Wed, Feb 24, 2010 at 05:08:56PM -0800, Garrett Cooper wrote: >> >>>>> > On Wed, Feb 24, 2010 at 3:49 PM, Murlin Wenzel <[email protected]> >> >>>>> > wrote: >> >>>>> > > Added clean_swap() to cleanup routine. This makes sure all >> >>>>> > > leftover swap >> >>>> files are removed. >> >>>>> > > >> >>>>> > > Signed-off-By: Murlin Ray Wenzel [email protected] >> >>>>> > >> >>>>> > Committed -- thanks! >> >>>>> > -Garrett >> >>>>> >> >>>>> Thanks Garret & Murlin. >> >>>> >> >>>> >> >>>> Hi Murlin, >> >>>> >> >>>> can you please look into this failure as it still fails on my SLES11 & >> >>>> RHEl5.4 >> >>>> boxes. >> >>>> >> >>>> [r...@mx3455a bin]# ./swapon03 >> >>>> swapon03 1 TFAIL : Failed swapon for file swapfile29: >> >>>> errno=EPERM(1): >> >>>> Operation not permitted >> >>>> swapon03 0 TWARN : tst_rmdir(): rmobj(/tmp/swasf2sLb) failed: >> >>>> unlink(/tmp/swasf2sLb/swapfile22) failed; errno=1: Operation not >> >>>> permitted >> >>>> swapon03 1 TFAIL : Failed to setup swaps >> >>>> >> >>>> attached is the strace log. >> >>> >> >>> That's the other part of the problem that I'm not sure what to do with >> >>> yet. >> >> The original test was written entirely based on the assumption that there >> >> were always a max of 30 swap files available. With newer kernels (SLE11 >> >> RHEL5.4) the kernel can be configured so that the max could be as low as >> >> 29 >> >> if not 28. The kernel is doing the right thing returning EPERM, but the > test >> >> needs to be re-worked to deal with new maximum limits/possibilites. >> >> >> >> It should actually be KERNEL_MAX - (CONFIG_MIGRATION enabled ? 2 : 0) >> >> - used_swap_devices ... >> >> >> >> NOTES >> >> The partition or path must be prepared with mkswap(8). >> >> >> >> There is an upper limit on the number of swap files that may be >> >> used, >> >> defined by the kernel constant MAX_SWAPFILES. Before kernel >> >> 2.4.10, >> >> MAX_SWAPFILES has the value 8; since kernel 2.4.10, it has the >> >> value >> >> 32. Since kernel 2.6.18, the limit is decreased by 2 (thus: 30) if >> >> the >> >> kernel is built with the CONFIG_MIGRATION option (which reserves >> >> two >> >> swap table entries for the page migration features of mbind(2) >> >> and >> >> migrate_pages(2)). >> >> >> >> The fun unknown is CONFIG_MIGRATION -- how do you know whether or >> >> not this is set from userspace? There's too much handwaving in this >> >> testcase that needs to be fixed. >> > >> > That's my point. There are even more config options in newer kernels >> > which > affect the number of swap files. AFAIK none of that info is available to > userspace app. The only known is MAX_SWAPFILES which is 32, or 8 on 2.4 > kernels. The current test makes an assumption that there would always be 32 > or 30 swapfiles available based on a kernel config at some point in the past. > I'm thinking the test should just use MAX_SWAPFILES(32 in this case), try to > create that many until EPERM error is returned, provide that TINFO to tester, > clean up everything and if that succeeds call the test a pass. It is too > ugly trying to start guessing about is 29 ok, or 30 ok or 32 ok with no way > of knowing how the kernel was configured. >> >> Here's a good question: where is this information stored in the >> kernel? If we can create an ltp test module to export some of this >> data [and extend it to other reporting as necessary] via sysfs >> STRICTLY for testing, it would help determinism a lot. >> Thanks, >> -Garrett ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
