[Bug 89944] GPU crash in Civilization 5

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

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

--- Comment #9 from Sami Liedes  ---
Tested; cannot reproduce problem with latest mesa (28d9e904) and llvm
(r234939).

-- 
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/20150414/2c899c5c/attachment.html>

[Bug 89980] [Regression] Graphical corruption after resuming from suspend (w/ dual monitor configuration)

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

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

--- Comment #5 from falaca at gmail.com ---
Created attachment 115071
  --> https://bugs.freedesktop.org/attachment.cgi?id=115071=edit
Mesa bisect 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/20150414/a44ef3a1/attachment.html>

[Bug 89980] [Regression] Graphical corruption after resuming from suspend (w/ dual monitor configuration)

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

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

--- Comment #4 from falaca at gmail.com ---
I have found the bad commit. I will attach my bisect log.

I bisected between 10.1-branchpoint and 10.2-branchpoint, and here's the final
result:

4a5519f1e019dbf1103e4f3abe0a695637a87518 is the first bad commit
commit 4a5519f1e019dbf1103e4f3abe0a695637a87518
Author: Marek Olšák 
Date:   Mon Feb 10 01:25:54 2014 +0100

r600g,radeonsi: set correct initial domain for shared resources

:04 04 eafa3cdc6eea908c6ba8861f3d063f6a3161217b
7938f0ed0cdf8c677af35f1b2e67739dc210bda8 Msrc

-- 
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/20150414/7a5c8c69/attachment.html>

[PATCH 1/2] drm: Shortcircuit vblank queries

[Mario Kleiner]

On 04/14/2015 08:36 PM, Chris Wilson wrote:
> On Tue, Apr 14, 2015 at 08:22:20PM +0200, Mario Kleiner wrote:
>> On 04/05/2015 05:40 PM, Chris Wilson wrote:
>>> Avoid adding to the waitqueue and reprobing the current vblank if the
>>> caller is only querying the current vblank sequence and timestamp and
>>> so we would return immediately.
>>>
>>> Signed-off-by: Chris Wilson 
>>> Cc: Ville Syrjälä 
>>> Cc: Daniel Vetter 
>>> Cc: Michel Dänzer 
>>> Cc: Laurent Pinchart 
>>> Cc: Dave Airlie ,
>>> Cc: Mario Kleiner 
>>> ---
>>>   drivers/gpu/drm/drm_irq.c | 18 ++
>>>   1 file changed, 10 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
>>> index 6f5dc18779e2..ba80b51b4b00 100644
>>> --- a/drivers/gpu/drm/drm_irq.c
>>> +++ b/drivers/gpu/drm/drm_irq.c
>>> @@ -1617,14 +1617,16 @@ int drm_wait_vblank(struct drm_device *dev, void 
>>> *data,
>>> vblwait->request.sequence = seq + 1;
>>> }
>>>
>>> -   DRM_DEBUG("waiting on vblank count %d, crtc %d\n",
>>> - vblwait->request.sequence, crtc);
>>> -   vblank->last_wait = vblwait->request.sequence;
>>> -   DRM_WAIT_ON(ret, vblank->queue, 3 * HZ,
>>> -   (((drm_vblank_count(dev, crtc) -
>>> -  vblwait->request.sequence) <= (1 << 23)) ||
>>> -!vblank->enabled ||
>>> -!dev->irq_enabled));
>>> +   if (vblwait->request.sequence != seq) {
>>> +   DRM_DEBUG("waiting on vblank count %d, crtc %d\n",
>>> + vblwait->request.sequence, crtc);
>>> +   vblank->last_wait = vblwait->request.sequence;
>>> +   DRM_WAIT_ON(ret, vblank->queue, 3 * HZ,
>>> +   (((drm_vblank_count(dev, crtc) -
>>> +  vblwait->request.sequence) <= (1 << 23)) ||
>>> +!vblank->enabled ||
>>> +!dev->irq_enabled));
>>> +   }
>>>
>>> if (ret != -EINTR) {
>>> struct timeval now;
>>>
>>
>> It would be good to have some DRM_DEBUG output for the skip-the-wait
>> case as well, so one can still follow from dmesg output when a
>> client does a drmWaitVblank call even if it is only a query.
>
> We still have DRM_DEBUG("returning %d to client"), as well as the
> drmIoctl:DRM_DEBUG(ioctl->name), is that not sufficient?
> -Chris
>

Oh right, that's good enough. Maybe add "on crtc %d" to that DRM_DEBUG, 
to make it unambiguous for which crtc some count is returned?

-mario

[PATCH 2/2] drm: Shortcircuit vblank queries

[Mario Kleiner]

On 04/05/2015 05:40 PM, Chris Wilson wrote:
> Bypass all the spinlocks and return the last timestamp and counter from
> the last vblank if the driver delcares that it is accurate (and stable
> across on/off), and the vblank is currently enabled.
>
> Signed-off-by: Chris Wilson 
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Cc: Michel Dänzer 
> Cc: Laurent Pinchart 
> Cc: Dave Airlie ,
> Cc: Mario Kleiner 
> ---
>   drivers/gpu/drm/drm_irq.c | 26 ++
>   1 file changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index ba80b51b4b00..be9c210bb22e 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1538,6 +1538,17 @@ err_put:
>   return ret;
>   }
>
> +static bool drm_wait_vblank_is_query(union drm_wait_vblank *vblwait)
> +{
> + if (vblwait->request.sequence)
> + return false;
> +
> + return _DRM_VBLANK_RELATIVE ==
> + (vblwait->request.type & (_DRM_VBLANK_TYPES_MASK |
> +   _DRM_VBLANK_EVENT |
> +   _DRM_VBLANK_NEXTONMISS));
> +}
> +
>   /*
>* Wait for VBLANK.
>*
> @@ -1587,6 +1598,21 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
>
>   vblank = >vblank[crtc];
>
> + /* If the counter is currently enabled and accurate, short-circuit 
> queries
> +  * to return the cached timestamp of the last vblank.
> +  */

Maybe somehow stress in the comment that this location in 
drm_wait_vblank is really the only place where it is ok'ish to call
drm_vblank_count_and_time() without wrapping it into a 
drm_vblank_get/put(), so nobody thinks this approach is ok anywhere else.

> + if (dev->vblank_disable_immediate &&
> + drm_wait_vblank_is_query(vblwait) &&
> + vblank->enabled) {

You should also check for (drm_vblank_offdelay != 0) whenever checking 
for dev->vblank_disable_immediate. This is so one can override all the
vblank_disable_immediate related logic via the drm vblankoffdelay module 
parameter, both for debugging and as a safety switch for desparate users 
in case some driver+gpu combo screws up wrt. immediate disable and that 
makes it into distro kernels.

The other thing i'm not sure is if it wouldn't be a good idea to have 
some kind of write memory barrier in vblank_disable_and_save() after 
setting vblank->enabled = false; and some read memory barrier here 
before your check for vblank->enabled? I don't have a feeling for how 
much time can pass between one core executing the disable and the other 
core receiving the news that vblank->enabled is no longer true if those 
bits run on different cores?

I've run your patches through my standard tests on x86_64 and they don't 
seem to introduce errors or more skipped frames. Normally it would be so 
wrong to do this without drm_vblank_get/put(), but i think here 
potential errors introduced wouldn't be worse than what a userspace 
client would see due to preemption or other execution delays at the 
wrong moment, so it's probably ok. But i don't know if lack of memory 
barriers etc. could introduce large delays and trouble on other 
architectures?

> + struct timeval now;
> +
> + vblwait->reply.sequence =
> + drm_vblank_count_and_time(dev, crtc, );
> + vblwait->reply.tval_sec = now.tv_sec;
> + vblwait->reply.tval_usec = now.tv_usec;

Have some DRM_DEBUG here, so one can follow the client doing the instant 
query through this path.

> + return 0;
> + }
> +
>   ret = drm_vblank_get(dev, crtc);
>   if (ret) {
>   DRM_DEBUG("failed to acquire vblank counter, %d\n", ret);
>

With the above addressed i'd give you a Reviewed-and-tested-by, but it 
would be good if somebody else could look over it as well.

-mario

[Bug 83274] XCom Enemy Unknown segfault at src/gallium/drivers/radeon/r600_texture.c:602

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

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

--- Comment #3 from nicolas  ---
hie,
i have the same bug since the release of the game with RV770.
Can you explain me what parameters i have to use with valgrind  ( i have
installed it) so that it can makes a useful output for you?

I'm sorry for the comment before, that's a bad manip.
Also sorry for bad english

-- 
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/20150414/0265634a/attachment.html>

[Bug 83274] XCom Enemy Unknown segfault at src/gallium/drivers/radeon/r600_texture.c:602

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

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

--- Comment #2 from nicolas  ---
(In reply to Michel Dänzer from comment #1)
> Looks like memory corruption. If it's not bug 80673 (which is supposed to be
> fixed in the latest game update), can you attach the output from running the
> game in valgrind?


Hie,
i h

-- 
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/20150414/2937bd2f/attachment.html>

[PATCH 1/2] drm: Shortcircuit vblank queries

[Mario Kleiner]

On 04/05/2015 05:40 PM, Chris Wilson wrote:
> Avoid adding to the waitqueue and reprobing the current vblank if the
> caller is only querying the current vblank sequence and timestamp and
> so we would return immediately.
>
> Signed-off-by: Chris Wilson 
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Cc: Michel Dänzer 
> Cc: Laurent Pinchart 
> Cc: Dave Airlie ,
> Cc: Mario Kleiner 
> ---
>   drivers/gpu/drm/drm_irq.c | 18 ++
>   1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 6f5dc18779e2..ba80b51b4b00 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1617,14 +1617,16 @@ int drm_wait_vblank(struct drm_device *dev, void 
> *data,
>   vblwait->request.sequence = seq + 1;
>   }
>
> - DRM_DEBUG("waiting on vblank count %d, crtc %d\n",
> -   vblwait->request.sequence, crtc);
> - vblank->last_wait = vblwait->request.sequence;
> - DRM_WAIT_ON(ret, vblank->queue, 3 * HZ,
> - (((drm_vblank_count(dev, crtc) -
> -vblwait->request.sequence) <= (1 << 23)) ||
> -  !vblank->enabled ||
> -  !dev->irq_enabled));
> + if (vblwait->request.sequence != seq) {
> + DRM_DEBUG("waiting on vblank count %d, crtc %d\n",
> +   vblwait->request.sequence, crtc);
> + vblank->last_wait = vblwait->request.sequence;
> + DRM_WAIT_ON(ret, vblank->queue, 3 * HZ,
> + (((drm_vblank_count(dev, crtc) -
> +vblwait->request.sequence) <= (1 << 23)) ||
> +  !vblank->enabled ||
> +  !dev->irq_enabled));
> + }
>
>   if (ret != -EINTR) {
>   struct timeval now;
>

It would be good to have some DRM_DEBUG output for the skip-the-wait 
case as well, so one can still follow from dmesg output when a client 
does a drmWaitVblank call even if it is only a query.

Other than that, this one [1/2] is

Reviewed-and-tested-by: Mario Kleiner 

-mario

[PATCH 1/2] drm: Shortcircuit vblank queries

[Mario Kleiner]

On 04/14/2015 04:21 PM, Chris Wilson wrote:
> On Tue, Apr 14, 2015 at 06:42:03PM +0900, Michel Dänzer wrote:
>> Also, the two patches should have different and more specific shortlogs.
>
> Second patch:
>
> drm: Query vblank counters directly for known accurate state
>
> ?
>

When i applied your patches, both patches showed a shortlog of
"drm: Shortcircuit vblank queries", i think that's what Michel means.

-mario

[PATCH 3/3] drm/tegra: Don't use vblank_disable_immediate on incapable driver.

[Mario Kleiner]

Tegra would not only need a hardware vblank counter that
increments at leading edge of vblank, but also support
for instantaneous high precision vblank timestamp queries, ie.
a proper implementation of dev->driver->get_vblank_timestamp().

Without these, there can be off-by-one errors during vblank
disable/enable if the scanout is inside vblank at en/disable
time, and additionally clients will never see any useable
vblank timestamps when querying via drmWaitVblank ioctl. This
would negatively affect swap scheduling under X11 and Wayland.

Signed-off-by: Mario Kleiner 
Cc: Thierry Reding 
Cc: Dave Airlie 
---
 drivers/gpu/drm/tegra/drm.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 1833abd..bfad15a 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -173,7 +173,6 @@ static int tegra_drm_load(struct drm_device *drm, unsigned 
long flags)
drm->irq_enabled = true;

/* syncpoints are used for full 32-bit hardware VBLANK counters */
-   drm->vblank_disable_immediate = true;
drm->max_vblank_count = 0x;

err = drm_vblank_init(drm, drm->mode_config.num_crtc);
-- 
1.9.1

[PATCH 2/3] drm: Prevent invalid use of vblank_disable_immediate.

[Mario Kleiner]

For a kms driver to support immediate disable of vblank
irq's reliably without introducing off by one errors or
other mayhem for clients, it must not only support a
hardware vblank counter query, but also high precision
vblank timestamping, so vblank count and timestamp can be
instantaneously reinitialzed to valid values. Additionally
the exposed hardware counter must behave as if it is
incrementing at leading edge of vblank to avoid off by
one errors during reinitialization of the counter while
the display happens to be inside or close to vblank.

Check during drm_vblank_init that a driver which claims to
be capable of vblank_disable_immediate at least supports
high precision timestamping and prevent use of instant
disable if that isn't present as a minimum requirement.

Signed-off-by: Mario Kleiner 
Cc: Ville Syrjälä 
Cc: Michel Dänzer 
Cc: Thierry Reding 
Cc: Dave Airlie 
---
 drivers/gpu/drm/drm_irq.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index af9662e..6efe822 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -336,6 +336,12 @@ int drm_vblank_init(struct drm_device *dev, int num_crtcs)
else
DRM_INFO("No driver support for vblank timestamp query.\n");

+   /* Must have precise timestamping for reliable vblank instant disable */
+   if (dev->vblank_disable_immediate && 
!dev->driver->get_vblank_timestamp) {
+   dev->vblank_disable_immediate = false;
+   DRM_ERROR("Set vblank_disable_immediate, but not supported.\n");
+   }
+
dev->vblank_disable_allowed = false;

return 0;
-- 
1.9.1

[PATCH 1/3] drm: Zero out invalid vblank timestamp in drm_update_vblank_count.

[Mario Kleiner]

Since commit 844b03f27739135fe1fed2fef06da0ffc4c7a081 we make
sure that after vblank irq off, we return the last valid
(vblank count, vblank timestamp) pair to clients, e.g., during
modesets, which is good.

An overlooked side effect of that commit for kms drivers without
support for precise vblank timestamping is that at vblank irq
enable, when we update the vblank counter from the hw counter, we
can't update the corresponding vblank timestamp, so now we have a
totally mismatched timestamp for the new count to confuse clients.

Restore old client visible behaviour from before Linux 3.17, but
zero out the timestamp at vblank counter update (instead of disable
as in original implementation) if we can't generate a meaningful
timestamp immediately for the new vblank counter. This will fix
this regression, so callers know they need to retry again later
if they need a valid timestamp, but at the same time preserves
the improvements made in the commit mentioned above.

Signed-off-by: Mario Kleiner 
Cc:  #v3.17+

Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Dave Airlie 
---
 drivers/gpu/drm/drm_irq.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index c8a3447..af9662e 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -131,12 +131,11 @@ static void drm_update_vblank_count(struct drm_device 
*dev, int crtc)

/* Reinitialize corresponding vblank timestamp if high-precision query
 * available. Skip this step if query unsupported or failed. Will
-* reinitialize delayed at next vblank interrupt in that case.
+* reinitialize delayed at next vblank interrupt in that case and
+* assign 0 for now, to mark the vblanktimestamp as invalid.
 */
-   if (rc) {
-   tslot = atomic_read(>count) + diff;
-   vblanktimestamp(dev, crtc, tslot) = t_vblank;
-   }
+   tslot = atomic_read(>count) + diff;
+   vblanktimestamp(dev, crtc, tslot) = rc ? t_vblank : (struct timeval) 
{0, 0};

smp_mb__before_atomic();
atomic_add(diff, >count);
-- 
1.9.1

[PATCH 1/2] drm: Shortcircuit vblank queries

[Chris Wilson]

On Tue, Apr 14, 2015 at 08:22:20PM +0200, Mario Kleiner wrote:
> On 04/05/2015 05:40 PM, Chris Wilson wrote:
> >Avoid adding to the waitqueue and reprobing the current vblank if the
> >caller is only querying the current vblank sequence and timestamp and
> >so we would return immediately.
> >
> >Signed-off-by: Chris Wilson 
> >Cc: Ville Syrjälä 
> >Cc: Daniel Vetter 
> >Cc: Michel Dänzer 
> >Cc: Laurent Pinchart 
> >Cc: Dave Airlie ,
> >Cc: Mario Kleiner 
> >---
> >  drivers/gpu/drm/drm_irq.c | 18 ++
> >  1 file changed, 10 insertions(+), 8 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> >index 6f5dc18779e2..ba80b51b4b00 100644
> >--- a/drivers/gpu/drm/drm_irq.c
> >+++ b/drivers/gpu/drm/drm_irq.c
> >@@ -1617,14 +1617,16 @@ int drm_wait_vblank(struct drm_device *dev, void 
> >*data,
> > vblwait->request.sequence = seq + 1;
> > }
> >
> >-DRM_DEBUG("waiting on vblank count %d, crtc %d\n",
> >-  vblwait->request.sequence, crtc);
> >-vblank->last_wait = vblwait->request.sequence;
> >-DRM_WAIT_ON(ret, vblank->queue, 3 * HZ,
> >-(((drm_vblank_count(dev, crtc) -
> >-   vblwait->request.sequence) <= (1 << 23)) ||
> >- !vblank->enabled ||
> >- !dev->irq_enabled));
> >+if (vblwait->request.sequence != seq) {
> >+DRM_DEBUG("waiting on vblank count %d, crtc %d\n",
> >+  vblwait->request.sequence, crtc);
> >+vblank->last_wait = vblwait->request.sequence;
> >+DRM_WAIT_ON(ret, vblank->queue, 3 * HZ,
> >+(((drm_vblank_count(dev, crtc) -
> >+   vblwait->request.sequence) <= (1 << 23)) ||
> >+ !vblank->enabled ||
> >+ !dev->irq_enabled));
> >+}
> >
> > if (ret != -EINTR) {
> > struct timeval now;
> >
> 
> It would be good to have some DRM_DEBUG output for the skip-the-wait
> case as well, so one can still follow from dmesg output when a
> client does a drmWaitVblank call even if it is only a query.

We still have DRM_DEBUG("returning %d to client"), as well as the
drmIoctl:DRM_DEBUG(ioctl->name), is that not sufficient?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 1/2] drm: Shortcircuit vblank queries

[Chris Wilson]

On Tue, Apr 14, 2015 at 08:17:21PM +0200, Mario Kleiner wrote:
> On 04/14/2015 04:21 PM, Chris Wilson wrote:
> >On Tue, Apr 14, 2015 at 06:42:03PM +0900, Michel Dänzer wrote:
> >>Also, the two patches should have different and more specific shortlogs.
> >
> >Second patch:
> >
> >drm: Query vblank counters directly for known accurate state
> >
> >?
> >
> 
> When i applied your patches, both patches showed a shortlog of
> "drm: Shortcircuit vblank queries", i think that's what Michel means.

I was making a suggestion for retitling. :)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 1/2] drm: Shortcircuit vblank queries

[Michel Dänzer]

On 06.04.2015 00:40, Chris Wilson wrote:
> Avoid adding to the waitqueue and reprobing the current vblank if the
> caller is only querying the current vblank sequence and timestamp and
> so we would return immediately.
> 
> Signed-off-by: Chris Wilson 
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Cc: Michel Dänzer 
> Cc: Laurent Pinchart 
> Cc: Dave Airlie ,
> Cc: Mario Kleiner 
> ---
>  drivers/gpu/drm/drm_irq.c | 18 ++
>  1 file changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 6f5dc18779e2..ba80b51b4b00 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1617,14 +1617,16 @@ int drm_wait_vblank(struct drm_device *dev, void 
> *data,
>   vblwait->request.sequence = seq + 1;
>   }
>  
> - DRM_DEBUG("waiting on vblank count %d, crtc %d\n",
> -   vblwait->request.sequence, crtc);
> - vblank->last_wait = vblwait->request.sequence;
> - DRM_WAIT_ON(ret, vblank->queue, 3 * HZ,
> - (((drm_vblank_count(dev, crtc) -
> -vblwait->request.sequence) <= (1 << 23)) ||
> -  !vblank->enabled ||
> -  !dev->irq_enabled));
> + if (vblwait->request.sequence != seq) {
> + DRM_DEBUG("waiting on vblank count %d, crtc %d\n",
> +   vblwait->request.sequence, crtc);
> + vblank->last_wait = vblwait->request.sequence;

BTW, it looks like the last_wait field is unused  and could be removed.


> + DRM_WAIT_ON(ret, vblank->queue, 3 * HZ,
> + (((drm_vblank_count(dev, crtc) -
> +vblwait->request.sequence) <= (1 << 23)) ||
> +  !vblank->enabled ||
> +  !dev->irq_enabled));
> + }
>  
>   if (ret != -EINTR) {
>   struct timeval now;
> 

Also, the two patches should have different and more specific shortlogs.


But apart from that, this patch is

Reviewed-by: Michel Dänzer 

and the second patch is

Acked-by: Michel Dänzer 


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

[PATCH] drm: fix trivial typo mistake

[John Hunter]

Signed-off-by: John Hunter 
---
 include/drm/drm_crtc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 2e80ad1..8ad8507 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -974,7 +974,7 @@ struct drm_mode_set {
  * struct drm_mode_config_funcs - basic driver provided mode setting functions
  * @fb_create: create a new framebuffer object
  * @output_poll_changed: function to handle output configuration changes
- * @atomic_check: check whether a give atomic state update is possible
+ * @atomic_check: check whether a given atomic state update is possible
  * @atomic_commit: commit an atomic state update previously verified with
  * atomic_check()
  *
-- 
1.9.1

[PATCH] trivial: Remove unused variable `tmp' from `radeon_combios_get_lvds_info()'

[Michael Witten]

> Signed-off-by: Michael Witten 
> ---
>  drivers/gpu/drm/radeon/radeon_combios.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
> b/drivers/gpu/drm/radeon/radeon_combios.c
> index 0b3c1e0..7962091 100644
> --- a/drivers/gpu/drm/radeon/radeon_combios.c
> +++ b/drivers/gpu/drm/radeon/radeon_combios.c
> @@ -1175,7 +1175,7 @@ struct radeon_encoder_lvds 
> *radeon_combios_get_lvds_info(struct radeon_encoder
>   uint16_t lcd_info;
>   uint32_t panel_setup;
>   char stmp[30];
> - int tmp, i;
> + int i;
>   struct radeon_encoder_lvds *lvds = NULL;
>
>   lcd_info = combios_get_table_offset(dev, COMBIOS_LCD_INFO_TABLE);
> -- 
> 1.7.11.2.252.gc4a64c8

PLEASE IGNORE THIS!

I made the same mistake that I did 3.5 years ago; the variable `tmp' is NOT 
unused:

http://article.gmane.org/gmane.comp.video.dri.devel/60785

Sorry for the irritation.

Sincerely,
Michael Witten

[Bug 89971] HDMI out *not* working with radeon (mobile 8550g)

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

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

--- Comment #7 from Adrian Gabor  ---
Nope, still the same.

-- 
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/20150414/3997ab04/attachment-0001.html>

[Bug 89971] HDMI out *not* working with radeon (mobile 8550g)

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

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

--- Comment #6 from Adrian Gabor  ---
Nope, still the same.

-- 
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/20150414/4d3c2acc/attachment.html>

[PATCH 1/2] drm: Shortcircuit vblank queries

[Chris Wilson]

On Tue, Apr 14, 2015 at 06:42:03PM +0900, Michel Dänzer wrote:
> Also, the two patches should have different and more specific shortlogs.

Second patch:

drm: Query vblank counters directly for known accurate state

?

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] drm/panel: Add display timing for HannStar HSD100PXN1

[Thierry Reding]

On Mon, Apr 13, 2015 at 03:09:26PM -0700, Eric Nelson wrote:
> Add support for the Hannstar HSD100PXN1 to the DRM simple panel driver.
> 
> The HSD100PXN1 is an XGA (1024x768) panel with an 18-bit LVDS interface.
> It supports pixel clocks in the range of 55-75 MHz.
> 
> This panel is offered for sale by Freescale as a companion part to its'
> i.MX5x Quick Start board and i.MX6 SABRE platforms with under the name
> MCIMX-LVDS1.
> 
> Signed-off-by: Eric Nelson 
> ---
>  .../bindings/panel/hannstar,hsd100pxn1.txt |  7 ++
>  drivers/gpu/drm/panel/panel-simple.c   | 26 
> ++
>  2 files changed, 33 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/panel/hannstar,hsd100pxn1.txt

Applied for v4.2, thanks.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150414/17e42e19/attachment.sig>

[Bug 89944] GPU crash in Civilization 5

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

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

--- Comment #8 from Tom Stellard  ---
Can you pull the latest version of llvm and mesa and see if the problem still
exists?

-- 
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/20150414/e1b98fc3/attachment.html>

[Bug 89909] [radeonsi][bisected] Cities: Skylines black rooftops

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

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

--- Comment #3 from Tom Stellard  ---
Can you run the program with the environment variables:

MESA_GLSL=dump PIGLIT_PLATFORM=gbm R600_DEBUG=ps,vs,gs


And post the output.

-- 
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/20150414/5b9ab64f/attachment.html>

[PATCH] trivial: Remove unused variable `tmp' from `radeon_combios_get_lvds_info()'

[Michael Witten]

Signed-off-by: Michael Witten 
---
 drivers/gpu/drm/radeon/radeon_combios.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_combios.c 
b/drivers/gpu/drm/radeon/radeon_combios.c
index 0b3c1e0..7962091 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -1175,7 +1175,7 @@ struct radeon_encoder_lvds 
*radeon_combios_get_lvds_info(struct radeon_encoder
uint16_t lcd_info;
uint32_t panel_setup;
char stmp[30];
-   int tmp, i;
+   int i;
struct radeon_encoder_lvds *lvds = NULL;

lcd_info = combios_get_table_offset(dev, COMBIOS_LCD_INFO_TABLE);
-- 
1.7.11.2.252.gc4a64c8

[Bug 89971] HDMI out *not* working with radeon (mobile 8550g)

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

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

--- Comment #5 from Alex Deucher  ---
Does booting with radeon.audio=0 on the kernel command line in grub 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/20150414/d4e53ba2/attachment.html>

[Bug 89916] DRI PRIME renders only black window

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

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

--- Comment #3 from towo at siduction.org ---
At the moment i use radeon ddx from git (older snapshot) with dri3.
Most apps work, but for example

DRI_PRIME=1 kodi

let freeze the whole xserver and let a zombie process left for /usr/bin/X.

Working over ssh still working. But reboot or halt is not possible, only hard
switch off.

I will try to use a new git snapshot and will tell, what's going on with it.

-- 
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/20150414/0e2a529f/attachment.html>

[PATCH] drm: fix trivial typo mistake

[Daniel Vetter]

On Tue, Apr 14, 2015 at 05:07:22PM +0800, John Hunter wrote:
> Signed-off-by: John Hunter 

Merged to topic/drm-misc, thanks.
-Daniel

> ---
>  include/drm/drm_crtc.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 2e80ad1..8ad8507 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -974,7 +974,7 @@ struct drm_mode_set {
>   * struct drm_mode_config_funcs - basic driver provided mode setting 
> functions
>   * @fb_create: create a new framebuffer object
>   * @output_poll_changed: function to handle output configuration changes
> - * @atomic_check: check whether a give atomic state update is possible
> + * @atomic_check: check whether a given atomic state update is possible
>   * @atomic_commit: commit an atomic state update previously verified with
>   *   atomic_check()
>   *
> -- 
> 1.9.1
> 
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Bug 89916] DRI PRIME renders only black window

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

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

--- Comment #2 from Adrian Gabor  ---
Radeon dual graphics doesn't work with DRI2 regardless of compositor.

Please try DRI3. I have an HAINAN dGPU as well and it works flawless with 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/20150414/a5ed8fa0/attachment.html>

[RFC/PATCH v2 0/5] Add live source objects to DRM

[Daniel Vetter]

On Mon, Apr 13, 2015 at 09:39:42PM +0300, Laurent Pinchart wrote:
> Hello,
> 
> Here's a proposal for a different approach to live source in DRM based on an
> idea by Daniel Vetter. The previous version can be found at
> http://lists.freedesktop.org/archives/dri-devel/2015-March/079319.html.

msm is also interested in a drm/v4l bridge on the capture/writeback side.
Although I haven't convinced them yet that rolling their own isn't
awesome.

> The need comes from the Renesas R-Car SoCs in which a video processing engine
> (named VSP1) that operates from memory to memory has one output directly
> connected to a plane of the display engine (DU) without going through memory.
> 
> The VSP1 is supported by a V4L2 driver. While it could be argued that it
> should instead be supported directly by the DRM rcar-du driver, this wouldn't
> be a good idea for at least two reasons. First, the R-Car SoCs contain several
> VSP1 instances, of which only a subset have a direct DU connection. The only
> other instances operate solely in memory to memory mode. Then, the VSP1 is a
> video processing engine and not a display engine. Its features are easily
> supported by the V4L2 API, but don't map to the DRM/KMS API. Significant
> changes to DRM/KMS would be required, beyond what is in my opinion an
> acceptable scope for a display API.
> 
> Now that the need to interface two separate devices supported by two different
> drivers in two separate subsystems has been established, we need an API to do
> so. It should be noted that while that API doesn't exist in the mainline
> kernel, the need isn't limited to Renesas SoCs.
> 
> This patch set proposes one possible solution for the problem in the form of a
> new DRM object named live source. Live sources are created by drivers to model
> hardware connections between a plane input and an external source, and are
> attached to planes through the KMS userspace API.
> 
> Patch 1/5 adds live source objects to DRM, with an in-kernel API for drivers
> to register the sources, and a userspace API to enumerate them.
> 
> Patch 2/5 implements connection between live sources and planes through
> framebuffers. It introduces a new live source flag for framebuffers. When a
> framebuffer is created with that flag set, a live source is associated with
> the framebuffer instead of buffer objects. The framebuffer can then be used
> with a plane to connect it with the live source. This is the biggest
> difference compared to the previous approach, and has several benefits:
> 
> - Changes are less intrusive in the DRM core
> - The implementation supports both the legacy API and atomic updates without
>   any code specific to either
> - No changes to existing drivers are needed
> - The framebuffer format and size configuration API is reused
> 
> The framebuffer format and size should ideally be validated using information
> queried directly from the driver that supports the live source device, but
> I've decided not to implement such communication between V4L2 and DRM/KMS at
> the moment to keep the proposal simple.
> 
> Patches 3/5 to 5/5 then implement support for live sources in the R-Car DU
> driver. The rcar_du_live_framebuffer structure and its associated helper
> functions could be moved to the DRM core later if other drivers need a similar
> implementation. I've decided to keep them in the rcar-du driver for now as
> it's not clear yet what other drivers might need.
> 
> Once again nothing here is set in stone.

Yeah, this looks rather nice A few questions/ideas:
- Should we also go right ahead and add live sinks here with this and
  enumerate both live sinks and sources as live resources or something
  similar? The only big difference I see is that sinks will have different
  attachment points than sources.

- Not fully sure about possible_planes. I guess if the justification is
  that the drm core can take care of some input validation for drivers
  then it's useful. But if the idea is that userspace can use this to
  figure out the routing then I think this won't work.

- Do we need other basic checks like max/min width/height? Same concern as
  above.

- I think a live_resource_create callback would be useful so that the
  driver can check additional constraints (maybe just some size will work
  if e.g. it feeds directly into an mpeg encoder). Also I think we should
  figure out whether the addfb2 call or only attaching the live
  source/sink locks down the configuration on the v4l side of things.
  Imo locking down the settings has the advantage that you can do that all
  upfront on both v4l and drm side, and then immediately start the
  pipeline with just connecting it.

- Some helper to connect the drm and v4l side of things might be useful,
  especially to make sure you don't end up with incompatible settings on
  either end. Ties in with the above question of where we want to lock
  down the settings.

- Do we need some additional properties on live sources/sinks to at least
  make 

[Bug 89971] HDMI out *not* working with radeon (mobile 8550g)

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

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

--- Comment #4 from Adrian Gabor  ---
The following is all the logs I could get after plugging the tv in:

kernel:

[  245.271229] [drm] probing gen 2 caps for device 1022:1412 = 700d01/6
[  245.271237] [drm] enabling PCIE gen 2 link speeds, disable with
radeon.pcie_gen2=0
[  245.623105] [drm] PCIE GART of 1024M enabled (table at 0x0004).
[  245.623237] radeon :01:00.0: WB enabled
[  245.623242] radeon :01:00.0: fence driver on ring 0 use gpu addr
0x8c00 and cpu addr 0x880070de4c00
[  245.623246] radeon :01:00.0: fence driver on ring 1 use gpu addr
0x8c04 and cpu addr 0x880070de4c04
[  245.623249] radeon :01:00.0: fence driver on ring 2 use gpu addr
0x8c08 and cpu addr 0x880070de4c08
[  245.623252] radeon :01:00.0: fence driver on ring 3 use gpu addr
0x8c0c and cpu addr 0x880070de4c0c
[  245.623256] radeon :01:00.0: fence driver on ring 4 use gpu addr
0x8c10 and cpu addr 0x880070de4c10
[  245.831042] [drm] ring test on 0 succeeded in 1 usecs
[  245.831049] [drm] ring test on 1 succeeded in 1 usecs
[  245.831055] [drm] ring test on 2 succeeded in 1 usecs
[  245.831065] [drm] ring test on 3 succeeded in 4 usecs
[  245.831072] [drm] ring test on 4 succeeded in 3 usecs
[  245.831107] [drm] ib test on ring 0 succeeded in 0 usecs
[  245.831201] [drm] ib test on ring 1 succeeded in 0 usecs
[  245.831412] [drm] ib test on ring 2 succeeded in 0 usecs
[  245.831450] [drm] ib test on ring 3 succeeded in 0 usecs
[  245.831469] [drm] ib test on ring 4 succeeded in 0 usecs

gdm-xorg:

apr 14 13:46:50 adrianPC /usr/lib/gdm/gdm-x-session[357]: (II) RADEON(0): EDID
vendor "CMN", prod id 5547
apr 14 13:46:50 adrianPC /usr/lib/gdm/gdm-x-session[357]: (II) RADEON(0):
Printing DDC gathered Modelines:
apr 14 13:46:50 adrianPC /usr/lib/gdm/gdm-x-session[357]: (II) RADEON(0):
Modeline "1366x768"x0.0   69.40  1366 1400 1420 1476  768 77
apr 14 13:46:50 adrianPC /usr/lib/gdm/gdm-x-session[357]: (II) RADEON(0):
Allocate new frame buffer 1366x768 stride 1376
apr 14 13:46:50 adrianPC /usr/lib/gdm/gdm-x-session[357]: (II) RADEON(0): VRAM
usage limit set to 696085K
apr 14 13:46:50 adrianPC /usr/lib/gdm/gdm-x-session[357]: (II) RADEON(0): EDID
vendor "CMN", prod id 5547
apr 14 13:46:50 adrianPC /usr/lib/gdm/gdm-x-session[357]: (II) RADEON(0):
Printing DDC gathered Modelines:
apr 14 13:46:50 adrianPC /usr/lib/gdm/gdm-x-session[357]: (II) RADEON(0):
Modeline "1366x768"x0.0   69.40  1366 1400 1420 1476  768 77

-- 
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/20150414/7fbd4578/attachment-0001.html>

[PATCH 3/3] drm/radeon: add userfence IOCTL

[Daniel Vetter]

On Mon, Apr 13, 2015 at 03:48:51PM -0400, Jerome Glisse wrote:
> On Mon, Apr 13, 2015 at 08:26:05PM +0200, Christian König wrote:
> > On 13.04.2015 19:51, Jerome Glisse wrote:
> > >On Mon, Apr 13, 2015 at 07:23:34PM +0200, Daniel Vetter wrote:
> > >>On Mon, Apr 13, 2015 at 04:52:17PM +0200, Christian König wrote:
> > >>>From: Christian König 
> > >>>
> > >>>WIP patch which adds an user fence IOCTL.
> > >>>
> > >>>Signed-off-by: Christian König 
> > >>I've discussed userspace fences a lot with Jerome last XDC, so here's my
> > >>comments:
> > >>
> > >>My primary concern with mid-batch fences is that if we create real kernel
> > >>fences (which might even escape to other places using android syncpts or
> > >>dma-buf) then we end up relying upon correct userspace to not hang the
> > >>kernel, which isn't good.
> > >Yes i agree on that, solution i propose make sure that this can not happen.
> > 
> > What if we want to base a GPU scheduler and Android sync points on that
> > functionality? E.g. it might be necessary to create "struct fence" objects
> > which are based on the information from userspace.
> > 
> > Would that be possible or would we run into issues?
> 
> Well i would not like that, but i do not like Android code much, but you
> could use the same code as i show in my other email and just have the
> android fence struct take a reference on the BO where the fence is. Then
> using same code to check status.
> 
> Obviously there should be timeout as there is no way for the kernel to
> know if such fence will ever signal.

Yeah I think if your umd is using this for all fencing needs, including
cross-process and everything then I don't think it's such a good idea any
more ;-) But if it's just fine-grained sync for heterogenous compute
within the same process (ocl, hsa or whatever) then this seems reasonable.

I guess this boils down to what the userspace side will look like, and
what kind of standard you're trying to implement here.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[i915] assert_device_not_suspended

[Samuel Thibault]

I forgot to mention that this is linux 4.0.0

Samuel

[i915] assert_device_not_suspended

[Samuel Thibault]

Hello,

Yesterday, as usual I ran xlock before the night. In the morning, I
typed a key to wake it up, it didn't. I had to reboot. I could however
read in the logs:

Apr 14 05:00:13 type kernel: [33976.116204] WARNING: CPU: 2 PID: 63 at 
drivers/gpu/drm/i915/intel_uncore.c:69 assert_device_not_suspended+0x45/0x4e 
[i915]()
Apr 14 05:00:13 type kernel: [33976.116206] Device suspended
Apr 14 05:00:13 type kernel: [33976.116206] Modules linked in: tun xt_REDIRECT 
nf_nat_redirect xt_tcpudp ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat 
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables 
x_tables binfmt_misc nfsd cpufreq_powersave auth_rpcgss cpufreq_stats 
oid_registry nfs_acl cpufreq_userspace lockd cpufreq_conservative bbswitch(O) 
grace sunrpc joydev hid_generic usbhid hid cdc_mbim cdc_ncm usbnet mii cdc_acm 
cdc_wdm arc4 brcmsmac cordic brcmutil b43 nls_utf8 nls_cp437 mac80211 vfat fat 
cfg80211 x86_pkg_temp_thermal i915 kvm_intel kvm snd_hda_codec_hdmi ssb 
rng_core pcmcia pcmcia_core crct10dif_pclmul crc32_pclmul ghash_clmulni_intel 
aesni_intel aes_x86_64 dell_wmi lrw sparse_keymap gf128mul drm_kms_helper 
dell_laptop glue_helper rfkill ablk_helper cryptd drm psmouse dcdbas evdev 
serio_raw bcma i2c_i801 acpi_cpufreq tpm_tis wmi i2c_algo_bit tpm i2c_core 
8250_fintek video ac battery processor button snd_hda_codec_idt 
snd_hda_codec_generic ledtrig_timer ledtrig_oneshot ledtrig_heartbeat 
ledtrig_default_on snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep 
snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore coretemp ohci_hcd 
ledtrig_backlight pcspkr i8k firewire_sbp2 firewire_core crc_itu_t loop fuse 
parport_pc ppdev lp parport autofs4 microcode crc32c_intel ehci_pci ehci_hcd 
sdhci_pci sr_mod sdhci cdrom sg mmc_core usbcore e1000e ptp usb_common pps_core 
thermal thermal_sys
Apr 14 05:00:13 type kernel: [33976.116266] CPU: 2 PID: 63 Comm: kswapd0 
Tainted: G   O4.0.0 #87
Apr 14 05:00:13 type kernel: [33976.116267] Hardware name: Dell Inc. Latitude 
E6420/  , BIOS A14 07/11/2012
Apr 14 05:00:13 type kernel: [33976.116268]   0009 
8144544b 8800b1313a88
Apr 14 05:00:13 type kernel: [33976.116270]  8104a9bc 0002 
a0848b37 ea00026dffa0
Apr 14 05:00:13 type kernel: [33976.116272]  8801388b 00100028 
8801388b0068 0010002c
Apr 14 05:00:13 type kernel: [33976.116274] Call Trace:
Apr 14 05:00:13 type kernel: [33976.116280]  [] ? 
dump_stack+0x40/0x50
Apr 14 05:00:13 type kernel: [33976.116284]  [] ? 
warn_slowpath_common+0x98/0xb0
Apr 14 05:00:13 type kernel: [33976.116295]  [] ? 
assert_device_not_suspended+0x45/0x4e [i915]
Apr 14 05:00:13 type kernel: [33976.116297]  [] ? 
warn_slowpath_fmt+0x45/0x4a
Apr 14 05:00:13 type kernel: [33976.116308]  [] ? 
assert_device_not_suspended+0x45/0x4e [i915]
Apr 14 05:00:13 type kernel: [33976.116317]  [] ? 
gen6_write32+0x32/0x83 [i915]
Apr 14 05:00:13 type kernel: [33976.116328]  [] ? 
i915_gem_write_fence+0x270/0x46d [i915]
Apr 14 05:00:13 type kernel: [33976.116337]  [] ? 
i915_gem_object_update_fence+0x40/0xa6 [i915]
Apr 14 05:00:13 type kernel: [33976.116346]  [] ? 
i915_gem_object_put_fence+0xa2/0xac [i915]
Apr 14 05:00:13 type kernel: [33976.116355]  [] ? 
i915_vma_unbind+0xa4/0x1a6 [i915]
Apr 14 05:00:13 type kernel: [33976.116364]  [] ? 
i915_gem_shrink+0x11e/0x178 [i915]
Apr 14 05:00:13 type kernel: [33976.116373]  [] ? 
i915_gem_shrinker_scan+0x60/0x82 [i915]
Apr 14 05:00:13 type kernel: [33976.116376]  [] ? 
shrink_slab.part.53.constprop.71+0x1a6/0x2ac
Apr 14 05:00:13 type kernel: [33976.116379]  [] ? 
shrink_zone+0x6b/0x131
Apr 14 05:00:13 type kernel: [33976.116381]  [] ? 
kswapd+0x57a/0x740
Apr 14 05:00:13 type kernel: [33976.116383]  [] ? 
zone_reclaim+0x1cb/0x1cb
Apr 14 05:00:13 type kernel: [33976.116386]  [] ? 
kthread+0xab/0xb3
Apr 14 05:00:13 type kernel: [33976.116388]  [] ? 
__kthread_parkme+0x5d/0x5d
Apr 14 05:00:13 type kernel: [33976.116389]  [] ? 
ret_from_fork+0x58/0x90
Apr 14 05:00:13 type kernel: [33976.116391]  [] ? 
__kthread_parkme+0x5d/0x5d
Apr 14 05:00:13 type kernel: [33976.116392] ---[ end trace de34697426b2c759 ]---

So it seems it's the reclaiming that triggered an i915 operation while
the graphic card was suspended.

It's probably worth mentioning that I use on my i915 card:

echo auto > /sys/bus/pci/devices/:00:02.0/power/control

In the following days, I'll be trying the attached patch.

Samuel
-- next part --
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5258,6 +5258,11 @@ i915_gem_shrinker_scan(struct shrinker *
if (!i915_gem_shrinker_lock(dev, ))
return SHRINK_STOP;

+   if (HAS_RUNTIME_PM(dev_priv->dev) && dev_priv->pm.suspended)
+   {
+   freed = SHRINK_STOP;
+   goto out;
+   }
freed = i915_gem_shrink(dev_priv,
 

[Bug 89909] [radeonsi][bisected] Cities: Skylines black rooftops

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

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

--- Comment #2 from Marek Olšák  ---
Sqrt(x) results are undefined if x < 0, so the only thing we are allowed to do
is sqrt(abs(x)). That is how RSQ works.

-- 
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/20150414/348f21a1/attachment.html>

[PATCH] drm: Make integer overflow checking cover universal cursor updates (v2)

[Daniel Vetter]

On Mon, Apr 13, 2015 at 11:06:13AM -0700, Matt Roper wrote:
> Our legacy SetPlane updates perform integer overflow checking on a
> plane's destination rectangle in drm_mode_setplane(), and atomic updates
> handled as part of a drm_atomic_state transaction do the same checking
> in drm_atomic_plane_check().  However legacy cursor updates that get
> routed through universal plane interfaces may bypass this overflow
> checking if the driver's .update_plane is serviced by the transitional
> plane helpers rather than the full atomic plane helpers.
> 
> Move the check for destination rectangle integer overflow from the
> drm_mode_setplane() to __setplane_internal() so that it also covers
> cursor operations.
> 
> This fixes an issue first noticed with i915 commit:
> 
> commit ff42e093e9c9c17a6e1d6aab24875a36795f926e
> Author: Daniel Vetter 
> Date:   Mon Mar 2 16:35:20 2015 +0100
> 
> Revert "drm/i915: Switch planes from transitional helpers to full
> atomic helpers"
> 
> The above revert switched us from full atomic helpers back to the
> transitional helpers, and in doing so we lost the overflow checking here
> for universal cursor updates.  Even though such extreme cursor positions
> are unlikely to actually happen in the wild, we still don't want there
> to be a change of behavior when drivers switch from transitional helpers
> to full helpers.
> 
> v2: Move check from setplane ioctl to setplane_internal rather than
> adding an additional copy of the checks to the transitional plane
> helpers.  (Daniel)
> 
> Cc: Daniel Vetter 
> Testcase: igt/kms_cursor_crc
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84269
> Signed-off-by: Matt Roper 

Applied to drm-misc, thanks.
-Daniel

> ---
>  drivers/gpu/drm/drm_crtc.c | 22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index b914882..160647a 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -2507,6 +2507,17 @@ static int __setplane_internal(struct drm_plane *plane,
>   goto out;
>   }
>  
> + /* Give drivers some help against integer overflows */
> + if (crtc_w > INT_MAX ||
> + crtc_x > INT_MAX - (int32_t) crtc_w ||
> + crtc_h > INT_MAX ||
> + crtc_y > INT_MAX - (int32_t) crtc_h) {
> + DRM_DEBUG_KMS("Invalid CRTC coordinates %ux%u+%d+%d\n",
> +   crtc_w, crtc_h, crtc_x, crtc_y);
> + return -ERANGE;
> + }
> +
> +
>   fb_width = fb->width << 16;
>   fb_height = fb->height << 16;
>  
> @@ -2591,17 +2602,6 @@ int drm_mode_setplane(struct drm_device *dev, void 
> *data,
>   if (!drm_core_check_feature(dev, DRIVER_MODESET))
>   return -EINVAL;
>  
> - /* Give drivers some help against integer overflows */
> - if (plane_req->crtc_w > INT_MAX ||
> - plane_req->crtc_x > INT_MAX - (int32_t) plane_req->crtc_w ||
> - plane_req->crtc_h > INT_MAX ||
> - plane_req->crtc_y > INT_MAX - (int32_t) plane_req->crtc_h) {
> - DRM_DEBUG_KMS("Invalid CRTC coordinates %ux%u+%d+%d\n",
> -   plane_req->crtc_w, plane_req->crtc_h,
> -   plane_req->crtc_x, plane_req->crtc_y);
> - return -ERANGE;
> - }
> -
>   /*
>* First, find the plane, crtc, and fb objects.  If not available,
>* we don't bother to call the driver.
> -- 
> 1.8.5.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Bug 89909] [radeonsi][bisected] Cities: Skylines black rooftops

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

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

Michel Dänzer  changed:

   What|Removed |Added

 CC||maraeo at gmail.com,
   ||tstellar at gmail.com

--- Comment #1 from Michel Dänzer  ---
Marek/Tom, any ideas?

-- 
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/20150414/40bc48ba/attachment.html>

[Bug 89916] DRI PRIME renders only black window

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

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

--- Comment #1 from Michel Dänzer  ---
Please attach the Xorg log file and the output of dmesg.

-- 
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/20150414/20f75b64/attachment.html>

[Bug 89971] HDMI out *not* working with radeon (mobile 8550g)

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

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

--- Comment #3 from Michel Dänzer  ---
Please attach the logs corresponding to the TV being connected to the HDMI
port.

-- 
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/20150414/b3933d4a/attachment.html>

[Bug 89980] [Regression] Graphical corruption after resuming from suspend (w/ dual monitor configuration)

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

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

--- Comment #3 from falaca at gmail.com ---
Based on my debugging so far, it seems that mesa is the likely culprit.

Step #1: Fresh install of Ubuntu 14.04 (installed on a new, clean partition):
Linux 3.13 kernel -> Manually upgraded to Linux 4.0 mainline
Xorg 1.15.1
Mesa 10.1.3
xf86-video-ati 7.3
libdrm 2.4.56

Status: The bug is not present, and confirms that the issue is not with the
kernel.

--

Step #2: Installed Ubuntu 14.04.2 hardware enablement stack:
Linux 4.0 (mainline)
Xorg 1.16.0
Mesa 10.3.2
xf86-video-ati 7.4
libdrm 2.4.56

Status: The bug is present.

--

Step #3: I reverted to the original 14.04 packages, but compiled xf86-video-ati
7.4 from git.

Status: The bug is not present, and confirms (?) that the issue is not with
ddx.

--

Step #4: I had trouble getting Ubuntu to work with Mesa compiled from git
(whenever I try to log in, I just get kicked back to the lightdm greeter), and
I couldn't upgrade Mesa from the Ubuntu repo without also upgrading Xorg, so I
upgraded Mesa from Oibaf PPA:

Linux 4.0 (mainline)
Xorg 1.15.1
Mesa 10.6 (oibaf-ppa)
xf86-video-ati 7.4 (git) (also tested 7.5.99 from oibaf-ppa)
libdrm 2.4.60 (oibaf-ppa)

Status: The bug is present. So it seems likely that the bug was introduced
somewhere between Mesa 10.1.3 and 10.3.2.

If I can figure out how to get Ubuntu to play nice with mainline Mesa compiled
from git (maybe if I figure out how to apply the Ubuntu patches), I can do a
bisect, but that's where I'm stuck as of now.

-- 
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/20150414/bc334b7f/attachment.html>

[Bug 89995] error 6 in libgallium.so.0.0.0 (Kodi Crashed when playing LiveTV using TVHeadend)

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

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

Michel Dänzer  changed:

   What|Removed |Added

  Component|Drivers/Gallium/radeonsi|Drivers/Gallium/r600

--- Comment #2 from Michel Dänzer  ---
Can you attach a backtrace of the crash from gdb, with the libgl1-mesa-dri-dbg
package installed?

-- 
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/20150414/5f456d9d/attachment-0001.html>

[Bug 89957] vm protection faults in piglit lest: texsubimage cube_map_array pbo

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

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

Dave Airlie  changed:

   What|Removed |Added

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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: