Re: [LEDE-DEV] [PATCH][ubox] Fixes log read starvation issue after threshold reached
Hi Ron,
thanks for your effort in sharing your fixes.
I have troubles understanding your patch, please find some comments
inline below.
~ Jo
--
On 07/11/2017 09:04 PM, Ron Brash wrote:
> This patch fixes a logread starvation error, which occurs after many
> logs are generated (around 16k if defaults are used). The log read
Do you have an easy test case for this? Is piping ~16K plaintext to the
logger enough to trigger the starvation? I'd like to understand the
problem some more before judging the patch.
> process seems to halt silently and yet continues running. A restart
> of the log services fixes it.
>
> This is problematic because logs should be logged, instead of silently lost
>
> Signed-off-by: “Ron Brash <“ron.br...@gmail.com”>
> ---
> log/logread.c | 24 ++--
> 1 file changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/log/logread.c b/log/logread.c
> index edac1d9..7eb028e 100644
> --- a/log/logread.c
> +++ b/log/logread.c
> @@ -230,8 +230,10 @@ static void logread_fd_data_cb(struct ustream *s,
> int bytes)
> break;
>
> cur_len = blob_len(a) + sizeof(*a);
> - if (len < cur_len)
> + if (len < cur_len) {
> + ustream_consume(s, len);
> break;
> + }
>
> log_notify(a);
> ustream_consume(s, cur_len);
> @@ -240,14 +242,28 @@ static void logread_fd_data_cb(struct ustream
> *s, int bytes)
> uloop_end();
> }
>
> +static void notify_fd_remove_cb();
If you move the static function here you do not need the forward
declaration.
> +
> static void logread_fd_cb(struct ubus_request *req, int fd)
> {
> static struct ustream_fd test_fd;
> -
> + uloop_register_notify_fd_remove(fd, notify_fd_remove_cb);
What is "uloop_register_notify_fd_remove()" ? It is not part of libubox
as far as I can see. Is it a function introduced by some other custom
changes of yours?
> test_fd.stream.notify_read = logread_fd_data_cb;
> ustream_fd_init(&test_fd, fd);
> }
>
> +struct ubus_context *context;
> +uint32_t ctx_id;
> +struct blob_buf * bb;
> +struct ubus_request request;
The "request" and "ctx_id" variables appear to be local to
"notify_fd_remove_cb()" and should be moved inside the function.
The "context" and "bb" variables should be declared "static" if they're
outside of the function context, however I am not sure if we actually
need them because those values can be usually obtained elsewhere in the
callback.
> +
> +static void notify_fd_remove_cb() {
> + ubus_lookup_id(context, "log", &ctx_id);
> + ubus_invoke_async(context, ctx_id, "read", bb->head, &request);
> + request.fd_cb = logread_fd_cb;
> + ubus_complete_request_async(context, &request);
> +}
> +
> int main(int argc, char **argv)
> {
> static struct ubus_request req;
> @@ -362,6 +378,9 @@ int main(int argc, char **argv)
> sender.fd = STDOUT_FILENO;
> }
>
> + context = ctx;
> + bb = &b;
> +
> ubus_invoke_async(ctx, id, "read", b.head, &req);
> req.fd_cb = logread_fd_cb;
> ubus_complete_request_async(ctx, &req);
> @@ -374,3 +393,4 @@ int main(int argc, char **argv)
>
> return ret;
> }
> +
> --
> 2.7.4
>
> ___
> 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
[LEDE-DEV] [PATCH] kernel: update kernel 4.9 to 4.9.37
- Refreshed all patches - Removed upstreamed - Adapted 4 patches: 473-fix-marvell-phy-initialization-issues.patch --- Removed hunk 5 which got upstreamed 403-net-phy-avoid-setting-unsupported-EEE-advertisments.patch 404-net-phy-restart-phy-autonegotiation-after-EEE-advert.patch -- Adapted these 2 RFC patches, merging the delta's from an upstream commit (see below) which made it before these 2. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux- stable.git/commit/?h=v4.9.36&id=97ace183074d306942b903a148aebd5d061758f0 180-usb-xhci-add-support-for-performing-fake-doorbell.patch --- - Moved fake_doorbell bitmask due to new item Compile tested on: cns3xxx, imx6 Run tested on: cns3xxx, imx6 Signed-off-by: Koen Vandeputte --- include/kernel-version.mk | 4 +- ...d-firmware-loader-for-uPD720201-and-uPD72.patch | 6 +-- .../802-usb-xhci-force-msi-renesas-xhci.patch | 4 +- ...y-Initialize-mdio-clock-at-probe-function.patch | 48 ...-add-support-for-performing-fake-doorbell.patch | 6 +-- ...cm2835-Load-driver-early-and-support-lega.patch | 8 ++-- ...e-bcm2835-Fix-cyclic-DMA-period-splitting.patch | 39 - .../cns3xxx/patches-4.9/075-spi_support.patch | 2 +- ...0002-mtd-spi-nor-fix-spansion-quad-enable.patch | 4 +- ...-nor-Add-support-for-S3AN-spi-nor-devices.patch | 6 +-- ...-rename-SPINOR_OP_-macros-of-the-4-byte-a.patch | 2 +- ...-add-a-stateless-method-to-support-memory.patch | 2 +- ...k-to-of_scan_flat_dt-before-accessing-ini.patch | 30 - ...o_set_value_cansleep-for-setting-chipsele.patch | 2 +- ...465-m25p80-mx-disable-software-protection.patch | 2 +- .../666-Add-support-for-MAP-E-FMRs-mesh-mode.patch | 22 +- ...jecting-with-source-address-failed-policy.patch | 2 +- ...80-NET-skip-GRO-for-foreign-MAC-addresses.patch | 8 ++-- .../generic/patches-4.9/701-phy_extension.patch| 2 +- .../702-phy_add_aneg_done_function.patch | 4 +- ...-add-detach-callback-to-struct-phy_driver.patch | 2 +- .../patches-4.9/704-phy-no-genphy-soft-reset.patch | 6 +-- .../710-phy-add-mdio_register_board_info.patch | 2 +- .../generic/patches-4.9/721-phy_packets.patch | 2 +- .../generic/patches-4.9/902-debloat_proc.patch | 2 +- .../130-pinctrl-ipq4019-add-pinctrl.patch | 51 -- .../0093-spi-double-time-out-tolerance.patch | 37 .../mediatek/patches-4.9/0096-dsa-multi-cpu.patch | 4 +- ...ovide-a-hook-for-link-up-link-down-events.patch | 2 +- ...-phy-move-phy-MMD-accessors-to-phy-core.c.patch | 4 +- ...e-phy_-read-write-_mmd-generic-MMD-access.patch | 2 +- ...oid-setting-unsupported-EEE-advertisments.patch | 13 -- ...tart-phy-autonegotiation-after-EEE-advert.patch | 9 ++-- ...phy-add-802.3-clause-45-support-to-phylib.patch | 6 +-- ...hook-up-clause-45-autonegotiation-restart.patch | 2 +- ...it-out-PHY-speed-and-duplex-string-genera.patch | 2 +- ...e-phy_lookup_setting-and-guts-of-phy_supp.patch | 2 +- .../415-phylink-add-phylink-infrastructure.patch | 2 +- ...-marvell-88E1512-add-flow-control-support.patch | 2 +- ...-marvell-88E-add-flow-control-support.patch | 2 +- ...-marvell-88E1540-add-flow-control-support.patch | 2 +- ...35-net-phy-fix-marvell-phy-status-reading.patch | 26 --- ...473-fix-marvell-phy-initialization-issues.patch | 10 - ...mtd-nor-support-mtd-name-from-device-tree.patch | 4 +- .../0054-mtd-add-chunked-read-io-to-m25p80.patch | 4 +- 45 files changed, 85 insertions(+), 318 deletions(-) delete mode 100644 target/linux/bcm53xx/patches-4.9/060-0001-net-phy-Initialize-mdio-clock-at-probe-function.patch delete mode 100644 target/linux/brcm2708/patches-4.9/950-0187-dmaengine-bcm2835-Fix-cyclic-DMA-period-splitting.patch delete mode 100644 target/linux/generic/patches-4.9/121-of-Add-check-to-of_scan_flat_dt-before-accessing-ini.patch delete mode 100644 target/linux/ipq806x/patches-4.9/130-pinctrl-ipq4019-add-pinctrl.patch delete mode 100644 target/linux/lantiq/patches-4.9/0093-spi-double-time-out-tolerance.patch delete mode 100644 target/linux/mvebu/patches-4.9/435-net-phy-fix-marvell-phy-status-reading.patch diff --git a/include/kernel-version.mk b/include/kernel-version.mk index b9f76a2..3033060 100644 --- a/include/kernel-version.mk +++ b/include/kernel-version.mk @@ -4,11 +4,11 @@ LINUX_RELEASE?=1 LINUX_VERSION-3.18 = .43 LINUX_VERSION-4.4 = .74 -LINUX_VERSION-4.9 = .34 +LINUX_VERSION-4.9 = .37 LINUX_KERNEL_HASH-3.18.43 = 1236e8123a6ce537d5029232560966feed054ae31776fe8481dd7d18cdd5492c LINUX_KERNEL_HASH-4.4.74 = c319ad6150d112bd4f8c9d1427868eeafd3ab461becf9457f814e4ba7c57808e -LINUX_KERNEL_HASH-4.9.34 = 13d159d1b1fa41ea19fcc2defe09d7532f312ee0b8279b8e12c961d8b02a4546
Re: [LEDE-DEV] procd: cherry-pick kernel watchdog start/stop to lede-17.01 branch
> On Jul 12, 2017, at 12:24 PM, Matthias Schiffer > wrote: > > On 07/12/2017 08:02 PM, Philip Prindeville wrote: >> >>> On Jul 11, 2017, at 3:19 AM, Hans Dedecker wrote: >>> >>> Hi, >>> >>> I would like to cherry-pick the start/stop kernel watchdog support to >>> the lede-17.01 procd branch : >>> >>> e5e99c4 watchdog: add support for starting/stopping kernel watchdog >>> >>> It allows to gracefully stop the kernel watchdog via ubus which was >>> before not possible as only the user space watchdog kicking could be >>> stopped. >>> >>> If nobody objects within the next few days I will take it as a passive >>> consensus and update the procd lede-17.01 branch and the procd package >>> Makefile in the lede-17.01 branch. >>> >>> Thx, >>> Hans >> >> >> Hi Hans! >> >> I’ve not been following this too closely, so forgive me if the question is a >> bit naive. >> >> Since the sysupgrade process involves replacing procd now, would the >> watchdog need to be stopped as procd exits so that the hardware doesn’t >> reset itself during a particularly length update? Let’s say you have a >> large FLASH with slow write times… that could take a long time and I don’t >> want a hardware watchdog thinking that the system has hung… >> >> Thanks, >> >> -Philip >> > > Hi, > the watchdog file descriptor is passed from procd to upgraded, which will > continue to trigger the watchdog during the upgrade. > > Matthias Awesome, thank you! ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] procd: cherry-pick kernel watchdog start/stop to lede-17.01 branch
On 07/12/2017 08:02 PM, Philip Prindeville wrote: > >> On Jul 11, 2017, at 3:19 AM, Hans Dedecker wrote: >> >> Hi, >> >> I would like to cherry-pick the start/stop kernel watchdog support to >> the lede-17.01 procd branch : >> >> e5e99c4 watchdog: add support for starting/stopping kernel watchdog >> >> It allows to gracefully stop the kernel watchdog via ubus which was >> before not possible as only the user space watchdog kicking could be >> stopped. >> >> If nobody objects within the next few days I will take it as a passive >> consensus and update the procd lede-17.01 branch and the procd package >> Makefile in the lede-17.01 branch. >> >> Thx, >> Hans > > > Hi Hans! > > I’ve not been following this too closely, so forgive me if the question is a > bit naive. > > Since the sysupgrade process involves replacing procd now, would the watchdog > need to be stopped as procd exits so that the hardware doesn’t reset itself > during a particularly length update? Let’s say you have a large FLASH with > slow write times… that could take a long time and I don’t want a hardware > watchdog thinking that the system has hung… > > Thanks, > > -Philip > Hi, the watchdog file descriptor is passed from procd to upgraded, which will continue to trigger the watchdog during the upgrade. Matthias signature.asc Description: OpenPGP digital signature ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] procd: cherry-pick kernel watchdog start/stop to lede-17.01 branch
> On Jul 11, 2017, at 3:19 AM, Hans Dedecker wrote: > > Hi, > > I would like to cherry-pick the start/stop kernel watchdog support to > the lede-17.01 procd branch : > > e5e99c4 watchdog: add support for starting/stopping kernel watchdog > > It allows to gracefully stop the kernel watchdog via ubus which was > before not possible as only the user space watchdog kicking could be > stopped. > > If nobody objects within the next few days I will take it as a passive > consensus and update the procd lede-17.01 branch and the procd package > Makefile in the lede-17.01 branch. > > Thx, > Hans Hi Hans! I’ve not been following this too closely, so forgive me if the question is a bit naive. Since the sysupgrade process involves replacing procd now, would the watchdog need to be stopped as procd exits so that the hardware doesn’t reset itself during a particularly length update? Let’s say you have a large FLASH with slow write times… that could take a long time and I don’t want a hardware watchdog thinking that the system has hung… Thanks, -Philip ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH v2] toolchain/arc: update to the most recent release arc-2017.03
arc-2017.03 is the most recent release toolchain for ARC cores
and it is based on upstream Binutils 2.28 and GCC 6.3.0
Signed-off-by: Evgeniy Didin
Cc: Alexey Brodkin
Cc: John Crispin
Cc: Hauke Mehrtens
---
Changes v1 -> v2:
*In toolchain/gcc/common.mk add '-release' to line 'PKG_REV:=2017.03'.
Now it is 'PKG_REV:=2017.03-release' and symlink at
build_dir/toolchain-arc_arc700_gcc-arc-2017.03-release_uClibc/gcc
pointing to the right place.
package/devel/gdb-arc/Makefile| 6 +++---
toolchain/binutils/Config.in | 8
toolchain/binutils/Config.version | 4 ++--
toolchain/binutils/Makefile | 6 +++---
toolchain/gcc/Config.in | 8
toolchain/gcc/Config.version | 8
toolchain/gcc/common.mk | 8
.../001-revert_register_mode_search.patch | 0
.../002-case_insensitive.patch| 0
.../010-documentation.patch | 0
.../230-musl_libssp.patch | 0
.../280-musl-disable-ifunc-by-default.patch | 0
.../300-mips_Os_cpu_rtx_cost_model.patch | 0
.../800-arm_v5te_no_ldrd_strd.patch | 0
.../810-arm-softfloat-libgcc.patch| 0
.../820-libgcc_pic.patch | 0
.../830-arm_unbreak_armv4t.patch | 0
.../840-armv4_pass_fix-v4bx_to_ld.patch | 0
.../850-use_shared_libgcc.patch | 0
.../851-libgcc_no_compat.patch| 0
.../870-ppc_no_crtsavres.patch| 0
.../880-no_java_section.patch | 0
.../881-no_tm_section.patch | 0
.../900-bad-mips16-crt.patch | 0
.../910-mbsd_multi.patch | 0
.../920-specs_nonfatal_getenv.patch | 0
.../930-fix-mips-noexecstack.patch| 0
.../940-no-clobber-stamp-bits.patch | 0
.../950-cpp_file_path_translation.patch | 0
toolchain/gdb/Makefile| 6 +++---
30 files changed, 27 insertions(+), 27 deletions(-)
rename toolchain/gcc/patches/{arc-2016.09-release =>
arc-2017.03-release}/001-revert_register_mode_search.patch (100%)
rename toolchain/gcc/patches/{arc-2016.09-release =>
arc-2017.03-release}/002-case_insensitive.patch (100%)
rename toolchain/gcc/patches/{arc-2016.09-release =>
arc-2017.03-release}/010-documentation.patch (100%)
rename toolchain/gcc/patches/{arc-2016.09-release =>
arc-2017.03-release}/230-musl_libssp.patch (100%)
rename toolchain/gcc/patches/{arc-2016.09-release =>
arc-2017.03-release}/280-musl-disable-ifunc-by-default.patch (100%)
rename toolchain/gcc/patches/{arc-2016.09-release =>
arc-2017.03-release}/300-mips_Os_cpu_rtx_cost_model.patch (100%)
rename toolchain/gcc/patches/{arc-2016.09-release =>
arc-2017.03-release}/800-arm_v5te_no_ldrd_strd.patch (100%)
rename toolchain/gcc/patches/{arc-2016.09-release =>
arc-2017.03-release}/810-arm-softfloat-libgcc.patch (100%)
rename toolchain/gcc/patches/{arc-2016.09-release =>
arc-2017.03-release}/820-libgcc_pic.patch (100%)
rename toolchain/gcc/patches/{arc-2016.09-release =>
arc-2017.03-release}/830-arm_unbreak_armv4t.patch (100%)
rename toolchain/gcc/patches/{arc-2016.09-release =>
arc-2017.03-release}/840-armv4_pass_fix-v4bx_to_ld.patch (100%)
rename toolchain/gcc/patches/{arc-2016.09-release =>
arc-2017.03-release}/850-use_shared_libgcc.patch (100%)
rename toolchain/gcc/patches/{arc-2016.09-release =>
arc-2017.03-release}/851-libgcc_no_compat.patch (100%)
rename toolchain/gcc/patches/{arc-2016.09-release =>
arc-2017.03-release}/870-ppc_no_crtsavres.patch (100%)
rename toolchain/gcc/patches/{arc-2016.09-release =>
arc-2017.03-release}/880-no_java_section.patch (100%)
rename toolchain/gcc/patches/{arc-2016.09-release =>
arc-2017.03-release}/881-no_tm_section.patch (100%)
rename toolchain/gcc/patches/{arc-2016.09-release =>
arc-2017.03-release}/900-bad-mips16-crt.patch (100%)
rename toolchain/gcc/patches/{arc-2016.09-release =>
arc-2017.03-release}/910-mbsd_multi.patch (100%)
rename toolchain/gcc/patches/{arc-2016.09-release =>
arc-2017.03-release}/920-specs_nonfatal_getenv.patch (100%)
rename toolchain/gcc/patches/{arc-2016.09-release =>
arc-2017.03-release}/930-fix-mips-noexecstack.patch (100%)
rename toolchain/gcc/patches/{
Re: [LEDE-DEV] [PATCH] block: support /dev/xvd* nodes
>> Xen provides paravirtualized block devices which most often appear as >> /dev/xvd*. This patch adds this pattern to those known to the block >> utilitiy. These devices require a kernel compiled with the xen-blkfront >> driver. > Having a closer look I just noticed that there are no XEN options set > for x86/64 kernel. Maybe this should be changed, or is the the x86/64 > subtarget useful as a Xen domU right now? > If not, it'd be great if you can test and suggest the necessary config > changes to achieve this as well. For some information, see the recent thread on lede-dev with the subject "Xen PVHVM drivers." x86/64 is indeed useful as a DomU domain, but its performance suffers from the lack of PVHVM driver support. -- Mike :wq ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] block: support /dev/xvd* nodes
On Wed, Jul 12, 2017 at 07:14:04AM -0400, W. Michael Petullo wrote:
> From bc848f9f3d0ffb9aa114c7faa3916f059f5616b2 Mon Sep 17 00:00:00 2001
> From: "W. Michael Petullo"
> Date: Wed, 12 Jul 2017 07:02:18 -0400
> Subject: [PATCH] block: support /dev/xvd* nodes
> To: LEDE Development List
>
> Xen provides paravirtualized block devices which most often appear as
> /dev/xvd*. This patch adds this pattern to those known to the block
> utilitiy. These devices require a kernel compiled with the xen-blkfront
> driver.
Having a closer look I just noticed that there are no XEN options set
for x86/64 kernel. Maybe this should be changed, or is the the x86/64
subtarget useful as a Xen domU right now?
If not, it'd be great if you can test and suggest the necessary config
changes to achieve this as well.
>
> Signed-off-by: W. Michael Petullo
> ---
> block.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/block.c b/block.c
> index d5c3937..3e4cfb5 100644
> --- a/block.c
> +++ b/block.c
> @@ -530,6 +530,7 @@ static void cache_load(int mtd)
> _cache_load("/dev/hd*");
> _cache_load("/dev/md*");
> _cache_load("/dev/vd*");
> + _cache_load("/dev/xvd*");
> _cache_load("/dev/mapper/*");
> }
>
> --
> 2.13.0
>
>
> ___
> 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
[LEDE-DEV] [PATCH] block: support /dev/xvd* nodes
>From bc848f9f3d0ffb9aa114c7faa3916f059f5616b2 Mon Sep 17 00:00:00 2001
From: "W. Michael Petullo"
Date: Wed, 12 Jul 2017 07:02:18 -0400
Subject: [PATCH] block: support /dev/xvd* nodes
To: LEDE Development List
Xen provides paravirtualized block devices which most often appear as
/dev/xvd*. This patch adds this pattern to those known to the block
utilitiy. These devices require a kernel compiled with the xen-blkfront
driver.
Signed-off-by: W. Michael Petullo
---
block.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/block.c b/block.c
index d5c3937..3e4cfb5 100644
--- a/block.c
+++ b/block.c
@@ -530,6 +530,7 @@ static void cache_load(int mtd)
_cache_load("/dev/hd*");
_cache_load("/dev/md*");
_cache_load("/dev/vd*");
+ _cache_load("/dev/xvd*");
_cache_load("/dev/mapper/*");
}
--
2.13.0
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] ECDSA support in dropbear (Was: Planning v17.01.2)
Hi, On Thu, Jun 15, 2017 at 04:41:50PM +0200, Jo-Philipp Wich wrote: > > ... and, if I may throw my EUR 0.02 in, why not recompile dropbear > > with "elliptic curve" support? > > whats the size impact? There is already an option DROPBEAR_ECC to enable ECDSA, disabled by default, and it adds 23 KB to the MIPS binary. See https://bugs.lede-project.org/index.php?do=details&task_id=786 for the same request. Baptiste signature.asc Description: PGP signature ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
