On Thu, 2007-08-09 at 15:10 +0400, Alexey Dobriyan wrote: > LTP run reproducably hangs during rwtest01 test > rwtest -N rwtest01 -c -q -i 60s -f sync 10%25000:rs-sync=$$ > Calltrace is always the same: > > INFO: trying to register non-static key > __lock_acquire+0x210/0xc9e > lock_acquire+0x87/0xa3 > _spin_lock_irqsave+0x2f/0x5f > prop_norm_single+0x32/0x74 > set_page_dirty+0xd6/0x151 > set_page_dirty_balance+0xc/0x71 > do_wp_page+0x4ae/0x52b > handle_mm_fault+0x616/0x6c4 > do_page_fault+0x1b0/0x51c [root@opteron ~]# PATH=/testcases/bin/:$PATH /testcases/bin/rwtest -N rwtest01 -c -q -i 60s -f sync 10%25000:rs-sync=$$ rwtest01 1 PASS : Test passed [root@opteron ~]# PATH=/testcases/bin/:$PATH /testcases/bin/rwtest -N rwtest01 -c -q -i 60s -f sync 10%25000:rs-sync=$$ I can reproduce, but not always. Also, since the task->dirties member is initialized in fork.c this should either _always_ happen or never. So this does point to some memory corruption, ->dirties is the very last member of the task struct. /me goes try with slab_debug,...
Attachment:
signature.asc
Description: This is a digitally signed message part
- Follow-Ups:
- Re: 2.6.23-rc2-mm1: hang, prop_norm_single involved
- From: Peter Zijlstra <[email protected]>
- Re: 2.6.23-rc2-mm1: hang, prop_norm_single involved
- References:
- 2.6.23-rc2-mm1: hang, prop_norm_single involved
- From: Alexey Dobriyan <[email protected]>
- 2.6.23-rc2-mm1: hang, prop_norm_single involved
- Prev by Date: Re: why are some atomic_t's not volatile, while most are?
- Next by Date: Re: [patch] ipvs: force read of atomic_t in while loop
- Previous by thread: 2.6.23-rc2-mm1: hang, prop_norm_single involved
- Next by thread: Re: 2.6.23-rc2-mm1: hang, prop_norm_single involved
- Index(es):
 |