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

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

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 o

Oops with kernel 2.4.5 on heavy disk traffic - reproduce

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 be

Oops with kernel 2.4.5 on heavy disk traffic

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 tree

Re: oops with kernel 2.4.5

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 ema

oops with kernel 2.4.5

Hi we found in logs a oops and here are the results from ksymoops (2.4.1) Unable to handle kernel NULL pointer dereference at virtual address 0004 c012db89 *pde = Oops: 0002 CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: