They were the images provided by downloads.openwrt.org, thus why I'm puzzled.
I have sama issue
I tried again today, used the plain openwrt-mediatek-filogic-bananapi_bpi-r3-mini-squashfs-sysupgrade.itb, the configurations are still not recovered when using the eMMC.
volume_identify could fail to find the tar because of the use of fitrw?
I've spend some time to debug the issue. And initially I was confused why it would work fine on the BPi R3 but not on the R3-mini.
Then I found this:
The presence of BLOCKSIZE (which is needed for the ubinized image) causes pad-rootfs to act different from how it acts without a given BLOCKSIZE:
And that results in padding to start with a bunch of all-1s before the 0xdeadc0de:
010c79f0 70 54 0b 8c b3 d9 d1 28 42 00 00 00 00 3f 80 b6 |pT.....(B....?..|
010c7a00 2c 00 01 cd 03 d0 1f 00 00 b3 fe ad 18 3e 30 0d |,............>0.|
010c7a10 8b 02 00 00 00 00 01 59 5a 19 c3 b5 00 00 00 00 |.......YZ.......|
010c7a20 00 23 c8 b5 00 00 00 00 00 04 80 00 00 00 00 29 |.#.............)|
010c7a30 ca b5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
010c7a40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
010c8000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
010e0000 de ad c0 de 00 00 00 00 00 00 00 00 7b 20 20 22 |............{ "|
And that then results in fstools not even looking for a backup tar.gz.
I've fixed this in fstools:
And bumped fstools on openwrt.git:
1 Like
Thanks for this - I guess this will fix a similar issue I'm experiencing on the WS-AP3915i that I never investigated: WS-AP3915i: Settings lost upgrading 23.05.0 -> 23.05.2
Looking at the sysupgrade image, it has a bunch of 0xff before the 0xdeadc0de marker, the system is on an SPI-NOR flash.
Thank you a lot!
I am still seeing this issue (crash at disabling wifi with wifi-schedule) regularly after 2-3 days of continuous using the device. The problem is I cannot reproduce it consistently. It seems that only by using the device some time and then make enabling/disabling operations the crash manifests. I am compiling my own firmware with some included packages (like bridger) and also I am using the latest wifi firmware from mediatek (20240507...) with hw offload and wed enabled. I initially thought that maybe is due to having packet steering enabled, so I disabled it but this wasn't the cause. Maybe someone can look at the log and give me some advices?
Oops#1 Part1
<6>[146505.201187] br-lan: port 3(phy1-ap0) entered blocking state
<6>[146505.206845] br-lan: port 3(phy1-ap0) entered disabled state
<6>[146505.212551] mt798x-wmac 18000000.wifi phy1-ap0: entered allmulticast mode
<6>[146505.219600] mt798x-wmac 18000000.wifi phy1-ap0: entered promiscuous mode
<6>[146505.226515] br-lan: port 3(phy1-ap0) entered blocking state
<6>[146505.232171] br-lan: port 3(phy1-ap0) entered forwarding state
<6>[146505.879629] br-lan: port 3(phy1-ap0) entered disabled state
<6>[146505.893048] br-lan: port 3(phy1-ap0) entered blocking state
<6>[146505.898716] br-lan: port 3(phy1-ap0) entered forwarding state
<6>[196151.836812] mt798x-wmac 18000000.wifi phy0-ap0: left allmulticast mode
<6>[196151.843569] mt798x-wmac 18000000.wifi phy0-ap0: left promiscuous mode
<6>[196151.850262] br-lan: port 2(phy0-ap0) entered disabled state
<1>[196152.341076] Unable to handle kernel paging request at virtual address b4aef5269c1fc0e8
<1>[196152.349077] Mem abort info:
<1>[196152.351959] ESR = 0x0000000096000004
<1>[196152.355781] EC = 0x25: DABT (current EL), IL = 32 bits
<1>[196152.361167] SET = 0, FnV = 0
<1>[196152.364294] EA = 0, S1PTW = 0
<1>[196152.367507] FSC = 0x04: level 0 translation fault
<1>[196152.372458] Data abort info:
<1>[196152.375410] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
<1>[196152.380966] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
<1>[196152.386085] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
<1>[196152.391467] [b4aef5269c1fc0e8] address between user and kernel address ranges
<0>[196152.398669] Internal error: Oops: 0000000096000004 [#1] SMP
<7>[196152.404309] Modules linked in: ksmbd pppoe ppp_async wireguard pppox ppp_generic nft_redir nft_nat nft_masq nft_flow_offload nft_fib_inet nft_ct nft_chain_nat nf_nat nf_flow_table_inet nf_flow_table nf_conntrack_netlink nf_conntrack mt7915e(O) mt76_connac_lib(O) mt76(O) mac80211(O) libchacha20poly1305 ipt_REJECT chacha_neon cfg80211(O) xt_time xt_tcpudp xt_multiport xt_mark xt_mac xt_limit xt_comment xt_TCPMSS xt_LOG slhc sch_cake poly1305_neon nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_quota nft_numgen nft_log nft_limit nft_hash nft_fib_ipv6 nft_fib_ipv4 nft_fib nf_tables nf_reject_ipv6 nf_reject_ipv4 nf_log_syslog nf_defrag_ipv6 nf_defrag_ipv4 libcurve25519_generic libcrc32c libchacha iptable_mangle iptable_filter ip_tables compat(O) cls_flower act_vlan crypto_safexcel ntfs3 cls_bpf act_bpf sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32 cls_route cls_matchall cls_fw cls_flow cls_basic act_skbedit act_mirred act_gact pwm_fan xt_set x_tables ip_set_list_set ip_set_hash_netportnet
<7>[196152.404481] ip_set_hash_netport ip_set_hash_netnet ip_set_hash_netiface ip_set_hash_net ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ipmac ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink nls_ucs2_utils cifs_arc4 asn1_decoder ifb ip6_udp_tunnel udp_tunnel oid_registry nls_utf8 nls_iso8859_1 nls_cp437 nls_cp1250 sha512_arm64 sha1_ce sha1_generic seqiv md5 md4 geniv des_generic libdes cbc authencesn authenc usb_storage leds_gpio xhci_plat_hcd xhci_pci xhci_mtk_hcd xhci_hcd fsl_mph_dr_of ehci_platform ehci_fsl ehci_hcd gpio_button_hotplug(O) vfat fat exfat dm_mirror dm_region_hash dm_log dm_crypt dm_mod dax usbcore usb_common aquantia air_en8811h tpm encrypted_keys trusted [last unloaded: ksmbd]
<7>[196152.563721] CPU: 3 PID: 2065 Comm: hostapd Tainted: G O 6.6.36 #0
<7>[196152.571270] Hardware name: Bananapi BPi-R3 Mini (DT)
<7>[196152.576302] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
<7>[196152.583329] pc : mtk_wed_setup_tc_block_cb+0x4/0x38
<7>[196152.588283] lr : tc_setup_cb_reoffload+0x30/0x134
<7>[196152.593057] sp : ffffffc081e53350
<7>[196152.596442] x29: ffffffc081e53350 x28: ffffffc080c704f8 x27: ffffff80039981c0
<7>[196152.603645] x26: 0000000000000000 x25: ffffff800b0b6800 x24: 0000000000000000
<7>[196152.610847] x23: 0000000000000000 x22: 0000000000000000 x21: ffffff800d0bcb6c
<7>[196152.618049] x20: ffffff800b0b6800 x19: ffffff800098ee80 x18: ffffffffffffc8f8
<7>[196152.625252] x17: ffffffbfff076000 x16: ffffffc080c90000 x15: 000041a46484ad6f
<7>[196152.632454] x14: 0000000000000000 x13: 0000000000000030 x12: 0000000000000002
<7>[196152.639657] x11: 00000000000000b0 x10: 00000000000008a0 x9 : ffffffc081e535e0
<7>[196152.646858] x8 : 0000000000000001 x7 : ffffff800d0bcb6c x6 : ffffff8009b5c320
<7>[196152.654061] x5 : ffffffc081e533f8 x4 : 0000000000000005 x3 : b4aef5269c1fbff8
<7>[196152.661263] x2 : ffffff8000265300 x1 : ffffffc081e533f8 x0 : 0000000000000005
<7>[196152.668466] Call trace:
<7>[196152.670985] mtk_wed_setup_tc_block_cb+0x4/0x38
<7>[196152.675587] 0xffffffc0790cb4bc
<7>[196152.678839] tcf_block_playback_offloads+0x70/0x1e8
<7>[196152.683786] tcf_block_unbind+0x6c/0xc8
<7>[196152.687692] tcf_block_setup+0x38/0x1e8
<7>[196152.691599] tcf_block_offload_cmd.isra.0+0xdc/0x128
<7>[196152.696632] tcf_block_offload_unbind+0x50/0x8c
<7>[196152.701233] __tcf_block_put+0x88/0x178
<7>[196152.705138] tcf_block_put_ext+0x4c/0x60
<7>[196152.709132] 0xffffffc0790aa974
<7>[196152.712357] __qdisc_destroy+0x40/0xa0
<7>[196152.716180] qdisc_put+0x54/0x6c
<7>[196152.719480] dev_shutdown+0x90/0x108
<7>[196152.723127] unregister_netdevice_many_notify+0x2ec/0x780
<7>[196152.728596] unregister_netdevice_queue+0xa4/0xb0
<7>[196152.733369] cfg80211_shutdown_all_interfaces+0x32c/0x37c [cfg80211]
<7>[196152.739806] cfg80211_unregister_wdev+0x10/0x18 [cfg80211]
<7>[196152.745371] ieee80211_if_remove+0x6c/0x110 [mac80211]
<7>[196152.750610] ieee80211_channel_switch_disconnect+0x1ce4/0x1cf0 [mac80211]
<7>[196152.757483] cfg80211_remove_virtual_intf+0x58/0x68 [cfg80211]
<7>[196152.763395] cfg80211_check_station_change+0x3190/0x32a8 [cfg80211]
<7>[196152.769740] genl_family_rcv_msg_doit+0xa8/0x108
<7>[196152.774431] genl_rcv_msg+0x1ac/0x240
<7>[196152.778166] netlink_rcv_skb+0x5c/0x128
<7>[196152.782075] genl_rcv+0x34/0x48
<7>[196152.785289] netlink_unicast+0x1e0/0x2c8
<7>[196152.789284] netlink_sendmsg+0x198/0x3c8
<7>[196152.793278] ____sys_sendmsg+0x1c8/0x278
<7>[196152.797273] ___sys_sendmsg+0x7c/0xc0
<7>[196152.801007] __sys_sendmsg+0x44/0x98
<7>[196152.804654] __arm64_sys_sendmsg+0x20/0x28
<7>[196152.808821] invoke_syscall.constprop.0+0x4c/0xe0
<7>[196152.813597] do_el0_svc+0x3c/0xb8
<7>[196152.816984] el0_svc+0x18/0x4c
<7>[196152.820115] el0t_64_sync_handler+0x118/0x124
<7>[196152.824543] el0t_64_sync+0x150/0x154
<0>[196152.828279] Code: b9401fe0 a8c27bfd d65f03c0 a9400c42 (f9407863)
<4>[196152.834439] ---[ end trace 0000000000000000 ]---
<3>[196152.843617] pstore: backend (ramoops) writing error (-28)
<0>[196152.849088] Kernel panic - not syncing: Oops: Fatal exception
<2>[196152.854899] SMP: stopping secondary CPUs
<0>[196152.858894] Kernel Offset: disabled
<0>[196152.862452] CPU features: 0x0,00000000,00000000,1000400b
<0>[196152.867832] Memory Limit: none
Hi team!!!
Does anyone have information about when approximately a full-release OpenWRT image?
This function in drivers/net/ethernet/mediatek/mtk_wed.c is quite small and simple. It's worth adding some debugging printk lines there which will flood your logs, but as those will be the last lines before the crash it will tell us what's happening.
Thanks for the idea, meanwhile I think I discovered the problem, my build included qosify which was used for some tests during my first experiences with the device, but soon I switched to using full hardware NAT + WED and forgot to disable the now irrelevant qosify service... So I disabled it and now the device seems fine. However, I noticed another issue one single time at the WLAN re-enabling phase, bridger started to use one CPU core 100%. I restarted the service and now it seems OK, so I think there is some issue inside Felix's code when dealing with network changes when the services are active.
Hello, any news?
It seems that recent builds of OpenWRT isolate wireless clients, they cannot ping or see each other. I reverted to a build from 6th of August to get back client inter-communication. Is this intentional? Does something need to be changed in the configuration? Note that I did not test between wireless and LAN clients, only between wireless.
LE: I made a new main build with reverted mt76 to this commit and local wireless clients started to see each other again. @daniel @nbd can you please check what it is happening? Thanks!
It is probably better to open a bug report here: https://github.com/openwrt/mt76/issues
Please try latest master from mt76.git to see if things work better now. I've pushed some fixes that might help
Thanks for the quick response, I've tested the new mt76 build with the fixes but unfortunately without success 
LE: I tested communication between LAN and WLAN and it was somehow strange. A ping from LAN to WLAN was not OK, but then I pinged from WLAN to LAN and it worked, then it worked from LAN to WLAN also... I use HW NAT + WED + bridger.
Thanks for the provided fixes. Unfortunately, this (also) does not help to solve the WLAN problems with MDNS/AVAHI, for example grouping of speakers or other HIFI components no longer works.
For further testing, I've reverted the latest master with the former mt76 stack ...
PKG_SOURCE_DATE:=2024-07-13
PKG_SOURCE_VERSION:=3b47d9df427c4833605a172f2a8f0e0012b04c80
... and all HIFI components are went back to normal.
1 Like
Please try latest patch from Felix here applied to latest mt76. It fixed the problem for me.
1 Like
Thanks, I'll test as soon as the build for my target (BPI-R3) is working again in master. Currently broken with latest kernel 6.6.47 due to a missing config symbol, e.g.
*
* Restart config...
*
*
* ARMv8.2 architectural features
*
Enable support for persistent memory (ARM64_PMEM) [N/y/?] n
Enable support for RAS CPU Extensions (ARM64_RAS_EXTN) [N/y/?] n
Enable support for Common Not Private (CNP) translations (ARM64_CNP) [Y/n/?] (NEW) make[8]: *** [scripts/kconfig/Makefile:77: syncconfig] Error 1
make[7]: *** [Makefile:697: syncconfig] Error 2
Yes, try to add to target/linux/mediatek/filogic/config-6.6 the following lines:
CONFIG_ARM64_CNP=y
CONFIG_ARM64_EPAN=y
or revert to a previous commit before Hauke's modifications
LE: Also master mt76 was updated with the fixes.
1 Like