i915 driver causing freezes on FreeBSD 13.0

Hello,

Not sure where to start, so let's start from the beginning: Issues started after upgrading to FreeBSD 13.0 from 12.2-p6. I was prepared for intel i915 rigmarole, so it did not surprise me that much. But now it got to the point where I don't even what am I doing anymore, I am just trying various combinations of settings, module loading, unloading, etc and hoping that something will somehow work. No luck so far.

Loading i915kms and starting X (both by issuing startx and by xdm service) causes freezes. Sometimes the freezes are not so fatal and the PC can be restarted via ctrl+alt+del or by typing blindly shutdown -r now into the dead blackness of my monitor, or sometimes only by pressing the power button and waiting. Sometimes these freezes are fatal to the point, where even pressing the reset button does not do anything and I have to power cycle the PC by holding the power button, or by turning off the power supply.

Here is what I've tried so far:
  1. Unloading everything drm-freebsd13.0-kmod, drm-kmod, i915kms, xf86-video-intel related from the system, uninstalling the packages and removing all mentions in /etc/rc.conf or in /usr/local/etc/X11/xorg.conf.d, this way ofcourse I can't get to X, because no screens were found.
  2. Installing the aforementioned packages from ports
  3. Installing the aforementioned packages from pkg
  4. loading the kernel module by saying explicitly in /etc/rc.conf
    Code:
    kld_list="${kld_list} /boot/modules/i915kms.ko cuse fusefs coretemp"
  5. loading the kernel module by saying in rc.conf
    Code:
    kld_list="${kld_list} i915kms cuse fusefs coretemp"
  6. now I somehow forced it to run, I have this entry
    Code:
    kld_list="${kld_list}  cuse fusefs coretemp"
    , so the i915kms loads only when I startx. This is not consistent, though. Next restart it may freeze again even with these settings.
  7. I noticed interesting GPU HANG messages in my logs, which happen right before freezing. But sometimes, this message does not even appear in /var/log/messages.
anyway, here are /var/log/messages
and here is Xorg.0.log
here is lspci

Code:
~> pls lspci
00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM Controller (rev 06)
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06)
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05)
00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #1 (rev d5)
00:1c.2 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #3 (rev d5)
00:1c.3 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #4 (rev d5)
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation B85 Express LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 05)
00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller (rev 05)
01:00.0 USB controller: VIA Technologies, Inc. VL805/806 xHCI USB 3.0 Controller (rev 01)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)
03:00.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 41)


Thanks for any idea or suggestion.
 
Okay, so as for today, I did not have any issues. The last change I made was in rc.conf, where I specificaly don't load i915kms, but it still gets loaded anyway when xdm starts. I won't close this thread immediately, I will leave it open and update after the weekend if anything randomly breaks. But still, I am confused as to what I did and what happened, not sure why it is fixed or even if it is fixed, maybe tomorrow it will freeze again, I am not certain.
 
Having a look the xorg.log I see you are using intel driver...
Code:
[    30.610]     ABI class: X.Org Server Extension, version 10.0
[    30.610] (II) LoadModule: "intel"
[    30.610] (II) Loading /usr/local/lib/xorg/modules/drivers/intel_drv.so
I had similar problems with "intel" driver and my solution was to change to "modesetting" driver.

Try to create a "test_modesetting.conf" on "/usr/local/etc/X11/xorg.conf.d" and let's see what happens.

Example:
Code:
Section "Device"
    Identifier  "Card0"
    #Driver      "intel"
    Driver      "modesetting"
    BusID       "PCI:0:2:0"
EndSection
 
Thanks for the reply diego,

So, I tried this: Changed the "intel" entry to "modesetting" and I also disabled all the other tweaks like "Option TearFree" and "AccelMethod" by commenting them all out in /usr/local/etc/X11/xorg.conf.d/20-intel.conf
I rebooted and tried startx
At first, of course, I had a "no screen" error from X, so I had to load i915kms manually by issuing kldload i915kms. That worked and I got to X by using startx
Then I tried rebooting with a small change - I put "i915kms" into /etc/rc.conf.
Now, after issuing startx I had a freeze, I had to reboot using the reset button on the PC case.

then I booted to single user mode, changed the /etc/rc.conf to not include the i915kms entry, quit the single-user mode by pressing CTRL+D, booted to multiuser, loaded i915kms by issuing kldload i915kms, did startx and now it froze so hard, I had to turn off the powersupply by a mechanical switch, not even the reset button worked.

Then I started the computer again, after boot sequence I loaded i915kms manually again, did no changes to anything, did startx and here I am, running X, writing this post. glxinfo says "Direct rendering: YES"
Now, is there any kind of consistency here? Not at all.

Anyway, after the second, hard freezeup, I have this in my /var/log/messages
Code:
  39 Apr 24 17:36:03 fbsd kernel: drmn0: <drmn> on vgapci0
  38 Apr 24 17:36:03 fbsd kernel: vgapci0: child drmn0 requested pci_enable_io
  37 Apr 24 17:36:03 fbsd syslogd: last message repeated 1 times
  36 Apr 24 17:36:03 fbsd kernel: [drm] Unable to create a private tmpfs mount, hugepage support will be      disabled(-19).
  35 Apr 24 17:36:03 fbsd kernel: Failed to add WC MTRR for [0xe0000000-0xefffffff]: -22; performance may      suffer
  34 Apr 24 17:36:03 fbsd kernel: [drm] Got stolen memory base 0x9fa00000, size 0x22000000
  33 Apr 24 17:36:03 fbsd kernel: [drm ERROR :i915_gem_init_stolen] Stolen reserved area 0xfffffe00d45eba     10R outside stolen memory 0xfffffe00d45eb9f8R
  32 Apr 24 17:36:03 fbsd kernel: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
  31 Apr 24 17:36:03 fbsd kernel: [drm] Driver supports precise vblank timestamp query.
  30 Apr 24 17:36:03 fbsd kernel: [drm] Connector VGA-1: get mode from tunables:
  29 Apr 24 17:36:03 fbsd kernel: [drm]   - kern.vt.fb.modes.VGA-1
  28 Apr 24 17:36:03 fbsd kernel: [drm]   - kern.vt.fb.default_mode
  27 Apr 24 17:36:03 fbsd kernel: [drm] Connector HDMI-A-1: get mode from tunables:
  26 Apr 24 17:36:03 fbsd kernel: [drm]   - kern.vt.fb.modes.HDMI-A-1
  25 Apr 24 17:36:03 fbsd kernel: [drm]   - kern.vt.fb.default_mode
  24 Apr 24 17:36:03 fbsd kernel: [drm] Connector HDMI-A-2: get mode from tunables:
  23 Apr 24 17:36:03 fbsd kernel: [drm]   - kern.vt.fb.modes.HDMI-A-2
  22 Apr 24 17:36:03 fbsd kernel: [drm]   - kern.vt.fb.default_mode
  21 Apr 24 17:36:03 fbsd kernel: sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)!
  20 Apr 24 17:36:03 fbsd kernel: [drm] Initialized i915 1.6.0 20190822 for drmn0 on minor 0
  19 Apr 24 17:36:03 fbsd kernel: WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD      14.0.
  18 Apr 24 17:36:03 fbsd kernel: VT: Replacing driver "efifb" with new "fb".
  17 Apr 24 17:36:03 fbsd kernel: start FB_INFO:
  16 Apr 24 17:36:03 fbsd kernel: type=11 height=1050 width=1680 depth=32
  15 Apr 24 17:36:03 fbsd kernel: cmsize=16 size=8294400
  14 Apr 24 17:36:03 fbsd kernel: pbase=0xe0009000 vbase=0xfffff800e0009000
  13 Apr 24 17:36:03 fbsd kernel: name=drmn0 flags=0x0 stride=7680 bpp=32
  12 Apr 24 17:36:03 fbsd kernel: cmap[0]=0 cmap[1]=7f0000 cmap[2]=7f00 cmap[3]=c4a000
  11 Apr 24 17:36:03 fbsd kernel: end FB_INFO
 
When it freezes, and you reboot, is the CPU temperature a bit high? Mine froze on an AMD, sometimes inconsistently, and my CPU temperature was kind of hot. This could explain inconsistencies on when it freezes.

It's the video driver, but could also be ACPI.

I simplified computer settings and reverted to using the generic kernel that came with the release. Then this stopped happening.
 
I will keep an eye on that. I got semi-consistent (or entirely consistent? I can't really tell at this point) non-freezing state with i915kms not being in /etc/rc.conf and letting xdm service autoload it when it starts, while using x11-drivers/xf86-video-intel and "Driver "intel"" section in /usr/local/etc/X11/xorg.conf.d/20-intel.conf. It did not freeze for 2 days, now I started experimenting again with modesetting as per diego's advice.
 
Ok, so after some tweaking and testing I got to this conclusion:

Loading i915kms in /etc/rc.conf makes the computer freeze with 100% probability.

Using the modesetting driver or the intel driver in xorg.conf.d/20-intel.conf does not make any difference, except for one thing: with intel driver, I can actually use xdm and login like that, with modesetting driver, xdm ofcourse fails to start, I have to login at the tty, manually kldload i915kms then I can startx and it works.
Any ideas?
As for me, I am somewhat OK with that, I can use the computer, albeit with a sour aftertaste, because it works and I don't know why. So just out of curiosity I would like to know what's wrong with it or atleast where to start looking for an issue.

TLDR:
Loading i915kms automatically in rc.conf makes the computer freeze on startx/xdm login
Loading it manually works like nothing's happening.
I lack a logical conlusion and it annoys me.
 
What you may be experiencing is where the i915kms driver resides.
The default one (/boot/kernel/)with kernel is loaded with this:

kld_list=i915kms

But you are loading the one from ports that ends up in /boot/modules.
kld_list="${kld_list} /boot/modules/i915kms.ko
So if manually running kldload works then you need to figure out which version it is using and add that to rc.conf..
 
It sounds like when you're using the new i915kms driver it's giving issues as this is similar in my experience when I try to load that driver and it reverts to the barebone generic driver. My scenario is gpu hangs when trying to use my webcam, I'm still running release 12.2 so when I eventually do update I'll confirm what I'm seeing.
 
What you may be experiencing is where the i915kms driver resides.
The default one (/boot/kernel/)with kernel is loaded with this:

kld_list=i915kms

But you are loading the one from ports that ends up in /boot/modules.

So if manually running kldload works then you need to figure out which version it is using and add that to rc.conf..

That's true for 12.2 and earlier, but not anymore for 13.0, drm stuff was removed from base, which means the only i915kms.ko remaining is the one from ports to be found in /boot/modules/ and that's what gets loaded with kld_list="i915kms" now.
 
That's true for 12.2 and earlier, but not anymore for 13.0, drm stuff was removed from base, which means the only i915kms.ko remaining is the one from ports to be found in /boot/modules/ and that's what gets loaded with kld_list="i915kms" now.
yeah, that's right. I checked it with
Code:
kldstat -h -v -n i915kms
. changing the entry in rc.conf to /boot/modules/i915kms.ko or only i915kms yields the same results using the kldstat command.

What you may be experiencing is where the i915kms driver resides.
The default one (/boot/kernel/)with kernel is loaded with this:

kld_list=i915kms

But you are loading the one from ports that ends up in /boot/modules.

So if manually running kldload works then you need to figure out which version it is using and add that to rc.conf..
I did precisely that and the result is -again- non-consistent. Not to mention, that it's the same module, as per bsduck's post. Yesterday it worked with /boot/modules/i915kms.ko in rc.conf, today (I did not change anything!), it did not freeze the PC, but I couldn't get to the XDM login screen, I only got a black screen with a cursor. I could get to tty by CTRL+ALT+F1 and waiting, what greeted me, were messages like:

Code:
Apr 26 17:51:33 fbsd kernel: drmn0: Resetting chip for hang on rcs0
Apr 26 17:51:33 fbsd syslogd: last message repeated 10 times
Apr 26 17:52:33 fbsd syslogd: last message repeated 16 times
Apr 26 17:52:33 fbsd kernel: drmn0: GPU recovery timed out, cancelling all in-flight rendering.
Apr 26 17:52:33 fbsd kernel: drmn0: Resetting chip for hang on rcs0
Apr 26 17:52:33 fbsd syslogd: last message repeated 1 times
Apr 26 17:52:52 fbsd login[6194]: ROOT LOGIN (root) ON ttyv0
Apr 26 17:53:29 fbsd kernel: drmn0: Resetting chip for hang on rcs0
Apr 26 17:53:46 fbsd syslogd: last message repeated 8 times
Apr 26 17:54:21 fbsd syslogd: last message repeated 17 times
Apr 26 17:54:21 fbsd login[6286]: ROOT LOGIN (root) ON ttyv1
Apr 26 17:54:23 fbsd kernel: drmn0: Resetting chip for hang on rcs0
Apr 26 17:54:24 fbsd kernel: drmn0: GPU recovery timed out, cancelling all in-flight rendering.
Apr 26 17:54:24 fbsd kernel: drmn0: Resetting chip for hang on rcs0
Apr 26 17:54:26 fbsd devd[77907]: notify_clients: send() failed; dropping unresponsive client
Apr 26 17:54:26 fbsd syslogd: last message repeated 1 times
Apr 26 17:54:33 fbsd kernel: drmn0: Resetting chip for hang on rcs0
Apr 26 17:54:54 fbsd syslogd: last message repeated 10 times

I edited rc.conf not to include any i915kms entry and rebooted and I am here now.
If it is a HW issue, then it is very weird that it started right the same day that I upgraded to 13.0. There must be some kind of a bug there.
Any ideas? I am basically clueless at this point.
 
I think you should just reinstall the package to the latest version of drm-fbsd13-kmod:
Code:
diego@freebsd:~$ pkg which /boot/modules/i915kms.ko
/boot/modules/i915kms.ko was installed by package drm-fbsd13-kmod-5.4.92.g20210419
Reinstall package after upgrade packages
Code:
pkg update && pkg upgrade -y
pkg upgrade -f drm-fbsd13-kmod
That It should install "gpu-firmware-kmod" too.
Reboot
 
Dont ask me why but sometimes reinstall all packages just work ;)
Code:
# pkg clean all && pkg autoremove -y
# pkg upgrade -f
reboot
 
Hello,
I run FreeBSD 13.0 and I have the same Intel Apu than you but rev 9. In /boot/loader.conf I have set the console driver to
vt and disable the vga textmode. In plus I have disable msi irq for pci and drm. You should set your console to the same resolution you want in X, the native one by preference.

hw.ata.atapi_dma="1"
hw.drm.msi="0"
hw.pci.enable_msi="0"
hw.pci.enable_msix="0"
hw.usb.no_boot_wait="1"
hw.usb.template="3"
hw.vga.textmode="0"
kern.vty="vt"
kern.vt.fb.default_mode="1920x1200"

I was using scfb and intel Xorg drivers with FreeBSD 12.2 but switch to modesetting with 13.0 and gain double performance benefit and more. scfb and intel Xorg drivers work but with less half FPS with glxgears. With the intel driver I use the option
Option "AccelMethod" "UXA"
who can make a difference compare to SNA. In FreeBSD 13.0 modesetting is the best for me. I load the i915kms and drm
modules in /etc/rc.conf. Graphic work normally.
 
Dont ask me why but sometimes reinstall all packages just work ;)
Code:
# pkg clean all && pkg autoremove -y
# pkg upgrade -f
reboot
I tried both of your advices, nothing helped.
Hello,
I run FreeBSD 13.0 and I have the same Intel Apu than you but rev 9. In /boot/loader.conf I have set the console driver to
vt and disable the vga textmode. In plus I have disable msi irq for pci and drm. You should set your console to the same resolution you want in X, the native one by preference.

hw.ata.atapi_dma="1"
hw.drm.msi="0"
hw.pci.enable_msi="0"
hw.pci.enable_msix="0"
hw.usb.no_boot_wait="1"
hw.usb.template="3"
hw.vga.textmode="0"
kern.vty="vt"
kern.vt.fb.default_mode="1920x1200"

I was using scfb and intel Xorg drivers with FreeBSD 12.2 but switch to modesetting with 13.0 and gain double performance benefit and more. scfb and intel Xorg drivers work but with less half FPS with glxgears. With the intel driver I use the option
Option "AccelMethod" "UXA"
who can make a difference compare to SNA. In FreeBSD 13.0 modesetting is the best for me. I load the i915kms and drm
modules in /etc/rc.conf. Graphic work normally.

So, I have vty="vt" set since FreeBSD 12.1 I think.
I tried hw.vga.textmode="0" and kern.vt.fb.default_mode="1920x1080"
All this yielded was a frozen computer, but differently than last time - I could move my cursor on a black screen, otherwise it was frozen. Did not even respond to ACPI shutdown triggered by power button.
I tried AccelMethod UXA with intel driver, this yielded 1fps in alacritty and also in glxgears, even though glxinfo said: Direct rendering = YES.

So after another 2 hours of experimentation I am back to square one = not loading i915kms in rc.conf and using intel driver in xorg.conf.d.
There is also another option = using the modesetting driver, but when I do that, xdm fails to start, I have to manually kldload i915kms after logging in in tty and also, using modesetting I can't seem to get rid of screentearing, which is annoying as hell.

Thank you for your time though, I may be a bit of a masochist, because I actually enjoy fiddling with settings.
It's getting a bit frustrating now though.
 
Ok, so is this a bug? Should I perhaps try contacting FreeBSD mailing list, or should I not bother them with this small-ish issue, as I have found a working solution, but have no idea why it does not work as advertised?
 
Ok, so is this a bug? Should I perhaps try contacting FreeBSD mailing list, or should I not bother them with this small-ish issue, as I have found a working solution, but have no idea why it does not work as advertised?
I'm afraid I have no more ideas. It looks to me a bug or something with your hardware. You could look and share your hardware using https://bsd-hardware.info/

FYI: there are records of all my laptops and servers there :)
 
I have also had the drmn0: Resetting chip for hang on rcs0 problem a few times, causing the screen to freeze and necessitating a reboot. This has also only happened since the upgrade to 13.0.

One added complication is that I've just moved from LXQT to KDE-Plasma, but I'm not sure that this has anything to do with things. The problem tends to happen when the system is under heavy mixed load, such as doing a backup while watching YouTube.

I'm running an old Intel i5-3570K which may be a useful data point.
 
One added complication is that I've just moved from LXQT to KDE-Plasma, but I'm not sure that this has anything to do with things.
I am certain that it has nothing to do with desktop environment. I am using a window manager.
My CPU is i5-4690.
Freezes happen immediately, so there is no system load to talk about.
 
Hi everyone.
I'm experiencing very similar issues with the same video hardware on a fresh 13.1-RELEASE install. No matter what I try, the result is always 100% unchanged: the display manager (LightDM) loads as expected and seems robust, but once logged in as a user, X freezes after a couple of seconds. It's always the same delay, about 3 seconds. It doesn't seem to be a desktop environment (LXDE) issue because when no video module is installed, the system loads the default x11-drivers/xf86-video-vesa and everything works without crashing, although too slow to be usable.

So far I have tried all this:
  1. installing alternatively drm-kmod and drm-510-kmod, both from packages and from ports;
  2. loading, or not loading, drm and i915kms modules from /etc/rc.conf in different combinations: either kld_list="" or kld_list="drm" or kld_list="i915kms" or kld_list="drm i915kms";
  3. loading x11-drivers/xf86-video-intel from /usr/local/etc/X11/xorg.conf.d/device.conf, with and without forcing DRI3, with and without UXA as acceleration option;
  4. using Driver "modesetting" instead of the intel driver; with and without specifying the BusID.
Here is how my /usr/local/etc/X11/xorg.conf.d/device.conf looks like:
Code:
Section "Device"
    Identifier "Xeon E3-1200"
    Driver     "intel"
    #Driver     "modesetting"
    #Option     "DRI"   "3"          # default is DRI3
    #Option     "AccelMethod" "SNA"  # default
    #Option     "AccelMethod" "UXA"  # fallback
    #BusID      "PCI:0:2:0"
EndSection

I noticed that DRI3, in spite of being the default (right?), keeps disabled unless forced from #Option "DRI" "3" in file xorg.conf.d/device.conf. But DRI2 gets always enabled.

Anyway, and no matter what is done, the result is always the same: the X server freezes with a black screen and a dead keyboard. I have to shutdown the system remotely from my laptop as, fortunately, the base system and ssh are not affected by this issue.

At this point I'm clueless, so any idea is welcomed. Many thanks.

P.S.: for the details, I could post the link to a comprehensive hardware probe if useful. Actually I don't know whether it is safe, so please let me know. Thanks.
 
Back
Top