[prev in list] [next in list] [prev in thread] [next in thread]
List: yaffs
Subject: Re: [Yaffs] Current Yaffs2 Compilation Bugs with Some Fixes
From: Robert Calhoun <rcalhoun () shotspotter ! com>
Date: 2014-10-28 19:50:12
Message-ID: D07568C2.4A02E0%rcalhoun () shotspotter ! com
[Download RAW message or body]
(My apologies if you receive this twice; I sent from the wrong account)
From: Sean Seifert <sseifert@appareo.com<mailto:sseifert@appareo.com>>
Date: 22 Oct 2014 6:26 PM
To: "yaffs@lists.aleph1.co.uk<mailto:yaffs@lists.aleph1.co.uk>" \
<yaffs@lists.aleph1.co.uk<mailto:yaffs@lists.aleph1.co.uk>>
Subject: [Yaffs] Current Yaffs2 Compilation Bugs with Some Fixes
(...)
Issue 4 (w/ fix):
------------------------------------------------------------------------------------------------------
Compilation broke on commit: 30f956c32c235e6b5fa77fb29965ababbd497561, Jul 22, 2014. \
Not all functions were updated for the new discard parameter. Here are the following \
that have been missed that discard parameter: fs/yaffs2/yaffs_vfs.c:2205: error: too \
few arguments to function ‘yaffs_flush_whole_cache’ fs/yaffs2/yaffs_vfs.c:751: error: \
too few arguments to function ‘yaffs_flush_file’ fs/yaffs2/yaffs_vfs.c:781: error: \
too few arguments to function ‘yaffs_flush_file’ fs/yaffs2/yaffs_vfs.c:2192: error: \
too few arguments to function ‘yaffs_flush_file’
Simply adding the extra discard parameter to these functions makes compilation work. \
What is the proper number to pass to each? I added a "1" to each for the sake of \
getting this compiling in my code, but want to make sure that the correct parameter \
gets passed into the functions.
(...)
I can reproduce Sean Seifert's issue #4, also reported by wikimfw@lotte.net in \
September.
I am also compiling an updated version of yaffs on an older kernel (2.6.34) following \
our discovery of very severe data corruption issues traced to the obsolete version of \
yaffs we were using (99c62e39578113a798483b5dc6c13a80737163f1 on branch yaffs2, from \
March 2010.) Thank you to William Juul for his help in diagnosing this!
Like Sean Seifert I could not get yaffs master HEAD to compile due the inconsistent \
definitions of yaffs_flush_file() in yaffs_guts and yaffs_vfs.
Rather than modify the source I rolled back to the commit before the new cache policy \
changes (to 4e188b08c5531f99f73383a85251e03a1e667b26, "Update to support Linux \
3.14/3.15") and was able to successfully build using that tree. We are now testing \
that build for deployment.
Question for Charles Manning/branch maintainers: Is there some release branch we \
should be using in lieu of integrating branch master at an arbitrary commit? Master \
seems like a work in progress at the moment.
re: Sean Seifert's issues 1 and 2:
I did not encounter these with kernel 2.6.34 and an (old-ish) version of gcc (4.4.7).
re: Sean Seifert's issues 3 and 5:
Sean, if I read your email correctly you have a yaffs2 system with out-of-band tags \
and no yaffs ECC on those tags.
Our defconfig (old and new) use the default (do not disable tag ECC) i.e.
# CONFIG_YAFFS_DISABLE_TAGS_ECC is not set
so we did not encounter this problem.
The Kconfig documentation says "This behavior can also be overridden with tags_ecc_on \
and tags_ecc_off mount options" so you may be able to compile with ECC tags on but \
then disable tag ECC at runtime with your kernel command line mount argument and \
still mount your filesystem.
Based on /proc/yaffs we are using out-of-band area for tags. It is probably desirable \
to to have YAFFS do ECC on the tags, because in many flash devices the OOB area is \
not entirely protected by ECC. For example we use Micron MT29F2G16ABBEAHC, which I \
believe is a typical SLC NAND device. It has 16 OOB bytes (2 bytes bad block marker, \
8 bytes ECC parity, 6 bytes "user data") for each 512 byte partial page, so a full \
2048-byte page has 6 * 4 = 24 user bytes, which are not fully protected by ECC using \
either the on-chip correction or (SoC controller + MTD driver). I assume this is why \
YAFFS does tag ECC by default on OOB tags even when the user data is protected at the \
MTD layer and below.
I find the whole use of OOB a bit difficult to follow. yaffs_packed_tags2 seems to \
comprise (4 x uint32) of tag data plus (uint8, uint32, unit32) of ECC data for a \
total of 25 bytes, one byte more than space available for user data. Clearly there is \
something I am not understanding here.
Anyway, we are using the following defconfig:
CONFIG_YAFFS_FS=y
CONFIG_YAFFS_YAFFS1=y
# CONFIG_YAFFS_9BYTE_TAGS is not set
# CONFIG_YAFFS_DOES_ECC is not set
CONFIG_YAFFS_YAFFS2=y
CONFIG_YAFFS_AUTO_YAFFS2=y
# CONFIG_YAFFS_DISABLE_TAGS_ECC is not set
CONFIG_YAFFS_ALWAYS_CHECK_CHUNK_ERASED=y
# CONFIG_YAFFS_EMPTY_LOST_AND_FOUND is not set
# CONFIG_YAFFS_DISABLE_BLOCK_REFRESHING is not set
# CONFIG_YAFFS_DISABLE_BACKGROUND is not set
# CONFIG_YAFFS_DISABLE_BAD_BLOCK_MARKING is not set
CONFIG_YAFFS_XATTR=y
and are able to read our existing filesystem without issues. These are all defaults \
set by patch-ker.sh for 2.6.34 except for CONFIG_YAFFS_ALWAYS_CHECK_CHUNK_ERASED, \
which I carried forward from our old defconfig.
-Rob Calhoun
[Attachment #3 (text/html)]
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: \
after-white-space; color: rgb(0, 0, 0); font-size: 14px; "> <div><font \
class="Apple-style-span" face="Arial">(My apologies if you receive this twice; I sent \
from the wrong account)</font></div> <div style="font-family: Calibri, sans-serif; \
"><br> </div>
<span id="OLK_SRC_BODY_SECTION" style="font-family: Calibri, sans-serif; ">
<div style="font-family:Arial; font-size:10pt; text-align:left; color:black; \
BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; \
PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: \
medium none; PADDING-TOP: 3pt"> <span style="font-weight:bold">From: </span>Sean \
Seifert <<a href="mailto:sseifert@appareo.com">sseifert@appareo.com</a>><br> \
<span style="font-weight:bold">Date: </span>22 Oct 2014 6:26 PM<br> <span \
style="font-weight:bold">To: </span>"<a \
href="mailto:yaffs@lists.aleph1.co.uk">yaffs@lists.aleph1.co.uk</a>" <<a \
href="mailto:yaffs@lists.aleph1.co.uk">yaffs@lists.aleph1.co.uk</a>><br> <span \
style="font-weight:bold">Subject: </span>[Yaffs] Current Yaffs2 Compilation Bugs with \
Some Fixes<br> </div>
</span>
<div style="font-family: Calibri, sans-serif; "><br>
</div>
<div style="font-family: Calibri, sans-serif; ">(...)</div>
<span id="OLK_SRC_BODY_SECTION" style="font-family: Calibri, sans-serif; ">
<div><br>
</div>
<div>
<div>
<div dir="ltr">
<div><b>Issue 4 (w/ fix):</b></div>
<div><b>------------------------------------------------------------------------------------------------------</b></div>
<div>Compilation broke on commit: <font color="#000000"><font face="monospace" \
style="font-size:12px">30f956c32c235e6b5fa77f</font><font face="monospace" \
style="font-size:12px">b29965ababbd497561, Jul 22, 2014. </font><font \
face="arial,helvetica,sans-serif">Not all functions were updated for the new \
discard </font><font face="arial,helvetica,sans-serif">parameter. Here are the \
following that have been missed that discard parameter:</font></font></div> \
<div><font color="#000000" face="monospace">fs/yaffs2/yaffs_vfs.c:2205: error: too \
few arguments to function ‘yaffs_flush_whole_cache’<br> </font></div>
<div>
<div style="color:rgb(0,0,0);font-family:monospace">fs/yaffs2/yaffs_vfs.c:751: error: \
too few arguments to function ‘yaffs_flush_file’</div> <div \
style="color:rgb(0,0,0);font-family:monospace">fs/yaffs2/yaffs_vfs.c:781: error: too \
few arguments to function ‘yaffs_flush_file’<br> </div>
<div style="color:rgb(0,0,0);font-family:monospace">fs/yaffs2/yaffs_vfs.c:2192: \
error: too few arguments to function ‘yaffs_flush_file’<br> </div>
<div style="color:rgb(0,0,0);font-family:monospace"><br>
</div>
<div style="color:rgb(0,0,0)"><font face="arial,helvetica,sans-serif">Simply adding \
the extra discard parameter to these functions makes compilation work. What is the \
proper number to pass to each? I added a "1" to each for the sake of \
getting this compiling in my code, but want to make sure that the correct parameter \
gets passed into the functions. </font></div> <div \
style="color:rgb(0,0,0);font-family:monospace"><br> </div>
</div>
</div>
</div>
</div>
</span>
<div style="font-family: Calibri, sans-serif; ">(...)</div>
<div style="font-family: Calibri, sans-serif; "><br>
</div>
<div>
<div><font class="Apple-style-span" face="Arial"><br>
</font></div>
<div>
<div style="font-family: Arial; ">I can reproduce Sean Seifert's issue #4, also \
reported by wikimfw@lotte.net in September.</div> <div style="font-family: Arial; \
"><br> </div>
<div style="font-family: Arial; ">I am also compiling an updated version of yaffs on \
an older kernel (2.6.34) following our discovery of very severe data corruption \
issues traced to the obsolete version of yaffs we were using \
(99c62e39578113a798483b5dc6c13a80737163f1 on branch yaffs2, from March 2010.) Thank \
you to William Juul for his help in diagnosing this!</div> <div style="font-family: \
Arial; "><br> </div>
<div style="font-family: Arial; ">Like Sean Seifert I could not get yaffs master HEAD \
to compile due the inconsistent definitions of yaffs_flush_file() in yaffs_guts and \
yaffs_vfs.</div> <div style="font-family: Arial; "><br>
</div>
<div style="font-family: Arial; ">Rather than modify the source I rolled back to the \
commit before the new cache policy changes (to \
4e188b08c5531f99f73383a85251e03a1e667b26, "Update to support Linux \
3.14/3.15") and was able to successfully build using that tree. We are now \
testing that build for deployment.</div> <div style="font-family: Arial; "><br>
</div>
<div style="font-family: Arial; "><br>
</div>
<div style="font-family: Arial; ">Question for Charles Manning/branch maintainers: Is \
there some release branch we should be using in lieu of integrating branch master at \
an arbitrary commit? Master seems like a work in progress at the moment.</div> <div \
style="font-family: Arial; "><br> </div>
<div style="font-family: Arial; "><br>
</div>
<div style="font-family: Arial; ">re: Sean Seifert's issues 1 and 2:</div>
<div style="font-family: Arial; ">I did not encounter these with kernel 2.6.34 and an \
(old-ish) version of gcc (4.4.7).</div> <div style="font-family: Arial; "><br>
</div>
<div style="font-family: Arial; ">re: Sean Seifert's issues 3 and 5:</div>
<div style="font-family: Arial; ">Sean, if I read your email correctly you have a \
yaffs2 system with out-of-band tags and no yaffs ECC on those tags.</div> <div \
style="font-family: Arial; "><br> </div>
<div style="font-family: Arial; ">Our defconfig (old and new) use the default (do not \
disable tag ECC) i.e.</div> <div><font class="Apple-style-span" face="Courier"> \
# CONFIG_YAFFS_DISABLE_TAGS_ECC is not set</font></div> <div style="font-family: \
Arial; ">so we did not encounter this problem.</div> <div style="font-family: Arial; \
"><br> </div>
<div style="font-family: Arial; ">The Kconfig documentation says "This behavior \
can also be overridden with tags_ecc_on and tags_ecc_off mount options" so you \
may be able to compile with ECC tags on but then disable tag ECC at runtime with your \
kernel command line mount argument and still mount your filesystem.</div>
<div style="font-family: Arial; "><br>
</div>
<div style="font-family: Arial; ">Based on /proc/yaffs we are using out-of-band area \
for tags. It is probably desirable to to have YAFFS do ECC on the tags, because in \
many flash devices the OOB area is not entirely protected by ECC. For example we use \
Micron MT29F2G16ABBEAHC, which I believe is a typical SLC NAND device. It has 16 OOB \
bytes (2 bytes bad block marker, 8 bytes ECC parity, 6 bytes "user data") \
for each 512 byte partial page, so a full 2048-byte page has 6 * 4 = 24 user bytes, \
which are not fully protected by ECC using either the on-chip correction or (SoC \
controller + MTD driver). I assume this is why YAFFS does tag ECC by default on \
OOB tags even when the user data is protected at the MTD layer and below.</div> <div \
style="font-family: Arial; "><br> </div>
<div style="font-family: Arial; ">I find the whole use of OOB a bit difficult to \
follow. yaffs_packed_tags2 seems to comprise (4 x uint32) of tag data plus (uint8, \
uint32, unit32) of ECC data for a total of 25 bytes, one byte more than space \
available for user data. Clearly there is something I am not understanding \
here.</div> <div style="font-family: Arial; "><br>
</div>
<div style="font-family: Arial; ">Anyway, we are using the following defconfig:</div>
<div style="font-family: Arial; "><br>
</div>
<div><font class="Apple-style-span" face="Courier">CONFIG_YAFFS_FS=y</font></div>
<div><font class="Apple-style-span" face="Courier">CONFIG_YAFFS_YAFFS1=y</font></div>
<div><font class="Apple-style-span" face="Courier"># CONFIG_YAFFS_9BYTE_TAGS is not \
set</font></div> <div><font class="Apple-style-span" face="Courier"># \
CONFIG_YAFFS_DOES_ECC is not set</font></div> <div><font class="Apple-style-span" \
face="Courier">CONFIG_YAFFS_YAFFS2=y</font></div> <div><font class="Apple-style-span" \
face="Courier">CONFIG_YAFFS_AUTO_YAFFS2=y</font></div> <div><font \
class="Apple-style-span" face="Courier"># CONFIG_YAFFS_DISABLE_TAGS_ECC is not \
set</font></div> <div><font class="Apple-style-span" \
face="Courier">CONFIG_YAFFS_ALWAYS_CHECK_CHUNK_ERASED=y</font></div> <div><font \
class="Apple-style-span" face="Courier"># CONFIG_YAFFS_EMPTY_LOST_AND_FOUND is not \
set</font></div> <div><font class="Apple-style-span" face="Courier"># \
CONFIG_YAFFS_DISABLE_BLOCK_REFRESHING is not set</font></div> <div><font \
class="Apple-style-span" face="Courier"># CONFIG_YAFFS_DISABLE_BACKGROUND is not \
set</font></div> <div><font class="Apple-style-span" face="Courier"># \
CONFIG_YAFFS_DISABLE_BAD_BLOCK_MARKING is not set</font></div> <div><font \
class="Apple-style-span" face="Courier">CONFIG_YAFFS_XATTR=y</font></div> <div \
style="font-family: Arial; "><br> </div>
<div style="font-family: Arial; ">and are able to read our existing filesystem \
without issues. These are all defaults set by patch-ker.sh for 2.6.34 \
except for CONFIG_YAFFS_ALWAYS_CHECK_CHUNK_ERASED, which I carried forward \
from our old defconfig.</div> <div style="font-family: Arial; "><br>
</div>
<div style="font-family: Arial; "><br>
</div>
<div style="font-family: Arial; ">-Rob Calhoun</div>
<div style="font-family: Arial; "><br>
</div>
</div>
</div>
</body>
</html>
_______________________________________________
yaffs mailing list
yaffs@lists.aleph1.co.uk
http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
--===============1373883007==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic