Messages in this thread | | | Date | Tue, 27 May 1997 23:02:48 +0200 | From | Pavel Machek <> | Subject | Cook 2.1.40 (mine ends with Oops.) |
| |
Hi!
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 ;-).
| |