On 5/13/13 10:15 PM, Dave Chinner wrote: > On Mon, May 13, 2013 at 09:00:45PM -0500, Eric Sandeen wrote: >> On 5/13/13 8:15 PM, Dave Chinner wrote: >>> On Mon, May 13, 2013 at 04:55:18PM -0500, Eric Sandeen wrote: >>>> This should, in theory, fail a test if it introduces one of >>>> a handful of "serious" kernel taints. I mask on a few taint >>>> values because using an out of tree module or a non-GPL module >>>> should never fail a test, for example. >>>> >>>> Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx> >>> >>> I like the idea - it should catch lockdep failures and other such >>> problems. >>> >>>> --- >>>> >>>> diff --git a/check b/check >>>> index a79747e..a9cac4e 100755 >>>> --- a/check >>>> +++ b/check >>>> @@ -446,6 +445,11 @@ do >>>> fi >>>> rm -f core $seqres.notrun >>>> >>>> + if [ "$HOSTOS" == "Linux" ]; then >>>> + tainted=`sysctl -n kernel.tainted` >>>> + let "tainted &= $TAINT_FAIL" >>>> + fi >>>> + >>>> start=`_wallclock` >>>> $timestamp && echo -n " ["`date "+%T"`"]" >>>> [ ! -x $seq ] && chmod u+x $seq # ensure we can run it >>>> @@ -507,6 +511,19 @@ do >>>> "entire diff)" >>>> err=true >>>> fi >>>> + >>>> + # See if this run tainted the kernel due to oops, etc >>>> + if [ "$HOSTOS" == "Linux" ] >>>> + then >>>> + tainted2=`sysctl -n kernel.tainted` >>>> + let "tainted2 &= $TAINT_FAIL" >>>> + if [ "$tainted" != "$tainted2" ] >>>> + then >>>> + echo " Kernel taint changed from $tainted to $tainted2." >>>> + echo " See dmesg for details." >>>> + err=true >>>> + fi >>> >>> Should we dump the last 100 lines of dmesg into the output file >>> here? And then rely on the golden image match failing to fail the >>> test? >> >> Or into $seq.full . . I dunno. It's hard to know how much dmesg you'd need to get the right bits. >> >> Dumping all of it into $seq.full might be best; it only trips when it's a new taint, so won't >> fire for every test. > > Only problem with $seqres.full is that it is internal to the test > and so many tests will not remove one that is there before the test > starts. Hence you'll get growing files the never get removed from > repeated failures. Oh, I see what you mean, yeah. > Even just dumping the above error message into > the output file would be sufficient, I think, as the 10 line diff > output will state it pretty clearly as the first difference.... *shrug* I don't see the advantage of failing the test explicitly vs. breaking it via output, but if you like that better I don't really mind, I can change it to do that. -Eric > Cheers, > > Dave. > _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
