I’m talking about this.
All I know is, when I turn on a GPU intensive app, the AMD drivers switches the screen to the dGPU, so the iGPU stays idle and all APU TDP goes to the CPU.
Given Quin_Chou message on the highlights, I’m curious about the (old?) MUX working on the 5070 + 1st gen screen combo.
Hi.
From the reports above, it does not seem very scientific. It is people observing things, but no data to back it up.
We did some pretty good scientific and methodical testing of the GPU stuttering etc. over on this thread:
That testing was made possible because there was source code for the EC firmware.
We could take the FW EC firmware, and modify it a bit, so it could collect the data we needed.
Unfortunately, we cannot do any of that scientific analysis and data gathering on the latest FW EC firmware until FW publish the changes they have made to the FW EC source code.
So, I guess we can only tell FW, “It doesn’t work” or “It has not fixed it”, without any diagnosis as to why.
This seems like an accurate assessment of the situation.
Signed, a data scientist.
I went ahead and updated to test this 4.01. So far, everything is still working. I will do some game tests at a later time.
However, I see it STILL has the throttling bug where it will set PROCHOT_CPU and PROCHOT_GPU statuses active if I disconnect or connect the 180w Framework power supply (changing power modes I guess). Sleep the laptop and wake it back up again and the throttling is cleared……until the next power cable connect or disconnect. Utterly frustrating they will not fix this issue.
Can anyone else confirm this issue on yours as well? You can use amdgpu_top set to watch the iGPU/CPU to see the throttling status.
So, I just tested this. Being idle, I went from ~3.5mhz to ~1.5hmz after unplugging and once re-plugged it went to the 544mhz for a brief second then back to about ~3.5mhz. Again, not sure if my testing matters without a dGPU, but it rectified itself.
Power setting is on performance when plugged in and balanced when on battery.
Thanks for testing, but I’m not talking about frequencies at all. As far as I can tell, it’s not actually throttling when the PROCHOT_CPU and PROCHOT_GPU are active in these ways. The bug is just that they are “showing” as active so any software that reports on the status, be it amdgpu_top, or mangohud, etc… all think the cpu and gpu are perpetually throttling.
Yes, I could just ignore it, but it’s wrong, an error, and seeing “throttling” constantly listed even when it is not throttling makes the feature completely useless.
Would @Quin_Chou please comment on this and let us know why it does this?
Question: Has anyone tried updating the keyboard firmware before (without) updating the bios? I want to try that first and hold off on bios until enough people have reported it’s good.
@jared_kidd Do not update the keyboard without updating the BIOS.
The purpose of the keyboard update is to adapt to the new EC firmware behavior.
Please update both of them together, or neither of them.
Really appreciate for your feedback. We are trying to check the behavior you saw but we would like to have more information about this.
Could you please specify when you disconnect or connect the 180W adapter? Was the system idle at the time, or was it running a workload (i.e., under load)?
Based on the information provided, it sounds like only saw the PROCHOT status trigger, but the processor did not actually enter a throttling state, correct?
What’s your fwupd version? I think it may be too old.
You can check with fwupdmgr --version
What command did you run to mount it? It says “wrong fs type”.
The filesystem is implemented by the mask ROM of the RP2040 chip and it’s FAT16.
Yes the system is idle at the time. Usually just a web browser is open. CPU is not being heavily used, sitting around normal temps of 50-54 Celsius, dGPU is not in use at the time either.
Correct. It does not appear to be throttling or effecting performance in this case.
And to be clear, this is not unique to this bios version. This has been an issue for a long time I think.
@FlyingTypeTrainer do you remember what expansion cards and devices you had attached when you ran the BIOS update the first time? That may help us debug why one of the PDs wasn’t updated the first time.
I had the same issue as FlyingTypeTrainer
port 1 - usb-c - connected FW power supply 180W
port 2 - usb-c - no device connected
port 3 - usb-a - no device connected
port 4 - usb-c - external monitor ASUS MB16AC
port 5 - usb-c - no device connected
port 6 - dongle hider (without any dongle inside), no other device attached
there was some UI glitch. I saw 2 cogs
and then success screen, nut only 1 tick icon next to PD controllers
the I have recording which indicate that PD1 was updated from 0.0.1E to 0.0.21
and PD2 from 0.0.21 to 0.0.21 which indicate that PD1 was not updated
PD 2 update was almost immediate.
there was some change in EC related to PD port numbering. maybe it is causing confusion
Thanks, that’s useful information. We’ll investigate.
What BIOS were you running previously?
I was running 3.07. It should be visible on one of the screen shots
I had this same problem; ended up using the manual method and that worked.
I also encountered another odd problem after the firmware update… immediately after it was extremely sluggish, to the point where it took several minutes just to boot the latest Arch Linux iso. Once it finally booted, even the screen scrolling was extremely sluggish. I first tried doing the “Load Optimized Defaults” in the bios, which didn’t fix it. My next hunch was to pull the battery out to completely reset the board but then I remembered about the battery disconnect functionality; I went in the bios and turned that on, which shut the computer off, then waited a few minutes and plugged it in, and miraculously that time it booted quickly and the slowness was completely gone.
Other than those two issues, I haven’t had any other problems, though it’s been ~10 minutes since I finished that so we’ll see.
The configuration was as follows:
Port 1: USB-C connected to a 140W Baseus Charger
Port 2: USB-A with a wireless mouse receiver
Port 3: Micro-SD with a 1TB Micro-SD card
Port 4: USB-C with nothing connected
Port 5: USB-A with nothing connected
Port 6: USB-A with nothing connected
It is worth noting that I have since discovered that port 1 is being very finicky with connected chargers. It is consistently working with that 140W Baseus charger it was connected to. I am having intermittent success with a 100W Baseus charger, a second but identical 140W Baseus charger, and the 240W Delta charger. Port 4 is having no problems at all with any of these chargers. Changing cables has not had an effect.
Is there a way to force PD firmware to update on port 1?
@M_G1
What problem do you have.
If the PD firmware fails to update, you can try plugging in the power on the other side of the laptop, and then trying the firmware update again.
Also, unplug all other USB devices while updating.
As far as I know, you just try to apply the update again and it should update the rest.
Good luck. When one of mine didn’t update I started having an intermittently dead port.
