Open probonopd opened 2 years ago
According to @evadot in https://twitter.com/manuvadot/status/1544994257169223680
You need drm-510-kmod which is available for >= 13.1-RELEASE
As per https://www.freshports.org/graphics/drm-510-kmod/, currently a package is only available for FreeBSD:14:amd64 latest, whereas we need FreeBSD:13:amd64 quarterly for the upcoming helloSystem 0.8.0.
In FreeBSD 13.1-RELEASE with quarterly packages, installing pkg install -y graphics/gpu-firmware-kmod
also installs gpu-firmware-intel-kmod-tigerlake-20220511.pkg
which looks like a promising start.
Trying to build graphics/drm-510-kmod
using Cirrus CI on FreeBSD 13.1-RELEASE now:
https://github.com/probonopd/drm-510-kmod-FreeBSD-13/blob/main/.cirrus.yml
What is the relationship of these ports to each other?
Are they mutually exclusive? Or do we need all of them in order to be able to support all (old and new) GPUs?
There is only a 14-CURRENT package as the builder for 13.X still run 13.0-RELEASE and we can't build drm-510-kmod there.
What is the relationship of these ports to each other?
* graphics/drm-510-kmod
This one track Linux 5.10 drm drivers (works on >=13.1)
* graphics/drm-54-kmod
This one track Linux 5.4 drm drivers (works on >= 13.0)
* graphics/drm-current-kmod * graphics/drm-devel-kmod
Both doesn't exists anymore in latest.
* graphics/drm-fbsd12.0-kmod
Specific drm-kmod for 12.X, track 4.16, not updated anymore (for quite some time).
* graphics/drm-fbsd13-kmod
Specific port for FreeBSD 13.X (will be deleted when 13.0 is EoL)
* graphics/drm-kmod
Meta port that will Do The Right Thing (tm), meaning installing a supported version of the drivers based on the release and installing all the firmwares.
Are they mutually exclusive? Or do we need all of them in order to be able to support all (old and new) GPUs?
They are mutually exclusive, you need one to have support for your GPU, graphics/drm-kmod again should do the right thing based on your OSVERSION. Not sure what you mean by "old and new".
Let me know if you need more info :)
Thanks for your explanations @evadot, very helpful :+1:
They are mutually exclusive, you need one to have support for your GPU, graphics/drm-kmod again should do the right thing based on your OSVERSION. Not sure what you mean by "old and new".
On helloSystem we want to support all GPUs from the oldest GPUs to the newest GPUs. In the case on Nvidia, this means that we need to ship Nvidia drivers 304, 340, and 390, and pick the one that is needed by the GPU in a particular system at runtime. My question is whether we need to do similar things for the different versions of graphics/drm-...kmod.
There is only a 14-CURRENT package as the builder for 13.X still run 13.0-RELEASE and we can't build drm-510-kmod there.
(Semi-OT) That's probably the same underlying reason why Intel GPUs are broken on 13.1 until 13.0 is deprecated. In practice this means unless we start to build our own packages for helloSystem (which we'd like to avoid), we are practically stalled for 2 quarters after 13.1 comes out until we can do a 13.1 based helloSystem release. I wish this could be solved somehow, e.g., by having builders for 13.0 and 13.1 at the same time.
Thanks for your explanations @evadot, very helpful +1
They are mutually exclusive, you need one to have support for your GPU, graphics/drm-kmod again should do the right thing based on your OSVERSION. Not sure what you mean by "old and new".
On helloSystem we want to support all GPUs from the oldest GPUs to the newest GPUs. In the case on Nvidia, this means that we need to ship Nvidia drivers 304, 340, and 390, and pick the one that is needed by the GPU in a particular system at runtime. My question is whether we need to do similar things for the different versions of graphics/drm-...kmod.
All drm-*-kmod support intel, amd and radeon GPUs. There is some difference of what is supported of course (Like in Linux based on the kernel version).
There is only a 14-CURRENT package as the builder for 13.X still run 13.0-RELEASE and we can't build drm-510-kmod there.
(Semi-OT) That's probably the same underlying reason why Intel GPUs are broken on 13.1 until 13.0 is deprecated.
It's not broken. 13.1 just support more recent intel GPUs.
In practice this means unless we start to build our own packages for helloSystem (which we'd like to avoid), we are practically stalled for 2 quarters after 13.1 comes out until we can do a 13.1 based helloSystem release.
I wish this could be solved somehow, e.g., by having builders for 13.0 and 13.1 at the same time.
This is a recurring demand that some people have and some other people are working on that.
I wish this could be solved somehow, e.g., by having builders for 13.0 and 13.1 at the same time.
This is a recurring demand that some people have and some other people are working on that.
That's great to hear!
Looks like I succeeded to build drm-510-kmod
on Cirrus CI but building helloSystem ISOs fails today due to the dreaded issue that FreeBSD packages that were there in quarterly yesterday can apparently be missing today.
Blocked by:
We now have an ISO that contains drm-510-kmod
but on Tiger Lake with a HDMI display attached over a USB-3 hub (that supports DP altmode), it still hangs with (as we can see in verbose mode):
initgfx: Creating new configuration....
initgfx: Auto-detecting graphics driver...
To debug:
When we press backspace at early boot to get to the bootloader OK
prompt, then boot with
unset boot_mute
set initgfx.detect.disable=1
boot
then we can boot to the desktop, from where we can switch to a console with Ctrl+Alt+F2, where we can log in as the user liveuser
and no password. There we can do sudo service slim stop
which stops Xorg. We can then return to the console with Ctrl+Alt+F2, enter
sudo cp /etc/rc.d/initgfx .
sudo nano initgfx # Change "initgfx.detect.disable"
sudo sh -x ./initgfx start
We see that the last thing that happens is
kdload /boot/modules/i915kms.so
Then it just hangs.
When we reboot and run sudo kldload -v /boot/modules/i915kms.so
manually, it also immediately hangs the system without any further information.
How to debug this further?
Notes
Next debugging step: Kernel dump https://docs.freebsd.org/en/books/developers-handbook/kerneldebug/? Would that help @evadot? Or how else could we debug this further?
On a 14.0-CURRENT based ISO with drm-510-kmod
from FreeBSD Packages, the screen goes black after
initgfx: Creating new configuration....
initgfx: Auto-detecting graphics driver...
(unlike what we get with 13.1-RELEASE and self-built drm-510-kmod
where it just hangs without the screen going black).
If we boot with initgfx.detect.disable=1
and then run sudo kldload /boot/modules/i915kms.ko
while we have tail -fn300 /var/log/messages
running in another terminal, we can see:
Jul 10 10:45:03 Laptop kernel: iic0: <I2C generic I/O> on iicbus0
Jul 10 10:45:03 Laptop kernel: iic1: <I2C generic I/O> on iicbus1
Jul 10 10:45:03 Laptop kernel: iic2: <I2C generic I/O> on iicbus2
Jul 10 10:45:04 Laptop kernel: drmn0: <drmn> on vgapci0
Jul 10 10:45:04 Laptop kernel: vgapci0: child drmn0 requested pci_enable_io
Jul 10 10:45:04 Laptop syslogd: last message repeated 1 times
Jul 10 10:45:04 Laptop kernel: [drm] Unable to create a private tmpfs mount, hugepage support will be disabled(-19).
Jul 10 10:45:04 Laptop kernel: [drm] Got stolen memory base 0x0, size 0x0
Jul 10 10:45:04 Laptop kernel: drmn0: [drm] Number of memory channels is zero
Jul 10 10:45:04 Laptop kernel: lkpi_iic0: <LinuxKPI I2C> on drmn0
Jul 10 10:45:04 Laptop kernel: iicbus3: <Philips I2C bus> on lkpi_iic0
Jul 10 10:45:04 Laptop kernel: iic3: <I2C generic I/O> on iicbus3
Jul 10 10:45:04 Laptop kernel: lkpi_iic1: <LinuxKPI I2C> on drmn0
Jul 10 10:45:04 Laptop kernel: iicbus4: <Philips I2C bus> on lkpi_iic1
Jul 10 10:45:04 Laptop kernel: iic4: <I2C generic I/O> on iicbus4
Jul 10 10:45:04 Laptop kernel: lkpi_iic2: <LinuxKPI I2C> on drmn0
Jul 10 10:45:04 Laptop kernel: iicbus5: <Philips I2C bus> on lkpi_iic2
Jul 10 10:45:04 Laptop kernel: iic5: <I2C generic I/O> on iicbus5
Jul 10 10:45:04 Laptop kernel: lkpi_iic3: <LinuxKPI I2C> on drmn0
Jul 10 10:45:04 Laptop kernel: iicbus6: <Philips I2C bus> on lkpi_iic3
Jul 10 10:45:04 Laptop kernel: iic6: <I2C generic I/O> on iicbus6
Jul 10 10:45:04 Laptop kernel: lkpi_iic4: <LinuxKPI I2C> on drmn0
Jul 10 10:45:04 Laptop kernel: iicbus7: <Philips I2C bus> on lkpi_iic4
Jul 10 10:45:04 Laptop kernel: iic7: <I2C generic I/O> on iicbus7
Jul 10 10:45:04 Laptop kernel: lkpi_iic5: <LinuxKPI I2C> on drmn0
Jul 10 10:45:04 Laptop kernel: iicbus8: <Philips I2C bus> on lkpi_iic5
Jul 10 10:45:04 Laptop kernel: iic8: <I2C generic I/O> on iicbus8
Jul 10 10:45:04 Laptop kernel: lkpi_iic6: <LinuxKPI I2C> on drmn0
Jul 10 10:45:04 Laptop kernel: iicbus9: <Philips I2C bus> on lkpi_iic6
Jul 10 10:45:04 Laptop kernel: iic9: <I2C generic I/O> on iicbus9
Jul 10 10:45:04 Laptop kernel: lkpi_iic7: <LinuxKPI I2C> on drmn0
Jul 10 10:45:04 Laptop kernel: iicbus10: <Philips I2C bus> on lkpi_iic7
Jul 10 10:45:04 Laptop kernel: iic10: <I2C generic I/O> on iicbus10
Jul 10 10:45:04 Laptop kernel: lkpi_iic8: <LinuxKPI I2C> on drmn0
Jul 10 10:45:04 Laptop kernel: iicbus11: <Philips I2C bus> on lkpi_iic8
Jul 10 10:45:04 Laptop kernel: iic11: <I2C generic I/O> on iicbus11
Jul 10 10:45:04 Laptop kernel: drmn0: successfully loaded firmware image 'i915/tgl_dmc_ver2_08.bin'
Jul 10 10:45:04 Laptop kernel: drmn0: [drm] Finished loading DMC firmware i915/tgl_dmc_ver2_08.bin (v2.8)
Jul 10 10:45:04 Laptop kernel: drmn0: [drm] failed to retrieve link info, disabling eDP
Jul 10 10:45:04 Laptop kernel: sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)!
Jul 10 10:45:04 Laptop kernel: lkpi_iic9: <LinuxKPI I2C> on drm1
Jul 10 10:45:04 Laptop kernel: iicbus12: <Philips I2C bus> on lkpi_iic9
Jul 10 10:45:04 Laptop kernel: iic12: <I2C generic I/O> on iicbus12
Jul 10 10:45:04 Laptop kernel: lkpi_iic10: <LinuxKPI I2C> on drm2
Jul 10 10:45:04 Laptop kernel: iicbus13: <Philips I2C bus> on lkpi_iic10
Jul 10 10:45:04 Laptop kernel: iic13: <I2C generic I/O> on iicbus13
Jul 10 10:45:04 Laptop kernel: lkpi_iic11: <LinuxKPI I2C> on drm3
Jul 10 10:45:04 Laptop kernel: iicbus14: <Philips I2C bus> on lkpi_iic11
Jul 10 10:45:04 Laptop kernel: iic14: <I2C generic I/O> on iicbus14
Jul 10 10:45:04 Laptop kernel: lkpi_iic12: <LinuxKPI I2C> on drm4
Jul 10 10:45:04 Laptop kernel: iicbus15: <Philips I2C bus> on lkpi_iic12
Jul 10 10:45:04 Laptop kernel: iic15: <I2C generic I/O> on iicbus15
Jul 10 10:45:04 Laptop kernel: [drm] Initialized i915 1.6.0 20200917 for drmn0 on minor 0
Jul 10 10:45:04 Laptop kernel: drmn0: [drm] Cannot find any crtc or sizes
Jul 10 10:45:04 Laptop kernel: lkpi_iic13: <LinuxKPI I2C> on drmn0
Jul 10 10:45:04 Laptop kernel: iicbus16: <Philips I2C bus> on lkpi_iic13
Jul 10 10:45:04 Laptop kernel: iic16: <I2C generic I/O> on iicbus16
Jul 10 10:45:05 Laptop kernel: VT: Replacing driver "efifb" with new "fb".
Jul 10 10:45:05 Laptop kernel: start FB_INFO:
Jul 10 10:45:05 Laptop kernel: type=11 height=1080 width=1920 depth=32
Jul 10 10:45:05 Laptop kernel: pbase=0x4000040000 vbase=0xfffffe00d4840000
Jul 10 10:45:05 Laptop kernel: name=drmn0 flags=0x0 stride=7680 bpp=32
Jul 10 10:45:05 Laptop kernel: end FB_INFO
Random thought, could it be that if we use a self-built drm-510-kmod
, then we also need to use a newer libdrm
than what is in FreeBSD Packages?
No, libdrm is only for userland. It might be good to test FreeBSD directly on your system, I don't have a tigerlake system myself but others have successfully used drm-kmod on it.
others have successfully used drm-kmod on it
Yes (in fact I have), see the Notes in https://github.com/helloSystem/ISO/issues/388#issuecomment-1179225257
It might be good to test FreeBSD directly on your system
What do you mean? Would it help if I could give you ssh access to the machine?
others have successfully used drm-kmod on it
Yes (in fact I have), see the Notes in #388 (comment)
It might be good to test FreeBSD directly on your system
What do you mean? Would it help if I could give you ssh access to the machine?
I mean testing directly FreeBSD 14-CURRENT, not hellosystem. Also test without external screen and different configuration to narrow the problem down.
Also test without external screen and different configuration to narrow the problem down.
Thing is, it seems to be working with the screen built into the Framework Laptop. But since I only have the "naked" Framework Mainboard I can only attach an external screen (via a USB-C dock with DP altmode).
So, on ravynOS 0.4.0pre4 (where it is working), FreeBSD 14 is used with drm-devel-kmod
using drm-kmod-drm_v5.5.19_7
. Also, I see the message drmn0: failed to load DMC firmware i915/tgl_dmc_ver2_04.bin. Disabling runtime power management.
(unrelated?) there.
However, drm-devel-kmod
is no longer in Ports so I can't build that for helloSystem...
Got it to work with some manual intervention.
drm-510-kmod
from FreeBSD Packages OK
prompt, then boot withunset boot_mute
set initgfx.detect.disable=1
boot
liveuser
and no password. sudo service slim stop
which stops Xorgsudo cp /etc/rc.d/initgfx .
sudo nano initgfx # Change "initgfx.detect.disable"
sudo sh -x ./initgfx start
service slim start
We now have an experimental build with a working HDMI display attached over a USB-3 hub (that supports DP altmode). Even HDMI audio works. :+1:
However, it does not work without manual intervention. When one just boots normal (without the procedure above), then the screen just goes black after initgfx: Auto-detecting graphics driver...
. Why? Maybe initgfx
is running into some race condition/timing conflict?
cc @mrclksr
As of today, drm-510-kmod
has disappeared from packages for FreeBSD 14 and the old build is no longer downloadable.
https://portsfallout.com/fallout?port=graphics%2Fdrm-510-kmod%24 is full of build errors.
cc @evadot
The manual procedure described 2 posts above does not work in FreeBSD 13.1; it seems like drm-510-kmod
does not work there? So the Intel TigerLake-LP GT2 [Iris Xe Graphics] GPU over DP altmode requires FreeBSD 14, or is this a bug?
drm-510-kmod works fine on 13.1, what's your problem ?
Hello @evadot,
do you know whether HDMI over USB3 DP altmode should be working on FreeBSD 13.1 on the Iris Xe Graphics (11th Gen Intel® Core™)? Has it been tested successfully?
When I follow those exact steps on FreeBSD 14, it works. The same steps on 13.1 lead to a garbled screen for a split-second, then the screen just goes black (no signal). I am using a Framework Mainboard (11th Gen Intel® Core™) connected to a HDMI screen over a USB3 dock that supports DP altmode (as can be determined by the fact that it is advertised as supporting 60Hz in 4K).
Notes
Is there anything I could do to help debug this?
kldload /boot/modules/i915kms.kmod
makes the screen go black (no signal), but the machine is still running at that point and can be accessed via ssh. dmesg
then shows:
drmn0: <drmn> on vgapci0
vgapci0: child drmn0 requested pci_enable_io
vgapci0: child drmn0 requested pci_enable_io
[drm] Unable to create a private tmpfs mount, hugepage support will be disabled(-19).
[drm] Got stolen memory base 0x0, size 0x0
drmn0: [drm] Number of memory channels is zero
drmn0: successfully loaded firmware image 'i915/tgl_dmc_ver2_08.bin'
drmn0: [drm] Finished loading DMC firmware i915/tgl_dmc_ver2_08.bin (v2.8)
drmn0: [drm] failed to retrieve link info, disabling eDP
sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)!
[drm] Initialized i915 1.6.0 20200917 for drmn0 on minor 0
drmn0: [drm] Cannot find any crtc or sizes
VT: Replacing driver "efifb" with new "fb".
start FB_INFO:
type=11 height=1080 width=1920 depth=32
pbase=0x4000040000 vbase=0xfffffe00da440000
name=drmn0 flags=0x0 stride=7680 bpp=32
end FB_INFO
drmn0: [drm] *ERROR* Link Training Unsuccessful
drmn0: [drm] *ERROR* Link Training Unsuccessful
drmn0: [drm] *ERROR* Link Training Unsuccessful
drmn0: [drm] *ERROR* Link Training Unsuccessful
drmn0: [drm] *ERROR* Link Training Unsuccessful
drmn0: [drm] *ERROR* Link Training Unsuccessful
drmn0: [drm] *ERROR* Link Training Unsuccessful
drmn0: [drm] *ERROR* Link Training Unsuccessful
pid 1997 (cron), jid 0, uid 0: exited on signal 10
Second try
drmn0: <drmn> on vgapci0
vgapci0: child drmn0 requested pci_enable_io
vgapci0: child drmn0 requested pci_enable_io
[drm] Unable to create a private tmpfs mount, hugepage support will be disabled(-19).
[drm] Got stolen memory base 0x0, size 0x0
drmn0: [drm] Number of memory channels is zero
drmn0: successfully loaded firmware image 'i915/tgl_dmc_ver2_08.bin'
drmn0: [drm] Finished loading DMC firmware i915/tgl_dmc_ver2_08.bin (v2.8)
drmn0: [drm] failed to retrieve link info, disabling eDP
sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)!
[drm] Initialized i915 1.6.0 20200917 for drmn0 on minor 0
drmn0: [drm] Cannot find any crtc or sizes
drmn0: [drm] Cannot find any crtc or sizes
Could possibly be related to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263761, which is still open.
Searching for type=11 height=1080 width=1920 depth=32
leads to
https://github.com/freebsd/drm-kmod/issues/162
which leads to
https://cgit.freebsd.org/src/commit/?id=3cbf6518d6eea08e0fbe6d7c609debac5ab31992
Coud that be the culprit here?
https://xyinn.org/md/freebsd/framework_laptop describes this exact issue:
The HDMI Expansion card is detected but I can't output anything to it even though xrandr detected the DP-3 port. The supported resolutions detected in xrandr for this display are also incorrect. The same monitor works via the Anker Dongle through its HDMI slot with the correct resolution. I also saw this error which didn't appear when using the Anker dongle's HDMI port without the HDMI expansion card connected: [drm ERROR :intel_dp_get_link_train_fallback_values] Link Training Unsuccessful.
@evadot respectfully pinging you again.
Possibly related to https://github.com/freebsd/drm-kmod/issues/223?
This is a FreeBSD bug for this exact situation: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263761
For the record: A 4K@30Hz compatible USB3 to HDMI adapter does not have this issue. The issue is only with 4k@60Hz compatible HDMI adapters.
With a 4K@30Hz compatible USB3 to HDMI adapter I get:
drmn0: <drmn> on vgapci0
vgapci0: child drmn0 requested pci_enable_io
vgapci0: child drmn0 requested pci_enable_io
[drm] Unable to create a private tmpfs mount, hugepage support will be disabled(-19).
[drm] Got stolen memory base 0x0, size 0x0
drmn0: successfully loaded firmware image 'i915/tgl_dmc_ver2_08.bin'
drmn0: [drm] Finished loading DMC firmware i915/tgl_dmc_ver2_08.bin (v2.8)
drmn0: [drm] failed to retrieve link info, disabling eDP
sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)!
[drm] Initialized i915 1.6.0 20200917 for drmn0 on minor 0
VT: Replacing driver "efifb" with new "fb".
start FB_INFO:
type=11 height=1080 width=1920 depth=32
pbase=0x4000040000 vbase=0xfffffe0113c40000
name=drmn0 flags=0x0 stride=7680 bpp=32
end FB_INFO
Jun 18 18:13:03 Users-Laptop kernel: drmn0: <drmn> on vgapci0
Jun 18 18:13:03 Users-Laptop kernel: vgapci0: child drmn0 requested pci_enable_io
Jun 18 18:13:03 Users-Laptop syslogd: last message repeated 1 times
Jun 18 18:13:03 Users-Laptop kernel: [drm] Unable to create a private tmpfs mount, hugepage support will be disabled(-19).
Jun 18 18:13:03 Users-Laptop kernel: [drm] Got stolen memory base 0x0, size 0x0
Jun 18 18:13:03 Users-Laptop kernel: drmn0: successfully loaded firmware image 'i915/tgl_dmc_ver2_08.bin'
Jun 18 18:13:03 Users-Laptop kernel: drmn0: [drm] Finished loading DMC firmware i915/tgl_dmc_ver2_08.bin (v2.8)
Jun 18 18:13:03 Users-Laptop kernel: drmn0: [drm] failed to retrieve link info, disabling eDP
I suspect the last line to be related to the issue: drmn0: [drm] failed to retrieve link info, disabling eDP
.
How to further debug this?
Update 02/2023: Intel TigerLake-LP GT2 [Iris Xe Graphics] works, can be used e.g., using 4k@30Hz USB3 HDMI adapters (e.g., containing Chrontel's CH7213) but can currently not be used with Framework's HDMI adapter or any other 4k@60Hz USB3 HDMI adapter. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263761 is blocking this.
Get Intel TigerLake-LP GT2 [Iris Xe Graphics]
8086:9a49:f111:0001
GPU recognized and working properly.On helloSystem 0.7.0
initgfx
just hangs in the detection phase. Tested on a Framework Mainboard with the 11th Gen Intel® Core™ i5-1135G7 @ 2.40GHz and a HDMI display attached over a USB-3 hub (that supports DP altmode). As a workaround, one needs to start withset initgfx.detect.disable=1
as described here.According to the FreeBSD wiki, "Requires DRM-KMOD 5.5 or higher. Fails to initialize with DRM-KMOD 5.4". At the time of this writing,
drm-fbsd13-kmod
5.5 is not yet available, https://www.freshports.org/graphics/drm-fbsd13-kmod. On e.g., Ubuntu 21.10, thei915
driver is used. Why is it that on older Linux versions just happily use thei915
driver whereas on FreeBSD we need to wait for something to be updated?