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

2014-10-29 Thread Claudio Thomas 
Hi,
compiling/installing the same sources+config, but with 3.8 kernel all is
fine...
But when compilng with 3.10 the jffs takes about 18 minutes to get ready:
[ 2.655217] Freeing unused kernel memory: 160K (c045f000 - c0487000)
procd: Console is alive
procd: - preinit -
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
jffs2 is ready
jffs2 is ready
[  800.742671] jffs2: notice: (888) jffs2_build_xattr_subsystem:
complete building xattr subsystem, 1 of xdatum (0 unchecked, 0 orphan)
and 12 of xref (0 dead, 2 orphan) found.
switching to overlay
procd: - early -
procd: - ubus -
procd: - init -
Please press Enter to activate this console.
[ 1083.939598] usb 1-1: new high-speed USB device number 2 using fsl-ehci

Anyone an idea what could be wrong or how I can get more informations
what the board is doing this whole time to fix it?
Pressing 1,2,3 or 4 does not give any infos during this time.
Thanks,
Claudio

-- 
Working on OpenWrt BB for Xmodus Systems XM1700E

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] jffs takes about 18 minutes to get ready on 3.10 kernel

2014-10-29 Thread Bastian Bittorf 
* Claudio Thomas  [29.10.2014 13:18]:
> [  800.742671] jffs2: notice: (888) jffs2_build_xattr_subsystem:

how large is the partitionsize?

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

bye, bastian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] jffs takes about 18 minutes to get ready on 3.10 kernel

2014-10-29 Thread Claudio Thomas 
On 29.10.2014 13:37, Bastian Bittorf wrote:
> * Claudio Thomas  [29.10.2014 13:18]:
>> [  800.742671] jffs2: notice: (888) jffs2_build_xattr_subsystem:
> how large is the partitionsize?
"rootfs_data" created automatically, ofs=0x96, len=0x326
> 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?

BTW: When booting BB@43085 and after executing "umount /overlay;
/sbin/jffs2reset -y" I was missing the "deadc0de"? (No jffs marker found)
  # echo $(hexdump /dev/mtd1 -n 4 -e '4/1 "%02x"')
  
To avoid this I've run
  # echo -e "\xde\xad\xc0\xde" | mtd write - mtd1
Why isn't jffs2reset marking the partition after reset? (same issue
after running /sbin/jffs2mark)

Thanks,
Claudio
-- 
Working on OpenWrt BB for Xmodus Systems XM1700E


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

2014-11-24 Thread Claudio Thomas 
Hi,

On 29.10.2014 23:32, Claudio Thomas wrote:
> On 29.10.2014 13:37, Bastian Bittorf wrote:
>> * Claudio Thomas  [29.10.2014 13:18]:
>>> [  800.742671] jffs2: notice: (888) jffs2_build_xattr_subsystem:
>> how large is the partitionsize?
> "rootfs_data" created automatically, ofs=0x96, len=0x326
>> 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








___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel