lkml.org 
[lkml]   [1997]   [Jan]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux 2.0.27 kernel crashing

Hi Rob!

On Tue, 31 Dec 1996, Rob Allen wrote:

> I have been experiencing problems with my usenet news server lately and I
> think I finally found the cause, and hopefully someone here will recognize
> a solution. What is happening is the server crashes, OS and all, between
> 12-24 hours of uptime while receiving a full usenet news feed. I have
> pasted below the last part of the kernel messages that syslogd reports. It
> looks as if every minute or so I get the EXT2-fs error on a particular
> inode, and finally leads up to the kernel crashing. I find that the kernel
> crashes after about 4-5 hours after the errors start.

As you probably know, this is a well-known problem that seems to occur
only on high end systems with large scsi storage.
It has been observed with various models of scsi disks and controllers.

The ext2 code checks all meta data structures and especially directory
blocks that are filled with variable length entries.

So, such syslog messages may be due to severall causes:

1) (bad) scsi bus with no parity checking
2) bad disk firmware
3) bugs in drivers
4) bugs in the kernel
5) bad hardware or over-heating
6) etc ...

(1) possible.
(2) seems improbable since various HD has been reported with same problems.
(3) possible but not in low-level drivers since such problems have been
reported with BusLogic, Adaptec 39XX/29XX and NCR53C8XX drivers.
If reports exist with IDE disks, then middle and upper-level scsi
drivers are probably not guilty.
(4) possible.
(5) possible.
(6) probably possible too ...

Your syslog messages are very interesting. I just will keep what seems to
me usefull information (and that I am able to understand).

> Dec 28 17:56:53 news kernel: EXT2-fs error (device 08:11): ext2_find_entry:
> bad entry in directory #79873: rec_len % != 0 - offset=0,
> inode=1226980165, rec_len=16733, name_len=23123

> Dec 28 17:58:38 news kernel: EXT2-fs error (device 08:11): ext2_find_entry:
> bad entry in directory #434178: rec_len % != 0 - offset=0,
> inode=1752457552, rec_len=8250, name_len=25966

> Dec 28 17:59:06 news kernel: EXT2-fs error (device 08:11): ext2_find_entry:
> bad entry in directory #434182: rec_len % != 0 - offset=0,
> inode=1752457552, rec_len=8250, name_len=25966

The 2 blocks above of 2 different directories have same apparent corrupted
data at offset 0. (Or it is the same (cached) data block ...)

> Dec 28 17:59:55 news kernel: Unable to handle kernel paging request at
> virtual address f621223c

> Dec 28 17:59:55 news kernel: EIP: 0010:[get_hash_table+48/180]

Should be interesting to point the exact instruction that
has been trapped in get_hash_table(). For that stuff, I am too short.
It is very improbable that get_hash_table() would trap if corrupted
data are transferred from the disk. That looks like buffer headers or
hashed lists mess (speculation, only).

> Dec 28 17:59:55 news kernel: Call Trace: [newseg+416/424] [getblk+49/1112]
> [newseg+416/424] [newseg+416/424] [inode_getblk+67/400] [newseg+416/424]
> [ext2_getblk+225/528]

Your report let me think that a software bug is probable. It is just a
speculation.
IMHO, it would be interesting to find the first report about this problem,
in order to correlate it with some kernel patches.

Regards, Gerard.

\
 
 \ /
  Last update: 2005-03-22 13:36    [W:0.462 / U:0.428 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site