Created attachment 222765 [details]
photo showing interesting console errors
OS: FreeBSD 13.0-BETA3
Graphics: Intel HD Graphics 5500
Sometimes, graphics won't work after waking up from suspend. It shows:
"drmn0: Failed to idle engines, declaring wedged!"
Note this doesn't cause a panic-reboot.
Other times, it seems to resume just fine, but triggers a panic after a few seconds of use. It either logs me out of my running session, or instantly reboots my system.
These issues don't happen all the time. Actually, I'm not sure how to consistently reproduce them :(
But as far as I can tell, it's been happening since at least 13.0-ALPHA3.
Possibly a duplicate of:
I see a similar issue here, just 100% reproducible (0 successful resumes out of more than 11). 13.0-BETA4. No visible panic, just black screen from startup, but you can tell from the heat of the laptop that its locked up :).
Intel HD Graphics 620 (Dell XPS 13)
- https://wiki.freebsd.org/Laptops/Dell_XPS13_9360 is the exact laptop
- dmesg, acpiconf, sysctl, loader.conf etc https://gist.github.com/dch/463caaaf723eabf84cf678b618b2d206
tried with & without following loader.conf tunables, and including below patch:
# cpu/gpu power tuning
Since 13.0-RC1 came out, this bug has only happened to me once. So at least I can say its occurrence has been greatly reduced.
Does this mean it is not really a drm-kmod bug but a base system issue? Given the drm port hasn't been updated/modified at all in the meantime...
I still get 100% hangs, now on 13.0-RC2.
I've needed to update my tunables, they were from an earlier port version, but that makes no difference to the outcome.
(In reply to Dave Cottlehuber from comment #3)
Mmm that's a shame. But I think yours is rather a different problem actually, different symptoms.
13.0-RC2 and RC3 were nearly flawless and this issue became really hard to see.
Unfortunately, 13.0-RC4 brought a big regression in this regard. It now happens most of the time!
At least, I think I was able to understand a little bit more:
When resuming, if I see this console message: "drmn0: Failed to idle engines, declaring wedged!" then it completely fails to resume X.
Whereas, when the above line doesn't appear and this other line still shows: "i915 raw-wakerefs=3 wakelocks=3 on cleanup" then it looks like all is fine for a few seconds, but after a while, Xorg is killed and restarted all of a sudden and I'm right back at my display manager (SDDM).
Same with 13.0-RC5...
I'd really like to see this issue go away before 13.0-RELEASE, otherwise it will be a real disappointment to have to deal with this bug potentially till 13.1-RELEASE :(
How are things with graphics/drm-fbsd13-kmod 5.4.92.g20210202 on 13.0-RELEASE?
(In reply to Graham Perrin from comment #7)
Hi Graham, fortunately things have been working really great since I updated to 13.0-RELEASE!!
The reason I hadn't reported it yet was because I wanted to test some more to be really sure all was indeed fine.
So far so good!
For me, I see no changes. 100% reliable on 12.2R (since 11.something even, IIRC). And on 13.0R no successful resumes at all.
I'm afraid I spoke too soon :(
On FreeBSD 13.0-RELEASE, resuming from sleep is behaving the way it did around 13.0-RC2/RC3 for me. This is, it works most of the time, but still fails once in a while. Unlike 12.2-RELEASE, where it just works all of the time...
Anyway, I discovered that when I get the dreaded "drmn0: Failed to idle engines, declaring wedged!" message, I can:
kldunload i915kms; kldload i915kms; service sddm restart
to get back X, at the cost of losing all my unsaved open files and stuff. At least this way I avoid having to reboot my system.
(In reply to Patricio Villar from comment #10)
> This is, [resuming from sleep] works most of the time, but still fails once
> in a while. Unlike 12.2-RELEASE, where it just works all of the time...
Could it be that back when you were on 12.2, you also had different version of `graphics/gpu-firmware-kmod' port installed?
My i5-7200U-based (Kaby Lake, HD620) laptop stopped resuming reliably after big DRM-related ports update which I did in January. At first I've suspected `graphics/drm-current-kmod' port causes this (they've recently started to follow Linux 5.4 and I've seen people reported a handful of regressions compared to 4.16), so I've iteratively tried every port revision down to drm-current-kmod-4.16.g20200320 (r548207) which definitely worked before, but the resume was still broken. Then I've downgraded the firmware port to gpu-firmware-kmod-g20200130 (r524664) and resume become reliable again.
It's kind of strange, as commit logs mention only changes related to AMD chips, but you might still wanna try to downgrade the firmware package and see if it makes a difference.
Thanks you, but just downgrading gpu-firmware-kmod didn't make a difference for me (I kept drm-kmod 5.4.92.g20210202).
As I said, on 13.0-RELEASE it's definitely harder to trigger this panic compared to other 13.0-* builds, but it still happens from time to time. It's not 100% reliable unlike previous major release.
Oh I forgot to add that I usually do around 5-6 suspend/resume cycles for it to happen BTW