I experienced a similar 12 Mi/s (100 Mbps) speed cap when downloading Steam games over the weekend. I was able to bump the speeds slightly to 17 Mi/s (140 Mbps) by switching to the “iwd” backend driver. Both speeds are still short of the 400 Mbps advertised by the local UAC-NanoHD access point which was located roughly 6 feet away from the laptop.
I also use a UDM Pro + Access Points and run a steam deck. If you can reliably reproduce the issue and include a set of simple steps, I’d be happy to test if I see the behavior as well.
For those experiencing Wifi issues with the MT7922 card: Arch Linux posted an update to the “linux-firmware” base package which also includes a “mt7921e” firmware update to version “20240219103244a”. The previous release featured firmware version “20231120183400a” from November 2023.
Just tested with some Netflix’s fast.com test and it still only reached 280-300 mbps tops. Then switched to iwd backend and now saw peaks of 380-400 which is about the average speed of my two ISPs (Starlink + German Telekom) combined via UDM Pro load balancing.
Thanks for the hint
I just ran my own tests on this and did not experience the same results. My set up is Arch, KDE Plasma connecting using the plasma-nm for NetworkManager. I used iperf3 to my UDM Pro.
wpa-supplicant backend:
Connecting to host 172.16.8.1, port 5201
[ 5] local 172.16.8.183 port 45848 connected to 172.16.8.1 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 37.8 MBytes 316 Mbits/sec 0 1.57 MBytes
[ 5] 1.00-2.00 sec 41.1 MBytes 345 Mbits/sec 0 2.18 MBytes
[ 5] 2.00-3.00 sec 36.2 MBytes 304 Mbits/sec 406 1.73 MBytes
[ 5] 3.00-4.00 sec 33.9 MBytes 284 Mbits/sec 0 1.85 MBytes
[ 5] 4.00-5.00 sec 39.0 MBytes 327 Mbits/sec 31 1.43 MBytes
[ 5] 5.00-6.00 sec 40.2 MBytes 338 Mbits/sec 0 1.53 MBytes
[ 5] 6.00-7.00 sec 38.0 MBytes 319 Mbits/sec 0 1.60 MBytes
[ 5] 7.00-8.00 sec 39.1 MBytes 328 Mbits/sec 0 1.66 MBytes
[ 5] 8.00-9.00 sec 39.6 MBytes 332 Mbits/sec 6 1.21 MBytes
[ 5] 9.00-10.00 sec 40.0 MBytes 335 Mbits/sec 0 1.29 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 385 MBytes 323 Mbits/sec 443 sender
[ 5] 0.00-10.06 sec 382 MBytes 318 Mbits/sec receiver
iwd backend:
Connecting to host 172.16.8.1, port 5201
[ 5] local 172.16.8.183 port 51122 connected to 172.16.8.1 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 18.9 MBytes 158 Mbits/sec 0 872 KBytes
[ 5] 1.00-2.00 sec 19.2 MBytes 161 Mbits/sec 0 1.15 MBytes
[ 5] 2.00-3.00 sec 19.1 MBytes 161 Mbits/sec 0 1.21 MBytes
[ 5] 3.00-4.00 sec 19.8 MBytes 166 Mbits/sec 0 1.27 MBytes
[ 5] 4.00-5.00 sec 19.2 MBytes 161 Mbits/sec 0 1.27 MBytes
[ 5] 5.00-6.00 sec 20.6 MBytes 173 Mbits/sec 0 1.27 MBytes
[ 5] 6.00-7.00 sec 19.4 MBytes 163 Mbits/sec 0 1.27 MBytes
[ 5] 7.00-8.00 sec 19.0 MBytes 159 Mbits/sec 0 1.27 MBytes
[ 5] 8.00-9.00 sec 17.4 MBytes 146 Mbits/sec 0 1.27 MBytes
[ 5] 9.00-10.00 sec 17.6 MBytes 148 Mbits/sec 0 1.37 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 190 MBytes 160 Mbits/sec 0 sender
[ 5] 0.00-10.06 sec 188 MBytes 157 Mbits/sec receiver
I was a bit shocked to see results at about half the default wpa-supplicant speed that I did it again (change, reboot, test) with the same results multiple times. Also, with the iwd backend the applet can’t detect the security type and lists is as “Unknown security type”. I think I’m better off sticking with the default wpa-supplicant for now.
Strange.
Just did an iperf3 measurement with iwd to a machine on LAN on battery in balanced power mode:
motzky@framework ~ iperf3 -c 172.16.37.114 -bidir
Connecting to host 172.16.37.114, port 5201
[ 5] local 172.16.191.204 port 50514 connected to 172.16.37.114 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 60.6 MBytes 508 Mbits/sec 0 2.09 MBytes
[ 5] 1.00-2.00 sec 70.6 MBytes 592 Mbits/sec 0 3.01 MBytes
[ 5] 2.00-3.00 sec 58.1 MBytes 488 Mbits/sec 0 3.01 MBytes
[ 5] 3.00-4.00 sec 63.0 MBytes 528 Mbits/sec 0 3.01 MBytes
[ 5] 4.00-5.00 sec 68.0 MBytes 570 Mbits/sec 0 3.01 MBytes
[ 5] 5.00-6.00 sec 78.4 MBytes 657 Mbits/sec 0 3.01 MBytes
[ 5] 6.00-7.00 sec 73.5 MBytes 617 Mbits/sec 0 3.01 MBytes
[ 5] 7.00-8.00 sec 77.4 MBytes 649 Mbits/sec 0 3.01 MBytes
[ 5] 8.00-9.00 sec 71.8 MBytes 601 Mbits/sec 0 3.01 MBytes
[ 5] 9.00-10.00 sec 62.9 MBytes 527 Mbits/sec 164 2.22 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 684 MBytes 574 Mbits/sec 164 sender
[ 5] 0.00-10.07 sec 684 MBytes 569 Mbits/sec receiver
Edit: forgot to mention that I updated linux-firmware yesterday after seeing @Arazil’s post.
Edit2: iperf result connected to UDM Pro running UniFi OS 3.2.12:
Connecting to host 172.16.1.1, port 5201
[ 5] local 172.16.191.204 port 41766 connected to 172.16.1.1 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 70.8 MBytes 593 Mbits/sec 0 2.73 MBytes
[ 5] 1.00-2.00 sec 84.0 MBytes 705 Mbits/sec 44 2.46 MBytes
[ 5] 2.00-3.00 sec 83.4 MBytes 699 Mbits/sec 30 1.85 MBytes
[ 5] 3.00-4.00 sec 81.5 MBytes 683 Mbits/sec 0 1.95 MBytes
[ 5] 4.00-5.00 sec 69.4 MBytes 582 Mbits/sec 0 2.02 MBytes
[ 5] 5.00-6.00 sec 78.6 MBytes 660 Mbits/sec 0 2.08 MBytes
[ 5] 6.00-7.00 sec 83.9 MBytes 704 Mbits/sec 0 2.12 MBytes
[ 5] 7.00-8.00 sec 80.6 MBytes 676 Mbits/sec 0 2.14 MBytes
[ 5] 8.00-9.00 sec 75.9 MBytes 636 Mbits/sec 0 2.15 MBytes
[ 5] 9.00-10.00 sec 83.4 MBytes 699 Mbits/sec 1 1.60 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 792 MBytes 664 Mbits/sec 75 sender
[ 5] 0.00-10.05 sec 790 MBytes 659 Mbits/sec receiver
When I maximize a video stream (youtube, unify protect, etc) the fans ramp up really high. Did I miss something and it’s using cpu for video? Any ideas?
Fans are shared for CPU and GPU. As to whether you’re using GPU acceleration or not depends on the app and and compiled support and even then, depends on which GPU was decided to be used.
Got my Laptop 16 yesterday and installed arch - mostly smooth sailing, but had to get it to boot something with secure boot (I used a fedora installer, just into grub no further) before it would allow me into the secure boot menu. Once I could get into the secure boot menu and disable it installing arch was smooth sailing from there on.
You have to go into the BIOS normally, with the f2 key, in order to disable secure boot. I don’t know why it’s like that. But mine as well would go straight in from a secure boot error and block me from disabling secure boot.
Yesterday, I noticed high battery percentage drops during light desktop use as well as dGPU temp rising to 49C.
Using framework’s own dgpu-power-state-linux (Fedora version seems to work fine on Arch), I saw that my dGPU stays always active and does not suspend anymore and always draws at least 1W:
According to nvtop, there is only iGPU usage.
Tried several things, including Reboot, removing dGPU, downgrading linux and linux-firmware packages to previous version, no dice.
I’m on 6.7.9-arch-1 and came from 6.7.8-arch-1 using Gnome and wayland.
I also tested booting Fedora Workstation 39 (seems on 6.6) and dGPU was suspended.
Any ideas what configuration or program could keep the dGPU active?
Sensor management perhaps? If you have anything trying to read GPU sensors it will keep it awake.
Can you check if your decoder is occupied? There’s often a few flags that need to be set. Make sure you have the mesa HW decoder package, as well as the correct flags in whatever browser you’re on.
Refer here for more info: Hardware video acceleration - ArchWiki
(As well as the page on Firefox if you’re using that).
Thank you. That pointed me in the right direction and I was able to resolve it. I was missing mesa-vdpau, but mainly, “media.ffmpeg.vaapi.enabled” needed to be set to “true” in about:config on firefox.
This is interesting. Can anyone offer any insight on this? igpu is faster than dgpu with glxgears.
[xamindar@framework16 ~]$ glxgears
ATTENTION: default value of option vblank_mode overridden by environment.
124233 frames in 5.0 seconds = 24845.639 FPS
122692 frames in 5.0 seconds = 24538.189 FPS
122730 frames in 5.0 seconds = 24545.896 FPS
X connection to :1 broken (explicit kill or server shutdown).
[xamindar@framework16 ~]$ DRI_PRIME=1 glxgears
ATTENTION: default value of option vblank_mode overridden by environment.
ATTENTION: default value of option vblank_mode overridden by environment.
72677 frames in 5.0 seconds = 14534.833 FPS
70026 frames in 5.0 seconds = 14004.973 FPS
72278 frames in 5.0 seconds = 14455.508 FPS
X connection to :1 broken (explicit kill or server shutdown).
[xamindar@framework16 ~]$
EDIT. Reading around, glxgears (and even glmark2) do not tax graphics enough to overcome the latency on the pci bus to the dgpu. Games still run faster though.
Thank you !
It was a combination of lm-sensors and GNOME shell extension Sensors (freon fork) which I set up to monitor CPU / APU temperatures only, as I expected it keeping dGPU awake, if monitored. But it turns out that the extension queries every sensor (like sensors CLI) and filters which value to show, thus keeping the dGPU awake anyways; rendering it unusable, unless I can find a way to tell lm-sensors to ignore chip “amdgpu-pci-0300” when dGPU is suspended.
I noticed a strange “amdgpu” message (“[drm] Unsupported pwrseq engine id: 2!
”) when loading up my Framework 16 under the Linux Zen kernel so I opened up an issue with that project to get it investigated and fixed.
I have the same messages with similar stacktrace on mine with regular 6.7.9-arch-1 kernel albeit on a different core:
[ 5.004199] amdgpu 0000:03:00.0: amdgpu: RAS: optional ras ta ucode is not available
[ 5.012282] amdgpu 0000:03:00.0: amdgpu: RAP: optional rap ta ucode is not available
[ 5.012289] amdgpu 0000:03:00.0: amdgpu: SECUREDISPLAY: securedisplay ta ucode is not available
[ 5.012323] amdgpu 0000:03:00.0: amdgpu: smu driver if version = 0x00000035, smu fw if version = 0x00000040, smu fw program = 0, smu fw version = 0x00525800 (82.88.0)
[ 5.012328] amdgpu 0000:03:00.0: amdgpu: SMU driver if version not matched
[ 5.055128] amdgpu 0000:03:00.0: amdgpu: SMU is initialized successfully!
[ 5.055449] amdgpu 0000:03:00.0: [drm] Unsupported pwrseq engine id: 2!
[ 5.055467] ------------[ cut here ]------------
[ 5.055469] WARNING: CPU: 12 PID: 395 at drivers/gpu/drm/amd/amdgpu/../display/dc/dcn31/dcn31_panel_cntl.c:172 dcn31_panel_cntl_construct+0x44/0x60 [amdgpu]
[ 5.055858] Modules linked in: cmac algif_hash algif_skcipher af_alg bnep intel_rapl_msr intel_rapl_common snd_sof_amd_acp63 mousedev snd_sof_amd_vangogh snd_sof_amd_rembrandt snd_sof_amd_renoir kvm_amd mt7921e snd_sof_amd_acp mt7921_common amdgpu(+) snd_sof_pci mt792x_lib snd_sof_xtensa_dsp kvm mt76_connac_lib snd_sof snd_hda_codec_realtek mt76 snd_hda_codec_generic snd_sof_utils irqbypass ledtrig_audio snd_soc_core snd_hda_codec_hdmi crct10dif_pclmul snd_compress crc32_pclmul amdxcp mac80211 ac97_bus polyval_clmulni snd_pcm_dmaengine drm_exec snd_hda_intel polyval_generic snd_pci_ps gf128mul snd_intel_dspcfg gpu_sched hid_sensor_als snd_intel_sdw_acpi snd_rpl_pci_acp6x btusb ghash_clmulni_intel drm_buddy hid_sensor_trigger industrialio_triggered_buffer snd_acp_pci i2c_algo_bit sha512_ssse3 btrtl kfifo_buf snd_hda_codec snd_acp_legacy_common drm_suballoc_helper sha256_ssse3 libarc4 btintel hid_sensor_iio_common snd_pci_acp6x drm_ttm_helper sha1_ssse3 btbcm snd_hda_core btmtk industrialio ttm joydev snd_hwdep
[ 5.055923] snd_pci_acp5x aesni_intel cfg80211 bluetooth drm_display_helper snd_pcm snd_rn_pci_acp3x ucsi_acpi crypto_simd snd_acp_config cec typec_ucsi snd_timer snd_soc_acpi hid_multitouch hid_sensor_hub sp5100_tco vfat cros_ec_lpcs cryptd usbhid ecdh_generic hid_generic wmi_bmof fat cros_ec rapl pcspkr typec video snd thunderbolt snd_pci_acp3x k10temp ccp soundcore rfkill i2c_piix4 roles wmi i2c_hid_acpi amd_pmf amd_pmc i2c_hid platform_profile serio mac_hid pkcs8_key_parser sg crypto_user loop fuse dm_mod nfnetlink zram ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 nvme nvme_core xhci_pci crc32c_intel xhci_pci_renesas nvme_auth
[ 5.055999] CPU: 12 PID: 395 Comm: (udev-worker) Not tainted 6.7.9-arch1-1 #1 ad54415bbff2f0801422a3b76df850f68e71ecab
[ 5.056002] Hardware name: Framework Laptop 16 (AMD Ryzen 7040 Series)/FRANMZCP07, BIOS 03.02 01/23/2024
[ 5.056003] RIP: 0010:dcn31_panel_cntl_construct+0x44/0x60 [amdgpu]
[ 5.056175] Code: 08 8b 56 08 89 57 10 8b 56 0c 85 d2 74 23 83 fa 01 74 1e 48 8b 40 10 48 c7 c6 80 df 0f c2 48 8b 00 48 8b 78 08 e8 4c 41 03 f5 <0f> 0b ba 0f 00 00 00 89 53 14 5b e9 17 6f 60 f5 66 2e 0f 1f 84 00
[ 5.056177] RSP: 0018:ffffa50c040e7370 EFLAGS: 00010246
[ 5.056179] RAX: 0000000000000000 RBX: ffff965123765fc0 RCX: 0000000000000027
[ 5.056180] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff96546e9216c0
[ 5.056182] RBP: ffffa50c040e73b0 R08: 0000000000000000 R09: ffffa50c040e7130
[ 5.056183] R10: 0000000000000003 R11: ffffffffb80ca788 R12: ffffa50c040e7404
[ 5.056184] R13: ffffffffc1fab5c0 R14: ffffa50c040e7760 R15: ffff96511e0d4800
[ 5.056185] FS: 00007221d7943540(0000) GS:ffff96546e900000(0000) knlGS:0000000000000000
[ 5.056187] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 5.056187] CR2: 0000583299e5e000 CR3: 0000000104ed6000 CR4: 0000000000f50ef0
[ 5.056189] PKRU: 55555554
[ 5.056190] Call Trace:
[ 5.056198] <TASK>
[ 5.056200] ? dcn31_panel_cntl_construct+0x44/0x60 [amdgpu 164728a6c26992f7aed1675a5d67c737dcdcdbdf]
[ 5.056361] ? __warn+0x81/0x130
[ 5.056378] ? dcn31_panel_cntl_construct+0x44/0x60 [amdgpu 164728a6c26992f7aed1675a5d67c737dcdcdbdf]
[ 5.056534] ? report_bug+0x171/0x1a0
[ 5.056542] ? handle_bug+0x3c/0x80
[ 5.056548] ? exc_invalid_op+0x17/0x70
[ 5.056550] ? asm_exc_invalid_op+0x1a/0x20
[ 5.056557] ? dcn31_panel_cntl_construct+0x44/0x60 [amdgpu 164728a6c26992f7aed1675a5d67c737dcdcdbdf]
[ 5.056729] dcn32_panel_cntl_create+0x37/0x50 [amdgpu 164728a6c26992f7aed1675a5d67c737dcdcdbdf]
[ 5.056915] construct_phy+0x96c/0xd10 [amdgpu 164728a6c26992f7aed1675a5d67c737dcdcdbdf]
[ 5.057143] link_create+0x1b2/0x200 [amdgpu 164728a6c26992f7aed1675a5d67c737dcdcdbdf]
[ 5.057321] create_links+0x135/0x420 [amdgpu 164728a6c26992f7aed1675a5d67c737dcdcdbdf]
[ 5.057492] dc_create+0x321/0x640 [amdgpu 164728a6c26992f7aed1675a5d67c737dcdcdbdf]
[ 5.057657] amdgpu_dm_init.isra.0+0x2a2/0x1ee0 [amdgpu 164728a6c26992f7aed1675a5d67c737dcdcdbdf]
[ 5.057849] ? srso_alias_return_thunk+0x5/0xfbef5
[ 5.057854] ? srso_alias_return_thunk+0x5/0xfbef5
[ 5.057856] ? irq_work_queue+0x2f/0x60
[ 5.057862] ? srso_alias_return_thunk+0x5/0xfbef5
[ 5.057863] ? srso_alias_return_thunk+0x5/0xfbef5
[ 5.057865] ? vprintk_emit+0x175/0x2b0
[ 5.057871] ? srso_alias_return_thunk+0x5/0xfbef5
[ 5.057873] ? srso_alias_return_thunk+0x5/0xfbef5
[ 5.057874] ? dev_printk_emit+0xa5/0xd0
[ 5.057885] dm_hw_init+0x12/0x30 [amdgpu 164728a6c26992f7aed1675a5d67c737dcdcdbdf]
[ 5.058063] amdgpu_device_init+0x1dde/0x2470 [amdgpu 164728a6c26992f7aed1675a5d67c737dcdcdbdf]
[ 5.058206] ? __entry_text_end+0x101f06/0x101f09
[ 5.058208] ? srso_alias_return_thunk+0x5/0xfbef5
[ 5.058211] amdgpu_driver_load_kms+0x19/0x190 [amdgpu 164728a6c26992f7aed1675a5d67c737dcdcdbdf]
[ 5.058349] amdgpu_pci_probe+0x165/0x4c0 [amdgpu 164728a6c26992f7aed1675a5d67c737dcdcdbdf]
[ 5.058486] local_pci_probe+0x42/0xa0
[ 5.058497] pci_device_probe+0xc1/0x260
[ 5.058502] ? sysfs_do_create_link_sd+0x6e/0xe0
[ 5.058511] really_probe+0x19b/0x3e0
[ 5.058518] ? __pfx___driver_attach+0x10/0x10
[ 5.058520] __driver_probe_device+0x78/0x160
[ 5.058522] driver_probe_device+0x1f/0x90
[ 5.058524] __driver_attach+0xd2/0x1c0
[ 5.058526] bus_for_each_dev+0x85/0xd0
[ 5.058531] bus_add_driver+0x116/0x220
[ 5.058535] driver_register+0x59/0x100
[ 5.058537] ? __pfx_amdgpu_init+0x10/0x10 [amdgpu 164728a6c26992f7aed1675a5d67c737dcdcdbdf]
[ 5.058676] do_one_initcall+0x58/0x320
[ 5.058684] do_init_module+0x60/0x240
[ 5.058688] init_module_from_file+0x89/0xe0
[ 5.058694] idempotent_init_module+0x120/0x2b0
[ 5.058697] __x64_sys_finit_module+0x5e/0xb0
[ 5.058699] do_syscall_64+0x61/0xe0
[ 5.058704] ? srso_alias_return_thunk+0x5/0xfbef5
[ 5.058706] ? syscall_exit_to_user_mode+0x22/0x40
[ 5.058710] ? srso_alias_return_thunk+0x5/0xfbef5
[ 5.058711] ? do_syscall_64+0x70/0xe0
[ 5.058712] entry_SYSCALL_64_after_hwframe+0x6e/0x76
[ 5.058719] RIP: 0033:0x7221d7d2488d
[ 5.058810] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 14 0d 00 f7 d8 64 89 01 48
[ 5.058811] RSP: 002b:00007fff05fbd668 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[ 5.058813] RAX: ffffffffffffffda RBX: 00005d668dca1200 RCX: 00007221d7d2488d
[ 5.058815] RDX: 0000000000000004 RSI: 00007221d824c376 RDI: 000000000000004b
[ 5.058816] RBP: 00007221d824c376 R08: 0000000000000001 R09: fffffffffffffe88
[ 5.058816] R10: 0000000000000050 R11: 0000000000000246 R12: 0000000000020000
[ 5.058817] R13: 00005d668dc891e0 R14: 0000000000000000 R15: 00005d668dca2670
[ 5.058821] </TASK>
[ 5.058822] ---[ end trace 0000000000000000 ]---
I updated the framework to 6.8.1-arch-1 and get still get message.
However on my PoC machine (Ryzen 5 3600X + RX 7600 XT), I cannot reproduce with neither kernel version.
Also added the same comment to @Arazil’s gitlab issue.
Has anyone on Plasma 6 had an issue where colors look washed out recently on the internal display? I can’t help but notice the colors seem to be off, kind of like how SDR looks with HDR on in Windows. One thing I’ve noticed is that when I change the refresh rate colors look fine, then seem to imperceptibly shift back towards being washed out.
I don’t know if it’s an issue with Arch, Framework, Plasma, config, or my brain.