[PATCH] drm/i915/gvt: fix deadlock in dispatch_workload()'s error path
90d27a1 moved the lock before this error path but forgot to add an
unlock here.
Fixes: 90d27a1b180e51ef0713 ("drm/i915/gvt: fix deadlock in workload_thread")
Cc: Pei Zhang
Cc: Zhenyu Wang
Signed-off-by: Eric Engestrom
---
drivers/gpu/drm/i915/gvt/scheduler.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c
b/drivers/gpu/drm/i915/gvt/scheduler.c
index f898df3..cd13c4b 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -177,6 +177,7 @@ static int dispatch_workload(struct intel_vgpu_workload
*workload)
rq = i915_gem_request_alloc(dev_priv->engine[ring_id], shadow_ctx);
if (IS_ERR(rq)) {
gvt_err("fail to allocate gem request\n");
+ mutex_unlock(_priv->drm.struct_mutex);
workload->status = PTR_ERR(rq);
return workload->status;
}
--
Cheers,
Eric
[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing
https://bugs.freedesktop.org/show_bug.cgi?id=91880 --- Comment #132 from Filip Brygidyn <brygidyn.filip+freedesktop at gmail.com> --- I am experiecing the same freezes on my updated arch box (kernel 4.8.11-2, mesa 13.0.2-2) with my MSI R9 390. Without radeon.dpm=0 I observe the following: - I can get into and stay in tty with no crashes - I experience wierd filckering/'image jumping'. (Not artifacts) - With 2 monitors connected the mentioned flickering is unbearable and the image jumps so much it's hard to see anything. (and it gets worse over time) - After I start a window manager (xfce in my case) the system will freeze at the moment I cause any major load. This would support the ongoing suspition that the problem may be caused by clock or voltage changes. With radeon.dpm=0 I am yet to crash a single time in the similar way. This may be unrelated but I experience similar (although much less frequently occuring) crashes under windows. The system would run perfectly fine under load or idle for a long time but when the load is changing the system sometimes freezes or crash with a BSOD. Good example would be when I am running a game and I alt-tab a lot, changing the load drasticaly from 100% to idle and back. That is the moment when crashes occur most frequently. I am yet to try other firmware, mclk or other suggestions mentioned in here. Will post when I get enough time and motivation to tinker... -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161204/0e88cb31/attachment.html>
[Bug 98907] commit bf75ef3 causes Xorg lock-up
https://bugs.freedesktop.org/show_bug.cgi?id=98907 Marek Olšák changed: What|Removed |Added Resolution|FIXED |INVALID -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161204/cab7d810/attachment.html>
[Bug 98907] commit bf75ef3 causes Xorg lock-up
https://bugs.freedesktop.org/show_bug.cgi?id=98907 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Olšák --- Thanks. You can always re-open this if you want. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161204/eda53ae6/attachment.html>
[Bug 97605] AMDGPU Black Screen when Booting
https://bugs.freedesktop.org/show_bug.cgi?id=97605 --- Comment #9 from Thomas J. Moore --- Symptoms and hardware appear to be identical to but 97055. I'll let either the bug reporter or someone else with authority mark it as such, though. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161204/88b9a1c0/attachment.html>
[Bug 97055] Black screens on A10-8780P (Carrizo) + R7 M260/M265 (Topaz) Combo
https://bugs.freedesktop.org/show_bug.cgi?id=97055 --- Comment #12 from Thomas J. Moore --- (In reply to Josh from comment #11) > I too am affected by this issue. It might help if you add yourself to the CC list. Not that anyone talks on this bug but me. > Is this issue ever going to be fixed? I have my doubts. I have made efifb (nomodeset) my default boot now, so I can at least use this machine. Can't adjust brightness, play games or watch full-screen videos, but I guess I'll just have to live with that. The only way I expect this will ever get fixed for me is if I get enough money together to buy a new machine. The fact is, the only changes I've noticed have been regressions. The non-start of X in 4.8 was fixed, but later 4.8-series kernels (and 4.9 kernels as well) seem to crash badly (panic? hard to tell, since I have no way of knowing what happens when the screen is black -- I can't even get LEDs on the keyboard to flash, since this piece of crap machine also suffers from a non-linux-compatible keyboard: http://unix.stackexchange.com/questions/233396/system-creates-extra-shift-alt-control-keypresses/302890, and my attempts to get it to log to EFI have been unsuccessful). The crash then forces a filesystem check on reboot, which takes forever and I don't have the patience to deal with that any more. I was able to get amdgpu running "properly" (w/o power management) in 4.8.11 eventually using a 4.4.32 kernel to do the initial boot with power management enabled, but it's still unreliable enough that it isn't worth trying very often. I said I wouldn't report any more on the lack of progress, but yeah, 4.8.11 and 4.9-rc7 are still complete garbage, even worse than before. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161204/632f54aa/attachment.html>
[Bug 91809] AMD R9 390 *ERROR* Invalid PCC GPIO: 13!
https://bugs.freedesktop.org/show_bug.cgi?id=91809 Manuel Iglesias changed: What|Removed |Added Version|unspecified |DRI git -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161204/33701d32/attachment-0001.html>
[Bug 98907] commit bf75ef3 causes Xorg lock-up
https://bugs.freedesktop.org/show_bug.cgi?id=98907 --- Comment #3 from Hleb Valoshka <375gnu at gmail.com> --- (In reply to Marek Olšák from comment #2) > Would it be possible to run the game with "GALLIUM_DDEBUG=2000" set, wait > for the hang, and attach the file created in ~/ddebug_dumps/ ? When I had run it as "GALLIUM_DDEBUG=2000 ./bms.sh" it started like for the 1st time and now I'm not able to reproduce this issue. Maybe it caches compiled resources? Anyway I've tried 2 other Source powered games and they run without issues as well. So it seems that you can close this ticket as unreproducible. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161204/7be4d6c6/attachment.html>
[Bug 98987] [RS690] BUG: soft lockup when radeon modesetting
https://bugs.freedesktop.org/show_bug.cgi?id=98987 --- Comment #5 from Vedran MiletiÄ --- Has KMS ever worked on that card for you? If yes, can you test older kernels? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161204/c8c03c70/attachment.html>
[drm-intel:topic/core-for-CI 7/9] arch/x86/entry/vdso/vclock_gettime.o:undefined reference to `__gcov_merge_add'
tree: git://anongit.freedesktop.org/drm-intel topic/core-for-CI head: 11390213da1d7677b2ff16361a49cfa7a440da97 commit: 15bdcbcc55853f70237aca4baa4152f8396799d4 [7/9] kbuild: Disable PIE by default config: x86_64-rhel_gcov (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: git checkout 15bdcbcc55853f70237aca4baa4152f8396799d4 # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): /usr/bin/ld: arch/x86/entry/vdso/vclock_gettime.o: relocation R_X86_64_32 against `.data' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: arch/x86/entry/vdso/vgetcpu.o: relocation R_X86_64_32 against `.data' can not be used when making a shared object; recompile with -fPIC >> arch/x86/entry/vdso/vclock_gettime.o:(.data+0x1a0): undefined reference to >> `__gcov_merge_add' /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation -- next part -- A non-text attachment was scrubbed... Name: .config.gz Type: application/gzip Size: 37281 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161204/940c6263/attachment-0001.gz>
[Bug 97166] lockup during gameplay of Batman series of games
https://bugs.freedesktop.org/show_bug.cgi?id=97166 --- Comment #12 from farmboy0+freedesktop at googlemail.com --- Looks like this patch fixes the problem: https://lists.freedesktop.org/archives/mesa-dev/2016-December/137213.html -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161204/71d1b3da/attachment.html>
[Bug 98874] Desktop suddenly freezes, login via ssh possible, no error messages, unable to power off
https://bugs.freedesktop.org/show_bug.cgi?id=98874 --- Comment #11 from Matthias Nagel --- Is there anything I can do to push this one forward? There are some events that trigger the crash with high probability: - autocompletion of URL in Firefox - open context menu in Libre Writer - scrolling source code in PhpStorm Unfortunately, with this bug my PC is nearly unusable for daily work. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161204/a122daf8/attachment.html>
[Bug 98874] Desktop suddenly freezes, login via ssh possible, no error messages, unable to power off
https://bugs.freedesktop.org/show_bug.cgi?id=98874 --- Comment #10 from Matthias Nagel --- Created attachment 128330 --> https://bugs.freedesktop.org/attachment.cgi?id=128330=edit dmesg with amdgpu.lockup_timeout=2500 after 3rd crash See log entries starting at 3308 sec. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161204/78cd7511/attachment.html>
[Bug 98874] Desktop suddenly freezes, login via ssh possible, no error messages, unable to power off
https://bugs.freedesktop.org/show_bug.cgi?id=98874 --- Comment #9 from Matthias Nagel --- Created attachment 128329 --> https://bugs.freedesktop.org/attachment.cgi?id=128329=edit 3rd dump -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161204/bd60880c/attachment.html>
Enabling peer to peer device transactions for PCIe devices
On 11/30/2016 6:23 PM, Jason Gunthorpe wrote: >> and O_DIRECT operations that access GPU memory. > This goes through user space so there is still a VMA.. > >> Also, HMM's migration between two GPUs could use peer to peer in the >> kernel, although that is intended to be handled by the GPU driver if >> I understand correctly. > Hum, presumably these migrations are VMA backed as well... I guess so. >>> Presumably in-kernel could use a vmap or something and the same basic >>> flow? >> I think we can achieve the kernel's needs with ZONE_DEVICE and DMA-API >> support >> for peer to peer. I'm not sure we need vmap. We need a way to have a >> scatterlist >> of MMIO pfns, and ZONE_DEVICE allows that. > Well, if there is no virtual map then we are back to how do you do > migrations and other things people seem to want to do on these > pages. Maybe the loose 'struct page' flow is not for those users. I was thinking that kernel use cases would disallow migration, similar to how non-ODP MRs would work. Either they are short-lived (like an O_DIRECT transfer) or they can be longed lived but non-migratable (like perhaps a CMB staging buffer). > But I think if you want kGPU or similar then you probably need vmaps > or something similar to represent the GPU pages in kernel memory. Right, although sometimes the GPU pages are simply inaccessible to the CPU. In any case, I haven't thought about kGPU as a use-case.
[Bug 98987] [RS690] BUG: soft lockup when radeon modesetting
https://bugs.freedesktop.org/show_bug.cgi?id=98987 --- Comment #4 from Václav OvsÃk --- today I inserted into MB Asus M2A-VM HDMI PCI-E card HD7770. With HD7770 the modeset works OK without any crash/lockup. Xserver started OK too. Loaded was radeon driver. The bug in radeon driver is in a part specific to RS690 chip so. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161204/99af7160/attachment.html>
Enabling peer to peer device transactions for PCIe devices
On 11/30/2016 8:01 PM, Logan Gunthorpe wrote: > > > On 30/11/16 09:23 AM, Jason Gunthorpe wrote: >>> Two cases I can think of are RDMA access to an NVMe device's controller >>> memory buffer, >> >> I'm not sure on the use model there.. > > The NVMe fabrics stuff could probably make use of this. It's an > in-kernel system to allow remote access to an NVMe device over RDMA. So > they ought to be able to optimize their transfers by DMAing directly to > the NVMe's CMB -- no userspace interface would be required but there > would need some kernel infrastructure. Yes, that's what I was thinking. The NVMe/f driver needs to map the CMB for RDMA. I guess if it used ZONE_DEVICE like in the iopmem patches it would be relatively easy to do.
Enabling peer to peer device transactions for PCIe devices
On 11/30/2016 7:28 PM, Serguei Sagalovitch wrote: > On 2016-11-30 11:23 AM, Jason Gunthorpe wrote: >>> Yes, that sounds fine. Can we simply kill the process from the GPU driver? >>> Or do we need to extend the OOM killer to manage GPU pages? >> I don't know.. > We could use send_sig_info to send signal from kernel to user space. So > theoretically GPU driver > could issue KILL signal to some process. > >> On Wed, Nov 30, 2016 at 12:45:58PM +0200, Haggai Eran wrote: >>> I think we can achieve the kernel's needs with ZONE_DEVICE and DMA-API >>> support >>> for peer to peer. I'm not sure we need vmap. We need a way to have a >>> scatterlist >>> of MMIO pfns, and ZONE_DEVICE allows that. > I do not think that using DMA-API as it is is the best solution (at least in > the current form): > > - It deals with handles/fd for the whole allocation but client could/will > use sub-allocation as > well as theoretically possible to "merge" several allocations in one from GPU > perspective. > - It require knowledge to export but because "sharing" is controlled from > user space it > means that we must "export" all allocation by default > - It deals with 'fd'/handles but user application may work with > addresses/pointers. Aren't you confusing DMABUF and DMA-API? DMA-API is how you program the IOMMU (dma_map_page/dma_map_sg/etc.). The comment above is just about the need to extend this API to allow mapping peer device pages to bus addresses. In the past I sent an RFC for using DMABUF for peer to peer. I think it had some advantages for legacy devices. I agree that working with addresses and pointers through something like HMM/ODP is much more flexible and easier to program from user-space. For legacy, DMABUF would have allowed you a way to pin the pages so the GPU knows not to move them. However, that can probably also be achieved simply via the reference count on ZONE_DEVICE pages. The other nice thing about DMABUF is that it migrate the buffer itself during attachment according to the requirements of the device that is attaching, so you can automatically decide in the exporter whether to use p2p or a staging buffer. > > Also current DMA-API force each time to do all DMA table programming > unrelated if > location was changed or not. With vma / mmu we are able to install > notifier to intercept > changes in location and update translation tables only as needed (we do not > need to keep > get_user_pages() lock). I agree.
Enabling peer to peer device transactions for PCIe devices
Hi All This has been a great thread (thanks to Alex for kicking it off) and I wanted to jump in and maybe try and put some summary around the discussion. I also wanted to propose we include this as a topic for LFS/MM because I think we need more discussion on the best way to add this functionality to the kernel. As far as I can tell the people looking for P2P support in the kernel fall into two main camps: 1. Those who simply want to expose static BARs on PCIe devices that can be used as the source/destination for DMAs from another PCIe device. This group has no need for memory invalidation and are happy to use physical/bus addresses and not virtual addresses. 2. Those who want to support devices that suffer from occasional memory pressure and need to invalidate memory regions from time to time. This camp also would like to use virtual addresses rather than physical ones to allow for things like migration. I am wondering if people agree with this assessment? I think something like the iopmem patches Logan and I submitted recently come close to addressing use case 1. There are some issues around routability but based on feedback to date that does not seem to be a show-stopper for an initial inclusion. For use-case 2 it looks like there are several options and some of them (like HMM) have been around for quite some time without gaining acceptance. I think there needs to be more discussion on this usecase and it could be some time before we get something upstreamable. I for one, would really like to see use case 1 get addressed soon because we have consumers for it coming soon in the form of CMBs for NVMe devices. Long term I think Jason summed it up really well. CPU vendors will put high-speed, open, switchable, coherent buses on their processors and all these problems will vanish. But I ain't holding my breathe for that to happen ;-). Cheers Stephen
Enabling peer to peer device transactions for PCIe devices
>> >> The NVMe fabrics stuff could probably make use of this. It's an >> in-kernel system to allow remote access to an NVMe device over RDMA. So >> they ought to be able to optimize their transfers by DMAing directly to >> the NVMe's CMB -- no userspace interface would be required but there >> would need some kernel infrastructure. > > Yes, that's what I was thinking. The NVMe/f driver needs to map the CMB > for RDMA. I guess if it used ZONE_DEVICE like in the iopmem patches it > would be relatively easy to do. > Haggai, yes that was one of the use cases we considered when we put together the patchset.
[git pull] drm fixes for v.4.9
Hi Linus, I awoke this morning to realise I hadn't sent my -fixes pull, I then discovered the office where my build and sign tags machine had a power cut, and since nobody will be in until tomorrow I can't restart my desktop. So this tag is unsigned due to that and the realisation I don't keep my gpg private key stored at home. Otherwise it's a pretty small pull request, couple of AMD powerxpress regression fixes and a power management fix, a couple of i915 fixes and one hdlcd fix, along with one core don't oops because of incorrect API usage fix. (and I did use capital letters even for the unsigned tag!) Dave. The following changes since commit e5517c2a5a49ed5e99047008629f1cd60246ea0e: Linux 4.9-rc7 (2016-11-27 13:08:04 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.9-rc8 for you to fetch changes up to ab7cd8d83e5dba13027de66f1b008b08b30b71a4: Merge tag 'drm-intel-fixes-2016-12-01' of git://anongit.freedesktop.org/git/drm-intel into drm-fixes (2016-12-04 06:31:26 +1000) Alex Deucher (1): drm/radeon: fix check for port PM availability Chris Wilson (1): drm/i915: Don't touch NULL sg on i915_gem_object_get_pages_gtt() error Dave Airlie (4): Merge branch 'drm-fixes-4.9' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge branch 'for-upstream/hdlcd' of git://linux-arm.org/linux-ld into drm-fixes Merge tag 'drm-misc-fixes-2016-11-30' of git://anongit.freedesktop.org/git/drm-misc into drm-fixes Merge tag 'drm-intel-fixes-2016-12-01' of git://anongit.freedesktop.org/git/drm-intel into drm-fixes Matthew Auld (1): drm/i915: drop the struct_mutex when wedged or trying to reset Michel Dänzer (1): drm: Don't call drm_for_each_crtc with a non-KMS driver Peter Wu (1): drm/amdgpu: fix check for port PM availability Rex Zhu (1): drm/amd/powerplay: initialize the soft_regs offset in struct smu7_hwmgr Robin Murphy (1): drm: hdlcd: Fix cleanup order drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 11 +-- drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c | 5 - drivers/gpu/drm/arm/hdlcd_drv.c | 2 +- drivers/gpu/drm/drm_ioctl.c | 10 ++ drivers/gpu/drm/i915/i915_gem.c | 5 +++-- drivers/gpu/drm/i915/intel_display.c | 3 ++- drivers/gpu/drm/radeon/radeon_atpx_handler.c | 11 +-- 7 files changed, 34 insertions(+), 13 deletions(-)
[Bug 98988] [Regression, bisected] New BONAIRE UVD firmware causes DPM problems and extremely slow performance
https://bugs.freedesktop.org/show_bug.cgi?id=98988 Bug ID: 98988 Summary: [Regression, bisected] New BONAIRE UVD firmware causes DPM problems and extremely slow performance Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: falaca at gmail.com Created attachment 128327 --> https://bugs.freedesktop.org/attachment.cgi?id=128327=edit Kernel bisect log I have a 2GB Radeon R7 260X (BONAIRE). With kernel 4.7 and above, I was experiencing extremely slow performance. Even desktop animations on Ubuntu 16.04 w/ Unity desktop are extremely choppy, probably about 10fps. dmesg produces several instances of the following error message: [drm:ci_dpm_set_power_state [radeon]] *ERROR* ci_upload_dpm_level_enable_mask failed I did a kernel bisect, and narrowed the problem to the following commit: http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=7050c6ef5f0e9bc5e6bf9eb035320b70f731b919 The bisect log is attached. It seems that the commit adds support for a new firmware file, "bonaire_uvd.bin". If the driver fails in loading the new firmware file, it falls back to the legacy file, "BONAIRE_uvd.bin". To confirm that the issue is caused by the new firmware, I deleted bonaire_uvd.bin, and performance is restored to normal with the latest stable kernel (4.9.0-rc7). For what it's worth, here are the contents of /sys/kernel/debug/dri/64/radeon_pm_info while idling on the Ubuntu desktop with the new firmware: uvddisabled vcedisabled power level avgsclk: 115774 mclk: 15000 And the old firmware: uvddisabled vcedisabled power level avgsclk: 30248 mclk: 165000 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161204/6babb43c/attachment.html>
[Bug 97055] Black screens on A10-8780P (Carrizo) + R7 M260/M265 (Topaz) Combo
https://bugs.freedesktop.org/show_bug.cgi?id=97055 --- Comment #11 from Josh --- I too am affected by this issue. Is this issue ever going to be fixed? Who do I need to talk to in order to get this issue properly looked into? Where can I go to contribute my services to try and get this issue resolved? Because this was not an issue with fglrx/Catalyst drivers. But now suddenly the new driver that has replaced it can't handle what is expected of it. I would be more than happy to take my complaints and possible offering of services to the proper place, so who needs to be informed of this issue so it can finally be fixed? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161204/bd0bea10/attachment-0001.html>
[Bug 188091] Resume with two monitors, second monitor is not resumed until VT switch
https://bugzilla.kernel.org/show_bug.cgi?id=188091 --- Comment #8 from Greg White --- Created attachment 246801 --> https://bugzilla.kernel.org/attachment.cgi?id=246801=edit Patch against atombios_dp.c Seems to fix the problem locally. I have no idea if it's correct or not, but it may help tracking down the actual problem. On my system, I see one training attempt when the monitors are on, 4-5 when they are in standby. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 188091] Resume with two monitors, second monitor is not resumed until VT switch
https://bugzilla.kernel.org/show_bug.cgi?id=188091 --- Comment #7 from Greg White --- I have attached a patch which seems to fix the problem here. Maybe it will be helpful? -- You are receiving this mail because: You are watching the assignee of the bug.
