Re: [OpenWrt-Devel] [PATCH] [ar71xx] Added support for D-link DHP-1565 rev. A1
Hi,
there are some space vs tab errors. looks like they are int he original
patch and were not introduced by your mail client. please fix and resend
John
On 04/11/2014 09:55, ja...@aol.pl wrote:
From: Jacek Kikiewicz ja...@aol.pl
Signed-off-by: Jacek Kikiewicz ja...@aol.pl
---
target/linux/ar71xx/base-files/etc/diag.sh | 1 +
.../ar71xx/base-files/etc/uci-defaults/01_leds | 4 +
.../ar71xx/base-files/etc/uci-defaults/02_network | 1 +
.../base-files/etc/uci-defaults/04_led_migration | 1 +
target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 +
.../ar71xx/base-files/lib/upgrade/platform.sh | 1 +
target/linux/ar71xx/config-3.10| 1 +
.../files/arch/mips/ath79/mach-dhp-1565-a1.c | 170
+
target/linux/ar71xx/generic/profiles/d-link.mk | 11 ++
target/linux/ar71xx/image/Makefile | 1 +
.../730-MIPS-ath79-add-DHP-1565A1.patch| 40 +
11 files changed, 234 insertions(+)
create mode 100644
target/linux/ar71xx/files/arch/mips/ath79/mach-dhp-1565-a1.c
create mode 100644
target/linux/ar71xx/patches-3.10/730-MIPS-ath79-add-DHP-1565A1.patch
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files/etc/diag.sh
index b3a8fc5..24f5871 100755
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -46,6 +46,7 @@ get_status_led() {
db120)
status_led=db120:green:status
;;
+dhp-1565-a1|\
here
dir-505-a1 |\
dir-600-a1 |\
dir-615-e1 |\
diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
index 599fc19..2e41250 100755
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
@@ -98,6 +98,10 @@ rb-2011uias-2hnd)
ucidef_set_led_switch eth10 ETH10 rb:green:eth10 switch1 0x02
;;
+dhp-1565-a1)
+ ucidef_set_led_switch wan WAN d-link:green:planet switch0
0x20
+ ;;
+
and here
dir-505-a1)
ucidef_set_led_netdev lan LAN d-link:green:power eth1
;;
diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
index 743f9de..c7d8aec 100755
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
@@ -258,6 +258,7 @@ mynet-n750)
[ -n $mac ] ucidef_set_interface_macaddr wan $mac
;;
+dhp-1565-a1 |\
dir-835-a1 |\
wndr3700v4 | \
wndr4300)
diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/04_led_migration
b/target/linux/ar71xx/base-files/etc/uci-defaults/04_led_migration
index 0df94a0..1cef8b9 100755
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/04_led_migration
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/04_led_migration
@@ -46,6 +46,7 @@ migrate_leds()
board=$(ar71xx_board_name)
case $board in
+dhp-1565-a1|\
dir-825-c1|\
dir-835-a1)
migrate_leds :orange:=:amber: :wifi_bgn=:wlan2g
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 40e9303..bd7a276 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -305,6 +305,9 @@ ar71xx_board_detect() {
*DB120 reference board)
name=db120
;;
+*DHP-1565 rev. A1)
+name=dhp-1565-a1
+;;
*DIR-505 rev. A1)
name=dir-505-a1
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 6220f16..3a3d4ee 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -167,6 +167,7 @@ platform_check_image() {
ap81 | \
ap83 | \
ap132 | \
+ dhp-1565-a1 |\
dir-505-a1 | \
dir-600-a1 | \
dir-615-c1 | \
and here
diff --git a/target/linux/ar71xx/config-3.10 b/target/linux/ar71xx/config-3.10
index 1b3eddb..3a2b4af 100644
--- a/target/linux/ar71xx/config-3.10
+++ b/target/linux/ar71xx/config-3.10
@@ -40,6 +40,7 @@ CONFIG_ATH79_MACH_BHU_BXU2000N2_A=y
CONFIG_ATH79_MACH_CAP4200AG=y
CONFIG_ATH79_MACH_CARAMBOLA2=y
CONFIG_ATH79_MACH_DB120=y
+CONFIG_ATH79_MACH_DHP_1565_A1=y
CONFIG_ATH79_MACH_DIR_505_A1=y
CONFIG_ATH79_MACH_DIR_600_A1=y
CONFIG_ATH79_MACH_DIR_615_C1=y
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-dhp-1565-a1.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-dhp-1565-a1.c
new file mode 100644
index 000..ae47764
--- /dev/null
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-dhp-1565-a1.c
@@ -0,0 +1,170 @@
+/*
Re: [OpenWrt-Devel] protobuf broken in BB
Hi, What happened to the testing ? we are considering a 14.07.1 in the very near future so this should be fixed beforehand. John On 05/11/2014 22:43, Guillaume Déflache wrote: Am 05.11.2014 17:39, schrieb obconseil: Le 05/11/2014 16:41, Guillaume Déflache a écrit : [...] For others' to understand I should have made clear the library itself builds fine, only the host's `protoc` does not get installed. It would not help, 2.4.1 of AA worked fine, only the Makefile's new host macros cause problems. That patch chunk should be reverted IMHO and only the version changed, in case someone still needs it (we do not). Besides there is 2.6.1 now: in my own experience x.y.n tends to be more stable than z.t.0 for all values of x,y,z,t and n! :) I just made a quick build using 2.6.1 from github on the openwrt's trunk. I had to remove the patch completely , and make the according changes on the Makefile. Then it built (host+package) without any issues on my debian jessie (I have to indicate here that I do not have the libprotobuf nor the libprotobuf-dev .deb packages installed on this machine. That's indeed better for testing! It created me the ./build_dir/host/protobuf-2.6.1/src/protoc without issues. Fine, but that's not the problem as I said before (see the very 1st quoted text in this message): *installing protoc at the right location* (that is .../build_dir/host/bin/protoc IIRC) is the problem. I checked that with our pre-BB snapshot it was installed where expected and that with the BB release it is not. You can try executing `make install` from the host build directory to convince yourself that that does what is required from the OpenWrt Makefile but currently missing in BB's. That's what I did and then the problem was gone. So you have to try using protoc to generate some source code files in order to really stumble on the problem. Apart from that everything works fine indeed. Meanwhile another protobuf-related problem showed up, perhaps someone can help: [100%] Building CXX object CMakeFiles/[CENSORED].pb.cc.o /tmp/ccKFaHTE.s: Assembler messages: /tmp/ccKFaHTE.s:16516: Error: opcode not supported on this processor:mips1 (mips1) `sync' make[5]: *** [CMakeFiles/[CENSORED].pb.cc.o] Error 1 Since the snapshot we used previously PKG_USE_MIPS16:=0 also got added, does that mean we should also use that on all packages that compile Protocol Buffer generated code and/or link with the PB library? Or is it necessary/possible to instruct the host protoc to generate source code for MIPS32? Does PB needs generating CPU-specific C/C++ (instrinsics?) or asm sections? (We do not need MIPS16 ATM, so any MIPS32 solution would do for us.) The target platform I'm using now is Ralink RT5350 , so mips24k , is that OK for you ? I currently develop for the ZyXEL NBG6716 (http://wiki.openwrt.org/toh/zyxel/zyxel_nbg6716) which is MIPS32 (MIPS74Kc). Would that happen to be backward compatible with yours? I don't really understand why you have such an error - it look like a compiler error rather than a protobuf error. Indeed, but I could upgrade many packages from our pre-BB snapshot to the BB release without changing a single compiler flag or source code line WRT MIPS16. Then today I just had a problem while compiling the 1st PB-generated source code file... Just saying! ;) Anyway I will try to force PKG_USE_MIPS16:=0 on related packages to see if it helps and report here. I have yet to build the package with a mips16 target. Anyway, the patch I used is joined to this mail - if it's OK with you I'll resend the patch with an official pull-request header. Sorry, the patch as it stands still would not solve our problem. Reverting the non-version related changes compared to pre-BBfinal pre-Git revisions would, I think (I can test that next Friday at the soonest). I would have no objections to 2.6.1 if it also works for us too (I can test that at the same time). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Hooks on wifi up/down for starting/stopping dependent functionality?
* Johan Almbladh j...@anyfi.net [17.11.2014 10:22]: The hotplug scripts receive events for interface names, but they know nothing about the underlying configuration. Is there any way to map a WLAN interface name, e.g. wlan0, to the corresponding UCI config entry in /etc/config/wireless? /sbin/hotplug-call exports some global shell-vars, which you can use in your script, e.g.: ACTION - e.g. 'ifup' INTERFACE - e.g. 'mywan' DEVICE - e.g. eth0.2 if you need some more, you can query them in your script with e.g. ubus call network.interface.mywan status you can parse the JSON with e.g. . /usr/share/libubox/jshn.sh OUT=$( ubus call network.interface.mywan status ) eval $( jshn -r $OUT ) echo $JSON_VAR_status bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [ar71xx] Added support for D-link DHP-1565 rev. A1
From: Jacek Kikiewicz ja...@aol.pl
Signed-off-by: Jacek Kikiewicz ja...@aol.pl
---
target/linux/ar71xx/base-files/etc/diag.sh | 1 +
.../ar71xx/base-files/etc/uci-defaults/01_leds | 4 +
.../ar71xx/base-files/etc/uci-defaults/02_network | 1 +
.../base-files/etc/uci-defaults/04_led_migration | 1 +
target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 +
.../ar71xx/base-files/lib/upgrade/platform.sh | 1 +
target/linux/ar71xx/config-3.10| 1 +
.../files/arch/mips/ath79/mach-dhp-1565-a1.c | 170 +
target/linux/ar71xx/generic/profiles/d-link.mk | 11 ++
target/linux/ar71xx/image/Makefile | 1 +
.../730-MIPS-ath79-add-DHP-1565A1.patch| 40 +
11 files changed, 234 insertions(+)
create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-dhp-1565-a1.c
create mode 100644
target/linux/ar71xx/patches-3.10/730-MIPS-ath79-add-DHP-1565A1.patch
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files/etc/diag.sh
index b3a8fc5..24f5871 100755
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -46,6 +46,7 @@ get_status_led() {
db120)
status_led=db120:green:status
;;
+ dhp-1565-a1|\
dir-505-a1 |\
dir-600-a1 |\
dir-615-e1 |\
diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
index 599fc19..2e41250 100755
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
@@ -98,6 +98,10 @@ rb-2011uias-2hnd)
ucidef_set_led_switch eth10 ETH10 rb:green:eth10 switch1 0x02
;;
+dhp-1565-a1)
+ ucidef_set_led_switch wan WAN d-link:green:planet switch0 0x20
+ ;;
+
dir-505-a1)
ucidef_set_led_netdev lan LAN d-link:green:power eth1
;;
diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
index 743f9de..c7d8aec 100755
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
@@ -258,6 +258,7 @@ mynet-n750)
[ -n $mac ] ucidef_set_interface_macaddr wan $mac
;;
+dhp-1565-a1 |\
dir-835-a1 |\
wndr3700v4 | \
wndr4300)
diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/04_led_migration
b/target/linux/ar71xx/base-files/etc/uci-defaults/04_led_migration
index 0df94a0..1cef8b9 100755
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/04_led_migration
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/04_led_migration
@@ -46,6 +46,7 @@ migrate_leds()
board=$(ar71xx_board_name)
case $board in
+dhp-1565-a1|\
dir-825-c1|\
dir-835-a1)
migrate_leds :orange:=:amber: :wifi_bgn=:wlan2g
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 40e9303..bd7a276 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -305,6 +305,9 @@ ar71xx_board_detect() {
*DB120 reference board)
name=db120
;;
+ *DHP-1565 rev. A1)
+ name=dhp-1565-a1
+ ;;
*DIR-505 rev. A1)
name=dir-505-a1
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 6220f16..3a3d4ee 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -167,6 +167,7 @@ platform_check_image() {
ap81 | \
ap83 | \
ap132 | \
+ dhp-1565-a1 |\
dir-505-a1 | \
dir-600-a1 | \
dir-615-c1 | \
diff --git a/target/linux/ar71xx/config-3.10 b/target/linux/ar71xx/config-3.10
index 1b3eddb..3a2b4af 100644
--- a/target/linux/ar71xx/config-3.10
+++ b/target/linux/ar71xx/config-3.10
@@ -40,6 +40,7 @@ CONFIG_ATH79_MACH_BHU_BXU2000N2_A=y
CONFIG_ATH79_MACH_CAP4200AG=y
CONFIG_ATH79_MACH_CARAMBOLA2=y
CONFIG_ATH79_MACH_DB120=y
+CONFIG_ATH79_MACH_DHP_1565_A1=y
CONFIG_ATH79_MACH_DIR_505_A1=y
CONFIG_ATH79_MACH_DIR_600_A1=y
CONFIG_ATH79_MACH_DIR_615_C1=y
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-dhp-1565-a1.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-dhp-1565-a1.c
new file mode 100644
index 000..ae47764
--- /dev/null
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-dhp-1565-a1.c
@@ -0,0 +1,170 @@
+/*
+ * D-Link DHP-1565 rev. A1 board support
+ *
+ * Copyright (C) 2014 Jacek Kikiewicz
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include linux/pci.h
Re: [OpenWrt-Devel] protobuf broken in BB
Hello, The last patch I sent to Guillaume is working for me. I'm waiting for his approval before re-submitting it to the list officially. Thanks John, Obinou Le 17/11/2014 09:54, John Crispin a écrit : Hi, What happened to the testing ? we are considering a 14.07.1 in the very near future so this should be fixed beforehand. John On 05/11/2014 22:43, Guillaume Déflache wrote: Am 05.11.2014 17:39, schrieb obconseil: Le 05/11/2014 16:41, Guillaume Déflache a écrit : [...] For others' to understand I should have made clear the library itself builds fine, only the host's `protoc` does not get installed. It would not help, 2.4.1 of AA worked fine, only the Makefile's new host macros cause problems. That patch chunk should be reverted IMHO and only the version changed, in case someone still needs it (we do not). Besides there is 2.6.1 now: in my own experience x.y.n tends to be more stable than z.t.0 for all values of x,y,z,t and n! :) I just made a quick build using 2.6.1 from github on the openwrt's trunk. I had to remove the patch completely , and make the according changes on the Makefile. Then it built (host+package) without any issues on my debian jessie (I have to indicate here that I do not have the libprotobuf nor the libprotobuf-dev .deb packages installed on this machine. That's indeed better for testing! It created me the ./build_dir/host/protobuf-2.6.1/src/protoc without issues. Fine, but that's not the problem as I said before (see the very 1st quoted text in this message): *installing protoc at the right location* (that is .../build_dir/host/bin/protoc IIRC) is the problem. I checked that with our pre-BB snapshot it was installed where expected and that with the BB release it is not. You can try executing `make install` from the host build directory to convince yourself that that does what is required from the OpenWrt Makefile but currently missing in BB's. That's what I did and then the problem was gone. So you have to try using protoc to generate some source code files in order to really stumble on the problem. Apart from that everything works fine indeed. Meanwhile another protobuf-related problem showed up, perhaps someone can help: [100%] Building CXX object CMakeFiles/[CENSORED].pb.cc.o /tmp/ccKFaHTE.s: Assembler messages: /tmp/ccKFaHTE.s:16516: Error: opcode not supported on this processor:mips1 (mips1) `sync' make[5]: *** [CMakeFiles/[CENSORED].pb.cc.o] Error 1 Since the snapshot we used previously PKG_USE_MIPS16:=0 also got added, does that mean we should also use that on all packages that compile Protocol Buffer generated code and/or link with the PB library? Or is it necessary/possible to instruct the host protoc to generate source code for MIPS32? Does PB needs generating CPU-specific C/C++ (instrinsics?) or asm sections? (We do not need MIPS16 ATM, so any MIPS32 solution would do for us.) The target platform I'm using now is Ralink RT5350 , so mips24k , is that OK for you ? I currently develop for the ZyXEL NBG6716 (http://wiki.openwrt.org/toh/zyxel/zyxel_nbg6716) which is MIPS32 (MIPS74Kc). Would that happen to be backward compatible with yours? I don't really understand why you have such an error - it look like a compiler error rather than a protobuf error. Indeed, but I could upgrade many packages from our pre-BB snapshot to the BB release without changing a single compiler flag or source code line WRT MIPS16. Then today I just had a problem while compiling the 1st PB-generated source code file... Just saying! ;) Anyway I will try to force PKG_USE_MIPS16:=0 on related packages to see if it helps and report here. I have yet to build the package with a mips16 target. Anyway, the patch I used is joined to this mail - if it's OK with you I'll resend the patch with an official pull-request header. Sorry, the patch as it stands still would not solve our problem. Reverting the non-version related changes compared to pre-BBfinal pre-Git revisions would, I think (I can test that next Friday at the soonest). I would have no objections to 2.6.1 if it also works for us too (I can test that at the same time). ___ 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] Frequent adsl disconnections with BTHOMEHUBV2B (lantiq xway danube)
Hi, On 15/11/2014 10:40, Jaime T wrote: Hi all. I'm running barrier breaker (r42625) on a BTHOMEHUBV2B and it's great apart from frequent adsl disconnections (approx 40 per day). My adsl-type is POTS so the relevant part of /etc/config/network is: config adsl 'dsl' option annex 'a2p' option firmware '/lib/firmware/adsl.bin' Each disconnection puts approximately the following into the syslog: Fri Nov 14 09:33:41 2014 daemon.info pppd[1218]: No response to 5 echo-requests I think I saw something similar when I was using an ADSL connection. When the connection was under full load (I don't remember whether it was upstream, downstream or both) the LCP echo requests that PPPD does seem to get dropped somewhere in the ADSL infrastructure. The link is however working fine passing real traffic. You can test this fairly easily by generating a lot of traffic that lasts over 5 seconds and it will cause the connection to drop. Then try increasing the lcp-echo-failure value in /etc/ppp/options and observing whether the download continues after 5 seconds. Gentoo have a patch that adds a lcp-echo-adaptive option to pppd. This treats traffic receipt as equivalent to receiving an lcp echo-reply. http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/src/patchsets/ppp/2.4.5/34_all_lcp-echo-adaptive.patch I did very briefly test with that patch and it seemed to work but I moved onto another connection before I'd convinced myself that it really was appropriate. Regards Richard Fri Nov 14 09:33:41 2014 daemon.notice pppd[1218]: Serial link appears to be disconnected. Fri Nov 14 09:33:41 2014 daemon.info pppd[1218]: Connect time 28.9 minutes. Fri Nov 14 09:33:41 2014 daemon.info pppd[1218]: Sent 554487 bytes, received 6119357 bytes. Fri Nov 14 09:33:41 2014 daemon.notice netifd: Network device 'pppoa-wan' link is down Fri Nov 14 09:33:41 2014 daemon.notice netifd: Interface 'wan' has lost the connection Fri Nov 14 09:33:47 2014 daemon.notice pppd[1218]: Connection terminated. Fri Nov 14 09:33:47 2014 daemon.notice pppd[1218]: Modem hangup Fri Nov 14 09:33:58 2014 kern.warn kernel: [ 1832.784000] leave showtime Fri Nov 14 09:33:59 2014 daemon.info pppd[1218]: Terminating on signal 15 Fri Nov 14 09:33:59 2014 daemon.info pppd[1218]: Exit. Fri Nov 14 09:33:59 2014 daemon.notice netifd: Interface 'wan' is now down Fri Nov 14 09:34:27 2014 kern.err kernel: [ 1861.796000] [DSL_BSP_Showtime 894]: Datarate US intl = 924903, fast = 0 Fri Nov 14 09:34:27 2014 kern.warn kernel: [ 1861.80] enter showtime, cell rate: 0 - 2181, 1 - 2181, xdata addr: 0x82b0 Fri Nov 14 09:34:29 2014 daemon.notice netifd: Interface 'wan' is setting up now My line stats are: # /etc/init.d/dsl_control status Chipset:Ifx-Danube 1.3 Line State: UP [0x801: showtime_tc_sync] Data Rate: 7.040 Mb/s / 924 Kb/s Line Attenuation: 37.4dB / 21.2dB Noise Margin: 7.1dB / 10.0dB Line Uptime:25m 39s The disconnections happen more frequently at night time. I have several of these boxes, and they all exhibit the same behaviour so I do not believe that it is a hardware problem specific to 1 router. I also have the original sky-supplied router which does not suffer from these disconnections. The dsl connection appears to be a bit of a black-box - I can find very little documentation discussing it, although 1 or 2 people have mentioned XTU bits, which I don't understand. Is there anything that I can modify to try to stop these disconnections from happening? Would lowering the connection speed help, and if so, can this be done? All info/suggestions would be gratefully received. With kind regards, Jaime ___ 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] lantiq usb - isochronous transfers
Hi Tobias, Thank you for reporting on your investigations. I have been comparing the AA and BB versions of ifx-hcd, having completely failed to notice that AA actually uses dwc-usb. Silly me! I am intrigued though that ifx-hcd 3.2 does compile for you with isochronous transfers enabled. I get the errors below. Would porting dwc-usb from AA be easier than using dwc2? Presumably it was replaced with ifx-hcd for a reason. Ben mips-openwrt-linux-uclibc-gcc -Wp,-MD,/home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc +dsp_uClibc-0.9.33.2/linux-lantiq_xway/ltq-hcd-danube/.ifxhcd_intr.o.d -nostdinc -isystem /home/ben/openwrt/barrier_breaker/staging_dir/toolchain-mips_34kc+dsp_gcc-4.8-linaro_uClibc-0.9.33.2/lib/gcc/mips-openwrt-linux-uclibc/4.8.3/include -I/home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc+dsp_uClibc-0.9.33.2/linux-lantiq_xway/linux-3.10.49/arch/mips/include -Iarch/mips/include/generated -Iinclude -I/home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc+dsp_uClibc-0.9.33.2/linux-lantiq_xway/linux-3.10.49/arch/mips/include/uapi -Iarch/mips/include/generated/uapi -I/home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc+dsp_uClibc-0.9.33.2/linux-lantiq_xway/linux-3.10.49/include/uapi -Iinclude/generated/uapi -include /home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc+dsp_uClibc-0.9.33.2/linux-lantiq_xway/linux-3.10.49/include/linux/kconfig.h -D__KERNEL__ -DVMLINUX_LOAD_ADDRESS=0x80002000 -DDATAOFFSET=0 -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno -format-security -fno-delete-null-pointer-checks -O2 -fno-reorder-blocks -fno-tree-ch -fno-caller-saves -mno-check-zero-division -mabi=32 -G 0 -mno-abicalls -fno-pic -pipe -mno-branch-likely -msoft-float -ffreestanding -march=mips32r2 -Wa,-mips32r2 -Wa,--trap -I/home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc+dsp_uClibc-0.9.33.2/linux-lantiq_xway/linux-3.10.49/arch/mips/include/asm/mach-lantiq -I/home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc+dsp_uClibc-0.9.33.2/linux-lantiq_xway/linux-3.10.49/arch/mips/include/asm/mach-lantiq/xway -I/home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc+dsp_uClibc-0.9.33.2/linux-lantiq_xway/linux-3.10.49/arch/mips/include/asm/mach-generic -Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable -fomit-frame-pointer -g -femit-struct-debug-baseonly -fno-var-tracking -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO -D__IS_DANUBE__ -D__EN_ISOC__ -D_ _UNALIGNED_BUF_ADJ__ -Dlinux -D__LINUX__ -D__IS_HOST__ -D__KERNEL__ -D__DYN_SOF_INTR__ -D__UEIP__ -D__DO_OC_INT__ -D__INNAKSTOP_BULK__ -D__INTRNAKRETRY__ -D__INTRINCRETRY__ -DMODULE -mno-long-calls -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(ifxhcd_intr) -DKBUILD_MODNAME=KBUILD_STR(ltq_hcd_danube) -c -o /home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc+dsp_uClibc-0.9.33.2/linux-lantiq_xway/ltq-hcd-danube/ifxhcd_intr.o /home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc+dsp_uClibc-0.9.33.2/linux-lantiq_xway/ltq-hcd-danube/ifxhcd_intr.c /home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc +dsp_uClibc-0.9.33.2/linux-lantiq_xway/ltq-hcd-danube/ifxhcd_intr.c: In function 'next_isoc_sub': /home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc +dsp_uClibc-0.9.33.2/linux-lantiq_xway/ltq-hcd-danube/ifxhcd_intr.c:572:4: error: implicit declaration of function 'init_hc' [-Werror=implicit-function-declaration] init_hc(urbd-epqh); ^ /home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc +dsp_uClibc-0.9.33.2/linux-lantiq_xway/ltq-hcd-danube/ifxhcd_intr.c: At top level: /home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc +dsp_uClibc-0.9.33.2/linux-lantiq_xway/ltq-hcd-danube/ifxhcd_intr.c:4035:6: warning: conflicting types for 'init_hc' [enabled by default] void init_hc(ifxhcd_epqh_t *_epqh) ^ /home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc +dsp_uClibc-0.9.33.2/linux-lantiq_xway/ltq-hcd-danube/ifxhcd_intr.c:4035:6: error: static declaration of 'init_hc' follows non-static declaration /home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc +dsp_uClibc-0.9.33.2/linux-lantiq_xway/ltq-hcd-danube/ifxhcd_intr.c:572:4: note: previous implicit declaration of 'init_hc' was here init_hc(urbd-epqh); ^ /home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc +dsp_uClibc-0.9.33.2/linux-lantiq_xway/ltq-hcd-danube/ifxhcd_intr.c: In function 'init_hc': /home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc +dsp_uClibc-0.9.33.2/linux-lantiq_xway/ltq-hcd-danube/ifxhcd_intr.c:4092:9: error: 'ifxhcd_epqh_t' has no member named 'isoc_frame_index' _epqh-isoc_frame_index=0; ^ /home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc +dsp_uClibc-0.9.33.2/linux-lantiq_xway/ltq-hcd-danube/ifxhcd_intr.c:4095:7: error: '_urb'
Re: [OpenWrt-Devel] [PATCH] iptables: correctly parse non-options arguments with musl libc
Hi Gianluca, thanks for your patch. However instead of adding wrappers to every single application I'd rather like us to add the optstring '-' extension to musl as a patch. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] kernel/modules: location of usb-common.ko changed
usb-common.ko was moved to drivers/usb/common starting from kernel 3.16 by upstream commit f4cbd33fd5f0587910fa9db403a1b42f1cabf820 Signed-off-by: Daniel Golle dan...@makrotopia.org --- package/kernel/linux/modules/usb.mk | 6 ++ 1 file changed, 6 insertions(+) diff --git a/package/kernel/linux/modules/usb.mk b/package/kernel/linux/modules/usb.mk index cc7092e..74de446 100644 --- a/package/kernel/linux/modules/usb.mk +++ b/package/kernel/linux/modules/usb.mk @@ -16,9 +16,15 @@ define KernelPackage/usb-core TITLE:=Support for USB DEPENDS:=@USB_SUPPORT KCONFIG:=CONFIG_USB CONFIG_XPS_USB_HCD_XILINX=n CONFIG_USB_FHCI_HCD=n +ifeq ($(strip $(call CompareKernelPatchVer,$(KERNEL_PATCHVER),ge,3.16.0)),1) + FILES:= \ + $(LINUX_DIR)/drivers/usb/core/usbcore.ko \ + $(LINUX_DIR)/drivers/usb/common/usb-common.ko +else FILES:= \ $(LINUX_DIR)/drivers/usb/core/usbcore.ko \ $(LINUX_DIR)/drivers/usb/usb-common.ko +endif AUTOLOAD:=$(call AutoLoad,20,usb-common usbcore,1) $(call AddDepends/nls) endef -- 2.1.3 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/2] kernel/modules: use crc32c_generic.ko instead of crc32c.ko
Starting from kernel version 3.15, the crc32c module was renamed to crc32c_generic. Signed-off-by: Daniel Golle dan...@makrotopia.org --- package/kernel/linux/modules/crypto.mk | 5 + 1 file changed, 5 insertions(+) diff --git a/package/kernel/linux/modules/crypto.mk b/package/kernel/linux/modules/crypto.mk index efa69b7..e0a2e27 100644 --- a/package/kernel/linux/modules/crypto.mk +++ b/package/kernel/linux/modules/crypto.mk @@ -299,8 +299,13 @@ define KernelPackage/crypto-crc32c TITLE:=CRC32c CRC module DEPENDS:=+kmod-crypto-hash KCONFIG:=CONFIG_CRYPTO_CRC32C +ifeq ($(strip $(call CompareKernelPatchVer,$(KERNEL_PATCHVER),ge,3.15.0)),1) + FILES:=$(LINUX_DIR)/crypto/crc32c_generic.ko + AUTOLOAD:=$(call AutoLoad,04,crc32c_generic,1) +else FILES:=$(LINUX_DIR)/crypto/crc32c.ko AUTOLOAD:=$(call AutoLoad,04,crc32c,1) +endif $(call AddDepends/crypto) endef -- 2.1.3 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Frequent adsl disconnections with BTHOMEHUBV2B (lantiq xway danube)
On 16 November 2014 23:47, Weedy weedy2...@gmail.com wrote: I had issues in the past with Bell sympatico stingers (made by Ikanos). They had firmware bugs verified by both Bell and Ikanos with anything that didn't run a broadcom DSP. There was nothing I could do except find a decent bridge modem based on a broadcom chipset. Thank you for the info. If you don't mind me asking, did you find a decent bridge modem based on a broadcom chipset? I'm happy to buy something else if I can use it with the bt home hub. I've got a spare usb socket and several spare ethernet ports on the home hub if that helps. Jaime ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Frequent adsl disconnections with BTHOMEHUBV2B (lantiq xway danube)
On Nov 17, 2014 12:08 PM, Jaime T enopa...@gmail.com wrote: On 16 November 2014 23:47, Weedy weedy2...@gmail.com wrote: I had issues in the past with Bell sympatico stingers (made by Ikanos). They had firmware bugs verified by both Bell and Ikanos with anything that didn't run a broadcom DSP. There was nothing I could do except find a decent bridge modem based on a broadcom chipset. Thank you for the info. If you don't mind me asking, did you find a decent bridge modem based on a broadcom chipset? I'm happy to buy something else if I can use it with the bt home hub. I've got a spare usb socket and several spare ethernet ports on the home hub if that helps. Jaime I don't know if my annex is the same as yours. SpeedStream 4200, generic firmware SpeedTouch ST516, generic firmware (play around with versions) Now I have a SmartNG for VDSL ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Frequent adsl disconnections with BTHOMEHUBV2B (lantiq xway danube)
Richard Mortimer richm+open...@oldelvet.org.uk wrote: I think I saw something similar when I was using an ADSL connection. When the connection was under full load (I don't remember whether it was upstream, downstream or both) the LCP echo requests that PPPD does seem to get dropped somewhere in the ADSL infrastructure. The link is however working fine passing real traffic. Sounds like the something a proper BQL limit on the etherne/ATM part of the PPPoE coud fix. For PPPoE, traffic shapping should occur on the PPP interface and should probably run at no more than 99% of the real link capacity (if you can determine it...sigh), the LCP messages should bypass that part. DSL with the modem built-in ought to auto-adjust the bandwdth viaBQL perfectly... -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Frequent adsl disconnections with BTHOMEHUBV2B (lantiq xway danube)
Hi Jaime, maybe you should also look at the rror counters. Especially the CRC and HEC errors short before the connection drops might be interesting. Best Regards Sebastian On Nov 16, 2014, at 15:43 , Jaime T enopa...@gmail.com wrote: On 15 November 2014 20:46, Michael Richardson m...@sandelman.ca wrote: How do you know it's not the DSLAM being unstable? Erm... I don't? I'm not sure what that means. Is there some way that I can find out from just my end (the consumer end) of the connection? I've called my ISP regarding the disconnections, and their response is Put our (supported) router back on, and we'll monitor the situation - I do that, and obviously the problem then disappears. I put my Openwrt'd BTHOMEHUBV2B, and the problem starts again. Rinse, repeat... ___ 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] Frequent adsl disconnections with BTHOMEHUBV2B (lantiq xway danube)
Hi Richard, hi Jaime On Nov 17, 2014, at 12:33 , Richard Mortimer richm+open...@oldelvet.org.uk wrote: Hi, On 15/11/2014 10:40, Jaime T wrote: Hi all. I'm running barrier breaker (r42625) on a BTHOMEHUBV2B and it's great apart from frequent adsl disconnections (approx 40 per day). My adsl-type is POTS so the relevant part of /etc/config/network is: config adsl 'dsl' option annex 'a2p' option firmware '/lib/firmware/adsl.bin' Each disconnection puts approximately the following into the syslog: Fri Nov 14 09:33:41 2014 daemon.info pppd[1218]: No response to 5 echo-requests I think I saw something similar when I was using an ADSL connection. When the connection was under full load (I don't remember whether it was upstream, downstream or both) the LCP echo requests that PPPD does seem to get dropped somewhere in the ADSL infrastructure. The link is however working fine passing real traffic. You can test this fairly easily by generating a lot of traffic that lasts over 5 seconds and it will cause the connection to drop. Then try increasing the lcp-echo-failure value in /etc/ppp/options and observing whether the download continues after 5 seconds. After changing the pop values have a look at the output of “ps w” on the router, when I tried to p;ay with these from the luci GUI I noticed that pppd was called with lcp-echo-failure 5 while the GUI reported 0 (meaning unlimited), so something might be off in parsing/passing the arguments from the GUI. (Then again with my testing I nave managed to get pop session timeout even though packet captures indicated that under load some lcl echo requests went missing…) Best Regards Sebastian Gentoo have a patch that adds a lcp-echo-adaptive option to pppd. This treats traffic receipt as equivalent to receiving an lcp echo-reply. http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/src/patchsets/ppp/2.4.5/34_all_lcp-echo-adaptive.patch I did very briefly test with that patch and it seemed to work but I moved onto another connection before I'd convinced myself that it really was appropriate. Regards Richard Fri Nov 14 09:33:41 2014 daemon.notice pppd[1218]: Serial link appears to be disconnected. Fri Nov 14 09:33:41 2014 daemon.info pppd[1218]: Connect time 28.9 minutes. Fri Nov 14 09:33:41 2014 daemon.info pppd[1218]: Sent 554487 bytes, received 6119357 bytes. Fri Nov 14 09:33:41 2014 daemon.notice netifd: Network device 'pppoa-wan' link is down Fri Nov 14 09:33:41 2014 daemon.notice netifd: Interface 'wan' has lost the connection Fri Nov 14 09:33:47 2014 daemon.notice pppd[1218]: Connection terminated. Fri Nov 14 09:33:47 2014 daemon.notice pppd[1218]: Modem hangup Fri Nov 14 09:33:58 2014 kern.warn kernel: [ 1832.784000] leave showtime Fri Nov 14 09:33:59 2014 daemon.info pppd[1218]: Terminating on signal 15 Fri Nov 14 09:33:59 2014 daemon.info pppd[1218]: Exit. Fri Nov 14 09:33:59 2014 daemon.notice netifd: Interface 'wan' is now down Fri Nov 14 09:34:27 2014 kern.err kernel: [ 1861.796000] [DSL_BSP_Showtime 894]: Datarate US intl = 924903, fast = 0 Fri Nov 14 09:34:27 2014 kern.warn kernel: [ 1861.80] enter showtime, cell rate: 0 - 2181, 1 - 2181, xdata addr: 0x82b0 Fri Nov 14 09:34:29 2014 daemon.notice netifd: Interface 'wan' is setting up now My line stats are: # /etc/init.d/dsl_control status Chipset:Ifx-Danube 1.3 Line State: UP [0x801: showtime_tc_sync] Data Rate: 7.040 Mb/s / 924 Kb/s Line Attenuation: 37.4dB / 21.2dB Noise Margin: 7.1dB / 10.0dB Line Uptime:25m 39s The disconnections happen more frequently at night time. I have several of these boxes, and they all exhibit the same behaviour so I do not believe that it is a hardware problem specific to 1 router. I also have the original sky-supplied router which does not suffer from these disconnections. The dsl connection appears to be a bit of a black-box - I can find very little documentation discussing it, although 1 or 2 people have mentioned XTU bits, which I don't understand. Is there anything that I can modify to try to stop these disconnections from happening? Would lowering the connection speed help, and if so, can this be done? All info/suggestions would be gratefully received. With kind regards, Jaime ___ 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Frequent adsl disconnections with BTHOMEHUBV2B (lantiq xway danube)
Hi Michael, On Nov 17, 2014, at 18:39 , Michael Richardson m...@sandelman.ca wrote: Richard Mortimer richm+open...@oldelvet.org.uk wrote: I think I saw something similar when I was using an ADSL connection. When the connection was under full load (I don't remember whether it was upstream, downstream or both) the LCP echo requests that PPPD does seem to get dropped somewhere in the ADSL infrastructure. The link is however working fine passing real traffic. Sounds like the something a proper BQL limit on the etherne/ATM part of the PPPoE coud fix. For PPPoE, traffic shapping should occur on the PPP interface Note SQM does not care too much where you put the shaper,but if you shape one the pppoe device the pop maintenance packets are never seen by SQM so they will not be dropped. Shaping on the raw ATM device (in your case) should also work (never tested this myself as I have no open dsl-router), but almost all packets will end up in the default queue (I think) as the packet classification can not see through the pop encapsulation. Also if you want to go that route you shold make sure the PPP maintenance packets get their own highest priority queue… (as dropping enough of those will most likely drop your connection, luckily they do not cost a lot of bandwidth...) and should probably run at no more than 99% of the real link capacity (if you can determine it...sigh), In my limited experience the link speed as reported by the modem was always the correct brute link speed that SQM’s link layer adjustments could work with, so maybe just taking the values the modem part of your router reports and subtract say 3% on egress and 10% on ingress should be a decent starting point. the LCP messages should bypass that part. Unless you shape on the ATM device ;) DSL with the modem built-in ought to auto-adjust the bandwdth viaBQL perfectly… For egress/upstream (I really hope we will get something like that in the future); bit for ingress/downlink you still need a properly configured shaper until the DSLAMs/MSANs/BRASs learn BQL fq_codel (which might take a while) Best Regards Sebastian -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails [ ___ 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] lantiq usb - isochronous transfers
Hi Ben, of course I used your fixes to compile the code! Maybe you would be more lucky with the AA's dwc-usb module and should give it a try? Actually I'm not very experienced with kernel hacking so I can not really give you a qualified hint. Probably I will also try to use dwc-usb one with my device as this one seems to be the most promising one. Tobias Am Montag, den 17.11.2014, 12:58 +0100 schrieb Ben Mulvihill: Hi Tobias, Thank you for reporting on your investigations. I have been comparing the AA and BB versions of ifx-hcd, having completely failed to notice that AA actually uses dwc-usb. Silly me! I am intrigued though that ifx-hcd 3.2 does compile for you with isochronous transfers enabled. I get the errors below. Would porting dwc-usb from AA be easier than using dwc2? Presumably it was replaced with ifx-hcd for a reason. Ben mips-openwrt-linux-uclibc-gcc -Wp,-MD,/home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc +dsp_uClibc-0.9.33.2/linux-lantiq_xway/ltq-hcd-danube/.ifxhcd_intr.o.d -nostdinc -isystem /home/ben/openwrt/barrier_breaker/staging_dir/toolchain-mips_34kc+dsp_gcc-4.8-linaro_uClibc-0.9.33.2/lib/gcc/mips-openwrt-linux-uclibc/4.8.3/include -I/home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc+dsp_uClibc-0.9.33.2/linux-lantiq_xway/linux-3.10.49/arch/mips/include -Iarch/mips/include/generated -Iinclude -I/home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc+dsp_uClibc-0.9.33.2/linux-lantiq_xway/linux-3.10.49/arch/mips/include/uapi -Iarch/mips/include/generated/uapi -I/home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc+dsp_uClibc-0.9.33.2/linux-lantiq_xway/linux-3.10.49/include/uapi -Iinclude/generated/uapi -include /home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc+dsp_uClibc-0.9.33.2/linux-lantiq_xway/linux-3.10.49/include/linux/kconfig.h -D__KERNEL__ -DVMLINUX_LOAD_ADDRESS=0x80002000 -DDATAOFFSET=0 -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -W no -format-security -fno-delete-null-pointer-checks -O2 -fno-reorder-blocks -fno-tree-ch -fno-caller-saves -mno-check-zero-division -mabi=32 -G 0 -mno-abicalls -fno-pic -pipe -mno-branch-likely -msoft-float -ffreestanding -march=mips32r2 -Wa,-mips32r2 -Wa,--trap -I/home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc+dsp_uClibc-0.9.33.2/linux-lantiq_xway/linux-3.10.49/arch/mips/include/asm/mach-lantiq -I/home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc+dsp_uClibc-0.9.33.2/linux-lantiq_xway/linux-3.10.49/arch/mips/include/asm/mach-lantiq/xway -I/home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc+dsp_uClibc-0.9.33.2/linux-lantiq_xway/linux-3.10.49/arch/mips/include/asm/mach-generic -Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable -fomit-frame-pointer -g -femit-struct-debug-baseonly -fno-var-tracking -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO -D__IS_DANUBE__ -D__EN_ISOC__ - D_ _UNALIGNED_BUF_ADJ__ -Dlinux -D__LINUX__ -D__IS_HOST__ -D__KERNEL__ -D__DYN_SOF_INTR__ -D__UEIP__ -D__DO_OC_INT__ -D__INNAKSTOP_BULK__ -D__INTRNAKRETRY__ -D__INTRINCRETRY__ -DMODULE -mno-long-calls -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(ifxhcd_intr) -DKBUILD_MODNAME=KBUILD_STR(ltq_hcd_danube) -c -o /home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc+dsp_uClibc-0.9.33.2/linux-lantiq_xway/ltq-hcd-danube/ifxhcd_intr.o /home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc+dsp_uClibc-0.9.33.2/linux-lantiq_xway/ltq-hcd-danube/ifxhcd_intr.c /home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc +dsp_uClibc-0.9.33.2/linux-lantiq_xway/ltq-hcd-danube/ifxhcd_intr.c: In function 'next_isoc_sub': /home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc +dsp_uClibc-0.9.33.2/linux-lantiq_xway/ltq-hcd-danube/ifxhcd_intr.c:572:4: error: implicit declaration of function 'init_hc' [-Werror=implicit-function-declaration] init_hc(urbd-epqh); ^ /home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc +dsp_uClibc-0.9.33.2/linux-lantiq_xway/ltq-hcd-danube/ifxhcd_intr.c: At top level: /home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc +dsp_uClibc-0.9.33.2/linux-lantiq_xway/ltq-hcd-danube/ifxhcd_intr.c:4035:6: warning: conflicting types for 'init_hc' [enabled by default] void init_hc(ifxhcd_epqh_t *_epqh) ^ /home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc +dsp_uClibc-0.9.33.2/linux-lantiq_xway/ltq-hcd-danube/ifxhcd_intr.c:4035:6: error: static declaration of 'init_hc' follows non-static declaration /home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc +dsp_uClibc-0.9.33.2/linux-lantiq_xway/ltq-hcd-danube/ifxhcd_intr.c:572:4: note: previous implicit declaration of 'init_hc' was here init_hc(urbd-epqh); ^
Re: [OpenWrt-Devel] [PATCH] comgt: add ncm proto support
Hi Sami, Having an E3276 would be nice for developing this further. I have already a patch for comgt ready which allows it to be used with non-TTY device nodes (i.e., /dev/cdc-wdmX), I just need to test it before sending. Then I could dig further into netifd integration. Matti___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] how can i *deselect* building rrdtool?
i am out of ideas here ... i'm doing a full build for my archer c7 router and, when a package fails to build, i simply deselect that package via make menuconfig (and, of course, any other packages that select it) and restart the build. at the moment, given that rrdtool failed to build, i deselected it, but the build again failed trying to build rrdtool. i've verified through make menuconfig that it is indeed deselected. here are the lines in .config related to rrdtool: $ grep rrdtool .config CONFIG_PACKAGE_lighttpd-mod-rrdtool=m CONFIG_PACKAGE_collectd-mod-rrdtool=m # CONFIG_PACKAGE_rrdtool is not set # CONFIG_PACKAGE_rrdtool1 is not set $ i'm baffled ... given that rrdtool is clearly not selected for building, why does a simple make insist on trying to build it? what triviality am i overlooking? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] how can i *deselect* building rrdtool?
you can also try a grep through all Makefile(s) to see which package has rrdtool in it's DEPENDS section if some package has it in it's DEPENDS, the build system will pull it; one easy way to check that some package depends on rrdtool is to run make defconfig and you'll eventually see that package selected; did you try a clean build ? when I'm puzzled about build errors, I clean the dir, or even git clone a fresh one; you could try to clean everything except the openwrt/dl folder and start fresh On Mon, Nov 17, 2014 at 9:16 PM, Robert P. J. Day rpj...@crashcourse.ca wrote: i am out of ideas here ... i'm doing a full build for my archer c7 router and, when a package fails to build, i simply deselect that package via make menuconfig (and, of course, any other packages that select it) and restart the build. at the moment, given that rrdtool failed to build, i deselected it, but the build again failed trying to build rrdtool. i've verified through make menuconfig that it is indeed deselected. here are the lines in .config related to rrdtool: $ grep rrdtool .config CONFIG_PACKAGE_lighttpd-mod-rrdtool=m CONFIG_PACKAGE_collectd-mod-rrdtool=m # CONFIG_PACKAGE_rrdtool is not set # CONFIG_PACKAGE_rrdtool1 is not set $ i'm baffled ... given that rrdtool is clearly not selected for building, why does a simple make insist on trying to build it? what triviality am i overlooking? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ 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] how can i *deselect* building rrdtool?
On Mon, 17 Nov 2014, Alexandru Ardelean wrote: you can also try a grep through all Makefile(s) to see which package has rrdtool in it's DEPENDS section if some package has it in it's DEPENDS, the build system will pull it; already tried that and saw nothing that would be causing this. one easy way to check that some package depends on rrdtool is to run make defconfig and you'll eventually see that package selected; did you try a clean build ? when I'm puzzled about build errors, I clean the dir, or even git clone a fresh one; you could try to clean everything except the openwrt/dl folder and start fresh that was my last resort, but i wanted to see if there was something else i could try first. i'm willing to believe that there is some leftover remnant from another package that is causing this, but it would be nice to verify that this *shouldn't* be happening. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] kmod-usb-core install error on 14.07
I have the Barrier Breaker 14.07 Mikrotik build installed on a Mikrotik RB2011. I want to use the USB port for a printer so I started by trying to install kmod-usb-printer and got the following error:- root@OpenWrt:~# opkg install kmod-usb-printer Installing kmod-usb-printer (3.10.49-1) to root... Downloading http://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/mikrotik/packages/base/kmod-usb-printer_3.10.49-1_ar71xx.ipk. Installing kmod-usb-core (3.10.49-1) to root... Downloading http://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/mikrotik/packages/base/kmod-usb-core_3.10.49-1_ar71xx.ipk. Installing kmod-nls-base (3.10.49-1) to root... Downloading http://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/mikrotik/packages/base/kmod-nls-base_3.10.49-1_ar71xx.ipk. Configuring kmod-nls-base. Configuring kmod-usb-core. kmod: failed to insert /lib/modules/3.10.49/usbcore.ko Configuring kmod-usb-printer. root@OpenWrt:~# It would appear that this is simply because the file is there already but I guess it should be fixed. Where/how do I find out if the problem has been reported already? -- Chris Green ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq usb - isochronous transfers
Aha! That explains why it compiles, and probably also explains why it doesn't actually work ;-) . I simply corrected a few obvious errors, without trying to understand the code properly. The chances of that being enough to fix it were bound to be pretty small. I'd like to try dwc2 as John suggests and maybe AA dwc-usb as well, but it might be a while because I don't know much about USB and don't have a lot of time at the moment either. I'll post again if I do get anywhere and hope to hear from you if you do too. Ben On Mon, 2014-11-17 at 19:58 +0100, pasdVn wrote: Hi Ben, of course I used your fixes to compile the code! Maybe you would be more lucky with the AA's dwc-usb module and should give it a try? Actually I'm not very experienced with kernel hacking so I can not really give you a qualified hint. Probably I will also try to use dwc-usb one with my device as this one seems to be the most promising one. Tobias Am Montag, den 17.11.2014, 12:58 +0100 schrieb Ben Mulvihill: Hi Tobias, Thank you for reporting on your investigations. I have been comparing the AA and BB versions of ifx-hcd, having completely failed to notice that AA actually uses dwc-usb. Silly me! I am intrigued though that ifx-hcd 3.2 does compile for you with isochronous transfers enabled. I get the errors below. Would porting dwc-usb from AA be easier than using dwc2? Presumably it was replaced with ifx-hcd for a reason. Ben mips-openwrt-linux-uclibc-gcc -Wp,-MD,/home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc +dsp_uClibc-0.9.33.2/linux-lantiq_xway/ltq-hcd-danube/.ifxhcd_intr.o.d -nostdinc -isystem /home/ben/openwrt/barrier_breaker/staging_dir/toolchain-mips_34kc+dsp_gcc-4.8-linaro_uClibc-0.9.33.2/lib/gcc/mips-openwrt-linux-uclibc/4.8.3/include -I/home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc+dsp_uClibc-0.9.33.2/linux-lantiq_xway/linux-3.10.49/arch/mips/include -Iarch/mips/include/generated -Iinclude -I/home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc+dsp_uClibc-0.9.33.2/linux-lantiq_xway/linux-3.10.49/arch/mips/include/uapi -Iarch/mips/include/generated/uapi -I/home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc+dsp_uClibc-0.9.33.2/linux-lantiq_xway/linux-3.10.49/include/uapi -Iinclude/generated/uapi -include /home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc+dsp_uClibc-0.9.33.2/linux-lantiq_xway/linux-3.10.49/include/linux/kconfig.h -D__KERNEL__ -DVMLINUX_LOAD_ADDRESS=0x80002000 -DDATAOFFSET=0 -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno -format-security -fno-delete-null-pointer-checks -O2 -fno-reorder-blocks -fno-tree-ch -fno-caller-saves -mno-check-zero-division -mabi=32 -G 0 -mno-abicalls -fno-pic -pipe -mno-branch-likely -msoft-float -ffreestanding -march=mips32r2 -Wa,-mips32r2 -Wa,--trap -I/home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc+dsp_uClibc-0.9.33.2/linux-lantiq_xway/linux-3.10.49/arch/mips/include/asm/mach-lantiq -I/home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc+dsp_uClibc-0.9.33.2/linux-lantiq_xway/linux-3.10.49/arch/mips/include/asm/mach-lantiq/xway -I/home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc+dsp_uClibc-0.9.33.2/linux-lantiq_xway/linux-3.10.49/arch/mips/include/asm/mach-generic -Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable -fomit-frame-pointer -g -femit-struct-debug-baseonly -fno-var-tracking -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO -D__IS_DANUBE__ -D__EN_ISOC__ -D_ _UNALIGNED_BUF_ADJ__ -Dlinux -D__LINUX__ -D__IS_HOST__ -D__KERNEL__ -D__DYN_SOF_INTR__ -D__UEIP__ -D__DO_OC_INT__ -D__INNAKSTOP_BULK__ -D__INTRNAKRETRY__ -D__INTRINCRETRY__ -DMODULE -mno-long-calls -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(ifxhcd_intr) -DKBUILD_MODNAME=KBUILD_STR(ltq_hcd_danube) -c -o /home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc+dsp_uClibc-0.9.33.2/linux-lantiq_xway/ltq-hcd-danube/ifxhcd_intr.o /home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc+dsp_uClibc-0.9.33.2/linux-lantiq_xway/ltq-hcd-danube/ifxhcd_intr.c /home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc +dsp_uClibc-0.9.33.2/linux-lantiq_xway/ltq-hcd-danube/ifxhcd_intr.c: In function 'next_isoc_sub': /home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc +dsp_uClibc-0.9.33.2/linux-lantiq_xway/ltq-hcd-danube/ifxhcd_intr.c:572:4: error: implicit declaration of function 'init_hc' [-Werror=implicit-function-declaration] init_hc(urbd-epqh); ^ /home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc +dsp_uClibc-0.9.33.2/linux-lantiq_xway/ltq-hcd-danube/ifxhcd_intr.c: At top level: /home/ben/openwrt/barrier_breaker/build_dir/target-mips_34kc
Re: [OpenWrt-Devel] kmod-usb-core install error on 14.07
On Mon, Nov 17, 2014 at 09:23:36PM +, Chris Green wrote: I have the Barrier Breaker 14.07 Mikrotik build installed on a Mikrotik RB2011. I want to use the USB port for a printer so I started by trying to install kmod-usb-printer and got the following error:- root@OpenWrt:~# opkg install kmod-usb-printer Installing kmod-usb-printer (3.10.49-1) to root... Downloading http://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/mikrotik/packages/base/kmod-usb-printer_3.10.49-1_ar71xx.ipk. Installing kmod-usb-core (3.10.49-1) to root... Downloading http://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/mikrotik/packages/base/kmod-usb-core_3.10.49-1_ar71xx.ipk. Installing kmod-nls-base (3.10.49-1) to root... Downloading http://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/mikrotik/packages/base/kmod-nls-base_3.10.49-1_ar71xx.ipk. Configuring kmod-nls-base. Configuring kmod-usb-core. kmod: failed to insert /lib/modules/3.10.49/usbcore.ko Configuring kmod-usb-printer. root@OpenWrt:~# It would appear that this is simply because the file is there already but I guess it should be fixed. Where/how do I find out if the problem has been reported already? However I have another error after installing the USB stuff, at the end of dmesg:- [ 6783.63] usbcore: Unknown symbol utf16s_to_utf8s (err 0) -- Chris Green ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] how can i *deselect* building rrdtool?
$ grep rrdtool .config CONFIG_PACKAGE_lighttpd-mod-rrdtool=m CONFIG_PACKAGE_collectd-mod-rrdtool=m # CONFIG_PACKAGE_rrdtool is not set # CONFIG_PACKAGE_rrdtool1 is not set $ i'm baffled ... given that rrdtool is clearly not selected for building, why does a simple make insist on trying to build it? what triviality am i overlooking? collectd-mod-rrdtool is =m in your .config and gets built. And it needs rrdtool-1.0 as librrd1. You didn't grep .config for plain rrd... https://github.com/openwrt/packages/blob/master/utils/collectd/Makefile#L315 $(eval $(call BuildPlugin,rrdtool,RRDtool output,rrdtool,+PACKAGE_collectd-mod-rrdtool:librrd1)) https://github.com/openwrt/packages/blob/master/utils/collectd/Makefile#L225 # exception: mod-rrdtool needs rrdtool-1.0.x ifneq ($(CONFIG_PACKAGE_collectd-mod-rrdtool),) CONFIGURE_ARGS+= --with-librrd=$(STAGING_DIR)/usr/lib/rrdtool-1.0 endif https://github.com/openwrt/packages/blob/master/utils/rrdtool1/Makefile#L47 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] how can i *deselect* building rrdtool?
On Mon, 17 Nov 2014, Hannu Nyman wrote: $ grep rrdtool .config CONFIG_PACKAGE_lighttpd-mod-rrdtool=m CONFIG_PACKAGE_collectd-mod-rrdtool=m # CONFIG_PACKAGE_rrdtool is not set # CONFIG_PACKAGE_rrdtool1 is not set $ i'm baffled ... given that rrdtool is clearly not selected for building, why does a simple make insist on trying to build it? what triviality am i overlooking? collectd-mod-rrdtool is =m in your .config and gets built. And it needs rrdtool-1.0 as librrd1. You didn't grep .config for plain rrd... https://github.com/openwrt/packages/blob/master/utils/collectd/Makefile#L315 $(eval $(call BuildPlugin,rrdtool,RRDtool output,rrdtool,+PACKAGE_collectd-mod-rrdtool:librrd1)) https://github.com/openwrt/packages/blob/master/utils/collectd/Makefile#L225 # exception: mod-rrdtool needs rrdtool-1.0.x ifneq ($(CONFIG_PACKAGE_collectd-mod-rrdtool),) CONFIGURE_ARGS+= --with-librrd=$(STAGING_DIR)/usr/lib/rrdtool-1.0 endif https://github.com/openwrt/packages/blob/master/utils/rrdtool1/Makefile#L47 ah, thank you ... it's going to take me a few minutes to digest that one, i thought just looking at dependencies via make menuconfig was sufficient. apparently, it's much more involved. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Frequent adsl disconnections with BTHOMEHUBV2B (lantiq xway danube)
Sebastian Moeller moell...@gmx.de wrote: Sounds like the something a proper BQL limit on the etherne/ATM part of the PPPoE coud fix. For PPPoE, traffic shapping should occur on the PPP interface Note SQM does not care too much where you put the shaper,but if you shape one the pppoe device the pop maintenance packets are never seen by SQM so they will not be dropped. Shaping on the raw ATM device (in your case) should also work (never tested this myself as I have no open dsl-router), but almost all packets will end up in the default queue (I think) as the packet classification can not see through the pop My point was that BQL running on the raw interface would see the LCP packets, and therefore would take them into account. I would except to do the various SQM on the ppp interface, with the BQL on the underlying interface (for the PPPoE case) providing the push back so that queing works. DSL with the modem built-in ought to auto-adjust the bandwdth viaBQL perfectly… For egress/upstream (I really hope we will get something like that in the future); bit for ingress/downlink you still need a properly configured shaper until the DSLAMs/MSANs/BRASs learn BQL fq_codel (which might take a while) Yes, I was ignoring that part. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] how can i *deselect* building rrdtool?
Some observations on things that build when you think they shouldn’t... This is something I noticed a while ago and can construct an example, but have been unable to understand why things work this way – bug or feature? Let's say you have a package - call it utility xyzzy. In the Makefile, you declare 2 additional packages: lib-x and lib-y along with the xyzzy utility. lib-x is dependent on libfoo and libbar. lib-y is only dependent on libfoo only. The xyzzy utility is dependent on lib-y and NOT lib-x. However, if I select xyzzy and hence lib-y is selected by default, when you build, libbar will be built (but not installed) even though it not selected in the build config as you have observed. /ted On Mon, Nov 17, 2014 at 9:16 PM, Robert P. J. Day rpj...@crashcourse.ca wrote: i am out of ideas here ... i'm doing a full build for my archer c7 router and, when a package fails to build, i simply deselect that package via make menuconfig (and, of course, any other packages that select it) and restart the build. at the moment, given that rrdtool failed to build, i deselected it, but the build again failed trying to build rrdtool. i've verified through make menuconfig that it is indeed deselected. here are the lines in .config related to rrdtool: $ grep rrdtool .config CONFIG_PACKAGE_lighttpd-mod-rrdtool=m CONFIG_PACKAGE_collectd-mod-rrdtool=m # CONFIG_PACKAGE_rrdtool is not set # CONFIG_PACKAGE_rrdtool1 is not set $ i'm baffled ... given that rrdtool is clearly not selected for building, why does a simple make insist on trying to build it? what triviality am i overlooking? rday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] how can i *deselect* building rrdtool?
On Mon, 17 Nov 2014, Ted Hess wrote: Some observations on things that build when you think they shouldn’t... This is something I noticed a while ago and can construct an example, but have been unable to understand why things work this way – bug or feature? Let's say you have a package - call it utility xyzzy. In the Makefile, you declare 2 additional packages: lib-x and lib-y along with the xyzzy utility. lib-x is dependent on libfoo and libbar. lib-y is only dependent on libfoo only. The xyzzy utility is dependent on lib-y and NOT lib-x. However, if I select xyzzy and hence lib-y is selected by default, when you build, libbar will be built (but not installed) even though it not selected in the build config as you have observed. i'm sure my followup to this is much simpler, but it's sometimes a bit of an ordeal to deselect a single package given the number of Selects throughout the build structure. in my case, i wanted to simply deselect rrdtool, and ended up having to deselect every rrd-related package i could find, having to backtrace through the recipes to see what selected what. i suspect it will get easier as i get more used to the layout of the build structure. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
