Messages in this thread | | | Date | Wed, 28 May 1997 11:51:56 -0400 (EDT) | From | Dave Wreski <> | Subject | Re: Cook 2.1.40 (mine ends with Oops.) |
| |
On Tue, 27 May 1997, Pavel Machek wrote: > 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].
I'm really not sure if its the same circumstances, but I had a similiar problem with 2.0.29 a while back, using EIDE disks, and 4x scsi 6-disc CDROM, on a 2940, and 32 megs RAM. I had a hardware problem somewhere in the system, which I boiled down to the motherboard. I replaced the motherboard, but to be sure that was the problem, I wanted to test it.
I wrote a script along the lines of 'while [ 1 ] ; cp -rv /mnt/cdrom0 /mnt/harddisk & cp -rv /mnt/cdrom0 /mnt/harddisk & sleep 200; done'
I let this run for more than 20 minutes, and eventually the disk/cdrom activity exceeded the sleep time, and it started to wrap around, coping files on top of itself. One loop hadn't finished before the next one began.
I eventually got all types of cp and kernel messages, until the system just locked up. I never did get it to run for more than 40 minutes before it gave up and hosed the machine.
I really think this is similiar to the problem you experienced. I can try and reproduce this if you think it would help.
> 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 really don't have time to configure a 2.1 capable machine, but I have redhat 4.2 on a few boxes that I could use..
Dave
| |