Hi!
On Mon, 28 Apr 2014 10:03:46 +0200, I wrote:
On Fri, 25 Apr 2014 19:03:22 -0400, Jerome Glisse j.glisse@gmail.com wrote:
On Fri, Apr 25, 2014 at 05:50:57PM -0400, Jerome Glisse wrote:
On Fri, Apr 25, 2014 at 05:47:48PM -0400, Jerome Glisse wrote:
On Thu, Apr 24, 2014 at 09:37:22AM -0400, Johannes Weiner wrote:
On Wed, Apr 02, 2014 at 04:26:08PM +0200, Thomas Schwinge wrote:
On Fri, 2 Aug 2013 11:37:26 -0400, Johannes Weiner hannes@cmpxchg.org wrote: > Each zone that holds userspace pages of one workload must be aged at a > speed proportional to the zone size. [...]
> Fix this with a very simple round robin allocator. [...]
This patch, adding NR_ALLOC_BATCH, eventually landed in mainline as commit 81c0a2bb515fd4daae8cab64352877480792b515 (2013-09-11).
I recently upgraded a Debian testing system from a 3.11 kernel to 3.12, and it started to exhibit "strange" issues, which I then bisected to this patch. I'm not saying that the patch is faulty, as it seems to be working fine for everyone else, so I rather assume that something in a (vastly?) different corner of the kernel (or my hardware?) is broken. ;-)
The issue is that when X.org/lightdm starts up, there are "garbled" section on the screen, for example, rectangular boxes that are just black or otherwise "distorted", and/or sets of glyphs (corresponding to a set of characters; but not all characters) are displayed as rectangular gray or black boxes, and/or icons in a GNOME session are not displayed properly, and so on. (Can take a snapshot if that helps?) Switching to a Linux console, I can use that one fine. Switching back to X, in the majority of all cases, the screen will be completely black, but with the mouse cursor still rendered properly (done in hardware, I assume).
Reverting commit 81c0a2bb515fd4daae8cab64352877480792b515, for example on top of v3.12, and everything is back to normal. The problem also persists with a v3.14 kernel that I just built.
My guess is that the pcie bridge can only remap dma page with 32bit dma mask while the gpu is fine with 40bit dma mask. I always thought that the pcie/pci code did take care of such thing for us.
Forgot to attach patch to test my theory. Does the attached patch fix the issue ?
Unfortunately it does not. :-/
Ha, the following seems to do it: additionally to dma_bits (your patch), I'm also overriding need_dma32 for later use in drivers/gpu/drm/ttm/ttm_bo.c:ttm_bo_add_ttm, I assume. With that hack applied, I have now rebooted a v3.14 build a few times, and so far things "look" fine.
diff --git drivers/gpu/drm/radeon/radeon_device.c drivers/gpu/drm/radeon/radeon_device.c index 044bc98..90baf2f 100644 --- drivers/gpu/drm/radeon/radeon_device.c +++ drivers/gpu/drm/radeon/radeon_device.c @@ -1243,6 +1243,8 @@ int radeon_device_init(struct radeon_device *rdev, rdev->need_dma32 = true;
dma_bits = rdev->need_dma32 ? 32 : 40; + dma_bits = 32; + rdev->need_dma32 = true; r = pci_set_dma_mask(rdev->pdev, DMA_BIT_MASK(dma_bits)); if (r) { rdev->need_dma32 = true;
Grüße, Thomas