Messages in this thread | | | From | "Jorge Nerin" <> | Date | Mon, 17 May 1999 23:22:03 +0200 | Subject | Re: kernel ooops... no timeout on find |
| |
> > > On Tue, 11 May 1999, Craig Armour wrote: > > > Hi, > > > > here is a kernel oops I seem to get very regularly. the system is an > > Asus P2bDS? dual PII with 512meg ram kernel is 2.2.7 . There are no NFS > > file systems on this box. > > > > I think this could be linked to a problem I'm having with phantom loads > > and sleeping find process running in state D > > > > > > 2:54pm up 6 days, 1:03, 6 users, load average: 1.03, 1.01, 1.00 > > 86 processes: 85 sleeping, 1 running, 0 zombie, 0 stopped > > CPU states: 1.1% user, 2.7% system, 0.0% nice, 96.2% idle > > > > 3554 ? D 0:01 find / ( -fstype nfs -o -fstype NFS -o -type d -regex > > \(^/tm > > > > the problem is occuring in both smp mode and non-smp mode. I'm guessing > > (becuase I don't know much of how kernels work...) that there is no time > > out for NFS file systems... in the interim, I'm going to kill updatedb > > from the cron as I believe this is the parent process. I can't kill the > > find process. > > > > any patches/ideas would be very helpfull... at the moment, I'm > > struggling to get more than two weeks of uptime out of what should be an > > enterprise server. > > > Darn... I see what happened, but how... You've got the following nice > combination: > a) extra pointer to dentry. OK, that would normally give you > KERN_CRIT-level printk followed by forced oops. > b) non-NULL d_parent not equal to dentry in question. > c) NULL (or otherwise invalid) pointer in parent's d_name. > That way you got an oops trying to pass arguments to printk. > > Sheesh... It may be a random memory corruption from whatever reason, but > since you have it reproducably I suspect that it's a real dcache corruption. > > Could you try the following: ........ > > ... and look what it will give. inode number and device may at least hint > where the hell it happens. > It's not the first report indicating that something is wrong with > dcache and this one at least may narrow the things down. Please, post the > resulting log as soon as you'll reproduce the oops with the patched > variant in place, OK? > Cheers, > Al > > - > Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/ > To Unsubscribe: send "unsubscribe linux-smp" to majordomo@vger.rutgers.edu
Well in 2.2.5 I also got a pair of oopses and finds in D state:
Apr 10 02:26:49 quartz kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000
Apr 10 02:26:49 quartz kernel: current->tss.cr3 = 023aa000, %cr3 = 023aa000
Apr 10 02:26:49 quartz kernel: *pde = 00000000 Apr 10 02:26:49 quartz kernel: Oops: 0002 Apr 10 02:26:49 quartz kernel: CPU: 1 Apr 10 02:26:50 quartz kernel: EIP: 0010:[8390:ei_open+-36832/96] Apr 10 02:26:50 quartz kernel: EFLAGS: 00010212 Apr 10 02:26:50 quartz kernel: eax: 00000038 ebx: c1ac1edc ecx: 0000000e edx: 00000038
Apr 10 02:26:50 quartz kernel: esi: c0905440 edi: 00000000 ebp: 00000038 esp: c1ac1e28
Apr 10 02:26:50 quartz kernel: ds: 0018 es: 0018 ss: 0018 Apr 10 02:26:50 quartz kernel: Process find (pid: 5217, process nr: 88, stackpage=c1ac1000)
Apr 10 02:26:50 quartz kernel: Stack: c484abe5 00000000 c0905440 00000038 c1ac1edc c3a4f7fc c484b9c6 c1ac1edc
Apr 10 02:26:50 quartz kernel: c0905440 00000038 c1ac1edc c3a4f7fc 00000000 c1ac1f1c 00005487 00000003
Apr 10 02:26:50 quartz kernel: c484abcc 000000a8 c484b005 c0905440 c4850fc8 00000004 00000200 c3a4f7fc
Apr 10 02:26:50 quartz kernel: Call Trace: [8390:ei_open+-33895/96] [8390:ei_open+-30342/96] [8390:ei_open+-33920/96] [8390:ei_open+- 32839/96] [8390:ei_open+-8324/96] [8390:ei_open+-29675/96] [8390:ei_open+-20961/96]
Apr 10 02:26:50 quartz kernel: [8390:ei_open+-8324/96] [8390:ei_open+-33920/96] [8390:ei_open+-20840/96] [8390:ei_open+- 38703/96] [d_alloc+24/336] [real_lookup+72/112] [lookup_dentry+266/440] [__namei+41/92]
Apr 10 02:26:50 quartz kernel: [sys_newlstat+46/148] [system_call+52/56]
Apr 10 02:26:50 quartz kernel: Code: f3 a5 a8 02 74 02 66 a5 a8 01 74 01 a4 5e 5f c3 57 56 8b 7c
And....
Apr 8 19:11:07 quartz kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000
Apr 8 19:11:07 quartz kernel: current->tss.cr3 = 010f7000, %cr3 = 010f7000
Apr 8 19:11:07 quartz kernel: *pde = 00000000 Apr 8 19:11:07 quartz kernel: Oops: 0002 Apr 8 19:11:07 quartz kernel: CPU: 0 Apr 8 19:11:07 quartz kernel: EIP: 0010:[8390:ei_open+-36832/96] Apr 8 19:11:07 quartz kernel: EFLAGS: 00010216 Apr 8 19:11:07 quartz kernel: eax: 00000120 ebx: c3fa1edc ecx: 00000048 edx: 00000120
Apr 8 19:11:07 quartz kernel: esi: c0d95400 edi: 00000000 ebp: 00000120 esp: c3fa1e28
Apr 8 19:11:07 quartz kernel: ds: 0018 es: 0018 ss: 0018 Apr 8 19:11:07 quartz kernel: Process find (pid: 2572, process nr: 87, stackpage=c3fa1000)
Apr 8 19:11:07 quartz kernel: Stack: c484abe5 00000000 c0d95400 00000120 c3fa1edc c0b274cc c484b9c6 c3fa1edc
Apr 8 19:11:07 quartz kernel: c0d95400 00000120 c3fa1edc c0b274cc 00000000 c3fa1f1c 00002eee 00000003
Apr 8 19:11:07 quartz kernel: c484abcc 000000a8 c484b005 c0d95400 c4850fc8 00000004 00000200 c0b274cc
Apr 8 19:11:07 quartz kernel: Call Trace: [8390:ei_open+-33895/96] [8390:ei_open+-30342/96] [8390:ei_open+-33920/96] [8390:ei_open+- 32839/96] [8390:ei_open+-8324/96] [8390:ei_open+-29675/96] [8390:ei_open+-20961/96]
Apr 8 19:11:07 quartz kernel: [8390:ei_open+-8324/96] [8390:ei_open+-33920/96] [8390:ei_open+-20840/96] [8390:ei_open+- 38703/96] [d_alloc+24/336] [real_lookup+72/112] [lookup_dentry+266/440] [__namei+41/92]
Apr 8 19:11:07 quartz kernel: [sys_newlstat+46/148] [system_call+52/56]
Apr 8 19:11:07 quartz kernel: Code: f3 a5 a8 02 74 02 66 a5 a8 01 74 01 a4 5e 5f c3 57 56 8b 7c
And the ltrace is...
strrchr("/mnt/winnt/Archivos de programa/"..., '/') = "/GROUND" fnmatch(0xbffffd0c, 0x080647cf, 4, 0x08064780, 0x08056938) = 1 __errno_location() = 0x400a9484 opendir("GROUND" <unfinished ...> SYS_stat(0x080647cf, 0xbffff384, 0x400a86cc, 0xbffff3ec, 85) = 0 SYS_open("GROUND", 2048, 027777772310) = 5 SYS_fcntl(5, 2, 1, 0x080647cf, 85) = 0 <... opendir resumed> ) = 0x08056f00 malloc(4096) = 0x08064b88 readdir(0x08056f00 <unfinished ...> SYS_lseek(5, 0, 1, 0x08064b88, 0x08056f00) = 0 SYS_getdents(5, 0xbfffb680, 15729, 0xbfffb680, 0x08068380
And it stops here....
El alumno no saca ceros; colecciona huevos de colores. (4/10) no habla; intercambia opiniones no enfada al profesor; estudia sus reacciones
\_/, _ | @___oo ( Jorge Nerin /\ /\ / (___,,,}_--~ ) /^\) ^\/ _) ~__ jnerin@svalero.es ) /^\/ _) (_ ) _ / / _) ( jnerinl@nexo.es /\ )/\/ || | )_) < > |(,,) )__) || / \)___)\ | \____( )___) )___ \______(_______;;; __;;;
ZU en Zaragoza (Spain)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |