and here is the 3rd crash in series (this time it's 2.0.27 but same code position),
and again it's smail writing an outgoing mail :-(
register dump etc. see below.
can anyone give me some hints if this might be a hardware problem
(but why does always sendmail trigger it?) or what else might be wrong ?
could it be that there are some raise conditions when an ext2 file system
gets *pretty* full ??? but it has been that full (and even worse)
all the time (1st thermodinamics law of free disk space ;-)
# df /dev/sdb8
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/sdb8 230026 227667 2359 99% /usr
# tune2fs -l /dev/sdb8
Filesystem magic number: 0xEF53
Filesystem state: not clean
Errors behavior: Continue
Inode count: 59392
Block count: 237567
Reserved block count: 0
Free blocks: 2359
Free inodes: 41510
First block: 1
Block size: 1024
Fragment size: 1024
Blocks per group: 8192
Fragments per group: 8192
Inodes per group: 2048
Last mount time: Thu Dec 12 10:52:05 1996
Last write time: Thu Dec 12 11:18:15 1996
Mount count: 1
Maximum mount count: 20
Last checked: Thu Dec 12 10:50:49 1996
Check interval: 0
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
this time I got some errors when running e2fsck on the /usr partition
holding /usr/spool/... which may give some more information what happend
ust before crashing (the mail file was already written to the outgoing
spool directory):
Inode 6565 size was 184038, counted 185344; corrected...
Inode 6565 i_blocks was 362, counted 364; corrected...
Inode 6699 entry 0vY7Rw-0001g4C in /spool/msglog/ has deleted/unused inode 6530
unattached inode 6452; reconnected ...
6452 2 -r-------- 1 1995 Dec 12 10:29 /usr/lost+found/#6452
6565 182 -rw-r--r-- 1 185344 Dec 12 10:29 /usr/spool/smail/log/logfile
6699 1 drwxr-xr-x 2 1024 Dec 12 10:29 /usr/spool/smail/msglog/
there was no inode 6530 or file /usr/spool/msglog/0vY7Rw-0001g4C after fsck.
general protection: 0000
CPU: 0
EIP: 0010:[<0017101a>]
EFLAGS: 00010202
eax: 00000001 ebx: 001f921c ecx: 00000003 edx: 00000002
esi: 01f9650c edi: 0000001b ebp: 00007b30 esp: 00407eb4
ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
Process sendmail (pid: 776, process nr: 39, stackpage=00407000)
Stack: 001f921c 00000003 00000001 001712cf 001f921c 00000003 00d9677c 00000000
00000001 0000000c 00006034 01e80800 00001b2f 0012ff3e 00c866e8 00179f82
00d966c8 00007b30 00000001 00d98000 00d966c8 01b7e8b8 0000000e 001f921c
Call Trace: [<001712cf>] [<0012ff3e>] [<00179f82>] [<0017a72e>] [<001743b1>] [<001743c7>] [<0012d633>]
[<00177415>] [<001383f3>] [<00138436>] [<0010b8e2>]
Code: 8b bc 83 c4 00 00 00 89 bc 83 c8 00 00 00 48 85 c0 7f df 89
Using `System.map' to map addresses to symbols.
>>EIP: 17101a <_load__block_bitmap+e2/280>
Trace: 1712cf <_ext2_free_blocks+117/3c0>
Trace: 12ff3e <___bforget+9e/d0>
Trace: 179f82 <_trunc_direct+16a/180>
Trace: 17a72e <_ext2_truncate+46/158>
Trace: 1743b1 <_ext2_put_inode+41/70>
Trace: 1743c7 <_ext2_put_inode+57/70>
Trace: 12d633 <_iput+df/1f0>
Trace: 177415 <_ext2_unlink+229/240>
Trace: 1383f3 <_do_unlink+113/130>
Trace: 138436 <_sys_unlink+26/40>
Trace: 10b8e2 <_system_call+52/80>
Code: 17101a <_load__block_bitmap+e2/280> movl 0xc4(%ebx,%eax,4),%edi
Code: 171021 <_load__block_bitmap+e9/280> movl %edi,0xc8(%ebx,%eax,4)
Code: 171028 <_load__block_bitmap+f0/280> decl %eax
Code: 171029 <_load__block_bitmap+f1/280> testl %eax,%eax
Code: 17102b <_load__block_bitmap+f3/280> jg fffffff2 <gcc2_compiled.+fffffff2>
Code: 17102d <_load__block_bitmap+f5/280> movl %eax,(%eax)
Code: 17102f <_load__block_bitmap+f7/280> nop
Code: 171030 <_load__block_bitmap+f8/280> nop
any idea what might be the reason for these failures ?
I'll build a new kernel image using gcc-2.7.2. now...
Harald
--
All SCSI disks will from now on ___ _____
be required to send an email notice 0--,| /OOOOOOO\
24 hours prior to complete hardware failure! <_/ / /OOOOOOOOOOO\
\ \/OOOOOOOOOOOOOOO\
\ OOOOOOOOOOOOOOOOO|//
Harald Koenig, \/\/\/\/\/\/\/\/\/
Inst.f.Theoret.Astrophysik // / \\ \
koenig@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^