Bug 217689 - x11-drivers/xf86-video-intel: Panic since latest update
Summary: x11-drivers/xf86-video-intel: Panic since latest update
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-x11 (Nobody)
Depends on:
Reported: 2017-03-10 20:35 UTC by Jason W. Bacon
Modified: 2019-02-06 11:58 UTC (History)
6 users (show)

See Also:
bugzilla: maintainer-feedback? (x11)

Text from /var/crash (99.95 KB, text/plain)
2017-03-16 22:13 UTC, Jason W. Bacon
no flags Details
Text from /var/crash (154.90 KB, text/plain)
2017-05-31 21:35 UTC, Dwayne MacKinnon
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jason W. Bacon freebsd_committer 2017-03-10 20:35:00 UTC
On my Lenovo T61, Intel driver was working well until the latest pkg upgrade.

I had been preloading i915kms out of necessity, from /boot/loader.conf.

System now panics when trying to start Xorg.

Tried moving i915kms load to /etc/rc.conf kms_list="i915kms".  Also tried not preloading it at all.  Same results in every case.

Here's a skeletal snapshot of the panic:

fbd0 on drm0
VT: Replacing driver "vga" with new "fb"
info [drm] Initialized i915 1.6.0 20080730 for drmn0 on minor 0
drm0: <Intel i965GM> on vgapci0
panic: make_dev_sv bad si_name (error=17, si_name=dri/card0)
#0 ... kdb_backtrace
#15 ... Xfast_syscall+0xfb

Happy to provide more info if needed.

Deleting xf86-video-intel and falling back to vesa eliminates the problem.
Comment 1 Alfonso S. Siciliano 2017-03-11 14:50:49 UTC
(In reply to Jason Bacon from comment #0)


Tried moving i915kms load to /etc/rc.conf kms_list="i915kms".  Also tried not preloading it at all.  Same results in every case.

kms_list="i915kms" seems wrong

You could try to put


in /etc/rc.conf
Comment 2 Jason W. Bacon freebsd_committer 2017-03-11 15:17:43 UTC

kld_list is what I had.  It's still there, but commented out, so I'm sure of this.

kms_list was a case of momentary dyslexia when writing the PR.
Comment 3 Matthew Rezny freebsd_committer 2017-03-16 17:10:37 UTC
(In reply to Jason Bacon from comment #0)

Start with complete information, i.e. everything between 0 and 15 in the backtrace. Attach Xorg.0.log and dmesg output.

Do you have a xorg.conf or anything in xorg.conf.d? Are you using stock packages are building locally?
Comment 4 Jason W. Bacon freebsd_committer 2017-03-16 22:11:43 UTC
Well, after another round of updates, the problem has gone away.

Unfortunately, I did not save a copy of Xorg.0.log from a failed start.

I'll attach the text from the last crash in case that helps.

No xorg.conf.

All packages installed vi pkg from pkg+http://pkg.FreeBSD.org/${ABI}/latest.
Comment 5 Jason W. Bacon freebsd_committer 2017-03-16 22:13:42 UTC
Created attachment 180887 [details]
Text from /var/crash
Comment 6 Matthew Rezny freebsd_committer 2017-03-20 13:14:32 UTC
(In reply to Jason Bacon from comment #5)

Your crash log shows that both i915kms.ko and i915.ko are loaded, and the crash was in the intel drm code. If the problem has gone away after the last update, then most likely your problem was simply a conflict between those two kernel modules, which should not be used together, that was caused by a bug in xf86-video-intel. The last update of this port was done specifically to fix the bug that resulted in it loading both modules when starting X.
Comment 7 Julien Cigar 2017-03-21 21:03:35 UTC
I'm still getting a panic on an old Asus EEE 1005P, with 10.3 and xf86-video-intel-2.99.917.20170228
Comment 8 Matthew Rezny freebsd_committer 2017-03-21 23:44:23 UTC
(In reply to Julien Cigar from comment #7)

This is your first reply to this PR, so "still getting a panic" has no context and means nothing. Post the full panic.
Comment 9 Matthew Rezny freebsd_committer 2017-04-26 11:09:23 UTC
OP indicated another update resolved the issue. No reply from the "me too" for over a month.
Comment 10 Dwayne MacKinnon 2017-05-31 21:31:11 UTC
I'm running into this issue now on an old Eurocom laptop. I've attached a crash log.
Comment 11 Dwayne MacKinnon 2017-05-31 21:35:36 UTC
Created attachment 183115 [details]
Text from /var/crash
Comment 12 Friedrich Volkmann 2018-07-06 17:55:59 UTC
When I bought a new mainboard with an onboard Intel graphics chip in (I believe) early 2015, I found out that the kernel had a known issue (which I do not remember in detail) that prevented xorg from working with the intel driver. I have used the vesa driver instead without any visible problems (except that mplayer reported my system as too slow). Today I upgraded to latest FreeBSD-11.2 stable and gave the intel driver a try again. After starting X, the system immediately rebooted. Then I tried the trick suggested by "sidetone" in https://forums.freebsd.org/threads/xorg-intel-hd-graphics-intel-driver-not-working.50605/ : I commented out "device i915drm" and "device drm" in the kernel config file. Now I can successfully start X. But switching back to text mode is broken. When I press Ctrl-Alt-F1 oder terminate X, the screen remains in graphics mode and gets somewhat distorted. I can't get to see the console output any more.
Comment 13 Niclas Zeising freebsd_committer 2018-07-06 18:06:24 UTC
(In reply to Friedrich Volkmann from comment #12)

Which graphics driver are you using?  The one in base (called drm2 sometimes) or from ports?  There should be no need to have any driver in the kernel config, they work fine as modules.

If you are running FreeBSD 11.2 or stable, can you please try with the graphics/drm-stable-kmod or graphics/drm-next-kmod graphics driver installed?

Comment 14 Friedrich Volkmann 2019-02-05 11:04:13 UTC
(In reply to Niclas Zeising from comment #13)

I was using FBSD 11-STABLE and now upgraded to 12-STABLE. No significant change...

I do not have any drm in the kernel config file. Upon starting X, i915kms.ko and drm2.ko are automatically loaded. These are certainly taken from the /boot/kernel directory, as the same thing happens when I load i915kms.ko in the console manually. The console gets black, so I can't ready any output nor what I'm writing. But when I type "startx", the display mode changes into graphics and it works. When I return to the console via ctrl-alt-F1 or terminating X, it is black again.

/usr/src/UPDATING advises to:

but it doesn't say where to add them. In the kernel config they don't work. After a quick web search, I've added them to /etc/make.conf, but I still have no Idea what they are doing.
2) "amd64 users should just install the drm-kmod port", but that ports installs documentation only, no modules. So I installed drm-fbsd12.0-kmod (version: 4.16.g20181215) instead. But there seem to be numerous issues with that port:

# kldload /boot/modules/i915kms.ko
link_elf_obj: symbol vt_fb_attach undefined
Warning: memory type linux leaked memory on destroy (2 allocations, 144 bytes leaked).
linker_load_file: /boot/modules/drm.ko - unsupported file type
KLD i915kms.ko: depends on drmn - not available or version mismatch
linker_load_file: /boot/modules/i915kms.ko - unsupported file type
kldload: an error occurred while loading module /boot/modules/i915kms.ko. Please check dmesg(8) for more details.

So I deinstalled that port and installed drm-legacy-kmod, but kldloading /boot/modules/i915kms.ko has the same effect as /boot/kernel/i915kms.ko.

There's some output when the module is loaded, but I can't read it, because it immediately disappears. This is what's in /var/log/messages:
kernel: drmn0: =======================================================
kernel: drmn0: This code is obsolete abandonware. Install the graphics/drm-legacy-kmod pkg
kernel: drmn0: =======================================================
kernel: drmn0: Deprecated code (to be removed in FreeBSD 13): drm2 drivers
kernel: drmn0: =======================================================
kernel: drmn0: This code is obsolete abandonware. Install the graphics/drm-legacy-kmod pkg
kernel: drmn0: =======================================================
kernel: drmn0: Deprecated code (to be removed in FreeBSD 13): drm2 drivers
kernel: drmn0: <Intel Haswell (GT2 desktop)> on vgapci0
kernel: info: [drm] Memory usable by graphics device = 2048M
kernel: info: [drm] MTRR allocation failed.  Graphics performance may suffer.
kernel: intel_iicbb0 on drmn0
kernel: iicbus0: <Philips I2C bus>error: [drm:pid2681:i915_write32] *ERROR* Unknown unclaimed register before writing to c5100
kernel:  on iicbb0 addr 0xff
kernel: info: [drm] Initialized i915 1.6.0 20080730 for drmn0 on minor 0
kernel: info: [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off

Writing this, I realize that this has been closed. That's certainly ok, because it's not an x11-drivers issue but a kernel issue. I just wonder where the new bug resides?
Comment 15 Niclas Zeising freebsd_committer 2019-02-05 11:12:06 UTC
(In reply to Friedrich Volkmann from comment #14)
We can reopen the PR if the issue persist.

You can try installing drm-kmod and adding kld_list="/boot/modules/i915kms.ko" to /etc/rc.conf, or load /boot/modules/i915kms.ko manually with kldload, and see if the new driver works better.  If you are on STABLE, or with a custom kernel, you have to build the kmod from ports, that's because it has to match the kernel.
Comment 16 Friedrich Volkmann 2019-02-05 12:25:17 UTC
(In reply to Niclas Zeising from comment #15)

As I already tried to explain in my previous comment, the drm-kmod port installs no modules, whereas the drm-fbsd12.0-kmod port installs a /boot/modules/i915kms.ko than does not work at all, and the drm-legacy-kmod port installs a /boot/modules/i915kms.ko that behaves the same way as /boot/kernel/i915kms.ko, i.e. blacking out the console screen. Apparently, it even spouts the same warning, telling me to install the port which is part of.

I guess that I'll have to buy a graphics card, because FreeBSD support for the Intel Haswell GPUs has never ever been working, and the degradation of the kernel module to a port that has "legacy" in its name indicates that this has finally been given up on.
Comment 17 Niclas Zeising freebsd_committer 2019-02-05 12:54:14 UTC
(In reply to Friedrich Volkmann from comment #16)

Haswell should be supported.

drm-kmod is a meta port that brings in the correct drm-*-kmod port, nothing else.  It does not have any modules by itself.

drm-legacy-kmod is the same driver that's in base on FreeBSD 12.  This is because the base kernel modules are slated for removal in FreeBSD 13.

You need to remove the driver installed from pkg before building the module from ports.  If you are on FreeBSD 12, then pkg remove drm-fbsd12.0-kmod followed by pkg autoremove should suffice.
Comment 18 Friedrich Volkmann 2019-02-05 13:58:33 UTC
"drm-legacy-kmod is the same driver that's in base on FreeBSD 12"
That's certainly the reason why both malfunction in the same way, and why the meta-port doesn't really install anything on FreeBSD 12.
Comment 19 Friedrich Volkmann 2019-02-06 08:39:39 UTC
I've created bug 235550 for the problem with the old module. I haven't created a bug for the problems with the new (linux-dependent) module, because my hardware certainly isn't supported by it anyway.