[OpenWrt-Devel] [PATCH] hostapd/netifd: fix missing htmode for wpa_supplicant

[Arvid E. Picciani]

the variable is called htmode, not ht

Signed-off-by: Arvid E. Picciani 
---
 package/network/services/hostapd/files/netifd.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/network/services/hostapd/files/netifd.sh 
b/package/network/services/hostapd/files/netifd.sh

index 7cdcb52..c914795 100644
--- a/package/network/services/hostapd/files/netifd.sh
+++ b/package/network/services/hostapd/files/netifd.sh
@@ -575,7 +575,7 @@ wpa_supplicant_add_network() {
}

local ht_str
-   [ -n "$ht" ] && append network_data "htmode=$ht" "$N$T"
+   [ -n "$htmode" ] && append network_data "htmode=$htmode" "$N$T"

cat >> "$_config" 

Re: [OpenWrt-Devel] [PATCH] base-files: procd initscriptsrestartonreload

[Felix Fietkau]

On 2014-09-15 11:42, Tristan Plumb wrote:
> 
>> On 15/09/2014 10:36, Tristan Plumb wrote:
>>  which specific package is causing issue ?
>> >>> In my setup, I've noticed this with dnsmasq and babeld. That is,
>> >>> that I needed to restart and instead of reload to get things to
>> >>> take effect. Everything else I run is configured by command line
>> >>> arguments.
>> >> what do you want to do ? track a file and if changed trigger a reload ?
>> > Nope, I want /etc/init.d/foo reload to work as expected.
> 
>> vagueness == no fix
> 
>> if you wont this fixed you need to be more elaborate than "as expected"
> 
> The current behavior with a procd service is that unless the service has
> declared its own routine /etc/init.d/foo reload will restart the service
> if the command line changes, but otherwise take no action to alert the
> service of new configuration files. The expected behavior is that reload
> will reload changed configuration by whatever means necessary, including
> restarting the service.
> 
> Which is what /etc/init.d/foo help claims it does.
> 
> 
> Lacking information about how the service is configured, it must
> restart.
For procd based services, the assumption should be that all information
is there to decide whether a service should be restarted on reload.
If a service does not get enough information to handle reload properly,
that's a bug which should not be worked around by using an unconditional
restart on reload.

> Knowing the configuration files, it must restart if they, the command
> line arguments, or the enviroment have changed, but not otherwise.
> 
> Knowing that the service takes SIGHUP to reread configuration files, it
> must restart if the command line arguments, or environment, have changed,
> but only be sent a signal otherwise.
That is currently not implemented within procd, but should be easy to add.

> Knowing that the service manages this itself nothing need happen.
> 
> And there are mixtures of the four, some services manage data one way and
> connections another. It might be useful to have one name for data and
> another for connections, but that's not what we've inherited, merely
> reload means to reload the configuration.
What do you mean by "connections"?

By the way, you mentioned in an earlier email that procd_set_param file
did not work for you to restart your service when a config file changes.
Can you produce a test case for that? I just tested it myself on a
simple service and it worked just fine.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] hostapd/netifd: fix missing htmode for wpa_supplicant

[Felix Fietkau]

On 2014-09-16 11:25, Arvid E. Picciani wrote:
> the variable is called htmode, not ht
> 
> Signed-off-by: Arvid E. Picciani 
I agree that there is a bug there, but simply passing htmode as-is to
wpa_supplicant might make things worse, as wpa_supplicant only knows a
subset of the possible values of that configuration option.
wpa_supplicant only knows NOHT, HT20, HT40+ and HT40-, whereas htmode
can also contain HT40 (auto-detect + or -) or VHT*.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] hostapd/netifd: fix missing htmode for wpa_supplicant

[Arvid E. Picciani]

If phy htmode is set to HT* or VHT*, set wpa_supplicant to HT20.
Previously it wasnt set at all.

Signed-off-by: Arvid E. Picciani 
---
 package/network/services/hostapd/files/netifd.sh | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/package/network/services/hostapd/files/netifd.sh 
b/package/network/services/hostapd/files/netifd.sh

index 2b5bc06..311fa51 100644
--- a/package/network/services/hostapd/files/netifd.sh
+++ b/package/network/services/hostapd/files/netifd.sh
@@ -568,7 +568,11 @@ wpa_supplicant_add_network() {
}

local ht_str
-   [ -n "$ht" ] && append network_data "htmode=$ht" "$N$T"
+   case "$htmode" in
+   HT* | VHT*)
+   append network_data "htmode=HT20" "$N$T"
+   ;;
+   esac

cat >> "$_config" 

[OpenWrt-Devel] Missing mpc83xx in BB-RC3

[Claudio Thomas]

Hi,
I until now was still using the trunk for testing and working, but today
I the first time checked out the 14.07/openwrt.git at git.openwrt.git.
Is there a reason why MPC83xx is not included in BB-RC3?

Best regards,
Claudio
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] hostapd/netifd: fix missing htmode for wpa_supplicant

[Felix Fietkau]

On 2014-09-16 13:31, Arvid E. Picciani wrote:
> If phy htmode is set to HT* or VHT*, set wpa_supplicant to HT20.
> Previously it wasnt set at all.
> 
> Signed-off-by: Arvid E. Picciani 
Your patch seems to have been mangled by your email program and does not
apply. Please fix and resend.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] 4g NCM modem huawei e3276

[Sami Olmari]

Sent. The lady at postoffice told that should take 4 days to arrive, so
friday or monday :-)

I did include return envelope (not paid tough), but I still urge you to
keep it for possible future troubleshooting :-P

Also, if/when there is patches available, I'd be more than willing to test
the stuff to the extreme, before you return the dongle even with me
resisting ;)

Sami Olmari

On Sep 16, 2014 9:06 AM, "John Crispin"  wrote:
>
> that is very kind, however i do have ~30 different sticks here already :)
>
> i will send the stick back to you once it all works, it will just
> collect dust in my office
>
> Thanks,
> John
>
>
> On 15/09/2014 18:29, Sami Olmari wrote:
> >
> > The more I think about this, the more I am going to let you just keep
> > the stick... In the future when I complain about some bug you can
> > still test it ;) Lets consider it mine donation to OpenWrt, the thing
> > I need to get working anyways :-)
> >
> > Sami Olmari
> >
> > On Sep 15, 2014 6:15 PM, "John Crispin"  > > wrote:
> >
> > Hi,
> > please send it to ..
> >
> >
> >
> > once i have the dongle i will need less than 48 hours to test and
will
> > return the stick via registered post. i just want to spare having to
> > pay 100 euros to buy a stick, i already spent 350 euro last month
on a
> > ecm, mbim anf qmi modem :) ncm is the last protocol on my list, once
> > supported openwrt will be able to handle all of the 6 major 3g/4g
> > protocols.
> >
> > Thanks for your support :)
> > John
> >
> >
> >
> > On 15/09/2014 14:16, Sami Olmari wrote:
> > > Hmm, that could work, at least I do have old spare dongle to use
> > > with system in mean time :-) Tell me where I can send the thing
and
> > > I'll send the thing in a few days :-)
> > >
> > > Sami Olmari
> > >
> > > On Sep 15, 2014 3:11 PM, "John Crispin"  > 
> > > >> wrote:
> > >
> > > Hi,
> > >
> > > my version of the scripts is based on Oskari patches and fixes a
> > > lot of the "not perfect" stuff
> > >
> > > however i am sure it wont work out of the box as i blindly
> > > reworked large parts of the code.
> > >
> > > i can send it back to you in finland when i am done testing.
> > >
> > > John
> > >
> > > On 15/09/2014 13:53, Sami Olmari wrote:
> > >>
> > >> I have 2 such devices, I do use Oskari Rauta's scripts to run
> > >> it.. not perfect but works after manual labour... Maybe there
> > >> would be at least some ideas... So.. I can definately help with
> > >> testing! I have to think how I could donate one dongle to you...
> > >>
> > >> Sami Olmari
> > >>
> > >> On Sep 15, 2014 1:35 PM, "John Crispin"  > 
> > > >
> > >> 
> >  > >>
> > >> Hi,
> > >>
> > >> i would like to add 4g ncm support. there are a few version of
> > > a patc
> > >> floating around that don't make use of dynamic_interface yet.
> > >>
> > >> anyone around that wants to 1) donate a huawei e3276 2) has a
> > >> huawei e3276 and wants to help testing ?
> > >>
> > >> John ___
> > >> 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] [PATCH] base-files: procd initscriptsrestartonreload

[tristan]

Felix Fietkau wrote:
> ...
> By the way, you mentioned in an earlier email that procd_set_param file
> did not work for you to restart your service when a config file changes.
> Can you produce a test case for that? I just tested it myself on a
> simple service and it worked just fine.

So I just made a test service:

root@hg:~# cat /etc/openwrt_version 
r42538
root@hg:~# cat /etc/init.d/test 
#!/bin/sh /etc/rc.common

START=70
USE_PROCD=1

start_service() {
procd_open_instance
procd_set_param command /bin/sleep 1
procd_set_param file /tmp/test
procd_set_param respawn
procd_close_instance
}

root@hg:~# cat /tmp/test
hello
root@hg:~# /etc/init.d/test start
root@hg:~# pidof sleep
6958
root@hg:~# /etc/init.d/test reload
root@hg:~# pidof sleep
6958
root@hg:~# echo goodbye > /tmp/test
root@hg:~# pidof sleep
6958
root@hg:~# rm /tmp/test
root@hg:~# pidof sleep
6958
root@hg:~# echo hello > /tmp/test
root@hg:~# pidof sleep
6958
root@hg:~# /etc/init.d/test restart
root@hg:~# pidof sleep
6985

Which more or less bears out what I was seeing with dnsmasq.

Note, that adding:

reload_service() {
restart
}

didn't change anything, except that reload did restart the service.


> For procd based services, the assumption should be that all information
> is there to decide whether a service should be restarted on reload.
> If a service does not get enough information to handle reload properly,
> that's a bug which should not be worked around by using an unconditional
> restart on reload.

I suppose it is reasonable to make any of the reload methods the default,
and assume that the service will override the default if needed. I just
found the current default to be surprising, as it doesn't match other
handlers' defaults.

> > Knowing that the service manages this itself nothing need happen.
> > 
> > And there are mixtures of the four, some services manage data one way and
> > connections another. It might be useful to have one name for data and
> > another for connections, but that's not what we've inherited, merely
> > reload means to reload the configuration.

> What do you mean by "connections"?

"Connections" is probably too narrow a word, control is maybe better?

The properties of how the service interacts with the outside world. As
in, dnsmasq will reload hosts and ethers on SIGHUP, but will quickly
notice any change in it's upstream resolv.conf, yet won't change what
ports it listens to or the how it allocates addresses without a restart.

The general idea though is that reloading different parts of a services
configuration may use different means. I think there is some history of
using reload for one purpose and restart for another, but that's not born
out by procd's default either.

Tristan

-- 
All original matter is hereby placed immediately under the public domain.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] [PKG_NAME=ubox] [git://nbd.name/luci2/ubox.git] [FILE=logger.c] current OpenWrt trunc

[John Crispin]

thank you, merged in r42572


On 16/09/2014 10:53, Бельков Максим wrote:
> From: Belkov Max 
>
> When logread daemon send a syslog message to another host, time, severity
> and facility are cut off.
> The message contains only text.
> This path adds time, severity and facility in the message as described in
> the RFC 3164.
> Signed-off-by: Belkov Max 
> ---
> Patched one file: logread.c
> This patch been tested and work well.
>
> --- /home/max/openwrt/l/log/logread.c.old 2014-09-15
> 03:03:50.0 +0400
> +++ /home/max/openwrt/l/log/logread.c 2014-09-16 12:04:44.388950951 +0400
> @@ -135,9 +135,14 @@ static int log_notify(struct blob_attr *
>   if (log_type == LOG_NET) {
>   int err;
>  
> - *buf = '\0';
> - if (hostname)
> - snprintf(buf, sizeof(buf), "%s ", hostname);
> + snprintf(buf, sizeof(buf), "<%u>", p);
> + /* extract syslog time from "Wed Jun 30 21:49:08 1993" and
> obtain
> +   "Jun 30 21:49:08 " according RFC 3164 */
> + strncat(buf, c + 4, 16);
> + if (hostname) {
> + strncat(buf, hostname, sizeof(buf));
> + strncat(buf, " ", sizeof(buf));
> + }
>   if (log_prefix) {
>   strncat(buf, log_prefix, sizeof(buf));
>   strncat(buf, ": ", sizeof(buf));
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] 4g NCM modem huawei e3276

[John Crispin]

On 16/09/2014 14:12, Sami Olmari wrote:
>
> Sent. The lady at postoffice told that should take 4 days to arrive,
> so friday or monday :-)
>
> I did include return envelope (not paid tough), but I still urge you
> to keep it for possible future troubleshooting :-P
>
> Also, if/when there is patches available, I'd be more than willing to
> test the stuff to the extreme, before you return the dongle even with
> me resisting ;)
>


awesome ! i will send you the patch for testing prior to merging it in
openwrt :)



> Sami Olmari
>
> On Sep 16, 2014 9:06 AM, "John Crispin"  > wrote:
> >
> > that is very kind, however i do have ~30 different sticks here
> already :)
> >
> > i will send the stick back to you once it all works, it will just
> > collect dust in my office
> >
> > Thanks,
> > John
> >
> >
> > On 15/09/2014 18:29, Sami Olmari wrote:
> > >
> > > The more I think about this, the more I am going to let you just keep
> > > the stick... In the future when I complain about some bug you can
> > > still test it ;) Lets consider it mine donation to OpenWrt, the thing
> > > I need to get working anyways :-)
> > >
> > > Sami Olmari
> > >
> > > On Sep 15, 2014 6:15 PM, "John Crispin"  
> > > >> wrote:
> > >
> > > Hi,
> > > please send it to ..
> > >
> > >
> > >
> > > once i have the dongle i will need less than 48 hours to test
> and will
> > > return the stick via registered post. i just want to spare
> having to
> > > pay 100 euros to buy a stick, i already spent 350 euro last
> month on a
> > > ecm, mbim anf qmi modem :) ncm is the last protocol on my
> list, once
> > > supported openwrt will be able to handle all of the 6 major 3g/4g
> > > protocols.
> > >
> > > Thanks for your support :)
> > > John
> > >
> > >
> > >
> > > On 15/09/2014 14:16, Sami Olmari wrote:
> > > > Hmm, that could work, at least I do have old spare dongle to use
> > > > with system in mean time :-) Tell me where I can send the
> thing and
> > > > I'll send the thing in a few days :-)
> > > >
> > > > Sami Olmari
> > > >
> > > > On Sep 15, 2014 3:11 PM, "John Crispin"  
> > > >
> > > > 
>  > > >
> > > > Hi,
> > > >
> > > > my version of the scripts is based on Oskari patches and fixes a
> > > > lot of the "not perfect" stuff
> > > >
> > > > however i am sure it wont work out of the box as i blindly
> > > > reworked large parts of the code.
> > > >
> > > > i can send it back to you in finland when i am done testing.
> > > >
> > > > John
> > > >
> > > > On 15/09/2014 13:53, Sami Olmari wrote:
> > > >>
> > > >> I have 2 such devices, I do use Oskari Rauta's scripts to run
> > > >> it.. not perfect but works after manual labour... Maybe there
> > > >> would be at least some ideas... So.. I can definately help with
> > > >> testing! I have to think how I could donate one dongle to
> you...
> > > >>
> > > >> Sami Olmari
> > > >>
> > > >> On Sep 15, 2014 1:35 PM, "John Crispin"  
> > > >
> > > > 
> >>
> > > >> 
> >
> > > 
>  wrote:
> > > >>
> > > >> Hi,
> > > >>
> > > >> i would like to add 4g ncm support. there are a few version of
> > > > a patc
> > > >> floating around that don't make use of dynamic_interface yet.
> > > >>
> > > >> anyone around that wants to 1) donate a huawei e3276 2) has a
> > > >> huawei e3276 and wants to help testing ?
> > > >>
> > > >> John ___
> > > >> openwrt-devel mailing list openwrt-devel@lists.openwrt.org
> 
> > >  >
> > > >  
> > >  >>
> > > >>  
> > >  >
> > > >  
> > > 

Re: [OpenWrt-Devel] [PATCH] base-files: procd initscriptsrestartonreload

[Felix Fietkau]

On 2014-09-16 14:18, tris...@trstn.net wrote:
> Felix Fietkau wrote:
>> ...
>> By the way, you mentioned in an earlier email that procd_set_param file
>> did not work for you to restart your service when a config file changes.
>> Can you produce a test case for that? I just tested it myself on a
>> simple service and it worked just fine.
> 
> So I just made a test service:
> 
> root@hg:~# cat /etc/openwrt_version 
> r42538
> root@hg:~# cat /etc/init.d/test 
> #!/bin/sh /etc/rc.common
> 
> START=70
> USE_PROCD=1
> 
> start_service() {
>   procd_open_instance
>   procd_set_param command /bin/sleep 1
>   procd_set_param file /tmp/test
>   procd_set_param respawn
>   procd_close_instance
> }
> 
> root@hg:~# cat /tmp/test
> hello
> root@hg:~# /etc/init.d/test start
> root@hg:~# pidof sleep
> 6958
> root@hg:~# /etc/init.d/test reload
> root@hg:~# pidof sleep
> 6958
> root@hg:~# echo goodbye > /tmp/test
> root@hg:~# pidof sleep
> 6958
> root@hg:~# rm /tmp/test
> root@hg:~# pidof sleep
> 6958
> root@hg:~# echo hello > /tmp/test
> root@hg:~# pidof sleep
> 6958
> root@hg:~# /etc/init.d/test restart
> root@hg:~# pidof sleep
> 6985
You forgot to call reload after changing /tmp/test :)
FYI, I just tested your script, and it works as expected - after
changing the file and calling reload, the pid is different.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Missing mpc83xx in BB-RC3

[Felix Fietkau]

On 2014-09-16 13:47, Claudio Thomas wrote:
> Hi,
> I until now was still using the trunk for testing and working, but today
> I the first time checked out the 14.07/openwrt.git at git.openwrt.git.
> Is there a reason why MPC83xx is not included in BB-RC3?
It wasn't upgraded to Linux 3.10 in time, so it's not properly
maintained enough for this release.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Missing mpc83xx in BB-RC3

[Claudio Thomas]

On 16.09.2014 14:44, Felix Fietkau wrote:
> On 2014-09-16 13:47, Claudio Thomas wrote:
>> Hi,
>> I until now was still using the trunk for testing and working, but today
>> I the first time checked out the 14.07/openwrt.git at git.openwrt.git.
>> Is there a reason why MPC83xx is not included in BB-RC3?
> It wasn't upgraded to Linux 3.10 in time, so it's not properly
> maintained enough for this release.
>
> - Felix
that's too bad.
I'll go soon as possible to update this.
Thanks,
Claudio
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] base-files: procd initscriptsrestartonreload

[tristan]

> You forgot to call reload after changing /tmp/test :)
> FYI, I just tested your script, and it works as expected - after
> changing the file and calling reload, the pid is different.

I see, I took the wording "reload on config file change" to mean that
prcod used inotify and reloaded at the time of the actual change. (which
isn't a feature I'm very interested in.)

Thanks. Everything makes much more sense now. Time to go change some
patches.

Tristan

-- 
All original matter is hereby placed immediately under the public domain.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] Lantiq: fix build warning from dsl_fs script

[thomas.langer]

fix inclusion of functions.sh in dsl_fs init script

without this, the following error is seen during build:
./etc/init.d/dsl_fs: line 4: /lib/functions.sh: No such file or directory

Signed-off-by: Thomas Langer 

diff --git a/target/linux/lantiq/base-files/etc/init.d/dsl_fs 
b/target/linux/lantiq/base-files/etc/init.d/dsl_fs
--- a/target/linux/lantiq/base-files/etc/init.d/dsl_fs
+++ b/target/linux/lantiq/base-files/etc/init.d/dsl_fs
@@ -1,7 +1,7 @@
 #!/bin/sh /etc/rc.common
 # Copyright (C) 2014 OpenWrt.org
 
-. /lib/functions.sh
+. $IPKG_INSTROOT/lib/functions.sh
 
 START=30
 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] procd crash

[Nuno Gonçalves]

On Wed, Apr 16, 2014 at 9:14 AM, Bastian Bittorf  wrote:
> * Nuno Gonçalves  [16.04.2014 09:34]:
>> Crash happens always after a dvb_usb_rtl28xxu stick is inserted for
>> the 2nd time.
>
> please run procd in debug-mode (hitting key '4') during bootup
>
> bye, bastian

With procd set to debug mode:

[   21.67] eth0: link up (100Mbps/Full duplex)
[   21.67] br-lan: port 1(eth0) entered forwarding state
[   21.68] br-lan: port 1(eth0) entered forwarding state
[   21.68] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   21.69] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
[   23.68] br-lan: port 1(eth0) entered forwarding state
procd: service_handle_set(242): Create service dnsmasq
procd: service_instance_update(66): Create instance dnsmasq::instance1
procd: instance_start(201): Started instance dnsmasq::instance1
procd: _rc(132): running /etc/init.d/dnsmasq running
procd: q_initd_run(68): start /etc/init.d/dnsmasq running
procd: q_initd_complete(98): stop /etc/init.d/dnsmasq running
procd: service_handle_set(238): Update service dnsmasq
procd: service_instance_update(58): Update instance dnsmasq::instance1
procd: _rc(132): running /etc/init.d/dnsmasq running
procd: q_initd_run(68): start /etc/init.d/dnsmasq running
procd: q_initd_complete(98): stop /etc/init.d/dnsmasq running
procd: watchdog_timeout_cb(37): Ping
procd: watchdog_timeout_cb(37): Ping
procd: watchdog_timeout_cb(37): Ping
procd: watchdog_timeout_cb(37): Ping
procd: watchdog_timeout_cb(37): Ping
procd: watchdog_timeout_cb(37): Ping
procd: watchdog_timeout_cb(37): Ping
procd: watchdog_timeout_cb(37): Ping
procd: watchdog_timeout_cb(37): Ping
procd: watchdog_timeout_cb(37): Ping
procd: watchdog_timeout_cb(37): Ping
procd: watchdog_timeout_cb(37): Ping
procd: watchdog_timeout_cb(37): Ping
procd: watchdog_timeout_cb(37): Ping
procd: watchdog_timeout_cb(37): Ping
procd: watchdog_timeout_cb(37): Ping
procd: watchdog_timeout_cb(37): Ping

/*
USB DEVICE INSERTION
*/

[  106.73] usb 1-1: new high-speed USB device number 2 using ehci-platform
procd: hotplug_handler_debug(404):
{{"ACTION":"add","DEVPATH":"\/devices\/platform\/ehci-platform\/usb1\/1-1","SUBSYSTEM":"usb","MAJOR":"189","MINOR":"1","DEVNAME":"bu[
 106.90] usb 1-1: dvb_usb_v2: found a 'TerraTec NOXON DAB Stick'
in warm state
s\/usb\/001\/002","DEVTYPE":"usb_device","PRODUCT":"ccd\/b3\/100","TYPE":"0\/0\/0","BUSNUM":"001","DEVNUM":"002","SEQNUM":"364"}}
procd: rule_handle_command(355): Command: makedevprocd:
rule_handle_command(357):  /dev/bus/usb/001/002procd:
rule_handle_command(357):  0644procd: rule_handle_command(358):
procd: rule_handle_command(360): Message:procd:
rule_handle_command(362):  ACTION=addprocd: rule_handle_command(362):
DEVPATH=/devices/platform/ehci-platform/usb1/1-1procd:
rule_handle_command(362):  SUBSYSTEM=usbprocd:
rule_handle_command(362):  MAJOR=189procd: rule_handle_command(362):
MINOR=1procd: rule_handle_command(362):  DEVN}}
procd: rule_handle_command(355): Command: execprocd:
rule_handle_command(357):  /sbin/hotplug-callprocd:
rule_handle_command(357):  usbprocd: rule_handle_command(358):
procd: rule_handle_command(360): Message:procd:
rule_handle_command(362):  ACTION=addprocd: rule_handle_command(362):
DEVPATH=/devices/platform/ehci-platform/usb1/1-1/1-1:1.0procd:
rule_handle_command(362):  SUBSYSTEM=usbprocd:
rule_handle_command(362):  DEVTYPE=usb_interfaceprocd:
rule_handle_command(362):  PRODUCT=ccd/b3/100procd:
rule_handle_command(362):  TYPE=0/0/0procd: rule_handle_command(362):
INTERFACE=255/255/255procd: rule_handle_command(362):
MODALIAS=usb:v0CCDp00B3d0100dc00dsc00dp00icFFiscFFipFFin00procd:
rule_handle_command(362):  SEQNUM=365procd: rule_handle_command(363):
procd: queue_proc_cb(286): Finished hotplug exec instance, pid=908
procd: queue_next(281): Launched hotplug exec instance, pid=910
procd: queue_proc_cb(286): Finished hotplug exec instance, pid=910
procd: hotplug_handler_debug(404):
{{"ACTION":"add","DEVPATH":"\/devices\/platform\/ehci-platform\/usb1\/1-1\/i2c-0","SUBSYSTEM":"i2c","SEQNUM":"366"}}
procd: hotplug_handler_debug(404):
{{"ACTION":"add","DEVPATH":"\/devices\/platform\/ehci-platform\/usb1\/1-1\/dvb\/dvb0.demux0","SUBSYSTEM":"dvb","MAJOR":"212","MINOR":"4","DEVNAME":"dvb\/adapter0\/demux0","DVB_ADAPTER_NUM":"0","DVB_DEVICE_TYPE":"demux","DVB_DEVICE_NUM":"0","SEQNUM":"367"}}
procd: rule_handle_command(355): Command: makedevprocd:
rule_handle_command(357):  /dev/dvb/adapter0/demux0procd:
rule_handle_command(357):  0644procd: rule_handle_command(358):
procd: rule_handle_command(360): Message:procd:
rule_handle_command(362):  ACTION=addprocd: rule_handle_command(362):
DEVPATH=/devices/platform/ehci-platform/usb1/1-1/dvb/dvb0.demux0procd:
rule_handle_command(362):  SUBSYSTEM=dvbprocd:
rule_handle_command(362):  MAJOR=212procd: rule_handle_command(362):
MINOR=4procd: rule_handle_command(362):
DEVNAME=dvb/adapter0/demux0procd: rule_handle_command(362):
DVB_ADAPTER_NUM=0procd: rule_handle_comma

[OpenWrt-Devel] [PATCH] tools: add missing ldconfig make dependency on the staging area

[John Szakmeister]

Signed-off-by: John Szakmeister 
---

Using make with multiple jobs fails without this.

 tools/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/Makefile b/tools/Makefile
index 09a0c8c..5629251 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -133,7 +133,7 @@ $(STAGING_DIR_HOST)/bin/stat: $(STAGING_DIR)/.prepared
false; \
fi
 
-$(STAGING_DIR_HOST)/bin/ldconfig:
+$(STAGING_DIR_HOST)/bin/ldconfig: $(STAGING_DIR)/.prepared
touch $@
chmod +x $@
 
-- 
2.1.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] uClibc bug: epoll_pwait broken on OpenWrt x86

[Matthias Schiffer]

On 09/16/2014 04:34 PM, Bernhard Reutner-Fischer wrote:
> On 15 September 2014 17:33, Matthias Schiffer
>  wrote:
>> Ping? I'd like to get this fixed as soon as possible (even though it's
>> probably too late for the OpenWrt BB final?). I guess I can try to write
>> a patch, but I had hoped someone on these lists could give some advice
>> on what the best way to fix this would be...
> 
> You could stuff the 6ff args into an immediate structure and pass a
> reference to that.
Wouldn't that pass the arguments on the stack, or am I understanding you
wrong? I think not using the stack if it can be avoided is the whole
point of INLINE_SYSCALL/INTERNAL_SYSCALL...

> 
> What does glibc do?
As far as I can tell, glibc's INTERNAL_SYSCALL implementation for i386
only supports up to 5 arguments, all syscall6 are implemented indepently
on i386 (in the case of epoll_pwait there is an indepdendent assembly
implementation as the 6th argument is implicit from the applications'
point of view; splice and maybe others are automatically generated
assembly as the kernel and libc APIs match)

Matthias



signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] procd crash

[John Crispin]

On 16/09/2014 17:18, Nuno Gonçalves wrote:
> On Wed, Apr 16, 2014 at 9:14 AM, Bastian Bittorf  
> wrote:
>> * Nuno Gonçalves  [16.04.2014 09:34]:
>>> Crash happens always after a dvb_usb_rtl28xxu stick is inserted for
>>> the 2nd time.
>> please run procd in debug-mode (hitting key '4') during bootup
>>
>> bye, bastian
> With procd set to debug mode:

this is a kernel oops and not a procd crash  ...




> [   21.67] eth0: link up (100Mbps/Full duplex)
> [   21.67] br-lan: port 1(eth0) entered forwarding state
> [   21.68] br-lan: port 1(eth0) entered forwarding state
> [   21.68] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> [   21.69] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
> [   23.68] br-lan: port 1(eth0) entered forwarding state
> procd: service_handle_set(242): Create service dnsmasq
> procd: service_instance_update(66): Create instance dnsmasq::instance1
> procd: instance_start(201): Started instance dnsmasq::instance1
> procd: _rc(132): running /etc/init.d/dnsmasq running
> procd: q_initd_run(68): start /etc/init.d/dnsmasq running
> procd: q_initd_complete(98): stop /etc/init.d/dnsmasq running
> procd: service_handle_set(238): Update service dnsmasq
> procd: service_instance_update(58): Update instance dnsmasq::instance1
> procd: _rc(132): running /etc/init.d/dnsmasq running
> procd: q_initd_run(68): start /etc/init.d/dnsmasq running
> procd: q_initd_complete(98): stop /etc/init.d/dnsmasq running
> procd: watchdog_timeout_cb(37): Ping
> procd: watchdog_timeout_cb(37): Ping
> procd: watchdog_timeout_cb(37): Ping
> procd: watchdog_timeout_cb(37): Ping
> procd: watchdog_timeout_cb(37): Ping
> procd: watchdog_timeout_cb(37): Ping
> procd: watchdog_timeout_cb(37): Ping
> procd: watchdog_timeout_cb(37): Ping
> procd: watchdog_timeout_cb(37): Ping
> procd: watchdog_timeout_cb(37): Ping
> procd: watchdog_timeout_cb(37): Ping
> procd: watchdog_timeout_cb(37): Ping
> procd: watchdog_timeout_cb(37): Ping
> procd: watchdog_timeout_cb(37): Ping
> procd: watchdog_timeout_cb(37): Ping
> procd: watchdog_timeout_cb(37): Ping
> procd: watchdog_timeout_cb(37): Ping
>
> /*
> USB DEVICE INSERTION
> */
>
> [  106.73] usb 1-1: new high-speed USB device number 2 using ehci-platform
> procd: hotplug_handler_debug(404):
> {{"ACTION":"add","DEVPATH":"\/devices\/platform\/ehci-platform\/usb1\/1-1","SUBSYSTEM":"usb","MAJOR":"189","MINOR":"1","DEVNAME":"bu[
>  106.90] usb 1-1: dvb_usb_v2: found a 'TerraTec NOXON DAB Stick'
> in warm state
> s\/usb\/001\/002","DEVTYPE":"usb_device","PRODUCT":"ccd\/b3\/100","TYPE":"0\/0\/0","BUSNUM":"001","DEVNUM":"002","SEQNUM":"364"}}
> procd: rule_handle_command(355): Command: makedevprocd:
> rule_handle_command(357):  /dev/bus/usb/001/002procd:
> rule_handle_command(357):  0644procd: rule_handle_command(358):
> procd: rule_handle_command(360): Message:procd:
> rule_handle_command(362):  ACTION=addprocd: rule_handle_command(362):
> DEVPATH=/devices/platform/ehci-platform/usb1/1-1procd:
> rule_handle_command(362):  SUBSYSTEM=usbprocd:
> rule_handle_command(362):  MAJOR=189procd: rule_handle_command(362):
> MINOR=1procd: rule_handle_command(362):  DEVN}}
> procd: rule_handle_command(355): Command: execprocd:
> rule_handle_command(357):  /sbin/hotplug-callprocd:
> rule_handle_command(357):  usbprocd: rule_handle_command(358):
> procd: rule_handle_command(360): Message:procd:
> rule_handle_command(362):  ACTION=addprocd: rule_handle_command(362):
> DEVPATH=/devices/platform/ehci-platform/usb1/1-1/1-1:1.0procd:
> rule_handle_command(362):  SUBSYSTEM=usbprocd:
> rule_handle_command(362):  DEVTYPE=usb_interfaceprocd:
> rule_handle_command(362):  PRODUCT=ccd/b3/100procd:
> rule_handle_command(362):  TYPE=0/0/0procd: rule_handle_command(362):
> INTERFACE=255/255/255procd: rule_handle_command(362):
> MODALIAS=usb:v0CCDp00B3d0100dc00dsc00dp00icFFiscFFipFFin00procd:
> rule_handle_command(362):  SEQNUM=365procd: rule_handle_command(363):
> procd: queue_proc_cb(286): Finished hotplug exec instance, pid=908
> procd: queue_next(281): Launched hotplug exec instance, pid=910
> procd: queue_proc_cb(286): Finished hotplug exec instance, pid=910
> procd: hotplug_handler_debug(404):
> {{"ACTION":"add","DEVPATH":"\/devices\/platform\/ehci-platform\/usb1\/1-1\/i2c-0","SUBSYSTEM":"i2c","SEQNUM":"366"}}
> procd: hotplug_handler_debug(404):
> {{"ACTION":"add","DEVPATH":"\/devices\/platform\/ehci-platform\/usb1\/1-1\/dvb\/dvb0.demux0","SUBSYSTEM":"dvb","MAJOR":"212","MINOR":"4","DEVNAME":"dvb\/adapter0\/demux0","DVB_ADAPTER_NUM":"0","DVB_DEVICE_TYPE":"demux","DVB_DEVICE_NUM":"0","SEQNUM":"367"}}
> procd: rule_handle_command(355): Command: makedevprocd:
> rule_handle_command(357):  /dev/dvb/adapter0/demux0procd:
> rule_handle_command(357):  0644procd: rule_handle_command(358):
> procd: rule_handle_command(360): Message:procd:
> rule_handle_command(362):  ACTION=addprocd: rule_handle_command(362):
> DEVPATH=/devices/platform/ehci-platform/usb1/1-1/dvb/dvb0.demux

[OpenWrt-Devel] [PATCH] ramips: add support for Nexx WT1520

[rogerpueyo]

From: Roger Pueyo Centelles 

---
 target/linux/ramips/base-files/etc/board.d/01_leds |   3 +
 .../linux/ramips/base-files/etc/board.d/02_network |   1 +
 target/linux/ramips/base-files/etc/diag.sh |   3 +
 target/linux/ramips/base-files/lib/ramips.sh   |   3 +
 .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
 target/linux/ramips/dts/NEXXWT1520.dts | 108 +
 target/linux/ramips/image/Makefile |   9 ++
 target/linux/ramips/rt305x/profiles/nexx.mk|  17 
 8 files changed, 145 insertions(+)
 create mode 100644 target/linux/ramips/dts/NEXXWT1520.dts
 create mode 100644 target/linux/ramips/rt305x/profiles/nexx.mk

diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds 
b/target/linux/ramips/base-files/etc/board.d/01_leds
index 01e2363..1806ff2 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -112,6 +112,9 @@ case $board in
hlk-rm04)
set_wifi_led "rt2800pci-phy0::radio"
;;
+   nexx-wt1520)
+   set_wifi_led "rt2800pci-phy0::radio"
+   ;;
all0239-3g|\
hw550-3g)
set_usb_led "hw550-3g:green:usb"
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index e027b3b..765d398 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -103,6 +103,7 @@ ramips_setup_interfaces()
dir-320-b1 | \
dir-615-h1 | \
hlk-rm04 | \
+   nexx-wt1520 | \
mzk-w300nh2 | \
mzk-750dhp)
ucidef_set_interfaces_lan_wan "eth0.1" "eth0.2"
diff --git a/target/linux/ramips/base-files/etc/diag.sh 
b/target/linux/ramips/base-files/etc/diag.sh
index 9ad7ccb..472da4b 100755
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -63,6 +63,9 @@ get_status_led() {
hlk-rm04)
status_led="hlk-rm04:red:power"
;;
+   nexx-wt1520)
+   status_led="nexx-wt1520:white:power"
+   ;;
all0239-3g|\
hw550-3g)
status_led="hw550-3g:green:status"
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index bb42ace..0a09225 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -157,6 +157,9 @@ ramips_board_detect() {
*"HILINK HLK-RM04")
name="hlk-rm04"
;;
+   *"Nexx WT1520")
+   name="nexx-wt1520"
+   ;;
*"HAME MPR-A1")
name="mpr-a1"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 407c218..8ff2da6 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -52,6 +52,7 @@ platform_check_image() {
hw550-3g | \
hg255d | \
hlk-rm04 | \
+   nexx-wt1520 | \
ip2202 | \
m3 | \
m4 | \
diff --git a/target/linux/ramips/dts/NEXXWT1520.dts 
b/target/linux/ramips/dts/NEXXWT1520.dts
new file mode 100644
index 000..c89bea1
--- /dev/null
+++ b/target/linux/ramips/dts/NEXXWT1520.dts
@@ -0,0 +1,108 @@
+/dts-v1/;
+
+/include/ "rt5350.dtsi"
+
+/ {
+   compatible = "NEXXWT1520", "ralink,rt5350-soc";
+   model = "Nexx WT1520";
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x200>;
+   };
+
+   chosen {
+   bootargs = "console=ttyS1,57600";
+   };
+
+   palmbus@1000 {
+   uart@500 {
+   status = "okay";
+   };
+
+   spi@b00 {
+   status = "okay";
+   m25p80@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "w25q32";
+   reg = <0 0>;
+   linux,modalias = "m25p80", "s25fl064k";
+   spi-max-frequency = <1000>;
+
+   partition@0 {
+   label = "u-boot";
+   reg = <0x0 0x3>;
+   read-only;
+   };
+
+   partition@3 {
+   label = "u-boot-env";
+   reg = <0x3 0x1>;
+   read-only;
+   };
+
+   factory: partition@4 {
+ 

Re: [OpenWrt-Devel] [PATCH] ramips: add support for Nexx WT1520

[John Crispin]

Hi,

looks much better ... 2 comments inline ...


On 16/09/2014 18:16, rogerpu...@rogerpueyo.com wrote:
> From: Roger Pueyo Centelles 
>
> ---
>  target/linux/ramips/base-files/etc/board.d/01_leds |   3 +
>  .../linux/ramips/base-files/etc/board.d/02_network |   1 +
>  target/linux/ramips/base-files/etc/diag.sh |   3 +
>  target/linux/ramips/base-files/lib/ramips.sh   |   3 +
>  .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
>  target/linux/ramips/dts/NEXXWT1520.dts | 108 
> +
>  target/linux/ramips/image/Makefile |   9 ++
>  target/linux/ramips/rt305x/profiles/nexx.mk|  17 
>  8 files changed, 145 insertions(+)
>  create mode 100644 target/linux/ramips/dts/NEXXWT1520.dts
>  create mode 100644 target/linux/ramips/rt305x/profiles/nexx.mk
>
> diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds 
> b/target/linux/ramips/base-files/etc/board.d/01_leds
> index 01e2363..1806ff2 100755
> --- a/target/linux/ramips/base-files/etc/board.d/01_leds
> +++ b/target/linux/ramips/base-files/etc/board.d/01_leds
> @@ -112,6 +112,9 @@ case $board in
>   hlk-rm04)
>   set_wifi_led "rt2800pci-phy0::radio"
>   ;;
> + nexx-wt1520)
> + set_wifi_led "rt2800pci-phy0::radio"
> + ;;
>   all0239-3g|\
>   hw550-3g)
>   set_usb_led "hw550-3g:green:usb"
> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
> b/target/linux/ramips/base-files/etc/board.d/02_network
> index e027b3b..765d398 100755
> --- a/target/linux/ramips/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
> @@ -103,6 +103,7 @@ ramips_setup_interfaces()
>   dir-320-b1 | \
>   dir-615-h1 | \
>   hlk-rm04 | \
> + nexx-wt1520 | \
>   mzk-w300nh2 | \
>   mzk-750dhp)
>   ucidef_set_interfaces_lan_wan "eth0.1" "eth0.2"
> diff --git a/target/linux/ramips/base-files/etc/diag.sh 
> b/target/linux/ramips/base-files/etc/diag.sh
> index 9ad7ccb..472da4b 100755
> --- a/target/linux/ramips/base-files/etc/diag.sh
> +++ b/target/linux/ramips/base-files/etc/diag.sh
> @@ -63,6 +63,9 @@ get_status_led() {
>   hlk-rm04)
>   status_led="hlk-rm04:red:power"
>   ;;
> + nexx-wt1520)
> + status_led="nexx-wt1520:white:power"
> + ;;
>   all0239-3g|\
>   hw550-3g)
>   status_led="hw550-3g:green:status"
> diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
> b/target/linux/ramips/base-files/lib/ramips.sh
> index bb42ace..0a09225 100755
> --- a/target/linux/ramips/base-files/lib/ramips.sh
> +++ b/target/linux/ramips/base-files/lib/ramips.sh
> @@ -157,6 +157,9 @@ ramips_board_detect() {
>   *"HILINK HLK-RM04")
>   name="hlk-rm04"
>   ;;
> + *"Nexx WT1520")
> + name="nexx-wt1520"
> + ;;
>   *"HAME MPR-A1")
>   name="mpr-a1"
>   ;;
> diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
> b/target/linux/ramips/base-files/lib/upgrade/platform.sh
> index 407c218..8ff2da6 100755
> --- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
> @@ -52,6 +52,7 @@ platform_check_image() {
>   hw550-3g | \
>   hg255d | \
>   hlk-rm04 | \
> + nexx-wt1520 | \
>   ip2202 | \
>   m3 | \
>   m4 | \
> diff --git a/target/linux/ramips/dts/NEXXWT1520.dts 
> b/target/linux/ramips/dts/NEXXWT1520.dts
> new file mode 100644
> index 000..c89bea1
> --- /dev/null
> +++ b/target/linux/ramips/dts/NEXXWT1520.dts
> @@ -0,0 +1,108 @@
> +/dts-v1/;
> +
> +/include/ "rt5350.dtsi"
> +
> +/ {
> + compatible = "NEXXWT1520", "ralink,rt5350-soc";
> + model = "Nexx WT1520";
> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x200>;
> + };
> +
> + chosen {
> + bootargs = "console=ttyS1,57600";
> + };
> +
> + palmbus@1000 {
> + uart@500 {
> + status = "okay";
> + };
> +
> + spi@b00 {
> + status = "okay";
> + m25p80@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "w25q32";
> + reg = <0 0>;
> + linux,modalias = "m25p80", "s25fl064k";
> + spi-max-frequency = <1000>;
> +
> + partition@0 {
> + label = "u-boot";
> + reg = <0x0 0x3>;
> + read-only;
> + };
> +
> + partition@3 {
> + label = "u-boot-env";
> +   

Re: [OpenWrt-Devel] Missing mpc83xx in BB-RC3

[Hauke Mehrtens]

On 09/16/2014 02:52 PM, Claudio Thomas wrote:
> On 16.09.2014 14:44, Felix Fietkau wrote:
>> On 2014-09-16 13:47, Claudio Thomas wrote:
>>> Hi,
>>> I until now was still using the trunk for testing and working, but today
>>> I the first time checked out the 14.07/openwrt.git at git.openwrt.git.
>>> Is there a reason why MPC83xx is not included in BB-RC3?
>> It wasn't upgraded to Linux 3.10 in time, so it's not properly
>> maintained enough for this release.
>>
>> - Felix
> that's too bad.
> I'll go soon as possible to update this.
> Thanks,
> Claudio

Hi,

If you have a device supported by the mpc83xx target please test OpenWrt
trunk with kernel 3.10.

I ported the patches to kernel 3.10 but I do not have a device to test
and asked for help, see:
https://lists.openwrt.org/pipermail/openwrt-devel/2014-July/026547.html

Just edit target/linux/mpc83xx/Makefile to make it build with kernel 3.10.

I do not think this will help to bring it into BB.

Hauke
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] tools: add missing ldconfig make dependency on the staging area

[Felix Fietkau]

On 2014-09-16 17:44, John Szakmeister wrote:
> Signed-off-by: John Szakmeister 
Committed in r42576, thanks.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] for-14.07 [packages] xinetd: ident-bind.patch copy from trunk ??

[Christian Schoenebeck]

Hi Jonathan,

could you please copy xinetd: 004-ident-bind.patch also to 14.07 ?

Christian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] overcommit memory/ratio

[Karl P]

Alternatively, if you know which process it is, set it's oom_adj_score so that 
it gets killed first.  Some other people are kinda used to things behaving as 
they are, for better or worse.  (Turning off overcommit on an openwrt device is 
no different than turning off overcommit on a desktop as far as I'm concerned. 
Somethings will be better, lots of things less so)


Cheers,
Karl P


On 09/15/2014 07:22 PM, Nikos Mavrogiannopoulos wrote:

Hello,
  It seems I have a memory leak in a process that runs under openwrt, and
occasionally the watchdog process is being killed by the oom-killer
causing a reboot. Seen that, I think that having the default overcommit
settings of the linux kernel is quite an overkill for a system like
openwrt where memory is really limited. May I suggest turning off
overcommit completely in openwrt using:
echo 2 > /proc/sys/vm/overcommit_memory
echo 100 >/proc/sys/vm/overcommit_ratio

somewhere in the init scripts. That way processes which have a leak will
eventually get a NULL pointer in malloc() and the oom-killer wouldn't
kill unrelated processes.

regards,
Nikos

[0].
http://serverfault.com/questions/362589/effects-of-configuring-vm-overcommit-memory
[1]. http://www.win.tue.nl/~aeb/linux/lk/lk-9.html
___
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] Missing dependency on host sed?

[John Szakmeister]

I'm finding that I'm running into an issue occasionally when trying to
build.  It appears that Make is trying to build gcc, but the host sed
hasn't been built yet so it ultimately fails:

checking for i686-linux-gnu-gcc option to accept ISO C89... bash:
/home/jszakmeister/projects/openwrt/staging_dir/host/bin
/sed: No such file or directory
(cached) make[2]: ***
[/home/jszakmeister/projects/openwrt/build_dir/toolchain-arm_arm926ej-s_gcc-4.6-linaro_uClibc-0.9.33
.2_eabi/gcc-linaro-4.6-2013.05/.prepared] Error 127


Any ideas on how to fix this?

-John
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Missing dependency on host sed?

[Jonathan Bennett]

Are you building with multiple processes (-j 2 or greater)? This reminds me
of an old bug that only popped up after a make distclean when building with
multiple build threads.

~Jonathan Bennett
On Sep 16, 2014 6:55 PM, "John Szakmeister"  wrote:

> I'm finding that I'm running into an issue occasionally when trying to
> build.  It appears that Make is trying to build gcc, but the host sed
> hasn't been built yet so it ultimately fails:
>
> checking for i686-linux-gnu-gcc option to accept ISO C89... bash:
> /home/jszakmeister/projects/openwrt/staging_dir/host/bin
> /sed: No such file or directory
> (cached) make[2]: ***
>
> [/home/jszakmeister/projects/openwrt/build_dir/toolchain-arm_arm926ej-s_gcc-4.6-linaro_uClibc-0.9.33
> .2_eabi/gcc-linaro-4.6-2013.05/.prepared] Error 127
>
>
> Any ideas on how to fix this?
>
> -John
> ___
> 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] Missing dependency on host sed?

[John Szakmeister]

On Tue, Sep 16, 2014 at 8:32 PM, Jonathan Bennett  wrote:
> Are you building with multiple processes (-j 2 or greater)? This reminds me
> of an old bug that only popped up after a make distclean when building with
> multiple build threads.

Yes sir, I am.  On the machine this is failing on, I'm attempting to
build with -j4.

-John
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Missing dependency on host sed?

[Jonathan Bennett]

In your tree, in the file tools/sed/Makefile, change HOST_BUILD_PARALLEL:=1
to HOST_BUILD_PARALLEL:=0 and see if that fixes the error.
On Sep 16, 2014 7:47 PM, "John Szakmeister"  wrote:

> On Tue, Sep 16, 2014 at 8:32 PM, Jonathan Bennett 
> wrote:
> > Are you building with multiple processes (-j 2 or greater)? This reminds
> me
> > of an old bug that only popped up after a make distclean when building
> with
> > multiple build threads.
>
> Yes sir, I am.  On the machine this is failing on, I'm attempting to
> build with -j4.
>
> -John
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Missing dependency on host sed?

[John Szakmeister]

On Tue, Sep 16, 2014 at 9:32 PM, Jonathan Bennett  wrote:
> In your tree, in the file tools/sed/Makefile, change HOST_BUILD_PARALLEL:=1
> to HOST_BUILD_PARALLEL:=0 and see if that fixes the error.

Unfortunately, it didn't help.  I think the issue is that
linux-headers needs the SED utility, but it's not being built ahead of
toolchain/prepare rather than sed failing to build with multiple jobs.
It seems like a dependency is getting filtered out somehow... perhaps
as part of the tools_enabled line in tools/Makefile (towards the
bottom)? :-(

-John
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Missing dependency on host sed?

[Jonathan Bennett]

I'll throw a couple thoughts out, and then defer to someone that
understands the openwrt build env better than I do.
First, you do have sed installed on your host system, right? I don't think
this is the issue, but best to check the easy things first. Also, a make
distclean sometimes clears up these problems.

Try compiling without a -j flag. I suspect that this is a parallel build
issue. If you can recreate it without -j, then the rest of this message is
a moot point.

Now, what I think is happening here is that we have a race between a couple
of compilation threads, one of which is the sed utility. What happens is
something that uses sed is trying to compile before sed has finished
compiling. The build env queues up a bunch of programs to compile, and
because sed takes quite a while to compile, it chews through that queue and
hits something that calls sed before sed exists. It would be helpful if we
could discern exactly which package is failing.

That said, I have put a "sleep 500" in my sed makefile, which basically
means that every other package that is allowed to do so will build and
install first, and I have been unable to reproduce.


If it's not cleared up shortly, go ahead and open a ticket on
dev.openwrt.org

~Jonathan Bennett

On Tue, Sep 16, 2014 at 8:43 PM, John Szakmeister 
wrote:

> On Tue, Sep 16, 2014 at 9:32 PM, Jonathan Bennett 
> wrote:
> > In your tree, in the file tools/sed/Makefile, change
> HOST_BUILD_PARALLEL:=1
> > to HOST_BUILD_PARALLEL:=0 and see if that fixes the error.
>
> Unfortunately, it didn't help.  I think the issue is that
> linux-headers needs the SED utility, but it's not being built ahead of
> toolchain/prepare rather than sed failing to build with multiple jobs.
> It seems like a dependency is getting filtered out somehow... perhaps
> as part of the tools_enabled line in tools/Makefile (towards the
> bottom)? :-(
>
> -John
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] for-14.07 [packages] xinetd: ident-bind.patch copy from trunk ??

[John Crispin]

On 16/09/2014 20:07, Christian Schoenebeck wrote:
> Hi Jonathan,
> 
> could you please copy xinetd: 004-ident-bind.patch also to 14.07 ?
> 
> Christian

Hi,

please provide a link to the exact commit that you want backported.

John



> ___ 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