<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi,<br>
<br>
On 29.10.2014 23:32, Claudio Thomas wrote:<br>
</div>
<blockquote cite="mid:54516AF4.6030009@xmodus-systems.de"
type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<div class="moz-cite-prefix">On 29.10.2014 13:37, Bastian Bittorf
wrote:<br>
</div>
<blockquote cite="mid:20141029123744.GS17340@medion.lan"
type="cite">
<pre wrap="">* Claudio Thomas <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:ct@xmodus-systems.de"><ct@xmodus-systems.de></a> [29.10.2014 13:18]:
</pre>
<blockquote type="cite">
<pre wrap="">[ 800.742671] jffs2: notice: (888) jffs2_build_xattr_subsystem:
</pre>
</blockquote>
<pre wrap="">how large is the partitionsize?</pre>
</blockquote>
"rootfs_data" created automatically, ofs=0x960000, len=0x3260000<br>
<blockquote cite="mid:20141029123744.GS17340@medion.lan"
type="cite">
<pre wrap="">while we are at it:
till r40402 we where probing jffs2_ready() before
writing to disc (e.g. new config-files).
what is the supposed way the handle that now?
(we grep the syslog for 'complete building xattr subsystem')
</pre>
</blockquote>
Sorry for the long delay, the tests need some time :-(<br>
<br>
I've made now a git pull+make clean, so that I've tested now again
with BB@43085:<br>
(For the tests I've booted using tftp+ramdisk)<br>
1. boot 3.10 with a working jffs and 3.8 config files: ~1183s(1),
~1232s(2), <br>
than run "/sbin/jffs2reset -y" (323s remove files time) and <br>
2. boot 3.10 with a empty jffs: ~1161s(1), ~1212s(2), <br>
than run "umount /overlay; /sbin/jffs2reset -y" (612s erase
time) and<br>
3. boot 3.10 with an erased jffs, <br>
see "No jffs marker found" (!) and <br>
received no "switching to overlay" (!) message, <br>
but /overlay is mounted: ~896s(1 - until complete
building...), ~899s(2)<br>
4. boot 3.10 with rebuilded jffs: ~1167(1), ~1205(2)<br>
<br>
For comparison a 3.8 build based on CC@43032<br>
1. boot 3.8: ~17.2s(1); "/sbin/jffs2reset -y" (1s remove files
time)<br>
2. boot 3.8 with empty jffs: ~5s(1); "umount /overlay;
/sbin/jffs2reset -y" (87s erase time)<br>
3. boot 3.8 with erased jffs: ~200s(1)<br>
4. boot 3.8 with rebuild jffs: ~17s(1)<br>
<br>
Is this helpful or should I test anything else?<br>
After comparing both there seem to be a performance issue, because
when looking only ate the erase time the 3.8 version erases the
flash 8 times faster. Any idea what I could check?<br>
</blockquote>
<br>
It seems that I finally find the reason for the long boot delay.<br>
After making some strace on jffsreset I find out that the longest
delay occurs after an ioctl-call:<br>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<tt> 0.000751 ioctl(3, MEMUNLOCK, 0xbfcde878) = 0</tt><tt><br>
</tt><tt> 293.231596 open(0x4801d1d6, O_RDONLY) = 4</tt><tt><br>
</tt><br>
This was nothing unexpected, but after I while I searched the web
for mtd+jffs+MEMUNLOCK and found the following:<br>
<a class="moz-txt-link-freetext" href="http://stackoverflow.com/questions/19706584/erasing-flash-nor-ioctlmemunlock-return-status">http://stackoverflow.com/questions/19706584/erasing-flash-nor-ioctlmemunlock-return-status</a><br>
Which was implemented in 3. 10 as described here:<br>
<a class="moz-txt-link-freetext" href="http://lists.infradead.org/pipermail/linux-mtd/2012-December/045230.html">http://lists.infradead.org/pipermail/linux-mtd/2012-December/045230.html</a><br>
<br>
The Problem is, it does not seem to run as expected on my hardware.
Removing it by a small patch solved the Problem. I know that this
isn't the best solution, but removing it I'm at the same trustworthy
<meta http-equiv="content-type" content="text/html; charset=utf-8">
point as I was when using the 3.8 kernel. The affected files are<br>
drivers/mtd/chips/cfi_cmdset_0002.c and<br>
drivers/mtd/devices/m25p80.c<br>
<br>
BTW: The last one was massive rewritten in 3.14, so that I guess
that I'm not the only one that found that this implementation wasn't
ok enough :-) <br>
<br>
In hope that I finally have a stable state for the mpc8306 on the
xm1700 board.<br>
I#ll come back after some more test :-)<br>
<br>
Thanks,<br>
Claudio<br>
<br>
--<br>
<span class="HOEnZb"><font color="#888888">Working on OpenWrt BB for
Xmodus Systems <a
href="http://www.xmodus-systems.de/en/terminals/routers.html"
target="_blank">XM17<font color="#888888">1</font>0E GSM/UMTS
Router</a></font></span><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>