Solved Black screen on amdgpu kernel module

loureir-or-not

loureir-or-not

Hey there!

I have been toying with the 14.2 as of recent on some machines, and something which striked me is that I get a black screen when loading the amdgpu kmod.

This is known even in the errata, and there was a solution... but I still only get to a black screen even after installing drm-kmod directly from ports as the errata hinted. It is almost convincing me to go to CURRENT for the time being...

The solution did work on my laptop running a NOVIDEO+Intel laptop where loading i915kms worked fine but I am experiencing an assumingly unrelated issue after, worth it's own thread.

My hardware (on the black screening machine) is as follows:

Version is FreeBSD 14.2-STABLE (using latest branches)
CPU is an AMD Ryzen 5 2600
GPU is an AMD Radeon RX 570
This issue startedo on Linux where the GPU started turning off on boot after an SSD reinstallation.

Any relevant information will be provided if asked.
 
loureir-or-not said:
Tags are wrong, oops
Click to expand...
You can edit your tags: click on the tag-icon immediately after the date, i.e. after Today at 8:10 AM . before the tag list.

loureir-or-not said:
I have been toying with the 14.2 as of recent on some machines, and something which striked me is that I get a black screen when loading the amdgpu kmod.
Click to expand...
You're probably in need of a 14.2-RELEASE (also for recent stable/14 versions) specific version of the package graphics/drm-61-kmod
What's the output of pkg info drm-61-kmod | grep Version
 
I take it that you've build graphics/drm-kmod?
You've got the right drm-61-kmod version: 6.1.92.1402501_3

What happens when you comment out kld_list="amdgpu" in /etc/rc.conf and issue kldload amdgpu from the command line?
 
Erichans said:
I take it that you've build graphics/drm-kmod?
You've got the right drm-61-kmod version: 6.1.92.1402501_3
Click to expand...
I have, yes. I remember finding this ib the errata.

Good to know I found the right version.
Erichans said:
What happens when you comment out kld_list="amdgpu" in /etc/rc.conf and issue kldload amdgpu from the command line?
Click to expand...
Basically the same result as if I were to load it automatically. It just black screens. (Single user mode doesn't load the AMDGPU driver so I can just load it manually)
 
(If you happen to not be using latest/main for the source of ports to build drm-kmod, I sugest you try that.
I don't envision, btw, that trying -CURRENT will give you better chances because you're not running anything really new hardware.)

Hmm, your Radeon RX 570 is from 2017 (your Ryzen 5 2600 from 2018); that seems ok. Anything peculiar in dmesg -a before the kldload?

As you have a black screen and not a panic, I'm curious what firmware is being kld-loaded after kldload amdgpu; can you ssh into it and get the output (termbin) of kldstat and a dmesg -a?

Alternatively, I'd try building graphics/drm-515-kmod (that should give you Version : 5.15.160.1402000_2).

Edit: Just to be sure, with drm-61-kmod, your stable is >= 1400508? From pkg info drm-61-kmod:
Code: 
This version is for FreeBSD 14-STABLE 1400508
and above.

Try adding at the start of /boot/loader.conf:
Code: 
boot_verbose="YES"
verbose_loading="YES"
 
I quite agree with your take on drm-515-kmod; it doesn't look good to me. I don't like that its amdgpu doesn't seem to load any firmware as shown in your kldstat output.
Edit:
The kldstat output with amdgpu from drm-61-kmod doesn't look suspicious to me:
Code: 
Id Refs Address                Size Name
 1  107 0xffffffff80200000  1f3dbd8 kernel
 2    1 0xffffffff8213f000     7808 cryptodev.ko
 3    1 0xffffffff82147000   5e9340 zfs.ko
 4    1 0xffffffff83310000     3390 acpi_wmi.ko
 5    1 0xffffffff83314000     3220 intpm.ko
 6    1 0xffffffff83318000     2178 smbus.ko
 7    1 0xffffffff8331b000     3360 uhid.ko
 8    1 0xffffffff8331f000     3360 wmt.ko
 9    1 0xffffffff83323000     4364 ums.ko
10    1 0xffffffff83328000     e5b0 snd_uaudio.ko
11    1 0xffffffff83337000     2a68 mac_ntpd.ko
12    1 0xffffffff83400000   66c888 amdgpu.ko
13    2 0xffffffff8333a000    86090 drm.ko
14    1 0xffffffff833c1000     22b8 iic.ko
15    2 0xffffffff833c4000     4120 linuxkpi_video.ko
16    3 0xffffffff833c9000     7350 dmabuf.ko
17    3 0xffffffff833d1000     3378 lindebugfs.ko
18    1 0xffffffff833d5000     c338 ttm.ko
19    1 0xffffffff833e2000     a0c0 amdgpu_polaris10_mc_bin.ko
20    1 0xffffffff833ed000     6378 amdgpu_polaris10_pfp_2_bin.ko
21    1 0xffffffff833f4000     6378 amdgpu_polaris10_me_2_bin.ko
22    1 0xffffffff833fb000     4378 amdgpu_polaris10_ce_2_bin.ko
23    1 0xffffffff83a6d000     7ca0 amdgpu_polaris10_rlc_bin.ko
24    1 0xffffffff83a75000    42388 amdgpu_polaris10_mec_2_bin.ko
25    1 0xffffffff83ab8000    42388 amdgpu_polaris10_mec2_2_bin.ko
26    1 0xffffffff83afb000     5278 amdgpu_polaris10_sdma_bin.ko
27    1 0xffffffff83b01000     5278 amdgpu_polaris10_sdma1_bin.ko
28    1 0xffffffff83b07000    5db60 amdgpu_polaris10_uvd_bin.ko
29    1 0xffffffff83b65000    2ac80 amdgpu_polaris10_vce_bin.ko
30    1 0xffffffff83b90000    21da8 amdgpu_polaris10_k_smc_bin.ko
Comparing the two dmesg -a outputs: using drm-515-kmod versus drm-61-kod[/icode], (apart from a number of [drm ERROR : of the drm-515-kmod dmesg output) the dmesg output belonging to drm-61-kmod (https://termbin.com/fvsr if I'm correct) doesn't list any outright ERROR, but it doesn't seem to me a spotless load of firmware either (I'm not a graphics specialist though).

That said, I'm running out of ideas where an immediate solution is in sight. The only other stuff I can come up with is some further investigation as to where the core of the problem might lie.

Unless other suggestions towards a solution surface here, to me, the follow up option seems to be to submit a PR. As mentioned in graphics/drm-61-kmod, I think https://github.com/freebsd/drm-kmod/ is probably the best place for submitting an "issue" (a PR).

drm-61-kmod should be functioning and you can ssh remotely to see what's happening (if I understand correctly), you might do some further testing to gather more data.

You could first verify that everything works X.org wise with the ordinary scfb(4) (for UEFI boot) or vesa(4) (for BIOS boot) as mentioned in url='https://docs.freebsd.org/en/books/handbook/x11/#x-graphic-card-drivers']5.3. Graphic card drivers[/url]. Verify if this is all set up and X org is working correctly. Then I think you should try without any specifc X.org driver specified in a .conf file in /usr/local/etc/X11/xorg.conf.d/. Switch to manually kldloading amdgpu. As mentioned you'll get a black screen but, that might only be a defect that affects the proper functioning of vt(4) partly. The vt-terminal might still accept input from the keyboard properly. Blind-type startx and see if X starts and "boots" correctly. The biggest surprise would be be that you now have a fully funtioning graphical X desktop environment (don't count on it). I'm speculating but, it could be that amdgpu (the on used for kldload-ing) of drm-61-kmod only messes up the vt terminal output; that could be worthwhile information. Then, if nothing else screws up, you could then remotely access the X.org log file and termbin it here and use as an attachment to a PR.

Based on your kldstat output you seem to be using ZFS. If this is a ZFS-on-root istall and you previously had a 14.1-RELEASE you might be able to use its Boot Environment (BE) to boot into that environment if that had a workable drm-61-kmod; and use that for the moment.
 
Erichans said:
The only other stuff I can come up with is some further investigation as to where the core of the problem might lie.
Click to expand...
My suspicion is that this was caused during an SSD installation as even NixOS failed to load the VT when using modeset when it worked fine before the SSD was installed.
Erichans said:
Unless other suggestions towards a solution surface here, to me, the follow up option seems to be to submit a PR. As mentioned in graphics/drm-61-kmod, I think https://github.com/freebsd/drm-kmod/ is probably the best place for submitting an "issue" (a PR).
Click to expand...
I'll see what I can do.
Erichans said:
drm-61-kmod should be functioning and you can ssh remotely to see what's happening (if I understand correctly), you might do some further testing to gather more data.
Click to expand...
I don't really have means of SSHing so I just write stdout or stderr to a file in the home directory. Then send it to termbin.
Erichans said:
Switch to manually kldloading amdgpu. As mentioned you'll get a black screen but, that might only be a defect that affects the proper functioning of vt(4) partly. The vt-terminal might still accept input from the keyboard properly. Blind-type startx and see if X starts and "boots" correctly. The biggest surprise would be be that you now have a fully funtioning graphical X desktop environment (don't count on it).
Click to expand...
I think I tried this already and didn't grt any groundbreaking results.
Erichans said:
Based on your kldstat output you seem to be using ZFS. If this is a ZFS-on-root istall and you previously had a 14.1-RELEASE you might be able to use its Boot Environment (BE) to boot into that environment if that had a workable drm-61-kmod; and use that for the moment.
Click to expand...
I just installed FreeBSD 14.2 pure without installing any version prior to that. So unfortunately that isn't an option.
 
14.2 Graphics Fix

pkg remove drm-kmod
pkg clean
pkg autoremove
ls /usr/
ls /usr/src
git clone -b releng/14.2 --depth 1 https://git.freebsd.org/src.git /usr/src
ls /usr/ports
git clone --depth 1 https://git.freebsd.org/ports.git /usr/ports
cd /usr/ports/
git -C /usr/ports pull
make fetchindex
make search name=drm-kmod
cd /usr/ports/graphics/drm-kmod
make describe
make run-depends
MAKE_JOBS_UNSAFE=yes
make install
pkg info drm-kmod

in my case "amdgpu", if intel i915kms;
FYI : https://docs.freebsd.org/en/books/handbook/x11/

kldload amdgpu
vi /etc/rc.conf
kld_list="amdgpu"
 
This is a troubleshooting step, if this works, use it as a band-aide until a real fix comes out that works for you.

If your system runs UEFI, use the scfb driver. If it is BIOS, then use the vesa driver. Read how here: FreeBSD Handbook.
 
The issue was caused by a loose HDMI connection.

I noticed it was an issue with loose HDMI first hand when on another desktop, it had the same issue. Plugging it in properly then gave me a workiny video feed. Because of how I was moving my monitor around as of recent, I plugged it in properly on the desktop with this issue and I got a... working video feed.

Funny, I know.
 
So you might not have been able to get even the boot menu, right? In the case where drm-kmod is broken, you can enter the boot menu, it displays some logs, and eventually the screen blanks.
 
Great, if you don't mind I'm still interested in your (now 100% funtioning!) Xorg.0.log for comparison purposes.

With these troubles behind, you can mark this thread solved by selecting 'Edit thread' from the three dots drop-down menu on the top right corner of the thread and changing the title prefix to 'Solved'.
 
Hi everyone!

I'm a Linux user aiming to move to FreeBSD. I did a clean install of FreeBSD 14.2 and had the same problem as the topic starter -- my screen went black after I loaded amdgpu driver (no matter I loaded the module manually or added it to the /etc/rc.conf).

My system is Lenovo Thinkpad X13 Gen1 AMD (AMD Ryzen 4450U with integrated AMD renoir graphics).

In my case, the solution was to remove old drm-kmod and install drm-61-kmod.

To help beginners -- please find below the step-by-step guide I got from Perplexity (it worked):

```
Remove Existing drm-kmod:
First, you need to remove the currently installed drm-kmod package:
sudo pkg remove drm-kmod

Check for Residual Packages:
After removing drm-kmod, you might want to clean up any unused dependencies:
sudo pkg autoremove

Add the FreeBSD KMOD Repository:
Create a repository configuration file for the latest kmod packages:
sudo mkdir -p /usr/local/etc/pkg/repos
sudo ee /usr/local/etc/pkg/repos/FreeBSD-kmods.conf

Then, add the following content to the file:
FreeBSD-kmods {
url: "pkg+https://pkg.freebsd.org/${ABI}/kmods_latest_2",
enabled: yes,
priority: 1,
mirror_type: "srv",
signature_type: "fingerprints",
fingerprints: "/usr/share/keys/pkg"
}

Update Package Repository:
Update your package repository to ensure you can access the latest packages:
sudo pkg update

Install drm-61-kmod:
Now, you can install drm-61-kmod:
sudo pkg install drm-61-kmod

Load the Module:
After installation, load the amdgpu module (or any other relevant module) using:
sudo kldload amdgpu
```

After this step, the driver was loaded and I haven't faced the black screen issue.

I added the module to /etc/rc.conf file by executing the following command:
# sysrc kld_list+=amdgpu
 
woody_road_9 said:
Then, add the following content to the file:
FreeBSD-kmods {
url: "pkg+https://pkg.freebsd.org/${ABI}/kmods_latest_2",
enabled: yes,
priority: 1,
mirror_type: "srv",
signature_type: "fingerprints",
fingerprints: "/usr/share/keys/pkg"
}

Update Package Repository:
Update your package repository to ensure you can access the latest packages:
sudo pkg update
Click to expand...
There is a long detailed thread about this : Possible solution to the drm-kmod kernel mismatch after upgrade from Bapt
  • It is better (and was not advised) not to hardcode '2' in kmods_latest_2; use the appropriate variable.
  • While adding a priority is most likely not harmful (one may have an elaborate local package repository setup that might interfere), user experience has not shown it to be necessary. It was also not specifically advised.
  • In general it seems not necessary to explicitly donwload a specific type of graphics package like graphics/drm-61-kmod anymore. Given the appropriate 'kmods' set up and with a fresh FreeBSD install, you can use pkg install drm-kmod. However, with any previous installed 'graphics packages' (containing kernel modules) present, given an appropriate 'kmods' set up, you should be able to use the meta package graphics/drm-kmod using the 2-step pkg-upgrade way; this applies to pkg(8) v 1.21.3 at least. With pkg(8) v 2.0.x. this '2-step way with pkg-upgrade(8)' is probably not necessary anymore.
At the moment for the amd64 architecture and supported FreeBSD versions, ports-mgmt/pkg v 2.0.3/2.0.4 as a package is available on 'latest'; on 'quarterly' it is still on v 1.21.3.

pkg(8) v. 2.0.5 has been added to ports but, has not landed as yet as a package for supported versions.

Edit: Pkg v 2.0.5 is now available as package on 14.2-RELEASE-amd64-'latest'.
 
You must log in or register to reply here.
Back
Top