linux-kernel - Re: radeon: screen garbled after page allocator change, was: Re: [patch v2 3/3] mm: page

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 28 Apr 2014 11:09:00 +0200
From:	Thomas Schwinge <thomas@...esourcery.com>
To:	Jerome Glisse <j.glisse@...il.com>
CC:	Mel Gorman <mgorman@...e.de>, Rik van Riel <riel@...riel.com>,
	"Andrea Arcangeli" <aarcange@...hat.com>,
	Zlatko Calusic <zcalusic@...sync.net>,
	Minchan Kim <minchan@...nel.org>, <linux-mm@...ck.org>,
	<linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Alex Deucher <alexander.deucher@....com>,
	Christian König <christian.koenig@....com>,
	<dri-devel@...ts.freedesktop.org>,
	"Johannes Weiner" <hannes@...xchg.org>
Subject: Re: radeon: screen garbled after page allocator change, was: Re: [patch v2 3/3] mm: page_alloc: fair zone allocator policy

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@...il.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@...xchg.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

Content of type "application/pgp-signature" skipped