* Andrea Arcangeli <andrea@suse.de> [021202 01:24]:
>> Pid: 2, comm: keventd
>> EIP: 0010:[<c0142ae3>] CPU: 0 EFLAGS: 00000206 Not tainted
>> EAX: c10ec45c EBX: 00000033 ECX: c11f8838 EDX: 40000000
>> ESI: c2fed680 EDI: c10ec400 EBP: 00000033 DS: 0018 ES: 0018
>[..]
>> >>EIP; c0142ae3 <try_to_sync_unused_inodes+1f/1f8> <=====
>> >>EAX; c10ec45c <_end+e521e4/13c9de8>
>> >>ECX; c11f8838 <_end+f5e5c0/13c9de8>
>> >>ESI; c2fed680 <[sb].data.end+a7ffd/25a9dd>
>> >>EDI; c10ec400 <_end+e52188/13c9de8>
>> Trace; c0117114 <__run_task_queue+4c/60>
>> Trace; c011e0e9 <context_thread+11d/19c>
>> Trace; c010588c <kernel_thread+28/38>
>ok, now it's clear what the problem is. there are inuse-dirty inodes
>that triggers a deadlock in the schedule-capable
>Can you give a spin to this untested incremental fix?
This appears to do the trick. I've tried some tests which always locked
it up before and now it's still rock stable.
It's also the 2.4 kernel which works more smoothly here, under heavy io
et all. Not yet 100% as well as 2.5 but quite near.
Very good work :)
Thanks for fixing the damn bug.
-- Javier Marcet <jmarcet@pobox.com>
This archive was generated by hypermail 2b29 : Sat Dec 07 2002 - 22:00:12 EST