[Bug 94037] [Gallium] glGetQueryObject with GL_ANY_SAMPLES_PASSED returns the same as with GL_SAMPLES_PASSED

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=94037

--- Comment #3 from Ilia Mirkin  ---
(In reply to peter.fiss from comment #2)
> Thanks for the quick answer. I'm going to try mesa-git on my Manjaro
> machine, but it looks like it will take a while until llvm-svn and mesa-git
> are compiled and installed.

You should be fine with your system llvm (or no llvm at all, unless you're
using radeonsi or are testing llvmpipe).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160207/a7f2a6ec/attachment.html>

[Bug 94037] [Gallium] glGetQueryObject with GL_ANY_SAMPLES_PASSED returns the same as with GL_SAMPLES_PASSED

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=94037

--- Comment #2 from peter.fiss at gmx.de ---
Thanks for the quick answer. I'm going to try mesa-git on my Manjaro machine,
but it looks like it will take a while until llvm-svn and mesa-git are compiled
and installed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160207/662b9494/attachment.html>

[Bug 94037] [Gallium] glGetQueryObject with GL_ANY_SAMPLES_PASSED returns the same as with GL_SAMPLES_PASSED

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=94037

--- Comment #1 from Ilia Mirkin  ---
This should have been (semi-accidentally) fixed in commit 

https://cgit.freedesktop.org/mesa/mesa/commit/?id=386a9ec77b7113c1e0c29c30b981a50175ac16e8

which refactored a lot of that code, and will be fixed even harder once my
recent series cleaning this up lands:

https://patchwork.freedesktop.org/series/3163/

note that the issue only applied to the 64-bit getters. Both of the 32-bit
getters did force the value to be true/false.

Long story short, try mesa-git, the problem should go away.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160207/f86ab0ca/attachment.html>

[Bug 90481] Radeonsi driver, X crash while playing "Spec ops: the line"

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=90481

Xavier Sellier  changed:

   What|Removed |Added

   Assignee|xsellier at gmail.com  |dri-devel at 
lists.freedesktop
   ||.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160207/60ef1ecf/attachment.html>

[Bug 94037] [Gallium] glGetQueryObject with GL_ANY_SAMPLES_PASSED returns the same as with GL_SAMPLES_PASSED

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=94037

Bug ID: 94037
   Summary: [Gallium] glGetQueryObject with GL_ANY_SAMPLES_PASSED
returns the same as with GL_SAMPLES_PASSED
   Product: Mesa
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: peter.fiss at gmx.de
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 121579
  --> https://bugs.freedesktop.org/attachment.cgi?id=121579=edit
Source code of the test program. Needs SDL2 to build. It shows a red background
if the describes bug exists.

The OpenGL-Wiki says, the function should return "GL_FALSE if none of the
scoped drawing commands generate samples that pass the depth test; otherwise,
the value is GL_TRUE". Source: https://www.opengl.org/wiki/Query_Object

When calling glGetQueryObjecti64v on r600 or nouveau (probably on any gallium
driver) however, it returns the number of samples which passed the depth test.
This would be correct behaviour if the argument was GL_SAMPLES_PASSED instead
of GL_ANY_SAMPLES_PASSED.

I have attached the source code of a simple example program. It worked
correctly on the following platforms:
- Arch Linux with Intel Ivy Bridge graphics (Mesa 11.1.1-1)
- Windows 7 with the same Intel graphics
- Windows 7 with Nvidia GeForce GT 640M
- Windows 7 with ATI Radeon HD 5670

It showed incorrect behaviour on these systems:
- Arch Linux with Nouveau and GeForce GT 640M (Mesa 11.1.1-1)
- Manjaro with r600 and Radeon HD 5670 (Mesa 11.1.1-1)

Note that the bugtracker does not allow me to specify 11.1 as mesa version.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160207/02640b76/attachment-0001.html>

[Bug 93649] [radeonsi] Graphics lockup while playing tf2

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=93649

Matthew Dawson  changed:

   What|Removed |Added

 Attachment #121242|0   |1
is obsolete||

--- Comment #11 from Matthew Dawson  ---
Created attachment 121578
  --> https://bugs.freedesktop.org/attachment.cgi?id=121578=edit
New avoid lockup patch

Latest version as posted to dri-devel.  With these two patches, your system
should no longer lockup forever.  It will freeze the game for a moment, and X
may die for other reasons.

Now the underlying tf2 issue needs investigation.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160207/541a14e3/attachment.html>

[Bug 93649] [radeonsi] Graphics lockup while playing tf2

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=93649

--- Comment #10 from Rosco P. Coltrane  ---
Same problem here on a fedora 23

GPU: HD 7970
CPU: Intel Core i7 950

Mesa 11.1.0
DRM 2.43.0
LLVM 3.7.0
kernel: 4.3.4

The logs are filed with "ring stalled" and GPU lock messages. I can send more
logs if needed.

radeon :02:00.0: ring 3 stalled for more than 10249msec
radeon :02:00.0: GPU lockup (current fence id 0x0001e5f1 last fence
id 0x0001e5f2 on ring 3)

I've tried a different firmware
(http://people.freedesktop.org/~agd5f/radeon_ucode/k/) which seemed to have
helped other people with their own problem but it didn't help in my case.

Does it makes sense to try to rollback to an older kernel?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160207/f7a17382/attachment.html>

[PATCH] drm: Export debugfs functionality for GPL code only

[gr...@linuxhacker.ru]

From: Oleg Drokin 

drm_debugfs_create_files and drm_debugfs_remove_files
should only be available for GPL-code only as per Greg-KH

Signed-off-by: Oleg Drokin 
---
 drivers/gpu/drm/drm_debugfs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 3bcf8e6..17ae4ae 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -128,7 +128,7 @@ fail:
drm_debugfs_remove_files(files, count, minor);
return ret;
 }
-EXPORT_SYMBOL(drm_debugfs_create_files);
+EXPORT_SYMBOL_GPL(drm_debugfs_create_files);

 /**
  * Initialize the DRI debugfs filesystem for a device
@@ -209,7 +209,7 @@ int drm_debugfs_remove_files(const struct drm_info_list 
*files, int count,
mutex_unlock(>debugfs_lock);
return 0;
 }
-EXPORT_SYMBOL(drm_debugfs_remove_files);
+EXPORT_SYMBOL_GPL(drm_debugfs_remove_files);

 /**
  * Cleanup the debugfs filesystem resources.
-- 
2.1.0

[PATCH] drm: Export debugfs functionality for GPL code only

[Greg Kroah-Hartman]

On Sun, Feb 07, 2016 at 06:50:49PM -0500, green at linuxhacker.ru wrote:
> From: Oleg Drokin 
> 
> drm_debugfs_create_files and drm_debugfs_remove_files
> should only be available for GPL-code only as per Greg-KH
> 
> Signed-off-by: Oleg Drokin 

Acked-by: Greg Kroah-Hartman 

Intel drm random freezes with Z36xxx/Z37xxx and several current 4.x kernels?

[Bruno Kant]

Hello,

Some news from my Shuttle XS35V4 (Celeron, with latest XS35V400.400 
BIOS) and its graphic card. But first of all, thanks to the people who 
made those codes available:

http://cgit.freedesktop.org/drm-intel
https://cgit.freedesktop.org/xorg/driver/xf86-video-intel

I am still using Fedora 23 Workstation (with the daily update).

I updated xf86-video-intel to the latest 2.99.917-544(-g8b8c9a3?) 
version. Then I booted using the freedesktop.org/drm-intel kernel which 
included the i915 1.6.0 20160124 graphic driver. My Shuttle graphic card 
is:

# lspci -nnk | egrep -iA3 "VGA"
00:02.0 VGA compatible controller [0300]: Intel Corporation Atom 
Processor Z36xxx/Z37xxx Series Graphics & Display [8086:0f31] (rev 0e)
 DeviceName:  Onboard IGD
 Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Device 
[1297:4019]
 Kernel driver in use: i915

With the freedesktop.org/drm-intel kernel (currently a patched 
4.5.0-rc2), my Linux ran for 14 hours whithout any crash. I stressed the 
box using two screens and three video streams.

Then I used the freedesktop.org/drm-intel content to patch a standard 
4.5.0-rc2 downloaded from kernel.org. My Shuttle is now up and running 
4.5.0-rc2 with the latest i915 1.6.0 20160124 kernel module and 
xf86-video-intel version 2.99.917-544. I think it should be much more 
stable now.

Best regards

[Bug 93424] [amdgpu] [powerplay] [runpm] Card doesn't re-init when using powerplay and runpm

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=93424

--- Comment #2 from Mike Lothian  ---
I've done another test

I ran DRI_PRIME=1 glxgears, just to keep the card running

I then launched BioShock and the sclk & mclk again stayed at their lowest
settings, I echo'd high into power_dpm_force_performance_level which changed
the sclk & mclk values. When I echo'd auto back into
power_dpm_force_performance_level and the clocks stayed high. When I exited the
game (with glxgears still running) the clocks went back to their lowest
settings, which is what I'd expect

So it looks like then the card is re-initialized the auto performance level
doesn't work correctly - or is being set to low

Hope this helps

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160207/ceb89697/attachment.html>

[Bug 91197] Radeon Trinity 7400G fails with 4K UHD screen - atombios stuck executing BF64

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91197

--- Comment #17 from dennis.jansen at web.de ---
Update: I get the BF64 error each time I switch between X and console. So it
takes about 5 seconds each time. I still have to manually had modes to get 4k
to work.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160207/92814f2f/attachment.html>

[Bug 91197] Radeon Trinity 7400G fails with 4K UHD screen - atombios stuck executing BF64

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91197

dennis.jansen at web.de changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #16 from dennis.jansen at web.de ---
(In reply to NeverMind from comment #15)
> Since the last update this bug no longer occur

Could you clarify? What was updated? How was it fixed? 
Because the bug is still present for me in 4.2.
If it was fixed for you, maybe you had a different bug. As this is the bug I've
created, I'm reopening it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160207/892282d9/attachment.html>

[PATCH] drm/radeon: Avoid double gpu reset by adding a timeout on IB ring tests.

[Matthew Dawson]

When the radeon driver resets a gpu, it attempts to test whether all the
rings can successfully handle an IB.  If these rings fail to respond, the
process will wait forever.  Another gpu reset can't happen at this point,
as the current reset holds a lock required to do so.  Instead, make all
the IB tests run with a timeout, so the system can attempt to recover
in this case.

While this doesn't fix the underlying issue with card resets failing, it
gives the system a higher chance of recovering.  These timeouts have been
confirmed to help both a Tathi and Hawaii card recover after a gpu reset.

This also adds a new function, radeon_fence_wait_timeout, that behaves like
fence_wait_timeout.  It is used instead of fence_wait_timeout as it continues
to work during a reset.  radeon_fence_wait is changed to be implemented
using this function.

V2:
 - Changed the timeout to 1s, as the default 10s from radeon_wait_timeout was
too long.  A timeout of 100ms was tested and found to be too short.
 - Changed radeon_fence_wait_timeout to behave more like fence_wait_timeout.

Signed-off-by: Matthew Dawson 
---
 drivers/gpu/drm/radeon/cik.c  | 11 --
 drivers/gpu/drm/radeon/cik_sdma.c |  9 ++--
 drivers/gpu/drm/radeon/r100.c | 10 +++--
 drivers/gpu/drm/radeon/r600.c | 10 +++--
 drivers/gpu/drm/radeon/r600_dma.c |  9 ++--
 drivers/gpu/drm/radeon/radeon.h   |  2 ++
 drivers/gpu/drm/radeon/radeon_fence.c | 40 ---
 drivers/gpu/drm/radeon/radeon_vce.c   | 11 +++---
 drivers/gpu/drm/radeon/uvd_v1_0.c | 10 +++--
 9 files changed, 89 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 4c30d8c..0600140 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -4219,13 +4219,20 @@ int cik_ib_test(struct radeon_device *rdev, struct 
radeon_ring *ring)
DRM_ERROR("radeon: failed to schedule ib (%d).\n", r);
return r;
}
-   r = radeon_fence_wait(ib.fence, false);
-   if (r) {
+   r = radeon_fence_wait_timeout(ib.fence, false, usecs_to_jiffies(
+   RADEON_USEC_IB_TEST_TIMEOUT));
+   if (r < 0) {
DRM_ERROR("radeon: fence wait failed (%d).\n", r);
radeon_scratch_free(rdev, scratch);
radeon_ib_free(rdev, );
return r;
+   } else if (r == 0) {
+   DRM_ERROR("radeon: fence wait timed out.\n");
+   radeon_scratch_free(rdev, scratch);
+   radeon_ib_free(rdev, );
+   return -ETIMEDOUT;
}
+   r = 0;
for (i = 0; i < rdev->usec_timeout; i++) {
tmp = RREG32(scratch);
if (tmp == 0xDEADBEEF)
diff --git a/drivers/gpu/drm/radeon/cik_sdma.c 
b/drivers/gpu/drm/radeon/cik_sdma.c
index d16f2ee..9c351dc 100644
--- a/drivers/gpu/drm/radeon/cik_sdma.c
+++ b/drivers/gpu/drm/radeon/cik_sdma.c
@@ -737,11 +737,16 @@ int cik_sdma_ib_test(struct radeon_device *rdev, struct 
radeon_ring *ring)
DRM_ERROR("radeon: failed to schedule ib (%d).\n", r);
return r;
}
-   r = radeon_fence_wait(ib.fence, false);
-   if (r) {
+   r = radeon_fence_wait_timeout(ib.fence, false, usecs_to_jiffies(
+   RADEON_USEC_IB_TEST_TIMEOUT));
+   if (r < 0) {
DRM_ERROR("radeon: fence wait failed (%d).\n", r);
return r;
+   } else if (r == 0) {
+   DRM_ERROR("radeon: fence wait timed out.\n");
+   return -ETIMEDOUT;
}
+   r = 0;
for (i = 0; i < rdev->usec_timeout; i++) {
tmp = le32_to_cpu(rdev->wb.wb[index/4]);
if (tmp == 0xDEADBEEF)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 5eae0a8..6e478a2 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -3732,11 +3732,17 @@ int r100_ib_test(struct radeon_device *rdev, struct 
radeon_ring *ring)
DRM_ERROR("radeon: failed to schedule ib (%d).\n", r);
goto free_ib;
}
-   r = radeon_fence_wait(ib.fence, false);
-   if (r) {
+   r = radeon_fence_wait_timeout(ib.fence, false, usecs_to_jiffies(
+   RADEON_USEC_IB_TEST_TIMEOUT));
+   if (r < 0) {
DRM_ERROR("radeon: fence wait failed (%d).\n", r);
goto free_ib;
+   } else if (r == 0) {
+   DRM_ERROR("radeon: fence wait timed out.\n");
+   r = -ETIMEDOUT;
+   goto free_ib;
}
+   r = 0;
for (i = 0; i < rdev->usec_timeout; i++) {
tmp = RREG32(scratch);
if (tmp == 0xDEADBEEF) {
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index cc2fdf0..ed12104 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -3381,11 +3381,17 

[Bug 94025] [bisected] r600_texture.c:562: r600_texture_get_htile_size: Assertion `0' failed

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=94025

Alexandre Demers  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from Alexandre Demers  ---


*** This bug has been marked as a duplicate of bug 94019 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160207/3b0fd6f4/attachment.html>

[Bug 94019] [bisected] 3D acceleration broken with gallium/radeon: just get num_tile_pipes from the winsys

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=94019

--- Comment #4 from Alexandre Demers  ---
*** Bug 94025 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160207/b779519a/attachment.html>

[Bug 94019] [bisected] 3D acceleration broken with gallium/radeon: just get num_tile_pipes from the winsys

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=94019

--- Comment #3 from Alexandre Demers  ---
(In reply to Ernst Sjöstrand from comment #1)
> There is a backtrace but no result of any bisect...?

I confirm the bisection section, see bug 94025.
294ec530c9829aead97487b1feb06361ef97cc2d is the first bad commit
commit 294ec530c9829aead97487b1feb06361ef97cc2d
Author: Marek Olšák 
Date:   Sat Jan 30 01:52:58 2016 +0100

gallium/radeon: just get num_tile_pipes from the winsys

Reviewed-by: Michel Dänzer 

:04 04 71cb2da01a5912443f2ca74f97e46533f50f50d8
964978b8372e95f18eb09db4158b032bf25611fb Msrc


New way of setting num_pipes gives a value of 12, while previous was giving a
value of 8 on a R9 280X.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160207/45066f12/attachment.html>

[Bug 94019] [bisected] 3D acceleration broken with gallium/radeon: just get num_tile_pipes from the winsys

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=94019

Alexandre Demers  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=94025
 CC||alexandre.f.demers at gmail.co
   ||m, maraeo at gmail.com

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160207/e6df46c7/attachment.html>

[Bug 94025] [bisected] r600_texture.c:562: r600_texture_get_htile_size: Assertion `0' failed

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=94025

Alexandre Demers  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=94019

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160207/b49b4eb0/attachment.html>

[Bug 94025] [bisected] r600_texture.c:562: r600_texture_get_htile_size: Assertion `0' failed

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=94025

--- Comment #4 from Nick Sarnie  ---
Likely duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=94019

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160207/a35b7166/attachment.html>

[PATCH 1/2] drm/radeon: Use drm_vblank_off/on to fix vblank counter trouble.

[Mario Kleiner]

I have a few simple patches which after testing seem to work well
enough and fix additional similar problems with nouveau. Got
distracted with other stuff last week. I'll try to send them out later
today when i'm at the machine.

-mario


On Sun, Feb 7, 2016 at 12:05 PM, Vlastimil Babka  wrote:
> On 01/22/2016 06:08 PM, Mario Kleiner wrote:
>> Anyway, some more hours of thinking and code browsing later, now i think
>> i have a simple and safe solution which should hopefully restore the
>> drm_vblank_pre/post_modeset behaviour with only a few lines of core
>> code. At the same time it should fix up another bug in that new
>> drm_update_vblank_count code that i just realized, in a way simple
>> enough for a stable fix.
>>
>> Now i just need to actually code and test it first.
>
> Ping, any news? :)
>

[PATCH 1/2] drm/radeon: Use drm_vblank_off/on to fix vblank counter trouble.

[Vlastimil Babka]

On 01/22/2016 06:08 PM, Mario Kleiner wrote:
> Anyway, some more hours of thinking and code browsing later, now i think 
> i have a simple and safe solution which should hopefully restore the 
> drm_vblank_pre/post_modeset behaviour with only a few lines of core 
> code. At the same time it should fix up another bug in that new 
> drm_update_vblank_count code that i just realized, in a way simple 
> enough for a stable fix.
> 
> Now i just need to actually code and test it first.

Ping, any news? :)

[Bug 94025] [bisected] r600_texture.c:562: r600_texture_get_htile_size: Assertion `0' failed

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=94025

--- Comment #3 from Alexandre Demers  ---
With the code prior to the bad commit, num_pipes was defined as 8 (while now it
is 12, thus hitting default and asserting)...

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160207/b8e291fd/attachment.html>

[Bug 112061] DisplayPort on Thinkpad T500 AMD 3650 gpu stopped working

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=112061

Pavol Klačanský  changed:

   What|Removed |Added

 Regression|No  |Yes

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 112061] New: DisplayPort on Thinkpad T500 AMD 3650 gpu stopped working

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=112061

Bug ID: 112061
   Summary: DisplayPort on Thinkpad T500 AMD 3650 gpu stopped
working
   Product: Drivers
   Version: 2.5
Kernel Version: 4.4.1
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: pavol at klacansky.com
Regression: No

As of upgrade to 4.4.1 the displayport output stopped working. I am using DPM
and it worked with 4.4.0-r1 and previous kernels.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 60879] [radeonsi] X11 can't start with acceleration enabled

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=60879

madmalkav  changed:

   What|Removed |Added

 CC||myhateisblind at hotmail.com

--- Comment #126 from madmalkav  ---
I can confirm same problem with Tahiti LE. Mesa 11.1.1-1 from Manjaro Linux
repository.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160207/93c3758d/attachment.html>