[OpenWrt-Devel] jffs takes about 18 minutes to get ready on 3.10 kernel (probably solved)

Claudio Thomas ct at xmodus-systems.de
Mon Nov 24 10:35:46 EST 2014


On 29.10.2014 23:32, Claudio Thomas wrote:
> On 29.10.2014 13:37, Bastian Bittorf wrote:
>> * Claudio Thomas <ct at xmodus-systems.de> [29.10.2014 13:18]:
>>> [  800.742671] jffs2: notice: (888) jffs2_build_xattr_subsystem:
>> how large is the partitionsize?
> "rootfs_data" created automatically, ofs=0x960000, len=0x3260000
>> 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')
> Sorry for the long delay, the tests need some time :-(
> I've made now a git pull+make clean, so that I've tested now again
> with BB at 43085:
> (For the tests I've booted using tftp+ramdisk)
> 1. boot 3.10 with a working jffs and 3.8 config files: ~1183s(1),
> ~1232s(2),
>     than run "/sbin/jffs2reset -y" (323s remove files time) and
> 2. boot 3.10 with a empty jffs: ~1161s(1), ~1212s(2),
>     than run "umount /overlay; /sbin/jffs2reset -y" (612s erase time) and
> 3. boot 3.10 with an erased jffs,
>     see "No jffs marker found" (!) and
>     received no "switching to overlay" (!) message,
>     but /overlay is mounted: ~896s(1 - until complete building...),
> ~899s(2)
> 4. boot 3.10 with rebuilded jffs: ~1167(1), ~1205(2)
> For comparison a 3.8 build based on CC at 43032
> 1. boot 3.8: ~17.2s(1);  "/sbin/jffs2reset -y" (1s remove files time)
> 2. boot 3.8 with empty jffs: ~5s(1); "umount /overlay;
> /sbin/jffs2reset -y" (87s erase time)
> 3. boot 3.8 with erased jffs: ~200s(1)
> 4. boot 3.8 with rebuild jffs: ~17s(1)
> Is this helpful or should I test anything else?
> 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?

It seems that I finally find the reason for the long boot delay.
After making some strace on jffsreset I find out that the longest delay
occurs after an ioctl-call:
     0.000751 ioctl(3, MEMUNLOCK, 0xbfcde878) = 0
   293.231596 open(0x4801d1d6, O_RDONLY) = 4

This was nothing unexpected, but after I while I searched the web for
mtd+jffs+MEMUNLOCK and found the following:
Which was implemented in 3. 10 as described here:

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 point as
I was when using the 3.8 kernel. The affected files are
drivers/mtd/chips/cfi_cmdset_0002.c and

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 :-)

In hope that I finally have a stable state for the mpc8306 on the xm1700
I#ll come back after some more test :-)


Working on OpenWrt BB for Xmodus Systems XM1710E GSM/UMTS Router

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20141124/33b8a907/attachment.htm>
-------------- next part --------------
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list