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.
-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 -- Thanks & Regards Rishi LTP Maintainer IBM, LTC, Bangalore Please join IRC #ltp @ irc.freenode.net ------------------------------------------------------------------------------ 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
