Re: ext3 panic on test4 running dbench

Andrew Morton
2003-09-25T18:44:36Z

"Martin J. Bligh" <mbligh@aracnet.com> wrote:
>
> maybe this is fixed already ... but:

No.

> Sep 24 02:26:14 elm3b67 kernel: invalid operand: 0000 [#1]
> Sep 24 02:26:14 elm3b67 kernel: CPU: 11
> Sep 24 02:26:14 elm3b67 kernel: EIP: 0060:[_end+404081921/1069412752] Not tainted
> Sep 24 02:26:14 elm3b67 kernel: EFLAGS: 00010206
> Sep 24 02:26:14 elm3b67 kernel: EIP is at 0xd857bb71

Your EIP looks like it is in modules space.

> Sep 24 02:26:14 elm3b67 kernel: eax: 00038815 ebx: 00000002 ecx: cbe4ab20 edx: 00000011
> Sep 24 02:26:14 elm3b67 kernel: esi: 00000000 edi: d82c6690 ebp: d4ecd1b0 esp: d857bb80
> Sep 24 02:26:14 elm3b67 kernel: ds: 007b es: 007b ss: 0068
> Sep 24 02:26:14 elm3b67 kernel: Process dbench (pid: 20747, threadinfo=d857a000 task=d4015900)
> Sep 24 02:26:14 elm3b67 kernel: Stack: cf768ea4 00000000 d82c6690 d857bc1c d8841400 d5f0a180 00000000 00000000
> Sep 24 02:26:14 elm3b67 kernel: 00818006 d8841400 00000000 d5489310 cf768ea4 c017f65f cc218280 c01892b9
> Sep 24 02:26:14 elm3b67 kernel: cf768ea4 d82c6690 00000000 00000000 d4ecd1b0 00000000 d4ecd1b0 cf768ea4
> Sep 24 02:26:14 elm3b67 kernel: Call Trace:
> Sep 24 02:26:14 elm3b67 kernel: [ext3_get_inode_loc+87/572] ext3_get_inode_loc+0x57/0x23c
> Sep 24 02:26:14 elm3b67 kernel: [journal_get_write_access+33/52] journal_get_write_access+0x21/0x34
> Sep 24 02:26:14 elm3b67 kernel: [ext3_reserve_inode_write+52/152] ext3_reserve_inode_write+0x34/0x98
> Sep 24 02:26:14 elm3b67 kernel: [ext3_mark_inode_dirty+26/52] ext3_mark_inode_dirty+0x1a/0x34
> Sep 24 02:26:14 elm3b67 kernel: [ext3_splice_branch+209/388] ext3_splice_branch+0xd1/0x184

But syslogd has conveniently gone and futzed with the oops trace so I
cannot tell what address your ext3 driver was loaded at. Sigh. Please add
`-x' to your syslogd invokation and shoot whoever first thought of this.

If, as I suspect, your ext3 is not loaded as a module then weird. There
are no indirect jumps around there which I can think of, so how did EIP get
that value? Maybe an overwritten return address?