One user had several BSOD even after multiple fresh Windows installs but it’s unknown if that’s due to BIOS 3.02 or a defective board.
This is a single data point so take it with a grain of salt, but I’ve had no issues with Windows 11 so far on a clean install even with a technically-unsupported AX210 NIC.
1 Like
I don’t have a lot of recent experience with PCs as I’ve spent the last decade on Apple devices. I’m sincerely hoping I don’t have a lot of issues that will require technical expertise at a level which I am no longer proficient
You don’t have to do it alone! You’ll be troubleshooting together with Framework’s highly knowledgeable support team
That’s good to know, thank you!
This is an amdgpu linux kernel driver issue that can be sort of mitigated by a simple extra kernel option for the time being.
Look here: this thread
Is there a chance we might be able to get a (tentative) timeline for a release of the 3.03 update? As in, sometime this month still, mid-November, Q1 2024 etc?
I understand this doesn’t affect Windows users much, just Linux users on newer kernels. I also realise there’s a workaround by running an LTS-derived kernel on some distributions, but that’s not ideal for many folks. Even though security updates are normally backported to LTS kernels, many driver improvements and additional hardware support are typically not, not even by vendors, unless it specifically affected a customer with a support contract (which wouldn’t happen on Fedora for example).
The answer is …
But for sure we seem to not have the same understanding of “soon” ahahah.
Expecially when we’re expecting something. Let’s wait a little more. The bios had to be released at the same time than batch 2 but did not make it. It makes me think that they’ve catched some last minute bugs just before the expected release.
Very possible, and I’m entirely fine with it. If it takes another month, it takes another month. That’s not the issue. But it would be nice to get some clarity on that.
1 Like
Thanks, it’s been a couple of days and this seems to have fixed the issue for me!
3 Likes
Sounds promising especially after the long testing period by framework. Thank you all for your work!
1 Like
I believe it’s actually older kernels that are affected. Notably latest stable (6.5.8 as of writing) seems unaffected according to what people have claimed on the forum.
Does that improve performance, or temperature? (i.e. What’s the rational / driver for the PL table modification?)
Maybe reviewers can do some post-BIOS-update performance benchmarking again?
(Remotely related: Asus Ally went through a rollercoaster period with BIOS updates impacting performance)
This is to improve performance if the mainboard is operating without a battery. It should have little/no impact when the system is operating with a battery in a normal laptop configuration.
2 Likes
Thank you for the prompt response. So this is related to the standalone / in-a-case use case. Neat that it has those users covered.
Regarding Kernel 6.5, is there a minimum patch version dependency? (e.g. 6.5.7-300 from the Fedora side of things?)
Good to hear 6.5.8 might be working, but at least up to 6.5.7 it definitely wasn’t 
. Running the BIOS upgrade now, so lets see.
I may also just be wrong!
It’s great seeing timely fixes from framework! Really pleasantly surprised by how fast this got delivered.
Looking forward to getting that 12th gen update for all the vulnerabilities disclosed last year 
Flashed the 3.03 BIOS via the boot+usb method and now my NixOS install is no longer reporting the previous amdgpu issues. Suspend is working. Steam is working. I’m so excited to actually be able to use this thing!
These issues were inconsistent to begin with, so hopefully this isn’t intermittent, but since the errors previously were always present in dmesg, I’m gonna stay hopeful.
I do still see this, but I’m guessing it’s not a huge deal and as long as the machine does what I want it to do, I don’t care overly much, but I’ll put it here for completeness:
[ 48.441047] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=14
[ 48.441281] [drm:amdgpu_mes_reg_write_reg_wait [amdgpu]] *ERROR* failed to reg_write_reg_wait