[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

another quota related ext3fs crash...



hiya!

see the attached file for the resolved bug() call. my kernel spit out 185
messages like this:

Mar  9 17:15:13 srck trottelkunde attempt to access beyond end of device
Mar  9 17:15:13 srck trottelkunde 16:42: rw=0, want=0, limit=12289725

right before the bug().

this message didn't get parsed by ksymoops

Mar  9 17:15:13 srck trottelkunde Assertion failure in journal_start() at transaction.c:226: "handle->h_transaction->t_journal == journal"

i'm somehow desperate by now, i get crashes like this on a monthly basis;
the quota code always seems to be the cause...

here are the lines of the last crashes (can't resolve call trace because
the old kernels are gone and i didn't resolve the traces when they
occured)

---

Dec  9 19:55:30 srck trottelkunde Kernel panic: EXT3-fs panic (device ide1(22,66)): load_block_bitmap: block_group >= groups_count - block_group = 131071, groups_count = 94
Dec  9 19:55:30 srck trottelkunde Assertion failure in journal_start() at transaction.c:227: "handle->h_transaction->t_journal == journal"

---

Jan  4 11:29:42 srck trottelkunde Kernel panic: EXT3-fs panic (device ide1(22,67)): load_block_bitmap: block_group >= groups_count - block_group = 131071, groups_count = 52
Jan  4 11:29:42 srck trottelkunde Assertion failure in journal_start() at transaction.c:227: "handle->h_transaction->t_journal == journal"

---

Feb 19 00:54:43 srck trottelkunde Kernel panic: EXT3-fs panic (device ide1(22,66)): load_block_bitmap: block_group >= groups_count - block_group = 131071, groups_count = 94
Feb 19 00:54:43 srck trottelkunde Assertion failure in journal_start() at transaction.c:225: "handle->h_transaction->t_journal == journal"

---

Mar  9 17:15:13 srck trottelkunde Kernel panic: EXT3-fs panic (device ide1(22,66)): load_block_bitmap: block_group >= groups_count - block_group = 131071, groups_count = 94
Mar  9 17:15:13 srck trottelkunde Assertion failure in journal_start() at transaction.c:226: "handle->h_transaction->t_journal == journal"

---

the kernels where always the -ac version from the current tree, using
vfsv0 quota.

is it possible that the hardware is the cause of these crashes? a
badblocks scan of the whole device hasn't reported anything suspicious
(there aren't any messages in the kernel logs which would point to bad
blocks either).

both partitions on this drive (/www and /home) had crashes; the only other
usrquota partition in this system is on another drive, has barely disk/fs
i/o (mounted as /tmp) and hasn't reported any problems yet.

btw. our semi-highend webservers which are running with vanilla 2.4.17
kernels and ext3 + vfsold quota hadn't had any crashes yet.

have you any ideas on how to resolve this problem?

best regards,
michael
ksymoops 2.4.3 on i686 2.4.18-ac1.  Options used
     -V (default)
     -k /proc/ksyms (specified)
     -l /proc/modules (default)
     -o /lib/modules/2.4.18-ac1/ (default)
     -m /usr/src/linux/System.map (default)

Kernel panic: EXT3-fs panic (device ide1(22,66)): load_block_bitmap: block_group >= groups_count - block_group = 131071, groups_count = 94
invalid operand: 0000
CPU:    0
EIP:    0010:[<c015a988>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: 0000006c   ebx: d7be4a80   ecx: c0260f68   edx: 0082ff51
esi: d7be4a80   edi: eeb00040   ebp: efc75600   esp: e0c1fb74
ds: 0018   es: 0018   ss: 0018
Process hlds_run (pid: 4928, stackpage=e0c1f000)
Stack: c022dcc0 c022ddac c022dca0 000000e2 c022dd80 d7be4a80 ef62e400 eeb00040
da11a0c0 e0c1e000 c0155c78 efc75600 00000001 eeb00040 ef62e400 00000001
c013f0be eeb00040 eeb00040 ffffffff c0000000 c0123070 eeb00040 00000001
Call Trace: [<c0155c78>] [<c013f0be>] [<c0123070>] [<c01c1ed4>] [<c0151aa6>]
[<c0144080>] [<c01447a6>] [<c01448c4>] [<c012e92f>] [<c012e967>] [<c0111315>]
[<c01585e0>] [<c0150343>] [<c01505b7>] [<c015490f>] [<c015492c>] [<c015b3b0>]
[<c0154a34>] [<c0154c98>] [<c012f55a>] [<c0154b66>] [<c012f55a>] [<c0154b66>]
[<c0154d78>] [<c0154f69>] [<c01603de>] [<c015a9ea>] [<c0152cfc>] [<c0152db0>]
[<c0152e53>] [<c0152db0>] [<c0140348>] [<c013e9dc>] [<c013806c>] [<c0138148>]
[<c0106c4f>]
Code: 0f 0b 83 c4 14 8d 76 00 ff 43 08 89 d8 eb 79 6a 01 68 f0 00

>>EIP; c015a988 <journal_start+58/f0>   <=====
Trace; c0155c78 <ext3_dirty_inode+58/d0>
Trace; c013f0be <__mark_inode_dirty+2e/80>
Trace; c0123070 <generic_file_write+330/750>
Trace; c01c1ed4 <do_rw_disk+384/540>
Trace; c0151aa6 <ext3_file_write+46/50>
Trace; c0144080 <write_dquot+c0/100>
Trace; c01447a6 <commit_dquot+36/40>
Trace; c01448c4 <sync_dquots+64/90>
Trace; c012e92e <fsync_dev+1e/40>
Trace; c012e966 <sys_sync+6/10>
Trace; c0111314 <panic+64/e0>
Trace; c01585e0 <ext3_warning+0/50>
Trace; c0150342 <__load_block_bitmap+32/1a0>
Trace; c01505b6 <ext3_free_blocks+106/590>
Trace; c015490e <ext3_clear_blocks+fe/130>
Trace; c015492c <ext3_clear_blocks+11c/130>
Trace; c015b3b0 <journal_get_write_access+40/60>
Trace; c0154a34 <ext3_free_data+f4/160>
Trace; c0154c98 <ext3_free_branches+1f8/210>
Trace; c012f55a <bread+1a/c0>
Trace; c0154b66 <ext3_free_branches+c6/210>
Trace; c012f55a <bread+1a/c0>
Trace; c0154b66 <ext3_free_branches+c6/210>
Trace; c0154d78 <ext3_truncate+c8/3a0>
Trace; c0154f68 <ext3_truncate+2b8/3a0>
Trace; c01603de <__jbd_kmalloc+1e/80>
Trace; c015a9ea <journal_start+ba/f0>
Trace; c0152cfc <start_transaction+5c/90>
Trace; c0152db0 <ext3_delete_inode+0/120>
Trace; c0152e52 <ext3_delete_inode+a2/120>
Trace; c0152db0 <ext3_delete_inode+0/120>
Trace; c0140348 <iput+e8/1d0>
Trace; c013e9dc <d_delete+4c/70>
Trace; c013806c <vfs_unlink+12c/160>
Trace; c0138148 <sys_unlink+a8/120>
Trace; c0106c4e <system_call+32/38>
Code;  c015a988 <journal_start+58/f0>
0000000000000000 <_EIP>:
Code;  c015a988 <journal_start+58/f0>   <=====
   0:   0f 0b                     ud2a      <=====
Code;  c015a98a <journal_start+5a/f0>
   2:   83 c4 14                  add    $0x14,%esp
Code;  c015a98c <journal_start+5c/f0>
   5:   8d 76 00                  lea    0x0(%esi),%esi
Code;  c015a990 <journal_start+60/f0>
   8:   ff 43 08                  incl   0x8(%ebx)
Code;  c015a992 <journal_start+62/f0>
   b:   89 d8                     mov    %ebx,%eax
Code;  c015a994 <journal_start+64/f0>
   d:   eb 79                     jmp    88 <_EIP+0x88> c015aa10 <journal_start+e0/f0>
Code;  c015a996 <journal_start+66/f0>
   f:   6a 01                     push   $0x1
Code;  c015a998 <journal_start+68/f0>
  11:   68 f0 00 00 00            push   $0xf0


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]