[Bug 106670] AMD GPU Error, random lockup, Ryzen 2500U Vega 8 GPU
https://bugs.freedesktop.org/show_bug.cgi?id=106670 --- Comment #6 from JerryD --- I used grubby to add to my kernel boot command 'idle=nomwait' and the problem seems resolved. The mwait instruction is known to possibly hang threads on some earlier released ryzen chips as documented in the AMD Errata. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm-tip:drm-tip 7/8] debug.c:undefined reference to `save_stack_trace'
Hi Chris, It's probably a bug fix that unveils the link errors. tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip head: c49f62682d40bd553d906245815a73976cfb604a commit: b339ba2c91ecf03b38560c20e88d98dc7b6739f6 [7/8] Merge remote-tracking branch 'drm-intel/topic/core-for-CI' into drm-tip config: m68k-allmodconfig (attached as .config) compiler: m68k-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout b339ba2c91ecf03b38560c20e88d98dc7b6739f6 # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=m68k All errors (new ones prefixed by >>): kernel/dma/debug.o: In function `dma_entry_alloc': >> debug.c:(.text+0x11d2): undefined reference to `save_stack_trace' mm/slub.o: In function `set_track': >> slub.c:(.text+0x12b4): undefined reference to `save_stack_trace' lib/debugobjects.o: In function `save_stack.isra.0': >> debugobjects.c:(.text+0x9f2): undefined reference to `save_stack_trace' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107324] Radeon driver fails to install with modprobe: ERROR: could not insert 'radeon': Invalid argument
https://bugs.freedesktop.org/show_bug.cgi?id=107324 --- Comment #1 from jamesstewartmil...@gmail.com --- sudo modprobe radeon gives modprobe: ERROR: could not insert 'radeon': Invalid argument I have tried oibaf drivers ppa and also have compiled a custom rt kernel (for audio use), with no joy. I have tried removing the hw xorg drivers reinstalling xorg-core, but again, no luck. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107324] Radeon driver fails to install with modprobe: ERROR: could not insert 'radeon': Invalid argument
https://bugs.freedesktop.org/show_bug.cgi?id=107324 Bug ID: 107324 Summary: Radeon driver fails to install with modprobe: ERROR: could not insert 'radeon': Invalid argument Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon Assignee: dri-devel@lists.freedesktop.org Reporter: jamesstewartmil...@gmail.com Hi, on the following: Advanced Micro Devices, Inc. [AMD/ATI] RV770/M98L [Mobility Radeon HD 4850] on a 2009 imac running kubuntu 18.04 and kde 16.04 and kernel: 4.15.0-29-generic I'm having no luck obtaining anything but the vesa driver. The addition of nomodeset to the kernel parameters (booting from refind with no grub) is necessary to get a graphical desktop. If I leave modesetting on, the screen blacks out as the mode is changed. If I turn it off I get the vesa but an error is reported that there is no ums available in the radeon module. This has occurred on kde neon clean install and kubuntu. Many thanks. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105532] Broken map generation in Northgard game
https://bugs.freedesktop.org/show_bug.cgi?id=105532 --- Comment #9 from Christian Lanig --- I can confirm this for Hawaii, Polaris 20 and Raven. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #21 from tempel.jul...@gmail.com --- Don't want to nag at anyone, but this bug still makes DC unusable for me and thus is a real dealbreaker. Does implementing a fix for it require lots of efforts? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/fb_helper: Add drm_fb_helper_output_poll_changed_with_rpm()
On Thu, Jul 19, 2018 at 08:08:15PM -0400, Lyude Paul wrote: > On Thu, 2018-07-19 at 09:49 +0200, Lukas Wunner wrote: > > On Wed, Jul 18, 2018 at 04:56:39PM -0400, Lyude Paul wrote: > > > When DP MST hubs get confused, they can occasionally stop responding for > > > a good bit of time up until the point where the DRM driver manages to > > > do the right DPCD accesses to get it to start responding again. In a > > > worst case scenario however, this process can take upwards of 10+ > > > seconds. > > > > > > Currently we use the default output_poll_changed handler > > > drm_fb_helper_output_poll_changed() to handle output polling, which > > > doesn't happen to grab any power references on the device when polling. > > > If we're unlucky enough to have a hub (such as Lenovo's infamous laptop > > > docks for the P5x/P7x series) that's easily startled and confused, this > > > can lead to a pretty nasty deadlock situation that looks like this: > > > > > > - Hotplug event from hub happens, we enter > > > drm_fb_helper_output_poll_changed() and start communicating with the > > > hub > > > - While we're in drm_fb_helper_output_poll_changed() and attempting to > > > communicate with the hub, we end up confusing it and cause it to stop > > > responding for at least 10 seconds > > > - After 5 seconds of being in drm_fb_helper_output_poll_changed(), the > > > pm core attempts to put the GPU into autosuspend, which ends up > > > calling drm_kms_helper_poll_disable() > > > - While the runtime PM core is waiting in drm_kms_helper_poll_disable() > > > for the output poll to finish, we end up finally detecting an MST > > > display > > > - We notice the new display and tries to enable it, which triggers > > > an atomic commit which triggers a call to pm_runtime_get_sync() > > > - the output poll thread deadlocks the pm core waiting for the pm core > > > to finish the autosuspend request while the pm core waits for the > > > output poll thread to finish > > > > The correct fix is to call pm_runtime_get_sync() *conditionally* in > > the atomic commit which enables the display, using the same conditional > > as d61a5c106351, i.e. if (!drm_kms_helper_is_poll_worker()). First of all, I was mistaken when I wrote above that a check for !drm_kms_helper_is_poll_worker() would solve the problem. Sorry! It doesn't because the call to pm_runtime_get_sync() is not happening in output_poll_execute() but in drm_dp_mst_link_probe_work(). Looking once more at the three stack traces you've provided, we've got: - output_poll_execute() stuck waiting for fb_helper->lock which is held by drm_dp_mst_link_probe_work() - rpm_suspend() stuck waiting for output_poll_execute() to finish - drm_dp_mst_link_probe_work() stuck waiting in rpm_resume() For the moment we can ignore the first task, i.e. output_poll_execute(), and focus on the latter two. As said I'm unfamiliar with MST but browsing through drm_dp_mst_topology.c I notice that drm_dp_mst_link_probe_work() is the ->work element in drm_dp_mst_topology_mgr() and is queued on HPD. I further notice that the work item is flushed on ->runtime_suspend: nouveau_pmops_runtime_suspend() nouveau_do_suspend() nouveau_display_suspend() nouveau_display_fini() disp->fini() == nv50_display_fini() nv50_mstm_fini() drm_dp_mst_topology_mgr_suspend() flush_work(>work); And before the work item is flushed, the HPD source is quiesced. So it looks like drm_dp_mst_link_probe_work() can only ever run while the GPU is runtime resumed, it never runs while the GPU is runtime suspended. This means that you don't have to acquire any runtime PM references in or below drm_dp_mst_link_probe_work(). Au contraire, you must not acquire any because it will deadlock while the GPU is runtime suspending. If there are functions which are called from drm_dp_mst_link_probe_work() as well as from other contexts, and those other contexts need a runtime PM ref to be acquired, you need to acquire the runtime PM ref conditionally on not being drm_dp_mst_link_probe_work() (using the current_work() technique). Alternatively, move acquisition of the runtime PM ref further up in the call chain to those other contexts. > Anyway-that's why your explanation doesn't make sense: the deadlock is > happening because we're calling pm_runtime_get_sync(). If we were to > make that call conditional (e.g. drm_kms_helper_is_poll_worker()), > all that would mean is that we wouldn't grab any runtime power reference > and the GPU would immediately suspend once the atomic commit finished, > as the suspend request in Thread 5 would finally get unblocked and thus > suspend. Right, that seems to be a bug nouveau_pmops_runtime_suspend(): If a display is plugged in while the GPU is about to runtime suspend, the display may be lit up by output_poll_execute() but the GPU will then nevertheless be powered off. I guess after calling drm_kms_helper_poll_disable() we should
[Bug 105532] Broken map generation in Northgard game
https://bugs.freedesktop.org/show_bug.cgi?id=105532 Alexander Tsoy changed: What|Removed |Added Resolution|--- |NOTOURBUG Status|NEW |RESOLVED --- Comment #8 from Alexander Tsoy --- Latest game update fixed this bug for me. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/10] drm: atmel-hlcdc: Use __drm_atomic_helper_plane_reset instead of copying the logic
Hi Alexandru, On Fri, 20 Jul 2018 22:15:03 +0100 Alexandru Gheorghe wrote: Please add a commit message here (even if it's just repeating what the subject says). > Signed-off-by: Alexandru Gheorghe With this addressed: Acked-by: Boris Brezillon > --- > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c > b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c > index 04440064b9b7..9330a076e15a 100644 > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c > @@ -942,10 +942,7 @@ static void atmel_hlcdc_plane_reset(struct drm_plane *p) > "Failed to allocate initial plane state\n"); > return; > } > - > - p->state = >base; > - p->state->alpha = DRM_BLEND_ALPHA_OPAQUE; > - p->state->plane = p; > + __drm_atomic_helper_plane_reset(p, >base); > } > } > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
