More details on how to implement this? I am seeing the same thing.
If you build your own image, just add the patch file, for example:
cat << EOF > target/linux/mediatek/patches-6.6/001-net-ethernet-mtk_eth_soc-fix-dma-for-devices-with-more-than-4gb-of-dram.patch
> From 005603010bf67b37c5757a1e8f61165dc7684152 Mon Sep 17 00:00:00 2001
From: Elad Yifee <eladwf@gmail.com>
Date: Mon, 29 Apr 2024 16:41:11 +0300
Subject: [PATCH] net: ethernet: mtk_eth_soc: Fix DMA for devices with more
than 4GB of dram
Add GFP_DMA32 flag to pages allocations in order to support devices with more
than 4GB of dram
Signed-off-by: Elad Yifee <eladwf@gmail.com>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 0000000000..94c629a554
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1890,7 +1890,7 @@ static void *mtk_page_pool_get_buff(struct page_pool *pp, gfp_t gfp_mask)
{
struct page *page;
- page = page_pool_alloc_pages(pp, gfp_mask | __GFP_NOWARN);
+ page = page_pool_alloc_pages(pp, gfp_mask | __GFP_NOWARN | GFP_DMA32);
if (!page)
return NULL;
EOF
and then build
@daniel I will make test tomorrow or Monday morning.
FWIW, mine idles (snapshot as of today, WAN and one LAN connected to GigE) at 4.5-5w using a USB PD meter.
Have not seen the FAN come on yet, CPU temp seems to be 52C (in the official case but without front/back/top.
Have not had a chance yet to see if my current 10gbit optics from FS work to connect to my ISP.
I installed collectd modules but seems it cannot detect CPU temperature, how did you read it?
Luci stats. But it takes a few minutes to show anything.
There's a /sys entry as well but I don't have the path on my phone just now.
Luci stats based on collectd modules output, my stats are not showing anything, not sure why.
As mentioned, it took some time after activation to show anything (I think that happens on other hardware too). Initially thermal tab was likewise empty...
I have it turned on for more than 3 days, I believe it's long enough?
For sure, probably took 5, maybe 10 min for me...
As I mentioned above, there's no reading at all.
I know some people might not believe this, so I am here to post the idling power consumption here (with 2 Giga ports UP), I only purchased a heatsink without fan for it, but I intentionally having my add-on heatsink to get in touch with the metal surface of NIC connectors to have more chance to dissipate heat.
You can reduce it if you change the CPU governor to "ondemand".
Guys, has anyone tested the patch Daniel just posted? Please let me know if it helps
I always have problem building my own image (not sure why), so I wanted to use the uboot arg to limit memory usage to 2GB first (it's ok for me at the moment), not sure how to implement that change in OpenWrt
A watt or two difference isn't much considering people didn't specify what's actually running in their systems. But I think this is probably the source of deviation. I suggest use Banana Pi's official image if people want to crowd source a consensus of idle power consumption of R4..
My current optics do not seem to feel like coming out of the RB5009 it resides in. Does anyone have pointer for what to look for? Would FS generic work?
More precisely, I need 10G BIDI LR, 10 km, TX1270/RX1330 nm, LC-Simplex, Singlemode
Before that patch when HW offload enabled without 2GB RAM workaround:
- it got troubles to establish connection in the Internet (on LAN)
- page was loading very long and on the end it got timeout (on LAN)
- the wireless connection is working normally
After applying that patch:
- as earlier, wireless connection works normally
- for LAN, it got same issues (trouble to establish connection; web pages got timeout on load)
so in tl;dr patch works partially - only for wireless. Something is missing in LAN connection. I will do more test late evening.
EDIT REASON: I perform tests on old build
Hey, can you please provide more details on your setup? Which wireless card, ports being used, etc...
@eladwf hey, I updated the previous post (it seems that wireless network works normally with and without your patch). Did I apply it correctly?
I create dedicated branch with your patch + apply change for kernel 6.6.30 - https://github.com/openwrt/openwrt/compare/main...danpawlik:openwrt:hw-offload
Right now I create a build from scratch (remove old openwrt dir then clone, feed update, make menuconfig...) and let see if it would be better.
About wireless card: I'm using mt7921e
.
Thanks, can you add this patch as well?
From 8203d3606663e1b4688c3267d01a2a3d3659d54f Mon Sep 17 00:00:00 2001
From: Elad Yifee <eladwf@gmail.com>
Date: Sun, 5 May 2024 14:36:40 +0300
Subject: [PATCH] Add PPE source port comparison
Signed-off-by: Elad Yifee <eladwf@gmail.com>
---
drivers/net/ethernet/mediatek/mtk_ppe.c | 3 ++-
drivers/net/ethernet/mediatek/mtk_ppe_regs.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_ppe.c b/drivers/net/ethernet/mediatek/mtk_ppe.c
index 0acee405a749..1598a58a032d 100644
--- a/drivers/net/ethernet/mediatek/mtk_ppe.c
+++ b/drivers/net/ethernet/mediatek/mtk_ppe.c
@@ -1052,7 +1052,8 @@ void mtk_ppe_start(struct mtk_ppe *ppe)
val = MTK_PPE_GLO_CFG_EN |
MTK_PPE_GLO_CFG_IP4_L4_CS_DROP |
MTK_PPE_GLO_CFG_IP4_CS_DROP |
- MTK_PPE_GLO_CFG_FLOW_DROP_UPDATE;
+ MTK_PPE_GLO_CFG_FLOW_DROP_UPDATE |
+ MTK_PPE_GLO_CFG_SP_CMP_EN;
ppe_w32(ppe, MTK_PPE_GLO_CFG, val);
ppe_w32(ppe, MTK_PPE_DEFAULT_CPU_PORT, 0);
diff --git a/drivers/net/ethernet/mediatek/mtk_ppe_regs.h b/drivers/net/ethernet/mediatek/mtk_ppe_regs.h
index 3ce088eef0ef..7f59966d70d2 100644
--- a/drivers/net/ethernet/mediatek/mtk_ppe_regs.h
+++ b/drivers/net/ethernet/mediatek/mtk_ppe_regs.h
@@ -17,6 +17,7 @@
#define MTK_PPE_GLO_CFG_FLOW_DROP_UPDATE BIT(9)
#define MTK_PPE_GLO_CFG_UDP_LITE_EN BIT(10)
#define MTK_PPE_GLO_CFG_UDP_LEN_DROP BIT(11)
+#define MTK_PPE_GLO_CFG_SP_CMP_EN BIT(25)
#define MTK_PPE_GLO_CFG_MCAST_ENTRIES GNEMASK(13, 12)
#define MTK_PPE_GLO_CFG_BUSY BIT(31)
--
2.44.0
should fix your problem. let me know if it does