[Bug 104285] Euro Truck Simulator 2 and American Truck Simulator artifacts (Mesa 17.3, AMD R9 280X)
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
>-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,
> &replaced);
> state->color_mgmt_changed |= replaced;
> return ret;
> + } else if (property == config->plane_gamma_lut_property) {
> + ret = drm_atomic_replace_property_blob_from_id(dev,
> + &state->gamma_lut,
> + val, -1, &replaced);
> + state->color_mgmt_changed |= replaced;
> + return ret;
> } else {
> return -EINVAL;
> }
> @@ -841,6 +847,8 @@ drm_atomic_plane_get_property(struct drm_plane
>*plane,
> state->degamma_lut->base.id : 0;
> } else if (property == config->plane_ctm_property) {
>
[PATCH] fix double ;;s in code
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 = &cpuinfo_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, &addr);
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 = &phb->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",
&gic_frequency)) {
pr_err("GIC frequency not specified.\n");
- return -EINVAL;;
+ return -EINVAL;
}
gic_timer_irq = irq_of
setterm -blank force no longer works after switch to omapdrm
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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&action=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
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&action=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
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&action=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
