Hi,
On 29.10.2014 23:32, Claudio Thomas wrote:
> On 29.10.2014 13:37, Bastian Bittorf wrote:
>> * Claudio Thomas <c...@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@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@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:
http://stackoverflow.com/questions/19706584/erasing-flash-nor-ioctlmemunlock-return-status
Which was implemented in 3. 10 as described here:
http://lists.infradead.org/pipermail/linux-mtd/2012-December/045230.html
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
drivers/mtd/devices/m25p80.c
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
board.
I#ll come back after some more test :-)
Thanks,
Claudio
--
Working on OpenWrt BB for Xmodus Systems XM1710E GSM/UMTS Router
<http://www.xmodus-systems.de/en/terminals/routers.html>
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
