[PATCH 1/2] drm/armada: fix page_flip refcounting leak

[Daniel Vetter]

On Sun, Oct 12, 2014 at 12:01:18AM +0100, Russell King wrote:
> A refcounting leak was found of the original frame buffer attached to
> the CRTC when using the page_flip ioctl, resulting in the frame buffer
> never being freed.
> 
> This was not obvious initially, as if the page flip subsequently
> re-attaches the original frame buffer, the refcounts will be balanced.
> However, if the original frame buffer is freed, then it will be leaked.
> 
> Fix this by ensuring that we take a reference on the incoming fb, but
> rely on the queued work to drop that ref count.
> 
> Signed-off-by: Russell King 

Yeah, looks like what I've expected, so
Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/armada/armada_crtc.c | 13 +
>  1 file changed, 5 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
> b/drivers/gpu/drm/armada/armada_crtc.c
> index 1f0875c26dc5..ac2d73f4af45 100644
> --- a/drivers/gpu/drm/armada/armada_crtc.c
> +++ b/drivers/gpu/drm/armada/armada_crtc.c
> @@ -945,18 +945,15 @@ static int armada_drm_crtc_page_flip(struct drm_crtc 
> *crtc,
>   armada_reg_queue_end(work->regs, i);
>  
>   /*
> -  * Hold the old framebuffer for the work - DRM appears to drop our
> -  * reference to the old framebuffer in drm_mode_page_flip_ioctl().
> +  * Ensure that we hold a reference on the new framebuffer.
> +  * This has to match the behaviour in mode_set.
>*/
> - drm_framebuffer_reference(work->old_fb);
> + drm_framebuffer_reference(fb);
>  
>   ret = armada_drm_crtc_queue_frame_work(dcrtc, work);
>   if (ret) {
> - /*
> -  * Undo our reference above; DRM does not drop the reference
> -  * to this object on error, so that's okay.
> -  */
> - drm_framebuffer_unreference(work->old_fb);
> + /* Undo our reference above */
> + drm_framebuffer_unreference(fb);
>   kfree(work);
>   return ret;
>   }
> -- 
> 1.8.3.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 73378] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!

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

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

--- Comment #10 from sterfield at gmail.com ---
Hi,

I've got the exact same error, preventing me to use UVD for H264 decoding

[   12.836644] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off
[   12.878552] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD
clocks!
[   12.878574] [drm:uvd_v1_0_ib_test] *ERROR* radeon: failed to raise UVD
clocks (-110).
[   12.878595] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on
ring 5 (-110).


I've tried with kernel 3.16-2-amd64 (from Debian testing), kernel 3.12.6 (from
Debian backports), the issue is the same.

As someone ask for "bisect", I did some google, and it apparently means that I
have to find the previous package / library where the problem is not present. I
supposed that it's located in libdrm-radeon1, so I tried last available package
in sid (2.4.58-2) and back in wheezy (2.4.40-1), but the problem is still
present in both version.

I'm willing to help to find the root of this issue, and I'm able to do some
test (I've spent several hours on this issue already), but I may just need some
indication on where to search.

Thanks for your help.

-- 
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/20141012/38c6b282/attachment.html>

[Bug 73378] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!

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

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

--- Comment #9 from sterfield at gmail.com ---
Created attachment 107750
  --> https://bugs.freedesktop.org/attachment.cgi?id=107750=edit
dmesg

Full dmesg after a cold boot, showing the UVD error.

-- 
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/20141012/ab74b62e/attachment.html>

[Bug 73378] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!

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

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

--- Comment #8 from sterfield at gmail.com ---
Created attachment 107749
  --> https://bugs.freedesktop.org/attachment.cgi?id=107749=edit
lspci of my graphic card

This is a result of "lspci -s 01:00.0 -vvv", showing all the details of my
graphic card.

-- 
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/20141012/ad655955/attachment.html>

[Bug 84944] tearing on radeonsi vdpau deinterlacer

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

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

--- Comment #1 from warpme at o2.pl ---
Created attachment 107748
  --> https://bugs.freedesktop.org/attachment.cgi?id=107748=edit
vdpauinfo log

-- 
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/20141012/5603f71c/attachment.html>

[Bug 84944] New: tearing on radeonsi vdpau deinterlacer

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

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

Bug ID: 84944
   Summary: tearing on radeonsi vdpau deinterlacer
   Product: Mesa
   Version: 10.2
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: warpme at o2.pl

Created attachment 107747
  --> https://bugs.freedesktop.org/attachment.cgi?id=107747=edit
Xorg.log

I'm developing diskless client for MythTV. 
I done some tests with kernel3.16.5, libdrm 2.4.58, Xorg1.16.1,
Mesa10.2.8/10.3, xorg-f86-ati 7.5.

On Brazos (HD6310, r600) all works well.

However with Kabini (HD8210, radeonsi) I have tearing on interlaced video with
MESA vdpau deinterlacer.

It looks like tearing is only on:
-interlaced content 
-on radeonsi.

As r600 deinterlacer works perfect - for me it looks like bug is in radeonsi
deinterlacer. 

Xorg and vdpauinfo logs attached.

-- 
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/20141012/6358951b/attachment.html>

[Bug 84920] Radeon UVD error

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

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

--- Comment #2 from Apostolos B.  ---
No flash. HW acceleration is gst-vaapi with the vdpau driver for r600. Firefox
32.

libva info: VA-API version 0.36.0
libva info: va_getDriverName() returns 0
libva info: User requested driver 'vdpau'
libva info: Trying to open /usr/lib/dri/vdpau_drv_video.so
libva info: Found init function __vaDriverInit_0_35
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.36 (libva 1.4.0)
vainfo: Driver version: Splitted-Desktop Systems VDPAU backend for VA-API -
0.7.4
vainfo: Supported profile and entrypoints
  VAProfileMPEG2Simple: VAEntrypointVLD
  VAProfileMPEG2Main  : VAEntrypointVLD
  VAProfileMPEG4Simple: VAEntrypointVLD
  VAProfileMPEG4AdvancedSimple: VAEntrypointVLD
  VAProfileH264Baseline   : VAEntrypointVLD
  VAProfileH264Main   : VAEntrypointVLD
  VAProfileH264High   : VAEntrypointVLD
  VAProfileVC1Advanced: VAEntrypointVLD

-- 
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/20141012/71fe13d2/attachment.html>

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #157 from agapito  ---
(In reply to Malte Schr?der from comment #156)
>> I've set aspm=0 for the radeon module and the system has been running for
> some hours straight.

Not for me.

-- 
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/20141012/07a9771f/attachment.html>

[Bug 84836] VERDE lockup with Unigine Valley/Heaven if ARB_sample_shading is enabled

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

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

--- Comment #3 from Marek Ol??k  ---
I think you forgot to install drirc from Mesa. What happens if you set this env
var?

allow_glsl_extension_directive_midshader=true

-- 
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/20141012/7ad5c043/attachment.html>

[Bug 82201] [HAWAII] GPU doesn't reclock, poor 3D performance

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

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

--- Comment #37 from Kai  ---
(In reply to Christian K?nig from comment #36)
> Ah! Ok that's something different. As long as the system was completely off
> (defined by no power to the GPU) there shouldn't be any influence from the
> previously booted os.

Well, I would say the GPU didn't have power. I mean some parts of the
motherboard stay powered for e.g. wake on LAN, but otherwise? I can try whether
disconnecting the power makes a difference, if you feel, that would be helpful
in tracking this down.

-- 
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/20141012/d6e6247c/attachment.html>

[Bug 82201] [HAWAII] GPU doesn't reclock, poor 3D performance

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

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

--- Comment #36 from Christian K?nig  ---
(In reply to Kai from comment #35)
> (In reply to Christian K?nig from comment #34)
> > (In reply to Kai from comment #33)
> > > And I have non-reclocking GPU again.
> > > Is there any data I can provide, that would help you tracking down, what
> > > Windows is setting, that is preventing proper initialisation of the card 
> > > for
> > > Linux?
> > 
> > Well that could actually be perfectly normal behavior. For some hardware
> > blocks you can upload the firmware only once after a bootup.
> > 
> > So what could happen is that the windows driver loads one version and the
> > linux driver needs a different one. The same problems applies the other way
> > around as well.
> 
> I think I need to rephrase the description: the system was powered off for
> ten to twelve hours after I had Windows running, and then on the next boot
> (into Linux), I didn't get a reclocking GPU. I didn't reboot the PC directly
> into Linux. (Though I didn't disconnect power, so some parts of the
> motherboard might stay powered.)

Ah! Ok that's something different. As long as the system was completely off
(defined by no power to the GPU) there shouldn't be any influence from the
previously booted os.

-- 
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/20141012/cd5606f7/attachment.html>

[Bug 82201] [HAWAII] GPU doesn't reclock, poor 3D performance

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

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

--- Comment #35 from Kai  ---
(In reply to Christian K?nig from comment #34)
> (In reply to Kai from comment #33)
> > And I have non-reclocking GPU again.
> > Is there any data I can provide, that would help you tracking down, what
> > Windows is setting, that is preventing proper initialisation of the card for
> > Linux?
> 
> Well that could actually be perfectly normal behavior. For some hardware
> blocks you can upload the firmware only once after a bootup.
> 
> So what could happen is that the windows driver loads one version and the
> linux driver needs a different one. The same problems applies the other way
> around as well.

I think I need to rephrase the description: the system was powered off for ten
to twelve hours after I had Windows running, and then on the next boot (into
Linux), I didn't get a reclocking GPU. I didn't reboot the PC directly into
Linux. (Though I didn't disconnect power, so some parts of the motherboard
might stay powered.)

-- 
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/20141012/57349f3c/attachment.html>

[Bug 82920] Invalid read during geometry program build

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

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

Glenn Kennard  changed:

   What|Removed |Added

  Component|Drivers/Gallium/r600|glsl-compiler
   Assignee|dri-devel at lists.freedesktop |idr at freedesktop.org
   |.org|
 QA Contact||intel-3d-bugs at lists.freedes
   ||ktop.org

--- Comment #4 from Glenn Kennard  ---
Testing "fixed_mc" with a debug-enabled mesa build I get:

Mesa: User error: GL_INVALID_ENUM in glGetString(GL_EXTENSIONS)
- this is from GLFW as far as i can tell, its trying to get the extension
string using the old method which is not supported in a >= 3.3 core context.
Otherwise unrelated to this bug though.

valgrind:
==30990== Invalid read of size 8
==30990==at 0x9F90847: ast_interface_block::hir(exec_list*,
_mesa_glsl_parse_state*) (ast_to_hir.cpp:5688)
==30990==by 0x9F875FC: _mesa_ast_to_hir(exec_list*,
_mesa_glsl_parse_state*) (ast_to_hir.cpp:100)
==30990==by 0x9FDB07A: _mesa_glsl_compile_shader
(glsl_parser_extras.cpp:1462)
==30990==by 0x9EB843D: compile_shader (shaderapi.c:849)
==30990==by 0x9EBA1AD: _mesa_create_shader_program (shaderapi.c:1830)
==30990==by 0x9EBA7C7: _mesa_CreateShaderProgramv (shaderapi.c:1919)
==30990==by 0x6C29EED: shared_dispatch_stub_892 (glapi_mapi_tmp.h:20555)
==30990==by 0x404B0D: main (in /recording/download/20140803/mc/mc)

and a number of further errors in that function, then later the gallium state
tracker throws an assertion:
../../src/mesa/state_tracker/st_glsl_to_tgsi.cpp:2104:visit: Assertion
`var->data.location != -1' failed.

In release mode this check drops through and the r600 tgsi translator rejects
it with:
EE ../../../../../../src/gallium/drivers/r600/r600_shader.c:353
tgsi_is_supported - unsupported src 0 (dimension 1)
and replaces the shader with a no-op dummy shader to not crash.


Basically the gallium driver layer is getting bad data out from the GLSL
compiler.

-- 
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/20141012/be301b2f/attachment-0001.html>

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #156 from Malte Schr?der  ---
Hi, with kernel v3.17 these crashes where much more frequent for me too. Now
I've set aspm=0 for the radeon module and the system has been running for some
hours straight.

-- 
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/20141012/880a32bb/attachment.html>

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #155 from agapito  ---
With kernel 3.16.5 i have this bug every 2 hours approximately. With kernel
3.17 every 20 minutes.

-- 
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/20141012/e2f09218/attachment.html>

AMD GPU new API for new module

[Christian König]

Am 11.10.2014 um 20:30 schrieb Daniel Vetter:
> On Thu, Oct 9, 2014 at 8:33 PM, Oded Gabbay  wrote:
>> Thanks for the input.
>> I do _not_ intend to fork IOCTLs for new H/W generations, if possible.
>> i.e, our driver now supports 2 h/w generations with the exact same set
>> of IOCTLs and I don't see how that would change in the future..
>>
>> What I'm more worried about is supporting different sets of UMD, which
>> will require different IOCTLs for the same operation, e.g. CreateQueue
>> for HSA runtime and OpenCL runtime.
>>
>> However, due to a very limited amount of UMDs, the "regular" way of
>> adding IOCTLs may be sufficient.
>>
>> Bottom line, need to think more about it :)
> Hm, generally the ioctls should be modelled on the hw for a generic
> umd. Of course that's a bit hard in practice since predicting the
> unkown is difficult ;-).

Yeah, exactly what I'm telling to the closed source people here at AMD 
as well :) It took me a while, but I think it's slowly sinking in now 
that IOCTL interfaces shouldn't be specialized for a certain use case.

The good news is that as far as I've seen the HSA IOCTL interface it 
actually looks quite generic to me.

Regards,
Christian.

> But on intel hw we have about 5+ different
> umd stacks if you count them all, and they all seem to be more-or-less
> happy with the same ioctl interface. Like I've said it does require a
> bit a mindset change though since clean-slate designs should only be
> done when there's overwhelming reasons that the old interfaces just
> don't cut it any more. Otoh you also need to make sure that all the
> different umd teams talk to each another since ime they also err on
> the other side and each come up with their own special hack to enable
> a given new feature.
> -Daniel

AMD GPU new API for new module

[Oded Gabbay]

On 11/10/14 21:30, Daniel Vetter wrote:
> On Thu, Oct 9, 2014 at 8:33 PM, Oded Gabbay  wrote:
>> Thanks for the input.
>> I do _not_ intend to fork IOCTLs for new H/W generations, if possible.
>> i.e, our driver now supports 2 h/w generations with the exact same set
>> of IOCTLs and I don't see how that would change in the future..
>>
>> What I'm more worried about is supporting different sets of UMD, which
>> will require different IOCTLs for the same operation, e.g. CreateQueue
>> for HSA runtime and OpenCL runtime.
>>
>> However, due to a very limited amount of UMDs, the "regular" way of
>> adding IOCTLs may be sufficient.
>>
>> Bottom line, need to think more about it :)
>
> Hm, generally the ioctls should be modelled on the hw for a generic
> umd.
Agreed.
Of course that's a bit hard in practice since predicting the
> unkown is difficult ;-). But on intel hw we have about 5+ different
> umd stacks if you count them all, and they all seem to be more-or-less
> happy with the same ioctl interface.
The problems start when you start migrating UMD from one kernel driver to 
another, which already has other UMDs. Then, you may need to create new IOCTLs.
Like I've said it does require a
> bit a mindset change though since clean-slate designs should only be
> done when there's overwhelming reasons that the old interfaces just
> don't cut it any more. Otoh you also need to make sure that all the
> different umd teams talk to each another since ime they also err on
> the other side and each come up with their own special hack to enable
> a given new feature.
Sounds familiar ;)
> -Daniel
>

[Bug 82201] [HAWAII] GPU doesn't reclock, poor 3D performance

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

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

--- Comment #34 from Christian K?nig  ---
(In reply to Kai from comment #33)
> And I have non-reclocking GPU again.
> Is there any data I can provide, that would help you tracking down, what
> Windows is setting, that is preventing proper initialisation of the card for
> Linux?

Well that could actually be perfectly normal behavior. For some hardware blocks
you can upload the firmware only once after a bootup.

So what could happen is that the windows driver loads one version and the linux
driver needs a different one. The same problems applies the other way around as
well.

-- 
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/20141012/c0f475d9/attachment.html>

[Bug 66384] VDPAU playback hangs when moving window between xrandr monitors

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

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

--- Comment #8 from Christian K?nig  ---
(In reply to David Heidelberger (okias) from comment #7)
> At this moment we have working DRI3 setup (without Present for Radeon).
> 
> Is there any effort to port VDPAU to DRI3?

Not yet, but it is on the todo list.

On the other hand it sounds like a good beginners task if somebody wants to get
his hands dirty. I'm glad to help and point out the right place in the sources
if somebody volunteers.

-- 
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/20141012/0a8ad77f/attachment.html>

[Bug 66384] VDPAU playback hangs when moving window between xrandr monitors

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

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

--- Comment #7 from David Heidelberger (okias)  
---
At this moment we have working DRI3 setup (without Present for Radeon).

Is there any effort to port VDPAU to DRI3?

-- 
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/20141012/b524a129/attachment.html>

[Bug 84920] Radeon UVD error

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

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

--- Comment #1 from Christian K?nig  ---
(In reply to Apostolos B. from comment #0) 
> Oct 11 23:20:38 mainland kernel: [drm:radeon_uvd_cs_msg] *ERROR* No more
> free UVD handles!

What browser do you use? Do you have video acceleration enabled in flash?

It sounds like flash is trying to play a lot of videos at the same time.

-- 
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/20141012/ed62aaf7/attachment-0001.html>

[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi

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

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

--- Comment #19 from David Heidelberger (okias)  
---
After Marek fixed some HyperZ issues, older issues are FIXED or waiting to
confirm. As usual, I tested it and didn't noticed any problems.

Is there possibility enable HyperZ soon as possible, to be able get enough
feedback until 10.4 release?

-- 
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/20141012/3bb3b34a/attachment.html>

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #154 from Jacob  ---
(In reply to agapito from comment #152)
> IMPORTANT
> 
> This was my first message in this bug report: 
> 
> I have the same problem with my HD 7950; using hangouts, playing Left for
> Dead 2, or watching a flash video my screen goes crazy with vertical lines
> or grey fog. Started when i upgraded to testing repo (Archlinux) and
> downloaded the newest linux-firmware package, who includes TAHITI_mc2.bin. I
> suffered this bug on kernels 3.14 and 3.15. 
> 
> --
> 
> In Archlinux i was stable with kernel 3.14, and the problem started when i
> was using the new firmware. I thought that the new firmware was the cause of
> this bug, but NO, because i had the same bug using the old firmare, so this
> bug it was caused by one of this radeon commits backported to kernel 3.14.6
> (the first kernel using newest firmware). I am 100% sure.
> 
> 
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/
> ?id=refs/tags/v3.14.21=1300

I've just compared the git messages from your link and from
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.15-rc3-utopic/CHANGES and it
seems like the commits made to drm/radeon, are the only commits these two
kernel versions have in common.
Only seven of them are part of 3.15-rc3, which crashed on me yesterday, so it
would seem like the crashes are caused by one of those commits

-- 
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/20141012/22911af8/attachment.html>

[Bug 82201] [HAWAII] GPU doesn't reclock, poor 3D performance

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

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

Kai  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |---

--- Comment #33 from Kai  ---
And I have non-reclocking GPU again.

But I think, I've a pretty good idea now, what's causing it: coming off a
Windows boot. There's another thing I've noticed when coming off a Windows
boot: the hid-lg-g710-plus module ([0]) doesn't get loaded properly during
initrd (something that is needed, because otherwise this keyboard has the
tendency to spam the console/input with "6"). The loading of that module can
usually be fixed by one reboot cycle. The reclocking takes a bit longer/more
effort.

Is there any data I can provide, that would help you tracking down, what
Windows is setting, that is preventing proper initialisation of the card for
Linux?


[0] <https://github.com/Wattos/logitech-g710-linux-driver/> (sadly an
out-of-tree driver, since nobody seemed to have reacted to the author on kernel
input mailing list: <http://thread.gmane.org/gmane.linux.kernel.input/30258>)

-- 
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/20141012/015b2653/attachment.html>

[Bug 81391] nouveau E[ PFIFO][0000:01:00.0] read fault at 0x000020f000 [PTE] from BAR1/HOST_CPU on channel 0x00ffbdf000 [unknown]

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

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

Srihari Vijayaraghavan  changed:

   What|Removed |Added

 Kernel Version|3.16.0-rc7  |3.17.0

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

[PATCH v2] gpu: drm: drm_dp_mst_topology.c: Fix improper use of strncat

[Rickard Strandqvist]

Fixed wrong usage of strncat, switched to strlcpy.
While sending the string size to function to reduce
the potential for misuse in future.

Signed-off-by: Rickard Strandqvist 
---
 drivers/gpu/drm/drm_dp_mst_topology.c |   15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index ac3c273..2a146d1 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -995,19 +995,20 @@ static void drm_dp_check_port_guid(struct 
drm_dp_mst_branch *mstb,

 static void build_mst_prop_path(struct drm_dp_mst_port *port,
struct drm_dp_mst_branch *mstb,
-   char *proppath)
+   char *proppath,
+   size_t proppath_size)
 {
int i;
char temp[8];
-   snprintf(proppath, 255, "mst:%d", mstb->mgr->conn_base_id);
+   snprintf(proppath, proppath_size, "mst:%d", mstb->mgr->conn_base_id);
for (i = 0; i < (mstb->lct - 1); i++) {
int shift = (i % 2) ? 0 : 4;
int port_num = mstb->rad[i / 2] >> shift;
-   snprintf(temp, 8, "-%d", port_num);
-   strncat(proppath, temp, 255);
+   snprintf(temp, sizeof(temp), "-%d", port_num);
+   strlcat(proppath, temp, proppath_size);
}
-   snprintf(temp, 8, "-%d", port->port_num);
-   strncat(proppath, temp, 255);
+   snprintf(temp, sizeof(temp), "-%d", port->port_num);
+   strlcat(proppath, temp, proppath_size);
 }

 static void drm_dp_add_port(struct drm_dp_mst_branch *mstb,
@@ -1078,7 +1079,7 @@ static void drm_dp_add_port(struct drm_dp_mst_branch 
*mstb,

if (created && !port->input) {
char proppath[255];
-   build_mst_prop_path(port, mstb, proppath);
+   build_mst_prop_path(port, mstb, proppath, sizeof(proppath));
port->connector = (*mstb->mgr->cbs->add_connector)(mstb->mgr, 
port, proppath);
}

-- 
1.7.10.4

[PATCH 2/2] drm/armada: convert to use vblank_on/off calls

[Russell King]

A future commit changes the way various vblank calls behave, which
causes drivers to break.  Converting to use the drm_crtc_vblank_on/off
calls avoids this breakage.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_crtc.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index ac2d73f4af45..73efc606c753 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -260,7 +260,7 @@ static void armada_drm_vblank_off(struct armada_crtc *dcrtc)
 * Tell the DRM core that vblank IRQs aren't going to happen for
 * a while.  This cleans up any pending vblank events for us.
 */
-   drm_vblank_off(dev, dcrtc->num);
+   drm_crtc_vblank_off(>crtc);

/* Handle any pending flip event. */
spin_lock_irq(>event_lock);
@@ -289,6 +289,8 @@ static void armada_drm_crtc_dpms(struct drm_crtc *crtc, int 
dpms)
armada_drm_crtc_update(dcrtc);
if (dpms_blanked(dpms))
armada_drm_vblank_off(dcrtc);
+   else
+   drm_crtc_vblank_on(>crtc);
}
 }

@@ -526,7 +528,7 @@ static int armada_drm_crtc_mode_set(struct drm_crtc *crtc,
/* Wait for pending flips to complete */
wait_event(dcrtc->frame_wait, !dcrtc->frame_work);

-   drm_vblank_pre_modeset(crtc->dev, dcrtc->num);
+   drm_crtc_vblank_off(crtc);

crtc->mode = *adj;

@@ -617,7 +619,7 @@ static int armada_drm_crtc_mode_set(struct drm_crtc *crtc,

armada_drm_crtc_update(dcrtc);

-   drm_vblank_post_modeset(crtc->dev, dcrtc->num);
+   drm_crtc_vblank_on(crtc);
armada_drm_crtc_finish_fb(dcrtc, old_fb, dpms_blanked(dcrtc->dpms));

return 0;
-- 
1.8.3.1

[PATCH 1/2] drm/armada: fix page_flip refcounting leak

[Russell King]

A refcounting leak was found of the original frame buffer attached to
the CRTC when using the page_flip ioctl, resulting in the frame buffer
never being freed.

This was not obvious initially, as if the page flip subsequently
re-attaches the original frame buffer, the refcounts will be balanced.
However, if the original frame buffer is freed, then it will be leaked.

Fix this by ensuring that we take a reference on the incoming fb, but
rely on the queued work to drop that ref count.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_crtc.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index 1f0875c26dc5..ac2d73f4af45 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -945,18 +945,15 @@ static int armada_drm_crtc_page_flip(struct drm_crtc 
*crtc,
armada_reg_queue_end(work->regs, i);

/*
-* Hold the old framebuffer for the work - DRM appears to drop our
-* reference to the old framebuffer in drm_mode_page_flip_ioctl().
+* Ensure that we hold a reference on the new framebuffer.
+* This has to match the behaviour in mode_set.
 */
-   drm_framebuffer_reference(work->old_fb);
+   drm_framebuffer_reference(fb);

ret = armada_drm_crtc_queue_frame_work(dcrtc, work);
if (ret) {
-   /*
-* Undo our reference above; DRM does not drop the reference
-* to this object on error, so that's okay.
-*/
-   drm_framebuffer_unreference(work->old_fb);
+   /* Undo our reference above */
+   drm_framebuffer_unreference(fb);
kfree(work);
return ret;
}
-- 
1.8.3.1