Seems an upstream issue... found this https://bugs.freedesktop.org/show_bug.cgi?id=104082 and reported my case also there. On Thu, Feb 8, 2018 at 3:43 PM, Stratos Zolotas <strzol@gmail.com> wrote:
Hello,
Although after cleaning the caches everything seems fine, I'm getting the following message from time to time on dmesg. I think it has also to do with kernel 4.15 or latest Mesa 18. I have spotted Comm: plasmashell and Comm: X on similar stack traces and the reason seems to be "coherent allocation failed for device 0000:01:00.0 size=2097152".
[ 5440.788265] amdgpu 0000:01:00.0: swiotlb buffer is full (sz: 2097152 bytes) [ 5440.788267] swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152 [ 5440.788270] CPU: 5 PID: 1979 Comm: plasmashell Tainted: G O 4.15.0-1-default #1 [ 5440.788271] Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./970A-DS3P, BIOS FD 02/26/2016 [ 5440.788271] Call Trace: [ 5440.788278] dump_stack+0x85/0xc5 [ 5440.788281] swiotlb_alloc_coherent+0xe0/0x160 [ 5440.788288] ttm_dma_pool_get_pages+0x1cb/0x590 [ttm] [ 5440.788292] ttm_dma_populate+0x24d/0x340 [ttm] [ 5440.788296] ttm_tt_bind+0x29/0x60 [ttm] [ 5440.788300] ttm_bo_handle_move_mem+0x5da/0x610 [ttm] [ 5440.788304] ttm_bo_validate+0x117/0x130 [ttm] [ 5440.788323] ? drm_vma_offset_add+0x41/0x60 [drm] [ 5440.788327] ttm_bo_init_reserved+0x38f/0x430 [ttm] [ 5440.788392] amdgpu_bo_do_create+0x184/0x3e0 [amdgpu] [ 5440.788420] ? amdgpu_fill_buffer+0x2e0/0x2e0 [amdgpu] [ 5440.788423] ? __switch_to_asm+0x40/0x70 [ 5440.788450] amdgpu_bo_create+0x3d/0x210 [amdgpu] [ 5440.788479] amdgpu_gem_object_create+0x6a/0xf0 [amdgpu] [ 5440.788507] ? amdgpu_gem_object_close+0x1b0/0x1b0 [amdgpu] [ 5440.788535] amdgpu_gem_create_ioctl+0x1c3/0x240 [amdgpu] [ 5440.788563] ? amdgpu_gem_object_close+0x1b0/0x1b0 [amdgpu] [ 5440.788571] drm_ioctl_kernel+0x5b/0xb0 [drm] [ 5440.788581] drm_ioctl+0x2ad/0x350 [drm] [ 5440.788609] ? amdgpu_gem_object_close+0x1b0/0x1b0 [amdgpu] [ 5440.788636] amdgpu_drm_ioctl+0x49/0x80 [amdgpu] [ 5440.788638] do_vfs_ioctl+0x90/0x5f0 [ 5440.788640] SyS_ioctl+0x74/0x80 [ 5440.788642] entry_SYSCALL_64_fastpath+0x2f/0xa1 [ 5440.788644] RIP: 0033:0x7f0956f47377
Don't know if it helps on debug but system seems stable and I have no strange behavior...
Stratos
On Thu, Feb 8, 2018 at 1:34 PM, Arjen de Korte <suse+factory@de-korte.org> wrote:
Citeren Mykola Krachkovsky <w01dnick@gmail.com>:
четвер, 8 лютого 2018 р. 12:20:29 EET Michal Srb написано:
On čtvrtek 8. února 2018 11:10:16 CET Mykola Krachkovsky wrote:
четвер, 8 лютого 2018 р. 11:53:12 EET Michal Srb написано:
On čtvrtek 8. února 2018 10:43:25 CET Mykola Krachkovsky wrote: But why previous (buggy) version worked fine? That's strange. My Mesa updates: 2018-02-01 11:35:16|install|Mesa|17.3.3-184.1|x86_64||openSUSE-20170510-0| 006a8dca9246bf852111f7fcee1f34d301a0252c| 2018-02-05 16:47:28|install|Mesa|18.0.0-185.1|x86_64||openSUSE-20170510-0| 6c4c429c5eb872737d7453cc0ed711ff455de424| 2018-02-08 09:45:27|install|Mesa|18.0.0-187.1|x86_64||repo-update| 7f37602bf8aa77467c45fb470c97f8f9dc26e78a78d9512e01405003c4887123|
It all just depends on how long you were using the broken version.
The path to get damaged cache with the broken Mesa was:
Compile shader -> store to cache -> load from cache -> store to cache.
During this chain of events the shader was still good and useable. Only the next load from cache with ANY version of Mesa results in invalid shader and broken rendering.
So maybe you never got to the second load from cache while you had the broken version. Only after updating to the next version and rebooting it happened.
Michal
Well, between 2018-02-05, 18.0.0-185.1 (I expect that's a broken version, isn't it?) and today (2018-02-08, 18.0.0-187.1) I definitely rebooted several times (at least 3 times). I almost never use suspend to disk, so usually just switch off and back on the pc.
Same here. The only times when I suspend to disk is when the battery of the laptop runs out of juice (which rarely happens). I must have (cold) started this laptop at least a dozen times or so since the previous snapshot and until the update this morning, without a hitch.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org