Bug 434878
| Summary: | Kernel panic - Unable to handle kernel paging request | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | MIdRange Support <mid-rangesupport> | ||||
| Component: | kernel | Assignee: | Josef Bacik <jbacik> | ||||
| Status: | CLOSED DUPLICATE | QA Contact: | Martin Jenner <mjenner> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 4.5 | CC: | dejohnso, esandeen, jbacik, lmcilroy, vgoyal | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | i686 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2008-12-10 13:38:57 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
MIdRange Support
2008-02-25 23:02:06 UTC
Created attachment 295857 [details]
sysreport
sysreport
Do you have a vmcore from this panic? Not that I can find. 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.
*** This bug has been marked as a duplicate of bug 196915 *** |