[Bug 107978] [amdgpu] Switching to tty fails with DisplayPort monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)
https://bugs.freedesktop.org/show_bug.cgi?id=107978
Bug ID: 107978 Summary: [amdgpu] Switching to tty fails with DisplayPort monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank) Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: shtetldik@gmail.com
After upgrading to Linux 4.19-rc3 (from 4.18.x), I can't switch to tty anymore, the monitor connected over DisplayPort goes into sleep mode.
I see this in dmesg when it happens:
[37342.777399] [drm:generic_reg_wait [amdgpu]] *ERROR* REG_WAIT timeout 10us * 3000 tries - dce110_stream_encoder_dp_blank line:922 [37342.777477] WARNING: CPU: 4 PID: 14403 at drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:254 generic_reg_wait+0xe7/0x160 [amdgpu] [37342.777478] Modules linked in: uas usb_storage rfcomm ebtable_filter ebtables devlink ip6table_filter ip6_tables iptable_filter cmac bnep arc4 nls_ascii nls_cp437 vfat amdkfd fat snd_hda_codec_realtek snd_hda_codec_generic edac_mce_amd btusb btrtl amdgpu btbcm snd_hda_codec_hdmi btintel iwlmvm snd_usb_audio snd_hda_intel bluetooth kvm_amd snd_hda_codec snd_usbmidi_lib wmi_bmof mxm_wmi mac80211 snd_hda_core kvm uvcvideo videobuf2_vmalloc snd_hwdep videobuf2_memops snd_rawmidi jitterentropy_rng videobuf2_v4l2 videobuf2_common snd_seq_device chash iwlwifi irqbypass gpu_sched videodev snd_pcm crct10dif_pclmul ttm crc32_pclmul media drbg snd_timer evdev drm_kms_helper cfg80211 ansi_cprng ghash_clmulni_intel efi_pstore pcspkr drm snd k10temp ecdh_generic soundcore efivars rfkill crc16 sp5100_tco sg ccp [37342.777514] rng_core wmi pcc_cpufreq button acpi_cpufreq nct6775 hwmon_vid parport_pc ppdev lp parport efivarfs ip_tables x_tables autofs4 xfs btrfs xor zstd_decompress zstd_compress xxhash raid6_pq libcrc32c crc32c_generic hid_generic usbhid hid sd_mod crc32c_intel ahci xhci_pci libahci aesni_intel xhci_hcd aes_x86_64 crypto_simd libata igb cryptd glue_helper nvme usbcore scsi_mod i2c_piix4 i2c_algo_bit nvme_core dca usb_common gpio_amdpt gpio_generic [37342.777542] CPU: 4 PID: 14403 Comm: kworker/4:1 Tainted: G W 4.19.0-rc3-amd64 #1 Debian 4.19~rc3-1~exp1 [37342.777542] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./X370 Taichi, BIOS L4.64 04/03/2018 [37342.777558] Workqueue: events drm_mode_rmfb_work_fn [drm] [37342.777615] RIP: 0010:generic_reg_wait+0xe7/0x160 [amdgpu] [37342.777617] Code: 44 24 58 8b 54 24 48 89 de 44 89 4c 24 08 48 8b 4c 24 50 48 c7 c7 20 9d b5 c1 e8 64 e6 f0 fe 83 7d 18 01 44 8b 4c 24 08 74 02 <0f> 0b 48 83 c4 10 44 89 c8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 41 0f [37342.777618] RSP: 0018:ffffa2ae81b9ba20 EFLAGS: 00010297 [37342.777620] RAX: 0000000000000000 RBX: 000000000000000a RCX: 0000000000000000 [37342.777621] RDX: 0000000000000000 RSI: ffff93d74eb166a8 RDI: ffff93d74eb166a8 [37342.777622] RBP: ffff93d746439180 R08: 0000000000000000 R09: 0000000000010200 [37342.777623] R10: 0720072007200720 R11: 0720073207320739 R12: 0000000000000bb9 [37342.777624] R13: 00000000000051e2 R14: 0000000000010000 R15: 0000000000000000 [37342.777625] FS: 0000000000000000(0000) GS:ffff93d74eb00000(0000) knlGS:0000000000000000 [37342.777626] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [37342.777627] CR2: 0000558f62bfa9d0 CR3: 00000003f2c38000 CR4: 00000000003406e0 [37342.777628] Call Trace: [37342.777695] dce110_stream_encoder_dp_blank+0x12c/0x1a0 [amdgpu] [37342.777754] core_link_disable_stream+0x54/0x220 [amdgpu] [37342.777813] dce110_reset_hw_ctx_wrap+0xc1/0x1e0 [amdgpu] [37342.777872] dce110_apply_ctx_to_hw+0x45/0x650 [amdgpu] [37342.777928] ? dc_remove_plane_from_context+0x1fc/0x240 [amdgpu] [37342.777985] dc_commit_state+0x2c6/0x520 [amdgpu] [37342.778047] amdgpu_dm_atomic_commit_tail+0x37a/0xd80 [amdgpu] [37342.778052] ? __wake_up_common_lock+0x89/0xc0 [37342.778054] ? _cond_resched+0x15/0x30 [37342.778056] ? wait_for_completion_timeout+0x3b/0x1a0 [37342.778117] ? amdgpu_dm_atomic_commit_tail+0xd80/0xd80 [amdgpu] [37342.778126] commit_tail+0x3d/0x70 [drm_kms_helper] [37342.778133] drm_atomic_helper_commit+0xb4/0x120 [drm_kms_helper] [37342.778148] drm_framebuffer_remove+0x361/0x410 [drm] [37342.778164] drm_mode_rmfb_work_fn+0x4f/0x60 [drm] [37342.778167] process_one_work+0x1a7/0x360 [37342.778169] worker_thread+0x30/0x390 [37342.778171] ? pwq_unbound_release_workfn+0xd0/0xd0 [37342.778173] kthread+0x112/0x130 [37342.778175] ? kthread_bind+0x30/0x30 [37342.778177] ret_from_fork+0x22/0x40 [37342.778179] ---[ end trace 3d987dd66a59ffb4 ]---
OS: Debian testing, kernel 4.19~rc3-1~exp1 GPU: Sapphire Pulse Vega 56. amdgpu firmware: 20180825+dfsg-1
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #1 from Shmerl shtetldik@gmail.com --- Same thing happens with kernel 4.19-rc4.
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #2 from Shmerl shtetldik@gmail.com --- Still broken with 4.19.0-rc6-amd64.
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #3 from Shmerl shtetldik@gmail.com --- Is this issue Debian specific or anyone observed it in other distros? Because if it's something wrong with Debian's kernel build I should probably file a Debian bug about it.
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #4 from george george@rylos.net --- I have same problem on Fedora F28 with 4.18 kernel. I have since switched back to DVI interface which does not exhibit this bug.
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #5 from Shmerl shtetldik@gmail.com --- My card doesn't have DVI, and HDMI produces horrible colors, so DisplayPort is the only sane option and it's broken :(
https://bugs.freedesktop.org/show_bug.cgi?id=107978
Nicholas Kazlauskas nicholas.kazlauskas@amd.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nicholas.kazlauskas@amd.com
--- Comment #6 from Nicholas Kazlauskas nicholas.kazlauskas@amd.com --- I haven't observed this behavior occurring under Ubuntu 18.04 or Arch on 4.18 or 4.19 kernels with a Vega 56.
Do you mind posting a full dmesg log with drm.debug=4 and an xorg log? It would also help to know what desktop environment you're using.
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #7 from Shmerl shtetldik@gmail.com --- I'm using KDE Plasma 5.13.5, current Debian testing x86_64. Can you try it with Debian? Ubuntu stack is not that close anymore.
I also noticed one detail. When screen mode is chaning (like before sddm comes up), the monitor goes to sleep briefly and then wakes up. That wasn't happening before and it's not a correct behavior. In 4.18 it wasn't waking up at all, and it was fixed in 4.19. Similar thing is happening during switch to tty (screen mode is changing indicated by the DP monitor icon appearing), except the monitor isn't waking up anymore.
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #8 from Shmerl shtetldik@gmail.com --- Created attachment 141960 --> https://bugs.freedesktop.org/attachment.cgi?id=141960&action=edit dmesg with drm.debug=4 and Xorg.0.log
Attaching logs.
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #9 from Shmerl shtetldik@gmail.com --- By the way, I tested it with this kernel:
https://github.com/M-Bab/linux-kernel-amdgpu-binaries/blob/master/linux-imag...
Which is built from AMD's tree. This issue is also present in it.
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #10 from Shmerl shtetldik@gmail.com --- I just found something. My monitor - Dell U2413 has a setting for toggling DisplayPort 1.2. It was enabled until now. When I disable that setting, tty starts working!
My cable is supposed to support DP 1.2 and be Vesa compliant. It's Accel UltraAV DP 1.2 cable.
I hope this can help narrow down the problem.
https://bugs.freedesktop.org/show_bug.cgi?id=107978
Shmerl shtetldik@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|[amdgpu] Switching to tty |[amdgpu] Switching to tty |fails with DisplayPort |fails with DisplayPort 1.2 |monitor going to sleep |monitor going to sleep |(REG_WAIT timeout / |(REG_WAIT timeout / |dce110_stream_encoder_dp_bl |dce110_stream_encoder_dp_bl |ank) |ank)
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #11 from george george@rylos.net --- (In reply to Shmerl from comment #10)
Interesting, I have the exact same monitor, Dell U2413, I'll give this a try!
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #12 from Shmerl shtetldik@gmail.com --- @Nicholas Kazlauskas: does it help to identify the source of the problem?
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #13 from Nicholas Kazlauskas nicholas.kazlauskas@amd.com --- (In reply to Shmerl from comment #12)
@Nicholas Kazlauskas: does it help to identify the source of the problem?
If I had to guess I would say this is an issue specific to that monitor - DP 1.2 should generally work without issue.
This does help narrow down the problem, thanks.
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #14 from Shmerl shtetldik@gmail.com --- (In reply to Nicholas Kazlauskas from comment #13)
If I had to guess I would say this is an issue specific to that monitor - DP 1.2 should generally work without issue.
It did work fine before in DP 1.2 mode (like with kernel 4.17.x), so there must have been some regression which caused this behavior.
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #15 from freedesktop@sibrenvasse.nl --- I own a DELL U2414H and a U2913WM, and are daisy chained via DisplayPort. I'm currently running into this issue.
A quick bisect gave this result: # first bad commit: [0d99889109892396a8164bf6dd178e36d3fe3166] drm/fb-helper: Eliminate the .best_encoder() usage
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #16 from Daniel Exner dex+fdobugzilla@dragonslave.de --- I own a Dell U3415W also connected via DisplayPort and I have the same issue.
Worked like a charm in the past.
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #17 from Shmerl shtetldik@gmail.com --- (In reply to Nicholas Kazlauskas from comment #13)
This does help narrow down the problem, thanks.
Is there any chance of fixing this in 4.20?
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #18 from Robin account-freedesktop@tripp.xyz --- Same problem for me. Using 2 identical DELL U2415 and a Radeon RX 580. On Arch with 4.18.x Daisychainig both monitors worked like a charm. After upgrading to 4.19 the monitors only work when I`m disableing DP1.2. But then I obviously can't Daisychain. Is there any way I can help troubleshoot this?
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #19 from Shmerl shtetldik@gmail.com --- This seem to commonly affect Dell monitors. Do they not follow DisplayPort 1.2 spec, or amdgpu is doing something incorrectly after all?
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #20 from Jerry Zuo Jerry.Zuo@amd.com --- The fix is showing up since 4.20-rc5. Please give a try.
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #21 from Sibren Vasse freedesktop@sibrenvasse.nl --- (In reply to Jerry Zuo from comment #20)
The fix is showing up since 4.20-rc5. Please give a try.
4.20-rc5 solves the problem for me!
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #22 from Shmerl shtetldik@gmail.com --- Great news! Debian didn't get 4.20 rc kernels yet, but I can try building one from source to test.
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #23 from Sibren Vasse freedesktop@sibrenvasse.nl --- Switching to tty now works for me , I still get the [drm:generic_reg_wait [amdgpu]] *ERROR* REG_WAIT timeout 10us * 3000 tries - dce110_stream_encoder_dp_blank line:944 message though
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #24 from Shmerl shtetldik@gmail.com --- Does KWin Wayland session work for you now? It was crashing also because of this.
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #25 from Shmerl shtetldik@gmail.com --- Just built 4.20-rc5+. This is indeed fixed, and KWin Wayland session is finally working with DisplayPort 1.2 enabled!
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #26 from Shmerl shtetldik@gmail.com --- And I don't see ERROR* REG_WAIT anymore. I'm using latest Vega firmware.
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #27 from Jerry Zuo Jerry.Zuo@amd.com --- The dce110_stream_encoder_dp_blank timeout is something I am working on. It doesn't break anything, but pretty annoying.
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #28 from Shmerl shtetldik@gmail.com --- Not sure if it's related, but with 4.20.0-rc6 the regression when monitor goes to sleep before reaching sddm is back. It's erratic, i.e. doesn't happen on every boot. And I do see this REG_WAIT in dmesg when it does.
Turning monitor off and on, then going to tty and restarting sddm works around it.
Similar bug was fixed in the previous kernels, so I wonder if the fix for this one somehow brought that issue back.
GPU: Sapphire Pulse Vega 56.
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #29 from Jerry Zuo Jerry.Zuo@amd.com --- Created attachment 142834 --> https://bugs.freedesktop.org/attachment.cgi?id=142834&action=edit parch for reg_wait timeout for dce
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #30 from Jerry Zuo Jerry.Zuo@amd.com --- Please try the patch, and see if you can see reg_wait timeout dce110_stream_encoder_dp_blank()
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #31 from Alex Deucher alexdeucher@gmail.com --- (In reply to Jerry Zuo from comment #30)
Please try the patch, and see if you can see reg_wait timeout dce110_stream_encoder_dp_blank()
Can you attach a non-zipped version?
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #32 from Jerry Zuo Jerry.Zuo@amd.com --- Created attachment 142835 --> https://bugs.freedesktop.org/attachment.cgi?id=142835&action=edit Patch for dp_blank timeout
https://bugs.freedesktop.org/show_bug.cgi?id=107978
Alex Deucher alexdeucher@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #142835|0 |1 is patch| | Attachment #142835|application/mbox |text/plain mime type| |
https://bugs.freedesktop.org/show_bug.cgi?id=107978
Alex Deucher alexdeucher@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #142834|0 |1 is obsolete| |
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #33 from Sibren Vasse freedesktop@sibrenvasse.nl --- Just tried the patch, so far no reg_wait warnings. Looking good!
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #34 from Shmerl shtetldik@gmail.com --- I tested the patch. I don't see the error message now, but the startup monitor sleep regression is still present. Is it a separate issue? I can open another bug if needed.
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #35 from Jerry Zuo Jerry.Zuo@amd.com --- "startup monitor sleep regression". Please give more details on that. Thanks.
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #36 from Shmerl shtetldik@gmail.com --- (In reply to Jerry Zuo from comment #35)
"startup monitor sleep regression". Please give more details on that. Thanks.
This behavior used to happen in the previous kernerls but got fixed at one point. Now it's back.
Basically, after GRUB, the system boots (I usually enable loglevel=4 to see system output), but right before reaching graphical login (sddm in my case), the monitor simply switched to sleep mode. To work around it, I have to:
1. Turn the monitor off and on. 2. Switch to tty1, and restart sddm from there.
This enables graphical login.
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #37 from Shmerl shtetldik@gmail.com --- I wonder if it's some kind of distro specific race condition that happens during boot. Happens to me in Debian testing (you can try reproducing it there).
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #38 from Shmerl shtetldik@gmail.com --- (In reply to Jerry Zuo from comment #30)
Please try the patch, and see if you can see reg_wait timeout dce110_stream_encoder_dp_blank()
Do you plan to backport at least this patch to 4.20.x?
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #39 from Shmerl shtetldik@gmail.com --- FYI: the dmesg message fix should be already included in 5.0-rc1:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/dr...
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #40 from Shmerl shtetldik@gmail.com --- Just tested kernel 5.0-rc1, the boot problem with monitor going to sleep is still happening. Same workaround (turn the monitor off / on, switch to tty1, restart sddm) helps.
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #41 from Shmerl shtetldik@gmail.com --- Same thing still happen with 5.0-rc2. Does anyone else experience this race condition when the monitor goes to sleep right after boot? It is related to the same setup (DisplayPort 1.2), since it's not happening with it disabled.
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #42 from Jerry Zuo Jerry.Zuo@amd.com --- We are currently looking at the startup issue now.
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #43 from Jerry Zuo Jerry.Zuo@amd.com --- We observed MST cannot light up in every reboot since 4.20, and we've already got the reboot/poweroff sequence fixed. The fix will show up soon ...
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #44 from Jerry Zuo Jerry.Zuo@amd.com --- Created attachment 143225 --> https://bugs.freedesktop.org/attachment.cgi?id=143225&action=edit Patch for fixing MST reboot/poweroff sequence
https://bugs.freedesktop.org/show_bug.cgi?id=107978
Alex Deucher alexdeucher@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #143225|application/mbox |text/plain mime type| | Attachment #143225|0 |1 is patch| |
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #45 from Jerry Zuo Jerry.Zuo@amd.com --- Please try the patch and see if that fixes your issue. We will come up with proper solution later.
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #46 from Shmerl shtetldik@gmail.com --- (In reply to Jerry Zuo from comment #45)
Please try the patch and see if that fixes your issue. We will come up with proper solution later.
I tested the patch, and it didn't fix the issue for me.
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #47 from Jerry Zuo Jerry.Zuo@amd.com --- You observed the monitor goes to sleep right after reboot, did you? Hotplug will have the display back on. Is that what you observed?
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #48 from Shmerl shtetldik@gmail.com --- (In reply to Jerry Zuo from comment #47)
You observed the monitor goes to sleep right after reboot, did you? Hotplug will have the display back on. Is that what you observed?
After any boot, not necessarily reboot. The system boots to the point where sddm should start, and monitor turns sleep mode on.Toggling the monitor off and (and then restarting sddm) works around it.
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #49 from Shmerl shtetldik@gmail.com --- Though my tests mostly focused on reboots. Let me double check what happens after actual cold off and boot.
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #50 from Shmerl shtetldik@gmail.com --- I think I know what happened. When I was rebooting, I still had the older kernel running (without the fix), to actually test the new one, so probably the bug still kicked in after reboot.
I now rebooted a few more times already from the patched kernel, and I don't see the issue anymore. It also doesn't happen with boot from complete off state.
Thanks!
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #51 from Jerry Zuo Jerry.Zuo@amd.com --- Good to hear that the patch fixes your issue. The official patch will be merged to the next kernel release. Thank you so much for your dedicated testing and prompt feedback ^_^
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #52 from Shmerl shtetldik@gmail.com --- (In reply to Jerry Zuo from comment #51)
Thanks! Do you mean the fix will land in 5.0 or the one release after that?
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #53 from Jerry Zuo Jerry.Zuo@amd.com --- The fix should show up in the coming release.
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #54 from Shmerl shtetldik@gmail.com --- (In reply to Jerry Zuo from comment #53)
The fix should show up in the coming release.
Great, thanks!
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #55 from Shmerl shtetldik@gmail.com --- Looks like the fix didn't make it into 5.0-rc7:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driv...
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #56 from Shmerl shtetldik@gmail.com --- I see the fix in this submission though: https://lists.freedesktop.org/archives/amd-gfx/2019-February/031437.html
So it's coming in 5.1 only?
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #57 from Alex Deucher alexdeucher@gmail.com --- (In reply to Shmerl from comment #56)
I see the fix in this submission though: https://lists.freedesktop.org/archives/amd-gfx/2019-February/031437.html
This patch missed the window for last week's -fixes pull.
So it's coming in 5.1 only?
It can still land in 5.0 and prior kernels via stable if it doesn't make it in for 5.0 final.
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #58 from Shmerl shtetldik@gmail.com --- The fix now merged in release branch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
https://bugs.freedesktop.org/show_bug.cgi?id=107978
Shmerl shtetldik@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED
--- Comment #59 from Shmerl shtetldik@gmail.com --- Closing, since it's already fixed in the released kernels.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org