+ Tvrtko and Chris for comments
Code seems to be added in:
commit 0cd4684d6ea9a4ffec33fc19de4dd667bb90d0a5
Author: Tvrtko Ursulin
Date: Tue Nov 21 18:18:50 2017 +
drm/i915/pmu: Add interrupt count metric
I think later in the thread there was a suggestion to replace this with
simple c
e
included boot time memory corruption.
Would that work?
Regards, Joonas
> > > -Original Message-
> > > From: Bjorn Helgaas
> > > Sent: 30 November 2020 22:21
> > > To: Surendrakumar Upadhyay, TejaskumarX
> > >
> > > Cc: Jesse Barnes ; Da
Quoting Bjorn Helgaas (2020-11-04 19:35:56)
> [+cc Jani, Joonas, Rodrigo, David, Daniel]
>
> On Wed, Nov 04, 2020 at 05:35:06PM +0530, Tejas Upadhyay wrote:
> > JSL re-uses the same stolen memory as ICL and EHL.
> >
> > Cc: Lucas De Marchi
> > Cc: Matt Roper
> > Signed-off-by: Tejas Upadhyay
>
Quoting Tvrtko Ursulin (2020-11-03 11:14:32)
>
>
> On 03/11/2020 02:53, Lu Baolu wrote:
> > On 11/2/20 7:52 PM, Tvrtko Ursulin wrote:
> >>
> >> On 02/11/2020 02:00, Lu Baolu wrote:
> >>> Hi Tvrtko,
> >>> On 10/12/20 4:44 PM, Tvrtko Ursulin wrote:
>
> On 29/09/2020 01:11, Lu Baolu wrote:
+ Lionel
Can you please take a look at best resolving the below problem.
Maybe we should eliminate the duplicate declarations? Updating such
a list manually seems error prone to me.
Regards, Joonas
Quoting Mauro Carvalho Chehab (2020-10-13 14:53:59)
> As reported by Sphinx:
>
> ./Docum
Quoting Daniel Vetter (2020-10-01 18:13:26)
> On Thu, Oct 1, 2020 at 5:08 PM Jani Nikula
> wrote:
> >
> > On Thu, 01 Oct 2020, Daniel Vetter wrote:
> > > On Thu, Oct 1, 2020 at 3:53 PM Christoph Hellwig wrote:
> > >>
> > >> On Thu, Oct 01, 2020 at 08:39:17PM +1000, Stephen Rothwell wrote:
> > >
Quoting paul...@kernel.org (2020-09-29 02:30:58)
> From: Thomas Gleixner
>
> CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
> removed. Cleanup the leftovers before doing so.
Change looks fine:
Reviewed-by: Joonas Lahtinen
Are you looking for us to merge or m
Quoting Christoph Hellwig (2020-09-28 15:37:41)
> On Mon, Sep 28, 2020 at 01:13:38PM +0300, Joonas Lahtinen wrote:
> > I think we have a gap that after splitting the drm-intel-next pull requests
> > into
> > two the drm-intel/for-linux-next branch is now missing material f
(+ intel-gfx for being i915 related)
(+ Chris who has looked into the issue)
Hi,
Thanks for reporting!
Could you open a bug report according to following instructions:
https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs
A full dmesg of a bad boot and git bisect logs will be
+ Dave and Daniel
+ Stephen
Quoting Christoph Hellwig (2020-09-26 09:29:59)
> On Fri, Sep 25, 2020 at 07:43:49PM -0700, Andrew Morton wrote:
> > On Thu, 24 Sep 2020 15:58:42 +0200 Christoph Hellwig wrote:
> >
> > > this series removes alloc_vm_area, which was left over from the big
> > > vmalloc
Quoting Stephen Rothwell (2020-06-16 02:39:12)
> Hi all,
>
> After merging the drm-intel-fixes tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from drivers/gpu/drm/i915/gt/intel_lrc.c:5972:
> drivers/gpu/drm/i915/gt/selftest_lrc.c: In function
> 'liv
Quoting john.hubb...@gmail.com (2019-08-02 05:19:37)
> From: John Hubbard
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversion, as described in
Quoting Stephen Rothwell (2019-05-20 15:15:38)
> Hi all,
>
> In commit
>
> 0d90ccb70211 ("drm/i915: Delay semaphore submission until the start of the
> signaler")
>
> Fixes tag
>
> Fixes: e88619646971 ("drm/i915: Use HW semaphores for inter-engine synchroni
>
> has these problem(s):
>
>
Quoting Daniel Vetter (2019-02-19 09:55:27)
> Hi all,
>
> topic/mei-hdcp-2019-02-19:
> Prep patches + headers for the mei-hdcp/i915 component interfaces
>
> Also contains the prep work in the component helpers plus adjustements
> for the snd-hda/i915 component interface.
>
> Plus one small stati
Hi Jerome,
This patch seems to have plenty of Cc:s, but none of the right ones :)
For further iterations, I guess you could use git option --cc to make
sure everyone gets the whole series, and still keep the Cc:s in the
patches themselves relevant to subsystems.
This doesn't seem to be on top of
Quoting Joerg Roedel (2019-01-22 18:51:35)
> On Tue, Jan 22, 2019 at 04:48:26PM +0200, Joonas Lahtinen wrote:
> > According to our IOMMU folks there exists some desire to be able to assign
> > the iGFX device aka have intel_iommu=on instead of intel_iommu=igfx_off
> > due to
Quoting Joerg Roedel (2019-01-22 13:01:09)
> Hi Daniel,
>
> On Tue, Jan 22, 2019 at 11:46:39AM +0100, Daniel Vetter wrote:
> > Note that the string of platforms which have various issues with iommu
> > and igfx is very long, thus far we only disabled it where there's no
> > workaround to stop it f
drm.h' differs
> from latest version at 'include/uapi/drm/i915_drm.h'
> diff -u tools/include/uapi/drm/i915_drm.h include/uapi/drm/i915_drm.h
>
> Cc: Adrian Hunter
> Cc: Chris Wilson
> Cc: Jiri Olsa
> Cc: Joonas Lahtinen
> Cc: Lionel Landwerlin
>
Quoting Eric Wong (2019-01-04 03:06:26)
> Joonas Lahtinen wrote:
> > Quoting Eric Wong (2018-12-27 13:49:48)
> > > I just got a used Thinkpad X201 (Core i5 M 520, Intel QM57
> > > chipset) and hit some kernel panics while trying to view
> > > image/anima
Quoting Eric Wong (2018-12-27 13:49:48)
> I just got a used Thinkpad X201 (Core i5 M 520, Intel QM57
> chipset) and hit some kernel panics while trying to view
> image/animation-intensive stuff in Firefox (X11) unless I use
> "iommu_intel=igfx_off".
>
> With Debian stable backport kernels, "linux-
Quoting Pavel Machek (2018-12-27 10:34:39)
> Hi!
>
> > > > > If you think it is useful, I can try to update my machine to
> > > > > linux-next.
> > > >
> > > > linux-next is closer to drm-tip, so it's better. Do you have some
> > > > specific reason for not wanting to run drm-tip (but linux-next
Quoting Pavel Machek (2018-12-12 20:29:02)
> Hi!
>
> > > > > > > > There's one similar for nouveau in Bugzilla, but it seems like
> > > > > > > > a genuine
> > > > > > > > memory corruption (1 bit flipped):
> > > > > > > >
> > > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=84880
> > >
#5
> [31850.668487] Hardware name: LENOVO 42872WU/42872WU, BIOS 8DET74WW
> (1.44 ) 03/13/2018
>
> Dmesg and /sys/class/drm/card0/error are attached.
>
> Best regards,
> Pavel
--
Joonas Lahtinen
Open Source Graphics Center
Intel Corporation
sible to bisect
which commit fixed it, and backport that. On the other hand, if it's
still reproducible, we know we're not spending time on something we
already fixed, and the priority gets a bump.
> If you think it is useful, I can try to update my machine to
> linux-next.
linux-next is closer to drm-tip, so it's better. Do you have some
specific reason for not wanting to run drm-tip (but linux-next is still
ok)?
Regards, Joonas
>
> Best regards,
> Pavel
>
--
Joonas Lahtinen
Open Source Graphics Center
Intel Corporation
Quoting Hans Holmberg (2018-11-21 13:35:19)
> On Wed, Nov 21, 2018 at 11:10 AM Joonas Lahtinen
> wrote:
> >
> > Quoting Hans Holmberg (2018-11-21 11:54:23)
> > > From: Hans Holmberg
> > >
> > > There is no need to rebuild i915_gpu_error.o when the v
Quoting Jani Nikula (2018-04-27 12:20:55)
> On Wed, 25 Apr 2018, Ian W MORRISON wrote:
> > Can I ask if this is on anyone's radar as I'm concerned this patch will
> > stall otherwise?
>
> Pushed to drm-intel-next-queued, thanks for the patch.
>
> I opted to drop the Cc: stable for now. This does
Quoting Jani Nikula (2018-04-17 12:02:52)
> On Mon, 16 Apr 2018, "Srivatsa, Anusha" wrote:
> >>-Original Message-
> >>From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> >>Sent: Wednesday, April 11, 2018 5:27 AM
> >>To: Ian W MORRISON
> >>Cc: Vivi, Rodrigo ; Srivatsa, Anusha
> >>; Wa
Quoting Stephen Rothwell (2018-03-23 02:50:18)
> Hi all,
>
> On Thu, 22 Mar 2018 13:21:29 +1100 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the drm-intel tree got a conflict in:
> >
> > drivers/gpu/drm/i915/gvt/scheduler.c
> >
> > between commit:
> >
> > fa3dd623e559 ("d
Quoting Salvatore Mesoraca (2018-03-13 21:51:28)
> Avoid 3 VLAs[1] by using real constant expressions instead of variables.
> The compiler should be able to optimize the original code and avoid using
> any actual VLAs. Anyway this change is useful because it will avoid a false
> positives with -Wvl
Quoting Jani Nikula (2018-02-19 11:34:34)
> On Fri, 16 Feb 2018, Bjorn Helgaas wrote:
> > On Mon, Nov 27, 2017 at 11:57:46AM -0500, Sinan Kaya wrote:
> >> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> >> where a PCI device is present. This restricts the device drivers to
On Tue, 2017-12-12 at 19:07 -0500, Sinan Kaya wrote:
> On 12/12/2017 9:04 AM, Joonas Lahtinen wrote:
> > Hi,
> >
> > I sent this individual i915 patch to our CI, and it is passing on
> > all platforms:
> >
> > https://patchwork.freedesktop.org/series/3482
CI_DEVFN(0, 0));
> > + int domain = pci_domain_nr(dev_priv->drm.pdev->bus);
> > +
> > + dev_priv->bridge_dev =
> > + pci_get_domain_bus_and_slot(domain, 0, PCI_DEVFN(0, 0));
> > if (!dev_priv->bridge_dev) {
> > DRM_ERROR("bridge device not found\n");
> > return -1;
> >
>
>
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
ough the drm-tip tree
as previously discussed.
Regards, Joonas
On Mon, 2017-12-11 at 12:14 +, Matthew Auld wrote:
> From: Joonas Lahtinen
>
> To give upcoming SKU BIOSes more flexibility in placing the Intel
> graphics stolen memory, make all variables storing the placement or s
+ GVT folks.
On Fri, 2017-12-08 at 09:15 +1100, Stephen Rothwell wrote:
> Hi all,
>
> Commit
>
> 365ad5df9caa ("drm/i915/gvt: Export
> intel_gvt_render_mmio_to_ring_id()")
>
> is missing a Signed-off-by from its committer.
>
--
Joonas Lahtine
uot;drm/i915: Add support for drm syncobjs")
There's been request to reduce the amount of Fixes: tags that are not
actually fixing bugs. This seems more like an optimization.
References: has been suggested for these cases instead.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
->mode_config.max_width = 8192;
> - dev->mode_config.max_height = 8192;
> + dev->mode_config.max_width = 16384;
> + dev->mode_config.max_height = 16384;
> }
>
> if (IS_I845G(dev_priv) || IS_I865G(dev_priv)) {
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
dered? Like:
#define FALLTHROUGH __attribute__((fallthrough));
With the appropriate version checks, of course.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
Jani Nikula
> Cc: David Airlie
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Tvrtko Ursulin
> Cc: Oscar Mateo
> Cc: intel-...@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Kees Cook
> Reviewed-by: Joonas Lahtinen # for
> mock
and removed the variable
altogether. I Cc'd you on the patch.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
On Tue, 2017-10-10 at 13:58 +0300, Joonas Lahtinen wrote:
> On Tue, 2017-10-10 at 17:50 +0800, Tina Zhang wrote:
> > GEM proxy is a kind of GEM, whose backing physical memory is pinned
> > and produced by guest VM and is used by host as read only. With GEM
> > proxy, host is
)
> i915_gem_set_caching_ioctl
> i915_gem_set_domain_ioctl
> i915_gem_sw_finish_ioctl
> i915_gem_set_tiling_ioctl
> i915_gem_madvise_ioctl
>
> Signed-off-by: Tina Zhang
> Cc: Daniel Vetter
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> +++ b/drivers/gpu/drm/i91
Jani Nikula
> Cc: David Airlie
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Tvrtko Ursulin
> Cc: Oscar Mateo
> Cc: intel-...@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: Thomas Gleixner
> Signed-off-by: Kees Cook
> @@ -32,9 +32,9 @@
probably the way to go :)
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
strange
hardware or kernel driver behavior.
You should choose depending on how often your function gets called, and
how critical the execution time is.
Hopefully this clarified things.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
; void *dst = NULL;
> > > > int ret = 0;
> > > >
> > >
> > > Applied this, thanks!
> >
> > Is it possible for bb_size to be both >= 2g and valid?
>
> Never be possible in practise and if really that big I think somethin
On ti, 2017-05-30 at 13:00 -0700, Hugh Dickins wrote:
> On Mon, 22 May 2017, Joonas Lahtinen wrote:
> > On la, 2017-05-20 at 10:56 +0900, J. R. Okajima wrote:
> > > "J. R. Okajima":
> > > >
> > > > I don't know whether the fix is good to m
/patchwork.freedesktop.org/patch/156990/
For quick testing on older kernels, just remove all lines with "_rcu"
in drivers/gpu/drm/i915/i915_gem_shrinker.c .
Regards, Joonas
PS: It'll help to subscribe to and track our mailing list at
intel-...@lists.freedesktop.org for future convenience.
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
he
> synchronize_rcu_expedited from the _count methods where it was useless
> (in addition to unsafe).
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
On ti, 2017-05-09 at 20:04 -0700, Hugh Dickins wrote:
> On Mon, 8 May 2017, Joonas Lahtinen wrote:
> > On pe, 2017-05-05 at 14:57 -0700, Hugh Dickins wrote:
> > > On Fri, 5 May 2017, Joonas Lahtinen wrote:
> > > > On ma, 2017-05-01 at 11:05 +0900, J. R. Okajima wrote:
On pe, 2017-05-05 at 14:57 -0700, Hugh Dickins wrote:
> On Fri, 5 May 2017, Joonas Lahtinen wrote:
> > On ma, 2017-05-01 at 11:05 +0900, J. R. Okajima wrote:
> > > Thanx for the reply.
> > >
> > > Andrea Arcangeli:
> > > >
> > > &g
the
bug.
I've anyway gone and prepared a patch to drop the RCU sync completely
from shrinker phase, as discussed originally with Chris.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
ase struct_mutex.
> + */
> + synchronize_rcu_expedited();
> +
> return freed;
> }
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
GFP_KERNEL);
> > struct drm_file *file;
> > int err;
>
filp = kzalloc(sizeof(*filp), GFP_KERNEL);
if (unlikely(!filp)) {
err = -ENOMEM;
goto err;
}
And appropriate onion teardown in case drm_open fails, so that we don't
leak memory.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
> v4.8 I've had it in all (four, actually) boots.
>
> What am I expected to do about this WARNING?
>
Bisecting the offending commit between v4.8 and v4.8.1 would be a good
start.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
: Joonas Lahtinen
---
This time CC'ing triv...@kernel.org too in the hopes of finally getting this in.
---
kernel/cpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index d948e44..d74199d 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -155,7 +
ing out of memory. Here, we can instead schedule a task to run
> on the other CPU to do the flush before trying again.
>
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Joerg Roedel
> Cc: io...@lists.linux-foundation.org
> Cc: linux-kernel@vger.kernel.
isable(); var = this_cpu_ptr() to var = get_cpu_ptr()
> v3: Actually use get_cpu_ptr (not get_cpu_var). Drop the spinlock
> removal, concentrate on the immediate bug fix.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96293
> Signed-off-by: Chris Wilson
> Cc: Joonas L
and try and reap objects holding onto vmaps.
>
> Signed-off-by: Chris Wilson
> Cc: Andrew Morton
> Cc: David Rientjes
> Cc: Roman Pen
> Cc: Mel Gorman
> Cc: linux...@kvack.org
> Cc: linux-kernel@vger.kernel.org
> Cc: Joonas Lahtinen
A comment below. But regardles
> Cc: Roman Peniaev
> Cc: Mel Gorman
> Cc: linux...@kvack.org
> Cc: linux-kernel@vger.kernel.org
> Acked-by: Andrew Morton # for inclusion via DRM
> Cc: Joonas Lahtinen
Reviewed-by: Joonas Lahtinen
> Cc: Tvrtko Ursulin
> ---
> include/linux/vmalloc.h | 4
>
On to, 2016-03-31 at 13:15 -0700, Greg Kroah-Hartman wrote:
> On Thu, Mar 31, 2016 at 08:30:05PM +0300, Joonas Lahtinen wrote:
> >
> > On to, 2016-03-31 at 12:49 -0400, Tejun Heo wrote:
> > >
> > > On Thu, Mar 31, 2016 at 11:45:06AM +0100, Chris Wilson wrote:
>
he
> > kernfs file mutex:
> ...
> >
> > Reported-by: Ville Syrjälä
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94350
> > Signed-off-by: Chris Wilson
> > Reviewed-by: Joonas Lahtinen
> > Cc: Ville Syrjälä
> > Cc: Joonas Lahtinen
> > C
up_write(&policy->rwsem);
>
> pm_suspend(...)
> ...disable_nonboot_cpus()
> _cpu_down()
> cpu_hotplug_begin(); // Locks cpu_hotplug.lock
> __cpu_notify(CPU_DOWN_PREPARE, ...);
>
Hi,
On ma, 2016-02-15 at 18:06 +0100, Peter Zijlstra wrote:
> On Mon, Feb 15, 2016 at 03:17:55PM +0100, Peter Zijlstra wrote:
> > On Mon, Feb 15, 2016 at 02:36:43PM +0200, Joonas Lahtinen wrote:
> > > Instead of implementing a custom locked reference counting, use lockref.
&g
should have been caught by cpuhp_lock_*
lockdep tracking.
So I'll move the discussion to linux-pm list to change the CPUfreq code. Thanks
for the comments.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
On ti, 2016-02-16 at 12:07 +0100, Peter Zijlstra wrote:
> On Tue, Feb 16, 2016 at 12:51:03PM +0200, Joonas Lahtinen wrote:
> > Quoting my original patch;
> >
> > "See the Bugzilla link for more details.
>
> If its not in the Changelog it doesn't exist. Patch
On ti, 2016-02-16 at 10:14 +0100, Peter Zijlstra wrote:
> On Tue, Feb 16, 2016 at 10:49:36AM +0200, Joonas Lahtinen wrote:
> > I originally thought of implementing this more similar to what you
> > specify, but then I came across a discussion in the mailing list where
> > it
Hi,
On ma, 2016-02-15 at 18:06 +0100, Peter Zijlstra wrote:
> On Mon, Feb 15, 2016 at 03:17:55PM +0100, Peter Zijlstra wrote:
> > On Mon, Feb 15, 2016 at 02:36:43PM +0200, Joonas Lahtinen wrote:
> > > Instead of implementing a custom locked reference counting, use lockref.
&g
a link for more
details.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93294
Cc: Linux kernel development
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: David Hildenbrand
Cc: Paul E. McKenney
Cc: Gautham R. Shenoy
Cc: Chris Wilson
Signed-off-by: Joonas Lahtinen
---
kernel/cpu.
Hi,
According to scripts/get_maintainer.pl Ingo or Peter would be more
appropriate to merge.
Added them as To:
On ke, 2016-02-03 at 22:42 +0530, Gautham R Shenoy wrote:
> Hello Joonas,
>
> On Wed, Feb 03, 2016 at 04:24:28PM +0200, Joonas Lahtinen wrote:
> > Use disti
Use distinctive name for cpu_hotplug.dep_map to avoid the actual
cpu_hotplug.lock appearing as cpu_hotplug.lock#2 in lockdep splats.
Cc: Gautham R. Shenoy
Cc: Rafael J. Wysocki
Cc: Intel graphics driver community testing & development
Signed-off-by: Joonas Lahtinen
---
kernel/cpu.c
70 matches
Mail list logo
