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

Re: JFFS2 stuck again.



On Tue, 10 Apr 2001, Vipin Malik wrote:

> Ok, this is what I got (runnig the stuff through ksymoops):

jffs2_gcd_mtd1  D C11442C4     0     8      1        (L-TLB)       9      7
Call Trace: [<c0107a0d>] [<c0107b74>] [<c01fffbb>] [<c01774ad>] [<c014190c>] [<e0011985>] [<e88b1196>]
       [<c0176f22>] [<c0179085>] [<edcba987>] [<edcba987>] [<edcba987>] [<edcba987>] [<c0109005>] [<c0178eb0>]
       [<c010748a>] [<c0107493>]


> Trace; c0107a0d <__down+5d/b0>
> Trace; c0107b74 <__down_failed+8/c>
> Trace; c01fffbb <stext_lock+dab/13c8>
> Trace; c01774ad <jffs2_garbage_collect_dirent+13d/1d0>
> Trace; c014190c <iget4+4c/e0>
> Trace; e0011985 <END_OF_CODE+1fd73791/????>
> Trace; e88b1196 <END_OF_CODE+28612fa2/????>
> Trace; c0176f22 <jffs2_garbage_collect_pass+332/420>
> Trace; c0179085 <jffs2_garbage_collect_thread+1d5/1e0>
> Trace; edcba987 <END_OF_CODE+2da1c793/????>
> Trace; edcba987 <END_OF_CODE+2da1c793/????>
> Trace; edcba987 <END_OF_CODE+2da1c793/????>
> Trace; edcba987 <END_OF_CODE+2da1c793/????>
> Trace; c0109005 <reschedule+5/10>
> Trace; c0178eb0 <jffs2_garbage_collect_thread+0/1e0>
> Trace; c010748a <kernel_thread+1a/30>
> Trace; c0107493 <kernel_thread+23/30>

ldconfig  D C3F666D4     0    18     10        (NOTLB)
Call Trace: [<c0107a0d>] [<c0107b74>] [<c01ffdd1>] [<c0139040>] [<c01391bc>] [<c012d970>] [<d851f8bb>]
       [<c012dc88>] [<c0108f13>]

> Trace; c0107a0d <__down+5d/b0>
> Trace; c0107b74 <__down_failed+8/c>
> Trace; c01ffdd1 <stext_lock+bc1/13c8>
> Trace; c0139040 <vfs_create+90/c0>
> Trace; c01391bc <open_namei+14c/5b0>
> Trace; c012d970 <filp_open+30/50>
> Trace; d851f8bb <END_OF_CODE+182816c7/????>
> Trace; c012dc88 <sys_open+38/c0>
> Trace; c0108f13 <system_call+33/40>

OK,... looks like both of them are waiting for a locked semaphore. Which
has to be the alloc_sem. One is calling jffs2_reserve_space_gc() from
jffs2_garbage_collect_dirent(), and the other is calling
jffs2_reserve_space() from jffs2_create().

The jffs2_reserve_space* functions don't show up on the call trace because 
of the way the down() call works, I believe. Not sure why jffs2_create() 
hasn't shown up though.

If they're both waiting on the alloc_sem, then it looks like it's been 
obtained somewhere and not released. That would probably have to be in an 
error path or it would happen far more often - but error paths would 
normally whinge about whatever went wrong. 

Could you confirm the exact locations in the code of offset c01774ad 
<jffs2_garbage_collect_dirent+13d/1d0>, please? Add 'EXTRA_CFLAGS := -g' 
to the fs/jffs2 Makefile if it's not already there, rebuild exactly the 
same kernel, then 'gdb vmlinux' and 'list *0xc01774ad'.

Assuming this confirms that it's the call to jffs2_reserve_space_gc() at
line 360 of gc.c, then someone who isn't on vacation needs to go through
the code looking for all instances of jffs2_reserve_space{_gc,} and
ensuring that jffs2_complete_reservation() is correctly called in all
circumstances where the reserve_space function succeeded.

--
dwmw2



To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com