Sounds like https://github.com/openwrt/openwrt/issues/13198#
Workaround for me has been to disable 2.4GHz WiFi. Keeping 5GHz is ok.
I think the main question here was to get frequency to be shown in htop no matter is it scalable or fixed for peace of mind and satisfaction (e.g 2000MHz). Thank you!
Workaround for me has been to disable 2.4GHz WiFi. Keeping 5GHz is ok.
Yes it looks so. As I had tied 2.4G devices strictly to 2.G and it worked perfectly fine since my initial setup and yesterday some of the devices started to switch between 2.4 and 5G bands. So sticking IOT devices to 2.4G is a better workaround for 2.4G devices only if you have know MAC addresses.
Hey, anyone else got this error in your boot log?
Same error on latest 23.05 (today) and kernel 6.1 snapshot from 2023-10-24.
This is after a clean sysupgrade. So no config or anything else...
[ 1.263651] mtk-pcie-gen3 11280000.pcie: host bridge /soc/pcie@11280000 ranges:
[ 1.270986] mtk-pcie-gen3 11280000.pcie: Parsing ranges property...
[ 1.277244] mtk-pcie-gen3 11280000.pcie: MEM 0x0020000000..0x002fffffff -> 0x0020000000
[ 1.618502] mtk-pcie-gen3 11280000.pcie: PCIe link down, current LTSSM state: detect.quiet (0x1)
[ 1.627299] mtk-pcie-gen3: probe of 11280000.pcie failed with error -110 <----- this one, what is this?
And this one
[ 0.047621] mtk-pcie-gen3 11280000.pcie: host bridge /soc/pcie@11280000 ranges:
[ 0.047641] mtk-pcie-gen3 11280000.pcie: Parsing ranges property...
[ 0.047650] mtk-pcie-gen3 11280000.pcie: MEM 0x0020000000..0x002fffffff -> 0x0020000000
[ 0.047746] /soc/pcie@11280000: Failed to get clk index: 0 ret: -517
[ 0.047755] mtk-pcie-gen3 11280000.pcie: failed to get clocks
Edit:
It's refering to mt7986a.dtsi and line 402.
pcie: pcie@11280000 {
compatible = "mediatek,mt7986-pcie",
"mediatek,mt8192-pcie";
device_type = "pci";
#address-cells = <3>;
#size-cells = <2>;
reg = <0x00 0x11280000 0x00 0x4000>;
reg-names = "pcie-mac";
interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>;
bus-range = <0x00 0xff>;
ranges = <0x82000000 0x00 0x20000000 0x00
0x20000000 0x00 0x10000000>;
clocks = <&infracfg CLK_INFRA_IPCIE_PIPE_CK>,
<&infracfg CLK_INFRA_IPCIE_CK>,
<&infracfg CLK_INFRA_IPCIER_CK>,
<&infracfg CLK_INFRA_IPCIEB_CK>;
clock-names = "pl_250m", "tl_26m", "peri_26m", "top_133m";
status = "disabled";
phys = <&pcie_port PHY_TYPE_PCIE>;
phy-names = "pcie-phy";
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0x7>;
interrupt-map = <0 0 0 1 &pcie_intc 0>,
<0 0 0 2 &pcie_intc 1>,
<0 0 0 3 &pcie_intc 2>,
<0 0 0 4 &pcie_intc 3>;
pcie_intc: interrupt-controller {
#address-cells = <0>;
#interrupt-cells = <1>;
interrupt-controller;
};
};
Yes same failed to get clocks error message here.
Firmware Version OpenWrt 23.05.0 r23497-6637af95aa / LuCI openwrt-23.05 branch git-23.236.53405-fc638c8
Kernel Version 5.15.134
Same problem here 
See here : https://forum.banana-pi.org/t/banana-pi-r3-can-not-control-pwm-fan/16090/2?u=rooot
It just means that the PCIe link is down because no M.2 card is inserted in the slot on the bottom of the board.
1 Like
Hi @daniel . Can the bridger package help offloading wan to lan? I'm using sfp on wan and lan1 + lan2. I'm trying to gather some information for the bridger package, and how it works. But from what I can find, it only offloads lan+wlan if I'm not mistaken. Not sure about the wan+lan etc...
I'm using qosify, so I don't want to brake anything.
Thanks.
Just a report, I had 23.05.0 running on my r3, but after upgrading with sysupgrade to 23.05.2 my wireless is gone.
[ 11.036047] mt798x-wmac 18000000.wifi: HW/SW Version: 0x8a108a10, Build Time: 20221012174743a
[ 11.176497] mt798x-wmac 18000000.wifi: WM Firmware Version: ____000000, Build Time: 20221012174805
[ 11.259269] mt798x-wmac 18000000.wifi: WA Firmware Version: DEV_000000, Build Time: 20221012174937
[ 31.830115] mt798x-wmac 18000000.wifi: Message 00000002 (seq 9) timeout
[ 31.836725] mt798x-wmac 18000000.wifi: Failed to start WA firmware
[ 31.842978] mt798x-wmac: probe of 18000000.wifi failed with error -110
I'm pretty sure this is not supposed to happen.
After perusing a bunch of threads, I removed the SFPs (no help).
Luckily, this was all done on the uSD, so I can still boot my old emmc installation, where it all works (haven't actually tried, this, so I'm just assuming).
Very odd, both 23.05.0 and 23.05.2 run work very well on my R3 board. Maybe you are affected by this hardware problem which can be caused by certain serial adapters:
1 Like
Its certainly possible, but not sure why my FDTI based adapter worked just fine with 23.0.5.0 and would stop working with 23.05.2.
I just pulled the console completely, and rebooted; the behavior is still the same, so its clearly not the adapter.
I might try to make a fresh/new sdcard image and see what happens from there.
I had high hopes for this hardware, but they seem to have been misplaced.
I've also seen reports of similar issues related to not strong enough or "too dirty" power supplies being used. This is even more true if you are using power-hungry SFP, mPCIe or M.2 modules. Please make sure this isn't the cause, as even a minimal change between 23.05.0 to 23.05.2 could result e.g. in changed timing during boot which can be the cause for this kind of issues to surface.
I've just retried using 23.05.2 SD card image on my BPI-R3 V1.1 board and it works just fine.
As an electrical engineer, you'll have to explain to me what you mean by the phrase "too dirty". I understand "too noisy" and marginal (i.e. voltage output drops as current draw increases); I think you probably mean the latter.
Worse, I just flipped the DIPs to boot from my old (23.05.0-rc3, actually) eMMC install, and unfortunately I now have the same issue there; I've also tried several different power-supplies (all rated 12V/2A. as thats what I have available at the moment), all with the same result.
Note that I've already removed the sfp (MM Finisar 8519J), so now is only the nvme ssd that could be the "issue". Alas, this means taking the board out of its box, so its a bit more work, and I'm not terribly hopeful.
I meant power supplies which show strong ripple and HF noise, esp. in moments when load changes. Being an electrical engineer I would trust you to able to make sure that this isn't the problem.
1000Base-* SFP generally draw way below 2W of power (unless you take the 100km versions...), so I'd be surprised if that gives you any problems.
NVMe is more likely to be the cause -- or a broken board (would be the first I hear of).
Hello. Since some of us are doing some custom stuff on the case etc. Anyone could recommend a EMI shield tape for antennas?
Anything on amazon.de?
Thanks.