Bug 434878 - Kernel panic - Unable to handle kernel paging request
Kernel panic - Unable to handle kernel paging request
Status: CLOSED DUPLICATE of bug 196915
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.5
i686 Linux
high Severity medium
: rc
: ---
Assigned To: Josef Bacik
Martin Jenner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-25 18:02 EST by MIdRange Support
Modified: 2010-09-08 21:44 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-10 08:38:57 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)
sysreport (4.98 MB, application/octet-stream)
2008-02-25 18:16 EST, MIdRange Support
no flags Details

  None (edit)
Description MIdRange Support 2008-02-25 18:02:06 EST
Description of problem:


Version-Release number of selected component (if applicable):
2.6.9-55.ELSMP

How reproducible:
single occurrance at this point.

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Feb 25 16:08:36 hsg09lt kernel: Unable to handle kernel paging request at 
virtual address 2016c383
Feb 25 16:08:36 hsg09lt kernel:  printing eip:
Feb 25 16:08:36 hsg09lt kernel: f8a882eb
Feb 25 16:08:36 hsg09lt kernel: *pde = 00000000
Feb 25 16:08:36 hsg09lt kernel: Oops: 0000 [#1]
Feb 25 16:08:36 hsg09lt kernel: SMP 
Feb 25 16:08:36 hsg09lt kernel: Modules linked in: nfs cpqci(U) mptctl mptbase 
sg nfsd exportfs lockd nfs_acl md5 ipv6 parport_pc lp parport pidentd(U) 
autofs4 i2c_dev i2c_core s
unrpc 8021q deadman(U) emcpdm(U) emcpgpx(U) emcpmpx(U) emcp(U) emcplib(U) 
button battery ac cpqphp tg3(U) bonding(U) floppy dm_snapshot dm_zero 
dm_mirror ext3 jbd dm_mod qla2300(
U) cciss usb_storage uhci_hcd ohci_hcd ehci_hcd sd_mod qla2xxx(U) scsi_mod 
qla2xxx_conf(U)
Feb 25 16:08:36 hsg09lt kernel: CPU:    3
Feb 25 16:08:36 hsg09lt kernel: EIP:    0060:[<f8a882eb>]    Tainted: P      
VLI
Feb 25 16:08:36 hsg09lt kernel: EFLAGS: 00010216   (2.6.9-55.ELsmp) 
Feb 25 16:08:36 hsg09lt kernel: EIP is at ext3_get_inode_block+0x26/0xf4 [ext3]
Feb 25 16:08:36 hsg09lt kernel: eax: 2016c201   ebx: 032016c2   ecx: 
f159def8   edx: 00000001
Feb 25 16:08:36 hsg09lt kernel: esi: e3c329e8   edi: 00000001   ebp: 
2016c203   esp: f159de80
Feb 25 16:08:36 hsg09lt kernel: ds: 007b   es: 007b   ss: 0068
Feb 25 16:08:36 hsg09lt kernel: Process oracle (pid: 1970, threadinfo=f159d000 
task=f28bf8b0)
Feb 25 16:08:36 hsg09lt kernel: Stack: f5596580 c015d497 00001000 f159def8 
00000000 e3c329e8 00000001 d6e68de8 
Feb 25 16:08:36 hsg09lt kernel:        f8a883da f8a8c832 00000000 eedc46bc 
00000000 eedc46bc f159def8 00000000 
Feb 25 16:08:36 hsg09lt kernel:        e3c329e8 f159def8 f1706de8 f8a88f05 
d6e68de8 d6e68de8 d6e68d18 00000000 
Feb 25 16:08:36 hsg09lt kernel: Call Trace:
Feb 25 16:08:36 hsg09lt kernel:  [<c015d497>] __getblk+0x2b/0x49
Feb 25 16:08:36 hsg09lt kernel:  [<f8a883da>] ext3_get_inode_loc+0x21/0x226 
[ext3]
Feb 25 16:08:36 hsg09lt kernel:  [<f8a8c832>] __ext3_journal_stop+0x19/0x34 
[ext3]
Feb 25 16:08:36 hsg09lt kernel:  [<f8a88f05>] 
ext3_reserve_inode_write+0x21/0x81 [ext3]
Feb 25 16:08:36 hsg09lt kernel:  [<f8a8bdd3>] ext3_orphan_del+0x159/0x1d9 
[ext3]
Feb 25 16:08:36 hsg09lt kernel:  [<f8a85f9e>] ext3_delete_inode+0x69/0xaa 
[ext3]
Feb 25 16:08:36 hsg09lt kernel:  [<f8a85f35>] ext3_delete_inode+0x0/0xaa [ext3]
Feb 25 16:08:36 hsg09lt kernel:  [<c0172020>] generic_delete_inode+0xa2/0x104
Feb 25 16:08:36 hsg09lt kernel:  [<c01721fc>] iput+0x5f/0x61
Feb 25 16:08:36 hsg09lt kernel:  [<c016f877>] dput+0x17b/0x1a7
Feb 25 16:08:36 hsg09lt kernel:  [<c015be1b>] __fput+0xda/0x100
Feb 25 16:08:36 hsg09lt kernel:  [<c015a9b0>] filp_close+0x59/0x5f
Feb 25 16:08:36 hsg09lt kernel:  [<c0123baf>] put_files_struct+0x57/0xc0
Feb 25 16:08:36 hsg09lt kernel:  [<c01247d0>] do_exit+0x252/0x40f
Feb 25 16:08:36 hsg09lt kernel:  [<c0124a78>] sys_exit_group+0x0/0xd
Feb 25 16:08:36 hsg09lt kernel:  [<c02d5ee3>] syscall_call+0x7/0xb
Feb 25 16:08:36 hsg09lt kernel:  [<c02d007b>] unix_dgram_recvmsg+0x11/0x1da
Feb 25 16:08:36 hsg09lt kernel: Code: 5b 5e 5f 5d c3 55 89 c5 57 56 53 83 ec 
10 89 d3 89 4c 24 0c 83 fa 02 0f 95 c0 31 d2 83 fb 08 0f 95 c2 85 d0 74 10 83 
fb 07 74 0b <8b> 85 80 
01 00 00 3b 58 50 72 0d 8b 8d 80 01 00 00 8b 41 2c 3b 
Feb 25 16:08:36 hsg09lt kernel:  <0>Fatal exception: panic in 5 seconds
Comment 1 MIdRange Support 2008-02-25 18:16:40 EST
Created attachment 295857 [details]
sysreport

sysreport
Comment 2 Josef Bacik 2008-03-12 14:49:45 EDT
Do you have a vmcore from this panic?
Comment 3 MIdRange Support 2008-03-17 14:52:02 EDT
Not that I can find.
Comment 4 Josef Bacik 2008-03-18 13:35:09 EDT
    52e4:       74 10                   je     52f6 
<ext3_get_inode_block+0x31>
    52e6:       83 fb 07                cmp    $0x7,%ebx
    52e9:       74 0b                   je     52f6 
<ext3_get_inode_block+0x31>
    52eb:       8b 85 80 01 00 00       mov    0x180(%ebp),%eax
    52f1:       3b 58 50                cmp    0x50(%eax),%ebx
    52f4:       72 0d                   jb     5303 
<ext3_get_inode_block+0x3e>
    52f6:       8b 8d 80 01 00 00       mov    0x180(%ebp),%ecx
    52fc:       8b 41 2c                mov    0x2c(%ecx),%eax
    52ff:       3b 18                   cmp    (%eax),%ebx
    5301:       76 1b                   jbe    531e 
<ext3_get_inode_block+0x59>

        if ((ino != EXT3_ROOT_INO &&
                ino != EXT3_JOURNAL_INO &&
                ino != EXT3_RESIZE_INO &&
                ino < EXT3_FIRST_INO(sb)) ||
                ino > le32_to_cpu(
                        EXT3_SB(sb)->s_es->s_inodes_count)) {
                ext3_error (sb, "ext3_get_inode_block",
                            "bad inode number: %lu", ino);
                return 0;
        }


we're panicing doing the 

    52eb:       8b 85 80 01 00 00       mov    0x180(%ebp),%eax

which is 

EXT3_SB(s), which is just sb->s_fs_info.  sb is %edb 2016c203 which is 
invalid, so ext3_get_inode_block was passed an invalid sb from 
ext3_get_inode_loc, which just passes inode->i_sb.  If i_sb was corrupted 
somwhere along the line it should have paniced earlier, as we get the sb from 
the inode in the orphan code, so we would have panic'ed thereabouts.  See if 
you can reproduce without all of those tainting modules, or setup netdump and 
capture a vmcore next time this problem happens.
Comment 6 Josef Bacik 2008-12-10 08:38:57 EST

*** This bug has been marked as a duplicate of bug 196915 ***
Comment 7 Lachlan McIlroy 2010-09-06 02:59:51 EDT
The kernel that crashed here is 2.6.9-55.ELsmp and it already includes the fix from BZ196915.  So either this isn't a duplicate or the fix from BZ196915 isn't complete.
Comment 8 Lachlan McIlroy 2010-09-08 21:44:21 EDT
Looks more like a duplicate of BZ629143.

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