lkml.org 
[lkml]   [2000]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Announce] Linux Test Project
On Thu, 10 Aug 2000, David Mansfield wrote:

> Nathan Straz wrote:
> >
> > SGI would like to announce the Linux Test Project. The goal of this
> > project is to create a formalized test system for the Linux kernel.
> >
> > We have released a set of 96 tests on the project's website
> > (http://oss.sgi.com/projects/ltp/). These tests exercise file systems
> > and system calls and can be used for stress testing or sanity tests.
> >
>
> One question: how is the framework going to handle tests which cause
> pathological behavior in the kernel. For example, 'infinite' hangs in
> the MM system during OOM, or crashes (OOPSes, panics) or deadlocks
> (process stuck in 'D' state). Most often these are the results of the
> tests I tend to run.
>
> Any testbed needs to handle these situations, at least somewhat. For
> example, if I leave a 12 hour regression going and leave the console,
> and I come back to see the system has rebooted itself, or is stuck solid
> - how do I know which test has 'failed'?

Simple: Write a note of what test is being performed to a file, then write
the results. It's obvious enough if you get a log file like:

Test 1343: Try stressing VM subsystem ... OK
Test 1344: Stress-testing mmap() ...

Obviously more information would be nice, but not always possible. Using a
serial console and logging the output on another machine should give
fairly good results, though?

> Ideally, in the case where something bad but not as fatal as complete
> lockup happens, the test bed should diagnose the fault. This could be
> capturing the oops, or running ps -alx to see where it's stuck.

Yep. Using a serial console should enable reasonable information capture,
and the script can have a standard set of "failure responses" to run if a
test returns a failure of any sort?

> In all the cases where I've tested the kernel, it has been a matter of
> 'Here is the test which crashes the kernel, let's see if it crashes this
> one, too' and I just want to throw this into the consideration of how to
> best create a test harness.

Indeed. The other question is, how to handle deadlocks? I'd probably use a
serial console, being logged by another machine; if the machine dies, just
reboot, then have the machine resume testing where it left off.


James.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.075 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site