From: Ryusuke Konishi <ryusuke-sG5X7nlA6pw@public.gmane.org>
To: WDunphy-/3AnZwnt+WyVkR+q5Y5grQ@public.gmane.org
Cc: konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org,
users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org
Subject: Re: Write hang on ARM based target
Date: Tue, 23 Jun 2009 12:35:05 +0900 (JST) [thread overview]
Message-ID: <20090623.123505.37056161.ryusuke@osrg.net> (raw)
In-Reply-To: <BAEFA5609CC3AB4BAE1625CAD4C27E5C01900FB9-qPLjlnsG5hmCmmEZ8mJCX5vx1ZQ4fP860E9HWUfgJXw@public.gmane.org>
Hi Bill,
On Mon, 22 Jun 2009 12:58:22 -0600, "Dunphy, Bill" wrote:
> An update.
>
> I've just begun some testing on a different reference design board
> utilizing the 88F6281. This particular board has native support in the
> 2.6.30 kernel which allowed me to give the in-tree version of NILFS a
> go. This board/kernel version combination ran though the testing
> mentioned below without a hitch this weekend (1 million loops). I've
> since performed a number of massive simultaneous data transfers without
> any errors. Performance appeared to be much better from a high level as
> well. So at this point, it appears to me that there is a NILFS
> sensitivity to the 2.6.22.18 kernel and/or a board oddity (even though
> other file systems worked flawlessly). My near term plan is to move
> forward with this new board/kernel combination. However, I will keep
> the original board and it's 2.6.22.18 kernel up and available if you
> would like me to try some other changes - you decide. In the meanwhile,
> I'll start banging away on this platform and report in if I see any
> strange behavior.
>
> Bill
Sorry for my late reply.
I found an inconsistent state in the value of sequence counter shown
in your log. I think some sort of synchronization problem is present.
If so, I think we should resolve the problem because it may occur in
any RISC architectures.
Could you test if the attached patch makes a difference?
The patch adds volatile specifiers to sequence counters which may be
shared among different tasks.
Thanks,
Ryusuke Konishi
> -----Original Message-----
> From: Dunphy, Bill
> Sent: Friday, June 19, 2009 9:01 AM
> To: 'Ryusuke Konishi'
> Cc: users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org; konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org
> Subject: RE: [NILFS users] Write hang on ARM based target
>
> Thanks. That patch integrated successfully.
>
> Ran it again with the following result:
>
> Jun 19 08:38:26 kernel: ========= NILFS SEGMENT INFORMATION ========
>
> Jun 19 08:38:26 kernel: full segment: segnum=39, start=79872, end=81919
>
> Jun 19 08:38:26 kernel: partial segment: start=81162, rest=758
>
> Jun 19 08:38:26 kernel: ------------------ SUMMARY -----------------
>
> Jun 19 08:38:26 kernel: nfinfo = 4 (number of files)
>
> Jun 19 08:38:26 kernel: nblocks = 14 (number of blocks)
>
> Jun 19 08:38:26 kernel: sumbytes = 312 (size of summary in bytes)
>
> Jun 19 08:38:26 kernel: nsumblk = 1 (number of summary blocks)
>
> Jun 19 08:38:26 kernel: flags = LOGBGN|LOGEND|SR
>
> Jun 19 08:38:26 kernel: ============================================
>
> Jun 19 08:38:26 kernel: NILFS(segment)
> nilfs_segctor_update_payload_blocknr: called
> Jun 19 08:38:26 kernel: NILFS(segment)
> nilfs_segctor_update_payload_blocknr: done
> Jun 19 08:38:26 kernel: NILFS(segment) nilfs_segctor_fill_in_file_bmap:
> called
> Jun 19 08:38:26 kernel: NILFS(segment) nilfs_segctor_fill_in_file_bmap:
> done
> Jun 19 08:38:26 kernel: NILFS(segment) nilfs_segctor_fill_in_checkpoint:
> called
> Jun 19 08:38:26 kernel: NILFS(segment) nilfs_segctor_fill_in_checkpoint:
> done
> Jun 19 08:38:26 kernel: NILFS(segment) nilfs_segctor_update_segusage:
> called
> Jun 19 08:38:26 kernel: NILFS(segment) nilfs_segctor_update_segusage:
> done
> Jun 19 08:38:26 kernel: NILFS(segment) nilfs_segctor_fill_in_checksums:
> called
> Jun 19 08:38:26 kernel: NILFS(segment) nilfs_segctor_fill_in_checksums:
> done
> Jun 19 08:38:26 kernel: NILFS(segment) nilfs_segbuf_write: submitting
> summary blocks
> Jun 19 08:38:26 kernel: NILFS(segment) nilfs_alloc_seg_bio: allocated
> bio (max_vecs=16)
> Jun 19 08:38:26 kernel: NILFS(segment) nilfs_segbuf_write: submitting
> normal blocks (index=1)
> Jun 19 08:38:26 kernel: NILFS(segment) nilfs_submit_seg_bio: submitting
> bio (start_sector=649296, size=57344,) Jun 19 08:38:26 kernel:
> NILFS(segment) nilfs_segbuf_write: submitted a segment (err=0,
> pseg_start=81162, #req)
> Jun 19 08:38:26 kernel: NILFS(segment) nilfs_segbuf_wait: called nbio=1
>
> Jun 19 08:38:26 kernel: NILFS(segment) nilfs_segbuf_wait: wait completed
>
> Jun 19 08:38:26 kernel: NILFS(segment) nilfs_segctor_complete_write:
> completing segment (flags=0x7)
> Jun 19 08:38:26 kernel: NILFS(segment) nilfs_segctor_complete_write:
> completed a segment having a super root )
> Jun 19 08:38:26 kernel: NILFS(segment) nilfs_segctor_do_construct:
> submitted all segments
> Jun 19 08:38:26 kernel: NILFS(segment) nilfs_segctor_construct: end
> (stage=9)
diff --git a/fs/segment.c b/fs/segment.c
index 84201ce..c9c28c2 100644
--- a/fs/segment.c
+++ b/fs/segment.c
@@ -2530,7 +2530,7 @@ void nilfs_segctor_clear_segments_to_be_freed(struct nilfs_sc_info *sci)
struct nilfs_segctor_wait_request {
wait_queue_t wq;
- __u32 seq;
+ volatile __u32 seq;
int err;
atomic_t done;
};
@@ -2699,7 +2699,7 @@ int nilfs_construct_dsync_segment(struct super_block *sb, struct inode *inode,
struct nilfs_segctor_req {
int mode;
- __u32 seq_accepted;
+ volatile __u32 seq_accepted;
int sc_err; /* construction failure */
int sb_err; /* super block writeback failure */
};
diff --git a/fs/segment.h b/fs/segment.h
index 44dca64..8533783 100644
--- a/fs/segment.h
+++ b/fs/segment.h
@@ -163,8 +163,8 @@ struct nilfs_sc_info {
wait_queue_head_t sc_wait_daemon;
wait_queue_head_t sc_wait_task;
- __u32 sc_seq_request;
- __u32 sc_seq_done;
+ volatile __u32 sc_seq_request;
+ volatile __u32 sc_seq_done;
int sc_sync;
unsigned long sc_interval;
--
1.6.2
next prev parent reply other threads:[~2009-06-23 3:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-08 15:46 [SPAM] Write hang on ARM based target Dunphy, Bill
[not found] ` <BAEFA5609CC3AB4BAE1625CAD4C27E5C01900F8D-qPLjlnsG5hmCmmEZ8mJCX5vx1ZQ4fP860E9HWUfgJXw@public.gmane.org>
2009-06-08 16:49 ` Ryusuke Konishi
[not found] ` <20090609.014919.79903506.ryusuke-sG5X7nlA6pw@public.gmane.org>
2009-06-08 20:30 ` Dunphy, Bill
[not found] ` <BAEFA5609CC3AB4BAE1625CAD4C27E5C01900F96-qPLjlnsG5hmCmmEZ8mJCX5vx1ZQ4fP860E9HWUfgJXw@public.gmane.org>
2009-06-09 19:04 ` Dunphy, Bill
[not found] ` <BAEFA5609CC3AB4BAE1625CAD4C27E5C01900F99-qPLjlnsG5hmCmmEZ8mJCX5vx1ZQ4fP860E9HWUfgJXw@public.gmane.org>
2009-06-12 4:23 ` Ryusuke Konishi
[not found] ` <20090612.132344.17157054.ryusuke-sG5X7nlA6pw@public.gmane.org>
2009-06-18 18:36 ` Ryusuke Konishi
[not found] ` <20090619.033642.32757627.ryusuke-sG5X7nlA6pw@public.gmane.org>
2009-06-18 18:42 ` Ryusuke Konishi
2009-06-18 19:48 ` Dunphy, Bill
[not found] ` <BAEFA5609CC3AB4BAE1625CAD4C27E5C01900FAC-qPLjlnsG5hmCmmEZ8mJCX5vx1ZQ4fP860E9HWUfgJXw@public.gmane.org>
2009-06-19 1:47 ` Ryusuke Konishi
[not found] ` <20090619.104731.99018736.ryusuke-sG5X7nlA6pw@public.gmane.org>
2009-06-19 15:01 ` Dunphy, Bill
[not found] ` <BAEFA5609CC3AB4BAE1625CAD4C27E5C01900FB3-qPLjlnsG5hmCmmEZ8mJCX5vx1ZQ4fP860E9HWUfgJXw@public.gmane.org>
2009-06-22 18:58 ` Dunphy, Bill
[not found] ` <BAEFA5609CC3AB4BAE1625CAD4C27E5C01900FB9-qPLjlnsG5hmCmmEZ8mJCX5vx1ZQ4fP860E9HWUfgJXw@public.gmane.org>
2009-06-23 3:35 ` Ryusuke Konishi [this message]
[not found] ` <20090623.123505.37056161.ryusuke-sG5X7nlA6pw@public.gmane.org>
2009-06-23 15:34 ` Dunphy, Bill
[not found] ` <BAEFA5609CC3AB4BAE1625CAD4C27E5C01900FBB-qPLjlnsG5hmCmmEZ8mJCX5vx1ZQ4fP860E9HWUfgJXw@public.gmane.org>
2009-06-24 21:16 ` Dunphy, Bill
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090623.123505.37056161.ryusuke@osrg.net \
--to=ryusuke-sg5x7nla6pw@public.gmane.org \
--cc=WDunphy-/3AnZwnt+WyVkR+q5Y5grQ@public.gmane.org \
--cc=konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org \
--cc=users-JrjvKiOkagjYtjvyW6yDsg@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox