dri-devel January 2016

dri-devel@lists.freedesktop.org

194 participants
1200 discussions

[PATCH libdrm 1/2] kmstest: Use util_open()
by Stefan Agner 26 Jan '16

26 Jan '16

Use the new util_open() helper instead of open-coding the method for finding a usable device. While at it, make the command-line interface more consistent with that of modetest by adding the -D and -M options. Signed-off-by: Stefan Agner <stefan(a)agner.ch> --- tests/kmstest/Makefile.am | 4 +++- tests/kmstest/main.c | 45 +++++++++++++++++++++++++++++---------------- 2 files changed, 32 insertions(+), 17 deletions(-) diff --git a/tests/kmstest/Makefile.am b/tests/kmstest/Makefile.am index fd21e61..100662e 100644 --- a/tests/kmstest/Makefile.am +++ b/tests/kmstest/Makefile.am @@ -2,6 +2,7 @@ AM_CFLAGS = \ $(WARN_CFLAGS)\ -I$(top_srcdir)/include/drm \ -I$(top_srcdir)/libkms/ \ + -I$(top_srcdir)/tests/ \ -I$(top_srcdir) if HAVE_INSTALL_TESTS @@ -17,7 +18,8 @@ kmstest_SOURCES = \ kmstest_LDADD = \ $(top_builddir)/libdrm.la \ - $(top_builddir)/libkms/libkms.la + $(top_builddir)/libkms/libkms.la \ + $(top_builddir)/tests/util/libutil.la run: kmstest ./kmstest diff --git a/tests/kmstest/main.c b/tests/kmstest/main.c index 120bc0f..fe8f42e 100644 --- a/tests/kmstest/main.c +++ b/tests/kmstest/main.c @@ -25,12 +25,14 @@ * **************************************************************************/ - +#include <getopt.h> #include <stdio.h> #include <string.h> #include "xf86drm.h" #include "libkms.h" +#include "util/kms.h" + #define CHECK_RET_RETURN(ret, str) \ if (ret < 0) { \ printf("%s: %s (%s)\n", __func__, str, strerror(-ret)); \ @@ -56,26 +58,37 @@ static int test_bo(struct kms_driver *kms) return 0; } -static const char *drivers[] = { - "i915", - "radeon", - "nouveau", - "vmwgfx", - "exynos", - "amdgpu", - "imx-drm", - "rockchip", - "atmel-hlcdc", - NULL -}; +static void usage(const char *program) +{ + fprintf(stderr, "Usage: %s [options]\n", program); + fprintf(stderr, "\n"); + fprintf(stderr, " -D DEVICE open the given device\n"); + fprintf(stderr, " -M MODULE open the given module\n"); +} int main(int argc, char** argv) { + static const char optstr[] = "D:M:"; struct kms_driver *kms; - int ret, fd, i; + int c, fd, ret; + char *device = NULL; + char *module = NULL; + + while ((c = getopt(argc, argv, optstr)) != -1) { + switch (c) { + case 'D': + device = optarg; + break; + case 'M': + module = optarg; + break; + default: + usage(argv[0]); + return 0; + } + } - for (i = 0, fd = -1; fd < 0 && drivers[i]; i++) - fd = drmOpen(drivers[i], NULL); + fd = util_open(module, device); CHECK_RET_RETURN(fd, "Could not open device"); ret = kms_create(fd, &kms); -- 2.6.4

2 2

[PATCH 00/11] sync framework de-staging: part 2 - de-stage
by Gustavo Padovan 26 Jan '16

26 Jan '16

From: Gustavo Padovan <gustavo.padovan(a)collabora.co.uk> This patch series de-stage the sync framework and it a follow up on the clean up series I've sent last week: http://thread.gmane.org/gmane.comp.video.dri.devel/145509 Now in part 2 we finish the de-stage of the sync framework. It start with the move of sync_file from staging to drivers/dma-buf, followed by a bunch of clean ups on sync_timeline and sw_sync. Finally we de-stage the later two plus the debug routines. Gustavo Padovan (11): dma-buf/sync_file: de-stage sync_file staging/android: store last signaled value on sync timeline staging/android: remove .fill_driver_data() timeline ops staging/android: remove .{fence,timeline}_value_str() from timeline_ops staging/android: remove struct sync_timeline_ops staging/android: remove sw_sync_timeline and sw_sync_pt staging/android: remove sw_sync.[ch] files staging/android: rename android_fence to timeline_fence dma-buf/sync_timeline: de-stage sync_timeline dma-buf/sync_file: bring debug back to sync file dma-buf/sync_file: bring sync_dump() back drivers/Kconfig | 2 + drivers/dma-buf/Kconfig | 21 ++ drivers/dma-buf/Makefile | 2 + drivers/dma-buf/sw_sync.h | 32 ++ drivers/dma-buf/sync_debug.c | 374 +++++++++++++++++++ drivers/dma-buf/sync_debug.h | 35 ++ drivers/dma-buf/sync_file.c | 451 +++++++++++++++++++++++ drivers/dma-buf/sync_timeline.c | 222 +++++++++++ drivers/staging/android/Kconfig | 19 - drivers/staging/android/Makefile | 1 - drivers/staging/android/sw_sync.c | 103 ------ drivers/staging/android/sw_sync.h | 59 --- drivers/staging/android/sync.c | 652 --------------------------------- drivers/staging/android/sync.h | 261 ------------- drivers/staging/android/sync_debug.c | 372 ------------------- drivers/staging/android/trace/sync.h | 82 ----- drivers/staging/android/uapi/sw_sync.h | 32 -- drivers/staging/android/uapi/sync.h | 97 ----- include/linux/sync_file.h | 123 +++++++ include/linux/sync_timeline.h | 114 ++++++ include/trace/events/sync_file.h | 57 +++ include/trace/events/sync_timeline.h | 31 ++ include/uapi/linux/sync.h | 97 +++++ 23 files changed, 1561 insertions(+), 1678 deletions(-) create mode 100644 drivers/dma-buf/Kconfig create mode 100644 drivers/dma-buf/sw_sync.h create mode 100644 drivers/dma-buf/sync_debug.c create mode 100644 drivers/dma-buf/sync_debug.h create mode 100644 drivers/dma-buf/sync_file.c create mode 100644 drivers/dma-buf/sync_timeline.c delete mode 100644 drivers/staging/android/sw_sync.c delete mode 100644 drivers/staging/android/sw_sync.h delete mode 100644 drivers/staging/android/sync.c delete mode 100644 drivers/staging/android/sync.h delete mode 100644 drivers/staging/android/sync_debug.c delete mode 100644 drivers/staging/android/trace/sync.h delete mode 100644 drivers/staging/android/uapi/sw_sync.h delete mode 100644 drivers/staging/android/uapi/sync.h create mode 100644 include/linux/sync_file.h create mode 100644 include/linux/sync_timeline.h create mode 100644 include/trace/events/sync_file.h create mode 100644 include/trace/events/sync_timeline.h create mode 100644 include/uapi/linux/sync.h -- 2.5.0

1 12

[PATCH v2 1/3] drm/etnaviv: fix get pages error path in etnaviv_gem_vaddr
by Lucas Stach 26 Jan '16

26 Jan '16

In case that etnaviv_gem_get_pages is unable to get the required pages the object mutex needs to be unlocked. Also return NULL in this case instead of propagating the error, as callers of this function might not be prepared to handle a pointer error, but expect this call to follow the semantics of a plain vmap to return NULL in case of an error. Signed-off-by: Lucas Stach <l.stach(a)pengutronix.de> --- drivers/gpu/drm/etnaviv/etnaviv_dump.c | 2 +- drivers/gpu/drm/etnaviv/etnaviv_gem.c | 6 ++++-- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_dump.c b/drivers/gpu/drm/etnaviv/etnaviv_dump.c index fd7d3e989e79..09a759e69dd2 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_dump.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_dump.c @@ -216,7 +216,7 @@ void etnaviv_core_dump(struct etnaviv_gpu *gpu) iter.hdr->iova = cpu_to_le64(vram->iova); vaddr = etnaviv_gem_vaddr(&obj->base); - if (vaddr && !IS_ERR(vaddr)) + if (vaddr) memcpy(iter.data, vaddr, obj->base.size); etnaviv_core_dump_header(&iter, ETDUMP_BUF_BO, iter.data + diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c b/drivers/gpu/drm/etnaviv/etnaviv_gem.c index 9f77c3b94cc6..b22712fdd31e 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c @@ -361,8 +361,10 @@ void *etnaviv_gem_vaddr(struct drm_gem_object *obj) if (!etnaviv_obj->vaddr) { struct page **pages = etnaviv_gem_get_pages(etnaviv_obj); - if (IS_ERR(pages)) - return ERR_CAST(pages); + if (IS_ERR(pages)) { + mutex_unlock(&etnaviv_obj->lock); + return NULL; + } etnaviv_obj->vaddr = vmap(pages, obj->size >> PAGE_SHIFT, VM_MAP, pgprot_writecombine(PAGE_KERNEL)); -- 2.7.0.rc3

1 2

omapdrm broken on v4.5-rc1, bisected to "mm, dax, gpu: convert vm_insert_mixed to pfn_t"
by Tomi Valkeinen 26 Jan '16

26 Jan '16

Hi Dan, omapdrm crashes on v4.5-rc1, and I bisected the problem to: 01c8f1c44b83a0825b573e7c723b033cece37b86 ("mm, dax, gpu: convert vm_insert_mixed to pfn_t"). Below is the crash dump. Any ideas? Tomi [ 22.428741] Unable to handle kernel NULL pointer dereference at virtual address 00000014 [ 22.436492] pgd = ed8d8000 [ 22.439666] [00000014] *pgd=aeea3831, *pte=00000000, *ppte=00000000 [ 22.444244] Internal error: Oops: 17 [#1] SMP ARM [ 22.444244] Modules linked in: omapdrm drm_kms_helper drm cfbfillrect cfbimgblt cfbcopyarea panel_dpi connector_analog_tv connector_hdmi connector_dvi encoder_tpd12s015 encoder_tfp410 omapdss [ 22.444244] CPU: 1 PID: 199 Comm: testpat Not tainted 4.4.0-06475-g01c8f1c44b83 #92 [ 22.444244] Hardware name: Generic OMAP4 (Flattened Device Tree) [ 22.444244] task: ed98cfc0 ti: ed982000 task.ti: ed982000 [ 22.487182] PC is at insert_page+0x14/0x1a8 [ 22.487182] LR is at vm_insert_mixed+0x8c/0xbc [ 22.495849] pc : [<c016db74>] lr : [<c016dfc4>] psr: 600c0113 [ 22.495849] sp : ed983d40 ip : ed983d78 fp : ed983d74 [ 22.495849] r10: b6320000 r9 : b6320000 r8 : ed983dc8 [ 22.495849] r7 : b6320000 r6 : 20000000 r5 : ed882710 r4 : 00000000 [ 22.495849] r3 : 00000707 r2 : 00000000 r1 : b6320000 r0 : ed882710 [ 22.495849] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 22.495849] Control: 10c5387d Table: ad8d804a DAC: 00000051 [ 22.532928] Process testpat (pid: 199, stack limit = 0xed982218) [ 22.532928] Stack: (0xed983d40 to 0xed984000) [ 22.545257] 3d40: ed983d64 ed983d50 c00a91dc c00a8a8c 000ada1e 000ada1e ed882710 20000000 [ 22.557342] 3d60: b6320000 ed983dc8 ed983d94 ed983d78 c016dfc4 c016db6c eeeaf034 000ada1e [ 22.557342] 3d80: 00000000 ed882710 ed983dc4 ed983d98 bf13c8f4 c016df44 00000000 f15c9000 [ 22.557342] 3da0: ed847e00 ed882710 ed847e00 00000000 00000000 00010000 ed983dfc ed983dc8 [ 22.582000] 3dc0: c016adac bf13c864 00000055 024200ca 00010000 b6320000 00000000 00000000 [ 22.582000] 3de0: ed882710 ed847e00 ed882710 ed847e00 ed983e84 ed983e00 c016e3b4 c016ad54 [ 22.598449] 3e00: 00000000 ed983e38 c016e1c0 c0b403c7 ed983e34 ed983e20 00000000 00000480 [ 22.598449] 3e20: 00000120 00000040 ed8dad88 00000055 c006d344 c009853c ed98cfc0 00000805 [ 22.598449] 3e40: c090d5d0 0000012f 00000000 ed847e00 b6320000 ed98cfc0 ed983e84 ed983fb0 [ 22.623107] 3e60: ed98cfc0 00000805 ed847e00 b6320000 ed882710 ed847e54 ed983edc ed983e88 [ 22.623107] 3e80: c074c878 c016e150 c01742a4 c0172a64 ed84dc48 00000000 ed845340 00010000 [ 22.623107] 3ea0: 00000000 00000800 ed983ed4 00000055 00000000 00000805 00000805 c074ca50 [ 22.647766] 3ec0: b6320000 ed983fb0 00054180 34324258 ed983efc ed983ee0 c074cb00 c074c620 [ 22.653015] 3ee0: c0a84bbc 00000805 c074ca50 b6320000 ed983fac ed983f00 c0009384 c074ca5c [ 22.664215] 3f00: 00000000 008ca000 ed845340 00000000 ed983f34 ed983f20 c009692c c009ded8 [ 22.664215] 3f20: b6320000 ed847e54 ed983f74 ed983f38 c015a474 c0096918 00000001 00000000 [ 22.664215] 3f40: 00010000 ed983f4c 00000003 00000000 00000001 00000000 008ca000 00000003 [ 22.688873] 3f60: b6320000 00000000 ed983fa4 ed983f78 c0172854 c019cc34 00000001 00010000 [ 22.688873] 3f80: 00000003 00010000 00054180 00038ab4 800c0110 ffffffff 10c5387d 10c5387d [ 22.688873] 3fa0: 00000000 ed983fb0 c074c14c c0009354 ffffffff 008ca000 b6320000 00000000 [ 22.705322] 3fc0: 00000000 00000000 00000000 34325241 34325258 00054180 34324258 00000780 [ 22.705322] 3fe0: 00000000 bebe9278 00038aac 00038ab4 800c0110 ffffffff afffd861 afffdc61 [ 22.705322] Backtrace: [ 22.732452] [<c016db60>] (insert_page) from [<c016dfc4>] (vm_insert_mixed+0x8c/0xbc) [ 22.732452] r8:ed983dc8 r7:b6320000 r6:20000000 r5:ed882710 r4:000ada1e [ 22.740234] [<c016df38>] (vm_insert_mixed) from [<bf13c8f4>] (omap_gem_fault+0x9c/0x150 [omapdrm]) [ 22.756103] r7:ed882710 r6:00000000 r5:000ada1e r4:eeeaf034 [ 22.756103] [<bf13c858>] (omap_gem_fault [omapdrm]) from [<c016adac>] (__do_fault+0x64/0xf0) [ 22.761871] r8:00010000 r7:00000000 r6:00000000 r5:ed847e00 r4:ed882710 [ 22.777130] [<c016ad48>] (__do_fault) from [<c016e3b4>] (handle_mm_fault+0x270/0x1588) [ 22.777130] r5:ed847e00 r4:ed882710 [ 22.777130] [<c016e144>] (handle_mm_fault) from [<c074c878>] (do_page_fault+0x264/0x43c) [ 22.796844] r10:ed847e54 r9:ed882710 r8:b6320000 r7:ed847e00 r6:00000805 r5:ed98cfc0 [ 22.796844] r4:ed983fb0 [ 22.807312] [<c074c614>] (do_page_fault) from [<c074cb00>] (do_translation_fault+0xb0/0xbc) [ 22.815704] r10:34324258 r9:00054180 r8:ed983fb0 r7:b6320000 r6:c074ca50 r5:00000805 [ 22.815704] r4:00000805 [ 22.815704] [<c074ca50>] (do_translation_fault) from [<c0009384>] (do_DataAbort+0x3c/0xbc) [ 22.815704] r7:b6320000 r6:c074ca50 r5:00000805 r4:c0a84bbc [ 22.815704] [<c0009348>] (do_DataAbort) from [<c074c14c>] (__dabt_usr+0x4c/0x60) [ 22.847656] Exception stack(0xed983fb0 to 0xed983ff8) [ 22.847656] 3fa0: ffffffff 008ca000 b6320000 00000000 [ 22.855072] 3fc0: 00000000 00000000 00000000 34325241 34325258 00054180 34324258 00000780 [ 22.855072] 3fe0: 00000000 bebe9278 00038aac 00038ab4 800c0110 ffffffff [ 22.855072] r8:10c5387d r7:10c5387d r6:ffffffff r5:800c0110 r4:00038ab4 [ 22.855072] Code: e92dd9f0 e24cb004 e24dd014 e1a04002 (e5922014) [ 22.888793] ---[ end trace b07c2ddadd5dfa33 ]---

2 1

[PATCH 1/2] drm/etnaviv: fix get pages error path in etnaviv_gem_vaddr
by Lucas Stach 26 Jan '16

26 Jan '16

2 3

[Bug 111271] New: Black stripe on screen with MGAG200 (PowerEdge R320) and modesetting
by bugzilla-daemon＠bugzilla.kernel.org 26 Jan '16

26 Jan '16

https://bugzilla.kernel.org/show_bug.cgi?id=111271 Bug ID: 111271 Summary: Black stripe on screen with MGAG200 (PowerEdge R320) and modesetting Product: Drivers Version: 2.5 Kernel Version: 4.4 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: jean-yves.faye(a)c-s.fr Regression: No Created attachment 201391 --> https://bugzilla.kernel.org/attachment.cgi?id=201391&action=edit dmesg I use Xorg with modesetting driver on a R320 PowerEdge Dell server. I've upgraded kernel from 3.10.40 to a newer version. With the upgrade, a black horizontal stripe appears next to the pointer when moving the mouse to the left edge of the screen. The stripe darker and wider on a CRT screen than a LCD screen it seems. I've tested on 4.4 and the problem is still present. I'm using Xorg with the modesetting driver, and the MGAG200 kernel module (dmesg and Xorg.log attached) I've run a git bisect on the kernel and identified the commit causing the regression : # first bad commit: [9125e6186822b2698da17690416cd1b55c030115] drm: Add drm_plane_force_disable() Unfortunately I'm not familiar with the GPU/DRM part of the kernel, so I can't get this any further. -- You are receiving this mail because: You are watching the assignee of the bug.

1 7

[PATCH] drm/exynos: fix building without CONFIG_PM_SLEEP
by Arnd Bergmann 26 Jan '16

26 Jan '16

The runtime PM operations use the suspend/resume functions even when CONFIG_PM_SLEEP is not set, but this now fails for the exynos DRM driver: exynos_mixer.c:1289:61: error: 'exynos_mixer_resume' undeclared here (not in a function) SET_RUNTIME_PM_OPS(exynos_mixer_suspend, exynos_mixer_resume, NULL) This removes the #ifdef and instead marks the functions as __maybe_unused, which does the right thing in all cases and also looks nicer. Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Fixes: ("drm/exynos: add pm_runtime to Mixer") diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c index 7498c6e76a53..fcaf71df77c1 100644 --- a/drivers/gpu/drm/exynos/exynos_mixer.c +++ b/drivers/gpu/drm/exynos/exynos_mixer.c @@ -1230,8 +1230,7 @@ static int mixer_remove(struct platform_device *pdev) return 0; } -#ifdef CONFIG_PM_SLEEP -static int exynos_mixer_suspend(struct device *dev) +static int __maybe_unused exynos_mixer_suspend(struct device *dev) { struct mixer_context *ctx = dev_get_drvdata(dev); struct mixer_resources *res = &ctx->mixer_res; @@ -1247,7 +1246,7 @@ static int exynos_mixer_suspend(struct device *dev) return 0; } -static int exynos_mixer_resume(struct device *dev) +static int __maybe_unused exynos_mixer_resume(struct device *dev) { struct mixer_context *ctx = dev_get_drvdata(dev); struct mixer_resources *res = &ctx->mixer_res; @@ -1283,7 +1282,6 @@ static int exynos_mixer_resume(struct device *dev) return 0; } -#endif static const struct dev_pm_ops exynos_mixer_pm_ops = { SET_RUNTIME_PM_OPS(exynos_mixer_suspend, exynos_mixer_resume, NULL)

3 5

Re: [Intel-gfx] [PATCH 0/6] Pipe level color management
by Daniel Stone 26 Jan '16

26 Jan '16

Hi Lionel, On 21 January 2016 at 15:03, Lionel Landwerlin <lionel.g.landwerlin(a)intel.com> wrote: > Hi, > > This serie introduces pipe level color management through a set of properties > attached to the CRTC. It also provides an implementation for some Intel > platforms. > > This serie is based of a previous set of patches by Shashank Sharma and takes > into account of the comments by Daniel Stone & Daniel Vetter. This is a lot more tractable than previous series, thanks! I think a lot of the confusion I had around this was from the number of hardware-specific features stuffed into this, and the manner in which they were stuffed in. For example, with the previous series, it looks like you could configure both PRE_CTM and POST_CTM LUTs in 12-bit mode, which is impossible as the PRM suggests the only way to have both LUTs active is with split-gamma mode. (For anyone else looking at the Broadwell PRM, note the split-gamma mode describes the two LUTs completely backwards: the only thing that makes sense is for the pre-CTM LUT to have a range of 0..1.0, and the post-CTM LUT to have a range of -3.0..3.0, rather than the other way around.) Now with everything just using split-gamma mode, I'm much happier with how this is looking. I took a look at some other architectures to see how this would fit, and also had a chat with Richard Hughes to clear some things up. AMD seems to support every possible mode under the sun, so should support any API we came up with. Most other architectures only implemented a single gamma table (equivalent to legacy gamma ramp), but there was one I have fairly detailed documentation for and also supports everything. The degamma/colour-transform-matrix/gamma model is definitely a good one, and it seems like everyone agrees on a 3x3 matrix for CTM. So far, so good. What I worry about is the _values_ we put into the CTM. Intel supports two quite fun properties of matrix output. Firstly, the range is (-3.0..3.0) rather than the (0.0..1.0) you might expect. Negative values are axis-mirrored, i.e. lut2_index = fabs(matrix_output), thus giving us a LUT range of (0.0..3.0). Secondly, whilst (0.0..1.0) is represented by linear LUT entries, the LUT values for (1.0..3.0) are calculated by a linear interpolation between LUT entry #512 (i.e. that for 1.0) and a bonus entry #513 (value for 3.0). I haven't seen this supported anywhere else, so would tend towards mirroring the last value into the extra supernumerary entry, i.e. emulate saturation for matrix output values to 1.0. I don't really know what to do about negative values as CTM output, since the doc I have here is silent on whether negative values are similarly axis-mirrored/sign-stripped, or whether they are instead clamped to 0.0. Either way, I'm not really sure it's behaviour we can rely upon to be portable. As a detail, the architecture I'm looking at has mixed granularity for the second (post-CTM) LUT: lower RGB-value entries have higher granularity (precision in LUT indexing), with lower granularity for higher entries. I don't think this is a problem though, since we can just decimate in the kernel (i.e. ignore every n'th LUT entry, to write a smaller LUT to hardware than we received to userspace). Anyway, beyond that, it seems there are a few things we agree on: - optional pre-matrix ('degamma') per-channel LUT of variable length, but (from a userspace point of view) fixed precision, input & output ranges 0.0..1.0 - optional 3x3 matrix with input range [0.0,1.0], with output values saturating to 1.0, and negative values producing undefined behaviour - optional post-matrix ('gamma') per-channel LUT of variable length, but (from a userspace point of view) fixed precision, input & output ranges 0.0..1.0 This would mean missing some Intel-specific features, but whether or not this is actually required I don't really know. At least it seems like it would be enough to implement standard ICC profile correction from Weston in a hardware-independent manner. Thierry, Alex, did you have any comments or ideas on this? Cheers, Daniel

4 5

gpu: kmalloc size WARNING in vga_arb_write
by Dmitry Vyukov 26 Jan '16

26 Jan '16

Hello, I've hit the following warning while running syzkaller fuzzer: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 29322 at mm/page_alloc.c:2999 __alloc_pages_nodemask+0x7d2/0x1760() Modules linked in: CPU: 2 PID: 29322 Comm: syz-executor Tainted: G B 4.5.0-rc1+ #283 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 00000000ffffffff ffff880069eff670 ffffffff8299a06d 0000000000000000 ffff8800658a4740 ffffffff864985a0 ffff880069eff6b0 ffffffff8134fcf9 ffffffff8166de32 ffffffff864985a0 0000000000000bb7 00000000024040c0 Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [<ffffffff8299a06d>] dump_stack+0x6f/0xa2 lib/dump_stack.c:50 [<ffffffff8134fcf9>] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482 [<ffffffff8134ff29>] warn_slowpath_null+0x29/0x30 kernel/panic.c:515 [< inline >] __alloc_pages_slowpath mm/page_alloc.c:2999 [<ffffffff8166de32>] __alloc_pages_nodemask+0x7d2/0x1760 mm/page_alloc.c:3253 [<ffffffff81745c99>] alloc_pages_current+0xe9/0x450 mm/mempolicy.c:2090 [< inline >] alloc_pages include/linux/gfp.h:459 [<ffffffff81669bb6>] alloc_kmem_pages+0x16/0x100 mm/page_alloc.c:3433 [<ffffffff816c20af>] kmalloc_order+0x1f/0x80 mm/slab_common.c:1008 [<ffffffff816c212f>] kmalloc_order_trace+0x1f/0x140 mm/slab_common.c:1019 [< inline >] kmalloc_large include/linux/slab.h:395 [<ffffffff81756b24>] __kmalloc+0x2f4/0x340 mm/slub.c:3557 [< inline >] kmalloc include/linux/slab.h:468 [<ffffffff832c65a4>] vga_arb_write+0xd4/0xe40 drivers/gpu/vga/vgaarb.c:926 [<ffffffff817a9831>] do_loop_readv_writev+0x141/0x1e0 fs/read_write.c:719 [<ffffffff817ad698>] do_readv_writev+0x5f8/0x6e0 fs/read_write.c:849 [<ffffffff817ad8b6>] vfs_writev+0x86/0xc0 fs/read_write.c:886 [< inline >] SYSC_writev fs/read_write.c:919 [<ffffffff817b0a21>] SyS_writev+0x111/0x2b0 fs/read_write.c:911 [<ffffffff86359636>] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185 ---[ end trace d543527022b589ec ]--- vga_arb_write does: kbuf = kmalloc(count + 1, GFP_KERNEL); The kmalloc should use GFP_USER|__GFP_NOWARN flags since the size is user-controlled. On commit 92e963f50fc74041b5e9e744c330dca48e04f08d.

2 1

[Bug 93360] [radeonsi/llvm] Segfault in CS:GO
by bugzilla-daemon＠freedesktop.org 26 Jan '16

26 Jan '16

https://bugs.freedesktop.org/show_bug.cgi?id=93360 Bug ID: 93360 Summary: [radeonsi/llvm] Segfault in CS:GO Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: tdroste(a)gmx.de QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 120470 --> https://bugs.freedesktop.org/attachment.cgi?id=120470&action=edit Backtrace of the segfault When loading of a level is done in CS:GO and the team selection menu should pop up CS:GO segfaults here: #0 0xf4f2cd2d in llvm::LiveRange::find(llvm::SlotIndex) () from /usr/local/lib/dri/radeonsi_dri.so Hardware: Hawaii PRO [Radeon R9 290] This happens with most recent LLVM SVN and Mesa git, and also with LLVM and Mesa from October. So this seems to be some long standing error in either Mesa or LLVM that is triggered now by a change of CS:GO. -- You are receiving this mail because: You are the assignee for the bug.

1 10

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2016