Here is recipe to do something pretty bad to your 2.1.40. On my side,
it died in schedule() at the end [but this might be due to
modifications in my kernel & I was too lazy to copy that one screen
full of info - call list was pretty big], but even before that machine
does unnice thing.
Ingrediens:
Take one linux system, one slow but big device, and one ext2
filesystem [probably not critical].
Create filesystem on _really_ slow and big device. Maybe even
slow but big harddrive could be ok. You probably need one much faster
device for this to work. Anyway do a cp -a /usr/TeX /slow. Run top and
enjoy:
For a while, everything is ok. Then, linux realizes that it is
too much of dirty data in ram and starts writing. Alas, device is
slow. And cp runs at max speed. More and more memory is consumed. And
cp still runs at max speed. Proccesses get swapped out, and you end
with total rss ~1MB and total buff ~15MB. Machine is in so bad state
that kill is running for minutes.
After that my machine died in schedule(). Yours may or may
not. I consider this to be design problem somewhere, IMHO cp should be
delayed until there's enough memory. I think that people already
reported similar problems (I belive that with badblocks). I believe
that this is _big_ problem.
BTW please try to repeat this, somebody [and report me
success]. My kernel has some custom patches and I do not believe
it. If you get oops in schedule() on virgin kernel, it will be pretty
important.
-- I'm really pavel@atrey.karlin.mff.cuni.cz. Pavel Look at http://atrey.karlin.mff.cuni.cz/~pavel ;-).