Re: [OpenWrt-Devel] OpenWrt 19.03 plans
Or that is $0.023647, anyway. :-) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt 19.03 plans
On 4/9/19 7:53 AM, Vincent Wiemann wrote: Hi Bjørn, routers are critical infrastructure. We should try to achieve the best we can. One of the reasons for the Lede split was that problems were procrastinated and accumulated over the release timeline. That's the reason why we should release less often, but with a higher quality. If problems delay a release that is a sign of taking responsibility. Some time ago a friend of mine told me that they have a problem with tickets that nobody wants to take care of. I told him when those tickets appear he should automatically assign them to all people with highest priority after a due date even if it is a minor issue. Productivity has increased rapidly since then. If a device is not supported in a specific release, that might give someone the stimulus to sit down and get this device working again. E.g. many devices have a partition layout on which a bigger kernel does not fit. It is possible to change the partition layout in most cases requiring a modification of the U-Boot boot environment variable. So hard it sounds unfortunately someone needs to be urged to do it. It's the same with porting ar71xx to ath79... When we stop generating ar71xx images some device owners wonder why there is no new release for it. They become aware that they need to sort of add support for this device as if it was a new device support and they might do it. Urging is a bad word, but we need to motivate people to do changes which are not of the fun kind or we might end up in a mess again. Regards, Vincent Wiemann On 09.04.2019 11:02, Bjørn Mork wrote: Jo-Philipp Wich writes: Is there any kind of "official" roadmap/checklist available what "needs" to be done? not that I am aware of, but from the top of my head: - make sure all targets are ported properly to 4.14 - disable all devices which cannot cannot handle the increased kernel size anymore - drop all targets which are not ported to 4.14 - fix important open issues in the tracker Apologies if this is out of line... I just fealt the urge to post my personal opinion, FWIW. It seems to me that you are setting way too high standards for yourselves. From my point of view, the OpenWrt master branch is almost always in a releasable state. The OpenWrt development and review process ensures an extremely high quality, even for targets which are considered WiP. There are very few days over the last 6 months where you could not have decided to cut a release branch, and got away with it. It's something to be proud of! But you need to tell the rest of the world that you are proud of this by making releases. You should accept that the targets which are ported properly to 4.14 defines "all targets" for the next release. It's not the other way round. Any remaining targets which can be expected to be ported to 4.14 or later, if any, can and should be deferred for a later release. Note that accepting this means that there could be a "next release" in 2019 too... You should also accept that there will be unfixed important open issues at all times. You can't fix them all. To make a release, these issues will either have to be - ignored for that release, - demoted to less important. or - removed by removing the feature/target/whatever is affected by the issue from the release Look at the Debian "release critical" bug handling. It's not really about fixing all the RC bugs, but dealing with them. I realize that actually making a release is real work too, and that this has to take some time after making the initial cut. But delaying the cut for the master branch to get in an even "more ready" state is not really helping... Just my .021 € (considering inflation) Bjørn Hi Bjorn, I agree with you on this one. New OpenWrt adopted a different working model from LEDE. That is staging trees and more careful testing before actual master commits. Long ago are the days when someone thought they were special, commit without review, and just blow up the nightly builds. OpenWrt should release regularly and it should be an editing (cutting) event. Target not on envisioned kernel, cut. Package not core and sketchy, cut. What's left is pretty good. With a variety of targets and volunteer support team bugs will happen. You can test to high confidence, but in such situations nothing is 100%. Instead, you just need to be prepared to deal with them in a timely matter. Just my $0.018649 exchanged at 20190410 04:00 Eric ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] umbim: registration set support
Bjørn Mork writes: > Ingo Feinerer writes: > >> anyone willing to review/commit this diff? >> >> http://lists.infradead.org/pipermail/openwrt-devel/2019-January/015445.html >> http://lists.infradead.org/pipermail/openwrt-devel/2019-January/015444.html > > > I assume John is very busy based on currently observed activity. So you > may have to be patient... > > The patch is registered in patchwork, so it's safely queued and will not > be lost: http://patchwork.ozlabs.org/patch/1022983/ Is there anything I or anyone else can do to help here? There are far too many patches like this one just sitting in patchwork. Pull requests on github works really well for the repos there. Thanks a lot to all the hard working reviewers/committers! But stuff like umbim here, and the other repos only avilable on git.openwrt.org, seems to depend on single maintainers. That is a problem for a volunteer project. You can't depend on people having infinite spare time. Very few have... Definitely not blaming anyone for lack of time. But is there any chance someone else can push a few patches to umbim.git? And maybe look through patchwork for anything else currently falling through the cracks? Thanks, Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] mtd: sysupgrade: Is `mtd write` Correct for NAND-Based Devices?
On 09/04/19 20:44, Jeff Kletsky wrote: In going through code used by a port of an IPQ4019 device, I see that target/linux/ipq40xx/base-files/lib/upgrade/linksys.sh in platform_do_upgrade_linksys() writes the image using get_image "$1" | mtd write - $part_label This surprises me as I had thought that NAND-based flash should use NAND utilities because of the possibility of bad blocks and metadata. I might be horribly mistaken, but I thought the mtd tool used in OpenWrt is indeed aware of raw flash writing and bad block handling. See the source here (yes it is a custom OpenWrt tool) https://github.com/openwrt/openwrt/blob/master/package/system/mtd/src/mtd.c -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] mtd: sysupgrade: Is `mtd write` Correct for NAND-Based Devices?
In going through code used by a port of an IPQ4019 device, I see that
target/linux/ipq40xx/base-files/lib/upgrade/linksys.sh
in platform_do_upgrade_linksys()
writes the image using
get_image "$1" | mtd write - $part_label
This surprises me as I had thought that NAND-based flash should use
NAND utilities because of the possibility of bad blocks and metadata.
The OEM firmware follows more of what I had expected to see:
ubifs_v1.1.4/usr/sbin/update_defs (Linksys OEM)
in erase_and_program()
if [ ${FLASH_TYPE} = "MTD_NANDFLASH" ]; then
echo -ne "\tErasing... /dev/$2\n" >> /dev/console
if [ "$VERBOSE" = "yes" ]; then
# flash_eraseall -j /dev/$2
flash_erase /dev/$2 0 0
else
# flash_eraseall -q -j /dev/$2
flash_erase -q /dev/$2 0 0
fi
check_error
echo -ne "\tProgramming... /dev/$2\n" >> /dev/console
if [ "$VERBOSE" = "yes" ]; then
#nandwrite -m -a -p /dev/$2 $3
nandwrite -p /dev/$2 $3
else
#nandwrite -q -m -a -p /dev/$2 $3
nandwrite -q -p /dev/$2 $3
fi
check_error
fi
While I don't have any bad blocks in my NAND (yet), should this be changed
to use the NAND-based utilities in a separate patch?
Jeff
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] fstools: block: make extroot mount preparation more robust
The extroot mount preparation code for r/w rootfs overlay discovery, and
determining the user-defined /etc/config/fstab location within, would only
discover overlays residing on JFFS2 or UBIFS MTD storage.
This led to attempts at loading the uci fstab configuration without the
required /tmp/overlay directory prefix on devices with a non-MTD r/w
rootfs overlay, and thus failure to find any custom fstab /overlay extroot
entries on PREINIT.
(example: the default openwrt eMMC partition layout on the zyxel nbg6817)
Futher, with UBIFS_EXTROOT enabled (fstools package default), and no MTD
rootfs partitions present, check_extroot would not attempt rootfs
discovery on block devices, such as the ext4 mmcblk rootfs overlay on the
nbg6817.
With this patch:
1) main_extroot now attempts to load uci fstab configuration from an
already mounted overlay, before defaulting to the prefix-less uci
config dir when no MTD rootfs partitions are detected.
2) check_extroot now also attempts to find rootfs partitions on block
devices when no MTD rootfs partitions are detected.
Fixes: FS#2231
Ref: https://bugs.openwrt.org/index.php?do=details_id=2231
Signed-off-by: Kenneth J. Miller
---
block.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/block.c b/block.c
index 39212d2..3dfc4a5 100644
--- a/block.c
+++ b/block.c
@@ -1301,7 +1301,7 @@ static int find_block_ubi_RO(libubi_t libubi, char *name,
char *part, int plen)
return err;
}
-#else
+#endif
static int find_root_dev(char *buf, int len)
{
@@ -1332,8 +1332,6 @@ static int find_root_dev(char *buf, int len)
return -1;
}
-#endif
-
static int test_fs_support(const char *name)
{
char line[128], *p;
@@ -1363,25 +1361,20 @@ static int check_extroot(char *path)
struct probe_info *pr = NULL;
char devpath[32];
-#ifdef UBIFS_EXTROOT
if (find_block_mtd("\"rootfs\"", devpath, sizeof(devpath))) {
int err = -1;
+#ifdef UBIFS_EXTROOT
libubi_t libubi;
libubi = libubi_open();
err = find_block_ubi_RO(libubi, "rootfs", devpath,
sizeof(devpath));
libubi_close(libubi);
- if (err)
- return -1;
- }
-#else
- if (find_block_mtd("\"rootfs\"", devpath, sizeof(devpath))) {
- if (find_root_dev(devpath, sizeof(devpath))) {
+#endif
+ if (err && find_root_dev(devpath, sizeof(devpath))) {
ULOG_ERR("extroot: unable to determine root device\n");
return -1;
}
}
-#endif
list_for_each_entry(pr, , list) {
if (!strcmp(pr->dev, devpath)) {
@@ -1585,7 +1578,7 @@ static int main_extroot(int argc, char **argv)
}
#endif
- return mount_extroot(NULL);
+ return mount_extroot("/tmp/overlay");
}
static int main_mount(int argc, char **argv)
--
2.21.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] fstools: block: make extroot mount preparation more robust
Signed-off plain-text patch:
>From 6df03fc450d7f1e2b49791b0d384a7b1ae0d9c69 Mon Sep 17 00:00:00 2001
From: Kenneth Miller
Date: Tue, 9 Apr 2019 19:14:37 +0200
Subject: [PATCH] block: make extroot mount preparation more robust
The extroot mount preparation code for r/w rootfs overlay discovery, and
determining the user-defined /etc/config/fstab location within, would
only discover overlays residing on JFFS2 or UBIFS MTD storage.
This led to attempts at loading the uci fstab configuration without the
required /tmp/overlay directory prefix on devices with a non-MTD r/w
rootfs overlay, and thus failure to find any custom fstab /overlay
extroot entries on PREINIT.
(example: the default openwrt eMMC partition layout on the zyxel nbg6817)
Futher, with UBIFS_EXTROOT enabled (fstools package default), and no MTD
rootfs partitions present, check_extroot would not attempt rootfs
discovery on block devices, such as the ext4 mmcblk rootfs overlay on
the nbg6817.
With this patch:
1) main_extroot now attempts to load uci fstab configuration from an
already mounted overlay, before defaulting to the prefix-less uci config
dir when no MTD rootfs partitions are detected.
2) check_extroot now also attempts to find rootfs partitions on block
devices when no MTD rootfs partitions are detected.
Signed-off-by: Kenneth Miller
---
block.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/block.c b/block.c
index 39212d2..3dfc4a5 100644
--- a/block.c
+++ b/block.c
@@ -1301,7 +1301,7 @@ static int find_block_ubi_RO(libubi_t libubi, char
*name, char *part, int plen)
return err;
}
-#else
+#endif
static int find_root_dev(char *buf, int len)
{
@@ -1332,8 +1332,6 @@ static int find_root_dev(char *buf, int len)
return -1;
}
-#endif
-
static int test_fs_support(const char *name)
{
char line[128], *p;
@@ -1363,25 +1361,20 @@ static int check_extroot(char *path)
struct probe_info *pr = NULL;
char devpath[32];
-#ifdef UBIFS_EXTROOT
if (find_block_mtd("\"rootfs\"", devpath, sizeof(devpath))) {
int err = -1;
+#ifdef UBIFS_EXTROOT
libubi_t libubi;
libubi = libubi_open();
err = find_block_ubi_RO(libubi, "rootfs", devpath,
sizeof(devpath));
libubi_close(libubi);
- if (err)
- return -1;
- }
-#else
- if (find_block_mtd("\"rootfs\"", devpath, sizeof(devpath))) {
- if (find_root_dev(devpath, sizeof(devpath))) {
+#endif
+ if (err && find_root_dev(devpath, sizeof(devpath))) {
ULOG_ERR("extroot: unable to determine root device\n");
return -1;
}
}
-#endif
list_for_each_entry(pr, , list) {
if (!strcmp(pr->dev, devpath)) {
@@ -1585,7 +1578,7 @@ static int main_extroot(int argc, char **argv)
}
#endif
- return mount_extroot(NULL);
+ return mount_extroot("/tmp/overlay");
}
static int main_mount(int argc, char **argv)
--
2.21.0
On 4/9/19 6:44 PM, Kenneth Miller wrote:
> I had trouble using an ext4 extroot overlay on my Zyxel NBG6817 running
> 18.06.2, so I took a closer look at the way libfstools and its block
> tool setup the extroot overlay during PREINIT and found some things
> broke extroot mounting on certain devices.
>
> The issue and logs are documented in the following ticket:
> https://bugs.openwrt.org/index.php?do=details_id=2231
>
> What I found was that the main_extroot code would only look for
> "rootfs_data" partitions on MTD storage (specifically only JFFS2 and
> UBIFS partitions), before defaulting to calling mount_extroot with no
> configuration path prefix.
> mount_extroot would then try to load the fstab uci config at
> /etc/config/fstab, which would fail as this isn't present on the normal
> r/o squashfs eMMC partition.
>
> With a /etc/config/fstab uci config be pre-placed on the squashfs,
> mount_extroot would continue after loading it and successfully finding
> an /overlay extroot entry, but fail during check_extroot when no MTD
> partition or UBIFS volume can be found.
>
> With the attached patch the behaviour of main_extroot and check_extroot
> is expanded to allow detection of rootfs overlays on block devices such
> as eMMC, without compromising the behavior for JFFS2 and UBIFS rootfs
> discovery:
>
> 1. The default mount_extroot call now uses '/tmp/overlay' as a default
> parameter should no MTD partition be detected. This results in
> config_load attempting to load a uci fstab with this
> prefix before defaulting to /etc/config/fstab.
> 2. UBIFS_EXTROOT now acts as a supplementary option instead of an
> exclusionary one and will allow rootfs discovery on block devices even
> when it fails to find UBIFS rootfs volumes.
> (IMHO the best design decision as this option defaults to 'y' in the
> fstools package configuration)
>
[OpenWrt-Devel] [PATCH] fstools: block: make extroot mount preparation more robust
I had trouble using an ext4 extroot overlay on my Zyxel NBG6817 running
18.06.2, so I took a closer look at the way libfstools and its block
tool setup the extroot overlay during PREINIT and found some things
broke extroot mounting on certain devices.
The issue and logs are documented in the following ticket:
https://bugs.openwrt.org/index.php?do=details_id=2231
What I found was that the main_extroot code would only look for
"rootfs_data" partitions on MTD storage (specifically only JFFS2 and
UBIFS partitions), before defaulting to calling mount_extroot with no
configuration path prefix.
mount_extroot would then try to load the fstab uci config at
/etc/config/fstab, which would fail as this isn't present on the normal
r/o squashfs eMMC partition.
With a /etc/config/fstab uci config be pre-placed on the squashfs,
mount_extroot would continue after loading it and successfully finding
an /overlay extroot entry, but fail during check_extroot when no MTD
partition or UBIFS volume can be found.
With the attached patch the behaviour of main_extroot and check_extroot
is expanded to allow detection of rootfs overlays on block devices such
as eMMC, without compromising the behavior for JFFS2 and UBIFS rootfs
discovery:
1. The default mount_extroot call now uses '/tmp/overlay' as a default
parameter should no MTD partition be detected. This results in
config_load attempting to load a uci fstab with this
prefix before defaulting to /etc/config/fstab.
2. UBIFS_EXTROOT now acts as a supplementary option instead of an
exclusionary one and will allow rootfs discovery on block devices even
when it fails to find UBIFS rootfs volumes.
(IMHO the best design decision as this option defaults to 'y' in the
fstools package configuration)
>From 9daabc73ed804fe969e0318dfe533794d6da73b6 Mon Sep 17 00:00:00 2001
From: Ken Miller
Date: Tue, 9 Apr 2019 01:03:26 +0200
Subject: [PATCH] block: make extroot mount preparation more robust
The extroot mount preparation code for r/w rootfs overlay discovery, and
determining the user-defined /etc/config/fstab location within, would only
discover overlays residing on JFFS2 or UBIFS MTD storage.
This led to attempts at loading the uci fstab configuration without the required
/tmp/overlay directory prefix on devices with a non-MTD r/w rootfs overlay, and
thus failure to find any custom fstab /overlay extroot entries on PREINIT.
(example: the default openwrt eMMC partition layout on the zyxel nbg6817)
Futher, with UBIFS_EXTROOT enabled (fstools package default), and no MTD rootfs
partitions present, check_extroot would not attempt rootfs discovery on block
devices, such as the ext4 mmcblk rootfs overlay on the nbg6817.
With this patch:
1) main_extroot now attempts to load uci fstab configuration from an already
mounted overlay, before defaulting to the prefix-less uci config dir when
no MTD rootfs partitions are detected.
2) check_extroot now also attempts to find rootfs partitions on block devices
when no MTD rootfs partitions are detected.
---
block.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/block.c b/block.c
index 39212d2..3dfc4a5 100644
--- a/block.c
+++ b/block.c
@@ -1301,7 +1301,7 @@ static int find_block_ubi_RO(libubi_t libubi, char *name, char *part, int plen)
return err;
}
-#else
+#endif
static int find_root_dev(char *buf, int len)
{
@@ -1332,8 +1332,6 @@ static int find_root_dev(char *buf, int len)
return -1;
}
-#endif
-
static int test_fs_support(const char *name)
{
char line[128], *p;
@@ -1363,25 +1361,20 @@ static int check_extroot(char *path)
struct probe_info *pr = NULL;
char devpath[32];
-#ifdef UBIFS_EXTROOT
if (find_block_mtd("\"rootfs\"", devpath, sizeof(devpath))) {
int err = -1;
+#ifdef UBIFS_EXTROOT
libubi_t libubi;
libubi = libubi_open();
err = find_block_ubi_RO(libubi, "rootfs", devpath, sizeof(devpath));
libubi_close(libubi);
- if (err)
- return -1;
- }
-#else
- if (find_block_mtd("\"rootfs\"", devpath, sizeof(devpath))) {
- if (find_root_dev(devpath, sizeof(devpath))) {
+#endif
+ if (err && find_root_dev(devpath, sizeof(devpath))) {
ULOG_ERR("extroot: unable to determine root device\n");
return -1;
}
}
-#endif
list_for_each_entry(pr, , list) {
if (!strcmp(pr->dev, devpath)) {
@@ -1585,7 +1578,7 @@ static int main_extroot(int argc, char **argv)
}
#endif
- return mount_extroot(NULL);
+ return mount_extroot("/tmp/overlay");
}
static int main_mount(int argc, char **argv)
--
2.21.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] DTS Style: Referring to "Upstream" Nodes
In general, within an OpenWrt DTS that `#include "some_linux_supplied.dtsi"` is it preferred to refer to a node defined in upstream code by label, or by path? For example, with `blsp1_spi2: spi@78b6000` in the upstream-controlled DTS, prefer _spi2 or (taking into account scope or path, as needed) spi@78b6000 Thanks, Jeff ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt 19.03 plans
Hi Bjørn, routers are critical infrastructure. We should try to achieve the best we can. One of the reasons for the Lede split was that problems were procrastinated and accumulated over the release timeline. That's the reason why we should release less often, but with a higher quality. If problems delay a release that is a sign of taking responsibility. Some time ago a friend of mine told me that they have a problem with tickets that nobody wants to take care of. I told him when those tickets appear he should automatically assign them to all people with highest priority after a due date even if it is a minor issue. Productivity has increased rapidly since then. If a device is not supported in a specific release, that might give someone the stimulus to sit down and get this device working again. E.g. many devices have a partition layout on which a bigger kernel does not fit. It is possible to change the partition layout in most cases requiring a modification of the U-Boot boot environment variable. So hard it sounds unfortunately someone needs to be urged to do it. It's the same with porting ar71xx to ath79... When we stop generating ar71xx images some device owners wonder why there is no new release for it. They become aware that they need to sort of add support for this device as if it was a new device support and they might do it. Urging is a bad word, but we need to motivate people to do changes which are not of the fun kind or we might end up in a mess again. Regards, Vincent Wiemann On 09.04.2019 11:02, Bjørn Mork wrote: > Jo-Philipp Wich writes: > >>> Is there any kind of "official" roadmap/checklist available what "needs" >>> to be done? >> >> not that I am aware of, but from the top of my head: >> >> - make sure all targets are ported properly to 4.14 >> - disable all devices which cannot cannot handle the increased kernel >> size anymore >> - drop all targets which are not ported to 4.14 >> - fix important open issues in the tracker > > Apologies if this is out of line... I just fealt the urge to post my > personal opinion, FWIW. > > It seems to me that you are setting way too high standards for > yourselves. From my point of view, the OpenWrt master branch is almost > always in a releasable state. The OpenWrt development and review process > ensures an extremely high quality, even for targets which are considered > WiP. There are very few days over the last 6 months where you could not > have decided to cut a release branch, and got away with it. It's > something to be proud of! But you need to tell the rest of the world > that you are proud of this by making releases. > > You should accept that the targets which are ported properly to 4.14 > defines "all targets" for the next release. It's not the other way > round. Any remaining targets which can be expected to be ported to 4.14 > or later, if any, can and should be deferred for a later release. Note > that accepting this means that there could be a "next release" in 2019 > too... > > You should also accept that there will be unfixed important open issues > at all times. You can't fix them all. To make a release, these issues > will either have to be > - ignored for that release, > - demoted to less important. or > - removed by removing the feature/target/whatever is affected by the >issue from the release > > Look at the Debian "release critical" bug handling. It's not really > about fixing all the RC bugs, but dealing with them. > > I realize that actually making a release is real work too, and that this > has to take some time after making the initial cut. But delaying the > cut for the master branch to get in an even "more ready" state is not > really helping... > > Just my .021 € (considering inflation) > > > Bjørn > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH RFC] kernel: drop -fno-reorder-blocks
From: Rafał Miłecki Dropping this option significantly improves NAT performance on BCM5301X (bcm53xx) for LAN to WAN traffic with GRO disabled (+14%). It slightly affects kernel size - it gets bigger by 1,5% - 3% depending on a target. Unfortunately this change may decrease NAT performance for some other platforms (targets). It seems to e.g. affect mt7621 with GRO enabled. https://www.gnu.org/software/gcc/news/reorder.html Following testing results come from OpenWrt with kernel 4.14.109 using OpenWrt's default fq_codel. ** 1) bcm53xx: BCM47094 SoC (echo 2 > rps_cpus) zImage size: 1840424 → 1871328 (+1,68%) a) gro off LAN to WAN: 824 Mb/s → 940 Mb/s (+14,08%) WAN to LAN: 935 Mb/s → 940 Mb/s (+0,53%) b) gro on LAN to WAN: 512 Mb/s → 534 Mb/s (+4,30%) WAN to LAN: 539 Mb/s → 549 Mb/s (+1,85%) ** 2) brcm47xx: BCM4706 SoC vmlinux.lzma: 1536486 → 1588082 (+3,36%) a) gro off LAN to WAN: 152 Mb/s → 157 Mb/s (+3,29%) WAN to LAN: 191 Mb/s → 182 Mb/s (-4,71%) b) gro on LAN to WAN: 223 Mb/s → 226 Mb/s (+1,35%) WAN to LAN: 214 Mb/s → 214 Mb/s (+0,00%) ** 3) ramips/mt7621: Ubiquiti ER-X (echo 8 > rps_cpus) vmlinux size: 6084176 → 6248016 (+2,69%) a) gro off LAN to WAN: 415 Mb/s → 418 Mb/s (+0,07%) WAN to LAN: 509 Mb/s → 543 Mb/s (+6,68%) b) gro on LAN to WAN: 640 Mb/s → 537 Mb/s (-16,09%) WAN to LAN: 748 Mb/s → 683 Mb/s (-8,69%) c) gro on [another run] LAN to WAN: 648 Mb/s → 530 Mb/s (-18,20%) WAN to LAN: 782 Mb/s → 691 Mb/s (-11,64%) ** 4) ar71xx: Netgear WNR2200 (AR7241) vmlinux size: 5106084 → 5244996 (+2,72%) a) gro off LAN to WAN: 94.1 Mb/s → 94.2 Mb/s (~ +0%) WAN to LAN: 94.2 Mb/s → 94.2 Mb/s (~ +0%) b) gro on LAN to WAN: 94.2 Mb/s → 94.2 Mb/s (~ +0%) WAN to LAN: 94.1 Mb/s → 94.2 Mb/s (~ +0%) ** Signed-off-by: Rafał Miłecki --- target/linux/generic/pending-4.14/201-extra_optimization.patch | 2 +- target/linux/generic/pending-4.19/201-extra_optimization.patch | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/target/linux/generic/pending-4.14/201-extra_optimization.patch b/target/linux/generic/pending-4.14/201-extra_optimization.patch index c7790657fd..3f7613d3dd 100644 --- a/target/linux/generic/pending-4.14/201-extra_optimization.patch +++ b/target/linux/generic/pending-4.14/201-extra_optimization.patch @@ -26,7 +26,7 @@ Signed-off-by: Felix Fietkau +KBUILD_CFLAGS += -O2 $(call cc-disable-warning,maybe-uninitialized,) $(EXTRA_OPTIMIZATION) else -KBUILD_CFLAGS += -O2 -+KBUILD_CFLAGS += -O2 -fno-reorder-blocks -fno-tree-ch $(EXTRA_OPTIMIZATION) ++KBUILD_CFLAGS += -O2 -fno-tree-ch $(EXTRA_OPTIMIZATION) endif endif diff --git a/target/linux/generic/pending-4.19/201-extra_optimization.patch b/target/linux/generic/pending-4.19/201-extra_optimization.patch index d86e29fc75..f002c49676 100644 --- a/target/linux/generic/pending-4.19/201-extra_optimization.patch +++ b/target/linux/generic/pending-4.19/201-extra_optimization.patch @@ -26,7 +26,7 @@ Signed-off-by: Felix Fietkau +KBUILD_CFLAGS += -O2 $(call cc-disable-warning,maybe-uninitialized,) $(EXTRA_OPTIMIZATION) else -KBUILD_CFLAGS += -O2 -+KBUILD_CFLAGS += -O2 -fno-reorder-blocks -fno-tree-ch $(EXTRA_OPTIMIZATION) ++KBUILD_CFLAGS += -O2 -fno-tree-ch $(EXTRA_OPTIMIZATION) endif endif -- 2.21.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
