Re: [PATCH] Re: Oops with kernel 2.4.5 on heavy disk traffic

2001-06-10 Thread Alois Treindl
On Sun, 10 Jun 2001, Alexander Viro wrote: > Please, apply. What's happing here is simple - we set i_ino by > PID and get something out of range of per-process inode. Confusion > follows... Fix: move initializing ->u.proc_i.task past the check. > Then proc_delete_inode() will be happy with

[PATCH] Re: Oops with kernel 2.4.5 on heavy disk traffic

2001-06-10 Thread Alexander Viro
Please, apply. What's happing here is simple - we set i_ino by PID and get something out of range of per-process inode. Confusion follows... Fix: move initializing ->u.proc_i.task past the check. Then proc_delete_inode() will be happy with it. Alois, Bryce - that ought to fix the

Oops with kernel 2.4.5 on heavy disk traffic - reproduce

2001-06-10 Thread Alois Treindl
I have reported before a kernel oops. I now oberserved the same oops, with the same stack trace, and a Dell Poweredge 1550 with dual CPU, 1 gb RAM, only one disk and with little disk usage (most file activity via NFS, where this system is a client). The kernel is identical to the one reported

Oops with kernel 2.4.5 on heavy disk traffic

2001-06-10 Thread Alois Treindl
I run kernel 2.4.5 on Dell Poweredge 2450 with 1.5 Gb RAM and an onboard adaptec disk driver, dual pentium III 933 Mhz, 3 disks (160 mb transfer rate, 36 Gb each). When I put the system under heavy load today (load level 15, about 20 httpd processes and three concurrent copies of large file

Oops with kernel 2.4.5 on heavy disk traffic

2001-06-10 Thread Alois Treindl
I run kernel 2.4.5 on Dell Poweredge 2450 with 1.5 Gb RAM and an onboard adaptec disk driver, dual pentium III 933 Mhz, 3 disks (160 mb transfer rate, 36 Gb each). When I put the system under heavy load today (load level 15, about 20 httpd processes and three concurrent copies of large file

Oops with kernel 2.4.5 on heavy disk traffic - reproduce

2001-06-10 Thread Alois Treindl
I have reported before a kernel oops. I now oberserved the same oops, with the same stack trace, and a Dell Poweredge 1550 with dual CPU, 1 gb RAM, only one disk and with little disk usage (most file activity via NFS, where this system is a client). The kernel is identical to the one reported

[PATCH] Re: Oops with kernel 2.4.5 on heavy disk traffic

2001-06-10 Thread Alexander Viro
Please, apply. What's happing here is simple - we set i_ino by PID and get something out of range of per-process inode. Confusion follows... Fix: move initializing -u.proc_i.task past the check. Then proc_delete_inode() will be happy with it. Alois, Bryce - that ought to fix the

Re: [PATCH] Re: Oops with kernel 2.4.5 on heavy disk traffic

2001-06-10 Thread Alois Treindl
On Sun, 10 Jun 2001, Alexander Viro wrote: Please, apply. What's happing here is simple - we set i_ino by PID and get something out of range of per-process inode. Confusion follows... Fix: move initializing -u.proc_i.task past the check. Then proc_delete_inode() will be happy with it.

Re: oops with kernel 2.4.5

2001-06-08 Thread Adam
well, my guess is that the compiler misscompiles your kernel. stil _contrary_ to REPORTING_BUGS file you did not gave any info about your system. some usefull stuff you should email are (adjust it to your setup) a) cd /usr/src/linux rm fs/buffer.o make fs/buffer.o

Re: oops with kernel 2.4.5

2001-06-08 Thread Adam
well, my guess is that the compiler misscompiles your kernel. stil _contrary_ to REPORTING_BUGS file you did not gave any info about your system. some usefull stuff you should email are (adjust it to your setup) a) cd /usr/src/linux rm fs/buffer.o make fs/buffer.o