<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - vram sizes reported by the kernel totally off" href="https://bugs.freedesktop.org/show_bug.cgi?id=106872#c1">Comment # 1</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - vram sizes reported by the kernel totally off" href="https://bugs.freedesktop.org/show_bug.cgi?id=106872">bug 106872</a> from <a class="email" href="mailto:michel@daenzer.net" title="Michel Dänzer <michel@daenzer.net>"> Michel Dänzer</a> <pre>Please attach the dmesg output from the affected system, preferably captured while or after the problem occurs. (In reply to Bas Nieuwenhuizen from <a href="show_bug.cgi?id=106872#c0">comment #0</a>) > 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 > 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 such BOs can still end up pinned at least partially in CPU visible VRAM, which would 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>