I’m also pretty sure battery charge isn’t the problem. This FW13 is normally run while trickle-charged from the FW power adapter. However yesterday, by accident, it was on battery down to 2% of full charge before the AC adapter was switched on, and it ran faultlessly the whole time. Earlier today it ran fine down to 19% of full charge.
I’ll reinstall ‘tlp’ when I have time (and after updating the BIOS so as not to complicate matters) since I think all it needs is an edited entry in the config file in /etc.
My own FW13 has an Intel-5 CPU which may be less likely to induce the problem than Ryzen, but it’s still frozen 4 or 5 times since June 30th, twice within 24 hours.
I’m preparing to update the BIOS to 3.05 together with the updated shell, and we’ll see if that fixes the problem…
I should add I’ve only used Windows on my Framework 13 laptop.
I have used both the built-in touchpad and a Bluetooth mouse.
I rarely bother with sleep and hibernate, I just boot up, use it, and shutdown.
Note that unless you’ve specifically disabled “Fast Startup”, the “Shutdown” button in Windows is actually “Log out then hibernate”. (Rebooting is still legit.)
TLP is kind of famous for randomly killing devices (both onboard and external), it’s a significant part of the power savings it provides. So you should either be prepared to debug issues of this sort or use something less aggressive (e.g. power-profiles-daemon as recommended in the Framework docs, preferably a recent version).
That is so right… Searching the OpenSuSE Forum for tlp-related problems revealed something which hadn’t occurred to me.
Some laptops have a BIOS parameter which disables USB devices when running on battery. This of course includes USB-C ports used for supplying AC power via the AC adapter. Gotcha - Catch 22!!
I think I’ll adopt a view similar to that of a contributor to the OpenSuSE forum. Having uninstalled ‘tlp’ I might keep it that way. If I want the laptop to save battery power I’ll close the lid to suspend it. There’s no point in complicating life unnecessarily.
The power-profiles-demon is running, and I’ll have a closer look at its config.
I suppose I must have disabled fast startup. Plus I usually do whatever it takes to make absolutely sure hibernate cannot occur no matter what. Once you have a fast NVME SSD all that stuff and hybrid boot doesn’t really help and only causes problems. People who try and use it are always moaning they found their laptop boiling hot or with the battery dead in their rucksack on many if not all Windows laptops not just Framework.
This Intel i5 FW13 still freezes occasionally, probably around once a week. They’re definitely not associated with heavy CPU activity or battery charge; the initial OpenSuSE installation from a USB memory stick followed by a huge backlog of online updates ran perfectly. Freezes are not associated with a specific user or account either.
At this point, I suspect they may occur when the wired mouse is being moved. (The mouse, together with a printer and scanner which are normally off, are connected to a Verbatim USB-A hub which draws its power from the USB-A adapter.)
However yesterday evening there were two freezes. I accidently clicked the trackpad during the first which seemed to get things going again. So I repeated that during the second and, sure enough, the same thing happened. Both “mice” are enabled and the console mouse manager (gpm) is disabled.
I’d like to disable the trackpad entirely, but can’t see anywhere in the UEFI “BIOS” where that’s possible. Would someone please help? I assume the trackpad driver is in the UEFI firmware, not the O/S.
Hey there!
I couldn’t read through the entire thread, but the issue you’re having looks similar to the one that is plaguing Lenovo Yoga laptops with AMD Ryzen 6000 mobile CPUs. On my unit (Ryzen 6800U/Radeon 680M) I get a BSOD after the screen freezes for what minutes (usually 5 to 10 minutes). And the error is usually a DPC_WATCHDOG_VIOLATION somehow related to the amdi2c.sys driver.
We had similar threads in the Lenovo community forum (here and here) but no one of us found a solution to this. Lenovo tech support also couldn’t debug it as they say it’s not reproducible on their units (and is also randomly happening). Long story short, after almost 2 years of use our laptops are still bugged and randomly freezing.
I look forward to see if you guys can find any hint about this. Hopefully it’s just some buggy BIOS setting that can be tuned with Smokeless’ UMAF.
I know that the laptop is different from yours, but I am available in performing any test that comes up in this thread.
Cheers
These freezes are beginning to look consistent across platforms.
My FW13 has an Intel i5 Core and runs OpenSuSE, but FW user’s reports on this website suggest freezes are far more frequent on Ryzen systems. At a sheer guess, I’d say they only occur on my laptop around once a week on average.
Until recently I’d assumed the system was always permanently frozen. However a few days ago there was a ~5-15 minutes delay before I began attending to the usual ritual of forcing a power-down and rebooting, but by then it had apparently unfrozen and was running normally.
Very ccasionally the system seems to have episodes where simple actions like responding to a mouse click are randomly delayed by seconds.
Maybe clicking the trackpad brings it all back to life, as I wondered above? I’d like to disable the trackpad completely as I don’t use it (I use a wired mouse / USB hub) and that would simplify things.
I’ll have a look at the journal next time it occurs.
I couldn’t find any watchdog violations in the Linux system journal, however I’m not sure this is the whole story. Maybe freezing pre-empts a journal entry, and the diagnostics are likely to be different anyway.
Double-check your drivers and remove unnecessary peripherals to fix the DPC Watchdog violation error.
The DPC Watchdog error can be caused by outdated or incorrectly installed drivers. Software conflicts are less common culprits.
Solve the DPC Watchdog violation error in Windows 10 and Windows 11 by checking IDE ATA/ATAPI controllers, removing external devices, updating SSD drivers, and scanning system files for errors. If all else fails, try a system restore.
All this is consistent with the idea it’s an adapter problem of some sort, and with the reported facts. In particular (in my case):
the possibility that clicking the unused trackpad may pull it out of the frozen state;
the episode of erratic responses mentioned earlier, since I’d just changed the adapters around (for convenience sake) without rebooting the system and I think it hasn’t occurred since;
Hi I have the 7040 13 inch laptop and are getting hard freezes from time to time what amd graphics do you recommend I download
Is there some amd auto downloader?
do I need to uninstall the previous driver that came with the OS
My FW13 i5 had several freezes on Saturday morning which provided an opportunity to make some systematic observations of the problem, with these results.
As mentioned previously, freezes tend to occur in episodes separated by problem-free periods. On Saturday mid-morning random screen responses became delayed by sub-second to maybe 2-sec “freezes” and the system eventually froze completely after a minute or so, recovered after ~15 minutes, and froze again.
That has all the characteristics of electrical noise, maybe causing spurious interrupts.
The system always does recover as M_R stated. However only the integrated monitor was unresponsive. The time-of-day clock apparently continued to be updated correctly (it showed the correct time when the screen came back to life after 15 mins), the screen darkened and increased brightness when the outboard mouse or the trackpad was moved during this time, and the spreadsheet in use beforehand continued to run normally afterwards. Nudging the mouse during a freeze moved the cursor when the monitor recovered.
The FW13 had an unused HDMI adapter, so the empty HDMI cable socket was electrically floating. Taking a hint from the How-To-Geek article linked above, I removed it and rebooted.
So far, two full days later, no problems. If it runs for a month without problems I’ll declare problem solved.
But the floating adapter connector doesn’t seem like a good idea, either electrically or since it’s exposed to dust on desk surfaces, etc. Is it possible to buy a dummy cover?
Yes, that’s definitely on the list and it has certainly worked for some users. However the highly episodic nature of the problem suggests to me there’s an underlying cause which the updated firmware may handle better.
I had a single freeze last night after 4 1/2 days, so I’ve reinstated the HDMI adapter and will update the BIOS ASAP.
But it would be nice to know why updating the BIOS seems to fix the problem rather than just doing it and hoping for the best! This still doesn’t feel to me like a common-or-garden program bug because it’s too randomly episodic.
The 3.05 update notes four fixes, only one of which (the thermal issue with Linux) could possibly be environmental or hardware related and it’s winter here. However the retimer update might do the trick: it could account for the fact it’s only the integrated display which freezes, and freezes evidently happen much more frequently on faster Ryzen FWs where I guess signal timing is more critical.
Two questions though…
The update notes show two links to the same Linux BIOS 3.05 update but one carries the comment “You must be running 3.05 or later to apply this update using EFI.” which is obviously curcular. What is really meant?
And am I correct in thinking that the Linux BIOS update includes the shell? Or is the shell provided by the O/S like the drivers?
What’s the general stability of the 3.05 bios? I’m still running 3.03b, and the experience of previous bluescreens has made me reluctant to update since the system is stable now.