We endeavor to improve battery performance wherever possible.
As it’s suspending to RAM, I expect there is to be some loss there. This sounds about right based on your setup.
We endeavor to improve battery performance wherever possible.
As it’s suspending to RAM, I expect there is to be some loss there. This sounds about right based on your setup.
I installed Fedora 39 beta (On the AMD 13"), and after the initial install, it rand a software update and got various updates as one would expect. Great. But since then, nothing.
Checking for updates on command line and in the Software app, I get nothing. It’s been almost a week, and no updates at all. I assume something is gummed up, but I don’t know how to resolve it.
I’ve updated to the 3.03 bios, and this has made my new machine much more viable. I suspect that one of the many many hard crashes I had on the 3.02 bios caused this issue.
I’m willing to wipe the drive and reinstall Fedora, but if there’s a way to fix the problem I’d prefer that.
I upgraded to kernel-6.5.9-300 tonight and it’s causing amdgpu to throw a lot of errors. FW 13 AMD
[ 1482.824984] amdgpu 0000:c1:00.0: amdgpu: [mmhub] page fault (src_id:0 ring:40 vmid:1 pasid:32773, for process RDD Process pid 3952 thread firefox:cs0 pid 4352)
[ 1482.824986] amdgpu 0000:c1:00.0: amdgpu: in page starting at address 0x0000000000000000 from client 18
[ 1482.824988] amdgpu 0000:c1:00.0: amdgpu: MMVM_L2_PROTECTION_FAULT_STATUS:0x00000000
[ 1482.824990] amdgpu 0000:c1:00.0: amdgpu: Faulty UTCL2 client ID: VMC (0x0)
[ 1482.824992] amdgpu 0000:c1:00.0: amdgpu: MORE_FAULTS: 0x0
[ 1482.824993] amdgpu 0000:c1:00.0: amdgpu: WALKER_ERROR: 0x0
[ 1482.824995] amdgpu 0000:c1:00.0: amdgpu: PERMISSION_FAULTS: 0x0
[ 1482.824996] amdgpu 0000:c1:00.0: amdgpu: MAPPING_ERROR: 0x0
[ 1482.824998] amdgpu 0000:c1:00.0: amdgpu: RW: 0x0
I will rollback the update for now.
jim@fedora:~$ sudo dnf history info 19
Transaction ID : 19
Begin time : Thu 26 Oct 2023 09:56:52 PM EDT
Begin rpmdb : 17a6f5f667197f6e80f3ddc64e6ed3fbdbb3a23b58192a2113e35824b0cf5354
End time : Thu 26 Oct 2023 09:57:31 PM EDT (39 seconds)
End rpmdb : 4402b76213a8d7a7d3a9adab73478d4811b86b6f31aedd0e55f4be813cbef8a9
User : Jim <jim>
Return-Code : Success
Releasever : 39
Command Line : update -y
Comment :
Packages Altered:
Install kernel-6.5.9-300.fc39.x86_64 @updates-testing
Install kernel-core-6.5.9-300.fc39.x86_64 @updates-testing
Install kernel-modules-6.5.9-300.fc39.x86_64 @updates-testing
Install kernel-modules-core-6.5.9-300.fc39.x86_64 @updates-testing
Install kernel-modules-extra-6.5.9-300.fc39.x86_64 @updates-testing
Upgrade freerdp-libs-2:2.11.2-3.fc39.x86_64 @updates-testing
Upgraded freerdp-libs-2:2.11.2-1.fc39.x86_64 @@System
Upgrade ibus-1.5.29~rc1-6.fc39.x86_64 @updates-testing
Upgraded ibus-1.5.29~rc1-5.fc39.x86_64 @@System
Upgrade ibus-gtk3-1.5.29~rc1-6.fc39.x86_64 @updates-testing
Upgraded ibus-gtk3-1.5.29~rc1-5.fc39.x86_64 @@System
Upgrade ibus-gtk4-1.5.29~rc1-6.fc39.x86_64 @updates-testing
Upgraded ibus-gtk4-1.5.29~rc1-5.fc39.x86_64 @@System
Upgrade ibus-libs-1.5.29~rc1-6.fc39.x86_64 @updates-testing
Upgraded ibus-libs-1.5.29~rc1-5.fc39.x86_64 @@System
Upgrade ibus-setup-1.5.29~rc1-6.fc39.noarch @updates-testing
Upgraded ibus-setup-1.5.29~rc1-5.fc39.noarch @@System
Upgrade libwinpr-2:2.11.2-3.fc39.x86_64 @updates-testing
Upgraded libwinpr-2:2.11.2-1.fc39.x86_64 @@System
Upgrade xorg-x11-server-Xorg-1.20.14-26.fc39.x86_64 @updates-testing
Upgraded xorg-x11-server-Xorg-1.20.14-24.fc39.x86_64 @@System
Upgrade xorg-x11-server-Xwayland-23.2.1-2.fc39.x86_64 @updates-testing
Upgraded xorg-x11-server-Xwayland-23.2.1-1.fc39.x86_64 @@System
Upgrade xorg-x11-server-common-1.20.14-26.fc39.x86_64 @updates-testing
Upgraded xorg-x11-server-common-1.20.14-24.fc39.x86_64 @@System
Fedora 39 is in the final freeze before release, this means only critical fixes will be published, no routine feature update. This is normal, and will change after release.
There was a freeze recently as they prepare for an official launch.
If the log noise is followed by actual issues, please see this thread.
hey guys, so i’m still having issues with firefox and video playback. i’ve done all the suggestions in this thread and have gotten videos to work, however the videos stutter every 10 seconds or so. like they freeze for a few seconds then catch back up while the audio keeps playing – making videos essentially unwatchable on firefox.
does anyone use firefox and have this issue? i’ve moved over to using brave which has no issues, but i’d really prefer to be using firefox but the video playback is killing me.
i’m on the latest update of fedora 39, 3.03 bios, and i’ve tried the flatpak and rpm version of firefox and they both have the same issue.
If you’re talking about HTML5 video playback, please do this here:
Fedora Linux 39 was released today!
@Matt_Hartley Could you update the first comment on this thread?
Ha! You totally beat me to it! Yep, doing so now.
Just a FYI if you are running Fedora and want VAAPI profiles exposed then you need to enable rpmfusion and run the steps listed here:
https://rpmfusion.org/Howto/Multimedia
To expose the various capabilities via vaapi for encode/decode - fedora strips patent encumbered bits from mesa by default. IME people forget to run the dnf swap bits after adding rpmfusion .
You can check what is exposed by installing libva-utils and running vainfo
I’m having an with Youtube videos in Firefox on Fedora 39, 6.5.11 Kernel (happened on previous kernels as well), 3.03 BIOS. Audio plays smooth, but video temporarily freezes or stutters for a bit then catches back up and plays smoothly for a bit. This happens at random, inconsistent intervals. Sometimes is merely and annoyance, sometimes it’s to the point of making the video completely unwatchable. It doesn’t seem resolution dependent. This will sometimes happen at 720p resolution and sometimes even 4K60 videos will play smooth. But that’s not the main oddity to this issue. Videos play fine with wired headphones and when using the inbuilt speakers. But if I use bluetooth earbuds, this video freezing and stuttering issue occurs. I can disconnect my bluetooth earbuds and the video will start playing smooth. Re-connect my bluetooth earbuds and the video will start getting choppy again.
This issue is unchanged whether I have the system in Power Saver, Balanced, or Performance modes. Also, I have the GPU set to “game mode” in the BIOS. I haven’t seen any graphical glitches or issues some people have had, just this video stuttering issue with videos while using bluetooth earbuds. This happens on battery and when plugged into a charger.
@BigT ; yup I noticed this also with the fc39 kernel; also happens in ublue/silverblue as well as workstation and in Plasma or Gnome; i’ve moved to using rawhide over the weekend and will be watching over the next couple of days for it.
So on rawhide I don’t get the stuttering; but I do get a lot of these familar messages (I see these on my rdna3 5950x quite often with various combinations of kernel/mesa/firefox/chrome)
MediaPD~oder #3[29662]: segfault at 60 ip 00007ff578b4901f sp 00007ff59f9fcd40 error 4 in libLLVM-17.so[7ff576949000+384c000] likely on CPU 9 (core 4, socket 0)
It’s something to do with the Mediapipeline decoder bits and it’s interaction with the rest of the system. I’ve never been able to root cause it (I thought it was my 5950x being PBO2 clocked/RAM/Mobo - but it’s definately software related rather than hardware after bisecting a heap of those things previously on my workstation.
resolved using xxmitsu/mesa-git ; I haven’t had any stuttering on the rawhide kernel 6.7.0-0.rc0.20231109git6bc986ab839c.12.fc40.x86_64
Note this is not the nodebug one
Clarifying for others reading this, this kernel on Rawhide has led to success in addressing the issue?
No:
ucsi_acpi and i2c_hid_acpi i2c-FRMW0005:00
Spam is still occurring with mainline 6.7
Also the ec_cros patches that were added sometime back to mainline for the Intel FW do not work for the AMD EC controller and there needs patches/documentaiton for the ec controller to be made available and added to a patchset. There is nothing in any of the various kernel trees i’ve diff’d that deal with the EC controller for the AMD. This includes the various ec_tool efi and userspace libs throwing invalid checksums when querying the AMD ec.
Can someone running the OEM Kernel that people mention for ubuntu let me know if ec_cros_lpc loads ; and if so where the source tree is so I can see what if any patches were made for the amd ec controller in that kernel.
Believe it’s here somewhere.
lsmod
lsmod | grep cros_ec_lpcs
cros_ec_lpcs 16384 0
cros_ec 20480 1 cros_ec_lpcs
dmesg
sudo dmesg | grep cros_ec_lpcs
[ 1.041101] cros_ec_lpcs cros_ec_lpcs.0: EC ID not detected
Modinfo
filename: /lib/modules/6.1.0-1025-oem/kernel/drivers/platform/chrome/cros_ec_lpcs.ko
description: ChromeOS EC LPC driver
license: GPL
srcversion: 907D9237F5875F0305F0B2C
alias: dmi*:svn*Framework*:pn*Laptop*:
alias: dmi*:svn*GOOGLE*:pn*Glimmer*:
alias: dmi*:svn*Acer*:pn*Peppy*:
alias: dmi*:svn*GOOGLE*:pn*Samus*:
alias: dmi*:svn*GOOGLE*:pn*Link*:
alias: dmi*:bvn*coreboot*:svn*GOOGLE*:
alias: dmi*:bvn*coreboot*:bvr*Google_*:
alias: acpi*:GOOG0004:*
depends: cros_ec
retpoline: Y
intree: Y
name: cros_ec_lpcs
vermagic: 6.1.0-1025-oem SMP preempt mod_unload modversions
sig_id: PKCS#7
signer: Build time autogenerated kernel key
sig_key: 3B:2B:98:A0:E5:73:1E:49:D6:FF:BA:80:A0:EE:55:23:4D:E6:D7:C7
sig_hashalgo: sha512
signature: 1B:F5:3B:BF:53:C7:17:6B:23:7A:A6:CA:89:99:E9:6A:76:EE:BA:82:
BD:6E:94:B3:7C:60:39:41:88:FF:46:54:24:16:35:0C:B4:73:EF:5B:
74:88:94:9B:97:FA:26:03:8C:EF:30:74:F0:94:E5:4C:75:4D:1B:BC:
12:EF:39:A0:C7:6D:E8:97:64:4E:37:3B:9C:BD:FE:5F:ED:E4:7C:FC:
9F:C6:53:EE:96:7B:7C:33:66:CE:2F:AC:D9:4E:C6:82:8B:48:C8:43:
CD:36:BC:AA:4B:4D:7B:A1:8C:B2:5A:4F:FD:5C:8D:B3:76:41:3C:13:
1F:34:A7:E1:EE:27:22:CE:BB:37:37:AD:3C:B1:09:B9:78:F4:EF:E5:
71:C3:C4:DE:EA:D2:E7:CD:CD:B9:C2:4B:75:A4:5F:24:FA:12:34:21:
4A:AA:30:7F:21:23:AA:D7:EB:7E:A0:F9:04:8C:E4:F8:F7:DB:0D:E9:
C8:2C:5E:AF:D6:E3:75:38:C3:E5:FB:86:61:F5:AF:87:D6:93:E5:EF:
0A:88:10:FC:A1:37:14:38:06:4B:0A:73:8D:53:C5:0D:10:44:C4:E6:
03:57:A8:4F:7B:C5:8C:5C:A2:02:07:5C:40:E7:5E:B0:48:17:0C:A0:
92:E2:55:BA:23:71:66:77:40:C5:3B:D0:FF:F8:D9:38:B2:34:AC:12:
B5:45:30:F1:31:B5:40:8D:74:20:4C:0F:EA:AA:81:33:35:08:83:10:
FE:28:B1:57:09:EF:98:93:3A:0A:D3:DE:60:F6:66:2D:8A:8B:9B:7F:
66:54:16:B1:00:1F:DB:16:0C:C1:D3:FD:1C:54:FF:ED:61:85:93:26:
C0:7E:AD:68:42:42:33:90:C3:7A:AA:95:07:30:1A:D3:A7:7C:72:0C:
E8:8F:3D:C9:87:B5:BF:ED:3C:22:EF:20:8C:C2:73:15:99:9F:4F:12:
41:E7:56:AD:86:66:4E:0E:BE:C4:E8:95:33:D6:97:7F:2E:83:B3:1D:
E1:0E:D2:E1:62:63:24:C0:B0:3E:34:AA:FF:F8:BC:5E:92:E6:16:5D:
04:EC:65:8A:71:92:4E:F5:0C:71:00:19:7B:0B:36:7D:9A:D6:71:6A:
48:7B:CF:E3:BE:3B:66:D2:2F:D9:EC:6B:05:C2:B6:5E:3D:73:6A:4F:
FE:52:C7:1D:26:7E:6E:D9:F1:A7:79:46:3C:60:21:A2:88:31:84:EB:
17:38:7E:42:04:AE:6A:DC:4E:E7:D3:24:62:F4:1C:4D:B8:70:4A:E8:
F7:4C:0A:B5:17:E2:04:52:29:8D:73:B9:A0:0A:A5:CF:4D:8C:A8:9F:
3C:3D:5D:33:C8:72:A0:C1:8D:94:8F:35
Yup it’s not loading there; so isn’t in that kernel either
I’ve got a 6.7-rc1 with patch applied you should see:
[ 8.837614] cros_ec_lpcs cros_ec_lpcs.0: loaded with quirks 00000003
[ 8.846694] cros_ec_lpcs cros_ec_lpcs.0: Chrome EC device registered
And you should then get errors from the PD.auto probe (which needs a fixup which doesn’t currently exist). Am not sure what needs to happen in the auto probe ; there seems to be some discussion/patches which may be related to how auto probing happens. But this likely needs flagging up the poll to people more familar than I. Perhaps @DHowett ? I see a thread for the Intel Framework which mentions similar output - so this may just be overly verbose output that shouldn’t appear in dmesg.
[ 8.984471] cros-usbpd-charger cros-usbpd-charger.3.auto: No USB PD charging ports found
[ 8.985733] cros-usbpd-charger cros-usbpd-charger.3.auto: Unexpected number of charge port count
[ 8.985737] cros-usbpd-charger cros-usbpd-charger.3.auto: Failing probe (err:0xffffffb9)
[ 8.985739] cros-usbpd-charger: probe of cros-usbpd-charger.3.auto failed with error -71