Messages in this thread | | | Date | Thu, 10 Aug 2000 17:03:15 +0100 (BST) | From | James Sutherland <> | Subject | Re: [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/
| |