@frank-w no mt7622 board wifi is disable
have you done the echo to dbdc before running the first commands (as i see 2 wlan interfaces)?
@frank-w my command order is:
- echo 1 > /sys/kernel/debug/ieee80211/phy0/mt76/dbdc
- iw reg set ISO_3166-1_alpha-2
- iw reg set DE
- iw reg get result below:
root@OpenWrt:/# iw reg get global country DE: DFS-ETSI (2400 - 2483 @ 40), (N/A, 20), (N/A) (5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS (5725 - 5875 @ 80), (N/A, 13), (N/A) (57000 - 66000 @ 2160), (N/A, 40), (N/A)
root@OpenWrt:/#
In your log you did
iwinfo wlan1 freqlist
And htinfo before the dbdc…thats why i asked…
But your system is capable of 5ghz now after the region config…does an additional wlanX come up after the echo dbdc? This new one is the 5g device…the older phy is 2g4 only
From line 43 of your log (freqlist was before it but long output)
root@OpenWrt:/# iwinfo wlan1 htmodelist
HT20 HT40
root@OpenWrt:/# echo 1 > /sys/kernel/debug/ieee80211/phy0/mt76/dbdc
So if 7615 phy0 is wlan0 and mt7622 is wlan1 after the echo to dbdc you should see a wlan2 interface in “ip a” (mt7615 phy1) which should be capable of 5ghz
So it was looking on my bpi-r2 (wlan0 is mt7615 phy0 and wlan1 is phy1): 802.11ac 4x4 standard size mini pcie card is launched
As i said earlier, dbdc is merged with 5.7 linux kernel,maybe openwrt uses newer mt76 driver for 5.4, here you need to look in source if dbdc is implemented or only the sys-file exists. Maybe next lts (5.10) comes in openwrt soon. Maybe you can try my debian-image (need to add firmware files) to test your card regardibg the dbdc mode
ok, thanks for your reply.
but it’s confuse for me the BPI kernel 4.19 branch it is support the all function. https://github.com/BPI-SINOVOIP/BPI-R64-openwrt
Maybe openwrt always links latest mt76 driver into it (then it should work),but mainline linux native starts supporting dbdc in mt76 driver from 5.7 (no external linking to openwrts mt76).
Have you tried disabling mt7622? Maybe wlan1 used by mt7622 blocks dbdc anyhow. Normally it should be created by a formatstring like wlan%d so it should create the next free wlanX,but i see in buggy mt6625 (not really comparable i know) driver that access is done to fixed interface name
I have the same random crash at the same address. I will disable HW NAT and monitor for a few days.
Update (20.01.2021): no crash since I disabled hardware NAT.
Could you point me to hwnat patches,did not find them. Afair they were in staging of blogics/felix’ tree,but i do not see them anymore…just need author to ask him about it
The only related i’ve found is this offloading patch in generic/pending
Seems to be this patch as the the code from bug report is from there
It looks like oops occours on (f0+d0=1c0) second rcu_assign_pointer. I don’t see implementation of mtk_foe_entry_commit in the patch (strange because header-entry is created),but i guess it generates a hash for the src-dest relation and saves it to eth->foe_flow_table with hash as index. I guess the hash is created and returned,but entry in flow-table is not created so there is a out-of-bounds access Found implementation of mtk_foe_entry_commit here,but strange access to foe_table after creating hash in mtk_ppe_hash_entry
btw. it looks like offloading is only supported for mt7621 and 7622 (r64), not mt7623 (r2) but always compiled in…try to add patches 15+16 to my repo for testing
seems it needs also basic offload patches (640+), and i cannot apply on my 5.11-base because of missing FLOW_OFFLOAD_* in nf_flow_table.h i did not found in any other patches…no chance to get openwrt-patches into a normal linux tree ;(
have got it merged with 5.10-patches from https://git.openwrt.org/?p=openwrt/staging/nbd.git;a=tree;f=target/linux/generic/pending-5.10;hb=HEAD
but it seems there is no Kconfig-option there…which option needs to be set to get the offloading?
maybe NFT_FLOW_OFFLOAD and/or NETFILTER_XT_TARGET_FLOWOFFLOAD ?
@lcsaszar @dixyes how did you disabled hwnat? unloading any module? can you trigger the issue anyhow?
I guess hwnat related asic should be almost the same in mt762x, so they share the same hwnat code for mt762{0,1,2,3,8,9}?
I enable/disable hwnat via luci: Network->Firewall->{enable “Software flow offloading" then enable/disable “Hardware flow offloading”}
When it’s enabled, just use it as gateway, it will crash at any time.
I still use that openwrt image I built before without enabling hwnat, now my r64 is used as my main router.
I bought r64 because my r6220(mt7621) will panic randomly with SMT and HWNAT both enabled. I disabled SMT, things seems to be OK, but there’s a strange slowly kernel memory leaking, that make r6220 crash in two day to two weeks period.
So I think the panic in SMT and HWNAT enabled mt7621 may be related to the panic in 2-cores and HWNAT enabled mt7622.
However I’m getting busy these days, I cannot confirm that. If I got some time, I will try trigger panic in mt7621 to compare with mt7622 panic.
Maybe,but it is only activated for mt7622 and 7621
Struct mtk_soc_data is modified by adding offload_version…and this has no default value and checked for existance/valid value (all in mtk_eth_soc.c
Reproducing with my code will be useful. Can you compare loaded mpdules when enabled/disabled and look in your kernelconfig,if both above options are set? Seems there is no mtk specific one
PPE offloading codes is located in mtk_soc_eth module, that driver is always built-in (in my own build), so there’s nothing changed in modules list (it’s even not shown in lsmod).
Openwrt use nftables kernel api to enable/disable offloading, I have few knowledge about it, so I donot know what you do to use offloading in common distros. You may check Openwrt fw3 releated code (mostly shell scripts) to find it out.
here’s my iptables -L:
root@BPIR64:~# iptables -L | grep -i offload
# no hwnat setted
FLOWOFFLOAD all -- anywhere anywhere /* !fw3: Traffic offloading */ ctstate RELATED,ESTABLISHED FLOWOFFLOAD
# hwnat enabled
FLOWOFFLOAD all -- anywhere anywhere /* !fw3: Traffic offloading */ ctstate RELATED,ESTABLISHED FLOWOFFLOAD hw
I have CONFIG_NFT_FLOW_OFFLOAD=m and CONFIG_NETFILTER_XT_TARGET_FLOWOFFLOAD=m, the two modules xt_FLOWOFFLOAD and nft_flow_offload is always loaded while enabling/disabling hwnat.
Thanks this looks like we need to know how flowcontrol in nftables need to be enabled…maybe nftables tools are need to patched too. Can you export nftables to file (maybe nftables-save) so we see the command to apply flowtables rule? List does not show it
It crashes too quick that I cannot save it all… maybe I should omit “treat oops as panic” option.
but I managed to get this:
iptables -A FORWARD -m comment --comment "!fw3: Traffic offloading" -m conntrack --ctstate RELATED,ESTABLISHED -j FLOWOFFLOAD --hw
Don’t know if nft or xt userspace tools (nft, iptables command) need to be patched, but seems that xt_FLOWOFFLOAD and nft_flow_offload kmod must be loaded.
So these packets are put in separate chain “flowoffload” with a hw flag…it will be interesting what happens in this chain…have you serial console working? Then you could remove rj45 cables and look on it,maybe there is no crash because no traffic on lan/ports. If serial not working you could try removing only wan,because i guess offloading only happens only if nat is activated on wan.
I think we ahould create new topic for it
Sure, we’d better discuss in standalone thread only about this hwnat issue
could you summarize it? as i don’t see the issue i cannot create opening-post…just trace you’ve got in openwrt, bug-report and iptables/nftables setting…