For those following along it’s a regression in libxmlb 0.3.17 (specifically) Downgrading to 0.3.16 if it’s available will fix it, and 0.3.18 will be released this week with the fix.
7 Likes
I was having the same issue on Debian testing.
Applying this patch mentioned in the discussion that you linked on top of libxmlb 0.3.17 does fix the issue and I could update the BIOS to 3.05 !
1 Like
I upgraded from 3.03b. I haven’t tried rolling back yet, as others suggested, nor tried the full bios defaults reset. Pretty busy atm, I’m on the last two weeks of the college semester. I’ll check back when I can get to it.
I removed the sg_display=0 parameter and switched to iGPU “auto” mode, and was not able to replicate the GPU reset issues I was having before in a couple places where I could consistently trigger it. I also tried an older kernel with an older initrd and couldn’t trigger it there either. However, it was already an intermittent issue, so I’ll have to keep testing things. If I don’t see it after multiple attempts to replicate, I might have to update my bug report in Debian.
Also tried running with sg on and igpu auto, finished multiple runs of the built in cyberpunk benchmark without any of the artifacting I had previously and no issues running a long ai only game of stellaris (I just had the computer play itself as a stress test XD).
So far so good, I’ll leave it like that and will update if issues show up.
I’m very glad to report that the BIOS update fixes the white display artifacts issues for me !
I had a pretty reliable way of triggering it on Debian testing with Plasma which was :
- boot
- login with a first user
- switch to a second user session
And now with 3.05 I cannot reproduce the issue anymore after several tries.
Yay ! \o/
(that’s all without sg_display=0)
1 Like
Given the actual feedback around BIOS 3.05 will there be an official release soon or there are still issues that may need to be investigated for this BIOS release ?
2 Likes
Wondering the same.
@Kieran_Levin Anything to note about this AMD Chipset Driver?
It isn’t a version available for download from AMD. The modification date of the AMD_Chipset_Drivers.exe from inside the AMD_Chipset_Software_5.06.29.310.exe has a modification date of 2023-06-29.
It is quite an old and outdated chipset driver compared to what is available from AMD. The latest release from AMD is 6.02.07.2300 with a release date of 2024-03-13 and a modification date of 2024-02-08. So 8 months newer and 2 official releases since the driver included in this bundle.
3 Likes
Do those drivers need to be adjusted for framework or why wouldn’t they pull the latest? I’m a bit confused now…
Another issue I encountered with this firmware is that /sys/class/thermal/thermal_zone3/temp occasionally shows a value of 180 °C.
It is a unified driver for multiple platforms across multiple generations.
So it would be possible* that there are no changes that are relevant to the FW platform after that version.
*: possible. Probable though? Given FW not updating other drivers that do affect existing platforms much and based on the way other OEMs do it: more likely they were tracking a specific bug, and the version they are shipping now is the one that has that fixed. But ignoring other benefits of newer drivers as that would not fix issues that the manufacturers was “tracking” but would require more testing.
1 Like
I’ve been messing around with the NPU support on Linux (per GitHub - amd/xdna-driver) and had a bear of a time trying to get things working on the 3.03 BIOS - kept running into an apparent memory allocation error (in dmesg) that prevented the NPU from being properly detected/initialized by the system. On a hunch I tried updating to 3.05, and now it works! I’m guessing something changed in the IOMMU apparatus that doesn’t appear in the summary on the first post here…
4 Likes
Could you write into support and provide us a minidump?
We would like to try and gather more data about this issue.
1 Like
For those affected by the wakes from suspend when attached to power, we still have this in the Fedora docs.
sudo sh -c '[ ! -f /etc/udev/rules.d/20-suspend-fixes.rules ] && echo "ACTION==\"add\", SUBSYSTEM==\"serio\", DRIVERS==\"atkbd\", ATTR{power/wakeup}=\"disabled\"" > /etc/udev/rules.d/20-suspend-fixes.rules'
This checks for an existing /etc/udev/rules.d/20-suspend-fixes.rules file, if none is found, creates it and appends ACTION==“add”, SUBSYSTEM==“serio”, DRIVERS==“atkbd”, ATTR{power/wakeup}=“disabled” to the file.
2 Likes
This hasn’t happened since that time, and I unfortunately had memory dumps disabled at the time. I since have turned them back on in Windows and will definitely submit a support ticket if I see it again.
I don’t know where to ask or whether I should contact support. I recently discovered some minor problem with the PD charging. This problem appears to persist before and after the BIOS/embedded controller update.
- When booting up(not restart), the PD charging input will momentarily off right upon pressing the power button before resuming to 20V(or whatever your power brick is doing). Only the FW13 AMD has this problem (IDK whether Intel versions have it too as I don’t have one).
- If the computer is switched off(not suspended) for half a day or longer, it won’t charge immediately when plugged in USBC PD, the LED is white and the current flow is 0A. You’ll have to wait for several minute before the current goes to positive and LED turns red.
Other users also discovered the problem, as shown here
1 Like
Mine does that too, but a lot of laptops renegotiate PD when powering up so it’s not that weird.
Yeah I have the same issue, it repeats that message every 2 seconds. Removing & reinserting the front right expansion card stops it until the next reboot. Setting ‘echo "on" > /sys/bus/pci/devices/0000\:c1\:00.3/power/control’ also works.
I’m running BIOS 3.05, kernel 6.8.5, with a USB A expansion card in the front right slot.
1 Like
Reporting from Kubuntu 24.04 (6.8.0-22-generic). I had these issues still with kernel 6.8 before the update (different from @Michael_Marley - not sure why, but I’m using KDE Plasma + Wayland + two external 4k displays).
So far everything looks good with sg_display=0 removed here too. I’ve done all the usual things that would trigger it and haven’t been able to replicate except for having it up and running for several days and adding/removing the monitors multiple times during that. (But I have added/removed monitors, slept/woken in different monitor states, etc.) I’ll report back if that changes, but we seem to be having joy here. 
FOLLOW-UP
After a weekend of running around with my laptop, all still seems to be good here, so this update may well have solved the sg_display issue!