Lorenzo, I have tested dynack on a (real distance apart) ~60km link
with some success. This is the code change made:
--- a/drivers/net/wireless/ath/ath9k/dynack.c
+++ b/drivers/net/wireless/ath/ath9k/dynack.c
@@ -20,8 +20,9 @@
#define COMPUTE_TO (5 * HZ)
#define LATEACK_DELAY (10 * HZ)
-#def
I was wondering if we are going to see UEFI compatible builds for x86_64
anytime soon. Neither of the 2 suggested solutions in the wiki work at this
time.
The first method fails at commits. I have emailed the author of that fix to
see if something can be done to resolve that.
The 2nd suggestion d
The port labled as "LAN" is eth1.
That's different from the -lite variant,
where the only existing port eth0 is used as LAN
---
target/linux/ath79/base-files/etc/board.d/01_leds | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/ath79/base-files/etc/board.d/01_leds
b
I made a similar change to this here:
https://github.com/openwrt/packages/pull/8159
However, it turns out this did not fix the problem as the problem has to
do with tools/xz and not the xz package. The error is the same and it's
causing build failures with CircleCI, as in:
https://github.com/open
Alexander Couzens [2019-03-10 12:29:10]:
> > > I changed the project to allow everybody to view the defects.
> >
> > can you please try harder? :-) I can view some stats, but no details
> > about actual defects. Am I doing it wrong?
>
> maybe it needs another run of the coverity scan. but I s
Hi,
>Can you be elaborate more in detail what use case you want to cover
>with this patch; in other words what is not working now ?
Ok,
my setup:
Two peer routers A and B which both connected to gateway C.
Routers A and B have public IPv6 addresses on WAN interfaces from same
subnet (because of RA
With transition from ar71xx to ath79 some of devices change their naming
of LEDs. When upgrading from ar71xx target images this will require the
user to adjust previously working configuration. This commit adds
migration script which can be used to rename old names to new ones.
With this previously
Currently leds migration scripts in ar71xx and lantiq share a lot of
logic and introducing leds migration to another target would mean
copying this code, again. Therefore move common logic to library in
base-files package.
Suggested-by: Petr Štetiar
Signed-off-by: Petr Štetiar
Signed-off-by: Tom
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Tom Psyborg
> Sent: Montag, 18. März 2019 15:51
> To: Rosen Penev
> Cc: Adrian Schmutzler ; OpenWrt
> Development List
> Subject: Re: [OpenWrt-Devel] [PATCH] ramips: Speed up eeprom
Hi,
On Mon, Mar 18, 2019 at 2:43 PM wrote:
>
> From: Pavel Merzlyakov
>
> A subnet may be changed after link-up event
Can you be elaborate more in detail what use case you want to cover
with this patch; in other words what is not working now ?
>
> Signed-off-by: Pavel Merzlyakov
> ---
> src/od
On Mon, Mar 18, 2019 at 03:51:09PM +0100, Tom Psyborg wrote:
> So, how enourmous boot speed-up did it achieve? I'd say not much since
> you read like what 500bytes of eeprom data?
Extracting 500b out of lets say 256kb is still more than 500 offsets
to be probed. If you do that byte-by-byte it's mu
So, how enourmous boot speed-up did it achieve? I'd say not much since
you read like what 500bytes of eeprom data?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
From: Pavel Merzlyakov
A subnet may be changed after link-up event
Signed-off-by: Pavel Merzlyakov
---
src/odhcp6c.c | 3 +++
src/ra.c | 20 +---
src/ra.h | 1 +
3 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/src/odhcp6c.c b/src/odhcp6c.c
index 19a8
Daniel Engberg [2019-03-18 13:55:07]:
Hi,
> Having a look at https://www.python.org/dev/peps/pep-0537/#lifespan it seems
> like a good idea to stick with 3.7?
it's a PITA to demand versions which are not packaged in current versions of LTS
Linux distros. Since Meson is a build system generator,
Hi,
> I think the cmake.mk-link approach would be a good idea and given
> previous discussions the plan is afaik to pull in Ninja first and
> once that's confirmed working via CMake add support for Meson.
fine with me.
> Having a look at https://www.python.org/dev/peps/pep-0537/#lifespan
> it
Hi,
I think the cmake.mk-link approach would be a good idea and given
previous discussions the plan is afaik to pull in Ninja first and once
that's confirmed working via CMake add support for Meson. Having a look
at https://www.python.org/dev/peps/pep-0537/#lifespan it seems like a
good idea
Hi Jan,
> I'm trying to add ninja and meson to packages feed. The reason for that
> is described here https://github.com/openwrt/openwrt/pull/1871 and
> https://github.com/openwrt/packages/issues/8315 .
great to hear that! I think eventually there should be a
"tools/meson/Makefile" along with an
Hi,
I'm trying to add ninja and meson to packages feed. The reason for that
is described here https://github.com/openwrt/openwrt/pull/1871 and
https://github.com/openwrt/packages/issues/8315 .
If you want to look at that, my test repo is here
https://github.com/ja-pa/meson-turris but it's not read
Hi,
> A number of upstream projects are beginning to use the Meson/Ninja build
> system. OpenWrt's sound/mpc and libs/libmpdclient kludge around this,
> and I would like to update the glib2 package. The latest version of
> glib2 uses Meson/Ninja.
just what the world needed, yet another build syst
From: Pavel Merzlyakov
1) Restore functionality which was lost in commit 876c7f5b.
Again at boot time kmodloader can load all modules (/etc/modules.d/*)
even if dependency information is completely missing.
This functionality is important in case of hidden dependency (not symbol
depende
20 matches
Mail list logo
