[linux-sunxi] [PATCH 3/7] drm/sun4i: Add SAT and DRC drivers

[Peter Korsgaard]

> "Maxime" == Maxime Ripard  writes:

Hi,

 > The A33 pipeline also has some new components called SAT and DRC. Even
 > though their exact features and programming model is not known (or
 > documented), they need to be clocked for the pipeline to carry the video
 > signal all the way.

 > Add minimal drivers for those that just claim the needed resources for the
 > pipeline to operate properly.

 > Signed-off-by: Maxime Ripard 
 > ---
 >  .../bindings/display/sunxi/sun4i-drm.txt   |  37 +++
 >  drivers/gpu/drm/sun4i/Makefile |   3 +-
 >  drivers/gpu/drm/sun4i/sun6i_drc.c  | 117 
 > +
 >  drivers/gpu/drm/sun4i/sun8i_sat.c  | 105 ++
 >  4 files changed, 261 insertions(+), 1 deletion(-)
 >  create mode 100644 drivers/gpu/drm/sun4i/sun6i_drc.c
 >  create mode 100644 drivers/gpu/drm/sun4i/sun8i_sat.c

 > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
 > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
 > index d467ea93ac08..87c3c8dd34cb 100644
 > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
 > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
 > @@ -51,6 +51,43 @@ Required properties:
 >second the block connected to the TCON channel 1 (usually the TV
 >encoder)

 > +SAT
 > +---
 > +
 > +The SAT, found in the A33, allows to do some color correction.
 > +
 > +Required properties:
 > +  - compatible: value must be one of:
 > +* allwinner,sun8i-a33-sat
 > +  - reg: base address and size of the memory-mapped region.
 > +  - clock: phandles to bus clock feeding the SAT
 > +  - resets: phandles to the reset line driving the SAT
 > +
 > +- ports: A ports node with endpoint definitions as defined in
 > +  Documentation/devicetree/bindings/media/video-interfaces.txt. The
 > +  first port should be the input endpoints, the second one the outputs
 > +
 > +DRC
 > +---
 > +
 > +The DRC, found in the latest Allwinner SoCs (A31, A23, A33), allows to
 > +do some backlight control to enhance the power consumption.

'Enhance the power consumption'? That doesn't sound like something you
would want ;) Presumably it is something to allow you to save power by
dynamically adjusting LCD backlight and pixel brightness/contrast
depending on screen content? I believe this is typically called content
adaptive backlight control:

https://www.ecnmag.com/article/2010/04/content-adaptive-lcd-backlight-control

You spell out what DRC and SAT stands for in the driver source code,
perhaps it also makes sense to do it here?

Perhaps rewording it to something like this is clearer:

.. allows to dynamically adjust pixel brightness/contrast based on
histogram measurements for LCD content adaptive backlight control.

-- 
Bye, Peter Korsgaard

[Bug 97594] [amdgpu SI] "drm/amd/amdgpu: Add GRBM lock to various SI functions" breaks amdgpu support for SI

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

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

--- Comment #2 from Arek Ruśniak  ---
sorry for lack of description

It's Alex's drm-next-4.9-wip branch.

First bad commit: 
commit  deca1d1f16eebfa0d070eed50a221e01cf716ee0
author  Tom St Denis 

drm/amd/amdgpu: Add GRBM lock to various SI functions
Add missing lock around SE/SH/INSTANCE selections.

-- 
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/20160904/3931616a/attachment.html>

[Bug 97594] [amdgpu SI] "drm/amd/amdgpu: Add GRBM lock to various SI functions" breaks amdgpu support for SI

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

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

--- Comment #1 from Arek Ruśniak  ---
Created attachment 126205
  --> https://bugs.freedesktop.org/attachment.cgi?id=126205=edit
commit: deca1d1 reverted

-- 
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/20160904/d579aeb2/attachment.html>

[PATCH] drm/tegra: Expose color key and plane blending controls to userspace

[Dmitry Osipenko]

On 02.09.2016 18:51, Thierry Reding wrote:
> On Fri, Sep 02, 2016 at 05:32:19PM +0200, Thierry Reding wrote:
>> On Fri, Sep 02, 2016 at 12:33:42PM +0300, Dmitry Osipenko wrote:
>>> Chromakey is a simple way of video overlay overlap implementation. This
>>> patch adds 2 new IOCTL's: first - sets color key and is common across of
>>> all Tegra SoC's, second - sets plane blending controls and allows to
>>> utilize the color key, this one is exclusive to Tegra20/30.
>>>
>>> Signed-off-by: Dmitry Osipenko 
>>> ---
>>>  drivers/gpu/drm/tegra/dc.c   | 150 +---
>>>  drivers/gpu/drm/tegra/dc.h   |   6 ++
>>>  drivers/gpu/drm/tegra/drm.c  | 159 
>>> +++
>>>  drivers/gpu/drm/tegra/drm.h  |  14 
>>>  include/uapi/drm/tegra_drm.h |  34 +
>>>  5 files changed, 337 insertions(+), 26 deletions(-)
>>
>> I think these are really nice features to have, but these would need to
>> be exposed as properties, rather than custom driver-specific IOCTLs. It
>> seems to me like the colorkey feature could be implemented in much the
>> same way as in the Armada, RCar and Nouveau drivers.
>>

Now, instead of custom driver-specific IOCTL's we would have custom
driver-specific DRM object properties. I'm not sure how they should be 
represented.

Should we assume that primary plane is the only source of colorkey? On Tegra,
colorkey isn't matched against the underlying plane, it represents area on the
plane (that uses that colorkey) that should be blended. In case of Xv, I have to
enable colorkey matching for the primary plane and make transparent areas of the
primary plane where colorkey matches and overlapped by the overlay, areas that
are overlapped and NOT matching colorkey are displayed on top of the overlay
(like mouse cursor or some window).

Should we assign colorkey (0xkey value itself) property per overlay plane? WIN_B
will use colokey0, WIN_C colorkey1.
Or make colorkey values property of CRTC? So it would be possible (probably not
so useful) to have 2 color keys used for one overlay.

Should colorkey be enabled/disabled via properties? I.e. it will be
"use_colorkey" plane property. Feels a bit icky to me.

I see only DRM_IOCTL_MODE_OBJ_SETPROPERTY, so no way to set all properties at 
once?

>> As for the blending options, I think they should be exposed in terms of
>> the zpos property, to allow generic userspace to make use of them. Also
>> can you explain why this needs to be exclusive to Tegra20 and Tegra30?

What about the actual alpha blending? What about having different blending 
modes?

Should we sacrifice it all and support only 1-2 use cases?

Given that properties are specific to each driver, I can hardly imagine such
generic userspace. Could you give an example?

> Ah... I just realized that the blending interface changed on Tegra124.
> All the more reason to expose this more generically, that way we can
> hide the differences between a property and support the same interface
> across all generations of Tegra.
> 
> Also see this:
> 
>   
> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/de9295aabdb7f80555c9b77b29ac77bcdac3280b
> 

-- 
Dmitry

[Bug 97594] [amdgpu SI] "drm/amd/amdgpu: Add GRBM lock to various SI functions" breaks amdgpu support for SI

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

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

Bug ID: 97594
   Summary: [amdgpu SI] "drm/amd/amdgpu: Add GRBM lock to various
SI functions" breaks amdgpu support for SI
   Product: DRI
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: arek.rusi at gmail.com

Created attachment 126204
  --> https://bugs.freedesktop.org/attachment.cgi?id=126204=edit
dmesg for first bad commit

With this commit displays off during loading amdgpu, sysrq don't work, boot is
stopped. 
When i reverted it, amdgpu works as always.

dmesg is silent

-- 
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/20160904/05dd9a25/attachment.html>

Regression in v4.8-rc4: i915 flickering since commit 1c80c25fb6

[Dominik Brodowski]

Hi!

Since commit 1c80c25fb6 (determined by git bisect, and confirmed by
reverting this patch on top of 9ca581b50d), the sceen on my DELL XPS 13
is flickering every once in a while (sometimes multiple times per
second, sometimes only every few seconds).

That's for

00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated 
Graphics (rev 09) (prog-if 00 [VGA controller])
Subsystem: Dell Device 0665
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915

and Debian Jessie userland.

Best,
Dominik

[PATCH 1/1] drm/i915/dsi: silence a warning about uninitialized return value

[Nicolas Iooss]

When building the kernel with clang and some warning flags, the compiler
reports that the return value of dcs_get_backlight() may be
uninitialized:

drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c:53:2: error: variable
'data' is used uninitialized whenever 'for' loop exits because its
condition is false [-Werror,-Wsometimes-uninitialized]
for_each_dsi_port(port, intel_dsi->dcs_backlight_ports) {
^~~
drivers/gpu/drm/i915/intel_dsi.h:126:49: note: expanded from macro
'for_each_dsi_port'
#define for_each_dsi_port(__port, __ports_mask)
for_each_port_masked(__port, __ports_mask)
^~
drivers/gpu/drm/i915/i915_drv.h:322:26: note: expanded from macro
'for_each_port_masked'
for ((__port) = PORT_A; (__port) < I915_MAX_PORTS; (__port)++)  \
^
drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c:60:9: note:
uninitialized use occurs here
return data;
   ^~~~

As intel_dsi->dcs_backlight_ports seems to be always initialized to a
non-null value, the content of the for loop is always executed and there
is no bug in the current code. Nevertheless the compiler has no way of
knowing that assumption, so initialize variable 'data' to silence the
warning here.

Signed-off-by: Nicolas Iooss 
---
 drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c 
b/drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c
index ac7c6020c443..eec45856f910 100644
--- a/drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dsi_dcs_backlight.c
@@ -46,7 +46,7 @@ static u32 dcs_get_backlight(struct intel_connector 
*connector)
struct intel_encoder *encoder = connector->encoder;
struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
struct mipi_dsi_device *dsi_device;
-   u8 data;
+   u8 data = 0;
enum port port;

/* FIXME: Need to take care of 16 bit brightness level */
-- 
2.9.3

[Bug 97593] [amdgpu SI] low performace, low (about 1/4) VRAM usage

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

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

--- Comment #2 from Arek Ruśniak  ---
Created attachment 126203
  --> https://bugs.freedesktop.org/attachment.cgi?id=126203=edit
xorg log for heaven

this is next boot then dmesg, heaven starts at 78 sec.

-- 
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/20160904/47c3efc4/attachment-0001.html>

[Bug 97590] Fury X (Fiji) LEDs do not reflect GPU load

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

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

--- Comment #1 from John Bridgman  ---
There was a Phoronix article recently celebrating the addition of an LED driver
to the Nouveau driver... guessing that something similar will need to be done
for amdgpu eventually.

-- 
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/20160904/d9f374e6/attachment.html>

[Bug 97593] [amdgpu SI] low performace, low (about 1/4) VRAM usage

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

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

--- Comment #1 from Arek Ruśniak  ---
Created attachment 126202
  --> https://bugs.freedesktop.org/attachment.cgi?id=126202=edit
kernel log for heaven

-- 
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/20160904/3e94504c/attachment.html>

[Bug 97593] [amdgpu SI] low performace, low (about 1/4) VRAM usage

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

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

Bug ID: 97593
   Summary: [amdgpu SI] low performace, low (about 1/4) VRAM usage
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: arek.rusi at gmail.com

Created attachment 126201
  --> https://bugs.freedesktop.org/attachment.cgi?id=126201=edit
screenshot from unigine-heaven

Hi, I've tried amdgpu driver for SI and GL apps run much slower than for
radeon.
Unigine-Heaven drops from 20 fps to 8 fps
VRAM usage ~ 200MB
requested VRAM ~500MB
GTT usage ~ 500MB 
Look at the screenshot for more.

drm-next-4.9-wip: 48fad3aff638c7bc16656e31047f689aa44020a1 
xorg-git
mesa-git:98f734e
llvm-svn:280612
libdrm:4462303 + 2 patches for SI support from amd-gfx's list

I used unigine-heaven benchmark for first shot but more apps in affected:
Alien Isolation
Shadow of Mordor
Bioshock Infinite
Metro 2033 Redux
XCOM
The Witcher 2
xonotic (for quality "low" performance is normal) 
In fact only glxgears, lightsmark, gputest(all),openarena are not affected :) 

In any case VRAM-usage isn't raised over a 250MB but dmesg & xorg logs are
different for each games, I will try update the logs later.
I've tested it with dpm=1, but dpm=0 makes nothing.

-- 
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/20160904/90051dce/attachment.html>

[PATCH] drm/etnaviv: Always init gpu->memory_base

[Marek Vasut]

On 08/26/2016 06:06 PM, Russell King - ARM Linux wrote:
> On Fri, Aug 26, 2016 at 04:25:13PM +0200, Marek Vasut wrote:
>> The content of gpu->memory_base should point to start of RAM, not zero.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Lucas Stach 
>> Cc: Christian Gmeiner 
>> Cc: Russell King 
>> ---
>>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
>> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> index ff6aa5d..a168532 100644
>> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> @@ -588,6 +588,8 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
>>  gpu->memory_base = PHYS_OFFSET;
>>  else
>>  gpu->memory_base = dma_mask - SZ_2G + 1;
>> +} else {
>> +gpu->memory_base = PHYS_OFFSET;
>>  }
> 
> The code is correct as-is.  Etnaviv GPUs are not without their own
> weirdness.

I suspected as much. I think my GPU isn't MC2.0 if I read the
minor_features0 bits right .

> For MC1.0 3D GPUs (eg, GC600 as found on Dove), there is an issue
> where _most_ GPU accesses go through a memory offsetting via the
> memory base, but accesses by the tiler do not: they bypass the
> memory base offsetting.
> 
> We have two options to work around that:
> 
> 1. Maintain two GPU address spaces, and mark relocations according
>to their use.  This is error prone: we would have to have the
>kernel verify the relocation type is valid for the load state
>address to avoid obvious security issues, and the maintanence
>of these different address spaces becomes more complex.
> 
> 2. Force the address offset to zero so all GPU accesses map through
>the same method irrespective of which GPU block is performing the
>access.
> 
> We've chosen (2) because it is much simpler, and less error prone,
> plus it fits with the platforms that we're aware of at the moment.
> I did push for the relocations to have an additional member which
> can be used to flag the type of the relocation if necessary in the
> future without changing the interface structure layouts, so we do
> have that option if we really need to do it - but we'd all prefer
> to avoid it.

I see, thanks for the detailed explanation.

> Also, iirc, the GPU tiler with MC1.0 is unable to access addresses
>> = 2GiB no matter what - if you do have a 3D GPU with MC1.0, and
> you have physical memory above 2GiB... there's no currently known
> solution... you lose.

Yes, i.MX6SX has GC400T and the DRAM starts at 0x8000_ .
Did I misunderstand something ?

-- 
Best regards,
Marek Vasut

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

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

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

--- Comment #36 from Marek Olšák  ---
If you're testing Mesa git, would you please set GALLIUM_DDEBUG="pipelined
2000" and run TF2, wait until the GPU hangs and repeat. After it happens for
the 3rd time, please zip and attach the contents of ~/ddebug_dumps/*. There
should be 3 files.

Though I've got a hunch that we're just running around in circles.

-- 
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/20160904/e4efb7b0/attachment.html>

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

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

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

--- Comment #35 from pandiculationfinch at gmail.com ---
game froze again after ~20minutes. using the 20130725 version firmware. so if
downgrading to 20130725 fixes TF2 it likely isn't the same issue as TF2.
game: stellaris

commands run to downgrade to linux-firmware-20130725:
sudo pacman -U /var/cache/pacman/pkg/linux-firmware-20130725-1-any.pkg.tar.xz
sudo pacman -S linux

other info:
Name: llvm-libs
Version : 3.8.1-1
Name: linux
Version : 4.7.2-1
Name: mesa-git
Version : 84594.98f734e-1
Name: linux-firmware
Version : 20130725-1

lspci:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Oland
XT [Radeon HD 8670 / R7 250/350]
01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Cape
Verde/Pitcairn HDMI Audio [Radeon HD 7700/7800 Series]

boot logs:
Sep 04 11:12:28 jambli kernel: [drm] initializing kernel modesetting (OLAND
0x1002:0x6610 0x174B:0xE269 0x00).
Sep 04 11:12:28 jambli kernel: [drm] register mmio base: 0xFDD8
Sep 04 11:12:28 jambli kernel: [drm] register mmio size: 262144
Sep 04 11:12:28 jambli kernel: ATOM BIOS: C66201
Sep 04 11:12:28 jambli kernel: radeon :01:00.0: VRAM: 2048M
0x - 0x7FFF (2048M used)
Sep 04 11:12:28 jambli kernel: radeon :01:00.0: GTT: 2048M
0x8000 - 0x
Sep 04 11:12:28 jambli kernel: [drm] Detected VRAM RAM=2048M, BAR=256M
Sep 04 11:12:28 jambli kernel: [drm] RAM width 128bits DDR
Sep 04 11:12:28 jambli kernel: [TTM] Zone  kernel: Available graphics memory:
8209378 kiB
Sep 04 11:12:28 jambli kernel: [TTM] Zone   dma32: Available graphics memory:
2097152 kiB
Sep 04 11:12:28 jambli kernel: [TTM] Initializing pool allocator
Sep 04 11:12:28 jambli kernel: [TTM] Initializing DMA pool allocator
Sep 04 11:12:28 jambli kernel: [drm] radeon: 2048M of VRAM memory ready
Sep 04 11:12:28 jambli kernel: [drm] radeon: 2048M of GTT memory ready.
Sep 04 11:12:28 jambli kernel: [drm] Loading oland Microcode
Sep 04 11:12:28 jambli kernel: radeon :01:00.0: Direct firmware load for
radeon/oland_pfp.bin failed with error -2
Sep 04 11:12:28 jambli systemd[1]: Created slice system-lvm2\x2dpvscan.slice.
Sep 04 11:12:28 jambli kernel: radeon :01:00.0: Direct firmware load for
radeon/oland_me.bin failed with error -2
Sep 04 11:12:28 jambli kernel: radeon :01:00.0: Direct firmware load for
radeon/oland_ce.bin failed with error -2
Sep 04 11:12:28 jambli kernel: radeon :01:00.0: Direct firmware load for
radeon/oland_rlc.bin failed with error -2
Sep 04 11:12:28 jambli kernel: radeon :01:00.0: Direct firmware load for
radeon/oland_mc.bin failed with error -2
Sep 04 11:12:28 jambli kernel: radeon :01:00.0: Direct firmware load for
radeon/OLAND_mc2.bin failed with error -2
Sep 04 11:12:28 jambli kernel: [drm] radeon/OLAND_mc.bin: 31452 bytes
Sep 04 11:12:28 jambli kernel: radeon :01:00.0: Direct firmware load for
radeon/oland_smc.bin failed with error -2
Sep 04 11:12:28 jambli kernel: radeon :01:00.0: Direct firmware load for
radeon/OLAND_smc.bin failed with error -2
Sep 04 11:12:28 jambli kernel: smc: error loading firmware
"radeon/OLAND_smc.bin"
Sep 04 11:12:28 jambli kernel: [drm] Internal thermal controller with fan
control
Sep 04 11:12:28 jambli kernel: [drm] radeon: power management initialized
Sep 04 11:12:28 jambli kernel: radeon :01:00.0: Direct firmware load for
radeon/TAHITI_vce.bin failed with error -2
Sep 04 11:12:28 jambli kernel: radeon :01:00.0: radeon_vce: Can't load
firmware "radeon/TAHITI_vce.bin"
Sep 04 11:12:28 jambli kernel: radeon :01:00.0: failed VCE (-2) init.

-- 
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/20160904/123f8eae/attachment-0001.html>

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

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

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

--- Comment #34 from pandiculationfinch at gmail.com ---
I should note I was testing against stellaris.

-- 
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/20160904/c6daad54/attachment.html>

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

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

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

--- Comment #33 from pandiculationfinch at gmail.com ---
not certain but assuming I ran the test correctly, I experienced a crash using
the oldest linux firmware I had linux-firmware-20140828. that leaves 13 months
of time to bisect if linux-firmware 20130725-1 does indeed work. I'll see about
trying installing the 20130725 version later have other stuff I need to do.

commands run to downgrade to linux-firmware-20140828:
sudo pacman -U
/var/cache/pacman/pkg/linux-firmware-20140828.13eb208-1-any.pkg.tar.xz
sudo pacman -S linux

after downgrade I had the following error on boot, so I'm assuming it worked:
Sep 04 09:53:14 jambli kernel: radeon :01:00.0: Direct firmware load for
radeon/TAHITI_vce.bin failed with error -2
Sep 04 09:53:14 jambli kernel: radeon :01:00.0: radeon_vce: Can't load
firmware "radeon/TAHITI_vce.bin"
Sep 04 09:53:14 jambli kernel: radeon :01:00.0: failed VCE (-2) init.

other info:
Name: llvm-libs
Version : 3.8.1-1
Name: linux
Version : 4.7.2-1
Name: mesa-git
Version : 84594.98f734e-1

Extended renderer info (GLX_MESA_query_renderer):
Vendor: X.Org (0x1002)
Device: AMD OLAND (DRM 2.45.0 / 4.7.2-1-ARCH, LLVM 4.0.0) (0x6610)
Version: 12.1.0
Accelerated: yes
Video memory: 2048MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 4.3
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.1

I forget the exact card off the top of my head but here is the output of lspci,
if you need more precise card information let me know how to get it from the
cli =):
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Oland
XT [Radeon HD 8670 / R7 250/350]
01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Cape
Verde/Pitcairn HDMI Audio [Radeon HD 7700/7800 Series]

-- 
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/20160904/b82df005/attachment.html>

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

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

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

--- Comment #32 from Rosco P. Coltrane  ---
I tested today 3 different firmwares on manjaro (HD7970) 

linux-firmware-20150527.3161bfa-1-any.pkg.tar.xz (chosen because it was a bit
before the first bugs were reported with TF2)

This allowed me to play TF2 without bugs for ~30 min. Then I had the bug
(screen freeze, sound loop) but the system recovered fine after 20 sec with no
loss of performance. I still had a problem before and after the bug with the
mouse pointer which wasn't visible at all time.

linux-firmware-20131013.7d0c7a8-1-any.pkg.tar.xz

This allowed me to play for a good hour, then: bug + recovery after 20 sec. At
the fifth bug the screen simply hanged, TF2 and steam crashed. (had to
ctrl+alt+f2). This one didn't have the mouse bug. This is the most stable TF2
experience I can get.

linux-firmware-20130725-1-any.pkg.tar.xz (earlier firmware available in the
repo)

This one crashed after 2 seconds loading the first map.

The first two firmwares also seem to have fixed the same bug which was present
in "Victor Vran" (same symptoms, screen freeze + sound loop).

-- 
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/20160904/5b9f1218/attachment.html>

[Bug 60533] CVE-2013-7445: Remote web page triggerable DOS in Linux DRM graphics.

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

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

--- Comment #42 from Mikhail  ---
17:17:15 ioctl(8, DRM_IOCTL_I915_GEM_BUSY, 0x7ffd3e0c1fc0) = 0
17:17:15 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffd3e0c1f10) = 0
17:17:15 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffd3e0c20a0) = 0
17:17:15 ioctl(8, DRM_IOCTL_I915_GEM_BUSY, 0x7ffd3e0c2180) = 0
17:17:15 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffd3e0c20d0) = 0
17:17:15 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffd3e0c2260) = 0
17:17:17 ioctl(8, DRM_IOCTL_I915_GEM_BUSY, 0x7ffd3e0c2180) = 0
17:17:17 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffd3e0c20d0) = 0
17:17:17 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffd3e0c2260) = 0
17:17:17 ioctl(8, DRM_IOCTL_I915_GEM_BUSY, 0x7ffd3e0c1e00) = 0
17:17:17 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffd3e0c1d50) = 0
17:17:17 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffd3e0c1ee0) = 0
17:17:17 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffd3e0c1c20) = 0
17:17:17 ioctl(8, DRM_IOCTL_I915_GEM_EXECBUFFER2, 0x7ffd3e0c1bb0) = 0
17:17:17 ioctl(8, DRM_IOCTL_I915_GEM_MADVISE, 0x7ffd3e0c1ba0) = 0
17:17:17 munmap(0x7ff2e02d4000, 32768)  = 0
17:17:17 ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffd3e0c1b90) = 0
17:17:17 ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffd3e0c1b90) = 0
17:17:17 munmap(0x7ff2ba4fc000, 65536)  = 0
17:17:17 ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffd3e0c1b90) = 0
17:17:17 munmap(0x7ff2a4637000, 114688) = 0
17:17:17 ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffd3e0c1b90) = 0
17:17:17 munmap(0x7ff2b5938000, 114688) = 0
17:17:17 ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffd3e0c1b90) = 0
17:17:17 munmap(0x7ff2a45c3000, 114688) = 0
17:17:17 ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffd3e0c1b90) = 0
17:17:17 munmap(0x7ff2a5be5000, 114688) = 0
17:17:17 ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffd3e0c1b90) = 0
17:17:17 munmap(0x7ff2a5bc9000, 114688) = 0
17:17:17 ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffd3e0c1b90) = 0
17:17:17 munmap(0x7ff2b5543000, 114688) = 0
17:17:17 ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffd3e0c1b90) = 0
17:17:20 munmap(0x7ff2a626c000, 114688) = 0
17:17:20 ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffd3e0c1b90) = 0
17:17:22 munmap(0x7ff2b55cf000, 114688) = 0
17:17:22 ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffd3e0c1b90) = 0
17:17:22 munmap(0x7ff2a4484000, 114688) = 0
17:17:22 ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffd3e0c1b90) = 0
17:17:22 munmap(0x7ff2a466f000, 114688) = 0
17:17:22 ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffd3e0c1b90) = 0
17:17:22 munmap(0x7ff2a4118000, 114688) = 0
17:17:22 ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffd3e0c1b90) = 0
17:17:22 munmap(0x7ff2b5418000, 114688) = 0
17:17:22 ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffd3e0c1b90) = 0
17:17:22 munmap(0x7ff2a5e1d000, 131072) = 0
17:17:22 ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffd3e0c1b90) = 0
17:17:22 munmap(0x7ff2a4078000, 131072) = 0
17:17:22 ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffd3e0c1b90) = 0
17:17:22 munmap(0x7ff2a45df000, 131072) = 0
17:17:22 ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffd3e0c1b90) = 0
17:17:22 munmap(0x7ff2a611, 131072) = 0
17:17:22 ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffd3e0c1b90) = 0
17:17:22 munmap(0x7ff2a40f8000, 131072) = 0
17:17:22 ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffd3e0c1b90) = 0
17:17:22 munmap(0x7ff2b434c000, 131072) = 0
17:17:22 ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffd3e0c1b90) = 0
17:17:23 munmap(0x7ff2a40d8000, 131072) = 0
17:17:23 ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffd3e0c1b90) = 0
17:17:23 ioctl(8, DRM_IOCTL_I915_GEM_CREATE, 0x7ffd3e0c1bd0) = 0
17:17:23 ioctl(8, DRM_IOCTL_I915_GEM_MMAP, 0x7ffd3e0c1b80) = 0
17:17:23 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffd3e0c1b80) = 0
17:17:23 ioctl(8, DRM_IOCTL_I915_GEM_BUSY, 0x7ffd3e0c1fc0) = 0
17:17:23 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffd3e0c1f10) = 0
17:17:23 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffd3e0c20a0) = 0
17:17:23 ioctl(8, DRM_IOCTL_I915_GEM_BUSY, 0x7ffd3e0c2180) = 0
17:17:23 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffd3e0c20d0) = 0
17:17:23 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffd3e0c2260) = 0
17:17:23 ioctl(8, DRM_IOCTL_I915_GEM_BUSY, 0x7ffd3e0c2180) = 0
17:17:23 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffd3e0c20d0) = 0

mouse pointer here freeze

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.

[Bug 60533] CVE-2013-7445: Remote web page triggerable DOS in Linux DRM graphics.

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

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

--- Comment #41 from Mikhail  ---
17:01:49 recvmsg(29, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily
unavailable)
17:01:49 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=8,
events=POLLIN}, {fd=10, events=POLLIN}, {fd=20, events=POLLIN}, {fd=29,
events=POLLIN}, {fd=32, events=POLLIN}, {fd=34, events=POLLIN}, {fd=48,
events=POLLIN}, {fd=50, events=POLLIN}, {fd=51, events=0}, {fd=53,
events=POLLIN}, {fd=59, events=POLLIN}, {fd=60, events=POLLIN}, {fd=66,
events=POLLIN}, {fd=70, events=POLLIN}, {fd=72, events=POLLIN}, {fd=73,
events=POLLIN}], 18, 0) = 3 ([{fd=4, revents=POLLIN}, {fd=8, revents=POLLIN},
{fd=10, revents=POLLIN}])
17:01:49 read(4, "\1\0\0\0\0\0\0\0", 16) = 8
17:01:49 epoll_wait(10, [{EPOLLIN, {u32=2906628656, u64=94517956944432}}], 32,
0) = 1
17:01:49 read(19,
"N\t\0\0\0\0\0\0\v,\17\0\0\0\0\0\2\0\0\0\3\0\0\0N\t\0\0\0\0\0\0"..., 13920) =
216
17:01:49 read(19, 0x55f6ad406780, 13728) = -1 EAGAIN (Resource temporarily
unavailable)
17:01:49 read(19, 0x55f6ad406768, 13752) = -1 EAGAIN (Resource temporarily
unavailable)
17:01:49 read(19, 0x55f6ad406750, 13776) = -1 EAGAIN (Resource temporarily
unavailable)
17:01:49 read(19, 0x55f6ad406738, 13800) = -1 EAGAIN (Resource temporarily
unavailable)
17:01:49 read(19, 0x55f6ad406720, 13824) = -1 EAGAIN (Resource temporarily
unavailable)
17:01:49 read(19, 0x55f6ad406708, 13848) = -1 EAGAIN (Resource temporarily
unavailable)
17:01:49 read(19, 0x55f6ad4066f0, 13872) = -1 EAGAIN (Resource temporarily
unavailable)
17:01:49 read(19, 0x55f6ad4066d8, 13896) = -1 EAGAIN (Resource temporarily
unavailable)
17:01:49 read(19, 0x55f6ad4066c0, 13920) = -1 EAGAIN (Resource temporarily
unavailable)
17:01:49 write(4, "\1\0\0\0\0\0\0\0", 8) = 8
17:01:49 read(8, "\2\0\0\0 \0\0\0\200\372\340\257\366U\0\0N\t\0\0r3\17\0
.\2\0\0\0\0\0", 1024) = 32
17:01:49 ioctl(8, DRM_IOCTL_MODE_RMFB, 0x7ffd3e0c682c) = 0
17:01:49 recvmsg(29, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily
unavailable)
17:01:49 poll([{fd=4, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10,
events=POLLIN}, {fd=20, events=POLLIN}, {fd=29, events=POLLIN}, {fd=32,
events=POLLIN}, {fd=34, events=POLLIN}, {fd=48, events=POLLIN}, {fd=50,
events=POLLIN}, {fd=51, events=0}, {fd=53, events=POLLIN}, {fd=59,
events=POLLIN}, {fd=60, events=POLLIN}, {fd=66, events=POLLIN}, {fd=70,
events=POLLIN}, {fd=72, events=POLLIN}, {fd=73, events=POLLIN}], 17, 0) = 1
([{fd=4, revents=POLLIN}])
17:01:49 read(4, "\1\0\0\0\0\0\0\0", 16) = 8
17:01:49 recvmsg(29, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily
unavailable)
17:01:49 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=8,
events=POLLIN}, {fd=10, events=POLLIN}, {fd=20, events=POLLIN}, {fd=29,
events=POLLIN}, {fd=32, events=POLLIN}, {fd=34, events=POLLIN}, {fd=48,
events=POLLIN}, {fd=50, events=POLLIN}, {fd=51, events=0}, {fd=53,
events=POLLIN}, {fd=59, events=POLLIN}, {fd=60, events=POLLIN}, {fd=66,
events=POLLIN}, {fd=70, events=POLLIN}, {fd=72, events=POLLIN}, {fd=73,
events=POLLIN}], 18, 0) = 0 (Timeout)
17:01:49 ioctl(8, DRM_IOCTL_I915_GEM_MADVISE, 0x7ffd3e0c6a70) = 0
17:01:49 ioctl(8, DRM_IOCTL_I915_GEM_BUSY, 0x7ffd3e0c6a20) = 0
17:01:49 ioctl(8, DRM_IOCTL_I915_GEM_MADVISE, 0x7ffd3e0c6a10) = 0
17:01:49 ioctl(8, DRM_IOCTL_I915_GEM_PWRITE, 0x7ffd3e0c6ac0) = 0
17:01:49 ioctl(8, DRM_IOCTL_I915_GEM_BUSY, 0x7ffd3e0c6ab0) = 0
17:01:49 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffd3e0c6a00) = 0
17:01:49 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffd3e0c6b90) = 0
17:01:49 ioctl(8, DRM_IOCTL_MODE_CURSOR, 0x7ffd3e0c6ce0) = 0
17:01:49 write(4, "\1\0\0\0\0\0\0\0", 8) = 8
17:01:49 write(4, "\1\0\0\0\0\0\0\0", 8) = 8
17:01:49 ioctl(8, DRM_IOCTL_I915_GEM_BUSY, 0x7ffd3e0c3f70) = 0
17:01:49 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffd3e0c3ec0) = 0
17:01:49 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffd3e0c4050) = 0
17:01:49 ioctl(8, DRM_IOCTL_I915_GEM_BUSY, 0x7ffd3e0c1e00) = 0
17:01:49 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffd3e0c1d50) = 0
17:01:49 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffd3e0c1ee0) = 0
17:01:49 ioctl(8, DRM_IOCTL_I915_GEM_BUSY, 0x7ffd3e0c1fc0) = 0
17:01:49 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffd3e0c1f10) = 0
17:01:49 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffd3e0c20a0) = 0
17:01:49 ioctl(8, DRM_IOCTL_I915_GEM_BUSY, 0x7ffd3e0c2180) = 0
17:01:49 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffd3e0c20d0) = 0
17:01:49 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffd3e0c2260) = 0
17:01:49 ioctl(8, DRM_IOCTL_I915_GEM_BUSY, 0x7ffd3e0c1e00) = 0
17:01:49 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffd3e0c1d50) = 0
17:01:49 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffd3e0c1ee0) = 0
17:01:49 ioctl(8, DRM_IOCTL_I915_GEM_BUSY, 0x7ffd3e0c1fc0) = 0
17:01:49 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffd3e0c1f10) = 0
17:01:49 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffd3e0c20a0) = 0
17:01:49 ioctl(8, DRM_IOCTL_I915_GEM_BUSY, 0x7ffd3e0c2180) = 0
17:01:49 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 

[PATCH] drm/nouveau: silence warnings reported during builds with W=1

[Ben Skeggs]

On 08/31/2016 06:04 AM, Arnd Bergmann wrote:
> On Tuesday 30 August 2016, Baoyou Xie wrote:
>> We get some warnings when building kernel with W=1:
>> drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf117.c:222:1: warning: no 
>> previous prototype for 'gf117_grctx_generate_main' [-Wmissing-prototypes]
>> drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.c:255:1: warning: no previous 
>> prototype for 'nv50_grctx_fill' [-Wmissing-prototypes]
>> drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.c:265:1: warning: no previous 
>> prototype for 'nv50_grctx_init' [-Wmissing-prototypes]
>> 
>>
>> In fact, some functions are only used in the file in which they
>> are declared and don't need a declaration, but can be made static.
>> and others are declared in the header files, but need to add
>> missing header dependencies.
>>
>> Signed-off-by: Baoyou Xie 
> 
> The patch looks very good, and this is better than one patch per file. I 
> would personally
> do this as two patches, as you are touching a number of files and are doing 
> two separate
> things here. As a rule of thumb, when the changelog text mentions two or more 
> things
> that the patch does, the patch should be split up so that each part does one 
> thing.
> After you do that, it also becomes easier to write a good subject line like 
> "mark
> function as static" and "add missing includes", which tells you more about 
> the patch
> than "silence warnings".
> 
> It's quite likely that the nouveau maintainers are less picky than I am 
> though, so
> if they want to apply the patch as-is
> 
> Acked-by: Arnd Bergmann 
> 
> Otherwise please split and resend in a few days, in case there are other 
> comments
This patch does indeed look a lot better than the previous series.  I
would also prefer the patch to be split into two as suggested by Arnd.

Other than that, I'm very happy to take the patch.  Thank you for your work!

Ben.

> that need to be addressed.
> 
>   Arnd
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160904/4beb8c4e/attachment-0001.sig>

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

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

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

--- Comment #31 from Marek Olšák  ---
(In reply to AmarildoJr from comment #29)
> I just tested the oldest firmware available in the Arch Linux Archive,
> namely linux-firmware 20130725-1, and the crashes don't happen. This is with
> current Arch, not a single package is old and all packages are up-to-date
> according to the repos.
> 
> I'm hitting 10 to 30 FPS in-game, but at least the crashes don't happen
> which IMO is a very good sign of where the problem might be.
> 
> I'll report the firmware problem to AMD.
> 
> In the mean time, does anyone know how I can try running the firmware from
> Catalyst?
> 
> @Marek, where is the best place to report this?

So are we certain the hangs are caused by firmware? Bisecting the firmware
would help a lot.

What's your GPU?

-- 
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/20160904/9caa4b13/attachment.html>

[radeon-alex:drm-next-4.9-wip 210/239] (.text+0x6bc00): multiple definition of `si_get_mclk_frequency_ratio'

[kbuild test robot]

echnology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 55182 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160904/9374967a/attachment-0001.obj>

[Bug 60533] CVE-2013-7445: Remote web page triggerable DOS in Linux DRM graphics.

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

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

--- Comment #40 from Mikhail  ---
kernel 4.8.0-0.rc4 and interface still freeze when free memory is absent:

stracing of gnome-shell:

# strace -t -p 1489
strace: Process 1489 attached
19:36:11 ioctl(8, DRM_IOCTL_I915_GEM_CREATE, 0x7ffc860b7690) = 0
19:36:11 ioctl(8, DRM_IOCTL_I915_GEM_BUSY, 0x7ffc860b7770) = 0
19:36:11 ioctl(8, DRM_IOCTL_I915_GEM_MMAP, 0x7ffc860b76c0) = 0
19:36:11 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffc860b76c0) = 0
19:36:12 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffc860b7840) = 0
19:36:12 ioctl(8, DRM_IOCTL_I915_GEM_BUSY, 0x7ffc860bd1d0) = 0
19:36:12 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffc860bd120) = 0
19:36:12 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffc860bd2b0) = 0
19:36:12 ioctl(8, DRM_IOCTL_I915_GEM_MADVISE, 0x7ffc860ba8d0) = 0
19:36:12 munmap(0x7f2403fa5000, 4096)   = 0
19:36:12 ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffc860ba8c0) = 0
19:36:12 ioctl(8, DRM_IOCTL_I915_GEM_CREATE, 0x7ffc860ba820) = 0
19:36:12 ioctl(8, DRM_IOCTL_I915_GEM_BUSY, 0x7ffc860ba900) = 0
19:36:12 ioctl(8, DRM_IOCTL_I915_GEM_MMAP, 0x7ffc860ba850) = 0
19:36:12 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffc860ba850) = 0
19:36:12 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffc860ba9d0) = 0
19:36:12 ioctl(8, DRM_IOCTL_MODE_CURSOR, 0x7ffc860bd400) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_BUSY, 0x7ffc860ba9f0) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffc860ba940) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffc860baad0) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_BUSY, 0x7ffc860ba9f0) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffc860ba940) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffc860baad0) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_BUSY, 0x7ffc860ba9f0) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffc860ba940) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffc860baad0) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_BUSY, 0x7ffc860ba9f0) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffc860ba940) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffc860baad0) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_BUSY, 0x7ffc860ba9f0) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffc860ba940) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffc860baad0) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_BUSY, 0x7ffc860ba9f0) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffc860ba940) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffc860baad0) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_BUSY, 0x7ffc860ba9f0) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffc860ba940) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffc860baad0) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_CREATE, 0x7ffc860ba970) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_MMAP, 0x7ffc860ba940) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffc860ba940) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffc860baad0) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_CREATE, 0x7ffc860ba970) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_MMAP, 0x7ffc860ba940) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffc860ba940) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffc860baad0) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_CREATE, 0x7ffc860ba970) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_MMAP, 0x7ffc860ba940) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffc860ba940) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffc860baad0) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_CREATE, 0x7ffc860ba970) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_MMAP, 0x7ffc860ba940) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffc860ba940) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffc860baad0) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_CREATE, 0x7ffc860ba970) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_MMAP, 0x7ffc860ba940) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffc860ba940) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffc860baad0) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_CREATE, 0x7ffc860ba970) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_MMAP, 0x7ffc860ba940) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffc860ba940) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffc860baad0) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_CREATE, 0x7ffc860ba970) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_MMAP, 0x7ffc860ba940) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffc860ba940) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffc860baad0) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_CREATE, 0x7ffc860ba970) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_MMAP, 0x7ffc860ba940) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7ffc860ba940) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffc860baad0) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7ffc860ba740) = 0
19:36:52 ioctl(8, DRM_IOCTL_I915_GEM_EXECBUFFER2, 0x7ffc860ba6d0) = 0
19:36:52 ioctl(8, 

[Bug 97590] Fury X (Fiji) LEDs do not reflect GPU load

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

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

Bug ID: 97590
   Summary: Fury X (Fiji) LEDs do not reflect GPU load
   Product: Mesa
   Version: git
  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: boltronics at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

Under Catalyst (fglrx) on Ubuntu 14.04, LEDs on Fury X graphics cards would
reflect the GPU load. This behaviour matches Windows. ie. Stand-by mode would
utilize a single green LED, low power would use one red LED, max power would
light up all 8 LEDs, etc. You can see this behaviour here:
https://www.youtube.com/watch?v=Evkk4HmjHOw

This helps give a nice immediate visual feedback showing what the cards are
actually doing, and can improve PC build aesthetics.

Since upgrading to AMDGPU + Mesa, all LEDs are permanently on, implying full
load (or maximum power draw?) at all times. Hopefully this is not what is
actually happening.

FWIW, the AMDGPU Pro stack also has this issue.

-- 
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/20160904/f9f9d4c6/attachment.html>

[PATCH] drm/imx: Fix of_node ref counting

[Christophe JAILLET]

This code is spurious.
It takes a ref on a node, then call 'of_node_put' on it and then store
this node somewhere.

It is likely that taking the ref on the parent node and releasing the child
node was expected instead.

So, use 'of_get_next_parent' instead. It does all this in just one
function call.

Signed-off-by: Christophe JAILLET 
---
Un-tested
---
 drivers/gpu/drm/imx/imx-drm-core.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index 438bac8fbc2b..60fb388c80f8 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -449,10 +449,8 @@ static int compare_of(struct device *dev, void *data)
}

/* Special case for LDB, one device for two channels */
-   if (of_node_cmp(np->name, "lvds-channel") == 0) {
-   np = of_get_parent(np);
-   of_node_put(np);
-   }
+   if (of_node_cmp(np->name, "lvds-channel") == 0)
+   np = of_get_next_parent(np);

return dev->of_node == np;
 }
-- 
2.7.4

[Bug 97123] [AMDGPU][CIK] Suspend to disk deadlocks system on resume always (Linus master + drm-next-4.9-wip)

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

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

--- Comment #4 from Shawn Starr  ---
Still had a lockup during a freeze() --> Reboot cycle

Will try patch:
[PATCH v2] drm/amd/amdgpu: S4 issue for amdgpu

-- 
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/20160904/f62cd049/attachment.html>

[Bug 80419] XCOM: Enemy Unknown Causes lockup

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

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

--- Comment #144 from AmarildoJr  ---
BTW, Team Fortress 2 also has hangups, and I was able to play it for +40
minutes without issues with "radeon.dpm=0".

-- 
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/20160904/c19388f3/attachment.html>

[Bug 80419] XCOM: Enemy Unknown Causes lockup

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

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

AmarildoJr  changed:

   What|Removed |Added

 CC||amarildosjr at riseup.net

--- Comment #143 from AmarildoJr  ---
(In reply to Alassane Maiga from comment #141)
> Well I can reliably make it stop locking the system completely now. I switch
> to console with ctrl+alt+f2 as soon as the game locks up and then back as
> soon as the ring stall messages start to fill up the screen. When I am back
> the game is not frozen anymore, but extremely slow. In fact all opengl
> related rendering becomes slow. And I get this message each time I switch to
> console :
> "GPU fault detected 146 0x0904xxxc
> VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00029E48
> VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x040C"
> 
> How should I give more information?
> 
> If I restart the performance comes back to normal

I think is a similar effect of when DPM is disabled (with 'radeon.dpm=0'). I'm
interested to know if DPM has a finger on this issue or not.

Here's a "git diff" between si_dpm.c from kernel 3.16 and 4.7.2:
http://pastebin.com/raw/UzZFfYgp

Perhaps there are some hints in there.

-- 
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/20160904/13194bbb/attachment.html>