<div>True, its the same system and you were right it was cache VIPT cache problem</div>
<div>the cache hold the stale value even after xlog_bread() update the buffer.</div>
<div>I do not know whether its correct ways to resolve the problem, but the problem no longer occur.</div>
<div> </div>
<div><span lang="EN">
<p>diff -Naur -X fs/xfs/linux-2.6/xfs_buf.c fs-dirty/xfs/linux-2.6/xfs_buf.c</p>
<p>--- fs/xfs/linux-2.6/xfs_buf.c 2010-07-18 12:27:11.000000000 +0530</p>
<p>+++ fs-dirty/xfs/linux-2.6/xfs_buf.c 2010-10-25 11:01:28.252762355 +0530</p>
<p>@@ -1166,6 +1166,13 @@</p>
<p></p>
<p>xfs_buf_ioerror(bp, -error);</p>
<p></p>
<p>+ if (!error &amp;&amp; </p>
<p>+ (bp-&gt;b_flags &amp; XBF_MAPPED) &amp;&amp; </p>
<p>+ (bp-&gt;b_page_count &gt; 1) &amp;&amp; </p>
<p>+ (bp-&gt;b_flags &amp; XBF_READ)) {</p>
<p>+ dma_cache_inv((unsigned long)bp-&gt;b_addr, </p>
<p>+ (bp-&gt;b_page_count * PAGE_SIZE) - bp-&gt;b_offset);</p>
<p>+ } </p>
<p>do {</p>
<p>struct page *page = bvec-&gt;bv_page;</p>
<p></p>
<p>@@ -1275,6 +1282,10 @@</p>
<p></p>
<p>submit_io:</p>
<p>if (likely(bio-&gt;bi_size)) {</p>
<p>+ if ((bp-&gt;b_flags &amp; XBF_MAPPED) &amp;&amp; (bp-&gt;b_page_count &gt; 1)) { </p>
<p>+ dma_cache_wback_inv((unsigned long)bp-&gt;b_addr, </p>
<p>+ (bp-&gt;b_page_count * PAGE_SIZE) - bp-&gt;b_offset);</p>
<p>+ }</p>
<p>submit_bio(rw, bio);</p>
<p>if (size)</p>
<p>goto next_chunk;</p>
<p> </p></span></div>
<div class="gmail_quote">On Thu, Nov 4, 2010 at 6:20 PM, Christoph Hellwig <span dir="ltr">&lt;<a href="mailto:hch@infradead.org">hch@infradead.org</a>&gt;</span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div class="im">On Thu, Nov 04, 2010 at 11:27:24AM +0530, Ajeet Yadav wrote:<br></div>
<div class="im">&gt; Linux XFS version : 2.6.34<br>&gt; Architecure: MIPS<br>&gt; I am getting the following error during mount.<br><br></div>Is this the same mips system that you have the vmap aliasing problems<br>during log recovery with?<br>
<br>As long as that is not fixed I would deeply distrust any callchain<br>from the recovery code like this one.<br></blockquote></div><br>