Re: Regression in 5.4 kernel on 32-bit Radeon IBM T40
Den 09-01-2020 kl. 17:12, skrev Christian König: Hi Christoph, Am 09.01.20 um 15:14 schrieb Christoph Hellwig: Hi Woody, sorry for the late reply, I've been off to a vacation over the holidays. On Sat, Dec 14, 2019 at 10:17:15PM -0500, Woody Suwalski wrote: Regression in 5.4 kernel on 32-bit Radeon IBM T40 triggered by commit 33b3ad3788aba846fc8b9a065fe2685a0b64f713 Author: Christoph Hellwig Date: Thu Aug 15 09:27:00 2019 +0200 Howdy, The above patch has triggered a display problem on IBM Thinkpad T40, where the screen is covered with a lots of random short black horizontal lines, or distorted letters in X terms. The culprit seems to be that the dma_get_required_mask() is returning a value 0x3fff which is smaller than dma_get_mask()0x.That results in dma_addressing_limited()==0 in ttm_bo_device(), and using 40-bits dma instead of 32-bits. Which is the intended behavior assuming your system has 1GB of memory. Does it? Assuming the system doesn't have the 1GB split up somehow crazy over the address space that should indeed work as intended. If I hardcode "1" as the last parameter to ttm_bo_device_init() in place of a call to dma_addressing_limited(),the problem goes away. I'll need some help from the drm / radeon / TTM maintainers if there are any other side effects from not passing the need_dma32 paramters. Obviously if the device doesn't have more than 32-bits worth of dram and no DMA offset we can't feed unaddressable memory to the device. Unfortunately I have a very hard time following the implementation of the TTM pool if it does anything else in this case. The only other thing which comes to mind is using huge pages. Can you try a kernel with CONFIG_TRANSPARENT_HUGEPAGE disabled? Any progress on this ? We have a bugreport in Mageia with the hw: Dell Inspiron 5100, 32-bit P4 processor, 2GB of RAM, Radeon Mobility 7500 (RV200) graphics that gets display issues too and reverting the offending commit restores normal behaviour. and the same issue is still there with 5.5 series kernels. -- Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH AUTOSEL 5.2 13/23] drm/i915/userptr: Acquire the page lock around set_page_dirty()
Den 03-09-2019 kl. 19:24, skrev Sasha Levin:
From: Chris Wilson
[ Upstream commit aa56a292ce623734ddd30f52d73f527d1f3529b5 ]
set_page_dirty says:
For pages with a mapping this should be done under the page lock
for the benefit of asynchronous memory errors who prefer a
consistent dirty state. This rule can be broken in some special
cases, but should be better not to.
Under those rules, it is only safe for us to use the plain set_page_dirty
calls for shmemfs/anonymous memory. Userptr may be used with real
mappings and so needs to use the locked version (set_page_dirty_lock).
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203317
Fixes: 5cc9ed4b9a7a ("drm/i915: Introduce mapping of user pages into video memory
(userptr) ioctl")
References: 6dcc693bc57f ("ext4: warn when page is dirtied without buffers")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: sta...@vger.kernel.org
Reviewed-by: Tvrtko Ursulin
Link:
https://patchwork.freedesktop.org/patch/msgid/20190708140327.26825-1-ch...@chris-wilson.co.uk
(cherry picked from commit cb6d7c7dc7ff8cace666ddec66334117a6068ce2)
Signed-off-by: Jani Nikula
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/i915/i915_gem_userptr.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 8079ea3af1039..b1fc15c7f5997 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -678,7 +678,15 @@ i915_gem_userptr_put_pages(struct drm_i915_gem_object *obj,
for_each_sgt_page(page, sgt_iter, pages) {
if (obj->mm.dirty)
- set_page_dirty(page);
+ /*
+* As this may not be anonymous memory (e.g. shmem)
+* but exist on a real mapping, we have to lock
+* the page in order to dirty it -- holding
+* the page reference is not sufficient to
+* prevent the inode from being truncated.
+* Play safe and take the lock.
+*/
+ set_page_dirty_lock(page);
mark_page_accessed(page);
put_page(page);
Please drop this one from all 5.2 and 4.19 stable queues
It has now been reverted in Linus tree:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=505a8ec7e11ae5236c4a154a1e24ef49a8349600
--
Thomas
