i915kms kernel module causing freezes on FreeBSD 13.0-RELEASE

[Matt K]

Hello,

After upgrading from FreeBSD 12.2-p6 to FreeBSD 13.0 I started encountering
freezes using the i915kms kernel module and starting X. Here's what I tried
and what I found out:

- Loading the module via rc.conf and kld_list="${kld_list} i915kms" causes
freezes 100% of the time when starting X (tty is fine). Does not matter if
I start X by "startx" command or by some login manager like XDM. It also
does not matter if I use the "modesetting" driver in xorg.conf or if I use
xf86-video-intel "intel" driver in xorg.conf. Freezes happen certainly.
- I tried both the pkg version of drm-fbsd13-kmod and the ports version.
- I tried various combinations of loading the i915kms manually with kldload
and starting X with modesetting, loading it automatically via rc.conf with
"intel" driver, loading it automatically via rc.conf with "modesetting"
driver, using XDM, not using XDM.
- These are the possibilities to have a stable usable system with X:
1. not mentioning i915kms in rc.conf is a must. Then I can load X with XDM
and it automatically pulls i915kms by specifying "Driver" "intel" in
xorg.conf.
2. not mentioning i915kms in rc.conf is a must. Then I have to "kldload
i915kms" and then I can "startx" and it works. In this case It does not
matter if I have "modesetting" or "intel" in xorg.conf, both work.

- Sometimes the freezes are so drastic, that not even pressing the power
button works, I've also had a few freezes, where also the reset button on
the PC case did not work (first time I've seen that happen in my entire
life) and I had to turn off the power supply by a mechanical switch.
- When the freezes happen, these messages appear in /var/log/messages
(during some of the softer freezes, when the computer even has a chance to
write something to logs):

May 2 16:34:15 fbsd kernel: drmn0: GPU HANG: ecode 7:1:0xdfffbe76, in
MainThread [101358], hang on rcs0
May 2 16:34:15 fbsd kernel: drmn0: Resetting chip for hang on rcs0

May 7 19:28:59 fbsd kernel: drmn0: GPU HANG: ecode 7:1:0xccfac4e0, in
MainThread [101334], hang on rcs0
May 7 19:28:59 fbsd kernel: drmn0: Resetting chip for hang on rcs0

Here is my original thread on FreeBSD forums
https://forums.freebsd.org/threads/i915-driver-causing-freezes-on-freebsd-13-0.80016/

What caused me to ask for your generous advice here is the fact that other
FreeBSD users chimed in with similar/identical problems with various other
intel CPUs, their problems, too, started after upgrading to 13.0.

user#1: CPU: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz (3192.68-MHz
K8-class CPU)
user#2: i5-3570K
me: i5-4690

Any advice is appreciated in advance,

MK

[Graham Perrin]

Post by Matt K
1. not mentioning i915kms in rc.conf is a must. Then I can load X with XDM
and it automatically pulls i915kms by specifying "Driver" "intel" in
xorg.conf.
2. not mentioning i915kms in rc.conf is a must. Then I have to "kldload
i915kms" and then I can "startx" and it works. In this case It does not
matter if I have "modesetting" or "intel" in xorg.conf, both work.

Try a third approach:

kld_list="drm"

[Chris Hill]

Post by Graham Perrin

Post by Matt K
1. not mentioning i915kms in rc.conf is a must. Then I can load X with XDM
and it automatically pulls i915kms by specifying "Driver" "intel" in
xorg.conf.
2. not mentioning i915kms in rc.conf is a must. Then I have to "kldload
i915kms" and then I can "startx" and it works. In this case It does not
matter if I have "modesetting" or "intel" in xorg.conf, both work.

kld_list="drm"

I had a similar problem with X appearing to hang. In my case, I had to
specify the full path:

$ grep kms /etc/rc.conf
kld_list="/boot/modules/i915kms.ko"

...in order to load the i915kms from the port graphics/drm-fbsd12.0-kmod
rather than the one from the kernel. Yes, I had to build the port, not
just install the pkg.

Caveat: Matt just upgraded to 13.0; I'm still on 12.2-RELEASE-p4 on
account of sloth. I'm guessing Matt probably needs
graphics/drm-fbsd13-kmod.

[Matt K]

Post by Graham Perrin
kld_list="drm"

This works. I will keep an eye on the system, logs, etc, and let you know
what I find. Now everything seems to be working as advertised. With
xf86-video-intel, even TearFree is working.
Where is this behavior documented? How did you know about this solution?
I think that this means that my problem is solved, but the question
remains: why does i915kms cause freezes when loaded from rc.conf and works
normally when loaded by hand? This is not handbook-documented behavior. Nor
is it consistent or transparent.

Post by Graham Perrin
I had a similar problem with X appearing to hang. In my case, I had to
$ grep kms /etc/rc.conf
kld_list="/boot/modules/i915kms.ko"
...in order to load the i915kms from the port graphics/drm-fbsd12.0-kmod
rather than the one from the kernel. Yes, I had to build the port, not
just install the pkg.
Caveat: Matt just upgraded to 13.0; I'm still on 12.2-RELEASE-p4 on
account of sloth. I'm guessing Matt probably needs
graphics/drm-fbsd13-kmod.

This is no longer the case, Chris. i915kms got removed from base in FreeBSD
13, so only /boot/modules/i915kms.ko from ports remains and that's what
gets loaded with kld_list="i915kms". I tried and checked with kldstat -h -v
-n.
--
MK

Post by Graham Perrin

Post by Graham Perrin

Post by Matt K
1. not mentioning i915kms in rc.conf is a must. Then I can load X with

XDM

Post by Graham Perrin

Post by Matt K
and it automatically pulls i915kms by specifying "Driver" "intel" in
xorg.conf.
2. not mentioning i915kms in rc.conf is a must. Then I have to "kldload
i915kms" and then I can "startx" and it works. In this case It does not
matter if I have "modesetting" or "intel" in xorg.conf, both work.

kld_list="drm"

I had a similar problem with X appearing to hang. In my case, I had to
$ grep kms /etc/rc.conf
kld_list="/boot/modules/i915kms.ko"
...in order to load the i915kms from the port graphics/drm-fbsd12.0-kmod
rather than the one from the kernel. Yes, I had to build the port, not
just install the pkg.
Caveat: Matt just upgraded to 13.0; I'm still on 12.2-RELEASE-p4 on
account of sloth. I'm guessing Matt probably needs
graphics/drm-fbsd13-kmod.
--
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "

[Graham Perrin]

Post by Graham Perrin
kld_list="drm"
This works. I will keep an eye on the system, logs, etc, and let you
know what I find. Now everything seems to be working as advertised.
With xf86-video-intel, even TearFree is working.
Where is this behavior documented?

FreeBSD for Pretty Little Unicorns, 1st Edition.

Post by Graham Perrin
How did you know about this solution?

It came to me in a dream. Whispered by the ghost of Barbara Stanwyck,
once the highest-paid woman in the United States and famed for movies
such as 'Sorry, Wrong Number'. Lesser-known but no less valuable
contributions to postmodern creative thinking include 'Sorry, Wrong
Module'.

Post by Graham Perrin
I think that this means that my problem is solved, but the question
remains: why does i915kms cause freezes when loaded from rc.conf and
works normally when loaded by hand? This is not handbook-documented
behavior. Nor is it consistent or transparent.

Maybe not Intel-specific.

I find kld_list="drm" less troublesome than kld_list="radeonkms" with
Thames [Radeon HD 7550M/7570M/7650M] with SDDM. A recent probe:
<https://bsd-hardware.info/?probe=e90abb54c9#d10>.

My voyage of discovery spanned around three years. Maybe longer. A few
flashbacks:

<https://lists.freebsd.org/pipermail/freebsd-current//2018-September/071327.html>
(2018) I found kld_list="/boot/modules/radeonkms.ko" troublesome with
FreeBSD 12.0-ALPHA7

<https://lists.freebsd.org/pipermail/freebsd-questions/2018-October/283113.html>
(2018) "… toying with the possibility that … a specific load/start order
might help."

<https://github.com/FreeBSDDesktop/kms-drm/issues/101#issuecomment-450776731>
(2019) I found drm-legacy-kmod better than drm-current-kmod with
13.0-CURRENT

<https://lists.freebsd.org/pipermail/freebsd-current/2020-November/077693.html>
(2020) kld_list="/boot/modules/drm.ko" worked for me, keyword:

    peculiar

Eventually I condensed the working peculiarity to kld_list="drm".

More accurately (in context – SDDM, KDE Plasma and so on):
<https://pastebin.com/4XjNFaKk> line 17.

[Matt K]

Interesting,

I read through all that info. Interesting info for me was from Polytropon
about the module loading order. I experimented a bit and loaded i915kms
through /usr/local/etc/rc.d script and it also worked. But this does not
surprise you, I suppose. Thank you for all those links.
Your persistence through the years is certainly inspiring.
Shouldn't your findings be mentioned in the handbook? By at least a few
words, such as: "if you have problems with kld_list=radeonkms/i915kms, try
kld_list=drm". Apparently, there are some people with similar problems, so
maybe solving the problem preemptively by documenting it, is the way to go.
I don't know the protocol here, this is my first time contacting the
FreeBSD mailing list.

Post by Matt K

Post by Graham Perrin
kld_list="drm"

This works. I will keep an eye on the system, logs, etc, and let you know
what I find. Now everything seems to be working as advertised. With
xf86-video-intel, even TearFree is working.
Where is this behavior documented?
FreeBSD for Pretty Little Unicorns, 1st Edition.
How did you know about this solution?
It came to me in a dream. Whispered by the ghost of Barbara Stanwyck, once
the highest-paid woman in the United States and famed for movies such as
'Sorry, Wrong Number'. Lesser-known but no less valuable contributions to
postmodern creative thinking include 'Sorry, Wrong Module'.
I think that this means that my problem is solved, but the question
remains: why does i915kms cause freezes when loaded from rc.conf and works
normally when loaded by hand? This is not handbook-documented behavior. Nor
is it consistent or transparent.
Maybe not Intel-specific.
I find kld_list="drm" less troublesome than kld_list="radeonkms" with
<https://bsd-hardware.info/?probe=e90abb54c9#d10>
<https://bsd-hardware.info/?probe=e90abb54c9#d10>.
My voyage of discovery spanned around three years. Maybe longer. A few
<https://lists.freebsd.org/pipermail/freebsd-current//2018-September/071327.html>
<https://lists.freebsd.org/pipermail/freebsd-current//2018-September/071327.html>
(2018) I found kld_list="/boot/modules/radeonkms.ko" troublesome with
FreeBSD 12.0-ALPHA7
<https://lists.freebsd.org/pipermail/freebsd-questions/2018-October/283113.html>
<https://lists.freebsd.org/pipermail/freebsd-questions/2018-October/283113.html>
(2018) "… toying with the possibility that … a specific load/start order
might help."
<https://github.com/FreeBSDDesktop/kms-drm/issues/101#issuecomment-450776731>
<https://github.com/FreeBSDDesktop/kms-drm/issues/101#issuecomment-450776731>
(2019) I found drm-legacy-kmod better than drm-current-kmod with
13.0-CURRENT
<https://lists.freebsd.org/pipermail/freebsd-current/2020-November/077693.html>
<https://lists.freebsd.org/pipermail/freebsd-current/2020-November/077693.html>
peculiar
Eventually I condensed the working peculiarity to kld_list="drm".
<https://pastebin.com/4XjNFaKk> <https://pastebin.com/4XjNFaKk> line 17.

[Graham Perrin]

… Shouldn't your findings be mentioned in the handbook? By at least a
few words, such as: "if you have problems with
kld_list=radeonkms/i915kms, try kld_list=drm".

By-the-book (the FreeBSD Handbook) is, I believe:

* more for goodness that is consistent and explicable

* less for trial-and-error that leads to goodness without explanation.

Apparently, there are some people with similar problems, so maybe
solving the problem preemptively by documenting it, is the way to go.
I don't know the protocol here, this is my first time contacting the
FreeBSD mailing list.

Today <https://forums.FreeBSD.org/threads/80534/post-513631> it seems
that a problem was avoided by _not_ installing xf86-video-intel, which
<https://www.freshports.org/x11-drivers/xf86-video-intel/> describes as
legacy.

Matt, would you describe your hardware as legacy? Is your system still
freeze-free _with_ xf86-video-intel?

[kilikmatej]

Post by Graham Perrin
Today <https://forums.FreeBSD.org/threads/80534/post-513631> it seems
that a problem was avoided by _not_ installing xf86-video-intel, which
<https://www.freshports.org/x11-drivers/xf86-video-intel/> describes
as legacy.
Matt, would you describe your hardware as legacy? Is your system still
freeze-free _with_ xf86-video-intel?

Hello, my system works freeze-free.

I am able to use both the modesetting driver and also the
xf86-video-intel in xorg.conf, freeze-free.

But, I am using xf86-video-intel, because that way I can enjoy TearFree,
which is not possible with "modesetting".

My CPU was launched in Q2/2014. When you say "legacy hardware",
something like a needle printer, a floppy disk drive and serial modem
pops to mind, not an 8-year old CPU, which is perfectly capable of doing
day-to-day work-related actitivities.