2009-03-07 00:04 -!- RazvanM(~RazvanM@pool-173-67-52-67.bltmmd.east.verizon.net) has joined #tux3 2009-03-07 05:25 -!- amey(~amey@socks.wantstofly.org) has joined #tux3 2009-03-07 05:25 -!- kedars(~kedars@socks.wantstofly.org) has joined #tux3 2009-03-07 07:52 -!- dcg(~dcg@131.pool80-103-1.dynamic.orange.es) has joined #tux3 2009-03-07 09:21 -!- dcg(~dcg@131.pool80-103-1.dynamic.orange.es) has joined #tux3 2009-03-07 09:24 -!- cdk(~chinmay@115.109.11.168) has joined #tux3 2009-03-07 10:27 -!- ned(~ned@c-76-19-208-96.hsd1.ma.comcast.net) has joined #tux3 2009-03-07 11:07 -!- cdk(~chinmay@115.109.11.168) has joined #tux3 2009-03-07 11:07 hi flips 2009-03-07 12:47 -!- RazvanM(~RazvanM@dazzler.isi.jhu.edu) has joined #tux3 2009-03-07 12:53 -!- konrad(~konrad@D-128-208-53-188.dhcp4.washington.edu) has joined #tux3 2009-03-07 12:57 -!- dcg(~dcg@136.pool80-103-1.dynamic.orange.es) has joined #tux3 2009-03-07 16:08 -!- marcin(~marcin@c-76-23-106-132.hsd1.sc.comcast.net) has joined #tux3 2009-03-07 16:38 -!- konrad(~konrad@D-128-208-53-188.dhcp4.washington.edu) has joined #tux3 2009-03-07 18:09 -!- cdk(~chinmay@115.109.11.168) has joined #tux3 2009-03-07 18:10 hi flips 2009-03-07 18:41 hi cdk 2009-03-07 18:41 whoops, bye 2009-03-07 22:22 -!- cdk(~chinmay@121.246.35.128) has joined #tux3 2009-03-07 22:22 hi flips 2009-03-07 22:22 hi 2009-03-07 22:22 wanted to talk about the lock problem that i mentioned. 2009-03-07 22:22 u asked for the stack trace. 2009-03-07 22:23 got it 2009-03-07 22:23 ok 2009-03-07 22:24 where? 2009-03-07 22:24 yes. just a min 2009-03-07 22:26 also the mkdir patch for userspace is ready. 2009-03-07 22:26 will send it in a few minutes 2009-03-07 22:30 heres the trace 2009-03-07 22:30 http://paste2.org/p/160568 2009-03-07 22:45 -!- amey_m(~amey@117.195.37.78) has joined #tux3 2009-03-07 22:48 back 2009-03-07 22:49 cdk, is this current repo, plus a patch? 2009-03-07 22:49 under what test? 2009-03-07 22:50 -!- kushal(~kushal@121.246.33.34) has joined #tux3 2009-03-07 22:50 this is current repo + our code 2009-03-07 22:50 this happens when i umount the parition 2009-03-07 22:51 is your kernel configured with stack frames enabled? 2009-03-07 22:51 let me check 2009-03-07 22:51 under "kernel hacking" 2009-03-07 22:51 l 2009-03-07 22:51 sorry 2009-03-07 22:54 warn for stack frames larger than 1024 ? 2009-03-07 22:54 CONFIG_FRAME_POINTER=y 2009-03-07 22:54 yes seems so 2009-03-07 22:55 its checked 2009-03-07 22:57 the map_region trace at the start is before buffer = (blockget(mapping(inode),start)); /* DREAMZ */ 2009-03-07 22:59 this lockup should also occur if you do sync, did you try that? 2009-03-07 22:59 -!- gaurav(~gaurav@59.95.24.225) has joined #tux3 2009-03-07 23:00 no...but yes it should 2009-03-07 23:01 how do i do that ? need to call tuxsync() ? 2009-03-07 23:01 ah, blockget calls ->write_begin 2009-03-07 23:02 which tries to lock a page that is already locked 2009-03-07 23:03 and we are stalled...so how to read the page to calculate the hash without blockget ? 2009-03-07 23:04 when does this hash caclculation take place? 2009-03-07 23:04 are you writing here? 2009-03-07 23:04 no .. just reading the block 2009-03-07 23:04 when? 2009-03-07 23:04 at what stage in the algorithm? 2009-03-07 23:05 in ma_region at the very start ... line 141 here http://bitbucket.org/kushal/tux3/src/3f15683382f1/user/kernel/filemap.c 2009-03-07 23:05 I should be looking at you patch of course 2009-03-07 23:05 this is the old code .. but the place hash is calculated at the same place 2009-03-07 23:05 I am not right now 2009-03-07 23:06 ok, here goes 2009-03-07 23:08 line 141? 2009-03-07 23:09 yes 2009-03-07 23:19 well, you know at that point that you have a block that is not mapped in the file, so why are you reading it? 2009-03-07 23:21 well the physical mapping will happen here....and we need hash ... reading from the logical mapping ? 2009-03-07 23:23 blockget isn't quite the right way 2009-03-07 23:23 the data is in cache and never neads to be read 2009-03-07 23:25 so how do we get it directly in the buffer to calculate the hash ? in user space blockget used to check whether it is in the cache 2009-03-07 23:27 i mean it used to get from the hlist 2009-03-07 23:28 the buffer you want is the one that was passed to tux3_get_block 2009-03-07 23:28 hlist? 2009-03-07 23:28 you looked up in the mapping hash? 2009-03-07 23:29 that was in userspace .. i mean blockget did 2009-03-07 23:29 yes 2009-03-07 23:30 well in kernel there is not a good interface for doing this yet 2009-03-07 23:31 :( we are stuck ? 2009-03-07 23:31 there's always a way 2009-03-07 23:35 you code should be in tux3_get_block, not map_region 2009-03-07 23:35 you check the hash first 2009-03-07 23:35 you do not call map_region for buffer data that matches an existing block 2009-03-07 23:35 ok? 2009-03-07 23:36 you only call map_region if the match fails, thus a new block needs to be allocated 2009-03-07 23:37 ok...but when we started working tux3_get_block was not present :( 2009-03-07 23:37 and what about userspace? 2009-03-07 23:43 and map_region eventually adds entry to dleaf so how can we avoid it totally?? 2009-03-07 23:43 -!- RazvanM(~RazvanM@pool-173-67-52-67.bltmmd.east.verizon.net) has joined #tux3