[nflug] Kernel Panic Help

[David J. Andruczyk]

--- Justin Bennett <Justin.Bennett at Dynabrade.com> wrote:

> I could use a little help deciphering a kernel panic. I've had this
> box 
> do this twice in one day. Once very early in the morning, and once
> about 
> 7:30pm. It looks in this instant it was f-prot (my nightly virus scan
> of 
> the user file systems) that triggered the panic, however the first
> time 
> f-prot wasn't running. The first time I didn't get an entry in 
> /var/log/messages. I think maybe it's an issue with the gigabit
> network 
> card?
> 
> 
> 
>  kernel: Unable to handle kernel NULL pointer dereference at virtual 
> address 00000020
>  kernel:  printing eip:
>  kernel: c0151f5a
>  kernel: *pde = 00000000
>  kernel: Oops: 0000
>  kernel: Kernel 2.4.9-e.65
>  kernel: CPU:    0
>  kernel: EIP:    0010:[find_inode+26/80]    Not tainted
>  kernel: EIP:    0010:[<c0151f5a>]    Not tainted
>  kernel: EFLAGS: 00010213
>  kernel: EIP is at find_inode [kernel] 0x1a
>  kernel: eax: 00000000   ebx: 00000000   ecx: 0000ffff   edx:
> 00000000
>  kernel: esi: 00000000   edi: 001ef0e4   ebp: c21875a8   esp:
> c63abe30
>  kernel: ds: 0018   es: 0018   ss: 0018
>  kernel: Process f-prot (pid: 1695, stackpage=c63ab000)
>  kernel: Stack: 001ef0e4 c21875a8 001ef0e4 f242c400 c0152395 f242c400
> 
> 001ef0e4 c21875a8
>  kernel:        00000000 00000000 00000001 eb221be0 f883a843 ea813b40
> 
> 001ef0e4 e493da60
>  kernel:        c0928580 e493d260 f884d348 f242c400 001ef0e4 00000000
> 
> 00000000 c092b090
>  kernel: Call Trace: [iget4+69/224] iget4 [kernel] 0x45 (0xc63abe40)
>  kernel: Call Trace: [<c0152395>] iget4 [kernel] 0x45 (0xc63abe40)
>  kernel: 
>
[e1000:__insmod_e1000_O/lib/modules/2.4.9-e.65/kernel/drivers/addo+-1226685/96]
> 
> journal_stop_R1e97930d [jbd] 0x1a3 (0xc63abe60)
>  kernel: [<f883a843>] journal_stop_R1e97930d [jbd] 0x1a3 (0xc63abe60)
>  kernel: 
>
[e1000:__insmod_e1000_O/lib/modules/2.4.9-e.65/kernel/drivers/addo+-1150136/96]
> 
> ext3_lookup [ext3] 0x58 (0xc63abe78)
>  kernel: [<f884d348>] ext3_lookup [ext3] 0x58 (0xc63abe78)
>  kernel: [real_lookup+79/192] real_lookup [kernel] 0x4f (0xc63abea8)
>  kernel: [<c0147e4f>] real_lookup [kernel] 0x4f (0xc63abea8)
>  kernel: [path_walk+1542/2192] path_walk [kernel] 0x606 (0xc63abec4)
>  kernel: [<c01485c6>] path_walk [kernel] 0x606 (0xc63abec4)
>  kernel: [__user_walk+58/96] __user_walk [kernel] 0x3a (0xc63abf20)
>  kernel: [<c0148bfa>] __user_walk [kernel] 0x3a (0xc63abf20)
>  kernel: [vfs_lstat+20/80] vfs_lstat [kernel] 0x14 (0xc63abf38)
>  kernel: [<c0145404>] vfs_lstat [kernel] 0x14 (0xc63abf38)
>  kernel: [sys_lstat64+17/48] sys_lstat64 [kernel] 0x11 (0xc63abf70)
>  kernel: [<c0145991>] sys_lstat64 [kernel] 0x11 (0xc63abf70)
>  kernel: [system_call+51/56] system_call [kernel] 0x33 (0xc63abfc0)
>  kernel: [<c010714b>] system_call [kernel] 0x33 (0xc63abfc0)

>From a quick scan of it,  it looks like the e1000 driver and jbd (part
of the kernels journaling filesystem) trampled on top of each other.  
This kernel is WAY out of date as well.  (what version fo RH Enterprise
is this? 2.1?)

Make sure you bring the kernel up to date,  (up2date -f kernel-docs
kernel-utils kernel or kernel-smp), check /boot/grub/menu.list to make
sure it choose to boot the right one, and then punt the box (when they
let you during the correct outtage window)

Is f-prot configured to avoid scanning /dev and /proc (and /sys on 2.6
kernels) ?  It's also possible that it tickled a device or node that
refers to kernel settings which can induce bad behavior. (no scanners
or backup routines should ever go into /proc or /sys, or even /dev, esp
if they run with root privs)



Dave J. Andruczyk

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
_______________________________________________
nflug mailing list
nflug at nflug.org
http://www.nflug.org/mailman/listinfo/nflug