[ale] Kernel panic

[Geoffrey]

James P. Kinney III wrote:
> run a memtest on your ram.
> 
> This is a kernel panic. It halts the system. Once this happens there is
> no way to access anything without a reboot.

Actually, that's not necessarily true.  It is possible that you can not 
access a particular device, as he's noted below.  Generally, kernel 
panics are hardware related.  Memory is the first thing I always test as 
well.

> 
> On Mon, 2006-02-13 at 10:28 -0500, Christopher Fowler wrote:
> 
>>I get this error message:
>>
>>
>>------------------------------------------------------------------------------------
>>Feb  9 12:32:40 sam-accunet kernel: Unable to handle kernel paging
>>request at virtual address 625ae8e0
>>Feb  9 12:32:40 sam-accunet kernel:  printing eip:
>>Feb  9 12:32:40 sam-accunet kernel: 02164c7f
>>Feb  9 12:32:40 sam-accunet kernel: *pde = 00000000
>>Feb  9 12:32:40 sam-accunet kernel: Oops: 0002 [#1]
>>Feb  9 12:32:40 sam-accunet kernel: CPU:    0
>>Feb  9 12:32:40 sam-accunet kernel: EIP:    0060:[<02164c7f>]    Not
>>tainted
>>Feb  9 12:32:40 sam-accunet kernel: EFLAGS: 00010202   (2.6.5-1.358-SAM-
>>ACCUNET-001)
>>Feb  9 12:32:40 sam-accunet kernel: EIP is at proc_read_inode+0x4/0x29
>>Feb  9 12:32:40 sam-accunet kernel: eax: 16f68390   ebx: 16f68390   ecx:
>>00000000   edx: 022cb760
>>Feb  9 12:32:40 sam-accunet kernel: esi: 16f68390   edi: 21fb8200   ebp:
>>0cec6180   esp: 1e33de80
>>Feb  9 12:32:40 sam-accunet kernel: ds: 007b   es: 007b   ss: 0068
>>Feb  9 12:32:40 sam-accunet kernel: Process sendmail (pid: 1582,
>>threadinfo=1e33d000 task=213c47b0)
>>Feb  9 12:32:40 sam-accunet kernel: Stack: 00000000 21ff8910 02164e22
>>21ff8910 0cec6207 21ff8963 02166f6d ffffffea
>>Feb  9 12:32:40 sam-accunet kernel:        00000000 21fb0e10 21fb0e10
>>1e33df78 0cec6180 21fb3b80 02164f5e 022cb840
>>Feb  9 12:32:40 sam-accunet kernel:        0cec6180 21fb0e10 0214ad81
>>1e33df78 1e33df14 00000000 1e33df78 1e33df14
>>Feb  9 12:32:40 sam-accunet kernel: Call Trace:
>>Feb  9 12:32:40 sam-accunet kernel:  [<02164e22>] proc_get_inode
>>+0x59/0xdd
>>Feb  9 12:32:40 sam-accunet kernel:  [<02166f6d>] proc_lookup+0xb6/0xc4
>>Feb  9 12:32:40 sam-accunet kernel:  [<02164f5e>] proc_root_lookup
>>+0x2a/0x42
>>Feb  9 12:32:40 sam-accunet kernel:  [<0214ad81>] real_lookup+0x66/0xc8
>>Feb  9 12:32:40 sam-accunet kernel:  [<0214af4f>] do_lookup+0x43/0x72
>>Feb  9 12:32:40 sam-accunet kernel:  [<0214b494>] link_path_walk
>>+0x516/0x6e2
>>Feb  9 12:32:40 sam-accunet kernel:  [<02135342>] follow_page+0xda/0xe5
>>Feb  9 12:32:40 sam-accunet kernel:  [<0214b8b3>] path_lookup+0xf8/0x128
>>Feb  9 12:32:40 sam-accunet kernel:  [<0214bee9>] open_namei+0x93/0x3eb
>>Feb  9 12:32:40 sam-accunet kernel:  [<02135342>] follow_page+0xda/0xe5
>>Feb  9 12:32:40 sam-accunet kernel:  [<0214098f>] filp_open+0x23/0x3c
>>Feb  9 12:32:40 sam-accunet kernel:  [<02140cde>] sys_open+0x31/0x7d
>>Feb  9 12:32:40 sam-accunet kernel:
>>Feb  9 12:32:40 sam-accunet kernel: Code: 51 89 e0 e8 5a 62 fb ff 8b 54
>>24 04 8b 04 24 89 53 5
>>------------------------------------------------------------------------------------
>>
>>After I get this no program can access the file system.  Its as if the
>>disks have disappeared.   If it was a controller failure or some other
>>hardware failure would I not get earlier messages on the syslog instead
>>of failure like this? 
>>
>>_______________________________________________
>>Ale mailing list
>>Ale at ale.org
>>http://www.ale.org/mailman/listinfo/ale
>>
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>Ale mailing list
>>Ale at ale.org
>>http://www.ale.org/mailman/listinfo/ale


-- 
Until later, Geoffrey