[OpenWrt-Devel] Device tree issues with TL-WDR4900 (mpc85xx) and kernel 4.0.1
leroi.lists at gmail.com
Sun Jun 14 13:19:23 EDT 2015
On 11 June 2015 at 13:25, Roman Yeryomin <leroi.lists at gmail.com> wrote:
> 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):
>> 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
> 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.
Should I send a patch reverting all changes to overlayfs up to that
commit until there is a proper fix?
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel