[OpenWrt-Devel] Device tree issues with TL-WDR4900 (mpc85xx) and kernel 4.0.1

[Roman Yeryomin]

On 7 May 2015 at 15:49, Felix Fietkau <nbd at openwrt.org> wrote:
> On 2015-05-07 08:01, Wojciech Dubowik wrote:
>> Try to boot with kernel locking enabled. I have seen jffs2 deadlocks on
>> readdir. As far as I remember
>> with this patch it went through but I don't know anymore whether I have
>> changed sth in config.
>>
>> Have a look at (search engine...) [PATCH] fs: jffs2: Add setup code for
>> spi nor flash.
>>
>> Even with this patch I got some possible dead lock warnings so it might
>> be just a partial cure. BTW it's
>> a bit scary for future use. Looks like jffs2 doesn't get enough care...
> I believe the locking issues are an overlayfs regression, maybe even
> the same one as this one (which I fixed years ago):
> http://linux-fsdevel.vger.kernel.narkive.com/XRtXLDlf/patch-1-2-overlayfs-fix-a-deadlock-in-ovl-dir-read-merged
>
> I believe this is the cause of the regression:
>
> commit 49c21e1cacd74a8c83407c70ad860c994e606e25
> Author: Miklos Szeredi <mszeredi at suse.cz>
> Date:   Sat Dec 13 00:59:42 2014 +0100
>

I'm working on 4.0 support for ar71xx and found that
/etc/rc.d/S00sysfixtime is not able to finish it's job after second
boot after flashing (t.i. after overlayfs is switched to jffs). I've
run strace and found that find hangs on the very last getdents64 call
(before calling it succesfully many times on previous
files/directories).
I've reverted every change up to
49c21e1cacd74a8c83407c70ad860c994e606e25 to overlayfs and it started
working. Applying 49c21e1cacd74a8c83407c70ad860c994e606e25 back breaks
it. So this commit is indeed the cause of regression.

Miklos, any ideas how to fix it in current tree? I'm using 4.0.5 now
but AFAIK there were no more changes to overlayfs.


Regards,
Roman
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel