http://bugs.freedesktop.org/show_bug.cgi?id=20211
Summary: Runing Kubrick game maximized freezes X and causes
kernel panic
Product: DRI
Version: XOrg CVS
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
http://bugs.freedesktop.org/show_bug.cgi?id=20211
--- Comment #1 from Jure Repinc 2009-02-19 01:30:09 PST
---
Created an attachment (id=23111)
--> (http://bugs.freedesktop.org/attachment.cgi?id=23111)
Xorg.0.log
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
-
http://bugzilla.kernel.org/show_bug.cgi?id=12613
mmvi...@yahoo.com changed:
What|Removed |Added
CC||mmvi...@yahoo.com
--- Comment #
On Wed, 2009-02-18 at 11:38 -0500, k...@bitplanet.net wrote:
> From: Kristian Høgsberg
>
> A number of GEM operations (and legacy drm ones) want to copy data to
> or from userspace while holding the struct_mutex lock. However, the
> fault handler calls us with the mmap_sem held and thus enforces
On Thu, 2009-02-19 at 10:19 +0100, Peter Zijlstra wrote:
> On Wed, 2009-02-18 at 11:38 -0500, k...@bitplanet.net wrote:
> > From: Kristian Høgsberg
> >
> > A number of GEM operations (and legacy drm ones) want to copy data to
> > or from userspace while holding the struct_mutex lock. However, th
On 19.02.2009 12:23, Arkadi Shishlov wrote:
> Roland Scheidegger wrote:
>> I suspect you're hitting a r200 asic bug, which isn't present in rv250
>> and other r200 family members. There are workarounds in the driver for
>> this (see r200UpdateTextureState), but to my knowledge they are
>> insuffici
Roland Scheidegger wrote:
> I suspect you're hitting a r200 asic bug, which isn't present in rv250
> and other r200 family members. There are workarounds in the driver for
> this (see r200UpdateTextureState), but to my knowledge they are
> insufficient for two-pass ATI_fragment_shader shaders. Ther
On Thu, Feb 19, 2009 at 10:19:05AM +0100, Peter Zijlstra wrote:
> On Wed, 2009-02-18 at 11:38 -0500, k...@bitplanet.net wrote:
> > From: Kristian Høgsberg
> >
> > A number of GEM operations (and legacy drm ones) want to copy data to
> > or from userspace while holding the struct_mutex lock. Howe
On Wednesday 18 February 2009, David Miller wrote:
> drm: Only use DRM_IOCTL_UPDATE_DRAW compat wrapper for compat X86.
>
> Only X86 32-bit uses a different alignment for "unsigned long long"
> than it's 64-bit counterpart.
>
> Therefore this compat translation is only correct, and only needed,
>
On Thu, Feb 19, 2009 at 7:26 AM, Roland Scheidegger
wrote:
> On 19.02.2009 12:23, Arkadi Shishlov wrote:
>> Roland Scheidegger wrote:
>>> I suspect you're hitting a r200 asic bug, which isn't present in rv250
>>> and other r200 family members. There are workarounds in the driver for
>>> this (see
http://bugs.freedesktop.org/show_bug.cgi?id=20211
Alex Deucher changed:
What|Removed |Added
Attachment #23111|application/x-trash |text/plain
mime type|
On Thu, 2009-02-19 at 11:33 +0100, Peter Zijlstra wrote:
> On Thu, 2009-02-19 at 10:19 +0100, Peter Zijlstra wrote:
> > On Wed, 2009-02-18 at 11:38 -0500, k...@bitplanet.net wrote:
> > > From: Kristian Høgsberg
> > >
> > > A number of GEM operations (and legacy drm ones) want to copy data to
> >
On Thu, Feb 19, 2009 at 15:46, Alex Deucher wrote:
> On Thu, Feb 19, 2009 at 7:26 AM, Roland Scheidegger
> wrote:
>> On 19.02.2009 12:23, Arkadi Shishlov wrote:
>>> Roland Scheidegger wrote:
I suspect you're hitting a r200 asic bug, which isn't present in rv250
and other r200 family mem
On Thu, Feb 19, 2009 at 9:51 AM, Stephane Marchesin
wrote:
> On Thu, Feb 19, 2009 at 15:46, Alex Deucher wrote:
>> On Thu, Feb 19, 2009 at 7:26 AM, Roland Scheidegger
>> wrote:
>>> On 19.02.2009 12:23, Arkadi Shishlov wrote:
Roland Scheidegger wrote:
> I suspect you're hitting a r200 as
On Mon, 2009-02-16 at 10:55 -0800, Jesse Barnes wrote:
> On Sunday, February 15, 2009 4:02 pm Chris Wilson wrote:
> > On my i915, the flip never occurs and we wait forever on the the vblank.
> > So I presume the command we sent the chip is invalid, or we miss the
> > irq? (I double-checked with loc
On Thu, 2009-02-19 at 16:17 +0100, Nick Piggin wrote:
> On Thu, Feb 19, 2009 at 09:49:40AM -0500, Kristian Høgsberg wrote:
> >
> > > Secondly, mmap_sem is not a recursive lock (very few kernel locks are,
> > > and we generally frown upon recursive locking schemes), this means that
> > > the fault
On Thu, Feb 19, 2009 at 09:49:40AM -0500, Kristian Høgsberg wrote:
>
> > Secondly, mmap_sem is not a recursive lock (very few kernel locks are,
> > and we generally frown upon recursive locking schemes), this means that
> > the fault handler still cannot function properly.
>
> I understand, but w
With a few additional suggestions by Jesse, I've managed to get
tear-free compositing working on i915. Here's the diff on top of the
original patch (though obviously this is just a suggestion, still need
to prevent multiple pending flips to the same plane and ensure that the
old buffer is eventuall
Peter Zijlstra wrote:
> On Tue, 2009-02-17 at 16:59 -0800, Eric Anholt wrote:
>
>> The basic problem was
>> mmap_sem (do_mmap()) -> struct_mutex (drm_gem_mmap(), i915_gem_fault())
>> struct_mutex (i915_gem_execbuffer()) -> mmap_sem (copy_from/to_user())
>>
>
> That's not the only problem, t
On Wed, 18 Feb 2009 15:41:02 -0800 (PST)
David Miller wrote:
>
> Platforms such as sparc64 have D-cache aliasing issues. We
> cannot allow virtual mappings in different contexts to be such
> that two cache lines can be loaded for the same backing data.
> Updates to one cache line won't be seen
On Thursday 19 February 2009 06:55:28 Chris Wilson wrote:
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 3795dbc..93e677a 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -435,6 +435,8 @@ EXPORT_SYMBOL(drm_vblank_get);
> */
> void drm_
On Thursday 19 February 2009 11:37:01 Chris Wilson wrote:
> With a few additional suggestions by Jesse, I've managed to get
> tear-free compositing working on i915. Here's the diff on top of the
> original patch (though obviously this is just a suggestion, still need
> to prevent multiple pending f
On Thursday 19 February 2009 16:43:54 Jesse Barnes wrote:
> On Thursday 19 February 2009 11:37:01 Chris Wilson wrote:
> > With a few additional suggestions by Jesse, I've managed to get
> > tear-free compositing working on i915. Here's the diff on top of the
> > original patch (though obviously thi
Hi Linus,
Please pull the 'drm-fixes' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes
Intel: This contains one lockdep fix, the other is still under discussion
along with a few locking and error path fixes. It also contains some
minor kms updates for
On Thu, 2009-02-19 at 23:26 +0100, Peter Zijlstra wrote:
> On Thu, 2009-02-19 at 22:02 +0100, Thomas Hellstrom wrote:
> >
> > It looks to me like the driver preferred locking order is
> >
> > object_mutex (which happens to be the device global struct_mutex)
> > mmap_sem
> > offset_mutex.
Attached is a new DRI2 flush extension that allows the driver to perform
a "real flush" before dispatching a swap or Xserver copy operation.
Currently we do this before a DRI2CopyRegion() call.
This allows drivers a real "end of scene" flush to ensure rendering is
complete prior to a swap.
I've
On Thu, 2009-02-19 at 22:02 +0100, Thomas Hellstrom wrote:
>
> It looks to me like the driver preferred locking order is
>
> object_mutex (which happens to be the device global struct_mutex)
> mmap_sem
> offset_mutex.
>
> So if one could avoid using the struct_mutex for object bookkeepin
>-Original Message-
>From: intel-gfx-boun...@lists.freedesktop.org
>[mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Jesse Barnes
>Sent: 2009年2月20日 8:48
>To: dri-devel@lists.sourceforge.net
>Cc: intel-...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCH] i915: add page fl
On Thu, 2009-02-19 at 18:04 -0800, Eric Anholt wrote:
> On Thu, 2009-02-19 at 23:26 +0100, Peter Zijlstra wrote:
> > On Thu, 2009-02-19 at 22:02 +0100, Thomas Hellstrom wrote:
> > >
> > > It looks to me like the driver preferred locking order is
> > >
> > > object_mutex (which happens to be the
29 matches
Mail list logo
