linux-kernel - Re: [PATCH] drm/i915,agp/intel: Do not clear stolen entries

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]

Message-Id: <849307$bc24ct@azsmga001.ch.intel.com>
Date:	Sun, 30 Jan 2011 09:55:34 +0000
From:	Chris Wilson <chris@...is-wilson.co.uk>
To:	Mario Kleiner <mario.kleiner@...bingen.mpg.de>,
	Hugh Dickins <hughd@...gle.com>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	linux-kernel@...r.kernel.org,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Arnd Bergmann <arnd@...db.de>, Jiri Olsa <jolsa@...hat.com>,
	Chris Clayton <chris2553@...glemail.com>,
	Mario Kleiner <mario.kleiner@...bingen.mpg.de>
Subject: Re: [PATCH] drm/i915,agp/intel: Do not clear stolen entries

> On Jan 30, 2011, at 1:28 AM, Hugh Dickins wrote:
> > I just tried setting the debug to 7 for a few seconds on 2.6.37, where
> > I see no problem: I appear to get the "pipe a underrun" messages with
> > that too; and the drm_ioctl messages, but much much fewer of them.
> > Though I've been veering between i386 and x86_64 in these tests, so
> > keep that in mind if what I'm saying makes no sense: the huge number
> > of drm_ioctls was with 2.6.36-rc2 (plus some of Chris's fixes) on
> > i386; the 64 underruns per second was with 2.6.36-rc2 (plus some of

There shouldn't be any difference between the drm_ioctl() calls between
2.6.37 and 2.6.38 as the userspace is the same. I think this might the
crux of the issue. Can you attach a drm.debug=0xe boot dmesg, and a sample
of drm.debug=0x7 during the busy period for .37 and .38? And also your
Xorg.0.log.

Running fvwm and a couple of xterms you should not be utilizing vblanks at
all (not even suffering the vblank interrupt being enabled) so this code
should not even be causing unwanted side-effects. Bizarre.

The delay in characters showing up is a bug in the ddx; the render queue
is not being flushed before X goes to sleep. It's either the batch not
being submitted or the render cache not being flushed to the scan out in a
timely manner. (And these bugs can be complicated further by the
introduction of a compositing WM.) Both bugs have existed off-and-on in
the ddx over the years. And over time, we have weaned the kernel from
flushing the graphics caches unnecessarily; though the larger impact would
have been during the .37 cycle, at least the ones that sprang to mind as
likely candidates.

The pipe-a underrun is a nuisance; at best nothing will happen, there's an
outside chance that your display may flicker and at worst your machine may
hard hang.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/