Re: [LEDE-DEV] [PATCH v2] [base-files] dont change defaults for vm.min_free_kbytes on devices with <64MiB RAM

[Felix Fietkau]

On 2016-09-16 19:39, Bastian Bittorf wrote:
> with 5c9cc7b7f8920944a413644e1c2ea23bfe655bcb we changed the default
> value of 'vm.min_free_kbytes' from ~650 to 4096 kilobytes on 
> 32MiB-RAM-devices.
> This makes them hardly useable with a lot of OOM-crashes.
> 
> Change that and use 1024 kilobytes for 32MiB-RAM-devices.
> For devices with more than 32MiB RAM we keep the behaviour / the values.
> 
> While we are at it, localize vars and read the memory without AWK/nonforking.
> 
> changes v1 -> v2: (suggestions from Felix Fietkau, Rafał Miłecki)
> - keep -quiet option from sysctl
> - use 1024 kilobyte on 32MiB-devices instead of the kernel default
> - consistently use unit [MiB]
> ---
>  package/base-files/files/etc/init.d/sysctl | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/package/base-files/files/etc/init.d/sysctl 
> b/package/base-files/files/etc/init.d/sysctl
> index a0daec0..7a16e01 100755
> --- a/package/base-files/files/etc/init.d/sysctl
> +++ b/package/base-files/files/etc/init.d/sysctl
> @@ -4,16 +4,20 @@
>  START=11
>  
>  set_vm_min_free() {
> - mem="$(grep MemTotal /proc/meminfo  | awk '{print $2}')"
> - if [ "$mem" -gt 65536 ]; then # 128M
> + local mem value
> +
> + read -r _ mem _  +
> + if   [ "$mem" -gt 65536 ]; then # 128MiB
>   val=16384
> - elif [ "$mem" -gt 32768 ]; then # 64M
> + elif [ "$mem" -gt 32768 ]; then # 64MiB
>   val=8192
> - elif [ "$mem" -gt 16384 ]; then # 32M
> - val=4096
> + elif [ "$mem" -gt 16384 ]; then # 32MiB
> + val=1024
I already changed the default in the master branch. By the way, I'm not
very fond of burying a small relevant fix in a bunch of unrelated
cleanups, even when documented in the commit msg.

- Felix

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v2] [base-files] dont change defaults for vm.min_free_kbytes on devices with <64MiB RAM

[Bastian Bittorf]

* Bastian Bittorf  [16.09.2016 19:43]:
> changes v1 -> v2: (suggestions from Felix Fietkau, Rafał Miłecki)

sorry, please drop that - i can see the change now:
https://git.lede-project.org/?p=source.git;a=commitdiff;h=25dab5d217715300dc609df07b56e5b73cefdfc1

bye, bastian

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH v2] [base-files] dont change defaults for vm.min_free_kbytes on devices with <64MiB RAM

[Bastian Bittorf]

with 5c9cc7b7f8920944a413644e1c2ea23bfe655bcb we changed the default
value of 'vm.min_free_kbytes' from ~650 to 4096 kilobytes on 32MiB-RAM-devices.
This makes them hardly useable with a lot of OOM-crashes.

Change that and use 1024 kilobytes for 32MiB-RAM-devices.
For devices with more than 32MiB RAM we keep the behaviour / the values.

While we are at it, localize vars and read the memory without AWK/nonforking.

changes v1 -> v2: (suggestions from Felix Fietkau, Rafał Miłecki)
- keep -quiet option from sysctl
- use 1024 kilobyte on 32MiB-devices instead of the kernel default
- consistently use unit [MiB]
---
 package/base-files/files/etc/init.d/sysctl | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/package/base-files/files/etc/init.d/sysctl 
b/package/base-files/files/etc/init.d/sysctl
index a0daec0..7a16e01 100755
--- a/package/base-files/files/etc/init.d/sysctl
+++ b/package/base-files/files/etc/init.d/sysctl
@@ -4,16 +4,20 @@
 START=11
 
 set_vm_min_free() {
-   mem="$(grep MemTotal /proc/meminfo  | awk '{print $2}')"
-   if [ "$mem" -gt 65536 ]; then # 128M
+   local mem value
+
+   read -r _ mem _ http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] A Wiki for LEDE Documentation

[John Crispin]

On 16/09/2016 18:47, Alberto Bursi wrote:
> 
> 
> On 09/16/2016 06:23 AM, John Crispin wrote:
>>
>> On 15/09/2016 22:41, Alberto Bursi wrote:
>>> Note that I'm not talking about the wiki. That was not a major issue as
>>> being a separate thing it can be set up unofficially, or whatever.
>>> I am just arguing about principles here, as I'm spotting a possibly bad
>>> pattern where the same bad practices of OpenWRT can bite again.
>> i am spotting that you are missing the point. i agree that your thread
>> of argumentation was valid fro owrt. things were often not possible
>> without the approval of the grandmaster. here things are different. we
>> dished out commit access to lots of people. opened up the comms, became
>> very transparent and after you guys started a discussion on how the wiki
>> should go we did not intervene but simply endorsed it. this is very far
>> from the old pattern of modus operandi. however your call for strong
>> leadership and guidance sounds like a wish to return to that which i
>> think most people do not want to do. you are free to do as you please.
>> if you need something from other community members simply ask and you
>> will get an answer.
>>
> 
> 1. I'm not advocating for a Third LEDE Reich so please stop thinking I 
> am lol.
> 
> 2. I'm not talking of just the wiki, the answers I got from that 
> discussion did trigger this.

ah ok, was not aware that we were mixing topics here, i thought we were
discussing the wiki and forum.

> 
> jow said "don't hold back yourself waiting for a response from "the LEDE 
> devs" -
> 
> those who care about a wiki will likely endorse whatever good solution
> is proposed and the rest either has no opinion or time to participate in
> the decision making processes"
> 
> I was just pointing out that for people this isn't obvious, and that getting 
> any answer isn't a given.

i think you were just unlucky to not get some of the stuff below
answered immediately.

> 
> To make some examples, I posted some weeks back asking things and making 
> a proposal about kirkwoods, I got no answer.
> I also sent a mail to Felix I think as I saw he seemed interested in 
> Kirkwoods in the last meeting logs, still no answer.

i guess kirkwood is somewhat unmaintained at the moment. i dont have any
kirkwood hw and no access to the datasheets so i cant help i am afraid.

> There is a guy that posted a big pull request about Mikrotik devices and 
> after he fixed all stuff you asked him he got no answer for like a month 
> even after he asked if you had forgotten him. I mean how about posting 
> something like "we are busy, it will be merged next month"?

ok, the one big commit that has been dangling for ages. point taken
there is indeed one. i could argue that we merged over 1k other commits
in the past few months.

> I open a pull request to fix something about kirkwoods, someone assigns 
> it to himself, but then no answers or status updates for two weeks.
> Then there are other guys in this mailing lists that seem to have had 
> issues with this lack of people answering too, like fhfredi...@gmail.com.

again, point taken, a minuscule amount of patches in the region of less
than 0.5% has not been merged within a few days.

as jow said, dont take it personal. if people dont reply, be more
persistent. if all else fails hunt people down in IRC.

John

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Procd and askconsole

[John Crispin]

On 16/09/2016 17:59, Alberto Bursi wrote:
> 
> 
> On 09/16/2016 10:48 AM, Lebleu Pierre wrote:
>> Hi all,
>>
>> I am new to this mailing list and I would like to present me as Pierre.
>>
>> I recently play a bit with procd and I found an "issue". Indeed, if I do
>> a factory reset, I am able to login as root without login. I have some
>> scripts in /etc/uci-defaults and one of them set the password for the
>> root account. So, this behaviour looks like to me a bug.
>>
>> For my understanding, when procd reaches STATE_INIT, it runs
>> the inittab and one of them is "askconsole". The problem is the system
>> is not completely ready to receive the user : the hostname is not even
>> set.
>>
>> In the old sysvinit, the inittab contains an entry called "bootwait"
>> wich is executed after the termination of init (eg : "/etc/rc.d").
>> I purpose to move the "askconsole" entry to STATE_RUNNING or to create
>> a new entry called "askconsolewait" in order to keep backward
>> compatibility.
>>
>> diff --git a/inittab.c b/inittab.c
>> index ae2c431..2d590e4 100644
>> --- a/inittab.c
>> +++ b/inittab.c
>> @@ -228,6 +228,10 @@ static struct init_handler handlers[] = {
>>  .name = "respawn",
>>  .cb = rcrespawn,
>>  .multi = 1,
>> +   }, {
>> +   .name = "askconsolewait",
>> +   .cb = askconsole,
>> +   .multi = 1,
>>  }
>>   };
>>   
>> @@ -251,11 +255,9 @@ void procd_inittab_run(const char *handler)
>>   
>>  list_for_each_entry(a, , list)
>>  if (!strcmp(a->handler->name, handler)) {
>> -   if (a->handler->multi) {
>> -   a->handler->cb(a);
>> -   continue;
>> -   }
>>  a->handler->cb(a);
>> +   if (a->handler->multi)
>> +   continue;
>>  break;
>>  }
>>   }
>> diff --git a/state.c b/state.c
>> index 4ad9e2d..fe37419 100644
>> --- a/state.c
>> +++ b/state.c
>> @@ -128,6 +128,7 @@ static void state_enter(void)
>>   
>>  case STATE_RUNNING:
>>  LOG("- init complete -\n");
>> +   procd_inittab_run("askconsolewait");
>>  break;
>>   
>>  case STATE_SHUTDOWN:
>>
>> What is your view ? Thank you.
>>
>> Cheers,
>>
>> Pierre
>>
> Is this fixing this issue ? 
> https://bugs.lede-project.org/index.php?do=details_id=123
> 

no, totally unrelated, i have a fix for #123 in my local tree already
though. need to give it a bit more testing though.


> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] A Wiki for LEDE Documentation

[Alberto Bursi]

On 09/16/2016 06:23 AM, John Crispin wrote:
>
> On 15/09/2016 22:41, Alberto Bursi wrote:
>> Note that I'm not talking about the wiki. That was not a major issue as
>> being a separate thing it can be set up unofficially, or whatever.
>> I am just arguing about principles here, as I'm spotting a possibly bad
>> pattern where the same bad practices of OpenWRT can bite again.
> i am spotting that you are missing the point. i agree that your thread
> of argumentation was valid fro owrt. things were often not possible
> without the approval of the grandmaster. here things are different. we
> dished out commit access to lots of people. opened up the comms, became
> very transparent and after you guys started a discussion on how the wiki
> should go we did not intervene but simply endorsed it. this is very far
> from the old pattern of modus operandi. however your call for strong
> leadership and guidance sounds like a wish to return to that which i
> think most people do not want to do. you are free to do as you please.
> if you need something from other community members simply ask and you
> will get an answer.
>

1. I'm not advocating for a Third LEDE Reich so please stop thinking I 
am lol.

2. I'm not talking of just the wiki, the answers I got from that 
discussion did trigger this.

jow said "don't hold back yourself waiting for a response from "the LEDE 
devs" -

those who care about a wiki will likely endorse whatever good solution
is proposed and the rest either has no opinion or time to participate in
the decision making processes"

I was just pointing out that for people this isn't obvious, and that getting 
any answer isn't a given.

To make some examples, I posted some weeks back asking things and making 
a proposal about kirkwoods, I got no answer.
I also sent a mail to Felix I think as I saw he seemed interested in 
Kirkwoods in the last meeting logs, still no answer.
There is a guy that posted a big pull request about Mikrotik devices and 
after he fixed all stuff you asked him he got no answer for like a month 
even after he asked if you had forgotten him. I mean how about posting 
something like "we are busy, it will be merged next month"?
I open a pull request to fix something about kirkwoods, someone assigns 
it to himself, but then no answers or status updates for two weeks.
Then there are other guys in this mailing lists that seem to have had 
issues with this lack of people answering too, like fhfredi...@gmail.com.

-Alberto

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] A Wiki for LEDE Documentation

[Alberto Bursi]

On 09/16/2016 06:25 AM, John Crispin wrote:
>
> On 15/09/2016 22:50, Alberto Bursi wrote:
>> I said that for that it's better a "talk/discussion" page on a wiki,
>> because a forum needs more time investment than a wiki to be done right
>> and should be treated as its own project with its own volunteers and so
>> on, not as an appendage of the wiki.
>
> why does it need more time ? i would have expected it to be the other
> way round as a forum is useful even with little traffic while a wiki
> only makes sense when handling lots of content
>
Because a wiki is mostly an affair people goes and reads to do stuff on 
their own, while a forum requires constant interaction with people.

Once the wiki is fixed, maintaining it will be relatively fast unless 
you make big sweeping changes to LEDE every day.

I already said above that just making a forum and letting it run on its 
own like the OpenWRT forum will not be good.
Really, a LEDE forum isn't for posting funny cat pics and memes, most 
people will post there somewhat technical questions, and this means we 
should plan to have some volunteer that answers them (even if just with 
a link to the wiki or FAQ or whatever) and also does mod duties.
The general hope is to kick-start the forum community so eventually 
there will be other users in forum that answer questions, but if you 
just open the forum people will ask, not get answers, go away, and no 
community will form there.

-Albert

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] kernel: add additional gadget drivers

[Tim Harvey]

On Fri, Sep 16, 2016 at 6:02 AM, Rafał Miłecki  wrote:
> On 16 September 2016 at 14:53, John Crispin  wrote:
>> On 15/09/2016 16:51, Tim Harvey wrote:
>>> Add the following gadget driver modules:
>>>  - kmod-usb-gadget-ncm (g_ncm)
>>>  - kmod-usb-gadget-hid (g_hid)
>>>
>>> Signed-off-by: Tim Harvey 
>>> ---
>>>  package/kernel/linux/modules/usb.mk | 39 
>>> +
>>>  1 file changed, 39 insertions(+)
>>>
>>> diff --git a/package/kernel/linux/modules/usb.mk 
>>> b/package/kernel/linux/modules/usb.mk
>>> index 020f474..14c7050 100644
>>> --- a/package/kernel/linux/modules/usb.mk
>>> +++ b/package/kernel/linux/modules/usb.mk
>>> @@ -316,6 +316,45 @@ endef
>>>  $(eval $(call KernelPackage,usb-gadget-mass-storage))
>>>
>>>
>>> +define KernelPackage/usb-gadget-hid
>>> +  TITLE:=USB HID Gadget
>>> +  KCONFIG:=CONFIG_USB_G_HID
>>> +  DEPENDS:=+kmod-usb-gadget +kmod-usb-lib-composite
>>> +  FILES:= \
>>> + $(LINUX_DIR)/drivers/usb/gadget/libcomposite.ko \
>>
>> this is included here and ...
>>
>>> + $(LINUX_DIR)/drivers/usb/gadget/function/usb_f_hid.ko \
>>> + $(LINUX_DIR)/drivers/usb/gadget/legacy/g_hid.ko
>>> +  AUTOLOAD:=$(call AutoLoad,52,usb_f_hid g_hid)
>>> +  $(call AddDepends/usb)
>>> +endef
>>> +
>>> +define KernelPackage/usb-gadget-hid/description
>>> +  Kernel support for USB HID Gadget
>>> +endef
>>> +
>>> +$(eval $(call KernelPackage,usb-gadget-hid))
>>> +
>>> +
>>> +define KernelPackage/usb-gadget-ncm
>>> +  TITLE:=USB CDC Ethernet (NCM)
>>> +  KCONFIG:=CONFIG_USB_G_NCM
>>> +  DEPENDS:=+kmod-usb-gadget +kmod-usb-lib-composite
>>> +  FILES:= \
>>> + $(LINUX_DIR)/drivers/usb/gadget/libcomposite.ko \
>>
>> here again. this seems wrong and will result in an error when both are
>> installed and then one of the 2 is removed.
>
> Hint: a separated package for libcomposite.ko that will be selected by
> both of your packages.
>

Ooops - yes when I added back kmod-usb-lib-composite I can remove
libcomposite.ko from FILES. Also I need to pull u_ether.ko into its
own hidden dep as its now used by two things.

I will submit a v2. Thanks for the pointers!

Tim

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] [base-files] dont change defaults for vm.min_free_kbytes on devices with <64mb RAM

[Martin Tippmann]

On Fri, Sep 16, 2016 at 3:04 PM, Felix Fietkau  wrote:
> On 2016-09-16 11:31, Bastian Bittorf wrote:
>> with 5c9cc7b7f8920944a413644e1c2ea23bfe655bcb we changed the default
>> value from ~650 to 4096 kilobyte on 32mb-RAM-devices. This makes them
>> hardly useable with a lot of oom-crashes. Fix that and keep the default.
>> For devices with more than 32mb we keep the behaviour and tweak the value.
> How about setting it to 1024 for 32M? That will give drivers a bit more
> room without affecting memory usage that much.

A quick test: opkg works (update, list, install) , luci works mostly
with 1024 (installing packages via luci fails sometimes due to oom,
but that also happens with the lower default value..., everything else
looks good)

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Memory Usage of LEDE trunk on devices with only 32mb memory.

[Martin Tippmann]

On Fri, Sep 16, 2016 at 3:13 PM, Martin Tippmann  wrote:
> opkg, luci works fine on LEDE with 32mb devices again. This seems to
> be culprit, the kernel size increase is only ~100kb and I guess
> negligible.

Misread that, it's more like 800kb but still not a huge problem for now.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] kernel: add additional gadget drivers

[John Crispin]

Hi,


On 15/09/2016 16:51, Tim Harvey wrote:
> Add the following gadget driver modules:
>  - kmod-usb-gadget-ncm (g_ncm)
>  - kmod-usb-gadget-hid (g_hid)
> 
> Signed-off-by: Tim Harvey 
> ---
>  package/kernel/linux/modules/usb.mk | 39 
> +
>  1 file changed, 39 insertions(+)
> 
> diff --git a/package/kernel/linux/modules/usb.mk 
> b/package/kernel/linux/modules/usb.mk
> index 020f474..14c7050 100644
> --- a/package/kernel/linux/modules/usb.mk
> +++ b/package/kernel/linux/modules/usb.mk
> @@ -316,6 +316,45 @@ endef
>  $(eval $(call KernelPackage,usb-gadget-mass-storage))
>  
>  
> +define KernelPackage/usb-gadget-hid
> +  TITLE:=USB HID Gadget
> +  KCONFIG:=CONFIG_USB_G_HID
> +  DEPENDS:=+kmod-usb-gadget +kmod-usb-lib-composite
> +  FILES:= \
> + $(LINUX_DIR)/drivers/usb/gadget/libcomposite.ko \

this is included here and ...

> + $(LINUX_DIR)/drivers/usb/gadget/function/usb_f_hid.ko \
> + $(LINUX_DIR)/drivers/usb/gadget/legacy/g_hid.ko
> +  AUTOLOAD:=$(call AutoLoad,52,usb_f_hid g_hid)
> +  $(call AddDepends/usb)
> +endef
> +
> +define KernelPackage/usb-gadget-hid/description
> +  Kernel support for USB HID Gadget
> +endef
> +
> +$(eval $(call KernelPackage,usb-gadget-hid))
> +
> +
> +define KernelPackage/usb-gadget-ncm
> +  TITLE:=USB CDC Ethernet (NCM)
> +  KCONFIG:=CONFIG_USB_G_NCM
> +  DEPENDS:=+kmod-usb-gadget +kmod-usb-lib-composite
> +  FILES:= \
> + $(LINUX_DIR)/drivers/usb/gadget/libcomposite.ko \

here again. this seems wrong and will result in an error when both are
installed and then one of the 2 is removed.

John

> + $(LINUX_DIR)/drivers/usb/gadget/function/u_ether.ko \
> + $(LINUX_DIR)/drivers/usb/gadget/function/usb_f_ncm.ko \
> + $(LINUX_DIR)/drivers/usb/gadget/legacy/g_ncm.ko
> +  AUTOLOAD:=$(call AutoLoad,52,usb_f_ncm g_ncm)
> +  $(call AddDepends/usb)
> +endef
> +
> +define KernelPackage/usb-gadget-ncm/description
> +  Kernel support for USB CDC NCM gadget
> +endef
> +
> +$(eval $(call KernelPackage,usb-gadget-ncm))
> +
> +
>  define KernelPackage/usb-uhci
>TITLE:=Support for UHCI controllers
>KCONFIG:= \
> 

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] How do I run a script once after factory installation?

[John Crispin]

On 16/09/2016 14:14, J Mo wrote:
> 
> The router device that I'm currently working on has some goofy failover
> system where it has two roofs filesystems (UBI) on it's NAND flash.
> 
> A special partition has a "upgrade-in-progress" bit that gets set and I
> need to flip it back to 0x0 after a successful system bootup. If I
> don't, the bootcmd program in u-boot detects the bit, assumes an
> upgrade/installation failure, and fails back to the old/previous rootfs.
> 
> Currently, this only affects factory installations installed from the
> OEM web UI upgrade tool, but I might like to make sysupgraded
> installations use it. I am not sure yet if I want to bother supporting it.
> 
> Thus, this needs to happen only once after the system has been
> upgraded/installed by a factory installation, and optionally a
> sysupgrade installation.
> 
> So my questions are:
> 
> 1.) Is there a way to determine if the current boot was from a factory
> install vs sysupgrade?
not really. that would be device specific



> 2.) Where is the appropriate place to do a run-once kind of thing? Like
> /etc/uci-defaults/ or sysupgrade's restore_config function. This would
> be an S99-like task; run at the very end of the boot process once we are
> sure the system has booted successfully.
> 
> Any examples anyone can point me to of anything similar before I
> re-invent something that might already exist?
there are these


target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc
target/linux/brcm47xx/base-files/etc/uci-defaults/09_fix_crc
target/linux/bcm53xx/base-files/etc/uci-defaults/09_fix_crc
target/linux/ramips/base-files/etc/uci-defaults/09_fix-seama-header
target/linux/ar71xx/base-files/etc/uci-defaults/09_fix-trx-header

which all do essentially do what you want but for different platforms


> If this had to run on every single boot, even non-upgrade boots, I could
> probably work with that by checking if the upgrade-in-progress bit is
> even set, but I figured I would ask if I could do a "run once after
> factory install" kind of thing first.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] [base-files] dont change defaults for vm.min_free_kbytes on devices with <64mb RAM

[Bastian Bittorf]

with 5c9cc7b7f8920944a413644e1c2ea23bfe655bcb we changed the default
value from ~650 to 4096 kilobyte on 32mb-RAM-devices. This makes them
hardly useable with a lot of oom-crashes. Fix that and keep the default.
For devices with more than 32mb we keep the behaviour and tweak the value.
We dont suppress output of sysctl-command, so the use has a chance to spot it.

While we are at it, localize vars and read the memory without AWK/nonforking.

Signed-off-by: Bastian Bittorf 
---
 package/base-files/files/etc/init.d/sysctl | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/package/base-files/files/etc/init.d/sysctl 
b/package/base-files/files/etc/init.d/sysctl
index a0daec0..c3b48f4 100755
--- a/package/base-files/files/etc/init.d/sysctl
+++ b/package/base-files/files/etc/init.d/sysctl
@@ -4,17 +4,19 @@
 START=11
 
 set_vm_min_free() {
-   mem="$(grep MemTotal /proc/meminfo  | awk '{print $2}')"
-   if [ "$mem" -gt 65536 ]; then # 128M
+   local mem value
+
+   read -r _ mem _ http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Memory Usage of LEDE trunk on devices with only 32mb memory.

[Bastian Bittorf]

* Jo-Philipp Wich  [15.09.2016 16:58]:
>   http://git.lede-project.org/5c9cc7b7f8920944a413644e1c2ea23bfe655bcb ?

indeed! this makes a huge difference on 32mb devices.
so my proposal is:

1) dont touch vm.min_free_kbytes for 32mb-devices
2) when changing defaults with 'sysctl' dont be quiet,
so the user has at least a chance to debug this.

patch is on the way...bye, bastian

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] A Wiki for LEDE Documentation

[Raylynn Knight]

I will be a contributor/user of whatever wiki is provided and have used both 
Dokuwiki and the Semantic MediaWiki (used by WikiDevi) as I’ve contributed to 
both the OpenWrt Wiki and MediaWiki.  I think my preference would be for 
DokuWiki.  

I have experience installing OpenWrt on over 50 different supported devices and 
a few unsupported devices.  As soon as the wiki is available I’d be willing to 
start entering data on the devices I have experience with.  

Ray

> On Sep 14, 2016, at 6:10 PM, Alberto Bursi  wrote:
> 
> 
> 
> On 09/14/2016 10:31 PM, Thomas Endt wrote:
>> I advise to setup a Dokuwiki, if no one else has good reasons
>> against it. Please slow me down in case I'm going too fast.
> Ok for me. As long as the theme is something modern and readable, 
> registered users/gardeners can rollboack edits, and there is a wysiwyg 
> editor, I'm ok with it. (Docuwiki has these features at least)
>> Oh, what is really needed for this build: Discussion between the volunteers,
>> either via mailing list, or via forum. I'd prefer the latter, since it's
>> easier to access for the standard user than a mailing list.
> Well, of course a forum is better, but it also carries much more work 
> than a wiki (I mean much more work to not just have a massive empty 
> space where any post echoes loudly like current OpenWRT forum, that does 
> not do any good).
> 
> I mean, hoping someone will answer people's questions is certainly good 
> and all, but to truly kick-start a forum (i.e. attract people into it) 
> you need some semi-official guys that camp there and (do their best to) 
> answer people's questions, and that might become a heavy burden fast.
> 
> I think we should avoid forums for now and should lay out the wiki's 
> plans in a wiki page and activate a plugin (there are at least a couple 
> for docuwiki) to make a "talk" page or "discussion" page like 
> Wikipedia's for wiki volunteer interactions.
> 
> -Albert
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev