Bug 87571 - kernel oops after "VFS: Busy inodes after unmount"
kernel oops after "VFS: Busy inodes after unmount"
Status: CLOSED DUPLICATE of bug 97677
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.2
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-03-28 17:55 EST by Stephan Koledin
Modified: 2007-04-18 12:52 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 13:52:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Stephan Koledin 2003-03-28 17:55:45 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623
Debian/1.0.0-0.woody.1

Description of problem:
RedHat 7.2 Machines within a processing farm have begun to occasionally oops,
apparently during periods of high load/activity.

Typically, a number if machines(5-10) will all oops around the same time.
Machines are pingable, but no other network services available. Serial console
is available, and allows root login. System is up with minimal
services/processes running. Anything associated with network connectivity has
died. dmesg shows the following:

VFS: Busy inodes after unmount. Self-destruct in 5 seconds.  Have a nice day...
md: recovery thread got woken up ...
md: recovery thread finished ...
Unable to handle kernel NULL pointer dereference at virtual address 00000004
 printing eip:
c014b901
*pde = 00000000
Oops: 0000
lm78 i2c-isa i2c-proc i2c-dev i2c-core vfat fat ide-cd cdrom binfmt_misc nfs l
CPU:    0
EIP:    0010:[<c014b901>]    Not tainted
EFLAGS: 00010246

EIP is at destroy_inode [kernel] 0x21 (2.4.18-17.7.x)
eax: 00000000   ebx: e9c39ad0   ecx: 00000000   edx: e9c39ad0
esi: e9c39ad0   edi: 00000001   ebp: 00000011   esp: c34b1f60
ds: 0018   es: 0018   ss: 0018
Process kswapd (pid: 5, stackpage=c34b1000)
Stack: e9c39ad0 c014ce05 e9c39ad0 f6785740 ea4b5de0 00000246 00000246 c1fdf8b8 
       c1fdf8a0 e9c39ad0 c014aa88 e9c39ad0 e9c39ad0 c34b0000 c011ffc0 00000003 
       00000000 00000000 00000282 fffcd952 c0131d1c 00000000 000040e6 00000000 
Call Trace: [<c014ce05>] iput [kernel] 0x1c5 (0xc34b1f64))
[<c014aa88>] prune_dcache [kernel] 0xf8 (0xc34b1f88))
[<c011ffc0>] process_timeout [kernel] 0x0 (0xc34b1f98))
[<c0131d1c>] wakeup_memwaiters [kernel] 0xdc (0xc34b1fb0))
[<c014ae00>] shrink_dcache_memory [kernel] 0x20 (0xc34b1fc8))
[<c0131ad1>] kswapd [kernel] 0x301 (0xc34b1fd0))
[<c0105000>] stext [kernel] 0x0 (0xc34b1fe8))
[<c0107146>] kernel_thread [kernel] 0x26 (0xc34b1ff0))
[<c01317d0>] kswapd [kernel] 0x0 (0xc34b1ff8))


Code: 8b 40 04 85 c0 74 08 53 ff d0 59 eb 11 89 f6 53 8b 15 d4 67 
 

The machines automount a substantial number of NFS volumes, depending on what
work is being done on the machine at a particular time.

Any ideas on what could be going on here, or any additional steps I can take to
debug this issue? 





Version-Release number of selected component (if applicable):
kernel-2.4.18-17.7.x

How reproducible:
Sometimes

Steps to Reproduce:
Unknown, but could be related to high load and network/file activity.

Additional info:

dmesg shows the following on a oops'd machine:

VFS: Busy inodes after unmount. Self-destruct in 5 seconds.  Have a nice day...
md: recovery thread got woken up ...
md: recovery thread finished ...
Unable to handle kernel NULL pointer dereference at virtual address 00000004
 printing eip:
c014b901
*pde = 00000000
Oops: 0000
lm78 i2c-isa i2c-proc i2c-dev i2c-core vfat fat ide-cd cdrom binfmt_misc nfs l
CPU:    0
EIP:    0010:[<c014b901>]    Not tainted
EFLAGS: 00010246

EIP is at destroy_inode [kernel] 0x21 (2.4.18-17.7.x)
eax: 00000000   ebx: e9c39ad0   ecx: 00000000   edx: e9c39ad0
esi: e9c39ad0   edi: 00000001   ebp: 00000011   esp: c34b1f60
ds: 0018   es: 0018   ss: 0018
Process kswapd (pid: 5, stackpage=c34b1000)
Stack: e9c39ad0 c014ce05 e9c39ad0 f6785740 ea4b5de0 00000246 00000246 c1fdf8b8 
       c1fdf8a0 e9c39ad0 c014aa88 e9c39ad0 e9c39ad0 c34b0000 c011ffc0 00000003 
       00000000 00000000 00000282 fffcd952 c0131d1c 00000000 000040e6 00000000 
Call Trace: [<c014ce05>] iput [kernel] 0x1c5 (0xc34b1f64))
[<c014aa88>] prune_dcache [kernel] 0xf8 (0xc34b1f88))
[<c011ffc0>] process_timeout [kernel] 0x0 (0xc34b1f98))
[<c0131d1c>] wakeup_memwaiters [kernel] 0xdc (0xc34b1fb0))
[<c014ae00>] shrink_dcache_memory [kernel] 0x20 (0xc34b1fc8))
[<c0131ad1>] kswapd [kernel] 0x301 (0xc34b1fd0))
[<c0105000>] stext [kernel] 0x0 (0xc34b1fe8))
[<c0107146>] kernel_thread [kernel] 0x26 (0xc34b1ff0))
[<c01317d0>] kswapd [kernel] 0x0 (0xc34b1ff8))


Code: 8b 40 04 85 c0 74 08 53 ff d0 59 eb 11 89 f6 53 8b 15 d4 67
Comment 1 Brent Fox 2004-07-07 10:26:42 EDT

*** This bug has been marked as a duplicate of 97677 ***
Comment 2 Red Hat Bugzilla 2006-02-21 13:52:23 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.
Comment 3 daniel muturi 2006-11-30 11:36:19 EST
(In reply to comment #2)
> Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

What was the resolution of this problem? I do not see any reference to a 
solution/fix.

Note You need to log in before you can comment on or make changes to this bug.