[opensuse-factory] White SDDM login screen after update Mesa 18
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? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op woensdag 7 februari 2018 14:47:21 CET schreef Argo Sieger:
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?
Just saw the same thing. I deleted both my user's ~/.cache and /var//lib/ sddm/.cache and now all seems back to normal. Weird phenomenon. -- 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 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. Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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
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
Il giorno Wed, 07 Feb 2018 14:56:01 +0100 Dominique Leuenberger / DimStar <dimstar@opensuse.org> ha scritto:
Those fixed mesa packages even already landed in the Tumbleweed-update channel.
Note: if you ever ran SDDM/Plasma with the "broken" Mesa, you *will* have to clean ~/.cache and /var/lib/sddm/.cache anyway, as the bad caches (causing the crashes) will be still on disk.
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
середа, 7 лютого 2018 р. 15:59:24 EET Michal Kubecek написано:
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
Hi, 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? -- Kind regards, Mykola Krachkovsky -- Найкращі побажання, Микола Крачковський
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
четвер, 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| -- Kind regards, Mykola Krachkovsky -- Найкращі побажання, Микола Крачковський
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
четвер, 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. -- Kind regards, Mykola Krachkovsky -- Найкращі побажання, Микола Крачковський
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
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
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
четвер, 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 -- Найкращі побажання, Микола Крачковський
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 <w01dnick@gmail.com> 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
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 <strzol@gmail.com> 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 <w01dnick@gmail.com> 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 <strzol@gmail.com> 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 <strzol@gmail.com> 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 <w01dnick@gmail.com> 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
неділя, 11 лютого 2018 р. 11:13:23 EET Stratos Zolotas написано:
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...
Have no such problem with latest update. At least I've checked locking after update and everything worked fine. Haven't tried to reboot yet. -- Kind regards, Mykola Krachkovsky -- Найкращі побажання, Микола Крачковський
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].
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 написано:
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
Thanks for the info! -- Kind regards, Mykola Krachkovsky -- Найкращі побажання, Микола Крачковський
понеділок, 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 -- Найкращі побажання, Микола Крачковський
participants (10)
-
Argo Sieger -
Arjen de Korte -
Dominique Leuenberger / DimStar -
Knurpht - Gertjan Lettink -
Knurpht - Gertjan Lettink tha
-
Luca Beltrame -
Michal Kubecek -
Michal Srb -
Mykola Krachkovsky -
Stratos Zolotas