Op woensdag 7 februari 2018 14:56:01 CET schreef Dominique Leuenberger / DimStar:

On Wed, 2018-02-07 at 14:50 +0100, Michal Srb wrote:

...

On středa 7. února 2018 14:47:21 CET Argo Sieger wrote:

...

I got white SDDM login screen after update Mesa to version 18. After deleting .cache I can login blindly, but after logout screen still remains white. Any ideas?

It's this bug: https://bugzilla.opensuse.org/show_bug.cgi?id=1079748

A fixed Mesa is on the way.

You can install it now from: https://download.opensuse.org/repositories/home:/michalsrb:/branches:/ bnc1079465:/X11:/XOrg/openSUSE_Tumbleweed/

Those fixed mesa packages even already landed in the Tumbleweed-update channel.

Cheers Dominique

OK, thanks, that explains that removing the caches "solved" my issue, I already updated. Had to remove the user's cache too btw before the desktop would show properly. -- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team Linux user #548252 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday, 7 February 2018 14:50 Michal Srb wrote:

On středa 7. února 2018 14:47:21 CET Argo Sieger wrote:

...

I got white SDDM login screen after update Mesa to version 18. After deleting .cache I can login blindly, but after logout screen still remains white. Any ideas?

It's this bug: https://bugzilla.opensuse.org/show_bug.cgi?id=1079748

A fixed Mesa is on the way.

You can install it now from: https://download.opensuse.org/repositories/home:/michalsrb:/branches:/ bnc1079465:/X11:/XOrg/openSUSE_Tumbleweed/

After installing the update delete /var/lib/sddm/.cache. Then it should work again.

The fix should be in fact already present in version 18.0.0-187.1 which is available in Tumbleweed update repository. (Package changelog mentions bsc#1079465 which is bsc#1079748 duplicate of.) Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On čtvrtek 8. února 2018 10:43:25 CET Mykola Krachkovsky wrote:

It was fine everything with previous updates, but after update to 18.0.0-187.1 I've got a white sddm and not working plasma. Removing caches helped. Is that what expected or some new cache incompatibility?

Not cache incompatilibity, but previous version of Mesa was bugged and wrote invalid data. Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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:

...

It was fine everything with previous updates, but after update to 18.0.0-187.1 I've got a white sddm and not working plasma. Removing caches helped. Is that what expected or some new cache incompatibility?

Not cache incompatilibity, but previous version of Mesa was bugged and wrote invalid data.

Michal

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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Citeren Mykola Krachkovsky :

четвер, 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

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 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 wrote:

...

Citeren Mykola Krachkovsky :

...

четвер, 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

Same behavior today for me also. Zypper dup downgraded Mesa packages and after a screen suspend got the white screen again. Clearing the caches again fixed the issue. On Sat, Feb 10, 2018 at 11:33 AM, Mykola Krachkovsky wrote:

четвер, 8 лютого 2018 р. 12:40:20 EET Mykola Krachkovsky написано:

...

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.

So, zypper dup downgraded Mesa to 18.0.0-186.1 and I got white screen again. What's going on with caches? Was 187 broken too? Was/Is 186 broken? It's rather simple to fix, but it'd be good for some more new information about this, can't find new info in [1].

1. https://bugzilla.opensuse.org/show_bug.cgi?id=1079465

-- Kind regards, Mykola Krachkovsky -- Найкращі побажання, Микола Крачковський -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Again similar behavior today after latest dup. I proceeded to lock my screen (CTRL+ALT+L) and I got an immediate corruption of the screen. Killing X (CTRL+ALT+BACKSPACE) resulted on white screen and had to remove again the caches to get a working desktop... On Sat, Feb 10, 2018 at 12:26 PM, Stratos Zolotas wrote:

Also I didn't had the upstream issue appearing (amdgpu 0000:01:00.0: swiotlb buffer is full) when running with the upgraded packages for several hours. After the downgrade it appeared again. Sorry for the double post....

On Sat, Feb 10, 2018 at 12:21 PM, Stratos Zolotas wrote:

...

Same behavior today for me also. Zypper dup downgraded Mesa packages and after a screen suspend got the white screen again. Clearing the caches again fixed the issue.

On Sat, Feb 10, 2018 at 11:33 AM, Mykola Krachkovsky wrote:

...

четвер, 8 лютого 2018 р. 12:40:20 EET Mykola Krachkovsky написано:

...

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.

So, zypper dup downgraded Mesa to 18.0.0-186.1 and I got white screen again. What's going on with caches? Was 187 broken too? Was/Is 186 broken? It's rather simple to fix, but it'd be good for some more new information about this, can't find new info in [1].

1. https://bugzilla.opensuse.org/show_bug.cgi?id=1079465

-- Kind regards, Mykola Krachkovsky -- Найкращі побажання, Микола Крачковський -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On sobota 10. února 2018 10:33:43 CET Mykola Krachkovsky wrote:

четвер, 8 лютого 2018 р. 12:40:20 EET Mykola Krachkovsky написано:

...

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.

So, zypper dup downgraded Mesa to 18.0.0-186.1 and I got white screen again. What's going on with caches? Was 187 broken too? Was/Is 186 broken? It's rather simple to fix, but it'd be good for some more new information about this, can't find new info in [1].

1. https://bugzilla.opensuse.org/show_bug.cgi?id=1079465

I just added a comment into the bug. The bug 1079465 was only happening in 185.1 and contrary to what we though, cleaning cache was not necessary to fix it (Mesa rejects shaders from older version correctly). Notice that the bug is a crash. All the cases where rendering gets broken are different bug in Qt5: https://bugzilla.opensuse.org/show_bug.cgi?id=1080578 Currently Qt5 does not correctly handle the situation when a cached shader is rejected by Mesa. So every upgrade/downgrade of Mesa above 18.0.0 triggers it. Cleaning the cache solves it until the next Mesa change. We are working on a fix. Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

понеділок, 12 лютого 2018 р. 16:27:39 EET Michal Srb написано:

All the cases where rendering gets broken are different bug in Qt5: https://bugzilla.opensuse.org/show_bug.cgi?id=1080578

Currently Qt5 does not correctly handle the situation when a cached shader is rejected by Mesa. So every upgrade/downgrade of Mesa above 18.0.0 triggers it. Cleaning the cache solves it until the next Mesa change. We are working on a fix.

Michal

Thanks for patch! -- Kind regards, Mykola Krachkovsky -- Найкращі побажання, Микола Крачковський