[Bug 75357] Barts (HD6850): Failure in evergreen_surface_check_2d
82.686843] radeon :01:00.0: evergreen_cs_track_validate_cb:477 cb[0] bo too small (layer size 1148928, offset 0, max layer 1, bo size 8192, slice 4487) May 23 22:05:07 mutilate warning: : [353782.686851] radeon :01:00.0: evergreen_cs_track_validate_cb:481 problematic surf: (704 408) (0 4 1 0 0 4 3) May 23 22:05:07 mutilate warning: : [353782.686854] radeon :01:00.0: evergreen_packet3_check:1970 invalid cmd stream 454 May 23 22:05:07 mutilate err: : [353782.686859] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! May 23 22:05:10 mutilate err: : [353784.942883] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x185 May 23 22:05:10 mutilate err: : [353784.942893] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! [... lots more of this ...] May 23 22:10:39 mutilate warning: : [354113.922155] radeon :01:00.0: vbo resource seems too big for the bo May 23 22:10:39 mutilate warning: : [354113.922166] radeon :01:00.0: vbo resource seems too big for the bo May 23 22:10:39 mutilate warning: : [354113.922170] radeon :01:00.0: vbo resource seems too big for the bo May 23 22:10:39 mutilate warning: : [354113.922173] radeon :01:00.0: vbo resource seems too big for the bo May 23 22:10:39 mutilate warning: : [354113.922176] radeon :01:00.0: vbo resource seems too big for the bo May 23 22:10:39 mutilate warning: : [354113.922179] radeon :01:00.0: vbo resource seems too big for the bo May 23 22:10:39 mutilate warning: : [354113.922182] radeon :01:00.0: vbo resource seems too big for the bo May 23 22:10:39 mutilate warning: : [354113.922185] radeon :01:00.0: vbo resource seems too big for the bo May 23 22:10:39 mutilate warning: : [354113.922188] radeon :01:00.0: vbo resource seems too big for the bo May 23 22:10:39 mutilate warning: : [354113.922191] radeon :01:00.0: vbo resource seems too big for the bo May 23 22:10:39 mutilate warning: : [354113.922194] radeon :01:00.0: vbo resource seems too big for the bo May 23 22:10:39 mutilate warning: : [354113.922196] radeon :01:00.0: vbo resource seems too big for the bo May 23 22:10:39 mutilate warning: : [354113.922199] radeon :01:00.0: vbo resource seems too big for the bo May 23 22:10:39 mutilate warning: : [354113.922202] radeon :01:00.0: vbo resource seems too big for the bo [... more, followed finally by ...] May 23 21:59:12 mutilate warning: : [353427.133393] radeon :01:00.0: evergreen_surface_check_2d:278 texture pitch 128 invalid must be aligned with 512 May 23 21:59:12 mutilate warning: : [353427.133402] radeon :01:00.0: evergreen_cs_track_validate_texture:827 texture invalid 0x01ec03c1 0x4013 0x060a 0x 0x8000 0x800304da May 23 21:59:12 mutilate err: : [353427.133407] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! May 23 21:59:13 mutilate err: : [353428.036913] [TTM] Could not find buffer object to map Following which the X server crashed, as above. If I start Chromium with --disable-gpu, the problem goes away in both cases, so the fault is likely either in Mesa or in the kernel or in the interaction between the two. (I had the Chromium software rendering blacklist overridden years earlier because it was trying to avoid problems that had been long fixed. I've now reversed that decision, obviously!) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150523/994aba54/attachment-0001.html>
[PATCH] drm/radeon: stop using addr to check for BO move
On 23.05.2015 20:58, Christian König wrote:
> From: Christian König
>
> It is theoretically possible that a swapped out BO gets the
> same GTT address, but different backing pages while being swapped in.
>
> Instead just use another VA state to note updated areas.
Alex, please ignore this one. I've send it out preliminary and there are
still bugs in it.
Regards,
Christian.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/radeon/radeon.h| 4 ++-
> drivers/gpu/drm/radeon/radeon_vm.c | 53
> +-
> 2 files changed, 32 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 46eb0fa..ef7df51 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -467,7 +467,6 @@ struct radeon_bo_va {
> /* protected by bo being reserved */
> struct list_headbo_list;
> uint32_tflags;
> - uint64_taddr;
> struct radeon_fence *last_pt_update;
> unsignedref_count;
>
> @@ -941,6 +940,9 @@ struct radeon_vm {
> /* BOs freed, but not yet updated in the PT */
> struct list_headfreed;
>
> + /* BOs cleared in the PT */
> + struct list_headcleared;
> +
> /* contains the page directory */
> struct radeon_bo*page_directory;
> unsignedmax_pde_used;
> diff --git a/drivers/gpu/drm/radeon/radeon_vm.c
> b/drivers/gpu/drm/radeon/radeon_vm.c
> index de42fc4..9739ded 100644
> --- a/drivers/gpu/drm/radeon/radeon_vm.c
> +++ b/drivers/gpu/drm/radeon/radeon_vm.c
> @@ -331,7 +331,6 @@ struct radeon_bo_va *radeon_vm_bo_add(struct
> radeon_device *rdev,
> bo_va->it.start = 0;
> bo_va->it.last = 0;
> bo_va->flags = 0;
> - bo_va->addr = 0;
> bo_va->ref_count = 1;
> INIT_LIST_HEAD(&bo_va->bo_list);
> INIT_LIST_HEAD(&bo_va->vm_status);
> @@ -491,9 +490,11 @@ int radeon_vm_bo_set_addr(struct radeon_device *rdev,
> }
>
> if (bo_va->it.start || bo_va->it.last) {
> - if (bo_va->addr) {
> + spin_lock(&vm->status_lock);
> + if (list_empty(&bo_va->vm_status)) {
> /* add a clone of the bo_va to clear the old address */
> struct radeon_bo_va *tmp;
> + spin_unlock(&vm->status_lock);
> tmp = kzalloc(sizeof(struct radeon_bo_va), GFP_KERNEL);
> if (!tmp) {
> mutex_unlock(&vm->mutex);
> @@ -502,14 +503,11 @@ int radeon_vm_bo_set_addr(struct radeon_device *rdev,
> tmp->it.start = bo_va->it.start;
> tmp->it.last = bo_va->it.last;
> tmp->vm = vm;
> - tmp->addr = bo_va->addr;
> tmp->bo = radeon_bo_ref(bo_va->bo);
> spin_lock(&vm->status_lock);
> list_add(&tmp->vm_status, &vm->freed);
> - spin_unlock(&vm->status_lock);
> -
> - bo_va->addr = 0;
> }
> + spin_unlock(&vm->status_lock);
>
> interval_tree_remove(&bo_va->it, &vm->va);
> bo_va->it.start = 0;
> @@ -520,10 +518,12 @@ int radeon_vm_bo_set_addr(struct radeon_device *rdev,
> bo_va->it.start = soffset;
> bo_va->it.last = eoffset - 1;
> interval_tree_insert(&bo_va->it, &vm->va);
> + spin_lock(&vm->status_lock);
> + list_add(&bo_va->vm_status, &vm->cleared);
> + spin_unlock(&vm->status_lock);
> }
>
> bo_va->flags = flags;
> - bo_va->addr = 0;
>
> soffset >>= radeon_vm_block_size;
> eoffset >>= radeon_vm_block_size;
> @@ -921,7 +921,16 @@ int radeon_vm_bo_update(struct radeon_device *rdev,
> }
>
> spin_lock(&vm->status_lock);
> - list_del_init(&bo_va->vm_status);
> + if (mem) {
> + if (list_empty(&bo_va->vm_status)) {
> + spin_unlock(&vm->status_lock);
> + return 0;
> + }
> + list_del_init(&bo_va->vm_status);
> + } else {
> + list_del(&bo_va->vm_status);
> + list_add(&bo_va->vm_status, &vm->cleared);
> + }
> spin_unlock(&vm->status_lock);
>
> bo_va->flags &= ~RADEON_VM_PAGE_VALID;
> @@ -947,10 +956,6 @@ int radeon_vm_bo_update(struct radeon_device *rdev,
> addr = 0;
> }
>
> - if (addr == bo_va->addr)
> - return 0;
> - bo_va->addr = addr;
> -
> trace_radeon_vm_bo_update(bo_va);
>
> nptes = bo_va->it.last - bo_va->it.start + 1;
> @@ -1038,7 +1043,7 @@ int radeon_vm_clear_freed(struct radeon_device *rdev,
> struct radeon_vm *vm)
> {
> struct rad
[PATCH] drm/radeon: stop using addr to check for BO move
From: Christian König
It is theoretically possible that a swapped out BO gets the
same GTT address, but different backing pages while being swapped in.
Instead just use another VA state to note updated areas.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h| 4 ++-
drivers/gpu/drm/radeon/radeon_vm.c | 53 +-
2 files changed, 32 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 46eb0fa..ef7df51 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -467,7 +467,6 @@ struct radeon_bo_va {
/* protected by bo being reserved */
struct list_headbo_list;
uint32_tflags;
- uint64_taddr;
struct radeon_fence *last_pt_update;
unsignedref_count;
@@ -941,6 +940,9 @@ struct radeon_vm {
/* BOs freed, but not yet updated in the PT */
struct list_headfreed;
+ /* BOs cleared in the PT */
+ struct list_headcleared;
+
/* contains the page directory */
struct radeon_bo*page_directory;
unsignedmax_pde_used;
diff --git a/drivers/gpu/drm/radeon/radeon_vm.c
b/drivers/gpu/drm/radeon/radeon_vm.c
index de42fc4..9739ded 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -331,7 +331,6 @@ struct radeon_bo_va *radeon_vm_bo_add(struct radeon_device
*rdev,
bo_va->it.start = 0;
bo_va->it.last = 0;
bo_va->flags = 0;
- bo_va->addr = 0;
bo_va->ref_count = 1;
INIT_LIST_HEAD(&bo_va->bo_list);
INIT_LIST_HEAD(&bo_va->vm_status);
@@ -491,9 +490,11 @@ int radeon_vm_bo_set_addr(struct radeon_device *rdev,
}
if (bo_va->it.start || bo_va->it.last) {
- if (bo_va->addr) {
+ spin_lock(&vm->status_lock);
+ if (list_empty(&bo_va->vm_status)) {
/* add a clone of the bo_va to clear the old address */
struct radeon_bo_va *tmp;
+ spin_unlock(&vm->status_lock);
tmp = kzalloc(sizeof(struct radeon_bo_va), GFP_KERNEL);
if (!tmp) {
mutex_unlock(&vm->mutex);
@@ -502,14 +503,11 @@ int radeon_vm_bo_set_addr(struct radeon_device *rdev,
tmp->it.start = bo_va->it.start;
tmp->it.last = bo_va->it.last;
tmp->vm = vm;
- tmp->addr = bo_va->addr;
tmp->bo = radeon_bo_ref(bo_va->bo);
spin_lock(&vm->status_lock);
list_add(&tmp->vm_status, &vm->freed);
- spin_unlock(&vm->status_lock);
-
- bo_va->addr = 0;
}
+ spin_unlock(&vm->status_lock);
interval_tree_remove(&bo_va->it, &vm->va);
bo_va->it.start = 0;
@@ -520,10 +518,12 @@ int radeon_vm_bo_set_addr(struct radeon_device *rdev,
bo_va->it.start = soffset;
bo_va->it.last = eoffset - 1;
interval_tree_insert(&bo_va->it, &vm->va);
+ spin_lock(&vm->status_lock);
+ list_add(&bo_va->vm_status, &vm->cleared);
+ spin_unlock(&vm->status_lock);
}
bo_va->flags = flags;
- bo_va->addr = 0;
soffset >>= radeon_vm_block_size;
eoffset >>= radeon_vm_block_size;
@@ -921,7 +921,16 @@ int radeon_vm_bo_update(struct radeon_device *rdev,
}
spin_lock(&vm->status_lock);
- list_del_init(&bo_va->vm_status);
+ if (mem) {
+ if (list_empty(&bo_va->vm_status)) {
+ spin_unlock(&vm->status_lock);
+ return 0;
+ }
+ list_del_init(&bo_va->vm_status);
+ } else {
+ list_del(&bo_va->vm_status);
+ list_add(&bo_va->vm_status, &vm->cleared);
+ }
spin_unlock(&vm->status_lock);
bo_va->flags &= ~RADEON_VM_PAGE_VALID;
@@ -947,10 +956,6 @@ int radeon_vm_bo_update(struct radeon_device *rdev,
addr = 0;
}
- if (addr == bo_va->addr)
- return 0;
- bo_va->addr = addr;
-
trace_radeon_vm_bo_update(bo_va);
nptes = bo_va->it.last - bo_va->it.start + 1;
@@ -1038,7 +1043,7 @@ int radeon_vm_clear_freed(struct radeon_device *rdev,
struct radeon_vm *vm)
{
struct radeon_bo_va *bo_va;
- int r;
+ int r = 0;
spin_lock(&vm->status_lock);
while (!list_empty(&vm->freed)) {
@@ -1049,14 +1054,15 @@ int radeon_vm_clear_freed(struct radeon_device *rdev,
r = radeon_vm_bo_update(rdev, bo_va, NULL);
[Bug 90378] [LLVM][bisected] GPU lockups in Left 4 Dead 2
https://bugs.freedesktop.org/show_bug.cgi?id=90378 --- Comment #5 from Daniel Scharrer --- While the glitches come from an earlier revision than the GPU lockups, both are caused by the machine scheduler. Disabling the machine scheduler for SI fixes both the glitches and the GPU lockups. See bug 88978 for details. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150523/698566de/attachment.html>
[Bug 88561] [radeonsi][regression, bisected] Depth test/buffer issues in Portal
https://bugs.freedesktop.org/show_bug.cgi?id=88561 Daniel Scharrer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Daniel Scharrer --- I think Marek's patch fixed the original Portal issue I bisected in radeonsi. The remakning glitches seem to be caused by a LLVM regression. I've added the relevant information to bug #88978. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150523/2ffd334d/attachment-0001.html>
[Bug 88978] [bisected] [SI Scheduler] Graphical corruption in Dota 2
https://bugs.freedesktop.org/show_bug.cgi?id=88978 --- Comment #13 from Daniel Scharrer --- Created attachment 115997 --> https://bugs.freedesktop.org/attachment.cgi?id=115997&action=edit R600_DEBUG=ps,vs,gs output for the Talos trace with r227461 (lockups) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150523/1e194a9b/attachment.html>
[Bug 88978] [bisected] [SI Scheduler] Graphical corruption in Dota 2
https://bugs.freedesktop.org/show_bug.cgi?id=88978 --- Comment #12 from Daniel Scharrer --- Created attachment 115996 --> https://bugs.freedesktop.org/attachment.cgi?id=115996&action=edit R600_DEBUG=ps,vs,gs output for the Talos trace with r227460 (no lockups) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150523/0bfd90d6/attachment.html>
[Bug 88978] [bisected] [SI Scheduler] Graphical corruption in Dota 2
https://bugs.freedesktop.org/show_bug.cgi?id=88978 --- Comment #11 from Daniel Scharrer --- Created attachment 115995 --> https://bugs.freedesktop.org/attachment.cgi?id=115995&action=edit patch to disable the machine scheduler for SI I can confirm that these these glitches are still present on current LLVM + Mesa git with a 7950 (TAHITI). Glitches happen in various games with different engines (Source, Unity, â¦). Here is a trace of The Talos Principle (first posted in bug #88561 comment 9), that still produces more than just occasional glitches (even with Marek's patch): http://constexpr.org/tmp/Talos-radeonsi.3.trace.xz (147 MiB) Like sarnex, I have bisected this to LLVM 51a3c27d6e0c66cc8d2d1da8e9205fec7b74ca5c (r227461). I had to revert b8797a7 and a99a16a in current Mesa git for it to build against that LLVM revision. Some Source engine games (L4D2, Nuclear Dawn, maybe others) don't just produce graphical glitches but also frequently lock up the GPU since a later change to the machine scheduler (r233366) - see bug #90378. Disabling the machine scheduler for SI on current LLVM (see attached patch) also fixes both the lockups an graphical glitches. Additionally, using R600_DEBUG=switch_on_eop with unpatched LLVM also works around both the graphical glitches and and GPU lockups. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150523/6c4ff000/attachment.html>
[Nouveau] [PATCH v2] nouveau: add coherent BO attribute
On Fri, May 22, 2015 at 3:23 AM, Martin Peres wrote: > On 21/05/2015 11:47, Ben Skeggs wrote: >> >> On 21 May 2015 at 16:08, Alexandre Courbot wrote: >>> >>> Add a flag allowing Nouveau to specify that an object should be coherent >>> at allocation time. This is required for some class of objects like >>> fences which are randomly-accessed by both the CPU and GPU. This flag >>> instructs the kernel driver to make sure the object remains coherent >>> even on architectures for which coherency is not guaranteed by the bus. >>> >>> Signed-off-by: Alexandre Courbot >> >> Reviewed-by: Ben Skeggs > > > Pushed! Thanks! Should we also bump the ABI version or something?
[PATCH 1/2] drm/nouveau: add staging module option
On Thu, May 21, 2015 at 5:35 PM, Ben Skeggs wrote:
> On 21 May 2015 at 16:04, Alexandre Courbot wrote:
>> On Thu, May 21, 2015 at 2:55 PM, Ben Skeggs wrote:
>>> On 21 May 2015 at 15:49, Alexandre Courbot wrote:
On Thu, May 21, 2015 at 1:48 PM, Ben Skeggs wrote:
> On 20 May 2015 at 15:56, Alexandre Courbot wrote:
>> Add a module option allowing to enable staging/unstable APIs. This will
>> allow us to experiment freely with experimental APIs for a while before
>> setting them in stone.
>>
>> Signed-off-by: Alexandre Courbot
>> ---
>> drm/nouveau/nouveau_drm.c | 18 ++
>> drm/nouveau/uapi/drm/nouveau_drm.h | 3 +++
>> 2 files changed, 21 insertions(+)
>>
>> diff --git a/drm/nouveau/nouveau_drm.c b/drm/nouveau/nouveau_drm.c
>> index 89049335b738..e4bd6ed51e73 100644
>> --- a/drm/nouveau/nouveau_drm.c
>> +++ b/drm/nouveau/nouveau_drm.c
>> @@ -75,6 +75,10 @@ MODULE_PARM_DESC(runpm, "disable (0), force enable
>> (1), optimus only default (-1
>> int nouveau_runtime_pm = -1;
>> module_param_named(runpm, nouveau_runtime_pm, int, 0400);
>>
>> +MODULE_PARM_DESC(staging, "enable staging APIs");
>> +int nouveau_staging = 0;
>> +module_param_named(staging, nouveau_staging, int, 0400);
>> +
>> static struct drm_driver driver_stub;
>> static struct drm_driver driver_pci;
>> static struct drm_driver driver_platform;
>> @@ -895,6 +899,7 @@ nouveau_ioctls[] = {
>> DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_PREP,
>> nouveau_gem_ioctl_cpu_prep, DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
>> DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_FINI,
>> nouveau_gem_ioctl_cpu_fini, DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
>> DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info,
>> DRM_UNLOCKED|DRM_AUTH|DRM_RENDER_ALLOW),
>> + /* Staging ioctls */
>> };
>>
>> long
>> @@ -1027,6 +1032,7 @@ static void nouveau_display_options(void)
>> DRM_DEBUG_DRIVER("... runpm: %d\n", nouveau_runtime_pm);
>> DRM_DEBUG_DRIVER("... vram_pushbuf : %d\n",
>> nouveau_vram_pushbuf);
>> DRM_DEBUG_DRIVER("... pstate : %d\n", nouveau_pstate);
>> + DRM_DEBUG_DRIVER("... staging : %d\n", nouveau_staging);
>> }
>>
>> static const struct dev_pm_ops nouveau_pm_ops = {
>> @@ -1088,6 +1094,18 @@ err_free:
>> static int __init
>> nouveau_drm_init(void)
>> {
>> + /* Do not register staging ioctsl if option not specified */
>> + if (!nouveau_staging) {
>> + unsigned i;
>> +
>> + /* This keeps us safe is no staging ioctls are defined */
>> + i = min(driver_stub.num_ioctls,
>> DRM_NOUVEAU_STAGING_IOCTL);
>> + while (!nouveau_ioctls[i - 1].func)
>> + i--;
>> +
>> + driver_stub.num_ioctls = i;
>> + }
> Hey Alex,
>
> I've got no specific objection. But I'm curious as to why you took
> this approach as opposed to just adding "if (!nouveau_staging) return
> -EINVAL;" directly in the experimental ioctls?
Mainly because we will likely forget to add this check (or to remove
it) in some of the staging ioctls. The current solution doesn't
require us to think about that - and the less things to think about,
the better.
> I think, in line with
> what's been done in other places, having module options per-api is
> perhaps a better choice too.
Do you mean that each experimental ioctl should have its own enable
option? I don't mind going that way if you think it is preferable. And
in that case my comment above is void.
>>> That would be more preferable I think, and obvious as to what exactly
>>> you're enabling.
>>>
But actually I wonder if having these experimental ioctls enabled as
compile options (either individually or as a whole) would not be
better. Some experimental ioctls may require code in staging (like the
PUSHBUF_2 ioctl that I would like to submit next), and I don't think
it is desirable to force extra code or kernel options (in this case,
CONFIG_STAGING) to Nouveau users who will not make use of them. I
remember that we concluded in favor or module options on IRC, but in
the light of this, wouldn't a config option be a less intrusive
choice?
>>> Right, but the whole point of this is to encourage the ioctls to not
>>> live there for too long, and progress to fully supported interfaces.
>>
>> Definitely, but my concern is that doing this will make Nouveau depend
>> on STAGING for at least short periods of time. Do we really want this?
> I admit to having slightly misread your last paragraph. For cases
> such as thas, a config option that depends on STAGING *and* the kernel
>
[Intel-gfx] drivers/gpu/drm/i915/i915_gem_gtt.c
On Fri, May 22, 2015 at 02:17:32PM -0700, Andrew Morton wrote: > I'm not sure what's happened to the drm code in linux-next - it's > exploding all over the place. Did someone turn on -Werror without > doing anywhere near enough testing? > > Anyway, I don't know how to fix this i386 build error: Seems like you have CONFIG_DRM_I915_WERROR set? We explicitely made sure to not enable -Werror by default, because different versions of gcc will generate different set of warnings making it roughly impossible to use -Werror by default (say, newer versions of gcc with more clever warnings trying to compile old commits while bisecting) -- Damien
[Bug 77394] Radeon R9 270X GPU lockup on power profile change
https://bugs.freedesktop.org/show_bug.cgi?id=77394 --- Comment #16 from nine at detonation.org --- Today I finally made decent progress on this issue. I can confirm that the GPU lockups are not the X server's fault, since they appear also when using weston and indeed, when running the eglkms Mesa demo on the pure framebuffer. Trying to find the exact OpenGL call that causes the lockup, I discovered, that when I change the power profile before starting any GL program (Mesa demo or display server), it continues to work until the next reboot. So all that was needed was a echo low > /sys/class/drm/card0/device/power_profile executed before starting the X server and I could change power profile at runtime. I then turned on dpm again and indeed: echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level echo auto > /sys/class/drm/card0/device/power_dpm_force_performance_level called by an ExecStartPre script from the display-server service file fixes the issue completely for me and I have now a fully working dpm :) So it seems like the first change of performance level/profile initializes something that must be initialized before the first GL call or CRTC change for power management to be stable. Any idea what this something might be? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150523/e100fb47/attachment-0001.html>
[Intel-gfx] drivers/gpu/drm/i915/i915_gem_gtt.c
On Sat, 23 May 2015 14:30:09 +0100 Damien Lespiau wrote: > On Fri, May 22, 2015 at 02:17:32PM -0700, Andrew Morton wrote: > > I'm not sure what's happened to the drm code in linux-next - it's > > exploding all over the place. Did someone turn on -Werror without > > doing anywhere near enough testing? > > > > Anyway, I don't know how to fix this i386 build error: > > Seems like you have CONFIG_DRM_I915_WERROR set? Yes. > We explicitely made sure to not enable -Werror by default, `make allmodconfig' enables CONFIG_DRM_I915_WERROR. I'm not sure what is the approved way of fixing this. Perhaps disabling CONFIG_DRM_I915_WERROR when CONFIG_COMPILE_TEST=y.
[git pull] drm fixes
On 23 May 2015 at 07:34, Linus Torvalds wrote: > On Thu, May 21, 2015 at 8:39 PM, Dave Airlie wrote: >> >> radeon has two displayport fixes, one for a regressions, >> i915 regression flicker fix needed to 4.0 can get fixed. > > Ok, I'm used to fixing up your whitespace and lack of capitalization, > but you're getting so incoherent that I can no longer even parse it > well enough to fix it up. > > English *is* your first language, right? Could you please re-phrase > > "i915 regression flicker fix needed to 4.0 can get fixed" > > because it's not really making sense to me, and I want my commit > messages to make sense. Really ^to^so i915: fix flicker regression from 4.0, patch required so 4.0 can get fix backported. Dave.
[Bug 77394] Radeon R9 270X GPU lockup on power profile change
https://bugs.freedesktop.org/show_bug.cgi?id=77394 nine at detonation.org changed: What|Removed |Added Summary|Desktop freezes often when |Radeon R9 270X GPU lockup |KDE starts compositing or |on power profile change |mplayer GL window changes | -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150523/833f78cc/attachment.html>
[Bug 90537] radeonsi bo/va conflict on RADEON_GEM_VA (rscreen->ws->buffer_from_handle returns NULL)
https://bugs.freedesktop.org/show_bug.cgi?id=90537 --- Comment #11 from pstglia at gmail.com --- (In reply to pstglia from comment #10) > > BTW: Is it sufficient to put the ISO on an USB stick with usb-creator-gtk to > > get a bootable Android? > > > > If yes then I'm clearly going to try that sooner or later. > > Never tried usb-creator-gtk. But "dd" works just fine (/dev/sdb is the > device mapped to my usb flash drive): > > dd if=android-x86-5.1_kernel_4.0.3_mesa_10.5.4_radeonsi_test_20150521.iso > of=/dev/sdb bs=65535 And yes, it is a bootable Android image (bootable under bios legacy mode - a UEFI img can also be generated). This img has no google apps (but you can download apps/apks from sites like www.apkmirror.com) or houdini (ARM binary translator). Many apps can run on it (those which depend on Dalvik) and some have x86 version (Like Angry Birds Series). About the tests, still waiting for more feedback from more users ( Android-x86 topic is https://groups.google.com/forum/#!topic/android-x86/AayRmQiZAlw ) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150523/20030e5d/attachment.html>
