[Bug 82714] New: nouveau: fails to properly initialize GPU

2014-08-16 Thread bugzilla-dae...@freedesktop.org 
NFO: drm_shared: display 0x2086410 DPMS is ON
[.683910] INFO: video_drm2d: activating display 0x2086410 to 1280x1024
[.719635] INFO: drm_shared: setting DPMS of display 0x2086410 to ON
[.887825] INFO: video_drm2d: activating display 0x2084720 to 1280x1024


[  465.815141] BUG: unable to handle kernel paging request at 88030e343ffc
[  465.815228] IP: [] evo_wait+0x5e/0x150 [nouveau]
[  465.815314] PGD 2350067 PUD 0 
[  465.815344] Oops: 0002 [#1] SMP 
[  465.815374] Modules linked in: nouveau
[  465.815435] CPU: 2 PID: 1588 Comm: kmscon Not tainted 3.17.0-rc1-kvm+ #4
[  465.815481] Hardware name: Gigabyte Technology Co., Ltd.
GA-A75M-UD2H/GA-A75M-UD2H, BIOS F6 09/28/2012
[  465.815541] task: 8800be8c1700 ti: 8800b83b8000 task.ti:
8800b83b8000
[  465.815589] RIP: 0010:[]  []
evo_wait+0x5e/0x150 [nouveau]
[  465.815670] RSP: 0018:8800b83bb978  EFLAGS: 00010206
[  465.815714] RAX: 88020e344000 RBX: 880214400af0 RCX:
c228
[  465.815758] RDX: 0001 RSI: 0080 RDI:
880214400bf0
[  465.815800] RBP: 8800b83bb998 R08: 8800b83b8000 R09:

[  465.815842] R10: 0400 R11:  R12:
3fff
[  465.815885] R13: 880214400bf0 R14: 407f R15:

[  465.815933] FS:  7f420afca700() GS:88021ec8()
knlGS:
[  465.815980] CS:  0010 DS:  ES:  CR0: 80050033
[  465.816016] CR2: 88030e343ffc CR3: b65d9000 CR4:
07e0
[  465.816071] Stack:
[  465.816090]  0010 880213b6c218 88021440
88020c533538
[  465.816151]  8800b83bba08 a00b35be 8800b83bb9d8
880214400af0
[  465.816214]  88021440 a00b03d5 880213b6c218
88021440
[  465.816295] Call Trace:
[  465.816344]  [] nv50_display_flip_next+0x7ee/0x860
[nouveau]
[  465.816411]  [] ? evo_kick+0x35/0x60 [nouveau]
[  465.816476]  [] nv50_crtc_commit+0x107/0x240 [nouveau]
[  465.816521]  [] drm_crtc_helper_set_mode+0x42b/0x570
[  465.816562]  [] drm_crtc_helper_set_config+0x805/0xa30
[  465.816604]  [] ? drm_mode_setcrtc+0x312/0x580
[  465.816670]  [] nouveau_crtc_set_config+0x60/0x130
[nouveau]
[  465.816715]  [] drm_mode_set_config_internal+0x64/0xe0
[  465.816756]  [] drm_mode_setcrtc+0xda/0x580
[  465.816793]  [] drm_ioctl+0x1e4/0x660
[  465.816832]  [] ? drm_mode_setplane+0x1e0/0x1e0
[  465.816892]  [] nouveau_drm_ioctl+0x62/0xd0 [nouveau]
[  465.816934]  [] ? pick_next_task_fair+0x415/0x450
[  465.816974]  [] do_vfs_ioctl+0x7e/0x4f0
[  465.817022]  [] SyS_ioctl+0x47/0x90
[  465.817059]  [] ? do_page_fault+0xc/0x10
[  465.817095]  [] system_call_fastpath+0x16/0x1b
[  465.817132] Code: e1 41 89 c4 4c 8d ab 00 01 00 00 41 c1 ec 02 4c 89 ef 45
01 e6 e8 63 19 75 e1 41 81 fe f7 03 00 00 0f 86 a6 00 00 00 48 8b 43 58 <42> c7
04 a0 00 00 00 20 48 8b 7b 08 48 8b 77 40 48 85 f6 0f 84 
[  465.817648] RIP  [] evo_wait+0x5e/0x150 [nouveau]
[  465.817720]  RSP 
[  465.817750] CR2: 88030e343ffc
[  465.826673] ---[ end trace 58553e4293b2aee3 ]---
[  466.357879] nouveau W[   PFIFO][:01:00.0] unknown intr 0x0020, ch 1


Attempts to read files in sysfs puts related processes in D-state for at least
/sys/class/dri/card1-*/status.

-- 
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/20140816/b4b8434e/attachment-0001.html>

[Bug 57349] [nouveau, EFI] xf86-video-nouveau-1.0.2 and above fail to find device with X 1.13.0

2014-08-16 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=57349

Bruno  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Bruno  ---
Fixed in 3.17-rc1 with commit 20cde694027e, though a fix for regression on
multi-head Apple-EFI systems pending.

-- 
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/20140816/94c9e6f5/attachment.html>

[Bug 82586] UBO matrix in std140 struct does not work

2014-08-16 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=82586

--- Comment #9 from Ilia Mirkin  ---
--enable-texture-float

-- 
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/20140816/e398b242/attachment.html>

[Bug 82586] UBO matrix in std140 struct does not work

2014-08-16 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=82586

--- Comment #8 from pavol at klacansky.com ---
I have tried to compile mesa, but all I get is GL 2.1

OpenGL version string: 2.1 Mesa 10.3.0-devel (git-9d9879a)

I just build master without any non-default flags. Can you help, please?
(I would like to bisect, and I reported other bug which I want to test)

-- 
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/20140816/6adf39f3/attachment.html>

[PATCH] drm/vmwgfx: fix asssignment of vmw_bo_p to NULL

2014-08-16 Thread Colin King 
From: Colin Ian King 

cppcheck detected an incorrect assignment:

 [drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:903]: (warning) Assignment
 of function parameter has no effect outside the function. Did you
 forget dereferencing it?

the original assigment didn't do anything, instead *vmw_bo_p should
be set to NULL.

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 7bfdaa1..b1632c4 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -917,7 +917,7 @@ static int vmw_translate_mob_ptr(struct vmw_private 
*dev_priv,

 out_no_reloc:
vmw_dmabuf_unreference(_bo);
-   vmw_bo_p = NULL;
+   *vmw_bo_p = NULL;
return ret;
 }

-- 
2.1.0.rc1

[PATCH 2/2] x86, ia64: Don't default to first video device

2014-08-16 Thread Bruno Prémont 
With commit 20cde694027e boot video device detection was moved from
efifb to x86 and ia64 pci/fixup.c.

For dual-GPU Apple computers above above change represents a regression
as code in efifb did forcefully override vga_default_device while the
merge did not (changed ordering of actions).

This stops setting default_vga_device when applying
IORESOURCE_ROM_SHADOW (only doing so for the detected boot GPU) and
updates logging of boot video device selection, in vgaarb which covers
VGA text-mode booting and first half of pci_fixup_video which covers
framebuffer mode (EFI, VESA).

By setting IORESOURCE_ROM_SHADOW only on effective boot GPU we also
corrects a longstanding complaint from intel driver as reported by
Andreas:
  > Does setting the ROM_SHADOW flag on (possibly) the wrong device
  > have any effect?
  Yes it does. Removing the line changes a long standing
i915 :00:02.0: Invalid ROM contents
  into a
i915 :00:02.0: BAR 6: can't assign [??? 0x flags
0x2000] (bogus alignment).
  The first is logged at KERN_ERR while the second is at KERN_INFO.

Reported-By: Andreas Noever 
Signed-off-by: Bruno Pr?mont 
CC: Matthew Garrett 
CC: stable at vger.kernel.org # v3.5+
---
Must be applied to stable when upstream commit
20cde694027e7477cc532833e38ab9fcaa83fb64, which is marked for
stable, gets applied.

Can be applied without patch 1/2 from this series though dropped
#ifndefs will cause this patch not to apply cleanly.


 arch/ia64/pci/fixup.c| 9 +
 arch/x86/pci/fixup.c | 9 +
 drivers/gpu/vga/vgaarb.c | 4 +++-
 3 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/arch/ia64/pci/fixup.c b/arch/ia64/pci/fixup.c
index ec73b2c..05198f8 100644
--- a/arch/ia64/pci/fixup.c
+++ b/arch/ia64/pci/fixup.c
@@ -54,8 +54,10 @@ static void pci_fixup_video(struct pci_dev *pdev)
continue;

if (screen_info.lfb_base >= start &&
-   (screen_info.lfb_base + screen_info.lfb_size) < end)
+   (screen_info.lfb_base + screen_info.lfb_size) < 
end) {
+   dev_printk(KERN_DEBUG, >dev, "Boot video 
device\n");
vga_set_default_device(pdev);
+   }
}
}

@@ -79,12 +81,11 @@ static void pci_fixup_video(struct pci_dev *pdev)
}
bus = bus->parent;
}
-   if (!vga_default_device() || pdev == vga_default_device()) {
+   if (pdev == vga_default_device()) {
pci_read_config_word(pdev, PCI_COMMAND, );
if (config & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
pdev->resource[PCI_ROM_RESOURCE].flags |= 
IORESOURCE_ROM_SHADOW;
-   dev_printk(KERN_DEBUG, >dev, "Boot video 
device\n");
-   vga_set_default_device(pdev);
+   dev_printk(KERN_DEBUG, >dev, "Video device with 
shadowed ROM\n");
}
}
 }
diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index c61ea57..5b392d2 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -342,8 +342,10 @@ static void pci_fixup_video(struct pci_dev *pdev)
continue;

if (screen_info.lfb_base >= start &&
-   (screen_info.lfb_base + screen_info.lfb_size) < end)
+   (screen_info.lfb_base + screen_info.lfb_size) < 
end) {
+   dev_printk(KERN_DEBUG, >dev, "Boot video 
device\n");
vga_set_default_device(pdev);
+   }
}
}

@@ -367,12 +369,11 @@ static void pci_fixup_video(struct pci_dev *pdev)
}
bus = bus->parent;
}
-   if (!vga_default_device() || pdev == vga_default_device()) {
+   if (pdev == vga_default_device()) {
pci_read_config_word(pdev, PCI_COMMAND, );
if (config & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
pdev->resource[PCI_ROM_RESOURCE].flags |= 
IORESOURCE_ROM_SHADOW;
-   dev_printk(KERN_DEBUG, >dev, "Boot video 
device\n");
-   vga_set_default_device(pdev);
+   dev_printk(KERN_DEBUG, >dev, "Video device with 
shadowed ROM\n");
}
}
 }
diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index 257674d..c6eeed5 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -580,8 +580,10 @@ static bool vga_arbiter_add_pci_device(struct pci_dev 
*pdev)
 * by default if arch doesn't have it's own hook
 */
if (vga_default == NULL &&
-   ((vgadev->owns & VGA_RSRC_LEGACY_MASK) == VGA_RSRC_LEGACY_MASK))
+   ((vgadev->owns & VGA_RSRC_LEGACY_MASK) == VGA_RSRC_LEGACY_MASK)) {
+   pr_info("vgaarb: Boot video device:

[PATCH 1/2] vgaarb: Drop obsolete #ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE

2014-08-16 Thread Bruno Prémont 
With commit 20cde694027e boot video device detection was moved from
efifb to x86 and ia64 pci/fixup.c.

Remove the left-over #ifndef check that will allways match since
the corresponding arch-specific define is gone with above patch.

Signed-off-by: Bruno Pr?mont 
CC: Matthew Garrett 
CC: stable at vger.kernel.org # v3.5+
---
May be applied to stable as cleanup for upstream commit
20cde694027e7477cc532833e38ab9fcaa83fb64 which is marked for
stable.

 drivers/gpu/vga/vgaarb.c | 8 
 include/linux/vgaarb.h   | 2 --
 2 files changed, 10 deletions(-)

diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index d2077f0..257674d 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -112,10 +112,8 @@ both:
return 1;
 }

-#ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE
 /* this is only used a cookie - it should not be dereferenced */
 static struct pci_dev *vga_default;
-#endif

 static void vga_arb_device_card_gone(struct pci_dev *pdev);

@@ -131,7 +129,6 @@ static struct vga_device *vgadev_find(struct pci_dev *pdev)
 }

 /* Returns the default VGA device (vgacon's babe) */
-#ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE
 struct pci_dev *vga_default_device(void)
 {
return vga_default;
@@ -147,7 +144,6 @@ void vga_set_default_device(struct pci_dev *pdev)
pci_dev_put(vga_default);
vga_default = pci_dev_get(pdev);
 }
-#endif

 static inline void vga_irq_set_state(struct vga_device *vgadev, bool state)
 {
@@ -583,11 +579,9 @@ static bool vga_arbiter_add_pci_device(struct pci_dev 
*pdev)
/* Deal with VGA default device. Use first enabled one
 * by default if arch doesn't have it's own hook
 */
-#ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE
if (vga_default == NULL &&
((vgadev->owns & VGA_RSRC_LEGACY_MASK) == VGA_RSRC_LEGACY_MASK))
vga_set_default_device(pdev);
-#endif

vga_arbiter_check_bridge_sharing(vgadev);

@@ -621,10 +615,8 @@ static bool vga_arbiter_del_pci_device(struct pci_dev 
*pdev)
goto bail;
}

-#ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE
if (vga_default == pdev)
vga_set_default_device(NULL);
-#endif

if (vgadev->decodes & (VGA_RSRC_LEGACY_IO | VGA_RSRC_LEGACY_MEM))
vga_decode_count--;
diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h
index 2c02f3a..c37bd4d 100644
--- a/include/linux/vgaarb.h
+++ b/include/linux/vgaarb.h
@@ -182,7 +182,6 @@ extern void vga_put(struct pci_dev *pdev, unsigned int 
rsrc);
  * vga_get()...
  */

-#ifndef __ARCH_HAS_VGA_DEFAULT_DEVICE
 #ifdef CONFIG_VGA_ARB
 extern struct pci_dev *vga_default_device(void);
 extern void vga_set_default_device(struct pci_dev *pdev);
@@ -190,7 +189,6 @@ extern void vga_set_default_device(struct pci_dev *pdev);
 static inline struct pci_dev *vga_default_device(void) { return NULL; };
 static inline void vga_set_default_device(struct pci_dev *pdev) { };
 #endif
-#endif

 /**
  * vga_conflicts
-- 
1.8.5.5

[Bug 82709] New: OpenCL not working on radeon hainan

2014-08-16 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=82709

  Priority: medium
Bug ID: 82709
  Assignee: dri-devel at lists.freedesktop.org
   Summary: OpenCL not working on radeon hainan
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: pali.rohar at gmail.com
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

OpenCL not working on Radeon HD 8690M card which has Hainan chip.

example hello world application shows this error log:

Build Log:
error: unknown target CPU 'hainan'

haagch on #dri-devel suggested me to:
$ sudo sed -i "s/tahiti/hainan/" /usr/lib/libMesaOpenCL.so

and after this "fix" I got:

Build Log:
fatal error: cannot open file '/usr/lib/clc/hainan-r600--.bc': No such file or
directory

After that he suggested me to renaming tahiti-r600--.bc to hainan-r600--.bc
which fixed that problem and OpenCL started working.

So problem is probably in clang and libclc -- that there is missing hainan name
in cpu table.

-- 
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/20140816/fafcbce1/attachment.html>

[PATCH 0/2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()

2014-08-16 Thread Bruno Prémont 
This series improves on commit 20cde694027e (x86, ia64: Move EFI_FB
vga_default_device() initialization to pci_vga_fixup()):
- cleanup remaining but always-true #ifndefs
- fix boot regression on dual-GPU Macs

Andreas, can you please test this series? It is a modification from
previous testing patch that should still work fine for you.
That testing patch would have been failing X startup on old BIOS systems
booted with vga=normal (or otherwise in VGA text mode).


Greg, in case you have scheduled above-mentioned commit for your next
stable iteration, please hold it back in the queue until this follow-up
has landed and can be included within the same stable update as alone
that patch regresses for Macs with dual-GPU and using efifb.

Bruno

[Bug 72685] [radeonsi hyperz] Artifacts in Unigine Sanctuary

2014-08-16 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=72685

--- Comment #24 from Marek Ol??k  ---
(In reply to comment #21)
>  Anyway besides more artifacts of course (i mentioned yesterday on irc to
> marek) that if i just disable stencil in si_state.c, there is no lockups in
> these traces/apps when hyperz is enabled S_028800_STENCIL_ENABLE(0)

I don't understand this. Forcing STENCIL_ENABLE(0) doesn't fix Sanctuary.

-- 
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/20140816/50bb4a44/attachment.html>

[PATCH v3] ASoC: tda998x: add a codec to the HDMI transmitter

2014-08-16 Thread Mark Brown 
On Tue, Jul 08, 2014 at 11:40:57AM +0200, Jean-Francois Moine wrote:

>  .../devicetree/bindings/drm/i2c/tda998x.txt|  13 ++
>  drivers/gpu/drm/i2c/Makefile   |   2 +-
>  drivers/gpu/drm/i2c/tda998x_codec.c| 247 
> +
>  drivers/gpu/drm/i2c/tda998x_drv.c  |  74 --
>  drivers/gpu/drm/i2c/tda998x_drv.h  |  32 +++
>  include/drm/i2c/tda998x.h  |   1 +

I'd expect to see the ASoC parts of this appear under sound/soc (even if
just a library that the DRM driver links against rather than as a MFD).
This should help avoid cross tree issues and surprises when people do
API changes.

> +  - audio-ports: one or two values corresponding to entries in
> + the audio-port-names property.

What are these values?

> +  - audio-port-names: must contain "i2s", "spdif" entries
> + matching entries in the audio-ports property.

So it's mandatory that both I2S and S/PDIF be specified?

The code looks broadly sensible in so far as it
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140816/ba04e7c1/attachment-0001.sig>

[PATCH] drm: fix drm_modeset_lock.h kernel-doc notation

2014-08-16 Thread Randy Dunlap 
From: Randy Dunlap 

Fix drm kernel-doc notation to squelch these warnings:

Warning(..//include/drm/drm_modeset_lock.h:41): cannot understand function 
prototype: 'struct drm_modeset_acquire_ctx '
Warning(..//include/drm/drm_modeset_lock.h:66): cannot understand function 
prototype: 'struct drm_modeset_lock '

Need to include the keyword 'struct' for structure descriptions.

Signed-off-by: Randy Dunlap 
---
 include/drm/drm_modeset_lock.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: lnx-317-rc1/include/drm/drm_modeset_lock.h
===
--- lnx-317-rc1.orig/include/drm/drm_modeset_lock.h
+++ lnx-317-rc1/include/drm/drm_modeset_lock.h
@@ -29,7 +29,7 @@
 struct drm_modeset_lock;

 /**
- * drm_modeset_acquire_ctx - locking context (see ww_acquire_ctx)
+ * struct drm_modeset_acquire_ctx - locking context (see ww_acquire_ctx)
  * @ww_ctx: base acquire ctx
  * @contended: used internally for -EDEADLK handling
  * @locked: list of held locks
@@ -56,7 +56,7 @@ struct drm_modeset_acquire_ctx {
 };

 /**
- * drm_modeset_lock - used for locking modeset resources.
+ * struct drm_modeset_lock - used for locking modeset resources.
  * @mutex: resource locking
  * @head: used to hold it's place on state->locked list when
  *part of an atomic update

[PATCH] dma-buf: fix kernel-doc warning

2014-08-16 Thread Randy Dunlap 
From: Randy Dunlap 

Fix kernel-doc warning, missing parameter description:

Warning(..//include/linux/seqno-fence.h:99): No description found for parameter 
'cond'

Signed-off-by: Randy Dunlap 
Cc: Rob Clark 
Cc: Maarten Lankhorst 
---
 include/linux/seqno-fence.h |1 +
 1 file changed, 1 insertion(+)

Index: lnx-317-rc1/include/linux/seqno-fence.h
===
--- lnx-317-rc1.orig/include/linux/seqno-fence.h
+++ lnx-317-rc1/include/linux/seqno-fence.h
@@ -62,6 +62,7 @@ to_seqno_fence(struct fence *fence)
  * @context: the execution context this fence is a part of
  * @seqno_ofs: the offset within @sync_buf
  * @seqno: the sequence # to signal on
+ * @cond: the fence condition to check
  * @ops: the fence_ops for operations on this seqno fence
  *
  * This function initializes a struct seqno_fence with passed parameters,

[Bug 79980] Random radeonsi crashes

2014-08-16 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=79980

--- Comment #92 from Chernovsky Oleg  ---
I've successfully reproduced this bug 

I'm on 3.16 kernel, mesa 10.2.5.

I start Qt5 QtCreator (as I know it uses OpenGL acceleration for some QML
elements), then I start any 3D-demanding app (like one of Valve's game titles).
After that I close app. And when I close QtCreator, this bug occurs, total
system hang, ring 0 freezes and does not wake up on soft reset.

Where should I look at to fix it? I assume it hids somewhere in GPUVM? (or is
it needed anymore or is it already fixed?)

-- 
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/20140816/6a6d4bf8/attachment.html>

Fence, timeline and android sync points

2014-08-16 Thread Jerome Glisse 
On Sat, Aug 16, 2014 at 09:01:27AM +0200, Thomas Hellstrom wrote:
> On 08/15/2014 04:52 PM, Jerome Glisse wrote:
> > On Fri, Aug 15, 2014 at 08:54:38AM +0200, Thomas Hellstrom wrote:
> >> On 08/14/2014 09:15 PM, Jerome Glisse wrote:
> >>> On Thu, Aug 14, 2014 at 08:47:16PM +0200, Daniel Vetter wrote:
>  On Thu, Aug 14, 2014 at 8:18 PM, Jerome Glisse  
>  wrote:
> > Sucks because you can not do weird synchronization like one i depicted 
> > in another
> > mail in this thread and for as long as cmdbuf_ioctl do not give you 
> > fence|syncpt
> > you can not such thing cleanly in non hackish way.
>  Actually i915 can soon will do that that.
> >>> So you will return fence|syncpoint with each cmdbuf_ioctl ?
> >>>
> > Sucks because you have a fence object per buffer object and thus 
> > overhead grow
> > with the number of objects. Not even mentioning fence lifetime issue.
> >
> > Sucks because sub-buffer allocation is just one of many tricks that can 
> > not be
> > achieved properly and cleanly with implicit sync.
> >
> > ...
>  Well I heard all those reasons and I'm well of aware of them. The
>  problem is that with current hardware the kernel needs to know for
>  each buffer how long it needs to be kept around since hw just can't do
>  page faulting. Yeah you can pin them but for an uma design that
>  doesn't go down well with folks.
> >>> I am not thinking with fancy hw in mind, on contrary i thought about all
> >>> this with the crappiest hw i could think of, in mind.
> >>>
> >>> Yes you can get rid of fence and not have to pin memory with current hw.
> >>> What matter for unpinning is to know that all hw block are done using the
> >>> memory. This is easily achievable with your beloved seqno. Have one seqno
> >>> per driver (one driver can have different block 3d, video decoding, crtc,
> >>> ...) each time a buffer is use as part of a command on one block inc the
> >>> common seqno and tag the buffer with that number. Have each hw block write
> >>> the lastest seqno that is done to a per block location. Now to determine
> >>> is buffer is done compare the buffer seqno with the max of all the 
> >>> signaled
> >>> seqno of all blocks.
> >>>
> >>> Cost 1 uint32 per buffer and simple if without locking to check status of
> >>> a buffer.
> >> Hmm?
> >> The trivial and first use of fence objects in the linux DRM was
> >> triggered by the fact that a
> >> 32-bit seqno wraps pretty quickly and a 32-bit solution just can't be
> >> made robust.
> >> Now a 64-bit seqno will probably be robust for forseeable future, but
> >> when it comes to implement that on 32-bit hardware and compare it to a
> >> simple fence object approach,
> > Using same kind of arithemic as use for jiffies would do it provided that
> > there is a checking that we never let someobject pass above a certain age.
> 
> But wouldn't the search-for-max scheme break if blocks complete out of
> order?

Seems i use wrong word in my email, the pseudo code is correct however, it's
not max it's min. So by knowing the minimum global seqno of all hw block you
know that at very least all hw block are past that point. Which means the
order into which blocks complete is irrevelant. But it also means that you
might delay more than needed the unbinding, thought pseudo code shows way to
alieviate and minimize this delay.

It's doable i had it kind of working couple years ago when we were reworking
fence in radeon driver but never got around to finish something clean because
implicit sync needs the reservation scheme which means you kind of need a
fence per buffer (well getting rid of that is where things get complicated
and painful).

Explicit sync is just so much nicer, but we made decision long ago about
implicit, another thing i am deeply regreting now.

Cheers,
J?r?me

> 
> /Thomas
> 
>

Fence, timeline and android sync points

2014-08-16 Thread Thomas Hellstrom 
On 08/15/2014 04:52 PM, Jerome Glisse wrote:
> On Fri, Aug 15, 2014 at 08:54:38AM +0200, Thomas Hellstrom wrote:
>> On 08/14/2014 09:15 PM, Jerome Glisse wrote:
>>> On Thu, Aug 14, 2014 at 08:47:16PM +0200, Daniel Vetter wrote:
 On Thu, Aug 14, 2014 at 8:18 PM, Jerome Glisse  
 wrote:
> Sucks because you can not do weird synchronization like one i depicted in 
> another
> mail in this thread and for as long as cmdbuf_ioctl do not give you 
> fence|syncpt
> you can not such thing cleanly in non hackish way.
 Actually i915 can soon will do that that.
>>> So you will return fence|syncpoint with each cmdbuf_ioctl ?
>>>
> Sucks because you have a fence object per buffer object and thus overhead 
> grow
> with the number of objects. Not even mentioning fence lifetime issue.
>
> Sucks because sub-buffer allocation is just one of many tricks that can 
> not be
> achieved properly and cleanly with implicit sync.
>
> ...
 Well I heard all those reasons and I'm well of aware of them. The
 problem is that with current hardware the kernel needs to know for
 each buffer how long it needs to be kept around since hw just can't do
 page faulting. Yeah you can pin them but for an uma design that
 doesn't go down well with folks.
>>> I am not thinking with fancy hw in mind, on contrary i thought about all
>>> this with the crappiest hw i could think of, in mind.
>>>
>>> Yes you can get rid of fence and not have to pin memory with current hw.
>>> What matter for unpinning is to know that all hw block are done using the
>>> memory. This is easily achievable with your beloved seqno. Have one seqno
>>> per driver (one driver can have different block 3d, video decoding, crtc,
>>> ...) each time a buffer is use as part of a command on one block inc the
>>> common seqno and tag the buffer with that number. Have each hw block write
>>> the lastest seqno that is done to a per block location. Now to determine
>>> is buffer is done compare the buffer seqno with the max of all the signaled
>>> seqno of all blocks.
>>>
>>> Cost 1 uint32 per buffer and simple if without locking to check status of
>>> a buffer.
>> Hmm?
>> The trivial and first use of fence objects in the linux DRM was
>> triggered by the fact that a
>> 32-bit seqno wraps pretty quickly and a 32-bit solution just can't be
>> made robust.
>> Now a 64-bit seqno will probably be robust for forseeable future, but
>> when it comes to implement that on 32-bit hardware and compare it to a
>> simple fence object approach,
> Using same kind of arithemic as use for jiffies would do it provided that
> there is a checking that we never let someobject pass above a certain age.

But wouldn't the search-for-max scheme break if blocks complete out of
order?

/Thomas

[Bug 82585] geometry shader with optional out variable segfaults

2014-08-16 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=82585

pavol at klacansky.com changed:

   What|Removed |Added

   Hardware|Other   |x86-64 (AMD64)
 OS|All |Linux (All)

-- 
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/20140816/64968e3d/attachment.html>

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst

2014-08-16 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=73338

--- Comment #16 from Maron  ---
Any further news? Gigabyte HD7870 same issues as above. I have to use catalyst
because of the fan noise.

-- 
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/20140816/4d2d9077/attachment.html>