2013/11/27, John Crispin <j...@phrozen.org>: > On 27/11/13 08:48, Florian Fainelli wrote: >> >> On Nov 26, 2013 11:42 PM, "John Crispin" <j...@phrozen.org >> <mailto:j...@phrozen.org>> wrote: >> > >> > On 26/11/13 23:29, José Vázquez wrote: >> >> >> >> Maybe the problem is that part of the new init process does not work >> >> well with two cpus:http://pastebin.com/LTUmbxZ6 >> > >> > >> > >> > who says the new init does not work on smp ? i would claim that bmips >> is just not supported properly and the maintainers of the code base have >> let the code rot for too long ... >> Nobody said that the problem is due to smp or bmips. Could be a silicon errata in some BCM6368 SoCs, something related with jffs2 and smp (http://lists.infradead.org/pipermail/linux-mtd-cvs/2012-November/008218.html), flash chips not completely supported or something else.
>> That is kind of gratuitous, I see no evidence of problems coming from >> the BMIPS SMP support code. The other BMIPS based platforms I have seen >> do not have any jffs2 problems but they do not use overlayfs. I still >> think that there might be some missing cache flushing in the overlay fs >> code which only pops up with BMIPS CPUs due to how the I/D caches are >> designed between the two threads. Time to reproduce that on my end too. >> What can i do to help? > > > according to you its a caching problem. as other mips boards have > working SMP i would expect this to be bmips related. A couple of months ago compiled an ext4 image to test but found that, once the kernel calls preinit, the firm creates a partition with jffs2 fs and switch to overlayfs; the only way to avoid this behavior was unsetting jffs2 from the kernel. I go to make a jffs2 image and will post the logs. If somebody can tell what i must do to check deeper this issue i'll try to make my best effort. José _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
