On Mon, 2010-09-27 at 21:08 +0100, Chris Wilson wrote:
> Hook the GEM vm open/close ops into the generic drm vm open/close so
> that the vma entries are created and destroy appropriately.
>
> Reported-by: Matt Mackall
> Cc: Dave Airlie
> Cc: Jesse Barnes
> Signed-off-by: Chris Wilson
All sign
On Mon, 2010-09-27 at 21:08 +0100, Chris Wilson wrote:
> Hook the GEM vm open/close ops into the generic drm vm open/close so
> that the vma entries are created and destroy appropriately.
>
> Reported-by: Matt Mackall
> Cc: Dave Airlie
> Cc: Jesse Barnes
> Signed-off-by: Chris Wilson
All sign
https://bugs.freedesktop.org/show_bug.cgi?id=30551
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=30551
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=30551
Summary: r600c: Segfaults with Evergreen
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component
https://bugs.freedesktop.org/show_bug.cgi?id=30551
Summary: r600c: Segfaults with Evergreen
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component
From: Andrew Morton
drivers/gpu/drm/radeon/atom.c: In function 'atom_op_delay':
drivers/gpu/drm/radeon/atom.c:653: warning: comparison is always false due to
limited range of data type
Cc: David Airlie
Cc: Alex Deucher
Cc: Matt Turner
Signed-off-by: Andrew Morton
---
drivers/gpu/drm/radeo
From: Andrew Morton
drivers/gpu/drm/radeon/atom.c: In function 'atom_op_delay':
drivers/gpu/drm/radeon/atom.c:653: warning: comparison is always false due to
limited range of data type
Cc: David Airlie
Cc: Alex Deucher
Cc: Matt Turner
Signed-off-by: Andrew Morton
---
drivers/gpu/drm/radeo
> >
> > We had an unplanned leak/race finding week:
>
> Updated pull request, TTM extra fix, GEM updated patch with tested by
> lines, and some urgent vmwgfx oops/fixes. (vmwgfx is in staging still,
> though I need to discuss that with vmware).
Today is proof the phenylephrine is a poor subst
The above mentioned commit didn't queue the buffer on the delayed destroy
list under some rare circumstances. It also didn't completely honor the
remove_all parameter.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c | 15 +++
1 files changed, 11 insertions(+), 4 de
On 22/09/10 22:55, Adam Jackson wrote:
> Yeah, I hate to just drop extension blocks, but it's better than the
> alternative. They're optional for a reason I suppose.
>
For my EIZO S2242W the base block is fine, but the extension block is
all zeros. Without this patch I get no X and no VT
Hmm. Forget this patch! I must have been extremely tired today. A new
one coming up in a moment.
/Thomas
On 10/01/2010 10:09 AM, Thomas Hellstrom wrote:
> The commit "drm/ttm: Fix two race conditions"
> was missing a return statement in a very unlikely code path.
>
> Signed-off-by: Thomas Hells
If the soon-to-be scanout buffer is partly covering the intended
VRAM region, move and pin will fail. In that case, just move it out
to system before attempting to move it in again.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c |5 +
1 files changed, 5 insertions
The removed code causes oopses with newer drms on master drop.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 6b
This is to avoid accessing uninitialized data during
drm_irq_uninstall and vblank ioctls. At the same time, enable error check from
drm_kms_init which previously appeared to ignore all errors.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 47 +++-
We add an option not to enable fbdev, this option is off (0) by default.
Not enabling fbdev at load time makes it possible to co-operate with
vga16fb and vga text mode when VT switching.
However, if 3D resources are active when VT switching, we're currently
not able to switch over to vga, due to d
These are fixes that should, if at all possible, make it into 2.6.36.
They are extracted from the previous patch series, "vmwgfx updates".
I will respin the rest of the patches for possible inclusion into drm-next.
I've renamed some patches and added some comment to emphasise the
fixes in them rat
On Thu, Sep 30, 2010 at 12:36:45 +0200, Thomas Hellstrom wrote:
> This fixes a race pointed out by Dave Airlie where we don't take a buffer
> object about to be destroyed off the LRU lists properly. It also fixes a rare
> case where a buffer object could be destroyed in the middle of an
> accelera
The commit "drm/ttm: Fix two race conditions"
was missing a return statement in a very unlikely code path.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/
> Hi Linus,
>
> We had an unplanned leak/race finding week:
Updated pull request, TTM extra fix, GEM updated patch with tested by
lines, and some urgent vmwgfx oops/fixes. (vmwgfx is in staging still,
though I need to discuss that with vmware).
Dave.
> Had a pretty nasty race in TTM reporte
Hi Linus,
We had an unplanned leak/race finding week:
Had a pretty nasty race in TTM reported (scrolling certain pages in
firefox caused a major leak of objects), fix from Thomas in here.
A nasty slow leak in the i915 GEM code, fix from Chris here.
A race on object deletion in the GEM code, fi
https://bugs.freedesktop.org/show_bug.cgi?id=30265
Nicolas Kaiser changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=30265
Nicolas Kaiser changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On 22/09/10 22:55, Adam Jackson wrote:
Yeah, I hate to just drop extension blocks, but it's better than the
alternative. They're optional for a reason I suppose.
For my EIZO S2242W the base block is fine, but the extension block is
all zeros. Without this patch I get no X and no VTs.
I suspe
> >
> > We had an unplanned leak/race finding week:
>
> Updated pull request, TTM extra fix, GEM updated patch with tested by
> lines, and some urgent vmwgfx oops/fixes. (vmwgfx is in staging still,
> though I need to discuss that with vmware).
Today is proof the phenylephrine is a poor subst
The above mentioned commit didn't queue the buffer on the delayed destroy
list under some rare circumstances. It also didn't completely honor the
remove_all parameter.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c | 15 +++
1 files changed, 11 insertions(+), 4 de
Hmm. Forget this patch! I must have been extremely tired today. A new
one coming up in a moment.
/Thomas
On 10/01/2010 10:09 AM, Thomas Hellstrom wrote:
The commit "drm/ttm: Fix two race conditions"
was missing a return statement in a very unlikely code path.
Signed-off-by: Thomas Hellstrom
> Hi Linus,
>
> We had an unplanned leak/race finding week:
Updated pull request, TTM extra fix, GEM updated patch with tested by
lines, and some urgent vmwgfx oops/fixes. (vmwgfx is in staging still,
though I need to discuss that with vmware).
Dave.
> Had a pretty nasty race in TTM reporte
If the soon-to-be scanout buffer is partly covering the intended
VRAM region, move and pin will fail. In that case, just move it out
to system before attempting to move it in again.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c |5 +
1 files changed, 5 insertions
The removed code causes oopses with newer drms on master drop.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 6b
This is to avoid accessing uninitialized data during
drm_irq_uninstall and vblank ioctls. At the same time, enable error check from
drm_kms_init which previously appeared to ignore all errors.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 47 +++-
We add an option not to enable fbdev, this option is off (0) by default.
Not enabling fbdev at load time makes it possible to co-operate with
vga16fb and vga text mode when VT switching.
However, if 3D resources are active when VT switching, we're currently
not able to switch over to vga, due to d
These are fixes that should, if at all possible, make it into 2.6.36.
They are extracted from the previous patch series, "vmwgfx updates".
I will respin the rest of the patches for possible inclusion into drm-next.
I've renamed some patches and added some comment to emphasise the
fixes in them rat
On Thu, Sep 30, 2010 at 12:36:45 +0200, Thomas Hellstrom wrote:
> This fixes a race pointed out by Dave Airlie where we don't take a buffer
> object about to be destroyed off the LRU lists properly. It also fixes a rare
> case where a buffer object could be destroyed in the middle of an
> accelera
The commit "drm/ttm: Fix two race conditions"
was missing a return statement in a very unlikely code path.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/
35 matches
Mail list logo
