On Wed, Jan 16, 2013 at 3:02 PM, shubham <[email protected]> wrote: > On 01/16/2013 06:45 PM, Sedat Dilek wrote: >> >> Hi, >> >> this is my first email to the LTP ML, so I am new and anot not >> familiar with known or unknown conventions here. >> >> I am using LTP, to be honest the "lite" test to check my Linux >> (upstream) and Linux-Next kernels. >> So, having run "runltplite.sh" successfully gives me a 1st impression >> or orientation this kernel has no bigger issues. >> >> To be honest I have checked with a minimal kernel-setup (a >> localmodconfig-ed setup with some debugging enabled). >> >> While looking trough the results especially searching for some >> pattern, I noticed the different spelling of the word "succeeded" VS. >> "succeded". >> The spell-checker integrated in Firefox v18.0 tells me "succeeded" >> with double-e is correct. >> >> [ SUCCEDED - one "E" ] >> >> $ egrep -i 'error|fail' >> runltplite-results_3.8.0-rc3-next20130116-2-iniza-generic.txt | egrep >> -i succeded >> flock01 1 TPASS : flock() succeded with Shared Lock, returned >> error number=0 >> flock01 2 TPASS : flock() succeded with Unlock, returned error >> number=0 >> flock01 3 TPASS : flock() succeded with Exclusive Lock, >> returned error number=0 >> >> [ SUCCEEDED - double "E" ] >> >> $ egrep -i 'error|fail' >> runltplite-results_3.8.0-rc3-next20130116-2-iniza-generic.txt | egrep >> -i succeeded >> madvise02 5 TFAIL : madvise succeeded unexpectedly >> open call succeededopen failed with EACCES as expectedopen call >> succeeded<<<execution_status>>> >> >> AFAICS flock01.c needs to be corrected: >> >> --- ltp-full-20120903.orig/testcases/kernel/syscalls/flock/flock01.c >> 2012-09-03 06:39:27.000000000 +0200 >> +++ ltp-full-20120903/testcases/kernel/syscalls/flock/flock01.c >> 2013-01-16 14:12:36.597859952 +0100 >> @@ -128,7 +128,7 @@ int main(int argc, char **argv) >> continue; /*next loop for MTKERNEL >> */ >> } else { >> tst_resm(TPASS, >> - "flock() succeded with %s, >> returned error number=%d", >> + "flock() succeeded with %s, >> returned error number=%d", >> test_cases[i].opt, TEST_ERRNO); >> } >> >> Not sure if you like that patch sent via git-email as a separate patch? >> > > We are not very concerned about some typos in log messages. Please come up > with a fix for a broken test case or something which will really add a value > to the LTP. Your patches are welcome. Kindly refer the documentation > provided with LTP for the format of patch. >
Hi, as said I am knew to LTP. Such a typo makes grepping for special search-patterns difficult. I was searching for real failures by sorting out "expected" and "succeeded" lines. Even this is a trivial fix for you - it helped here :-). Not sure what you are expecting from me. Might be I flood ltp-results ML with the results of my Linux-Next kernels. Unsure if this helps people or not. Personally, I don't like the outputs of results... Especially start/end tags should include the (file)name of the testcase. But I had no deeper look into the results and only run the "lite" test-script. Looking into the README file I see I am missing some kernel-configs to be enabled. Not sure if I really what to dig that deep into LTP. Of course, LTP is a helpful testing-framework. It gives me a better feeling than just only test my kernels... 1. on bare metal (not in any VM) 2. in daily usage I could catch a madvise regression in Linux-Next and reported it. Thanks! Regards, - Sedat - [1] http://marc.info/?l=linux-next&m=135819894717604&w=2 > Thanks > ------------------------------------------------------------------------------ Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
