[Bug 101387] amdgpu display corruption and hang on AMD A10-9620P

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=101387

--- Comment #8 from Carlo Caione <carlo at caione.org> ---
Just a better description of what's going on and a couple of questions.

When amdgpu_atombios_crtc_powergate_init() is called this triggers the parsing
of the command table with index == 13 (>> execute C5C0 (len 589, WS 0, PS 0)).
As already reported the parameter space used (struct
ENABLE_DISP_POWER_GATING_PARAMETERS_V2_1) is 32 bytes wide.

During the execution of this table several CALL_TABLE (op == 82) are executed. 

In particular we first just to table with index == 78 (>> execute F166 (len
588, WS 0, PS 8)), then to table with index == 51 (>> execute F446 (len 465, WS
4, PS 4)) and finally to table with index == 75 (>> execute F6CC (len 1330, WS
4, PS 0)) before finally reaching the EOT for table 13.

During the execution of table 75 a MOVE_PS is executed with a destination index
== 1, accessing ctx->ps[idx] and causing the stack corruption.

So either the atombios code is wrong or the atombios interpreter in the kernel
is doing something wrong.

I also have a couple of questions / observations:

1) Table 75 has WS == 4 and PS == 0 and looking at the opcodes in the table I
basically have only *_WS opcodes (MOVE_WS, TEST_WS, ADD_WS, etc...) and just
two *_PS instructions (MOVE_PS and OR_PS) that (guess what) are the
instructions causing the stack corruption. My guess here is that the opcodes
*_PS in the atombios are wrong and they should actually be *_WS opcodes.

2) Don't we need to allocate the size of the ps allocation struct for the
command table we are going to execute after a CALL_TABLE matching the ps size
in the table header? IIUC the code in the kernel, when we are jumping to a
different table ctx->ps is not being reallocated.

3) Could the point at (2) also be a problem in our case? Assuming that ps read
from the table header has something to do with the size of the parameter space
(guessing here) Table 13 has PS == 0, while table 75 has PS == 4 whereas both
are using the same ctx->ps.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170614/9530850e/attachment.html>