FreeBSD / amdgpu / Vega 3, pstate TEST_DEBUG_DATA: 0x0

Mon Apr 27 20:50:07 UTC 2020

On 2020-04-27 4:43 p.m., Andriy Gapon wrote:
> On 24/04/2020 20:22, Harry Wentland wrote:
>> On 2020-04-24 8:34 a.m., Andriy Gapon wrote:
>>>
>>> First, I understand that my platform is not directly supported and probably not
>>> very interesting, but I still hope to get some tips or pointers.
>>>
>>
>> Hi Andriy,
>>
>> yeah, limited insight here since FreeBSD isn't something I'm familiar
>> with. :)
> 
> Harry,
> 
> thanks a lot for your help.  It set me on a right path, although a bit
> indirectly :-)
> 
> Let me start by saying that I was able to fix the driver.
> 
> After looking at the laptop in a dark room I could see that the backlight was
> actually on, but there was no video output.
> 
> So, I went back to comparing FreeBSD and Linux logs, especially around the place
> where "TEST_DEBUG_DATA: 0x0" was reported.  And then suddenly I spotted what I
> missed before.  Linux reported 3 pipes while FreeBSD reported 4.  And the errors
> were about the forth, non-existent, pipe -- I guess, not surprising at all.
> With some additional printfs I could confirm it for sure.  So, then I looked for
> the code where the number of pipes is set and almost immediately could see the
> problem.
> 
> FreeBSD amdgpu has DCN_VERSION_1_01 support ifdef-ed out, for whatever reason.
> Your commit "drm/amd/display: Drop DCN1_01 guards" has not been ported yet and
> CONFIG_DRM_AMD_DC_DCN1_01 is not defined.  Of course, the number of pipes was
> not the only thing that did not match the actual hardware/firmware because of
> that.  Once I set CONFIG_DRM_AMD_DC_DCN1_01 everything just worked.
> 
> Thank you again!
> 

Awesome. Glad my comment helped and glad you found the problem.

Harry

>>> I am trying to get amdgpu/FreeBSD going on Motile M141 laptop with Ryzen 3 3200U
>>> CPU that has Vega 3 graphics integrated.  When amdgpu starts loading the screen
>>> goes black and never lights up again.  I am not sure whether there is no signal
>>> at all or whether the backlight is turned off, but the screen is completely
>>> dark.  I can blindly interact with the system, so it's not crashed or hung.
>>> From system logs I can see that the driver attaches successfully.  It recognizes
>>> the hardware, loads its firmware, detects the eDP screen and so on.
>>>
>>
>> Does BSD have a way to check or set your backlight value manually (a la
>> /sys/class/backlight on linux)? If so I'd suggest checking and setting
>> it to non-zero values, ideally to max_brightness.
>>
>> Have you tried an external display?
>>
>>> The FreeBSD's amdgpu port that I am trying is based on code circa 5.0.
>>> There is no newer version ported.
>>> I tried a couple of Linux distros with 5.3.x kernels and they worked without any
>>> problems. So that gives me some hope.
>>>
>>> I compared driver messages (with drm_debug set to 0xfff) between Linux and
>>> FreeBSD and they look quite similar.  Except for one thing.
>>> In the FreeBSD case there are these error messages that are not seen with Linux:
>>>
>>> [drm] pstate TEST_DEBUG_DATA: 0x0
>>> WARNING !(0) failed at
>>> /usr/home/avg/devel/kms-drm/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c:868
>>> #0 0xffffffff83451633 at linux_dump_stack+0x23
>>> #1 0xffffffff8325a9ee at dcn10_verify_allow_pstate_change_high+0x4e
>>> #2 0xffffffff8325e925 at dcn10_wait_for_mpcc_disconnect+0x25
>>> #3 0xffffffff8325de53 at dcn10_disable_plane+0x53
>>> #4 0xffffffff8325c9f5 at dcn10_init_hw+0x755
>>> #5 0xffffffff83295ca8 at dc_create+0x538
>>> #6 0xffffffff8327a8da at dm_hw_init+0x1ea
>>> #7 0xffffffff831701d1 at amdgpu_device_init+0x1b11
>>> #8 0xffffffff83185177 at amdgpu_driver_load_kms+0xd7
>>> #9 0xffffffff833f138e at drm_dev_register+0x17e
>>> #10 0xffffffff83178dea at amdgpu_pci_probe+0x18a
>>> #11 0xffffffff83456f40 at linux_pci_attach+0x560
>>> #12 0xffffffff80bf68ea at device_attach+0x3ca
>>> #13 0xffffffff80bf6490 at device_probe_and_attach+0x70
>>> #14 0xffffffff80bf8358 at bus_generic_driver_added+0x58
>>> #15 0xffffffff80bf4289 at devclass_driver_added+0x39
>>> #16 0xffffffff80bf41c7 at devclass_add_driver+0x147
>>> #17 0xffffffff83455ae9 at _linux_pci_register_driver+0xc9
>>>
>>> That warning plus stack trace is actually BREAK_TO_DEBUGGER() in the original
>>> Linux code.
>>> So, that makes me think that the problem is pretty serious.
>>
>> BREAK_TO_DEBUGGER is probably overly scary here. It's somewhat a concern
>> as this means power consumption might be higher than expected. We've
>> seen this issue on several systems without any other adverse effects to
>> usability.
>>
>> Harry
>>
>>> I tried searching for "TEST_DEBUG_DATA: 0x0" and I could not find a single
>>> result with "0x0" in it.  Usually there is some non-zero value.
>>> To me this looks like maybe some hardware component is not turned on...
>>> Perhaps this is something relatively obvious for people that hack on the driver
>>> and the hardware.
>>> I hope to receive some hint about what to look for.
>>> I can cherry-pick commits from Linux, apply patches, add additional debugging
>>> logs, etc.
>>>
>>> FreeBSD amdgpu dmesg: https://people.freebsd.org/~avg/amdgpu.dmesg.txt
>>> Full Linux dmesg: https://people.freebsd.org/~avg/linux-5.3.0-28.dmesg.out
>>>
>>> And with with drm_debug=0xfff.
>>> FreeBSD: https://people.freebsd.org/~avg/fbsd-dmesg.txt
>>> Linux: https://people.freebsd.org/~avg/linux-5.3.9-dmesg.txt
>>>
>>> I see that both Linux and FreeBSD have similar messages about failing to load
>>> some microcode components, but I guess that it must be okay since Linux works:
>>> [    4.487381] [drm] reserve 0x400000 from 0xf400c00000 for PSP TMR
>>> [    4.564893] [drm] failed to load ucode id (12)
>>> [    4.564894] [drm] psp command failed and response status is (-53233)
>>> [    4.567891] [drm] failed to load ucode id (13)
>>> [    4.567892] [drm] psp command failed and response status is (-65521)
>>> [    4.570891] [drm] failed to load ucode id (14)
>>> [    4.570892] [drm] psp command failed and response status is (-65521)
> 
> 
> 