I dont think it’s necessarily the same issue. DPC WATCHDOG VIOLATION is a generic error message which means basically some hardware stopped responding part-way through an operation. I would expect these errors are very common with new hardware. I guess we’ll find out (if/when?) the next 7040 series bios update comes out.
2 Likes
Haven’t reached out to support yet, but I have also been experiencing DPC WATCHDOG VIOLATION bluescreens at least every other week. Getting PTSD from sorting out “driver issues” in AMD graphics cards from 2019-2022 (0/3 on them being driver issues, all had reproducible failures, I don’t want to talk about how long I put up with it, all fixed by RMAs).
I ran some basic stability testing using Karhu RAMtest for a couple hours when I first got the machine but I’ll try more extensive testing on my Crucial 5600 2x16 kit (CT2K16G56C46S5). I’ve also had to RMA a Crucial kit before due to one bad stick; I have really, really bad luck when it comes to hardware problems lol.
1 Like
I wonder if this is actually the same issue…
The difference in Framework response there versus here is super frustrating. Like I get that DPC Watchdog Violation can be a thousand different things, like the post from nrp implies. But there in a thread of 26 posts about Linux freezes, they’ve had 5 Framework posts from two different employees acknowledging there’s an issue, providing useful troubleshooting steps (if Framework needs more information on this Windows issue, then hey, maybe tell us what would help you?), and they’ve seemingly identified the problem.
Here in a thread of 180 posts of users having issues, there’s been a single response and it’s vague and generic about going through basic troubleshooting steps like checking the RAM, then drivers, then a mainboard replacement. The difference is stark.
8 Likes
@jhoff80 I couldn’t agree more. I tried to reach out to Linus Sebastian (LTT, Framework investor) to try and get him to bring these issues exposure with the view to get answers and appealed to @nrp to acknowledge a very obvious common fault. Neither wanted to help, so I’m just going to start emailing various tech news sites in the hope there’s a bite.
We are being treated like s**t here, and being paying customers, we don’t deserve it. The lack of transparency is appalling and as more and more people state their frustrations, they’re choosing the hard way in getting us the information we deserve; 1. Acknowledge there is a problem, 2. Be truthful with us, even if the news is “we don’t know what’s causing this, but we’re working on it” and 3. “We’re doing X Y and Z, to diagnose the cause and provide a fix for our loyal customers”
There’s nothing more brand-damaging than a bunch of disgruntled and frustrated customers. We deserve more than contempt, and like I’ve stated before, consumers need all the info before making a purchasing decision.
1 Like
We have a hypothesis that one of the causes of DPC_Watchdog_Violation on Framework Laptop 13 (AMD Ryzen 7040 Series) could be this same firmware issue. We are testing this out as part of the development process for the next 7040 Series BIOS update and will include the change if we find that it works. However, we believe that other general issues like a bad memory module for example could also trigger the same blue screen type.
Response from @nrp in this thread regarding FW 16
3 Likes
Same here. Updated the driver four days ago after @jhoff80 mentioned it was available, and just had another freeze and DPC_WATCHDOG bluescreen…
Just to update, as quoted above, this is something we’re directly investigating as part of our current development process on a Framework Laptop 13 (AMD Ryzen 7040 Series) BIOS update.
We found a firmware issue towards the end of Framework Laptop 16 development that resulted in similar symptoms. We have a hypothesis that one of the causes of DPC_Watchdog_Violation on Framework Laptop 13 (AMD Ryzen 7040 Series) could be this same firmware issue. We are testing this out as part of the development process for the in-development 7040 Series BIOS update and will include the change if we find that it works.
20 Likes
Wonder if that explains the mouse stuttering and seeming propensity to BSOD under light loads. It kind of makes sense, the only heavy load I can imagine where one would use the touchpad would be something like compiling software, so you walk away and wait for gcc to finish… no BSOD. For gaming, I assume there is a mouse attached and touchpad is off (or not receiving input for the duration of gameplay)… so, no BSOD. Then you are browsing Firefox (input heavy), boom, BSOD… fingers crossed
Thank you for the update, I’m glad that the possible issue/fix is in the process of being pinned down. Do you happen to have a timeframe on this update that we can be looking out for?
1 Like
Thank you
Just chiming in to say that I’m also suffering from this with my fw13 amd7840u model, including the occasional touchpad hiccups.
What seems to have worked for me was going into Safe Mode, using DDU to remove any old Intel/NVIDIA graphics drivers (not sure if this step is necessary but did so anyhow), using AMD’s Cleanup Utility to remove the Framework AMD drivers, then rebooting the computer normally and installing the latest Radeon drivers straight from AMD.
Ofc it hasn’t been long enough to say if this truly fixed the issue regarding the DPC_WATCHDOG_VIOLATION BSODs or not, but I can say that I was getting crashes about 1-2 times a day, and ever since I did the above, I have had the computer running for 3 days now with no crashes. I am however still having minor issues with touchpad responsiveness so hoping Framework’s investigation sorts that out.
I’ll update you guys if I do end up having another crash, though fingers crossed I do not lol.
EDIT: This doesn’t work.
Checking in my current status since it’s been a bit. I have received a stick of RAM via RMA, but still experienced the same BSOD running just that stick.
I’m also on AMD 7640U FW13 and been experiencing the same DPC_WATCHDOG_VIOLATION BSODs. Since reading this thread and hearing about the trackpad firmware thing I have limited my use of it, using an external mouse and switching the trackpad off from Windows settings and haven’t had an issue so far.
I’ve also cleaned up my drivers as @apprchngvnthrzn mentioned, just to be sure. And, as I said, no crashes yet. But I’ve also been having them way less frequently than I’ve seen other users, so I don’t know yet that it is actually helping (they would usually happen once or twice a week, sometimes at bigger intervals).
Will keep updated if it crashes again.
Hey @Alex_Salinero, welcome!
Unfortunately I can say that driver cleanup and updating to the latest AMD drivers didn’t get rid of the crashes for me completely, it only seemed to reduce the amount of crashes, though it varies, considering I’ve already crashed twice day within 4 hours.
While it’s not easily reproducible, all of my BSODs have happened when scrolling in any Chromium-based browser or Electron-based app like Discord. Every single one. It seems to happen more often if I was just doing something GPU-intensive, like playing a game, right before doing so. It does seem to me that it is indeed somewhat related to the touchpad, maybe even the same bug the FW16 had.
I imagine that maybe turning off hardware acceleration in these applications would further reduce the amount of BSODs I’m getting, but I haven’t tried it out yet. Alternative, I could do as you did and strictly limit trackpad use, using an external mouse instead.
1 Like
I posted earlier about how updating the Realtek drivers and switching to Firefox fixed the crashing for me. It reduced the frequency from daily to every week or two. It always seems to happen when I am using the touch pad.
I have noticed that the touch pad has a delay sometimes, almost like it has to wake up even though I just used it. It doesn’t always do it though. I also find it odd that sometimes the touch pad will stutter and then lock up. In this state, sometimes it will recover and start working normally, but usually it is followed by the DPC_WATCHDOG_VIOLATION. In the event that it does return to working normally, it only works for a minute or two and then the BSOD happens.
I will try using only an external USB mouse and see if I get anymore BSOD’s.
2 Likes
Although OpenSuse isn’t crashing for me, when I use dmesg to display the chatter from the kernel ring buffer there are a very large number of “i2c_hid_acpi i2c-FRMW0005:00:i2c_hid_get_input: incomplete report (7/65535)” warnings.
I’m no expert, but as far as I can tell this means the i2c bus was expecting a message of length 7, and got a message of length 65535.
Sometimes that touchpad just won’t shut up?
I’m going to try disconnecting the touchpad internally and using an external mouse instead.
I am also experiencing the same on a 7840u unit, 2x16Gb Crucial 5600 RAM (CT16G56C46S5.M8G1) & SK Hynix P31 Gold 2TB, swapped AX210. I am here for the ride, really want FW to succeed but I’ve had the same BSODs in similar circumstances per this thread, garbled audio at times and a lovely bug whereby the trackpad doesn’t work at all once the laptop wakes and only a reboot fixes.
Am not piling in for the sake of it, really didn’t expect this to be bulletproof out of the box with new platform and modular approach - but also really want to be able to rely on this machine. I have NOT contacted support, have several machines I can use & jump on them thus far due to time constraints.
Truth is right now if I need to jump on a call or present etc am firing up my old Thinkpad.
If there’s anything needs tested or more info I can provide which might help I am here for that.
Has anyone unplugged the touchpad and tested it to see if the issue is present.
1 Like