Re: [PATCH] ramips: switch to kernel 5.10

[Ilya Lipnitskiy]

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 missing a KERNEL_SIZE or fails to boot with 5.10?

Ilya

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH][uhttpd] fix compiler uninitialized variable

[Thomas Huehn]

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 declared here
  591 | void *t, *o;
  |   ^
cc1: all warnings being treated as errors

Signed-off-by: Thomas Huehn 
Acked-by: Alexander Couzens 
---
 ubus.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/ubus.c b/ubus.c
index 619135c..99cc400 100644
--- a/ubus.c
+++ b/ubus.c
@@ -588,7 +588,7 @@ static void uh_ubus_list_cb(struct ubus_context *ctx, 
struct ubus_object_data *o
struct blob_attr *sig, *attr;
struct list_data *data = priv;
int rem, rem2;
-   void *t, *o;
+   void *t, *o=NULL;
 
if (!data->verbose) {
blobmsg_add_string(data->buf, NULL, obj->path);
@@ -598,8 +598,12 @@ static void uh_ubus_list_cb(struct ubus_context *ctx, 
struct ubus_object_data *o
if (!obj->signature)
return;
 
-   if (data->add_object)
+   if (data->add_object) {
o = blobmsg_open_table(data->buf, obj->path);
+   if (!o)
+   return;
+   }
+
blob_for_each_attr(sig, obj->signature, rem) {
t = blobmsg_open_table(data->buf, blobmsg_name(sig));
rem2 = blobmsg_data_len(sig);
@@ -630,6 +634,7 @@ static void uh_ubus_list_cb(struct ubus_context *ctx, 
struct ubus_object_data *o
}
blobmsg_close_table(data->buf, t);
}
+
if (data->add_object)
blobmsg_close_table(data->buf, o);
 }
-- 
2.33.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Mesh bug: rough routes causing blackhole

[Federico Capoano]

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 connected to the LAN end up in
the routing table of the mesh interfaces of the root node (the one
which has internet connection) with an invalid next hop.
If this goes on unchecked, after a tipping point I have not been able
to identify, packets are not routed to the root node anymore, even
though the mesh link is up and running.
It took me months to understand in detail what was going on, because
there's no error or warning logged to syslog, the only symptom I have
been able to observe consistently is the routing table of the mesh
filled with routes that look like garbage.

EG:

iw mesh1 mpath dump
DEST ADDR NEXT HOP  IFACE SN METRIC QLEN EXPTIME DTIM
DRET FLAGS HOP_COUNT PATH_CHANGE
90:38:3d:dd:42:61 00:00:00:00:00:00 mesh1 0 0 0 0 1600 4 0x0 0 0
3a:bd:b8:ec:00:da 00:00:00:00:00:00 mesh1 0 0 0 0 1600 4 0x0 0 0
2e:bc:05:55:1b:fe 00:00:00:00:00:00 mesh1 0 0 0 0 1600 4 0x0 0 0
b6:75:f9:d4:75:21 00:00:00:00:00:00 mesh1 0 0 0 0 1600 4 0x0 0 0
2a:81:a7:88:b2:3d 00:00:00:00:00:00 mesh1 0 0 0 0 1600 4 0x0 0 0
38:cb:3b:46:a3:b0 00:00:00:00:00:00 mesh1 0 0 0 0 1600 4 0x0 0 0
1c:48:1f:b9:ff:2f 00:00:00:00:00:00 mesh1 0 0 0 0 1600 4 0x0 0 0
a4:e1:c5:1d:0b:67 00:00:00:00:00:00 mesh1 0 0 0 0 1600 4 0x0 0 0
0c:33:7e:b6:6f:aa 00:00:00:00:00:00 mesh1 0 0 0 0 1600 4 0x0 0 0
e4:fa:0b:af:d5:eb 00:00:00:00:00:00 mesh1 0 0 0 0 1600 4 0x0 0 0
32:e7:70:d6:00:b8 00:00:00:00:00:00 mesh1 0 0 0 0 1600 4 0x0 0 0
16:90:cc:07:c7:f4 00:00:00:00:00:00 mesh1 0 0 0 0 1600 4 0x0 0 0
f8:71:4d:52:77:92 00:00:00:00:00:00 mesh1 0 0 0 0 1600 4 0x0 0 0
0e:7e:0d:96:51:37 00:00:00:00:00:00 mesh1 0 0 0 0 1600 4 0x0 0 0
9a:bb:4e:36:2a:bc 00:00:00:00:00:00 mesh1 0 0 0 0 1600 4 0x0 0 0
a4:79:30:19:69:3c 00:00:00:00:00:00 mesh1 0 0 0 0 1600 4 0x0 0 0
[...cut...(there were more)...]

I am not the only one affected by this, there's a detailed discussion here:
https://forum.openwrt.org/t/mesh-802-11s-routing-table-gets-filled-with-garbage-causing-a-black-hole-openwrt-21-02-rc4-mt7603e-mt7615e/104808

I would be very grateful if anyone could advise how to collect more
detailed data which would help me to identify where the bug is
originating from, so that I can send a proper bug report and keep
investigating to nail down what's going on (it's incomprehensible to
me why something like this is happening).

Best regards
Federico Capoano

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: kernel: add a bridge feature for filtering BPDU packets on ports

[Martin Blumenstingl via openwrt-devel]

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 Martin Blumenstingl
 wrote:
>
> Hi Andre,
>
> On Sat, Sep 25, 2021 at 1:17 PM Andre Heider  wrote:
> [...]
> > With these 3 reverted (on top of da5bb885 "toolchain/gcc: switch to
> > version 11 by default") it works again:
> > Revert "hostapd: let netifd set bridge port attributes for snooping"
> > Revert "netifd: update to the latest version"
> > Revert "kernel: add a bridge feature for filtering BPDU packets on ports"
> thanks for investigating this!
>
> > With just the first 2 reverts it's still broken.
> I can confirm that reverting all three fixes communication between
> clients on the ath10k 802.11ac card on Home Hub 5A
> communication between a client connected to the ath9k 802.11bgn card
> and ath10k worked fine even without the revert on the Home Hub 5A.
it seems that commit 6cd54254e4bbe7ed2b71c17cb2d54ad7b0bc2991
("netifd: update to the latest version") fixed this issue for me


Best regards,
Martin

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

dnsmasq compile error: rfc1035.c:978:56: error: 'struct dnsmasq_daemon' has no member named 'workspacename'

[Patrick Vorlicek]

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
'/root/openwrt/ea8500/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/dnsmasq-full/dnsmasq-2.86/src'
arm-openwrt-linux-muslgnueabi-gcc -Os -pipe -fno-caller-saves -fno-plt
-fhonour-copts -Wno-error=unused-but-set-variable
-Wno-error=unused-result -mfloat-abi=hard
-fmacro-prefix-map=/root/openwrt/ea8500/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/dnsmasq-full/dnsmasq-2.86=dnsmasq-2.86
-Wformat -Werror=format-security -DPIC -fpic -fstack-protector
-D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -flto
-I/root/openwrt/ea8500/staging_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-11.2.0_musl_eabi/usr/include
-I/root/openwrt/ea8500/staging_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-11.2.0_musl_eabi/include/fortify
-I/root/openwrt/ea8500/staging_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-11.2.0_musl_eabi/include
-DHAVE_UBUS -DHAVE_POLL_H   -DHAVE_CONNTRACK -DNO_ID  -DNO_TFTP  
-DVERSION='"2.86"' 
-I/root/openwrt/ea8500/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/usr/include
 
-c rfc1035.c
rfc1035.c: In function 'report_addresses':
rfc1035.c:978:56: error: 'struct dnsmasq_daemon' has no member named
'workspacename'
  978 |   if (!extract_name(header, len, ,
daemon->workspacename, 1, 0))
  |    ^~
rfc1035.c:980:66: error: 'struct dnsmasq_daemon' has no member named
'workspacename'
  980 |   if (safe_name(daemon->namebuff) &&
safe_name(daemon->workspacename))
  |  ^~
rfc1035.c:981:92: error: 'struct dnsmasq_daemon' has no member named
'workspacename'
  981 |
ubus_event_bcast_connmark_allowlist_resolved(mark, daemon->namebuff,
daemon->workspacename, attl);
 
|   

^~
make[5]: ***
[/root/openwrt/ea8500/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/dnsmasq-full/dnsmasq-2.86/Makefile:166:
rfc1035.o] Error 1
make[5]: Leaving directory
'/root/openwrt/ea8500/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/dnsmasq-full/dnsmasq-2.86/src'

It's a custom build of current master
(830c2e53781ade1817b03bbb8ece6291ae34df5d) with the following dnsmasq
config:

# CONFIG_PACKAGE_dnsmasq is not set
# CONFIG_PACKAGE_dnsmasq-dhcpv6 is not set
CONFIG_PACKAGE_dnsmasq-full=y
CONFIG_PACKAGE_dnsmasq_full_dhcp=y
CONFIG_PACKAGE_dnsmasq_full_dhcpv6=y
# CONFIG_PACKAGE_dnsmasq_full_dnssec is not set
CONFIG_PACKAGE_dnsmasq_full_auth=y
CONFIG_PACKAGE_dnsmasq_full_ipset=y
CONFIG_PACKAGE_dnsmasq_full_conntrack=y
CONFIG_PACKAGE_dnsmasq_full_noid=y
# CONFIG_PACKAGE_dnsmasq_full_broken_rtc is not set
# CONFIG_PACKAGE_dnsmasq_full_tftp is not set

A make dirclean does not help, the target is ipq806x, host is Ubuntu
20.04. Any idea what I did wrong?

-- 
Viele Grüße,
Patrick Vorlicek


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] ramips: switch to kernel 5.10

[Eneas U de Queiroz]

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 mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: WDS stopped working in 21.02, looking for bug in netifd, how to patch?

[Daniel Haid]

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 patched not to treat it as an error if wlan0.sta1 
is already added to the bridge?


-
D.H.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Wifi bug

[e9hack]

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 'return -1' correct or a bug?

Regards,
Hartmut

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH] ramips: switch to kernel 5.10

[Stijn Segers]

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ł Dembicki
 ; Rui Salvaterra 
 Cc: OpenWrt Development List ; 
Adrian

 Schmutzler ; David Bauer 
 Subject: Re: [PATCH] ramips: switch to kernel 5.10

 "Paweł Dembicki"  schreef op 9 september
 2021 13:47:36 CEST:
 >czw., 9 wrz 2021 o 10:49 Rui Salvaterra  
napisał(a):

 >>
 >> Tested on mt7621 (Redmi AC2100) and running stable for several 
months.

 >>
 >
 >Hi Rui,
 >
 >Please remember, if this patch will be merged before my PR #4255 
[1],

 >all mt7620 JBOOT devices will be broken.
 >
 >The reason is simple: The 5.10 kernel will be > 2MB. My PR will 
switch

 >all mt7620 JBOOT devices to the OKLI loader.

 Would something similar need to be done for the mt76x8 subtarget?

 I just have a single one of these but I reckon they are equally 
flash-starved...


But if KERNEL_SIZE/IMAGE_SIZE is set properly there, those would just 
fail to build, so no harm could be done?



That is a valid point. I checked master:

$ grep "define Device" image/mt7620.mk|wc -l
119
$ grep \ KERNEL_SIZE image/mt7620.mk|wc -l
1
$ grep "define Device" image/mt76x8.mk|wc -l
80
$ grep \ KERNEL_SIZE image/mt76x8.mk|wc -l
0

That's not encouraging I guess :-P. And just having IMAGE_SIZE defined 
won't prevent the bootloader from choking on an oversized kernel, or am 
I wrong about that?


Cheers

Stijn



Best

Adrian



 Cheers

 Stijn

 >
 >Best Regards,
 >Pawel
 >
 >[1] https://github.com/openwrt/openwrt/pull/4255
 >
 >> Signed-off-by: Rui Salvaterra 
 >> ---
 >>  target/linux/ramips/Makefile | 3 +--
 >>  1 file changed, 1 insertion(+), 2 deletions(-)
 >>
 >> diff --git a/target/linux/ramips/Makefile
 >> b/target/linux/ramips/Makefile index d3f2d4b8fc..c9fc1aa58a 
100644

 >> --- a/target/linux/ramips/Makefile
 >> +++ b/target/linux/ramips/Makefile
 >> @@ -10,8 +10,7 @@ BOARDNAME:=MediaTek Ralink MIPS
 >>  SUBTARGETS:=mt7620 mt7621 mt76x8 rt288x rt305x rt3883
 >> FEATURES:=squashfs gpio
 >>
 >> -KERNEL_PATCHVER:=5.4
 >> -KERNEL_TESTING_PATCHVER:=5.10
 >> +KERNEL_PATCHVER:=5.10
 >>
 >>  define Target/Description
 >> Build firmware images for Ralink RT288x/RT3xxx based 
boards.

 >> --
 >> 2.33.0
 >>
 >>
 >> ___
 >> 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

 Hi,
 --
 Sent from my smartphone with K-9 Mail. Please excuse my brevity.

 ___
 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 mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Wifi bug

[Felix Fietkau]

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 ./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 shown up in my own tests...

 - Felix
>>>
>>> This is probably what you are looking for...
>>> To me it looks like it might actually be a list handling bug in libubox.
> 
>> Can you please try this netifd patch?
> 
> At the first glance, the impact looks ok to me:
>wifi goes down with "with down", netifd stays alive and wifi remains down. 
>  :-)
> 
> Hannu

Fix pushed, thanks for testing.

- Felix

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Wifi bug

[Hannu Nyman]

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, which line of code in netifd it crashes on, so I
can fix it. So far the bug has not shown up in my own tests...

- Felix


This is probably what you are looking for...
To me it looks like it might actually be a list handling bug in libubox.



Can you please try this netifd patch?


At the first glance, the impact looks ok to me:
  wifi goes down with "with down", netifd stays alive and wifi remains down.  
:-)

Hannu



Thanks,

- Felix

---
diff --git a/alias.c b/alias.c
index 951e046bb3f1..98d54100fef9 100644
--- a/alias.c
+++ b/alias.c
@@ -178,13 +178,9 @@ alias_notify_device(const char *name, struct device *dev)
  {
struct alias_device *alias;
  
-	device_lock();

-
alias = avl_find_element(, name, alias, avl);
if (alias)
alias_set_device(alias, dev);
-
-   device_unlock();
  }
  
  struct device *

diff --git a/bonding.c b/bonding.c
index 0bf4f9a331ef..457fe5159899 100644
--- a/bonding.c
+++ b/bonding.c
@@ -566,8 +566,6 @@ bonding_free_port(struct bonding_port *bp)
  
  	bonding_remove_port(bp);
  
-	device_lock();

-
device_remove_user(>dev);
  
  	/*

@@ -582,8 +580,6 @@ bonding_free_port(struct bonding_port *bp)
device_set_present(dev, true);
}
  
-	device_unlock();

-
free(bp);
  }
  
diff --git a/bridge.c b/bridge.c

index 2ce5c2b11b49..7e61b9df8326 100644
--- a/bridge.c
+++ b/bridge.c
@@ -512,8 +512,6 @@ restart:
goto restart;
}
  
-	device_lock();

-
device_remove_user(>dev);
uloop_timeout_cancel(>check_timer);
  
@@ -529,8 +527,6 @@ restart:

device_set_present(dev, true);
}
  
-	device_unlock();

-
free(bm);
  }
  
diff --git a/config.c b/config.c

index d83ea9cb6b6c..9bbda39d3fb5 100644
--- a/config.c
+++ b/config.c
@@ -762,7 +762,6 @@ config_init_all(void)
  
  	vlist_update();

config_init = true;
-   device_lock();
  
  	device_reset_config();

config_init_devices(true);
@@ -775,12 +774,10 @@ config_init_all(void)
config_init_wireless();
  
  	config_init = false;

-   device_unlock();
  
  	device_reset_old();

device_init_pending();
vlist_flush();
-   device_free_unused(NULL);
interface_refresh_assignments(false);
interface_start_pending();
wireless_start_pending();
diff --git a/device.c b/device.c
index bb39ea7f8d71..b3d0e85f8550 100644
--- a/device.c
+++ b/device.c
@@ -99,18 +99,6 @@ device_type_get(const char *tname)
return NULL;
  }
  
-void device_lock(void)

-{
-   __devlock++;
-}
-
-void device_unlock(void)
-{
-   __devlock--;
-   if (!__devlock)
-   device_free_unused(NULL);
-}
-
  static int device_vlan_len(struct kvlist *kv, const void *data)
  {
return sizeof(unsigned int);
@@ -895,14 +883,27 @@ device_free(struct device *dev)
  }
  
  static void

-__device_free_unused(struct device *dev)
+__device_free_unused(struct uloop_timeout *timeout)
  {
-   if (!safe_list_empty(>users) ||
-   !safe_list_empty(>aliases) ||
-   dev->current_config || __devlock)
-   return;
+   struct device *dev, *tmp;
+
+   avl_for_each_element_safe(, dev, avl, tmp) {
+   if (!safe_list_empty(>users) ||
+   !safe_list_empty(>aliases) ||
+   dev->current_config)
+   continue;
+
+   device_free(dev);
+   }
+}
+
+void device_free_unused(void)
+{
+   static struct uloop_timeout free_timer = {
+   .cb = __device_free_unused,
+   };
  
-	device_free(dev);

+   uloop_timeout_set(_timer, 1);
  }
  
  void device_remove_user(struct device_user *dep)

@@ -919,19 +920,7 @@ void device_remove_user(struct device_user *dep)
safe_list_del(>list);
dep->dev = NULL;
D(DEVICE, "Remove user for device '%s', refcount=%d\n", dev->ifname, 
device_refcount(dev));
-   __device_free_unused(dev);
-}
-
-void
-device_free_unused(struct device *dev)
-{
-   struct device *tmp;
-
-   if (dev)
-   return __device_free_unused(dev);
-
-   avl_for_each_element_safe(, dev, avl, tmp)
-   __device_free_unused(dev);
+   device_free_unused();
  }
  
  void

diff --git a/device.h b/device.h
index 0496e893cbc9..37f8c37c58a3 100644
--- a/device.h
+++ b/device.h
@@ -300,9 +300,6 @@ extern const struct uci_blob_param_list device_attr_list;
  extern struct device_type simple_device_type;
  extern struct device_type tunnel_device_type;
  
-void device_lock(void);

-void device_unlock(void);
-
  void device_vlan_update(bool done);
  void device_stp_init(void);
  
@@ 

Re: Wifi bug

[Felix Fietkau]

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 on, so I
>> can fix it. So far the bug has not shown up in my own tests...
>>
>> - Felix
> 
> 
> This is probably what you are looking for...
> To me it looks like it might actually be a list handling bug in libubox.Can 
> you please try this netifd patch?

Thanks,

- Felix

---
diff --git a/alias.c b/alias.c
index 951e046bb3f1..98d54100fef9 100644
--- a/alias.c
+++ b/alias.c
@@ -178,13 +178,9 @@ alias_notify_device(const char *name, struct device *dev)
 {
struct alias_device *alias;
 
-   device_lock();
-
alias = avl_find_element(, name, alias, avl);
if (alias)
alias_set_device(alias, dev);
-
-   device_unlock();
 }
 
 struct device *
diff --git a/bonding.c b/bonding.c
index 0bf4f9a331ef..457fe5159899 100644
--- a/bonding.c
+++ b/bonding.c
@@ -566,8 +566,6 @@ bonding_free_port(struct bonding_port *bp)
 
bonding_remove_port(bp);
 
-   device_lock();
-
device_remove_user(>dev);
 
/*
@@ -582,8 +580,6 @@ bonding_free_port(struct bonding_port *bp)
device_set_present(dev, true);
}
 
-   device_unlock();
-
free(bp);
 }
 
diff --git a/bridge.c b/bridge.c
index 2ce5c2b11b49..7e61b9df8326 100644
--- a/bridge.c
+++ b/bridge.c
@@ -512,8 +512,6 @@ restart:
goto restart;
}
 
-   device_lock();
-
device_remove_user(>dev);
uloop_timeout_cancel(>check_timer);
 
@@ -529,8 +527,6 @@ restart:
device_set_present(dev, true);
}
 
-   device_unlock();
-
free(bm);
 }
 
diff --git a/config.c b/config.c
index d83ea9cb6b6c..9bbda39d3fb5 100644
--- a/config.c
+++ b/config.c
@@ -762,7 +762,6 @@ config_init_all(void)
 
vlist_update();
config_init = true;
-   device_lock();
 
device_reset_config();
config_init_devices(true);
@@ -775,12 +774,10 @@ config_init_all(void)
config_init_wireless();
 
config_init = false;
-   device_unlock();
 
device_reset_old();
device_init_pending();
vlist_flush();
-   device_free_unused(NULL);
interface_refresh_assignments(false);
interface_start_pending();
wireless_start_pending();
diff --git a/device.c b/device.c
index bb39ea7f8d71..b3d0e85f8550 100644
--- a/device.c
+++ b/device.c
@@ -99,18 +99,6 @@ device_type_get(const char *tname)
return NULL;
 }
 
-void device_lock(void)
-{
-   __devlock++;
-}
-
-void device_unlock(void)
-{
-   __devlock--;
-   if (!__devlock)
-   device_free_unused(NULL);
-}
-
 static int device_vlan_len(struct kvlist *kv, const void *data)
 {
return sizeof(unsigned int);
@@ -895,14 +883,27 @@ device_free(struct device *dev)
 }
 
 static void
-__device_free_unused(struct device *dev)
+__device_free_unused(struct uloop_timeout *timeout)
 {
-   if (!safe_list_empty(>users) ||
-   !safe_list_empty(>aliases) ||
-   dev->current_config || __devlock)
-   return;
+   struct device *dev, *tmp;
+
+   avl_for_each_element_safe(, dev, avl, tmp) {
+   if (!safe_list_empty(>users) ||
+   !safe_list_empty(>aliases) ||
+   dev->current_config)
+   continue;
+
+   device_free(dev);
+   }
+}
+
+void device_free_unused(void)
+{
+   static struct uloop_timeout free_timer = {
+   .cb = __device_free_unused,
+   };
 
-   device_free(dev);
+   uloop_timeout_set(_timer, 1);
 }
 
 void device_remove_user(struct device_user *dep)
@@ -919,19 +920,7 @@ void device_remove_user(struct device_user *dep)
safe_list_del(>list);
dep->dev = NULL;
D(DEVICE, "Remove user for device '%s', refcount=%d\n", dev->ifname, 
device_refcount(dev));
-   __device_free_unused(dev);
-}
-
-void
-device_free_unused(struct device *dev)
-{
-   struct device *tmp;
-
-   if (dev)
-   return __device_free_unused(dev);
-
-   avl_for_each_element_safe(, dev, avl, tmp)
-   __device_free_unused(dev);
+   device_free_unused();
 }
 
 void
diff --git a/device.h b/device.h
index 0496e893cbc9..37f8c37c58a3 100644
--- a/device.h
+++ b/device.h
@@ -300,9 +300,6 @@ extern const struct uci_blob_param_list device_attr_list;
 extern struct device_type simple_device_type;
 extern struct device_type tunnel_device_type;
 
-void device_lock(void);
-void device_unlock(void);
-
 void device_vlan_update(bool done);
 void device_stp_init(void);
 
@@ -346,7 +343,7 @@ void device_release(struct device_user *dep);
 int device_check_state(struct device *dev);
 void device_dump_status(struct blob_buf *b, struct 

Re: Wifi bug

[Hannu Nyman]

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 shown up in my own tests...

- Felix



This is probably what you are looking for...
To me it looks like it might actually be a list handling bug in libubox.


perus@ub2104:/Openwrt/r7800$ 
./build_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-11.2.0_musl_eabi/gdb-10.1/gdb/gdb 
./staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/root-ipq806x/sbin/netifd 
netifd.1632756907.1577.11.core

GNU gdb (GDB) 10.1
Copyright (C) 2020 Free Software Foundation, Inc.
...
Type "apropos word" to search for commands related to "word"...
Reading symbols from 
./staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/root-ipq806x/sbin/netifd...


warning: Can't open file /sbin/netifd during file-backed mapping note processing
...
warning: Can't open file /lib/libc.so during file-backed mapping note processing
[New LWP 1577]

warning: Could not load shared library symbols for 8 libraries, e.g. 
/lib/libubox.so.20210819.

Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?
Core was generated by `/sbin/netifd'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0xb6ea058c in ?? ()
(gdb) bt
#0  0xb6ea058c in ?? ()
#1  0x0001edc0 in device_broadcast_cb (ctx=, list=)
    at 
/Openwrt/r7800/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/netifd-2021-09-21-08e954e1/device.c:497

#2  0xb6f2f228 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) set solib-search-path 
./staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/

host/ packages/ pkginfo/  root-ipq806x/ stamp/    usr/
(gdb) set solib-search-path 
./staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/usr/lib/
Reading symbols from 
/Openwrt/r7800/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/usr/lib/libubox.so.20210819...
Reading symbols from 
/Openwrt/r7800/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/usr/lib/libubus.so.20210630...
Reading symbols from 
/Openwrt/r7800/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/usr/lib/libuci.so...
Reading symbols from 
/Openwrt/r7800/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/usr/lib/libjson-c.so.5.1.0...
Reading symbols from 
/Openwrt/r7800/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/usr/lib/libblobmsg_json.so.20210819...
Reading symbols from 
/Openwrt/r7800/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/usr/lib/libnl-tiny.so...

(gdb) bt
#0  0xb6ea058c in __safe_list_del_iterator (i=0xbee1ed0c)
    at 
/Openwrt/r7800/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/libubox-2021-08-19-d716ac4b/safe_list.c:49

#1  __safe_list_move_iterator (i=0xbee1ed0c, list=0xb6f2f220)
    at 
/Openwrt/r7800/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/libubox-2021-08-19-d716ac4b/safe_list.c:58
#2  safe_list_for_each (head=head@entry=0xb6f2f220, cb=cb@entry=0x1ed94 
, ctx=0xbee1ed3c,

    ctx@entry=0xbee1ed34)
    at 
/Openwrt/r7800/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/libubox-2021-08-19-d716ac4b/safe_list.c:73

#3  0x000210d0 in device_broadcast_event (dev=0xb6f2f200, ev=)
    at 
/Openwrt/r7800/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/netifd-2021-09-21-08e954e1/device.c:506

#4  0x000289a4 in handle_hotplug_msg (size=, data=)
    at 
/Openwrt/r7800/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/netifd-2021-09-21-08e954e1/system-linux.c:777

#5  handle_hotplug_event (u=0x46ea4 , events=)
    at 
/Openwrt/r7800/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/netifd-2021-09-21-08e954e1/system-linux.c:793

#6  0xb6e9e9f4 in uloop_run_events (timeout=)
    at 
/Openwrt/r7800/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/libubox-2021-08-19-d716ac4b/uloop.c:198

#7  uloop_run_timeout (timeout=timeout@entry=-1)
    at 
/Openwrt/r7800/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/libubox-2021-08-19-d716ac4b/uloop.c:555

#8  0x00013ae8 in uloop_run ()
    at 
/Openwrt/r7800/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/usr/include/libubox/uloop.h:111

#9  main (argc=1, argv=)
    at 
/Openwrt/r7800/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/netifd-2021-09-21-08e954e1/main.c:339

(gdb)



There is also a few seconds' gap in the system log, when netifd starts again:


Mon Sep 27 18:35:06 2021 kern.warn kernel: [  178.272585] ath10k_pci 
:01:00.0: peer-unmap-event: unknown peer id 0
Mon Sep 27 18:35:06 2021 kern.warn kernel: [  178.272647] ath10k_pci 
:01:00.0: peer-unmap-event: unknown peer id 0
Mon Sep 27 18:35:07 2021 daemon.notice netifd: Network device 'wlan0' link is 
down

Mon Sep 27 18:35:12 2021 user.notice : Added device handler type: bonding
Mon Sep 27 18:35:12 2021 

Re: Wifi bug

[Hannu Nyman]

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:

hb@vbox-linux6:~/src/openwrt/LEDE/archer-C7-ath79-5.10.x-dsa/build_dir/target-mips_74kc_musl/netifd-2021-09-21-08e954e1> 
../../../scripts/remote-gdb netifd.1632747166.9335.11.core netifd

Choose target:
  1) mips_74kc (musl )
GNU gdb (GDB) 10.1
...
Reading symbols from netifd...
[New LWP 9335]
Core was generated by `/sbin/netifd'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x77d79ed5 in ?? (warning: GDB can't find the start of the function at 
0x77d79ed5.


    GDB is unable to find the start of the function at 0x77d79ed5
and thus can't determine the size of that function's stack frame. 



Did you remember to provide it with a unstripped "netifd" binary from the 
staging_dir ?
(or did you try with the stripped final binary in build_dir or router? which 
will fail unless you have disabled stripping and have the full binary intact)




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Wifi bug

[e9hack]

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:

hb@vbox-linux6:~/src/openwrt/LEDE/archer-C7-ath79-5.10.x-dsa/build_dir/target-mips_74kc_musl/netifd-2021-09-21-08e954e1>
 ../../../scripts/remote-gdb netifd.1632747166.9335.11.core netifd
Choose target:
  1) mips_74kc (musl )
GNU gdb (GDB) 10.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu 
--target=mips-openwrt-linux-musl".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from netifd...
[New LWP 9335]
Core was generated by `/sbin/netifd'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x77d79ed5 in ?? (warning: GDB can't find the start of the function at 
0x77d79ed5.

GDB is unable to find the start of the function at 0x77d79ed5
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
This problem is most likely caused by an invalid program counter or
stack pointer.
However, if you think GDB should simply search farther back
from 0x77d79ed5 for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
)
(gdb)

Regards,
Hartmut

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Wifi bug

[Felix Fietkau]

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 
>>> with strace, I got this lines immediately before the page fault:
>>>
>>> unlink("/tmp/resolv.conf.d/resolv.conf.auto.tmp") = -1 ENOENT (No such file 
>>> or directory)
>>> open("/tmp/resolv.conf.d/resolv.conf.auto.tmp", 
>>> O_RDWR|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 14
>>> ioctl(14, TIOCGWINSZ, 0x7f717a74)   = -1 ENOTTY (Not a tty)
>>> _llseek(14, 0, [0], SEEK_SET)   = 0
>>> readv(14, [{iov_base="", iov_len=1023}, {iov_base="", iov_len=1024}], 2) = 0
>>> close(14)   = 0
>>> open("/tmp/resolv.conf.d/resolv.conf.auto", O_RDONLY|O_LARGEFILE) = 14
>>> readv(14, [{iov_base="", iov_len=1023}, {iov_base="", iov_len=1024}], 2) = 0
>>> close(14)   = 0
>>> unlink("/tmp/resolv.conf.d/resolv.conf.auto.tmp") = 0
>>> munmap(0x77d61000, 8192)= 0
>>> --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x77d61038} ---
>>> +++ killed by SIGSEGV +++
>>>
>>> The part 0x77d61... does change on several starts. The offset 0x.038 is 
>>> the same.
>> 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 shown up in my own tests...
>> 
>> - Felix
> 
> It doesn't generate a core-dump. How can I activate core-dumps?
Normally it should be active by default. Is CONFIG_KERNEL_ELF_CORE set
in your .config?

- Felix

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Wifi bug

[e9hack]

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 fault:

unlink("/tmp/resolv.conf.d/resolv.conf.auto.tmp") = -1 ENOENT (No such file or 
directory)
open("/tmp/resolv.conf.d/resolv.conf.auto.tmp", 
O_RDWR|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 14
ioctl(14, TIOCGWINSZ, 0x7f717a74)   = -1 ENOTTY (Not a tty)
_llseek(14, 0, [0], SEEK_SET)   = 0
readv(14, [{iov_base="", iov_len=1023}, {iov_base="", iov_len=1024}], 2) = 0
close(14)   = 0
open("/tmp/resolv.conf.d/resolv.conf.auto", O_RDONLY|O_LARGEFILE) = 14
readv(14, [{iov_base="", iov_len=1023}, {iov_base="", iov_len=1024}], 2) = 0
close(14)   = 0
unlink("/tmp/resolv.conf.d/resolv.conf.auto.tmp") = 0
munmap(0x77d61000, 8192)= 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x77d61038} ---
+++ killed by SIGSEGV +++

The part 0x77d61... does change on several starts. The offset 0x.038 is the 
same.

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 shown up in my own tests...

- Felix


It doesn't generate a core-dump. How can I activate core-dumps?

Regards,
Hartmut


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Wifi bug

[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 fault:
> 
> unlink("/tmp/resolv.conf.d/resolv.conf.auto.tmp") = -1 ENOENT (No such file 
> or directory)
> open("/tmp/resolv.conf.d/resolv.conf.auto.tmp", 
> O_RDWR|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 14
> ioctl(14, TIOCGWINSZ, 0x7f717a74)   = -1 ENOTTY (Not a tty)
> _llseek(14, 0, [0], SEEK_SET)   = 0
> readv(14, [{iov_base="", iov_len=1023}, {iov_base="", iov_len=1024}], 2) = 0
> close(14)   = 0
> open("/tmp/resolv.conf.d/resolv.conf.auto", O_RDONLY|O_LARGEFILE) = 14
> readv(14, [{iov_base="", iov_len=1023}, {iov_base="", iov_len=1024}], 2) = 0
> close(14)   = 0
> unlink("/tmp/resolv.conf.d/resolv.conf.auto.tmp") = 0
> munmap(0x77d61000, 8192)= 0
> --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x77d61038} ---
> +++ killed by SIGSEGV +++
> 
> The part 0x77d61... does change on several starts. The offset 0x.038 is 
> the same.
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 shown up in my own tests...

- Felix

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] mac80211: add support for xiaomi AX9000

[k16622806117]

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 
a/package/kernel/mac80211/patches/237-005-ath11k-Use-exclusive-srng_write32-hif-api-for-srng-w.patch
 
b/package/kernel/mac80211/patches/237-005-ath11k-Use-exclusive-srng_write32-hif-api-for-srng-w.patch
new file mode 100644
index 000..6764cf7
--- /dev/null
+++ 
b/package/kernel/mac80211/patches/237-005-ath11k-Use-exclusive-srng_write32-hif-api-for-srng-w.patch
@@ -0,0 +1,137 @@
+From 2b867c226aa6dae11cf320342b624caaef23b3f1 Mon Sep 17 00:00:00 2001
+From: P Praneesh 
+Date: Mon, 14 Dec 2020 21:56:00 +0530
+Subject: [PATCH 5/6] ath11k: Use exclusive srng_write32 hif api for srng write
+ access
+
+Currently the pci_write32() performs multiple checks on the offset
+argument to identify if its a DP or CE mem offset, and selects
+a corresponding window start address to be added to the offset
+before performing the write operation.
+This could be costly for certain calls falling in the hotpath
+such as ath11k_hal_srng_access_end() which is used by the CE
+and DP code to update the srng head and tail pointer for src and
+dest rings correspondingly.
+
+Hence offload the window start determination during ring
+initialization itself and use the same offset which has window
+start address included for write operation.
+
+Added srng_write32 hif operation for this purpose.
+read32 is not used much in the datapath, hence using the
+existing hif call itself
+
+Signed-off-by: Sriram R 
+Signed-off-by: P Praneesh 
+---
+ drivers/net/wireless/ath/ath11k/ahb.c |  1 +
+ drivers/net/wireless/ath/ath11k/hal.c | 13 -
+ drivers/net/wireless/ath/ath11k/hif.h |  6 ++
+ drivers/net/wireless/ath/ath11k/pci.c |  7 +++
+ 4 files changed, 22 insertions(+), 5 deletions(-)
+
+--- a/drivers/net/wireless/ath/ath11k/ahb.c
 b/drivers/net/wireless/ath/ath11k/ahb.c
+@@ -745,6 +745,7 @@ static const struct ath11k_hif_ops ath11
+   .stop = ath11k_ahb_stop,
+   .read32 = ath11k_ahb_read32,
+   .write32 = ath11k_ahb_write32,
++  .srng_write32 = ath11k_ahb_write32,
+   .irq_enable = ath11k_ahb_ext_irq_enable,
+   .irq_disable = ath11k_ahb_ext_irq_disable,
+   .map_service_to_pipe = ath11k_ahb_map_service_to_pipe,
+--- a/drivers/net/wireless/ath/ath11k/hal.c
 b/drivers/net/wireless/ath/ath11k/hal.c
+@@ -837,13 +837,13 @@ void ath11k_hal_srng_access_end(struct a
+   if (srng->ring_dir == HAL_SRNG_DIR_SRC) {
+   srng->u.src_ring.last_tp =
+   *(volatile u32 *)srng->u.src_ring.tp_addr;
+-  ath11k_hif_write32(ab,
++  ath11k_hif_srng_write32(ab,
+  (unsigned 
long)srng->u.src_ring.hp_addr -
+  (unsigned long)mem,
+  srng->u.src_ring.hp);
+   } else {
+   srng->u.dst_ring.last_hp = *srng->u.dst_ring.hp_addr;
+-  ath11k_hif_write32(ab,
++  ath11k_hif_srng_write32(ab,
+  (unsigned 
long)srng->u.dst_ring.tp_addr -
+  (unsigned long)mem,
+  srng->u.dst_ring.tp);
+@@ -957,6 +957,7 @@ int ath11k_hal_srng_setup(struct ath11k_
+   int i;
+   u32 reg_base;
+   unsigned long *mem;
++  u32 offset;
+ 
+   ring_id = ath11k_hal_srng_get_ring_id(ab, type, ring_num, mac_id);
+   if (ring_id < 0)
+@@ -1015,8 +1016,9 @@ int ath11k_hal_srng_setup(struct ath11k_
+  lmac_idx);
+   srng->flags |= HAL_SRNG_FLAGS_LMAC_RING;
+   } else {
++  offset = ath11k_hif_get_window_offset(ab, reg_base);
+   srng->u.src_ring.hp_addr =
+-  (u32 *)((unsigned long)mem + reg_base);
++  (u32 *)((unsigned long)mem + offset);
+   }
+   } else {
+   /* During initialization loop count in all the descriptors
+@@ -1040,9 +1042,10 @@ int ath11k_hal_srng_setup(struct ath11k_
+  lmac_idx);
+   srng->flags |= HAL_SRNG_FLAGS_LMAC_RING;
+   } else {
+-  srng->u.dst_ring.tp_addr =
+-  (u32 *)((unsigned long)mem + reg_base +
++  offset = ath11k_hif_get_window_offset(ab, reg_base +
+   (HAL_REO1_RING_TP(ab) - 
HAL_REO1_RING_HP(ab)));
++  srng->u.dst_ring.tp_addr =
++  (u32 *)((unsigned long)mem + offset);
+