freebsd
i915: Unable to start Sway
Describe the bug I am unable to start Sway. Some troubleshooting was performed in this thread, but I am not experienced enough with the FreeBSD kernel to understand what my next steps ought to be.
FreeBSD version
FreeBSD logos 15.0-CURRENT FreeBSD 15.0-CURRENT #2 drm-related-linuxkpi-changes-n279098-fac501fff97e: Mon Jul 28 13:50:04 EDT 2025 root@logos:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 1500054 1500048
PCI Info
pciconf -lv
hostb0@pci0:0:0:0: class=0x060000 rev=0x05 hdr=0x00 vendor=0x8086 device=0x7d30 subvendor=0x1028 subdevice=0x0d64
vendor = 'Intel Corporation'
class = bridge
subclass = HOST-PCI
vgapci0@pci0:0:2:0: class=0x030000 rev=0x00 hdr=0x00 vendor=0x8086 device=0x7d41 subvendor=0x1028 subdevice=0x0d64
vendor = 'Intel Corporation'
device = 'Arrow Lake-U [Intel Graphics]'
class = display
subclass = VGA
none0@pci0:0:4:0: class=0x118000 rev=0x05 hdr=0x00 vendor=0x8086 device=0x7d03 subvendor=0x1028 subdevice=0x0d64
vendor = 'Intel Corporation'
device = 'Meteor Lake-P Dynamic Tuning Technology'
class = dasp
pcib1@pci0:0:6:0: class=0x060400 rev=0x00 hdr=0x01 vendor=0x8086 device=0x774d subvendor=0x1028 subdevice=0x0d64
vendor = 'Intel Corporation'
class = bridge
subclass = PCI-PCI
pcib2@pci0:0:7:0: class=0x060400 rev=0x10 hdr=0x01 vendor=0x8086 device=0x7ec4 subvendor=0x1028 subdevice=0x0d64
vendor = 'Intel Corporation'
device = 'Meteor Lake-P Thunderbolt 4 PCI Express Root Port'
class = bridge
subclass = PCI-PCI
none1@pci0:0:8:0: class=0x088000 rev=0x00 hdr=0x00 vendor=0x8086 device=0x774c subvendor=0x1028 subdevice=0x0d64
vendor = 'Intel Corporation'
class = base peripheral
none2@pci0:0:10:0: class=0x118000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x7d0d subvendor=0x1028 subdevice=0x0d64
vendor = 'Intel Corporation'
device = 'Meteor Lake-P Platform Monitoring Technology'
class = dasp
none3@pci0:0:11:0: class=0x120000 rev=0x05 hdr=0x00 vendor=0x8086 device=0x7d1d subvendor=0x1028 subdevice=0x0d64
vendor = 'Intel Corporation'
device = 'Meteor Lake NPU'
class = processing accelerators
subclass = processing accelerators
xhci0@pci0:0:13:0: class=0x0c0330 rev=0x10 hdr=0x00 vendor=0x8086 device=0x7ec0 subvendor=0x1028 subdevice=0x0d64
vendor = 'Intel Corporation'
device = 'Meteor Lake-P Thunderbolt 4 USB Controller'
class = serial bus
subclass = USB
none4@pci0:0:13:2: class=0x0c0340 rev=0x10 hdr=0x00 vendor=0x8086 device=0x7ec2 subvendor=0x1028 subdevice=0x0d64
vendor = 'Intel Corporation'
device = 'Meteor Lake-P Thunderbolt 4 NHI'
class = serial bus
subclass = USB
xhci1@pci0:0:20:0: class=0x0c0330 rev=0x00 hdr=0x00 vendor=0x8086 device=0x777d subvendor=0x1028 subdevice=0x0d64
vendor = 'Intel Corporation'
class = serial bus
subclass = USB
none5@pci0:0:20:2: class=0x050000 rev=0x00 hdr=0x00 vendor=0x8086 device=0x777f subvendor=0x1028 subdevice=0x0d64
vendor = 'Intel Corporation'
class = memory
subclass = RAM
iwlwifi0@pci0:0:20:3: class=0x028000 rev=0x00 hdr=0x00 vendor=0x8086 device=0x7740 subvendor=0x8086 subdevice=0x4090
vendor = 'Intel Corporation'
class = network
ig4iic0@pci0:0:21:0: class=0x0c8000 rev=0x00 hdr=0x00 vendor=0x8086 device=0x7778 subvendor=0x1028 subdevice=0x0d64
vendor = 'Intel Corporation'
device = 'Arrow Lake-H [Serial IO I2C Host Controller]'
class = serial bus
ig4iic1@pci0:0:21:3: class=0x0c8000 rev=0x00 hdr=0x00 vendor=0x8086 device=0x777b subvendor=0x1028 subdevice=0x0d64
vendor = 'Intel Corporation'
device = 'Arrow Lake-H [Serial IO I2C Host Controller]'
class = serial bus
none6@pci0:0:22:0: class=0x078000 rev=0x00 hdr=0x00 vendor=0x8086 device=0x7770 subvendor=0x1028 subdevice=0x0d64
vendor = 'Intel Corporation'
class = simple comms
pcib3@pci0:0:28:0: class=0x060400 rev=0x00 hdr=0x01 vendor=0x8086 device=0x773c subvendor=0x1028 subdevice=0x0d64
vendor = 'Intel Corporation'
class = bridge
subclass = PCI-PCI
none7@pci0:0:30:0: class=0x078000 rev=0x00 hdr=0x00 vendor=0x8086 device=0x7725 subvendor=0x1028 subdevice=0x0d64
vendor = 'Intel Corporation'
device = 'Arrow Lake-H [PCH Serial IO UART Host Controller]'
class = simple comms
isab0@pci0:0:31:0: class=0x060100 rev=0x00 hdr=0x00 vendor=0x8086 device=0x7703 subvendor=0x1028 subdevice=0x0d64
vendor = 'Intel Corporation'
class = bridge
subclass = PCI-ISA
hdac0@pci0:0:31:3: class=0x040100 rev=0x00 hdr=0x00 vendor=0x8086 device=0x7728 subvendor=0x1028 subdevice=0x0d64
vendor = 'Intel Corporation'
class = multimedia
subclass = audio
none8@pci0:0:31:4: class=0x0c0500 rev=0x00 hdr=0x00 vendor=0x8086 device=0x7722 subvendor=0x1028 subdevice=0x0d64
vendor = 'Intel Corporation'
class = serial bus
subclass = SMBus
none9@pci0:0:31:5: class=0x0c8000 rev=0x00 hdr=0x00 vendor=0x8086 device=0x7723 subvendor=0x1028 subdevice=0x0d64
vendor = 'Intel Corporation'
class = serial bus
nvme0@pci0:1:0:0: class=0x010802 rev=0x01 hdr=0x00 vendor=0x1344 device=0x5425 subvendor=0x1344 subdevice=0x1100
vendor = 'Micron Technology Inc'
device = '2500 NVMe SSD (DRAM-less)'
class = mass storage
subclass = NVM
re0@pci0:44:0:0: class=0x020000 rev=0x15 hdr=0x00 vendor=0x10ec device=0x8168 subvendor=0x1028 subdevice=0x0d64
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller'
class = network
subclass = ethernet
DRM KMOD version https://github.com/freebsd/drm-kmod/commit/11774df8b0de434f22799ce65416131b07839729
To Reproduce Steps to reproduce the behavior: Start sway
Screenshots If applicable, add screenshots to help explain your problem.
Additional context Add any other context about the problem here.
One thing that might be helpful is to get a trace on Linux with all the DRM debugging options you can find turned on. As we found in the other thread, work is getting submitted to the GuC processor but the submitted work never actually starts which causes the GPU hangs. It would be helpful to understand what step we are missing on BSD.
See something like this
Thank you for the suggestion, @amshafer. There is no drm directory in /sys/modules, but I was able to get some debugging info by adding the following lines to my /boot/loader.conf file:
hw.dri.__drm_debug="-1"
dev.drm.__drm_debug="-1"
compat.linuxkpi.drm_debug="-1"
Is the information contained in the file above helpful?
That's similar to the logging I have enabled. I was saying it would be helpful if we could get equivalent logging on Linux to compare it with. Linux will have the /sys/modules path.
I booted in to the Linux 6.8.0-71-generic kernel with the command line argument drm.debug=0x19f and obtained the following output:
I can confirm problems that @centromere has. I am on Meteor Lake too and freshly released FreeBSD 15.
With drm-latest-kmod (6.9) I just get kernel panic and reboot when loading i915kms module. Situation is a bit better with drm-66-kmod (6.6) it loads sucessfully but I get screen artifacts even on console. As @emaste suggested switch to a different vty and back usually resolves artifacts (sort of).
I can not start sway. Basically I get the same output as @centromere .
00:00:00.003 [DEBUG] [sway/server.c:236] Initializing Wayland server
00:00:00.003 [INFO] [wlr] [libseat] [libseat/libseat.c:77] Seat opened with backend 'seatd'
00:00:00.003 [INFO] [wlr] [libseat] [libseat/backend/seatd.c:212] Enabling seat
00:00:00.003 [INFO] [wlr] [backend/session/session.c:108] Successfully loaded libseat session
00:00:00.013 [INFO] [wlr] [backend/backend.c:248] Found 1 GPUs
00:00:00.014 [INFO] [wlr] [backend/drm/backend.c:225] Initializing DRM backend for /dev/dri/card0 (i915)
00:00:00.014 [DEBUG] [wlr] [backend/drm/drm.c:110] Using atomic DRM interface
00:00:00.014 [DEBUG] [wlr] [backend/drm/drm.c:132] ADDFB2 modifiers supported
00:00:00.014 [INFO] [wlr] [backend/drm/drm.c:310] Found 4 DRM CRTCs
00:00:00.014 [INFO] [wlr] [backend/drm/drm.c:268] Found 24 DRM planes
00:00:00.014 [INFO] [wlr] [render/egl.c:205] Supported EGL client extensions: ...
00:00:00.016 [DEBUG] [wlr] [render/egl.c:523] Using EGL device /dev/dri/card0
MESA: warning: Could not get intel_device_info.
libEGL warning: egl: failed to create dri2 screen
My CPU:
Intel(R) Core(TM) Ultra 9 185H (family: 0x6, model: 0xaa, stepping: 0x4)
@dumbbell in 6.6 Meteor Lake was behind force_probe kernel parameter. It was declared stable in 6.7. Maybe that has something to do with these sway starting problems on drm-66-kmod ? Unfortunately I am not able to test your 6.9 (drm-latest-kmod) because I get panic.
Also, there is no meteorlake firmware in gpu-firmware-kmod package. I am using binaries downloaded from Linux kernel git.
I can confirm problems that @centromere has. I am on Meteor Lake too and freshly released FreeBSD 15.
With drm-latest-kmod (6.9) I just get kernel panic and reboot when loading i915kms module. Situation is a bit better with drm-66-kmod (6.6) it loads sucessfully but I get screen artifacts even on console. As @emaste suggested switch to a different vty and back usually resolves artifacts (sort of).
I can not start sway. Basically I get the same output as @centromere .
00:00:00.003 [DEBUG] [sway/server.c:236] Initializing Wayland server 00:00:00.003 [INFO] [wlr] [libseat] [libseat/libseat.c:77] Seat opened with backend 'seatd' 00:00:00.003 [INFO] [wlr] [libseat] [libseat/backend/seatd.c:212] Enabling seat 00:00:00.003 [INFO] [wlr] [backend/session/session.c:108] Successfully loaded libseat session 00:00:00.013 [INFO] [wlr] [backend/backend.c:248] Found 1 GPUs 00:00:00.014 [INFO] [wlr] [backend/drm/backend.c:225] Initializing DRM backend for /dev/dri/card0 (i915) 00:00:00.014 [DEBUG] [wlr] [backend/drm/drm.c:110] Using atomic DRM interface 00:00:00.014 [DEBUG] [wlr] [backend/drm/drm.c:132] ADDFB2 modifiers supported 00:00:00.014 [INFO] [wlr] [backend/drm/drm.c:310] Found 4 DRM CRTCs 00:00:00.014 [INFO] [wlr] [backend/drm/drm.c:268] Found 24 DRM planes 00:00:00.014 [INFO] [wlr] [render/egl.c:205] Supported EGL client extensions: ... 00:00:00.016 [DEBUG] [wlr] [render/egl.c:523] Using EGL device /dev/dri/card0 MESA: warning: Could not get intel_device_info. libEGL warning: egl: failed to create dri2 screenMy CPU:
Intel(R) Core(TM) Ultra 9 185H (family: 0x6, model: 0xaa, stepping: 0x4)@dumbbell in 6.6 Meteor Lake was behind
force_probekernel parameter. It was declared stable in 6.7. Maybe that has something to do with these sway starting problems on drm-66-kmod ? Unfortunately I am not able to test your 6.9 (drm-latest-kmod) because I get panic.Also, there is no meteorlake firmware in gpu-firmware-kmod package. I am using binaries downloaded from Linux kernel git.
I have the same hardware and got same problem, my dmesg:
[drm] Got Intel graphics stolen memory base 0x0, size 0x0
drmn0:
Sway unable to start, but xfce can, xfce show gpu info: llvmpipe(LLVM 19.1.7, 256 bits)
As noted in the issue that refers to this one, I noticed that even X11 on Meteor Lake doesn't have DRI. This issue is bigger than just sway, it means that DRI is not functional on Meteor Lake, and sway doesn't start because it relies on DRI. Can some of the people with the same issue confirm by running glxinfo | grep -i accel in your X11 session? It would also be meaningful to do cat /var/log/Xorg.0.log | grep DRI, which for me contains this line: [ 15.564] (II) AIGLX: Screen 0 is not DRI2 capable
I followed the previous discussion and kept going. Reading the lindebugfs file also caused a panic for me, but after removing i915_execlists_show_requests and intel_engine_print_breadcrumbs both of which caused a panic I was able to get some information on the engine.
I think it's not initialized properly.
@colfrog I'm on Meteor Lake but not only I can't start sway, I can't even start Xorg. After loading i915kms the console gets garbled and freezes. So does using 16.0 CURRENT with drm-latest-kmod somewhat help you? UPDATE: nope, this didn't work, going to open a separate issue.
@colfrog I'm on Meteor Lake but not only I can't start sway, I can't even start Xorg. After loading i915kms the console gets garbled and freezes. So does using 16.0 CURRENT with drm-latest-kmod somewhat help you? UPDATE: nope, this didn't work, going to open a separate issue.
I would try to compile the latest master if I were you, but this does seem like a separate issue. Have you installed the firmware? It's not in the metapackage
Yes, installed the gpu-firmware-kmod package, also compiled the latest master, the console freezes and becomes unresponsive. Also, it seems that the Meteor Lake flavor is still missing from the firmware?
Yes, installed the gpu-firmware-kmod package, also compiled the latest master, the console freezes and becomes unresponsive. Also, it seems that the Meteor Lake flavor is still missing from the firmware?
No it's not in the gpu-firmware-kmod package. You have to install gpu-firmware-intel-kmod-meteorlake.
Installed the firmware and, after waiting for a while, the console becomes readable like this, but always frozen
Installed the firmware and, after waiting for a while, the console becomes readable like this, but always frozen
That's unfortunate. I'd play with sysctls in /boot/loader.conf in the meantime and open a separate issue if I were you. Specifically the modeset sysctl (I don't know the full name by heart)