Alexander Buzin Posted October 23, 2023 Share Posted October 23, 2023 (edited) The image is coped on SD using: sudo dd if=Armbian_23.8.2_Orangepi3b_bookworm_edge_6.5.2.img of=/dev/sda bs=1M status=progress The initial startup is fine (booting, setting of root password, user name/password, wifi setup as well as locales/tzdata). We obtain a system with working internet connection, it can be upgraded using apt etc. However, after reboot wifi fails (the first impression was that we installed something wrong during upgrade phase. However, the sequence: fresh sdcard boot, armbian initialization, reboot (through the reboot command, not a button)) still results in the following: 1708 [ 6.944457] WCN_ERR: read marlin3E chip id fail, ret=-110 1709 [ 6.944506] WCN: marlin_scan_finish! 1710 [ 6.944515] sdiohal:probe ok 1711 [ 6.944740] sdiohal:scan end! 1712 [ 6.944756] WCN: then marlin start to download 1713 [ 6.944802] WCN: marlin_request_firmware from /lib/firmware/wcnmodem.bin start! 1714 [ 6.949062] kworker/0:3: vmalloc error: size 18446744073709551615, exceeds total pages, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0 1715 [ 6.949147] CPU: 0 PID: 73 Comm: kworker/0:3 Not tainted 6.5.2-edge-rockchip64 #1 1716 [ 6.949162] Hardware name: Rockchip RK3566 OPi 3B (DT) 1717 [ 6.949173] Workqueue: events pre_btwifi_download_sdio 1718 [ 6.949205] Call trace: 1719 [ 6.949212] dump_backtrace+0x94/0x114 1720 [ 6.949230] show_stack+0x18/0x24 1721 [ 6.949241] dump_stack_lvl+0x48/0x60 1722 [ 6.949260] dump_stack+0x18/0x24 1723 [ 6.949273] warn_alloc+0x118/0x1b0 1724 [ 6.949290] __vmalloc_node_range+0x724/0x770 1725 [ 6.949302] vmalloc+0x5c/0x6c 1726 [ 6.949312] load_firmware_data_path+0x64/0x220 1727 [ 6.949327] pre_btwifi_download_sdio+0xe8/0x182c 1728 [ 6.949341] process_one_work+0x214/0x4a0 1729 [ 6.949355] worker_thread+0x6c/0x430 1730 [ 6.949366] kthread+0x104/0x108 1731 [ 6.949377] ret_from_fork+0x10/0x20 Full 'armbianmonitor -U' output is provided here https://pastebin.com/87nvKDsN I hope that somebody might get an idea what's happening inside... Kind regards, al P.S. this result doesn't depend on to which wifi network I'm connected (2.4GHz/5GHz). Edited October 23, 2023 by Alexander Buzin 0 Quote Link to comment Share on other sites More sharing options...
Dino René Caballero Marquez Posted October 25, 2023 Share Posted October 25, 2023 Hello, for my part, I could not connect through Bluetooth, are the drivers present? 0 Quote Link to comment Share on other sites More sharing options...
Alexander Buzin Posted November 15, 2023 Author Share Posted November 15, 2023 I have successfully built Armbian_23.11.0-trunk_Orangepi3b_bookworm_edge_6.6.1.img al@orangepi3b:~$ neofetch ------------- █ █ █ █ █ █ █ █ █ █ █ OS: Armbian (23.11.0-trunk) aarch64 ███████████████████████ Host: Rockchip RK3566 OPi 3B ▄▄██ ██▄▄ Kernel: 6.6.1-edge-rockchip64 ▄▄██ ███████████ ██▄▄ Uptime: 48 mins ▄▄██ ██ ██ ██▄▄ Packages: 540 (dpkg) ▄▄██ ██ ██ ██▄▄ Shell: bash 5.2.15 ▄▄██ ██ ██ ██▄▄ Resolution: 1280x1024 ▄▄██ █████████████ ██▄▄ Terminal: /dev/ttyS2 ▄▄██ ██ ██ ██▄▄ CPU: (4) @ 1.800GHz ▄▄██ ██ ██ ██▄▄ Memory: 162MiB / 1915MiB ▄▄██ ██ ██ ██▄▄ ▄▄██ ██▄▄ ███████████████████████ █ █ █ █ █ █ █ █ █ █ █ al@orangepi3b:~$ lspci 00:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3568 Remote Signal Processor (rev 01) al@orangepi3b:~$ lsusb Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 007 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 006 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub The annoying 'wandering bug' with wifi/bt initialization is still present. Some reboots result in successful WCN init, some fail. OrangePi has released image with linux6.6.0-rc5, where this bug is present as well. I have submitted bug report to the opi's github. When wifi/bt is properly initialized BT (as well as wifi) seems to be working fine: al@orangepi3b:~$ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: end0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 2e:67:81:50:50:6c brd ff:ff:ff:ff:ff:ff 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether a0:67:20:f1:bc:33 brd ff:ff:ff:ff:ff:ff inet 192.168.1.103/24 brd 192.168.1.255 scope global dynamic noprefixroute wlan0 valid_lft 75391sec preferred_lft 75391sec inet6 2a00:1370:81a0:5883:ccaf:5af0:3abb:7996/64 scope global dynamic noprefixroute valid_lft 352sec preferred_lft 352sec inet6 fe80::16b8:4ba3:568:1e9e/64 scope link noprefixroute valid_lft forever preferred_lft forever al@orangepi3b:~$ sudo rfkill ID TYPE DEVICE SOFT HARD 0 bluetooth bluetooth unblocked unblocked 1 wlan phy0 unblocked unblocked 2 bluetooth hci0 unblocked unblocked al@orangepi3b:~$ sudo hciconfig hci0: Type: Primary Bus: UART BD Address: A0:67:20:F1:BD:34 ACL MTU: 1021:8 SCO MTU: 240:3 UP RUNNING RX bytes:820 acl:0 sco:0 events:57 errors:0 TX bytes:2775 acl:0 sco:0 commands:57 errors:0 When wifi/bt initialization fails both wifi and bt devices are missing: al@orangepi3b:~$ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: end0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 2e:67:81:50:50:6c brd ff:ff:ff:ff:ff:ff al@orangepi3b:~$ sudo rfkill ID TYPE DEVICE SOFT HARD 0 bluetooth bluetooth unblocked unblocked al@orangepi3b:~$ sudo hciconfig It is still not impossible that I have a faulty hardware, because nobody yet reported neither similar behavior, nor its absence. If some extra tests can shed some light on the behavior of this board please let me know, I can try to perform them. 0 Quote Link to comment Share on other sites More sharing options...
Alexander Buzin Posted November 27, 2023 Author Share Posted November 27, 2023 (edited) Surprisingly, but it seems that I've found a workaround for my problem with opi3b. Let's formulate that problem once again. About 50% of reboots result in incorrect detection of uwe5622 wifi/bt hardware and its failure. This behavior is observed only with kernels 6.5 and 6.6, while 5.10 works fine. It applies both to the self-built images, and to the official one mentioned in the first post of this topic. The first sign of the failure in dmesg output is: [ 6.800762] WCN: start_marlin [MARLIN_WIFI] [ 6.800794] WCN: marlin power state:0, subsys: [MARLIN_WIFI] power 1 [ 6.800805] WCN: the first power on start [ 6.829202] sdiohal:sdiohal_scan_card [ 6.830872] sdiohal:sdiohal_probe: func->class=0, vendor=0x0000, device=0x0000, func_num=0x0001, clock=150000000 [ 6.831338] sdiohal err:dt readl fail ret:-110, system_addr=0x4082c208 where 0x4082c208 is defined as CHIPID_REG_M3E, and -110 is -ETIMEDOUT While correct detection of the uwe5622 hardware looks like this: [ 6.853081] WCN: start_marlin [MARLIN_WIFI] [ 6.853111] WCN: marlin power state:0, subsys: [MARLIN_WIFI] power 1 [ 6.853123] WCN: the first power on start [ 6.880736] sdiohal:sdiohal_scan_card [ 6.881342] sdiohal:sdiohal_probe: func->class=0, vendor=0x0000, device=0x0000, func_num=0x0001, clock=150000000 [ 6.882090] WCN: marlin_get_wcn_chipid: chipid: 0x2355b001 [ 6.882143] WCN: marlin_scan_finish! [ 6.882153] sdiohal:probe ok [ 6.885132] sdiohal:scan end! The file drivers/net/wireless/uwe5622/unisocwcn/Makefile by default enables auto-detection of the chip (CONFIG_CHECK_DRIVER_BY_CHIPID): ifeq ($(CONFIG_RK_WIFI_DEVICE_UWE5622),y) export CONFIG_WCN_SDIO = y #export CONFIG_WCN_USB = y # export CONFIG_WCN_GNSS = y ccflags-y += -DCONFIG_CHECK_DRIVER_BY_CHIPID #ccflags-y += -DCONFIG_UWE5622 BSP_CHIP_ID := uwe5622 WCN_HW_TYPE := sdio endif However, if we turn auto-detection off and fix chip type explicitly in the form of CONFIG_UWE5622: #ccflags-y += -DCONFIG_CHECK_DRIVER_BY_CHIPID ccflags-y += -DCONFIG_UWE5622 The situation changes dramatically. While still we observe either successful or non-succesfull execution of sdiohal_readl function, the wifi/bt operation starts correctly always. Lucky start: [ 7.331850] sdiohal:sdiohal_scan_card [ 7.332293] sdiohal:sdiohal_probe: func->class=0, vendor=0x0000, device=0x0000, func_num=0x0001, clock=150000000 [ 7.333169] sdiohal:reg_value: 0x0 [ 7.334238] sdiohal:reg_value: 0x80 [ 7.334777] sdiohal:reg_value 0x04: 0x0 [ 7.336164] sdiohal:reg_value 0x04: 0x0 [ 7.339875] sdiohal:reg_value 0x08: 0x0 [ 7.345033] sdiohal:reg_value 0x08: 0x0 [ 7.345588] sdiohal:reg_value 0x0: 0x0 [ 7.346610] sdiohal:reg_value 0x0: 0x0 [ 7.346737] WCN: marlin_scan_finish! [ 7.346749] sdiohal:probe ok [ 7.346971] sdiohal:scan end! [ 7.346985] WCN: then marlin start to download [ 7.347491] WCN: marlin_get_wcn_chipid: chipid: 0x2355b001 [ 7.347515] WCN: marlin_request_firmware from /lib/firmware/uwe5622/wcnmodem.bin start! Unlucky start: [ 7.330243] sdiohal:sdiohal_scan_card [ 7.330827] sdiohal:sdiohal_probe: func->class=0, vendor=0x0000, device=0x0000, func_num=0x0001, clock=150000000 [ 7.331215] sdiohal err:dt readl fail ret:-110, system_addr=0x40840014 [ 7.331232] sdiohal:sdio dump_aon_reg entry [ 7.331263] sdiohal:pmu sdio status:[0x140]:0xe1 [ 7.331294] sdiohal:pmu sdio status:[0x141]:0x3c [ 7.331321] sdiohal:pmu sdio status:[0x142]:0xf [ 7.331349] sdiohal:pmu sdio status:[0x143]:0xd9 [ 7.331376] sdiohal:pmu sdio status:[0x144]:0x0 [ 7.331402] sdiohal:pmu sdio status:[0x145]:0x0 [ 7.331429] sdiohal:pmu sdio status:[0x146]:0x0 [ 7.331456] sdiohal:pmu sdio status:[0x147]:0x0 [ 7.331483] sdiohal:pmu sdio status:[0x148]:0x66 [ 7.331510] sdiohal:pmu sdio status:[0x149]:0x0 [ 7.331536] sdiohal:pmu sdio status:[0x14a]:0x0 [ 7.331563] sdiohal:pmu sdio status:[0x14b]:0x0 [ 7.331590] sdiohal:pmu sdio status:[0x14c]:0x0 [ 7.331616] sdiohal:pmu sdio status:[0x14d]:0x0 [ 7.331643] sdiohal:pmu sdio status:[0x14e]:0x0 [ 7.331669] sdiohal:pmu sdio status:[0x14f]:0x0 [ 7.331768] sdiohal:cm4d haddr 0:[0x144]:0x0 [ 7.331799] sdiohal:cm4d haddr 0:[0x145]:0x0 [ 7.331828] sdiohal:cm4d haddr 0:[0x146]:0x0 [ 7.331857] sdiohal:cm4d haddr 0:[0x147]:0x0 [ 7.331957] sdiohal:cm4i haddr 1:[0x144]:0x0 [ 7.331986] sdiohal:cm4i haddr 1:[0x145]:0x0 [ 7.332015] sdiohal:cm4i haddr 1:[0x146]:0x0 [ 7.332043] sdiohal:cm4i haddr 1:[0x147]:0x0 [ 7.332145] sdiohal:cm4s haddr 2:[0x144]:0x0 [ 7.332175] sdiohal:cm4s haddr 2:[0x145]:0x0 [ 7.332203] sdiohal:cm4s haddr 2:[0x146]:0x0 [ 7.332232] sdiohal:cm4s haddr 2:[0x147]:0x0 [ 7.332331] sdiohal:dmaw haddr 3:[0x144]:0x0 [ 7.332360] sdiohal:dmaw haddr 3:[0x145]:0x0 [ 7.332388] sdiohal:dmaw haddr 3:[0x146]:0x0 [ 7.332416] sdiohal:dmaw haddr 3:[0x147]:0x0 [ 7.332518] sdiohal:dmar haddr 4:[0x144]:0x0 [ 7.332548] sdiohal:dmar haddr 4:[0x145]:0x0 [ 7.332575] sdiohal:dmar haddr 4:[0x146]:0x0 [ 7.332603] sdiohal:dmar haddr 4:[0x147]:0x0 [ 7.332704] sdiohal:aon_to_ahb haddr 5:[0x144]:0x0 [ 7.332734] sdiohal:aon_to_ahb haddr 5:[0x145]:0x0 [ 7.332763] sdiohal:aon_to_ahb haddr 5:[0x146]:0x0 [ 7.332792] sdiohal:aon_to_ahb haddr 5:[0x147]:0x0 [ 7.332894] sdiohal:axi_to_ahb haddr 6:[0x144]:0x0 [ 7.332923] sdiohal:axi_to_ahb haddr 6:[0x145]:0x0 [ 7.332952] sdiohal:axi_to_ahb haddr 6:[0x146]:0x0 [ 7.332981] sdiohal:axi_to_ahb haddr 6:[0x147]:0x0 [ 7.333081] sdiohal:hready_status haddr 7:[0x144]:0xff [ 7.333111] sdiohal:hready_status haddr 7:[0x145]:0xff [ 7.333139] sdiohal:hready_status haddr 7:[0x146]:0xfb [ 7.333168] sdiohal:hready_status haddr 7:[0x147]:0x10 [ 7.333176] sdiohal:val:0x3c [ 7.333181] sdiohal:sdio dump_aon_reg end [ 7.333184] sdiohal:sdiohal_abort [ 7.333206] sdiohal:before abort, SDIO_VER_CCCR:0x43 [ 7.333239] sdiohal:after abort, SDIO_VER_CCCR:0x43 [ 7.333248] sdiohal:reg_value: 0xffffffff [ 7.333747] sdiohal:reg_value: 0xfffffeff [ 7.338906] sdiohal:reg_value 0x04: 0x0 [ 7.339544] sdiohal:reg_value 0x04: 0x0 [ 7.339900] sdiohal:reg_value 0x08: 0x0 [ 7.340512] sdiohal:reg_value 0x08: 0x0 [ 7.340848] sdiohal:reg_value 0x0: 0x0 [ 7.341439] sdiohal:reg_value 0x0: 0x0 [ 7.341656] WCN: marlin_scan_finish! [ 7.341682] sdiohal:probe ok [ 7.343219] sdiohal:scan end! [ 7.343247] WCN: then marlin start to download [ 7.343809] WCN: marlin_get_wcn_chipid: chipid: 0x2355b001 [ 7.343835] WCN: marlin_request_firmware from /lib/firmware/uwe5622/wcnmodem.bin start! Auto-detection supports a selection between three chips: * 0x2355000x: Marlin3 series (AFAIU WIFI/BT/GNSS) * 0x2355B00x: Marlin3 lite series (AFAIU Marlin3 without GNSS) * 0x5663000x: Marlin3E series (AFAIU aka 5621ds) It seems that developers of uwe5622 tried to implement auto-detection, but in some cases it has failed, e.g. hisilicon with usb-uwe5623, rk with uwe5621. IMHO it's just one more failed case. I tested more than 10 reboots, every time the initialization of WIFI/BT is ok. Finally, I've found the source of the problem. It is patch wifi-4003-uwe5622-adjust-for-rockchip.patch first introduced in rockchip64-6.5 and moved further to rockchip64-6.6. It includes the following change against yet unknown to me source: --- a/drivers/net/wireless/uwe5622/unisocwcn/Makefile +++ b/drivers/net/wireless/uwe5622/unisocwcn/Makefile @@ -70,8 +70,8 @@ ifeq ($(CONFIG_RK_WIFI_DEVICE_UWE5622),y) export CONFIG_WCN_SDIO = y #export CONFIG_WCN_USB = y # export CONFIG_WCN_GNSS = y -#ccflags-y += -DCONFIG_CHECK_DRIVER_BY_CHIPID -ccflags-y += -DCONFIG_UWE5622 +ccflags-y += -DCONFIG_CHECK_DRIVER_BY_CHIPID +#ccflags-y += -DCONFIG_UWE5622 BSP_CHIP_ID := uwe5622 WCN_HW_TYPE := sdio endif It seems that the authors of the original code were already doubtful about ability of their creature to correctly detect uwe5622 in RK environment. IMHO this patch should be reverted. I have not succeeded to create an issue about this CSC board (despite the fact that the failing image is a part of https://www.armbian.com/download/ ). Further I'm going to test stability of wifi connection over longer time. P.S. I feel I want to add a disclaimer... Despite somewhat critical nature of this thread I completely recognize a tremendous effort performed by armbian team to enable so easy building, patching, testing and working of GNU/Linux on a huge amount of underlying boards. Special thanks to Paolo Sabatino (and probably not only to him) for enabling this poorly documented (probably better to say undocumented, as well as erroneously documented) bs to work. Thanks a lot guys! Edited November 29, 2023 by Alexander Buzin discovery of harmful patch responsible for this failure 0 Quote Link to comment Share on other sites More sharing options...
Alexander Buzin Posted November 27, 2023 Author Share Posted November 27, 2023 (edited) One more result of my studies is the fact that we have at least two errors in unisoc_uwe_bsp: uwe-bsp {} section of patch//kernel/archive/rockchip64-6.6/dt/rk3566-orangepi-3b.dts file. The current implementation is: unisoc_uwe_bsp: uwe-bsp { compatible = "unisoc,uwe_bsp"; wl-reg-on = <&gpio0 RK_PD3 GPIO_ACTIVE_HIGH>; bt-reg-on = <&gpio2 RK_PB7 GPIO_ACTIVE_HIGH>; wl-wake-host-gpio = <&gpio0 RK_PD6 GPIO_ACTIVE_HIGH>; bt-wake-host; bt-wake-host-gpio = <&gpio2 RK_PC0 GPIO_ACTIVE_HIGH>; sdio-ext-int-gpio = <&gpio2 RK_PC1 GPIO_ACTIVE_HIGH>; unisoc,btwf-file-name = "/lib/firmware/wcnmodem.bin"; blksz-512; keep-power-on; }; The corresponding dmesg excerpt looks like: [ 2.784301] WCN: marlin_init entry! [ 2.785118] WCN: marlin_parse_dt chip_en gpio=27 [ 2.785143] WCN_ERR: gpio chip_en request err: 27 [ 2.785171] WCN: marlin_parse_dt reset gpio=79 [ 2.785212] WCN: wcn config keep power on [ 2.785221] WCN: wcn config bt wake host [ 2.785242] WCN: marlin_parse_dt bt-wake-host-gpio=80 [ 2.785895] sdiohal:sdiohal_parse_dt adma_tx:0, adma_rx:0, pwrseq:0, irq type:gpio, gpio_num:81, blksize:512 [ 2.785916] sdiohal:not config sdio host node. [ 2.790439] sdiohal:sdiohal_init ok [ 2.791699] WCN: marlin_probe ok! wl-reg-on should be disabled like it is already done in rk3399-orangepi-4-lts.dts: //wl-reg-on = <&gpio0 10 GPIO_ACTIVE_HIGH>; // handled by sdio-pwrseq it's existence results in the confusing error message: [ 2.785143] WCN_ERR: gpio chip_en request err: 27 which comes from the fact that pin 0 RK_PD3 is already acquired by sdio_pwrseq reset-gpios. The statement wl-wake-host-gpio = <&gpio0 RK_PD6 GPIO_ACTIVE_HIGH>; is senseless, because in fact it does not acquire gpio: sudo gpioinfo /dev/gpiochip0 gpiochip0 - 32 lines: ...................... line 27: unnamed "reset" output active-low [used] ...................... line 30: unnamed unused input active-high To really enable wl-wake-host-gpio the line wl-wake-host; should be added to dts file, Otherwise wl-wake-host-gpio should be also commented out to disable it completely. So if we comment out wl-reg-on line and add wl-wake-host; line the dmesg output will look very nice: [ 2.739043] WCN: marlin_init entry! [ 2.739730] WCN: marlin_parse_dt reset gpio=79 [ 2.739782] WCN: wcn config keep power on [ 2.739792] WCN: wcn config bt wake host [ 2.739814] WCN: marlin_parse_dt bt-wake-host-gpio=80 [ 2.739834] WCN: wcn config wifi wake host [ 2.739856] WCN: marlin_parse_dt wl-wake-host-gpio=30 [ 2.740211] sdiohal:sdiohal_parse_dt adma_tx:0, adma_rx:0, pwrseq:0, irq type:gpio, gpio_num:81, blksize:512 [ 2.740230] sdiohal:not config sdio host node. [ 2.744759] sdiohal:sdiohal_init ok [ 2.746017] WCN: marlin_probe ok! gpios now also look really nice: gpiochip0 - 32 lines: line 27: unnamed "reset" output active-low [used] line 30: unnamed "wl-wake-host-gpio" input active-high [used] gpiochip2 - 32 lines: line 15: unnamed "reset" output active-high [used] line 16: unnamed "bt-wake-host-gpio" input active-high [used] line 17: unnamed "sdiohal_gpio" input active-high [used] The only problem is that we don't know which lines are really used and which are connected to NC (not connected) pins of 20U5622 package, which has several possible control lines pinouts... I have strong impression that bt-reg-on and wl-wake-host-gpio in opi3b are connected to NC pins and can be removed. On the other hand, probably, it is better to provide full set of lines and let software to decide which ones to use... Finally, rk3399-orangepi-4-lts.dts is also buggy. The lines bt-wake-host-gpio and wl-wake-host-gpio are missing their enablers bt-wake-host and wl-wake-host, so, they are not active. This can be checked by gpioinfo. Probably it means that they are not needed. Edited November 27, 2023 by Alexander Buzin 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.