| Bug ID | 106872 |
|---|---|
| Summary | vram sizes reported by the kernel totally off |
| Product | DRI |
| Version | unspecified |
| Hardware | Other |
| OS | All |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | DRM/AMDgpu |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | bas@basnieuwenhuizen.nl |
With Pierre-Loup's desktop we have an issue where the reported= VRAM and CPU visible VRAM are totally off. e.g. the last report we had kernel reported total VRAM size of 0xfffffffb3070f000 (16.0 EiB) and a visible VRAM size of 0x86135000 (2.09 G= iB). The system is a large aperture system, so expected is ~8 GiB for both, and = it is most of the time. The system typically boots in a good state and eventua= lly after a while transitions to a bad state and sometimes it transitions back. We have not been able to find a pattern and on one of the earlier cases the debugfs vram_mm file reported reasonable size & utilization. The kernels that have been tried include amd-staging-drm-next and a released kernel (need to look up whether it was 4.15 or 4.16 if that information is needed)
Please attach the dmesg output from the affected system, prefe= rably captured while or after the problem occurs. (In reply to Bas Nieuwenhuizen from comment #0) > e.g. the last report we had kernel reported tota= l VRAM size of > 0xfffffffb3070f000 (16.0 EiB) and a visible VRAM size of 0x86135000 (2= .09 > GiB). Not the other way around? One potential issue I can see is that only BOs with AMDGPU_GEM_CREATE_NO_CPU_ACCESS are accounted for invisible_pin_size. But s= uch BOs can still end up pinned at least partially in CPU visible VRAM, which w= ould mess up the calculation of how much visible VRAM currently isn't pinned. One possible solution for this would be for amdgpu_bo_pin_restricted and amdgpu_bo_unpin to walk the list of memory nodes and calculate exactly how = much of each of them lies in visible or invisible VRAM.
(In reply to Michel D=C3=A4nzer from comment #1) > One possible solution for this would be for amdg= pu_bo_pin_restricted and > amdgpu_bo_unpin to walk the list of memory nodes and calculate exactly= how > much of each of them lies in visible or invisible VRAM. We actually have a helper for that in amdgpu_vram_mgr_vis_size(). Apart from that if the problem only occurse after a certain time it looks l= ike we have a mismatch between adding the pinned size and subtracting it again.= Or alternatively some sort of memory corruption. Have you tried running it with KASAN enabled for a while?
| What | Removed | Added |
|---|---|---|
| Status | NEW | ASSIGNED |
| Assignee | dri-devel@lists.freedesktop.org | michel@daenzer.net |
Created attachment 140160 [details] [review] drm/amdgpu: Refactor amdgpu_vram_mgr_bo_sizes helper