Re: [PATCH 02/11] sched/wait,drm: Replace wait_on_atomic_t usage

> Cc: David Airlie <airl...@linux.ie> > Signed-off-by: Peter Zijlstra (Intel) <pet...@infradead.org> Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk> -Chris

Re: [PATCH 02/11] sched/wait,drm: Replace wait_on_atomic_t usage

d-off-by: Peter Zijlstra (Intel) Reviewed-by: Chris Wilson -Chris

Re: [PATCH] [v2] drm/i915/pmu: avoid -Wmaybe-uninitialized warning

e699e30113 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout") > Signed-off-by: Arnd Bergmann <a...@arndb.de> Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk> -Chris

Re: [PATCH] [v2] drm/i915/pmu: avoid -Wmaybe-uninitialized warning

e699e30113 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout") > Signed-off-by: Arnd Bergmann Reviewed-by: Chris Wilson -Chris

Re: [PATCH] drm/i915/pmu: avoid -Wmaybe-uninitialized warning

Quoting Arnd Bergmann (2018-03-13 12:08:29) > The conditional spinlock confuses gcc into thinking the 'flags' value > might contain uninitialized data: > > drivers/gpu/drm/i915/i915_pmu.c: In function '__i915_pmu_event_read': > arch/x86/include/asm/paravirt_types.h:573:3: error: 'flags' may be

Re: [PATCH] drm/i915/pmu: avoid -Wmaybe-uninitialized warning

Quoting Arnd Bergmann (2018-03-13 12:08:29) > The conditional spinlock confuses gcc into thinking the 'flags' value > might contain uninitialized data: > > drivers/gpu/drm/i915/i915_pmu.c: In function '__i915_pmu_event_read': > arch/x86/include/asm/paravirt_types.h:573:3: error: 'flags' may be

[PATCH] kernel: Downgrade warning for unsafe parameters

s we check that every test themselves do not provoke any kernel warnings. References: 91f9d330cc14 ("module: make it possible to have unsafe, tainting module params") Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Jani Nikula <jani.nik...@intel.com> Cc: Rusty Russell

[PATCH] kernel: Downgrade warning for unsafe parameters

s we check that every test themselves do not provoke any kernel warnings. References: 91f9d330cc14 ("module: make it possible to have unsafe, tainting module params") Signed-off-by: Chris Wilson Cc: Jani Nikula Cc: Rusty Russell Cc: Jean Delvare Cc: Andrew Morton Cc: Li Zhong Cc: Petri

Re: [PATCH] drm/i915/selftests: fix inconsistent IS_ERR and PTR_ERR

Quoting Gustavo A. R. Silva (2018-02-15 16:09:09) > > > On 02/15/2018 03:13 AM, Jani Nikula wrote: > > On Wed, 14 Feb 2018, "Gustavo A. R. Silva" wrote: > >> Fix inconsistent IS_ERR and PTR_ERR in shrink_boom. > >> The proper pointer to use is _explode_ instead of

Re: [PATCH] drm/i915/selftests: fix inconsistent IS_ERR and PTR_ERR

Quoting Gustavo A. R. Silva (2018-02-15 16:09:09) > > > On 02/15/2018 03:13 AM, Jani Nikula wrote: > > On Wed, 14 Feb 2018, "Gustavo A. R. Silva" wrote: > >> Fix inconsistent IS_ERR and PTR_ERR in shrink_boom. > >> The proper pointer to use is _explode_ instead of _purge_. > >> > >> This issue

Re: [PATCH V2] lib/scatterlist: Add SG_CHAIN and SG_END macros for LSB encodings

Quoting Anshuman Khandual (2018-02-15 03:33:56) > This replaces scatterlist->page_link LSB encodings with SG_CHAIN and > SG_END definitions without any functional change. > > Signed-off-by: Anshuman Khandual > --- > Changes in V2: > - Changed SG_EMARK as SG_END as

Re: [PATCH V2] lib/scatterlist: Add SG_CHAIN and SG_END macros for LSB encodings

Quoting Anshuman Khandual (2018-02-15 03:33:56) > This replaces scatterlist->page_link LSB encodings with SG_CHAIN and > SG_END definitions without any functional change. > > Signed-off-by: Anshuman Khandual > --- > Changes in V2: > - Changed SG_EMARK as SG_END as per Johannes and Tvrtko > -

Re: [Intel-gfx] [PATCH 2/5] drm: Allow determining if current task is output poll worker

Quoting Lyude Paul (2018-02-12 17:46:11) > On Sun, 2018-02-11 at 10:38 +0100, Lukas Wunner wrote: > > Introduce a helper to determine if the current task is an output poll > > worker. > > > > This allows us to fix a long-standing deadlock in several DRM drivers > > wherein the ->runtime_suspend

Re: [Intel-gfx] [PATCH 2/5] drm: Allow determining if current task is output poll worker

Quoting Lyude Paul (2018-02-12 17:46:11) > On Sun, 2018-02-11 at 10:38 +0100, Lukas Wunner wrote: > > Introduce a helper to determine if the current task is an output poll > > worker. > > > > This allows us to fix a long-standing deadlock in several DRM drivers > > wherein the ->runtime_suspend

Re: [PATCH 0/3] x86 bugfixes for LTO

Quoting Arnd Bergmann (2018-02-02 14:54:28) > Here are three bugfixes for x86 that I needed to get LTO-enabled > kernels to build reliably. I'm not sure abouto that first one > though. Is there a howto on how to build LTO kernels? I tried Andi's lto-415-2 branch, but linking fails with lots of

Re: [PATCH 0/3] x86 bugfixes for LTO

Quoting Arnd Bergmann (2018-02-02 14:54:28) > Here are three bugfixes for x86 that I needed to get LTO-enabled > kernels to build reliably. I'm not sure abouto that first one > though. Is there a howto on how to build LTO kernels? I tried Andi's lto-415-2 branch, but linking fails with lots of

Re: [PATCH] gpu/drm/udl: Replace struct_mutex with driver private lock

Quoting Shreeya Patel (2018-02-09 12:10:56) > dev->struct_mutex is the Big DRM Lock and the only bit where > it’s mandatory is serializing GEM buffer object destruction. > Which unfortunately means drivers have to keep track of that > lock and either call unreference or unreference_locked >

Re: [PATCH] gpu/drm/udl: Replace struct_mutex with driver private lock

Quoting Shreeya Patel (2018-02-09 12:10:56) > dev->struct_mutex is the Big DRM Lock and the only bit where > it’s mandatory is serializing GEM buffer object destruction. > Which unfortunately means drivers have to keep track of that > lock and either call unreference or unreference_locked >

Re: [PATCH] khungtaskd: Kick stuck processes

Quoting Tetsuo Handa (2018-02-08 23:10:43) > Chris Wilson wrote: > > After spotting a stuck process, and having decided not to panic, give > > the task a kick to see if that helps it to recover (e.g. to paper over a > > missed wake up). > > Yes, we are seeing hangs at

Re: [PATCH] khungtaskd: Kick stuck processes

Quoting Tetsuo Handa (2018-02-08 23:10:43) > Chris Wilson wrote: > > After spotting a stuck process, and having decided not to panic, give > > the task a kick to see if that helps it to recover (e.g. to paper over a > > missed wake up). > > Yes, we are seeing hangs at

[PATCH] khungtaskd: Kick stuck processes

-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Ingo Molnar <mi...@kernel.org> Cc: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Cc: Andrew Morton <a...@linux-foundation.org> --- kernel/hung_task.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/hung_tas

[PATCH] khungtaskd: Kick stuck processes

-off-by: Chris Wilson Cc: Ingo Molnar Cc: Tetsuo Handa Cc: Andrew Morton --- kernel/hung_task.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/hung_task.c b/kernel/hung_task.c index 751593ed7c0b..b32acb6bcc63 100644 --- a/kernel/hung_task.c +++ b/kernel/hung_task.c @@ -132,6 +132,8

Re: [PATCH] acpi: osl: Replace GFP_ATOMIC with GFP_KERNEL in acpi_os_execute

Quoting Rafael J. Wysocki (2018-02-08 09:51:41) > On Thursday, January 25, 2018 11:13:41 AM CET Jia-Ju Bai wrote: > > After checking all possible call chains to acpi_os_execute here, > > my tool finds that acpi_os_execute is never called in atomic context. > > And acpi_os_execute calls

Re: [PATCH] acpi: osl: Replace GFP_ATOMIC with GFP_KERNEL in acpi_os_execute

Quoting Rafael J. Wysocki (2018-02-08 09:51:41) > On Thursday, January 25, 2018 11:13:41 AM CET Jia-Ju Bai wrote: > > After checking all possible call chains to acpi_os_execute here, > > my tool finds that acpi_os_execute is never called in atomic context. > > And acpi_os_execute calls

Re: [PATCH 1/2] staging: android: ion: Add __GFP_NOWARN for system contig heap

Quoting Laura Abbott (2018-01-05 19:14:08) > syzbot reported a warning from Ion: > > WARNING: CPU: 1 PID: 3485 at mm/page_alloc.c:3926 > > ... >__alloc_pages_nodemask+0x9fb/0xd80 mm/page_alloc.c:4252 > alloc_pages_current+0xb6/0x1e0 mm/mempolicy.c:2036 > alloc_pages

Re: [PATCH 1/2] staging: android: ion: Add __GFP_NOWARN for system contig heap

Quoting Laura Abbott (2018-01-05 19:14:08) > syzbot reported a warning from Ion: > > WARNING: CPU: 1 PID: 3485 at mm/page_alloc.c:3926 > > ... >__alloc_pages_nodemask+0x9fb/0xd80 mm/page_alloc.c:4252 > alloc_pages_current+0xb6/0x1e0 mm/mempolicy.c:2036 > alloc_pages

Re: [Intel-gfx] Graphics on thinkpad x270 after dock/undock works only for the first time (CPU pipe B FIFO underrun)

Quoting Rodrigo Vivi (2018-01-02 19:21:08) > On Sat, Dec 30, 2017 at 12:53:58PM +, Jiri Kosina wrote: > > On Sat, 30 Dec 2017, Jiri Kosina wrote: > > > > > Seems like disabling RC6 on the kernel command line works this around, > > > and > > > I can dock / undock several times in a row with

Re: [Intel-gfx] Graphics on thinkpad x270 after dock/undock works only for the first time (CPU pipe B FIFO underrun)

Quoting Rodrigo Vivi (2018-01-02 19:21:08) > On Sat, Dec 30, 2017 at 12:53:58PM +, Jiri Kosina wrote: > > On Sat, 30 Dec 2017, Jiri Kosina wrote: > > > > > Seems like disabling RC6 on the kernel command line works this around, > > > and > > > I can dock / undock several times in a row with

Re: [Intel-gfx] [PATCH v2] drm/i915: Try EDID bitbanging on HDMI after failed read

Quoting Rodrigo Vivi (2018-01-02 19:12:18) > On Sun, Dec 31, 2017 at 10:34:54PM +, Stefan Brüns wrote: > > + edid = drm_get_edid(connector, i2c); > > + > > + if (!edid && !intel_gmbus_is_forced_bit(i2c)) { > > + DRM_DEBUG_KMS("HDMI GMBUS EDID read failed, retry using GPIO

Re: [Intel-gfx] [PATCH v2] drm/i915: Try EDID bitbanging on HDMI after failed read

Quoting Rodrigo Vivi (2018-01-02 19:12:18) > On Sun, Dec 31, 2017 at 10:34:54PM +, Stefan Brüns wrote: > > + edid = drm_get_edid(connector, i2c); > > + > > + if (!edid && !intel_gmbus_is_forced_bit(i2c)) { > > + DRM_DEBUG_KMS("HDMI GMBUS EDID read failed, retry using GPIO

Re: [PATCH] swiotlb: suppress warning when __GFP_NOWARN is set v2

Quoting Christian König (2018-01-02 12:13:58) > TTM tries to allocate coherent memory in chunks of 2MB first to improve > TLB efficiency and falls back to allocating 4K pages if that fails. > > Suppress the warning when the 2MB allocations fails since there is a > valid fall back path. > > v2:

Re: [PATCH] swiotlb: suppress warning when __GFP_NOWARN is set v2

Quoting Christian König (2018-01-02 12:13:58) > TTM tries to allocate coherent memory in chunks of 2MB first to improve > TLB efficiency and falls back to allocating 4K pages if that fails. > > Suppress the warning when the 2MB allocations fails since there is a > valid fall back path. > > v2:

Re: PROBLEM: i915 causes complete desktop freezes in 4.15-rc5

Quoting Alexandru Chirvasitu (2017-12-30 17:31:32) > Short description: I get freezes of my desktop completely eliminating > mouse / keyboard functionality. > > I’m on an UltraLap 5330, Processor: i7-7500U, Memory: 32 GB DDR4-2133 > Video Card: Intel HD (included). It's running Void linux 64 bit.

Re: PROBLEM: i915 causes complete desktop freezes in 4.15-rc5

Quoting Alexandru Chirvasitu (2017-12-30 17:31:32) > Short description: I get freezes of my desktop completely eliminating > mouse / keyboard functionality. > > I’m on an UltraLap 5330, Processor: i7-7500U, Memory: 32 GB DDR4-2133 > Video Card: Intel HD (included). It's running Void linux 64 bit.

[PATCH v2] mm/vmalloc: Replace opencoded 4-level page walkers

ge_range()? Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98269 References: msg-id:20161028171825.ga15...@roeck-us.net Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Andrew Morton <a...@linux-foundation.org> Cc: David Rientjes <rient...@google.com> Cc: Vladimir Davydov <

[PATCH v2] mm/vmalloc: Replace opencoded 4-level page walkers

Signed-off-by: Chris Wilson Cc: Andrew Morton Cc: David Rientjes Cc: Vladimir Davydov Cc: Johannes Weiner Cc: Mel Gorman Cc: Wang Xiaoqiang Cc: Jerome Marchand Cc: Joonsoo Kim Cc: linux...@kvack.org --- mm/vmalloc.c | 108 ++- 1 file c

Re: [PATCH] [v2] drm/i915: use static const array for PICK macro

Quoting Chris Wilson (2017-12-11 12:51:42) > Quoting Arnd Bergmann (2017-12-11 12:46:22) > > The varargs macro trick in _PIPE3/_PHY3/_PORT3 was meant as an optimization > > to shrink the i915 kernel module by around 1000 bytes. However, the > > downside is a size regression wi

Re: [PATCH] [v2] drm/i915: use static const array for PICK macro

Quoting Chris Wilson (2017-12-11 12:51:42) > Quoting Arnd Bergmann (2017-12-11 12:46:22) > > The varargs macro trick in _PIPE3/_PHY3/_PORT3 was meant as an optimization > > to shrink the i915 kernel module by around 1000 bytes. However, the > > downside is a size regression wi

Re: [RFC] Rebasing the IDR

Quoting Matthew Wilcox (2017-11-30 17:36:30) > About 40 of the approximately 180 users of the IDR in the kernel are > "1-based" instead of "0-based". That is, they never want to have ID 0 > allocated; they want to see IDs allocated between 1 and N. Usually, that's > expressed like this: > >

Re: [RFC] Rebasing the IDR

Quoting Matthew Wilcox (2017-11-30 17:36:30) > About 40 of the approximately 180 users of the IDR in the kernel are > "1-based" instead of "0-based". That is, they never want to have ID 0 > allocated; they want to see IDs allocated between 1 and N. Usually, that's > expressed like this: > >

Re: [Intel-gfx] [PATCH v3 4/9] drm: Add some HDCP related #defines

Quoting Sean Paul (2017-12-05 05:15:03) > In preparation for implementing HDCP in i915, add some HDCP related > register offsets and defines. The dpcd register offsets will go in > drm_dp_helper.h whereas the ddc offsets along with generic HDCP stuff > will get stuffed in drm_hdcp.h, which is new.

Re: [Intel-gfx] [PATCH v3 4/9] drm: Add some HDCP related #defines

Quoting Sean Paul (2017-12-05 05:15:03) > In preparation for implementing HDCP in i915, add some HDCP related > register offsets and defines. The dpcd register offsets will go in > drm_dp_helper.h whereas the ddc offsets along with generic HDCP stuff > will get stuffed in drm_hdcp.h, which is new.

Re: [Intel-gfx] [PATCH v3 2/9] drm/i915: Add more control to wait_for routines

2 value, > - unsigned int timeout_ms) > + unsigned int fast_timeout_us, > + unsigned int slow_timeout_ms, > + u32 *out_value) > { > unsigned fw = > intel_uncore_forcewake_for_reg(dev_priv, reg, FW_REG_READ); > int ret; > + u32 reg_value; Before int ret; Try to avoid building a Christmas tree if possible. Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk> -Chris

Re: [Intel-gfx] [PATCH v3 2/9] drm/i915: Add more control to wait_for routines

unsigned int timeout_ms) > + unsigned int fast_timeout_us, > + unsigned int slow_timeout_ms, > + u32 *out_value) > { > unsigned fw = > intel_uncore_forcewake_for_reg(dev_priv, reg, FW_REG_READ); > int ret; > + u32 reg_value; Before int ret; Try to avoid building a Christmas tree if possible. Reviewed-by: Chris Wilson -Chris

Re: [Intel-gfx] [PATCH v3 3/9] drm: Add Content Protection property

Quoting Daniel Vetter (2017-12-05 15:34:36) > Two bits missing imo: > - Should explain that userspace should poll this property to detect a > change from ENABLED to DESIRED (and take adequate actions and e.g. stop > the stream). No uevent will be sent out because the HDCP specs require >

Re: [Intel-gfx] [PATCH v3 3/9] drm: Add Content Protection property

Quoting Daniel Vetter (2017-12-05 15:34:36) > Two bits missing imo: > - Should explain that userspace should poll this property to detect a > change from ENABLED to DESIRED (and take adequate actions and e.g. stop > the stream). No uevent will be sent out because the HDCP specs require >

Re: d17a1d97dc ("x86/mm/kasan: don't use vmemmap_populate() to initialize shadow"): BUG: KASAN: use-after-scope in __drm_mm_interval_first

> [ 26.770152] raw: 88007f39c5e8 88007f39c5e8 > [ 26.770152] page dumped because: kasan: bad access detected > [ 26.790299] > [ 26.790299] Memory state around the buggy address: > [ 26.790299] 88006cb3fa80: 00 00 00 00 00 00 00 00 00 00 00

Re: d17a1d97dc ("x86/mm/kasan: don't use vmemmap_populate() to initialize shadow"): BUG: KASAN: use-after-scope in __drm_mm_interval_first

26.790299] > [ 26.790299] Memory state around the buggy address: > [ 26.790299] 88006cb3fa80: 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 f1 > [ 26.790299] 88006cb3fb00: f1 f1 f1 00 f2 f2 f2 f2 f2 f2 f2 00 > 00 f2 f2 f2 > [ 26.790299] >88006cb3fb80: f2 f2 f2 f8 f8 f2 f2 f2 f2 f2 f2 f8 > f8 f8 f8 f8 > [ 26.790299]^ > [ 26.790299] 88006cb3fc00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 > f8 f8 f8 f2 > [ 26.790299] 88006cb3fc80: f2 f2 f2 00 00 00 00 00 00 00 00 00 > 00 00 00 00 > [ 26.790299] > [ 26.790299] frame offset: 232 > [ 26.790299] desc: '5 32 8 3 __u 96 16 4 prng 160 16 7 state__ 224 > 160 3 tmp 416 224 2 mm ' > [ 26.790299] func: __igt_insert+0x0/0xc87 > [ 26.790299] > == > > > That desc string is: number of local objects, then for each object: > offset, size, name length, name. > > So that's variable tmp in __igt_insert. > > Looks very much like a real use-after-scope. The fix should already be in mmotm: commit 3e6e51217dd14dcda10d4bc9a38b1440e2d42c14 Author: Chris Wilson Date: Thu Nov 9 21:24:34 2017 + lib/rbtree,drm/mm: Add rbtree_replace_node_cached() Add a variant of rbtree_replace_node() that maintains the leftmost cache of struct rbtree_root_cached when replacing nodes within the rbtree. -Chris

Re: [Intel-gfx] [PATCH v2 2/8] drm/i915: Add more control to wait_for routines

Quoting Sean Paul (2017-12-01 17:20:24) > /** > - * _wait_for - magic (register) wait macro > + * __wait_for - magic wait macro > * > - * Does the right thing for modeset paths when run under kdgb or similar > atomic > - * contexts. Note that it's important that we check the condition again

Re: [Intel-gfx] [PATCH v2 2/8] drm/i915: Add more control to wait_for routines

Quoting Sean Paul (2017-12-01 17:20:24) > /** > - * _wait_for - magic (register) wait macro > + * __wait_for - magic wait macro > * > - * Does the right thing for modeset paths when run under kdgb or similar > atomic > - * contexts. Note that it's important that we check the condition again

Re: [Intel-gfx] [RFC PATCH 3/6] drm/i915: Add HDCP framework + base implementation

Quoting Sean Paul (2017-11-30 03:08:58) > This patch adds the framework required to add HDCP support to intel > connectors. It implements Aksv loading from fuse, and parts 1/2/3 > of the HDCP authentication scheme. > > Note that without shim implementations, this does not actually implement >

Re: [Intel-gfx] [RFC PATCH 3/6] drm/i915: Add HDCP framework + base implementation

Quoting Sean Paul (2017-11-30 03:08:58) > This patch adds the framework required to add HDCP support to intel > connectors. It implements Aksv loading from fuse, and parts 1/2/3 > of the HDCP authentication scheme. > > Note that without shim implementations, this does not actually implement >

[PATCH] lib/rbtree,drm/mm: Add rbtree_replace_node_cached()

of drm_mm_replace_node() is its testsuite... Fixes: f808c13fd373 ("lib/interval_tree: fast overlap detection") Testcase: igt/drm_mm/replace Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Davidlohr Bueso <dbu...@suse.de> Cc: Jérôme Glisse <jgli...@redhat.com> Cc: Andrew Morto

[PATCH] lib/rbtree,drm/mm: Add rbtree_replace_node_cached()

of drm_mm_replace_node() is its testsuite... Fixes: f808c13fd373 ("lib/interval_tree: fast overlap detection") Testcase: igt/drm_mm/replace Signed-off-by: Chris Wilson Cc: Davidlohr Bueso Cc: Jérôme Glisse Cc: Andrew Morton Cc: Joonas Lahtinen Cc: Daniel Vetter Link: https://patchwork.freedesktop

Re: [PATCH] reservation: don't wait when timeout=0

Quoting Christian König (2017-11-21 15:49:55) > Am 21.11.2017 um 15:59 schrieb Rob Clark: > > On Tue, Nov 21, 2017 at 9:38 AM, Chris Wilson <ch...@chris-wilson.co.uk> > > wrote: > >> Quoting Rob Clark (2017-11-21 14:08:46) > >>> If we are testing

Re: [PATCH] reservation: don't wait when timeout=0

Quoting Christian König (2017-11-21 15:49:55) > Am 21.11.2017 um 15:59 schrieb Rob Clark: > > On Tue, Nov 21, 2017 at 9:38 AM, Chris Wilson > > wrote: > >> Quoting Rob Clark (2017-11-21 14:08:46) > >>> If we are testing if a reservation object's fences hav

Re: [PATCH] reservation: don't wait when timeout=0

Quoting Rob Clark (2017-11-21 14:08:46) > If we are testing if a reservation object's fences have been > signaled with timeout=0 (non-blocking), we need to pass 0 for > timeout to dma_fence_wait_timeout(). > > Plus bonus spelling correction. > > Signed-off-by: Rob Clark >

Re: [PATCH] reservation: don't wait when timeout=0

Quoting Rob Clark (2017-11-21 14:08:46) > If we are testing if a reservation object's fences have been > signaled with timeout=0 (non-blocking), we need to pass 0 for > timeout to dma_fence_wait_timeout(). > > Plus bonus spelling correction. > > Signed-off-by: Rob Clark > --- >

Re: [PATCH] ftrace: Allow configuring global trace buffer size (for dump-on-oops)

Quoting Chris Wilson (2017-11-13 13:07:08) > We have recently turned on ftrace-dump-on-oops for i915's CI and an > issue we have encountered is that the trace buffer size greatly exceeds > the pstore capabilities; we get the tail of the oops but not the > introduction. > > Cu

Re: [PATCH] ftrace: Allow configuring global trace buffer size (for dump-on-oops)

Quoting Chris Wilson (2017-11-13 13:07:08) > We have recently turned on ftrace-dump-on-oops for i915's CI and an > issue we have encountered is that the trace buffer size greatly exceeds > the pstore capabilities; we get the tail of the oops but not the > introduction. > > Cu

[PATCH] ftrace: Allow configuring global trace buffer size (for dump-on-oops)

should suffice for the majority of users; reserving the configuration for those that eschew the cmdline option. Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Steven Rostedt <srost...@redhat.com> Cc: Peter Zijlstra <pet...@infradead.org> Cc: Ingo Molnar <mi...@elte

[PATCH] ftrace: Allow configuring global trace buffer size (for dump-on-oops)

should suffice for the majority of users; reserving the configuration for those that eschew the cmdline option. Signed-off-by: Chris Wilson Cc: Steven Rostedt Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Tomi Sarvela Cc: Joonas Lahtinen Cc: Daniel Vetter --- kernel/trace/Kconfig | 6 ++ kernel

Re: [PATCH] irq_work: Don't reinvent the wheel but use existing llist API

Quoting Frederic Weisbecker (2017-10-31 01:46:54) > From: Byungchul Park > > Although llist provides proper APIs, they are not used. Make them used. > > Signed-off-by: Byungchul Park > Cc: Peter Zijlstra > Signed-off-by:

Re: [PATCH] irq_work: Don't reinvent the wheel but use existing llist API

Quoting Frederic Weisbecker (2017-10-31 01:46:54) > From: Byungchul Park > > Although llist provides proper APIs, they are not used. Make them used. > > Signed-off-by: Byungchul Park > Cc: Peter Zijlstra > Signed-off-by: Frederic Weisbecker > --- > kernel/irq_work.c | 6 +- > 1 file

Re: WARNING in drm_modeset_lock_all

Quoting syzbot (2017-10-27 09:09:50) > This bug is generated by a dumb bot. It may contain errors. > See https://goo.gl/tpsmEJ for details. > Direct all questions to syzkal...@googlegroups.com. > > syzbot will keep track of this bug report. > Once a fix for this bug is committed, please reply to

Re: WARNING in drm_modeset_lock_all

Quoting syzbot (2017-10-27 09:09:50) > This bug is generated by a dumb bot. It may contain errors. > See https://goo.gl/tpsmEJ for details. > Direct all questions to syzkal...@googlegroups.com. > > syzbot will keep track of this bug report. > Once a fix for this bug is committed, please reply to

Re: WARNING in drm_modeset_lock_all

Quoting syzbot (2017-10-27 09:09:50) > Hello, > > syzkaller hit the following crash on > 6f20b7a58cb9c0fe00badcdfd65b1f4a8f28dfc6 > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is

Re: WARNING in drm_modeset_lock_all

Quoting syzbot (2017-10-27 09:09:50) > Hello, > > syzkaller hit the following crash on > 6f20b7a58cb9c0fe00badcdfd65b1f4a8f28dfc6 > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is

Re: [PATCH] drm/i915/selftests: Convert timers to use timer_setup()

Quoting Chris Wilson (2017-10-25 11:24:19) > Quoting Chris Wilson (2017-10-24 17:17:09) > > Quoting Kees Cook (2017-10-24 16:13:44) > > > In preparation for unconditionally passing the struct timer_list pointer > > > to > > > all timer callbacks,

Re: [PATCH] drm/i915/selftests: Convert timers to use timer_setup()

Quoting Chris Wilson (2017-10-25 11:24:19) > Quoting Chris Wilson (2017-10-24 17:17:09) > > Quoting Kees Cook (2017-10-24 16:13:44) > > > In preparation for unconditionally passing the struct timer_list pointer > > > to > > > all timer callbacks,

Re: [PATCH] drm/i915/selftests: Convert timers to use timer_setup()

Quoting Chris Wilson (2017-10-24 17:17:09) > Quoting Kees Cook (2017-10-24 16:13:44) > > In preparation for unconditionally passing the struct timer_list pointer to > > all timer callbacks, switch to using the new timer_setup() and from_timer() > > to pass the timer pointer ex

Re: [PATCH] drm/i915/selftests: Convert timers to use timer_setup()

Quoting Chris Wilson (2017-10-24 17:17:09) > Quoting Kees Cook (2017-10-24 16:13:44) > > In preparation for unconditionally passing the struct timer_list pointer to > > all timer callbacks, switch to using the new timer_setup() and from_timer() > > to pass the timer pointer ex

Re: [PATCH] drm/i915/selftests: Convert timers to use timer_setup()

ux.intel.com> > Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com> > Cc: Rodrigo Vivi <rodrigo.v...@intel.com> > Cc: David Airlie <airl...@linux.ie> > Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com> > Cc: Chris Wilson <ch...@chris-wilson.co.uk> > Cc:

Re: [PATCH] drm/i915/selftests: Convert timers to use timer_setup()

nen > Cc: Rodrigo Vivi > Cc: David Airlie > Cc: Tvrtko Ursulin > Cc: Chris Wilson > Cc: intel-...@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org > Signed-off-by: Kees Cook Thank you for saving me from having to do this myself, Reviewed-by: Chris Wilson -Chris

Re: [Intel-gfx] [PATCH v3] drm/i915: Replace *_reference/unreference() or *_ref/unref with _get/put()

Quoting Harsha Sharma (2017-10-08 15:04:07) > @@ -624,7 +624,7 @@ static bool intel_fbdev_init_bios(struct drm_device *dev, > ifbdev->preferred_bpp = fb->base.format->cpp[0] * 8; > ifbdev->fb = fb; > > - drm_framebuffer_reference(>fb->base); > +

Re: [Intel-gfx] [PATCH v3] drm/i915: Replace *_reference/unreference() or *_ref/unref with _get/put()

Quoting Harsha Sharma (2017-10-08 15:04:07) > @@ -624,7 +624,7 @@ static bool intel_fbdev_init_bios(struct drm_device *dev, > ifbdev->preferred_bpp = fb->base.format->cpp[0] * 8; > ifbdev->fb = fb; > > - drm_framebuffer_reference(>fb->base); > +

Re: [PATCH 2/2] drm/i915: Use rcu instead of stop_machine in set_wedged

rom > > commit 20e4933c478a1ca694b38fa4ac44d99e659941f5 > Author: Chris Wilson <ch...@chris-wilson.co.uk> > Date: Tue Nov 22 14:41:21 2016 + > > drm/i915: Stop the machine as we install the wedged submit_request handler > > Chris said parts of the reasons

Re: [PATCH 2/2] drm/i915: Use rcu instead of stop_machine in set_wedged

rom > > commit 20e4933c478a1ca694b38fa4ac44d99e659941f5 > Author: Chris Wilson > Date: Tue Nov 22 14:41:21 2016 + > > drm/i915: Stop the machine as we install the wedged submit_request handler > > Chris said parts of the reasons for going with stop_machine() was th

Re: [PATCH 1/2] drm/i915: Preallocate our mmu notifier workequeu to unbreak cpu hotplug deadlock

ge_fault+0x2a4/0x570 > do_vfs_ioctl+0x94/0x670 > ? entry_SYSCALL_64_fastpath+0x5/0xb1 > ? __this_cpu_preempt_check+0x13/0x20 > ? trace_hardirqs_on_caller+0xe3/0x1b0 > SyS_ioctl+0x41/0x70 > entry_SYSCALL_64_fastpath+0x1c/0xb1 > RIP: 0033:0x7fbb83c39587 > RSP: 002b:

Re: [PATCH 1/2] drm/i915: Preallocate our mmu notifier workequeu to unbreak cpu hotplug deadlock

ge_fault+0x2a4/0x570 > do_vfs_ioctl+0x94/0x670 > ? entry_SYSCALL_64_fastpath+0x5/0xb1 > ? __this_cpu_preempt_check+0x13/0x20 > ? trace_hardirqs_on_caller+0xe3/0x1b0 > SyS_ioctl+0x41/0x70 > entry_SYSCALL_64_fastpath+0x1c/0xb1 > RIP: 0033:0x7fbb83c39587 > RSP: 002b:7f

Re: [PATCH 1/2] drm/i915: Preallocate our mmu notifier workequeu to unbreak cpu hotplug deadlock

Quoting Daniel Vetter (2017-10-06 10:06:36) > 4.14-rc1 gained the fancy new cross-release support in lockdep, which > seems to have uncovered a few more rules about what is allowed and > isn't. > > This one here seems to indicate that allocating a work-queue while > holding mmap_sem is a no-go,

Re: [PATCH 1/2] drm/i915: Preallocate our mmu notifier workequeu to unbreak cpu hotplug deadlock

Quoting Daniel Vetter (2017-10-06 10:06:36) > 4.14-rc1 gained the fancy new cross-release support in lockdep, which > seems to have uncovered a few more rules about what is allowed and > isn't. > > This one here seems to indicate that allocating a work-queue while > holding mmap_sem is a no-go,

Re: [PATCH 2/2] drm/i915: Use rcu instead of stop_machine in set_wedged

rom > > commit 20e4933c478a1ca694b38fa4ac44d99e659941f5 > Author: Chris Wilson <ch...@chris-wilson.co.uk> > Date: Tue Nov 22 14:41:21 2016 + > > drm/i915: Stop the machine as we install the wedged submit_request handler > > Chris said parts of the reasons

Re: [PATCH 2/2] drm/i915: Use rcu instead of stop_machine in set_wedged

rom > > commit 20e4933c478a1ca694b38fa4ac44d99e659941f5 > Author: Chris Wilson > Date: Tue Nov 22 14:41:21 2016 + > > drm/i915: Stop the machine as we install the wedged submit_request handler > > Chris said parts of the reasons for going with stop_machine() was th

Re: [PATCH] drm/i915: Preallocate mmu notifier to unbreak cpu hotplug deadlock

Quoting Daniel Vetter (2017-10-05 14:22:06) > 4.14-rc1 gained the fancy new cross-release support in lockdep, which > seems to have uncovered a few more rules about what is allowed and > isn't. > > This one here seems to indicate that allocating a work-queue while > holding mmap_sem is a no-go,

Re: [PATCH] drm/i915: Preallocate mmu notifier to unbreak cpu hotplug deadlock

Quoting Daniel Vetter (2017-10-05 14:22:06) > 4.14-rc1 gained the fancy new cross-release support in lockdep, which > seems to have uncovered a few more rules about what is allowed and > isn't. > > This one here seems to indicate that allocating a work-queue while > holding mmap_sem is a no-go,

Re: [PATCH] drm/i915: Preallocate mmu notifier to unbreak cpu hotplug deadlock

a/0x20 [i915] > i915_reset+0xb9/0x230 [i915] > i915_reset_device+0x1f6/0x260 [i915] > ? gen8_gt_irq_ack+0x170/0x170 [i915] > ? work_on_cpu_safe+0x60/0x60 > i915_handle_error+0x2d8/0x430 [i915] > ? vsnprintf+0xd1/0x4b0 > ? scnprintf+0x3a/0x70 > hangcheck_declare_

Re: [PATCH] drm/i915: Preallocate mmu notifier to unbreak cpu hotplug deadlock

a/0x20 [i915] > i915_reset+0xb9/0x230 [i915] > i915_reset_device+0x1f6/0x260 [i915] > ? gen8_gt_irq_ack+0x170/0x170 [i915] > ? work_on_cpu_safe+0x60/0x60 > i915_handle_error+0x2d8/0x430 [i915] > ? vsnprintf+0xd1/0x4b0 > ? scnprintf+0x3a/0x70 > hangcheck_declare_hang+0xd

Re: [PATCH] drm/i915/selftests: fix check for intel IOMMU

ettled for something that appeared good enough (for the small selection of configs I tested). Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk> -Chris

Re: [PATCH] drm/i915/selftests: fix check for intel IOMMU

hing that appeared good enough (for the small selection of configs I tested). Reviewed-by: Chris Wilson -Chris

Re: [PATCH] dma-buf: remove redundant initialization of sg_table

etected by clang scan-build: > "warning: Value stored to 'sg_table' during its initialization is > never read" > > Signed-off-by: Colin Ian King <colin.k...@canonical.com> Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk> -Chris

Re: [PATCH] dma-buf: remove redundant initialization of sg_table

; "warning: Value stored to 'sg_table' during its initialization is > never read" > > Signed-off-by: Colin Ian King Reviewed-by: Chris Wilson -Chris

Re: [PATCH] drm/i915: remove redundant variable hw_check

stored to 'hw_check' during its initialization > is never read" > > Fixes: f6d1973db2d2 ("drm/i915: Move modeset state verifier calls") > Signed-off-by: Colin Ian King <colin.k...@canonical.com> Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk> > --- >

Re: [PATCH] drm/i915: remove redundant variable hw_check

ialization > is never read" > > Fixes: f6d1973db2d2 ("drm/i915: Move modeset state verifier calls") > Signed-off-by: Colin Ian King Reviewed-by: Chris Wilson > --- > drivers/gpu/drm/i915/intel_display.c | 2 -- > 1 file changed, 2 deletions(-) > > di

Re: [Intel-gfx] [PATCH v2 5/5] tools/testing/scatterlist: Test new __sg_alloc_table_from_pages

Quoting Tvrtko Ursulin (2017-09-06 13:10:57) > > On 06/09/2017 11:48, Chris Wilson wrote: > > All ascending. Interesting challenge for 3,2,1,0; it can be coalesced, > > we just don't. I wonder if we are missing some like that. But for the > > Hm, how do you thin

Re: [Intel-gfx] [PATCH v2 5/5] tools/testing/scatterlist: Test new __sg_alloc_table_from_pages

Quoting Tvrtko Ursulin (2017-09-06 13:10:57) > > On 06/09/2017 11:48, Chris Wilson wrote: > > All ascending. Interesting challenge for 3,2,1,0; it can be coalesced, > > we just don't. I wonder if we are missing some like that. But for the > > Hm, how do you thin

Re: [PATCH v2 5/5] tools/testing/scatterlist: Test new __sg_alloc_table_from_pages

of segments depending on > the sequence of input pages and other conditions. > > v2: Move to data driven for readability. > > Signed-off-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com> > Cc: Chris Wilson <ch...@chris-wilson.co.uk> > Cc: linux-kernel@vger.kernel.o

Re: [PATCH v2 5/5] tools/testing/scatterlist: Test new __sg_alloc_table_from_pages

nce of input pages and other conditions. > > v2: Move to data driven for readability. > > Signed-off-by: Tvrtko Ursulin > Cc: Chris Wilson > Cc: linux-kernel@vger.kernel.org > --- > tools/testing/scatterlist/Makefile | 30 + >

Re: Abysmal scheduler performance in Linus' tree?

Quoting Andy Lutomirski (2017-09-06 06:13:39) > I'm running e7d0c41ecc2e372a81741a30894f556afec24315 from Linus' tree > today, and I'm seeing abysmal scheduler performance. Running make -j4 > ends up with all the tasks on CPU 3 most of the time (on my > 4-logical-thread laptop). taskset -c 0

Re: Abysmal scheduler performance in Linus' tree?

Quoting Andy Lutomirski (2017-09-06 06:13:39) > I'm running e7d0c41ecc2e372a81741a30894f556afec24315 from Linus' tree > today, and I'm seeing abysmal scheduler performance. Running make -j4 > ends up with all the tasks on CPU 3 most of the time (on my > 4-logical-thread laptop). taskset -c 0

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