[Bug 104285] Euro Truck Simulator 2 and American Truck Simulator artifacts (Mesa 17.3, AMD R9 280X)

[bugzilla-daemon]

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

--- Comment #6 from Alex Vorobyev  ---
Solus started shipping Linux 4.15.3 and Mesa 18.0 RC4, but unfortunately the
problem is still there. After comment #4 I wonder if LLVM 6.0 will make the
difference...

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 04/10] drm: Add Plane Gamma properties

[Shankar, Uma]

>-Original Message-
>From: Harry Wentland [mailto:harry.wentl...@amd.com]
>Sent: Saturday, February 17, 2018 3:07 AM
>To: Ville Syrjälä ; Daniele Castagna
>
>Cc: Shankar, Uma ; dri-devel@lists.freedesktop.org
>Subject: Re: [PATCH 04/10] drm: Add Plane Gamma properties
>
>On 2018-02-16 03:10 PM, Ville Syrjälä wrote:
>> On Thu, Feb 15, 2018 at 02:45:29PM -0500, Daniele Castagna wrote:
>>> rk3399 has the option of setting per-plane gamma.
>>> The YUV2YUV registers are per-plane. Each plane YUV2YUV pipeline has
>>> at least 3 optional stages, two of those being degamma and gamma, and
>>> they can be configured per-plane.
>>>
>
>I don't mind having a per-plane gamma, especially since rk3399 has it in HW. It
>just seemed a bit curious to me and I'd rather avoid properties that would 
>never
>be used by any driver.
>
>>> I'm not sure about Intel HW. I think they might have something
>>> similar planned, considering the original patch was from uma.shankar.
>>> CCing directly in case he knows more.
>>
>> IIRC some of out upcoming stuff will have a pipeline like
>> 'csc->degamma->csc->gamma->blender'. I don't really know what the
>> point of the post csc gamma is though. Normally you would not want to
>> reapply any gamma prior to blending.
>>
>> The only use case I can think of would be if you don't have a gamma
>> lut in the crtc for post blend gamma. In that case I suppose you might
>> consider doing the gamma before blending and accepting the slightly
>> incorrect blending results. But at least on our hardware we always
>> have a gamma lut in the crtc as well.
>
>That's what I was thinking of as the only possible use-case as well.
>

The primary use case of the post CSC plane gamma LUT will be to do tone
mapping in case of HDR data. Again the accuracy of it will depend on the
number of LUT samples and precision. It could be used, if for some strange
use case we want non-linear blending. I believe Android was using non-linear
blending by design (not sure if it changed in recent variants). Also as Ville
mentioned, if we lack gamma at pipe level on certain hardware, this may be
required. But tone mapping is the primary use case.

Regards,
Uma Shankar

>Harry
>
>>
>> So yeah, I don't really have any reason why we'd need to actually to
>> expose the per-plane gamma. Some "crazy" artistic use case perhaps?
>>
>> I'm totally fine not exposing it until someone comes up with an actual
>> use for it.
>>
>> Does rk3399 have a dedicated csc for yuv->rgb before degamma? Or are
>> you supposed to use the same csc for that as you'd use for ctm? In
>> that case I can understand why the hw would have a gamm lut on each
>> side of the csc. But it would also means that you can't do yuv->rgb
>> and ctm at the same time unless you're fine with doing it wrong.
>>
>>>
>>> On Thu, Feb 15, 2018 at 2:29 PM, Harry Wentland
> wrote:
 On 2018-02-15 12:32 AM, Daniele Castagna wrote:
> From: "uma.shankar at intel.com (Uma Shankar)"
> 
>
> Add plane gamma as blob property and size as a range property.
>

 Plane degamma & CTM make sense to me but I'm not sure why gamma
>would be on a per-plane basis. That said, HW sometimes has these implemented
>in odd ways. Do we know of any HW that will currently or in the future need 
>per-
>plane gamma or are we just trying to cover all potentialities?

 Harry

> (am from https://patchwork.kernel.org/patch/9971325/)
>
> Change-Id: I606cd40c9748b136fc2bf4750bea1da285add62d
> Signed-off-by: Uma Shankar 
> ---
>  drivers/gpu/drm/drm_atomic.c|  8 
>  drivers/gpu/drm/drm_atomic_helper.c |  4 
>  drivers/gpu/drm/drm_mode_config.c   | 14 ++
>  include/drm/drm_mode_config.h   | 11 +++
>  include/drm/drm_plane.h |  9 +
>  5 files changed, 46 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c
> b/drivers/gpu/drm/drm_atomic.c index d4b8c6cc84128..f634f6450f415
> 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -778,6 +778,12 @@ static int drm_atomic_plane_set_property(struct
>drm_plane *plane,
>   );
>   state->color_mgmt_changed |= replaced;
>   return ret;
> + } else if (property == config->plane_gamma_lut_property) {
> + ret = drm_atomic_replace_property_blob_from_id(dev,
> + >gamma_lut,
> + val, -1, );
> + state->color_mgmt_changed |= replaced;
> + return ret;
>   } else {
>   return -EINVAL;
>   }
> @@ -841,6 +847,8 @@ drm_atomic_plane_get_property(struct drm_plane
>*plane,
>   

[PATCH] fix double ;;s in code

[Pavel Machek]

Fix double ;;'s in code.

Signed-off-by: Pavel Machek 

diff --git a/arch/arc/kernel/setup.c b/arch/arc/kernel/setup.c
index 9d27331..ec12fe1 100644
--- a/arch/arc/kernel/setup.c
+++ b/arch/arc/kernel/setup.c
@@ -373,7 +373,7 @@ static void arc_chk_core_config(void)
 {
struct cpuinfo_arc *cpu = _arc700[smp_processor_id()];
int saved = 0, present = 0;
-   char *opt_nm = NULL;;
+   char *opt_nm = NULL;
 
if (!cpu->extn.timer0)
panic("Timer0 is not present!\n");
diff --git a/arch/arc/kernel/unwind.c b/arch/arc/kernel/unwind.c
index 333daab..183391d 100644
--- a/arch/arc/kernel/unwind.c
+++ b/arch/arc/kernel/unwind.c
@@ -366,7 +366,7 @@ static void init_unwind_hdr(struct unwind_table *table,
return;
 
 ret_err:
-   panic("Attention !!! Dwarf FDE parsing errors\n");;
+   panic("Attention !!! Dwarf FDE parsing errors\n");
 }
 
 #ifdef CONFIG_MODULES
diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
index 629f8e9..cf2701c 100644
--- a/arch/arm/kernel/time.c
+++ b/arch/arm/kernel/time.c
@@ -83,7 +83,7 @@ static void dummy_clock_access(struct timespec64 *ts)
 }
 
 static clock_access_fn __read_persistent_clock = dummy_clock_access;
-static clock_access_fn __read_boot_clock = dummy_clock_access;;
+static clock_access_fn __read_boot_clock = dummy_clock_access;
 
 void read_persistent_clock64(struct timespec64 *ts)
 {
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 6618036..9ae31f7 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -1419,7 +1419,7 @@ static int compat_ptrace_hbp_get(unsigned int note_type,
u64 addr = 0;
u32 ctrl = 0;
 
-   int err, idx = compat_ptrace_hbp_num_to_idx(num);;
+   int err, idx = compat_ptrace_hbp_num_to_idx(num);
 
if (num & 1) {
err = ptrace_hbp_get_addr(note_type, tsk, idx, );
diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c
index f0f5cd4..f9818d7 100644
--- a/arch/powerpc/kvm/book3s_xive.c
+++ b/arch/powerpc/kvm/book3s_xive.c
@@ -188,7 +188,7 @@ static int xive_provision_queue(struct kvm_vcpu *vcpu, u8 
prio)
if (!qpage) {
pr_err("Failed to allocate queue %d for VCPU %d\n",
   prio, xc->server_num);
-   return -ENOMEM;;
+   return -ENOMEM;
}
memset(qpage, 0, 1 << xive->q_order);
 
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 496e476..a6c92c7 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1854,7 +1854,7 @@ static int pnv_pci_ioda_dma_set_mask(struct pci_dev 
*pdev, u64 dma_mask)
s64 rc;
 
if (WARN_ON(!pdn || pdn->pe_number == IODA_INVALID_PE))
-   return -ENODEV;;
+   return -ENODEV;
 
pe = >ioda.pe_array[pdn->pe_number];
if (pe->tce_bypass_enabled) {
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 353e20c..886a911 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -439,7 +439,7 @@ setup_uga32(void **uga_handle, unsigned long size, u32 
*width, u32 *height)
struct efi_uga_draw_protocol *uga = NULL, *first_uga;
efi_guid_t uga_proto = EFI_UGA_PROTOCOL_GUID;
unsigned long nr_ugas;
-   u32 *handles = (u32 *)uga_handle;;
+   u32 *handles = (u32 *)uga_handle;
efi_status_t status = EFI_INVALID_PARAMETER;
int i;
 
@@ -484,7 +484,7 @@ setup_uga64(void **uga_handle, unsigned long size, u32 
*width, u32 *height)
struct efi_uga_draw_protocol *uga = NULL, *first_uga;
efi_guid_t uga_proto = EFI_UGA_PROTOCOL_GUID;
unsigned long nr_ugas;
-   u64 *handles = (u64 *)uga_handle;;
+   u64 *handles = (u64 *)uga_handle;
efi_status_t status = EFI_INVALID_PARAMETER;
int i;
 
diff --git a/block/sed-opal.c b/block/sed-opal.c
index 9ed51d0c..e4929ee 100644
--- a/block/sed-opal.c
+++ b/block/sed-opal.c
@@ -490,7 +490,7 @@ static int opal_discovery0_end(struct opal_dev *dev)
 
if (!found_com_id) {
pr_debug("Could not find OPAL comid for device. Returning 
early\n");
-   return -EOPNOTSUPP;;
+   return -EOPNOTSUPP;
}
 
dev->comid = comid;
diff --git a/drivers/clocksource/mips-gic-timer.c 
b/drivers/clocksource/mips-gic-timer.c
index a04808a..65e18c8 100644
--- a/drivers/clocksource/mips-gic-timer.c
+++ b/drivers/clocksource/mips-gic-timer.c
@@ -205,12 +205,12 @@ static int __init gic_clocksource_of_init(struct 
device_node *node)
} else if (of_property_read_u32(node, "clock-frequency",
_frequency)) {
pr_err("GIC frequency not specified.\n");
-   return -EINVAL;;
+   return -EINVAL;
}
gic_timer_irq = 

setterm -blank force no longer works after switch to omapdrm

[Pavel Machek]

Hi!

I used to have use omap fb driver, and blanking worked as expected. It
no longer works with omap drm driver. (Tested on v4.16-rc1, but I
believe it is broken in older versions, too.)

Can you test it on your hw? Any ideas what could be wrong?

xset dpms force on/off works as expected.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105145] vaExportSurfaceHandle interaction with surface interlaced flag prevents switching on vaapi deinterlacing dynamically

[bugzilla-daemon]

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

Christian König  changed:

   What|Removed |Added

 Resolution|--- |NOTOURBUG
 Status|NEW |RESOLVED

--- Comment #1 from Christian König  ---
Yeah, that is a design issue with vlVaExportSurfaceHandle.

E.g. vlVaExportSurfaceHandle can only export surfaces when they are in the
progressive memory layout because VA-API doesn't supports interlaced layouts.
To not run into issues with that limitation we reallocate the backing store for
the surface and copy from the interlaced presentation to the progressive layout
on the first vlVaExportSurfaceHandle.

Now post processing is only possible if you got the interlaced format, cause
otherwise extracting the odd/even fields costs to much time.

What we could try to do is to reverse what is done in vlVaExportSurfaceHandle
before post processing, e.g. copy from progressive to interlaced. But that
usually means we lag for quite a number of frames (because of the extra copy)
until all surfaces are in interlaced format again.

Not sure what to do here except for fixing VA-API.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105083] Random blinking display

[bugzilla-daemon]

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

--- Comment #7 from Ashley Bone <442fc...@opayq.com> ---
(In reply to denisgolovan from comment #6)
> (In reply to Allen from comment #5)
> 
> > the flicker happens periodically as Redshift adjusts the color temperature
> > over time.
> 
> Yes. Seems pretty similar.
> However it happens also periodically when redshift is active.

I agree, this is the flickering I'm seeing, and it does happen occasionally
when redshift is running even when it's not adjusting the color temperature. 
It's much more frequent during the transition times when it is adjusting.

If I disable either redshift or amdgpu DC, I don't see any flickering.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland

[bugzilla-daemon]

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

--- Comment #33 from Bong Cosca  ---
Wine works perfect with above change.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100387] War Thunder game has visual errors, missing textures

[bugzilla-daemon]

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

--- Comment #21 from aceman  ---
Yes, with amdgpu+radeonsi (on RX560) there are no issues. It runs at 40-60fps
on Medium details.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105145] vaExportSurfaceHandle interaction with surface interlaced flag prevents switching on vaapi deinterlacing dynamically

[bugzilla-daemon]

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

Bug ID: 105145
   Summary: vaExportSurfaceHandle interaction with surface
interlaced flag prevents switching on vaapi
deinterlacing dynamically
   Product: Mesa
   Version: git
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: k.phil...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

When decoding interlaced video with VAAPI and least when using the radeonsi
driver, it is impossible to postproc-deinterlace a frame from a surface that
was used with vaExportSurfaceHandle() before.

This effectively means that it is impossible to dynamically switch on
deinterlacing mid-stream, i.e. after an *interlaced* frame has been shown
unprocessed with vaExportSurfaceHandle.

Try for example with mpv from git:
mpv -vo gpu --hwdec=vaapi /path/to/interlaced/video.mkv
(add --gpu-context=wayland when running under Wayland, else vaapi will not
work)
give it a few seconds and then switch on deinterlacing with the 'd' key.
You will see the error mesage "vaRenderPicture() failed (invalid VASurfaceID)"
and not get any deinterlacing. Having deinterlacing enabled from the beginning
(e.g. with "--deinterlace=yes") works, since no unprocesssed surface is
exported then.

The chain of events seems to be:
- Create surfaces for decoding. They are marked interlaced by default on
radeonsi. (see
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/radeonsi/si_get.c?id=9d21dbeb88bc99ca0e153c11265e19536ad36b61#n655
- PREFERS_INTERLACED is always returned as true)
- Export the decoded surfaces with vaExportSurfaceHandle() and present them to
the user. This has the side-effect of making the surfaces non-interlaced (see
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/va/surface.c?id=9d21dbeb88bc99ca0e153c11265e19536ad36b61#n966)
- Now we want to turn on postproc.
- Create surfaces for postproc. They are, again, marked interlaced by default
- Trying to deinterlace gives VA_STATUS_ERROR_INVALID_SURFACE_ID since it
thinks that the source surface is not interlaced, and that the destination
surface is - both of which is wrong (see
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/va/postproc.c?id=9d21dbeb88bc99ca0e153c11265e19536ad36b61#n131)

Reporting this against the radeonsi driver since I couldn't test with anything
else, but the issue may really be in how vlVaExportSurfaceHandle works on all
drivers.
On a related note, since the radeonsi driver by default generates interlaced
surfaces when using vaCreateSurfaces, vlVaExportSurfaceHandle making them
progressive seems to be the only reason it correctly bob-deinterlaces at the
moment (MADI seems to be fine because it uses another code path). At least
after all output surfaces have been exported once, before that it just blits. I
also consider this a bug that could now be solved at the same time. If not, I
can open a new ticket for that.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Ris: [PATCH] drm/sun4i: fix HSYNC and VSYNC polarity

[giulio.bene...@micronovasrl.com]

Thanks! Giulio Benetti  Messaggio originale Oggetto: Re: [PATCH] drm/sun4i: fix HSYNC and VSYNC polarityDa: Maxime Ripard A: Giulio Benetti CC: Chen-Yu Tsai ,dri-devel@lists.freedesktop.org,linux-arm-ker...@lists.infradead.org,linux-ker...@vger.kernel.orgOn Thu, Feb 15, 2018 at 06:54:48PM +0100, Giulio Benetti wrote:> Differently from other Lcd signals, HSYNC and VSYNC signals> result inverted if their bits are cleared to 0.> > Invert their settings of IO_POL register.> > Signed-off-by: Giulio Benetti Applied, thanks!Maxime-- Maxime Ripard, Bootlin (formerly Free Electrons)Embedded Linux and Kernel engineeringhttp://bootlin.com___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105083] Random blinking display

[bugzilla-daemon]

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

--- Comment #6 from denisgolo...@yandex.ru ---
(In reply to Allen from comment #5)

> the flicker happens periodically as Redshift adjusts the color temperature
> over time.

Yes. Seems pretty similar.
However it happens also periodically when redshift is active.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105144] Recent mesa makes GPU temperature too hot with GL/VDPAU/VAAPI

[bugzilla-daemon]

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

Bug ID: 105144
   Summary: Recent mesa makes GPU temperature too hot with
GL/VDPAU/VAAPI
   Product: DRI
   Version: XOrg git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: whatisthis.sow...@gmail.com

With mesa 17.3 (and maybe kernel >= 4.13), using GL,VAAPI or VDPAU, GPU
temperature makes to be too hot.

Almost upper than 60℃ with RADEON HD7770 (less than 15℃ at room).
When not using GL etc, temperature upper than 50℃.
With earlier version of GL, VAAPI and VDPAU, temperature is less than 60℃ (at
worst, less than 70℃).

Regards,
Ohta.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105083] Random blinking display

[bugzilla-daemon]

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

--- Comment #5 from Allen  ---
(In reply to Harry Wentland from comment #4)
> How bad is the flicker? Would you be able to take a video showing the
> flicker and post it (youtube or anywhere, really)?

Video Card: RX 480

As I am suffering as well from this problem, I have uploaded a video to
youtube.

https://youtu.be/fMNhPH6QG00

the flicker happens periodically as Redshift adjusts the color temperature over
time.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104439] intel_do_flush_locked failed: Invalid argument

[bugzilla-daemon]

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

--- Comment #8 from Urs Fleisch  ---
I have verified if the git bisect has found the real bad commit and can confirm
that

c7c6e46f913b drm/i915: Convert execbuf to use struct-of-array packing for
critical fields

is the last good commit. Two commits later

commit 170fa29b14fadf2deb361589cefe6a78b21b1b22
Author: Chris Wilson 
Date:   Wed Aug 16 09:52:07 2017 +0100

drm/i915: Simplify eb_lookup_vmas()

Since the introduction of being able to perform a lockless lookup of an
object (i915_gem_object_get_rcu() in fbbd37b36fa5 ("drm/i915: Move object
release to a freelist + worker") we no longer need to split the
object/vma lookup into 3 phases and so combine them into a much simpler
single loop.

and

commit d1b48c1e7184d9bc4ae6d7f9fe2eed9efed11ffc
Author: Chris Wilson 
Date:   Wed Aug 16 09:52:08 2017 +0100

drm/i915: Replace execbuf vma ht with an idr

This was the competing idea long ago, but it was only with the rewrite
of the idr as an radixtree and using the radixtree directly ourselves,
along with the realisation that we can store the vma directly in the
radixtree and only need a list for the reverse mapping, that made the
patch performant enough to displace using a hashtable. Though the vma ht
is fast and doesn't require any extra allocation (as we can embed the node
inside the vma), it does require a thread for resizing and serialization
and will have the occasional slow lookup. That is hairy enough to
investigate alternatives and favour them if equivalent in peak performance.
One advantage of allocating an indirection entry is that we can support a
single shared bo between many clients, something that was done on a
first-come first-serve basis for shared GGTT vma previously. To offset
the extra allocations, we create yet another kmem_cache for them.

the bug was introduced. Graphics are distorted, the Linux kernel is not really
usable with my Intel graphics Q35.
The bug is easy to reproduce: Start the Chromium and browse maps.google.com.

Chromium reports

intel_do_flush_locked failed: Invalid argument

Using strace on ioctl, I can see that the invalid argument is caused by

ioctl(129, DRM_IOCTL_I915_GEM_EXECBUFFER2_WR, 0x7ffd8b5b6540) = -1 EINVAL
(Invalid argument)

Using some printk debugging, it can be seen that i915_gem_execbuffer2() returns
first -512=-ERESTARTSYS and then four times -22=-EINVAL.

@Chris Wilson: Could you please have a look at the problem? Do you have old
Intel graphics Q35 available to reproduce the issue? I would fix the problem
myself if I had enough knowledge about this driver. The best I could probably
do would be to introduce a module parameter to restore the old behavior using
the hashtable instead of the radix tree, but there must be a better solution to
use the new radix tree and keep it working on old Intel graphics hardware. I
will provide you with as much information as needed and will check patches once
you have some available.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Lukas Wunner]

On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
>   workqueue: Allow retrieval of current task's work struct
>   drm: Allow determining if current task is output poll worker
>   drm/nouveau: Fix deadlock on runtime suspend
>   drm/radeon: Fix deadlock on runtime suspend
>   drm/amdgpu: Fix deadlock on runtime suspend

Pushed to drm-misc-fixes, thanks a lot everyone for the acks,
reviews, testing and comments.

drm-misc maintainers, heads-up:

drm-misc-fixes is still based on 4.15-rc8.  The present series
applies cleanly to both 4.15 and 4.16, so I had no need to have
4.16-rc1 backmerged, but that may be necessary sooner or later.
I did a local test pull into drm-fixes, the shortlog looked sane
and it merged and compiled cleanly.

Please note two other commits are still pending in drm-misc-fixes:

commit 745fd50f3b044db6a3922e1718306555613164b0
Author: Daniel Vetter 
Date:   Wed Jan 31 12:04:50 2018 +0100

drm/cirrus: Load lut in crtc_commit

Gustavo sent a pull request for this one on Jan 31 but erroneously
based it on the wrong commit and it ended up not being pulled by Dave.

commit 54f809cfbd6b4a43959039f5d33596ed3297ce16
Author: Leo (Sunpeng) Li 
Date:   Wed Jan 17 12:51:08 2018 +0100

drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits

This one has already been pulled by Dave into drm-next for 4.17
as commit 1c6c6ebb but Maarten subsequently cherry-picked
it onto drm-misc-fixes.

Let me know if I've made any mistakes.

Thanks,

Lukas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 197841] lg 25um58-P monitor wrong refresh rate with rx 460

[bugzilla-daemon]

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

habbosuperb...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |CODE_FIX

--- Comment #2 from habbosuperb...@gmail.com ---
This problem was solved in kernel 4.15

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[drm/ttm] 3cd2e64830: BUG:kernel_hang_in_early-boot_stage,last_printk:early_console_in_setup_code

[kernel test robot]

FYI, we noticed the following commit (built with gcc-7):

commit: 3cd2e64830059791297a2f7817b41557a60f9234 ("drm/ttm: move ttm_lock and 
ttm_object into vmwgfx")
url: 
https://github.com/0day-ci/linux/commits/Christian-K-nig/drm-ttm-move-ttm_lock-and-ttm_object-into-vmwgfx/20180204-085007
base: git://people.freedesktop.org/~airlied/linux.git drm-next

in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -m 512M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+---+++
|   
| 24b8ef699e | 3cd2e64830 |
+---+++
| boot_successes
| 18 | 0  |
| boot_failures 
| 30 | 9  |
| INFO:task_blocked_for_more_than#seconds   
| 16 ||
| Kernel_panic-not_syncing:hung_task:blocked_tasks  
| 16 ||
| BUG:workqueue_lockup-pool 
| 14 ||
| BUG:kernel_hang_in_early-boot_stage,last_printk:early_console_in_setup_code   
| 0  | 7  |
| 
BUG:kernel_reboot-without-warning_in_early-boot_stage,last_printk:early_console_in_setup_code
 | 0  | 2  |
+---+++



early console in setup code
BUG: kernel hang in early-boot stage, last printk: early console in setup code
Linux version 4.15.0-rc8-01510-g3cd2e64 #1
Command line: ip=vm-lkp-nex04-yocto-x86_64-29::dhcp root=/dev/ram0 user=lkp 
job=/lkp/scheduled/vm-lkp-nex04-yocto-x86_64-29/boot-1-yocto-minimal-x86_64-2016-04-22.cgz-3cd2e64830059791297a2f7817b41557a60f9234-20180217-52809-f8gx9u-0.yaml
 ARCH=x86_64 kconfig=x86_64-randconfig-ws0-02131753 
branch=linux-devel/devel-hourly-2018021313 
commit=3cd2e64830059791297a2f7817b41557a60f9234 
BOOT_IMAGE=/pkg/linux/x86_64-randconfig-ws0-02131753/gcc-7/3cd2e64830059791297a2f7817b41557a60f9234/vmlinuz-4.15.0-rc8-01510-g3cd2e64
 max_uptime=600 
RESULT_ROOT=/result/boot/1/vm-lkp-nex04-yocto-x86_64/yocto-minimal-x86_64-2016-04-22.cgz/x86_64-randconfig-ws0-02131753/gcc-7/3cd2e64830059791297a2f7817b41557a60f9234/0
 LKP_SERVER=inn debug apic=debug sysrq_always_enabled 
rcupdate.rcu_cpu_stall_timeout=100 net.ifnames=0 printk.devkmsg=on panic=-1 
softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 
prompt_ramdisk=0 drbd.minor_count=8 systemd.log_level=err ignore_loglevel 
console=tty0 earlyprintk=ttyS0,115200 console=ttyS0,115200 vga=normal rw 
drbd.minor_count=8 rcuperf.shutdown=0

Elapsed time: 320



To reproduce:

git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
lkp
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.15.0-rc8 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_KASAN_SHADOW_OFFSET=0xdc00
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERN

[Bug 105142] Texture operations hang indefinitely

[bugzilla-daemon]

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

--- Comment #2 from Pawel Veselov  ---
Created attachment 137415
  --> https://bugs.freedesktop.org/attachment.cgi?id=137415=edit
version list

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105142] Texture operations hang indefinitely

[bugzilla-daemon]

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

--- Comment #1 from Pawel Veselov  ---
Created attachment 137414
  --> https://bugs.freedesktop.org/attachment.cgi?id=137414=edit
stack trace

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105142] Texture operations hang indefinitely

[bugzilla-daemon]

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

Bug ID: 105142
   Summary: Texture operations hang indefinitely
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: libdrm
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: pawel.vese...@gmail.com

Created attachment 137413
  --> https://bugs.freedesktop.org/attachment.cgi?id=137413=edit
dmesg output

Reproducible running compiz on mate, on FC27.
I can reproduce this fairly consistently, if enabling emerald window
decorations, though it can fail with GTK+ decorations as well. Using Alt-Tab to
switch between windows triggers this problem. Only the process is hanging,
SIGKILL is needed to restart the process.

Stack trace attached in stack.txt
Library version list attached in vers.txt
Full dmesg output attached in dmesg.txt

I'm fairly certain I've miscategorized this bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel