| Summary: | [HadesCanyon/regression] GPU hang causes also X server to die | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Eero Tamminen <eero.t.tamminen> | ||||||
| Component: | DRM/AMDgpu | Assignee: | Default DRI bug account <dri-devel> | ||||||
| Status: | RESOLVED MOVED | QA Contact: | |||||||
| Severity: | critical | ||||||||
| Priority: | not set | ||||||||
| Version: | DRI git | ||||||||
| Hardware: | x86-64 (AMD64) | ||||||||
| OS: | Linux (All) | ||||||||
| See Also: | https://bugs.freedesktop.org/show_bug.cgi?id=108898 | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | i915 features: | ||||||||
| Attachments: |
|
||||||||
|
Description
Eero Tamminen
2019-11-07 13:53:19 UTC
Please attach your dmesg output and xorg log is using X. Please note that after a GPU reset, in most cases you need to restart your desktop environment because no desktop environments properly handle the loss of their contexts at the moment. Created attachment 145908 [details]
dmesg
(In reply to Alex Deucher from comment #1) > Please attach your dmesg output and xorg log is using X. Please note that > after a GPU reset, in most cases you need to restart your desktop > environment because no desktop environments properly handle the loss of > their contexts at the moment. Failed tests complain about the invalid MIT-MAGIC-COOKIE-1, so it seems that later failures are because X went down (and came back up with display manager). AFAIK reset should affect only the context running in the GPU when it was reseted, not the others [1], and in this case the problematic client should be GfxBench (Manhattan test-case, see bug 108898), not X server. Btw. Why AMD kernel module doesn't tell which process / context had the issue, like i915 does? [1] At least that's the case with i915, as long as the whole system doesn't hang. (In reply to Eero Tamminen from comment #0) > * If latest Mesa is used with drm-tip kernel 5.3, 4/5 times X fails to > start. This started to happen with Mesa version within couple of days of > the GPU hang recovery issue, so potentially there are more issue in Mesa > (HadesCanyon) AMD support Correction. That issue happens only when using latest Mesa with few months old X server and (5.3) drm-tip kernel. If latest git versions of all are used, X starts fine. But since the indicated date, it dies later, when Manhattan test-case causes problems. Created attachment 145909 [details]
Xorg log
X dies to ConfigureWindow() -> miResizeWindow() -> miCopyRegion() -> glamor_create_pixmap() -> radeonsi_dri.so -> abort().
Lightdm log show abort to be:
X: src/gallium/winsys/amdgpu/drm/amdgpu_cs.c:1061: amdgpu_cs_check_space: Assertion `rcs->current.cdw <= rcs->current.max_dw' failed.
This is the same abort that causes X server to fail at boot with git Mesa and a bit older X server & drm-tip kernel.
Is above abort due to something on the kernel side, or Mesa issue?
(In reply to Eero Tamminen from comment #3) > > AFAIK reset should affect only the context running in the GPU when it was > reseted, not the others [1], and in this case the problematic client should > be GfxBench (Manhattan test-case, see bug 108898), not X server. > > Btw. Why AMD kernel module doesn't tell which process / context had the > issue, like i915 does? It does, but in the case of a whole GPU reset, vram is lost after a reset so the buffers from all processes that use the GPU are lost. Depending on the nature of the hang, a whole GPU reset may be required rather than just killing the shader wave. -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/951. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.