Re: How to investigate kernel failure?
On Fri, Oct 17, 2003 at 11:50:28AM +0200, aCaB wrote:
> Oct 17 04:48:38 fserv kernel: Call Trace: [getblk+25/80]
> [ext3_getblk+185/624] [vc_resize+289/1168] [ext3_find_entry+501/768]
> [ext3_bread+35/128]
> Oct 17 04:48:38 fserv kernel: [ext3_readdir+150/912]
> [permission+42/48] [vfs_readdir+97/144] [filldir64+0/368]
> [sys_getdents64+79/259] [filldir64+0/368]
> Oct 17 04:48:38 fserv kernel: [sys_fcntl64+128/144] [system_call+51/56]
[...]
> Oct 17 04:48:50 fserv kernel: Call Trace: [getblk+25/80]
> [ext3_getblk+185/624] [vc_resize+289/1168] [ext3_find_entry+501/768]
> [ext3_bread+35/128]
> Oct 17 04:48:50 fserv kernel: [ext3_readdir+150/912]
> [vfs_permission+121/256] [permission+42/48] [vfs_readdir+97/144]
> [filldir64+0/368] [sys_getdents64+79/259]
> Oct 17 04:48:50 fserv kernel: [filldir64+0/368] [sys_fcntl64+128/144]
> [system_call+51/56]
[...]
> Oct 17 08:13:58 fserv kernel: Call Trace: [getblk+25/80]
> [journal_get_descriptor_buffer+57/112]
> [journal_commit_transaction+1373/3799] [schedule+758/800]
> [kjournald+278/448]
> Oct 17 08:13:58 fserv kernel: [commit_timeout+0/16]
> At this point the server was defently dead, only replaying to the ping.
The above are stack dumps. As you can see the most-recently invoked
function in each case was getblk(), so I'd say you need to check your
filesystem (and/or replace the hard drive).
Marcin
--
Marcin Owsiany <porridge@debian.org> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
Reply to: