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
 
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.
 
You must log in or register to reply here.
Back
Top