On 2021-09-27 13:33, e9hack wrote:
> Am 27.09.2021 um 12:59 schrieb Felix Fietkau:
>>
>> Hi,
>>
>>
>> On 2021-09-26 14:48, e9hack wrote:
>>> Do you see a page fault from netifd in the log? If it does crash, it is
>>> restarted by procd. This does restart the network stack. If I start netifd
From: Linkai
Signed-off-by: Linkai
---
...exclusive-srng_write32-hif-api-for-srng-w.patch | 137 +
1 file changed, 137 insertions(+)
create mode 100644
package/kernel/mac80211/patches/237-005-ath11k-Use-exclusive-srng_write32-hif-api-for-srng-w.patch
diff --git
Hi,
On 2021-09-26 14:48, e9hack wrote:
> Do you see a page fault from netifd in the log? If it does crash, it is
> restarted by procd. This does restart the network stack. If I start netifd
> with strace, I got this lines immediately before the page fault:
>
>
Am 27.09.2021 um 12:59 schrieb Felix Fietkau:
Hi,
On 2021-09-26 14:48, e9hack wrote:
Do you see a page fault from netifd in the log? If it does crash, it is
restarted by procd. This does restart the network stack. If I start netifd with
strace, I got this lines immediately before the page
Felix Fietkau kirjoitti 27.9.2021 klo 13.59:
On a crash, it should drop a .core file to /tmp. Please copy that to
your build host and use ./scripts/remote-gdb to obtain a backtrace from
it. I'd like to know, which line of code in netifd it crashes on, so I
can fix it. So far the bug has not
Am 27.09.2021 um 14:01 schrieb Felix Fietkau:
Normally it should be active by default. Is CONFIG_KERNEL_ELF_CORE set
in your .config?
It was not activated, but the output from gdb looks not so helpful:
e9hack kirjoitti 27.9.2021 klo 16.39:
Am 27.09.2021 um 14:01 schrieb Felix Fietkau:
Normally it should be active by default. Is CONFIG_KERNEL_ELF_CORE set
in your .config?
It was not activated, but the output from gdb looks not so helpful:
Felix Fietkau kirjoitti 27.9.2021 klo 19.17:
On 2021-09-27 17:45, Hannu Nyman wrote:
Felix Fietkau kirjoitti 27.9.2021 klo 13.59:
On a crash, it should drop a .core file to /tmp. Please copy that to
your build host and use ./scripts/remote-gdb to obtain a backtrace from
it. I'd like to know,
On 2021-09-27 18:30, Hannu Nyman wrote:
> Felix Fietkau kirjoitti 27.9.2021 klo 19.17:
>> On 2021-09-27 17:45, Hannu Nyman wrote:
>>> Felix Fietkau kirjoitti 27.9.2021 klo 13.59:
On a crash, it should drop a .core file to /tmp. Please copy that to
your build host and use
There is a race condition between hostapd and netifd.
Now that the bug is found, I could try to write a patch. But I do not
know what the correct behaviour should be.
Should netifd not add wlan0.sta1 to the bridge at all? If so, what is
the best way to implement it?
Or should hostapd be
Am 27.09.2021 um 19:02 schrieb Felix Fietkau:
Fix pushed, thanks for testing.
- Felix
It fixes my issue too.
In bonding_enable_port() and bridge_enable_member() is in the middle a 'return
-1'. In all error cases before and afterwards is located a 'goto ...' to revert
some things. Is
Hi Adrian,
Op zondag 26 september 2021 om 23u45 schreef Adrian Schmutzler
:
Hi,
-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
On Behalf Of Stijn Segers
Sent: Donnerstag, 9. September 2021 14:26
To: openwrt-devel@lists.openwrt.org; Paweł
On 2021-09-27 17:45, Hannu Nyman wrote:
> Felix Fietkau kirjoitti 27.9.2021 klo 13.59:
>> On a crash, it should drop a .core file to /tmp. Please copy that to
>> your build host and use ./scripts/remote-gdb to obtain a backtrace from
>> it. I'd like to know, which line of code in netifd it crashes
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Sat, Sep 25, 2021 at 6:53 PM
Hello,
I'm having this issue since about a week, normaly such things with core
components are noticed and even fixed by others faster than I have the
time to report it - so maybe I just did something stupid with my
configuration?
make[5]: Entering directory
On Thu, Sep 9, 2021 at 5:49 AM Rui Salvaterra wrote:
>
> Tested on mt7621 (Redmi AC2100) and running stable for several months.
>
> Signed-off-by: Rui Salvaterra
> ---
Tested on rt3883: Asus RT-N56U
Tested-by: Eneas U de Queiroz
___
openwrt-devel
In file included from ubus.c:20:
ubus.c: In function 'uh_ubus_list_cb':
libubox/blobmsg.h:256:9: error: 'o' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
256 | blob_nest_end(buf, cookie);
| ^~
ubus.c:591:19: note: 'o' was
Hi everyone,
I am quite confident there is a bug affecting mesh mode when mesh
interfaces are bridge with the LAN.
I have noticed this bug since 21.02 rc1. but it also happens on the
latest master of OpenWrt (today) and the latest master of hostapd.
Somehow the mac addresses of devices
Hi Stijn,
> >> >all mt7620 JBOOT devices will be broken.
...
> $ grep \ KERNEL_SIZE image/mt7620.mk|wc -l
> 1
That one is under "define Device/amit_jboot", searching for that yields:
$ git grep "\$(Device/amit_jboot)" | wc -l
8
So all JBOOT devices look covered.
Which mt76x8 device(s) is
19 matches
Mail list logo
