FreeBSD 14.1-RELEASE-p2 panics with amdgpu when SDDM starts #311
Comments
|
So, what I noticed is that if I booted back into the older There was also some weirdness around the boot environment (I use ZFS) where at one point I had to boot into the There's something about the |
|
I will try and attach the full |
|
|
I've been bitten by this as well, on an AMD-based machine that is my primary computer. I ran 14.0 happily on this machine and it was dead reliable. Since installing 14.1, I am seeing a full system crash or two per week. This is a show-stopper for me -- too disruptive. I am re-installing NixOS as we speak. |
|
I have started getting kernel panics even with the "known good" ZFS boot environment for I have fiddled with my Without the I also used to have These steps were taken by looking at the stack trace from the panic, and also reading this comment in another bug report that suggested it might be the linux compatibility layer https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278212#c7 |
|
Another crash after resuming from suspend, no linux compat loaded, was able to post a full crash text file to gist. https://gist.github.com/sc68cal/0d71c26141300a8807b27f92005003fe |
|
I've also been encountering similar issues after upgrading to 14.1. I have 5 machines all with the A12-9800E APU. The graphics driver throws a fit 100% of the time after sddm hands off to KDE5 (x11) when autologin is enabled. If I don't have it do autologin, then it loads into KDE fine. Also since updating to 14.1 the display will no longer "wake back up" after the screen turns off from being idle. As is, i've had to disable autologin and display sleep. Would very much like to see this fixed. |
|
Per recommendation found on below page I uninstalled drm-515-kmod that get installed by the recommended drm-kmod metaport and instead installed drm-61-kmod from the ports tree (not yet available in pkg). This resolved both my issues. https://forums.freebsd.org/threads/amd-gpu-driver-has-a-serious-bug-introduced-in-14-1.94338/ For my particular issue, I would consider this issue closed once drm-61-kmod gets added to the pkg repository. Ideally drm-kmod would also point to 61 instead of 515 as well. |
|
Getting a similar issues too myself. |
|
But the drm-61 packaged is NOT available by pkg or via source - the src fails as I've mentioned in my post. |
|
Ports is not enough to build |
|
On Fri, 20 Sept 2024 at 09:45, Claus Andersen ***@***.***> wrote:
Ports is not enough to build /usr/ports/graphics/drm-61-kmod you need to
have /usr/src as well.
Yes, that's true, as I discovered. So I installed the sources, did a 'make
install' of drm-61-kmod, which now completed without error, rebooted my
system and ran into the problem I reported -- no graphic devices found.
After the multiple problems I encountered with FreeBSD, I am now running
Arch Linux on the system without any issues.
… —
Reply to this email directly, view it on GitHub
<#311 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABGOGJYWFOURTUJTDQE5O3LZXQRGFAVCNFSM6AAAAABLPP6VQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRTG43TMNJUGY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Sorry! Did not mean to imply! That remark was aimed at @knaggsy2000 who in his PR seems to be missing Did NixOS cause issues as well or are you just distro hopping to Arch? As for @sc68cal original problem there has been kernel changes as he sussed out.
Current 14.1p2 kernel version is 1401000. So with the p2 kernel or later I would go with drm-61. Or at least test it. For @FloppyKing (see above) it has been a success as reported on the forum as well. |
|
@ClausAndersen Yes, src is installed - always install it as sometimes I need to make a custom kernel, not BUT in this case: - See you have also mentioned something on my OG post. Let me look at that... |
|
@sc68cal Tell us more about that panics. |
|
@FloppyKing That was the article that I found too. Originally, wasn't able to compile from ports. Turns out my src folder was quite out-of-date and wiping it and cloning from new, allowed me to compile drm-61. |
|
drm-61 IS able to built from src, please look at my issue for info #317 |
|
On Fri, 20 Sept 2024 at 10:32, Claus Andersen ***@***.***> wrote:
Sorry! Did not mean to imply! That remark was aimed at @knaggsy2000
<https://github.com/knaggsy2000> who in his PR seems to be missing
/usr/src/.
No offense taken.
Did NixOS cause issues as well or are you just distro hopping to Arch?
NixOS works as advertised. No particular problems. But it does impose
performance and complexity penalties that became tiresome. Arch has been my
Linux distribution of choice for years, I had a Clonezilla backup of it
for the machine in question, so after the FreeBSD problems surfaced, I just
restored the tried and true Arch and updated it.
… As for @sc68cal <https://github.com/sc68cal> original problem there has
been kernel changes as he sussed out.
ports/graphics/drm-61-kmod/Makefile
IGNORE= not supported on older than 14-STABLE 1400508, no kernel support
Current 14.1p2 kernel version is 1401000.
So with the p2 kernel or later I would go with drm-61. Or at least test
it. For @FloppyKing <https://github.com/FloppyKing> (see above) it has
been a success as reported on the forum
<https://forums.freebsd.org/threads/amd-gpu-driver-has-a-serious-bug-introduced-in-14-1.94338/#post-671127>
as well.
—
Reply to this email directly, view it on GitHub
<#311 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABGOGJ3TV4E4YBCHLPKKVALZXQWWBAVCNFSM6AAAAABLPP6VQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRTHA3TMMZWHE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Why is this happening? If others in the future finds the issue it might be interesting with some background for the uninitiated. It takes a lot of resources to write a driver from scratch. And some informationen needed to do it might not be publicly available. That is why FreeBSD is actually using Linux drivers with some patches. FreeBSD is a full operating system (kernel+userland) and does not share code with the Linux kernel nor the typical GNU userland utilities found in many Linux Distributions (Linux kernel+distribution specific userland). FreeBSD does however have a high degree or Linux compatibility and is able to run nativer Linux binaries. The graphics drivers (in this case amdgpu) comes (mainly) from the Linux world and they depend on a Linux kernel feature called DRM (Direct Rendering Manager). DRM evolves with the Linux Kernel. In FreeBSD this is handled with the DRM kernel module. Notice the major and minor version numbers on this module: 5.10, 5.15 and now 6.10. This corresponds to the the versions of the Linux Kernel it tries to match. With the transition from 5 to 6 we are now moving a full major version forward. I do not know the finer details but "something" happened around the 14.1-RELEASE-p2 kernel. Most likely what has been considered a bugfix in the Linux compatibility layer. You would not see new features introduced in a p1 -> p2 point update. This has then unfortunately triggered some side issues with the amdgpu driver. Exactly what and who is to blame I will not speculate on. Ít is typical for users to upgrade their packages at the same time as the system. So they might get a newer amdgpu driver. Or the issue has been latent with the driver for a longer time. This then only becomes visible with the bugfixed kernel. It might be an issue which was fixed in the Linux world but relies on newer DRM features. There is many small devils hidden here. Would this not be rather trivial if we had the drm-61 as a binary package ready to go? Yes! But. ports/graphics/drm-61-kmod/Makefile All the 14 pre-built pacakages must work on all kernels - even 1400000. That is why you cannot find a pre-built package and need to build it yourself. This is fairly easy if you understand how to build ports. This then tricks some as this port is a little special. It needs some of the Linux compatibility headers from the FreeBSD kernel. Regular users do normally not need them of have them installed. So that is an extra still simple but unusual step. And remember that when you have built your own version you have a binary version which you can use on other hosts. So bugs do happen. And fixes are available. In my mind this could have been handled much more smoothly if the project had made a binary package available from an official location for download. I understand why it was not simply added to the package repository because of backwards compatibility. But a direct download would have been nice for regular users. It might also be worth reading the DRM Kmod Primer. |
|
This is a very useful explanation.
My difficulty would not have been solved by a 61 package. As I've said
previously, I got drm-61-kmod built and installed as a port and it did not
work on my system, as I've described elsewhere, I provided a dmesg that
shows that my hardware is vanilla, the
gpu on the processor chip. And 515 crashes the system periodically (a few
times a week with constant use).
I have also experienced consistent failures to properly reawaken a mounted
USB drive after use of zzz, resulting in the need to fsck the drive.
I also experienced a softdep-related issue with my root file-system as a
result of a 515 crash. This required a bit of work to get the system back
on its feet, at which point I backed up the files I'd been working on,
which were intact, and restored Arch Linux.
I must say I'm more than a bit surprised to encounter softdep problems at
this point in its history. The same for the USB issue. The USB driver was a
huge problem for FreeBSD many years ago and I believe it was re-written.
I've had no problems with it
using FreeBSD in recent years until now.
I realize that FreeBSD doesn't have the resources or the user community
that Linux has. But I used both 13-series versions of FreeBSD as well as
14.0 without significant issues. So hopefully my experience is not an
indication that the complexity
of providing FreeBSD for the desktop is beyond the capacity of the project
and what I've encountered is not indicative of a systemic problem.
…On Sat, 21 Sept 2024 at 04:34, Claus Andersen ***@***.***> wrote:
Why is this happening? If others in the future finds the issue it might be
interesting with some background for the uninitiated.
It takes a lot of resources to write a driver from scratch. And some
informationen needed to do it might not be publicly available. That is why
FreeBSD is actually using Linux drivers with some patches. FreeBSD is a
full operating system (kernel+userland) and does not share code with the
Linux kernel nor the typical GNU userland utilities found in many Linux
Distributions (Linux kernel+distribution specific userland). FreeBSD does
however have a high degree or Linux compatibility and is able to run
nativer Linux binaries.
The graphics drivers (in this case amdgpu) comes (mainly) from the Linux
world and they depend on a Linux kernel feature called DRM (Direct
Rendering Manager <https://en.wikipedia.org/wiki/Direct_Rendering_Manager>).
DRM evolves with the Linux Kernel.
In FreeBSD this is handled with the DRM kernel module. Notice the major
and minor version numbers on this module: 5.10, 5.15 and now 6.10. This
corresponds to the the versions of the Linux Kernel it tries to match. With
the transition from 5 to 6 we are now moving a full major version forward.
I do not know the finer details but "something" happened around the
14.1-RELEASE-p2 kernel. Most likely what has been considered a bugfix in
the Linux compatibility layer. You would not see new features introduced in
a p1 -> p2 point update. This has then unfortunately triggered some side
issues with the amdgpu driver. Exactly what and who is to blame I will not
speculate on. Ít is typical for users to upgrade their packages at the same
time as the system. So they might get a newer amdgpu driver. Or the issue
has been latent with the driver for a longer time. This then only becomes
visible with the bugfixed kernel. It might be an issue which was fixed in
the Linux world but relies on newer DRM features. There is many small
devils hidden here.
Would this not be rather trivial if we had the drm-61 as a binary package
ready to go? Yes! But.
ports/graphics/drm-61-kmod/Makefile
IGNORE= not supported on older than 14-STABLE 1400508, no kernel support
All the 14 pre-built pacakages must work on all kernels - even 1400000.
That is why you cannot find a pre-built package and need to build it
yourself. This is fairly easy if you understand how to build ports. This
then tricks some as this port is a little special. It needs some of the
Linux compatibility headers from the FreeBSD kernel. Regular users do
normally not need them of have them installed. So that is an extra still
simple but unusual step. And remember that when you have built your own
version you have a binary version which you can use on other hosts.
So bugs do happen. And fixes are available. In my mind this could have
been handled much more smoothly if the project had made a binary package
available from an official location for download. I understand why it was
not simply added to the package repository because of backwards
compatibility. But a direct download would have been nice for regular users.
It might also be worth reading the DRM Kmod Primer
<https://freebsddesktop.github.io/2018/12/08/drm-kmod-primer.html>.
—
Reply to this email directly, view it on GitHub
<#311 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABGOGJ42IHGL3X43YIMCASLZXUVQRAVCNFSM6AAAAABLPP6VQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRVGA3DCMJSGM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
@ClausAndersen I will state that he (Claus) gives very verbose and detailed replies to people. I like that - and should be valued for that fact. Thank you, Claus - please keep it up. @donaldcallen I've used ZFS ever since it was available in FreeBSD for all my drives, and glad that I did. Have you considered to use ZFS? Just wondering. Don't get me wrong, I've used UFS for a long time. |
|
On Sun, 22 Sept 2024 at 18:24, knaggsy2000 ***@***.***> wrote:
@ClausAndersen <https://github.com/ClausAndersen> I will state that he
(Claus) gives very verbose and detailed replies to people. I like that -
and should be valued for that fact. Thank you, Claus - please keep it up.
@donaldcallen <https://github.com/donaldcallen> I've used ZFS ever since
it was available in FreeBSD for all my drives, and glad that I did. Have
you considered to use ZFS? Just wondering. Don't get me wrong, I've used
UFS for a long time.
If my softdep problem was the only issue, I'd consider using ZFS instead of
UFS. But the graphics driver bug is a show-stopper for me and Arch Linux
has replace FreeBSD on my system.
I should also note that I used ZFS in the past, including on the backup
drive that I"ve just reported
not remaining mount after awakening from system suspension. I had issues
with that, too, about which I filed a bug report almost exactly two years
ago. Its status is still 'new'.
I have had an on-again off-again relationship with
FreeBSD for about 20 years, mostly off-again. I run it for awhile, I prefer
it to Linux, and then I run into show-stopping bugs. It has happened every
time I've tried to use the system over a very long period of time. I hope
I'm wrong, but I fear
that the project just does not have the critical mass to do something as
complex as providing a reliable desktop operating system on PC hardware.
… —
Reply to this email directly, view it on GitHub
<#311 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABGOGJ343SFGKBBEVZWSDBLZX47RDAVCNFSM6AAAAABLPP6VQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRWHE4TCMRXG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Hi! Right now I'm using 14.1-RELEASE-p5, hw specs Ryzen 7 3800X and RX 580, and I have hard crashes with drm-515-kmod (drm-510-kmod is good), I share my crash file for add more info to this issue: |
|
@yukiteruamano Have you seen my reported issue? #317 |
No, but I can test build a drm-610-kmod using poudriere I have this infra for my own packages and for future collaboration with ports packages |
|
@donaldcallen I remember those USB issues several years ago, sometimes even unplugging a USB device could cause a kernel panic. But no longer see that anymore, for a long time now. I am a Linux user too, and Arch seemed very appealing to me - but currently settled on Debian for that. My personal preference of OS will ALWAYS be FreeBSD though, for many reasons - outside the scope of this issue. But I don't understand why you don't use ZFS (did I miss something?) - I know it has additional hardware requirements, especially more RAM. Been using FreeBSD since v5 to v14.1 continuously for my main PC. Seen lots happen during that time. It's funny how an OS that has originated many years before Linux, appears to get less support: - 1979 - wow, the earliest mention. I'm sure v5 was released around 2003 (please correct me if I'm wrong), so a little more time for me. The only reason I got into FreeBSD is because at that time, my current laptop couldn't install ANY distro of Linux (remember them being on MULTIPLE CDs?). But when I installed FreeBSD v5, everything worked - so I stuck with it ever since. Feel like I've gone off-subject a little, I'm sorry. |
Please try drm-610-kmod, ensure your src folder and ports folder are completely up-to-date - see my post for details on that. |
|
@yukiteruamano As you have a RX 580, which is similar to my card mentioned in my post. Please update on MY post and not here. |
|
The issue with @yukiteruamano has been resolved - see my post for that info. |
|
@sc68cal Any updates? As lots has happened. |
Describe the bug
My desktop FreeBSD machine was working great with KDE-5 plasma and
amdgpukmod until I usedfreebsd-updateto update toFreeBSD 14.1-RELEASE-p2During multiuser boot, SDDM starts and then the kernel panics.
FreeBSD version
FreeBSD 14.1-RELEASE-p2 (bad)
FreeBSD thor 14.1-RELEASE FreeBSD 14.1-RELEASE releng/14.1-n267679-10e31f0946d8 GENERIC amd64 1401000 1401000(good)PCI Info
output
DRM KMOD version
To Reproduce
Steps to reproduce the behavior:
Start SDDM
Additional context
I have a kernel panic log that I can link
kernel panic log
The text was updated successfully, but these errors were encountered: