Re: [LEDE-DEV] [PATCH v2] [base-files] dont change defaults for vm.min_free_kbytes on devices with <64MiB RAM
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 [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
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
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
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, &actions, 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&task_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
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
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] Procd and askconsole
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, &actions, 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&task_id=123 ___ 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
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
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.
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] [base-files] dont change defaults for vm.min_free_kbytes on devices with <64mb RAM
On 16 September 2016 at 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. > We dont suppress output of sysctl-command, so the use has a chance to spot it. s/kilobyte/kilobytes/ s/mb/ MiB/ s/dont/don't/ > While we are at it, localize vars and read the memory without AWK/nonforking. While you are at it, it would be great if you could use "MiB" in code as well. ___ 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.
On Thu, Sep 15, 2016 at 5:19 PM, Martin Tippmann wrote: > I have to do more testing through, this was just a quick look on a > CC15 Freifunk Router. Hi, Basti already send a patch and it looks like it's just this setting that causes problems: CC15.05.1 on 1043nd: root@openwrt:/tmp# cat /proc/meminfo MemTotal: 28580 kB MemFree:9784 kB MemAvailable: 15812 kB current LEDE with vm.min_free_kbytes: root@lede:~# cat /proc/meminfo MemTotal: 27828 kB MemFree:9788 kB MemAvailable: 7792 kB current LEDE without the vm.min_free_kbytes setting: root@lede:~# cat /proc/meminfo MemTotal: 27828 kB MemFree:9996 kB MemAvailable: 15636 kB 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. regards Martin ___ 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
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. -- Rafał ___ 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
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. > We dont suppress output of sysctl-command, so the use has a chance to spot it. I'd like to keep the -q. I don't see the point in adding some permanent logspam that is completely irrelevant for most people. - Felix ___ 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
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?
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] How do I run a script once after factory installation?
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? 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? 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. Thanks in advance ___ 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
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] Procd and askconsole
On 16/09/2016 10:48, 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, &actions, 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 > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev > Hi Pierre, just to be clear, you mean that there is a short timeslot between inittab/askconsole and uci-defaults during which a passwordless login is possible and you would liek to prevent this ? if i understood the problem corretly please simply set ttylogin=1 here -> https://git.lede-project.org/?p=source.git;a=blob;f=package/base-files/files/bin/config_generate;h=80ed61b9e2dabf6f2f99102345be3da60097af3e;hb=HEAD#l231 that should make the image boot with password login required even if no password is set. the normal use case is that one flashes, enables the flag and then upon second bootup the unit will require a login. in your use case you already want the password protection on the very first boot i think John ___ 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.
* 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
[LEDE-DEV] Procd and askconsole
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, &actions, 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 ___ 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
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