On Tue, Feb 19, 2008 at 11:47:11PM +0300, wrote: > On Wed, Feb 13, 2008 at 03:42:02PM +1100, Nick Piggin wrote: > > On Wednesday 13 February 2008 11:17, Nick Piggin wrote: > > > On Wednesday 13 February 2008 09:27, Alexey Dobriyan wrote: > > > > > > It's a trivial dumb module which does nothing but loads and unloads. > > > > I redid ftest03 later without any suspicious activity and it oopsed the > > > > same way. > > > > > > Ah crap. Hmm, maybe I didn't consider all cases with my last patch to > > > that code... is there an easy way to get the ftest03 source and run > > > it? > > > > OK I didn't realise it is a test from ltp. > > > > But I can't reproduce it for the life of me with the latest git kernel > > and latest ltp tarball. > > > > Is it easy to reproduce? > > Well, yes. SMP, non-preemptible kernel, (and maxcpus=1 really helps!) > > while true; do > ./ftest03 > done > > This alone seems stable, but starting whole LTP in parallel downs the box > very quickly. > > > Are you reproducing it simply by running the > > ftest03 binary directly from the shell? How many times between oopses? > > It is multi-process but no threads, so races should be minimal down > > this path -- can you get an strace of the failing process?
Speaking of multi-proceseness, changing MAXCHILD to 1, nchild to 1, AFAICS, generates one child which oopses the very same way (in parallel with generic LTP) But, lowering MAXIOVCNT to 8 generates no oops. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
