Linux 2.6.0-test1 Ext3 Ooops. Reboot needed.

Hi again,
I still see some oops that I think are ext3 related. The machine now is
almost hang, it works via ssh but the X/KDE environment just locks up, I had to reboot it.

Find below the three oops I found during last 24 hours.

Regards,

 Unable to handle kernel paging request at virtual address e9000018
 printing eip:
c0168790
*pde = 00000000
Oops: 0000 [#1]
CPU:    0
EIP:    0060:[<c0168790>]    Not tainted
EFLAGS: 00010286

EIP is at find_inode_fast+0x20/0x70
eax: df456a90 ebx: 002f2b15 ecx: e9000018 edx: e9000018
esi: dfe03800 edi: dff8ecc4 ebp: dfe03800 esp: dd42de34
ds: 007b es: 007b ss: 0068
Process famd (pid: 19519, threadinfo=dd42c000 task=d428e0a0)

Stack: 00000000 dd42c000 db202800 002f2b15 c0168e42 dfe03800 dff8ecc4 002f2b15
       dff8ecc4 002f2b15 db202800 dfe03800 db202800 c018a54b dfe03800 002f2b15
       d9a8e07c fffffff4 d9af3738 d9af36d0 c015cd92 d9af36d0 db202800 dd42df38
Call Trace:
 [<c0168e42>] iget_locked+0x52/0xc0
 [<c018a54b>] ext3_lookup+0x6b/0xd0
 [<c015cd92>] real_lookup+0xd2/0x100
 [<c015d036>] do_lookup+0x96/0xb0
 [<c015d4e0>] link_path_walk+0x490/0x8a0
 [<c015ddf9>] __user_walk+0x49/0x60
 [<c0158fac>] vfs_lstat+0x1c/0x60
 [<c015965b>] sys_lstat64+0x1b/0x40
 [<c01092bb>] syscall_call+0x7/0xb

Code: 8b 11 0f 18 02 90 39 59 18 89 c8 74 13 85 d2 89 d1 75 ed 31
 <6>note: famd[19519] exited with preempt_count 1
Unable to handle kernel paging request at virtual address e9000018
 printing eip:
c0168790
*pde = 00000000
Oops: 0000 [#2]
CPU:    0
EIP:    0060:[<c0168790>]    Not tainted
EFLAGS: 00010286

EIP is at find_inode_fast+0x20/0x70
eax: df456a90 ebx: 002a2b1f ecx: e9000018 edx: e9000018
esi: dfe03800 edi: dff8ecc4 ebp: dfe03800 esp: dadbbe34
ds: 007b es: 007b ss: 0068
Process updatedb (pid: 25529, threadinfo=dadba000 task=d34b40c0)

Stack: 00000000 dadba000 dea27a80 002a2b1f c0168e42 dfe03800 dff8ecc4 002a2b1f
       dff8ecc4 002a2b1f dea27a80 dfe03800 dea27a80 c018a54b dfe03800 002a2b1f
       c4788030 fffffff4 df567a98 df567a30 c015cd92 df567a30 dea27a80 dadbbf38
Call Trace:
 [<c0168e42>] iget_locked+0x52/0xc0
 [<c018a54b>] ext3_lookup+0x6b/0xd0
 [<c015cd92>] real_lookup+0xd2/0x100
 [<c015d036>] do_lookup+0x96/0xb0
 [<c015d4e0>] link_path_walk+0x490/0x8a0
 [<c015ddf9>] __user_walk+0x49/0x60
 [<c0158fac>] vfs_lstat+0x1c/0x60
 [<c015965b>] sys_lstat64+0x1b/0x40
 [<c01092bb>] syscall_call+0x7/0xb

Code: 8b 11 0f 18 02 90 39 59 18 89 c8 74 13 85 d2 89 d1 75 ed 31
 <6>note: updatedb[25529] exited with preempt_count 1
bad: scheduling while atomic!
Call Trace:
 [<c0118667>] schedule+0x3b7/0x3c0
 [<c014084b>] unmap_page_range+0x4b/0x80
 [<c0140a4d>] unmap_vmas+0x1cd/0x230
 [<c0144608>] exit_mmap+0x78/0x190
 [<c011a084>] mmput+0x64/0xc0
 [<c011dd23>] do_exit+0x113/0x440
 [<c0116c60>] do_page_fault+0x0/0x479
 [<c010a360>] do_divide_error+0x0/0x100
 [<c0116d8c>] do_page_fault+0x12c/0x479
 [<c015233b>] __getblk+0x2b/0x60
 [<c0186263>] ext3_getblk+0x93/0x260
 [<c0150b5f>] wake_up_buffer+0xf/0x30
 [<c0150bac>] unlock_buffer+0x2c/0x50
 [<c015435c>] ll_rw_block+0x5c/0x90
 [<c0152293>] __find_get_block+0x73/0xf0
 [<c018a1d4>] ext3_find_entry+0x354/0x410
 [<c0116c60>] do_page_fault+0x0/0x479
 [<c0109cc5>] error_code+0x2d/0x38
 [<c0168790>] find_inode_fast+0x20/0x70
 [<c0168e42>] iget_locked+0x52/0xc0
 [<c018a54b>] ext3_lookup+0x6b/0xd0
 [<c015cd92>] real_lookup+0xd2/0x100
 [<c015d036>] do_lookup+0x96/0xb0
 [<c015d4e0>] link_path_walk+0x490/0x8a0
 [<c015ddf9>] __user_walk+0x49/0x60
 [<c0158fac>] vfs_lstat+0x1c/0x60
 [<c015965b>] sys_lstat64+0x1b/0x40
 [<c01092bb>] syscall_call+0x7/0xb

  ricardo galli

What is "famd"? File access monitor daemon? From where did you obtain it?

On Friday 18 July 2003 23:00, Andrew Morton shaped the electrons to shout:

"File alteration monitor", from Debian. It uses portmapperand is recommended to improve kde performance.

$ apt-cache show fam
Package: fam
Priority: extra
Section: admin
Installed-Size: 232
Maintainer: Joerg Wendland <[email protected]>
...
Description: File Alteration Monitor
 FAM monitors files and directories, notifying interested applications
 of changes.
 .
 This package provides a server that can monitor a given list of files
 and notify applications through a socket. If the kernel supports dnotify
 (kernels >= 2.4.x) FAM is notified directly by the kernel. Otherwise it has
 to poll the files' status. FAM can also provide a RPC service for monitoring
 remote files (such as on a mounted NFS filesystem).

Nevertheless I saw the same message the morning after updatedb run.

Regards,

  ricardo galli       GPG id C8114D34
  http://mnm.uib.es/~gallir/

OK.

I was attacked by dselect as a small child and have since avoided debian. Is there a tarball anywhere?

But was the "Process:" also famd in that case?

A bug in the dnotify code is unsurprising - it doesn't get used or tested much, and many things around it have changed.

On Friday 18 July 2003 23:27, Andrew Morton shaped the electrons to shout:

I tried Debian after I was 30 and apt-get was already born, never used that beast.

I just download the sources for you:
http://mnm.uib.es/~gallir/tmp/fam_2.6.10.orig.tar.gz
http://mnm.uib.es/~gallir/tmp/fam_2.6.10-1.diff.gz (Debian patch)

It was updatedb:

 Code: 8b 11 0f 18 02 90 39 59 18 89 c8 74 13 85 d2 89 d1 75 ed 31
  <6>note: updatedb[25529] exited with preempt_count 1
 bad: scheduling while atomic!
 Call Trace:
  [<c0118667>] schedule+0x3b7/0x3c0
  [<c014084b>] unmap_page_range+0x4b/0x80
  [<c0140a4d>] unmap_vmas+0x1cd/0x230
  [<c0144608>] exit_mmap+0x78/0x190
  [<c011a084>] mmput+0x64/0xc0
  [<c011dd23>] do_exit+0x113/0x440
  [<c0116c60>] do_page_fault+0x0/0x479
  [<c010a360>] do_divide_error+0x0/0x100
  [<c0116d8c>] do_page_fault+0x12c/0x479
  [<c015233b>] __getblk+0x2b/0x60
  [<c0186263>] ext3_getblk+0x93/0x260
  [<c0150b5f>] wake_up_buffer+0xf/0x30
  [<c0150bac>] unlock_buffer+0x2c/0x50
  [<c015435c>] ll_rw_block+0x5c/0x90
  [<c0152293>] __find_get_block+0x73/0xf0
  [<c018a1d4>] ext3_find_entry+0x354/0x410
  [<c0116c60>] do_page_fault+0x0/0x479
  [<c0109cc5>] error_code+0x2d/0x38
  [<c0168790>] find_inode_fast+0x20/0x70
  [<c0168e42>] iget_locked+0x52/0xc0
  [<c018a54b>] ext3_lookup+0x6b/0xd0
  [<c015cd92>] real_lookup+0xd2/0x100
  [<c015d036>] do_lookup+0x96/0xb0
  [<c015d4e0>] link_path_walk+0x490/0x8a0
  [<c015ddf9>] __user_walk+0x49/0x60
  [<c0158fac>] vfs_lstat+0x1c/0x60
  [<c015965b>] sys_lstat64+0x1b/0x40
  [<c01092bb>] syscall_call+0x7/0xb

  ricardo galli       GPG id C8114D34
  http://mnm.uib.es/~gallir/

Its standard in other systems too

%rpm -qi fam
Name : fam Relocations: (not
relocateable)
Version : 2.6.8 Vendor: Red Hat, Inc.
Release : 9 Build Date: Fri 31 Jan 2003
15:22:04 GMT
Install Date: Wed 02 Apr 2003 19:18:31 BST Build Host:
stripples.devel.redhat.com
Group : System Environment/Daemons Source RPM:
fam-2.6.8-9.src.rpm
Size : 185235 License: GPL/LGPL
Signature : DSA/SHA1, Mon 24 Feb 2003 05:47:28 GMT, Key ID
219180cddb42a60e
Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL : http://oss.sgi.com/projects/fam/
Summary : FAM, the File Alteration Monitor.
Description :
FAM, the File Alteration Monitor, provides a daemon and an API which applications can use for notification of changes in specific files or directories.

Fear ye not the perils of dselect and associated evils. Though it is, admittedly, one of the most user-malevolent tools known to man, with a UI designed by sadistic perverts from the very bowels of this earth, you don't need to use it to run debian (I never do). apt will do everything you need to do.

But, leaving aside for a moment, the holy crusade of righteousness ...

----------------------

NAME
deb - Debian binary package format

SYNOPSIS
filename.deb

...

FORMAT
The file is an ar archive with a magic number of !<arch>.

-----------------------

So it should be pretty easy to rip what you want out of there. If that doesn't work, I'll make you a tarball ;-)

M.

it's probably the SGI thing that dnotify()s directories for one of the GUI filemanagers out there...

I've seen similar oops with reiserfs, single user mode and a 70 proc write/read/delete loop. No idea at all yet on the cause. I was initially trying to blame akpm's change to keep the inode hashed until after delete_inode was called (the oops was always during the delete stage of run), but the logic looks right.

My oops all looked like this:

Unable to handle kernel NULL pointer dereference at virtual address

00000000
printing eip:
c01805e7
*pde = 00000000

Oops: 0000 [#1]
CPU:    1
EIP:    0060:[<c01805e7>]    Not tainted
EFLAGS: 00010286

EIP is at find_inode+0x17/0x70
eax: 00000000 ebx: d9bd826c ecx: 00000000 edx: eb5e992c
esi: f7d416e8 edi: f7f10134 ebp: e8f63d14 esp: e8f63d00
ds: 007b es: 007b ss: 0068
Process cp (pid: 1303, threadinfo=e8f62000 task=e66ba0c0)

Stack: f7d416e8 e8f63d54 f7d416e8 eb5e992c f7f10134 e8f63d40 c01807e4
f7d416e8
       f7f10134 c01d5270 e8f63d8c d4b301c8 1a62db00 00000000 f7d416e8
f7f10134
       e8f63d70 c0180f2e f7d416e8 f7f10134 c01d5270 c01d50f0 e8f63d8c
e8f63d74
Call Trace:
 [<c01807e4>] get_new_inode+0x54/0x1b0
 [<c01d5270>] reiserfs_find_actor+0x0/0x30
 [<c0180f2e>] iget5_locked+0xce/0x150
 [<c01d5270>] reiserfs_find_actor+0x0/0x30
 [<c01d50f0>] reiserfs_init_locked_inode+0x0/0x20
 [<c01d52e3>] reiserfs_iget+0x43/0xb0
 [<c01d5270>] reiserfs_find_actor+0x0/0x30
 [<c01d50f0>] reiserfs_init_locked_inode+0x0/0x20
 [<c01cf540>] reiserfs_lookup+0x200/0x2a0
 [<c017e6d9>] d_lookup+0x29/0x50
 [<c01729d9>] real_lookup+0xd9/0x100
 [<c0172cc6>] do_lookup+0x86/0xa0
 [<c0173215>] link_path_walk+0x535/0xa20
 [<c0173c4d>] __user_walk+0x3d/0x60
 [<c016e19b>] vfs_lstat+0x1b/0x60
 [<c017ce53>] dput+0x23/0x2c0
 [<c016e81b>] sys_lstat64+0x1b/0x40
 [<c016233b>] filp_close+0x4b/0x80
 [<c01623f6>] sys_close+0x86/0x100
 [<c010b3ef>] syscall_call+0x7/0xb

Code: 0f 18 00 90 39 b3 90 00 00 00 74 10 85 c0 89 c3 75 ec 31 c0