If it is a faulty touchpad, then I would’ve thought some QA testing on Framework may have caught that out? Unless they just thought “Eh it works ship it”
I can see why it would’ve been missed, never had trackpads, or mice or keyboards cause bluescreens before. But if it is indeed a hardware issue with the trackpad, that should be covered by warranty (or at least a replacement sent out by Framework as a courtesy). I’d like to see them check to make sure the others are done. Idk. I’ve still remained perplexed at this issue, or why it occurs so randomly. But then I’m not an electrical engineer.
The issue for us checking the RAM at fault, most of us don’t have replacement kits lying around or are willing to just spend money to get one to test with. Usually our tools to test RAM is not faulty are memtest tools, and unless that picks up errors anyway, we’re going to have a hard time proving it is faulty to get it returned at this point.
If it is a trackpad issue, then it kinda vindicates the idea of modularity that it can just be replaced without having to RMA the entire laptop. But that is the only theory we have to go on.
To be fair, it would be hard to QC the trackpad specifically for this issue because of the nature of these BSODs, the most frustrating thing about them is how random and sporadic they are, some weeks I can go the whole week without a crash, and other weeks I’m crashing everyday at least twice a day. Almost like the laptop has a mind of its own.
Also you are right on the money regarding checking the RAM at fault, it’s a lot easier said than done, because if you don’t have spare RAM laying around (and honestly, who does?), then your options are as follows:
RMA the existing RAM, which means your laptop will be a paperweight while you wait for Crucial/Kingston/Framework/etc. to ship out the new RAM, not great for people who only have the one laptop to begin with.
Buy a new set of RAM and try that out, but I see no reason I should go out of my way to spend $150+ dollars on new RAM just to test if my crashes are due to RAM or not, not to mention once again not everyone can just afford to drop that kind of cash.
I too am just going based off of memtest86 results for now and I still have yet to run into any indication in those tests that my RAM is broken or buggy in anyway, hence I’m convinced it is not a RAM issue. Also, due to the fact that memtest86 isn’t reporting any errors even after so many passes, it is unlikely Crucial would be sympathetic and even RMA my RAM to begin with.
Jumping back here after some time to say I’ve had two different Input Keyboards (for a different reason), DPC_WATCHDOG_VIOLATION BSODs with both of them. So, yeah, even a trackpad swap seems to be of no help. I’ve also had an SSD swap, same thing.
Ok, thank you for your input. Just to clarify, it was the entire input cover kit that you replaced? (keyboard, trackpad, fingerprint sensor, metal plate)
I’m pleased this has come, hopefully it resolved the issue we’ve been having, but Framework really need to learn a thing or two about transparency and communication. It wouldn’t have taken 30 seconds for someone to have posted it in the most active thread on the stability issues it addresses.
But also frustrated about comms AND the fact that the BSODs actually seem to be related to the EC firmware, not BIOS. This is within FW’s control and the EC was fixed in development weeks ago (FW16 and then FW13) so I’m not sure why it took so long to get an EC firmware update out.
Didn’t notice any charger compatability issues, except sometimes plugging it into my Samsung charger would cause the light to blink for a few seconds before it connected. Will try the firmware.
EDIT: Should add that my chargers I use now are usually fast chargers at least
And yes, it would’ve been nice for Framework to have someone pop into the thread and say “Hey guys, we’ve released a beta BIOS to try and fix this issue you’ve all had for four months without acknowledgment or communication”
Most of my chargers I use on the laptop are 65w+, I think the flaky charging/USB-C PD experience mainly affected chargers with less than 60w power output but I could be wrong.
this is just my guess, but reading between the lines, I assume that since Framework usually update the BIOS and EC together, they were planning to do so here too, but unfortunately the BIOS update introduced regressions. After they got the timeline for the next BIOS update, they determined it was too long to have people wait for the EC changes, and made their own 3.03b (or had to ask Insyde to make this installer) which took a little more time, but allowed them to split the update in order to get the EC changes out faster, even if it meant not having them be a part of the BIOS update. This is all just a guess though, and I don’t have any insider knowledge on this sort of thing.
Has anyone seen their battery die faster than before the update? It could just be me, since I’m beta testing Arc browser and it isn’t fully optimized, but my battery doesn’t last much longer than 4 hours now.
It’s early days yet, but for me battery life seems the same. Light web browsing and Slack etc has cost me 10% battery in about 90 mins (in the “Best power efficiency” power profile).
i was actually about to say this too, my theory is that framework initially wanted to update the BIOS and EC together, saw that it was going to take a while to update the BIOS due to aforementioned regression, decided to release the EC update first as a stop gap while waiting on a fix for the regressions in the new BIOS