Yeah as far as I can tell the framework ec_sros_lpc patches that went in sometime around the 6.2 series don’t support the newer ec in the amd framework.
They are certainly not in any of the mainline trees if they exist at all. Have asked if ec_cros_lpc loads with the magic OEM kernel people mention for the ubuntu distro. But I haven’t found anything in any of the trees i’ve looked through.
There is a ec_tool efi loadable i’ve tried and it also doesn’t support the ec on the amd framework; spitting out invalid checksum.
I noticed that I linked the wrong debugging patch (sorry!). I edited the post.
So if anyone has built a kernel with it, please pick it again and rebuild.
The patch that is linked significantly increases the number of iterations mc146818_avoid_UIP will try and logs when it’s over 100. With this patch in place if you have reproduced the issue you’ll see a warning in your logs:
reading the RTC time required %d loop iterations
But hopefully your clock doesn’t jump forward. Please share logs with that patch in place to see how many iterations it required.
Have run up a new build of my patched kernel with this against the fedora 6.7-rc2 os-build tree. And removed the rtc kernel flag - will let you know if I encounter any time skipping.
2023-11-21 17:49:38,716 DEBUG: [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=14
2023-11-21 17:49:38,717 DEBUG: [drm:amdgpu_mes_reg_write_reg_wait [amdgpu]] *ERROR* failed to reg_write_reg_wait
consistently during resume running the amd_s2idle.py script ; is there an open bug in the amd gitlab for this? As it’s still there with latested mainline patches and linux-firmware for Phoenix.
And removed the rtc kernel flag - will let you know if I encounter any time skipping.
There are two sets of patches, one for using ACPI for RTC alarm and one for UIP clear not happening in 10ms. Make sure that you’ve got both in your test kernel if you’re not using the kernel command line parameter.
I am still seeing these:
Functionally harmless right?
consistently during resume running the amd_s2idle.py script ; is there an open bug in the amd gitlab for this? As it’s still there with latested mainline patches and linux-firmware for Phoenix.
Nothing is opened in AMD Gitlab for this. FWIW I believe it’s caused by a firmware included in the BIOS not Linux in this case.
One thing I do need to create a bug report for is being able to dynamically change resolution in Wayland. I.e changing to 1920x1080 from Display settings or xrandr nets a black (but backlit) screen. It works ok in X11 session and if it’s set from the Login Manager or from a TTY but not once a Wayland session is running. Not sure if it’s a plasma/Wayland or DRM/amdgpu bug but it was happening in the fc39 kernel as well as the 6.6 and rawhide 6.7 userspace.
I also noticed the panel reports it does 48hz as well as 60hz ; does this meant it implement the PSR and but I don’t see VRR support in drm_ibfo etc?
Yup -the os-build tree pulled in 6.7-rc2 Monday night my time , and either something in that series, and or your rtc patch OR the epp preferred cores patch set - seems to have fixed whatever it was ; I just tried after rebuild this morning and it’s working now.
Spoke too soon; worked first swap to 1920x1080, thenback to 2256x1504 ok - but back to blanked out behaviour when I went to 1920x1200 and trying to switch now to 1920x1080 fails. This is via kwin_wayland.