Simon May <simon@imsl.es> wrote:> We use kernel 2.4.18 with a slackware linux dist.
> e2fsprogs version 1.29
>
> you will see that sendmail was the application that lead to the error
> at the time the machine was doing a weekly new letter to clients
> which puts it under abit of load but not a lot really
> the machine has a 1 Gb processor and 768 Mb RAM so is reasonably
> powerful.
Below is the oops and extracted stack trace:
<0>Assertion failure in do_get_write_access() at transaction.c:589:
"handle->h_buffer_credits > 0"
<4>invalid operand: 0000
<4>CPU: 0
<4>EIP: 0010:[<c015fb48>] Not tainted
<4>EFLAGS: 00010286
<4>eax: 00000063 ebx: ead2ae20 ecx: ffffffff edx: 00000001
<4>esi: c1c7bae0 edi: c1c7bae0 ebp: c1c24000 esp: e7edfe34
<4>ds: 0018 es: 0018 ss: 0018
<4>Process sendmail (pid: 27413, stackpage=e7edf000)
<4>Stack: c0254aa0 c0254eae c0254a80 0000024d c0254f61 c1c24000
e5e92a00 ead2ae20
<4> c1c24094 c1c24094 00000000 00000000 c1c24000 cd05a5e0
c015ff39 e5e92a00
<4> ead2ae20 00000000 e891c800 00000000 dbfd29c0 c1c60000
c01599fe e5e92a00
<4>Call Trace: [<c015ff39>] [<c01599fe>]
[<c0159e56>] [<c0159f59>] [<c015a039>]
STACK TRACE FOR TASK: 0xe7ede000 (sendmail)
0 do_get_write_access+340 [0xc015fb48]
1 journal_get_write_access+52 [0xc015ff34]
2 ext3_do_update_inode+469 [0xc01599f9]
3 ext3_mark_iloc_dirty+29 [0xc0159e51]
4 ext3_mark_inode_dirty+36 [0xc0159f54]
5 ext3_dirty_inode+208 [0xc015a034]
6 __mark_inode_dirty+44 [0xc01464e4]
7 update_atime+70 [0xc0147a22]
8 do_generic_file_read+1105 [0xc012674d]
9 generic_file_read+124 [0xc0126a10]
10 sys_read+141 [0xc0133305]
11 system_call+44 [0xc0106e48]
ebx: 00000004 ecx: 0810dc38 edx: 00001000 esi: 0810a0b9
edi: 3e65d011 ebp: bfff9a5c eax: 00000003 ds: 002b
es: 002b eip: 401a7004 cs: 0023 eflags: 00000293
esp: bfff9a2c ss: 002b
This looks like a bug that Andrew Morton posted a patch for recently:
> Under rare conditions (filesystem corruption, really) it is possible
> for ext3_dirty_inode() to require _two_ blocks for the transaction: one
> for the inode and one to update the superblock - to set
> EXT3_FEATURE_RO_COMPAT_LARGE_FILE. This causes the filesystem to go
> BUG.
>
> So reserve an additional block for that eventuality.
fs/ext3/inode.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
--- 25/fs/ext3/inode.c~ext3-transaction-reserved-blocks Sat Dec 14 18:28:21 2002
+++ 25-akpm/fs/ext3/inode.c Sat Dec 14 18:28:21 2002
@@ -2698,7 +2698,7 @@ void ext3_dirty_inode(struct inode *inod
handle_t *handle;
lock_kernel();
- handle = ext3_journal_start(inode, 1);
+ handle = ext3_journal_start(inode, 2);
if (IS_ERR(handle))
goto out;
if (current_handle &&
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
