| Bug ID | 107623 |
|---|---|
| Summary | (4.18.3)[drm:hwss_edp_wait_for_hpd_ready [amdgpu]] *ERROR* hw= ss_edp_wait_for_hpd_ready: wait timed out! |
| Product | DRI |
| Version | unspecified |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | DRM/AMDgpu |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | jian-hong@endlessm.com |
Created att=
achment 141196 [details]
"wait timed out!" in dmesg
We have an ASUS X570ZD laptop equipped with AMD Ryzen 7 2700U with Radeon V=
ega
Mobile Gfx and NVIDIA GeForce GTX 1050 Mobile.
We tried with Linux kernel 4.18.3.
After system resumes from suspend, there is a prompted picture for a short
time, then system goes no display for a long time.
After the long time, system turns off the display's backlight. User must
presses any key to have the login screen.
The resume process is not smooth and hits the error:
[drm:hwss_edp_wait_for_hpd_ready [amdgpu]] *ERROR* hwss_edp_wait_for_hpd_re=
ady:
wait timed out!
We have the dmesg with amdgpu.dc_log=3D1 and drm.debug=3D6
It is nouveau with parameters runpm=3D0 and noaccel=3D1 as the= driver for NVIDIA GeForce GTX 1050 Mobile card.
Created attachment 1411=
97 [details]
The resume process video
Created att=
achment 141207 [details]
dmesg of boot into multi-user.target
If I boot system into "multi-user.target", then "systemctl s=
uspend" and press
key to resume. This issue is not reproduced.
Have you tried with nouveau disabled? https://askubuntu.com/questions/841876/how-to-di= sable-nouveau-kernel-driver/951892#951892
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | WORKSFORME |
This issue was detected on 4.18.3 when using a somewhat reduce= d developer config. When using our usual full distro kernel config (from Ubuntu), the i= ssue convincingly goes away. Both Jian-Hong and I looked at the differences in the config and couldn't s= pot anything obvious that would explain different behaviour. Trying to bisect g= ood and bad configs, for a while it looked like it might be CONFIG_NUMA_BALANCI= NG=3Dy and CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=3Dy but we then disproved that in further experiments. We didn't find which config option is responsible for = the different behaviour. There's probably a bug here somewhere, but as it's working on our shipped config I'll close this issue, as we need to focus our time on other issues = on this platform.
| What | Removed | Added |
|---|---|---|
| See Also | https://bugs.freedesktop.org/show_bug.cgi?id=3D110477 |