Re: [OpenWrt-Devel] Device tree issues with TL-WDR4900 (mpc85xx) and kernel 4.0.1
On 15 June 2015 at 15:52, Miklos Szeredi mik...@szeredi.hu wrote:
On Mon, Jun 15, 2015 at 10:24:28AM +0200, Felix Fietkau wrote:
On 2015-06-15 10:20, Miklos Szeredi wrote:
On Thu, Jun 11, 2015 at 2:01 PM, Miklos Szeredi mszer...@suse.cz wrote:
On 7 May 2015 at 15:49, Felix Fietkau n...@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 mszer...@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.
What's the full mount setup? (cat /proc/mounts)
/dev/root /rom squashfs ro,relatime 0 0
proc /proc proc rw,noatime 0 0
sysfs /sys sysfs rw,noatime 0 0
tmpfs /tmp tmpfs rw,nosuid,nodev,noatime 0 0
/dev/mtdblock8 /overlay jffs2 rw,noatime 0 0
overlayfs:/overlay / overlay
rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work 0 0
tmpfs /dev tmpfs rw,relatime,size=512k,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
debugfs /sys/kernel/debug debugfs rw,noatime 0 0
- Felix
Following patch should fix the locking issue.
Please test.
It worked! Thanks Miklos!
Felix, attaching tested and ready to commit patch.
Or do you want me to send it separately to the list?
Regards,
Roman
--- a/fs/overlayfs/readdir.c
+++ b/fs/overlayfs/readdir.c
@@ -23,6 +23,7 @@ struct ovl_cache_entry {
u64 ino;
struct list_head l_node;
struct rb_node node;
+ struct ovl_cache_entry *next_maybe_whiteout;
bool is_whiteout;
char name[];
};
@@ -39,7 +40,7 @@ struct ovl_readdir_data {
struct rb_root root;
struct list_head *list;
struct list_head middle;
- struct dentry *dir;
+ struct ovl_cache_entry *first_maybe_whiteout;
int count;
int err;
};
@@ -79,7 +80,7 @@ static struct ovl_cache_entry *ovl_cache
return NULL;
}
-static struct ovl_cache_entry *ovl_cache_entry_new(struct dentry *dir,
+static struct ovl_cache_entry *ovl_cache_entry_new(struct ovl_readdir_data *rdd,
const char *name, int len,
u64 ino, unsigned int d_type)
{
@@ -98,29 +99,8 @@ static struct ovl_cache_entry *ovl_cache
p-is_whiteout = false;
if (d_type == DT_CHR) {
- struct dentry *dentry;
- const struct cred *old_cred;
- struct cred *override_cred;
-
- override_cred = prepare_creds();
- if (!override_cred) {
- kfree(p);
- return NULL;
- }
-
- /*
- * CAP_DAC_OVERRIDE for lookup
- */
- cap_raise(override_cred-cap_effective, CAP_DAC_OVERRIDE);
- old_cred = override_creds(override_cred);
-
- dentry = lookup_one_len(name, dir, len);
- if (!IS_ERR(dentry)) {
- p-is_whiteout = ovl_is_whiteout(dentry);
- dput(dentry);
- }
- revert_creds(old_cred);
- put_cred(override_cred);
+ p-next_maybe_whiteout = rdd-first_maybe_whiteout;
+ rdd-first_maybe_whiteout = p;
}
return p;
}
@@ -148,7 +128,7 @@ static int ovl_cache_entry_add_rb(struct
return 0;
}
- p = ovl_cache_entry_new(rdd-dir, name, len, ino, d_type);
+ p = ovl_cache_entry_new(rdd, name, len, ino, d_type);
if (p == NULL)
return -ENOMEM;
@@ -169,7 +149,7 @@ static int ovl_fill_lower(struct ovl_rea
if (p) {
list_move_tail(p-l_node, rdd-middle);
} else {
- p = ovl_cache_entry_new(rdd-dir, name, namelen, ino, d_type);
+ p = ovl_cache_entry_new(rdd, name, namelen, ino, d_type);
if (p == NULL)
rdd-err = -ENOMEM;
else
@@ -219,6 +199,43 @@ static int ovl_fill_merge(struct dir_con
return ovl_fill_lower(rdd, name, namelen, offset, ino, d_type);
}
+static int ovl_check_whiteouts(struct dentry *dir, struct ovl_readdir_data *rdd)
+{
+
Re: [OpenWrt-Devel] Device tree issues with TL-WDR4900 (mpc85xx) and kernel 4.0.1
On 2015-06-15 10:20, Miklos Szeredi wrote: On Thu, Jun 11, 2015 at 2:01 PM, Miklos Szeredi mszer...@suse.cz wrote: On 7 May 2015 at 15:49, Felix Fietkau n...@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 mszer...@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. What's the full mount setup? (cat /proc/mounts) /dev/root /rom squashfs ro,relatime 0 0 proc /proc proc rw,noatime 0 0 sysfs /sys sysfs rw,noatime 0 0 tmpfs /tmp tmpfs rw,nosuid,nodev,noatime 0 0 /dev/mtdblock8 /overlay jffs2 rw,noatime 0 0 overlayfs:/overlay / overlay rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work 0 0 tmpfs /dev tmpfs rw,relatime,size=512k,mode=755 0 0 devpts /dev/pts devpts rw,relatime,mode=600 0 0 debugfs /sys/kernel/debug debugfs rw,noatime 0 0 - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Device tree issues with TL-WDR4900 (mpc85xx) and kernel 4.0.1
On 11 June 2015 at 13:25, Roman Yeryomin leroi.li...@gmail.com wrote: On 7 May 2015 at 15:49, Felix Fietkau n...@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 mszer...@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. Felix, John, Should I send a patch reverting all changes to overlayfs up to that commit until there is a proper fix? Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Device tree issues with TL-WDR4900 (mpc85xx) and kernel 4.0.1
On 7 May 2015 at 15:49, Felix Fietkau n...@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 mszer...@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@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Device tree issues with TL-WDR4900 (mpc85xx) and kernel 4.0.1
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 mszer...@suse.cz Date: Sat Dec 13 00:59:42 2014 +0100 ovl: check whiteout while reading directory Don't make a separate pass for checking whiteouts, since we can do it while reading the upper directory. This will make it easier to handle multiple layers. Signed-off-by: Miklos Szeredi mszer...@suse.cz It probably happens like this: overlayfs does a readdir, in which jffs2 takes a lock. From within the readdir fill callback, it calls lookup_one_len, which ends up back in jffs2 and tries to take the same lock again. = deadlock. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Device tree issues with TL-WDR4900 (mpc85xx) and kernel 4.0.1
On 07/05/15 14:26, Heiner Kallweit wrote: [snip] 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... Regards, Wojtek Heiner Thanks for the hints! Because you mentioned that you have lots of problems with gianfar under 4.0: what kind of problems? I have got locking problems when using multiqueue on gianfar. I have no problems on 3.18. There is also reset issue on SGMII interface but if you are using TL-WDR4900 you have RGMII, so no problem. Wojtek Heiner ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Device tree issues with TL-WDR4900 (mpc85xx) and kernel 4.0.1
On 06/05/15 21:23, Heiner Kallweit wrote:
Am 05.05.2015 um 22:17 schrieb Heiner Kallweit:
Am 05.05.2015 um 08:29 schrieb Wojciech Dubowik:
On 04/05/15 22:45, Heiner Kallweit wrote:
I tried to make the TL-WDR4900 work under kernel 4.0.
Adjusting the platform-specific patches was quickly done and the system boots.
However I get the following error messages.
[2.959975] /leds/system: could not get #gpio-cells for
/soc@ffe0/gpio-controller@f000
[2.968276] leds-gpio: probe of leds failed with error -22
[ 34.622909] /buttons/reset: could not get #gpio-cells for
/soc@ffe0/gpio-controller@f000
[ 34.631383] gpio-keys buttons: Failed to get gpio flags, error: -22
[ 34.637657] gpio-keys: probe of buttons failed with error -22
I'm not a device tree expert, what I checked so far:
The gpio-related section in tl-wdr4900-v1.dts is empty
gpio0: gpio-controller@f000 {
};
Gpio controller is now at fc00. See latest commit for
arch/powerpc/boot/dts/fsl/pq3-gpio-0.dtsi.
Regards,
Wojtek
PS. I have been also trying 4.0 but I have ran into so many problems with
gianfar that I have given it up.
For now...
Thanks. I face issues with the network as well and had to attach a serial
console + tftpboot to make it work again.
Back to 3.19.0 now ..
Heiner
I gave it one more try and replaced the gianfar driver from 4.0.1 with the one
from 3.19.0. Results:
- When rebooting first time after flashing the system (4.0.1) came up properly
and was reachable via network.
- After next reboot: system hangs
Booting the failing system with a serial console attached shows that after procd
-init- nothing happens.
I can log in via serial console. ps -ef showed that /etc/rc.d/S00sysfixtime was
hanging.
Checking the commands in this script manually I figured out that each access to
/etc/uci-default blocks the console.
Seems like the first start after flashing the system does something bad with
/etc/uci-defaults.
Or for whatever reason something can't deal properly with the empty
/etc/uci-defaults after the second boot.
No clue whom to blame ..
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...
Regards,
Wojtek
Heiner
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Device tree issues with TL-WDR4900 (mpc85xx) and kernel 4.0.1
On Thu, May 7, 2015 at 8:01 AM, Wojciech Dubowik
wojciech.dubo...@neratec.com wrote:
On 06/05/15 21:23, Heiner Kallweit wrote:
Am 05.05.2015 um 22:17 schrieb Heiner Kallweit:
Am 05.05.2015 um 08:29 schrieb Wojciech Dubowik:
On 04/05/15 22:45, Heiner Kallweit wrote:
I tried to make the TL-WDR4900 work under kernel 4.0.
Adjusting the platform-specific patches was quickly done and the system
boots.
However I get the following error messages.
[2.959975] /leds/system: could not get #gpio-cells for
/soc@ffe0/gpio-controller@f000
[2.968276] leds-gpio: probe of leds failed with error -22
[ 34.622909] /buttons/reset: could not get #gpio-cells for
/soc@ffe0/gpio-controller@f000
[ 34.631383] gpio-keys buttons: Failed to get gpio flags, error: -22
[ 34.637657] gpio-keys: probe of buttons failed with error -22
I'm not a device tree expert, what I checked so far:
The gpio-related section in tl-wdr4900-v1.dts is empty
gpio0: gpio-controller@f000 {
};
Gpio controller is now at fc00. See latest commit for
arch/powerpc/boot/dts/fsl/pq3-gpio-0.dtsi.
Regards,
Wojtek
PS. I have been also trying 4.0 but I have ran into so many problems
with gianfar that I have given it up.
For now...
Thanks. I face issues with the network as well and had to attach a serial
console + tftpboot to make it work again.
Back to 3.19.0 now ..
Heiner
I gave it one more try and replaced the gianfar driver from 4.0.1 with the
one from 3.19.0. Results:
- When rebooting first time after flashing the system (4.0.1) came up
properly and was reachable via network.
- After next reboot: system hangs
Booting the failing system with a serial console attached shows that after
procd -init- nothing happens.
I can log in via serial console. ps -ef showed that
/etc/rc.d/S00sysfixtime was hanging.
Checking the commands in this script manually I figured out that each
access to /etc/uci-default blocks the console.
Seems like the first start after flashing the system does something bad
with /etc/uci-defaults.
Or for whatever reason something can't deal properly with the empty
/etc/uci-defaults after the second boot.
No clue whom to blame ..
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...
Regards,
Wojtek
Heiner
Thanks for the hints!
Because you mentioned that you have lots of problems with gianfar
under 4.0: what kind of problems?
Heiner
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Device tree issues with TL-WDR4900 (mpc85xx) and kernel 4.0.1
On 07/05/15 14:49, Felix Fietkau 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 mszer...@suse.cz Date: Sat Dec 13 00:59:42 2014 +0100 ovl: check whiteout while reading directory Don't make a separate pass for checking whiteouts, since we can do it while reading the upper directory. This will make it easier to handle multiple layers. Signed-off-by: Miklos Szeredi mszer...@suse.cz It probably happens like this: overlayfs does a readdir, in which jffs2 takes a lock. From within the readdir fill callback, it calls lookup_one_len, which ends up back in jffs2 and tries to take the same lock again. = deadlock. This is exactly what I have seen. I have got deadlocks on readdir. Unfortunately I don't have any logs saved... Wojtek - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Device tree issues with TL-WDR4900 (mpc85xx) and kernel 4.0.1
Am 05.05.2015 um 22:17 schrieb Heiner Kallweit:
Am 05.05.2015 um 08:29 schrieb Wojciech Dubowik:
On 04/05/15 22:45, Heiner Kallweit wrote:
I tried to make the TL-WDR4900 work under kernel 4.0.
Adjusting the platform-specific patches was quickly done and the system
boots.
However I get the following error messages.
[2.959975] /leds/system: could not get #gpio-cells for
/soc@ffe0/gpio-controller@f000
[2.968276] leds-gpio: probe of leds failed with error -22
[ 34.622909] /buttons/reset: could not get #gpio-cells for
/soc@ffe0/gpio-controller@f000
[ 34.631383] gpio-keys buttons: Failed to get gpio flags, error: -22
[ 34.637657] gpio-keys: probe of buttons failed with error -22
I'm not a device tree expert, what I checked so far:
The gpio-related section in tl-wdr4900-v1.dts is empty
gpio0: gpio-controller@f000 {
};
Gpio controller is now at fc00. See latest commit for
arch/powerpc/boot/dts/fsl/pq3-gpio-0.dtsi.
Regards,
Wojtek
PS. I have been also trying 4.0 but I have ran into so many problems with
gianfar that I have given it up.
For now...
Thanks. I face issues with the network as well and had to attach a serial
console + tftpboot to make it work again.
Back to 3.19.0 now ..
Heiner
I gave it one more try and replaced the gianfar driver from 4.0.1 with the one
from 3.19.0. Results:
- When rebooting first time after flashing the system (4.0.1) came up properly
and was reachable via network.
- After next reboot: system hangs
Booting the failing system with a serial console attached shows that after
procd -init- nothing happens.
I can log in via serial console. ps -ef showed that /etc/rc.d/S00sysfixtime was
hanging.
Checking the commands in this script manually I figured out that each access to
/etc/uci-default blocks the console.
Seems like the first start after flashing the system does something bad with
/etc/uci-defaults.
Or for whatever reason something can't deal properly with the empty
/etc/uci-defaults after the second boot.
No clue whom to blame ..
Heiner
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Device tree issues with TL-WDR4900 (mpc85xx) and kernel 4.0.1
On 04/05/15 22:45, Heiner Kallweit wrote:
I tried to make the TL-WDR4900 work under kernel 4.0.
Adjusting the platform-specific patches was quickly done and the system boots.
However I get the following error messages.
[2.959975] /leds/system: could not get #gpio-cells for
/soc@ffe0/gpio-controller@f000
[2.968276] leds-gpio: probe of leds failed with error -22
[ 34.622909] /buttons/reset: could not get #gpio-cells for
/soc@ffe0/gpio-controller@f000
[ 34.631383] gpio-keys buttons: Failed to get gpio flags, error: -22
[ 34.637657] gpio-keys: probe of buttons failed with error -22
I'm not a device tree expert, what I checked so far:
The gpio-related section in tl-wdr4900-v1.dts is empty
gpio0: gpio-controller@f000 {
};
Gpio controller is now at fc00. See latest commit for
arch/powerpc/boot/dts/fsl/pq3-gpio-0.dtsi.
Regards,
Wojtek
PS. I have been also trying 4.0 but I have ran into so many problems
with gianfar that I have given it up.
For now...
However #gpio-cells is defined in fsl/pq3-gpio-0.dtsi and this file is imported
by fsl/p1010si-post.dtsi.
And fsl/p1010si-post.dtsi is imported by tl-wdr4900-v1.dts.
This worked under 3.19 (despite the fact that 3.19 was never officially
supported for this device),
seems like something with the DT handling has changed in 4.0.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Device tree issues with TL-WDR4900 (mpc85xx) and kernel 4.0.1
Am 05.05.2015 um 08:29 schrieb Wojciech Dubowik:
On 04/05/15 22:45, Heiner Kallweit wrote:
I tried to make the TL-WDR4900 work under kernel 4.0.
Adjusting the platform-specific patches was quickly done and the system
boots.
However I get the following error messages.
[2.959975] /leds/system: could not get #gpio-cells for
/soc@ffe0/gpio-controller@f000
[2.968276] leds-gpio: probe of leds failed with error -22
[ 34.622909] /buttons/reset: could not get #gpio-cells for
/soc@ffe0/gpio-controller@f000
[ 34.631383] gpio-keys buttons: Failed to get gpio flags, error: -22
[ 34.637657] gpio-keys: probe of buttons failed with error -22
I'm not a device tree expert, what I checked so far:
The gpio-related section in tl-wdr4900-v1.dts is empty
gpio0: gpio-controller@f000 {
};
Gpio controller is now at fc00. See latest commit for
arch/powerpc/boot/dts/fsl/pq3-gpio-0.dtsi.
Regards,
Wojtek
PS. I have been also trying 4.0 but I have ran into so many problems with
gianfar that I have given it up.
For now...
Thanks. I face issues with the network as well and had to attach a serial
console + tftpboot to make it work again.
Back to 3.19.0 now ..
Heiner
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Device tree issues with TL-WDR4900 (mpc85xx) and kernel 4.0.1
I tried to make the TL-WDR4900 work under kernel 4.0.
Adjusting the platform-specific patches was quickly done and the system boots.
However I get the following error messages.
[2.959975] /leds/system: could not get #gpio-cells for
/soc@ffe0/gpio-controller@f000
[2.968276] leds-gpio: probe of leds failed with error -22
[ 34.622909] /buttons/reset: could not get #gpio-cells for
/soc@ffe0/gpio-controller@f000
[ 34.631383] gpio-keys buttons: Failed to get gpio flags, error: -22
[ 34.637657] gpio-keys: probe of buttons failed with error -22
I'm not a device tree expert, what I checked so far:
The gpio-related section in tl-wdr4900-v1.dts is empty
gpio0: gpio-controller@f000 {
};
However #gpio-cells is defined in fsl/pq3-gpio-0.dtsi and this file is imported
by fsl/p1010si-post.dtsi.
And fsl/p1010si-post.dtsi is imported by tl-wdr4900-v1.dts.
This worked under 3.19 (despite the fact that 3.19 was never officially
supported for this device),
seems like something with the DT handling has changed in 4.0.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
