i915kms issues on 14.1-STABLE

J

jb82

Hey,
I'm quite new to the awesome FreeBSD community. 14.1-RELEASE with `drm-61-kmod` should allegedly support even the newest Alder Lake and Raptor Lake HW. I have a NUC with Intel 1360p, did my best but the machine experiences many issues with the driver, especially with KDE on 14.1-STABLE with that driver (the driver + firmware compiled from ports as-is). Machine is barely usable. So, my question is whether 1360p's iGPU is not supported at all (seems that Linux Kernel 6.1 supports it though) and if it is considered supported, what is the best way how to provide a feedback.

Behavior (dmesg):
  • GPU is correctly detected
  • Firmware is correctly loaded
  • But after starting Plasma/X11 session there's so much flickering and tearing that the UI is barely usable

Everything above given my assumption, that 14.1-STABLE being 1-2 months from the release should not be IMHO that bad. Of course, only considering i915kms support, everything else feels awesome.

So, please, feel free to correct any of my assumptions, I guess such an information might be worthy also for other people considering FreeBSD.

Thank you!
 
Make sure you're building graphics/drm-61-kmod from ports, the packages on the FreeBSD repositories are still being built for 14.0-RELEASE. I'm not able to test it but the 14.0-RELEASE kernel modules will probably fail to load on 14.1.

Makoto said:
FreeBSD 14.1 is still BETA.
Click to expand...
Tricky I know but 14.1-BETA1 != 14.1-STABLE. It's a different branch, releng/14.1 vs. stable/14.

That said, I would recommend the OP to stick to 14.1-BETA1 (and eventually -RELEASE), it's much easier to keep it updated.
 
SirDice said:
Make sure you're building graphics/drm-61-kmod from ports.
Click to expand...
Yes, as mentioned in the post, both driver + firmware taken from ports. dmesg doesn't complain about anything, but after logging into KDE (via sddm) a console is full of bug reports and UI is unusable.

Thanks for mentioning that inequality! I wasn't aware of that.
 
jb82 said:
Thanks for mentioning that inequality! I wasn't aware of that.
Click to expand...
It has to do with the way releases are made. New minor releases are always branched off from the major stable branches, in a way the stable branches are the alpha versions of the next minor release versions.

A picture says more than a thousand words:
forums.freebsd.org

LTS support and version clarifications

Hello everybody, I have read the documentation for a while but have not been able to clarify my doubts. I will try to be as short as possible. At present according to this table: https://www.freebsd.org/security/#sup the latest LTS version is Stable 12. So if I wanted to have a long support I...
forums.freebsd.org forums.freebsd.org
 
Well, 14.1-BETA2 definitely easier ride then STABLE but... still some flicker, e.g. when the browser is run the terminal flickers for 1-2s. Moreover, overall graphics performance seems to be on 60% of that in Linux/Windows for the very same machine. Any sanitiziers enabled for -BETA?

From time to time I see this:

Code: 
drmn0: [drm] *ERROR* Timed out waiting for DSB workload completion.
 
Hello:

For what its worth, here is our experience with Alder/Raptor Lake. We messed with this extensively at the beginning of the year with 14.0 and were unable to get drm running successfully. The error message: "drmn0: [drm] *ERROR* Timed out waiting for DSB workload completion." is one we experienced trying to get drm working with 14.0. Only when we moved to 14-stable was drm functional. Now we run 14.1-stable. ( 14.1-STABLE FreeBSD 14.1-STABLE stable/14-n267634-7b65987885da GENERIC amd64 )

It's unclear from above if there is a drm issue or KDE/plasma issue here. Does your system have another graphics card? Here's what we did to get drm working:

1) Install and build 14-stable/14.1 stable (now) from scratch for a command line system - disable sddm.

2) Get X going with the scfb (examine Xorg.0.log) driver with vanilla X - no fancy KDE/plasma wm or any wm - all defaults. Basic X should start with no configuration file displaying 3 windows. Mouse troubles are another issue (sometimes evdev/sysctl). Appears this was accomplished.

3) As someone said above, build/install drm-61-kmod (or its update) from source. Do not forget the correct firmware. Is there any error message?

3a) Load the module and observe dmesg from the command line. Was the firmware loaded correctly? Note: one cannot unload this module.

4) Start X again from the command line without any additional configuration - default wm as in #2. The system should pick up drm as default - see X.org.0.log and verify the correct display modes are available. (check xrandr too)
4a) Add
# Intel GPU drivers
kld_list="i915kms"
to /etc/rc.conf
reboot

4b) Examine dmesg again - search for drm. Something similar to below should be seen:
[drm] Got Intel graphics stolen memory base 0x4c800000, size 0x4000000
drmn1: <drmn> on vgapci1
vgapci1: child drmn1 requested pci_enable_io
vgapci1: child drmn1 requested pci_enable_io
drmn1: successfully loaded firmware image 'i915/adlp_dmc_ver2_16.bin'
drmn1: [drm] Finished loading DMC firmware i915/adlp_dmc_ver2_16.bin (v2.16)
lkpi_iic9: <LinuxKPI I2C> on drm1
lkpi_iic10: <LinuxKPI I2C> on drm2
lkpi_iic11: <LinuxKPI I2C> on drm3
[drm] Initialized i915 1.6.0 20201103 for drmn1 on minor 0
VT: Replacing driver "efifb" with new "drmfb".
name=drmn1 id=i915drmfb flags=0x0 stride=7680

5) Try a slightly more complex wm - we verified i3 and xfce4 working.

6) If all is functional using i3 and/or xfce4 try the KDE/plasma.

As a last resort try Openbsd7.5 to check the drm with Alder Lake. For Alder Lake, drm worked out of the box for 7.5, although there was no KDE/plasma for testing - working with other wms.
 
You must log in or register to reply here.
Back
Top