After some testing, I also have a consistent issue with the BQL patch. Installed the exact same OpenWRT without the BQL patch and it's not having this issue.
In my case the router locks up during a speedtest, flent rrul run or fast.com speedtest.
Steps to reproduce:
- Run one of those speedtests
- During the download phase, the router CPU usage is much higher than expected, fully maxing out one of the cores. Router becomes very sluggish, SSH stops responding nor sending anymore output. Router does not seem to recover, no longer responds to pings.
Takes about 1 or 2 speedtest.net runs to trigger the issue for me.
Interesting. Are you using a single router port both for speedtest and other connections such as SSH?
No, I'm using 3 ports in total on the router.
p0, 2.5Gbps port connected to a cable modem, link at 1Gbps due to the cable modem not supporting higher.
p1, 1Gbps port connected to a DSL modem.
p2, 1Gbps port connected to a switch.
I also did some testing, however, on top of the net-next main branch (i.e. v6.1-rc1). Some observations:
- Rootfs over NFS (1G RGMII)- stable all the time
- Another 1G RGMII port: ssh sessions when a port was under
iperf3 -P4 (@10/100/1000 speeds, both directions) - no single disconnect. With iperf3 + ping I haven't noticed an improvement in response (with and without BQL), but regardless of speed and direction, the intervals were very stable. I probably need to run a more sophisticated BQL examination
- 10G SFP+ ports bridged and bidirectional RFC2544 latency/jitter test. Latency improved by 1-2% with BQL.
The question is, why I don't observe similar issues to what you see on Mikrotik and OpenWRT. I am wondering if this can be a kernel baseline-related, or some other configuration. Can you provide me with a
zcat /proc/config.gz output?
All I have are the scars on my back from 3 weeks of hacking on the beaglebone BQL driver, where in some flash of insight and a lot of printks, I saw it was rounding up the size of the smallest tx packets by a few on the rx return, and that was why it was hanging.
I was disproportionately happy at finally getting this right as finally my audio and LED blinkenlights were reliably in sync, no matter the rest of the load on the audio subsystem.
I know this is not necessarily adding insight but... in the other tester's setups are there encapsulations in play?
As someone was asking about PoE:
I started to work on this yesterday and I can successfully communicate with the PoE controller using mtpoe_ctrl but the PoE controller on the RB5009 uses the Mikrotik PoE protocol v4 but mtpoe_ctrl only implements up to version 3 so only some commands (firmware version, temperature and input voltage readout) work.
I'm currently working on reversing their kernel driver but it's pretty tedious work... (maybe I'll whip out the logic analyzer and stock firmware later, it almost seems like the easier option...).
For details see Mikrotik RB750 r2 series POE - #68 by TheChaosJack
@adron @robimarko Hi guys, I am wondering if you ever get the JTAG working on the Marvell Armada 7040 (88f7040). I get the same errors as you guys and it just not seem to work. Did you had any luck in the recent time or even a working config file for openocd? Thank you!
Unfortunatelly not, even on a different 7040 board I cannot get OpenOCD to work
That is a pity. Thank you for the replay though!
Hello I have the RB5009 with the first OpenWrt firmware, is there a recent image with the 5.15 kernel, I can't build an image
@robimarko I just noticed that on my board, TMS and TDI are tied to VCC over a small resistor (4.5 kΩ). Correct me if I am wrong, but isn't that a way to deactivate JTAG? Did you notice something similar on your board?
I did not look for it at all, RB5009 is on the todo pile currently
okay I see, what I noticed is that I just have the nTRST pin available on the 10-pin JTAG header, but not the nReset pin (at least I think that, since I only get a JTAG-ID back, if I connect pin 10 from the ARM-JTAG Header to nTRST on my J-Link). This is exactly the opposite what you described earlier, right? You had the Reset pin available, I believe. Do you know any approach to identify a reset pin on a pcb? because I do not have access to the datasheet of the marvell 7040. Thank you!
I am gonna be honest and say, that I really dont remember what was experimented way back.
I dont think that it was me that even tried JTAG on RB5009
Any reason why you reverted to iptables/fiirewall3?
Probably by accident when converting another config from an older device.
Thank you for your build !
Do you have the full nftables version? if so, very gladly.
Replaced it with an nftables version now.