Re: [PATCH v2 06/11] staging/android: turn fence_info into a __u64 pointer

Op 02-02-16 om 21:28 schreef Gustavo Padovan: > Hi Maarten, > > 2016-02-02 Maarten Lankhorst <maarten.lankho...@linux.intel.com>: > >> Op 02-02-16 om 14:23 schreef Gustavo Padovan: >>> From: Gustavo Padovan <gustavo.pado...@collabora.co.uk> >>> >

Re: [PATCH v3 06/11] staging/android: turn fence_info into a __u64 pointer

Op 03-02-16 om 14:25 schreef Gustavo Padovan: > From: Gustavo Padovan > > Turn sync_fence_info into __u64 type enable us to extend the struct in the > future without breaking the ABI. > > v2: use type __u64 for fence_info > > v3: fix commit message to reflect the

Re: [PATCH v2 02/11] staging/android: rename sync_pt_info to fence_info

Op 02-02-16 om 14:23 schreef Gustavo Padovan: > From: Gustavo Padovan > > As struct sync_pt doesn't exist anymore it is a good idea remove any > reference to it in the sync_framework. sync_pts were replaced directly by > fences. > rename it to sync_fence_info to prevent polluting the global

Re: [PATCH v2 08/11] staging/android: make info->len return only the size of fence_infos

Op 02-02-16 om 14:23 schreef Gustavo Padovan: > From: Gustavo Padovan > > The len member of struct sync_file_info was returning the size of the whole > buffer (struct sync_file_info + fence_infos at the of it). This commit > change it to return only the size of the array of fence_infos. > > It

Re: [PATCH v2 06/11] staging/android: turn fence_info into a __u64 pointer

Op 02-02-16 om 14:23 schreef Gustavo Padovan: > From: Gustavo Padovan > > Making fence_info a pointer enables us to extend the struct in the future > without breaking the ABI. > > v2: use type __u64 for fence_info > Signed-off-by: Gustavo Padovan > --- > drivers/staging/android/sync.c | 2

Re: [PATCH v2 02/11] staging/android: rename sync_pt_info to fence_info

Op 02-02-16 om 14:23 schreef Gustavo Padovan: > From: Gustavo Padovan > > As struct sync_pt doesn't exist anymore it is a good idea remove any > reference to it in the sync_framework. sync_pts were replaced directly by > fences. > rename it to sync_fence_info to

Re: [PATCH v2 06/11] staging/android: turn fence_info into a __u64 pointer

Op 02-02-16 om 14:23 schreef Gustavo Padovan: > From: Gustavo Padovan > > Making fence_info a pointer enables us to extend the struct in the future > without breaking the ABI. > > v2: use type __u64 for fence_info > Signed-off-by: Gustavo Padovan

Re: [PATCH v2 08/11] staging/android: make info->len return only the size of fence_infos

Op 02-02-16 om 14:23 schreef Gustavo Padovan: > From: Gustavo Padovan > > The len member of struct sync_file_info was returning the size of the whole > buffer (struct sync_file_info + fence_infos at the of it). This commit > change it to return only the size of

Re: [PATCH 06/10] staging/android: turn fence_info into a __64 pointer

Op 29-01-16 om 22:20 schreef Gustavo Padovan: > From: Gustavo Padovan > > Making fence_info a pointer enables us to extend the struct in the future > without breaking the ABI. > > Signed-off-by: Gustavo Padovan > --- > drivers/staging/android/sync.c | 2 +- >

Re: [PATCH 09/10] staging/android: add flags member to sync ioctl structs

Op 29-01-16 om 22:20 schreef Gustavo Padovan: > From: Gustavo Padovan > > Play safe and add flags member to all structs. So we don't need to > break API or create new IOCTL in the future if new features that requires > flags arises. > This only helps if you reject flags != 0 in the ioctl, else

Re: [PATCH 09/10] staging/android: add flags member to sync ioctl structs

Op 29-01-16 om 22:20 schreef Gustavo Padovan: > From: Gustavo Padovan > > Play safe and add flags member to all structs. So we don't need to > break API or create new IOCTL in the future if new features that requires > flags arises. > This only helps if you reject

Re: [PATCH 06/10] staging/android: turn fence_info into a __64 pointer

Op 29-01-16 om 22:20 schreef Gustavo Padovan: > From: Gustavo Padovan > > Making fence_info a pointer enables us to extend the struct in the future > without breaking the ABI. > > Signed-off-by: Gustavo Padovan > --- >

Re: [PATCH v2 01/11] dma-buf/sync_file: de-stage sync_file

Hey, Op 27-01-16 om 14:30 schreef Gustavo Padovan: > From: Gustavo Padovan > > sync_file is useful to connect one or more fences to the file. The file is > used by userspace to track fences. > > Signed-off-by: Gustavo Padovan > Is there a value in keeping the abi unchanged? If not, then

Re: [PATCH v2 01/11] dma-buf/sync_file: de-stage sync_file

Hey, Op 27-01-16 om 14:30 schreef Gustavo Padovan: > From: Gustavo Padovan > > sync_file is useful to connect one or more fences to the file. The file is > used by userspace to track fences. > > Signed-off-by: Gustavo Padovan >

Re: [REGRESSION] component: add support for releasing match data

Op 26-01-16 om 15:48 schreef Russell King - ARM Linux: > On Tue, Jan 26, 2016 at 03:28:34PM +0100, Maarten Lankhorst wrote: >> Something similar to a segfault. It's trying to call 0x6b6b6b6b6b which >> is POISON_FREE. >> >> mc appears to be freed already, so cal

Re: [REGRESSION] component: add support for releasing match data

Op 26-01-16 om 15:15 schreef Russell King - ARM Linux: > On Tue, Jan 26, 2016 at 02:42:16PM +0100, Maarten Lankhorst wrote: >> Commit ce657b1cddf1f88c56 ("component: add support for releasing match >> data") causes a general protection fault when unloading snd-hda-inte

[REGRESSION] component: add support for releasing match data

Hey, Commit ce657b1cddf1f88c56 ("component: add support for releasing match data") causes a general protection fault when unloading snd-hda-intel with the i915 module loaded on a recent skylake machine. This breaks one of the i915 acceptance tests that performs a module unload/reload on

[REGRESSION] component: add support for releasing match data

Hey, Commit ce657b1cddf1f88c56 ("component: add support for releasing match data") causes a general protection fault when unloading snd-hda-intel with the i915 module loaded on a recent skylake machine. This breaks one of the i915 acceptance tests that performs a module unload/reload on

Re: [REGRESSION] component: add support for releasing match data

Op 26-01-16 om 15:15 schreef Russell King - ARM Linux: > On Tue, Jan 26, 2016 at 02:42:16PM +0100, Maarten Lankhorst wrote: >> Commit ce657b1cddf1f88c56 ("component: add support for releasing match >> data") causes a general protection fault when unloading snd-hda-inte

Re: [REGRESSION] component: add support for releasing match data

Op 26-01-16 om 15:48 schreef Russell King - ARM Linux: > On Tue, Jan 26, 2016 at 03:28:34PM +0100, Maarten Lankhorst wrote: >> Something similar to a segfault. It's trying to call 0x6b6b6b6b6b which >> is POISON_FREE. >> >> mc appears to be freed already, so cal

Re: [PATCH 00/11] sync framework de-staging: part 1 - clean up

hase > staging/android: remove sync_fence_create_dma() > For whole series: Reviewed-by: Maarten Lankhorst Renaming sync_fence to sync_file makes sense, it should hopefully reduce confusion.

Re: [PATCH 00/11] sync framework de-staging: part 1 - clean up

ntless sync_timeline_signal at destroy > phase > staging/android: remove sync_fence_create_dma() > For whole series: Reviewed-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com> Renaming sync_fence to sync_file makes sense, it should hopefully reduce confusion.

Re: [RFC 00/29] De-stage android's sync framework

Op 20-01-16 om 15:32 schreef Gustavo Padovan: > 2016-01-20 Maarten Lankhorst : > >> Hey, >> >> Op 15-01-16 om 15:55 schreef Gustavo Padovan: >>> From: Gustavo Padovan >>> >>> This patch series de-stage the sync framework, and in order to accomp

Re: [RFC 00/29] De-stage android's sync framework

Op 20-01-16 om 15:32 schreef Gustavo Padovan: > 2016-01-20 Maarten Lankhorst <maarten.lankho...@linux.intel.com>: > >> Hey, >> >> Op 15-01-16 om 15:55 schreef Gustavo Padovan: >>> From: Gustavo Padovan <gustavo.pado...@collabora.co.uk> >>

Re: [PATCH] android: fix warning when releasing active sync point

Op 15-12-15 om 18:19 schreef Dmitry Torokhov: > On Tue, Dec 15, 2015 at 2:01 AM, Maarten Lankhorst > wrote: >> Op 15-12-15 om 02:29 schreef Dmitry Torokhov: >>> Userspace can close the sync device while there are still active fence >>> points, in which case kernel

Re: [PATCH] android: fix warning when releasing active sync point

Op 15-12-15 om 18:19 schreef Dmitry Torokhov: > On Tue, Dec 15, 2015 at 2:01 AM, Maarten Lankhorst > <maarten.lankho...@linux.intel.com> wrote: >> Op 15-12-15 om 02:29 schreef Dmitry Torokhov: >>> Userspace can close the sync device while there are still active fenc

Re: [PATCH] android: fix warning when releasing active sync point

Op 15-12-15 om 02:29 schreef Dmitry Torokhov: > Userspace can close the sync device while there are still active fence > points, in which case kernel produces the following warning: > > [ 43.853176] [ cut here ] > [ 43.857834] WARNING: CPU: 0 PID: 892 at >

Re: [PATCH] android: fix warning when releasing active sync point

Op 15-12-15 om 02:29 schreef Dmitry Torokhov: > Userspace can close the sync device while there are still active fence > points, in which case kernel produces the following warning: > > [ 43.853176] [ cut here ] > [ 43.857834] WARNING: CPU: 0 PID: 892 at >

Re: linux-next: build failure after merge of the drm-misc tree

Op 08-09-15 om 01:42 schreef Stephen Rothwell: > Hi all, > > On Thu, 3 Sep 2015 10:49:19 +1000 Stephen Rothwell > wrote: >> After merging the drm-misc tree, today's linux-next build (arm >> multi_v7_defconfig) failed like this: >> >> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c: In function >>

Re: linux-next: build failure after merge of the drm-misc tree

Op 08-09-15 om 01:42 schreef Stephen Rothwell: > Hi all, > > On Thu, 3 Sep 2015 10:49:19 +1000 Stephen Rothwell > wrote: >> After merging the drm-misc tree, today's linux-next build (arm >> multi_v7_defconfig) failed like this: >> >>

[PATCH] drm/i915: Do not call intel_crtc_disable if the crtc is already disabled.

Signed-off-by: Maarten Lankhorst --- diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 85ac6d85dc39..30e0f54ba19d 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -6315,9 +6315,6 @@ static void intel_crtc_d

[PATCH] drm/i915: Do not call intel_crtc_disable if the crtc is already disabled.

, and can be fixed by not calling intel_crtc_disable when the crtc is already disabled. Reported-and-Tested-by: Jörg Otte jrg.o...@gmail.com Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com --- diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915

Re: [Intel-gfx] [-next] WARNING at i915_gem_track_fb

Op 13-07-15 om 14:51 schreef Sergey Senozhatsky: > 4.2.0-rc2-next-20150713 > > [ 1239.783862] [ cut here ] > [ 1239.783892] WARNING: CPU: 0 PID: 364 at > drivers/gpu/drm/i915/i915_gem.c:5368 i915_gem_track_fb+0xdc/0x106 [i915]() > [ 1239.783894]

Re: [4.2.0-rc1-00201-g59c3cb5] Regression: kernel NULL pointer dereference

Op 13-07-15 om 09:42 schreef Jörg Otte: > 2015-07-13 9:23 GMT+02:00 Maarten Lankhorst > : >> Op 13-07-15 om 08:22 schreef Daniel Vetter: >>> On Sun, Jul 12, 2015 at 09:52:51AM -0700, Linus Torvalds wrote: >>>> On Sun, Jul 12, 2015 at 1:03 AM, Jörg Otte wrote: &

Re: [4.2.0-rc1-00201-g59c3cb5] Regression: kernel NULL pointer dereference

gain, so any testing done on > integration trees (like -next or drm-intel-nightly) won't test any patches > for 4.2. > -Daniel > > Oh and Signed-off-by: Daniel Vetter in case you > decide to apply this right away. > Well your version has the benefit of compiling without errors. :-) Reviewed-by: Maarten Lankhorst -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [Intel-gfx] [-next] WARNING at i915_gem_track_fb

Op 13-07-15 om 14:51 schreef Sergey Senozhatsky: 4.2.0-rc2-next-20150713 [ 1239.783862] [ cut here ] [ 1239.783892] WARNING: CPU: 0 PID: 364 at drivers/gpu/drm/i915/i915_gem.c:5368 i915_gem_track_fb+0xdc/0x106 [i915]() [ 1239.783894] WARN_ON(new-frontbuffer_bits

Re: [4.2.0-rc1-00201-g59c3cb5] Regression: kernel NULL pointer dereference

-by: Maarten Lankhorst maarten.lankho...@linux.intel.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [4.2.0-rc1-00201-g59c3cb5] Regression: kernel NULL pointer dereference

Op 13-07-15 om 09:42 schreef Jörg Otte: 2015-07-13 9:23 GMT+02:00 Maarten Lankhorst maarten.lankho...@linux.intel.com: Op 13-07-15 om 08:22 schreef Daniel Vetter: On Sun, Jul 12, 2015 at 09:52:51AM -0700, Linus Torvalds wrote: On Sun, Jul 12, 2015 at 1:03 AM, Jörg Otte jrg.o...@gmail.com

Re: [4.2.0-rc1-00201-g59c3cb5] Regression: kernel NULL pointer dereference

Op 12-07-15 om 18:52 schreef Linus Torvalds: > On Sun, Jul 12, 2015 at 1:03 AM, Jörg Otte wrote: >> BUG: unable to handle kernel NULL pointer dereference at 0009 >> IP: [] 0xbd3447bb > Ugh. Please enable KALLSYMS to get sane symbols. > > But yes, "crtc_state->base.active" is

Re: [4.2.0-rc1-00201-g59c3cb5] Regression: kernel NULL pointer dereference

Op 12-07-15 om 18:52 schreef Linus Torvalds: On Sun, Jul 12, 2015 at 1:03 AM, Jörg Otte jrg.o...@gmail.com wrote: BUG: unable to handle kernel NULL pointer dereference at 0009 IP: [bd3447bb] 0xbd3447bb Ugh. Please enable KALLSYMS to get sane symbols. But yes,

Re: [lkp] [drm/i915] 7f072451f2d: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun

Hey, Op 15-06-15 om 08:58 schreef Huang Ying: > FYI, we noticed the below changes on > > git://anongit.freedesktop.org/drm-intel drm-intel-next-queued > commit 7f072451f2d3d53e4f6939440e15ab36afed2051 ("drm/i915: Implement > intel_crtc_control using atomic state, v4") > > Test Environment check:

Re: [lkp] [drm/i915] 7f072451f2d: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun

Hey, Op 15-06-15 om 08:58 schreef Huang Ying: FYI, we noticed the below changes on git://anongit.freedesktop.org/drm-intel drm-intel-next-queued commit 7f072451f2d3d53e4f6939440e15ab36afed2051 (drm/i915: Implement intel_crtc_control using atomic state, v4) Test Environment check:

Re: [PATCH 2/3] locking: ww_mutex: Allow to use rt_mutex instead of mutex for the baselock

Hey, Op 10-03-15 om 16:28 schreef Peter Zijlstra: > On Tue, Mar 10, 2015 at 03:10:46PM +0100, Maarten Lankhorst wrote: >> Op 10-03-15 om 13:37 schreef Peter Zijlstra: > >>> So IIRC this is the function that checks who gets wounded (and gets to >>> do the whole r

Re: [PATCH 2/3] locking: ww_mutex: Allow to use rt_mutex instead of mutex for the baselock

Op 10-03-15 om 13:37 schreef Peter Zijlstra: > On Fri, Feb 27, 2015 at 05:57:08PM +0100, Sebastian Andrzej Siewior wrote: >> +static int __sched __mutex_lock_check_stamp(struct rt_mutex *lock, >> +struct ww_acquire_ctx *ctx) >> +{ >> +#ifdef

Re: [PATCH 2/3] locking: ww_mutex: Allow to use rt_mutex instead of mutex for the baselock

Op 10-03-15 om 13:37 schreef Peter Zijlstra: On Fri, Feb 27, 2015 at 05:57:08PM +0100, Sebastian Andrzej Siewior wrote: +static int __sched __mutex_lock_check_stamp(struct rt_mutex *lock, +struct ww_acquire_ctx *ctx) +{ +#ifdef CONFIG_WW_MUTEX_RTMUTEX

Re: [PATCH 2/3] locking: ww_mutex: Allow to use rt_mutex instead of mutex for the baselock

Hey, Op 10-03-15 om 16:28 schreef Peter Zijlstra: On Tue, Mar 10, 2015 at 03:10:46PM +0100, Maarten Lankhorst wrote: Op 10-03-15 om 13:37 schreef Peter Zijlstra: So IIRC this is the function that checks who gets wounded (and gets to do the whole retry thing), right? So for the RT case, I

Re: [PATCH 2/3] locking: ww_mutex: Allow to use rt_mutex instead of mutex for the baselock

On 06-03-15 13:14, Sebastian Andrzej Siewior wrote: > On 03/02/2015 09:46 AM, Maarten Lankhorst wrote: >> Hey, >> >> Op 02-03-15 om 04:20 schreef Mike Galbraith: >>> On Fri, 2015-02-27 at 17:57 +0100, Sebastian Andrzej Siewior wrote: >>>> This patch m

Re: [PATCH 2/3] locking: ww_mutex: Allow to use rt_mutex instead of mutex for the baselock

On 06-03-15 13:14, Sebastian Andrzej Siewior wrote: On 03/02/2015 09:46 AM, Maarten Lankhorst wrote: Hey, Op 02-03-15 om 04:20 schreef Mike Galbraith: On Fri, 2015-02-27 at 17:57 +0100, Sebastian Andrzej Siewior wrote: This patch makes it possible to replace the base mutex by a rt_mutex

Re: [PATCH 2/3] locking: ww_mutex: Allow to use rt_mutex instead of mutex for the baselock

Hey, Op 02-03-15 om 04:20 schreef Mike Galbraith: > On Fri, 2015-02-27 at 17:57 +0100, Sebastian Andrzej Siewior wrote: >> This patch makes it possible to replace the base mutex by a rt_mutex. In >> general one would not do this. > I would argue that the thing should be born as a full fledged

Re: [PATCH 2/3] locking: ww_mutex: Allow to use rt_mutex instead of mutex for the baselock

Hey, Op 02-03-15 om 04:20 schreef Mike Galbraith: On Fri, 2015-02-27 at 17:57 +0100, Sebastian Andrzej Siewior wrote: This patch makes it possible to replace the base mutex by a rt_mutex. In general one would not do this. I would argue that the thing should be born as a full fledged

Re: [PATCH 1/3] locking: ww_mutex: add one level of indirection for access of the lock

Assuming it's compile tested, can't really test that here. :) Reviewed-by: Maarten Lankhorst I can't review the second or third patch, I don't understand rt mutexes well enough. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message

Re: [PATCH 1/3] locking: ww_mutex: add one level of indirection for access of the lock

Assuming it's compile tested, can't really test that here. :) Reviewed-by: Maarten Lankhorst maarten.lankho...@canonical.com I can't review the second or third patch, I don't understand rt mutexes well enough. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body

Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

cons->max_segment_size = (unsigned int)-1; > + cons->segment_boundary_mask = (unsigned long)-1; > +} Use DMA_SEGMENTS_MAX_SEG_COUNT or UINT/ULONG_MAX here instead? Patches look sane, Reviewed-By: Maarten Lankhorst > +/* > + * calc_constraints - calculates if the new attaching d

Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

instead? Patches look sane, Reviewed-By: Maarten Lankhorst maarten.lankho...@canonical.com +/* + * calc_constraints - calculates if the new attaching device's constraints + * match, with the constraints of already attached devices; if yes, returns + * the constraints; else return ERR_PTR(-EINVAL

Re: [PATCH v3] dma-buf: cleanup dma_buf_export() to make it easily extensible

Op 28-01-15 om 13:54 schreef Sumit Semwal: > At present, dma_buf_export() takes a series of parameters, which > makes it difficult to add any new parameters for exporters, if required. > > Make it simpler by moving all these parameters into a struct, and pass > the struct * as parameter to

Re: [PATCH v3] dma-buf: cleanup dma_buf_export() to make it easily extensible

Op 28-01-15 om 13:54 schreef Sumit Semwal: At present, dma_buf_export() takes a series of parameters, which makes it difficult to add any new parameters for exporters, if required. Make it simpler by moving all these parameters into a struct, and pass the struct * as parameter to

Re: [RFC PATCH] unlock rtnl mutex in ic_open_devs while waiting

Op 06-01-15 om 23:21 schreef David Miller: > From: Maarten Lankhorst > Date: Mon, 05 Jan 2015 14:52:06 +0100 > >> This fixes a deadlock with alx_link_check, which takes the rtnl_mutex in >> a work item to check the link. >> >> I have no idea whether

Re: [RFC PATCH] unlock rtnl mutex in ic_open_devs while waiting

Op 06-01-15 om 23:21 schreef David Miller: From: Maarten Lankhorst maarten.lankho...@canonical.com Date: Mon, 05 Jan 2015 14:52:06 +0100 This fixes a deadlock with alx_link_check, which takes the rtnl_mutex in a work item to check the link. I have no idea whether alx should be fixed

[RFC PATCH] unlock rtnl mutex in ic_open_devs while waiting

This fixes a deadlock with alx_link_check, which takes the rtnl_mutex in a work item to check the link. I have no idea whether alx should be fixed or ipconfig.c, but this saves 120 seconds off my boot time. ;-) Signed-off-by: Maarten Lankhorst --- diff --git a/net/ipv4/ipconfig.c b/net/ipv4

[RFC PATCH] unlock rtnl mutex in ic_open_devs while waiting

This fixes a deadlock with alx_link_check, which takes the rtnl_mutex in a work item to check the link. I have no idea whether alx should be fixed or ipconfig.c, but this saves 120 seconds off my boot time. ;-) Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- diff --git a/net

Re: 3.18-rc regression: drm/nouveau: use shared fences for readable objects

Hey, Op 27-11-14 om 02:18 schreef Tobias Klausmann: > > > On 26.11.2014 21:29, Michael Marineau wrote: >> On Mon, Nov 24, 2014 at 11:43 PM, Maarten Lankhorst >> wrote: >>> Hey, >>> >>> Op 22-11-14 om 21:16 schreef Michael Marineau: >>

Re: 3.18-rc regression: drm/nouveau: use shared fences for readable objects

Hey, Op 27-11-14 om 02:18 schreef Tobias Klausmann: On 26.11.2014 21:29, Michael Marineau wrote: On Mon, Nov 24, 2014 at 11:43 PM, Maarten Lankhorst maarten.lankho...@canonical.com wrote: Hey, Op 22-11-14 om 21:16 schreef Michael Marineau: On Nov 22, 2014 11:45 AM, Michael Marineau m

Re: 3.18-rc regression: drm/nouveau: use shared fences for readable objects

Hey, Op 22-11-14 om 21:16 schreef Michael Marineau: > On Nov 22, 2014 11:45 AM, "Michael Marineau" wrote: >> >> On Nov 22, 2014 8:56 AM, "Maarten Lankhorst" < > maarten.lankho...@canonical.com> wrote: >>> Hey, >>> >>> Op 22-1

Re: 3.18-rc regression: drm/nouveau: use shared fences for readable objects

Hey, Op 22-11-14 om 21:16 schreef Michael Marineau: On Nov 22, 2014 11:45 AM, Michael Marineau m...@marineau.org wrote: On Nov 22, 2014 8:56 AM, Maarten Lankhorst maarten.lankho...@canonical.com wrote: Hey, Op 22-11-14 om 01:19 schreef Michael Marineau: On Thu, Nov 20, 2014 at 12:53 AM

Re: 3.18-rc regression: drm/nouveau: use shared fences for readable objects

Hey, Op 22-11-14 om 01:19 schreef Michael Marineau: > On Thu, Nov 20, 2014 at 12:53 AM, Maarten Lankhorst > wrote: >> Op 20-11-14 om 05:06 schreef Michael Marineau: >>> On Wed, Nov 19, 2014 at 12:10 AM, Maarten Lankhorst >>> wrote: >>>> Hey, >>&

Re: 3.18-rc regression: drm/nouveau: use shared fences for readable objects

Hey, Op 22-11-14 om 01:19 schreef Michael Marineau: On Thu, Nov 20, 2014 at 12:53 AM, Maarten Lankhorst maarten.lankho...@canonical.com wrote: Op 20-11-14 om 05:06 schreef Michael Marineau: On Wed, Nov 19, 2014 at 12:10 AM, Maarten Lankhorst maarten.lankho...@canonical.com wrote: Hey

Re: 3.18-rc regression: drm/nouveau: use shared fences for readable objects

Op 20-11-14 om 05:06 schreef Michael Marineau: > On Wed, Nov 19, 2014 at 12:10 AM, Maarten Lankhorst > wrote: >> Hey, >> >> On 19-11-14 07:43, Michael Marineau wrote: >>> On 3.18-rc kernel's I have been intermittently experiencing GPU >>> lockups s

Re: 3.18-rc regression: drm/nouveau: use shared fences for readable objects

Op 20-11-14 om 00:08 schreef Tobias Klausmann: > On 19.11.2014 09:10, Maarten Lankhorst wrote: >> ... >> On the EDITED patch from fixed-fences-for-bisect, can you do the following: >> >> In nouveau/nv84_fence.c function nv84_fence_context_new, remove >> >>

Re: 3.18-rc regression: drm/nouveau: use shared fences for readable objects

Op 20-11-14 om 00:08 schreef Tobias Klausmann: On 19.11.2014 09:10, Maarten Lankhorst wrote: ... On the EDITED patch from fixed-fences-for-bisect, can you do the following: In nouveau/nv84_fence.c function nv84_fence_context_new, remove fctx-base.sequence = nv84_fence_read(chan); and add

Re: 3.18-rc regression: drm/nouveau: use shared fences for readable objects

Op 20-11-14 om 05:06 schreef Michael Marineau: On Wed, Nov 19, 2014 at 12:10 AM, Maarten Lankhorst maarten.lankho...@canonical.com wrote: Hey, On 19-11-14 07:43, Michael Marineau wrote: On 3.18-rc kernel's I have been intermittently experiencing GPU lockups shortly after startup

Re: 3.18-rc regression: drm/nouveau: use shared fences for readable objects

Hey, On 19-11-14 07:43, Michael Marineau wrote: > On 3.18-rc kernel's I have been intermittently experiencing GPU > lockups shortly after startup, accompanied with one or both of the > following errors: > > nouveau E[ PFIFO][:01:00.0] read fault at 0x000734a000 [PTE] > from PBDMA0/HOST_CPU

Re: 3.18-rc regression: drm/nouveau: use shared fences for readable objects

Hey, On 19-11-14 07:43, Michael Marineau wrote: On 3.18-rc kernel's I have been intermittently experiencing GPU lockups shortly after startup, accompanied with one or both of the following errors: nouveau E[ PFIFO][:01:00.0] read fault at 0x000734a000 [PTE] from PBDMA0/HOST_CPU on

Re: [PATCH] drm/irq: BUG_ON() -> WARN_ON()

Hey, Op 10-11-14 om 12:01 schreef Jani Nikula: > On Sat, 08 Nov 2014, Rob Clark wrote: >> Let's make things a bit easier to debug when things go bad (potentially >> under console_lock). >> >> Signed-off-by: Rob Clark >> --- >> drivers/gpu/drm/drm_irq.c | 3 ++- >> 1 file changed, 2

Re: [PATCH] drm/irq: BUG_ON() - WARN_ON()

Hey, Op 10-11-14 om 12:01 schreef Jani Nikula: On Sat, 08 Nov 2014, Rob Clark robdcl...@gmail.com wrote: Let's make things a bit easier to debug when things go bad (potentially under console_lock). Signed-off-by: Rob Clark robdcl...@gmail.com --- drivers/gpu/drm/drm_irq.c | 3 ++- 1 file

Re: page allocator bug in 3.16?

Op 25-09-14 om 23:10 schreef Peter Hurley: > On 09/25/2014 04:33 PM, Alex Deucher wrote: >> On Thu, Sep 25, 2014 at 2:55 PM, Peter Hurley >> wrote: >>> After several days uptime with a 3.16 kernel (generally running >>> Thunderbird, emacs, kernel builds, several Chrome tabs on multiple >>>

Re: page allocator bug in 3.16?

Op 25-09-14 om 23:10 schreef Peter Hurley: On 09/25/2014 04:33 PM, Alex Deucher wrote: On Thu, Sep 25, 2014 at 2:55 PM, Peter Hurley pe...@hurleysoftware.com wrote: After several days uptime with a 3.16 kernel (generally running Thunderbird, emacs, kernel builds, several Chrome tabs on

Re: page allocator bug in 3.16?

Hey, On 25-09-14 20:55, Peter Hurley wrote: > After several days uptime with a 3.16 kernel (generally running > Thunderbird, emacs, kernel builds, several Chrome tabs on multiple > desktop workspaces) I've been seeing some really extreme slowdowns. > > Mostly the slowdowns are associated with

Re: page allocator bug in 3.16?

Hey, On 25-09-14 20:55, Peter Hurley wrote: After several days uptime with a 3.16 kernel (generally running Thunderbird, emacs, kernel builds, several Chrome tabs on multiple desktop workspaces) I've been seeing some really extreme slowdowns. Mostly the slowdowns are associated with

Re: [GIT PULL] x86 fixes

Hey, Op 23-09-14 om 15:18 schreef Matt Fleming: > On Tue, 23 Sep, at 10:18:07AM, Ard Biesheuvel wrote: >> It will be difficult for me to keep up with this thread over the next >> days, so I have added Leif and Roy on cc. If you need to make any >> changes that affect arm64, they should be able to

Re: [GIT PULL] x86 fixes

Hey, Op 23-09-14 om 15:18 schreef Matt Fleming: On Tue, 23 Sep, at 10:18:07AM, Ard Biesheuvel wrote: It will be difficult for me to keep up with this thread over the next days, so I have added Leif and Roy on cc. If you need to make any changes that affect arm64, they should be able to

Re: [REGRESSION] "efi: efistub: Convert into static library" and preparation patches

Hey, Op 08-09-14 om 14:55 schreef Ard Biesheuvel: > On 5 September 2014 22:27, Matt Fleming wrote: >> On Thu, 04 Sep, at 10:37:53PM, Matt Fleming wrote: >>> Thanks Ard, I'll take a look in the morning. >> Maarten, could you try out this patch? >> > Any developments regarding this patch? > I

Re: [REGRESSION] efi: efistub: Convert into static library and preparation patches

Hey, Op 08-09-14 om 14:55 schreef Ard Biesheuvel: On 5 September 2014 22:27, Matt Fleming m...@console-pimps.org wrote: On Thu, 04 Sep, at 10:37:53PM, Matt Fleming wrote: Thanks Ard, I'll take a look in the morning. Maarten, could you try out this patch? Any developments regarding this

Re: [REGRESSION] "efi: efistub: Convert into static library" and preparation patches

Op 04-09-14 om 13:19 schreef Ard Biesheuvel: > >> On 4 sep. 2014, at 12:48, Maarten Lankhorst >> wrote: >> >> Op 03-09-14 om 21:57 schreef Ard Biesheuvel: >>> On 3 September 2014 19:59, Matt Fleming wrote: >>>> On Wed, 03 Sep, at 05:37:2

Re: [REGRESSION] "efi: efistub: Convert into static library" and preparation patches

Op 03-09-14 om 21:57 schreef Ard Biesheuvel: > On 3 September 2014 19:59, Matt Fleming wrote: >> On Wed, 03 Sep, at 05:37:26PM, Ard Biesheuvel wrote: >>> Will do, thanks. >>> >>> @Matt: so there is two ways to fix this, the patch above addressing >>> this single instance, and alternatively,

Re: [REGRESSION] "efi: efistub: Convert into static library" and preparation patches

Op 04-09-14 om 09:40 schreef Matt Fleming: > On Thu, 04 Sep, at 08:47:57AM, Ard Biesheuvel wrote: >> So how about we: >> - add ASSERT(_got == _egot, "GOT entries not supported in >> boot/compressed") to the linker script >> - #define __nogotentry __attribute__((visibility(hidden))) somewhere >> in

Re: [REGRESSION] efi: efistub: Convert into static library and preparation patches

Op 04-09-14 om 09:40 schreef Matt Fleming: On Thu, 04 Sep, at 08:47:57AM, Ard Biesheuvel wrote: So how about we: - add ASSERT(_got == _egot, GOT entries not supported in boot/compressed) to the linker script - #define __nogotentry __attribute__((visibility(hidden))) somewhere in compiler.h

Re: [REGRESSION] efi: efistub: Convert into static library and preparation patches

Op 03-09-14 om 21:57 schreef Ard Biesheuvel: On 3 September 2014 19:59, Matt Fleming m...@console-pimps.org wrote: On Wed, 03 Sep, at 05:37:26PM, Ard Biesheuvel wrote: Will do, thanks. @Matt: so there is two ways to fix this, the patch above addressing this single instance, and

Re: [REGRESSION] efi: efistub: Convert into static library and preparation patches

Op 04-09-14 om 13:19 schreef Ard Biesheuvel: On 4 sep. 2014, at 12:48, Maarten Lankhorst maarten.lankho...@canonical.com wrote: Op 03-09-14 om 21:57 schreef Ard Biesheuvel: On 3 September 2014 19:59, Matt Fleming m...@console-pimps.org wrote: On Wed, 03 Sep, at 05:37:26PM, Ard Biesheuvel

Re: [REGRESSION] "efi: efistub: Convert into static library" and preparation patches

Hey, Op 03-09-14 om 14:18 schreef Ard Biesheuvel: > Could you please try adding the visibility attribute lik this instead? > > diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h > index 044a2fd3c5fe..8725d85f1903 100644 > --- a/arch/x86/include/asm/efi.h > +++

Re: [REGRESSION] "efi: efistub: Convert into static library" and preparation patches

Op 03-09-14 om 08:06 schreef Ard Biesheuvel: > On 2 September 2014 21:29, Matt Fleming wrote: >> On Tue, 02 Sep, at 05:25:58PM, Maarten Lankhorst wrote: >>> Hey, >>> >>> My macbook pro 8.2 fails to do a efi stub boot with these patches. >>> >>>

Re: [REGRESSION] efi: efistub: Convert into static library and preparation patches

Op 03-09-14 om 08:06 schreef Ard Biesheuvel: On 2 September 2014 21:29, Matt Fleming m...@console-pimps.org wrote: On Tue, 02 Sep, at 05:25:58PM, Maarten Lankhorst wrote: Hey, My macbook pro 8.2 fails to do a efi stub boot with these patches. Commit f23cf8bd5c1f49 efi/x86: efistub: Move

Re: [REGRESSION] efi: efistub: Convert into static library and preparation patches

Hey, Op 03-09-14 om 14:18 schreef Ard Biesheuvel: Could you please try adding the visibility attribute lik this instead? diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h index 044a2fd3c5fe..8725d85f1903 100644 --- a/arch/x86/include/asm/efi.h +++

[REGRESSION] "efi: efistub: Convert into static library" and preparation patches

Hey, My macbook pro 8.2 fails to do a efi stub boot with these patches. Commit f23cf8bd5c1f49 "efi/x86: efistub: Move shared dependencies to " causes the first break, but this can be averted by changing struct efi_config *efi_early; to struct efi_config *efi_early

[REGRESSION] efi: efistub: Convert into static library and preparation patches

Hey, My macbook pro 8.2 fails to do a efi stub boot with these patches. Commit f23cf8bd5c1f49 efi/x86: efistub: Move shared dependencies to asm/efi.h causes the first break, but this can be averted by changing struct efi_config *efi_early; to struct efi_config *efi_early

[PATCH] android: fix reference leak in sync_fence_create

According to the documentation sync_fence_create takes ownership of the point, not a reference on the point. This fixes a memory leak introduced in 3.17's android fence rework. Signed-off-by: Maarten Lankhorst Cc: Colin Cross Cc: Dan Carpenter --- drivers/staging/android/sync.c | 1 - 1 file

Re: [PATCH 2/2] android: add sync_fence_create_dma

Hey, Op 28-08-14 om 13:57 schreef Dan Carpenter: > On Thu, Aug 28, 2014 at 08:54:05AM +0200, Maarten Lankhorst wrote: >> Hey, >> >> On 15-08-14 08:46, Greg Kroah-Hartman wrote: >>> On Thu, Aug 14, 2014 at 11:54:52AM +0200, Maarten Lankhorst wrote: >>>>

Re: [PATCH 2/2] android: add sync_fence_create_dma

Hey, Op 28-08-14 om 13:57 schreef Dan Carpenter: On Thu, Aug 28, 2014 at 08:54:05AM +0200, Maarten Lankhorst wrote: Hey, On 15-08-14 08:46, Greg Kroah-Hartman wrote: On Thu, Aug 14, 2014 at 11:54:52AM +0200, Maarten Lankhorst wrote: This allows users of dma fences to create a android fence

[PATCH] android: fix reference leak in sync_fence_create

According to the documentation sync_fence_create takes ownership of the point, not a reference on the point. This fixes a memory leak introduced in 3.17's android fence rework. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com Cc: Colin Cross ccr...@google.com Cc: Dan Carpenter

Re: [PATCH 2/2] android: add sync_fence_create_dma

Hey, On 15-08-14 08:46, Greg Kroah-Hartman wrote: > On Thu, Aug 14, 2014 at 11:54:52AM +0200, Maarten Lankhorst wrote: >> This allows users of dma fences to create a android fence. > > Who is going to use these functions? I need an in-kernel user before I > can add new api

Re: [PATCH 2/2] android: add sync_fence_create_dma

Hey, On 15-08-14 08:46, Greg Kroah-Hartman wrote: On Thu, Aug 14, 2014 at 11:54:52AM +0200, Maarten Lankhorst wrote: This allows users of dma fences to create a android fence. Who is going to use these functions? I need an in-kernel user before I can add new api calls. So I found

<    1   2   3   4   5   6   7   8   9   10   >